No, I'm not even suggesting that the CatWeasel is ver close to what was
called for in the earlier discussion regarding an archival format for data
normally distributed or contained on FD's. What I was getting at was that,
while the CatWeasel seems to work OK for some things, and, in fact, quite a
few, it probably doesn't read/write hard sectored disks and it probably
doesn't allow minute adjustment sector-by-sector of the data on the diskette
in order to make the format and the data fields within it all
clock-coherent. It was my suggestion that the device be supported with
software to allow not only that data be extracted from the bitwise
oversampled data recorded as in Tim's buffer, but also that software be
generated to permit the data to be reduced, essentially, to just the data in
the data fields with some set of information (which was TBD when I last
looked) implying the nature of the format in which it was recorded.
Further, it was to be able to write the data into any known format,
including known formats not supported by the controller available to the
user.
My suggestion was that a good test would be to write an Apple][ diskette
using a PDP-8.
I've also suggested that a "perhaps even better" approach might be to
generate FDC code for the Scenix SX to do the job of several different and
increasingly scarce FDC chips. This would easily support the function I was
going on about earlier.
It's easy, of course, to wachs poetic about what things could or should be.
I've got a first-attempt at an EPP interfaced board down on the shelf in the
basement. It may, someday, have the abilities I've suggested, but I'm not
interested in making a large investment in time until I have convinced
myself that when the hardware's done, there will be a point in having built
it. Without adequate support software to interpret and regenerate the
bitstream recorded from a floppy drive, I'm not sure the hardware's worth
building. I did want to demonstrate interchangeability between 5-1;4"
diskettes written on my Apple-][ and my Ampro, for which I have the needed
hardware (if I can find my Apple . . .). I'm quite certain that will work,
though I don't know it's needed. OTOH, there are diskettes which are no
longer available or for which drives are such a maintenance headache it
would be easier to handle them with a different drive type, except the
system doesn't support them. That's where I was headed.
The Catweasel may be a good model to keep in mind, but the comment about
bits moving around over time does give me pause.
Have a look at my embedded remarks below, plz.
Dick
----- Original Message -----
From: Tim Mann <mann_at_pa.dec.com>
To: <classiccmp_at_classiccmp.org>
Cc: Richard Erlacher <richard_at_idcomm.com>
Sent: Tuesday, July 04, 2000 8:45 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> > 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.
>
> > 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.
>
I simply mean that the Catweasel and Tim's buffer/sampler board are two
shots at two different targets. There's little point in comparing them
unless the overlap more than they appear to do in the writing I've seen up
to now.
>
> My point was that the Catweasel hardware has identical capabilities to
> Tim's, plus the write capability that Tim hasn't added yet. I'm not sure
> what "proof" of this you're looking for. Working software? (Available,
> though more should be written to handle more formats.) The documentation
> for the programming interface? (Available.) A look at the schematic
> to convince yourself the design is correct? (Not available,
unfortunately,
> but I don't really see the need for it.)
>
Perhaps it has the capability, but as I said, it's after a different end.
We're not trying to replace FDC's here, but rather simply want to read,
save, and rewrite formats foreign to our systems with as little pain as
possible.
>
> > 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.
>
> The only reason for the odd clock rate is that it let the designer use
> a cheap and readily available 28.322 MHz crystal (divided by 2 or 4).
>
I guess that's as good a reason as any. 48 MHz oscillators are cheap and
available almost everywhere. Maybe those would serve in a similar device.
>
> 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 - 22:29:54 BST