March 26th, 2010
Since the BETA version of Bleemcast! works on nullDC (I’m referring to private nullDC versions here) I decided to check out the retail version some days ago. Unfortunately, both of the Bleemcast! versions I tried ended up failing hard, mostly because MMU “emulation” on nullDC cannot be exactly considered as sufficient. Because of that, hacking around and attempting to debug the thing was futile, not to mention that the way that thing is coded makes debugging even harder (and to think that some people seem to believe otherwise… heh).
Without more proper MMU emulation there’s nothing to be done about this issue so I decided to leave it for now.
With nothing else to do and with a debug-friendly nullDC build around, not attempting to fix anything would be a waste.
So I picked up a game with unknown (to me) issues and started debugging. Today’s pick was Street Fighter Alpha 3. After a bit of debugging, a quick look at various documents, as well as previous time consuming experience gave away what the issue was.
Hacking around with DMA interrupts for a few moments ended up in this:
Right, now all left to do is actually fix what causes the problem instead of hacking around it. Maybe when I’m not too bored to do it, or I should just leave it to drk||Razi (this was an inside joke).
So, what’s next? There aren’t many other stuff with problems I’m not aware of. Guess I should take a break…
Posted in nullDC | 2 Comments »
September 10th, 2009
Don’t you just hate it when you encounter a very strange bug that can’t be logically explained, you take lots of hours to trace/debug it and you end up finding out that the cause was at most one single line of code? That was the case here.
Some games would fail to “identify” the connected Visual Memory Unit (that’s the Dreamcast equivalent of a memory card with integrated LCD screen and clock). As a result they would not use any of the VMU features, they would still complain that there is no VMU connected and of course they would not be able to save/load game data.
So I took the time to debug the issue… and it turned out that the error was caused by something relatively minor. Wonder if all the games that had similar issues are fixed now. We’ll see I guess.
For the time being here is a pic of the game “Spawn: In the Demon’s Hand” after the bug was squashed.
Tags: card, dc, dreamcast, emulator, fix, memory, nullDC, vms, vmu
Posted in nullDC | 15 Comments »
September 6th, 2009
So there I was the other day taking a look at some of the issues on nullDC (ehm, you know, that Dreamcast emulator).
Of all the known issues the game D2 had one of the strangest ones. The game prompts you to swap discs at predetermined occasions but it fails to detect that the disc swap actually happens.
So I fire up the debugger, start the game and begin stepping/skipping instructions. Nothing comes up so I proceed to step 2, disassembling. After running through the disassembled code for some hours and marking/tracing relevant code I fire up the debugger again and start manipulating the game code… and voila:
Right, now we got the game to “detect” that we inserted the same disc… not really, but at least there is some sort of reaction.
What could be the “right” way to do this? Running through the disassembled code a bit more and taking a look at some documentation is enough to point out the most possible cause. Add to that drkIIRaziel’s code which is full of info messages and there you have the cause and the solution. Adding a quick ugly hack in the GD-ROM code proves that, the problem is solved and the game swaps fine. One problem gone, a billion remaining.
The end result is drk pointing out that the GD-ROM code needs another re-write… yeah, right, maybe next year or something.
Tags: D2, dc, dreamcast, emulator, fix, nullDC
Posted in nullDC | 1 Comment »