Thread by @TubeTimeUS

picked up this absolute beast of a hard drive. this is the Maxtor XT-2190! it stores 160MB when formatted. this was huge for 1987.

it's got 4 defects. they give you those numbers on the label because you have to manually enter them when you low-level format it!

I'm not sure it's working because the drive's logic board isn't screwed down. and it's missing the insulating spacer so it can just short out against the metal case 😐

also this cap is hanging on by only a single wire

fortunately that's easy to fix.

oh wow it spins up! 🔊🔊🔊 for this one

i like the two tones it makes after it comes up to speed. the noise is made by the voice coil head actuator.

you can tell this is a fancy 🧐expensive drive because it doesn't use a lowbrow stepper motor for the head actuator.

unfortunately, none of my MFM controllers are compatible with it!

you see, in the old days before IDE, hard drives just output the raw data coming straight off the heads. the interface was very similar to that of a floppy drive. track step, head select, mfm read/write.

the drive had no (or limited) intelligence, and the interface had no way to communicate any metadata! the controller card had manual jumpers for setting that.

so if your controller didn't have exactly the right entry in its drive table you were SOL unless you were willing to accept reduced capacity.

or if you had one of these, you could dump the controller's ROM and patch it to modify an existing entry in the drive table. then burn an EPROM and swap it out on the board.

and sure i could do that. but i'm also curious about whatever data was stored on the drive. but that leads to a second problem.

controller cards used different low-level formats! remember that the MFM interface to the actual hard drive itself only provides the raw phase transitions from the disk itself. the sector format was up for grabs, and there were multiple competing formats.

so i could hack the ROM of one of these cards for the correct drive geometry, hook up the drive, aaaaand get garbage because the controller chip doesn't understand the sector format.

of course, i also have a Saleae logic analyzer. so i could digitize a raw track and try to figure out the sector format myself, if i really wanted to.

hacked up some cables

there be data here!

lots of pulses. top signal is the index pulse. bottom is the data.

horizontal axis is in nanoseconds. this is the distribution of the pulse widths. maybe from this i can figure out the code used.

so the pulse widths seem to be 200ns, 266, 333, and 400. the basic cell width is therefore 66ns. that means that this code generates transitions that are 3, 4, 5, or 6 codes. (a few are 7 codes but i think this is an invalid code that demarks the sectors)

ok i'm wrong, the 7 code one is correct but the data sequence for that is just less common.

i'm counting the number of zeros between ones to get the number of cells. a '1' represents a transition so i just ignore them because they're already implied in my data. max number is 7 (0011 0011 encodes to 0000100000001000)

so yeah pretty sure this is RLL(2,7)

wrote a crappy RLL(2,7) decoder and this is a sample of the binary data that i can see. could this be a sector header followed by data? of course there might be stupid bugs in the decoder...

it's easier to look at as an image. there are off-by-one errors due to the way my decoder handles errors.

a good trick is to try to load the raw data into GIMP, adjusting the width of the image to look for alignments. this thing appears to have 26 sectors on a single track, which lines up with the common value used for RLL.

in general track formats look like: index mark followed by 26 sectors.
each sector has a preamble (short period bit pattern to sync up the PLL) followed by a sync word(often with a pattern that "breaks" the MFM/RLL code), then sector metadata, then the data, and finally the CRC.

i can't find out what the common RLL 2,7 address marks/sync words are. all i can find is this cryptic description from a badly translated patent

fixed a bug in the decoder, and now i see this

the gap between sectors seems to be filled with this pattern: 1000100010001...

depending on your starting alignment, this can decode to a long string of '11111111111...' or '1010101010101...'

so two nearby sectors look like this. i think the highlighted bits are the sector header. the actual sector data itself seems to be the same for both sectors. the sector header should contain the sector number, track number, and head number

this seems to be an easier way to look at the raw RLL data. each number represents the number of zeros in between the ones. the start of a sector header seems to be 3333423333.

possible sector headers.

shortened the sync a bit and noticed some repetition (since the logic analyzer captured a bit more than a single rotation of the disk.) there appear to be 27 of these. this corresponds with 26 RLL data sectors and an index mark.

if i stare at this long enough, i'll start seeing patterns. i think the sectors are interleaved but the rightmost field could be the sector number.

got a bit more decoded by reading data from several different heads. last 16 bits are probably the header CRC. next, i need to figure out the cylinder/track number. since the drive has 1224 of these i'll need at least an 11 bit field.

ok made some great progress by reading multiple tracks. track# is a 9 bit field but the bits are inverted. track# also uses two LSBs of the A4 address mark.

wrote some crappy python to decode the sector header. the index mark uses flag 4 and sector 13. sectors are marked 1-25, with the 26th named 30, for some reason.

lets look at the first sector on the disk. it almost looks like real data, but something's not right.

i mean it *looks* kinda like an MBR. first half has the bootloader code, second half has the partition table. but it doesn't end with 55 AA.

time to break out the Gesswein MFM reader/emulator. I know this drive isn't MFM but at least it can capture the raw flux transitions.

I'm borrowing this reader/emulator but turns out it is super handy so I think I'll have to get one of my own. already have a few BeagleBone Black devices kicking around.