21 Oct
2006
21 Oct
'06
5:16 p.m.
Ray Arachelian <ray at arachelian.com> wrote:
Jules Richardson wrote:
In the 90's I did some business reading various-format hard-sectored
5.25" and 8" floppies.
The drives were perfectly standard drives.
The "controller" was a 286-clone (I think I spent $25 for it in the
early 90's, it was hopelessly slow and out-of-date even then) interfaced
by parallel port to a circuit that would read the transitions off the
floppy along with the sector holes for a few revolutions, and store
the timing information in a SRAM chip. Overall it was the SRAM chip
and a dozen chips of TTL on a breadboard, with a ribbon cable to the
PC-clone.
This kludge could read each floppy and store the raw transitions
to a file on the hard drive in under a minute. Yes, that's a lot
longer than optimal but the transfer software was literally something
I threw together in GWBASIC. It is almost true that it takes longer
to write an E-mail of this length than it takes to throw together the
circuit on a protoboard and write the aquisition software :-).
I toyed with the idea of optimizing the software by doing it in
assembler instead of slow GWBASIC, but even for the several hundred
floppies I had to do, I knew I could just chug through all the floppies
in far less time than it would take to round up an assembler and the
concentration to make it work!
So the "reasonably fast PC" and "generously sized hard drive" is
basically a 286 clone rescued from the trash in the 90's along with
its built-in 10MB IDE drive :-).
Tim.
Sure - I wouldn't want that either, I'd
expect the motor to only be
run during each track read, though. Whether starting and stopping the
motor n times to read a disk is a good idea or not I don't know - it's
more stress on the drive for sure, but whether it's sufficiently more
to warrant not doing it I don't know.
What's the worst-case floppy rotation speed - 300rpm? So five
revolutions per second. Fastest transfer rate is 1Mbps (although
didn't some PS/2 systems manage two?) which in theory gives a maximum
of 200Kbits for a track. But with 8x oversampling that'll be 200KB of
data for a single sampled track read. So roughly 18 seconds per track,
given the port speeds you mentioned above.
That's slooooow. Given the nature of the data though, it'd probably
compress (using something like LZW) reasonably well - but then if
driven by an old 8bit CPU it may be that any compression (or
decompression for write transfers) uses up any time saved at the
transfer stage.
Sounds to me like the computer driving this needs to be reasonably fast,
and needs to have lots of RAM and perhaps even a generously sized hard
drive for post-read analysis.