• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

GEMDOS on the Lisa can be built again!

cheesestraws

Well-known member
GEM and GEMDOS, which are perhaps best known from the Atari ST series, were also ported to the Lisa.  Both were designed to be portable, and DRI sent the source for the Lisa port to OEMs that were considering porting GEM as their 'example implementation'.  When Caldera/SCO open sourced GEM, part of the random dump of stuff they threw at the folks requesting it was this porting kit.  The FreeGEM folks were mostly interested in PC GEM (I was on the periphery of this, fiddling with programming language bindings), and Atari GEM had gone its own way anyway.  Bits of it did end up in EmuTOS, though.

The practical upshots of this, though, are: the code for Lisa is out there, and so is the original toolchain to build Atari GEMDOS.  And @gilles already did a bunch of work to get GEMDOS booting on the Lisa.

My "discovery" of the last few days is: not only can you use an Atari emulator and the GEMDOS-on-Atari toolchain to build application code for GEMDOS on Lisa (in fact, for at least my simple applications so far, there's not even a need to recompile), but you can use it to build the OS itself (after a little mucking about - one component was completely missing and I had to hack a replacement together from a combination of Atari GEMDOS and CP/M code).   I'll write up instructions for building it soon, but if anyone wants the files let me know.

61152616773__53683FF7-3748-47C3-ACD7-9B36DBD8E4E9.JPG

This is a photo of GEMDOS running on my Lisa.  You'll have to take my word for it that it's a new build of the code, rather than the GEMDOSFI.SYS that DRI shipped.

Now, this is supremely useless, except for historical interest.  But I'm kind of tempted to see if I can get GEM itself to run and whether, if so, I can try to run some old Atari software on it, or backport some of the FreeGEM goodies to it.  Can anyone else think of fun things to do?

 

stepleton

Well-known member
Wow, congratulations! I'd love to have the files.

Is there any support for hard drives, or is it floppy-only?

 

cheesestraws

Well-known member
Wow, congratulations! I'd love to have the files.
Thanks! I've attached them here.  The tl;dr is to unzip it, aim Hatari at it as its "GEMDOS drive", load COMMAND.PRG and do

cd SYSBLD
SETUP
MAKEFI




which should give you a GEMDOSFI.SYS file suitable for use with the boot disc stuff in the first post.

I was planning on doing a more technical writeup on lisalist2 but I seem to get a database error when I post there, so I was going to go to bed and see if the problem went away overnight :)

Is there any support for hard drives, or is it floppy-only?
If I'm reading the code right, there is support for 5MB ProFiles in there, but I couldn't get it to actually work (this is partly the motivation for getting it building, to see why).  Using RWAbs to access the HD raw, I seemed to be able to read blocks but writing wasn't doing anything at all.  But I know basically nothing about ProFiles, so this could be ... tricky. :)

View attachment hatari-gemdos-lisa-build.zip

 
Last edited by a moderator:

stepleton

Well-known member
Huh, interesting! Not certain how sure you are of reading working, but as a test, you might try reading block $FFFFFF, which is the spare table for the ProFile---if the first 13 bytes are 'PROFILE      ' (note six spaces), then you're probably reading valid data. (Then again, if the GEMDOS disk driver really expects sectors to have only 512 bytes, then it might be ignoring the first 20 bytes of the 532-byte block, so if it doesn't work, it doesn't necessarily mean things are broken.)

Writing is not so different from reading, so even if there's a bug, I expect most of the hard work will have been done already.

 

sunder

Well-known member
Very nice!

Are there many CP/M68k apps out there? I know there were a ton for the 8080/z80.

 

sunder

Well-known member
I was planning on doing a more technical writeup on lisalist2 but I seem to get a database error when I post there, so I was going to go to bed and see if the problem went away overnight :)
So this is a bug with the SMF I have or possibly postgres setup with SMF, there's some visible or invisible unicode char it complains about. It only seems to happen from macos x or iOS.

The only fix I've found for this, and it's lame, is to paste the text of the code into a pure text only editor such as vi in terminal and then copy it back and paste it into SMF to strip things out.

It might be something like smart quotes or emdashes or hard spaces, not sure exactly, there's a description here (must be logged in to see it): https://lisalist2.com/index.php/topic,64.0.html

 

blusnowkitty

Well-known member
I wonder if any existing GEM applications will run on LisaGEM? Would be cool to have a fully graphical environment with more apps than 7/7 :D

 

cheesestraws

Well-known member
The only fix I've found for this, and it's lame, is to paste the text of the code into a pure text only editor such as vi in terminal and then copy it back and paste it into SMF to strip things out.
How odd!  OK, I'll give that a try :)

I wonder if any existing GEM applications will run on LisaGEM? Would be cool to have a fully graphical environment with more apps than 7/7 :D
Well, applications from the porting kit (e.g. the desktop) run mostly fine under EmuTOS on my Atari emulator, and CLI applications compiled on the Atari will also run on the Lisa.  So I'm guessing that a number of early GEM applications might work?  At the moment GEM itself still won't run on my real hardware, though, so I need to work out why... (the VDI loads fine, but the AES "bus error"s on startup)

 
Last edited by a moderator:

cheesestraws

Well-known member
it might be ignoring the first 20 bytes of the 532-byte block
It is, but we can fix this, we can rebuild it.  ahem

reading block $FFFFFF, which is the spare table for the ProFile---if the first 13 bytes are 'PROFILE      ' (note six spaces), then you're probably reading valid data
After a certain amount of wrangling—GEMDOS only uses 16 bit block numbers, apparently—I get this, which looks promising:

61160019217__614E37E4-5653-491A-B85E-1EC9F673DCCA.JPG

Time to go a-digging!

 

cheesestraws

Well-known member
The only fix I've found for this, and it's lame, is to paste the text of the code into a pure text only editor such as vi in terminal and then copy it back and paste it into SMF to strip things out.
"Zap Gremlins" in BBEdit worked wonders.  I'd used an Em dash :lisa2:

 

cheesestraws

Well-known member
The source code and build environment are now hosted on GitHub, in case anyone wants to play with it a bit, at https://github.com/cheesestraws/lisa-gemdos

Note that this is only GEMDOS (and the Lisa screen driver), not GEM itself!  I'd like to get to that in time, but it will be much easier to do that if I have working hard disc support and preferably working serial ports.  As it stands, we're stuck with binaries for that at the moment.

 

cheesestraws

Well-known member
Huh, interesting! Not certain how sure you are of reading working, but as a test, you might try reading block $FFFFFF, which is the spare table for the ProFile---if the first 13 bytes are 'PROFILE      ' (note six spaces), then you're probably reading valid data. (Then again, if the GEMDOS disk driver really expects sectors to have only 512 bytes, then it might be ignoring the first 20 bytes of the 532-byte block, so if it doesn't work, it doesn't necessarily mean things are broken.) 

  

Writing is not so different from reading, so even if there's a bug, I expect most of the hard work will have been done already. 
I ended up just hacking in your lisa_io ProFile driver as a substitute for the DRI one—it would be nicer to fix the original driver but honestly since there are no guarantees it ever worked in the first place, and since my grip on the Lisa hardware and on the ProFile are... tenuous at best, this seemed the best option to get it working in reasonable time.  Perhaps this is a decision to revisit later in the interests of sound industrial archaeology, but for now...

But yeah, now I can make a filesystem and copy things to the HD, and that makes me very happy.

IMG_1148.JPG

 

stepleton

Well-known member
Oh wow, that's fantastic! I'm so happy my library was useful for, well, anything at all really :lisa2:

I had considered mentioning it here, but as it's written to be small, I didn't think it would be so helpful for explaining how Apple parallel port drives work. I didn't consider that you would just cut the knot with it instead!

Is the PPP(xxxx)RRR/WWW part of the GEMDOS code or is it some debugging text that you've added while you were integrating the library?

Can't wait to see what you do next...

 
Last edited by a moderator:

cheesestraws

Well-known member
What's up with the fish? :?: 


Gary Kildall was an angler? :lol:  
I have absolutely no idea.  Odd, isn't it.  I assume it's debug code left in (?).  I quite like it, anyway.

I had considered mentioning it here, but as it's written to be small, I didn't think it would be so helpful for explaining how Apple parallel port drives work. I didn't consider that you would just cut the knot with it instead!
It was really easy to integrate!  Just wrote a bit of glue to call it from C then dropped it in.  The BIOS/BDOS distinction seems really to work well; I didn't need to change anything outside the HD read and write block routine at all.  Thankyou for making it available!

Is the PPP(xxxx)RRR/WWW part of the GEMDOS code or is it some debugging text that you've added while you were integrating the library? 
That's debugging text I added while I was trying to debug, to make sure that your library was actually getting the numbers I was passing in at the top. (It wasn't to start with because I'd got the C glue wrong.  Whoops.)

Can't wait to see what you do next...
Well, the very next thing to do is to clean up the screen driver build system so I can build that.

I'm at a bit of a fork in the road here, depending on whether this is to be a kind of archaeology project or actually an attempt to get a reasonably modern GEM running on the Lisa.  The problem is that I don't have the source code to either the BDOS or the GEM that the porting kit came with.  I have the source code (part of the GPLed code dump) to a different version of the BDOS, and I can't find the source code for most of 68k GEM at all (or, at least, not legitimately; there's a dump of an early Atari GEM but that's got Atari copyright on it as well and it shouldn't strictly speaking have escaped).  I've been looking at EmuTOS, and they seem to have backported a lot from GEM/x86 and FreeGEM.  So: I could either try to reverse-engineer/disassemble the existing GEM to work out why it's crashing, and produce a historical artefact, or I could try to port the AES and VDI (and perhaps even BDOS) from EmuTOS.

I'm not quite sure which is the best course here, honestly.  I do want to get applications running, though.

 

stepleton

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

Personally, as long as it doesn't stop anyone from doing the historical stuff later, I'm always a fan of more features and capability...

 
Top