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

[HatCat]

I forgot about that game.

I was trying to remember a list of games using non-conformist ucodes so I could check them all and implement the case-specific endian decoders for quickly writing as many of the DMEM bytes simultaneously at once where possible. (Not very portable/readable code but definitely fast and could still work in a CA env.)

I don't know this game very well so I'm hoping it's near the start where I don't have to figure out how to play to get to it?

Also just for reference, when I say "illegal element/addr", obviously it does not mean an invalid RSP instruction, just that the documentation says it is not a legal operand for the assembler to generate (could have been hard-written by SP DMA for instance). Without exception handling facilities they are still technically legal; I would rather be notified of games attempting it though.

To implement it tho! Need to find where in the game it does this....

[angrylion]

It does this at the beginning, before showing anything.

[HatCat]

Have updated the plugin once again.
As usual for the list of changes check the forum change log.

Thanks to suanyuan, angrylion and dsx! with information into making this update.

[GPDP]

While testing out the various versions of this plugin (latest version as of this post, of course) using Ocarina of Time (NTSC version 1.0), I came across a few error messages which then resulted in the emulation not progressing past a black screen.

Using a combination of an HLE video plugin (tried Jabo's 1.7.0.57, Glide64 for PJ64, and SoftGraphic 1.2) and Shunyuan's HLE audio plugin with the HLE RSP plugin, I get the following OStask.type messages, followed by a black screen with ***CPU PAUSED*** at the bottom:

8BC43B5D
00000004

Oddly enough, clicking on another window, then back to the Project 64 window makes the emulation progress as normal. I can get into the main menu, but if I choose a file and try to load it, it immediately brings another OStask.type message up saying 00000004. Trying the earlier trick only results in this message popping up again no matter how many times I do it.

I then tried using the LLE version with both Jabo's plugin and z64gl along with Shunyuan's audio, and I had no issues at all. Then I tried MLE with Jabo's DirectSound and both Jabo's Direct3D and Glide64, and again no issues. Same for the fully LLE rsp.dll plugin. Only HLE gives me the errors.

I then tested this combination with many of my other games, and of those, Conker's BFD, Donkey Kong 64, Majora's Mask, and Perfect Dark all give me similar issues and errors, though not all showed the 00000004 message, only 8BC43B5D, and I was able to play most of them. OoT seems to be the only one that refuses to enter the game outright. Games like Super Mario 64, Super Smash Bros., Mario Party, Mischief Makers, and others did not give me any error messages.

And again, this is ONLY using the HLE RSP plugin. Zilmar's RSP does not do any of this using the same combination of both HLE audio and video plugins, whether it's set to recompiler or interpreter.

Edit: Using the MLE variant with Shunyuan's audio seems to fix the issue, so there's that I suppose.

[V1del]

rsp-hle is HLE Video/LLE Audio, rsp-mle HLE Video/HLE Audio iirc, so that would be the cause

[HatCat]

HLE version of my plugin is useful for debugging to show where games send RSP task types other than gfx (0x00000001) and audio (0x00000002). If so then a message alerts you that the RSP will have to execute this specific task type in the absence of the ability to HLE it.

So just press Enter to bypass such messages, and it should function normally.

The only problem is that some games (Pokemon Stadium) use a JPEG decoder task type (0x00000004) like, a lot of times consecutively, so you have to hold down the Enter key to bypass all of those.

But if you're not interested in finding games for me that use special task types you can always use the MLE version of my plugin for full speed.

Originally Posted by V1del

rsp-hle is HLE Video/LLE Audio, rsp-mle HLE Video/HLE Audio iirc, so that would be the cause

Switched the other way around and then yes.
-mle means part of it is LLE (audio in this case).

[GPDP]

So that's what those messages are. Thing is, the error messages on OoT don't appear consecutively. I basically have to click on another window, then click back on the PJ64 window for the next message to appear, which is, of course, tedious. Nevertheless, if I encounter it again on another game, I will certainly report it here.

[HatCat]

They should be consecutive because the SP tasks are consecutive.
0x00000004 happens immediately after 0xsdfsdlkgsdfgsfsdfwhocares.
I think I don't really care if there is some WINAPI issue causing one to happen prematurely based on your window actions.

I already know of these SP task types--

• 0x00000004 -- no official macro for it, but typically known for the JPEG decompressor in Pokemon Stadium
• 0x00000007 -- HVQM video decompressor ucode used by PKMN Puzzle League
• 0x00000000 -- a rumor I read about in mupen64plus dev that Tetrisphere has a corrupt/null gfx task header
• Any of the games booting off the NUS-CIC-6105 chip (Zelda, Banjo/Rareware, etc.), as you can tell in the ROM browser information in most emulators.

I thought there was something in Resident Evil 2 but I think that was just a header check that couldn't pass in Hacktarux's HLE RSP.


I haven't played around with HLE enough to know what other games will complain with it.

[GPDP]

Well, it appears the 00000004 message that pops up for OoT only appears right at the intro, and whenever there are pre-rendered backgrounds, which explains why I would get all those messages whenever I loaded a save file: the game would start me out at Link's house, which uses a pre-rendered background. Starting from the Temple of Time does not trigger the messages, but stepping outside of it does. I'm guessing OoT uses the same JPEG decompressor as Pokemon Stadium?

Still testing games, so I'll report if I see another such message elsewhere.

[bsmiles32]

00000004 "messages" usually concerns JPEG decoding.*
There are at least 3 different versions of jpeg decoding tasks :
-the most common is found in OoT, Pokemon Stadium and Pokemon Stadium 2.
-a variant is found in Pokemon Stadium Japan.
-the last version is found in Bottom of the 9th and Ogre Battle.

*The only exception I know of is a small rsp task found during booting of OoT, which stores ve12 into dmem[0x10-0x1f].