UPDATE: No, really this time! See the bottom... And more pondering on how to write the new disk...
I think I got 'em all, now...
There were a few questionables... some tracks that had multiple identical sectors... would make sense e.g. if those sectors were unwritten (after format). But, then... there're a few that're filled with 0xff, a few filled with 0x00, and a few filled with 0xea (or something similar).
These are a bit difficult to be *certain* are properly-IDed. But I think I verified it pretty well.
Negative sector-IDs indicate data was found *long after* the alleged sector-ID... so most-likely is data associated with a *different* sector-ID which wasn't readable with that search-method.
Sectors with allegedly 1024 bytes are most-likely wrongly-read Sector IDs (which is verifiable with the mismatched ID-CRC). So, then, the corresponding data-CRCs are prefixed with the location where a CRC-match was *actually* found. Thus, 0x27d39 indicates a data-CRC of 0x7d39, and an "N" value of 2. (N is a sector-ID mark indicating sector-size... (128<<N).. so 2 indicates 512 bytes.
Alright... The last column indicates individual sector-extractions which were done previously (now weeks, if not months, ago)... These only exist if the floppy-disk-controller reported no-error (in either ID-CRC nor Data-CRC). If their CRCs match that reported by *this* extraction-attempt, then they're marked "OK". If they were found, previously, but not with this attempt, then their CRCs are in that column.
... So... in this example... we've read a CRC-matched Sector ID indicating sector-zero, with a verified data-CRC of 0xda6e... That one's a bit questionable, as other sectors also have that data-CRC. BUT that data-CRC matches that of a sector which is filled with nothing but 0x00. So, it could be an empty-sector.
The only remaining questionable-bit is the fact that the ID-CRC is prefixed with 1.
That happens when a sector-ID is matched with that on-disk... BUT... the address-mark, which is usually 0xa1 0xa1 0xa1, was read as 0xe1 0xe1 0xe1. This *could* be a quarter-bit-shift issue... But, again, I haven't *fully* wrapped my head around that. But what that 1-prefix indicates is that the ID-CRC was calculated *assuming* 0xa1's, but the program read 0xe1's. Well, if the 0xe1's were in-error, then how are we to know the ID itself wasn't in-error, as well...?
So, some amount of uncertainty, but I did my best within my understanding to verify that it's *unlikely* I'm mistaken... I had to do similar with numerous missing-sectors, and most were much easier to discern (e.g. they had *different* matching CRCs than every other verified sector, so therefore *must* belong to the only missing sector... right?)
So... Now... I think it's time to actually *write* the new disk. I have no idea how to do that, yet.
Some things I'm still ignoring... sector-interleave... I'll probably write all the sectors in order, for now. It looks to me like they're *not* written that way on the original disk. They write them out-of-order so that they can be read-back as quickly-as-possible, while taking into account the facts of processing-time for each sector, and the amount of time it takes for the disk to spin around to the next sector. Clever, for the sake of speed-improvement, but not required (right?).
...I think that's it.
I might experiment with fudging some of the characteristics... E.G. there's a "gap-length" of only 16 bytes after the index-mark. And yet, there's 190 at the *end* of the track. And, if the thing I read before is true (that IBM-PC-compatible disk-controllers fail on sectors too close to the index-mark, which seems quite probable considering the *majority* of my missing sectors were sector-0...)... Then, why not throw, say, 90 of the 190 bytes from the end at the *beginning* instead? Of course, those 190 are based on the spindle-RPM at the time of write... So... who knows if that's a good idea. OTOH, I'm using the same *drive* in both the...
Read more »