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

[fallaha56]

hi, thanks for posting on the other forum but on Win10 the download comes up as a virus and is blocked...

https://go.microsoft.com/fwlink/?lin...tid=2147717281

[HatCat]

Not a fan of vBulletin, but if you need to use it to discuss the plugin, I can still check EmuTalk. Just driving by here to address a patch to my save editor I missed for months, sorry for the delay. Probably should find a way to delete this thread or have some moderator do it.

Originally Posted by fallaha56

hi, thanks for posting on the other forum but on Win10 the download comes up as a virus and is blocked...

https://go.microsoft.com/fwlink/?lin...tid=2147717281

You'd have to run that by whoever is in charge of the anti-virus industry; I have no idea who entertains that business.

Back when I used to run a Microsoft system and believed in anti-virus I vaguely seem to recall an installer for Mupen64 being blocked by an AV on Windows Vista...think it was McAfee that was put onto my system at the time. Fiddled around with the executable in a hex editor to replace the name "Hacktarux" with something else in the emu about page, then the AV stopped blocking it. So evidently didn't like seeing the word "hack" ??

I couldn't begin to predict what AVs might do. If I had access to your system fallaha, I'd diagnose it out of curiosity and see what's causing the AV blockage there, but I don't have access and that's far away in another lifetime for me now.

Otherwise my hunch is, if you were able to compile it and build it and not have the AV complain, maybe it doesn't like the newer beta version of GNU linker I used to build the DLL on Windows, maybe I'm trying to purposely infect everyone with a virus who lazily downloads binaries instead of compiling from source...bottom line is I can't control what you all or your anti-virus programs think.

[HatCat]

FWIW I seem to recall trying to cram everything in one night (bad habit of that...) and ready both the RSP and angrylion RDP fork plugins for release in one night.

When I released the RSP on EmuTalk it was because I ran out of time and finished tweaking the Windows build of the RDP the day after. Was ready to release the RDP on the next day in response to any observations about the RSP plugin and to avoid double-posting. Ironic thing is nobody ever commented on the current release of my RSP on EmuTalk, so I never got to update the RDP thread on EmuTalk with my current GL fork of angrylion's plugin with all the newer commits merged. I assume that's not a let-down for anyone with that multi-thread thing out there though, though I personally haven't tried it yet since it uses M64+ spec, not zilmar spec.

[RPGMaster]

Originally Posted by HatCat

I assume that's not a let-down for anyone with that multi-thread thing out there though, though I personally haven't tried it yet since it uses M64+ spec, not zilmar spec.

It actually supports zilmar spec as well, although the UI was quite buggy for it on 1964, so PJ64 is recommended.

[HatCat]

Right but you're talking about the Windows port. I can only use zilmar-spec plugins, which have been around on Macintosh and Linux for quite some time before Mupen64Plus gave up properly repairing it for 64-bit.

[RPGMaster]

My bad, I forgot you're on Linux . Seems odd that some plugins which support multiple OSes, only support zilmar spec for their Windows version.

[HatCat]

There is a long story that comes with that, but let's just say that all the non-standard C code and WIN32-isms (like DWORD, HWND etc.) in zilmar's specifications got people native to UNIXes a little confused while trying to properly translate into standard code.

Mupen64Plus eventually gave up and made up their own spec because while the 32-bit translation by Hacktarux worked dandy, it was still technically not ABI-identical, and further issues arose with 64-bit plugins. AFAICT I am the only person to have accurately and successfully translated zilmar's spec into a standard-C-code-only, 64-bit-compatible platform-agnostic API. If I'm correct, then the idea wasn't popular enough for others besides me to have targeted it, so it's no surprise that GLideN64 or the angrylion multi-thread thing don't know what else to do for 64-bit non-Windows than to rely on Mupen64Plus' spec.

[RPGMaster]

Originally Posted by bsmiles32

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 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 ? ... ).

Wow this was such an informative post! It's a shame that this post was never approved until now. It's still useful 4 years later. Thanks a lot bsmiles32 .