Skip to main content
Home Forums 68kMLA Floppy emu - Emulating HD20 :-) — #7
Post #7 by Gorgonops
Source Forum68kMLA
CategoryTroubleshooting
Post DateTue, 17 Dec 2013 - 17:47
Original URLhttps://68kmla.org/bb/threads/floppy-emu-emulating-hd20.29449/
Post
Wholy (@rp, I didnt know that was out there. There was a thread by dennis nedry that was discussing the HD20 and reverse engineering it. Maybe thats his site? info? I dunno.
During the last long thread about this I threw in some links to bitsavers (where this is) and the *important* parts of the HD20 directory, the two .pdf files which discuss the command format and the directory with the firmware listing, definitely weren't there at the time. (The dates on said files/directories are September/October this year.) Those .pdf files are the missing piece that in theory should make emulating an HD-20 "not that hard" once you have a device (like the Floppy Emu) that can "arbitrarily" communicate over the IWM connector. It's fair to say that the mechanics of the data transfer (IE, using the IWM as a UART, etc.) had been pretty much sussed out but lacking the command set information was a big black spot. Pretty much the only way to figure that out would have been to:

A: Accurately disassemble the driver, and from there step backwards through the other parts of the OS which makes calls to it, and/or:

B: Put together a test program which bangs on a working HD-20 and log/analyze everything the signal lines are doing when the drive is commanded to do "X", "Y", or "Z".

The .PDFs are awfully short on detail and the expected return codes from some of the operations (like all the diagnostic ops) aren't really specified, but it's still a huge leap forward.

Honestly if you can work out the details (which, again, should be much easier now) emulating an HD20 could be easier than a floppy drive. The protocol is "packet based", IE, it sends discrete groups of 7-bit encoded bytes, and it appears to allow for the drive to take (within reasonable limits) arbitrary time to complete the request when executing sector read/write commands. (You're not actually having to emulate the mechanics of real "spinning disk", the HD-20 is an abstracted "storage device" like a SCSI drive.) That implies at least that some of the SD Card latency issues that BMoW runs into when emulating floppies won't matter anywhere near as much. And, again, the protocol appears to allow arbitrary device sizes (within reason), so a device set up as an HD-20 emulator should be able to, for instance, make direct use of vMac or BasiliskII disk volumes by just checking the size of the file and reporting it to the Mac at boot time.

Anyway, nice that these docs *finally* cropped up. They've been wanted positively forever.

mp.ls