Support non-cycle accurate way to do better non stalling RSP execution

[richard42]

Originally reported on Google Code with ID 614

Some roms seem to hang with mupen64plus even when using cxd4 (with RSP-CPU semaphore
lock and "wait for CPU host").

Alright, I've just finished having a closer look into zilmar's $project64 Git, and
I believe I've isolated EXACTLY why he was able to bypass the lack of cycle-accuracy
which cxd4 RSP emulator was able to take advantage of (as well as his, of course).

(Note that I almost never have cared about or looked at the Project64 
source code myself, so I lack the experience to answer questions about 
most of his C++ code, or probably any C++ code for that matter. :P)
Here is the excerpt you might want to take a look at the attached code snipped

The guts of the fix are in bold italicized font near the very bottom of the page.

Why is this a fix?
Because the highlighted code is checking if neither HALT nor BROKE bits were set by
the RSP *after* DoRspCycles finished executing the microcode task within my RSP emulator.
 Now, ordinarily, as you might already know, anytime a RSP task finishes, it unconditionally
*MUST* have the HALT bit set (and 99% of the time, the BROKE status, too), or it can
never have escaped the RSP CPU loop to begin with, which would remain infinite until
HALT was eventually set.

So my trick in my RSP emulator is, if CFG_WAIT_FOR_CPU_HOST or CFG_MEND_SEMAPHORE_LOCK
were enabled, when MFC0 (defined at $rsp/su.h::94) gets requested to extract a scalar
read of SP_SEMAPHORE_REG, or SP_STATUS_REG, I also will prematurely set the HALT bit
right away and terminate any further execution of the RSP execution CPU loop.  Now,
this breaks the main `while` loop in $rsp/execute.h, but does not end the execute function
straight away.  Just outside past the body of that loop, I reverse my setting of the
HALT bit by clearing it.  This way, I am able to HALT the RSP, while "wrongly" making
sure that the HALT status in SP_STATUS_REG is not set.

This sounds weird/wrong, but it is the way that Project64 2.x detects that we want
to RESTART THE RSP TASK FROM THE VERY BEGINNING, with the updated host CPU's proper
data available to the RSP this time to prevent the permanent semaphore waiting loops.
 There you have it:  The high-level explanation of this, is that we want the CPU host
(Mupen64Plus) to be able to restart the RSP task from the very beginning (cxd4 still
handle remembering the SP_PC_REG val where it should resume) with the correct appointment
of CPU host data sent by Mupen64Plus or pj64 this time.  This is the science behind
the "cycle-accuracy" timing simulation hack fix.

This fixes roms like: Boss Games, Gauntlet Legends etc. stalling, but will lose a couple,
maybe a few VI/s from the interpreter speed.

Reported by ursula.abendroth@web.de on 2014-05-18 18:58:24

---

• _Attachment: fix_guts.html_

[richard42]

Original bug report is from cxd4/RJ/badcat/Fatcat/Iconoclast. Thats why "my" is appearing
in the text.

Reported by ursula.abendroth@web.de on 2014-05-18 19:02:39

[Papermanzero]

This issue is relevant for the CPU<->RSP Synchronisation. https://groups.google.com/forum/#!topic/mupen64plus/yO43UlpV_2Y

[loganmc10]

I would love to see this worked out. It seems like the last (public) attempt at getting these games to boot was in 2010. I tried to follow along with what cxd4 was saying and I tried something like this:

If doRSPCycles returns and SP_STATUS_HALT is still 0, then re-run it. I tried doing it different ways, but I could never get it to work properly. It never seemed to exit the loop in WDC. doRSPCycles would never return with SP_STATUS_HALT set.

I tested this with rsp-cxd4 and CFG_MEND_SEMAPHORE_LOCK enabled. I assume there is some data that needs to be reset/set before re-entering doRSPCycles, but I'm not sure exactly what that is.

[Papermanzero]

angrylion would be a good contact to see how to improve the behavior. The discussion is pretty old, but I guess no one worked on the optimisation of the RSP behavior. http://www.emutalk.net/threads/43088-Zilmar-s-RSP-spec-two-questions

[loganmc10]

I need to play around with it a bit more, but I got it booting!

[Papermanzero]

This is amazing! Congratulations.

[loganmc10]

This is fixed and can be closed now