News: 11 March 2016 - Forum Rules

Author Topic: Help using a debugger to track where a ROM resets  (Read 463 times)

cschifani

  • Jr. Member
  • **
  • Posts: 34
    • View Profile
Help using a debugger to track where a ROM resets
« on: August 07, 2021, 12:31:06 pm »
I'm tinkering with a ROM hack of Rockman 2, and I know that there is an issue that causes the game to reset to the bootup screen somewhere between offsets 3d78d and 3dd10. I have a savestate one frame before the game resets, and I'd like to use the FCEUX debugger to find out what is being called that causes the game to reset. I can guess that the game is jumping to 38019 or something like that because that's usually what shows up on the debugger immediately after the reset, but this doesn't seem to be the issue. Can someone describe for me how I might use the FCEUX debugger to better pinpoint the cause of the reset? Any help you might provide would be greatly appreciated.

Cyneprepou4uk

  • Hero Member
  • *****
  • Posts: 719
  • I am the baldest romhacker
    • View Profile
Re: Help using a debugger to track where a ROM resets
« Reply #1 on: August 07, 2021, 01:18:54 pm »
Try enable "break on bad opcodes" checkmark in debugger.

FAST6191

  • Hero Member
  • *****
  • Posts: 3301
    • View Profile
Re: Help using a debugger to track where a ROM resets
« Reply #2 on: August 07, 2021, 04:22:18 pm »
http://fceux.com/web/help/Debugger.html

There are many schools of thought.

You can run to line if you have a range, or use a break on execute to do much the same.

You can step through the code one instruction at a time.

You can see if something jumps to the reset vector (given the name RST if you don't want to use the FFFC it is in memory).

Stepping is probably what most would do. Here you literally execute one instruction at a time and can observe what is going on -- a fault causing a hang that is resolved by a reset being the likely suspect. I don't know the NES fault handling though and https://wiki.nesdev.com/w/index.php?title=CPU_interrupts