News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - CrashingThunder

Pages: [1]
Personal Projects / Re: Banjo-Kazooie Returns
« on: January 05, 2015, 09:22:39 pm »
No offense but you should've done a fan-made "Banjo-Threeie"

Well, it basically is that. Just with a different name. But oh man...if somebody were to make their own cutscenes and what-not...that would make me really happy.

ROM Hacking Discussion / Nemu64 : Setting Instruction Breakpoints
« on: December 14, 2014, 11:44:04 pm »
Hey, me again with more questions. I want to be able to set a breakpoint when a specific instruction is executed. Not just a specific type of instruction, but literally that one, at that unique spot in memory. I've located that specific instruction in the memory debugger and set a read breakpoint on that 32 bit portion of the ROM, but it doesn't break. Probably because the "read" breakpoint doesn't mean "the CPU has executed this command" but it only means "the CPU tried to read from this spot in memory".

Please tell me there's a way to set a breakpoint upon executing a specific assembly instruction at a unique part of memory?

EDIT : Well, as per usual, I figure it out before anybody responds. But I'm not going to delete this because I feel like it wasn't intuitively obvious. You have to click to the left of the instruction:

Personal Projects / Re: Banjo-Kazooie Returns
« on: December 14, 2014, 03:50:58 am »
This looks really good. It could even end up being the Banjo Three-ie we've always wanted! But what about the more "unique" parts of the game (like the tiptup choir as an example). It'll be a bit more tough to make new stuff like that in the game, but not impossible.

What do you mean exactly, by the fact that Origami64 treats the entire game as one block of data? He knows where specific parts of the code are. Also, if I'm understanding you correctly, the main categorization of the ROM map has already been underway by Luigi1er (which is awesome -- I've made full use of this information) : Scratch that, apparently the file doesn't exist anymore. Well, there was a fair amount of information about where things were stored (by a level-by-level basis) but it seems he either deleted the file or it was relocated.

Regardless, I'll look into that DL parser at some point, but I feel I may be treading a little too deep with that kind of stuff. At least at this point. I plan on utilizing my extra free time during the winter break to work on this kind of stuff.

Well, that seems immensely complicated. I can't say I didn't expect that, however. Lots of good information you guys gave me, though, so thank you for that. I'm trying to decide on an aspect of the game I want to focus on and get somewhere with. If you've seen this post, Luigi1er is doing some great work on Paper Mario 64: ...

You can see that he's doing a lot of work in a variety of areas. And then there's also Origami64 by Skellux, which came out recently :

I'm a fair (but finite) ways behind either of these two people, so I'm trying to think of something in the game more doable for someone of my knowledge and skills that also hasn't been done yet.

Thank you for the multitude of replies, they are appreciated. I know that there is a way to do this without modifying instructions, because I have seen others modify similar data to what I am doing. I'm just trying to do it myself so I am more capable of solving different problems in the future.

This probably deserves another thread entirely, but I'll throw this question out for fun :

How would one go about decoding the structure of the levels in Paper Mario 64? Obviously, level data for N64 games aren't modified too much (the only big editor out there that I know of is an SM64 editor). I have little to no idea how I would go about deducing the structure of the level. I do have access to where the levels are in the ROM, however, so I would know where to look.

(I may be way off base on this) In other words, say there was a level that consisted of a flat floor, and a cube in the center. How is the cube stored in memory? My guess is that the game stores a bunch of polygons (probably squares, maybe triangles) to represent the cube. Each polygon would have a certain amount of datapoints, probably the 3D coordinates for each corner and a texture to draw and maybe some other stuff like whether or not it is solid.

I guess I'm answering my own question here...aren't I. Does my description of how the game would store level data sound right? Is there somebody out there that has detailed knowledge on model formats for N64 games?

Thank you for your replies. I'll try looking further back in the instructions before trying what Zoinkity said. But I have a followup question regarding that:

If I'm backtracing through instructions, how do I actually know those instructions were executed? What if I got into a particular section of the code from a branch elsewhere? I'm using Nemu64's debugger, and there isn't any sort of "backstep" option.

Also, if I were to go the "make my own subroutine" route, how could I put my own code into RAM like weiissvulf said? The ROM file doesn't contain the RAM -- that's not in the cartridge, but inside of the console (virtually, in this case). I would have to branch somewhere else in ROM that isn't being used. How do I know for sure an area in memory is never used?

ROM Hacking Discussion / R4300i ASM : Adding new instructions to game code
« on: December 09, 2014, 12:53:09 am »
I've been dabbling around with Paper Mario 64's engine lately. I found the particular code that makes enemies fall asleep for a particular amount of turns. Here is the part that sets the status type (sleep = 06) and the amount of turns (03).

Code: [Select]
SB       S1, 0x0210(S0)
BNEZ   V0, 0x80266008
SB       S2, 0x0211(S0)

When this code is run, S1 = 06, and S2 = 03, so the enemy falls asleep for three turns. What I want to happen is that they get a different status effect (other than 06) and for a different amount of turns.

But, therein lies the problem. The SB instruction doesn't store immediate values to memory. It stores values within registers, in this case S1 and S2. S1 and S2 are loaded somewhere waayy back in the instructions being executed, most likely from other registers, which are loaded from other registers. The point is that I can't just store the value 06 to memory. It has to be a register, right? I looked through the instruction list and couldn't find an SBI instruction or something (Store Byte Immediate).

So what I think I need to do is to throw an extra instruction in there like ADDIU      S1, R0, 0x07
If I do this before the code above, it'll store 07 instead of 6, but I can't just throw another instruction into the code because it's all a fixed size!  :banghead:

As a side thought : I don't want to do this if I don't have to, but could I also write a quick subroutine somewhere in memory that isn't accessed at any time that does the code mentioned above? I feel like that could get hairy really quick.

Personal Projects / Re: Paper Mario 64 - General Hacking Tool
« on: December 06, 2014, 06:30:58 pm »
How goes the progress on hacking this game? I've come along a fair ways, but I'm still getting used to the process. I'm sure many people know about this tool, but I stumbled upon a program called Cheat Engine that allows you to actively search for specific values (such as Mario's health), and then make subsequent searches on all of the results that turned up, allowing you to narrow down which one is right (ex: Mario's HP is currently 7, you search for 7 in Cheat Engine. Then you eat a Mushroom and Mario's HP is 10. You search again in Cheat Engine for 10, and the results get narrowed down even further). And once I find the location in RAM (not ROM, so you wouldn't find this in the .n64 ROM file), I can set a breakpoint there to view code that is being run when that location is accessed. Then, I find code that was running when the breakpoint was triggered and it can lead me to where the game is looking for specific values, such as the price of an item in a shop.

I also use Nemu64 for the in-game debugger, allowing me to view ASM code that is being run, and to set breakpoints when certain parts of memory are written or read from. Using these things, I was able to change a SUBI command (subtract immediate value) to an ADDI (add immediate value) so that when I bought a particular item from the store, it gave me money instead of taking it away  :laugh:

Anyways, I recommend using those programs if you (or anybody else reading this) aren't already using them or something similar.

Edit : Did the same thing with attacking a particular enemy lol (attacking with Mario gives them HP). But I don't think what I'm doing is changing the game itself -- just modifying the RAM that is being used by the emulator. I am totally speculating, but I believe I need to find the code that writes to the RAM. The code that loads the enemy stats (which you've found) and puts them in the temporary memory when you're in a battle.

Personal Projects / Re: Paper Mario Hacking Documentation
« on: November 09, 2014, 12:26:32 pm »
Well the zeros are there for a reason. Let's look at the entire hex information that encapsulates the northern toad town shop. The item slots are stored in memory linearly, one after another. There's no room for control codes in between the slots. That's not to say they aren't somewhere else nearby, but this is exactly where they are. The zeros are just part of how the variables are stored in memory. Items have four bytes, prices have two bytes. It can't be any other way because that's how the shop data is laid out.

Here are the first two item slots, separated by the || :

   [00 00 00 98] [00 00 00 05] [00 24] [00 2A] || [00 00 00 8F] [00 00 00 0A] [00 24] [00 26]

00 00 00 98 is a fright jar. 00 00 00 05 is the price (5 coins). 00 24 is the text group (always 24 for shop items). 00 2A is the descriptor. Changing this changes what shows up on the item description.
00 00 00 8F is a sleepy sheep. 00 00 00 0A is the price (10 coins). Same text group. Different descriptor for a different item.

There is no other information for an item slot than those four attributes. So, why do we need to know about control codes regarding how the game lets you buy items if that's all we want to do with them anyways? I mean, if I wanted to make it possible to change how the shop actually functions, then yeah, I'd probably need to find control codes for that sort of thing.

EDIT: In regards to control codes, however, can I pick your brain (or anybody else's)?

I'm trying to figure out a fairly common control code. Check this out:

Code: [Select]
   Format : 02 FE 36 3C XX 00 00 YY YY 00 00 00 ZZ
      XX = ??? (Usually 80-8F)
      YY = Item ID
      ZZ = Text Group (24)
      02 FE 36 3C 80
   A0F69C : "Lucky Star"
   7F5C64 : "First Degree Card"
   7F5CA0 : "Second Degree Card"
   7F5CDC : "Third Degree Card"
   7F5D18 : "Fourth Degree Card"
   7F5D54 : "Diploma"
   9E5618 : "Koopa Legends"

The same code of [02 FE 36 3C 80] seems to appear for all "key items" you obtain. In my searching, however, there are other control codes that have 81-8F. Sometimes the 02 in front is different as well (SOMETIMES, there are multiple control codes in a row, like [FE 36 3C 80] [FE 36 3C 81] [FE 36 3C 82] . Often times, the last byte goes up sequentially like this. BUT, it does seem for getting key items, the control code 02 FE 36 3C 80 is always used. So...what does this control code actually mean, and what do the variations mean? If I could figure that out, I could add this information into the document.

I have a few ideas to as what the control codes mean. Perhaps ending in 80 means you are receiving the item, and 81-8F have to do with other aspects of items. Or maybe the control code doesn't have to do with receiving or using items at all?  :banghead:

EDIT2: More information! See Reply #13 :,17948.0.html

Notice the control code for enemy attacks as well. The last four bytes are [FE 36 3C 8X]. So...the plot thickens.

EDIT3: More thoughts, cause why not:

If it's a control code, that means its part of the MIPS instruction set right? Cause that's what the N64 uses? If so, I suspect byteswapping the ROM would definitely be a bad idea...cause that would be confusing if you were jumping to addresses. Here's the data for when you obtain the First Degree Card (The non-byteswapped version):

Code: [Select]
02 00 36 FE 80 3C 00 00 0A 00 00 00 24

I did some research on the instruction set, looking for opcodes. It turns out, the JUMP opcode has the following format:

Code: [Select]
[6 bits for the op code][26 bits for the address to jump to]

The opcode for J (Jump) is 000010, aka "2" in binary/hex.

Except I'm confused because it's 6 bits for the op code and 26 bits for the address. Not being in multiples of 4 is messing with my head :(

In the datasheet it says the following (instr_index is the 26 bit address):
Code: [Select]
The low 28 bits of the target address is the instr_index field shifted left 2bits. The remaining upper bits are the corresponding
bits of the address of the instruction in the delay slot (not the branch itself).
Jump to the effective target address. Execute the instruction that follows the jump, in the branch delay slot, before
executing the jump itself.

Personal Projects / Re: Paper Mario Hacking Documentation
« on: November 08, 2014, 11:42:33 pm »
Which parts? My idea for this is to provide information about how different things are stored and in what format so they can be easily edited.

I agree with the idea of having the tool use the correct endian instead, but HxD doesn't seem to support swapping bytes (as far as I could tell). If someone stumbles upon the document and has a non-byteswapped ROM, I just want them to know how they can fix it and keep on rolling.

Personal Projects / Paper Mario Hacking Documentation
« on: November 06, 2014, 05:19:09 pm »
Paper Mario 64 Hacking Documentation :

Seeing as there is hardly any Paper Mario 64 documentation in regards to hex editing, I've decided to make it myself! A lot of what is on my document is derived from Luigi1er, who is currently working on a tool to edit many aspects of the game ( There's also Skellux, who made Origami64( So, I'm putting all the information together into one place. I don't claim to have discovered the information in my document -- I just think it would be beneficial to the people who want to help hack Paper Mario 64.

And, it's a work in progress, as I can't explain something I don't understand well. But, I hope it will be used as a tool for getting started with hacking Paper Mario.

Cheers  ;)

Personal Projects / Re: Paper Mario 64 - General Hacking Tool
« on: November 05, 2014, 10:25:32 am »
Thanks for the files, especially the information about where the data resides for each area. It seems like you've basically got the whole ROM already mapped out for the most part (at least in general), which is fantastic.

Anyways, I'll be continuing my efforts to find something that hasn't been found yet. I remember searching the internet a couple of years ago, wanting to find something exactly like this and Origami64, but ended up disappointed. It looks like the Paper Mario nut is about to be cracked  ;D

EDIT: I think I actually found something nobody else has, or at least not documented anywhere I've seen. The Little Oinks! Their data range is [0x841000, 0x841077] and have a similar format to items in shops that I have yet to figure out. Each Lil' Oink has a 4-byte Item ID (like shops), and two other 4-byte pieces of information that are  [00 00 00 01] and [00 00 00 64] for every single of the 10 piggies. I'm going to mess with these values later to see what they mean, but I tested my theory by setting the IDs for each piggie to be cake mix [00 00 00 AA] and that was exactly what they dropped  :laugh:

Code: [Select]
   Offset : 00 00 00 AA 00 00 00 BB 00 00 00 CC ITEM NAME
      AA = Item ID
      BB = 01 (why?)
      CC = 64 (why?)
   841000 : 00 00 00 8D 00 00 00 01 00 00 00 64 DRIED SHROOM
   84100C : 00 00 00 8C 00 00 00 01 00 00 00 64 SUPER SHROOM
   841018 : 00 00 00 80 00 00 00 01 00 00 00 64 FIRE FLOWER
   841024 : 00 00 00 82 00 00 00 01 00 00 00 64 THUNDER RAGE
   841030 : 00 00 00 95 00 00 00 01 00 00 00 64 LIFE SHROOM
   84103C : 00 00 00 A3 00 00 00 01 00 00 00 64 MAPLE SYRUP
   841048 : 00 00 00 83 00 00 00 01 00 00 00 64 SHOOTING STAR
   841054 : 00 00 00 97 00 00 00 01 00 00 00 64 REPEL JEL
   841060 : 00 00 00 A2 00 00 00 01 00 00 00 64 JAMMIN JELLY
   84106C : 00 00 00 8E 00 00 00 01 00 00 00 64 ULTRA SHROOM

Personal Projects / Re: Paper Mario 64 - General Hacking Tool
« on: November 04, 2014, 12:29:15 am »
You've inspired me to get into hacking Paper Mario. After a little messing around and referencing this thread, I was able to find the offsets for several locations and alter the exit locations. (I could do stuff like making the exit from Toad Town Plaza go to the inside of the whale  :happy:). You said the exit locations are located at the end of the data for the level, so I used that info and searched backwards for the "music key" (the 05802D5D4C value for regular background music) and also found the hex offsets for the levels.

My question is: is there any demand for these offsets? One could find them using information in this thread, but it's fairly time consuming. Is there an existing list of offsets for these levels (and their attributes like exit destinations and music tracks) that already exists? If not, I would happily continue to generate these lists of offsets so making tools would be a little easier for you people who have a better idea of what you're doing. After 15 minutes or so (things started slowly too) I came up with this:

Code: [Select]
   Toad Town Plaza
      822F30 : Exits
      80913B : Music
   Pleasant Path 1st Zone
      9FA720 : Exits
      9F6A03 : Music
   Pleasant Path 2nd Zone
      A00250 : Exits
      9FC943 : Music

This shows the offsets of the exit locations for that level, as well as where the music track is located. I'd gladly continue to generate this information if people wanted it!  ;)

More questions:

I was trying to understand the shops. Your tool already does it all, but I'm trying to make sense of the item descriptions. If this stuff is true (which it is):

Code: [Select]
Item Slot Format: AA 00 00 00 BB 00 CC 00 DD 00 00 00
   AA = Item ID
   BB = Item Price
   CC = 24 --> dont know why yet
   DD = Item Description (See ID_tag table)


00 : Fire Flower (80)
01 : Snowman Doll  (81)
02 : Thunder Rage (82)
03 : Thunder Bolt (84)
04 : Shooting Star (83)
05 : Dusty Hammer (86)
06 : Pebble  (85)
07 : Stone Cap (88)
08 : Volt Shroom (8B)
09 : Mushroom (8A)
0A : Super Shroom (8C)

Why is the order all screwy? Looking at the ID Column, it starts off with 80, 81, 82...but then jumps to 84, then back to 83. I'm trying to make sense of why these jump around instead of going up in a linear fashion. I did it to 0A to see if I could find a pattern but I can't see one yet.

Pages: [1]