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

[HatCat]

Fukkkk, for all I know, pokefan999 is the one who grabbed an e-mail address, logged onto IRC as "mudlord" and pretended to be him, and sent it to mupen64plus devs saying "Here, contact this guy and port his work over", that way he could see the message they posted on code.google and instantly know about it on the day that they posted it, so he could use it as "proof" that I have ever talked to them before.

Shit, man, that only proves that he's the one affiliated with them XD
This is his grand test to see if I care about mupen64plus nearly as much as he does

Burn the witch!

[shunyuan]

I find this line of code will hang Project64 2.0, if user click RSP configuration in menu before the emulator start.

EXPORT void CALL InitiateRSP(RSP_INFO Rsp_Info, unsigned int *CycleCount)
{
    if (CycleCount != NULL) /* cycle-accuracy not doable with today's hosts */
        *CycleCount = 0x00000000;
    RSP = Rsp_Info;
    *RSP.SP_PC_REG = 0x04001000 & 0x00000FFF;
    while (RSP.IMEM != RSP.DMEM + 4096)
        message("Virtual host map noncontiguity.", 3);
#ifdef SP_EXECUTE_LOG
    output_log = fopen("simd_log.bin", "ab");
#endif
    return;
}

Because Proejct64 2.0 will call InitiateRSP() first before call DllConfig(), and will create a dummy RSP_INFO and pass it to InitiateRSP().

But only debug version of your LLE RSP have DllConfig() function will trigger the infinite loop.

[the_randomizer]

Originally Posted by Pau

You lie again. The message was directed to you. Everybody can look at the receipents and see your mail address *****removed**** as the only receipent

Stop the incessant accusatory/defamatory statements, it's annoying. Create another thread so you can stop clogging this one.

[HatCat]

Originally Posted by suanyuan

I find this line of code will hang Project64 2.0, if user click RSP configuration in menu before the emulator start.

EXPORT void CALL InitiateRSP(RSP_INFO Rsp_Info, unsigned int *CycleCount)
{
    if (CycleCount != NULL) /* cycle-accuracy not doable with today's hosts */
        *CycleCount = 0x00000000;
    RSP = Rsp_Info;
    *RSP.SP_PC_REG = 0x04001000 & 0x00000FFF;
    while (RSP.IMEM != RSP.DMEM + 4096)
        message("Virtual host map noncontiguity.", 3);
#ifdef SP_EXECUTE_LOG
    output_log = fopen("simd_log.bin", "ab");
#endif
    return;
}

Because Proejct64 2.0 will call InitiateRSP() first before call DllConfig(), and will create a dummy RSP_INFO and pass it to InitiateRSP().

But only debug version of your LLE RSP have DllConfig() function will trigger the infinite loop.

True, what you said is definitely the case.

Well, I need some sort of way to check to make sure the emulator is not mapping them non-contiguously.

I know how to fix it, but, if it's just the debug version...heh.

Does it only happen on pj64 2.0 or other emulators?

[shunyuan]

Another question:

Is it possible to reset the RSP when the emulator is running? if it is possibe then how to do it?

For example the RSP interpreter try to process a task (a display list maybe), but unable to complete the task and need to abort in the middle. How does the RSP recover from this situation and skip the current task and continue to process next task?

[HatCat]

Originally Posted by nintendo1889

Stop the incessant accusatory/defamatory statements, it's annoying. Create another thread so you can stop clogging this one.

I don't even see that e-mail in the HTML source code of the page he linked.
It obviously doesn't exist.

Unless, I have to log in and be a Google member like him to see that e-mail??
Oooh, even more proof that he's affiliated with them, not me?

btw guys please don't quote that link in his post anymore lmao

[shunyuan]

Originally Posted by FatCat

True, what you said is definitely the case.

Well, I need some sort of way to check to make sure the emulator is not mapping them non-contiguously.

I know how to fix it, but, if it's just the debug version...heh.

Does it only happen on pj64 2.0 or other emulators?

If you can test LLE RSP on mupen64, then I guess no other emulator has this problem. 1964 will refuse to use a plugin without DllConfig().

[HatCat]

Originally Posted by suanyuan

Another question:

Is it possible to reset the RSP when the emulator is running? if it is possibe then how to do it?

For example the RSP interpreter try to process a task (a display list maybe), but unable to complete the task and need to abort in the middle. How does the RSP recover from this situation and skip the current task and continue to process next task?

That has to be coordinated by the CPU, assuming you are asking about resetting the RSP CPU while the main N64 VR4300 processor is still running.

No emulator can do that at the moment except *now* Project64 2.0.
Thanks to Project64 2.0 I can break out of the RSP, without setting SP_STATUS_HALT, and the CPU host will interpret that as a request to re-conduct the RSP microcode task and try executing it again with the updated information.

Unless I am not understanding your question.

Originally Posted by suanyuan

If you can test LLE RSP on mupen64, then I guess no other emulator has this problem. 1964 will refuse to use a plugin without DllConfig().

Mupen64 is the other emulator I used to test.
If DllConfig is required for 1964 than the debug DLL should load on it for testing it.

Well, I'll think about a solution.
But, InitiateRSP seems to be the best place to have the check.
But I'm all ears if you know a better place.

[shunyuan]

Originally Posted by FatCat

That has to be coordinated by the CPU, assuming you are asking about resetting the RSP CPU while the main N64 VR4300 processor is still running.

No emulator can do that at the moment except *now* Project64 2.0.
Thanks to Project64 2.0 I can break out of the RSP, without setting SP_STATUS_HALT, and the CPU host will interpret that as a request to re-conduct the RSP microcode task and try executing it again with the updated information.

Yes, this is what I ask.

if the emulator call DoRspCycles() and caught an exception (access violation ,LLE graphics errors or LLE audio erros) then how to recover from this situation and continue to process next RSP task?

Actually when I run Kirby 64 with LLE RSP on Project64 2.0 release build, I got exceptions when call DoRspCycles() that caused by graphic plugin.

[HatCat]

Originally Posted by suanyuan

Yes, this is what I ask.

if the emulator call DoRspCycles() and caught an exception (access violation ,LLE graphics errors or LLE audio erros) then how to recover from this situation and continue to process next RSP task?

Actually when I run Kirby 64 with LLE RSP on Project64 2.0 release build, I got exceptions when call DoRspCycles() that caused by graphic plugin.

Um, well, the RSP has to finish executing the task before the results are sent to the RDP, I think, so if the RDP emulator / Jabo's LLE gfx or z64gl raised a gfx plugin exception then it would likely be the responsibility of that RDP emulator to manage its own exception.

Maybe for Kirby64 the CPU is sending bad DMA addresses to the RSP, which might or might not be sent to the RDP, and the CPU recompiler/interpreter settings you are using might not be stable enough?