I have finally made some progress. The problem with DIDIR seemed to be the main problem, which was making me try all kinds of crazy things.
After fixing the DIDIR, it turned out I actually had a mistake when I had to read from offsets that were not perfectly aligned with a block address.
I can boot Wind Waker from the GC menu now + actually get in-game. I have given Sonic 2 and Zelda Collector's Edition a try too. These are not showing up in the system menu and instead the GC seems to get into an endless read loop at repeating adresses. However, I can boot those fine through Swiss and actually get into gameplay segments. I have not observed any in-game crashes either.
I am not sure why those games are not showing up in the system menu. Is there perhaps a read timeout in the system menu? My current implementation only gets around 430KB/s, so load times are awful.
Next I will look into multiple block reads + actual 4 bit SD (although I will probably wait until I have a dedicated PCB to do that).
I have implemented the multiple block reads. I get around 900KB/s in Cleanrip now. I have hooked up an LED to show SD card activity. I can see it blanking for some period inbetween reads, so it seems that Cleanrip itself might be capping the speed?
I am still having trouble with recognizing games from the system menu. From the games I have tested I can boot Wind Waker, Twilight Princess, and Melee. The loading times are a bit high, but stuff such as videos plays fine.
The other games I tried are usually not showing up at all in the system menu. They end up in an endless loop of sending the same read commands. However, it seems that some games are recognized at some point. For instance, Metroid Prime sometimes shows up after repeating the same reads for 2-3 times. Does anyone have any idea why that happens?
All games boot fine from Swiss and I have not encountered any in-game crashes, except for Zelda Collector's edition, which does not get past the Nintendo logo. This may be because of Swiss, since it applies a lot of patches at startup.
Edit: it seems a lot of games also have the audio streaming bit set in the header, but are not in the list of audio streaming games.
Cleanrip is limited by the SD card and hash calculation, build a custom version with both disabled to benchmark your drive.
Some games have the audio streaming bit set because they do issue audio streaming commands, even though they don't actually use it. I think the real drive would complain without the bit set.
Looks promising mr.Bear! Im keeping a close eye on this thread!
tueidj wrote: If they're attempting the exact same read commands multiple times it sounds like they might be timing out (and automatically being retried). But that should only happen a few times before showing an error.
I suppose the IPL is responsible for the timeout? In that case, I should be able to compare a game that is detected and one that is not detected. I would expect the game that is not detected to request longer transactions. I am pretty sure my emulator is faster for short transactions, as I do not really have any seek time.
Do you know if the read timeout is per read or over multiple reads?
And yes indeed, I do not get any errors from the GC, it just keeps reading and reading..
Edit: also does anyone know what to respond to cmd 0xe4, when it enables audio streaming? At this moment I always respond with 0x00000000.
The timeout is reset for each individual read request.
cmd 0xE4 enables/disables audio streaming. 0xE401xxxx enables it, 0xE400xxxx disables it. When enabling, the last 2 bytes possibly specify some buffer size; they're normally 0x000A, doesn't really matter for an emulator. A response of 0 should be fine.
tueidj wrote: The timeout is reset for each individual read request.
I don't think timeout is the problem. For reading from SD card I have a non-DMA and DMA mode. The non-DMA mode first goes from the SD-card to the CPU and then to the GC. Because of that it is very slow (takes a few minutes to boot a disc into the start screen, up to a minute to show the disc logo in the GC menu). Even though it is so slow, it still recognizes the games it normally recognizes too in DMA mode (which is way faster).
If timeout would be the problem, I would expect it would not recognize any disc in non-DMA mode. Unless the disc itself is able to set a timeout while being read in the system menu? Then it would depend on which disc is being read, but I am probably overthinking this.
I checked the multiple reads problem a bit further. Basically, the GC sends a reset signal to the drive and then it starts all over again with asking the disc ID, then the enable/disable audio streaming, and finally multiple reads, after which it sends the reset again.
meneerbeer wrote: I don't think timeout is the problem. For reading from SD card I have a non-DMA and DMA mode. The non-DMA mode first goes from the SD-card to the CPU and then to the GC. Because of that it is very slow (takes a few minutes to boot a disc into the start screen, up to a minute to show the disc logo in the GC menu). Even though it is so slow, it still recognizes the games it normally recognizes too in DMA mode (which is way faster).
The reads up to the point of failure may be small/fast enough that the timeout isn't hit. The timeout is 10 seconds I believe, and some games read in 512KB sized chunks. It sounds like you're hitting the timeout based on the "starts all over again with asking the disc ID..."
I would love to see a an ODE for the GameCube similar in function and form to something like GDEMU. I wonder how much interest there would be if something came of this and word spread around the internet?!?
meneerbeer wrote: I will take a look at the requested read sizes between working and failing games.
What debug capabilities do you have? Can you log the drive commands/response with a time stamp and print on uart? I can get you some command/response logs with time stamps if it helps.
It is no longer needed, but thanks for the offer. The custom PCB ended up working fine. The games that failed to be recognized are now recognized and playable. I have not encountered any crashes, except for the games that use audio streaming. However, I do not reply at all to audio streaming commands, so that is probably the reason.
I am still confused why the FPGA dev board did not work, as it was working really nice as soon as I got games to boot through Swiss.
I am currently looking at getting the SD card to work using the native protocol, rather than SPI. SPI is just too slow for my taste and I do not see much point in adding audio streaming + file system support before the native protocol is working. Just like you I took quite a long break after the custom design PCB was working..
I am still working on it every now and then, whenever I have some time and motivation.
Unfortunately, it seems the FPGA I designed the board for is a bit small, which made it impossible to fit any existing SD card interface solution. Therefore, I am now working on another board with a bigger FPGA and also looking into adding a high speed USB interface to make life easier..
What I learned from this, is that it is a good idea to give prototypes more resources than you think you will need.
So looking forward to this can't wait , I've gone through 4 gc lazers in the last 12 years.
That's great to hear, looking at the lack of any option for an ODE for the GC at the moment.
With your design, would you be able to keep the optical drive in conjunction with the ODE? Will it only support SD cards or USB drives are an option?
Sassokee wrote: With your design, would you be able to keep the optical drive in conjunction with the ODE? Will it only support SD cards or USB drives are an option?
At the moment the board would only support SD cards. I do not have any plans to support USB. I am planning to test some of the bigger SD cards on the market (200GB+) and I think those have plenty of space.
It should be possible to keep the optical drive. However, if it ever comes to a final product, I would be more interested in easy installation. The goal of this drive emulator is anyways to never make you want to use your slow DVD drive again.
That's great to hear, I can't wait to see how the final product will look like, I mentioned USB drives as they are cheaper than SD cards, for example a 250GB USB HDD is loke 8 times cheaper than a 256GB SD card. For keeping the optical drive, in case you get hold of new games you want to play.
Really interested in this project, any progress?
What would be the price range?
Sassokee wrote: That's great to hear, I can't wait to see how the final product will look like, I mentioned USB drives as they are cheaper than SD cards, for example a 250GB USB HDD is loke 8 times cheaper than a 256GB SD card. For keeping the optical drive, in case you get hold of new games you want to play.
I would argue that you don't really need a card or drive this big anyway. A 32GB card can hold ~20 unscrubbed games (note that scrubbing is not recommended), which is plenty. You can keep your game collection on a bigger hard drive drive and rotate them as you beat them and start new ones.
xboxman2 wrote: Really interested in this project, any progress?
I received the boards. Did only basic testing, but they seem to work. Software and RTL side still needs lots of work..
To make the board yourself would be in the range of the price for a WASP.
As for the SD vs USB debate. I am planning to test some bigger SD cards (128/256GB range). That should be able to hold plenty of games.