[CDG5] Booting 9 from driver-less disks

[Elliot Nunn]

Got it! …kind of

This commit adds an ATALoad patch to the tbxi-patches library:

https://github.com/elliotnunn/tbxi-patches/commit/9351898

ATALoad reliably falls back on the ROM ATADisk driver when no driver partition
is present. In QEMU, this enables a successful boot. Not so on my Mac mini. On
that machine, the ROM driver does not recognise the bootable partition as being
bootable, and we get stuck at the question mark.

> On 20 Aug 2019, at 2:32 pm, Elliot Nunn <elliotnunn at fastmail.com> wrote:
> 
> 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
> 
> _______________________________________________
> cdg5 mailing list
> cdg5 at ucc.asn.au
> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5