DVD Drive Emulator Question

[meneerbeer]

Are you using the multi-sector read command in SPI? It really speeds things up, at "32 MHz" I get 2.3MB/s with it

I am not. I could definitely look into that later. 2.3MB/s does sound fast enough to mimic a drive well enough.

For now I just want to try to get things to work. Speed should not matter that much right now. With very slow SD reading Melee was booting, so I should at least be able to get to that point with the faster reading.

[meneerbeer]

Small update.

I used CleanRip to dump Melee with the drive emulator. I get around 430 KB/s of throughput, but I also send every received command over UART, which blocks the response (normally that is turned off, but CleanRip does not seem to like it if I respond quickly). The dumped disc is showing differences.

I am now doing another dump. If that is different from the previous dump I most likely read the disc offset received from the Cube incorrectly from time to time.

Edit: second dump is different from the first.

[meneerbeer]

I am really confused. I am sending the offset that is requested from the disc over UART to my PC (the drive emualtor sends it, not the Cube). I run CleanRip to dump a disc with the drive emulator. It seems from time to time certain addresses are requested twice. CleanRip seems to request 0x10000 bytes per read operation.

Here is an example of where I notice that reading seems to go wrong:

154 000002fd: 0099 0000
155 00000302: 009a 0000
156 00000307: 009b 0000
157 0000030c: 009c 0000
158 00000311: 009d 0000
159 00000316: 009e 0000
160 0000031b: 009f 0000
161 00000320: 009f 0000
162 00000325: 00a0 0000
163 0000032a: 00a1 0000
164 0000032f: 00a2 0000
165 00000334: 00a3 0000
166 00000339: 00a4 0000
167 0000033e: 00a5 0000

The third and fourth column are the read offset that is requested. The red color indicates where it seems to go wrong. Address 009f 0000 is requested twice. I think that should not happen. I have compared the resulting rip with a good rip. It is also at this second 009f 0000 that the dumps differ (location 00a0 0000). The difference only lasts for a length of 0x00030000 (which is the size of 3 0x10000 read operations), so 3 reads seem to go wrong. What is weird to me is that this difference is not longer, as the double read at the same offset does not seem accounted for later (it will just go to 00a0 0000 at the next read and it always keeps incrementing by 0x10000).

There are more places where double reads at the same offset occur. For all cases I checked the wrong dump data is 0x30000 long.

I have run CleanRip a second time and the positions at which double reads occur are different again.

What is also weird is that the data that is ripped at the double read is not the same data as the previous read.

Edit: I think I am sometimes responding twice to the same command. From what I can see in my logic analyzer signals is that sometimes my new_command_flag is not cleared properly.

[pyroholic]

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.

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.

[meneerbeer]

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.

Hi there!

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?

[emu_kidid]

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.

Do you always receive the full "packet" from the Cube or is it possible to receive partial data if all registers are not set?

[meneerbeer]

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.

Do you always receive the full "packet" from the Cube or is it possible to receive partial data if all registers are not set?

I always seem to receive 12 bytes, so the full packet. Otherwise, my implementation would wait endlessly until it receives 12 bytes.

[pyroholic]

Hi,

What I mentioned about asserting the strobe signal is both the response from the drive, AND also the strobe signal from the cube, after a read request has ben performed the cube strobe signal remains high until the interface is ready to receive the response, then it is pulled low to indicate that. If you start writing the response while the strobe signal is still asserted i think you can get errors. I have no delays in my design other than waiting for that condition.

I was previously using video clock due to crosstalk but i have change board since and now i use a 100mhz internal clock on the fpga. I synchronize all input signals through double buffers using the 100mhz clock and generate output signals and control the io bus in that domain so all logic runs in the 100mhz domain. This also simplifies setting timing constraints since you only need to care about one domain. To detect edges i simply wait for the condition when strobe signal is 1 and was previously 0.

SD interface should not be that difficult to get working since you transit the same commands, the tricky part is geting the crc-generator running since you need checksums for each package and in four bit mode one crc for each bit line. Timing mig also be tricky, since the interface is closed and licensed you won't get any timing info through official channels. There are some decent basic information about the interface that is free and sufficient for the logic implementation through.

[meneerbeer]

Hi,
What I mentioned about asserting the strobe signal is both the response from the drive, AND also the strobe signal from the cube, after a read request has ben performed the cube strobe signal remains high until the interface is ready to receive the response, then it is pulled low to indicate that. If you start writing the response while the strobe signal is still asserted i think you can get errors.

I also think you need to wait for the strobe signal from the Cube to be low. I do not check for it, however. From what I have seen on the logic analyzer I always respond afterwards. I guess I will add waiting for the strobe signal to be low as well.

I was at the point that my dumps from CleanRip were correct, but that also does not seem to be the case anymore. When the dumps were correct The Wind Waker would boot through Swiss, but it would crash before reaching the main menu.

I am having weird problems anwyays. When I add a SignalTap instance it works less well and discs are no longer recognized in the GameCube menu. I also seem unable to get the softcore to run at 50 MHz (using MBlite+), which I think it should be able to.

I was previously using video clock due to crosstalk but i have change board since and now i use a 100mhz internal clock on the fpga. I synchronize all input signals through double buffers using the 100mhz clock and generate output signals and control the io bus in that domain so all logic runs in the 100mhz domain. This also simplifies setting timing constraints since you only need to care about one domain. To detect edges i simply wait for the condition when strobe signal is 1 and was previously 0.

That makes sense. I am getting a bit tired of all the synchronization between clocks, so this approach seems nice.

[pyroholic]

Are you analyzing the strobe signal in signaltap? If you do you will most likely break your timing if you still use it as a clock with rising edge, similar phenomenons can occur if you gate it and use as both clock and signal. The drive strength on the gc pins are quite low so analyzing any of the pins unbuffered can also break things. When i ran signaltap I always monitored the buffered signals and had no issue. As soon as you start adding logic to the input signals and the fanout increases and timing fails, so you should buffer all inputs. I'm currently using the logic analyzer in vivado, I really miss signaltap... chipscope is pretty decent also

[meneerbeer]

Are you analyzing the strobe signal in signaltap? If you do you will most likely break your timing if you still use it as a clock with rising edge, similar phenomenons can occur if you gate it and use as both clock and signal. The drive strength on the gc pins are quite low so analyzing any of the pins unbuffered can also break things. When i ran signaltap I always monitored the buffered signals and had no issue. As soon as you start adding logic to the input signals and the fanout increases and timing fails, so you should buffer all inputs. I'm currently using the logic analyzer in vivado, I really miss signaltap... chipscope is pretty decent also

Yes, I analyze the strobe signal as well. However, I remember that I threw away all disc interface related signals and it would still act weird, but that was some time ago already. I guess you are right that it is not very good to analyze a clock signal.

SignalTap is the best in my experience as well.

I think I will try to rewrite some parts. Perhaps take a look at another softcore. It would be very convenient if I can at least get the softcore to run at 50 MHz.

[pyroholic]

Which fpga chip are you running? I don't think 50mhz should be a problem for a light weight processor. You could also go for a simpler architecture if you find one which has a decent compile for it. Unless you are going to run an os on it an 8-bit cpu should have no problems.

I wrote a nes emulator for an fpga a couple of year ago with sd card support for rom loading. The 8-bit 6502 runs a small fat32 driver that i wrote in assembly for loading games. The cpu runs at ~1.79mhz and I had no problems to get ok transfer speeds. It might be a bit slow for the cube but an 8-bit cpu should suffice for logic control and file system support. And definitely fast enough at 50mhz.

[meneerbeer]

Which fpga chip are you running? I don't think 50mhz should be a problem for a light weight processor. You could also go for a simpler architecture if you find one which has a decent compile for it. Unless you are going to run an os on it an 8-bit cpu should have no problems.

I wrote a nes emulator for an fpga a couple of year ago with sd card support for rom loading. The 8-bit 6502 runs a small fat32 driver that i wrote in assembly for loading games. The cpu runs at ~1.79mhz and I had no problems to get ok transfer speeds. It might be a bit slow for the cube but an 8-bit cpu should suffice for logic control and file system support. And definitely fast enough at 50mhz.

I am using a DE1-SoC, just like you were initially. I want to use a softcore so I can port it to a small and cheap FPGA.

Cool project with the NES. I think I will try to get the ZPU softcore running.

[pyroholic]

Ok, then it should definitely be able to run a soft core at 50mhz. I took a quick peak at zpu, seems to run 4 cycles/instruction, which might be a bit slow. There are a couple of nice 32-bit soft cores, leon3 and openrisc that are synthesizable at pretty high frequencies, or if you want a small 8-bit core then check avr based soft core. They usually run single cycle/instruction and can reach pretty high frequencies. The bigest benefit of 8-bit is that program code will be smaller and you need less block ram to store the program. The fat driver I wrote was about 700 bytes program code and 50 bytes of ram. A c based version would grow a bit but not that much. Also with avr you will have a well supported toolchain.

Otherwise you have the free version of nios ii if you don't mind using altera ip. It should be pretty small as well.

[tueidj]

8-bit would probably be a headache to implement audio streaming (decoding) with...

[meneerbeer]

Ok, then it should definitely be able to run a soft core at 50mhz. I took a quick peak at zpu, seems to run 4 cycles/instruction, which might be a bit slow. There are a couple of nice 32-bit soft cores, leon3 and openrisc that are synthesizable at pretty high frequencies, or if you want a small 8-bit core then check avr based soft core. They usually run single cycle/instruction and can reach pretty high frequencies. The bigest benefit of 8-bit is that program code will be smaller and you need less block ram to store the program. The fat driver I wrote was about 700 bytes program code and 50 bytes of ram. A c based version would grow a bit but not that much. Also with avr you will have a well supported toolchain.

Otherwise you have the free version of nios ii if you don't mind using altera ip. It should be pretty small as well.

Is it possible to add your own peripherals to the AVR softcores? I have some experience with AVR.

Last time I tried the ZPU I could not get it to work correctly. It might have been in the compiler.

[pyroholic]

You should just be able to map the peripheral registers as memory so that's no problem. For audio streaming I would implement the decoding in the fabric and feed it using the cpu and a buffer.

[meneerbeer]

OK, I will keep the AVR8 in mind. Currently I really do not have the motivation to start almost from scratch again and try to understand a different softcore.

I am now trying to synthesize the normal MBlite instead of the MBlite+. I have worked with the normal MBlite before. If I can get that to run at a decent speed I think I will use that for now.

Edit: it seems I can run the normal MBlite at 100 MHz. I am going to switch to that one. I know it will fit on small FPGAs as long as it does not use too much memory. Perhaps I can not add the FAT filesystem support, but that could be done from Swiss, like the Wiikey. When I finally have something that works I will start worrying about those things.

[pyroholic]

Nice that the regular mblite worked better, 100mhz is not too shabby. Even if you have fat32 support from swiss, you are still going to need some basic functions from the filesystem implemented in software to fetch block addresses for the clusters, otherwise you would need to make a table with the mapping of the file you are loading. And unless you are using very large clusters on the filesystem that table would be pretty large as well.

Anyway first things first, I guess that getting the communication between the fpga and the cube and booting a game is your first priority. I checked my code on how I do the handshaking and basically for data written by the gamecube, I shift the data in when I detect a rising edge on gamecube strobe while read/write signal is set to "write" and on receiving the 9th byte out of twelve I assert the strobe signal from the drive emulator. Internally I use a counter to keep track of which byte that is received and the counter is reset either if read/write is set to read or if the reset signal is asserted.

The condition for writing data to the bus is that the read/write signal is set to "read" and that the gamecube strobe signal has been deasserted. When a transfer has completed and the last byte has been clocked to the bus the strobe signal is deasserted when the hardware is ready to receive the next command. The state of the data bus is controlled completely by the r/w signal after it has been synchronized to my clock domain.

[meneerbeer]

Thanks for all the info! I am not sure if I have enough time next three weeks to work on it, or at least get far with it.

One more question: does the frequency of the drive strobe matter much? When I use my SD Card with SPI at 25MHz I get bytes with a rate of 3MB/s, so my clock on the drive strobe is around 3MHz. That system ran at 25 MHz, so when there is new data I would make the drive strobe high for one cycle and otherwise it would be low again. I suppose at higher clock speeds having it high for only one cycle would not really work I guess.

Also, I believe in your topic you mentioned that at one point you were writing data so fast to the Cube that it would crash (at the 13.5 MHz rate, but then without any breaks like normal drive).

[pyroholic]

I can't really say how much the frequency matters on the drive. After some more investigation into my problem with high speed transfers it seemed that it was not due to the transfer itself but actually some cache issues due to some mistake I made. I'm not sure why it worked with smaller buffers since they should have the same issue, but I did quite some rework on the kernel module and use another approach with zero-copy from the usb-drive to the buffer. I'm gonna try pushing the clock frequency upwards and see where it hits the roof someday when i get my computer back up after a recent crash.

One thing that you should aim for is even duty cycle of the strobe signal, so if you are clocking serial data @25MHz I assume you divide that clock by 8 as a base for the ~3MHz clock for transfers. Just assert the clock on cycle 0 and deassert on cycle 4 (of the 25 MHz clock), that way you get a 50% duty cycle and a 3MHz strobe signal when you have data to transfer. I implemented it as a free running counter which makes it really simple. In between transfers I just let the strobe idle high until the next data is ready. Then just start shifting data to the bus and start toggling the strobe signal again. The read drive also has pauses in the transfers which you can see with a logic analyzer, it also idles with the strobe signal high. Also for timing, make sure that you write data on the falling edge of the strobe signal (that would be when the clock division counter is 4), so that there is time for the data to stabilize before the cube samples on the rising edge (which would be when the clock division counter is 0).

[meneerbeer]

I can't really say how much the frequency matters on the drive. After some more investigation into my problem with high speed transfers it seemed that it was not due to the transfer itself but actually some cache issues due to some mistake I made. I'm not sure why it worked with smaller buffers since they should have the same issue, but I did quite some rework on the kernel module and use another approach with zero-copy from the usb-drive to the buffer. I'm gonna try pushing the clock frequency upwards and see where it hits the roof someday when i get my computer back up after a recent crash.

Sounds like your drive emulator is a serious beast. I bet in its current state it is already really fast. I could have gone your way with the ARM core, but that would have been more investigation work and I want to target a cheap FPGA anyways. Having the DE1-SoC always connected to my Cube is not really convenient. Getting a good drive speed would have been easier I guess, since Linux takes care of that.

Have you seen the Snickerdoodle board by the way? It might be the ideal platform for your project.

One thing that you should aim for is even duty cycle of the strobe signal, so if you are clocking serial data @25MHz I assume you divide that clock by 8 as a base for the ~3MHz clock for transfers. Just assert the clock on cycle 0 and deassert on cycle 4 (of the 25 MHz clock), that way you get a 50% duty cycle and a 3MHz strobe signal when you have data to transfer. I implemented it as a free running counter which makes it really simple. In between transfers I just let the strobe idle high until the next data is ready. Then just start shifting data to the bus and start toggling the strobe signal again. The read drive also has pauses in the transfers which you can see with a logic analyzer, it also idles with the strobe signal high. Also for timing, make sure that you write data on the falling edge of the strobe signal (that would be when the clock division counter is 4), so that there is time for the data to stabilize before the cube samples on the rising edge (which would be when the clock division counter is 0).

That seems like a nicer solution. Right now my drive strobe is always low during transmission (before I respond with the first byte it is still high obviously). When there is new data in the FIFO (it will appear immediately on the output of the FIFO), I make the drive strobe high for one cycle. This was easy to implement, but it does not resemble the behaviour of the real drive closely. I also noticed that indeed the drive strobe is high on the real drive when there are no transfers. Your solution with the counter should not be much harder to implement.

Thanks for all the help so far! Hopefully I can give these new ideas a try soon.

[pyroholic]

I had missed the snickerdoodle board actually, I looked for a chrap board last year but could not find one. This one is basic alla the procent of the parts if you order one of each so a good puckade in my opinion. I'll see if I can have one ordered to work and try it out.

[meneerbeer]

After more than a year I have picked up this project again....

I rewrote some of my code, but I kept having the same problem as I remember to have had one year ago. At some point I would receive an unknown command from the GameCube. I have looked further into this issue and it seems that the DIDIR signal sometimes goes high for a very short period. This sometimes resets some signals in my design, making it capture an incorrect command from the GameCube. I am not sure why DIDIR does this strange thing.

I am now filtering out these short periods that DIDIR is high and this seems to have helped quite well. I am no longer receiving weird commands. I have dumped Wind Waker and Zelda Collector's Edition with my drive emulator using Cleanrip and both had a correct md5, so this seems promising.

Unfortunately I am unable to boot both games from the GameCube menu. The image of the Wind Waker does show up, but once I boot it I only get a 0x12 command from the Cube after which I do not see any activity anymore. Zelda Collector's Edition does not even show the image. Instead, the cube keeps sending read commands to repeating offsets.

Wind Waker I am actually able to boot from Swiss. It shows the title screen (with Outset Island), but once I press start it gives a black screen (after several read requests). Zelda Collector's edition also boots from Swiss, but it seems to hang immediately at the 60Hz disclaimer. It is interesting that Swiss is able to boot these games. Does Swiss do anything different when booting games than the system menu perhaps?

Meanwhile, I will have a look at multiblock reads to improve read speed.

p.s. with Collector's Edition I did have an interesting experience. After having run clean rip I exited to the GameCube menu and I saw the image popped up and I was able to start the game after which I was able to start and play Ocarina of Time (it seems this game is completely loaded into the GC's memory, so there are only reads at specific moments).

[novenary]

I rewrote some of my code, but I kept having the same problem as I remember to have had one year ago. At some point I would receive an unknown command from the GameCube. I have looked further into this issue and it seems that the DIDIR signal sometimes goes high for a very short period. This sometimes resets some signals in my design, making it capture an incorrect command from the GameCube. I am not sure why DIDIR does this strange thing.

I am now filtering out these short periods that DIDIR is high and this seems to have helped quite well. I am no longer receiving weird commands. I have dumped Wind Waker and Zelda Collector's Edition with my drive emulator using Cleanrip and both had a correct md5, so this seems promising.

Sounds like you're having noise issues, quadruple-check your wiring and/or enable termination resistors in the FPGA.