Page 1 of 15

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

Posted: Sat Apr 25, 2015 1:57 pm
by Revenant
bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging.

Screenshots, changelogs, documentation: http://bsnes.revenant1.net

What's new
"Step over" and "step out" buttons in debugger
Improved debugger UI with register editing
Redesigned memory editor and breakpoint editor
Improved handling of address mirroring for breakpoints (extends to the entire address space, not just RAM)
Real-time code and data highlighting in memory editor, with fast searching for known code/data locations and unexplored regions
Cartridge ROM and RAM views in memory editor for mapper-agnostic analysis
Enhanced VRAM, sprite, and tilemap viewing
SA-1 disassembly and debugging
SA-1 bus and BW-RAM viewing and (partial) usage logging
Super FX disassembly and debugging
Super FX bus viewing and usage logging

Non-debugging features:

Satellaview / BS-X support
SPC file dumping
SPC output visualizer (keyboards & peak meters)
IPS and BPS soft patching
Multiple emulation improvements backported from bsnes/higan (mostly via bsnes-classic)

See the project on GitHub for more info and source.

Download
bsnes-plus v05 (Windows, 64-bit accuracy & compatibility)


xkas-plus is here. I don't really maintain it anymore.

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

Posted: Sat Apr 25, 2015 2:33 pm
by thefox
Cool to see some work on SNES debuggers.

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

Posted: Sat Apr 25, 2015 3:12 pm
by infidelity
I'm liking this! However the refresh button within the Memory Viewer, is not resetting the highlighted hex values. Also idk if I read the release notes wrong, but I see no way of doing hex searches within the hex viewer. I appreciate this release, im still tinkiering with it!

Oh this is so nice! Really I hope we can get hex string value searches, and the refresh button in the memory viewer working, I have not stopped using this! I think this might be it for me with NES hacking if those things can be implemented! Thank you so much for this release! I hope you consider the things I suggested! :-)

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

Posted: Sat Apr 25, 2015 3:17 pm
by 93143
Revenant wrote:Super FX disassembly and debugging
Super FX bus viewing and usage logging
Cool beans. I'm going to need Super FX tools for my port.

And hey what? I didn't know xkas was byuu's work too. He wrote two assemblers?

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

Posted: Sat Apr 25, 2015 6:48 pm
by Revenant
infidelity wrote:I'm liking this! However the refresh button within the Memory Viewer, is not resetting the highlighted hex values. Also idk if I read the release notes wrong, but I see no way of doing hex searches within the hex viewer. I appreciate this release, im still tinkiering with it!

Oh this is so nice! Really I hope we can get hex string value searches, and the refresh button in the memory viewer working, I have not stopped using this! I think this might be it for me with NES hacking if those things can be implemented! Thank you so much for this release! I hope you consider the things I suggested! :-)
The refresh button updates the values of the currently visible bytes (and changes their color if they've been accessed since the last refresh), i.e. the same thing that happens once per second when "auto update" is checked. I might add another button to completely reset the read/write/execute statistics later. Searching memory will also probably be in the next release.

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

Posted: Sat Apr 25, 2015 6:57 pm
by infidelity
The color doesn't change for me. I see red/blackish maroon when code is logged, and my following example is when the rom is first read with a SEI (78).

I have the debugger already set to a snapped setting before loading the rom, I load the rom, and then I step into every opcode. So I see the SEI get it's color changed to red, but when I hit refresh after that SEI has been logged, it doesn't reset the color to the hex's original default color. So to me, it gives me the assumption this code is constantly being logged, when it's not anymore.

I've also noticed that I cannot write hex code consistently, Im only allowed to write one hex value, then I have to click the very next address I want to edit, in order to edit it.

Seriously this is a dream coming true for me, with what you have released! I keep checking back here for any new info and updates. I'm having a lot of fun with this debugger! I'm looking forward to future updates, thank you for this!

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

Posted: Sat Apr 25, 2015 7:20 pm
by Revenant
infidelity wrote:The color doesn't change for me. I see red/blackish maroon, when code is logged, and my example is when the rom is first read with a SEI (78). I have the debugger already set to a snapped setting before loading the rom, I load the rom, and then I step into every opcode. So I see the SEI get it's color changed to red, but when I hit refresh, it's doesn't reset the color to its original default color.
It's not supposed to. The colored bytes are meant to show everything that's been marked as code or data for the entire time that the ROM has been running; the refresh button just causes the window to show the most up-to-date view. Like I said, I might add the option to clear the usage logging in a later version.

The memory editing itself will be a bit more keyboard-friendly as well, but for now you can also enter multiple bytes by moving the cursor around with the keyboard (though it's still a little bit cumbersome...)

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

Posted: Sat Apr 25, 2015 7:37 pm
by infidelity
Well I hope you do add the clearing off logged data then, lol! I'll try using the cursor key as you mentioned, in trying to write hex in succession. :-) Again many thanks for this!

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

Posted: Sun Apr 26, 2015 12:16 am
by Near
> Screenshots: 1 2 3

This looks really cool! Thanks a million for putting this together!
Hopefully with this, we can finally abandon the era of closed-source debuggers (Geiger's Snes9X fork, no$sns)

> And hey what? I didn't know xkas was byuu's work too. He wrote two assemblers?

Way more than two.

xas was the original. Its source code would make Cthulu tremble in fear.
I rewrote things to xkas when I learned how to use the spacebar, that went up to v06.
I wrote spcas for SPC700 assembly here. It was also garbage.
I rewrote xkas again when I learned what classes were, and how to write a recursive parser, to add support for multiple targets (for Mother 3's translation), that went up to v14.
I rewrote bass when I learned what abstraction was. That added support for optional table assembly.
I rewrote bass again after creating a programming language and learning how to implement recursive macros.
To this day, the program remains a patching assembler, and not a linking assembler. That was always its goal, though.

That people continue to use xkas v06 to this day (and syntax-compatible clones of it like ASAR) is one of my greater sources of shame. It would seem I'm responsible for the ZSNES of assemblers =(

> Like I said, I might add the option to clear the usage logging in a later version.

One thing I've been considering was to expand the usage bytes to longs, and then storing the number of reads/writes/executes. This would essentially turn the usage data into full-on profile data, and you could generate "heat map"-style images. This would show you where the most important RAM variables are at, and the hottest sections of code, for use in optimization.

The obvious downside is that would eat an extra 48MB of RAM. But given higan's requirements, that's probably not that big of a deal for the debugger version.

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

Posted: Sun Apr 26, 2015 2:13 am
by Revenant
byuu wrote:This looks really cool! Thanks a million for putting this together!
Hopefully with this, we can finally abandon the era of closed-source debuggers (Geiger's Snes9X fork, no$sns)
Very glad to hear you like it! :) I still feel like it's pretty rough around the edges but I think it's at the point where people could get some real use out of it. (Apparently ikari_01 has already been using it for debugging sd2snes / MSU-1 stuff, which is cool!)

The closed-source nature of Geiger's debugger was one of my big reasons for starting this; I got a good couple of years' worth of use out of it but I eventually decided it was too buggy and crash-prone to put up with anymore, and it was obvious it was pretty much going to stay that way forever. (As for no$sns, I tried it once and somehow SMP breakpoints just flat-out refused to ever trigger, which made it totally useless for what I was doing at the time, so I gave up on it...)

It also occurred to me that (to my knowledge) there have never been any debuggers with proper SA-1 or SuperFX break/step support, so that seemed like another necessity (and I thank you for bsnes 073 having that Super FX disassembler tucked away, it was a good starting point :P)
One thing I've been considering was to expand the usage bytes to longs, and then storing the number of reads/writes/executes. This would essentially turn the usage data into full-on profile data, and you could generate "heat map"-style images. This would show you where the most important RAM variables are at, and the hottest sections of code, for use in optimization.

The obvious downside is that would eat an extra 48MB of RAM. But given higan's requirements, that's probably not that big of a deal for the debugger version.
That's a pretty cool idea. It's also kind of interesting to note that it's sort of the opposite of what I (and the person who brought up the code/data highlighting idea originally) thought to use it for - that is, seeing the stuff that doesn't get highlighted, in order to potentially find unused/obscure stuff (or just free ROM/RAM space). It would definitely be cool to have more detailed statistics available for other purposes, though.

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

Posted: Sun Apr 26, 2015 2:50 am
by Myask
Revenant wrote: On-the-fly ROM saving and reloading from the memory editor for quick hacking and testing
This sounds like an open invitation for user error; some extra "safety" features might be in order to help avoid the "Aw crap I just saved over the base/good ROM" headaches. (Sure, the user could make it read-only, but if they already didn't have backups...) actually, that sounds like a simple way to do it: Make a default-on "prevent overwrite" option somewhere in options so it forces one to save a new version (or patch?) each time.

Though I hear that, between foolproofing interfaces and better fools coming out, fools are winning.

(side note: In Mednafen one can just edit visible ROM like any other memory, and changes are immediately effective, and though I don't believe it allows saving per se, it has dump/load options.)

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

Posted: Sun Apr 26, 2015 2:54 am
by UnDisbeliever
Thankyou for working on this project. I'm sure I'll spend many hours with it trying to track down a stack smash or incorrect register size in my future SNES Development work.

But I can't get it to work.
I'm using your pre-compiled windows binary on Windows 8.1 and can't get it to start without error.

The program initially wanted:
  • libgomp-1.dll
  • pthreadGC2.dll
I've tried two different versions (Which I found in RawTherapeePortable and InkscapePortable), but neither work, giving me the following error:

Code: Select all

GOMP_parallel could not be located in the dynamic link library [...]bsnes-plus/snesfilter.dll
The .exe still runs, but I'm wondering if some of the functionality is missing due to this.


I think there is a version mismatch somewhere. Can you please point to the .dlls that you used.

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

Posted: Sun Apr 26, 2015 3:32 am
by ARM9
Revenant wrote: bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging.
Very cool, thanks a lot for your effort, I can see myself using this one a lot. I wonder, does this debugger have any support for keybinds? I might try to contribute something myself otherwise, because it would be nice for stepping and setting breakpoints for example.
Revenant wrote: It also occurred to me that (to my knowledge) there have never been any debuggers with proper SA-1 or SuperFX break/step support
The MESS debugger has superfx support, I believe it does sa-1 too but I haven't tested it myself.

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

Posted: Sun Apr 26, 2015 3:34 am
by Ramsis
Revenant wrote:bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging.
Fantastic, thanks a lot for making this! :D
byuu wrote:That people continue to use xkas v06 to this day (and syntax-compatible clones of it like ASAR) is one of my greater sources of shame. It would seem I'm responsible for the ZSNES of assemblers =(
LOL! :lol:

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

Posted: Sun Apr 26, 2015 5:38 am
by Near
> (Apparently ikari_01 has already been using it for debugging sd2snes / MSU-1 stuff, which is cool!)

Oh, he's still working on it? Neat!

I'd like to see if he'd be willing to change the MSU1 playback rate to match the spec 44100hz. If not, the BS Zelda hack is going to require two separate audio tracks due to desyncing over very long tracks.

> The closed-source nature of Geiger's debugger was one of my big reasons for starting this

It's so disgusting when people like him and FuSoYa take the open source code to Snes9X, add a bit of work to it (amounting to maybe 1% of the difficulty of the project itself), and then close off the source code.

I know the license permits it, but just because you can, doesn't mean you should. A shame nobody ever taught them the value of reciprocation.

I chose the GPL instead of ISC for higan because of people like that.

> which made it totally useless for what I was doing

It's also useless to anyone not running Windows or Wine.

> and I thank you for bsnes 073 having that Super FX disassembler tucked away, it was a good starting point

Sure. I intended to offer proper SuperFX debugging, but never got around to hooking it up to the UI =)

> that is, seeing the stuff that doesn't get highlighted, in order to potentially find unused/obscure stuff (or just free ROM/RAM space)

I originally came up with the usage map idea for two reasons:

1. to let the disassembler go backward (we can't do that with variable opcodes) and forward (we can't do that with P having the ability to change opcode widths), and

2. to find unused blocks of WRAM / SRAM for ROM hacking