HxC Floppy Drive Emulator

I was telling a friend at work about this project today and he was quite interested as he used to do a lot of work in Verilog and VHDL, but he asked me why a simpler device such as a PIC wasn't used instead of an FPGA.

His reasoning was since a floppy drive has known responses from the host, why wasn't a PIC programmed to mimic a floppy drive instead of recreating all of the logic for a floppy disk drive.

To be honest, I have no idea. Any comments from anyone as to why a PIC would not be suitable to mimic a floppy drive would be greatly appreciated so I can tell him.

Thank you,
Gizmomelb

Hi,

The main problem is that the floppy emulator need to download data from USB bus as fast as possible (at ~1MB/S) and shift data, generate MFM pulses, handle track position in the same time.
I think that we need a very powerful uC to do all this tasks in the same time.
Without the downloading part, a PIC is powerful enough...

The other point is that with a PIC it will be very difficult to simulate an protected disk (CAPS / IPF , Pasti/STX).
We need to be able to accelerate or slow down the bitrate with a good precision:

For example the CAPS/IPF documentation says this :
<<
Cell Density Map
[...]
The density value supplied by the library is relative to the complete cell time of a
track. Each step represents a 1/1000th difference from the default cell density used by
normal speed cell groups of the whole track. A value of 1000 represents a cell group
in normal - 100% - width; a higher value is a wider cell group (slower/takes more
time to read); a lower value is a narrower cell group (faster/takes less time to read).

It is normal to have variable cell density within the same track as a protection
measure.
>>

So with a default cell density of 250000bits/s, the shifter can be set at 249750bits/s, 250000bits/s, 250250bits/s , etc (steps of 250bits).

At 250000bits/s a step of 250bits/s represents 1/((1/250000)-(1/250250))= 4nS !!

4ns is the period of a 250Mhz clock.

The fpga version of the floppy emulator will probably have a less precise but enough precise ( ) cell density step (8ns or 16 ns).

Anyway this bitrate feature seems to me very difficult to simulate with a simple uC.

seems like this guy's cracked it a uC:

http://www.techtravels.org/amiga/amigablog/

While I confess I haven't read much about the HxC project, I think I can help here.

I'm the guy over at the techtravels site.

The main reason why you can't use a PIC for floppy type stuff is because its just too darn slow. PICs use a divide by 4 execution cycle. So if you're running at 20mhz, then your instruction execution cycle is only 200ns. 20 / 4 = 5mhz, 1/5mhz = 200ns. The amiga's drives have 2us bit cell times, which mean that you'd have to send a bit every 2us, which gives you all of 10 instructions to do everything else. Double to 40mhz, and you get 20. Still sucks.

dsPic30, I believe, was recommended for my project by some Microchip Application Engineers. My project does DRIVE/disk -> PC, opposite of what you are doing, but similar. The reason I didn't consider that was because development tools, debuggers, etc were much more expensive for that family than for their smaller PICs.

I use a Parallax microcontroller SX28 running at 50mhz, and 50mhz=50 mips on that unit. Really fast. 20ns execution rate. Which gives me 100(!!!) instructions per MFM raw bit.

I currently use about 380ns + ISR overhead to read and store each MFM bit into serial memory.

Hope this helps,

Keith