[CDG5] Booting 9 from driver-less disks

[Elliot Nunn]

Got it, for real!

https://github.com/elliotnunn/tbxi-patches/commit/a8c1a4d <https://github.com/elliotnunn/tbxi-patches/commit/a8c1a4d>

The commit message describes some of the hurdles.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190825/dde3c243/attachment.htm