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
why FPGA? why not PIC?
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.
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.
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
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