new bsnes-plus debugging features

Hi everyone,

a few days ago I finished some debugging feature plans I had for bsnes-plus in order to debug some games I work on.

As it would be nice to maybe create a pull request to maybe merge it into the original bsnes-plus version I'd like to have some people to test the new feature.

You can download and compile it from this page:
https://github.com/BenjaminSchulte/bsnes-plus



New features of the debugger are:

• The disassembler and debugger are now merged into one window.
• The disassembler has some simple syntax highlighting
• The disassembler supports WLA symbol files (located as .sym file in the same directory as the ROM)
• The disassembler displays the address names instead of the addresses, if known
• You can follow JMP and BRA addresses by clicking on them
• You can toggle breakpoints by clicking on the address
• You can name addresses by right clicking on the line
• There is an index of all names (=Symbol) which can be filtered
• You can add comments to disassembled lines
• There is a feature to break on BRK opcodes
• You can pass --break-immediately to the disassembler to debug from the very beginning
• A new debug port which allows you the log static messages directly from your ROM
• The disassembler tries to figure out the upfollowing code, even if its the first time you disassemble it
• Displays some simple loops
• If activated, all names and comments will be stored in a .sym file when closing the emulator for next time

However, as I only work with a few original ROMs, I didn't really test the new emulator very well, so I'd like you to test the new features and let me know:

• Does this actually work on Mac and Windows? (I only work using Linux)
• Did I accidentally remove an important feature?
• Is there a must-have-feature you really, really would miss here?
• I only tested the main CPU, the other processors should still work but have very limited features. Does this still work?
• Are there some new bugs I missed? (If so, please let me know which game and how to reproduce)

Have a great day!

Looks great

It would be easier to test if there were a windows binary exe. I personally don't have QT installed, for one thing. So, I don't really want to try to make my own.

This looks quite comprehensive! The ability to load symbols from a file is something I'd find very useful, but I use CA65 as my assembler instead of WLA, so the symbol files probably won't be compatible.

I've been following your work on this since I saw it pop up on GitHub, very nice work!

I haven't personally tried using it yet, but revamping the disassembler/tracer has been high on my to-do list for a long time. I think after the next upcoming (hopefully soon) release of bsnes-plus I'd love to consider integrating this into a future release as well.



ca65 symbol file support was a to-do item for me as well, since it's what I've been using for my recent SNES work as well. I don't think it should be too difficult to support both.

Depending on the structure of ca65's symbol files, you could do what I did and have a lua script convert to WLA format for you.

This looks amazing!

I would try it, but I got an exception error when I tried to run mingw trying to get it to compile on win10 x64. Unfortunately it doesn't really give me much else to work with, and I should go to bed. :/

http://revenant1.net/bsnes-plus-benny-win64.zip

Note: building out of the box fails on Windows because "ERROR" is already defined in wingdi.h, which conflicts with the DebugPrintCommand::Level enum. I suggest using mixed-case names for enum values instead.

Either way, this looks really great so far! I haven't tested it extensively to make sure everything behaves as it should but I'm excited about this nonetheless.

If wingdi.h is Windows Graphics Device Interface, then what's the header for Windows Graphics Device Interface Next Generation Subsystem?

Thank you for the feedback (and for compiling it on Windows).

I was quite a little busy with my main job and other current SNES project so I didn't check here for a while. I think I'll try to fix the windows version by the end of the next week and also check out the CA65 assembler in order to also support their symbol files later.

Got to try it, and the layout is great, I just wish there was a simple dump feature so I can save say a subroutine to a file.

Today I implemented a basic support for symbol files generated by the ca65 -Ln parameter.

Because no symbol file currently supports comments (Well, surely because it's actually no "symbol") the .sym file will be replaced by a different file format if bsnes is closed (if not deactivated in the debuggers options). Maybe someday this could go into a separate file or so.

I also added "exporting a dump" to my personal ToDo list, but I don't have that much time currently, due to two other big projects

Today I implemented a simple measurement tool. I did not test it very well and already know a lot of stuff which need to be implemented, until you can really use this in your daily life.



Currently you can measure values from memory or from VCounter and do calculations between each measurement.

What's still missing:
- There are no labels/numbers on the preview graph, so you don't really know what value it is.
- The configuration is not saved, so you will always have to reconfigure everything
- Graphs can not be compared
- It's not tested very well
- Did not test it on windows
- Should be configurable/triggerable using the debug-port $420E, which currently only allowed to print debug messages.
- Would be great to have breakpoints configurable if some calculations exceeded some limits
- There is no documentation

Does this work with SA-1 games? I want to see if I can hack KSS and SMRPG to work without a SA-1 chip.

I mean, I don't work with those games, but as I do see an SA-1 tab in the debugger as well as adding breakpoints in the SA-1 bus, I'm going to take a wild guess that it likely works.

EDIT: With that said, I'm having a hard time believing you're going to be able to pull that off. Those chips add a bunch of processing horsepower to aid the underpowered CPU, hacking the support out of them would likely put way too much burden on the CPU. You're welcome to take a crack at it, though I'm quite skeptical of you being successful.

Sorry, but this is bullshit. I've already did so much work to disprove it.

Best way to really disprove it is make a patch. Those of us with Everdrives would definitely appreciate it!

...wow. You sound rather insecure. Instead of addressing my skepticism with an abstract explanation on how you would pull it off, you instead dismiss it entirely by claiming that my skepticism is "bullshit," further adding that you've already done "so much work to disprove it," but not giving one iota proving said statement. Well done.

https://www.youtube.com/watch?v=w6niMlZzoUY

I've been working on this game for a long time. I'm just tired of having to come up with proof for everything I say.

Honestly, I think you are being immature. While I also disagree about the S-CPU being underpowered, I don't think this is the way to go about it showing it.

As has been touched on previously, there may be several reasons for a game to use the SA-1. It could just be that at the turn of the 5th gen, developers just wanted something more convenient so they could write the game in a higher level language. This doesn't necessarily mean that the S-CPU is incapable of running such games. I don't claim to know anything about how KSS or SMRPG work, but I would not be surprised if they used a lot of SA-1 specific stuff (or just had extensive inefficient machine-generated code) which would make it harder to just do a straight port to the S-CPU. I'm not saying it can't be done but in my eyes, the perceived effort would outweigh any benefits.

And when people are being jerks, don't be jerkier.

That doesn't prove much. All this proves is that you allegedly made a SNES homebrew ROM, so you know how to ASM program in 65816 for the SNES.


Not a single second of that video comes close to proving how you will take all of the processing work that the SA1 has to do and dumping it on the 5A22.

???

I'm just showing how fast a stock SNES can be, because you said the S-CPU is underpowered.

I mean that's fine and all, but it is, for all intents and purposes, underpowered, especially compared to the SA1.

I was pissed off because I've already talked about this a lot in other threads.

Is this true even of things like Faceball 2000 for Game Boy? Its frame rate on an effectively 1.05 MHz CPU isn't great, nor is its draw distance (video).

If you're just moving sprites around, CPU speed doesn't matter much.

...and I already censored the post that you quoted.

@Benny, this debugger is great! You have issues disabled on github - where would you like feedback directed? In posts here? I'm using this to do some homebrew development and the source view is already my favorite!

Some suggested features that would really round things out and replace (my) need for other debuggers:
* Debug printing from game code; preferably compatible with no$sns' register 21FC (write 1 char of output to the debug window) - this is a bit easier to scale than the symbol print stuff (though that can be useful for other things!)
* Symbol table in the main UI instead of a popup to make it easier to navigate (and less difficult to lose the popup behind other windows)
* Clicking on symbols jumps to disasm location for code, memory editor for data
* Hotkey to reload cart
* Dreaming: option to watch for cart file changes and reload automatically

Keep up the awesome work!

Bsnes-plus has this, though you may need to bind the key yourself. I use it all the time.

oh... (－‸ლ)
thanks!

So I decided to try this out. Built my bounceballs example, renamed my debug.sym file to superfeather-ex-bounceballs.sym and it's picked up my symbols! Neat! I'm not sure how I feel about it saving changes into the original symbols file, since my buildsystem is going to overwrite that .sym file on every build. I'd like to second the motion to move bsnes-plus modifications of the symbols to a different file, so that any extra metadata doesn't get lost.

I've merged these *awesome* additions, together with the latest changes from Revenenant and Undisbeliever, to my macOS branch. Pre-built binary here.

optiroc: does your branch still work on other platforms? (when building from source, no need for binaries)
I'm interested in making some fixes/tweaks to the debugger; wondering to which repo I should send pull requests

I haven’t tried in a good while, but I see no reason it shouldn’t compile with the right prerequisites in place. That said, you should absolutely send PRs to Revenant or BenjaminSchulte instead (depending on what you base your changes on)!

There's some build issues on Windows with QT5; I was able to hack around most of them but the big one is that QT for mingw doesn't support Qt's WebEngine at all. I replaced the QWebEngine use in the console with the QTextEdit from the original and it works! I am noticing some massive slowdowns when logging DMA; I doubt chromium would handle it much better. May be good to switch to a listview or something instead. Also, oddly the font used in the disassembly and memory windows is now too large (though this may just be an artifact of qt4->5).

I do like the changes you've merged in for the Tile Viewer and your fixes on top of the debugger. With these three sets of changes combined the debugger is pretty sweet! Awesome stuff all around :thumbsup:

Yeah, about that... For my own builds I've added a system to log game/project specific information (as well as the DMA logging you've discovered in the public branch) in real time, and the old QtTextEdit view slowed down the application to a halt *quickly*. The WebEngine view handles massive amounts of logging much better, I suspect, by virtue of being spun off a separate thread.

The better solution would be to write a custom view, obviously, having a full chromium process just for a console logger is a massive waste of resources... But I believe it would still need to run in a separate thread and I'm not familiar enough with Qt to be able to hack something like that together in a reasonable amount of time.


The improvements to the VRAM viewers are 100% Undisbeliever's work so be sure to thank him if you find them useful!

Which incidentally is why I run Discord in a web browser instead of installing its (Electron-based) native client.

Thank you for this the debugger.

Question:
Where does bnes keep the configuration files stored?
I downloaded a fresh version and when I opened it has all the paths and configs saved from the old binary.

I need to reset the settings as a crash caused some weird behavior on the emulator/debugger. Now all games have slow down!

Thank you .

on Windows:
%appdata%/.bsnes/bsnes-qt.cfg

otherwise:
~/.bsnes/bsnes-qt.cfg

Thanks a lot for this very interesting tool!

By any chance, is it also available as compiled windows binaries somewhere?