Pokemon Pinball (GBC) crashes

[Zowayix]

In the latest mGBA nightly build, Pokemon Pinball will crash in about a few seconds of gameplay. The menu and Pokedex seem to be fine, but as soon as you actually start playing, it'll just crash seemingly randomly, and reset to a corrupted palette, like this:

This doesn't seem to happen in 0.6.1, just at some point between then and the latest nightly build.

There doesn't seem to be any particular thing that triggers the crash, though the ball falling down the middle seems to always crash, if it hasn't crashed before then. My first theory was that it was rumble-related, but sometimes the ball ends up hitting one of the bumpers and I can feel a (pretty weak) rumble on my controller (Logitech F710), so that part's fine.

It'll even crash after a while if you just leave the ball there at the beginning and never launch it.

Tested on European, USA, and Japanese versions just to make sure; it all happens.

mGBA build: 0.7-5037-523fb63c (compiled from the most recent git)
PC specs:

• PC 1: Xubuntu 17.10, Intel i7-3720QM @ 2.6GHz, integrated Ivy Bridge graphics
• PC 2: Antergos (fully updated), AMD A4-1200 @ 1GHz, integrated AMD 8180G

I think that should be everything I needed to mention.

[endrift]

Regressed in a949fdf.

[endrift]

Regressed in a949fdf.

[endrift]

This is a really weird case because it's sitting on an edge case in interrupt handling that I don't know how to deal with properly:

B: 15 C: 67 (BC: 1567)
D: 01 E: 70 (DE: 0170)
H: FF L: FF (HL: FFFF)
PC: 0565 SP: DFF7
ROM: 03 RAM: 00 WRAM: 01 VRAM: 00
[Z-H-]
00:0565:  3600	ld [hl], $00

It writes $00 to IE to try to disable interrupts but sometimes it does this at the same time as an IRQ firing. There's a small window where the IRQ has been asserted so the hardware will jump to the interrupt vector as soon as the instruction is over but the instruction can write to the interrupts enabled register before it ends. When this happens it jumps to 0 because it sees and interrupt was asserted but it can't find the interrupt vector associated.

[endrift]

This is a really weird case because it's sitting on an edge case in interrupt handling that I don't know how to deal with properly:

B: 15 C: 67 (BC: 1567)
D: 01 E: 70 (DE: 0170)
H: FF L: FF (HL: FFFF)
PC: 0565 SP: DFF7
ROM: 03 RAM: 00 WRAM: 01 VRAM: 00
[Z-H-]
00:0565:  3600	ld [hl], $00

It writes $00 to IE to try to disable interrupts but sometimes it does this at the same time as an IRQ firing. There's a small window where the IRQ has been asserted so the hardware will jump to the interrupt vector as soon as the instruction is over but the instruction can write to the interrupts enabled register before it ends. When this happens it jumps to 0 because it sees and interrupt was asserted but it can't find the interrupt vector associated.

[ISSOtm]

The previous version dealt with this by not jumping at all (since it didn't enter any if blocks), and that seems like correct behavior, according to the documentation I read / stuff I've heard about how the CPU works.
I guess you could check whether (IF & 0x1F) == 0 (since the other bits aren't considered by the interrupt processing), and not call LR35902RaiseIRQ (https://github.com/mgba-emu/mgba/blob/master/src/gb/gb.c#L622) if that's the case. The check could even be merged with the if just prior.

[ISSOtm]

The previous version dealt with this by not jumping at all (since it didn't enter any if blocks), and that seems like correct behavior, according to the documentation I read / stuff I've heard about how the CPU works.
I guess you could check whether (IF & 0x1F) == 0 (since the other bits aren't considered by the interrupt processing), and not call LR35902RaiseIRQ (https://github.com/mgba-emu/mgba/blob/master/src/gb/gb.c#L622) if that's the case. The check could even be merged with the if just prior.

[endrift]

That is not the correct behavior, as discovered by @LIJI32. That patch was an attempt to fix the behavior.

[endrift]

That is not the correct behavior, as discovered by @LIJI32. That patch was an attempt to fix the behavior.

[ISSOtm]

Then what is the correct behavior ?

[ISSOtm]

Then what is the correct behavior ?