LisaList2

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)

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