[HN Gopher] The history of Digital Research's Gemdos for the Ata...
___________________________________________________________________
The history of Digital Research's Gemdos for the Atari ST (1986)
Author : lproven
Score : 40 points
Date : 2024-02-14 12:15 UTC (10 hours ago)
(HTM) web link (cd.textfiles.com)
(TXT) w3m dump (cd.textfiles.com)
| unwind wrote:
| Interesting that this uses the coding convention of putting
| parentheses around the expression in return statements.
|
| So return (1);
|
| instead of just return 1;
|
| I remember using the former style as I tried (in frustration) to
| learn C back on the Amiga (so roughly at the same time, late
| 80s/early 90s) using articles in magazines.
|
| 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. :)
| pavlov wrote:
| 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.
| tom_ wrote:
| 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.
| CakeEngine wrote:
| Another early 90s C learner here, and I also put (and still
| do!) parentheses around return expressions. But I do:
| `return( 1 );`
|
| not `return (1);`
|
| ...because the bracket belongs to the return, not the
| expression. It's by analogy with 'if' and 'while', a mental
| "look out, here comes an expression" warming.
| icedchai wrote:
| 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...
| JNRowe wrote:
| dmr's reference manual1 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
| DICE2 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.
|
| 1 https://www.bell-labs.com/usr/dmr/www/cman.pdf
|
| 2 http://apollo.backplane.com/FreeSrc/dice-1.15.tgz
| lproven wrote:
| The same Matt Dillon that went on to start Dragonfly BSD, of
| course.
|
| https://www.dragonflybsd.org/team/
| AnimalMuppet wrote:
| Is it to visually distinguish from an empty return? That is,
| return 1;
|
| is visually closer to return;
|
| than return (1);
|
| 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...
| convolvatron wrote:
| 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.
| chasil wrote:
| I used the original Xerox Ventura Publisher, which came with a
| GEM runtime for DOS.
|
| I miss it.
|
| https://en.wikipedia.org/wiki/Corel_Ventura
| rjsw wrote:
| 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.
| lproven wrote:
| I know that GEM/4 and GEM/5 has additional features, such as
| Bezier 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.
| randombits0 wrote:
| 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.
| cmrdporcupine wrote:
| 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.
| eschneider wrote:
| 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. :)
| cmrdporcupine wrote:
| 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
| Rochus wrote:
| Great resources, thanks for sharing!
| Beijinger wrote:
| 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
| cmrdporcupine wrote:
| 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.
| rbanffy wrote:
| 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 wrote:
| 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...
| DominoTree wrote:
| 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
| cmrdporcupine wrote:
| 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.
| cmrdporcupine wrote:
| 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"_
| Rochus wrote:
| > _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.
| tempodox wrote:
| 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.
| richardjam73 wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-14 23:01 UTC)