Ok. I just thought that obvious though when the answer was given being that you can see it in the log. I didn't really understand the point of your post.

On another note, Geiger's Debugger should be updated. It's now outdated by quite a bit compared to the latest version of SNES9x. I wonder if he's still interested at all in updating it.

This is a good reason why debugging features should be included in the main build of the emulators. It's always present with the latest version so this problem doesn't occur.

I agree completely. Why don't emulator authors include debuggers? Wouldn't that make their job significantly easier when they find a game that doesn't run?

Also, Geiger if you're reading this and considering updating your debugger, please include VRAM breakpoints.

You took the words of what I wanted to say right out of my mouth. I doubt he'll update it, it's been what, 2 years? Lack of VRAM breakpoints is why a breakpoint on $00420B writes is the next best thing I suggested :/. But even that isn't fully adequate. Some games don't use DMA to write to VRAM, they do sequential writes with the S-CPU to $2118 or $2119 during forced blank and that is much more difficult to track. (B/c the pointer generally will auto increment/decrement and you can't set a breakpoint on any particular address it takes on. You can see it by clicking on "what's used" after each instruction but that's about it.)

Oops, yeah. There's the DBR in the [nn:nnnn] address. Well, I haven't used Geiger's debugger in quite a long time. Good to know you can hack your way around problems like this, though. Pretty much the only thing that made my earlier translation hacks possible was my knowledge of every last undocumented command in the ZSNES debugger. I even used to hex edit the savestates directly to change the register values.

Don't go with bsnes v014+, it lacks the debugger. I'm trying to come up with a way of keeping as much of the debugger out of the core as possible, and I'll probably then rewrite it. The good news is that it'll be the first native Linux SNES debugger. Not that anyone will care or ever use it because of its' speed. But a really good debugger will needs hooks all over the code, slowing down emulation when it is not on, and making the code harder to read.

v013 has VRAM breakpoints, and they are a godsend. I was able to track down an obscure tilemap issue in Der Langrisser in like ~5 minutes with those.

But look on the bright side, we're getting closer and closer to having every game we want translated anyway. We won't need a debugger much longer. We really needed it back in the beginning. Imagine an FF5 hack on par with d4s' work on BoF2. FF5 GBA would no longer be the definitive port.


Not really. We have the ultimate debuggers: the emulator source code, and knowledge of how it works. I can go in and add my debugging extensions directly into my emulator to track things at a level a debugger could never, ever come close to. I also can typically tell what part of the SNES is causing the bug just by looking at it, which narrows my search down a lot. Plus, I only have one known bug at this time, so I don't have much of a need for help tracking them down