Romhacking => ROM Hacking Discussion => Topic started by: dnsmatch on July 13, 2020, 11:20:17 pm

Title: FCEUX tracing help
Post by: dnsmatch on July 13, 2020, 11:20:17 pm
I am new to assembly hacking and have had success with creating game genie codes with SNES9x Gieger and some simple NES games. I do understand basic assembly such as storing, loading, comparing and branching basics. My trouble is as a newbie, is how do you keep track of a routine that your in? If I find x player movement RAM address for example and set a break point, and my goal is to walk thru walls, or something bit more complicated, how should I go about of knowing if i am in correct routine? Example, if i want to do a walk thru walls code, would my RAM address appear somewhere near the routine? I have done some walk thru walls on SNES, but damn, so many routines, its hard to know if its relevant and instead of changing the branches one at a time and hoping for expected result, is there a better methodology? A simple act of walking into a wall then stopping a trace can produce thousands of lines of code! I do understand often times there will be repeat of routines you can keep going past, but what do you guys look for and how do you keep track if the routine is correct or not?

July 14, 2020, 03:18:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
So with SNES 9x I can trace fine, but does FCEUX have a trace log that can output to a file inside of in the console?
Title: Re: FCEUX tracing help
Post by: bogaabogaa on July 15, 2020, 01:38:15 pm
What helps to find routines you are interested in is knowing the platform well enough so you can imagine how things might be programmed. You made the example for watching players xPos. That one is easy to find and you can spot other things with sometimes just watching RAM. A good example is OAM is something that is easy to spot for some retro consoles.  When you like to walk through walls you like to get to the collusion routines. The PPU can't do any of it so you know it needs to be on the CPU side.
Sometimes the collusion of tiles are placed in a memory table in RAM or WRAM. It can be spot when you have your PPU viewer open and brows the RAM pages. Else there comes not much to mind then return from Routines early to see what they do.
Try to use different tools. Like try out Bsnes Plus, Mesen-S, GigerSnes9x or Bizhawk. Some debugger might be good for something a other one is good for something else.
Title: Re: FCEUX tracing help
Post by: Cyneprepou4uk on July 15, 2020, 04:12:13 pm
Why does code read axis position ram addresses? To change movement, to draw sprites, to check collisions with walls, enemies and projectiles, to scroll the level, something else maybe. If you see anything that you don't need in a routine where breakpoint was hit, then you are probably in a wrong room. Comments for other ram addresses help you read the code.

You can set additional breakpoint to a "wall" ram address while moving towards a wall (toggle a movement button or freeze a proper value in a button address), which is located in a large range of ram addresses for level data. Then check for cpu cycles counter in debugger between breakpoints hits of axis and wall addresses. The value should be not very high if both hits happen in a routine you are looking for.

does FCEUX have a trace log that can output to a file inside of in the console?

Fceux has a good tracer which can output to a text file. Also it can be combined with a code/data logger. You can start logging data and keep moving around in the game in a single place without hitting walls until logger can't find new data anymore. Then set "only log new code" option in a tracer and launch it, go hit a wall, and log should basically have only code which is required for forbitting you from moving foward.