mfm_util --quiet 0 --format WD_1006 --sectors 17,0 --heads 8 --cylinders 320 --header_crc 0xffff,0x1021,16,0 --data_crc 0xffffffff,0x140a0445,32,6 --sector_length 512 --extracted_data_file xyz.img --transitions_file callan_raw1 >read.logAdding the "-quiet 0" switch makes it "unquiet" so it dumps all the tracks in hex format. This means you have to use an editor to dig through "read.log", but on my system with vim that is easy and fast (and generating the whole log only takes a few seconds).
The trick is in learning how to interpret it. The best start is the link above about "adding new formats". Also helpful is to look at the source code for wd_mfm_decoder.c as there is a big comment at the start of the file that describes a vast array of known formats.
Just for the record, the disk controller responsible for what I am working with is a multibus card. I have a hardware manual here that gives it several names:
Liberty Bay Computing, Winchester Disk Controller Model WDC-796-A Callan Winchester ControllerThe manual describes the format on page 2-1 as follows:
Index Gap 16 bytes 0x4E ID Sync 13 bytes 0x00 ID Mark 2 bytes A1, F8 ID Cylinder 1 byte (low order) ID Cylhi,hd 1 byte (head in low 3 bits, cyl in top 4 bits) ID CRC 2 bytes CRC remainder ID postamble 8 bytes 0x00 DF Sync 13 bytes 0x00 DF Mark 2 bytes A1, FE DF Data bps bytes (bps = 128, 256, or 512) DF ECC 4 bytes ECC remainder DF postamble x bytes 0x4E (x=15 for bps of 128,256; x=34 for bps=512) EOT filler xx bytes 0x4E to end of trackOne thing fishy about this -- where is the sector number?
I am trying to compare this with what I see on the dump from mfm_util that I get using "-quiet 0". I get the feeling it suppresses the runs of zero bytes and 0x4E.
Tom's Computer Info / [email protected]