You may be onto something, Tim, but I'd make one observation here. The
signal on pin2 of the 8" drive cable, though often driven with the 1793's
TG43 signal, does not turn write precomp on and off, but, rather, reduces
the write current to the heads. This reduces the amplitude of the signal
driving the heads, hence reduces the overall amplitude of the recovered
signal as well. That same signal is used to enable write precompensation on
some controllers, many of which use a less-than-ideal timebase to define the
precompensation offsets imposed on the data stream.
There are several possibilities in this case, namely that (1) there was no
consideration given to the write current or write precompensation timing,
(2) there was write precompensation but the controller didn't drive the RWC
line (pin 2), (3) the drive ignores pin 2 and counts tracks to control write
current (quite common on 8" drives) and (4) both effects are controlled
correctly at the controller. I cant tell you without taking time with it,
what effect each of these will have. Nevertheless, I'd say without any
hesitation that it won't be easy sifting through the sampled data to see
which condition causes what sort of shift.
Do you think you could take a stab at swapping the timebase on your
Catweasel board with a 32 MHz crystal? I think that would be VERY
illuminating, particularly where these precomp/write-current-related effects
are concerned, because phase noise introduced by the deviation of the
Catweasel timebase from a harmonic of the data rate adds confusion.
I may try to lay hands on one some day, but I have to say my interest in
that product is not great, though I do like to play with disk interfaces in
general. I'd be prone, some day, to look at your source code and use what I
can glean from that to support a different sampling arrangement that does
use the precise harmonic of the nominal data rate. Even that will take a
while, and, as you can see from all the traffic, there's quite a good deal
of interest in this item at the moment.
Dick
----- Original Message -----
From: Tim Mann <mann_at_pa.dec.com>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, July 05, 2000 4:17 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> 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_at_compaq.com http://www.tim-mann.org
> Compaq Computer Corporation, Systems Research Center, Palo Alto, CA
>
>
Received on Wed Jul 05 2000 - 18:25:20 BST