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

[HatCat]

Yeah, I couldn't follow your question, but the only thing I need to be able to do is just edit a RSP command and change it into some other 32 bits. Like a VSAR/VSAW command for example, I could rewrite that to access an accumulator element other than high/middle/low and see if it alters the behavior on hardware, or if it ignores objectively irrelevant bits in the shuffle immediate. It's not as precise as getting the exact values as through zilmar's method of reversing them, but there is little that I don't already know to the point where I only have a few tests remaining.

[RPGMaster]

Originally Posted by HatCat

Yeah, I couldn't follow your question, but the only thing I need to be able to do is just edit a RSP command and change it into some other 32 bits. Like a VSAR/VSAW command for example, I could rewrite that to access an accumulator element other than high/middle/low and see if it alters the behavior on hardware, or if it ignores objectively irrelevant bits in the shuffle immediate.

I was just unsure how you would locate/see the RSP instructions if the game doesn't work on emulator. I guess it's able to at least run the game? Even if it freezes, perhaps you're still able to log the RSP IMEM data.

[bsmiles32]

Just for information, most of audio ucodes fit within the 4k of IMEM, so dumping IMEM content before starting rsp execution will give you the full ucode listing. Note that usually ucodes aren't exactly 4k but smaller, that's why you get some junk bytes at the end.

For ucodes that are longer that 4k (and cannot fit entirely within IMEM), they usually explicitely DMA the missing parts of ucodes as needed. This happen for instance to load the mp3 ucode for PerfectDark or ConkerBadFurDay audio tasks, or for the later version of MusyX (IndianaJones and BattleForNaboo). And this is quite common for GFX tasks.

What I used personally to study ucodes, is to dump them from DRAM before starting RSP execution. You get the starting DRAM address of the ucode by reading DMEM[0xfd0-0x0fd3]. (For games that don't use the traditional boot ucode, use DMEM[0xfc8-0xfcb]). Once you have a binary dump of the ucode, just use a disassembler on that (I use https://bitbucket.org/ottehr/rsp-tools, but you can use whatever you like).

I highly recommend you to have a good reference (ie source code) on RSP vector instructions nearby when you look at disassemblies, otherwise you'll get confused really quickly.

I know that you really want to work on GFX ucode specifically, but those are the most difficult to reverse engineer because the code flow is really messy, and they are bigger than other tasks.
For starters, and to get the feeling of what it takes to reverse engineer ucode, I would rather suggest you to try the jpeg tasks, which are easier (code flow is not very convoluted, they actually implement a known algorithm, and they are fully reverse engineered), yet not trivial.
If you want something shorter, just try to undertand the boot ucode.

When studying a ucode, you should identify:
-where are the ending point(s)
-where are the DMA functions, do they load things to IMEM (and therefore can modify the ucode...) or DMEM.
-if you can spot functions (starting, ending addresses and parameters)
...
Then try to build a map of DMEM to identify the purpose of each addresses
(is this a constant ? what size is this data ? ... ).

This list of tips is of course not exhaustive, but should give you a starting point.

I did more checking and it appears to be split up in the rom. For instance in SSB64, the beginning of the RSP for what I assume is for Audio, begins at offset 0xB70 in the rom. Then I checked where the code at address _04001100 in IMEM would be, and found it at offset 0x3A340.

Indeed, ucodes are usually splitted in 2 parts: the "boot" ucode, and the "real" ucode. The only purpose of the "boot" ucode is to load the "real" ucode into IMEM, load its data into DMEM and then jump to "real" ucode entrypoint (0x1080).
There are some exceptions to this description, with games doing some anti piracy tricks in the boot_ucode (those who uses CIC 6105 for instance), and some that don't use boot ucode at all.

[RPGMaster]

So now that I've confirmed that the RSP code can be found in the ROM. How can I distinguish between audio and gfx for RSP code?

I'd like to study microcode, so I can play games like Rogue Squadron at full speed one day . After seeing what other people have done, I now have faith that I could possibly reverse engineer it.

[HatCat]

Rogue Squadron is faster than Mario. :/ Its RSP ucode is simpler in some ways than Mario's...heck it even enforces data alignment in the MusyX audio stuffs so that audio recompiler ops are less likely to break. It's only "harder" to emulate because HLE doesn't document it; that's it. Otherwise it's no worse than any other game.

So you found RSP instruction cache segments in the ROM itself?
Well if you don't see data memory too close by or linking to it saying whether it's audio and gfx, look for instructions like VEQ/VNE/VRCP*/VRSQ*/LTV/others. If you see stuff like that, there's almost no way it's an audio ucode. It must be something else, like gfx.

[Zapfy]

Hi. This isn't working for me and I have a few questions. (I'm a noob to this stuff)

I'm using 1.7.0.50 of PJ64. You say: "(Note that some emulator versions, such as Project64 2.0, but not 2.1 and later, might end up attempting to read base-directory files from somewhere other than the "EXE folder".)" Where will it look then?

I can run the cgfui.exe file and select what I want, but nothing changes. It even generates the CFG file if it's not already there. Is the rsp.dll file in the plugin folder supposed to change according to what I selected after I press Save & Quit?


I can't go to Options > RSP because it says "Failed to read config". All my files are in the right place however.

Is there anyway you can just give me all the dll files it generates, so I can put the one I want in the Pugin folder manually? Is that even how it works? I can't tell because it wont work for me

[HatCat]

Thank you for reading the manual. You're the first, maybe second person to post in this thread with any indication that it was read.

When I wrote that I knew that Project64 2.0 (not 2.1) had a bug where the config files got read/written as $pj64/Screenshots/Plugin, rather than $pj64 core exe folder, but I guess I assumed this was something zilmar introduced when he started over Project64 from scratch and scratched working on Project64 1.7. Seems I was wrong; it was a bug in PJ64 1.7 as well, only it's some other folder besides $pj64/Screenshots/Plugin.

I don't know what it is, but why can't you simply use a fixed version like Project64 2.1? Why do you need Project64 1.7?

[Zapfy]

Well 2.x isn't allowed for speedrunning, so I'm trying to create a really good 1.7 setup. I've only ever used 2.x a few times and I just found 1.7 to be more stable I guess...

What about giving me the dll files (that get produced?) so I can put the one I want in the plugin folder manually? Will that work?

Thanks

[HatCat]

Then use 1.6 or, better yet, something like Mupen64 if you want better timing.

1.7 is hardly an improvement in that regard, and it is not even legitimately available to users at this point. The fact that you have a copy of 1.7 is enough proof that it was either cracked/hacked or used off of somebody else's version who did donate, and from what I hear these executables can get changed in ways that affect emulation.

But that doesn't bother/interest me. I'm just saying, it's basically obsolete. 2.1 is better, and 1.6 is more stable/accurate with timing.

And my DLL doesn't produce DLLs; you just use the DLL. It goes in the plugin folder. You must be reading some ancient version of my original post that talks about multiple versions of my plugin. Use the latest version, not older ones. Those were only provided for lulz.

[RPGMaster]

Originally Posted by Zapfy

Well 2.x isn't allowed for speedrunning, so I'm trying to create a really good 1.7 setup. I've only ever used 2.x a few times and I just found 1.7 to be more stable I guess...

Lol so 2.x isn't allowed but 1.7 is? That's very odd if true. Mupen64 has better timing, so I'd definitely use that for a speedrun.

Originally Posted by HatCat

Rogue Squadron is faster than Mario. :/ Its RSP ucode is simpler in some ways than Mario's...heck it even enforces data alignment in the MusyX audio stuffs so that audio recompiler ops are less likely to break. It's only "harder" to emulate because HLE doesn't document it; that's it. Otherwise it's no worse than any other game.

So you found RSP instruction cache segments in the ROM itself?
Well if you don't see data memory too close by or linking to it saying whether it's audio and gfx, look for instructions like VEQ/VNE/VRCP*/VRSQ*/LTV/others. If you see stuff like that, there's almost no way it's an audio ucode. It must be something else, like gfx.

Alright thanks. I'll look for those instructions then . Wow I just realized, probably the reason why SM64 uses little power in HLE is because it's 30 fps. It all makes sense now! Even Quest64 is 30 fps. Lol before, I just thought games like SM64 was done efficiently .

Sometime this week, I'll do some reversing I guess . Hope I learn valuable information from it at the very least.