Why the method of reading floppy-disk data-tracks, laid out in the past log-entry, is not de-facto...

Again, the normal methods for data-extraction are sector-by-sector. Even the "read track" command technically does-so on a sector-by-sector basis.

(In fact, now that I think about it, I think I could've just as easily used the "read-sector" command, with the trick laid-out in the previous log).

Why *not* extract the entirety of a track, with *all* its data, including CRC, sector-IDs, gaps, and more... and let the PC process it?

Well, here's something:

...the sector is finally terminated by another gap, GAP3, of 80 bytes of 4eh. This gap is designed to be long enough to allow for any variations in recording speed and thus avoid the inadvertent overwriting of the following sector.

That's apparently an extreme oversimplification...

Basically, before every section of information (not going to call it 'data', since that's confusable with the data section, and not going to call those sections 'sectors' similarly...). Between each section of information, be that section the "Sector ID", the "Data", or the "Track ID" sections, there's a "gap" followed by a bunch of "sync" bytes.

In other words, each of these sections of information is kinda like a barcode-label, the read/write head a bit like a barcode-reader. So, on a single track, on a single side of a floppy-disk, containing 10 sectors of user-data, it's somewhat like 21-ish pieces of sticky-backed paper, each with a printed-on bar-code.

They're most-likely *not* perfectly-aligned with each other, nor perfectly-spaced. And most-likely each bar-code scanner (human) will scan each barcode at a different rate, most-likely very different from that it was written-at. Thus, each barcode has its own syncing information. Likewise, each section of information on the diskette has its own syncing information.

So... treating it as "the trick" does... is a bit misleading. In fact, I've just been browsing the hex-dump of a single track and found that by the time the second sector is read, data comes through *completely* wrong.

The sync-bytes are supposed to be 0x00, and yet they appear as 0xff! The gap3 bytes are supposed to be 0x4e, yet they're coming through as 0x21!

(Wait, what?!)

OK, I could expect a certain amount of bit-shift... ... but 0x00 is *nothing* like 0xff, bit-shift-wise, right...? Nor is 0x21 a simple bit-shift away from 0x4e.

So now... I haven't analyzed it *completely*, but my thought, here, is that it's not actually shifted by a whole *bit* worth of data, but by *half* a bit as stored on the magnetic-media... Wherein it's necessary to look into MFM. Essentially, each data-bit on the magnetic-media is stored as *two* "bits" such that each data-bit contains a transition between 0 and 1. (or, maybe, North and South polarization?). The purpose being to allow the disk-controller to *sync* to the inherent "bit-clock" stored in those transitions.

But, of course, since I'm using "the trick" it did that syncing *long* ago, (512 data-bytes, + a bunch of other information/header-bytes), and kept that sync with every bit-transition thereafter, rather than trying to resynchronize with every "sync" section, as it would've if I'd've requested the read of each properly-sized *sector.*

So, for the *first* sector's worth of data everything's aligned properly... The syncing happened on its sector-header. But every "sync" and "gap" section, thereafter, could be *completely* misaligned... maybe a full-bit which would be easy to see, or maybe a half-bit as I think I've found, here... Maybe *several* bits/half-bits... Or, judging by that earlier-quote, it could even be misaligned by *several bytes*.

Further-still... who's to guarantee that each section is aligned at the magnetic-bit-level...? Maybe they're askew by 1/3 or 1/10th of a bit...?

I *think* what'd be seen, then, is a few bytes that don't make sense (after the end of one section and upon entry of the next)... and then after a little while the disk-controller's clock will have re-synced with the edges in the data-bits. BUT, again, there's nothing that forces that to be synced *in phase*, only *in frequency*. So, I think, it could be off by a "half-bit" after a few bytes' worth of settle-time.

....

Which means...

Essentially...

re-implementing quite a bit of the floppy-disk-controller's "syncing" system, now in software, and analyzing the data bit-wise, rather than byte-wise... and, plausibly, there being some data (even if stored/retained without-error) that will be interpretted in-error. Thankfully, that should only happen on the gap/sync bytes, right?

(And... all this assumes that the controller can [or attempts to] maintain sync with bit-edges in fields *other* than just the sync-pattern... which would be controller-specific, no?).