Here is what is going on, offsets for SLUS_212.68Ģ problematic places are 0x4155B0, 0x415668 where CTC2 zero, vi05 is done. Sadly i don't understand why this happening. I found problematic runtimes on EE, and on VU. I looked today into that issue, and is definitely VU issue. You can step in and try to figure out what the VU tries to accomplish.īoth ways sound horrible from my point of view.
Pcsx2 slow motion fix code#
Probably it initiates some recompiled code in the VU. Then one can try to find out which program is changing this value and go deep into the nasty code.Īnother way could be to use a debugger and check what EE does when it is not waiting. One could try to find the responsible address and fix it to either 1 or 0 to achieve something similar as the VU cycle stealing hack or freeze the emulation completely.
However there will be probably hundreds of values with similar behavior. Everytime before a frame is emitted some bit has to change 01 as the wait condition in the EE thread (probably somewhere in VU0) is satisfied. However the issue can be in the VU component or one of the components feeding it. Then the origin for the EE wait is probably known. At least some asymmetry should appear (Asymmetry can also occur due to the different use of VU0/1).
Accordingly case 1) should be faster than case 2). I think MTVU only separates VU1 but not VU0 and such it doesn't help when VU0 is blocking the emulation. If you want you can check whether there is a difference betweenĪpparently VU cycle stealing does something to the process so one of both VU components have an issue.
0 kommentar(er)
