Wow; $192 for a 5.25" floppy disk drive

Ray Arachelian ray at
Sat Oct 21 05:44:41 CDT 2006

Jules Richardson wrote:
> 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.  Perhaps designing a new floppy controller
might be better?  One that can get the analog signal from the R/W head

You might even be able to use a normal floppy controller to drive the
head and motor, but duplicate the R/W head sensor from the floppy drive
to an add-on card with a sensitive and fast 8 or 16 bit A/D converter.

This way, only a quick, single pass over the floppy is needed, and you
don't have to worry about varying the motor speed.  If the r/w head is
sensitive enough, and  the A/D converter is fast enough, a single pass
should suffice.

Once the data is in RAM and then saved to hard disk, lots and lots of
analysis can be done in software regardless of its format.  Better yet,
it should just be compressed and transferred over to another machine for
analysis.  The analysis would take a lot longer, but can be done in a
batch.  (i.e. if you have lots and lots of floppies to go through, in
terms of human interaction time, you're better off scanning them in as
quickly as possible, and then letting the machine process them overnight.)

You'd probably want to scan half tracks as well as any extra tracks the
physical drive head is capable of reaching, if you suspect that the
disks are protected.

Such a setup would be able to handle anything you throw at it and would
even be able to recover data from damaged floppies.  Well, not
physically damaged floppies, but floppies where the sync marks or data
are too weak to resolve in normal cases.

More information about the cctalk mailing list