GEMDOS on the Lisa can be built again!

[cheesestraws]

Do whatever will be the most fun for you, is what I'd say :lisa:

I think I'm going to have to use a newer BDOS anyway, having spent a chunk of today digging into why GEM wasn't loading and getting nowhere.  So that is probably what comes next .

 

[cheesestraws]

A quick update on this: I've spent quite a lot of time trying to get what I think is the release GEMDOS 1.1 running on this using the DR compiler suite.  Unfortunately it is very crashy, and adding debug output seems to move the crashes around, which is not entirely helpful.  Part of this is about uninitialised memory, but it's quite hard to debug.  I'm considering whether to try to build this using the GCC Atari cross-compiler suite thing for MiNT, which can produce basic TOS executables.  Nothing else is required for building the GEMDOS as far as I can see, but it would mean that this wouldn't be able to be self-hosting any more, which would be a shame.

 

[stepleton]

It might be useful to try out the cross-compiler just to help troubleshoot the problem.

Good luck! I don't know much about GEMDOS, but I'm cheering for this project as a spectator :lisa2:

Quick question---I suspect the answer is no, but does GEMDOS use the Lisa's MMU in any way? I'm guessing not (it probably just uses the flat memory space set up by the boot ROM), but if it does use the MMU, then it's possible that any old 68k compiler won't work. The 68000 can only recover from a page fault for certain instructions, so subroutine calls have to generate code that uses these instructions to "test" distant memory locations (and thereby trigger a page fault) before doing any actual work with them.

 

[cheesestraws]

does GEMDOS use the Lisa's MMU in any way

Not as far as I can see, no—this will run quite cheerfully on a 68000 without any MMU at all, it's only a little bit more complicated than CP/M.  None of the assembly code seems to do anything special with distant addresses, certainly (not that I really know what I'm talking about).  So any 68k compiler ought to do, I think.  The one I'm using at the moment is insanely basic, to be honest.

I'm especially amused that the linker has no way to suppress the GEMDOS executable header in outputs so all the other tooling just works around the fact that things like the file with the master copy of the boot sector have a GEMDOS executable header on them, and it just ... doesn't copy the first 28 bytes.  This is all pretty spartan.

I'm very grateful for the Atari-targeted tools (i.e. disassembler) that I've got here, which are making this much easier!

 

[cheesestraws]

I'm increasingly sure that a significant chunk of the problem here is that sometime between whatever prerelease GEMDOS was shipped with the porting kit and the release version 1.1, the contract between the BDOS and the BIOS changed such that the BDOS now expects its working memory to be zeroed by the BIOS, whereas the previous one obviously didn't.  I think the next step is to look at other BIOSes (the Atari and VME ones, perhaps?) to see what they do.

So far, by slapdash initialising globals properly, I have progressed from an uncontrolled crash in the filesystem code to a controlled (but erroneous) error return in the program loader, to a crash so hard in the program loader that it actually segfaulted IDLE once or twice.  This definitely feels like progress...

 

[sunder]

changed such that the BDOS now expects its working memory to be zeroed by the BIOS, whereas the previous one obviously didn't.  I think the next step is to look at other BIOSes (the Atari and VME ones, perhaps?) to see what they

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:
 

0000| 0000 0294 MAXMEM .EQU $0294 ;MAX MEMORY ADDRESS + 1



Generally the Lisa's BOOT ROM will load the boot block around address 2000 depending on which device is selected/options ROMs are loaded, but you should be able to know from the boot loader where the boot loader ends, so use that as your start address and zero RAM all the way to MAXMEM-1 using a DBRA loop.

 

[cheesestraws]

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:

That's a very good idea.  I don't have the source code to the bootloader, so I'll have to disassemble/reassemble it...

 

[stepleton]

Generally the Lisa's BOOT ROM will load the boot block around address 2000 depending on which device is selected/options ROMs are loaded, but you should be able to know from the boot loader where the boot loader ends, so use that as your start address and zero RAM all the way to MAXMEM-1 using a DBRA loop.

Super minor point here, and you may have spotted it already, but there's a dropped zero---the boot block is loaded to $20000. Look for the symbol "TWGDATA" in the boot ROM: http://bitsavers.trailing-edge.com/pdf/apple/lisa/firmware/Lisa_Boot_ROM_Asm_Listing.TEXT

 

[cheesestraws]

Super minor point here, and you may have spotted it already, but there's a dropped zero---the boot block is loaded to $20000

I haven't actually done this yet, I've been trying to track down another weirdness.  So thanks.  This is I think next on my list...

Just some ambient notes on the process:

1. Whoever decided to use longjmp in this code, I will find you and I will stare at you judgmentally
   
2. Documenting an error number as, and I quote verbatim, "General mishap" is hilarious but most decidedly not useful.
   

 

[sunder]

1. Documenting an error number as, and I quote verbatim, "General mishap" is hilarious but most decidedly not useful.
   

Pity, they missed an opportunity here to call that error something a lot more fun: Major Havoc

[8D]

 

[cheesestraws]

Funnily enough, it turns out that it helps if you don't load your command line interpreter over the second half of the BDOS's BSS.

*facepalm*

 

[CC_333]

This is neat!

Could it be possible to port this to the Mac eventually?  It seems like it would be generally possible, since the Lisa and Mac architectures are quite similar, but because of the Mac's ROM being what it is, I'd suppose it'd need a stub program/loader (as all the 68k-Mac oriented Linux/*BSD distros I've seen do), which greatly complicates it to the point that it's probably going to be prohibitively difficult.

Be that as it may, the fact that there's new development happening for the Lisa, likely for the first time in more than 30 years, is quite exciting!

Keep up the good work!!

c

 

[cheesestraws]

Be that as it may, the fact that there's new development happening for the Lisa, likely for the first time in more than 30 years, is quite exciting!

Thankyou for your kind words, but this isn't the only new development for the Lisa, and I'm not particularly good at it.  This project wouldn't have got anywhere without @stepleton's development work, for example, which I am relying upon for hard disc drivers and to understand various bits of the Lisa.  And of course the folks at DRI who originally built this OS.  I'm just following along picking up the bits and playing Lego with them.

Could it be possible to port this to the Mac eventually?  It seems like it would be generally possible, since the Lisa and Mac architectures are quite similar, but because of the Mac's ROM being what it is, I'd suppose it'd need a stub program/loader (as all the 68k-Mac oriented Linux/*BSD distros I've seen do), which greatly complicates it to the point that it's probably going to be prohibitively difficult.

I mean, this seems entirely possible.  GEMDOS and GEM are designed to be very portable anyway, so not a great deal of code would actually need to be written.  The question is, of course, whether it would be worth it.  I am personally very fond of GEM, and I've sunk a reasonable amount of time into it over the years, but that doesn't blind me to the fact that it was largely following along where the Mac led.  Possibly more interesting on the Mac would be to write a kind of "shim" GEMDOS/AES/VDI to allow GEM applications to run under MacOS.  Because the AES and VDI try to assume as little as possible about the graphics hardware they're running on, this might be feasible (thunking through VDI calls to QuickDraw, etc).  But I don't really know enough about how traps work etc to say whether this is really feasible or not.

 

[cheesestraws]

Aaaaaand here we are.  GEMDOS 1.1, release version (I think?  It's sort of hard to tell) running on real hardware.  Please disregard the random debugging.  The only remaining binary blob in play is the bootloader, and the only reason I'm still using that is because I kind of like the random fish it draws on the screen?



The next step will be trying to see whether I can get GEM to run (now I can actually debug things).  Loading it gets as far as trying to relocate the AES and then it falls over.  So!

The eventual plan is to get this self-hosting, so that the Lisa can build its own OS.  This sounds difficult but actually shouldn't be: the tools I'm using ought to run just fine on it, I just need to work out a way to get them over.  I suspect Kermit...

 

[NJRoadfan]

 Possibly more interesting on the Mac would be to write a kind of "shim" GEMDOS/AES/VDI to allow GEM applications to run under MacOS.  Because the AES and VDI try to assume as little as possible about the graphics hardware they're running on, this might be feasible (thunking through VDI calls to QuickDraw, etc).  But I don't really know enough about how traps work etc to say whether this is really feasible or not.

Isn't this basically what MagiC-Mac was? It even saw PowerPC and native OS X versions.

https://en.wikipedia.org/wiki/MagiC

 

[cheesestraws]

Isn't this basically what MagiC-Mac was? It even saw PowerPC and native OS X versions.

... I did not know this was a thing.  That's pretty much what I meant.  Glad I don't have to build it now

 

[NJRoadfan]

Its open source nowadays: https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/

 

[CC_333]

Thankyou for your kind words...

Of course!

but this isn't the only new development for the Lisa, and I'm not particularly good at it.  This project wouldn't have got anywhere without @stepleton's development work, for example, which I am relying upon for hard disc drivers and to understand various bits of the Lisa.  And of course the folks at DRI who originally built this OS.  I'm just following along picking up the bits and playing Lego with them.

Perhaps, but even so, you are still to be commended for your curiosity and motivation to do something potentially useful with his work!

I mean, this seems entirely possible.  GEMDOS and GEM are designed to be very portable anyway, so not a great deal of code would actually need to be written.  The question is, of course, whether it would be worth it.  I am personally very fond of GEM, and I've sunk a reasonable amount of time into it over the years, but that doesn't blind me to the fact that it was largely following along where the Mac led.  Possibly more interesting on the Mac would be to write a kind of "shim" GEMDOS/AES/VDI to allow GEM applications to run under MacOS.  Because the AES and VDI try to assume as little as possible about the graphics hardware they're running on, this might be feasible (thunking through VDI calls to QuickDraw, etc).  But I don't really know enough about how traps work etc to say whether this is really feasible or not.

Yeah, OK.  Running the full GEM environment on a Mac (a platform GEM strove to emulate) is probably redundant and pointless, but developing some kind of API or runtime environment for GEWM programs to run natively on the Mac OS would be neat, and theoretically, it could be made to work on pretty much every Mac out there, even G3s and G4s, due in large part to PPC classic Mac OS' excellent 68k emulation.

Of course, once the means to run GEM programs on the Mac effectively exist, one needs to develop more of them, as not many existed in the first place, owing mostly to the fact that GEM on any platform other than the Atari never gained enough popularity to make doing so worthwhile.  However!  Since the Atari was also 68k-based, there exists the unique ability to port any extant Atari GEM programs whose source is available to the Lisa (and, perhaps with minimal adaptation, the Mac), so one has that neat advantage []

c

 

[cheesestraws]

Yeah, OK.  Running the full GEM environment on a Mac (a platform GEM strove to emulate) is probably redundant and pointless, but developing some kind of API or runtime environment for GEWM programs to run natively on the Mac OS would be neat, and theoretically, it could be made to work on pretty much every Mac out there, even G3s and G4s, due in large part to PPC classic Mac OS' excellent 68k emulation.

As @NJRoadfan noted above, this already exists.  So I'll stick to this doomed endeavour and not try for the other .

 

[sunder]

Because the AES and VDI try to assume as little as possible about the graphics hardware they're running on, this might be feasible (thunking through VDI calls to QuickDraw, etc).  But I don't really know enough about how traps work etc to say whether this is really feasible or not.

On the Mac (and even LOS), the A-Line traps are almost fully used. You could cheat and use some of the F-Line traps that aren't used by the FPU or PMMU, or perhaps use some other mechanism if GEMDOS allows for it.