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 I can finally put this project (and my mind) to rest.

--------------

UPDATE: Therein lies a problem...

Once these bits've been masked, what then...? Sure, we can locate a potential match... Can search for a repeating pattern... But *reading* the bits, thereafter...?

Here's a prime example:

So, we're looking for 0x4e, and we found a match... And want to keep looking for the remaining 0x4e's until there's a non-match. (And, technically, the next non-match would ideally be 0x00).

Problem is, with the mask, shifted as-appropriate to find the 0x4e, decoding the masked-value looks like 0x00. Even though, again, the *non*-masked value actually contains 0x4e.

Oy.

------------------

This came up (again) because I keep seeing 0xe1's where there should be 0xa1's...

0xe1 is definitely *not* a shifted-equivalent of 0xa1, there's an extra transition in that one.