Jump to content
cheesestraws

GEMDOS on the Lisa can be built again!

Recommended Posts

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.thumb.JPG.3a0b29df70f83291386e0135641f5ff6.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?

Share this post


Link to post
Share on other sites
7 minutes ago, stepleton said:

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

 

7 minutes ago, stepleton said:

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

hatari-gemdos-lisa-build.zip

Edited by cheesestraws

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Very nice!

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

Share this post


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

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

Share this post


Link to post
Share on other sites
34 minutes ago, sunder said:

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

 

20 minutes ago, blusnowkitty said:

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)

Edited by cheesestraws

Share this post


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

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

 

17 hours ago, stepleton said:

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.thumb.JPG.5b099c3024da74b4379a088cf71cbe63.JPG

 

Time to go a-digging!

 

Share this post


Link to post
Share on other sites
4 hours ago, sunder said:

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:

Share this post


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

"Zap Gremlins" in BBEdit worked wonders.  I'd used an Em dash :lisa2:

Love that command's name! And yes, fond memories of BBEdit back when I was still on an actual mac. :)

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
On 5/19/2020 at 12:38 AM, stepleton said:

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.thumb.JPG.f5e4490fc23cfb652b55ec87a0d7d6f1.JPG

Share this post


Link to post
Share on other sites

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

Edited by stepleton

Share this post


Link to post
Share on other sites
9 hours ago, ScutBoy said:

What's up with the fish? :?: 

 

9 hours ago, jessenator said:

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.

 

12 hours ago, stepleton said:

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!

 

12 hours ago, stepleton said:

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

 

12 hours ago, stepleton said:

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.

Share this post


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

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

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

×