I looked at this a bit more, and I think it's probably not going to happen. At least I think it doesn't really make sense to pursue, given the difficulty that looks to be involved, when mmcmaster already has a working solution for an SD SCSI disk emulator that would accomplish almost the same thing. I did identify a few interesting notes in the docs, though, and a whole bunch of questions that need answering.
The two main docs of interest are the specifications for Directly Connected Disks, one from March 1985 and one from May 1985.
The good news is that the communication protocol allows for several daisy-chained HD20's, with a floppy drive at the end of the chain. Block addresses are three bytes, implying a maximum disk size of 8 GB if 512 byte blocks are used. The protocol uses handshaking for the drive to signal when it's ready, which should avoid the problems I had with floppy emulation where some SD cards aren't fast enough to keep up with the Mac.
Bad news: First off, the handshake method described in the doc doesn't make sense to me. For drive-to-Mac transfers, the doc says the drive should continue sending data until the handshake signal is de-asserted (May '85 doc, bottom of page 4). But the handshake signal and the drive data are sent on the same pin, and just interpreted differently depending on what state the transfer is in. Once an open-ended data transfer has begun, and it's using that pin for data, I don't see how the same pin could be used to indicate the end of the transfer. I must be misunderstanding something, but the provided examples don't go into enough detail to explain it.
The March and May versions of the spec have *major* differences. That would be OK if we knew for sure that the May document was the final version, but if the spec changed that much in two months between March and May, I'm guessing that it continued to change after that. So the May doc is probably not entirely correct or complete, and using it as the starting point for emulation would be problematic.
The size of a block is not mentioned anywhere in the May doc. The March doc says it's 532 bytes, which is a little baffling, and I strongly suspect that includes some extra metadata that's never described. A floppy sector (block) is 524 bytes, of which 12 is tags and 512 is the actual data. Does HD20 use tags? Does it include some other, or additional per-block metadata? The doc doesn't say.
The HD20 checksum algorithm is not defined or described anywhere. It's a one byte checksum, so it can't be the same algorithm that's used for floppy checksumming.
In addition to read, write, and status commands, the May doc also lists about a dozen other commands and their parameters, but it never says what those commands do or what response the drive should make. These include device id, seek, park, format, servo status, diagnostic stuff, and others.
I spent a while digging through a disassembly of the Mac Plus ROM looking for help, but I couldn't even identify where the HD20-relevant routines were, so it was a dead end.
Lastly, I realized I don't know how I would go about testing this. I don't have any disk images of an HD20 drive, and I'm not sure what one would look like, if they truly have 532 byte sectors. And unlike a floppy, I can't plug in an HD20 after the Mac has already booted, and then ping it with a test program. It has to be present when the Mac first boots, which means I can't easily observe what's happening as it queries the drive.
TL;DNR - Lots of questions and undefined details from the docs, probably all solvable with enough time and effort (especially with a disassembly of the HD20 ROM routines), but probably not worth the headaches given that a nice SD hard disk solution already exists.
The two main docs of interest are the specifications for Directly Connected Disks, one from March 1985 and one from May 1985.
The good news is that the communication protocol allows for several daisy-chained HD20's, with a floppy drive at the end of the chain. Block addresses are three bytes, implying a maximum disk size of 8 GB if 512 byte blocks are used. The protocol uses handshaking for the drive to signal when it's ready, which should avoid the problems I had with floppy emulation where some SD cards aren't fast enough to keep up with the Mac.
Bad news: First off, the handshake method described in the doc doesn't make sense to me. For drive-to-Mac transfers, the doc says the drive should continue sending data until the handshake signal is de-asserted (May '85 doc, bottom of page 4). But the handshake signal and the drive data are sent on the same pin, and just interpreted differently depending on what state the transfer is in. Once an open-ended data transfer has begun, and it's using that pin for data, I don't see how the same pin could be used to indicate the end of the transfer. I must be misunderstanding something, but the provided examples don't go into enough detail to explain it.
The March and May versions of the spec have *major* differences. That would be OK if we knew for sure that the May document was the final version, but if the spec changed that much in two months between March and May, I'm guessing that it continued to change after that. So the May doc is probably not entirely correct or complete, and using it as the starting point for emulation would be problematic.
The size of a block is not mentioned anywhere in the May doc. The March doc says it's 532 bytes, which is a little baffling, and I strongly suspect that includes some extra metadata that's never described. A floppy sector (block) is 524 bytes, of which 12 is tags and 512 is the actual data. Does HD20 use tags? Does it include some other, or additional per-block metadata? The doc doesn't say.
The HD20 checksum algorithm is not defined or described anywhere. It's a one byte checksum, so it can't be the same algorithm that's used for floppy checksumming.
In addition to read, write, and status commands, the May doc also lists about a dozen other commands and their parameters, but it never says what those commands do or what response the drive should make. These include device id, seek, park, format, servo status, diagnostic stuff, and others.
I spent a while digging through a disassembly of the Mac Plus ROM looking for help, but I couldn't even identify where the HD20-relevant routines were, so it was a dead end.
Lastly, I realized I don't know how I would go about testing this. I don't have any disk images of an HD20 drive, and I'm not sure what one would look like, if they truly have 532 byte sectors. And unlike a floppy, I can't plug in an HD20 after the Mac has already booted, and then ping it with a test program. It has to be present when the Mac first boots, which means I can't easily observe what's happening as it queries the drive.
TL;DNR - Lots of questions and undefined details from the docs, probably all solvable with enough time and effort (especially with a disassembly of the HD20 ROM routines), but probably not worth the headaches given that a nice SD hard disk solution already exists.