How to find X and Y in debugger ?

[raousoft]

Hi , I am kinda noob in terms of debugging
I started first a breakpoint on the RAM value of X position (of a sprite)
When I track down that , I find something similar to this :


I was never able to find where the Y value originates from , where $EB27 here is an unidentified block.

[Quietust]

Hi , I am kinda noob in terms of debugging
I started first a breakpoint on the RAM value of X position (of a sprite)
When I track down that , I find something similar to this :


I was never able to find where the Y value originates from , where $EB27 here is an unidentified block.

You'll just need to trace further back - if your emulator's debugger has an option to output an execution log, that'll probably help.

Also, are you sure that code is related to a sprite's X coordinate? All I see is an indirect read through a pointer in zeropage, ultimately reading a value from ROM.

[raousoft]

Thanks for the information,
I wanted to change the X,Y position of a sprite based text.
When I peek at the OAM RAM (Y,Tile,Attrib,X), then I perform a RAM (CPU) search and try the addresses till the text change position.
That's how I did set up a breakpoint, now if it's getting the values from the ROM, How can I track that.

[Quietust]

I wanted to change the X,Y position of a sprite based text.
When I peek at the OAM RAM (Y,Tile,Attrib,X), then I perform a RAM (CPU) search and try the addresses till the text change position.
That's how I did set up a breakpoint, now if it's getting the values from the ROM, How can I track that.

The way you "track that" is by reverse-engineering the program - you disassemble it, find the code that manages sprites, then figure out exactly how it works (or at least enough to solve your specific problem).

If you're looking for specific addresses, there are none - there was no "standard library" for the NES back then, so every developer had to write their sprite logic from scratch, and as a result, most of them did it differently.

[unregistered]

Hi , I am kinda noob in terms of debugging
I started first a breakpoint on the RAM value of X position (of a sprite)
When I track down that , I find something similar to this :


I was never able to find where the Y value originates from , where $EB27 here is an unidentified block.

Quietust gave excellent advice, but I’ll dive a little into getting you started... hope that’s ok.


When this code shows up:

Code: Select all

lda ($00), y @ $EB27 = $30

and you want to solve what it’s doing...

1.) that’s an indirect indexing instruction. So:

a) It pulls the byte at $00, makes it a low byte, and combines it with a high byte - from $01 (the high byte is always pulled from the next memory location after the location in parentheses). So, let’s say $00 holds #$25 and $01 holds #$EB. Then the result of that combination is $EB25.

b) next, using $EB25 as the base-address, it adds the value of the y register to that address... since the read from value is $EB27, y, in this example, must be 2.

2.) That line of code is also declaring that $EB27 now holds #$30. So, if that is the current line (in the PC or Program Counter), the accumulator register will definitely hold #$30 after processing that instruction.


Mesen’s “Memory Tools” and its debugger will easily let you double check everything you’ve just read.

edit.

[raousoft]

Thank you so much, you made many things clear to me

[unregistered]

Thank you so much, you made many things clear to me

Sorry for this incredibly late response, but you’re welcome! Happy it helped.