A Lisa Inside An FPGA

[stepleton]

It is the Selector software you're seeing here, and my own LisaFPGA shows the same behaviour. I can just press 1 to select the built-in parallel port, and it works fine from there. @slewis1962, does pressing 1 when you see this screen not work for you?

If we're getting this far, then the ProFile is working and the Selector is successfully loading and running from it. And I generally unplug my (no batteries) Lisas all the time: sometimes using the STARTUP FROM... menu and other times just booting directly. On real hardware, I've never seen this problem. On my LisaFPGA, it happens whether I use the STARTUP FROM... menu or not. (Edit: I checked again: it ONLY happens if I boot naturally and it NEVER happens if I use the STARTUP FROM... menu.)

It didn't do this on my LisaFPGA until I upgraded the firmware the first time. It has done this ever since (at least with an H/A8 ROM configuration).

Note that the Selector never talks to the PRAM itself.


Working through the problem:

So before the Selector reads the list of images from the hard drive and posts the hard drive image selection menu, it checks to see whether the hard drive is a Cameo/Aphid, an ESProFile, or any other disk capable of honouring the Selector "magic blocks" protocol. This check is failing.

A look at the routine that does the check shows a number of reasons the check could fail. Some of them can happen because talking to the hard drive emulator fails, or because it doesn't see the special byte sequence in the $FFFFFF block that says that the emulator supports the Selector protocol. But as I've pointed out when i complained about this problem earlier, I've checked the contents of the $FFFFFF block myself and always found it to have this marker. There is probably another reason.

The Selector always has an idea of which of seven possible parallel ports (the internal parallel port and six possible expansion cards) it could be talking to --- that's called "the current hard drive" or "the current port" or something similar. (In the code, it's called "zCurrentDrive".) The HD emulator check routine calls this routine that confirms that the current parallel port is actually connected to a hard drive. The routine doesn't actually talk to hardware; it just looks up the current port in a table that the Selector has built earlier when it scans all the possible parallel ports for hard drives. This check can fail if (a) the current parallel port is invalid or (b) if the table says that there's no hard drive on the current parallel port.

Going back to my LisaFPGA, I can confirm that an H/40 ROM configuration (H ROM with a Twiggy I/O board) boots the Selector successfully but that an H/A8 (H with Sony) will not. If I take a slow-motion video of the Selector's own boot screen (shown and then cleared away before the screen in @slewis1962's post), I see a flash of what looks like:

Connecting to the boot drive: ?invalid drive?... failed

This is happening here, where the drive is being identified by reading the byte at $1B3. We normalise that byte to turn the identifier $00 to $02 if needed (since the boot ROM on a 2/10 uses $00 and $02 interchangeably to refer to the internal parallel port, and $02 works in all non-expansion-card parallel port cases), then call PrintParallelPort. PrintParallelPort compares that byte to a set of valid parallel port identifiers, and if none match, it prints ?invalid drive?.

So I think this is a major part of the problem. Per the boot ROM manual (PDF page 25), location $1B3 is supposed to say the location of the boot device. On the LisaFPGA running H/40, this location appears to wind up having something unexpected in it.

Trying to find what this strange thing could be... If I press the NMI key at any point during the hard drive loading process and then go into Service Mode, the contents of $1B3 appear to be $00, which is suspicious. At that page in the Boot ROM manual, it says that $00 is for a built-in hard drive, which arguably an H/A8 computer should not have (note that the manual appears to use "parallel port" and "builtin hard drive" to mean different things). If I try an H/40 ROM, then $1B3 appears to be $02, which is as expected per the manual.

Ah! Now remember that byte normalisation that turns $00 into $02. It only happens on a Lisa 2/10, something that's registered by a value of $03 at memory location $2AF. On the LisaFPGA, a H/40 ROM configuration has $2AF = 0 ("Lisa 0" per Boot ROM manual PDF page 27), while an H/A8 ROM has $2AF = 1 ("Lisa 2 with Sony, old I/O board (slow timers)"). So it won't convert $00 into $02. $00 is not a valid hard drive identifier for the Selector or the code it depends on.

If this theory is correct, then we have a testable prediction: shorting GPIO0 to 3V3, making our Lisa into a 2/10, will find the Selector booting successfully. Let's try it: yes! And in Service Mode, $2AF  = $03. (Even though it maybe should really be a different value meaning "Lisa 2/10 with Sony, some I/O board with slow timers, internal disk." You can tell the slow timers by the lower pitch of the boot ROM beeps when running at the stock clock frequency!)

(NB: Other minor edits were made for clarity)

[stepleton]

Questions in a separate post since the one before is probably too long:

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

[AlexTheCat123]

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

No, I never even touch $1B3! The boot ROM is the only thing that messes with it. My (very quick and possibly inaccurate because I have two homework assignments I need to get done) scan of the boot ROM listing seems to indicate that $1B3 only gets set if the user typed a boot command, and NOT if the system is trying to autoboot, so perhaps this is happening because it's autobooting and nothing overwrites the default value that's in RAM, which happens to be 0?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

I've seen it occasionally on real hardware, although I've always just dismissed it as a fluke and never really paid attention to when/why it happened. I feel like I've probably noticed it more after cold boots than warm boots/resets, but I don't have any concrete evidence to back that up.

[sigma7]

I never even touch $1B3! The boot ROM is the only thing that messes with it.

At 16E8 and 16FE the ROM checks to see if the startup-from menu is requested, if not, at 1706 it checks to see if PRAM is valid.

If PRAM appears valid, at 1722 it loads the stored boot device id from PRAM into D0.

Then at 1754, D0 is stored in $1B3. (The ROM listing I'm looking at is misformatted: the bytes of the instruction at 1754: 11C0 01B3 are not shown in the listing, it just increments the PC, making it look like there is no instruction there... the instruction is in the ROM binary.)

The PRAM checksum algorithm is simply adding with some rotates then checking if the sum is zero, so all zeros looks valid.

Suggest defaulting the PRAM to some other value.

[slewis1962]

It won't even give me the boot menu, it boots straight into this error and that's it.

I think this is an issue with Stepleton's awesome selector software (used by the ESProFile) and/or the default values for the PRAM, depending on your point of view.

If you press a key during the self-test, you will see the startup-from menu, and then selecting a startup device works.

If you miss that opportunity, (I surmise) the values in the PRAM look like a default startup device has been selected, but doesn't fully specify which device. So when the selector loads it can't tell which parallel port it was loaded from. You can type the digit 1 and it will proceed normally. If you use a real ProFile, I expect it works normally without this hiccup.

As far as I can tell, the integrity check the ROM does on the PRAM values at startup doesn't catch some of the scrambled permutations, and I suppose the default values in the LisaFPGA match one of these (all zeros perhaps).

I see there is a 93C56 eeprom on the LisaFPGA... perhaps that can be used as actual persistent PRAM?

Otherwise, we should probably come up with a new set of default values to request. IIRC there is another problematic PRAM value that makes the MacWorks XL mouse double-click insanely short, so double-click won't work until one changes the setting in the control panel. Other options may be short RAM test and I suppose startup defaults to the primary parallel port.

edit: corrected description of the selector

This is really embarrassing. I got my first Lisa in 1991 or 1992. I used to know all this stuff. I guess since my Lisa's have been sitting on a shelf since I archived the Twiggy Basic disks sometime in 2012 I have forgotten the basics! Anyway, I typed 1 and it gave me the selector menu. Thanks for the help.

[slewis1962]

It is the Selector software you're seeing here, and my own LisaFPGA shows the same behaviour. I can just press 1 to select the built-in parallel port, and it works fine from there. @slewis1962, does pressing 1 when you see this screen not work for you?

Yes it does. As I said in my previous post I seem to have forgotten all that I knew years ago due to my Lisa's sitting on a shelf for almost 14 years! I appreciate the help!

[slewis1962]

Questions in a separate post since the one before is probably too long:

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

This is what I get on my LisaFPGA board. I'll try later with my actual Lisa.


*EDIT*
I used the selector with Alex's ESProfile the other day for the first and only time on my Lisa 1. I didn't have any problem and it booted up to the normal selector menu. I'll try it on my 2/5 or 2/10 later on. I also have a MacXL which I could try it on.

[stepleton]

No, I never even touch $1B3! The boot ROM is the only thing that messes with it. My (very quick and possibly inaccurate because I have two homework assignments I need to get done) scan of the boot ROM listing seems to indicate that $1B3 only gets set if the user typed a boot command, and NOT if the system is trying to autoboot, so perhaps this is happening because it's autobooting and nothing overwrites the default value that's in RAM, which happens to be 0?

I wonder if this commit fixed a bug that was also causing us to get "lucky" when the boot ROM talked to the floppy controller; maybe it read a different value from the PRAM before that somehow?

If PRAM appears valid, at 1722 it loads the stored boot device id from PRAM into D0.

...

The PRAM checksum algorithm is simply adding with some rotates then checking if the sum is zero, so all zeros looks valid.

Interesting. On a real Lisa 2/5 (without batteries) that has just been plugged into the wall, odds are that the PRAM is initialised to random values with a checksum that doesn't match. If so, then CHKPM fails at $1706, and then if CHKPROFILE at $1714 sees a ProFile on the parallel port, then we decide to boot from that ProFile at $171E.

But if the PRAM contains all zeroes, then it's valid (as you say) and the boot device is $00, which is as good as $02 for booting from the ProFile to the boot ROM

I think it's a Selector bug to fail in this way, so I will probably change the code here to promote $00 to $02 for all Lisas except a Lisa 1. So a version bump from 1.0 to 1.01 is pending...

Yes it does. As I said in my previous post I seem to have forgotten all that I knew years ago due to my Lisa's sitting on a shelf for almost 14 years! I appreciate the help!

I'm glad it helps! But the Selector software itself is only five years old; it was written in the depths of COVID. So there's no old knowledge that you have lost here. (For me that's something that's reassuring to hear  ).

I used the selector with Alex's ESProfile the other day for the first and only time on my Lisa 1. I didn't have any problem and it booted up to the normal selector menu. I'll try it on my 2/5 or 2/10 later on. I also have a MacXL which I could try it on.

Thanks for trying on the Lisa 1; what you see matches my expectations based on today's investigation (and also my experience). The 2/5 specifically is the system of primary interest for this test, especially when you start it up for the first time after unplugging it and plugging it back in; the rest shouldn't behave in an unexpected way (I hope). But I'm betting it just works, since the boot PRAM probably won't be initialised to zeros. It would still be helpful to confirm it, of course!

[AlexTheCat123]

I wonder if this commit fixed a bug that was also causing us to get "lucky" when the boot ROM talked to the floppy controller; maybe it read a different value from the PRAM before that somehow?

I was pondering this earlier and came to the same conclusion. Perhaps the stack corruption was touching PRAM values and causing them to be nonzero, making the checksum fail and causing the values to get reset to good defaults?

I think it's a Selector bug to fail in this way, so I will probably change the code here to promote $00 to $02 for all Lisas except a Lisa 1. So a version bump from 1.0 to 1.01 is pending...

Even so, I think I should probably still make PRAM initialize with garbage instead of 0's to be more accurate to the original hardware. My goal is 100% accuracy (or as close to that as I can realistically get), and the fact that the Selector works on real hardware but shows weird behavior here means that I'm not quite there yet.

[slewis1962]

Questions in a separate post since the one before is probably too long:

1. The problem appears to be that the LisaFPGA, when booting from the internal parallel port in an H/A8 configuration, sets $1B3 to $00 and not $02. @AlexTheCat123, is this as expected?

2. Does anyone use the Selector (the drive image boot menu) with a real Lisa 2/5? Do you ever see the problem @slewis1962 reported? Either way, what happens if you quit the Selector (press Q from the hard drive image menu), then enter Service Mode (press Apple-S), then type 1 (for DISPLAY MEM), then 1B3<return> (for ADDRESS?), then 1<return> (for COUNT?)? What do you see if you then type 1, then 2AF<return>, then 1<return>?

This is from my Lisa 1 with D/40 ROMS. It booted into selector with no problems.



This is from my Lisa 2/5 with H/A8 ROMS. It also booted into selector with no problems.

[stepleton]

Thanks for that --- interesting to see that 02 right there after the BF, but perhaps not unexpected given the discussion we've been having. Had you already booted this Lisa at least once before (and left it plugged in after that), or is it right after having the Lisa unplugged and then plugging it back in? I suspect it doesn't matter, but there's a very slim chance it might.

[slewis1962]

Thanks for that --- interesting to see that 02 right there after the BF, but perhaps not unexpected given the discussion we've been having. Had you already booted this Lisa at least once before (and left it plugged in after that), or is it right after having the Lisa unplugged and then plugging it back in? I suspect it doesn't matter, but there's a very slim chance it might.

This is first thing after booting. I pulled it off the shelf and plugged it in. It booted to selector, I chose Q, then hit apple-s.

[stepleton]

thanks! It's consistent with the theory that uninitialised PRAM is in a random, invalid state; it's not all zeroes.