So, I’ve been working on the FPGA version of the amiga floppy project for some time. I just recently had a fair bit of free time, and so everything came together rather quickly!
I’m now able to read amiga floppy disks in using the same Java client software I had developed for use with the Parallax SX microcontroller board. There were a few minor changes in the software — most notably the read data routine from the hardware.
I’ve written the code in Verilog on a Xilinx Spartan-3e evaluation board.
The various hardware parts I’ve described:
- UART: Written from scratch, a transmitter and a receiver. Simple to use, variable baud rates.
- FIFO: Generated from Xilinx’s CoreGen. This connects the floppy interface to the USB interface. 32k bytes
- FSM to always empty the FIFO to the PC. Once something goes in the FIFO, it immediately gets sent to the PC
- Read-floppy-FSM: Stores 225ms of Delta T’s (aka time between edges) as 8-bit integers into the FIFO.
- Command FSM: Receives single-character commands from the java software to execute (R for read, U for upper head, L for lower head, etc)
- Transmit test pattern routine: Sends 32k of data to the PC to test for reliable communication
A couple advantages with the FPGA solution:
- We transmit the data to the PC as soon as it’s available. I want to characterize the actual latency, but it should be pretty small. This is different from my load->FRAM, and then FRAM-> PC method. This method should be much faster and we’re just not idling for 225ms.
- Instead of transmitting the bit-sync’d raw MFM to the PC, I’m sending the delta T’s. While this requires a little more processing on PC, the PC can more easily determine why a particularly sector can’t be read. For instance, is the time between pulses too small? Too large? On a fringe edge? Plus, since the Java decodes these, I can now add sliders for “acceptable delta T’s” for each 4, 6, or 8us windows. Before that would require modifying the firmware on the microcontroller. I can also start to do statistical analysis on the pulse times.
I am currently doing about 430ms per track. This sucks. I was beating that by 100ms with my microcontroller. However, the problem is that because a variable amount of data is going to the PC, the PC receiving code does not know when exactly to stop receiving, so there’s a wait-timer which I have to optimize. Once I receive the minimum amount of data, I wait 100ms since the last received data, and then exit. I’ve got to put my logic analyzers in place and figure out how to optimize it.
Denis@h3q can read a disk in 43s, which is pretty darn good. He is using tokens like I mentioned here and here and here. I’m transferring much more data though, which gives me more information. I like his time, and maybe that would be a nice goal to beat! Wow. That’s only 269ms/track. Hrrrmm…. that’s pretty good.