UPDATE, years later:

Most of the early logs for this project are actually [wrongly] under #Improbable AVR -> 8088 substitution for PC/XT . I really thought *This* project was going to be a couple nights' endeavor at most, but it kept stringing me along for, apparently nearly a month[?!] before I finally gave it its own project page.

This is This Project's first log:

https://hackaday.io/project/18868-improbable-avr-8088-substitution-for-pcxt/log/53451-warm-fuzzy

And you can "Next log" from there for a while 'till it redirects here.

-----

Extracting the data from the floppy-disk has proven to be quite an ordeal.

The current status is that I'm extracting each *track* with a linux-system... It sounds easy, but due to what I assume to be corruption due to old-age, it's a bit more difficult than merely using 'dd'.

Out of 800 sectors, I've been unable to extract 34 of them using regular-ol' "read sector" techniques.

So, I've come across a trick, which, briefly, boils down to requesting a known-good sector, but telling the disk-controller that the sector-size is larger than it really is. If you tell it the sector-size is 16384 bytes, you'll wind-up extracting the entire track (a couple times) as though it's *data*. And, that includes information like sector-headers and CRCs, which is some handy information to have. (And can't be viewed via normal means).

BUT: This is more difficult than it sounds...

Each sector can be written and rewritten without modifying those around it. But one floppy drive may be slightly slower or slightly faster than another. Or the clock-generator might vary from one day to the next, or the disk itself may expand or contract, due to temperature changes... Or any number of different things... which result in... one sector's data is not *aligned* with the next.

So, there are "Gaps" between each sector which consist of nothing more than a repeated byte-pattern. A few bytes/bits in that pattern might get overwritten slightly with each new sector-write. But that shouldn't matter, because no *data* is stored there. But... again, we're left with the fact that the bits within one sector's "gap" may not be *aligned* with another's.

So, when the entire *track* is extracted via "the trick" mentioned earlier, the first sector will be viewable... but all those, thereafter, may contain an unknown bit-shift.

To make it more complicated, data isn't stored on the disk in regular ol' bits. It's stored using MFM "modified frequency-modulation" that basically amounts to two bits for every data-bit, storing the data *as well as* a clock-signal with each data-bit. And, to make it more complicated, each of those MFM-bits is determined by the previous.

Thus, the "bit-shift" seen in the extracted-track data isn't shifted by one or two *data* bits, it's shifted by one or two (or maybe dozens) of *MFM-bits*.

So, now... I've been learning about MFM.

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

Here's the "gap" between two sectors...

As you can see, the gap-bytes are supposed to be 0x4e, but what I'm seeing in my extracted-track data is 0x12.

(The 0x7a is the second/final CRC-byte from the previous sector's data-field. The 0xfe and 0x82 appear to be where the sector's gap was overwritten, possibly several times, and are otherwise unnecessary data. It's also possible these two read-back values don't match the waveform shown, at all; the clock may take some time to resynchronize when the MFM data from one section doesn't align with that of the next... Regardless, it appears to have "resynced" with the 0x12's thereafter, just not with the correct phase.)

So, to extract that sector from the track, I need to figure out that sector's MFM-bit-shift. Thankfully, since the gap-bytes are supposed to be 0x4e, and there are a lot of them, it should be just a matter of trying a bunch of combinations until that 0x12 turns into 0x4e, then use that combination (aka, here, "bit-shift") to read the remainder of the bytes from that sector. And, yahknow, computers are pretty good at trying out a bunch of different things until it works. So, once I've figured out how to code that up, it should be an automated-process to extract all the sectors from every track, and automatically compensating for the bit-shift. We'll see.

-----------

OLD NOTE, see update at the top for a better starting-point.

You can see more about my past-endeavors with this project over at: https://hackaday.io/project/18868-improbable-avr-8088-substitution-for-pcxt/log/54227-the-trick-analyzed... And the logs prior to that one, related to this project, go back probably a few weeks. Though all further updates on the matter will be under *this* project-page.