[pianohombre]

I've found a couple RAM Maps detailing certain video game properties at start-up. For instance: number of lives to start, character upgrades, etc.

I can edit this data at run-time using BSNES. For example, say I want the character to start with 5 lives instead of 2. At location $7E:1F80 I can easily pause/break the rom change 02 to 05 then run the rom again. And after refreshing the screen it will show 5 lives. However, $7E:1F80 is not viewable in the hex editor since it doesn't understand SNES addresses. So I use Lunar Address to find mirror address $00:2B93 (dma location not exactly 100% sure how this works as of yet). Ok so I load that new address in an assembly editor or hex editor and it reads as follows:

Code: [Select]

80A993: A9 2C LDA #$2C ;load accumulator address location 2c
80A995: AA TAX ;transfer accumulator to x
80A996: 98 TYA ;transfer y to accumulator
..
So when viewing RAM in bsnes it was easy to temporarily change values, but if I want to permanently have the character start with 5 lives I need to edit the ROM, yet the value reads as A9 instead of the 02 in the video game. Am I doing a mistake switching between SNES and PC addresses, or did I make a mistake somewhere else? I've read a lot of documentation apparently $7E is the WRAM location, but it's supposed to be mirrored in $00.

[FuSoYa]

Your mistake is in assuming the RAM is part of the ROM.  It's not.  WRAM is temporary storage that goes away when your SNES is turned off.  Lunar Address is assuming you know that, and is just giving you the ZSNES savestate location in case you want to play with it that way (hence the "ZSNES ZST" text description under the address).

Anyway, if you want to know where the value is coming from you'll want to use a SNES debugger/tracer.  You can either run a trace and search it for the RAM address in question to work out what ROM address the value was originally loaded from in the code, or set a breakpoint on the RAM address to pause code execution when it's modified and hopefully what you want is just a few bytes before that.

You may need to hunt a bit though, as the first few writes may be for something unrelated as the game might first clear the address, or use it for displaying a title screen, or whatever.  Reverse engineering skills and knowledge of 65816 ASM are a plus for something like this.

[pianohombre]

Boy all this rom-editing is very tedious. I feel like there's 10 steps for every one task someone wants to do. It feels like the stone-age of programming. When I searched on google, reading different forum posts about editing ram/rom/wram I didn't hear anything about tracing/breakpoints. I'll look into it. Thanks.
April 11, 2017, 03:34:38 am - (Auto Merged - Double Posts are not allowed before 7 days.)Hi thanks for the above response. I watched how to debug in bsnes, although most people prefer snes9x debugger it seems, and was able to get the rom working. It was pretty straight-forward much easier than trying to debug a large program in c++ with 100 breakpoints. Just changed one value. I just had to switch a value. I spent many hours over the course of 3 or 4 days searching through hexadecimal and thousands of lines of assembly trying to find a needle in a haystack before learning to use this breakpoint thing properly.

Next, I'd like to add some 65816 asm instructions in there to change a few instructions. I'll have to rewatch an example I saw on youtube about pointers. Again I'd like to edit the ROM, not just edit the save state file or apply an asm patch.