DVD Drive Emulator Question

[meneerbeer]

I have been working on a DVD drive emulator the past few days. I think I am very close to having something that is able to boot a game. The emulator consists of an FPGA with an SD Card. I have used "dd" to copy a Wind Waker PAL ISO to the SD Card. So basically, there is no filesystem support.

Unfortunately, I am unable to get Zelda to boot. When I turn on my GameCube it will hang on the GameCube logo (no error message, so it at least somewhat acknowledges there is a DVD drive). I have been using the FPGA as a logic analyzer as well, so I can take a look at the signals. The GC will first issue a read Disc ID (0xa8000040) command, which just means I need to return the first 32 bytes of the CD. This seems to go fine. After this the GameCube will issue a read command (0xa8000000) and it will try to read 32 bytes at offset 0x00002440. This seems to be the Apploader section. My emulator seems to be perfectly capable of responding to the read commands. However, it still gets stuck on the GameCube logo.

I plugged in my DVD drive (with my copy of the WindWaker) and then used my FPGA as a logic analyzer again. It is sometimes a bit difficult to find things of interest. However, I also found the read command at offset 0x00002440 with the real drive. It seems the data that the drive sends is actually slightly different. Based on that observation I used cleanrip to dump my copy of the Wind Waker, but it does not seem to matter. The ISO I used before is the same as my own rip at offset 0x00002440. Of course I tried to "dd" my own rip to the SD Card as well, but the problem persists.

The difference is as follows:

ISO/Drive Emulator:
00002440: 3230 3032 2f30 392f 3035 0000 0000 0000 2002/09/05......
00002450: 8120 0258 0000 1934 0001 adb0 0000 0000 . .X...4........

Real Drive:
00002440: 3230 3032 2f30 392f 3035 0000 0000 0000 2002/09/05......
00002450: 8120 1ba0 0000 1f50 0001 adb0 0000 0000 . .....P........

Does anyone have any idea why the data in the ripped iso is different from what the drive sends? I will give Melee a try soon, I guess.

[tueidj]

No modchip involved?
It looks like extra code is being tacked onto the end of the original apploader and the entry point is being adjusted to point at it...

[meneerbeer]

I was indeed using a modchip. I tried a drive without one and the output is now the same. It is still not working, so I have some debugging to do.

[novenary]

Yeah, XenoGC patches the apploader for region free and special modes at boot. http://www.gc-forever.com/wiki/index.ph ... C#Settings

[emu_kidid]

Both have been patched by the XenoGC, use a clean verified dump.

FYI:
0x2450: Apploader Entry Point
0x2454: Apploader Size

[meneerbeer]

I dumped it with a Wii that does not have a modchip, iirc.

I suppose the modchip will "corrupt" the dump when you use cleanrip?

I am getting a bit further. The GameCube now boots into a black screen when I disable the logic analyzer. I think there is a timing issue somewhere. When I still have the logic analyzer connected, it will sometimes boot into a black screen after a very long time. In that case the GameCube seems to try to read the disc multiple times (it will read at the same offsets multiple times).

[emu_kidid]

I thought a 0x12000000 command occurred first (it does in games at least), followed by 0xA8000040 then 0xA8000000 (at 0x2440), and amongst all that, 0xE0000000 commands to check for status which you should be replying with 0x00000000 to for now (maybe 0xE0 is only used if error is set in the DI Status register, I can't remember exactly).

Also, don't reply too fast to the GC on cold boot, place a delay in the read disc ID command (A8000040) of about 2-3 seconds if you can, that way you can hold A in the IPL and see if the disc is read properly enough before you have to worry about getting in-game where more commands may be issued (depending on the game).

Lastly, use a game which doesn't have the Audio Streaming bit set in the header as well to avoid having the IPL issue an additional audio streaming setup command (look for ISO where byte 0x08 in the ISO is set to 0, use those games).

[meneerbeer]

Tried pressing the 'A' button at startup. I did not know about that one. I guess that shows how little I know about the GameCube. I reply pretty fast to the read disc ID command, but it still goes into the system menu.

Anyways, when I press 'A', I get into the system menu and the disc is actually recognized as Zelda. Booting it unfortunately gives a black screen. I think the last command that is issued is 0x12000000, which I of course respond to.. I have the SD Card clock hooked to an LED and I do not see any activity from there, so no more reading occurs after booting the game.

Also tried pressing 'A' for Melee. It is recognized as well. Booting it does trigger reads from the SD Card and I do not see a 0x12000000 issued. Unfrotunately ti gives a black screen as well. Perhaps some of the data is read in incorrectly at the start?

I feel like I am so close....

[emu_kidid]

Data is either read incorrectly or you aren't handling interrupts (and clearing them) properly. You need to reply to 0x12000000, but you also need to handle when values are changed on the DVD Status Register.

Take a look at how Swiss responds to a 0x12000000 from the software side when simulating a DVD drive for SD Gecko here.

[meneerbeer]

I reply this as well to 0x12000000:
*(u32*)(dvd[DI_DMAADDR]+4) = 0x20010608;
*(u32*)(dvd[DI_DMAADDR]+8) = 0x61000000;

I am not sure what you mean with handling values on the DVD Status Register?

When I use a very slow implementation of SD reading. I can get Melee to boot, but it seems to hang on the memory card menu. The SD reading is slow because it will first go from the SPI unit that communicates with the SD card to the CPU and then from the CPU to the DI (communicates with the GameCube via the DVD port) interface. Melee does not issue a 0x12000000 at startup, I will have to check if it does later.

I think the problem is somewhere else. The system seems very sensitive to the clock speed I am using, which does not really make sense considering my implementation. Making it lower will make it no longer work for instance.

[tueidj]

Have you compared what a real drive returns for 0x12000000? IIRC it's 16 (maybe even 32) bytes total, there are four zeroes each before and after the data shown in your post.

[meneerbeer]

Have you compared what a real drive returns for 0x12000000? IIRC it's 16 (maybe even 32) bytes total, there are four zeroes each before and after the data shown in your post.

I have. It is 32 bits indeed. When I start Zelda I think that is the only command that is issued. I suppose when you insert a disc into the GameCube it will read the ID + apploader? I think something goes wrong when loading the apploader. I have not seen any weird things in the game description and logo of the game that you will see in the GC menu.

I will have to debug. When I add the logic analyzer to the FPGA, the GC will not recognize the disc. Instead, it will keep reading constantly and I think it is reading the same sectors repeatedly.

I think I will try to boot Swiss using the drive emulator. If I can get that to boot, I could look into making homebrew to test reading from the disc and send the received data to the PC using USBGecko.

[emu_kidid]

I still strongly believe that you need to properly respond & fill out the DVD Status register bits when a read is in progress/complete, you can return the correct data to the DMA commands but if you're not properly addressing when an interrupt has completed/been cleared/etc, then you will have issues.

[tueidj]

That's not something the drive ("mass access storage device") has to handle, the disk interface (the hardware that sits between the MMIO regs and the physical drive connector) takes care of it.

[meneerbeer]

That's not something the drive ("mass access storage device") has to handle, the disk interface (the hardware that sits between the MMIO regs and the physical drive connector) takes care of it.

That is what I figured as well.

Thanks for the responses so far. I will try to figure out what is going wrong. At least Melee was already booting, so it must be something very small..

[tueidj]

It might just be a timing issue. Plenty of GC games make bad assumptions about how long disk access should take, for example they issue a read, clear a flag and then poll while waiting for a read-complete callback to set the same flag... except if the read completes too fast (before the flag is initially cleared) the game polls forever. Wii games are generally better because the disk access times were less predictable (thanks to DRM/starlet being a slow piece of crap) and the programmers couldn't get away with being so sloppy.

[meneerbeer]

It might just be a timing issue. Plenty of GC games make bad assumptions about how long disk access should take, for example they issue a read, clear a flag and then poll while waiting for a read-complete callback to set the same flag... except if the read completes too fast (before the flag is initially cleared) the game polls forever. Wii games are generally better because the disk access times were less predictable (thanks to DRM/starlet being a slow piece of crap) and the programmers couldn't get away with being so sloppy.

I can definitely add a delay for that. I am rather quick with my responses, however, my SD Card can not get the same speed as the disc drive yet. I am running it in SPI mode at 12.5 MHz, so that gives 12.5/8=1.56MB/s at most. I tried increasing the clock, but my SD Card does not seem to like it, which is really strange to me, as I read somewhere 25 MHz should be possible..

My softcore seems to not be able to run above ~30 MHz either. Also weird, because I think you can get to 50 MHz with it on Xilinx (I use Altera currently).

I also want to investigate these clock issues. Make sure that everything is reliable.

[tueidj]

Maybe it's too slow. That would probably explain the repeated reads of the same data - the software read timeout is firing, but there's no error being signalled by the drive so the game just retries.

[meneerbeer]

Swiss boots from the SD Card! Now I can just load my games through SD to EXI, so I am done with this project!

Just kidding. This does give me some opportunities though. Perhaps give cleanrip a try for instance.

[Unseen]

I am running it in SPI mode at 12.5 MHz, so that gives 12.5/8=1.56MB/s at most. I tried increasing the clock, but my SD Card does not seem to like it, which is really strange to me, as I read somewhere 25 MHz should be possible..

25 MHz is indeed possible, at least I had cards running with that speed on a microcontroller. Are you sure that you output/sample the bits on the correct clock edges? It usually works even with the wrong edge, but only if the clock speed is low enough.

Alternatively (if your board is wired to support it) you could try native SD mode with 4 bit transfer width. ikari_01 has implemented in sd2snes, so there is even (Verilog) code to peek at in case of problems.

Swiss boots from the SD Card! :o Now I can just load my games through SD to EXI, so I am done with this project! :D :D

Cool, when do the pre-orders start? ;)

[emu_kidid]

That's not something the drive ("mass access storage device") has to handle, the disk interface (the hardware that sits between the MMIO regs and the physical drive connector) takes care of it.

Well this explains a lot

[meneerbeer]

I am running it in SPI mode at 12.5 MHz, so that gives 12.5/8=1.56MB/s at most. I tried increasing the clock, but my SD Card does not seem to like it, which is really strange to me, as I read somewhere 25 MHz should be possible..

25 MHz is indeed possible, at least I had cards running with that speed on a microcontroller. Are you sure that you output/sample the bits on the correct clock edges? It usually works even with the wrong edge, but only if the clock speed is low enough.

Alternatively (if your board is wired to support it) you could try native SD mode with 4 bit transfer width. ikari_01 has implemented in sd2snes, so there is even (Verilog) code to peek at in case of problems.

I am planning to look into native 4 bit transfers at some point. I guess I would need some more speed, if I want to add audiostreaming as well. I am currently using SPI and the softcore handles the steps to init the SD Card and reading sectors just like you would on a microcontroller. I did speed things up by connecting the SPI unit directly to the DI unit (communicates with the disc drive). By setting a register it will then immediately write the read data to the DI unit. That way I can respond quickly with disc data. I guess it is comparable to DMA.

The slow setup would be to first read the disc data to the softcore and then to the DI unit. That is what I did initially.

I think the problems I am having are due to timing. The strobe signal from the GameCube is recognized as a clock in my implementation (and obviously it is). When I do not constrain it, I am able to boot Swiss. When I constrain it, Swiss is no longer recognized. I was not expecting to have problems with such slow clocks. I believe it is only around 13.5 MHz. Altera is a bit harder to implement timing constraints in my experience. Gonna have another look tonight.

[tueidj]

In the direct mode if a disc read doesn't align with the start of a sector, I guess you just tick the SPI clock until you reach the beginning of the data you need to return?

[meneerbeer]

In the direct mode if a disc read doesn't align with the start of a sector, I guess you just tick the SPI clock until you reach the beginning of the data you need to return?

Yes, that is correct. Same goes for a read that does not align with the end of the last sector. The SPI clock is ticked until the whole sector is read, but the data is not sent to the GC.

[emu_kidid]

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