Spent the last few days analysing the data from a particular sector I am having trouble reading. To setup the analysis I changed the PIC code to seek to track 159 (my problem track) and then captured a couple of rotations using Logic. Then I made a copy of the disc on the Amiga (which is able to read the track without problems) and then captured the MFM data in the same way.
Luckily the MFM decoder is able to find most sector heads on the problem disc so I had a fighting chance to put the two captures side by side. Since there is still a lot of data here I am concentrating on comparing just one sector.
Using Excel I put the data in side by side and put a formula in to look for mismatches. Very quickly I could see that on 4 occasions my decoder was misjuding the bit window widths. The good news at least was the number of flux transitions in both captures were the same.
A ‘textbook’ disc should have flux transitions at 4, 6 or 8us intervals so it was time to do some further analysis. The MFM decoder has been modified to show 1) what width the code is assuming and 2) the actual time elapsed since the last flux transition. Then using Excel we can analyse the drift. The first table shows the drift timing and the number of times it occured for the freshly copied disc:
| Drift (uS) | Count |
| -0.250 | 65 |
| -0.125 | 491 |
| 0.000 | 987 |
| 0.125 | 1063 |
| 0.250 | 643 |
| 0.375 | 44 |
From this we can see the timing is actually pretty consistent; there are a couple of times we are 375ns out but generally speaking we are no more than 250ns out. Bear in mind also that the capture is running at 8Mhz so 125ns is the resolution.
Now compare this with the sector I am having trouble reading:
| Drift (uS) | Count |
| -0.875 | 1 |
| -0.750 | 18 |
| -0.625 | 100 |
| -0.500 | 217 |
| -0.375 | 340 |
| -0.250 | 235 |
| -0.125 | 453 |
| 0.000 | 412 |
| 0.125 | 511 |
| 0.250 | 455 |
| 0.375 | 294 |
| 0.500 | 187 |
| 0.625 | 66 |
| 1.125 | 4 |
Yikes! Big difference. Straight away we can see there is a much larger range of drifts and the drifts are bigger. Most importantly we can see some are miles out, 4 over 1us out. Why? I don’t know – badly duplicated, age-related, perhaps a deliberate attempt by the manufacturer to put a signature on the disk for authenticity validation…?
Speculation aside my code is failing at the 4 points where the window is 1.125us out. The MFM decoder needs to be re-thought a little to tolerate this. I was surprised the original code works as well as it does because it’s working strictly on the edges of the flux changes rather than using a “sample window”.