Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pokemon Pinball (GBC) crashes #1000

Closed
Miss-Inputs opened this issue Feb 24, 2018 · 5 comments
Closed

Pokemon Pinball (GBC) crashes #1000

Miss-Inputs opened this issue Feb 24, 2018 · 5 comments
Labels
severity:bug Severe issues affecting multiple games severity:regression Issues that were not present in previous versions

Comments

@Miss-Inputs
Copy link

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
Copy link
Member

endrift commented Feb 24, 2018

Regressed in a949fdf.

@endrift
Copy link
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.

@endrift endrift added severity:bug Severe issues affecting multiple games severity:regression Issues that were not present in previous versions labels Feb 24, 2018
@ISSOtm
Copy link

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
Copy link
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
Copy link

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
Labels
severity:bug Severe issues affecting multiple games severity:regression Issues that were not present in previous versions
Projects
None yet
Development

No branches or pull requests

3 participants