Menu
▾
▴
1 Attachments
#154 game crashes with custom code in VBA-M but other emulators don't (???)
So hello, I hope I didn't miss the right ticket to report bugs :)
So what the problem is that I rewrote a routine that does internal sound rendering in Pokemon Emerald (German Version) and "sometimes" causes the game to crash with VBA-M (PC seems to get into unused memory areas above 0x10000000) and to reset after a while (when PC reaches BIOS area). It only seems to happen when closing the main Pokemon Menu (Start -> Pokemon). The amount of trys you need to get is crash can vary between 2 and ~100 (just open and close the Pokemon menu).
So the first thing you might tell me now is that I wrote some buggy code which causes the game to crash. I loaded the ROM in the VBA-SDL-H debugger and couldn't force a single crash and therefore I cannot analyze my code. I tried a few other emulators like the "old" VBA 1.8.0 and No$gba 2.7. I didn't have a single crash with those ones and I'm a little bit unsure if it's a problem with VBA-M or my code (or the repointed memory areas, nothing out of valid areas!!!).
I'll try to attatch an IPS file (patch) to give you my modified version of Pokemon Emerald GER (Code: BPED) and I'd really appreciate any help or advice you can offer me.
PS: If you want to I can offer you the source of my code.
It's located at 0xF00000 in ROM and gets loaded to IWRAM 0x03006380 upon ROM start and is executed in IWRAM.
Try a version prior to R 1170
Well, I tried R1149 but it failed as well.
What's up with the versions before R1170? Was there a special change in the emulator core?
Try Higan, i believe it uses the same GB_APU as us.
Higan doesn't seem to work with games that use 128k Flash Backup Memory. The game will always freeze right after the BIOS. I didn't find a way to adjust the save type so I couldn't test it on Higan :/
Last edit: ipatix 2014-05-21
This ticket can get closed now. There was nothing wrong with the emulator. Apperantly it has been an issue with the DMA registers I didn't consider.
Last edit: ipatix 2014-06-06
Okay, so years later I've got some more stuff to talk about. So back then I was apparently happy that I've found a workaround in my code (writing zeroes to the DMA3 regs) to prevent the issue (which doesn't really make any sense) but after some reinvestigation I've come to the conclusion there must be an issue with the emulator.
I wasn't able to reproduce this issue in No$gba Debugger 2.8f, higan v104 or mGBA. I've used a real BIOS with all of them.
So, one of the problems I have is debugging this. However, what I did find out is that after the game has crashed, the CPU is in IRQ mode and perhaps in SVC mode before. At the time of crash the CPU seems to have got an IRQ (which will call my DMA3 related code) coming in while an SWI (CpuSet) was active before. That's what I'm guessing from the SWI Logging + Register View. Also, the interrupt handler in the game will change from IRQ to user mode, so that must mean that either my code hasn't been executed yet or the end of the interrupt handler (and restoring of the IRQ mode) is reached already but will crash afterwards.
From what I've read in the GBATEK the BIOS will change to user mode for the actual execution of the SWI function and therefore I don't think it should be an SVC stack overflow (which would currupt user stack, ewwww). Sadly there is no possibility to check all the registers from all the different modes in VBA-M (or perhaps there is with the GDB interface, but I don't know how to use that) so I cannot see LR from the different modes. Unfortunatly large portions of the IWRAM including the stacks are completely corrupted (with data from CpuSet I think???) and therefore is of no use at the time of crash.
Anyway, with this additional information available, is there anything I can do for further investigation or do you have any new ideas about this?
project has moved to github, but the information provided might be useful to Normatt if you can turn the findings into a test rom.