• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Floppy emu - Emulating HD20 :-)

dougg3

Well-known member
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.
Yeah, it's pretty incomplete, and I think things have changed since the May version too.

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:

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.
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.

 

bigmessowires

Well-known member
I decided to look at the problem from the other end, and made a little progress there. While the Mac still returns error -17 for everything, I'm now able to receive HD20 commands on the Floppy Emu and display them on its screen. It looks like the Mac keeps sending an HD20 status command, and because it gets no reply, it shows error -17.

The format of the status command mostly matches what's described in the HD20 doc, but with the inclusion of two extra "mystery bytes". With help from dougg3, we studied the ROM routines to determine that those bytes are probably the size of the output data and the size of the expected reply. Those were likely added as some kind of future-proofing feature, so drives could gracefully handle commands they don't know about, if the Mac and the drive are using different version of the API.

If I can figure out how to construct and send a proper status reply, I'm hoping it will be enough to get past error -17.

 
Top