[CDG5] Booting 9 from driver-less disks

[Elliot Nunn]

Hi all,

The classic Mac OS requires non-floppy disks to have a driver partition to be
bootable. The ROM ATA/SCSI/FW/USB Manager has a special code path to load a DRVR
from this partition, and then the DRVR takes over. (After boot is completed,
DRVRs can come from other sources.)

This was fine when Macintosh formatting utilities routinely wrote out this
driver partition. But many 9-compatible Macs either shipped with, or have ended
up with, driver-less HFS boot disks. Open Firmware can read the NewWorld ROM
from these disks, but the ROM then leaves the machine with an OldWorld-style
blinking-question-mark-on-floppy-disk. (For reasons that I don't understand yet,
the ROM sometimes relents after 25 seconds of blinking, and uses its own DRVR.)

For Mac OS 8/9 to boot, the disk then needs to be reinitialised by Drive Setup
or similar. This is inconvenient for tinkerers, and a show-stopper on machines
with limited I/O options.

By the time this problem is encountered, the NewWorld ROM is already safely
loaded into RAM. Now, with our ability to patch the NewWorld ROM, we have an
opportunity to produce a workaround.

I have looked into this, and I think I am close to a solution. These are some of
my findings about the ROM boot process, which I don't think are documented
elsewhere. They focus on the ATA Manager, but the Monster Disk Driver Technote
suggests that SCSI will work the same way.

The .ATALoad DRVR in ROM (ID -20175) uses accRun time to scan for new ATA
drives, and load their ATA drivers. It can be signalled to do this by the 10.x
ROM function at offset 0x5D940, and possibly by another mechanism as more disks
come online. The 0x5D940 function is called in every search iteration of the ROM
function FindStartupDevice. The ATA Manager has a horrible and poorly documented
calling convention, but using IDA I have gotten a decent idea of the ATA Manager
calls that .ATALoad makes. ATA Manager calls are used to load the driver from
disk, then the driver has a special entry point at offset 8 to determine whether
a given partition is bootable. At this point, I think, the driver calls the ATA
Manager to "open" itself and get a slot in the unit table.

So one option is to patch ATALoad to "see" a driver partition where there is
none. It would be difficult to automate such a patch to work with different
versions, because the relevant function is compiled from C, so register
allocations might change frequently.

At the moment I am not near a real Mac, but in Qemu, I have noticed that the 68k
ROM glue to the StartLib function GetStartupDevice returns an error when the
driver partition is missing. This suggests that the native StartLib parcel PEF
is unable to interpret the "bootpath" property of the "chosen" node without the
help of the DRVR. I think the most elegant solution would still be to fake the
presence of a driver partition.

Cheers,

Elliot