True about the limited I/O, but not true about the layers. The RPi can run a variety of operating systems, including various Linux distributions, but it can also be programmed at bare metal level, running ARM code written in assembly. There are several github projects laying out some staged experiments specifically to help people learn how to do this.
See for example https://github.com/dwelch67/raspberrypi
[edit: and also http://www.valvers.com/open-software/ra ... g-in-cpt1/
which is bare metal but using C.]

Indeed, there's a project now running, over on Stardot, to hook up a raspberry Pi as an ARM-powered second processor to an Acorn Beeb, which is of course a 6502 machine:
http://stardot.org.uk/forums/viewtopic.php?f=3&t=10421
The minimal code needed on the Pi side will be written in assembly language to the bare metal. The interconnect to the 6502 host will be partly SPI based.

Interesting. However, if someone were interested in running ARM code from the bare metal, I would recommend starting with a smaller ARM microcontroller instead. For instance, if you get an NXP LPC chip, you can download the free FlashMagic program, and use it to write a file to flash through a UART port. All you need on a Cortex is to put the initial stack pointer at address 0, and the reset vector at address 4, pointing to your bare metal code. Hit reset, and your program starts, running off the internal oscillator (which is accurate enough to run the UART).

The single greatest advantage of the Pi is that it boots from SD card. So you can have one card to boot a linux, another to boot RiscOS, one for your minecraft or your scratch, and another for your bare metal work. There's no way that a mistake or misbehaviour in one environment can affect another - perfect isolation!

I do agree that an ARM microcontroller is also an interesting platform!

But I'm guessing the RPi offers a rather steep learning curve for the bare metal fans. I once made a bootloader for an TI OMAP SoC + companion chip, and the combined programming manuals were about 8000 pages, and the chip required many registers to set up correctly before you can get down to business. For someone coming out of the 6502 world, that can be a daunting task. At least with a simple microcontroller, the internal memories are all ready to go when you hit reset, and setting up an I/O port or a UART may require setting up just a handful or registers.

Well, from what I recall of the github examples, I believe it's not too bad. Of course for many purposes you can copy and paste instead of reading enormous manuals.

That's what I did. And then I only looked at a few relevant parts for my work. However, if your aim is to truly understand everything from the ground up, you shouldn't copy somebody else's code. Using it as an example is very helpful though.

There's also a danger with only consulting the parts of the manual that you think are relevant. The other day I was struggling for hours trying to get a peripheral to work, only to discover that it wasn't getting any clock, despite me setting the clock enable bit. Turns out that the module that had the clock enable bit wasn't powered, and required its own power enable bit, which was of course documented in a completely different part of the manual.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Meh, it's typically crappy 3rd party drivers that are crashy, not the kernel proper. But if hating on Microsoft empowers you, then attaboy I guess.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As Garth has revealed this (interesting) thread I like to throw in my 2 cents

First of all, the '816 is the only publicly available "official" successor of the 6502. There may other variants of this CPU being embedded somewhere, I don't know. Being an old fellow of the 6502 I cannot but take a look at that beast . To be honest - when I read the Byte article (198?) about the '816 I found it disgusting - yes! Being strongly influenced by CPUs like 68000 and Z8000 (only books) this '816 thing was no match. OK, the backwards compatibility could be nice - but who wants to run old 8 bit stuff anymore? Then these mode flags!! Oh no! After all this trouble with the D-flag now more of that?
But then:

THIS nifty trick did raise my acceptance of the '816 significantly. This means a reasonable C compiler (or similar stack oriented languages) could produce acceptable results. And although here and there some 16 bit limits were present they can circumvented using long pointers and long addressing. As for fun building a sort of a home computer using a '816 (something like a "Mensch computer", just a little updated) seems to be a long range goal.

In the daily business there is no room for 65xx(x) stuff. Too expensive, outdated, difficult to use, poor tools,... Perhaps for educational purposes these basic components are of some use.

It *does* change the landscape considerably! I'm not the only one to think of it, though. I subsequently saw it mentioned elsewhere on 6502.org, and almost certainly it was in the designers' minds as well.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm not sure whether this was truly the case. In the Byte article (Byte 1984, issue 8 (mostly architecture), and issue 9 (hardware)) they did not emphasis that. Perhaps I have overseen it, but this technique isn't mentioned in Eyes/Lichty "Programming the 65816" as well.

My assumption is based on the existence of the "Stack Relative Indirect Indexed" addressing mode. This is very similar to the "Direct Indirect Indexed". Would they have included the Stack Relative mode knowing that transferring SP to DPR would make the deal?

Correct! I was thinking of 16 bit successors only. The 65CE02 was a fine improvement, sadly that it wasn't distributed with more emphasis. (Otherwise I would have one for sure )

Of course they should have/take the time but I know (or have learned) how difficult it is to judge the strength and weakness of a processor just by glimpsing at its instructions and register set. And of course it depends too on the application(s) you have in mind when looking at something new.


When driving a Rolls Royce you do not think about parking spots.

Sure, some products do exist. I bet the Jetta example is typical: pretty much thoroughly proofed and verified software - no one is allowed to change a single bit never! For one of our customers we have built weird workarounds in hardware as no one dares to touch the software! In that special case I remember only one (!) table value needs to be altered - and the overall CRC of course. But instead we built a hardware that alters the databus when this (and only this) fetch was taken