Floppy to FPGA?

I'm currently working with an old imaging device whose only output is a floppy drive which only allows transferring 6 images at a time (due to floppy disk size constraint). I had the idea of implementing an FDC (floppy drive controller) on an fpga then connecting the drive cable to the fpga and using the fpga to stream the images through a serial port thus bypassing the disk size constraint. Can anybody comment on the feasibility of this project and perhaps point me to some existing VHDL code? Otherwise, does anyone have any other feasible ideas?

Thanks.

Reply to
fslearner
Loading thread data ...

Implementing an fdc controller in fpga should be a piece of cake. The signal is 1 Mbps at tops asfaik. It's proberbly MFM encoded signal, otherwise it's likely GCR or FM. 1.44M/1.2M discs are 500 kbps. 720k/360k = 250 kbps.

The signal consists of a pulse for every magnetic flux asfair. If you use an oscillator to count the number of clocks between these pulses. You can derive data from there.

On a higher level you have to pay attention so that your host only read disc data when it has been completed, and fat is consistent. Should you erase or in other way alter "floppy" your scanner device better be aware of this. Through the signal 'discchange' wire or simply instruct it on console. Your fpga can also imitate two floppys btw, by useing the select signals.

A quick approach is to add one those usb-fpga kits. And tie floppy i/o to it.

Don't forgett that floppy idc36 is 5V.. ;)

Reply to
pbdelete

fslearner schrieb:

should be doable. there is one guy who has floppy disk host interface done by 100% software with some small microcontroller. So with FPGA you defenetly can do it. but I bet you need todo it all from scratch.

Antti

Reply to
Antti

Doable, no doubt, but you need more information than just the specs of the interface between floppy and controller. With an FPGA you can recover the raw data sent to the floppy as well as the head positioning and motor on/off commands. You will need details about the file system structure in the floppy to allow you to interpret these data and commands to recover the files you want to send out.

As an aside, I worked for a company that made a system that simulated a magnetic tape drive, for similar purposes. Instead of filling a tape reel and then remove it and physically transport it to a different location to process the data, "fake" the drive, collect the data from the tape interface and stream it over the Internet for processing.

Reply to
Roberto Waltman

Steve Wozniak designed the Apple II floppy disk interface, many years ago, using a few TTL chips, IIRC.

Leon

Reply to
Leon

My understanding is that you want to create a replacement device for the floppy drive so that you can stop having to shuffle data back and forth. This would mean that the FPGA device would have to fully emulate drive and the disk itself and to be completely transparent to the test equipment that you are using. That's not a trivial project.

Why not just use something like the Delkin Flashpath SmartMedia Floppy Adapter

formatting link
it looks like you might need to add a driver to the system, but your test equipment is likely running Windows under the hood anyway so this might be possible.

If your test equipment has a spare IDE location then you could also just use a straight IDE to CompactFlash like this one.

formatting link

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

Five TTL chips, one 555 timer, and a 256x8 PROM for a state machine.

There is a second 256*8 PROM to store boot code, but that is logically independent of the disk controller functionality.

However, the reason this worked is that it didn't have to be compatible with anything else in the world.

The trick to making a good FDC is having a robust data separator. Simple techniques don't work well with marginal cases. Even a single DPLL doesn't solve the problem, because you need to deal with pulse shifting from the magnetic media independently of tracking frequency variations due to motor speed. A second-order DPLL works pretty well though. There was a lot of work done in this area in the 1980s. WD and SMC had US patents (which should have expired by now) on some clever second-order DPLL designs.

Reply to
Eric Smith

Odds are, this equipment is way too old to have a 3.5" floppy -or- an IDE port. Most likely, it's a 5.25" inch drive, mayby FAT12 360K, mayby not.

It's still very doable. I've done something almost the same to the MFM interface on an old hard disk drive.

Snag the -entire- data stream, sector/track headers and all into memory. A 360K floppy will fit into 1/2 meg of memory.

Use a micro to sift through the image to find the data fields of the sectors. Then find the file system in those.

If the micro has a usb port, you can emulate a flash key. Or write out to a SD/MMC card. Or whatever.

It was a fun project; remember that the device will be reading as well as writing, if there's a file system on the "disk".

Reply to
ghelbig

I remember seeing someone already did it, but with a microcontroller rather than an FPGA. Google for "semi-virtual disk". It is using an Atmel AVR uC to simulate a floppy. Works for both FM and MFM formats.

-Alex.

Reply to
Alex Freed

formatting link

Seems to be a PIC 16C65b @ 20MHz + 256kByte sram in essence.

Schematic+PCB:

formatting link

Reply to
pbdelete

Reply to
Alex Freed

I suppose I should have mentioned that the drive in question is actually a 3.5" floppy. I'm not sure whether there's a spare IDE port however. It also runs some DOS variant.

Reply to
fslearner

As others have concurred, definitely feasible. I have implemented a read-only version of a WD1793 FDC in VHDL which interfaces to a SPI serial flash device rather than a floppy drive.

Some in this thread have talked about drive pules and MFM encoding etc etc - that's *way* too low-level for your requirements. There is no need to emulate operation at the physical encoding level - in fact you'd be silly to do so! You need only emulate the register level interface of the controller and implement a means to store the data for a disk image.

Depending on the actual controller, you *may* need to store a little more info than the actual sector data - for example I needed to flag which sectors had a non-standard data address mark. However considering that you don't need to read the 'images' back on the same controller, you can probably get away with fudging it.

The size of your emulated floppy image is probably still going to be constrained by the size of a floppy disk - your imaging device still needs to 'see' a formatted file system and is only expecting a floppy-sized disk. However, since you can 'suck' the image off your emulated drive immediately I'd imagine you could have an arrangement such that as soon as an image is written, it is transferred to your PC and then deleted from the emulated disk?!?

I started my implementation with a micro (soft IP core) rather than VHDL code. I had an interrupt firing off a write to the emulated disk controller 'command' register. It was sort-of working but wasn't quite quick enough for what I needed, so I opted for a VHDL design. However, I'm sure there's plenty of small micros around fast enough to do the job.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

In that case... What type of bus is in the system? If you can drop another card into the system, hyou have all kinds of options.

There are USB drivers for DOS. If you can get that far, your choices open up significantly.

Reply to
ghelbig

Cool! I could surely use that to add a "floppy" to my Sinclair Spectrum on an FPGA toy :)

I would not be so positive. Each approach has its merits. Consider the benefits of the MFM approach:

  1. Any cheap micro is fast enough for 125K bits per sec.
  2. No modification needed - connect to the floppy connector.

-Alex.

Reply to
Alex Freed

You're not the first to ask. I'll have to post the source it on my site. Be warned, it's really crappy code... ;)

You have a point, my mind was stuck in IDE land where the controller is basically integrated on the drive - I forgot early drives were so primitive!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

Let us know the link when it appears.

If it works then it should be a good starting point for improvements.

Reply to
Kryten

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.