lisa-gemdos VS circle

The origin story of the GEM stuff is quite interesting. Lee Lorenzen was an employee at Xerox in Texas, and wanted to get some of the ideas from the Star onto commodity x86 hardware (just prior to IBM PC). He made a prototype, presented it, and it went nowhere. Gary Kildall (DR) then recruited him to come work for them doing basically that. He (Lorenzen) later went off to spin up his own company -- which created Ventura Publisher, which was built on a fork of GEM.

GEM maybe has a bad reputation as a bit of a Mac UI knockoff, but the history is actually deeper than that. Like a lot of things DR did, it got a bit neglected on the market.

Atari Corp also did a bad job of ongoing maintenance of this stuff. At least not until the latest-80s/early 90s when they suddenly started to iterate on it, hired Eric Smith (author of "MiNT" a unixy multitasking kernel that built overtop GEMDOS) to work on the OS, and pushed out proper multitasking versions... for their 68020/030 machines ... but too late.

It'd be cool if Landon Dyer (who is a user here) were to comment on this, as he was on the team that ported all this stuff from x86 to 68k. Unfortunately it looks like his blog where he wrote this up (dadhacker.com) seems to be gone (!?), it was great writing.

I also believe some of the sources from GEMDOS were used as part of the DR-DOS source tree later. All of this is GPL now.

Also interesting, before the ST, the 68k port of GEMDOS was run on Motorola VME 68k machines, but also on the Apple Lisa. The version running on the latter has since been resurrected, and boots:

https://github.com/cheesestraws/lisa-gemdos

Finally, the (GPL'd) EmuTOS source code base basically did all of the heroic work of porting the original DR sources to the Atari ST again, based on the original DR sources. And they have done an amazing job of reproducing Atari/DR's work faithfully.

https://emutos.sourceforge.io/

That, and EmuTOS runs lovely on other 68k machines (Amiga, Mac, and Lisa for example) as well as ColdFire machines (the "FireBee" Atari-ish computer, and dev boards). It's a great little 68k/ColdFire operating system that is quite portable and well supported.

EmuTOS running on Amiga: https://www.youtube.com/watch?v=uxIytWnqQnU

FWIW having seen the sources for both, GEMDOS isn't based directly off CP/M68k. There are commonalities, and some bits of code shared (executable format for one) but they're entirely separate codebases.

The first platform to run GEMDOS on 68k was the Apple Lisa. That was the dev machine DR used.

That's been resurrected in the past few years: https://github.com/cheesestraws/lisa-gemdos

And in fact EmuTOS itself now boots on the Lisa again.

I have a feeling the stack-based calling convention may be influenced by the dev period on the Lisa? The reason I say this is that I know Mac OS Classic used this scheme as well: push all args to stack and call TRAP. I suspect because of this that the Lisa did as well, though I couldn't tell you for sure since hardly any docs are out there for that. Atari was not unique in choosing these scheme.

Now, why Apple did this, I don't know. Maybe it's because they wrote everything in their own bespoke Pascal and that was something about their compiler?

I am not sure an x86 version of GEMDOS really ever existed so doubt it came from there.

FWIW you got me interested, so I'm reading the CP/M68k sources right now and from the bits I've read, I do see the stack based calling convention there, as well:

  _bios2:

If you're a developer and feeling adventurous, you can also try building it yourself. The source is all on GitHub. It uses the circle-stdlib project (which is circle plus some additions to support much of the C and C++ standard libraries) as a submodule; hopefully I've set that up correctly, but you could always clone that separately and place it in the MiniScript-Pi folder. Check out circle's build instructions for info on setting up your toolchain. (Mac users: be careful with the configure script, which does not work properly on MacOS; find me on Discord and I'll help you fix the script or configure manually.)

I suggest checking out circle https://github.com/rsta2/circle since it's basically a library for the pi hardware. I'm doing some experiments with it myself now.

You can also run a Pi without an operating system, programming it in C or C++ probably. See for example: GitHub - rsta2/circle: A C++ bare metal environment for Raspberry Pi with USB (32 and 64 bit)

BMC64 is VICE in a trenchcoat unikernel / bare-metal framework called Circle: https://github.com/rsta2/circle

It uses the circle library (https://github.com/rsta2/circle) to provide a minimal runtime (mainly to interface with the hardware).

I experimented with circle the other day (https://github.com/rsta2/circle) Looks promising, and most likely within your knowledge of C/C++ development.

Natively would be amazing but a vast amount of work.

The way Apple moved classic MacOS from 680x0 to PowerPC was to write a tiny kernel emulator, with an API to run native stuff on the metal, and run more or less the whole OS under emulation, profile it and just translate the most speed-critical bits.

That's a lot of work for a FOSS project but given the performance delta between 1980s 680x0 and 2020s ARM, total emulation of the whole thing should be perfectly fine. It's how the PiStorm Amiga upgrade works.

https://amigastore.eu/853-pistorm.html

So all I envision is something like Aranym:

https://aranym.github.io/

... running on top of Ultibo, say:

https://ultibo.org/

Or maybe Circle:

https://github.com/rsta2/circle

Circle is a C++ bare metal programming environment for the Raspberry Pi.

The only other reasonable option would be to port it to a new platform which is popular that has a few well documented hardware interfaces so as not to create a hellish nightmare writing drivers. Maybe then you could do a one-off port to that platform (though you might have to re-target the HolyC compiler to target it instead if it is not x86_64). The Raspberry PI seems like a decent option here since there is already a baremetal C++ library supporting USB, keyboard, mouse, sound, video, and as an added bonus UART, I2C, SPI, GPIO. You would have good code examples for porting all the necessary drivers. But obviously this would still be a lot of work and the compiler would need to be re-targeted and user space adapted for running on ARM. That being said backwards compatibility is strong, ARM seems actually interested in keeping it that way (at least for now). The library I'm talking about is here: https://github.com/rsta2/circle