Deciphering DCD (Hard Disk 20)

[Tashtari]

The more I delve into the HD20 and the DCD protocol in general, the more fascinating things seem to become...

I'm going to start this thread just so I can put some of the things I've found out somewhere.

The May 1985 DCD Document is the best overall source for information on the DCD protocol, but that's not saying much given that it's full of inaccuracies, or things that might have been accurate at some point during development, but no longer. Its description of the 7-to-8 encoding that is used to communicate with the device over the IWM is accurate, the description of the eight protocol "states" selected by the phase lines is very nearly accurate (state 0 has ReadData in data mode, not sense mode), the description of how DCDs are chained is accurate. The descriptions of the handshake protocols between the Mac and the DCD are accurate, except for the holdoff protocol which is quite different (see what I've written about this in the README for TashTwenty). The document also features a list of commands that is almost entirely wrong. It's that that I'm going to focus on.

Read blocks (0x00) and write blocks (0x01) are both accurately described by the document. Controller status (0x03) is almost accurately described, with a small alteration to the format of the buffer returned by the device. There is a small, handwritten allusion to what command 0x02 is in the document - the description of the write command also seems to suggest that "write verify" is in the same format, and "02" is scrawled next to "write verify". This is consistent with the behavior I've seen when sticking the analyzer on the HD20 Test application running in destructive mode, it does a long series of 0x02 commands that run through the drive's logical blocks in order, presumably using the drive's own reads to discover errors.

So what about the rest? I would see the occasional 0x04-and-beyond command, a couple showed up when doing an Erase Disk from the Finder and a bunch were thrown out at the start of the HD20 Test run, but none of them seemed to line up with the stuff from the May 1985 document. It wasn't until I read this article from MacGUI and got my hands on a copy of HD Diag that things started to make sense...

The December 1984 Nisha Firmware Specification Document contains a bunch of commands that sound familiar versus the ones in the May 1985 document and a protocol for carrying them that doesn't seem to line up with anything else. But when I put the analyzer on the 512ke running HD Diag and started throwing commands at it, I noticed that all the commands I sent used the command numbers listed in the December 1984 document, plus 4. Do the others line up?

Beginning of HD20 Test Test:
Mac: 0A 03 00 00 00 00 DCD: 8A 00 00 00 00 00 Mac: 05 00 00 00 00 00 DCD: 85 00 00 00 00 00 Mac: 11 00 00 00 00 00 DCD: 91 00 00 00 00 00 Mac: 04 00 00 00 00 00 DCD: 84 00 00 00 00 00 Mac: 17 00 80 00 00 00 DCD: 97 00 00 00 00 00 (then more 17/97)

0x0A - 4 = 0x06 ... Set_Recovery
0x05 - 4 = 0x01 ... Read_Controller
0x11 - 4 = 0x0D ... Read_SpareTable
0x04 - 4 = 0x00 ... Read_Id
0x17 - 4 = 0x13 ... Read_Track

Set_Recovery takes a parameter of either 0x01 or 0x00, according to the document, but Mac here sends... an 0x03? But these are entirely sane things for a test application to do at the start of its run.

Erase Disk:
Mac: 19 01 00 00 00 00 DCD: 99 00 00 00 00 00 Mac: 1A 00 00 00 00 00 DCD: 9A 00 00 00 00 8A

0x19 - 4 = 0x15, and 0x1A - 4 = 0x16 ... neither of which are listed in the December 1984 document. Dang, things were looking so promising. The drive did a bunch of clicking before responding to each of these, and I think they lined up with "Formatting disk..." and "Verifying format..." so perhaps that's what they do, lay down sector boundaries on each track and verify that they're there.

I'm guessing there were some non-radical but significant changes to the Nisha firmware specification after December 1984, but until someone discovers some more documents in the bottom of a file drawer somewhere, we may be left guessing.

Fortunately, no guesswork is needed for TashTwenty to work, for two reasons. One, Mac never does anything except 0x00, 0x01, and 0x03 in the course of normal operation. Two, one of the features of the DCD protocol that the May 1985 document doesn't mention is that Mac always gives an expected response length whenever it sends a command, so TashTwenty can (and does) respond to commands it doesn't know with an empty block, which seems to frequently get interpreted as "yup, yeah, did the thing you said, everything's fine". It certainly works for Erase Disk, anyway.

Here endeth the rambling.

 

[olePigeon]

I'll be watching this thread intently if you ever get the Eject flag working.

 

[Tashtari]

if you ever get the Eject flag working

Ah, yes, that...

The discovery of the way the Nisha diagnostic commands fit into the command set does kind of reduce my hopes that there's an "eject media" command anywhere... but they weren't high to begin with given that while the Mac does seem to recognize that a DCD with the "ejectable" flag is ejectable, it doesn't appear to send it any sort of command when told to eject it, it just unmounts and remounts it. I remember seeing something about an extra bit set in the controller status command but it didn't appear to correspond to anything, but I'll take another look one of these days. Still, it's very believable that the idea of a DCD with removable media was part of future plans that never came to fruition.

 

[mg.man]

it doesn't appear to send it any sort of command when told to eject it, it just unmounts and remounts it.

It may not be at all related, but I've seen this behaviour with a floppy drive where that little gear in the eject motor has failed. When you drag the floppy to the Trash, the disk "unmounts" from the desktop and the motor runs (but doesn't do anything since that gear is toast), then the disk "mounts" again. *If* I'm quick enough and physically eject the disk, it stays ejected. In the case of the floppy, it's looking for a "disk loaded" state from the microswitch. Could there be a "disk loaded" flag or something that is being queried? ...and therefore could be set/unset?

 

[Tashtari]

Could there be a "disk loaded" flag or something that is being queried? ...and therefore could be set/unset?

The controller status block has a "disk-in-place" flag, which is consistent with terminology Apple uses elsewhere (I forget where) to mean that media is loaded in a removable-media drive. It may be that the Mac polls the controller status when this bit is cleared, I haven't tested this. However, Mac does not poll the controller status when the "disk-in-place" flag is set, so it wouldn't know if a disk was removed unless some other event caused it to read the controller status. Anyway, letting Mac know that media has been removed after the fact is a lousy practice and inconsistent with how floppies are treated - Mac likes to unmount disks explicitly, that's why when you drag a disk to the trash, the motor comes on for a moment before the disk actually ejects. That's why the apparent absence of an "eject media" command seems like such a glaring omission.

 

[mg.man]

that's why when you drag a disk to the trash, the motor comes on

Right. But you said earlier...

when told to eject it, it just unmounts

How are you "telling" it to eject? Dragging to Trash? If so, is there no activity at all over the interface? If not, why does it go through the unmount / mount? Does it unmount then check the "disk-in-place" flag - which is (still?) set, so just re-mounts?

 

[Tashtari]

How are you "telling" it to eject?

Either dragging to the trash or going to File...Eject. I'd have to set the test up again to make sure (it's been a while), but it does seem to check controller status after the eject, find that the disk-in-place flag is still set, and re-mount the drive. There is activity over the bus from the reads/writes done as part of unmounting the disk, but nothing that looked like an "eject" command. As such, the drive has no way to know that it's expected to do anything but report "yup, disk is still there."