libretro
Pac-Man 2 The New Adventures - bug when trying play arcade
Hello. Thanks for reading my topic.
ROM name is Pac-Man 2 - The New Adventures (1994)(Ballistic - Namco)(US) (TOSEC Naming). In Stage 2 has an arcade allowing play Pacman and Jr Pacman arcade machines. When player select an arcade machine to play the screen is changed to arcade game, but is happening an bug the screen is changed to blank and freeze the emulation not allowing play the arcade being an error.
Have uploaded an screenshot and save state for rom USA version. Load the save state and try select the arcade machine.
Have an nice day.
Pac-Man 2 - The New Adventures (1994)(Ballistic - Namco)(US).state1.zip
Using hack CPU overclock to 125 % "fix" that bug. However not is the correct way to fix that issue.
Using the latest core available as of this writing (obtainable through the core downloader - 1.7.4 - 3c16987) the crash also occurs for me.
To test, simply input the password 'PCJRDPW' at the beginning. If the password works, Pac Man will give you the thumbs up, and you should see this screen:
Instead, here it fades to black and then well, it just stays black and never shows the above screen.
Tested with PicoDrive and BlastEm cores as well and the password/Jr Pac Man mini game works for both of them.
I know this is a known issue but I was under the impression it was fixed so maybe the bug reappeared at some point in the last 11 months or so.
Fixed upstream by https://github.com/ekeeke/Genesis-Plus-GX/commit/4529c8275b548385b4793375ef79016cb3c93609
For the record, this mini-game waits (at several spots) for the vertical interrupt flag to be set in vdp status, which requires the vdp status to be read just when the vertical interrupt is triggered but before it is being processed (as the flag is cleared by vdp as soon as interrupt is acknowledged by cpu).
But since the game is using a relatively long loop to do that, any slight variation of cpu timings in emulator could make him miss the short window where the flag is set. It works on real hardware as the CPU execution get slighly shifted each frame while the interrupt always occurs at exact same time in frame, so it eventually ends up reading the flag being set after a few frames.
Some emulators add a signicant delay between the flag being set and the interrupt occurence to fix games doing this but it is not really accurate. What linked commit above does is modifying 68k bus refresh delay emulation so it is less deterministic and makes the cpu execution shifting with time, similar to how it does on real hardware (but still not fully accurate).
@ekeeke Thanks for fixing ! You say some emulators try fix that issue using code not accurate. Perhaps MAME not does that 68k bus refresh delay for avoid that issue ? In MAME not happen that bug.
MAME sets VINT flag at the same time as VBLANK flag, at the start of line 224, which gives enough time for the game to read it set before VINT occurs and clears it... but is not accurate to real hardware
Please close this issue if you consider it fixed, only repo owner or issue author can do it.