Help to read 5 1/4" floppy disks via Arduino?

OK, I've got my stack of 5 1/4" floppy disks that I want to see if they still work. Not that there's anything valuable on them, but it would be nice to rip them.

I've got my Arduino waiting for usage. And I'm trying to figure out where to get code.

http://pastebin.com/4MtRr7A5

OK, I don't have an LCD to hook it up to; is it important? Also, what desktop software would I need?

I have no idea. I just found that on Google.

Worst part about it? The code was submitted by a guest, so I can't track the guy down :(

Looks like the LCD prints debug information from what I can see at a quick glance, it will output raw serial data.

This could also help:
http://www.interfacebus.com/PC_Floppy_Drive_PinOut.html
http://dwellertech.blogspot.com.au/2...iga-disks.html

Can't seem to find a project to read them, mainly make the floppy drive make noise.

Well, he's got a Kryoflux reading the floppies, not an Arduino.

I wonder if that Arduino code is outputting a raw disk image over serial...?

Hmmm, half the connectors are ground. I've got more than 17 inputs on my Arduino. Tinker time methinks...

Hi =) I'm the guy who built the floppy autoloader in the blogspot post you linked.. Coincidentally, I'm also the same guy who uploaded that pastebin snippet =)

As for reading floppies with an arduino.. it's doable, but insane.. the code I posted is able to reliably retrieve the pulse widths of the written data, but the arduino only has enough ram to store about 64 widths.. a standard track on a 3.5" disk could have over 56000 widths to process.. I couldn't get the data out of the arduino fast enough without destroying the accurate timing of the data being read..

You can easily control motor on/off, step direction, and move the head, but to read & capture the data stream, you'll need to think differently.. maybe a 5.25" disk sends data slow enough that you'll have more luck (data speed is related to the rotational speed of drive, and storage density.. I was trying to read a 3.5" DD disk, that rotates in about 200ms, so within 200ms, you have to measure the widths between each pulse from the rdata line, and either store them, or process them out into 4us,6us,8us buckets, and store that to take less space.. either way the arduino either has too little ram, or too little time to do the i/o to push the data elsewhere)

I've had more success with a 'maple', (actually an olimexino-stm32) which runs a little faster, and crucially has dma.. I got one of those to use timer data capture with dma to automatically measure the time between pulses from the rdata line, and then store the data out to an fram chip via spi.. the fram was big enough to store 64k widths.. so then the whole thing could read 1 side of 1 track, push it to the fram over spi, then pull it back from the fram, and store it down to the sdcard attached.

That was enough for the proof of concept I wanted ;p and I'd learnt enough to know just how fickle reading data like this can be (especially when custom track formats/copy protection comes into play) so I then bought a kryoflux, as although I'll still probably finish mine, I needed something that would 'just work' to read all the floppies in the video ;p reused the original arduino to replace the motherboard of the autoloader, controlling the motor/sensors.

It's all good fun tho =) use a kryoflux if you care about the data, but if you want to just tinker & learn how to build your own controller, go right ahead, I can offer a few pointers if you get stuck!

Schweet! Author and builder has joined the party!

Yeah, I was almost thinking of a computer-side app that would pick up the data stream, and creating a disk image. I'm an early (not original, not quite SammyIAm) adopter of floppy drive music, so I know my way around floppy drives relatively well.

I know that 5 1/4"ers are slower, less data, and physically larger. By how much slower, I'm not sure.

Heh.. it all comes down to timing ;p

You want to record the time deltas between each pulse from the rdata line.. for a 3.5" DD disk, they would normally be 4us, 6us, and 8us wide. Of course, this is a real spinning lump of plastic driven by 1980s motor tech.. so they are never exactly right ;p and once copy protection gets involved then all bets are off..

If you want to record the data to make an image to use, look into how the image data is represented, it may only store the bytes decoded from the mfm bits.. in which case storing all the timings exactly is only needed to give you a better chance at deciding if something is a 4/6/8us delta.. (eg, if you see 5us.. is it a long 4us, or a short 6us?)

So, timings.. 1st trying to time the deltas between the pulses.. that's kinda tough on an arduino.. 16mhz clock, 1 cycle per instruction, gives 62.5 ns per instruction.. or putting it another way.. 32 instructions 2us, or 64 in 4us.. in a worst case, you could have a whole track full of 4us gaps.. (although mfm may not like that) .. so you really have to be able to respond to the rdata pin transition, and store/output the data, within that, else you risk missing the next pulse..

With that kind of margin, beware of using an interrupt handler to service the pin transitions, the overhead may be more expensive that just busy looping.. it's also why the sketch was written using..
if( ( PORTD & _BV(RDATA) ) != rdataflip){
instead of
if(digitalRead(RDATA) != rdataflip){
as the overhead of calling digitalRead is noticeable with these kind of tolerances.. If I were serious and still wanted to use the arduino.. I suspect I'd need to ditch using Wiring entirely for the main loop, and drop to inline assembler.. (or.. just buy a faster micro cpu ;p)

Or just do what you did and just buy a Kryoflux....

Definitely going to do that, but see what I can do with the Arduino.