On most of your points, I agree.
There's no reason to assume the Catweasel won't work for what's wanted here,
and it's possible I'm overemphasizing the harmonic series available with the
"right" crystal frequency, but the very fact that you've seen bit shift over
time in dealing with the same files suggests something's out of whack. The
fact is that, while a crystal frequency of a more or less precise harmonic
of the data has a good chance of "doing it" correctly the off-harmonic
timebase the Catweasel uses has no chance at all of generating a correctly
timed output under any circumstances. I don't know how important this is.
It's certainly not an issue for recovering the data.
There's no reason it can't read diskettes and it's software interpret the
sample data correctly, but it can't, under any circumstances generate the
correct timing on writes. This isn't due to the write precompensation, with
which it probably doesn't deal at all, but certainly could do closely
enough, depending on the drives, etc, but because of the frame-slip inherent
in alignment of a bitstream sampled at one rate but having to be resolved to
another. What concerns me is that in the Catweasel case, the data is
sampled at a rate that allows correct recovery of the data, but there's no
timebase for generating a correctly timed output bitstream. It does have
to be "close enough" though, since software can correct the stream to within
~70 ns per bit.
Crystal oscillators are specified to 100 ppm for commercial applications.
With that level of accuracy, a "slip" won't occur very often, and even more
seldom close together. OTOH, when the sample rate is at 14x the data rate,
a bit will slip into the adjacent window every 128 bits, worst case or 255
on the average, as compared with a crystal that's at a harmonic of the data
rate, to within 100 ppm, which will slip every 2e8 bits on the average.
Consequently, it's reasonable to believe that there's some software
compensation for this inherent asynchronism. Unfortunately, that suggests
that there is accomodation in the software for this built in problem.
Otherwise, I'd suggest simply changing the oscillator to 16 MHz to see
whether that mitigates the bit shift you've observed.
please see embedded comments below
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 10:46 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> > 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
>
> On reading, the Catweasel has a mode where the high order bit of each
> sample byte gives the state of the index/sector hole sensor. This should
> be great for reading hard sectored disks. On writing, you have to write
> a whole track at a time, but it should work OK to compute where the sector
> holes ought to be, construct a track of the right length, and write it
> out starting at the index hole.
>
You'd have to allow for mechanical variations here so the resulting diskette
would have proper timing with respect to the sector hole, but that could, in
fact, be achievable. I was thinking it might be a good application for a
ninth bit of memory in the buffer so you can adjust the data stream to fit
the occurrence of index/sector
>
> > 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.
>
> I don't see why not, but maybe I don't understand this point. Maybe
you're
> saying that 14.161 MHz isn't a high enough sample rate...? That seems
> unlikely to me.
>
It's absolutely adequate for sampling. I'm not sure it's corect for
writing, however.
>
> > 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.
>
> This sounds great. My suggestion is that the next step should be to work
> on defining the necessary data formats and writing the software, using
> the Catweasel (or Tim's board, for that matter) as the hardware base.
> It doesn't seem necessary to get bogged down in designing more hardware
> first.
>
Much of that work has already been done, I hope. There was considerable
discussion about it a couple of months back.
>
It would be nice, however, to know, not just guess, that the oscillator
frequency is correct and not just adequate, for both reading and writing.
>
> > The Catweasel may be a good model to keep in mind, but the comment about
> > bits moving around over time does give me pause.
>
> That comment had nothing to do with the Catweasel specifically. What
> I've observed is that when reading old 8" disks, some look as though they
> were written with way too little write-precompensation. I was speculating
> that there was enough precomp initially, but that the bits have moved
> over time. I might have been completely wrong about that; maybe there
> was not enough precomp initially, but the original data separator circuits
> were good enough to read the disks anyway. In any case, you'd see the
> same thing with Tim's board or any sampling-based hardware.
>
It's precisely the write precomp and the resulting bit-shift, or, rather,
lack of it, that concerns me here. In theory, 14 MHz should be adquate for
sampling analog data, the highest frequency component of which is 7 MHz.
However, the data that's sampled passes through shaping circuits which mask
the actual events at the media/head boundary.
>
> > 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.
>
> They are exactly the same *hardware* approach, except that the Catweasel
> has an ISA interface and Tim's has a parallel port interface. The
*software*
> that comes with the Catweasel is not the software you're proposing, but
> that software hasn't been written yet for Tim's board either. If it looks
> like a duck and quacks like a duck, we can make duck soup from it even
> if the person who raised it was more interested in duck eggs.
>
Clearly, since the Catweasel has an ISA interface, it will work for those
who have a free ISA slot, but it's of limited usefulness to folks who don't
use ISA. Further, the two approaches, though similar, are not identical,
due to the asynchronism between nominal oscillators. Tim was taking into
consideration the fact that many folks in this forum don't use
ISA-compatible computers, yet would like to be able to read/write foreign
diskettes. Of those, perhaps 10% want to build hardware. If the Catweasel
offers a solution, I'm all for using it, but there are unknowns, and a
significant share of the ones who do build hardware do it so they'll KNOW
what they've got, and won't have to guess what it does. A trial run with a
16 MHz oscillator in place of the 14 MHz might be a solution, though it
might require a close look at the code to defeat whatever is done to adjust
for the asynchronism of the rates, if necessary. It may turn out that it
works just fine with that alteration. Building an ISA port isn't terribly
complicated, but it's bit more of a job than making/using a parallel port.
Since the job of hooking up a CPLD and a RAM is pretty minor and almost
anyone who's paying attention, even those who have never built hardware
before, can hand-wire one in a couple of hours and program the CPLD with a
total investment of less than $20, (mitigating the risk, I'd say) I don't
think one should overlook that aspect. It's likely lots of code will have
to be written either way.
>
> 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 - 10:22:49 BST