The truth is, there's quite a bit one could learn from the Catweasel. I'm
not particularly interested, however, since the REAL problem is inherently
solved with Tim's sample-buffer circuit, and would be completely solved,
i.e. write capable with just a bit more hardware and quite a bit of
software.
The CPLD's are so easy to use and so readily available, I'd say they're as
good as off-the-shelf stuff once the code is written and the circuit
published.
It would be QUITE easlistic to build a minimal FDC in the same PLD with the
buffer control/EPP interface circuitry, thereby allowing the circuit by
itself to operate the target drive in both read and write mode. This would
completely solve the problem of hard-sectored diskettes, by the way.
Please see remarks embedded below.
----- Original Message -----
From: Tim Mann <mann_at_pa.dec.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, July 04, 2000 6:51 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> 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.
>
Unless it's proven that the Catweasel does everything an expanded version of
Tim's sampler/buffer board potentially does, it's not a real solution.
>
> > 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.
>
it would be dirt-simple to make it work in the other direction, though the
accompanying software will not be so simple.
>
> 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.
>
I've found over the years that sampling at less than 16x seldom works out
for FDC interfaces. 14x isn't much below that, but that could account for
the eventual movement of bits. I wouldn't bet on that, however.
>
The clock used to generate precomp on the majority of the successful FDC
designs I perused back in the '80's used 12x the data rate as a bit clock.
They would shift an early bit about 166 ns early and a late one 166 ns late.
The ones I liked best back then used a presettable (e.g. LS161) counter,
always clocked with a free running 6 MHz clock. Qoutput bit 3 (Q3) was tied
to the enable, such that when it was LOW, the counter idled, but when it was
preset with a value >8, it would count. Terminal count out was the write
data output. Early led to a preset of 0x0E, nominal led to a 0x0D, and late
got a 0x0C. That made the thing into a clocked eqivalent of a one-shot.
Consequently, it's handy to have a 24x clock avalable so you can extract
both a 12x and an 8x clock from it. The 8x is for the sample rate, while
the 12x is for the write precomp. I don't see an advantage in using the odd
frequencies on the Catweasel, but there probably is one. I just don't see
it today.
>
> Tim Mann tim.mann_at_compaq.com http://www.tim-mann.org
> Compaq Computer Corporation, Systems Research Center, Palo Alto, CA
>
>
Received on Tue Jul 04 2000 - 21:14:45 BST