I can't keep track of all the directions this discussion is going in, but here are a few bits of information that might be useful. My software for reading FM and MFM with the Catweasel is available from my Web pages, so you can look at the source code for details of what it does, adapt it to work with different hardware if you prefer to build your own, dissect it and note all its shortcomings, ignore it, or whatever. See www.tim-mann.org/trs80resources.html. There's also a link there to the Linux drivers for the card, which include some writing support and have a different implementation of reading (but which uses the same idea), so you can look at that source code too. The basic idea for reading is very simple. I have two thresholds, t1 and t2. Given a sample s, if s <= t1, I classify it as short (10); if t1 < s <= t2, as medium (100); if t2 < s, as long (1000). This lets me reconstruct the MFM clock/data bit stream. I set the thresholds statically, by looking at histograms of samples from various tracks of different disks, and placing the thresholds rougly in the middle of the valleys between the three observed peaks. This technique is crude (maybe it would be better to emulate a phase locked loop in software, for instance), but it works well for 3.5" and 5.25" disks, and some 8" disks too. I'll come back to the other 8" disks in a bit. When I said something about "bit-shifting" with the Catweasel, I was *not* talking about reading the same track repeatedly and getting different results. On what I was *not* talking about: I haven't done any systematic tests to see how much the sample data read from a track varies from one attempt to another. I do know that when I fail to decode some data (getting a CRC error), rereading the track sometimes helps. I would expect some variation from one read to the next because the magnetic signal on the disk doesn't really have sharp edges; the electronics inside the drive that decide where the flux transitions are going to produce somewhat different results from one try to the next. I would expect this is worse on old disks that are fading or where tiny bits of oxide are starting to flake off. On what I *was* talking about: There is a physical effect where two flux transitions that are recorded close together tend to move apart. An Intel FDC data sheet that I have calls this effect "bit-shifting", but I don't know whether that's a standard term or not. Write precompensation approximately corrects for this effect, but not exactly. On some 8" disks that I've read, I've seen severe cases of this effect, enough that I had to put a heuristic into my program to compensate for it. On at least a few disks, the effect increased up to track 43, backed way off at track 44, and then slowly increased again; this is consistent with the disk having been written in a system that turns on write precomp using the TG43 (track greater than 43) signal, but that doesn't have enough precomp. The size of the errors I've seen is much more than one Catweasel clock, so it doesn't have anything to do with the Catweasel sample rate beating against the data rate. So, what's the heuristic? It's quite crude and oversimplified too, but seems to work pretty well. The general idea is that if an interval is a bit off from what you were expecting it to be, multiply the error by some factor around 0.5 to 0.8 (you sometimes have to tune it for each disk if they are particularly bad), and add that to the next interval before classifying it as short, medium, or long. This helped immensely, making some disks that previously had a CRC error on about half the tracks even after many retries read perfectly, with no retries. Here is some code that should make it clearer: void mfm_decode(int sample) { static float adj = 0.0; int len; if (sample + adj <= mfmthresh1) { /* Short */ len = 2; } else if (sample + adj <= mfmthresh2) { /* Medium */ len = 3; } else { /* Long */ len = 4; } adj = (sample - (len/2.0 * mfmshort)) * postcomp; if (out_fmt == OUT_SAMPLES) printf("%d%c ", sample, "--sml"[len]); mfm_bit(1); while (--len) mfm_bit(0); } Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org Compaq Computer Corporation, Systems Research Center, Palo Alto, CA