The history of Digital Research's Gemdos for the Atari ST (1986)(cd.textfiles.com)
cd.textfiles.com
The history of Digital Research's Gemdos for the Atari ST (1986)
http://cd.textfiles.com/crawlycrypt1/program/books/progem/gemdos.15
5 comments
I developed GEM applications on DOS and on the Atari ST, didn't do anything that required as much precision as Ventura Publisher. The runtime that came with Ventura wasn't a standard GEM one.
I know that GEM/4 and GEM/5 has additional features, such as Bézier curve support for Artline.
https://en.wikipedia.org/wiki/GEM_(desktop_environment)
These were eventually backported into FreeGEM and the current OpenGEM has them built in, I believe.
https://en.wikipedia.org/wiki/GEM_(desktop_environment)
These were eventually backported into FreeGEM and the current OpenGEM has them built in, I believe.
My old and unreliable memory thinks that TOS (the ST DOS) was modeled after DOS as far as interrupt calls and whatnot to make it easier for devs. I know the disk format was the same, though DOS wouldn’t read the ST disk unless it had a DOS boot sector on it. ST didn’t care.
Worth pointing out (see my other comment) that Ventura Publisher was written by the original inventor/architect of GEM itself; Lee Lorenzen. After leaving DR.
I used that for magazine publishing. Definitely better than pasting galleys on boards, which is what it replaced, but I'm not sure I'd go so far as to say I miss it. :)
Interesting that this uses the coding convention of putting parentheses around the expression in return statements.
So
Does anyone know where it comes from?
Some time later (late 90s) at university I learned C again but with actual (good!) teachers, and also got exposed to way more code and talk about code thanks to Internet and comp.lang.c etc, and around that time (I think?) I stopped using them.
Nowadays they always make me think the author is anxious that the function will return before the entire expression is evaluated, which makes me smile. :)
So
return (1);
return 1;
Does anyone know where it comes from?
Some time later (late 90s) at university I learned C again but with actual (good!) teachers, and also got exposed to way more code and talk about code thanks to Internet and comp.lang.c etc, and around that time (I think?) I stopped using them.
Nowadays they always make me think the author is anxious that the function will return before the entire expression is evaluated, which makes me smile. :)
dmr's reference manual¹ used it, see section 9.10.
Matt Dillon's DICE would have been popular on the Amiga then, and it looks like it also favored parens. The latest tarball of DICE² is pretty fun for a spelunking session, if you're feeling nostalgic. It makes for an interesting mix as it pulls in a few contemporaneous non-Dillon tools with varying styles.
¹ https://www.bell-labs.com/usr/dmr/www/cman.pdf
² http://apollo.backplane.com/FreeSrc/dice-1.15.tgz
Matt Dillon's DICE would have been popular on the Amiga then, and it looks like it also favored parens. The latest tarball of DICE² is pretty fun for a spelunking session, if you're feeling nostalgic. It makes for an interesting mix as it pulls in a few contemporaneous non-Dillon tools with varying styles.
¹ https://www.bell-labs.com/usr/dmr/www/cman.pdf
² http://apollo.backplane.com/FreeSrc/dice-1.15.tgz
The same Matt Dillon that went on to start Dragonfly BSD, of course.
https://www.dragonflybsd.org/team/
https://www.dragonflybsd.org/team/
Wow I had almost forgotten those names, thanks!
Maybe it’s a way to highlight that returning an expression value directly is possible?
Back then C was rare on home computers. Programmers were more used to BASIC where typically GOSUB / RETURN couldn’t return a value at all.
Back then C was rare on home computers. Programmers were more used to BASIC where typically GOSUB / RETURN couldn’t return a value at all.
I looked at some C code I wrote about 25 years ago. It all followed the return(N) convention. I also learned C on an Amiga, coincidentally. I started with Lattice / SAS C...
I used to do it as well, but I'm not sure why either? (I learned C in the early 90s.) The reference material was never great back in those days, so maybe I just started doing it by extending the rules for if(), while(), for() and function calls and not getting any pushback from the compiler.
Eventually I stopped because it saves 1 byte and means pressing fewer keys.
Eventually I stopped because it saves 1 byte and means pressing fewer keys.
Is it to visually distinguish from an empty return? That is,
So this could be a way of signaling "hey, I'm returning a value here, not just leaving the function".
But I'm just speculating...
return 1;
return;
return (1);
So this could be a way of signaling "hey, I'm returning a value here, not just leaving the function".
But I'm just speculating...
I am extremely biased. but I always think of return as an implicitly bound continuation. so it seems quite natural to want to call it.
Another early 90s C learner here, and I also put (and still do!) parentheses around return expressions. But I do:
`return( 1 );`
`return (1);`
We used to comment the crash of a GUI app on the ST with the phrase “GEM over!” (alluding to “Game Over”). Nice to learn about its history.
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
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), 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://stardot.org.uk/forums/viewtopic.php?t=20964
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/
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
You can see Lorenzen's original pitch to Xerox of his "LoneStar" prototype here: 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), 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://stardot.org.uk/forums/viewtopic.php?t=20964
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/
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
I meant to add this link:
https://archive.computerhistory.org/resources/access/text/20...
CHM "Oral History of Lee Lorenzen"
There's quite a few pages there about GEM and its history.
"VisiCorp was working on the operating environment Visi On, which was going to be their answer to a graphical user interface. When I went and saw it, I said, "Oh, we could do better." We had an Apple Lisa, and it was a 68K-based system. That was awesome that they had that at Digital Research. I said, "Let's take concurrent CP/M." They had a 68K version running on the Lisa, but they didn't have any user interface. So, I said, "Let me do the user interface for it." I don't think I used the same code, but I basically redid everything to create something called Crystal, which was the Lone Star type thing, but running on this Lisa hardware. It had a mouse, and it had a bitmapped display, but it ran on CP/M 68"
https://archive.computerhistory.org/resources/access/text/20...
CHM "Oral History of Lee Lorenzen"
There's quite a few pages there about GEM and its history.
"VisiCorp was working on the operating environment Visi On, which was going to be their answer to a graphical user interface. When I went and saw it, I said, "Oh, we could do better." We had an Apple Lisa, and it was a 68K-based system. That was awesome that they had that at Digital Research. I said, "Let's take concurrent CP/M." They had a 68K version running on the Lisa, but they didn't have any user interface. So, I said, "Let me do the user interface for it." I don't think I used the same code, but I basically redid everything to create something called Crystal, which was the Lone Star type thing, but running on this Lisa hardware. It had a mouse, and it had a bitmapped display, but it ran on CP/M 68"
The EmuTOS community is also wonderful - a couple years ago I was writing a small driver and the folks on the mailing list gave me a lot of encouragement and guidance until my driver finally ended up in the official tree (and now EmuTOS natively supports the UltraSatan RTC)
Also, let's not forget about some other amazing projects at even higher levels of the OS stack: FreeMiNT and XaAES
Multitasking with a real Bash shell on a 4MB ST is a reality (and kinda mindblowing) - not to mention what you can do if you get some more RAM and have Ethernet/USB also working :D
Also, let's not forget about some other amazing projects at even higher levels of the OS stack: FreeMiNT and XaAES
Multitasking with a real Bash shell on a 4MB ST is a reality (and kinda mindblowing) - not to mention what you can do if you get some more RAM and have Ethernet/USB also working :D
I recall running original bourne shell or ksh or csh (I forget which) on my 1MB upgraded 520 with floppies. In MiNT. In 1991. Lol. But I recall there were more appropriate ST-specific shells. Mupfel, and another one I can't recall.
Used to run a UUCP node on that machine and spool in email and Usenet. Memories.
Used to run a UUCP node on that machine and spool in email and Usenet. Memories.
Oh wow. You mean these things run EmuTOS?
https://www.mouser.com/c/embedded-solutions/engineering-tool...
I first mistook coldfire for Firebee ST
https://acp.atari.org/about.html
I first mistook coldfire for Firebee ST
https://acp.atari.org/about.html
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-...
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.
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.
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.
Well... At least ARM boards can emulate a 68060 faster than a 68060 can run itself.
This part of why I wrote this:
https://www.theregister.com/2024/02/12/pistorm_accelerated_a...
Emu68 is a bare-metal, JIT-compiled, 680x0 emulator for the Pi. It works well enough for routine use now, even thought it's not quite at version 1.0 yet. It's much, much faster than Musashi under Linux.
Effectively, Emu68 means that there's a new 680x0 machine in town: a RasPi with its stock peripherals that natively boots and runs 68K code.
If it can replace the 68000 or 68020 in a real Amiga 1000, 500, 2000, or 1200, then it can replace the 68000 in an ST or a Mac or whatever.
So far, Emu68 only runs AmigaOS, but EmuTOS runs on Amigas now.
EmuTOS on Emu68 is doable. FreeMINT on Emu68 should not be that much more of a reach.
I'd love to see Classic MacOS on Emu68, and SMSQ/E, and a few other things too.
https://www.theregister.com/2024/02/12/pistorm_accelerated_a...
Emu68 is a bare-metal, JIT-compiled, 680x0 emulator for the Pi. It works well enough for routine use now, even thought it's not quite at version 1.0 yet. It's much, much faster than Musashi under Linux.
Effectively, Emu68 means that there's a new 680x0 machine in town: a RasPi with its stock peripherals that natively boots and runs 68K code.
If it can replace the 68000 or 68020 in a real Amiga 1000, 500, 2000, or 1200, then it can replace the 68000 in an ST or a Mac or whatever.
So far, Emu68 only runs AmigaOS, but EmuTOS runs on Amigas now.
EmuTOS on Emu68 is doable. FreeMINT on Emu68 should not be that much more of a reach.
I'd love to see Classic MacOS on Emu68, and SMSQ/E, and a few other things too.
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/commit/a7ce3f1f77779be96c...
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/commit/a7ce3f1f77779be96c...
> and wanted to get some of the ideas from the Star onto commodity 8080/8086 hardware
It's actually a pitty that the source code of the Xerox Star is not (yet) available to the public. Does anyone know whether this is in progress? I remember that the publication of the Xerox PARC source code took many years.
It's actually a pitty that the source code of the Xerox Star is not (yet) available to the public. Does anyone know whether this is in progress? I remember that the publication of the Xerox PARC source code took many years.
Great resources, thanks for sharing!
The Atari ST operating system is kinda divided into two parts. GEMDOS/BIOS/XBIOS is the underlying system that GEM GUI uses. GEMDOS is roughly equivalent to Microsoft's DOS. You can write applications that don't use the GUI.
I miss it.
https://en.wikipedia.org/wiki/Corel_Ventura