bsnes-plus and xkas-plus (new debugger and assembler)

[infidelity]

I have another request regarding the Memory Viewer within the bsnes plus debugger. Would you consider an option for users, to not have to refresh the RAM, but to have the debugger consistently do it? I ask because, I'm starting to understand better on the usage of that refresh button. This goes back to an earlier question I had, regarding the significant time lag in RAM register writes.

For a simple example, if you know where the controllers push bit register is in the game you are working on, and you press a button, there is an almost 1 second, to 1 1/2 second delay from the time you press the button, to the time that result is displayed in the snes RAM.

If I kept pressing the refresh button, as fast as physically possible, the results of other specific RAM writes were showing up much faster than before.

If there is anyway there can be option to disable that refresh button, and to have the RAM consistently updated on it's own, this would be a huge benefactor. Because with the RAM being updated visually the way it should, I can pin-point specific things, such as timers for certain actions, how each specific plane scrolls it's x/y positions, fade ins/outs for palettes or the snes's brightness register, etc, etc.

I apologize for the consistent requests, but I feel not only to myself, but for others in my hacking mode as well, the requests I've mentioned would really help out hackers such as us. I've been rom hacking the 6502 NES for 10 years now, and because of your work in bsnes plus, I've never put this much time & effort into studying the 65c816's opcodes, to go along with the 6502 set I know by heart.

Again thanks for your all your work and efforts. -infidelity

Edit - I see you already had this same question asked, and answered haha. http://www.romhacking.net/forum/index.p ... c=19640.20

[Revenant]

Still slowly working on bsnes-plus in my spare time, but I also (finally) touched up xkas-plus a bit and added a link to binaries in the OP. Check it out!

Fun fact: KALE uses xkas-plus to generate limit-removing patches (in IPS format) that can be applied from the editor, as an example of how I've extended it to be useful for systems other than the SNES.

[Revenant]

https://youtu.be/fZPjFJGzI88

Didn't have the time or motivation to work on useful debugging stuff lately, so I spent a couple of hours banging this out instead.

I'll be rewriting the memory and breakpoint editors soon, and will probably release again after that. In the meantime, EmuCR has daily snapshots now (which I haven't tested at all, so try them and see, I guess).

[Optiroc]

https://youtu.be/fZPjFJGzI88

Didn't have the time or motivation to work on useful debugging stuff lately, so I spent a couple of hours banging this out instead.

Ha! Great stuff. I'll use that as a tool for teaching my kid play our favourite SNES songs on an 8-manual organ in a couple of years.. (:

I'll be rewriting the memory and breakpoint editors soon, and will probably release again after that. In the meantime, EmuCR has daily snapshots now (which I haven't tested at all, so try them and see, I guess).

Looking forward to any new development, I'm so thrilled to finally have a working and malleable SNES debugger at hand. Do you reckon you'll make any changes to the bsnes part of the breakpoints, or is it only ut-qt/ changes? I'm thinking of adding breakpoint import options from the commandline, but maybe you're planning that as well?

[Near]

https://youtu.be/fZPjFJGzI88

Real Piano Hero 4-player coop mode.

[Sik]

Huh, fading out only lowers the volume, it doesn't stop playback after it goes mute.

[Revenant]

Do you reckon you'll make any changes to the bsnes part of the breakpoints, or is it only ut-qt/ changes? I'm thinking of adding breakpoint import options from the commandline, but maybe you're planning that as well?

I'm planning to have breakpoints written out to a file when unloading a game and then automatically (by default) reloaded later, so that they persist across sessions like the FCEUX debugger. Would that suit your needs as well?

On a related note, another thing I'd like to implement is the option to repurpose the "WDM" instruction (0x42) as an "int 3"-style debug trap.

[Optiroc]

I'm planning to have breakpoints written out to a file when unloading a game and then automatically (by default) reloaded later, so that they persist across sessions like the FCEUX debugger. Would that suit your needs as well?

That'd be great for ROM hacking for sure. When working on your own projects code will likely move around from build to build, so it won't be of as much use then (it could even become a nuisance, but then you can just remove the breakpoints file when rebuilding, provided the filename/path is relative to the sfc file).

On a related note, another thing I'd like to implement is the option to repurpose the "WDM" instruction (0x42) as an "int 3"-style debug trap.

Yes! A quick way to set 'X' breakpoints is what you want 99% of the time when hacking around anyway, so that sounds like a very elegant solution to me.

[infidelity]

Will the new refresh rate for the memory viewer, also be applied to the palette and vram viewers?

Still anxiously awaiting the next build!

[Revenant]

Probably. I avoided doing that before for performance reasons, since originally, the debug windows were being refreshed from the same function that refreshed the actual SNES screen, so refreshing the debug windows too rapidly could cause noticeable hiccups. That's no longer the case so it should be doable (the refreshing itself isn't particularly CPU-intensive, it just caused problems when it was being triggered by something other than the debugger UI itself).

Anyway, I'm actually working on more debug GUI updates now, so a new release shouldn't be too far off.

That'd be great for ROM hacking for sure. When working on your own projects code will likely move around from build to build, so it won't be of as much use then (it could even become a nuisance, but then you can just remove the breakpoints file when rebuilding, provided the filename/path is relative to the sfc file).

Moving code is definitely something to consider; I'd make the breakpoint files human-readable so they could be edited as needed in between builds. Depending on your assembler you could probably also have the assembler spit some extra info into stdout or something and then convert that into a list of breakpoints pretty easily.

But that's also the main reason I had the idea to use WDM as a breakpoint, since it's (potentially) much more convenient to have breakpoints in the code itself that you can enable/disable at will.

[KungFuFurby]

Your framework makes sense when the BRK opcode is misused for something else other than acting as a breakpoint (the WDM opcode, on the other hand, is executed as a two-byte NOP instruction by the processor, and you can make it "emulate" a breakpoint of whatever type you desire... if you keep it two bytes, then emulators that don't support the debugger can run the game with no harm done, including real hardware. Otherwise, you'll need another WDM opcode to keep this code hardware and emulator-safe for non-debuggers).

Case in point for unexpected uses of the BRK opcode: Sangokushi Seishi ~ Tenbu Spirits. This game uses the BRK opcode to execute a command from an entire collection of routines for each call. One of those happens to be a musical call, which is how I found out, and it's the only time I've run into this opcode and see that apparently have some regular use.

[Revenant]

As uncommon as that is in SNES games, I'd hesitate to call it "misuse" (after all, breakpoints and error traps are far from the only valid uses for software interrupts). There can be advantages to using them to basically emulate the concept of syscalls; there's obviously more overhead involved but you get to use instructions that are one or two bytes shorter than an equivalent JSR/JSL.

Another game I can think of that does this is Soul Blazer, which makes heavy use of the COP instruction for basically the same purpose.

Anyway, WDM acting as a two-byte NOP is the exact reason I wanted to use that instead of repurposing actual interrupts (though right now I don't plan for the second byte to be used for anything special).

[tepples]

But that's also the main reason I had the idea to use WDM as a breakpoint, since it's (potentially) much more convenient to have breakpoints in the code itself that you can enable/disable at will.

I've used stores to some otherwise unused memory location for this purpose.

[uVSthem]

I'm wondering, will bsnes-plus and bsnes-classic ever get x64 or accuracy builds?

[Revenant]

I'd probably have to build 64-bit Windows Qt libraries first, since Digia don't seem to offer any themselves, and building Qt under MinGW was a minor ordeal the last time I actually attempted it. I'll get it sorted out eventually (unless someone else wants to volunteer to do Win64 builds themselves; OS X builds would be nice too, on that note )

I'll probably include both compatibility (default) and accuracy builds with the next release.