4 ms·

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 c

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 8080/8086 hardware (just prior to IBM PC, still in latter stages of the CP/M era). 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. You can see Lorenzen's original pitch to Xerox of his "LoneStar" prototype here: https://www.youtube.com/watch?v=EMBGRZftS30 https://www.youtube.com/watch?v=EMBGRZftS30 I believe he has gone on since to be involved in venture investment. 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. The ability to fairly easily port MS/PC-DOS software to the Atari ST could have been a "secret power" for the ST, but didn't really pan out. The ST did have the ability to work with PC floppies and filesystems, and that was super useful. I recall we were promised ports of e.g. Lotus 123, and MS Word, and neither became a thing. Well, Word did (MS Write) but it was a hot mess (https://www.atarimagazines.com/startv3n1/microsoftwrite.html https://www.atarimagazines.com/startv3n1/microsoftwrite.html), and there were better indigenous word processors already. Also interesting, before the ST was ready, the 68k port of GEM & GEMDOS was run on Motorola VME 68k machines, but also on the Apple Lisa. The article touches on this, but seems to think the Lisa port was not completed, but it actually was, and the has since been resurrected, and boots: https://github.com/cheesestraws/lisa-gemdos https://github.com/cheesestraws/lisa-gemdos https://stardot.org.uk/forums/viewtopic.php?t=20964 https://stardot.org.uk/forums/viewtopic.php?t=20964 https://68kmla.org/bb/index.php?threads/gemdos-on-the-lisa-can-be-built-again.35896/ https://68kmla.org/bb/index.php?threads/gemdos-on-the-lisa-c... Finally, the (GPL'd) EmuTOS team has basically done 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/ https://emutos.sourceforge.io/ So the Atari ST now has a fully open source GPL'd operating system stack. 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. If you build out a 68k or ColdFire based board it is a good choice as an OS. EmuTOS running on Amiga: https://www.youtube.com/watch?v=uxIytWnqQnU https://www.youtube.com/watch?v=uxIytWnqQnU

Rochus 3y ago
Great resources, thanks for sharing!
Beijinger 3y ago
Oh wow. You mean these things run EmuTOS? https://www.mouser.com/c/embedded-solutions/engineering-tools/embedded-processor-development-kits/development-boards-kits-coldfire/ https://www.mouser.com/c/embedded-solutions/engineering-tool... I first mistook coldfire for Firebee ST https://acp.atari.org/about.html https://acp.atari.org/about.html
- cmrdporcupine 3y ago
  There are ColdFire boards that can. Only certain ones. I think this the one that is officially "supported": M5484LITE https://www.nxp.com/products/no-longer-manufactured/mcf5484-lite-evaluation-kit:M5484LITE https://www.nxp.com/products/no-longer-manufactured/mcf5484-... There are various ColdFires, I forget the differences between them and which EmuTOS supports, but it's documented in their repo I believe. A lot comes down to memory map, and uart, etc. Some years ago I made an attempt to get it to boot in qemu's coldfire personality but only got part way. But I think other's have maybe done this since? Or at least in the qemu 68k emulator.
  - rbanffy 3y ago
    Ouch! $50+ for a 32-bit MCU destroys my hopes of an RPi-sized "modern" Atari ST. OTOH, NXP claims they can still make 68060's if we want a lot of them. Well... At least ARM boards can emulate a 68060 faster than a 68060 can run itself.
    - cmrdporcupine 3y ago
      Yeah these days you're better off either emulating or just doing FPGA. An Artix A7 could do a 68k series pretty damned well. If you're aiming low at <100mhz and just 68000/68010 compatibility, you can fit the whole machine on a single relatively cheap FPGA. Re: ARM SBC, I always wonder if you could get one of those ARM boards to boot in big-endian, to make the emulation easier. Because technically ARM can be bi-endian. I think I tried it with an old RPi before, and had no luck. There was someone working on an ARM port of EmuTOS for a bit. I played with that myself, taking bits of EmuTOS and doing them native ARM. My idea was that your usercode could be emulated, running 68k, but when you passed the syscall boundary (TRAP/SWI etc) you could flip to running native ARM. I don't have the src anywhere anymore I think, but I even had things like the VT52 console ported over, etc. Endianness is one problem, but also the fact that the Atari ST had planar video and very specific modes, so you end up basically writing the VDI from scratch, you can't borrow anything from EmuTOS VDI really. Maybe you could now that they've done work to get it running on Falcon modes, I dunno. That and the AES/VDI "syscall" interfaces are based around (big endian) 16-bits all over the place, and RSC files etc contain that, etc. So you end up having to have this translation layer between 16 and 32 bit, because, well, why would want to stick with 16-bits? I went down that road for a while and then thought to myself... why am I doing this? I have 2 Falcons, a Mega ST, a Mega STe, and some 1040STs lying around... that I never boot. Oh one more thing, this just came across emutos-devel in the last week, there's a guy who got enough of a 68k "Atari ST"-like machine into QEMU to get EmuTOS to boot, and it's apparently fast: https://github.com/John-Titor/qemu https://github.com/John-Titor/qemu https://github.com/John-Titor/qemu/commit/a7ce3f1f77779be96cac75ffe1956f6dbeb86fbd#diff-0276b7be482748a8579eddbffb914c946fdc966e64f0aafa7a86a9c8de3f106cR218 https://github.com/John-Titor/qemu/commit/a7ce3f1f77779be96c...

Rochus 3y ago

Great resources, thanks for sharing!

Beijinger 3y ago

Oh wow. You mean these things run EmuTOS? https://www.mouser.com/c/embedded-solutions/engineering-tools/embedded-processor-development-kits/development-boards-kits-coldfire/ https://www.mouser.com/c/embedded-solutions/engineering-tool... I first mistook coldfire for Firebee ST https://acp.atari.org/about.html https://acp.atari.org/about.html

cmrdporcupine 3y ago
There are ColdFire boards that can. Only certain ones. I think this the one that is officially "supported": M5484LITE https://www.nxp.com/products/no-longer-manufactured/mcf5484-lite-evaluation-kit:M5484LITE https://www.nxp.com/products/no-longer-manufactured/mcf5484-... There are various ColdFires, I forget the differences between them and which EmuTOS supports, but it's documented in their repo I believe. A lot comes down to memory map, and uart, etc. Some years ago I made an attempt to get it to boot in qemu's coldfire personality but only got part way. But I think other's have maybe done this since? Or at least in the qemu 68k emulator.
- rbanffy 3y ago
  Ouch! $50+ for a 32-bit MCU destroys my hopes of an RPi-sized "modern" Atari ST. OTOH, NXP claims they can still make 68060's if we want a lot of them. Well... At least ARM boards can emulate a 68060 faster than a 68060 can run itself.
  - cmrdporcupine 3y ago
    Yeah these days you're better off either emulating or just doing FPGA. An Artix A7 could do a 68k series pretty damned well. If you're aiming low at <100mhz and just 68000/68010 compatibility, you can fit the whole machine on a single relatively cheap FPGA. Re: ARM SBC, I always wonder if you could get one of those ARM boards to boot in big-endian, to make the emulation easier. Because technically ARM can be bi-endian. I think I tried it with an old RPi before, and had no luck. There was someone working on an ARM port of EmuTOS for a bit. I played with that myself, taking bits of EmuTOS and doing them native ARM. My idea was that your usercode could be emulated, running 68k, but when you passed the syscall boundary (TRAP/SWI etc) you could flip to running native ARM. I don't have the src anywhere anymore I think, but I even had things like the VT52 console ported over, etc. Endianness is one problem, but also the fact that the Atari ST had planar video and very specific modes, so you end up basically writing the VDI from scratch, you can't borrow anything from EmuTOS VDI really. Maybe you could now that they've done work to get it running on Falcon modes, I dunno. That and the AES/VDI "syscall" interfaces are based around (big endian) 16-bits all over the place, and RSC files etc contain that, etc. So you end up having to have this translation layer between 16 and 32 bit, because, well, why would want to stick with 16-bits? I went down that road for a while and then thought to myself... why am I doing this? I have 2 Falcons, a Mega ST, a Mega STe, and some 1040STs lying around... that I never boot. Oh one more thing, this just came across emutos-devel in the last week, there's a guy who got enough of a 68k "Atari ST"-like machine into QEMU to get EmuTOS to boot, and it's apparently fast: https://github.com/John-Titor/qemu https://github.com/John-Titor/qemu https://github.com/John-Titor/qemu/commit/a7ce3f1f77779be96cac75ffe1956f6dbeb86fbd#diff-0276b7be482748a8579eddbffb914c946fdc966e64f0aafa7a86a9c8de3f106cR218 https://github.com/John-Titor/qemu/commit/a7ce3f1f77779be96c...