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

[HatCat]

Originally Posted by suanyuan

Another bug I found with you rsp_mle, pilotwin64 will crash, and game show the debug info as picture below:



But if I use Zimlar's RSP 1.7.0.9, then the game can continue without problem.

save file:

Actually it seems to crash for me no matter what I do.

I load your save state.
I press A on "Next"
I go down to "Quit" which you highlighted in your screenshot
I press A
it freezes/hangs, no known escape

I am describing this on Project64 2.0 CPU interpreter (only RDB setting I changed) with zilmar's RSP 1.7.0.9 interpreter.


Maybe my rsp_mle.dll is relying on the CPU to send correct gfx hle data to the HLE video plugin, and the CPU core is what has the bug here?
Dunno, hard to tell if I can't reproduce it in the same way.

I can try to give more screenshots if you need.

[HatCat]

Originally Posted by Zera

Yeah, that's pretty much the crash I was talking about in your audio plugin thread. So it was a RSP issue?

I am using rsp_mle as well.

It even happens when I use my rsp_hle .dll, or zilmar's RSP HLE, where *nothing* gets executed on the RSP, only in the plugins.


There is something else affecting the crashing I think for you guys here.

[shunyuan]

Originally Posted by FatCat

It even happens when I use my rsp_hle .dll, or zilmar's RSP HLE, where *nothing* gets executed on the RSP, only in the plugins.


There is something else affecting the crashing I think for you guys here.

But HLE emulations only handle video and audio tasks, other type of tasks are still handled by RSP. Maybe this the difference between your RSP_HLE and Zilmar's RSP.

And if you use Zilmar's RSP 1.7.0.9, and don't use the save file, just start the game from beginning, it won't crash at exit of first level, no matter using interpreter or recompiler CPU core.

Anyway, it might be another bug of emulator CPU core.

[HatCat]

Originally Posted by suanyuan

But HLE emulations only handle video and audio tasks, other type of tasks are still handled by RSP. Maybe this the difference between your RSP_HLE and Zilmar's RSP.

But 95% of N64 games never use any RSP tasks other than those types.
So if you use rsp_hle.dll then only 5% of the time is there a chance anything ever gets executed on the RSP.


And, if it does, my RSP_HLE.DLL specifically notifies you with a message box window, telling you that a non-gfx, non-audio task was encountered.
Take Banjo-Tooie, for example. You start that game up; you get a message box telling you that the RSP_HLE must execute a new task type natively on the RSP.

Originally Posted by suanyuan

And if you use Zilmar's RSP 1.7.0.9, and don't use the save file, just start the game from beginning, it won't crash at exit of first level, no matter using interpreter or recompiler CPU core.

Tried that, doesn't crash on either plugin.
Neither RSP 1.7.0.9 recompiler nor my RSP MLE version.

[shunyuan]

Originally Posted by FatCat

And, if it does, my RSP_HLE.DLL specifically notifies you with a message box window, telling you that a non-gfx, non-audio task was encountered.
Take Banjo-Tooie, for example. You start that game up; you get a message box telling you that the RSP_HLE must execute a new task type natively on the RSP.

didn't test RSP_HLE yet.

Originally Posted by FatCat

Tried that, doesn't crash on either plugin.
Neither RSP 1.7.0.9 recompiler nor my RSP MLE version.

It is weird, but this game won't crash until you finish 1 level, and choose quit form menu. And the audio is still playing, just no response to input, and show the crash dump in screen. (tested with different gfx and audio plugins)

Maybe not related to RSP mle, but somehow Zilmar's RSP can avoid the crash.

[HatCat]

Sorry, but I don't know how to play this crazy-ass game without save states.
Just the intro is annoying the crap out of me.

I think I'd rather check the intro of K.I. Gold Unless you determined that was not an RSP issue (issue still there with pj64 rsp)??

I'll try downgrading to an older version like the ones you mentioned for the other ROM to see if it matters there.

[shunyuan]

Originally Posted by FatCat

Sorry, but I don't know how to play this crazy-ass game without save states.
Just the intro is annoying the crap out of me.

I think I'd rather check the intro of K.I. Gold Unless you determined that was not an RSP issue (issue still there with pj64 rsp)??

I'll try downgrading to an older version like the ones you mentioned for the other ROM to see if it matters there.

It is ok, but I think for the save state the memory has corrupted, so no matter which RSP will trigger the same crash.

And K.I. gold I think it is a RSP issue, because mupen64's rsp can run old version, but LLE RSP has problem with old version of K.I..

[HatCat]

Originally Posted by suanyuan

And K.I. gold I think it is a RSP issue, because mupen64's rsp can run old version, but LLE RSP has problem with old version of K.I..

But keep in mind that mupen64 rsp dll HLE's the RSP.
It never executes the RSP, not even for custom task types.
So it makes sense that a hand-written simulation of the ucode would avoid the crash.


Now for some reason, I'm running the (V1.0) version of K.I. Gold, yet I cannot get the intro to crash on my latest RSP.dll public release 3? I'm using the recompiler core, default Mupen64 CPU emulator settings for 0.5.1 as far as I can tell; I am not sure why it's crashing for you.

[shunyuan]

Originally Posted by FatCat

But keep in mind that mupen64 rsp dll HLE's the RSP.
It never executes the RSP, not even for custom task types.
So it makes sense that a hand-written simulation of the ucode would avoid the crash.


Now for some reason, I'm running the (V1.0) version of K.I. Gold, yet I cannot get the intro to crash on my latest RSP.dll public release 3? I'm using the recompiler core, default Mupen64 CPU emulator settings for 0.5.1 as far as I can tell; I am not sure why it's crashing for you.

It is weird.

Because the mingw32 build of rsp_mle works fine.

But the visual studio build of rsp_mle will crash.

I just use your project file in winbuild folder, and enable EXTERN_COM_LIST_GBI in config.h

/* Choose whether to define, or keep undefined, the above macros. */
#define MINIMUM_MESSAGE_PRIORITY    1 // show most messages of RSP weirdness
#define EXTERN_COMMAND_LIST_GBI // Not really recommended but user preference
// #define EXTERN_COMMAND_LIST_ABI // Not really significant but user preference
// #define SEMAPHORE_LOCK_CORRECTIONS // Recommended only for CPUs supporting it
// #define WAIT_FOR_CPU_HOST // Never use, except with some ROMs on Project64 2.
// #define SP_EXECUTE_LOG // For debugging only.  Keep it off to free CPU.
// #define VU_EMULATE_SCALAR_ACCUMULATOR_READ // experimental but needs tests

Even Killer Instinct Gold 1.2 will stuck in mupen64 5.1.

But same dll will work fine on project64 2.1 with Killer Instinct Gold 1.2.

So confusing.

[HatCat]

Bah, I thought I finished removing the files.
The binaries should be in this thread, not my Git repo.


In the meantime, while you are trying to find internal problems with my RSP emulator, I would advise against using rsp_mle.dll; the only thing to test about that file is to see if an error comes up saying a game tried to use DPC_STATUS_FREEZE, which for some reason zilmar always clears before doing gfx tasks in HLE from the video plugin which is what we're trying to find out why and where it gets used.

But just plain rsp.dll should be enough.
The more things that are HLE'd, the less likely a crash will happen internally within my RSP emulator, and not somebody else's plugin, so just test rsp.dll in those cases.

Now, the GNU build is rsp.dll.
The Microsoft Visual Studio build, compiled as C++, is rsp_free.dll and has no dependencies whatsoever (not even user32.dll/kernel32.dll).

I would suggest comparing between those.