pyroholic wrote:Sounds like a fun project, hope you get the double read issues sorted. When I wrote my drive emulator I remember that I had to consider the timing of when to assert the drives strobe signal to acknowledge commands, but i guess a timing issue there would cause other errors. I think 2.3MB/s is not that bad transfer speed, since you are using no file system you can directly translate addresses from the cube to the sd cards block address space so you will basically have no seek time which increases speed pretty much, there are usually not that big chunks transferred at each request from what I have seen.
The issue with double reads has been resolved and I have had cases where I would get a good dump from CleanRip. My previous implementation was detecting a rising edge of DIDIR and if that happened, a register would be set that there is a new command. For some reason this flag was sometimes set during my replies as well. Now I just count how many bytes I have received from the Cube and set the register based on that. That seems to have solved it.
With asserting the drive's strobe signal, do you mean making it high when receiving the last four bytes from the Cube? I have seen some problems with that too. If the timing is too far off, it will give the red error screen. Perhaps something is still wrong there for me. The problem is that the drive strobe signal is triggered on the clock on my FPGA. That means I need to synchronize between the strobe from the cube and the clock on the FPGA. Right now I make a signal high triggered on the strobe from the cube and then buffer it twice with registers triggered by the FPGA clock. I definitely see the moment that the drives strobe signal asserts differs from time to time. Probably because the strobe from the Cube is not that periodic and because of the synchronization between clocks. I am not sure if that is causing the issues though.
Using SPI for the SD Card is only temporary hopefully.
Switching to native SD now would mean I need to invest quite a lot of time to understand and implement the protocol and then there is still the problem that I can not get the drive emulator working.
I would advice against using the strobe signal from the cube as a clock input. It is not really periodic and is only active while shifting data on the bus and while acknowledging transfers from the drive interface. You are still going to need an internal clock to drive your logic and gating the input clock as a signal will mess up things as well. When the strobe signal is at full speed during transfers it is approximately 20 MHz while the drive interface is around 13.5MHz from my measurements. Internally I use a 100 MHz clock which might be a bit overkill but i can adjust when to read/write the data bus with pretty high accuracy and it has worked well. You won't need to do as much synchronization between clock domains that way either.
Last time I read that you were using the video clock from the Cube and multiplied it by 2 to 108 MHz. Are you still doing that? I believe you did not need to do any synchronization thanks to that.
Or are you using a clock on the FPGA board? How are you doing the synchronization, if I may ask? Buffer it with the normal clock and then detect when the Cube's strobe signal rises in order to sample the data bus?