This approach to reading and interpreting data recorded on a floppy is very
sound, though it might be a bit tricky to interpret. It will almost surely
guarantee that you can duplicate the diskette, and quite precisely.
However, to that end, if 8" diskettes are on your list of targets, you
should oversample 16x so that you can deal in a fairly standard way with the
write precompensation. You won't see it on reads, hopefully, but you
definitely will want to generate appropriate offsets for writing when you
set about to duplicate a diskette.
For quite some time I've tried to persuade Eric Smith, who's quite
knowledgable about programming the SCENIX SX processor, to write some
firmware that would create, functionally, a FDC chip out of one of these
ultra-fast single-chippers. The sampling and passing to an external micro
for buffering would have to be done by the SX, but since it would function
as a FDC, it could get away with relying on an outside master controller to
take the sampled data and store it in memory. Data would then be processed
to reduce its size prior to archival and would also require pre-write
processing to expand it to its 16x or perhaps even 32x oversampled format to
generate adequate sufficiently fine resolution for proper
write-precompensation.
Back when the discussion was about archiving old floppy disk contents,
there was considerable discussion how to read and replicate existing FD's.
At that time I suggested the methodology in which I have the most
confidence, i.e. oversampling at a rate compatible with normal write precomp
and subsequently reducing the sample resolution with software. The fact is
that it's not difficult to sample and store the signal from the FDD.
Interpreting it in light of the modulation, data format, data rate, etc, is
quite involved, but certainly achievable, though someone has to undertake to
write the code with which to accomplish this. Having the entire diskette
sampled as has been suggested, a track at a time means that one's computer
can, at its own pace, reduce, interpret, reformat, etc, the data prior to
writing it to a duplicate. The reformatting of the data into its original
format offers the advantage of phase coherency between sectors so the PLL on
the controller doesn't have to shift phase between sectors. That will make
the job easy in a case where the PLL has, over time, drifted off its nominal
data rate.
More importantly, however, the data can be reclaimed and error-corrections
made, that are not possible with the FDC.
Sampling circuits are quite straighforward and don't need much software to
operate them, particularly if they're put in parallel with the FDC. The FDC
can be used to direct the headload and seek operations and, in fact, the FDC
can tell whether a given sector was recovered correctly, thereby lending
confidence to the notion that the data sampled in that particular pass was
completely readable.
There are, IIRC, 10416 byte-times, nominally in an 8" FD track at MFM. at
16x ovrsampling, that's a fair amount of data. While there are a number of
256Kx8 SRAMS out there, they're not likely to be lying in the corner unused.
I recommend, therefore that such a circuit be devised with DRAMS. Those are
available on one of those PC-video cards in the bottom drawer, that you
don't use any longer. I doubt it will take any longer than 30 minutes to
design an adequate sampling circuit readable from a PC's parallel port in
EPP mode. In about a week, I may have time to do that and build it up. If
somebody's got the time an is willing to take on the coding burden to
prove/disprove this notion, I'd be willing to fabricate the circuit and send
it to whoever is willing to do the coding.
Dick
----- Original Message -----
From: <CLASSICCMP_at_trailing-edge.com>
To: <CLASSICCMP_at_classiccmp.org>
Sent: Tuesday, July 04, 2000 7:03 AM
Subject: Tim's own version of the Catweasel/Compaticard/whatever
> Hi folks -
>
> The topic of reading or writing older "odd" disk formats
> (hard-sectored, GCR, whatever) comes up here pretty often. And often
> the discussion leads towards the Catweasel floppy interface (currently
> available commercially, as I understand) or the Compaticard interfaces
> (not currently being manufactured, as I understand).
>
> I've recently "modernized" my foreign format disk reading
> hardware. The idea of both the "old" version and the "new" versions
> are very similar to each other, and to what other tools like the
> Catweasel and the Compaticard do:
>
> Data from a floppy disk drive comes as a series of pulses on
> the read data line. All these circuits (using different means) buffer
> up to an entire track of data in RAM, and then allow a user program to
> look at the buffer and analyze the data on its own terms. They also
> allow control over rudimentary floppy functions such as step in/out,
> load head/start motor, etc.
>
> *I* buffer the pulses on the read data line by simply recording
> a "1" bit if there was a pulse in a window, and a "0" if there wasn't.
> I sample at 4MHz, meaning that a complete revolution of a floppy
> requires most a megabit of RAM. I also buffer information such as
> index pulse data (essential for decoding many hard-sectored floppy
formats.)
>
> The bit rate from most standard floppy formats is roughly 500 kHz, meaning
> my 4 MHz sample rate oversamples by a factor of 8 or so. Yes, it's
overkill
> for many applications, but I want to be sure that all information on the
> floppy is faithfully represented in the buffer. Besides, many GCR and
> some MFM variants use half- or even third-fundamental-frequency components
> (sliding the pulse in the window to encode more data without increasing
> the clock rate) and oversampling is necessary for these formats.
>
> Other buffers (I believe the Catweasel
> falls in this category) record the times between successive pulses in
> RAM, instead of the "raw bits".
>
> My "previous generation" buffer had a megabit of SRAM and
> interfaced via a 16-bit-in and 16-bit-out parallel interface (usually
> to a DR11-style interface on a PDP-11). The megabit of SRAM was made
> up of a whole bunch of 2k*8 SRAMS, meaning that just the buffer memory
> required a couple of sizable PC boards. (If you're familiar with the
> technology, you'll get the idea that "previous generation" buffer was
> based on chips readily available around 15 years ago.)
>
> My "new generation" buffer has the same megabit of SRAM - but
> now in a single SRAM chip - and interfaces via a PC-clone bidirectional
> parallel port. Other than the big SRAM chip, the rest of the buffer is
> just eleven SSI and MSI HCTTL IC's. The eleven chips form the PC-side
> interface, the floppy-side interface, the timing clocks, the buffer
> sequencer, and the buffer address (17 bits) counters.
>
> So how is my buffer different than, for example, the Catweasel?
>
> 1. The Catweasel uses some custom LSI parts, as far as I can figure out.
> 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.
>
> 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.)
>
> 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.
>
> 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.
>
> Would it be worth writing up my new floppy disk data buffer so that
> others could improve on it? Would anyone be interested in unstuffed
and/or
> stuffed PCB's? Should I give it a name? (The "Timweasel", anyone? I
> gotta think of a better name!)
>
> --
> Tim Shoppa Email: shoppa_at_trailing-edge.com
> Trailing Edge Technology WWW: http://www.trailing-edge.com/
> 7328 Bradley Blvd Voice: 301-767-5917
> Bethesda, MD, USA 20817 Fax: 301-767-5927
>
>
Received on Tue Jul 04 2000 - 11:48:17 BST