schlae/minnow-disk

Reading and analyzing IBM 23FD Minnow floppy disks

minnow-disk's Issues

Possibly 3830 sector format?

Hi Eric, what a cool project! I was messing around with the track 0 data, and I could not make it match with the 370/135 sector description int the IBM doc. If I read it correctly, each byte should immediately be followed by the next start bit (so startbit, 8xdatabit, parity bit, startbit) but the track data seems to have lots of extra 0 bits between bits. Also, lots and lots of parity errors.

Now, treating it as if it were 3830 format, so 1 sync bit at sector start, then a continuous stream of 258 bytes consisting of 8 x databit, + 1 paritybit, it all seems to line up, and no parity errors on track 0.

Having said that, all the other tracks do give lots of parity errors (though some of them are mostly error free). I find it hard to believe that track0 would have no parity errors by pure coincidence! So I am wondering, is there any chance the disk is actually 3830 format?

Peter

Sector bits visualized

I had a look at the data and it seems the first track is definitely different than the others.

This visualization is based on the Model 145 format - black/white are bits of a byte with start bit + 8 data + parity, and the gray areas are zero fillers - in a place that waits for the next start bit. As one can see:

• there is the CFDA on the first byte - a binary counter (and even its parity is correct for all 256 sectors, which I can not say for the remaining bytes - looks like very random, 25382/30177 pass/fail ratio)
• majority of commands looks like having a parameter that is also incrementing (on left)
• there are some glitches as few rows are completely shifted (may need to rework my FM decoder though)
• the first track may have a 9-bit framing that repeats in 5 words? the visual 45-bit pattern suggest such idea
• some sectors may be empty with a repeating pattern? or is that a fixed XOR encryption?
• some sectors do not trigger a start bit (suggest reading error? hard to image its intentionally blank when the header has similar data as others)

Was the data capture 100% good or could it be done better? (eg in analog way, at correct rpm, with more microsteps?) - only if one could tap the wire on a real machine while loading this.

The use of zero-filler bits to delay operations is possible, but rather unlikely, and imho the disc has a non-145 alike byte framing.