Yeah, it's pretty incomplete, and I think things have changed since the May version too.The stuff on bitsavers has massive holes in it. (A particularly irksome thing that comes from comparing the March and May-dated versions of the protocol documentation is the earlier one specifically suggests that the protocol contains "acks" transmitted through the IWM from the drive to the computer, while a conservative reading of the May document suggests that handshaking is limited to that business of "toggling /HSHK", which is semi-infuriating because it's not entirely clear how /HSHK works.) There may be no way to definitively fill in some of the grey areas without constructing a probe and doing signal capture and analysis on a live and working HD-20. Unfortunately.
For example: the May version claims that if the computer needs to hold the drive off from transmitting (so it can handle a pending serial interrupt) during an 8 byte group of data, it changes to state 0 and ignores the rest of the group in progress. Then when it signals to the drive that it's ready again, the drive will continue by repeating the group that was interrupted.
I've been disassembling the HD-20 driver in the Mac Plus ROM and it looks to me like now the behavior is that the drive finishes transmitting the interrupted group, and then when the computer says it's ready, the drive continues where it left off with the next group. My complete guess is the behavior probably changed because this note was considered unacceptable behavior:
I also think that more aspects of the hold-off behavior have changed too. We may be able to figure out the behavior based on the ROM disassembly and what it tells the IWM to do, but it'll take some time to digest.If interrupts are occuring with high frequency, then it is possible for the Macintosh to do a hold-off in the middle of the same (restarted) group over and over again, potentially forever.