rakslice / macemu

Basilisk II and SheepShaver Macintosh emulators
0 stars 0 forks source link

SS: newworld doesn't boot from CD when set by bootdriver #35

Closed rakslice closed 3 years ago

rakslice commented 4 years ago

When a new world rom boots in SS, it always ignores the bootdriver pref and boots from the first disk

rakslice commented 4 years ago

idk if this has ever worked w/ newworld ROM.

The bootdriver param goes into PRAM 0x137a, and the bootdisk param into 0x1378.

Mac OS 8.5/8.6 Startup Disk control panel crashes SS in Windows and Linux, but the Mac OS 9.0 version doesn't crash, and saves the expected values in to PRAM, they just have no effect when you reboot using them.

Changing the disk numbers and driver refnums has no effect.

Is the boot behaviour that SS is relying on in new world not part of a normal boot but some kind of fallback or vestigial thing that is not subject to the normal Startup Disk setting on a real Mac?

rakslice commented 4 years ago

initing the drivers (init_disk(), init_cdrom()) in a different order doesn't make any difference to the order of the disks in the disks list, because the system always actually opens the drivers in the same order, with Disk first (thus adding its disks first)

rakslice commented 4 years ago

The change from .Disk to .ATADisk was a recent change in https://github.com/rakslice/macemu/commit/5b31736785586493e3a98c2eca91f1e548765dbe but this isn't a factor in the problem -- it happens even in a cebix/macemu build

rakslice commented 4 years ago

I ended up writing a workaround, where I just reorder the disk queue right after the CDROM is opened based on the parameter value, which works okay and my PR for it was merged.

But I still want a solution that isn't a hack if we can find out what interface the NewWorld Mac ROM actually gives for this

rakslice commented 3 years ago

From "Apple iMac Computer Developer Note" (1998) (PDF version) section "Startup Disk Control Panel"

Open Firmware now bears responsibility for locating a startup device. This is very different from previous Mac OS systems where the Mac OS ROM had responsibility for locating the startup device. On the iMac computer, the Mac OS ROM image itself comes from the startup disk, so decisions regarding startup device must be made earlier in the startup process. Open Firmware recreates as much as possible the user experience of earlier systems but the implemention is very different.

Previous systems stored the user's selected startup device in PRAM. The startup device was set in PRAM when the user selected a device in the Startup Disk control panel. This device was honored by the Mac OS ROM unless the selected device was unavailable or was overridden by the user. The startup disk routine for the iMac, rather than setting Mac OS PRAM, sets an Open Firmware config variable called boot-device. This setting is honored by Open Firmware unless the selected device was unavailable or was overridden by the user.

...

Once Open Firmware locates a startup device and successfully loads a Mac OS ROM, image it passes information about the chosen device in the bootpath variable. This information, rather than that previously set in PRAM, is subsequently used by the Mac OS ROM to locate the device containing the startup System Folder.

That last part is rather confusingly worded, maybe a misunderstanding on the part of the writer, when you learn what they're trying to explain.

From Apple Tech Note TN 1062 "Fundamentals of Open Firmware, Part II: The Device Tree":

Section 3.5 of the IEEE Specification names the following standard nodes that a device tree must support.

/
/aliases
/chosen
/openprom
/options
/packages

From Apple Tech Note TN1167 "The Mac ROM Enters a New World":

Once Open Firmware selects a device, it sets the "bootpath" property in the "chosen" node to the path to that device.

They don't say what format the path in the setting is in; possibly a typical Open Firmware device path to the disk device starting with /.

rakslice commented 3 years ago

There's nothing I've tried putting in chosen/bootpath that doesn't just hang the system, although that is different than the default behaviour so at least to that extent I know that it at least cares about that property value.