A couple days ago, whenever I got ahold of floppy.c, I wrote a quickie code stub that utilizes floppySectorMfmDecode from floppy.c of fellow (http://fellow.sourceforge.net). Note you must use the mirrors to actually download anything….
This MFM decoder from fellow.c is pretty clear. AFR is located here See http://www.techtravels.org/wp-content/uploads/pefiles/afr10f.zip for the local copy.
Anyways, I used mainly the data-portion of the decoder, which was putting out junk for my input from the SX/amiga drive. So I sort of put it on the back burner.
Then I realized that since it decodes the header, this might be a GREAT check for SOME data validity. Some of the header fields are MFM-encoded separately from each other, and from the actual data. What this means is that you need less good data to get a valid read. What sucks is that the actual data is spread out across 1024 bytes of MFM encoding, if the second half is screwed up you lose the even bits of your data. If the first half you lose the odd bits. This is because the clock bits take up the other ‘half’ of encoded data….
Here’s the results of that code stub:
(2372) Format: 255 Sector: 9 Track: 0 Sectors to end: 9
(5620) Format: 255 Sector: 1 Track: 0 Sectors to end: 6
(6700) Format: 170 Sector: 245 Track: 85 Sectors to end: 232 (not valid format)
(8811) Format: 170 Sector: 65 Track: 85 Sectors to end: 240 (not valid format)
(20645) Format: 84 Sector: 170 Track: 174 Sectors to end: 193 (not valid format)
(28232) Format: 255 Sector: 3 Track: 2 Sectors to end: 10
(35714) Format: 255 Sector: 10 Track: 2 Sectors to end: 82
(70992) Format: 170 Sector: 93 Track: 64 Sectors to end: 245 (not valid format)
(89788) Format: 255 Sector: 7 Track: 6 Sectors to end: 4
(98245) Format: 255 Sector: 1 Track: 7 Sectors to end: 3
The valid sectors have a format ID of 255, 0xFF, the other ones are simply corrupted data.
You can even tell they are invalid because the sector numbers, track numbers etc are out of range.
So what’s this mean? I gotta get to fine tuning my SX code that captures this data. I knew I wasn’t SUPER close because out of 100kb of code, I’m getting a lousy 10 sectors, where I should be getting much more.
For this, I really have to learn exactly how the RTCC functions in fine detail, because doing this correctly requires very good timing.