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

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.
Original issue reported on code.google.com by ursula.a...@web.de on 18 May 2014 at 6:58
Attachments:
fix_guts.html
Javier19 / mupen64plus

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