Project64 Forums

Project64 Forums (
-   Open Discussion (
-   -   New LLE RSP Plugin (accurate, fast but untested?) (

fallaha56 15th April 2018 10:26 PM

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

HatCat 10th November 2018 11:06 PM

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 (Post 73933)
hi, thanks for posting on the other forum but on Win10 the download comes up as a virus and is blocked...

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 10th November 2018 11:17 PM

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 11th November 2018 06:07 AM


Originally Posted by HatCat (Post 75032)
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 11th November 2018 02:52 PM

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 12th November 2018 06:06 AM

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

HatCat 13th November 2018 03:59 PM

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 5th December 2018 01:51 AM


Originally Posted by bsmiles32 (Post 55451)
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, 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 :D .

All times are GMT. The time now is 05:01 AM.

Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.