Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1291  
Old 15th April 2018, 10:26 PM
fallaha56 fallaha56 is offline
Project Supporter
Member
 
Join Date: Apr 2006
Posts: 34
Default download

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
Reply With Quote
  #1292  
Old 10th November 2018, 11:06 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,260
Default

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.

Quote:
Originally Posted by fallaha56 View Post
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.

Last edited by HatCat; 10th November 2018 at 11:18 PM.
Reply With Quote
  #1293  
Old 10th November 2018, 11:17 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,260
Default

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.
Reply With Quote
  #1294  
Old 11th November 2018, 06:07 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,015
Talking

Quote:
Originally Posted by HatCat View Post
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.
Reply With Quote
  #1295  
Old 11th November 2018, 02:52 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,260
Default

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.
Reply With Quote
  #1296  
Old 12th November 2018, 06:06 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,015
Red face

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.
Reply With Quote
  #1297  
Old 13th November 2018, 03:59 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,260
Default

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.
Reply With Quote
  #1298  
Old 5th December 2018, 01:51 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,015
Talking

Quote:
Originally Posted by bsmiles32 View Post
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 .
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:58 PM.


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