This is an exciting project! Excellent work!
As a reference point, I've hit a peak of 9.6MB/s using a 32GB SanDisk Extreme (120MB/s) > Stratos CF AztecMonster > Sixty Eight Thousand SCSI Bolt > IIfx (50MHz clock). Seems likely the SCSI Bolt is actually the bottleneck here since it's a 10MB/s fast/narrow bus.
I'll be excited to see what you can hit on the IIfx!
View attachment 83652
In my experience Startup Disk will correctly set the disk/interface, while System Picker will correctly set the partition/system folder (if you have multiple bootable partitions and/or system folders on the same physical disk.)
Using a combination of both has worked well for me, but maybe I've missed a more elegant solution.
Nice! I imagine the SCSI bolt is using DMA. I will have to borrow an IIfx to test with as in theory the tighter timings at 20mhz ought to be fine (from a CF timing perspective) but some cards like it, some don't. I'm hoping the IIsi will work as an intermediate test case too.
I'm incorporating bus drivers on a revised prototype to make it easier on the cards. Technically, it might be possible to use the "fast" address space with a PIO-6 card too but we'll see what happens. I admit, PDS isn't my main focus here so it's a bit of an extra if I manage to get something working there.
Your experience matches what I observed. I just ended up special-casing system picker so my ROM will pick up its intent and make the correct changes to the startup device instead.
If you felt like hacking on it you'd need to do something along the lines of taking the selected volume, locate the driver, and find its AuxDCE entry that will describe what slot and resource number to detect the special case. Or take the opposite approach and go via slot manager. Then for slot devices
correctly update the PRAM.
Each partition in an Apple Partition Map has a "Startup" status bit. I suppose it's like the active partition flag in MBR formatted disk.
If my Old World Mac isn't booting from the currently selected partition on an SSD, I can connect it to a modern Mac and use iPartition.app to set which partition has the Startup bit (or I can use
dd and
xxd to read and set the flags).
A partition may have multiple System Folders.
bless on a modern Mac can set which folder of a partition gets booted. This info is stored in the
drFndrInfo of a HFS or HFS+ partition.
dumpvols.sh is a script you can use to view those status bits and the
drFndrInfo of a disk.
https://gist.github.com/joevt/a99e3af71343d8242e0078ab4af39b6c
Attached contains PRAM notes. I suppose default boot is stored in
DefBoot (if the Mac uses XPRAM). The
supermario source code on github has some classic macOS PRAM info. Which Macs added XPRAM?
Other XPRAM notes:
https://okmij.org/ftp/xPRAM.html
Mac Plus added XPRAM. Believe me, I've done enough digging on PRAM to now to know what's going on here
The issue in particular is that System Picker is not special casing volumes on Nubus/PDS cards - these must have startup the startupDevice PRAM location (4 bytes at $78) in the form $00000SRR, where S is slot # and RR is the resource number. This is
required for a nubus card presenting storage to have its BootRec executed at early boot time so it can install its driver and be booted from. I detailed a bit on this earlier in the thread.
However, system picker just puts the driver refnum into startupDevice in conjunction with changes to the HFS volume flags. That's fine for SCSI, and floppy (?), but it renders Nubus cards unbootable as
@jeremywork noted. I ended up special casing this as I do like using System Picker; my driver will stash its refnum in private slot PRAM and primaryinit will correct the startupDevice PRAM if required.
--------------------------------------------------------------------------------------------------------------------------------------------
Another dose of notes on disk drivers.
Any volumes added in DrvrOpen belonging to this driver should be dequeued and their entries disposed of if DrvrClose is called (Mode32, A/UX only known to do this...)
System picker sets startup info to the driver refnum (incorrectly). But you can detect and check for that in PrimaryInit, if you choose...
Prime notes: This is the routine used to read/write data from drivers.
IO will always be in 512 byte multiples unless you support the character-based routines.
Prime should return ioErr if anything went wrong, but still advance the drive position up to the point the error occurred and update ioActual.
Support of 4GB volumes on sys 7.5 requires treating the long (signed long int32) parameters of IOParamBlock as unsigned longs. Nice and easy.
Expectation of the rdVerify mode is to check buffer contents against data read using the parameters and return dataVerErr if it doesn't match
Not sure if it's actually used (outside of floppy formatting) or is even considered valid with a HDD/HD20 type device.
If a partial read/write is performed (not all the requested data) then an error must be returned, it will not be handled correctly otherwise
Valid Prime return codes:
nsDrvErr (no such drive) is considered a fatal error and should never be retried
offlineErr is a temporary failure e.g no medium present
ioErr should be used for actual issues accessing the device - if it's fatal or not is up to Mac OS
dataVerErr only should be used with rdVerify
noErr (duh)
Control call Eject isn't called on Mac OS 7.1 just before shutdown. Might just be the A/UX version? 7.5 certainly does this.
If you have no need for an interrupt, there is nothing precluding you from using slot $C, $D address spaces. I'm going to default to $D as this will mean it should never have a slot conflict with another card.
