0.5.8 - Regression in paraLLEl RSP
bladeSk opened this issue · 13 comments
Banjo Tooie (U) is broken when using paraLLEl RSP + RDP, this can be seen right at the beginning, in the intro sequence.
0.5.7 - correct behavior:
0.5.8 - the camera is stuck in the wrong place:
Thanks for reporting this issue!
I might've missed a mupen64plus-core patch needed by the new parallel-rsp changes, can you try the following build to see if that fixes it for you? https://github.com/Rosalie241/RMG/actions/runs/8452095843
Thanks for responding so quickly. Unfortunately, the issue persists. I tried the portable Windows build without changing any settings besides selecting both paraLLEl plugins.
Thanks for your reply, can you try copying the parallel rsp plugin from a v0.5.7 build to the v0.5.8 build to see if that fixes it aswell?
Yep, it works when using mupen64plus-rsp-parallel.dll from 0.5.7 in 0.5.8.
After chatting with m4xw who maintains the parallel-rsp repo, I've managed to bisect the issue and we've merged a temporary workaround for the issue, can you try the following build to see if that fixes it for you aswell?
Excellent, that fixed it!
I suspect that PARALLEL_INTEGRATION might not be defined for the mupen build, but the code behind that IFDEF is still needed for mupen due to it emulating the RSP synchronously.
I suspect that
PARALLEL_INTEGRATIONmight not be defined for the mupen build, but the code behind that IFDEF is still needed for mupen due to it emulating the RSP synchronously.
it is defined, you can see the small cmake changes for the mupen64plus plugin here: https://github.com/Rosalie241/parallel-rsp/tree/RMG
Hmm, it looks like it is broken on ParaLLEl as well, but it shouldn't be caused by these changes. I'll investigate further what's happening and is the issue is with parallel-rsp or with mupen/parallel core. I assume its with the emulator core.
It looks like the RSP is spinning on the semaphore register, waiting for the CPU to set it. To avoid freezing when a program does exactly this, the emulator will yield back to the CPU after too many reads from the RSP CPU0 status register or reads from the semaphore register when it is locked (value 1). Then semaphore is then released by the CPU, and then next time the RSP is run, it can continue on.
This is how it's supposed to work, and is exactly what's happened in parallel-rsp; however, this camera issue appears. Changing the behaviour so that the RSP never actually locks the semaphore-- which is what you are doing here-- fixes this bug you are seeing; however, this is not correct behaviour.
It assume this hack to not correctly emulate the test-and-set behaviour of the semaphore register is just fixing some other unknown inaccuracy by introducing a new inaccuracy that happens to bypass the true bug.
I'll continue looking into this, but simply removing the lines like in this PR is absolutely not a long term fix, and may actually break other things, as synchronization between the RSP and CPU is now broken when using the semaphore register for that purpose.
I know it's a bandaid fix, but before your PR, didn't it do the same anyways, i.e not do the semaphore thing?
I've got a proper fix I'm working on that's emulator core side. The core needs to resume RSP execution when it writes to the RSP semaphore register and the previous value was non-zero