View Full Version : Need help intercepting an FDC connection

July 27th, 2005, 03:48 PM
Hey all!
I've got this really old retro device from 1994 called a "Double Pro Fighter", you can see all about it at my site here (http://www.randomsonicnet.org/workshop/). Anyway the only data in and out of this device is through the parallel port adaptor and the floppy disc drive. Now this is the interesting thing, the floppy disc drive loads and saves data MUCH faster. Now I'm wondering whether it's possible to intercept the 8bit databus from the floppy and connect it to a computer and emulate a floppy drive or something. I have the datasheet for the floppy disc controller chip, and it's avaliable on the site, but I've never attempted anything like this before, I dunno if it's even possible. Anyone attempted anything like this before to try and get data out of old vintage equipment for example?
Thanks in advance guys, I know this is a bit technical but hey maybe you can help ^_^

July 27th, 2005, 05:07 PM
Interesting project ... but to make sure I understand completely, you want to replace the floppy controller with a device that emulates the floppy controller, but talks to another device such as a PC? Or are you going to emulate the floppy drive, and leave the existing controller in place?

July 27th, 2005, 06:37 PM
Either really, though I'd imagine accessing the raw data before it's gone through the controller chip is probably easier if starting from scratch. However if someone knows how to manipulate the FDC interface then I'd obviously go with that.

July 27th, 2005, 07:15 PM
Assuming a standard floppy controller ... (I haven't looked at your data sheet.)

The interface between the machine and the floppy controller is fairly primitive and well defined. It consists of I/O ports in the x86 I/O port range. There is some DMA involved too, but I'm not entirely sure how it works - the floppy controller isn't memory mapped, so how the heck does DMA help? :-)

Writing an emulator is easy. Building the hardware that looks like a floppy controller but actually goes to a different machine is different. Your fake floppy controller has to have address decode logic just like the original so it responds only to the correct I/O ports. Then it has to forward the data to the PC on the other side. Maybe the forwarding is as simple as latching the data into a buffer for a short period of time.

On the other side you need something that can receive the data and present it to the PC. This can be as simple as just a few I/O ports. Software would have to constantly poll the ports for changes to the data, and then respond quickly enough to fake out the original system. I'm not an engineer, but I can imagine that getting the signal timing would be the challenge here.

A more sophisticated setup would have some additional intelligence in the fake floppy controller to make the handshaking with the external PC easier & more accurate.

July 27th, 2005, 07:28 PM
Thanks for your reply! However that does sound pretty intense to say the least, I'd probably have to build a board with various multiplexers and stuff for the decode logic which I don't really understand, unless I could use a PIC chip to do it... that might be one way of simplifying things a bit. Shame I don't have a pic chip programmer :roll:

I just wonder if there's anything else that can manipulate the FDC connector for something more than a floppy drive, just so I can think of a few building blocks that could save time. The only thing I've thought of is possibly a USB floppy drive, but to rip that apart and then reverse everything and write drivers would be hell.

I REALLY want to do this, but I just don't know whether I have the skill involved, I'd happily learn though if only I knew where to look for sucha n obscure project :lol:

July 28th, 2005, 05:58 PM
You might be able to do something with a PIC or micro controller. If you could emulate the floppy interface and send the data off-card using an easier mechanism it would be much easier. For example, the PIC or micro-controller mimics the floppy controller chip, but passes the request to the other machine using something higher level, such as a parallel port. (You would use a parallel type port interface on both sides.) The parallel port on a modern PC is far faster than a floppy drive, even without ECP or EPP modes.

On the PIC side you don't really have a parallel port - just the 8 data wires and 5 control wires that make up the guts of the interface. A PIC would be able to toggle those on and off fairly quickly.

Better start reading up on micro controllers ... I don't have any experience with them, but I know some of them like the Basic Stamp come with a lot of software tools to give you a jump start.

August 9th, 2005, 09:48 PM
to take a stab at how DMA benefits the floppy circuitry Mike, the registers in the controller/chip may not be memory mapped, but the data from the drive/disk gets sent to memory. On pc's that have DMA (the Tandy 1000 and Peanut are notable examples of those that don't), the data from the floppy can get to intended memory directly, IIRC w/o passing through the 8088, or something like that. Hence the Direct in DMA.

August 13th, 2005, 12:48 PM
Sure. Now tell me how.

If the controller isn't memory mapped then you can only talk to it on I/O ports. The 8088 has 64Ks worth of I/O ports, and the floppy controller circuitry only responds if you put the port address on the lower address bits and the correct line indicating I/O (and not memory) is set. (Or possibly low, if it's using negative logic. I'm not digging out the book now.)

If the DMA controller is capable of writing to port addresses instead of just memory addresses, then the DMA controller can handle the transfer.

I just discovered an excellent link that explains this very well:


So to summarize it, the DMA controller can write to I/O ports as well as memory addresses. The floppy controller never is memory mapped. The DMA controller moves it one byte at a time.