This is about what we can learn from the old to help with the new.
I hope that those that are working on Operating Systems and Bare Metal projects for the RPi take a moment to look at the past themselves to better understand where the future could go.
I want only to inspire any developer to look at the past before implementing something new on the RPi, especially if it is an OS. We can learn a lot for the past, especially if writing an Operating System.
Looking at the HW, quickly:
I have been looking at the capabilities of the Raspberry Pi in terms of what the HW provides us. A bit of a bare metal view, though it may put into perspective what we may learn from the past in furthering the Raspberry Pi. The hope is to learn what can be done in, and what has worked well in the past that can be brought up to the RPi, especially in the areas of OS, Games, Graphics applications, and similar. In this I am mostly ignoring the VideoCoreIV for anything other than a FrameBuffer and simple DSP (which is a way that we can use the VideoCore well even in bare metal).
Blitter: Of the retro systems being compared only the Amiga and Atari ST/Falcon had Blitter. The DMA controllers of the Raspberry Pi are more than capable of doing most of what the blitter of the past did, and the newer DMA has abilities that Blitter could never dream about. So this is one that has come to a nearly direct evolution of the technology.
Copper: Only the Amiga had a Copper. Today the same thing can be done on the RPi with ease, though differently. This requires a small amount of code on the GPU, though within our limits, to implement the equivalent of a display list, and tell the DMA what to do. Though we only have one horizontal and vertical resolution on screen at a time with the RPi. There may even be other ways to accomplish this trick without the GPU (and without the CPU), I just do not know them yet.
MMU: The Atari TT/Falcon Some Amiga's, and the Acorn Archimedes had and used an MMU. The Raspberry Pi has a good ARM MMU, that is more capable than any of the Archimedes versions, though somewhat limiting compared to the 68040 and some 68030 versions. For just memory mapping and protection we have a great MMU that provides everything we need, we just lost a few nice tricks of the 680x0 series.
Clocks: This is one where all had them, to varying resolutions, and we have more and more choices of resolution. This may seem a bit simple though it is still very important in doing things on computers.
HW Sprites/Blobs: Only the Amiga had useful ones, Archimedes had only one. On the Raspberry Pi we have no hardware sprites at all. Though we have HW that can perform the actions needed to implement sprites with minimal software intervention, and do so as well as the Amiga did with Blobs, though at higher resolutions and higher color depths.
DSP: Only the Falcon had a DSP of the oldies. The Raspberry Pi has both an accessible GPU that can act as a DSP without interfering with graphics, and the VFP/NEON unit that runs asynchronous to the CPU (though does require intervention of the CPU). So this is another area where the RPi has evolved, though this really is useful to any system even though most of the oldies did not have it.
HW Summery: In most areas the capability of the RPi HW is best described as a better Amiga, I bet you did not expect that. The above is short and readable compared to the research that I have done looking at everything, and how it fits into actual real world usage of the systems. So lets look at what this means for the OS, by taking a look at Amiga OS and Atari TOS+MiNT(ignoring the others as they are not so good at fitting even the HW they ran on [other than RISC OS, and it does not really fit using the extra features so well]). Some will note that I left out multiple processors, this was so extremely rare in the 80's that it is not something that most people ever saw in any form.
Amiga OS, TOS+MiNT, and fitting the RPi
When the wars were going between Atari users and Amiga users I was using both, so had a more comparative perspective, noting that each is better at somethings than the other, so it comes down what you want it to do.
TOS+MiNT was an interesting system, in being a sudo-unixish system running a truly lean GUI on top. This is a OS that probably could have done quite well on just about any HW, though it did take advantage of the Blitter on the ST/Falcon. One of the points that was both a strength and weakness of TOS+MiNT is the way it used TRAP instructions to call the OS (think SWI on ARM), as it was a good balance between everything having its own separate trap call (like Mac OS with A-Line ops, or RISC OS with SWI's) and having to few entry points (like Linux kernel today), it made things manageable for maintaining speed (though not as good as the Amiga way). TOS+MiNT was not very good at interfacing to and truely taking advantage of the HW, and its systems for implementing new drivers were somewhat hacky in ways that would make a modern OS programmer cringe (hacky can sometimes be good, though if you remember intercepting interrupts multiple layers deep in TOS+MiNT, yuck).
Now Amiga OS was all about moving base pointers, fiddling with memory in unique ways that were way faster than what the CPU could ever do. And the Amiga hardware kept part of memory to the chipset and part to the CPU, making it so that the CPU had to go through the chip set to access the chipsets RAM (SlowRAM). Does this sound familiar? What about the memory on the RPi? Pretty much the same between the two. And the executable formats (including that of libraries) was great, it was complete, lean, simple to work with, and relocatable (not like the ELF that is not as easy to work with, though still good).
So the Amiga OS does so well, what the features of the Amiga OS that we can learn from, in terms of writing BareMetal or OS software for the RPi?
- Use HW outside the CPU whenever it will give the CPU more time (excluding the GPU in this statement, for other reasons).
- Make any entry points to for the kernel minimal in nature (for OS dev).
- Keep the kernel small minimal and simple, like Amiga Exec.
- Take advantage of shared address spaces (one reason the Amiga was so fast for a microkernel).
- Use a lean format for libraries, the is quick and easy to interpret and relocate, though still complete.
- Do not use special formats for drivers or kernel modules (this is one that got me, recently).
- Minimize the need for context switches into a privileged CPU mode.
- Use only a minimal number of scripts to load everything up, though do use Scripts.
- Use device oriented file system access.
- Have all devices represented in the same way, including file system devices.
- Amiga had no memory protection, as she ran in System mode all the time, we want memory protection.
- Do not use a file system that imposes limits on growing files within the normal limits of the file system, so no OFS.
- Provide limits on the programs accessing HW to help prevent conflicts.
EDIT2: Removed statement that could have been missleading.