One of my research areas is security or trust enhancements in compilation. Synthesis, too. Almost all of that work focuses on 32-64 bits due to limitations of lower ones. Yet, I keep seeing projects such as this and SymbOS that blow my mind in what can be done with so little hardware. I think the implementation techniques used in them probably contain plenty of wisdom that could lead to improvements in embedded compiler and metaprogramming research. Maybe even 32-64 bit systems in just making better usage of resources.
Need to have a whole collection of articles for implementing HLL constructs and algorithms effectively in 8-16 bit systems. Maybe 4bit while we're at it to give these 8-bit show-offs a challenge. ;)
EDIT: Editing to add the interesting link below I found on 4-bit computing courtesy of Wikipedia's article on 4-bit. Interesting part was how manufacturers brought offer to developers as invite only. Wonder if they've since transitioned to 8-bit.
I'll email you some of the work I've posted. Background is high assurance security engineering. Dealing with software lifecycle, compilers, etc are part of it. Meanwhile, I just posted an essay with references relevant to the topic you're interested in:
Interesting observation: Despite it's graphical resemblance to early Mac OS, preemptive multi-tasking actually makes this OS substantially more advanced.
Haha yeah. This and SymbOS are what we might see in an alternative future if all the chip fabs announced: "Ok. We tried to scale. The physics were just impossible. You have to keep using the same hardware and just do more with it."
Much more interesting than I thought they'd be, though. :)
If they ported Wolf3d, that would be awesome. That was just a guy walking around in a Wolf3d room. Lamest vid ever. Is there one of them actually playing the game, sound FX, shooting bad guys, etc?
Nonetheless, the 8-bit stuff described here does make one wonder what people will do with raspberry pi's in 30 years. Might be really cool stuff. Two teams give me a hint at where it might go based on prior lightweight work:
They both run with limited hardware. Moving things like graphics and audio to dedicated hardware as many SOC's do today will only expand what you can do with minimal processors.
It's not just the windows - it's a host of details. I spent many hours staring at that original monochrome Macintosh interface, and the homage here is obvious.
- Single menu bar at the top of the screen
- System logo menu to the left of the application menus
- Clock on the right side of the menu bar
- Desktop icons arranged top to bottom on the right
- Trash icon in the bottom right
- Same medium grey dithered desktop background
- Same light grey dithered scroll bar fill
- Horizontal stripe pattern in the window title bar
- Centered window title text
- Identical window zoom icon placed in identical location
- Identical file browser window header and column arrangement
The system font is different (likely because it is smaller), the scroll arrows are different, and the Mac never had accelerator-key underlines in its menus, but it is very, very clear that the people designing this interface knew the classic Mac OS well and have purposefully based their design on it.
I had little idea what it would look like when I first started experimenting with window managers, but it was Paul Fisher's initial mock-ups and font designs which steered things towards the Mac "look". I was just happy to have some guidance and help regarding the visuals, since I was too busy with code to design fonts. But it's clear that Paul took a lot of design cues from System 1-7, and this led me to study those same GUIs closely, although I diverged from that when it came to the tab controls on the Profiler (task manager). But yeah: homage it is, and it's also practical, since it looks good at such a low resolution.
Compare to e.g. AmigaOS or Atari's own GEM for the ST/TT line and you'll see what he means. It's much closer to the original MacOS style than the main alternatives of the period.
But it has fewer pixels to play with and video and audio hardware that has at least ten times the power of that of a 128k Macintosh :-)
I would like to see a description of that multi-tasking solution. A simple way to do it that I see is to give each of those 16 processes 16 bytes of stack space, but that would be very tight. You would have to carefully count your stack depth in every subroutine. An alternative is to go for a software stack, but that is slow.
Like many computers of the time, the Ataris accessed more than 64K of memory by switching banks. Depending on how the banks are selected (size and whether a bank can appear at any address or not, be writable) doing multitasking can be actually easy.
As already noted, the Atari's banking window is outside of the stack area. IIRC, André Fachat's Geck/OS optionally makes use of an enhanced MMU which bank switches the stack area, but we have no such mechanism on the Atari. What I came up with is a hybrid stack segmentation/caching approach. Even when copying is required, stack frames are typically very shallow, so the fixed stack isn't quite as burdensome as supposed.
Looks interesting. Is the code available somewhere? It certainly sucks it's not possible to map any 16K bank to any 16K segment (shouldn't be too difficult) but I guess nobody was thinking about multitasking and memory protection when those computers were designed.
I'm not releasing the kernel or graphics library code for the moment (it's not finished, for one thing), but application sources will be available and drivers, etc, will all be open-source. The fixed 16KB banking window is a pain in one respect, namely that applications (which themselves are relocated into the banking window) cannot directly access MALLOCed RAM. Of course there are ways around this, but I was a little envious of the more flexible banking schemes on some of the Z80 platforms described in the SymbOS developer docs. But it's also fun working around the Atari's limitations.
> After a further six months of nagging doubts about the proprietary “window mask” technology I had designed, I decided to take the plunge and do what Jörn had suggested might lead to a considerable increase in rendering speed: namely, to abandon the window masks (which, it turned out, might as well have been called “regions”), and use a traditional dirty-rectangle window management system, as used in SymbOS.
This is pretty funny when you recall regions were a key part of the original Macintosh system software — as described in “I Still Remember Regions”:
I just started getting into programming on the 6809, which looks to have be designed by the same developers as the 6502. Wonder if in a few years I'll be able to do the same :)
Edit: I'm reminded of OS-9, but I don't believe that matches the bullet points from the article
MOS took engineers from Motorola who made the 6800 chip, cloned it and MOS 6501 was pin compatible with the 6800 and the 6502 changed two pins. Motorola sued and won over the 6501 but not the 6502.
The 6809 was a 16 bit chip IIRC. TRS-80 COCO used it. It was the original chip to be used on the $600 Macintosh project until Steve Jobs took it over and changed it to the 68000 CPU.
6800 cost $300 and 6502 cost $30, guess which ones the 8 bit video game consoles and computers wanted to use?
I'm pretty sure the 6809 is still considered a 8-bit processor. You could treat 2 of the 8-bit registers as a 16-bit, but it was still 8-bit registers.
I had a friend in high school who upgraded from the TRS-80 COCO to the TRS-80 COCO2 and offered me his old computer. I already had a Commodore 64 and I told him no, to give it to another friend who didn't have a computer yet. I should have taken it so I could run OS9 on it.
I guess my Atari 400 won't run it (only upgraded to 48k - yeah soldering), but my 130XE looks good for it. I didn't know about flash cartridge (or Ultimate 1MB/Incognito). If the mouse uses the joystick port, how does it work (paddle?)?
Doing preemptive multitasking (with hardware memory protection, more or less) was actually not too hard on the 130XE (and the variants that added more RAM... I had mine up to 320K at one point, and some people even had 1 or 2 MB).
The extra RAM on those machines appeared in 16K banks that could be switched in and out by setting a control register.
Code in one 16K bank was totally isolated from code in other banks. Obviously code that wasn't located in that part of the address space could access anything that was in the currently switched-in bank, but there was no way for one bank to directly access another.
I wrote a primitive multitasking kernel (nowhere near as elaborate as this) using a C package that simulated a 16 bit machine by using multiple bytes of Page 0 as pseudo-registers. You just had to save those off before switching banks and jumping back to the other task.
It actually worked reasonably well, but not fast enough to be practical.
In addition to this, Jörn convinced me that pre-emptive multitasking was possible on the 6502, so in May 2014, I began the arduous task of converting the existing code to run from a bank-switched cartridge, while simultaneously designing the pre-emptively multitasking kernel.
What is especially heartening at this stage is that the 8-bit Atari can actually run a pre-emptive scheduler, and run it well – in spite of the 6502’s fixed stack.
In 1987 I published a preemptive multitasking for 6502[1] (Apple II). If I remember properly (it's only been 30 years or so), the stack is fixed at $100, so all you need to do on a context switch is save the stack somewhere else and restore it. That's 256 bytes to move around. I used the mouse card as an interrupt source (video refresh) to get a regular source of interrupts.
[1] I can't find any trace online, except for some weird Word document of what must have been the original README file.
The main thing that is unlike the original hardware is the 128kb memory target and the addition of a mouse. The 64kb era was effectively ushered in with the C64 and 800XL in 1982, but 128kb came a few years later and concurrent with a market shift to 16-bit CPUs. Accessing that much memory on an 8-bit isn't a natural fit for their addressing capability, even though there are several examples of models shipping with it.
(In a lot of ways memory posed a bigger problem than CPU time back then.)
Need to have a whole collection of articles for implementing HLL constructs and algorithms effectively in 8-16 bit systems. Maybe 4bit while we're at it to give these 8-bit show-offs a challenge. ;)
EDIT: Editing to add the interesting link below I found on 4-bit computing courtesy of Wikipedia's article on 4-bit. Interesting part was how manufacturers brought offer to developers as invite only. Wonder if they've since transitioned to 8-bit.
http://www.embeddedinsights.com/channels/2010/12/10/consider...