FDD Emulator
Chad George
Posts: 138
I have an application where it would be useful to have a FDD (floppy disk drive) hardware emulator.
Basically, the idea is to have a bit of hardware/software that acts exactly like a FDD, except the file system is created "on-the-fly" from some in-memory data source.
Originally, this seemed like a really great option, but when I started looking into the FDD connector it look like its really really low level interface (ie. move motor, read/write head, etc.)
Does anybody have enough experience with this interface to indicate if this is even possible?
Basically, the idea is to have a bit of hardware/software that acts exactly like a FDD, except the file system is created "on-the-fly" from some in-memory data source.
Originally, this seemed like a really great option, but when I started looking into the FDD connector it look like its really really low level interface (ie. move motor, read/write head, etc.)
Does anybody have enough experience with this interface to indicate if this is even possible?
Comments
So I'm not sure it requires handling analog signals. I did see a reference to conditioning circuits when I looked at a the datasheets for FDD controller chips, but it seems most of the other implementations to everything 100% digital.
Here's what I've got so far.
1. the disks spin at a constant rate 300 RPM (i guess I saw some other numbers too, but this seems the most common).
2. The read/write head is controlled by a stepper motor which controls which track is being read.
This involves 3 I/O signals (from Props perspective)
Input - Step - move one track fwd/rev
Input - Dir - which way to move
Output - Track0 - indicate when we are at track 0...it seems the FDD controller will sends a bunch of step-ins until it gets a Track0 signal.
3. There is an output signal that the prop will need to generate for beginning of track. presumably this signal and the 300 RPM spin rate is used to calculate bit positions along the track.
4. Three lines control data I/O
Input - Write Data
Input - Write Enable
Output - Read Data
Right now I'm just interested in reading from the emulated FDD...writing seems more complex...but maybe I'm backwards.
So the short version of what I think needs to be done is...
1. monitor the Step/Dir lines and generate a Track0 signal when appropriate...to know which Track the controller is trying to read from.
2. retrieve the data that should be on the currently selected Track
3. generate an Index signal and output the data stream at the "correct" bitrate.
I know that's a bit simplified and I'm currently overlooking the difficulty of step #2, but does anyone see anything super critical I'm missing here.
Look at this Wikipedia page them have most info of FDD functioning
http://en.wikipedia.org/wiki/Floppy_disk
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
books.google.fi/books?id=iMZMEuyxK10C&pg=PA455&lpg=PA455&dq=pc+floppy+disk+interface+read+data+format&source=bl&ots=vVnvEtF4CD&sig=5CNctpwpARQKsCTlDJ0AV97aTh4&hl=fi&ei=5tlESoHDCoTw-QbB-JAg&sa=X&oi=book_result&ct=result&resnum=7
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater - thanks, that chapter looked good ... I'll have to get my hands on a copy of the book.
Now I'm pretty sure that FDD data streams will be MFM encoded... no problem there... actually it makes sense as the clock/synchronization signal is embedded in the data stream. I was sceptical about how they could rely on the index signal and disk spin rate alone to synchronize bit timing.
Also from some reading on HDD (that referenced similarities to FDD) I guess the next thing to dig into is the low level formatting of the disk.
For HDD I know that alot of the internal magic is hidden away by the internal controller, but my guess is that FDDs must be alot more standardized.
So the Index signal marks the beginning of a track...MFM encoding is used for the bit stream on a track...and somehow low level formatting splits tracks up into physical sectors. It seems there is actually "something" physically written to the disk during this low-level format.
Obviously on top of all this is the high level formatting (FAT file system), but that seems fairly well documented.
You said
"seems there is actually "something" physically written to the disk during this low-level format."
It is not so magic.
GAPData-SectorData-Checksum-GAPData-SectorData-Checksum ....... that many times that sectors in track
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
The one listed uses a USB drive but it would probably be easier to use an SD card since the code is already out there for the Propeller. It appears that it reads the contents from the USB drive, pulls it onto it's local storage, and then makes the local image available as if it were a floppy disk image.
Robert
Yes, I figured it was something like that...I'm still looking for the low level details on exactly what constitutes the GAPData and what form the Checksum and ECC are to be in.
Most of what I've found so far is too high level to begin planning any real implementation.
Also I've got to figure out how I'm actually going to test this system. I could put a scope between a PC and its FDD and then replace the FDD with my circuit.
But I presume I'll need really low level access to the FDD controller on the PC side of things to really do any significant testing.
But writing / hacking kernel drivers is a royal pain.
@Robert,
I definitely think it would be useful to the vintage computer groups. I know alot of guys around here have interest in those fields which is why I'd start by seeing what knowledge and interest there was out there.
Personally, I'm planning on using this with fairly modern PC FDD controllers (CNC machines to be specific). But the FDD hasn't changed much in a few decades so anything we get working should be a benefit to others too.
You shouldn't have to do any low level access to the floppy controller. To test you would just a PC with a floppy controller and connect your device to a regular 34-pin floppy cable. Ideally it would look like the interface on the back of the floppy drive. Actually if you use all the Drive selection bits you use have the Prop application watch all of them so a single device could emulate multiple drives. Ideally you could have an LCD or other interface on it so you could select what the parameters are for each drive (tracks, Single or double sided, density like single, double, or High) so it can emulate multiple drives. What would be really cool is to store standard disk IMG formats on an SD card and then via a selection screen pop each one in a slot for virtual floppy drives provided by the propeller. If the user has one real drive it may be a nice way to create images too!
A while back I had to reproduce a floppy controller for one of my robots. When I did that I had to track down datasheets for many of the disk controller IC's and can find them again if it would help.
Robert
What I meant by low-level access was that I'll need the PC's floppy controller reading and writing to the emulated FDD long before it can actually emulate the file system correctly.
I imagine it'll take pretty much direct register access to the floppy controller IC, which probably means replacing the OS driver completely.
On the other hand...maybe the linux device drivers are good enough as they are as long as I don't try to mount the file system.
I want to start with simple things like ... seek to track X ... read a single sector (or even entire track if sectors don't exist yet).
I think that's got to be known to work before its practical to try implementing the file system.
First, I would ask why you would have to worry about the file system. That is at a whole different layer than the floppy interface. You should only need that for the SD interface side and that is already written.
By avoiding the higher levels you can make it work with many more devices. Ideally you shouldn't have to care about the higher level format. Looking at the interface between the floppy controller and the drive you would be more concerned about the tracks, sectors, sector ID marks, etc. You really don't care about the data within each sector itself. That would be up to the system itself and what it wants to store where.
This site has a lot of details on a floppy controller:
http://home.comcast.net/~swtpc6800/DC5/FDC_Index.htm
Specifically look at the datasheet for the disk controller chip. You'll want to emulate the signals between the floppy controller and the drive. It should have the drive selects, write data, read data, step, direction, track 00, index, ready, etc. By keeping monitoring the step and direction you can set the track 0 line as needed and then remember which track it is on by virtually moving which track you are dealing with. When it goes to read data I believe it will just be a serial data stream clocked out at the data rate appropriate for the density of the disk you are emulating. If you are doing this from an image of a disk it may already have the sector marks. If not you would have to emulate them too.
I would start with just implementing the READ functionality of the floppy. Get a Propeller wired up the the lines on the floppy controller you would need. Then write a short program to display the state of those and keep track of them. If you try to get a directory you should probably see it stet the drive select and step out the head to the directory track. It's not trivial but I definitely think it is possible.
Robert
Post Edited (RobotWorkshop) : 6/26/2009 6:44:27 PM GMT
Look on thid .PDF document.
Next last in it You have description on all bytes in sector. (page 26)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I definitely don't want to implement the file system on the Propeller side of things until everything else is working.
I still think I need the ability on the PC side to see what the FDD controller is getting from any arbitrary track and portion of that track.
That website looks like a good place to digest on for while, thanks.
@Sapieha, thanks alot... that's good stuff.
I'm really curious what you want to do IN THE END with this FDD-emulator
can you describe it in a few sentences ?
best regards
Stefan
I'm making a system that transfers programs between CNC machines and a server. All of the machines have a serial port and most have a floppy drive too.
The serial port is the simplest interface, but I can't tell when the machine is ready to receive a program, so the operator has to go back to the PC or some other way of initiating the file transfer.
The FDD interface at the machine is a lot more capable. It has directory display, select file from list, read/write file to disk...everything you'd expect.
I'd like to use the FDD interface built into all the machines, rather than adding a new user interface to implement the serial transfer. Also floppy disks are really horrid in a dirty environment like a machine shop...so manually transferring with USB thumb drive would be really usefull too (as a backup to the main system)
So that's why I'm looking into emulating a FDD. When the system is ready to send a file to the machine, it will just show up in the virtual FDD "directory" for the operator to select and download. When the operator saves a program to the virtual FDD, it will automatically be stored into the database on the network.
Post Edited (Chad George) : 6/26/2009 7:26:23 PM GMT
5V signals to 3.3V.
I would absolutely *not* do any filesystem-level stuff. But you do have to decide what floppy disk format you will
support; if you only support MS-DOS, then things are much easier. (Supporting Amigas is a bit more painful.)
Of course on a read you're going to have to send *every* sector on a track every time, because there's no way to
guess which sector the PC is looking for. So a sector read will always end up being a track read, possibly
interrupted early.
They even explicitly mention CNC machines as a typical use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC & PAL templates: http://forums.parallax.com/showthread.php?p=803904
I've gotten the propeller to drive a floppy - see partway down this thread -
http://forums.parallax.com/forums/default.aspx?f=25&m=205895&g=206028#m20602
which could help going in the reverse direction of having the propeller look like a floppy.
You'd receive requests to enable the drive, start the motor, step the head to a track and select a side.
You'd need to count head step pulses and step direction, generate a track zero signal at some point, then count track step pulses to find the requested track number.
Then you could have the propeller prepare a full track of 18 or whatever sectors for the requested track and side, where each 512 byte sector has its own MFM-encoded and CRC calculated header and data blocks. You might need to dedicate a cog or two to help do this on the fly because of the amount of memory a full encoded track would need.
The floppy code that I wrote does the CRC generation and MFM conversion for when writing a single sector, so I know the propeller can do this part. You'd just need to do the same thing for the sector header, and for all sectors of the track.
When the track bits are ready, you could start generating index pulses to tell the caller that the disk is up to speed, and at the same time you'd stream the prepared bits out to the caller, continuing to stream the bits until the caller either disabled the drive or asked for another track or side.
It would be a challenge, but I'm sure it could be done.