RFC: Floppy reader/writer project (recovering UniPlus Unix for the Lisa)
classiccmp at philpem.me.uk
Sat Feb 16 16:15:35 CST 2008
Ray Arachelian wrote:
> Philip Pemberton wrote:
>> What you'd have to do is find the amplified signal, then bring it into
>> the range an A/D controller would accept, and digitise it. You'll
>> probably want at least 20 megasamples/second to get a good amount of
>> resolution out of the data, and for a revolution time of a second,
>> you're talking 20 megabytes of data per track (assuming you use an
>> 8-bit converter).
> Sounds like it might be a very useful thing to build. (I don't even
> have my hands on the disks at this point, he's resorting to using
> CopyIIMac right now, which hopefully will be able to read a bit past the
It may be a useful thing to build, but it probably isn't practical to build
it. If I had a drive that I had a schematic for, I might be a little less
> So such a setup would need a dedicated machine... at 20MB/track it would
> need something like 3.2GB for a whole floppy, maybe double that if we
> wanted to include half-tracks and extra tracks, and whatever custom
> software to try and clean up the signal.
I'd go for a Linux-based PC. Anything with about 512MB RAM should be able to
do analysis of one or two tracks at a time (plus multi-read averaging and
parameter testing); I'd shove at least a 300GB hard drive in there because
you'll need the space, and they're around the mid range these days so not
Heck, even a laptop could probably do this... my IBM T42 is probably more than
enough. An ASUS Eee submini PC with a 16GB CF card could probably be pressed
into service as a data capture device -- so assuming the final reader box is
around 160x100mm in size (Eurocard), you're probably talking about something
with the dimensions of a large hardback book, excluding power supply.
I wouldn't object to hopping on a train to go image some discs with something
that small and light... $DEITY knows, if I had the last known copy of some
rare software package I wouldn't let it out of my sight...
> Sounds like a machine with a
> DSP would help speed up the post processing too. Ouch... Would still
> be worthwhile assuming that the media itself hasn't been physically worn
> off and just degraded... I guess something like this is what the data
> recovery guys use...
1) Open disc shutter (if 3" or 3.5")
2) Hold disc up to light and look through the aperture.
3) If you see any transparent spots, don't expect a perfect image. If you see
any transparent rings, give up now.
-- Most floppy discs have a Mylar disc with a magnetic coating -- the Mylar
substrate is usually transparent.
> I suppose you could also slow down the motor speed, as to increase
> resolution, but all of these would be pretty invasive drive mods.
> (you'd still need some way to precisely measure the distance traveled by
> the motor.)
Putting a tach on the motor would be fairly uninvasive. Avago (nee Agilent)
make some optical encoders (HEDB-9140 series) that come as a kit with a metal
codewheel (basically a disc with radial holes in it). You could probably glue
it onto the spindle motor flywheel without it causing much speed shift. That
gets you between 100 and 1024 counts (pulses) per revolution, which is more
than enough to measure instantaneous speed variation.
It's an idea. Maybe not a good one, but an idea nonetheless.
Now I'm off to figure out how to buffer the SDRAM enough that the regular
refresh cycles won't affect it... I'm thinking some of the FPGA's block RAM
might be pressed into service as a dual FIFO, and that the SDRAM could be run
at 2*Fmaster_clk to keep said FIFOs near empty unless the SDRAM was refreshing.
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
More information about the cctalk