Got a savestate?



Move the mouse over the sprites in the Scene Viewer; the Memory Viewer should update itself accordingly (unless the offset is too large - in that case try reducing the window size to 1x1).



Yes.

With that vram address, I found the "pixels" of the sprites in the ROM, but it doesnt change the xy location.
Please, how do I find the attributes?

please bare with me, obviously I'm learning as I go.
I gather this is the calculation you're talking about:
address_of_character = (base_location_bits << 14) + (32 * character_number)
I have a couple more questions
1. The source of the $2102 breakpoint should be VRAM?
2. I'm not understanding what << means in the calculation example

Shifting left = adding a zero to the binary value; shifting right = removing the last binary digit. Same result as multiplying with / dividing by 2. But no, that's not the calculation. The breakpoint source can be RAM or ROM.

See the section "sprites" in anomie's doc again. OAM has a low table (containing xPos, yPos, tile index, palette etc.) and a high table (containing bit 9 of xPos, and the sprite size selector). Let's say you want to change the vertical position of sprite #53 (counting from zero). The position of sprite #53 in the low table is 53 * 4 = 212, and yPos is the second byte.

...
byte 208 = sprite #52 xPos
byte 209 = sprite #52 yPos
byte 210 = sprite #52 tile
byte 211 = sprite #52 name table, palette etc.
byte 212 = sprite #53 xPos
byte 213 = sprite #53 yPos
byte 214 = sprite #53 tile
byte 215 = sprite #53 name table, palette etc.
byte 216 = sprite #54 xPos
byte 217 = sprite #54 yPos
byte 218 = sprite #54 tile
byte 219 = sprite #54 name table, palette etc.
...

So you'd set the breakpoint for write access at address 2104h (OAM data register) when register 2102h is 213.
Note that a breakpoint hit is only valid when bit 0 of register 2103h is not set (i.e. the low table is selected).


(Please correct me if I'm wrong.)

Sometimes I work around the limitations of Geiger's debugger by tracing DMA transfers or breaking on writes to $2116. Then you can see the VRAM address being used for the beginning of most transfers to VRAM. Certainly not nearly as nice as breaking on write to specific VRAM addresses, but it's something. If I get severely frustrated, I still keep a copy of BSNES .13 that does break on VRAM writes.

I tried to contact Geiger awhile back for source code so I could update the bloody debugger, but he never answered. SNES debuggers are still stuck in a time warp of several years ago.

At least you've kept things progressing better with emulation though. Who needs additional research? It just isn't necessary. The SNES is simple enough that emulators, especially yours, already does 99% of everything. How do you like that? Your own logic (regarding debuggers below) against you! (I don't even share that view, I said it simply for logic/argument sake)


Debuggers have never really been about necessity, but rather efficiency and time saving in my opinion. I could do 95% of my hacking work with nothing but a hex editor if I tried hard enough, but why should anyone when there's a better tool for the job that can make it much faster and save valuable time?

A full featured debugger saves time and is more efficient in problem solving, testing, or investigating many occurrences. I think you need to get started on a new SNES ROM hacking project again, use the tools we have, and then tell me if a better debugger would have saved you time. You're too far removed. I'm thinking you'd agree. You yourself have said you have used the BSNES source code for your debugging, thus proving the existing tools are not good enough. Unfortunately, I doubt modifying the BSNES source for debugging needs is going to be a preferred, effective debugging solution for many out there. It certainly isn't for myself.

I don't know much about this kind of thing, but would it be possible to have a separate program interact or control BSNES as a debugger? It would then be this separate program handling the debugging windows and functionality mostly independent of the emulator other than some control communication back and forth. I think I've seen something like that somewhere before. Just a thought as I'm not versed enough in co-threading or BSNES's design model to know if something like that is feasible.


Now, if we could just have that same functionality without having to get compilers, install packages, learn foreign source code, and modify code, we wouldn't be having this conversation!

It's less to do with the UI.. but the interface itself is barely passable (let's face it, putting up a DOS-ish console screen while running ZSNES isn't the most appealing thing in the world). It will be rewritten using QT. However, the bigger issue is the core (to be rewritten/replaced), which is preventing this portion from finishing...

Even then, you probably should wait til 2020 or something (or earlier perhaps), because the debugger is currently at the backburner of "stuff to do".