As noted, the *one* place where an HD-20 emulator would provide a unique value proposition is as a storage device for the original SCSI-less Fat Macs; an SD->SCSI device is of no help there. Outside of that it's basically a waste of time. But I totally understand why it's a daunting proposition and you wouldn't want to take it on; the lack of good documentation for the devices is positively infuriating.
(I suspect it's to no minor degree intentional obfuscation in order to make the HD-20 difficult to clone. Apple broke their own rules with that device, having told 3rd party developers since the Mac's introduction to use the serial ports for any hard-disk like devices.)
The "DV 17" tech note and several other sources back up that "532 byte" block size, but likewise they're not at all forthcoming about what the extra bytes are actually used for. And, yeah, the rest of those docs on Bitsavers basically raise more questions than they answer. There's no sample return values for basically any of the function calls.
A: If the Mac needs to interrupt data transmission (which is of a fixed standard size... probably a "block", but there's also references to "groups" so it could be either) TO the drive it can tell the drive it's stopping by fiddling the phase lines.
B: If the Mac needs to interrupt reception of data FROM the drive it can fiddle with the phase lines to tell the HD-20 it's not listening anymore, and then simply ignore any data that comes from the drive in the period between the Mac saying it's not listening and the drive acknowledging the stop.
C: I don't actually see a mechanism for the HD-20 to halt transmission from the Mac. The annotations on the diagram on page 9 say that the drive needs to respond within X amount of time to the Mac asserting a holdoff, but it doesn't say anything about the drive being able to tell the Mac to back off.
With that in mind there must be some pretty strict cadence that's observed in the driver to ensure that the HD-20 isn't overrun by data during multiblock transfers, and I think that's *partially* described in the protocol layout; after each data block there's 70ms of "silence", after which there's another 14ms for the HD-20 to say it's ready for the next sync block. Assuming the Rodime drive had typical-of-the-era rotational speed and track-to-track stepping time that 80ms-ish window is probably sufficient to allow the drive to keep up in real time for consecutively-addressed blocks even if it has to step. (The drive has a buffer big enough for a couple of blocks, that also undoubtedly helps.) I do sort of wonder how the system handled, say, bad blocks (were those tracked by the drive transparently or at the file-system level?) or if extra time was hardcoded into the driver to allow the disk to seek when the next read/write transaction was non-contiguous with the last...
Anyway, yeah, documentation is *bad*. Reverse engineering this is a job for someone that *really* wants it, there's no shame in not being that person.
(I suspect it's to no minor degree intentional obfuscation in order to make the HD-20 difficult to clone. Apple broke their own rules with that device, having told 3rd party developers since the Mac's introduction to use the serial ports for any hard-disk like devices.)
The "DV 17" tech note and several other sources back up that "532 byte" block size, but likewise they're not at all forthcoming about what the extra bytes are actually used for. And, yeah, the rest of those docs on Bitsavers basically raise more questions than they answer. There's no sample return values for basically any of the function calls.
Just for the record, I think that daisy-chain mechanism it describes is the same used for "smartport" floppy drives as used on later Apple II family drives. I *think*.
So... I can't claim I really understand it myself, but I *think* what's really poorly explained in that section (or just sort of implied) is that the handshake is really only semi-bidirectional. IE, the way I interpret it is:
A: If the Mac needs to interrupt data transmission (which is of a fixed standard size... probably a "block", but there's also references to "groups" so it could be either) TO the drive it can tell the drive it's stopping by fiddling the phase lines.
B: If the Mac needs to interrupt reception of data FROM the drive it can fiddle with the phase lines to tell the HD-20 it's not listening anymore, and then simply ignore any data that comes from the drive in the period between the Mac saying it's not listening and the drive acknowledging the stop.
C: I don't actually see a mechanism for the HD-20 to halt transmission from the Mac. The annotations on the diagram on page 9 say that the drive needs to respond within X amount of time to the Mac asserting a holdoff, but it doesn't say anything about the drive being able to tell the Mac to back off.
With that in mind there must be some pretty strict cadence that's observed in the driver to ensure that the HD-20 isn't overrun by data during multiblock transfers, and I think that's *partially* described in the protocol layout; after each data block there's 70ms of "silence", after which there's another 14ms for the HD-20 to say it's ready for the next sync block. Assuming the Rodime drive had typical-of-the-era rotational speed and track-to-track stepping time that 80ms-ish window is probably sufficient to allow the drive to keep up in real time for consecutively-addressed blocks even if it has to step. (The drive has a buffer big enough for a couple of blocks, that also undoubtedly helps.) I do sort of wonder how the system handled, say, bad blocks (were those tracked by the drive transparently or at the file-system level?) or if extra time was hardcoded into the driver to allow the disk to seek when the next read/write transaction was non-contiguous with the last...
Anyway, yeah, documentation is *bad*. Reverse engineering this is a job for someone that *really* wants it, there's no shame in not being that person.