When a breakpoint is hit, the game will pause and you can manually step through the code currently executing in the debugger with the control buttons at the upper left.
You can see the current state of the registers, such as the accumulator and X/Y indices, in the top right. You can also see the state of specific RAM addresses in the debugger itself; for instance, this line shown in the screenshot:
INC $19 [$000019] = $01
is indicating that the RAM address $19 is currently $01 as of the line the debugger is currently at.
With that information, you can check that the values being obtained and written in the code actually line up with what you are expecting. In particular, a few things you'll want to confirm:
That the X index being used to get a value from the TileProp table is actually within the range of that table (i.e. it is between 00 and 05). This may indicate an issue with the way the index is being obtained. If you are getting bad values, check that the value of $157C (the sprite's direction) is only either 00 or 01; any other values will cause incorrect indices.
That the values being obtained from the TileProp table actually match up with the values you have in the code. If not, check whether the data bank is set correctly (the "D" register in the CPU view). It should match the bank the code is currently running in; if it doesn't, that bank isn't being properly set, so the code ends up using a different ROM address than the one you're actually expecting it to be.
That the Y index used to index the OAM data hasn't been changed. It should be the same value for each of the $0300/$0301/$0302/$0303 addresses, and the value itself should be a multiple of 04 in hex (i.e. [x0], [x4], [x8], or [xC]). If it's not a multiple of 4, then the OAM data is misaligned for some reason.
That the OAM data isn't being overwritten by something else. You can do this by setting a breakpoint on the specific address the YXPPCCCT settings are being written to (the 24-bit address shown in light blue by the debugger). When you press the "continue" button in the top left (the play button), the code will skip until the next breakpoint is hit, i.e. when the RAM address gets written to again.
This isn't an all-encompassing list of potential causes, but it'll give you a starting point on what to look for. Basically, just look for anything that doesn't match up with how the code seems like it should be executing.
Professional frame-by-frame time wizard. YouTube
- SMW Glitch List
- SMW Randomizer