• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

GEMDOS on the Lisa can be built again!


Well-known member
Dragging this thread back towards what passes for a topic... :)

Can you modify the boot loader such that it zeros RAM before it loads the BIOS/BDOS? You should be able to get max ram from the Lisa BIOS low memory globals at 0294:
I ended up just temporarily fixing the BSS clearing code, once I found it :) .  It ... attempts to have a mechanism for detecting the size of the BSS to clear it, but then it ... doesn't use that and just uses a constant size instead.  And likewise for the start of the TPA.  This definitely does feel half-finished :p .

We are currently at the point of it bringing up the GEM 'Wait' cursor and then immediately crashing!  Which is definite progress.



Well-known member
Woohoo, congratulations!! I'm glad someone found a use for that I/O library. I had a practical use in mind --- still do --- but I keep getting distracted by other projects!

Any benefit you may have enjoyed from my code as a learning tool comes from repackaging the knowledge that has been reverse-engineered or archived by other people --- I'm thinking of things like bitsavers, Patrick Schaefer's website, LisaEm, the BLU documentation, the list goes on...

Can't wait to see GEM going---good luck!



Well-known member
Can't wait to see GEM going---good luck!
Thanks!  I suspect the actual build tree for the versions of GEM.PRG and GEMVDI.PRG I have are lost; I talked to the emutos people and they think their initial AES dump came from a combination of the PC GEM sources (which are dual-platform x86/68k) with disassembled bits of the Lisa binaries I have.  That said, the PC GEM does look very like the disassembly I've been staring disconsolately at, so that's a good start.

Now I just have to work out how to compile the thing...  I was hoping to eventually make this self-hosting, but the urge to give up and use the MiNT-targetted gcc is pretty high.



Well-known member
Well, here it is.  It crashes at about this point, but the theory is definitely sound.

(These are the binaries that DRI shipped)





Well-known member

Once you have this up and running, GEMDOS will be one of the few Lisa OSs for which we have source code. The only other one out there for now that I know of is the Lisa Monitor, an Apple-internal OS that supported development of the Lisa OS, the Office System, and its apps. There are scans of a printed listing on Bitsavers.



Well-known member
Once you have this up and running, GEMDOS will be one of the few Lisa OSs for which we have source code
The GEMDOS bit is running pretty well!  My ability to test it is rather limited by the fact that there doesn't seem to be a huge amount of GEMDOS software out there that isn't GEM software...  I'm going to clean up the build system, but I think the OS is pretty well there.  There's some improvements I'd like to make and some "ease of debugging" changes I should revert to make it faster again but I think it's more or less happy.

It's the GEM GUI itself that isn't happy.  I just whacked a little bit of instrumentation into the IDLE emulator and it's not crashing, it's just deaf to most input.  I can see the VDI being polled for events, so I think there's a gotcha somewhere in the screen driver (which also manages input devices).  Which is good, because I have the source for that :).



Well-known member
Aaaaaaaaand success!

The mouse issue was just that ... the device number had been changed some time between the release of the Lisa BIOS and the release 1.1 BDOS.

Here is GEM running and loading an application on the Lisa, off the hard disc (HD support is a bit limited).

View attachment IMG_1270.mov

Next step: tidy up build scripts!



Well-known member
FirstWordPlus nearly runs!  I especially like the dingbat garblage that is the result of it trying to have an 'Atari' menu...



After this it tries to redraw the document window and crashes.



Well-known member
The original First Word, which is probably a fairer test as it is about the same age as this version of GEM, works basically fine:


The fonts are a bit funky, and I suspect that might be what scuppering the Plus version, it's when it tried to redraw the text area that it segfaulted.  But as a proof of concept, this is indeed a piece of Atari desktop software running on the Lisa.

Anyone want a boot disc image? :)



Well-known member
*waves arms* I'll take one!

To quote Zoidberg, "I'll take 8!"

Here's a couple of disc images which will let you run off floppy or install on a hard disc.  These are 400K DiskCopy 4.2 images.  You should be able to boot from gemdos11-boot.dc, and it should give you a prompt that looks something like

Command v. 0.38 8/16/85 LTG
{a} _

You can run GEM from the floppy.  To run it, just use the 'gemvdi' command.  This will load the VDI and display a message; it will then load the desktop.  Very slowly.  If you double-click on the 'A' drive at the bottom left of the desktop, you should be able to fiddle with the files on the floppy through there.  HELLO.APP is a simple hello world GEM application that ought to load and work.

You can install it onto a hard disc in the following way.  It's a bit manual at the moment, apologies, and has a lot of limitations.  It will probably only work on a 2/10 with an internal hard disc; it might work on a 2/5 with a hard disc hung off the internal port as well.  I haven't tried it.  And it will only see 5 meg of that hard disc no matter how big it is.  I am using an X/Profile with a 5meg STAR, personally.

First of all, create a filesystem on the hard disc.  This is very rude and does not ask for permission first, and obviously it WILL wipe out anything else on the disc (this utility is just the filesystem-creating half of the old FORMAT command).

mkfs c

Then "install" the OS:

copy gemdoshi.sys c:
copy command.prg c:
putboot c: hboot.abs

It is important that gemdoshi.sys is the first file on the disc, because it's a 1-stage bootloader that can't read the filesystem, it just loads the first thing it sees.  You should now be able to reboot and the machine will come up into GEMDOS.  At this point, copy the rest of the contents of the floppy disc (possibly omitting GEMDOSFI.SYS which is the floppy version of the OS executable and both the ABS files which are the bootloader) to the hard disc:

copy gemvdi.prg c:
copy gem.* c:
copy meta.sys c:
copy *.fnt c:
copy desk*.* c:
copy hello.app c:
at this point, you should be able to eject the floppy (Cmd-NumPadEnter, for some reason) and run 'gemvdi' to get to the desktop.

The second disc image contains some applications which are either useless or don't work, but prove (or don't) the concept.  I'd suggest sticking them in a GEMAPPS directory to make it easier to delete them later:

cd \
copy a:*.* c:
cd \

then, again, run GEMVDI to get to the desktop.

  • 1ST_WORD is a word processor that very nearly works.  Text redraw is funky, expecially when you select things, but at least it doesn't crash on startup.
  • DOODLE is a DR demo application which is... exactly what it says on the tin.
  • RCS is the Resource Construction Kit, the GEM rough equivalent of ResEdit.
  • ST-GUIDE crashes immediately :-(

Hope this is enough to play with for the moment.  I'm going to take a break for this for a day or so now and then work out what to do next with it.



Well-known member
So it boots off an X/Profile on a 2/5. HELLO.APP works, but 1ST_WORD.APP causes a complete system hang when trying to create a new document. Make sure to have a floppy disk inserted if you try to access the drive, otherwise it will crash the system with Lisa Error 47.

Also: don't forget to copy ASSIGN.SYS and LISA25.SYS to the hard drive when doing your file copies.


Last edited by a moderator:


Well-known member
So it boots off an X/Profile on a 2/5.
Great!  I'm pretty sure the port was originally designed for the 2/5 (hence the "25" in "LISA25.SYS").

Make sure to have a floppy disk inserted if you try to access the drive, otherwise it will crash the system with Lisa Error 47. 
This is one of the reasons I get a strong feeling that this wasn't ever really finished; it was a demo platform, rather than a serious port.  Error handling is nonexistent (if you get an abort/retry/ignore prompt and press 'r' for retry, it actually restarts the machine, at least here).  I have found so many ways to crash this so far :)



Well-known member
Here's a question:  is there an approved method of detecting what hard discs are attached to the Lisa, or at least a method that is known to work?  If worst comes to worst I will have a look at the boot ROM source, but it slightly scares me.



Well-known member
Here's a question:  is there an approved method of detecting what hard discs are attached to the Lisa, or at least a method that is known to work?  If worst comes to worst I will have a look at the boot ROM source, but it slightly scares me.
I don't know of any, but in general, check each slot for a dual parallel port card, if installed check each card for the OCD bit - Open Cable Detect, if the cable is connected, there might be a drive there.

If there is a drive there, you can try to probe reading of block 0x00ffffff - this will give you the name and size of the drive, and whether it is a ProFile like or a Widget like drive, but don't depend on the text name, look at the protocol version. Take a look at the Widget ERS for this. If you don't want to deal with the crazy multi-block read/write commands, stick to ProFile-y commands only - the Widgety drives are backwards compatible with this protocol, though it's slightly slower.

Note that SunRem and Corvus made compatible drives that may have different sizes, but that -1 block will give you the size of the drive. Please don't do what Lisa Office System and Xenix did - they hard coded the expected drive size inside the driver :facepalm: - as a result, if you attach a 30MB or 40MB SunRem MFM drive you could only use the first 10MB.

The ROM routine for the ProFile only contains a read block routine only for ProFile style disks, but you can pass the address of the VIA and thus test both the motherboard parallel port for an attached hard drive - whether Widget or ProFile (or X/ProFile), and any/all of the 6 possible attached external drives.

You'll need to hook the bus error vector to prevent crashes as accesses to non-existant ports won't properly signal DTACK and so will generate a bus error. You can setup the ISV (Interrupt Service Routine) ahead of time to write a flag saying that port isn't there before you call the ROM profile read routine and maybe maintain an array of info about what's connected where and what size it is.

From what I recall, if you have 2 port serial card, the 2K ROM onboard does a quick check of the port, and then if clicked for boot, would set the right variables to the address of the port and pass them to the Boot ROM ProFile routine to read the block and boot that way, I don't think they contain actual ProFile read routines.