RFC: Floppy reader/writer project (recovering UniPlus Unix for the Lisa)

[Philip Pemberton]

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 
> errors.)

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 
pessimistic :)

> 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 
tremendously expensive.

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.