Welcome Guest [Log In] [Register]

Announcements

Welcome to Zelda64.net. Announcements can be found below!

6.26.2018  Make sure you keep your passwords safe. If you use the same password on here as on other sites, it is highly recommended that you change it. If you can't change your password, and want it changed, let me or other active staff know, and we can force a reset or change it for you. ~PwnzLPs
Welcome to Zelda64. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. A valid email address is required. Your email address will NOT be sold as it is only needed to prevent spammers (and admittedly, some still get around this, but this makes it a bit more difficult, plus, if the moderators need to contact you, we have an email on file to do so). Thanks for considering us!


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
[OoT Debug] To Aspiring ASM Hackers; How to easily add 0x10000 bytes of Free Ram for Custom ASM - Courtesy of CloudMax
Topic Started: Mar 20 2016, 11:02 AM (1,356 Views)
Three Pendants
Member Avatar

Hello everyone.

I've dabbled in Mips ASM in the past as my previous work would attest to but due to how constrained the memory system of OoT is it was difficult to try and do anything that went beyond the normal parameters of the game. Well thanks to CloudMax he has shown me a simple and efficient way of adding 0x10000 bytes of free space to ram! Here is the conversation...

<CloudMax> so, we have this code http://bin.cloudmodding.com/inokunonam.mips when compiled into GameShark it would be http://bin.cloudmodding.com/isazinelij

<%CloudBot> Title: Cloudbin - DMA Transfer
<%CloudBot> Title: Cloudbin - DMA Transfer GameShark
<CloudMax> but we want to insert it into the ROM, obviously. not the RAM. so we need to convert the offset for where the code would be in the ROM instead

<Three_Pendants> Oh, that doesn't seem too terribly complicated.

<Three_Pendants> So where C6844 would line up in ROM

<Three_Pendants> rather than RAM*

<CloudMax> right.

<CloudMax> and calculating that should be easy if you know the offsets

<Three_Pendants> Thanks to the spreadsheet that shouldn't be too difficult.

<CloudMax> for starters, it is located in the "code" file.

<CloudMax> the "code" file starts at 0x8001CE60 in RAM, so we'd just subtract that from 800C6844, then we know where it's located in "Code"

<Three_Pendants> So, C6844 - 1CE60?

<CloudMax> anyway, 0x800C6844-0x8001CE60=0xA99E4. Which means that you want to insert my hack at 0xA99E4 in "code". and that file should be at 0x00A94000 in ROM, so input it at 0xB3D9E4 .

<Three_Pendants> Hmm, what data is this initially overwriting?

<CloudMax> I took a piece of code that's ran on boot up and optimized it a lot to bring it down to much fewer instructions

<CloudMax> allowing me to insert my own code without destroying anything

<Three_Pendants> Gotcha. Now that is useful information.

<Three_Pendants> How exactly do JAL's work? For instance there's one that goes to 0x21F50 which is the "Get Item" routine, but in Hex it looks like 0C00BD0D - OCOO is easy enough to figure out. It's the JAL. But how does BD0D translated 0x2F434? - This is how BD0D x 4 (for each instruction)

<CloudMax> http://pastebin.com/cmCXpewE may be useful if you do not already have it.
<%CloudBot> Title: Nintendo 64 opcodes - Pastebin.com

<Three_Pendants> 500000 / 4 is 14000. Doesn't that go beyond the FFFF allowed parameter of the basic JAL command?

<CloudMax> it does allow more than FFFF actually.

<Three_Pendants> I'll have to read up on the command proper.

<CloudMax> Yupp. It actually uses 26 bits for the parameter in JAL
<CloudMax> and not 16
<CloudMax> as can be seen in the paste I sent :)

<Three_Pendants> ...So it uses six bytes, not four?

<CloudMax> well, 6 and a half :P

<Three_Pendants> Hah. So the 0C is literally what tells the system "This is a JAL Command. Everything after is the Jump Proper"?

<CloudMax> they only use 6 bits for the opcode identifier. the remaining 26 for parameters.

<Three_Pendants> I didn't even know that it could work that way.

<CloudMax> Now you do :)

<Three_Pendants> Haha, indeed! Thanks once more.

<Three_Pendants> I'll try and see if I can't try out a simple test of JAL to the new space.

<Three_Pendants> Excellent! All right, creating a JAL to there was a simple task and it read data from there without issue. Wonderful.

<CloudMax> :)

<Three_Pendants> So whenever I find a function I find lacking I can add to it. I never imagined it would be so simple!

<CloudMax> I honestly have no clue why so many people don't do this. some people complain about not having space to inject code and whatnot

<Three_Pendants> I imagine it's the trepidation. My mind had it that this would be a grand undertaking, you made it obvious that it is far from it.

<CloudMax> haha, yes.

And that's all there is to it! If you copy the actual hex from the gameshark code at the start and put it exactly in that place in ROM you will have 0x10000 more bytes of free ram at 0x80500000!



Offline Profile Quote Post Goto Top
 
Tunnellord1337
Member Avatar
1337Lord
Never mind
Edited by Tunnellord1337, Mar 20 2016, 12:11 PM.
Offline Profile Quote Post Goto Top
 
aroenai
Member Avatar
Sentient Hunk of Green Cheese
Can anyone explain this hack a little bit? Mainly what this function does that the more efficient code replaces and if it frees up any space in rom.
Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
« Previous Topic · Documentation · Next Topic »
Add Reply