part of our floppy quest is we want to read mac 800k floppies – partially because there’s a lotta good content out there on 800k floppies, and partially because we are still heading towards imaging the prince floppy (which, being 800k formatted made it a bit of a pain to read).
1.4MB floppies on mac are easily readable because by the time they got to 1.4MB apple stopped being clever with their disk formatting. but 800K floppies are really clever/freaky!
unlike ibm pc formatting, there are not a fixed number of sectors per track. there’s four groupings of tracks, and there are MORE sectors on the outer tracks (tracks 0 thru 31) than on the innermost sectors (64 thru 79). that’s because there’s technically more surface area on the outer edges of the disc where the lower number tracks live.
mac floppies also rotate at different speeds depending on the track, which is also a joy. given its quite hard to find and control those old floppy drives compared to our bog-standard ‘shugart 34 pin’ pc types, there’s incentive to try to get these to read cleanly on cheap and available hardware. (apple superdrives are…not cheap. no not that superdrive, the OTHER one)
but the problem remains: the inner tracks have flux pulses that are significantly longer than the outermost tracks, because if we have a flux-per-inch limit, then we have to spend more time to traverse that distance on the inner tracks.
and ibm pc mfm-optimized drives do not like this: they really expect the flux to change on very specific timebases: about 2us, 3us and 4us -ish. and once you start reading those longer pulses they get into 10 or 11us and that is much longer than the drive and media expect.
firstly, the HD diskette isn’t really meant to encode such long pulses, and secondly the disk drive automatic gain control starts getting amped up after 5 or 6us and thinks it must have lost a pulse, so it ends up reading old/weak flux inversions and ‘splits’ the longer pulse into 2 or 3 ghost fragments. the flux decoder is getting extra bits where it ought not, and gives up.
we’re going to order some true DD diskettes to see if that helps with the first issue. for the second issue, we tried setting the DENSITY input low but that didn’t help – we’re thinking we could try to detect spurious pulses to try and repair the GCR cells during flux read. hopefully we’ll figure something out? – video.