EvilJagaGenius / jagoombacolor

Jaga's Goomba Color fork
102 stars 9 forks source link

Pokemon Polished Crystal romhack crashes with a DMA error #37

Open ShadowOne333 opened 10 months ago

ShadowOne333 commented 10 months ago

Trying to load up Polished Crystal (A Pokemon Crystal romhack) into Jagoomba Color throws an error message. For reference, here's the hack in question in case it's needed for debugging: https://github.com/Rangi42/polishedcrystal/releases/tag/v3.0.0-beta

When running the game through the emulator with the latest Jagoomba v5 (last version tested), the game does get to the title screen, but after pressing a button to get to the game menu screen, the following error message is shown:

image

Quoting one of Polished Crystal's developers, Rangi42, here's the issue with the game and Jagoomba:

IIRC the main feature Goomba is missing for PC support is DMA copying; PC actually checks some arbitrary bug with reading/writing rSC that happened to be incorrect for VBA and was easy to check, which is what I really wanted to discourage using.

It's worth noting also that the next version of Red++ (v4) will be using Polished Crystal as a base for having Gen 1 with the Gen 2 engine, so it might be worth the shot to add support for this for everyone interested in running those games without a specific GBC flashcart. I think this has been talked about before in GBATemp, and I found this message regarding possible debugging info of help:

... I thought I fixed HDMA. Urg. Upon further research it's being hung up on a bug with the blasted link cable? rSC EQU $ff02 ; Serial Transfer Control (R/W)

As an additional note, the message about "Please use a more accurate emulator" doesn't stop the game from running, it only gives a warning if the game does happen to crash, according to developer FIQ.

FredrIQ commented 10 months ago

The rSC thing is a VBA emulator check. Failing it doesn't crash the game, it only gives you a warning when you start a new game. However, if the game crashes for an unrelated reason, like what happened above (rst 0 is unused, so triggering it results in the above screen), will replace the "please report this bug" text with "use a more accurate emulator".

Just to make it clear that the emulator check isn't causing the crash.

You can find the source code for the hack at https://github.com/Rangi42/polishedcrystal which might assist in debugging. I do not have the hardware to run Jagoomba (mgba does not replicate the gba well enough to be a valid substitute) so I cannot personally debug this issue.

ShadowOne333 commented 10 months ago

I do not have the hardware to run Jagoomba (mgba does not replicate the gba well enough to be a valid substitute) so I cannot personally debug this issue.

I can do tests on my side using a real GBA with an EZ Flash Omega flashcart. If a test build arises, I would happily test it out with whatever the latest version of Polished Crystal is at the time.

michyprima commented 3 months ago

@FredrIQ so I've been stubborn about this the last two days, and I tried a few approaches which all failed. I was able to identify the commit that broke compatibility tho and it's this one. Older 3.0.0 versions get past the error just fine.

Of course that's a huge commit so after trying a few things that came to mind I had to (momentarily) give up.

Any suggestion on what I could look into? The game seems to crash right before the unown part of the intro starts after the "game freak presents". I can see 0000BFFF in the top left corner if I build the debug version of jagoombacolor which is triggered by a write to a bad address.

I've been trying to get this to work with NanoBoyAdvance which should be cycle accurate and I'm not ready to give up yet. haha

https://github.com/EvilJagaGenius/jagoombacolor/assets/4800403/1d4f2264-6905-464d-a210-b5d449f1c6dd

FredrIQ commented 3 months ago

Sorry for late response, was away for a time and came back to a huge list of unread mail, heh.

Only thing that comes to mind right away is that the commit changed the h-blank handler so that I could essentially run context-specific interrupt routines. This is done by the LCD interrupt doing a jr to hLCDInterruptFunction (note that the jr "underflows" pc since it jr-s to HRAM, which might be causing the issue?), which in turn is a jp instruction to wherever I actually wanted to go.

I don't think the commit tinkered with the intro animation code directly at all, so if it crashes there starting with this commit, it's likely one of the tweaks to the graphics routines, such as the above mentioned case.