Wow... managed to recover all but two sectors without getting the coding right for "quarter-bit-shift."

Of course, it seems at least one of the two remaining missing-sectors is definitely a quarter-bit-shift issue:

The floppy-disk controller read three 0xa0's where it should've read three 0xa1's (in the address-mark, before the user-data).

So, it seems I need to think about this more thoroughly after all.

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

In the image it looks like there's only one possible bit-alignment that could *possibly* have happened.

So, the question is, [how] could this have happened...? Note the highlighted '10'. Again, from the floppy-disk-controller all I know is that it read 0xa0a0, I don't *know* what the MFM-encoding was. And a data-bit = 0 can be represented as *either* '00' or '10' in the MFM-encoding. The *value* 0xa0 wasn't written to the floppy disk, 0xa1 was. So, that means it must've been encoded correctly *for 0xa1* when written to the disk. When reading-back, of course, there may be bit-shift due to misaligned sector-writes... I think I've over-explained this several times already.

The last time I tried coding this up, I got myself into some trouble... essentially I rewrote *every* 0-data-bit from the floppy-disk-controller with '00'. (via a mask). Then I masked-out *every* corresponding MFM-bit within the search-pattern (0xa1). The result...? 0xa1's representation in the above image, would've been 00 00 00 00 10 00 10 00

Well, shit, that pattern's *easy* to find... since 0's are all (now) represented as '00' in the string-to-be-searched. The result was, I guess, that it wasn't finding what it was looking for because it'd find it too early, then only match once, rather than the three times it's supposed to repeat. Right, so I need to be a bit more conservative with my pattern-masking...

And I've been trying to figure out how to do that for well over a week, now.

My head's just not in coding that up, for some reason.

But I can *see* the pattern, and I'm pretty certain that's exactly what's happened, in this case... So, maybe I can at least code-up a quick-fix to handle this one case.

............

And, again, I think why I managed to get away *without* handling quarter-bit-shift correctly for so many sectors probably has to do with each track's having been read multiple times as though it was a single sector. So bit-shift in the first pass would likely vary from bit-shift in the next. But not always. Apparently.

(Oh, and note that 0xa1 isn't actually a proper MFM encoding. There's a "missing clock bit" The sixth data-bit (0) *should* be represented as '10', but is intentionally-neglected in address-marks, *only*. If that wasn't the case it wouldn't match the 0xa0a0 pattern!).