Timing problems still?

I think I’m still having timing related issues. I have RTCC overflowing every 1.8us which I *know* is less than the 2us bit cell(or less than half the bit cell, if you take it to be 4us), but this seems to be what I need to do in order to hit the center of the next bitcells. I think this is probably because it takes a little while to detect and process the edge transition, and by that time, I’m too far into the 1st cell to use a full 2us jump. I contemplated (and did in previous designs) use a smaller delay after the transition than after a non-transition. This does give the desired effect, so perhaps I’ll put that into play.

You know, sync isn’t actually too big of an issue, because the edge transitions are so frequent, that I’m never going more than 3 bitcells(ie 3 two-microsecond cells) in a row in a free-running mode. And since the data always starts with a transition, I don’t have to worry about getting out-of-sync. If I happen to lose a bit or two, besides the shifting-problem, my device will just wait and resync at the next bitcell.

I think I’m accurately capturing, finally, on the PC the exact stream coming out of the drive. This is good, but now it sort of brings me to the next phase of work on the PC trying to get the PC to massage the raw MFM data into actual data. This isn’t easy (for me) although I pretty much have all the actual documentation I need.

I’m still concerned I’m doing something wrong because the output I’m getting from the drive is very heavy in 0x55 and 0xAA’s. The AA’s might make sense because they are the first-half of the sync words(0xAAAA 0xAAAA 0x4489 0x4489) so that might make sense, but the 0x4489’s are nowhere to be found. 75% of some samples are 0x55 and 0xAA’s. This doesn’t sound right. I would expect a much wider character distribution.

I’ve been trying to use Marco’s code to do the MFM decoding, and although it compiled easily, I just don’t think it’s going to work ‘off the shelf’ like that.