Author Topic: bsnes-plus and xkas-plus (new SNES debugger and multiplatform assembler) (Read 21856 times)

Revenant · « **on:** April 25, 2015, 04:58:14 pm »

Two new projects! Hooray! (They're both forks of byuu's programs so I'm putting them both in this thread. Why not?)

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: 1 2 3 4 5

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)

Coming soon
On-the-fly ROM saving and reloading from the memory editor for quick hacking and testing
More keyboard shortcuts for menus, etc.
Automatic saving/loading breakpoints between sessions
Similar addressing improvements for cheats

See the project on GitHub for more info and source.

Download
bsnes-plus v073+3a (Windows, 64-bit accuracy & compatibility)
bsnes-plus v073+3a (Windows, 32-bit compatibility)

xkas-plus is my fork of the xkas v014 assembler. Among other changes, its biggest new features are:
Assembling directly to an IPS patch
Table file support
SNES ExLoROM / ExHiROM support
Ability to export defines and labels to a separate file (supports FCEUX and VICE debug symbols or regular assembly includes)
Additional architecture/platform support:

See the project on GitHub for more info and source.

Download
xkas-plus v14+1 (Windows)

Lenophis · « **Reply #1 on:** April 25, 2015, 06:53:12 pm »

Quote from: Revenant on April 25, 2015, 04:58:14 pm

Coming soon
IPS soft patching

99% of the time when I've had problems, it's because I soft-patched a rom and I didn't realize it. This is a playing convenience, not a debugging "feature." I ask that this be left out or an option to disable its use.

Revenant · « **Reply #2 on:** April 25, 2015, 07:10:25 pm »

That was planned as a counterpart to UPS soft patching, which is already part of bsnes and is already optional.

sics · « **Reply #3 on:** April 26, 2015, 09:40:51 am »

Hola seria genial que le agregarle soporte para .7z y temporizador para cargar los estados.

Hi would you add great support .7z and timer to load states .

justin3009 · « **Reply #4 on:** April 26, 2015, 09:55:33 am »

Oh dear god I'll be trying this out as soon as possible.

Edit: Oop. Missing libgomp-1.dll on launch.

Edit 2: Are we allowed to make feature requests at all? Probably an easier one, but could we allow any button on the keyboard be used as a button assignment? I know you have to use Shift + something to allow the shift key, but it'd be preferable if we could just use 'Shift' as a button. Same thing with Ctrl. I know later bSNES version allowed that, not sure if that's really a 'bad' idea or not though.

DackR · « **Reply #5 on:** April 26, 2015, 01:21:45 pm »

Love what I see so far. Will be testing out SA-1 debugging a bit. Thanks so much for working on this.

I'm sure I'll have some feedback once I've actually used it.

Revenant · « **Reply #6 on:** April 26, 2015, 01:44:06 pm »

Quote from: justin3009 on April 26, 2015, 09:55:33 am

Oh dear god I'll be trying this out as soon as possible.

Edit: Oop. Missing libgomp-1.dll on launch.

Fixed. I basically threw the snesfilter (and other) plugins in at the last minute without bothering to check their dependencies (compared to the program itself), but it should run now. Sorry about that

Quote

Edit 2: Are we allowed to make feature requests at all? Probably an easier one, but could we allow any button on the keyboard be used as a button assignment? I know you have to use Shift + something to allow the shift key, but it'd be preferable if we could just use 'Shift' as a button. Same thing with Ctrl. I know later bSNES version allowed that, not sure if that's really a 'bad' idea or not though.

Feature requests are definitely welcome. I plan to play around and make some changes to the frontend eventually and changing how inputs are setup might be part of that.

mziab · « **Reply #7 on:** April 26, 2015, 02:06:42 pm »

Quote from: sics on April 26, 2015, 09:40:51 am

Hola seria genial que le agregarle soporte para .7z y temporizador para cargar los estados.

Hi would you add great support .7z and timer to load states .

The version of bsnes this was forked from definitely had 7z support via snesreader. However, upon testing just now I see it doesn't seem to work with newer 7z files. Older ones seem to work just fine, though. Apparently, LZMA2 is not supported.

Revenant · « **Reply #8 on:** April 26, 2015, 04:14:29 pm »

Do you know if blargg's modified 7z code was ever updated since v073?

SC · « **Reply #9 on:** April 26, 2015, 04:24:09 pm »

Quote from: Revenant on April 25, 2015, 04:58:14 pm

SPC file dumping

How does it work?
Do I have to do that manually pressing a key?
Or is it automatically detected when a new song is played and then dumps it from the beginning to some folder specified previously?
The former is nice, but the latter would be awesome.

Anyway, awesome project here. I might use it in the future.

Revenant · « **Reply #10 on:** April 26, 2015, 04:46:42 pm »

There's an option for it in the Tools menu (next to the "capture screenshot" option). You can also bind it to a keyboard key. It'll wait until the next time a note plays and then dump the SPC to the "exported data" directory (which is by default the same directory as the ROM).

SC · « **Reply #11 on:** April 26, 2015, 05:23:33 pm »

Ah, so it is like the ol' ZSNES dump spc command.
Well, nice, but I hoped for it to be implemented the other way I described. You think that would be too difficult?

It could be great, as it would make it easier to make very accurate OSV rips, unless there's another easier way I have missed all these years.

mziab · « **Reply #12 on:** April 26, 2015, 05:31:56 pm »

Quote from: Revenant on April 26, 2015, 04:14:29 pm

Do you know if blargg's modified 7z code was ever updated since v073?

vbam seems to use a somewhat newer version of blargg's File Extractor, which supports LZMA2 from the looks of it.

STARWIN · « **Reply #13 on:** April 26, 2015, 05:41:20 pm »

I'll probably try to use this instead of geiger's the next time I mess with a SNES game. The effort is appreciated. Tested it a bit:

Currently the memory editor shows a constant amount of offsets at once. This should depend on the window height. Line length should probably depend on window width. (or in both cases an adjustable variable as an alternative. might even be better)

Disassembler window also seems to show only a constant amount of instructions. It won't let me read the current procedure very far, and it also won't try to disassemble surrounding memory (basically all those ... areas). A scrollable sliding disassembled window would be nice, like in FCEUX. Disassembler could also show the hex representation of the instructions in addition to the addresses.

The empty box in the memory editor instantly shifts the view to the address written. It also aligns the offsets by the input, which can be convenient. It could perhaps use a goto button next to it and wait for its press for better UI (mainly for new users).

If I break manually, the disassembler window won't update until I step. Not that it matters..

Revenant · « **Reply #14 on:** April 26, 2015, 05:53:02 pm »

I definitely plan on reworking the memory viewer and other stuff; almost all of the debugger GUI is unchanged from the original bsnes debugger, but I'll be working on improving it as time goes on. I mostly wanted to get the actual debugging features and useful stuff ready before anything else.

DaMarsMan · « **Reply #15 on:** April 27, 2015, 06:13:25 pm »

Looks like an interesting project.

Having done some romhacking back in the day I can say quite confidently that I hate soft patching. I've had quite a few problems with it and I remember a lot of people who also did. I think it's important to remember adding features for the sake of having them can also add layers of complexity and bugs that you might not want.

Also, what's really the appeal of 7zip? I'm of the opinion that 7z for anything related to SNES is also a layer of complexity we need to move away from. There is no reason to not be working with raw files. 7zip was great when we had 60GB hard drives. What's the tradeoffs?

mziab · « **Reply #16 on:** April 27, 2015, 06:23:29 pm »

While it can be argued compressing roms with 7zip makes increasingly little sense, the support for it was already there, self-contained and completely optional. The code just needed to be updated to use a more recent version of blargg's File Extractor to support newer archives compressed with LZMA2. Proactively removing a feature that was already there in bsnes doesn't really make sense, seeing as purists can just not use snesreader.

Revenant · « **Reply #17 on:** April 27, 2015, 07:00:33 pm »

Quote from: DaMarsMan on April 27, 2015, 06:13:25 pm

Having done some romhacking back in the day I can say quite confidently that I hate soft patching. I've had quite a few problems with it and I remember a lot of people who also did. I think it's important to remember adding features for the sake of having them can also add layers of complexity and bugs that you might not want.

As I pointed out earlier in the thread, bsnes already supported soft patching long before I ever modified it; I'm just updating it to include a format that is still in common use. It always was and still will be a completely optional feature.

SC · « **Reply #18 on:** April 27, 2015, 09:05:17 pm »

Quote from: SC on April 26, 2015, 04:24:09 pm

How does it work?
Do I have to do that manually pressing a key?
Or is it automatically detected when a new song is played and then dumps it from the beginning to some folder specified previously?
The former is nice, but the latter would be awesome.

Anyway, awesome project here. I might use it in the future.

Quote from: SC on April 26, 2015, 05:23:33 pm

Ah, so it is like the ol' ZSNES dump spc command.
Well, nice, but I hoped for it to be implemented the other way I described. You think that would be too difficult?
It could be great, as it would make it easier to make very accurate OSV rips, unless there's another easier way I have missed all these years.

Oh, Revenant, please could you answer my bolded underlined question there? Or anyone, if there's any other easy way to dump accurate SPCs from the exact beginning of playtime.

Quote from: Revenant on April 26, 2015, 01:44:06 pm

Feature requests are definitely welcome.

Thank you.

Sorry if it bothers you, I know it is an accessory part of your project, but...

Ah, at least I will be using it for pure romhacking/debugging.

mziab · « **Reply #19 on:** April 28, 2015, 03:55:34 am »

I can field that question. Commands like "play new song" are game-specific or rather engine-specific (games by the same developer tend to use the same engine). The SPC700 does not have a convenient abstraction like that. It's something developers need to implement by themselves. As such, adding a universal "detect when a new song is played and dump" feature isn't really feasible. Now, if it were a platform like NDS, where most games use high-level functions from the official SDK, that would be another story entirely.