 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - Finding an indextable |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
|
jeb Newcomer               Since: 08-15-06 From: Switzerland Last post: 6466 days Last view: 6466 days |
| ||
| Hello!
First i want to say hello, because it's my first post on this board. I've never done anything in romhacking before, but a few weeks ago i've seen pok�mon hacks and I tought that this is a really interessting thing I want to try out, too. I decieded to try it on Zelda OOT because the zelda games are my favourite games. I started with the textsystem. I saw that there is already a thread about this task, but either the person didn't post anything he knew or he didn't get out more. Anyway, there's more to know about it. Now i know how to change color, asking questions to the player and so on. I will post all this infos when I know more about it. This was about my motivation doing romhacking. My problem: In the textengine of OOT, there is a "opcode" to jump to another dialog. This dialog is refered by a 16-bit index. Because there is an index, there must be a index table too, which contains the real adress of the dialog. I checked if there are the real offsets of the dialogs inside the rom or the offsets from beginning of the dialog data. Both doesn't exist (or i didn't find it). Now I need your help how to find an indextable. I thought about choosing a variable which contains any adress and a second one which contains the offset of the dialog in relation to this variable. Then checking each byte (or word or whatever) and see, if the dialog offsets fit inside this system. But to be honest, i don't really know how a indextable might be structured and this algorithm is slow and very bugy. If I make an error while coding that program, it takes me hours to find the error. So if you know a better algorithm to find a indextable or know already how the textsystem in OOT works, I would be very happy. At least I want so say sorry for my bad english. It's not my main language. Thanks for your help jeb |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828      Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6283 days Last view: 6283 days |
| ||
You should be aware that hacking N64 games is hard.  As for your question, the game probably does something like add the data in this index table to a fixed address. If you can, the best method would be to trace the ASM code that reads that instruction and see what it does. |
|||
|
jeb Newcomer Since: 08-15-06 From: Switzerland Last post: 6466 days Last view: 6466 days |
| ||
| Hi!
I thought that sbd. will come and say: It's hard  ASM-Hacking is a difficult task. I have already expirience using ASM for x86, but not for n64. I've seen a few papers about the n64 having a main and 2/3 coprocessors. But i've not yet seen a tutorial on how to use them together. Maybe because it's not that know atm. But does anybody know a good paper/tutorial to learn coding for the n64 to start asm-hacking it?
thx, jeb |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6283 days Last view: 6283 days |
| ||
| I suggest you start messing around with instructions in Nemu's debugger. N64 (R4300i) is a bit like x86. There's a few things you should know though:
-Coprocessors. I think COP0 is the RSP/RDP, not sure but I've never had a need to deal with it in ASM hacking yet. COP1 is the floating point processor. Unless you're hacking physics (speed, weight etc) you probably won't need to deal with COP1, but it's worth studying (not that hard really). -Delay slot. Branching is slow on the R4300, so while a branch is taking place, the instruction after it is executed. That means when you see code like: JAL somewhere ADDIU $A1, $zero, 0004 $A1 is actually set to 4 before the JAL is executed. It's easy to forget about this; don't! You can make good use of it in ASM hacks (and forgetting about it often leads to violent crashes). Note the B*L instructions which skip the delay slot if the branch is not taken. -Funny instructions. Sometimes commercial games do things that seem strange or pointless, but usually they have a purpose. For example you might see a game do this: J somewhere NOP somewhere: etc... This seems like a pointless jump, but executing it clears a cache or some such. Another nice example: OR $A1, $zero, $T2 Any number OR zero is itself, so this copies $T2 into $A1. The R4300 lacks the ability to directly copy registers, so this is a nice way to do it. ($zero (AKA $R0), if you hadn't guessed, is a register whose value is always zero.) -LUI (Load Upper Immediate). Most documents will tell you that this loads an immediate 16-bit value to the upper half of a register. What they often fail to mention is it also zeros the low 16 bits. -Signed addition. I'm not entirely sure of the specifics but IIRC, adding a value over 0x7FFF to a register results in the high word (2 bytes) being decremented, even when using unsigned addition, due to some integer overflow somewhere. You might see this: LUI $A1, 8014 ;$A1 = 0x80140000 LW $A2, C000($A1) This reads from 8013C000! However if the second instruction were LW $A2, 7000 it would read from 80147000. This can be a major pain. -Alignment. 16-bit accesses have to be to an even address (ending in 0, 2, 3, 4, 8, A, C or E); 32-bit accesses - including execution - has to be to an address ending in 0, 4, 8 or C. I'm not sure what happens if they're not aligned but it's probably not what you want. |
|||
Cellar Dweller + Red Koopa   Since: 11-18-05 From: Arkansas Last post: 6292 days Last view: 6283 days |
| ||
| For detailed information on each instruction see http://techpubs.sgi.com/library/manuals/2000/007-2597-001/pdf/007-2597-001.pdf
(The rest of this post if mostly for HH) COP0 is the system control processor. It handles stuff such as the TLB, interrupts, and exceptions. The RSP and RDP are separate from the CPU. The RSP is a modified 32 bit MIPS processor with its own private memory(IMEM for code and DMEM for data). The RSP's COP0 allows it to copy data between main memory(RDRAM) and its private data memory(DMEM). Also, the RSP's COP1 is a vector unit instead of a floating point unit. IMEM, DMEM, and hardware registers to control the RSP and RDP are mapped into the main memory address space(see rcp.h). |
|||
|
jeb Newcomer Since: 08-15-06 From: Switzerland Last post: 6466 days Last view: 6466 days |
| ||
| Thx for your informations. I've also found a few code-examples for n64. I'll see if I understand it.
thanks |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - Finding an indextable |
| |
