[CDG5] Booting 9 from driver-less disks

[Daniel B-J]

SCSI Interface Modules have the ability to override the driver on disk for a device.
SIMs seem to be the only type of Interface Module with that capability.
AIMs and FWIMs can't do it.

So SCSI Manager (4.3) supports fallback drivers by design and you are reversing ATA's mechanism for it.
Apple restricted info on Firewire booting, so I have no idea how it works at all.

It would be interesting to make a tbxi that loads and provides drivers for a RAMDisk. That would work on everything.
> On Aug 20, 2019, at 2:32 AM, 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