Yes. Looking at random code will mean nothing really. Typically when reverse engineering any code, a hacker will start with some bit of known information and work from there. For example, when I did the Fire Emblem pointer work up there, I started with known information which was the start of a text string. I set a breakpoint upon reading that address to get started. That way, when the debugger hits that breakpoint, it is on the specific instruction that loads the first character from that string. You work outward and typically in reverse from there. I saw the address was stored in $00. So, then I tried to figure out HOW that value got to be there. It came from $0f02. Ok.. how did it get there? And so on and so on. You ask questions, you find answers. I find trace files are more useful in some instances than the debugger. They show me a bigger picture at once.

The actual art of turning groups of instructions into logical game actions is a difficult one and really comes with experience. I can recognize things 100 times better just by looking at a group of instructions compared to when I got started years ago. One way to learn is to change some instructions and note the effect it has on the game. You don't want to touch instructions that would effect the stack though because that will just crash the game in most all instances. Bit by bit you'll start to figure it out. Maybe you'll know what 4 instructions do first. Then you branch out until you know what small routine does.  It just takes time.

The most important thing you need to do though is look at code revolving around known information. Even the best of us won't have much like looking at a group of instructions without knowing anything about what's stored in memory locations etc. You need some kind of known information to work with such as text addresses, font addresses, known memory locations, etc. The more information you build up, the better able to understand the code you'll be. things like sta $0055 will translate into STA hitpoints or something like that. You can put logical labels to the addresses similar to what the actual source code the devs had may have looked like.

THIS IS TIME CONSUMING. Remember that. All of ROMhacking is time consuming. You can't learn anything overnight. It will take time, always. You can't try jumping to the end goal. You need to break your tasks into smaller and smaller subtasks until you reach a size you can tackle.

This varies from game to game, and is also an integral part of calculating some games' pointers. It has to do with the game's memory mapping.

For SNES games, there are two main types of memory mapping - HiROM and LoROM. For HiROM games, the game's data is stored in 64KByte banks (0x10000 bytes) and is mapped to the hardware bus at $C0:0000. It's actually pretty simple - the first byte of the file, 0x000000, maps to the hardware at $C0:0000. The second byte 0x000001 or however many zeroes you want to put, maps to $C0:0001. And so on and so forth up to the end of the file. Thus, 0x3DEA5 maps to $C3:DEA5. If you wanted to find the value of a pointer to that location, you just invert the endian on the bytes - A5 DE C3 is the full value of the pointer, but a lot of games will just deal with the lower two bytes, A5 DE.

LoROM games are a bit tougher to understand at first. LoROM banks are only 32KBytes in size (0x8000.) They map to memory at $00:8000 and are mirrored at $80:8000. Thus the first 0x0000-0x7FFF bytes of the file are at $00:8000-$00:FFFF. The tricky bit happens when you roll over to the next bank. Since $XX:0000-$XX:7FFF are reserved for direct access to RAM, the first byte of the second data bank (0x8000 in the file) is mapped at $01:8000. As such, let's say you had an address 0x3440F. The low two bytes of that address are 440F, but since that's accessing RAM as far as the processor is concerned, you need to add an extra $8000 bytes to it to get your "real" pointer value, or C40F (which, endian swapped, is 0F C4.) Calculating the bank is a bit trickier. Since you're on your... *counts*... 6th set of 8000 bytes (counting bank 00) the bank is then 06 or 86 depending on the game.

As far as the NES is concerned, all games map their data differently, but *many* of them have data banks that are 16KBytes in size (0x4000) and are mapped 0x8000-0xBFFF. Do with that information as you will.

Did you try finding the pointer for that string? It is a different game and they're probably stored differently than in the SNES remake.

Gideon Zhi just explained why that "descrepancy" exists.
You should really learn to read people's posts and put some thought into them.

cYa,

Tauwasser

Funny thing is I actually found the pointers, without taking one look at the debugger. Really though all the complicated, mindboggling "ASM" "Offsets" headache, wasn't necessary to find what I wanted to find.