04.30.08
Posted in Amiga Floppy at 2:45 pm by Administrator
Someone on sci.electronics.design mentioned the following article:
http://www.nalanda.nitc.ac.in/industry/appnotes/Natsemi/AN-505.pdf
This is a Floppy Disk Data Separator Design Guide for DP8473 which is a floppy disk controller like the infamous NEC 765 controller. It’s a little heavy on the math end, but overall it discusses many of the issues that I first fought with when first coming up with how to design the whole PLL clock and data recovery mechanism.
I really want to revisit the way I read data to make things more reliable. There are a certain class of disks which are unreadable by my project, but work fine in a normal Amiga. I don’t know how or why or which ones. Not yet. Sometimes mass-produced floppies don’t work. I’ve had problems with HD disks, although using a TEAC drive helped.
I think it’s related to the read speed or the write speed.
This article covers “performance measures” and while it uses a bunch of fairly proprietary and expensive/complicated test equipment, I’d like to come up with some type of metric to say, “I’m working at 95% of best case, or 90% of best case” or whatever.
My end goal is to have something that works BETTER than the Amiga…….. and I think it’s reachable…..plus add in my error correction stuff and I’m sure I’ll get past it. But I’m not there yet, and so it’s time to figure out why not and how to fix it.
Permalink
04.28.08
Posted in Amiga Floppy at 11:06 am by Administrator
You know, I always hate the “first day back” working on a project. Things always seem to get screwed up between the time I last worked on a project, and that day. Even if nothing has changed. Or so I say.
I came back and starting getting a lot of “SYNC errors.” A sync error occurs whenever the software thinks it’s reading track #20, and for whatever reason the drive is giving data for track #21 — or some different track.
That was this time’s problem. I really don’t know what changed or what affected it, but I decided to slow the thing down a little bit, and that seemed to solve the problem. Right now 50ms seems to fix it, but I’ll lower that, and more importantly dig a little deeper to see if I can figure out why the heck I need that.
50ms doesn’t seem like a long time, but I really don’t like it after I spent so much optimizing this thing to be as fast as possible. I was trying to go back in time with the software, to see if maybe something like my updated receive UART code was screwing things up, but it didn’t help much……
Permalink
04.02.08
Posted in Amiga Floppy at 10:28 am by Administrator
While I have yet to actually implement the full-scale error correction as I want to, I did some manual tests today.
I basically took a track that I was erroring out on, and swapped in 1-bit away values for the bad bytes. In some cases, it appeared to fix the problem.
There’s alot more work to be done on this, but I think it will pay off.
Permalink
03.17.08
Posted in Amiga Floppy at 12:55 am by Administrator
I’ve been thinking for quite some time about error correction. About using the structure of the MFM to our advantage. I’ve come up with something although I haven’t implemented the idea yet.
As you know from my many references to it, http://www.techtravels.org/amiga/amigablog/?p=62 , this post shows the 32 possible byte combinations from legal raw MFM.
I’ve run some numbers today. First, there are illegal values, and then you have illegal PAIRS of MFM bytes. For instance, while 0xAA is valid by itself, and 0×11 is valid by itself, 0xAA11 is illegal, because the combination of those would produce 4 consecutive zeros, and as we know, this is illegal. Just like 0×55 is legal and 0×88 is legal, but 0×5588 is illegal because that would produce back-to-back 1’s, also illegal.
So as far as PAIRS go, roughly 1/3 of the total possible pairs (32*32=1024), are illegal. That works out to be 341 pairs or so. I was always interested in the percentage of bad pairs so we could use that info to detect bad bits/bytes.
So here’s my logic:
We need to know the data is bad, and that we fixed the data once we’ve attempted some error correction stuff. The checksum works fine here. The checksum uses XOR, and while its not perfect, it provides us with a decent check.
Next, we need to know which bytes are bad so we know which ones to fix. This is also easy. Because we know which raw values are ok, we can simply check the bytes against a table (when the checksum fails), and then we know roughly which ones are bad. The byte before or after might be screwy, but we have the general location.
So now that we know which bytes need fixed, we need to figure out what the correct values for the bytes would be. Enter hamming distance. If you don’t know what that is, look here. Long and short of it is that it provides a measurement of how many bits need flipped/changed to go from one byte to another. In our case, it tells us that if we have a single-bit error (and this we have to guess on), and we give it the bad byte, it will tell us which LEGAL mfm bytes the byte could have been. I wrote a small c program today that calculates the hamming distance between BAD BYTES, and legal mfm bytes. Note this produced ~7200 lines of results.
So then what, we now have a small subset of guesses to make at the byte value. Now, if there is just one bad byte, then its easy enough to swap in some choices, and then re-checksum the track to see if that fixes it. If there are multiple values, this becomes much harder for me to wrap my head around programmatically wise. I think the problem wreaks of recursion, which I’ve never been very good at. I need to test all the possible (or probable) values in each of the appropriate locations. This is not simple iteration, as far as I know.
So here’s some examples: (these are in decimal,not my normal hex)
Let’s say our bad byte is DEC 83. Once again, this is illegal because of the “3″ ended in binary 11.
So, the output from my program tells me that a single-bit error could have cause an 81 to look like an 83, that means bit 2 in that byte got mangled from a 0 to a 1.
But it could been an 82 as well. So bit 1 might have been set, when it should have been cleared.
But that’s it. Assuming that we just had a single-bit error, then those are the only two possibilities. I think single-bit errors are the most common, but I’ll need to work on this.
OK, so now let’s look at 2-bit errors in the same byte. If bad byte is still 83, then 17, 18, and 85 are possible choices.
What I’m really doing is intelligently narrowing the search space to valid possible choices. And then, I could apply the PAIR logic from above, and potentially eliminate more of the choices.
I think it might make sense to check upwards of 3-bad bits of error…… After that it seems like maybe brute force might just be better/simpler…..
While this stuff is nice, if we have a byte get mangled in such a way that it produces another legal different raw mfm byte, then it might be impossible to check. I can still apply my pair-logic to it which might help identify which byte is the problem byte.
Definitely different and excited stuff. I’ve never seen this idea used before, at least not in the amiga floppy world.
Permalink
03.01.08
Posted in Amiga Floppy at 4:33 pm by Administrator
While my send UART code has been pretty solid for some time, I’ve always though my receive uart code needed doublechecked and worked on.
I spent some time today just going through the code, graphing out some timing diagrams, checking my cycle-counts and so forth. The RX uart code is actually pretty good. There is some minor jitter in detecting when the startbit actually falls, but it is on the order of a couple cycles. Depending on exactly when the start bit happens, it can either take 2 cycles or 4 cycles. This is only a difference 40ns, and I’m not horribly worried about it.
I still want to do some type of stress test on it because I don’t want this to be a source of problems if I ever decide to implement writing as a feature.
Permalink
