Pokemon Pinball (GBC) crashes #1000

Closed
Zowayix opened this Issue Feb 24, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@Zowayix

Zowayix commented Feb 24, 2018

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:
pokemon pinball usa rumble version sgb enhanced gb compatible -0

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

This comment has been minimized.

Show comment
Hide comment
@endrift

endrift Feb 24, 2018

Member

Regressed in a949fdf.

Member

endrift commented Feb 24, 2018

Regressed in a949fdf.

@endrift

This comment has been minimized.

Show comment
Hide comment
@endrift

endrift Feb 24, 2018

Member

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.

Member

endrift commented Feb 24, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ISSOtm

ISSOtm Feb 25, 2018

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 commented Feb 25, 2018

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

This comment has been minimized.

Show comment
Hide comment
@endrift

endrift Feb 25, 2018

Member

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

Member

endrift commented Feb 25, 2018

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

@ISSOtm

This comment has been minimized.

Show comment
Hide comment
@ISSOtm

ISSOtm Feb 25, 2018

Then what is the correct behavior ?

ISSOtm commented Feb 25, 2018

Then what is the correct behavior ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment