Jump to content
cheesestraws

GEMDOS on the Lisa can be built again!

Recommended Posts

8 hours ago, sunder said:

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...

Share this post


Link to post
Share on other sites
On 6/10/2020 at 6:35 AM, sunder said:

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

Share this post


Link to post
Share on other sites
On 6/12/2020 at 12:28 PM, stepleton said:

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.

Share this post


Link to post
Share on other sites
11 hours ago, cheesestraws said:
  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]

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
12 hours ago, CC_333 said:

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.

 

12 hours ago, CC_333 said:

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.

Share this post


Link to post
Share on other sites

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?

 

61452029748__38E74BA5-3A6E-43BA-B92C-C98DC4453168.thumb.JPG.ba24baa10b49a125b85b012deff7f266.JPG

 

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...

Share this post


Link to post
Share on other sites
13 hours ago, cheesestraws said:

 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

Share this post


Link to post
Share on other sites
8 hours ago, NJRoadfan said:

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 :-p

Share this post


Link to post
Share on other sites
16 hours ago, cheesestraws said:

Thankyou for your kind words...

Of course!

16 hours ago, cheesestraws said:

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!

 

16 hours ago, cheesestraws said:

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

Share this post


Link to post
Share on other sites
8 hours ago, CC_333 said:

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 :-).

Share this post


Link to post
Share on other sites
19 hours ago, cheesestraws said:

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.

 

Share this post


Link to post
Share on other sites

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

 

On 6/10/2020 at 6:35 AM, sunder said:

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
On 6/23/2020 at 1:01 PM, stepleton said:

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.

Share this post


Link to post
Share on other sites

Wow!!

 

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.

Share this post


Link to post
Share on other sites
8 hours ago, stepleton said:

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 :-).

Share this post


Link to post
Share on other sites
13 hours ago, stepleton said:

Once you have this up and running, GEMDOS will be one of the few Lisa OSs for which we have source code.

 

As a side note, does anyone know what happened to the Lisa Office System source release from a few years back?

Share this post


Link to post
Share on other sites

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).

 

 

Next step: tidy up build scripts!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×