[Bejeweled 2] Unplayable Due To Crashing

[Unitorami]

Game or games this happens in

NPUG-30038 & NPEG-00036

What area of the game / PPSSPP

This happens in both standalone and RALibetro Core. Upon loading the dump, game will work about 1 in 5 times. It will always crash on loading title screen at around 90%. This makes it unplayable and frustrating for anyone who wants to give it a chance.

What should happen

It shouldn't crash.

Logs

https://forums.ppsspp.org/showthread.php?tid=3211 https://report.ppsspp.org/game/NPUG30038_1.00 https://report.ppsspp.org/game/NPEG00036_1.01

Platform

Windows

Mobile phone model or graphics card

Name: Radeon(TM) RX 580 | Driver Version: 30.0.13026.3

PPSSPP version affected

v1.12.3 and Latest RALibetro Core

Last working version

Sometime in 2014 seems to be the last time it worked fine.

Graphics backend (3D API)

OpenGL / GLES

Checklist

• [X] Test in the latest git build in case it's already fixed.
• [X] Search for other reports of the same issue.
• [X] Try resetting settings or older versions and include if the issue is related.
• [X] Try without any cheats and without loading any save states.
• [x] Include logs or screenshots of issue.

[anr2me]

On the USA version, if you put breakpoint on this write address 0x08a54204 (where the invalid address being stored) If the game managed to go to main menu without getting invalid address, this breakpoint won't be triggered on that subroutine (ie. probably not supposed to reach there yet aka. faulty), because normally the game will only write that address once right after the game launched, if there is a 2nd hit before reaching main menu, the game will get invalid address.

When this game runs properly, the address being stored in that location have a value of 0x08bxxxxx When this game stuck due to invalid address, the address being stored in that location have a value of 0x12xxxxxx (is this memory area being used on PSP? may be a mirror of another area?)

Btw, while it hit that "faulty" breakpoint and emulation got paused for awhile, suddenly i'm seeing the logs flooded with alot of "pixel" error messages (i don't remembered the exact message, something related to pixel/pixelmap), until eventually my monitor goes black screen (i run PPSSPP on windowed 1x), looked like there is leaks occurred while emulation is paused, probably on my geforce VRAM (since my monitor goes blank, and i'm using beta driver). And after my monitor shows something again (took a few seconds before the display restored), the Debug Log console window disappeared and i can't toggle it again to see the exact error message (i can still reset the game tho)

[anr2me]

Changing the CPU clock to 111 mhz or 333 mhz seems to be able to avoid getting invalid memory access, this game doesn't seems to work well with 222 mhz, but 200 mhz seems to worked fine too.

[unknownbrackets]

Hm, that indicates some sort of timing issue. Is it always user_main reading and writing from that address?

-[Unknown]

[anr2me]

Yes, all of them are from user_main thread Btw, that "Write32" near Invalid address didn't exist when the game runs properly, all of them supposed to be "Read32" The game stuck on this screen

This is the logs when i tried to log only the "Write" hit, while the "Read" hit logs supposed to flood in after the Dialog finished. The game is running fine and waiting for me to press Start

[unknownbrackets]

I guess it could be message dialog timing...

-[Unknown]

[Unitorami]

Thank you two for the responses on the issue.

Changing the CPU clock to 111 mhz or 333 mhz seems to be able to avoid getting invalid memory access, this game doesn't seems to work well with 222 mhz, but 200 mhz seems to worked fine too.

Is creating a patch perhaps an option for fixing this? Or will all players have to switch CPU clock in order to play the game?

[anr2me]

Thank you two for the responses on the issue.

Changing the CPU clock to 111 mhz or 333 mhz seems to be able to avoid getting invalid memory access, this game doesn't seems to work well with 222 mhz, but 200 mhz seems to worked fine too.

Is creating a patch perhaps an option for fixing this? Or will all players have to switch CPU clock in order to play the game?

It will be fixed when the devs have the chance to investigate it and find out what actually happened.

Changing the CPU clock is just a workaround if you wanted to play the game while waiting for a proper fix to be made.

[Unitorami]

Thank you two for the responses on the issue.

Changing the CPU clock to 111 mhz or 333 mhz seems to be able to avoid getting invalid memory access, this game doesn't seems to work well with 222 mhz, but 200 mhz seems to worked fine too.

Is creating a patch perhaps an option for fixing this? Or will all players have to switch CPU clock in order to play the game?

It will be fixed when the devs have the chance to investigate it and find out what actually happened.

Changing the CPU clock is just a workaround if you wanted to play the game while waiting for a proper fix to be made.

Understood. Thank you

[anr2me]

Changing MSG_INIT_DELAY_US to 200000,250000, or 350000 seems to fix this issue. I guess Dialog timings need to be accurate too to prevent the game from doing something at the wrong time (not sure whether 200ms is the accurate timing or not tho) May be a thread is interfering another thread during a critical session, and shifting the timing slightly avoid those threads from bumping each other at critical time.

[anr2me]

Using CPU core: Interpreter seems to work fine, might be because it gets low FPS during the loading scene.

And strangely, using IR Interpreter will crash PPSSPP due to exception during ~Read_U32~ ReadUnchecked_U32

PS: i'm not using Fast Memory, and JIT won't even crash PPSSPP on this game, may be this is one of the reason why iOS users gets crashes issue too often? because they use IR Interpreter

Edit: oops sorry it was ReadUnchecked_U32 instead of Read_U32 which have address validation

[unknownbrackets]

Is the IR crash any better here? IR always uses fast memory (ReadUnchecked instead of Read), for performance reasons. If you want memory access to be slower and not crash when the PSP would have crashed, you'll need to use interpreter or jit.

That said, I just added checks in #15879 so that if you turn off fast memory and turn off ignore illegal addresses, it won't crash. That might help debug where it's crashing if it still is.

-[Unknown]

[anr2me]

With Fastmem enabled on IR interpreter, it still crashed

With fastmem disabled blue screen appeared

But the PC address is slightly different than JIT

[anr2me]

When the game is working properly (ie. by changing the CPU clock to 55 mhz), this faded-out dialog should have disappeared before the loading progressbar started to move, while when the game have stuck or crash issue the dialog didn't disappeared yet

Btw, does dialog time supposed to be affected by CPU clock like that? i thought time is ticking at the same rate regardless of CPU clock from the game/PSP perspective

[hrydgard]

This may be related to #12044 which is also about a dialog timing problem.

[sum2012]

New option, Simulate UMD slow reading speed work !!!

[hrydgard]

That good, but is quite odd, since I think this was a PSN game, which never ran from UMD! So, it does seem likely that the timing problem is actually caused by something else.

However, I'm willing to enable it for this game for now, with a comment in the compat.ini file.

[hrydgard]

Enabled the workaround, punting further investigation to future versions.