PS2 Retroarch Fix Core GBA

[andres0021]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

[Description of the bug]
Hello, good afternoon. I wanted to ask if there are plans to fix the GBA core freezes for PS2. The core has had problems since it was included in RetroArch for PS2. I wanted to know if there is a solution. I hope you can answer. I clarify that the freezes happen in all GBA games, randomly, for a few seconds or minutes. Greetings!

Expected behavior

[What you expected to happen]

Actual behavior

[What is actually happening]

Steps to reproduce the bug

1. [First step]
2. [Second step]
3. [and so on...]

Bisect Results

[Try to bisect and tell us when this started happening]

Version/Commit

You can find this information under Information/System Information

• RetroArch: [version/commit]

Environment information

• OS: [The operating system you're running]
• Compiler: [In case you are running local builds]

[andymcca]

This issue will likely get closed by a moderator because it will be deemed a core issue, not a Retroarch issue.

I can give a little insight into this @andres0021 because as you know we have discussed this issue before.

From my testing I believe the issue is linked to cache clearing/invalidation. In the gpsp dynarec, every time a block is translated into native code, we flush/invalidate the CPU cache using platform specific code. For the PS2, this takes the form of FlushCache(0) to flush/invalidate the dcache and FlushCache(2) to invalidate the icache.

If the current block has already been translated then we won't do the above because there is no need - the correct native code will already have been committed to memory via the flush routine above.

If I change the function so that we DO flush after each block unconditionally i.e. whether or not we have to translate the block, then the intermittent crashes you describe go away. At the cost of a massive speed-hit of course because we're effectively making the cache redundant.

So I SUSPECT there is another device somehow invalidating the dcache periodically without performing a writeback (this would be a Flushcache(1) or Flushcache(3) command or equivalent) which then trashes the recently written dynarec code which is still sitting in the cache. This MIGHT be something like the audio driver in Retroarch, rather than a gpsp issue.

Happy for someone to tell me that all of the above is rubbish 😆 Also - I believe the Picodrive core has a dynarec on PS2 and doesn't have this issue?

[andres0021]

It all sounds very complicated, you can't even imagine how much I want to play GBA on Retroarch PS2 haha. But do you think something can be done? Or have they already given up on it? El sáb., 5 de octubre de 2024 8:46 a. m., andymcca ***@***.***> escribió:

…

This issue will likely get closed by a moderator because it will be deemed a core issue, not a Retroarch issue. I can give a little insight into this @andres0021 <https://github.com/andres0021> because as you know we have discussed this issue before. From my testing I believe the issue is linked to cache clearing/invalidation. In the gpsp dynarec, every time a block is translated into native code, we flush/invalidate the CPU cache using platform specific code. For the PS2, this takes the form of FlushCache(0) to flush/invalidate the dcache and FlushCache(2) to invalidate the icache. If the current block has already been translated then we won't do the above because there is no need - the correct native code will already have been committed to memory via the flush routine above. If I change the function so that we DO flush after each block unconditionally i.e. whether or not we have to translate the block, then the intermittent crashes you describe go away. At the cost of a massive speed-hit of course because we're effectively making the cache redundant. So I SUSPECT there is another device somehow invalidating the dcache periodically without performing a writeback (this would be a Flushcache(1) or Flushcache(3) command or equivalent) which then trashes the recently written dynarec code which is still sitting in the cache. This MIGHT be something like the audio driver in Retroarch, rather than a gpsp issue. Happy for someone to tell me that all of the above is rubbish 😆 Also - I believe the Picodrive core has a dynarec on PS2 and doesn't have this issue? — Reply to this email directly, view it on GitHub <#17076 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO7AR7CPMSKNUX667SRVSUDZZ7GSDAVCNFSM6AAAAABPMOIRBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGAZDSNZTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[andymcca]

I wouldn't say anyone has given up on it - it's just that I don't think anyone has spent a lot of time looking into it except me 😆

I will keep looking at it when I can but it is very time-consuming and I don't have a lot of spare time. But it is an intriguing issue for me so I keep coming back to it. It would be great if someone who is more familiar with PS2 Dev would look into it as I am definitely not a PS2 developer!

There are cache-related issues with a handful of PS2 games which make them difficult to emulate (e.g. Dead or Alive 2), because PCSX2 doesn't emulate the cache by default but those games rely on it to function correctly. This is kind of the reverse of that, because I think David told me before that the gpsp core works on Retroarch if you run it on PCSX2, so that makes me think even more that it's a cache issue.