Update: Therein lies a problem... at the bottom
I've this running idea that there's actually 4 potential "bit-shifts" for each data-bit. This is a bit funky because MFM-encoding uses *two* bits on the floppy-disk for every data-bit. So, then, half-bit shift makes sense... but quarter?
Well, I'm using the phrase "bit-shift" a bit loosely, here... but the idea remains the same: that for every *data* bit, there's actually four possible outcomes due to the bit-wise misalignment of sectors.
I wrote a thing on it, but it's a draft and I haven't the energy now to revise it... but here's an example:
Note the highlighted bit-patterns *don't* match. But they do, if you consider what I'm (poorly) calling "quarter-bit shift".
Briefly: the "?" pattern is the MFM-bit-pattern I *presume* to have been read from the floppy-disk (It's not possible to *see* the actual MFM bit-pattern; the floppy-disk-controller returns the *data bytes* it decoded from the MFM-pattern it saw passing under the head). It's the MFM-re-encoding of the data-bytes read by the floppy-controller.
But there are some key factors... The floppy-controller reads two MFM bits for every data-bit *that it returns*. So, e.g. if the floppy-disk-controller returned the byte 0x01, then there are certain things we do *know* about the MFM-bit-pattern it saw... We know, with some amount of certainty, that the very last two of the 16 MFM-bits must've been '01'. So, those two bits get 1's in the mask. And data-bits that are Zero have two representations in MFM, either '00' or '10'. So, we know, with some amount of certainty, that for every data-bit that the floppy-disk-controller returned as '0', it must've seen either of those two MFM-bit-patterns. So, I throw '01' in the mask, to indicate that the first MFM-bit is questionable, could be either 0 or 1, but the second bit is "known" to be 0.
Thus, in the highlighted example, the two patterns actually very-well could be the same, on-disk, despite the fact they differ in encoding.
And, that's a bit more confusing by the fact that in reality, the matching-pattern, if decoded from MFM clearly ends with a bit-value of 1 (the pattern ends in '01') while the pattern I'm searching for (0x4e) ends with a bit-value of 0 (the pattern ends with 'x0').
But, again, it's not that we're debating what the disk-controller reported. In fact, we're working *within* what the disk-controller reported... It clearly said the last databit it detected (MFM-encoded as the last two bits in that string) is '0' (originally-presumed to have been stored as '10' in MFM). When, in fact, it may very well have been that it detected an MFM-pattern corresponding to the data-bit value of '0', but that it read that '0'-bit from two consecutive encodings of two entirely different actual bits as stored-on-disk. WHEW.
Thus... I've just added this "mask" feature... and we'll see where it goes. It should *only* apply to half-bit-shifts. Though, also, there's a "missing clock" in certain bit-strings (between sectors) that would present itself similarly, so I think I can reuse this mask feature for those, as well.
Kinda surprising I had such good luck with the last go-round; managing to extract all but 8 of the (originally hundreds of) missing sectors.
I think the key-factor is that I requested a *really long* sector-size that allowed the disk to spin around multiple times. Thus, when the bit-shift of a particular sector was off, in the first cycle, by say a half-bit, it might be off by a full-bit by the next rotation, and be easier to detect.
So, here's hoping when I get this "quarter-bit-shift" thing functioning properly, hopefully soon, that it gets me the remaining sectors and...
Read more »