[Lunky]

Hi Everybody,

I'm quite new to the editing scene when it comes to tiles, sprites, and whatnot. So,,, i'm running in to an issue that I can't get my head around.

So, i'm fooling around in a NES game for learning purposes and i'm actually trying to change some NPC locations. To be specific; I'm trying to make the shopkeeper and the old man to switch places in some areas, Just the NPC sprites, not their actions. for example; "It's Dangerous to go alone, take this" should be done by the shopkeeper, not the old man.

i thought it would be as easy as searching the  sprite HEX code and just swap them for that specific room, but i can't seem to find those in the rom file. I know they're $99, and $9D, atleast that's what the emulators PPU viewer tells me.

How do I tackle this as a newbie?

Cheers!

[Psyklax]

Well that's not going to work. But it's good that you're experimenting yourself.

I don't know what $99 and $9D refer to here but I assume it's the address on the pattern table for part of the characters (I assume the two characters use more than one 8x8 tile).

The easiest method would be to literally copy-paste the characters over each other in Tile Molester: no hacking knowledge required, but somehow I think it'd defeat the purpose of experimenting.

If you want to change the actual reference, you'll have to get into the code, so we're talking assembly. It's not as scary as you might think, but you won't find it by simply searching the ROM for $99, as you'll find thousands of results ($99 is quite a common opcode for an assembly instruction).

I'll have a look later today and see if I can figure out what you're looking for.

EDIT: Okay, I've had a look, and I have some success. I'll give you the short explanation of what to do, then how I did it.

Open a hex editor like HxC and change:
$6EEB to 9C
$6EED to 98
$6FB7 to 00
$6FB9 to 02

Right, now the explanation of how I found that.

Opened FCEUX's PPU Viewer and saw the two tiles for the old man at $98 and $99 (Zelda uses 8x16 sprite mode, so they count as a single sprite). The game takes those two tiles (one sprite) and flips them horizontally for the other half of him. So to see why the game picked $98 for the old man, we need to use the Trace Logger.

Using save states, I get to the frame directly before the old man appears on-screen, turn on Trace Logger (to a file), advance one single frame, then turn off the Trace Logger. This gives me a file with everything the CPU did in that one frame - it's a lot, but it definitely found that $98 in that frame. I look in the RAM at that moment at $200-300 and search for $98. I see it in there twice - one for the left side, one for the right. You'll need to read about PPU OAM to understand what the $200-300 area of memory actually means:
http://wiki.nesdev.com/w/index.php/PPU_OAM

Anyway, I find the exact RAM address where $98 gets sent to, and search for it in the log file. I see an instruction at $788D: STA $0201,X @ $0289 = #$98. This tells the CPU to store the contents of the Accumulator to address $289 (your number may vary as it's cycled around the $200-300 range), the contents of which is $98, obviously. So I then search backwards for #$98 to see where that came from, hoping for something between $6000-FFFF (meaning it came from the ROM).

I see it was stored to $0002 in RAM, but it got there from $766B - bingo. Now, the $6000-7FFF portion of NES address space isn't actually ROM, it's cartridge SRAM - where the games are saved for later. People think SRAM is just for saving games, but in fact it's simply extra RAM which can keep its state with a constant power source - like a battery - whereas the RAM in the NES will lose its data if it's not constantly refreshed. So the game took this $98 from the ROM and wrote it to the SRAM. So where is it in the ROM? Let's right-click $766B in the RAM window, and make a write breakpoint, then reset the game.

As the NES boots, it will write $98 to $766B, and we can now see that it comes from $AEDB in the NES address space. So go to $AEDB in the RAM window, right-click, "go here in ROM file", and there's your result: $6EEB. As for the other two numbers, that's to select the palette, because the old man and the trader use different palettes. I found those numbers the exact same way.

So there you have it. Of course I have a lot of experience with the NES and 6502 assembly, but if I can figure it out, so can you. Hope this was educational for you!

[KingMike]

NES games rarely use cartridge RAM for code execution. Normally data storage (whether saved or temporary).
It's very likely Nintendo did it in FDS port games (Zelda, Metroid, Kid Icarus) to reuse FDS code, from which RAM execution was required (by copying code from the ROM to the SRAM).

Likewise I can only recall seeing one SNES game executing code from RAM (Popful Mail).

[Psyklax]

NES games rarely use cartridge RAM for code execution. Normally data storage (whether saved or temporary).
It's very likely Nintendo did it in FDS port games (Zelda, Metroid, Kid Icarus) to reuse FDS code, from which RAM execution was required (by copying code from the ROM to the SRAM).

The FDS had RAM in the $6000-DFFF range, so maybe they use the SRAM so that the code can still reference the same addresses without any modification. Sure, they could just bump every address up by $2000 but since they were using cartridge SRAM anyway to store save games, they probably figured it was easier this way.

[abw]

Likewise I can only recall seeing one SNES game executing code from RAM (Popful Mail).

Here's one to add to the list, then: during 4 of the cinematics in FFVI (the title screen, the opening credits, the floating island rising into the sky, and the world tearing apart), the game decompresses a chunk of stuff from $C2686C - $C28A60 into $7E5000 - $7E7C62 and then starts executing code from $7E5000/$7E5003/$7E5006/$7E5009. There are some references on the wiki if you're interested.

[Fiskbit]

Zelda executes from RAM because it doesn't have enough space in the fixed bank to house all the non-swappable code. This is because the cart version lacks the extra FDS sound capabilities, so it has to rely on DPCM for some of its sound effects. DPCM data must live in the last 16 KB and takes up over half of the fixed bank.

[Lunky]

Well that's not going to work. But it's good that you're experimenting yourself.

I don't know what $99 and $9D refer to here but I assume it's the address on the pattern table for part of the characters (I assume the two characters use more than one 8x8 tile).

The easiest method would be to literally copy-paste the characters over each other in Tile Molester: no hacking knowledge required, but somehow I think it'd defeat the purpose of experimenting.

If you want to change the actual reference, you'll have to get into the code, so we're talking assembly. It's not as scary as you might think, but you won't find it by simply searching the ROM for $99, as you'll find thousands of results ($99 is quite a common opcode for an assembly instruction).

I'll have a look later today and see if I can figure out what you're looking for.

EDIT: Okay, I've had a look, and I have some success. I'll give you the short explanation of what to do, then how I did it.

Open a hex editor like HxC and change:
$6EEB to 9C
$6EED to 98
$6FB7 to 00
$6FB9 to 02

Right, now the explanation of how I found that.

Opened FCEUX's PPU Viewer and saw the two tiles for the old man at $98 and $99 (Zelda uses 8x16 sprite mode, so they count as a single sprite). The game takes those two tiles (one sprite) and flips them horizontally for the other half of him. So to see why the game picked $98 for the old man, we need to use the Trace Logger.

Using save states, I get to the frame directly before the old man appears on-screen, turn on Trace Logger (to a file), advance one single frame, then turn off the Trace Logger. This gives me a file with everything the CPU did in that one frame - it's a lot, but it definitely found that $98 in that frame. I look in the RAM at that moment at $200-300 and search for $98. I see it in there twice - one for the left side, one for the right. You'll need to read about PPU OAM to understand what the $200-300 area of memory actually means:
http://wiki.nesdev.com/w/index.php/PPU_OAM

Anyway, I find the exact RAM address where $98 gets sent to, and search for it in the log file. I see an instruction at $788D: STA $0201,X @ $0289 = #$98. This tells the CPU to store the contents of the Accumulator to address $289 (your number may vary as it's cycled around the $200-300 range), the contents of which is $98, obviously. So I then search backwards for #$98 to see where that came from, hoping for something between $6000-FFFF (meaning it came from the ROM).

I see it was stored to $0002 in RAM, but it got there from $766B - bingo. Now, the $6000-7FFF portion of NES address space isn't actually ROM, it's cartridge SRAM - where the games are saved for later. People think SRAM is just for saving games, but in fact it's simply extra RAM which can keep its state with a constant power source - like a battery - whereas the RAM in the NES will lose its data if it's not constantly refreshed. So the game took this $98 from the ROM and wrote it to the SRAM. So where is it in the ROM? Let's right-click $766B in the RAM window, and make a write breakpoint, then reset the game.

As the NES boots, it will write $98 to $766B, and we can now see that it comes from $AEDB in the NES address space. So go to $AEDB in the RAM window, right-click, "go here in ROM file", and there's your result: $6EEB. As for the other two numbers, that's to select the palette, because the old man and the trader use different palettes. I found those numbers the exact same way.

So there you have it. Of course I have a lot of experience with the NES and 6502 assembly, but if I can figure it out, so can you. Hope this was educational for you!

You sir, are amazing, very educational and gets me going to search more stuff. good thing about roms is, if you break it, you can try and fix it, if you can't fix it, there's a backup,

Small question; i'm assuming the above adresses will switch all the trader and old man tiles. what about specific places ( as in rooms/dungeons )? Is it possible to switch their tiles room per room? Same principle?

Thanks for your contribution and lesson!

[Psyklax]

what about specific places ( as in rooms/dungeons )? Is it possible to switch their tiles room per room? Same principle?

Not sure I understand, do you mean switching rooms? So when you enter the shop you actually enter the old guy's place? I mean, that's probably a little different - the function of the room and the look of the room will be separate. But anything's possible with ROM hacking, so maybe what I've shown you already will give you some kind of starting point.

[Lunky]

Not sure I understand, do you mean switching rooms? So when you enter the shop you actually enter the old guy's place? I mean, that's probably a little different - the function of the room and the look of the room will be separate. But anything's possible with ROM hacking, so maybe what I've shown you already will give you some kind of starting point.

Thanks for the answer!

What I mean is, in example; When i'm switching tiles , i would like the spots to be more specific.

In the original, the Old man is the  tile for the "Money making game" rooms, let's say i want to switch his Tile for those specific rooms with the Moblin tile.

But keep his Tile for the "It's dangerous to go alone" room. Is it the same Principle as above?

Sorry for the awfull sentences, autocorrect isn't my best friend.

I'll fool around more when weekend is here.

Thanks again for the valuable lesson!