[pianohombre]

Basically, I'm working on an editor. It supports more than one game. It has been completely done for 3 games and partially done for 1 game. I'm trying to determine how to find some unknown values for the partially done game so that it will work better. I know the editor works for this game (i.e. the layout is showing up correctly so that means it gets decompression correctly). I was thinking of running a trace-route for the completed game on a few known values, but here's my problem:

in hex and assembly it all looks like gibberish to me, just a hodge-podge of numbers and letters. Yes, I have a chart of assembly definitions so I know, for example, what LDA, STA, JSR means. I just can't determine the significance of unique addresses in a chunk of code. Like, why is this address important? and ok the programmers picked this random address to store the beginning of a pointer table, but how will I find this random address in a game that hasn't been hacked to death?

[Valendian]

Static analysis (reading the code) is difficult, it is better to use a debugger. The debugger will allow you to watch the code execute in slow motion so you can observe how the data flows through the registers. A debugger does this by allowing you to step through the code one instruction at a time and will pause until you manually step forward. Break points can save time. If you place a read/write break point on data, then the debugger will run like a normal emulator but will stop when the game reads or writes that data. You can also place execute break points on instructions.

[pianohombre]

Hi, thanks for your response. There is a program that converts (snes) hex into assembly, but I do enjoy being able to use an emulator/debugger to enter different values, into the RAM, for example and see it execute live. I do enjoy having the debugger sometimes spit out ASM code into a separate file, during a specific action though. Sometimes it's easier to look at a 10-20kb file, than scroll through thousands of lines in a file 3mb or less.

I'm not exactly sure the difference between setting a breakpoint for read/write/execute though. I'll have to briefly skim over documentation. I think if I can see a block of code 50 lines or less that executes properly with the known address, it will help narrow down the address location in another rom. Generally, the unknown address will be in the same bank (as the other rom), but not necessarily so. That's where things can get tedious and time-consuming and a needle in a haystack.

[Valendian]

Yeah its always going to be tedious when you work so close to the metal. But every small step is progress and all adds up over time.

These values you're looking for, do you know roughly where the data lives? If you have some idea then corrupting that region of data will help narrow it down. This is much faster than walking through code.

Or do you know the function in which it should be accessed? Only thing to do here is set a break point at the function entry point, when that triggers the debugger will break. Take this opportunity to make a save state so you can rewind the clock. Nop out instructions and step through over and over again, that's all you can really do here.

[FAST6191]

Break on read
You know where something is in the ROM (or RAM if it started life as you making a cheat) and you tell the emulator to stop (or log) when that area is read by something.

Break on write.
You have an area of RAM you know something ends up in. You set this and the emulator will stop (or log) when this area gets written to and tell you what did it. Many times the instruction itself, preceding instructions or the other register states will tell you where is reading from as well. At first most use this for graphics (know a font lands in this place, set a break on write there, start the game/section again and watch it read it from the ROM), but it soon becomes useful for all sorts of things (if you know a stats table in RAM then you can find it in the ROM, or the save).

Break on execute
Not all the ROM or RAM (varies with system -- stuff like the GBA will mostly run code directly from the ROM section, stuff like the DS and anything that runs from a CD or floppy disc will most likely use RAM) is code for the CPU (obviously you have graphics, music, level data...). The breakpoint will stop (or log) when the CPU runs code at this location. At first most would probably use it to help with subroutines -- if a game does something fairly complex but infrequently/at essentially random points (you typically don't die in a game exactly every 5000ms or at the end of a song) it will tend to kick it to a subroutine. You can use this to help you find everything that calls this subroutine. Not a great example but when we are first teaching assembly we will often teach people to convert a cheat, say infinite lives in Mario. A cheat is easy -- you have one life counter unless it is an anti cheat game, however the assembly for it may have many things that touch the life counter (pits, poison mushrooms, time, crushing, enemies, hazards...) so you would have to find everything that removes from that to do infinite lives, assuming it does not kick it to a subroutine anyway.
Another first/early use is for stepping through code. You might know where a section of code is* and what the end result is or generally is, however the methods it uses on the way may be useful to know. Classic examples are for figuring out stuff like https://www.dragonflycave.com/mechanics/gen-i-capturing (a "hidden" mechanic or calculation the game does) or figuring out custom compression.

*for the "hidden" calculation/mechanic you might bet on it eventually using HP or another stat. You set a break on read for that stat in RAM, go into a position where it will calculate something based on it (say a fight in a game) and now you know what is reading the stat to use.

[pianohombre]

If you have some idea then corrupting that region of data will help narrow it down. This is much faster than walking through code.

Not necessarily, although I may have found an address that's important, there's several values that are required for the engine to piece together the graphics I'm looking for. Basically it simulates what an emulator might do, but it's light-weight compared to something people use frequently. I'm going to try and get the trace log for a rom with working values then spend a few hours trying to wrap my head around it. It looks like PPU is an important processor for handling graphics. I might be better off trace-logging that than the CPU.

[Psyklax]

It looks like PPU is an important processor for handling graphics.

You don't say? So you're looking at the NES, correct? Well, you can't trace log the PPU, because it doesn't take instructions like the CPU does. Instead, the CPU interacts with it through registers. So if you want to change a byte in the PPU's memory, the CPU has to write two bytes to one register for the address, then write the byte it wants to another register to perform the write.

Also, I'm not entirely sure what you're working on, but getting familiar with assembly and a debugger will probably be helpful.

[pianohombre]

Psylax, no it's an snes game: Megaman & Bass, for the editor I've been working on forever.