New LLE RSP Plugin (accurate, fast but untested?)

[shunyuan]

Originally Posted by FatCat

Ah, I might have forgotten something.

In RunRSP you applied this:

void RunRSP()
{
	unsigned int TaskType;

	// clear all registers
	memset(&RspRegs, 0, sizeof(RspRegs));
...

Again, I have no HLE-in-the-plugins experience here, but this raises a couple questions to me.

First, most of the RSP registers are powered on to a randomized/undefined state and value. The exceptions include the 8 RSP accumulator segments and some bits of the system control (CP0) registers and status flags.
The game software is always responsible for initializing these registers after system startup, or else their value is undefined (not necessarily zero'd).

So is it really necessary to zero the memory for RspRegs every time there is an RSP task to execute?

--------

Second, I'm not sure whether this check is really necessary.

	TaskType = *((unsigned int *)(RSP.DMEM + 0xFC0));

	if (TaskType == 2)
		run_microcode();

When the CPU host knows there is a SP task, it tells the RSP plugin first.
If the RSP plugin judges it to be a audio task, it can request your audio plugin to HLE it.

So you're checking here to make sure it's an audio task in case the RSP plugin was wrong about it being an audio task.
This is stable and safe and fine, but slower because your if() causes an extra branch every time we want to run something in HLE.

The branch frame could be worked around like this:

if (TaskType != 2)
    // MessageBoxA(NULL, "RSP thought this task was aud?", NULL, 0x00000030);
    return;
else
    run_microcode(); // Rename this to `run_task()` for my next release

Some of that other code (clear SP_STATUS_HALT, reset the program counter) might also be obsolete/redundant since the main CPU (pj64) or indirectly the RSP plugin itself is responsible for maintaining that security, but again you might keep it there just to be safe.

Thanks, got it.

[shunyuan]

Originally Posted by FatCat

The implementation seems simple enough to secure, though I don't really know any experience with setting up audio HLE from a LLE RSP.

I see you based off a new template of zilmar's InitiateRSP off the one from the plugin specs, using only the elementary pointer symbols needed for audio, DMA and such.

I was curious if this would work in your audio HLE plugin?

// #undef  SEMAPHORE_LOCK_CORRECTIONS
/* The CPU-RSP semaphore is a lock defining synchronization with the host.
 * As of the time in which bpoint reversed the RSP, host interpretation of
 * this lock was incorrect.  The problem has been inherent for a very long
 * time until a rather recent update applied between Project64 1.7:2.0.
 *
 * If this is on, 1964 and Mupen64 will have no sound for [any?] games.
 * It will be almost completely useless on Project64 1.6 or older.
 * The exception is HLE audio, where it will work for almost every game.
 *
 * Keep this off when using audio LLE or playing games booting off the NUS-
 * CIC-6105 chip (also uses the semaphore); keep it on with Project64 2.0.
 */

#define SEMAPHORE_LOCK_CORRECTIONS // Recommended only for CPUs supporting it

To execute on LLE it needs Project64 2.x's CPU, but I'm not sure what happens if you try it in HLE...

For your own analysis, this macro is only used in $(rsp)/su/cop0/mfc0.h, reading from SP_SEMAPHORE_REG.

I have question for this part. Inside audio plugin, there are no way to get the rsp context. Since at InitiateAudio (AUDIO_INFO Audio_Info), all the information passed to audio plugin has nothing to do with RSP.

typedef struct {
	HWND hwnd;
	HINSTANCE hinst;

	BOOL MemoryBswaped;    // If this is set to TRUE, then the memory has been pre
	                       //   bswap on a dword (32 bits) boundry 
						   //	eg. the first 8 bytes are stored like this:
	                       //        4 3 2 1   8 7 6 5
	BYTE * HEADER;	// This is the rom header (first 40h bytes of the rom
					// This will be in the same memory format as the rest of the memory.
	BYTE * RDRAM;
	BYTE * DMEM;
	BYTE * IMEM;

	DWORD * MI_INTR_REG;

	DWORD * AI_DRAM_ADDR_REG;
	DWORD * AI_LEN_REG;
	DWORD * AI_CONTROL_REG;
	DWORD * AI_STATUS_REG;
	DWORD * AI_DACRATE_REG;
	DWORD * AI_BITRATE_REG;

	void (*CheckInterrupts)( void );
} AUDIO_INFO;

So if audio plugin wants to take advantage of SP_SEMAPHORE_REG, no matter to use LLE RSP or not, how to get that semaphore register?

[HatCat]

Honestly I don't know lmao

But, in `mfc0.h` where your HLE audio pre-compiles the microcodes for doing HLE, are already several instances of the RSP registers being read from.

Somehow (I really don't know how.) your audio HLE plugin is already simulating those reads from the SP system control registers, so whatever method was already being done for that, maybe it could be done for updating the SP_SEMAPHORE_REG lock algorithm in the manner defined in that file.

[shunyuan]

Originally Posted by FatCat

Honestly I don't know lmao

But, in `mfc0.h` where your HLE audio pre-compiles the microcodes for doing HLE, are already several instances of the RSP registers being read from.

Somehow (I really don't know how.) your audio HLE plugin is already simulating those reads from the SP system control registers, so whatever method was already being done for that, maybe it could be done for updating the SP_SEMAPHORE_REG lock algorithm in the manner defined in that file.

Because I have my own copy of RSP registers in audio plugin, defined at rsp_interface.c.

/************************************************************************** 
 * rsp_interface by Shunyuan
 *
 * A simple interface for LLE RSP to make other module can use RSP engine
 * 
 * NOTE: The LLE RSP is written by CDX4 (Iconoclast).
 ***************************************************************************/
#include <Windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "rsp.h"

RSP_REGS	RspRegs;
RSP_INFO	RSP;

static void DummyFunc(void) {}

void InitiateRSP(unsigned char *RDRAM, unsigned char *DMEM, unsigned char *IMEM)
{

[HatCat]

Yeah I saw that; I just didn't think how audio plugin would access it.
I guess RspRegs is meant to be more than just some virtual typedef; it should be an entirely separate machine instance for replicating on the audio.

So it would be: `*RspRegs.SP_SEMAPHORE_REG`.

But all you would have to do is un-comment the #define by `// #define SEMAPHORE_LOCK_CORRECTIONS` in config.h, and I think it would apply the change for you in the HLE audio compiler.

If it does the whole thing out in LLE first while compiling though then it might still be broken....

[shunyuan]

Originally Posted by FatCat

Yeah I saw that; I just didn't think how audio plugin would access it.
I guess RspRegs is meant to be more than just some virtual typedef; it should be an entirely separate machine instance for replicating on the audio.

So it would be: `*RspRegs.SP_SEMAPHORE_REG`.

But all you would have to do is un-comment the #define by `// #define SEMAPHORE_LOCK_CORRECTIONS` in config.h, and I think it would apply the change for you in the HLE audio compiler.

If it does the whole thing out in LLE first while compiling though then it might still be broken....

Thanks, I got it.

[mesk14]

Originally Posted by FatCat

I actually just finished doing that a few days ago. But feel free to play OOT anyway, haven't done MM yet.

No problems? Were you able yo complete the game? Did you use z64gl? Ill probably play MM instead,as I was only going to play OoT to help test the plugin.

[HatCat]

Originally Posted by mesk14

No problems? Were you able yo complete the game? Did you use z64gl? Ill probably play MM instead,as I was only going to play OoT to help test the plugin.

I did use z64gl, though atm it seems that packing my computer up and taking it with me to another state might have interfered somehow...I can only start games using Jabo's Direct3D LLE and not z64gl LLE.

Haven't worried about it much to isolate why.

I was able to complete the game just fine.
I did run into some "Weird addr." warning messages along the way, but they turned out to be unpredictable/random because re-loading saved states to try to get the errors to pop up again failed. They were probably caused by the VR4300 host CPU recompiler core and not my RSP interpreter.

So yes, completely playable.

But Zelda Majora's Mask!
My favorite game, didn't run it yet to find out.

Zelda MM however is unplayable on ziggy's RSP plugin for z64gl.
He and Ville Linde of MAME omitted the almost-never-used BLTZAL scalar operation, but angrylion eventually added it back in. I based my implementation off the official MIPS R4000 manual at the time.

So !
Can't play Zelda MM in LLE without using my RSP plugin or maybe zilmar's RSP (recompiler/interpreter?).

[HatCat]

Studies show that assembly output is optimized better when I vectorize the split steps in a vector operation.

For example, a traditional Vector Multiply emulator, does

VMUL.cond ::

for (int i = 0; i < 8; i++) {
    multiplyElements();
    storeProductToAccumulator();
    WBAccToVRFile();
    UpdateVCF(); // set/clear vector control flag registers, if needed
}

Parallelization of the simultaneous vector hits is better achieved and optimized by splitting the loops:

register int i;

for (i = 0; i < 8; i++)
    multiplyElements();
for (i = 0; i < 8; i++)
    storeProductToAccumulator();
for (i = 0; i < 8; i++)
    WBAccToVRFile();
for (i = 0; i < 8; i++)
    UpdateVCF(); // again, only if non-SGI VU uses these in VMUL

While some of the SGI versions convert from the scalar-limited Intel PCs easily enough (Vector Logical :: [N]AND/OR/XOR), others (Vector Select/Clip and the Vector Add group :: VADD/VADDC/VSUB/VSUBC/VABS/VSAR) do not.

static void VADDC(int vd, int vs, int vt, int e)
{
    unsigned int result[8];
    register int i;

    VCO = 0x0000;
    for (i = 0; i < 8; i++)
        result[i] = (unsigned short)VR[vs][i] + (unsigned short)VR_T(i);
    for (i = 0; i < 8; i++)
        VACC[i].s[LO] = (short)result;
    for (i = 0; i < 8; i++)
        VCO |= (result[i] > 0x0000FFFF) << i; /* (result[i] >> 16) << i */
    for (i = 0; i < 8; i++)
        VR[vd][i] = VACC[i].s[LO];
    return;
}

Let `result` be a software vector register of n=8 elements, 32 bits wide, storing the additive computational result of the zero-extended 16-bit shorts VS and VT, of two vector registers respectively of the n=8 elements =16b wide vector register file.

If the `VR_T(i)` macro is defined to indicate a shuffled vector/scalar coefficient, the compiler could optimize the very first loop to be a single SSEz vector instruction on the Intel machine.

This is the accurate way to do it because the documentation says so. Obviously it would be faster (but less accurate) to say, shift `result[i]` over by 16 bits. The result is either going to be 0 or 1, so mask that into VCO.

Only because, summation of 2 non-sign-extended 16-bit-wide registers, can never exceed 0x0001FFFE.

[the_randomizer]

If you need more testing, just say the word