Well let me know if you want to come down here for a shopping
trip/vacation. I can take you to a lot better places than Dismal World.
Joe
>>
You're on :-) I occasionally get down to Orlando..!
-Linc.
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
>Since soldering is so much more reliable, and just as fast once you get
>used to using the soldering iron, I don't see the point of said
>breadboards. But anyway...
I've been using these breadboards for about 20 years now and I still
like them for a lot of things. They certainly aren't good for all
possibilities, but I regularly do digital logic into the 50 MHz
range with them and have few problems.
Modern CMOS logic families seem to be a lot more forgiving for poor bypassing
and high-impedance power sources than good old-fashioned "straight" TTL.
In fact, just for fun, I've pulled out *all* the bypass capacitors around
a 40 MHz HC TTL circuit and found that it operated identically to before
the bypass capacitors were pulled. Compare this to old-fashioned
straight 7400-series logic where if I don't put bypass capacitors everywhere
all the flip flops randomly choose a new state every time the clock
ticks!
On the subject of breadboarding with solder and wires: are there PC-boards
designed specifically for "place-and-tack" surface-mount prototyping?
I'm envisioning a power grid, a bunch of SOIC pads with small fanout,
a place for some surface-mount discrete parts, and maybe some way of putting
a header connector on the board. That'd be really useful. Sort of like
those through-hole prototyping PC boards that used to be popular.
Tim.
Let me interject a few notes about the Catweasel here. Quoting from Tim
Shoppa's original message:
> 1. The Catweasel uses some custom LSI parts, as far as I can figure out.
It uses a PLD. The 1996 version, which I have, uses a MACH 211. I'm not
sure what the new 2000 version uses; probably something similar. The PLD
equations aren't released, though, so knowing this doesn't tell you much.
> My circuit is much more "hackable", anyone with a TTL databook can figure
> out what it does and improve on it. Or you can build one yourself from
> scratch. (Other than the 128K*8 SRAM, all the other parts were literally
> purchased from the local electronics shop. Heck, most of the chips can
> be bought at Radio Shack!) Total cost for the chips in my buffer is
> about $30.00, about half of that in the SRAM chip.
I sympathize with that, but for those of us who are much better at software
than hardware, something off-the-shelf is a big plus. You can get a Catweasel
for $85 to $95 completely assembled.
> 2. The Catweasel uses a proprietary, largely undocumented programming
> interface. My circuitry is entirely open, and I think it's pretty easy
> to program. (My first hack at acquiring data with the new buffer was
> dashed off in about half an hour under QBASIC.)
You can now get the documentation for the programming interface just by
asking the designer (Jens Schoenfeld). He told me that it isn't secret
anymore. The document is in German, but I could provide a translation
if anyone needs it. (My German isn't that great, but the document is
so simple you can almost read it without knowing any German.) There is
also an open-source Linux driver, and the program I wrote for reading
FM and MFM disks to one of the TRS-80 emulator formats (cw2dmk) is also
open source.
> 3. The Catweasel requires a bus slot inside a PC-clone. My new buffer uses
> a much more general purpose parallel interface. So you can hook it up
> to a laptop, or even to something that isn't a PC-clone at all.
That's a real plus; on the other hand, if you do have a PC clone with an
ISA slot, it's more convenient having the board inside the computer than
hanging off the parallel port (especially if you're already using the parallel
port for something else).
> Those are what I see as advantages over the Catweasel. There are also
> some disadvantages:
>
> 4. You can't just go out and buy my buffer, but you can buy Catweasels
> off the shelf.
>
> 5. My buffer is strictly "read-only" as I use it. I think the Catweasel
> (and Compaticard) both allow writing.
Yes, the Catweasel allows writing. I haven't tried this yet, though.
Another point to note is that the Catweasel samples at 7 or 14 MHz (software
selectable). In reading some old 8" MFM disks, I found that there had
been a lot of bit-shifting over the years (or maybe there was not enough
write precomp applied to begin with), and I had to use an extra heuristic
to make them readable at all. I'm not sure that 4 MHz would have been
a high enough sample rate for these.
Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org
Compaq Computer Corporation, Systems Research Center, Palo Alto, CA
>One final point that perhaps Tim could answer. If he does provide a
>schematic, would he have any objections if somebody else created a CPLD
>(or FPGA, or..) version? Giving him full credit for the original idea, of
>course. Because if he doesn't mind, then the whole issue goes away. You
>can build whichever version suits you...
The entire idea of discussing my circuit here was to get some ideas
for improvements, *and* to make it clear that this was entirely an
"open" hardware design and a "non-secret" programming interface.
The circuit is hardly original enough for me to claim it to be my
idea, especially as other manufacturers have been making proprietary
interfaces that do the same thing for at least a decade. I wanted
to make the design public so that it will last for longer than your
typical PC-clone piece of hardware.
Tim.
> >It seems strange for the drive to look so otherwise perfect and
> >these items to be mush. Any thoughts?
>
> Storage conditions, especially atmospheric ozone. I spent 6 years
> living in LA, and the lifetime of my natural-rubber bike tires there
> was measured in months. Foam would either dry up and turn brittle
> or go the other way and turn gooey, typically within a couple of
> years of manufacture.
>
> Obviously temperature and exposure to UV light/direct sunlight are
> factors too.
Well, heat I'd buy, but other areas of the drive would have shown
the effects of sun, and the hub is inside, away from light.
I was wondering what storing the unit in the presence of unsealed
containers of petrochemicals might do... or even worse, whatever
a medical school (formaldehyde?) might have in storage...
-dq
Hey,
I have a friend who's interested in selling the following items, and he asked me to post this to the list. Reply to me if you're interested and I will put you in touch with him. -- MB
----------------------------------------
I looked at some of my junque and the only thing that
is all together is one 400K external drive. I found 1
128K board, 1 128K board upgraded to 512 and one later
128/512K board set up as 512K. I haven't looked at all
of the cases yet to see if I can make some 128's or
not. I found some old HD20 parts that may be for the
original, runs off the external drive port on a 512K
(fat Mac), using a floppy to start up and recognize
the hard drive. The only profile part is a controller
board (I think - if I am remembering right). It's all
in my basement. The three IBM PC Jr's are still in the
garage and haven't been run in years.
In a message dated 7/5/00 2:00:03 PM Eastern Daylight Time,
rigdonj(a)intellistar.net writes:
> Where are you?
>
> I know where there's a few located in central Florida.
>
> Joe
>
Eastern Pennsylvania.
-Linc.