keithOK, I’ve applied the “double 1’s” fix that I talked about earlier today.
This definitely helped things. I think my results are quite possibly the best I’ve seen them yet.
Now, my SX enforces both the back-to-back one MFM rule, and the no-more-than-3-consecutive-zeros rule. So despite what the drive puts out, the SX only sends back compliant MFM.
I think I was detecting the same transition twice somehow. While I’m not super happy about the way I’ve gone about fixing it, this patch seems to have worked.
I can still read the all 0xFF’s and all 0x00’s disk ok, so at least I haven’t gone backwards.
I sometimes get mixed results no matter the disk. Sometimes when I read the track I get certain sectors right, for example maybe 1-7 but no 8,9,10. Other times I get 8,9,10 right, along with 1-5, but then 6 and 7 are corrupt. It’s very wierd. And remember I’m reading exactly the same spot on the disk. So depending on the, I don’t know, order of the data, changes the validity of it????
Also, I’m running into exactly the same problem in some cases I had before. While the data looks PERFECT, the checksum isn’t coming out correctly in all cases. Header checksum matches. Data checksum does not, but the data is fine.
Maybe my data checksum in the header is getting corrupted? So that’s why it doesn’t match?
I thought for a half-second about just making multiple passes over the data, get the good sectors from each of the batches until I have all 11. 🙂
Im getting closer…………………..
I must confess that even after I’ve read thoroughly through both your explanations and ASM source I still don’t understand your algorythm 🙂 especially when you talk about 1-to-1 problem.
What if you just treat 1-to-1 as just 1, not 11?
Well that’s actually what I did. I added a quick two-line fix to the ISR. It basically says:
if we’ve seen an edge(a 1) AND we havent seen a following 0, then ignore any more edges until we’ve seen a “0”
so a 11111111111111111100 from the drive would read as 100.
but realistically I was getting only double ones. So I might get a 1100 for example, and now my new code writes just 100 to the FRAM.
No consecutive edges are stored.
As far as my algorithm goes, I don’t think its actually that complicated or confusing — and its small.
Maybe if I write it more concisely you’ll get it:
0. ISR can fire due to a 2us timer interrupt OR a falling edge on the READDATA lead from the floppy.
1. Regular 2us interrupts trigger my ISR routine.
2. The ISR does NOTHING until it sees a falling edge.
3. The ISR records a “1” for the falling edge in the fram. Consecutive ones are not written.
4. Every 2us period AFTER that falling edge, a “0” is written by the regular 2us timer. Up to 3 consecutive “0”s until my ISR goes into idle mode and we start over looking for a new edge.
That’s it. I keep track of whether we’ve seen an edge in the “seenedge” variable, and validhigh records the number of “0”s we’ve seen. We use these variables to keep track of the maximum allowed numbers.