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.netWhat'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.
Downloadbsnes-plus v05 (Windows, 64-bit accuracy & compatibility)xkas-plus is
here. I don't really maintain it anymore.
Cool to see some work on SNES debuggers.
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!
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?
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.
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!
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...)
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!
> 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.
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
)
Quote:
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.
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.)
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:
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.
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.
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!
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!
> (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
UnDisbeliever wrote:
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.
Try downloading again, sorry about that. I didn't realize that the snesfilter plugin had any additional dependencies (I basically built and included them at the last minute since I wasn't doing anything with them myself, yet), but libgomp-1.dll is included now (and I assume pthreadGC2.dll was a dependency of the versions you had found elsewhere, since my stuff uses libwinpthread-1.dll instead).
Also, (sorry for all these questions) is there a reason why the ram values have such a significant lag, when being inserted? I noticed that Geigers also did this, and I see it happening here as well? You can clearly tell this when you know the exact ram address for the controller push bits. I'm using Megaman X as my rom of choice, for using your current debugger, and when I press whichever pushbit I want, it takes nearly a second 1/2 to display. This is for every kind of action within the hex viewer. I didn't know if this was something unavoidable, or if this is a symptom of my Windows 7 OS?
I've already began finding new things within MMX, that I was never able to before, until now! Really cant wait for new revisions!
Having a lot of fun with this!
Myask wrote:
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.
That or an actual version control library. How hard would it be to adapt Git?
This is gonna be really useful, thanks.
Wow, super nice work!
How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only. Trying to target 32-bit only now, let's see if that does the job...
EDIT: Got some compiler errors, which at first I thought would be remedied by forcing a 32-bit only build. Which didn't help, so I then found that this patch to the Core Graphics headers did the trick:
https://gist.github.com/jweinberg/3336233
Qt 4 supports both Carbon and Cocoa, so I'd probably rather just switch to the Cocoa version of Qt 4 instead of going to Qt 5 (Qt 4 is also much more lightweight out of the box than Qt 5 is, and I've had serious issues with Qt 5 on OS X in the past, so I'd rather play it safe and stick with 4.8.6).
Also I'll make a note of that CoreGraphics fix for later. If that's all you had to do to get it to build, though, then that's good news; I know AWJ was making some headway at trying to get his own fork to build without issues on OS X but hadn't been able to test it yet.
Revenant wrote:
Qt 4 supports both Carbon and Cocoa, so I'd probably rather just switch to the Cocoa version of Qt 4 instead of going to Qt 5 (Qt 4 is also much more lightweight out of the box than Qt 5 is, and I've had serious issues with Qt 5 on OS X in the past, so I'd rather play it safe and stick with 4.8.6).
Also I'll make a note of that CoreGraphics fix for later. If that's all you had to do to get it to build, though, then that's good news; I know AWJ was making some headway at trying to get his own fork to build without issues on OS X but hadn't been able to test it yet.
Yup, that macro fix made it build without any problems – and everything seems to work fine as well except for the minor annoyance that you get a 32-bit Carbon build. Will try to build Qt 4 Cocoa and see what happens... It seems that there are some references to Carbon in the ruby/input stuff too, maybe it's possible to def those to use SDL instead so any references to Carbon can be abolished completely.
Revenant wrote:
Try downloading again, sorry about that. I didn't realize that the snesfilter plugin had any additional dependencies (I basically built and included them at the last minute since I wasn't doing anything with them myself, yet), but libgomp-1.dll is included now (and I assume pthreadGC2.dll was a dependency of the versions you had found elsewhere, since my stuff uses libwinpthread-1.dll instead).
Thanks for that.
There is ONE feature that I would like to see in the debugger, I would like the debugger to accept breakpoint locations from the command line.
I currently have a script that scans ca65's
.memlog file for
BREAKPOINT_ and displays its address for me. I normally would have to click buttons and copy+paste it into the window, but hopefully in the future..
After quickly looking though the Application::main code I
think I can add it myself
, I'll try to make the argument parsing as clean as possible.
Expect a push request sometime during the weekend.
> How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only.
I've built the old Qt 4 bsnes to use 64-bit Cocoa before. It had all the usual Qt-caused bugs you'd expect, but it worked. You might have to do some digging if (whoever owns Qt this week) has buried said builds, though.
> It seems that there are some references to Carbon in the ruby/input stuff too
Cocoa never added a simple method to query the state of keyboard keys, so we had to.
SDL could work at the cost of another dependency. Or you could warp your mind, lose your grip on sanity, and implement polling through the HID manager API. That has to seriously be the most hideous API that I've ever looked at ... and I've investigated SSL/TLS libraries.
byuu wrote:
> How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only.
I've built the old Qt 4 bsnes to use 64-bit Cocoa before. It had all the usual Qt-caused bugs you'd expect, but it worked. You might have to do some digging if (whoever owns Qt this week) has buried said builds, though.
> It seems that there are some references to Carbon in the ruby/input stuff too
Cocoa never added a simple method to query the state of keyboard keys, so we had to.
So now I've tried builds with both 64-bit Qt4 and Qt5. Actually, as a side note, not a whole lot of changes were needed to make it build and it seemed to work just fine – but I suppose there's no real argument to be made for migrating this project to Qt5 at this point.
Anyway, my goal with this tinkering was to get proper HiDPI rendering (seeing all the debugging views with chubby pixeldoubled font rendering urged me to), and actually it wasn't Qt4 or the use of Carbon that was the culprit – the build was 64-bit Cocoa all along. So then I realized that you need an Info.plist with the "NSPrincipalClass" and (optionally, at least on 10.10) "NSHighResolutionCapable" keys set, and all text are rendered with beautiful tiny pixels... (:
The GL viewport didn't automatically accomodate for the higher DPI though, but I'll dig in and make it play nicely one of these nights. I'm absolutely thrilled to not have to use my old WinXP VM for SNES debugging anymore!
Would you happen to have a time frame, for when we can expect a revision to bsnes plus's debugging features?
Thank You!
Nope, sorry. I'm developing this in my spare time without any kind of release schedule. I'm still trying to put a little bit of work into it (in some way or another) every day but it could be a few weeks before I have anything actually substantial to release.
ARM9 wrote:
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.
Not yet, though I'm planning to add hotkeys for some of the debugger functionality.
ARM9 wrote:
The MESS debugger has superfx support, I believe it does sa-1 too but I haven't tested it myself.
Interesting. I've never actually used MESS but if there's anything specifically useful about its own debugger that you'd like to see in mine then feel free to make suggestions.
I appreciate your hard work! I'll keep checking back every now and then. Thanks for the speedy reply btw!
Optiroc wrote:
byuu wrote:
> How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only.
I've built the old Qt 4 bsnes to use 64-bit Cocoa before. It had all the usual Qt-caused bugs you'd expect, but it worked. You might have to do some digging if (whoever owns Qt this week) has buried said builds, though.
> It seems that there are some references to Carbon in the ruby/input stuff too
Cocoa never added a simple method to query the state of keyboard keys, so we had to.
So now I've tried builds with both 64-bit Qt4 and Qt5. Actually, as a side note, not a whole lot of changes were needed to make it build and it seemed to work just fine – but I suppose there's no real argument to be made for migrating this project to Qt5 at this point.
Anyway, my goal with this tinkering was to get proper HiDPI rendering (seeing all the debugging views with chubby pixeldoubled font rendering urged me to), and actually it wasn't Qt4 or the use of Carbon that was the culprit – the build was 64-bit Cocoa all along. So then I realized that you need an Info.plist with the "NSPrincipalClass" and (optionally, at least on 10.10) "NSHighResolutionCapable" keys set, and all text are rendered with beautiful tiny pixels... (:
The GL viewport didn't automatically accomodate for the higher DPI though, but I'll dig in and make it play nicely one of these nights. I'm absolutely thrilled to not have to use my old WinXP VM for SNES debugging anymore!
Could you try building again from the latest source
without the modified Qt 4 headers? AWJ changed things a bit in his upstream fork so that macro issue should no longer happen, so you should be able to build on OS X 100% problem-free now (hopefully...)
Revenant wrote:
Could you try building again from the latest source without the modified Qt 4 headers? AWJ changed things a bit in his upstream fork so that macro issue should no longer happen, so you should be able to build on OS X 100% problem-free now (hopefully...)
Yes, now it works without modified CoreGraphics headers! Nice. I wonder if there's any demand for pre-built OSX binaries? I'd be happy to help with that.
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
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.
https://youtu.be/fZPjFJGzI88Didn'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).
Revenant wrote:
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.. (:
Revenant wrote:
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?
Revenant wrote:
https://youtu.be/fZPjFJGzI88
Real Piano Hero 4-player coop mode.
Huh, fading out only lowers the volume, it doesn't stop playback after it goes mute.
Optiroc wrote:
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.
Revenant wrote:
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).
Revenant wrote:
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.
Will the new refresh rate for the memory viewer, also be applied to the palette and vram viewers?
Still anxiously awaiting the next build!
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.
Optiroc wrote:
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.
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.
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).
Revenant wrote:
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.
I'm wondering, will bsnes-plus and bsnes-classic ever get x64 or accuracy builds?
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.
Any new progress to report on?
infidelity wrote:
Any new progress to report on?
I am wondering the same thing. Any news on the 64bit accuracy builds?
Haven't really had a lot of time to work on things lately (mostly due to work), but I should be making more progress starting in the next week or so.
Things I'm planning on doing for the time being:
- rewriting the memory editor
- rewriting the breakpoint window (maybe), adding the WDM trap option
- adding more register info to the Super FX disassembler (for instructions that use ROMBR and other such registers)
- Setting up 64-bit accuracy builds
I know its only been a month since I last asked, but any new developments? I can relate to work being an inconvenience to doing stuff like this. I check a couple times a week for any new updates. Thanks again.
Hopefully I'll be working on it soon now that things have been slowing down at work, which has been eating up most of my programming time lately; developing C++/Qt applications like this one (and my other main projects as of late) is also what I do for a living, and sadly I don't have an unlimited amount of time to put into the same general thing every single day
Totally understandable! Thanks for the reply!
Does BSNES support the super scope as an input?
uVSthem wrote:
Does BSNES support the super scope as an input?
bsnes supports the SNES Mouse, the Super Scope, the Justifiers (the paired lightguns used by Lethal Enforcers) and the Super Multitap. I have some degree of interest in adding support in bsnes-classic for more controller port peripherals, particularly the various Turbo File devices.
Thanks, I was looking in the settings for controller port 1. I didn't realize the light guns had to be in port 2.
AWJ wrote:
uVSthem wrote:
Does BSNES support the super scope as an input?
bsnes supports the SNES Mouse, the Super Scope, the Justifiers (the paired lightguns used by Lethal Enforcers) and the Super Multitap. I have some degree of interest in adding support in bsnes-classic for more controller port peripherals, particularly the various Turbo File devices.
uVSthem wrote:
Thanks, I was looking in the settings for controller port 1. I didn't realize the light guns had to be in port 2.
AWJ wrote:
uVSthem wrote:
Does BSNES support the super scope as an input?
bsnes supports the SNES Mouse, the Super Scope, the Justifiers (the paired lightguns used by Lethal Enforcers) and the Super Multitap. I have some degree of interest in adding support in bsnes-classic for more controller port peripherals, particularly the various Turbo File devices.
The two controller ports on the SNES aren't quite identical; light guns can only work in port 2. That's why the Justifiers have one gun that plugs into the SNES and one gun that plugs into the other gun, rather than two identical guns that both plug into the SNES.
It's been a while. Here's version 073+2. I didn't do everything with it that I actually wanted but I think it merits a new release at this point, and maybe this'll spur me to work on it more often. Download(s) in the original post.
Changelog [mostly scraped from commit messages in no particular order]:
Code:
Replaced original memory editor with a new, faster and better one [Revenant]
Added hotkeys for breaking and stepping in the debugger (F5 through F8) [Revenant]
Added new "Sound Viewer" window to tools menu [Revenant]
Removed "enable" checkbox from breakpoints, now enabled by R/W/X setting [Revenant]
Re-enabled quickload/save menus [Revenant]
Frame count added to CPU/SA1 traces [Revenant]
Fixed cycle timing issue introduced by debugger in previous release [Revenant]
Slightly improved SPC700, SA1 and SuperFX disassembly [Revenant]
Fixed MMIO mapping on SA1 bus (fixes crash with Marvelous and possibly others) [AWJ]
Various emulation, build, and other improvements [AWJ]
Backported various OpenGL, Direct3D, and rawinput fixes from bsnes 081+ [mziab]
Fixed potential GUI deadlock when Windows system menu is opened [Revenant]
Improved BPS/UPS/IPS soft patching support [mziab, Revenant]
snesreader no longer advertises RAR support that it doesn't actually have [mziab]
Backport newer File Extractor from VBA-M. LZMA2-compressed 7zip archives work now [mziab]
Various build fixes, mostly for clang / Mac OS [Optiroc, AWJ]
Nicer OSX app bundle (custom icon and retina support enabled) [Optiroc]
If there's something I was going to add / should have added but didn't, feel free to poke me about it anyway.
64-bit accuracy builds are still coming eventually.
> snesreader no longer advertises RAR support that it doesn't actually have [mziab]
It did have that (snesreader used blargg's fex library, which had it.) You had to toggle an ifdef that made the software non-GPL due to unrar's license, so it was off by default. Would probably have been smarter to not add .rar to the valid extensions when that wasn't compiled in.
Not that I think anyone really cares about loading SNES ROMs in from RAR archives.
byuu wrote:
Not that I think anyone really cares about loading SNES ROMs in from RAR archives.
It's common to find sets of SPC700 save states in a RAR archive renamed to
.rsn. They used RAR instead of Zip because a solid archive can reuse repeated engine and sample data from one SPC to the next. At the time, 7-Zip didn't exist, and gzip's window size wasn't near enough to cover a game's SPC set. This left RAR.
The same is true of archives containing a ROM and all its variants (Japan, North America, and Europe versions), though those are more likely to have gone to .7z.
Thanks, Revenant!
64-bit builds (including accuracy) are now available in the OP.
Going forward I'll probably keep publishing both 64 and 32-bit builds (but most likely only 64-bit for accuracy).
Yah for 64-bit for accuracy!!
Does anyone know if BSNES-Classic has a 64-bit for accuracy build now as well?
If you're using bsnes-plus for development or ROM hacking, you should be aware that PPU register viewing and VRAM/CGRAM/OAM breakpoints only work with the compatibility profile.
I don't have access to an environment to build 64-bit Windows binaries, but as far as I know bsnes-classic should compile for that target if you have the necessary libraries (i.e. Qt 4.8).
The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.
I've uploaded newer 64-bit builds which should be a fair bit faster than the previous ones (blame me not bothering to switch away from outdated sjlj-based tools until now...)
If you were experiencing slower emulation with the x64 builds (especially with coprocessor-based games) that shouldn't be an issue anymore.
AWJ wrote:
The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.
I think having 64-bit compatibility and accuracy but only 32-bit compatibility seems like a pretty reasonable default. I think most people at this point would be best-suited by the 64-bit compatibility build, whereas a 32-bit accuracy build would be too underperforming to be worth it (and I doubt many potential users still need the performance profile
that much...)
I personally did not even own a 64-bit machine until fairly recently, which is one of the reasons I didn't publish 64-bit builds until now (the other being the aforementioned lack of official 64-bit Qt binaries for Windows). But both of those aren't issues for me anymore, and I can keep producing 32-bit builds with the same toolchain, so I'll likely continue to do so until it stops being feasible.
I gave up on 32-bit builds, myself.
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.
I haven't heard a single complaint from anyone for not having the 32-bit builds anymore. And I usually average around 60,000 downloads a release (it was a 2:1 split on 64-bit vs 32-bit when I released both), so I don't think it's really a big issue anymore.
And as much as I want to drop the performance profile, the bottom-tier computers (Zotac Zbox BI-320, Intel NUC5CPYH, etc) still require it to run at full speed. The 10% speedup for 64-bit mode is quite nice here. Even with that, I still dip to around ~55fps during the Yoshi's Island title screen, but the games themselves are all playable.
Another nice ~10% speedup is to use profile-guided optimizations. But like the 32-bit builds, I just couldn't keep up with all the extra work they require (it was seriously taking me 4-6 hours to put together new release builds at one point), so I stopped doing it.
byuu wrote:
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98.
Have you tried
MinGW-W64? Despite its name, it can make 32-bit builds.
byuu wrote:
I gave up on 32-bit builds, myself.
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.
I used to have those exact things in the build instructions for bsnes-plus back when I still used the original MinGW (which is basically dead, for all intents and purposes). Now that I use mingw-w64, I can just make both 64- and 32-bit builds with the same stock toolchain in about 30 seconds total. (I do plan to eventually commit some makefile additions to streamline it a bit for other people, but it definitely beats having to scavenge for fixes to an out-of-date compiler distribution.)
> Have you tried MinGW-W64? Despite its name, it can make 32-bit builds.
Yes, -m32 produces binaries with miscompiled instructions. This causes lots of weird glitches and outright crashes depending upon what you do. It's probably fine for simple projects, but doesn't work for something as complicated as higan. The NES core seems especially prone to problems.
I guess the SNES core is stable enough for Revenant, so that's good at least.
Excelent work and congratulations for the Accuracy Build!!!! Please, can you upload an updated x64 accurate build? Air Strike Patrol have a bug in the "Good Luck" message when I launch it in the accuracy profile but with the last compatibility build (2015/11/21) the message shows perfect. Thanks!!!
If I recall, that "Good Luck" text is supposed to "rotate", but it's on the same BG as the HUD on the left. The compatibility profile caches the BG scroll registers so the message and HUD both end up stationary. And a long time ago with v073 accuracy, the timing was wrong so the effect didn't work right. It's fixed in since probably v078 or so, but ... yeah. I get that I change the internals too much for you to be able to do much besides attempt back-porting fixes. Especially for your specific case where you can't just use the relatively stable Emulator::Interface, but have to tap into all the internal state for the debugger. We're in kind of a lose-lose situation here with all these forks, unfortunately :(
The ASP devs definitely enjoyed toying with the PPUs.
Thanks for the reply!! Well, it's a pity for now.
I love the SNES games and I love this emulator for the accuracy but it's open source after all so I can wait for futures releases (for the bsnes-plus version with more Higan capabilities). Thanks again for this awesome work!!!
byuu wrote:
If I recall, that "Good Luck" text is supposed to "rotate", but it's on the same BG as the HUD on the left. The compatibility profile caches the BG scroll registers so the message and HUD both end up stationary. And a long time ago with v073 accuracy, the timing was wrong so the effect didn't work right. It's fixed in since probably v078 or so, but ... yeah.
Out of curiosity, what changed about the timing that fixed that spinning text? I know ASP has been well-known for doing some rather uncommon stuff with the PPU, but I didn't realize the BG scrolling trickery behind that text (or whatever it is) until I tried it for myself. Doing a comparison of the accuracy PPUs in higan and bsnes-plus didn't reveal anything obviously relevant to me, but I'm certainly not all that familiar with the details of either one.
I did backport the fix you recently made for ATX2, and I know AWJ made some other changes to the PPU a while back, but do you think there are any other potential accuracy issues still worth checking on?
Well, there is a bug in the Super Game Boy emulation: missing sound effects in Game Boy games. For example, unaudible multiple shots sounds with the S weapon in Operation C (Contra) and unaudible percusison effects of the music in Crystal Castle and Cloud Castle of Castlevania 2 Belmont's Revenge.
> Out of curiosity, what changed about the timing that fixed that spinning text?
I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.
> do you think there are any other potential accuracy issues still worth checking on?
Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?
Again, bad memory, so I can't really point you at many specifics >_>
byuu wrote:
> Out of curiosity, what changed about the timing that fixed that spinning text?
I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.
> do you think there are any other potential accuracy issues still worth checking on?
Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?
Again, bad memory, so I can't really point you at many specifics >_>
IIRC the SD Gundam G-Next problem was a regression that crept in when you changed the SA-1 to use a hardcoded switch table for its address map instead of a Bus object, in an attempt to get back speed that was lost in the post-074 memory system rewrite. bsnes-classic/plus still use the pre-074 memory system (which also means that unlike higan they support SA-1 games with BS-X data pack slots--another casualty of the memory system rewrite)
I have a stupid question regarding this great emulator.
I don't know how I did that but now, I have a FPS display on top left of the screen and I want to remove it.
Does someone know where I can find the keys assignment regarding such features ?
Would like to know if development is still going on with this emulator/debugger? If so may I ask, will we see a feature to actually "refresh" the logged areas of the ROM? This is beneficial in seeing what is currently being read by the snes, and what is not. Also, any chance on a different color for when you edit the ROM of the game? The logged values are RED, but when you overwrite the ROM, it's the same color as well. Please and thank you, great job on this!
alekmaul wrote:
I have a stupid question regarding this great emulator.
I don't know how I did that but now, I have a FPS display on top left of the screen and I want to remove it.
Does someone know where I can find the keys assignment regarding such features ?
That seems strange, since the only place bsnes-plus attempts to display a FPS counter is on the status bar (bottom right). Can you post a screenshot?
infidelity wrote:
Would like to know if development is still going on with this emulator/debugger?
Slowly, but yes. In between my job and other projects I'm hoping to resume development sometime soon (including more memory view improvements/fixes), so stay tuned.
While we're at it, a quick bug report. The edit boxes for the register values are too small on my machine:
Attachment:
Screenshot_20160501_180116.png [ 5.9 KiB | Viewed 3105 times ]
Looks like a(nother) case of Qt's font metrics having problems. The register edit boxes are supposed to be sized for n+1 digits.
Do the memory viewer and the main debug window have sane default sizes, at least?
I assume compatibility, since that's the default profile when building.
Revenant wrote:
I assume compatibility, since that's the default profile when building.
Thanks for the reply. I'll hold out for a x64 classic accuracy build.
Revenant wrote:
Looks like a(nother) case of Qt's font metrics having problems. The register edit boxes are supposed to be sized for n+1 digits.
Do the memory viewer and the main debug window have sane default sizes, at least?
I did some tests by changing the font size via qt4-config and it looks like those fields do respond to changes, but the calculation doesn't seem quite right. I went from font point size 9 to 7 and most fields shrunk so much that they didn't even display a single full digit. I might look into this later at some point.
The memory viewer is fine. I think it might not have started out that way though? I remember resizing the window to make it wider and it seems to remember this window size. The main debug window is just a smidgeon too small to avoid wrapping the step-thru debug messages onto two lines, and unfortunately it seems this particular window doesn't remember the size I give it. I could probably work around this using a KWin window rule override.
I think part of the issue here might be that the calculation doesn't account for padding. It looks like the KDE Breeze style has a bit more padding in the textboxes than what Windows uses.
Deleting the value "geometry.memoryEditor" in ~/.bsnes/bsnes-qt.cfg should revert the memory editor to its original size, assuming I remembered the path correctly.
At some point I'll probably experiment with using proper size hints instead of hacky fixed sizes like a few other components of the UI already were (which is why I mentioned those windows in particular).
Revenant wrote:
alekmaul wrote:
I have a stupid question regarding this great emulator.
I don't know how I did that but now, I have a FPS display on top left of the screen and I want to remove it.
Does someone know where I can find the keys assignment regarding such features ?
That seems strange, since the only place bsnes-plus attempts to display a FPS counter is on the status bar (bottom right). Can you post a screenshot?
Strange, I reboot my PC and the frame rate is no more display on screen :O !
Next time, I will do a screenshot :/
I'm trying to compile bsnes-plus from CarterLi's source code which includes the nice 6xBRZ filter but, I'm having trouble getting it to build in Qt5 with the newer Qtcore in MSYS2 on my Windows x64 PC. I'm new to this side of things.
Does anyone know where to get a Windows, 64-bit accuracy build of the latest BSNES Classic?
I don't have a 64-bit build environment up and running, but here's the latest git commit built for x86
https://drive.google.com/uc?export=down ... lpLakhJQ1k
qwertymodo wrote:
I don't have a 64-bit build environment up and running, but here's the latest git commit built for x86
https://drive.google.com/uc?export=down ... lpLakhJQ1kThanks, hopefully someone can put up the x64 build in the future.
I managed to compile a Windows 32-bit binary of bsnes-plus with the 6xBRZ filter from CarterLi's source code. It's highly recommended to use OpenGL rather than Direct3D for the xBRZ filter because of frame rate issues. Credit to the respective authors.
http://www99.zippyshare.com/v/5Hl3rF00/file.html
I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile.
https://github.com/sharknnth/bsnes-plus ... g/v073%2B3
Sharpy wrote:
I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile.
https://github.com/sharknnth/bsnes-plus ... g/v073%2B3Thank you. Would it be worth doing the same for BSNES-Classic?
Thanks for both programms, they are coming in handy for my StarOcean spanish translation, specially ExtHiROM/ExtLoROM support and asembling to a IPS patch in xkas-plus
ADD: I tested the assembler a minutes ago after reading the documentation. I used some code which works in ASAR, a branch of xkas. But I get some errors and have some questions now:
1) How can I make the asesembler assume I coding for a HiROM, LoROM or ExtHiROM? The first line in all my source code since the times of x816 is "hirom" or "lorom", but with xkas I get an error.
2) How can I write comments? May I use ';'?
3) May I use .b, .w or .l after opcodes in order to set the instruction length?
Thanks!
Does anyone know what this is about. I cannot get it to run on my system.
http://www.emucr.com/2016/09/bsnes-plus ... v0735.html
I can't help too much but it looks like someone forked Revenant's fork. ....Heh. (Or is possibly malware...might want to be careful.)
In any case, I've been waiting for someone else to bump this thread (so I wouldn't have to...hehe) so I could tell Revenant that this debugger is A++++++++.
I've been using the mess debugger for some time which I think is a very underrated and not very well known debugger but I'm definitely switching to bsnes-plus now. I only wish I had known about it sooner.
Thanks so much for making this!
magno wrote:
1) How can I make the asesembler assume I coding for a HiROM, LoROM or ExtHiROM? The first line in all my source code since the times of x816 is "hirom" or "lorom", but with xkas I get an error.
2) How can I write comments? May I use ';'?
3) May I use .b, .w or .l after opcodes in order to set the instruction length?
Thanks!
1) with xkas v14 (and xkas-plus) you'll need to write
arch snes.cpu first to set the architecture, then use
hirom,
lorom, etc. to select a memory mapping.
2) xkas v14 (and xkas-plus) uses
// for comments.
3) Yes.
The
doc/xkas.html file that comes with the assembler is probably slightly out of date by now, but covers most of the basics.
uVSthem wrote:
Does anyone know what this is about. I cannot get it to run on my system.
http://www.emucr.com/2016/09/bsnes-plus ... v0735.htmlI haven't looked at it yet, but I assume it's related to (or the same as) the xBRZ builds that Sharpy posted earlier.
jwdonal wrote:
Thanks so much for making this!
Glad you find it worth using
Hopefully this isn't a dumb question...but why do I see the following:
Debug Properties window in NORMAL build:
- S-PPU tab shows all appropriate values
- S-DSP tab shows no values
Debug Properties window in ACCURACY build:
- S-PPU tab shows no values
- S-DSP tab shows all appropriate values
Anyone else experience this?
EDIT: Another thing I noticed is that the S-CPU trace log is missing the Program Bank Register (PBR). Actually the Debugger GUI window is missing this value as well.
I see the same thing with the properties window.
As for the PBR, though, that isn't missing. PBR is the top byte of PC.
Nicole wrote:
I see the same thing with the properties window.
Okay, thanks for confirming. Hopefully a fix will come in the future. Probably a really simple fix.
Nicole wrote:
As for the PBR, though, that isn't missing. PBR is the top byte of PC.
Wow, that's a big
DUH on my part.
Thanks!
The properties window issue is just a basic oversight that I keep forgetting to fix. The normal and accuracy builds use two different PPU implementations, where one provides a property list to the GUI but the other doesn't (and vice-versa for the DSP). I posted a github issue about it as a self-reminder just now.
uVSthem wrote:
Sharpy wrote:
I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile.
https://github.com/sharknnth/bsnes-plus ... g/v073%2B3Thank you. Would it be worth doing the same for BSNES-Classic?
You're welcome, I've done so here with BSNES-Classic and added awjackson's Super FX improvements to it.
https://github.com/sharknnth/bsnes-classic/releasesjwdonal wrote:
I can't help too much but it looks like someone forked Revenant's fork. ....Heh. (Or is possibly malware...might want to be careful.)
In any case, I've been waiting for someone else to bump this thread (so I wouldn't have to...hehe) so I could tell Revenant that this debugger is A++++++++.
I've been using the mess debugger for some time which I think is a very underrated and not very well known debugger but I'm definitely switching to bsnes-plus now. I only wish I had known about it sooner.
Thanks so much for making this!
Don't worry, it's not malware, I'm the bloke that has forked it.
uVSthem wrote:
Does anyone know what this is about. I cannot get it to run on my system.
http://www.emucr.com/2016/09/bsnes-plus ... v0735.htmlThanks to CarterLi, this has been fixed with the latest build I posted here
https://github.com/sharknnth/bsnes-plus/releases
Hey, I just noticed on the page
https://github.com/sharknnth/bsnes-classic/release that the download link for bsnes-classic-6xBRZ.073u3-x64.zip links to the old bsnes-classic-6xBRZ.073u2-x64.zip file. The zip file is named 6xBRZ.073u2-x64.zip but when you unzip and compare the files it is the same contents as the 073u2 zip. Also, if you run the exe and check the about window it says 073u1. Does anyone know what's up with all the discrepancies?
Sharpy wrote:
uVSthem wrote:
Sharpy wrote:
I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile.
https://github.com/sharknnth/bsnes-plus ... g/v073%2B3Thank you. Would it be worth doing the same for BSNES-Classic?
You're welcome, I've done so here with BSNES-Classic and added awjackson's Super FX improvements to it.
https://github.com/sharknnth/bsnes-classic/releasesjwdonal wrote:
I can't help too much but it looks like someone forked Revenant's fork. ....Heh. (Or is possibly malware...might want to be careful.)
> I'm the bloke that has forked it.
"Yay", more bsnes forks.
Between the endless forks and now Piko selling my software on Steam, it's nice to know my fears when I had the bsnes reference license were entirely valid and justified.
> added awjackson's Super FX improvements to it
From what I understand, his timing changes were incomplete. Although it does look to be far enough along to be a substantial improvement over what was there before, it's still generally not a good idea to implement things in flux like that.
Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer, much thanks to UnDisbeliver:
Very well timed, too, because I've been gearing up to work on some other new graphics-related features (tilemap viewer, etc.) Now that I'm focusing on actual features again, another release should finally be not too far off.
Awesome! That'll be super helpful debugging msu-1 video code. While you're at it, I hope you can fix up that issue where the PPU registers dialog is blank in the accuracy profile.
Revenant wrote:
Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer...
Sweet, so excited!! Nice work!
qwertymodo wrote:
I hope you can fix up that issue where the PPU registers dialog is blank in the accuracy profile.
I second that!
I've also found some other bugs:
1) The upper byte of the Bus-B address for all of the DMA channels on the S-CPU tab of the Properties window is shown as $00. It should be $21.
2) The H-counter/V-counter registers ($213C-D) in the S-PPU tab of the Properties window seem to be totally broken. They should only update when $2137 (Soft Latch) is read or by setting-and-clearing bit 7 of $4201. Instead, the H-counter seems to be stuck permanently at 0 and the V-counter updates continuously with the current scanline number.
I also have a few enhancement requests that I might as well throw out there:
1) Would be totally
outstanding if you could add buttons in the Debugger window for "Run to next Vblank" and "Run to next Hblank". That would be super powerful.
2) The S-CPU tab in the properties window is missing a number of register values that would be very useful to have. Specifically $4210-4212 and $4214-421F.
3) I wonder if you could change the "H" count value in the Debugger window log to show the actual Dot number value as opposed to the master cycle count value. Right now the count displayed is always [current Dot number * 4] (each dot is 4 master cycles). It seems odd that the "V" count is the scanline number as expected but the "H" count isn't the Dot number...?
4) Would be a little nicer if the "Direction" value for each of the DMA channels in the S-CPU tab of the Properties window said either "A->B" or "B->A" instead of "true"/"false". True/false doesn't make much sense for a direction value.
I'll get around to fixing up the properties window soon, along with some of jwdonal's suggestions, and some other stuff like additional S-SMP properties (timer info, etc).
Alright, made the aforementioned fixes to the properties view, and changed the log window to display the H-counter in dots instead of cycles. Should be pretty consistent (and useful) across all three profiles.
Hcycle is much more useful for timing code than Hdot is.
It sounded like the problem was that you were reporting the real-time values instead of the latched values.
You should report the real-time Vcounter, Hcounter values somewhere prominent (like in the CPU tracer); plus the latched VCOUNTER, HDOT values in the register/properties viewer. Be sure to use the CPU version, as the Hcounter values are meaningless in the scanline-based renderers.
Very nice VRAM viewer, by the way!
The latched values are what the properties window now shows, with the tracer showing the real-time values. The latter is the same as before, just with hdot instead of hcounter.
I feel like having the log window express horizontal position in the same units that the latch and IRQ registers use is more intuitive/useful the majority of the time, but the properties window should probably still show the realtime hcounter value (and current lineclocks) for more advanced timing applications.
Or, maybe I should just add another config setting to let the user decide which value the debug window shows.
Revenant wrote:
Or, maybe I should just add another config setting to let the user decide which value the debug window shows.
This please.
But of course beggars can't be choosers either. I'm just happy to have this amazing SNES debugger available at all!
byuu wrote:
Hcycle is much more useful for timing code than Hdot is.
Having thought more about this I agree with byuu, but I also still think that it makes more sense to have the 'H' value in the debugger log be the actual dot number and not the cycle number. But at the same time I think knowing the cycle number is also important and you could very simply add a "CYC:#" in each debug log entry.
I realize now that this is actually really important because looking at some of my logs I just realized that the Hcycle value is not always an exact multiple of 4 of the dot count. So you can't just take the current Hdot count, multiply by 4, and always get the correct Hcycle count. So I think the best approach would be to have this in the debugger log:
Code:
<blah blah> V:# H:# CYC:# <blah blah>
jwdonal wrote:
byuu wrote:
Hcycle is much more useful for timing code than Hdot is.
Having thought more about this I agree with byuu, but I also still think that it makes more sense to have the 'H' value in the debugger log be the actual dot number and not the cycle number. But at the same time I think knowing the cycle number is also important and you could very simply add a "CYC:#" in each debug log entry.
I realize now that this is actually really important because looking at some of my logs I just realized that the Hcycle value is not always an exact multiple of 4 of the dot count. So you can't just take the current Hdot count, multiply by 4, and always get the correct Hcycle count. So I think the best approach would be to have this in the debugger log:
Code:
<blah blah> V:# H:# CYC:# <blah blah>
The SNES has two separate h-counters (and two v-counters), one on the CPU and one on the PPU. When you latch the counters (by any method) and poll them it's the PPU counter you're reading, but IRQs are based on the CPU counter. The PPU counter has 340 dots, but on most scanlines a couple of the HBlank dots are stretched, so it takes 1364 master clocks to count from 0 to 339. The CPU counter has no stretched dots (every dot is exactly 4 master clocks) but it seems to count from -1 to 339 (or -1 to 338 on the short scanline without stretched dots). (I write "seems to" because you can't poll the CPU counter on a real SNES, but if you enable an H-IRQ with a position of 340 it'll never fire)
Because there are two counters with different behaviours, the meaning of "the actual dot number" is ambiguous.
> The PPU counter has 340 dots, but on most scanlines a couple of the HBlank dots are stretched, so it takes 1364 master clocks to count from 0 to 339.
Yep, two of them are like that. It varies per system and sometimes per power cycle, but is usually ~322 and ~326 that are two clock cycles "longer" for some reason. I've seen it be 321+325 (rarely) and 323+327 (most often.)
With the exception of scanline 240 on odd frames when not in interlaced mode, where those dots are of normal length. I hear there's a case like this in PAL too, but I haven't timed that out yet to confirm. You'd have to ask nocash.
Such a pain in the ass system :P
> The CPU counter has no stretched dots (every dot is exactly 4 master clocks) but it seems to count from -1 to 339
I prefer to think of it as a propagation delay. You see it take more cycles (4, I believe?) when you enable H+V IRQs as opposed to just V IRQs, for instance.
> Because there are two counters with different behaviours, the meaning of "the actual dot number" is ambiguous.
Even worse is that, due to performance requirements, the CPU and PPU counters are almost never truly in perfect sync (aside from the obvious long-dot differences) between the two, because one processor thread is ahead of the other under emulation. And with the balanced/performance cores, the PPU Hcounter is basically 'frozen' on account of it being a scanline-based renderer.
byuu wrote:
With the exception of scanline 240 on odd frames when not in interlaced mode, where those dots are of normal length.
At least on NTSC, that's supposed to be there to control variation of the color burst phase from one field to the next. The NTSC color subcarrier is 6 qpels wide; PAL is 4.8.
Quote:
I hear there's a case like this in PAL too, but I haven't timed that out yet to confirm. You'd have to ask nocash.
His doc says NTSC has a short (1360 qpel) line 240 in field=1 of 240p and PAL has a long (1368 qpel) line in field=1 of 576i.
Quote:
Such a pain in the ass system
It'd be even more of a pain visually if each field had the same phase, like
most pre-PlayStation NTSC consoles other than the NES, SNES, and TG16. The PAL NES and PAL SNES output is "dirty" in much the same way as the NTSC Neo Geo AES output because the artifacts appear in the same position each frame rather than crawling the way they do on TG16, PlayStation, N64, and later consoles.
There's probably some cost cutting as well. The PPUs of both the NTSC NES and NTSC Super NES could generate only 1360 or 1364 qpels, presumably because some of the timing logic operates on a pixel basis. If they had a bit more resources, they could have had it generate a 240p signal with 1364 qpels on lines 240-242 and 1365 qpels on all other lines, for a total of 357627 qpels (59604.5 subcarrier cycles) per field. That'd at least give a closer-to-standard dot crawl in 240p mode. And 480i mode with all 1365 all the time would have been exactly standard timing.
Responding to a post in a different thread to avoid derailment:
koitsu wrote:
1. BG VRAM addresses (ex. $2107 to $210a bits 7-2) were shown in bytes not words (ex. $7000 instead of $3800) -- I kept wondering why all the values were 2x larger than what I expected. It's a matter of preference which is "accurate"; IMO, I'd show both, but with notation of words vs. bytes for both
This is something from the old stock v073 debugger that I have wanted to change for a while now. I might get it out of the way soon for the upcoming (i.e. later this week, hopefully) +3 release, but if I do that then I don't know if I'll yet bother to add a proper 16-bit mode to the memory editor like I wanted to.
Quote:
2. BG sizes (ex. $2107 to $210a bits 1-0) depicted are backwards or wrong: they should be WxH, yet %10 is shown as 64x32 when in fact it's 32x64 (%10 = "long vertical screen", i.e. horizontal mirroring; %01 = "wide horizontal screen", i.e. vertical mirroring)
Call that another v073-ism, I guess. I can change that easily enough.
Quote:
3. There was a CPU or PPU MMIO register which wasn't being tracked. Now I'm annoyed because I didn't write down which register it was!
Whichever one it was, it probably shows up in the properties viewer in very recent (i.e. <10 days ago) revisions, since I greatly expanded that for all profiles and views. But if I somehow overlooked anything useful, I can add it in too.
Quote:
Again, not your problem, but: bsnes-plus gives you two binaries: bsnes.exe and bsnes-accuracy.exe. The former works (but what it's built with/what profile it's using I don't know, but it does randomise WRAM and registers), and bsnes-accuracy.exe crashes on startup. I don't run "official" bsnes/higan because of the debugger need and the file format/manifest ordeal (refuse to get into that again).
"bsnes.exe" is the compatibility profile, which is the default when building. In the (soon obsolete) v073+2 release from 2015, the power-on states of both of those profiles are extremely deterministic (but will still initialize WRAM with something that isn't zeros). I finally got around to adding higan's randomization behavior about two weeks ago.
No idea why the accuracy build crashes for you, assuming it's the official release version from this thread or the GitHub repo. I haven't had anyone else mention this happening since the release, but sometime later I can give you an up-to-date accuracy build to try.
1. Gotcha. The inconsistency drove me bonkers until I remembered that most of the documentation refers to the VRAM as "in words", but when looking at things in a memory/hex editor, you're looking at bytes. So I can see the point of showing both the "word offset" and "byte offset" versions.
2. Yup, 64x32 and 32x64 were backwards. I submit a pull request:
https://github.com/devinacker/bsnes-plus/pull/763. I'm using binaries from bsnes-plus-073.2-6xBRZ-x64 (see below), which was the latest I could find. bsnes.exe has a modification date of 2016-11-07 04:16. If I figure out what MMIO register it is, I'll be sure to let you know. Thanks!
Quote:
No idea why the accuracy build crashes for you, assuming it's the official release version from this thread or the GitHub repo. I haven't had anyone else mention this happening since the release, but sometime later I can give you an up-to-date accuracy build to try.
Where I got the binaries:
https://github.com/sharknnth/bsnes-plus/releases
koitsu wrote:
2. Yup, 64x32 and 32x64 were backwards. I submit a pull request:
https://github.com/devinacker/bsnes-plus/pull/76Got it, thanks
Quote:
3. I'm using binaries from bsnes-plus-073.2-6xBRZ-x64 (see below), which was the latest I could find. bsnes.exe has a modification date of 2016-11-07 04:16. If I figure out what MMIO register it is, I'll be sure to let you know. Thanks!
Those are unofficial builds that add the xBRZ video filter option, but are otherwise pretty much the same. 7 Nov is when I most recently made any commits, so at least it's an up-to-date build (so disregard what I just said about power-on state, I guess). As for the accuracy build crash, you might try one of the previous releases on that repo, or wait for the next official release on my end, which should be just around the corner.
Over a year later, here's a new release, better than ever.
Windows 64-bit compatibility & accuracyWindows 32-bit compatibilityThings of interest:
- PPU tools! VRAM viewer, tilemap viewer, and an improved version of the existing sprite viewer.
- True Satellaview/BS-X support! (1 2) As of this release, bsnes-sx2 is now officially deprecated.
- MSU1 revision 2 support! Should now behave pretty much exactly the same as current sd2snes firmware.
Huge thanks to UnDisbeliever and LuigiBlood, respectively, for helping out with the first two of those things in the couple of weeks leading up to the release.
Hopefully it won't be another year before I release another one of these (yeah, that's what I said last time, isn't it?) I know there's still some stuff I probably said that I'd do (or that I want to do, anyway) that hasn't been done yet, but it'll happen. Thanks to everyone who motivated me to finally work on this again, especially recently.
Anyway, the rest of the boring changelog:
Code:
Added tilemap viewer, revamped VRAM viewer and improved OAM viewer [UnDisbeliever]
Added all BS-X/Satellaview support from bsnes-sx2 [LuigiBlood]
Added PPU breakpoint support to accuracy and performance builds [Revenant]
Added more comparison options to cheat search dialog [Grieverheart]
Added some command line debugger arguments (see `bsnes --help`) [UnDisbeliever]
Added debug window option to show H-count as either dots or clocks [Revenant]
Added option to use WDM instruction as a software breakpoint [Revenant]
Added "allow invalid input" and "allow modifier keys" to settings window [Revenant]
Updated MSU1 support to revision 2 (includes pause/resume support) [Revenant]
Improved handling of debug window GUI state when breaking/running/stepping [Revenant]
Expanded debug properties view for multiple chips on all 3 build profiles [Revenant]
Made power-on state (especially accuracy PPU) randomized the same way as higan [Revenant]
Memory viewer displays current address at bottom of window [Revenant]
Memory viewer now displays APU bus instead of just APU RAM [Revenant]
Memory viewer now displays (most) I/O registers as read-only values [Revenant]
Debug log files are now only opened if a game is actually open [Revenant]
Debugger switches between debug/main window depending on focus policy [Revenant]
Fixed flickering/blanking of game screen when changing/resizing windows [Revenant]
Fixed CPU bug w/ direct page wrapping in emulation mode [AWJ]
Fixed disassembly of PEA/PEI/PER instructions [AWJ]
Fixed some details of S-DD1 memory mapping [AWJ]
Fixed typing in native file dialogs triggering emulator hotkeys [Revenant]
Fixed debug events messing with emulation speed if turbo/slowdown keys were held [Revenant]
Fixed spurious debug events caused by dummy reads during SPC write instructions [Revenant]
Fixed file dialog path being cleared when cancelling a native file dialog [Revenant]
Fixed handling of $00Fx registers when dumping SPCs [Revenant]
Fixed "search next/prev" behavior when wrapping to beginning or end of memory [Revenant]
This is absolutely excellent! Nice work! Definitely worth the wait. All of my bug fixes and feature requests look like they made it in...save one...
jwdonal wrote:
I also have a few enhancement requests that I might as well throw out there:
1) Would be totally outstanding if you could add buttons in the Debugger window for "Run to next Vblank" and "Run to next Hblank". That would be super powerful.
I noticed there are no open issues on the github project page so I wanted to re-request this feature in case it got lost in the thread.
Our of curiosity, is this something that's hard to do?
As of right now if I want to trigger on a vblank/hblank I have to actually insert special code into my application to loop on reads of $4212 and set a breakpoint on it. This is pretty annoying since inserting this special debug code then changes all of the addresses for other breakpoints in the ROM. The only other option is to sit there and hold the "Step" button continuously until you get to the next hblank/vblank. Not so bad if you just want the very next hblank, but if you want like 30 hblanks in the future or even worse...the next vblank!...then you've got major problems.
For vblank, wouldn't a read breakpoint on the NMI vector work?
tepples wrote:
For vblank, wouldn't a read breakpoint on the NMI vector work?
Only if NMIs are enabled in $4200. In nearly all of my test ROMs so far I haven't needed (or wanted) this.
jwdonal wrote:
Our of curiosity, is this something that's hard to do?
Nah, not really. Like several other things, it was on my mind but I wanted to just get a long-overdue release out the door with a specific feature set in mind, more or less. Plus I want to be able to come up with a way to add more actions to the debug GUI without actually making it too cluttered.
jwdonal wrote:
Only if NMIs are enabled in $4200. In nearly all of my test ROMs so far I haven't needed (or wanted) this.
Speaking of that ... I'm really sorry to pester you on this, but I didn't see a response to this in the other thread.
Are you planning to release your test ROMs to the public? And if so, do you have any timeline on that? I am really, truly interested in these tests that I am failing.
I don't mean to rush you, so take all the time you need, but I'd just like to know if or hopefully when I can take a crack at them :D
If so, I'll be sure to pass all the fixes onto Revenant so he can get them into bsnes-plus as well.
Revenant wrote:
Plus I want to be able to come up with a way to add more actions to the debug GUI without actually making it too cluttered.
I've long since come to the conclusion that the only way to avoid this is via a command-line driven debugger. Doesn't have to be an actual terminal, you can put a terminal-like window inside the UI, and still save some very useful things like graphics viewers and such.
Problem is of course that the discoverability of a command-line debugger is absolute shit, and few people (if any) will bother to read extensive documentation on commands (I know about 1% of the functions in gdb, and I've been using it for over a decade.)
Maybe the best compromise possible would be some kind of dynamically generated UI that lets users edit a config file to enable the options they want to use in the debugger. Everything else is stripped out to avoid clutter. But boy, talk about a lot of really hard work.
Just fyi, the snesfilter.dll with xBRZ filters from bsnes classic also works with this!
Cool! I love PPU debugging tools!
byuu wrote:
Are you planning to release your test ROMs to the public? And if so, do you have any timeline on that? I am really, truly interested in these tests that I am failing.
I'd definitely like to see them as well. Even if I'm not immediately able to apply any fixes myself, it'd be great to have that stuff available for documentation purposes.
byuu wrote:
I've long since come to the conclusion that the only way to avoid this is via a command-line driven debugger. Doesn't have to be an actual terminal, you can put a terminal-like window inside the UI, and still save some very useful things like graphics viewers and such.
I've considered at least moving the step buttons and related widgets into a toolbar, to streamline them a bit and add more space for a few other options without it seeming like too much.
VICE sort of does both - it has a terminal/monitor-style debugger but with toolbar buttons at the top for common operations like single-stepping, etc.
byuu wrote:
Maybe the best compromise possible would be some kind of dynamically generated UI that lets users edit a config file to enable the options they want to use in the debugger.
Or to expose a protocol that interoperates with existing front-ends to command-line debuggers, such as
gdbserver's protocol. Then any of several
front ends to gdb can be used.
Another way to improve discoverability is to provide a worked example of debugging some homebrew ROM.
Just thought of another feature request that would be extremely useful - the ability to set controller buttons as pressed/not-pressed during debugging. You don't need anything graphically fancy, I'd be happy with just a set of 12 check boxes for pressed/not-pressed state.
So my updated feature request list is:
1) Add buttons in the Debugger window for "Run to next Vblank" and "Run to next Hblank".
2) Add ability to set controller button states during debugging.
Thanks again for making such a great debugger.
+1!
Often I find myself pressing "Run", then rapidly switching to the viewport window and jamming the keyboard in a faint hope to deliver a required button press in time. (It's futile of course.)
ikari_01 wrote:
+1!
Often I find myself pressing "Run", then rapidly switching to the viewport window and jamming the keyboard in a faint hope to deliver a required button press in time. (It's futile of course.)
I know that feeling all too well.
In my experience, not using the keyboard, but a dedicated joypad for input in combination with the bsnes option "allow input when focus is lost" mitigates this problem quite well: Press buttons on joypad with one hand, control debugger with the other.
If you don't mind another input device cluttering up your workspace, that is.
When I was actually ROM hacking, I'd find the gamepad polling code point. Then I'd run to that break point, and modify the value it stored immediately after the input was polled for the keypress I wanted.
Then I would run the trace logger to capture the event I wanted that only happened after an input event.
The ability to do this from a debugger without having to figure out where to hook each and every game would certainly be very convenient.
(this was also done against ZSNES, where you couldn't press/release emulated gamepad inputs while the debugger was activated.)
byuu wrote:
When I was actually ROM hacking, I'd find the gamepad polling code point. Then I'd run to that break point, and modify the value it stored immediately after the input was polled for the keypress I wanted.
Then I would run the trace logger to capture the event I wanted that only happened after an input event.
I recently did exactly this for Chrono Trigger. I hijacked one of the unused store dialogs to intercept the gamepad read and OR the B button bit so it immediately exits the store without ever displaying anything. Since the store dialogs are full-screen, voila, I now have a command to reload all of the graphics for an area after playing a video, without having to do it all manually. It even fades in for me and everything. Definitely agree the override dialog would be a useful feature (also, agreed that without it, a USB/Bluetooth gamepad makes this much easier since you can hold the buttons without any side effects outside of the emulator like you get with keyboard input).
Here is a minor release which fixes a few bugs of varying importance. I plan to start doing these more often, maybe monthly. Download links are in the OP as usual.
Code:
Fixed low-res scanlines being horizontally resized too much when fast-forwarding
while a high-res screen mode is active (compat/performance builds only) [Revenant]
Fixed potential issue with modifier keys triggering multiple wrong inputs [Revenant]
Fixed potential crashes when nonexistent cart RAM would be mapped by a manifest
and/or certain coprocessors (such as the SA1) [Revenant]
Fixed potential crash when tracing SA1/SuperFX with trace mask enabled [Revenant]
Fixed trace mask being wrongly enabled when loading a cartridge [Revenant]
I'll start addressing more of your ideas and issues once the holidays are over. I wanted to get a few things taken care of before then, but hopefully I can start to keep up more frequent official releases.
Something that would be incredibly helpful would be to make it easier and more straightforward to log or otherwise debug DMA transfers. Maybe a breakpoint that triggers upon the start of a DMA transfer to a specific destination, or triggers on the start of a transfer on a particular channel (I guess that's doable already with a write breakpoint on $420B with the data field set to the channel flag). And maybe a more compact dialog just for viewing DMA states (or perhaps the state of the last transfer per channel, if it differs from the current register state). Right now the best I can do is set a write breakpoint on a destination, then hunt through the properties dialog, but the values there don't always seem to match up to the values used for the transfer in question. The new VRAM and tilemap viewers have been fantastic, but I keep finding myself in need of hunting down where the video data is actually *coming from*, whether it's directly from ROM or a WRAM buffer.
Also, it would be nice if, in the tilemap viewer, you could hover your cursor or click on the image and have it tell you the address of the tile.
A quick note on some registers that I just noticed are missing from the S-PPU tab of the Properties viewer.
MPYL/MPYM/MPYH: $2134-$2136
jwdonal wrote:
A quick note on some registers that I just noticed are missing from the S-PPU tab of the Properties viewer.
MPYL/MPYM/MPYH: $2134-$2136
I believe I can add support for this (don't have a way to compile/test though). I'll file a pull request in a bit.
Edit: filed (and fully untested!):
https://github.com/devinacker/bsnes-plus/pull/103
koitsu wrote:
jwdonal wrote:
A quick note on some registers that I just noticed are missing from the S-PPU tab of the Properties viewer.
MPYL/MPYM/MPYH: $2134-$2136
I believe I can add support for this (don't have a way to compile/test though). I'll file a pull request in a bit.
Edit: filed (and fully untested!):
https://github.com/devinacker/bsnes-plus/pull/103That patch displays the last result the CPU read from the registers--the added member variables are only updated on reading from 2134-2136, not on writing to 211B-211C.
According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
AWJ wrote:
That patch displays the last result the CPU read from the registers--the added member variables are only updated on reading from 2134-2136, not on writing to 211B-211C.
I haven't looked at the patch since I'm not familiar with the source, but if that's true then it should definitely be changed to update on any writes to 211B/C since 2134/5/6 have no (user apparent) delay. Updating only on CPU read is not particular useful - not that I don't appreciate Koitsu's help!!
AWJ wrote:
According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
I doubt it but it only really matters if a particular game ever tries to read the result registers during mode 7 rendering _and_ uses that result for a particular purpose. This is probably unlikely but who knows. In any case I can pretty much guarantee that the behavior is determinate based on whatever mode 7 parameters are currently configured.
I responded to the PR, but it looks like AWJ beat me to part of my response
I don't think anything is known about how the registers behave when Mode 7 is active. Is this something that could feasibly be looked into with a test ROM?
Revenant wrote:
I don't think anything is known about how the registers behave when Mode 7 is active. Is this something that could feasibly be looked into with a test ROM?
Certainly. And a logic analyzer is useful as well.
But I really don't think it's that critical. You'd want to show that at least one game depends on reading a very specific byte value in order to justify all that coding/testing effort. Given that BSNES doesn't implement the behavior, and every SNES game already runs on BSNES, then I think you might have a hard time finding that justification.
Issue has been discussed in the pull request:
https://github.com/devinacker/bsnes-plus/pull/103And yes, I got the code wrong (keying off of reading, not writing). devinacker covered this in his follow-up.
Related to that, some annoyance/complexity here is what actually "triggers" the mathematical operation. I thought about how the official docs outline a double-write to $211b followed by $211c followed by getting your result from $2134-2136, but started wondering what would happen if you did the writes in the opposite order (multiplier first, followed by low/high multiplicand). Would the registers internally reflect the value if read? I referred to
nocash's docs, which specifically state "After writing to 211Bh
or 211Ch, ...", which to me means the calculation/result is being provided all the time. This is compounded by the aspect AWJ mentioned. I'm thus left with the impression -- for lack of better phrasing here, my apologies -- that the hardware is essentially doing the calculation constantly/non-stop.
I also now sympathise with byuu having literally 3 separate CPU/PPU cores to maintain. What a fucking nightmare.
Welcome to how a feature request opens a can of worms. :P
koitsu wrote:
I'm thus left with the impression -- for lack of better phrasing here, my apologies -- that the hardware is essentially doing the calculation constantly/non-stop.
Seems plausible to me, assuming that the calculation involves some of the same circuitry responsible for Mode 7 rendering.
Anyway, I just got home from work, so I'll merge the fix shortly.
AWJ wrote:
According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
No. I know that it's using it for the mode 7 multiplication calculations, but I have not emulated it. I don't even believe I'm caching the mode 7 multiplications themselves yet (it should only be adding things per-pixel.)
The PPU multiplication updates are like one piece of a large jigsaw puizzle. Trying to tackle it alone would just make a mess of things. If we were to form proper cycle stepping of all PPU operations, $2134-2136 would naturally fall seamlessly into place.
I desperately need jwdonal's test ROMs and PPU timing findings to improve bsnes further. But ... I have three other emulation cores to keep me busy in the mean time, so I guess it's no great rush.
jwdonal wrote:
You'd want to show that at least one game depends on reading a very specific byte value in order to justify all that coding/testing effort. Given that BSNES doesn't implement the behavior, and every SNES game already runs on BSNES, then I think you might have a hard time finding that justification.
I emulate all kinds of things that no games rely on. It's not so much about making regular games run better, it's about ensuring someone in the future doesn't decide to use those registers as "free, fast multiplication" while also using mode 7, and then end up surprised when their game breaks on real hardware.
I've been on the other end of that (with different limitations) ... it's not fun.
I don't think
most emulators should bother. Especially not Snes9X/bsnes-performance/bsnes-balanced. But we should ideally have one emulator that a person uses as a final test before releasing their games, and that should emulate anything that is humanly possible.
koitsu wrote:
I also now sympathise with byuu having literally 3 separate CPU/PPU cores to maintain. What a fucking nightmare.
After probably 4+ years of maintaining them all (and building profile-optimized binaries for all three, in both 32-bit and 64-bit configurations), I finally threw in the towel and discontinued the performance/balanced cores.
I'm very appreciative that someone out there understands why I had to do that. It was a very difficult decision for me, and one that's obliterated most of the small userbase I still had left.
..........
By the way, if you guys want an even
bigger rabbit hole to chase ... the regular CPU mul/div stuff isn't 100% emulated either.
As most of you know, it's a multi-cycle process of updating the math computations one bit at a time. And thanks to blargg, we know the algorithms and have that emulated.
But it is possible to start a division during a multiplication, and even easier to start a multiplication during division. The result is that both run simultaneously, only they share some transistors along the way. The resultant computations are a complete mess, and even blargg was unable to make sense of them. This is currently unemulated, and probably the easiest way to quickly detect bsnes versus real hardware today.
byuu wrote:
I emulate all kinds of things that no games rely on. It's not so much about making regular games run better, it's about ensuring someone in the future doesn't decide to use those registers as "free, fast multiplication" while also using mode 7, and then end up surprised when their game breaks on real hardware.
I agree. I should clarify that an emulator would want to
at a bare minimum ensure that the Mode7 mult does not provide correct answers during mode 7 rendering in order to avoid that scenario. But as far as having the readback result be what it actually is in real hardware cycle for cycle...meh.
I'm working on some SNES Mouse stuff so I'm adding mouse support to the Carbon input driver.
However! Since I don't have access to the canonical windows build at the moment I'm not quite sure how it's supposed to map the mouse input. At the moment I'm just feeding mouse coordinate deltas to table[mouse(n).axis(x)] as a proof of concept. It works, kind of, but is it supposed to translate the coordinates in some smarter way to get more of a 1:1 relation between the host operating system's mouse and what you end up with in "emulator space"?
Edit: I got the 32-bit Windows build running in a virtual machine. With the RawInput driver the pointer (using Mario Paint for testing) wouldn't move at all, and with the DirectInput driver the pointer basically only jumps from corner to corner. Can I chalk that behavior up to the virtual machine tripping things up, or has the mouse support been "orphaned"?
Update: After some digging through old Apple documentation I managed to "pin" and hide the cursor when mouse access is requested, while still retrieving movement deltas. Works like a charm now!
PS: My macOS build is downloadable at
https://goo.gl/06Ofmd
Optiroc wrote:
I'm working on some SNES Mouse stuff so I'm adding mouse support to the Carbon input driver.
However! Since I don't have access to the canonical windows build at the moment I'm not quite sure how it's supposed to map the mouse input. At the moment I'm just feeding mouse coordinate deltas to table[mouse(n).axis(x)] as a proof of concept. It works, kind of, but is it supposed to translate the coordinates in some smarter way to get more of a 1:1 relation between the host operating system's mouse and what you end up with in "emulator space"?
Edit: I got the 32-bit Windows build running in a virtual machine. With the RawInput driver the pointer (using Mario Paint for testing) wouldn't move at all, and with the DirectInput driver the pointer basically only jumps from corner to corner. Can I chalk that behavior up to the virtual machine tripping things up, or has the mouse support been "orphaned"?
Virtual Machines don't emulate absolute positioning, they only emulate relative positioning. eg, if I move the mouse over the window the virtual machine is running in and click, the mouse "real coordinates" will be in the center of the screen, and it will calculate the movement from the center of the screen. This also happens with the joystick. Suffice it to say, you can not play the vast majority of games inside a Windows virtual machine using emulated input, because you don't have any precision to work with. The solution I came up with if I wanted to play a game inside a virtual machine was to actually map the USB port to the real USB port for a mouse or joystick and that solves it. Without doing it this way, when you move an analog stick, it will only be 0% or 100% moved, because it's only tracking the relative movement and when it stops moving, it's back to zero. I hope this makes some kind of sense. This was the trick I used to run a MMORPG game on a Mac inside Parallels, as well as the MMORPG game inside a Windows VM on top of Windows when I needed to move inventory items between two characters without going through the auction house.
That said, the "moves from corner to corner" is exactly the expected behavior from a virtual machine. You can sometimes enable an alternate relative movement feature in some VM's, but they tend to only take it from one extreme to the other.
Kismet wrote:
Virtual Machines don't emulate absolute positioning, they only emulate relative positioning. eg, if I move the mouse over the window the virtual machine is running in and click, the mouse "real coordinates" will be in the center of the screen, and it will calculate the movement from the center of the screen. This also happens with the joystick. Suffice it to say, you can not play the vast majority of games inside a Windows virtual machine using emulated input, because you don't have any precision to work with. The solution I came up with if I wanted to play a game inside a virtual machine was to actually map the USB port to the real USB port for a mouse or joystick and that solves it. Without doing it this way, when you move an analog stick, it will only be 0% or 100% moved, because it's only tracking the relative movement and when it stops moving, it's back to zero. I hope this makes some kind of sense.
Yup. After looking a bit more at the RawInput and DirectInput drivers to clean up the behavior of mine I think that makes sense. Both those API seem to work by acquiring exclusive access to the device and read out raw relative mouse movements. And as you said, that won't work with most vm hosts with the default configuration at least.
Kismet wrote:
This was the trick I used to run a MMORPG game on a Mac inside Parallels, as well as the MMORPG game inside a Windows VM on top of Windows when I needed to move inventory items between two characters without going through the auction house.
By the way, that link Optiroc posted on the previous page is more or less the official Mac release for 073+3a; I just haven't added it as a proper release to the github project page/this thread/etc. Feel free to use it as an "official" build instead of building from source yourself if you want.
I'm pretty sure the VMWare Tools for ESXi clients enables absolute positioning for mouse control, but without the Tools installed, it behaves the way you describe. Just curious, with this talk about the input code, have you figured out the issue with input not working after the machine locks or goes to sleep?
qwertymodo wrote:
Just curious, with this talk about the input code, have you figured out the issue with input not working after the machine locks or goes to sleep?
Aside from making sure I was able to reproduce it, I haven't looked into it a great deal yet, but thanks for the reminder.
In other (less useful) news, having to debug some troublesome SPC dumps led me to write a new optional plugin for loading/playing SPC and SNSF files.
Okay, what's going on here?
Attachment:
bsnes-what.png [ 11.73 KiB | Viewed 5284 times ]
It may or may not be relevant (probably not) that this ROM works in no$sns and Snes9X, but not any version of bsnes/higan, and that the problem seems to be that forced blank isn't getting turned off...
EDIT: As expected, the reason the ROM wasn't working was completely unrelated. I presume this is just a bug in the disassembler...
Hmm, I guess for some reason it's getting confused about whether the LDA is supposed to be two or three bytes and skips the first byte of the next instruction as a result. I'll have to check that out.
(edit: to clarify, this is almost definitely just a bug with the disassembler and not the actual emulator)
Any word on when the next release will be out? I could _really_ use those Run-to-next-hblank and Run-to-next-vblank buttons right about now.
That code was never supposed to execute at all. The problem was that I was carelessly jumping to the ROM version of that routine when I should have been using the one in RAM. As you can see from the code, I had just started the GSU (and the GSU program was very short, just eleven bytes of code, but it wasn't cached). Still not sure why this would cause one byte to be skipped, instead of outright locking out the CPU... or maybe it did lock out the CPU, which could explain why the code started at that routine every time I broke for debugging...
And now that I actually look up brk it seems it can take a "signature byte", so I guess brk #$21 makes more sense than I initially thought once you accept that something caused the disassembler to skip the actual opcode...
jwdonal wrote:
Any word on when the next release will be out? I could _really_ use those Run-to-next-hblank and Run-to-next-vblank buttons right about now.
when it's done ®
93143 wrote:
That code was never supposed to execute at all. The problem was that I was carelessly jumping to the ROM version of that routine when I should have been using the one in RAM. As you can see from the code, I had just started the GSU (and the GSU program was very short, just eleven bytes of code, but it wasn't cached). Still not sure why this would cause one byte to be skipped, instead of outright locking out the CPU... or maybe it did lock out the CPU, which could explain why the code started at that routine every time I broke for debugging...
And now that I actually look up brk it seems it can take a "signature byte", so I guess brk #$21 makes more sense than I initially thought once you accept that something caused the disassembler to skip the actual opcode...
The SNES doesn't have any provision to allow the CPU to be halted externally (from the cartridge or expansion slot). In the case of SuperFX cartridges, if the CPU reads from ROM while the SuperFX is busy with it, it gets the IRQ vectors no matter what address it reads from.
IRQ vectors, not open bus? Yeah, now that I actually look up the behaviour, I see that's true...
Well, it's not super relevant. I had thought it might be ending up in a tight loop, but I just tested the working version in bsnes-plus, and it too manages to always stop right at the ldx #SuperFX immediately above the code I've shown (you can see the partially cut off stx $310E at the top) - except this time it's in shadow RAM like it's supposed to be. I guess that's just how the timing works out...
I've been trying to debug some Super FX code, and it looks like when loop is executed, the debugger displays an instruction corresponding to the byte immediately prior to the jump target in R13 rather than the byte immediately following loop. Actual code execution seems to be correct.
Also, the display of conditional branch addresses seems to be one less than what shows up in no$sns; ie: bne $8418 instead of bne $8419. And sure enough, $8418 is the address of the byte immediately preceding the actual branch target, and instead of showing the byte following the branch instruction, the debugger shows the byte at $8418. Again, actual execution seems to be correct.
Also, I notice that the CLSR display says 10.7 MHz, even though I wrote a 1 to it, no$sns agrees that it's 1, and changing the code so that it writes a 0 instead results in slowdown.
93143 wrote:
Also, I notice that the CLSR display says 10.7 MHz, even though I wrote a 1 to it, no$sns agrees that it's 1, and changing the code so that it writes a 0 instead results in slowdown.
ARM9 fixed this (and added ROMBR to the property viewer) in a pull request a few weeks ago, so if you're able to use a newer development build then that should be fine.
I'll fix the branch/loop thing in the disassembler sometime soon, thanks for pointing that out.
Glad to help.
I just checked, and it looks like the same thing happens with iwt R15, #addr. The address displays correctly because it's baked into the ROM, obviously, but the next instruction displayed seems to be the one immediately preceding the jump target instead of the one that should be in the pipeline. I imagine jmp and ljmp behave similarly.
I'm experiencing some sort of color math emulation bug in bsnes-plus (accuracy version). I've tried this test ROM in several other emulators (no$sns, higan, snes9x, etc) and it looks correct. However, when running in bsnes-plus-accuracy the fog/clouds are displayed with a different random color on each power-on/reset/load/reload. I'm running v073+3a. It seems to be picking a random color out of thin air. The color that it randomly chooses is usually not even from the existing palette. Lol.
Attachment:
translucent.sfc [32 KiB]
Downloaded 403 times
jwdonal wrote:
I'm experiencing some sort of color math emulation bug in bsnes-plus (accuracy version). I've tried this test ROM in several other emulators (no$sns, higan, snes9x, etc) and it looks correct. However, when running in bsnes-plus-accuracy the fog/clouds are displayed with a different random color on each power-on/reset/load/reload. I'm running v073+3a. It seems to be picking a random color out of thin air. The color that it randomly chooses is usually not even from the existing palette. Lol.
Attachment:
translucent.sfc
You're not initializing $2132 (COLDATA) properly. You need to write %11100000 ($e0) to set it to black, not 0. The upper 3 bits are which channels to change and the lower 5 bits are the value to change them to. Writing 0 does absolutely nothing.
You should probably be using an initialization routine to set initial values for all the registers as well as zero out the memory. This way you're starting with a known state. bsnes-plus is likely simulating the real hardware behavior of RAM effectively being filled with random values on power on.
There's an InitSNES routine floating around that you can use.
AWJ wrote:
You're not initializing $2132 (COLDATA) properly. You need to write %11100000 ($e0) to set it to black, not 0. The upper 3 bits are which channels to change and the lower 5 bits are the value to change them to. Writing 0 does absolutely nothing.
Sneaky
Lol. I haven't done much (really anything) with color math yet, so that's why I didn't know about that special write behavior. Thanks!
HihiDanni wrote:
There's an InitSNES routine floating around that you can use.
This works for me, but it's a mess due to taking code from different locations. I've cleaned it up myself but haven't put it online yet and probably won't for a while, so.
After using bsnes-plus for a couple days, here are my impressions. Compilation was easy compared to higan, though I needed to edit some files to disable pulseaudio and to shrink the cheats.xml file, it's not nice to drop a 3mb file to my home dir without asking me. The tilemap viewer in particular was good. The debugger on the other hand fell short in many ways.
- why does it only show instructions after break/step? I expected a continuous view
- why does the disassembler show such a small amount of code? I couldn't find any way to increase it
- I couldn't figure out how to set breakpoints
- the disassembler showed wrong code once, perhaps it took the code as 16-bit when the registers were set to 8-bit (and shown as 8-bit in the debugger window)
Finally, I couldn't set right shift to the select key. Any other key was accepted, but not shift for some reason. Maybe a Qt quirk?
calima wrote:
- why does it only show instructions after break/step? I expected a continuous view
I don't think that'd work that well. Thousands of instructions could be executed every frame. Even if the UI can handle printing them that fast, it would be limited by only being able to refresh at 60 Hz too, so if it shows, say, fifty instructions on screen at once, 99% of the instructions would never even appear on the screen. Furthermore, if the UI's refresh is synced up to the game's, you'd just see the last fifty instructions executed each frame, probably showing something boring like the start of vblank.
That all said, I do think there are things that'd be nice to have a continuous view of; I just don't see it working that well for the main debugger log. For instance, something that could keep track of variables in real-time would be nice, rather than having to look at the memory viewer. I've also seen some
interesting visualizations in Retro Game Mechanics Explained's videos that might be nice to see in real-time.
calima wrote:
- I couldn't figure out how to set breakpoints
Tools -> Breakpoint Editor. "Address Range" is the address range to break on, "R/W/X" is whether you want it to break on a read, write, or execute of those addresses, and "Data" is if you want it to break only when reading/writing a certain value from that address.
the problem is the SNES is such a big machine that the spaghetti gui style of debugger just gets to unweildy, the NES is pushing it, you end up with 5 windows you have to shuffle to get all the data you need. Factor in the SNES has lots more code, lots more registers, lots more visual state, more palletes, more sprites, a whole spereate sound processor, dma, hdma, ram,vram,sram it just gets too much to make a "button for the thing" debugger. And then you have SA-1, Super FX, DSP, C4 etc etc It gets to the point it needs a monitor so all the commands are in text form, and you can query what you need when you need it. Having some of the other things in a visual format is nice, but I think having a monitor first would be the way to go.
calima wrote:
- why does the disassembler show such a small amount of code? I couldn't find any way to increase it
- the disassembler showed wrong code once, perhaps it took the code as 16-bit when the registers were set to 8-bit (and shown as 8-bit in the debugger window)
These are both shortcomings of the crusty old bsnes 73 disassembler; as you guessed, it does show all currently displayed code with the current register sizes regardless of what was actually executed.
You might be interested in
the new WIP debugger GUI which improves the disassembler portion substantially, among other things.
Quote:
Finally, I couldn't set right shift to the select key. Any other key was accepted, but not shift for some reason. Maybe a Qt quirk?
You'll need to check the "allow modifier keys to be assigned standalone" option in order to bind things to Shift/Ctrl/Alt/etc. On the other hand if it only doesn't work for one/both of the shift keys in particular, that might be an issue with the current input driver.
Anyway, I've been very recently working to finally(!) wrap up the v4 release which I should be able to get out there fairly soon. After that I'm going to be focusing on officially migrating the project to Qt 5, as well as continuing and merging Benny's excellent work with the redesigned debugger frontend. (That said, if you have any feedback/suggestions specifically pertaining to that, feel free to post them in the other thread for now)
v4's the last native release I'll be working with, citing a version incompatibility with Qt 5. Still, I managed to compile it with a modification to the makefiles...
KungFuFurby wrote:
v4's the last native release I'll be working with, citing a version incompatibility with Qt 5.
Is that because of an incompatibility with a particular version of OS X or something? Do you know if it affects all Qt 5 releases or just more recent ones?
I'm on Mac OS X 10.6.8. I actually modified the makefiles on my end to account for the SDK version, and thanks to Macports, I have C++11 support, which was a previous sore spot for compilation on my end.
I actually looked it up one day via MacPorts. Qt is utilizing features on newer versions of the Mac operating system that are not supported on my version of Mac... and 5.3.2, which I would have to manually build (or hunt it down somewhere...), is the absolute last version I can use, if I've been doing the correct lookup.
Hopefully it shouldn't be any harder to build that way after officially transitioning to 5.x, at least. I don't really foresee the frontend code (even with the new debug GUI) relying on any extremely recent Qt features considering it's all written for Qt 4 right now anyway; I could certainly try accounting for older OS/library versions in the build process somehow.
Might be just as well since AFAIK, options for getting prebuilt 64-bit Qt 5 binaries on Windows are still limited - the only official ones are for MSVC (which isn't an option for this project right now), and the Qt64-NG project stopped at 5.5.0. msys2 lets you install newer versions but I'm not yet sure how those compare in terms of size/dependencies since I haven't tried that option yet.
https://github.com/devinacker/bsnes-plu ... -04-x64.7zI've finally had time to finish all the miscellaneous stuff I'd been putting off this year. Changes in no particular order:
Code:
v04 [2018-06-18]
Added reworked tile viewer, fully replaces original VRAM viewer [UnDisbeliever]
Added tilemap export option and various other improvements to tilemap viewer [UnDisbeliever]
Added mouse and gamepad/joystick support to input driver on macOS [Optiroc]
Added reworked Cx4 low level emulation based on ikari's documentation [Revenant]
(WIP, improves timing in Mega Man X2/X3 intro/attract modes, etc.)
Added experimental 'snesmusic' plugin for SPC/SNSF file playback [Revenant]
Added autodetection of MSU-1 ROMs with no manifest required [Revenant]
Added various additional items to Properties Viewer [Revenant, koitsu, ARM9]
Added option to automatically save/load breakpoints between sessions [Revenant]
Added support for saving unfiltered screenshots [UnDisbeliever]
Added more flexible command-line loading (for BS-X, Sufami Turbo, Super GB games) [Revenant]
Added "Cart ROM" usage mapping for SuperFX code/data [Revenant]
Added support for larger Satellaview data files and more accurate reset state [LuigiBlood]
Added hotkey to pause and advance a single frame [Revenant]
Added hotkey to toggle system power [Revenant]
Added "auto-save SRAM" setting to UI [Revenant]
Added manifest viewer to tools menu/window [Revenant]
Fullscreen mode now auto-hides mouse cursor after 5 sec [Revenant]
Most debug windows are now given focus if opened when already open [Revenant]
Debugger no longer shows cart memory on CPU bus when SuperFX is accessing it [Revenant]
Debugger window is now forced open when a debug event occurs [Revenant]
CGRAM viewer now displays 5-bit color values instead of shifted 8-bit ones [ARM9]
Fixed interrupt-related (and other) dummy reads uselessly triggering breakpoints, etc. [Revenant]
Fixed SuperFX disassembly/logging not always properly accounting for pipelining [Revenant]
Fixed BS-X memory mapping registers causing severe unnecessary slowdown [Revenant]
(fixes Treasure Conflix, possibly others)
Fixed mouse not automatically being released when powering off or changing inputs [Revenant]
Fixed soft-patching headered ROMs when snesreader plugin wasn't loaded [Revenant]
Fixed ROM cheats and ranged breakpoints ignoring address mirroring [Revenant]
Fixed emulation speed hotkeys sometimes failing to restore normal speed afterward [Revenant]
Updated emulation of auto joypad refresh timing [byuu?]
Updated emulation of SMP wait state control [byuu, AWJ]
Updated emulation of SuperFX PLOT dithering (fixes Star Fox) [qwertymodo]
Updated emulation of horizontal scroll latching (fixes PD Pac-Man) [AWJ]
Updated emulation of DSP-n status flags [AWJ]
Updated emulation of S-DSP's ENDX state (fixes Magical Drop) [AWJ]
Updated memory mapping heuristics for some cartridge types (fixes SRAM mapping w/ ExHiROM, etc.)
As usual, thanks to everybody who contributed patches, bug reports and suggestions.
All future releases are going to (finally) target Qt 5, and I'm planning to integrate Benny's new debugging frontend as well. I'll probably have some stuff to discuss about that frontend once I get to that.
macOS build also coming soon (i.e. probably this weekend when I bother getting the repo set up on my work laptop). 32-bit Windows builds are also available on request. (Also, the Windows builds more or less officially use msys2 now, but I still need to update the build instructions...)
Quote:
Updated emulation of S-DSP's ENDX state (fixes Magical Drop) [AWJ]
Sigh, that's not a correct fix. We've already confirmed Magical Drop locks up on real hardware from time to time.
Jonas' research into DSP register initialization was incomplete, and attempting a partial fix to run this game will just push the issue off everyone's radar instead of getting it supported properly.
Oh well, I guess I've been guilty of this in the past too, like my pre-dot renderer hack for Uniracers.
Sorry for yet another bummer post by me. The rest of the changes all look great though, great work!
I became aware of that a little while after the change was originally made upstream (a bit shy of a year ago), but I decided in this case I was willing to err slightly in the user's favor until we actually know what the correct behavior is. Consider it temporary, of course.
(hacks are hacks, I know...)
Yeah, and I can't really complain anymore with bsnes v107. I've got some game title matching to disable the new faster PPU/DSP cores on an as-needed basis.
I was just really hoping we'd get some interest in figuring out this behavior fully. It's a really fun game and deserves proper emulation.
Revenant wrote:
Added experimental 'snesmusic' plugin for SPC/SNSF file playback [Revenant]
Am I supposed to be able to just load a SPC file? If not, how can I play around with this? If so, what am I doing wrong such that it doesn't work?
Yeah, loading any spc/snsf/minisnsf file should work as long as snesmusic.dll (or your OS' equivalent) is present:
Otherwise, it might have a problem with whichever specific file(s)? you're trying to load? I can check it out if you're having issues.
Ahh, problems from not installing things. Have to put snesmusic.so in the system-wide library directories, or else run with LD_LIBRARY_PATH=/path/to/directory/containing/so/file
Thank you!
(Made a stupid shell script to let me continue to not install things.)
Cool, glad it works
It's definitely a pretty rudimentary player; I originally made it for the completely silly reason of being able to debug some strange SPCs that I dumped from a Super Wild Card DX firmware a while ago. It's a good companion for the (equally rudimentary) sound viewer window though.
I'm trying to get started on some from-scratch homebrew work, and was very quickly vexed by the relative unfriendliness of the debugging process when dealing with existing asm code, especially compared to, say, debugging a C++ project in Visual Studio.
I've started prodding at some parts of the toolchain so far, mostly just to get source-assembly files mapped to rom memory addresses in the disassembler, and wanted to gauge if there was any interest in this. So far, I've just got a
small proof-of-concept here. (old disassembler is in the top left, and my local version showing source info is in the top right, plus a couple of the source asm files for one of the projects from Neviksti's Snes starter kit provided for reference). This consists of a couple small changes to wla-dx's linker to output the obj list info into the final symbol file (and generate the address-to-line map) and changes to bsnes to acknowledge that sym file and reformat the disassembler accordingly.
In terms of long-term goals, I'd like to going beyond in-emulator debugging, though. Ideally, I'd like to get to a point where one can have a VS Code debugger extension that talks to bsnes in a robust capacity. For example, from VS Code, launch bsnes as a debug target, drop a breakpoint in Code in an asm file (which bsnes is able to acknowledge as an exec-breakpoint on the corresponding address), and be able to present some debug information in Code when the emulation is paused. That may be a ways away, but I wanted to sort of read the room to see if adding such functionality to bsnes - or at least this debug-centric fork of bsnes - would be up for consideration.
So, this is really poor to debug when I compare it to the best debugger on the market
That is really not a fair comparison.
I guess when you have an external linker like WLA-DX you really don't know where stuff is compared to where you write it... that would really suck.
Having a fully integrated VSCode module would be awesome. However for a first step ( and yes I know I'm a broken record at this point BUT ) having a remote "monitor" would be a more useful addition. Then we can use the monitor to debug and test the code. Then the VS Code debugger can interface with the monitor keeping it neatly separated.
Oziphantom wrote:
I guess when you have an external linker like WLA-DX you really don't know where stuff is compared to where you write it... that would really suck.
That's kind of touching on something I was wondering myself: is there a toolchain I'm not aware of where that isn't the case, or am I missing some part of the process people pursue normally when doing rom dev where this functionality wouldn't be desired right from the get-go? I mean, aside from "most rom development has just been hacking at existing rom files and
there really isn't much of a homebrew scene"
Quote:
Having a fully integrated VSCode module would be awesome. However for a first step ( and yes I know I'm a broken record at this point BUT ) having a remote "monitor" would be a more useful addition. Then we can use the monitor to debug and test the code. Then the VS Code debugger can interface with the monitor keeping it neatly separated.
So, based on my understanding of how such a debug extension (and corresponding suite) would exist, that is kind of how it should be architectured, anyway. There would have to be a module added in the emulator that operates on stdin to be able to respond to external actions and stdout to relay information about the emulator's current state, e.g. the c++ debug extension can talk with GDB through stdin/stdout, and afaik the python debug extension talks with
python's existing pdb module in a similar capacity. The debug extension in Code is then used to be the adapter/interface between Code's host UI and the target in question.
I haven't dug into that part of it too much - don't want to put the cart before the horse too much - but the "module in bsnes" would probably turn into "Expand the console in Debugger to include a lot more information, add a field to allow for user input for various commands and interactions, and then pipe each of those through stdout and stdin respectively".
Most of the good SNES tools are Win95. Back then we had X816 which doesn't have a linker, Geiger's Debugger ( which has now been superseded ) and a bunch of viewing tools. Before Geiger's we had the ZSNES debugger.
Using a linker assembler like WLA-DX will complicate things, I don't use WLA-DX
STDIN/STDOUT I guess works, I'm more use to using sockets and a telnet interface, which is basically the same code wise, just you can
a.) attach mid run and not have to set it up at the start
b.) can be piped through to another machine/VM - which is handy for when you need to run some Linux VM to get bleeding edge version that fixes some bug in the emulator you need, and its not in the windows build yet
Having
M
D
Bank
R
Break
Watch
Trace
>
and I guess something that lets us change if A/Index should be 8/16bit is the bare minimum
having A would also be handy, L, S super handy as well
Been working away at this, and finally got to a proof of doing some light debugging in VS Code, i.e. being able to pause and step from VS Code, display the current PC in a file, and also setting/clearing breakpoints before launching a session or during a session:
https://www.youtube.com/watch?v=hkuMV-1LLmISome parts of it are still rough and needs some cleanup and all that sort of thing, but it's at the point of being functional. As mentioned before, the VS Code interface really is pretty simple once you get things going: it throws down json requests to bsnes via stdin, and bsnes sends json responses and events about the current state of the debugger back through stdout.
I've already got an issue/task filed on wla-dx to add the necessary addr-to-line mapping to the WLA symbol file, but haven't yet filed the PR for a few reasons, but I will get that going once I polish a few things up. I'll also take a look at asar to see how easy it'd be to add the same information to its wla-style symbol file output, since that's a popular tool.
Once I polish up the bsnes stuff as well, I'll also file a PR (or just a task) to devinacker to add this functionality to bsnes. So far, it's basically taking a bunch of work
benny already did around symbol loading/mgmt, adding the functionality to communicate with vscode, adding a git submodule for another json project (though, Qt5 upgrade will deprecate that) and uplifting a handful of other systems accordingly.
Also, ofc, got to prep the extension itself to launch the bsnes executable from vscode and publish that somewhere. It's not a whole lot - we don't need a debug adapter because bsnes supports the debug protocol directly - but it's just a little bit.
Do you have a good source that explains how to make VSCode plugins like this. Everything either just does simple stuff or assumes you are doing some JS stuff and know all this 80 things on how it works...
Yeah, tell me about it... Ironically, despite the frustrations in trying to shake down the various pages and documentation on this, furiously asking "What do you want from me?!?!
" the answer ended up being rather simple - but obfuscated because of much of the intended utility all of the debug adapter extension shenanigans.
So, first off, there is the (newly created)
site for outlining the debug protocol that msft put together. It still focuses a lot on "So you want to make a debug adapter extension or something, eh?" and doesn't discuss the raw mechanics. However, those raw mechanics just aren't that much:
and that's...pretty much it. With some additional notes:
For one, in this case, I'm only launching the process because it implements the debug protocol directly - there isn't an adapter that has to reinterpret things to talk to another existing debugger (see: gdb, pdb, etc) or run in a node.js env. This is defined in what is currently a very light extension, that basically only
Contributes a debugger that defines the path to bsnes to launch, and a couple configuration attributes that will be tacked onto the Launch request (e.g. "program" to define what ROM to load up, or "stopAtEntry" to have the game start in a frozen state) which the bsnes debugger has to acknowledge.
Two, the specification for requests, responses, and events, are available
here (this was also available historically as, at the very least,
this TypeScript definition file in the VSCode github repo). As mentioned, those are JSON objects in HTTP messages, so the format of everything will be, with cr/lf visible, along the lines of:
Code:
Content-Length: 331\r\n
\r\n
{"command":"initialize", "arguments": {"clientID":"vscode", "clientName":"Visual Studio Code", "adapterID":"bsnes debug", "pathFormat":"path", "linesStartAt1":true, "columnsStartAt1":true, "supportsVariableType":true, "supportsVariablePaging":true, "supportsRunInTerminalRequest":true, "locale":"en-us"}, "type":"request", "seq":1}
And the responses back have to be the same way, including the Content-Length header,
and including the "\r\n\r\n", no more, no less (see "responses and events are sent back..." above). I only mention this part because I was tearing my hair out for a couple of hours trying to understand why my initial implementation wasn't working, and it turned out I had stdout in text mode, not binary, so my "\r\n\r\n" was turning into "\r\r\n\r\r\n" which was causing a silent failure.
Getting back to the original question, though,
this implementation of a debug protocol written in C to do debugging of lua is what you're probably looking for in terms of raw code that peels these covers back. Of course, you can get a tease of my current implementation of this stuff over
here, too. Not yet shippable, and there's some stuff that's going to change as I go, but this is kind of the skeleton of it so far (note that ExternDebugHandler::processRequests is called as part of the Application::run tick, if you're wondering about the re-entry point of it all)
Cool stuff
Although I'm not (currently) one myself, VSCode users may also be interested in
Optiroc's syntax definitions for SNES assembly. They're part of libSFX which is based around ca65 instead of WLA, but ideally I'd like to support loading symbols from both, especially since libSFX is already designed with some of bsnes-plus's existing debugging features in mind (namely software breakpoints, etc.) and it'd be great to support even tighter integration between a SNES development framework and other external tools like that.
Anyway, while I've mostly been working on Cx4 and Satellaview emulation recently, I don't have a whole lot more to do for those for the time being (until I start setting up some more hardware tests on my actual Satellaview unit, anyway). Pretty soon I'll start to integrate Benny's debug frontend stuff a little bit at a time in order to get feedback/make some potential adjustments as needed. Once that's further along I can start to get this stuff integrated as well.
(I also have a more-or-less working Qt5 branch of the existing frontend ready to go, so I might go ahead and merge that into master before I start doing any more big-time GUI updates; what do you think?)
Personally I have no major opinion on the timing of Qt5 integration, but I can give more information that may influence yours: Right now, to support JSON objects gracefully, I had to add an additional git submodule to the project to link in another JSON repo, and use the functionality that that provides. However, Qt5 provides a JSON system as well, that was absent from Qt4. If Qt5 is integrated before I prep a PR for the vscode work, I have no issue with supporting Qt5’s objects beforehand. If Qt5 is integrated after I prep a PR, then some work should be done after-the-fact to deprecate and remove the external JSON functionality I’m roping in. Aside from that it doesn’t affect me, really.
That's a good point, and there isn't ever going to be a non-Qt5-based release that includes the new debugger GUI, so I'd probably consider working from (or merging) the qt5 branch if possible and working from there if possible.
(Also, if you're planning a pull request, please be aware that I'm not planning to merge benny's entire fork all at once at any point, and there will likely be commits from that fork which end up being omitted entirely, depending on how I feel about certain changes/features, so you'll probably end up needing to rebase your changes at some point in the future)
Yeah, when I say "Based on" I mostly mean "I copied everything in
disassembler/symbols and cleaned out some stuff that may not make sense in the immediate term but can be recuperated later" (e.g. breakpoints specified in the symbol files themselves, being able to write out new symbol files from the emulator). I'm not operating on the full fork or anything. There will be some collision of code, but it should not be too significant because most of the changes in that vein should be shared. Later on, when a PR is actually filed and let's say you haven't integrated any of benny's work, I can do a check to see how bad a resolve looks like if, say, all of that stuff had to come in - since that would be some work that you have to do ultimately - but that can be handled at the time, if that scenario comes to pass. Otherwise, if it comes to it that you integrate his work, I'm fine handling the resolves myself.
CypherSignal wrote:
Yeah, tell me about it... Ironically, despite the frustrations in trying to shake down the various pages and documentation on this, furiously asking "What do you want from me?!?!
" the answer ended up being rather simple - but obfuscated because of much of the intended utility all of the debug adapter extension shenanigans.
(snip)
Not yet shippable, and there's some stuff that's going to change as I go, but this is kind of the skeleton of it so far (note that ExternDebugHandler::processRequests is called as part of the Application::run tick, if you're wondering about the re-entry point of it all)
Awesome thanks.
Now we just need to get the newish debugger with a Windows binary
So one can see the WRAM as graphics
The current release does already have support for showing WRAM (as part of the entire CPU address space) in the graphics viewer, if that helps.
Ooo I missed the new release... indeed it does. AWESOME thanks.
I actually tried playing around with VS Code integration awhile back, so I'm really happy to see that somebody managed to succeed where I failed. That being said, however, I was able to get
bass v15 syntax highlighting working.
https://github.com/devinacker/bsnes-plu ... tag/v05rc2Apologies for such a long wait since the last release. v05 with most of the new debugging frontend goodies and other stuff is almost ready. I'm publishing this as an informal release candidate for now, since I'm about to be away from home until next week and I didn't want to just publish a major update immediately before leaving, but I still wanted to finally get this out there in some form since I had been working to wrap it up lately after finally being able to make time for it again.
Some of the stuff from Benjamin's new GUI fork (custom message logging, value graphing, etc.) isn't in yet just because I wanted to give those a little more deliberation, but I do still plan to incorporate more new stuff, hopefully soon.
There are also a couple of emulation related things (SA1 timing, for example) that are mostly ready to go in local branches but I didn't want to actually merge yet for various reasons.
Anyway, check it out, feedback and suggestions are always welcome. I'm going to try for a "real" release next week once I'm back home, but hopefully this is pretty much it unless I managed to screw something up at the last minute without realizing it. Final release will have more in-depth/updated documentation and stuff but the GitHub release page also has a preliminary changelog.
edit: replaced with slightly newer build containing some things that weren't merged into the dev branch by mistake
Official v05 release now available!
https://github.com/devinacker/bsnes-plu ... -05-x64.7zI need to update the screenshots in the OP and add them to a more informative project website, but I'll be doing that shortly. (edit: done)
https://ci.appveyor.com/project/devinac ... /artifactsAutomated 64-bit Windows dev builds (w/ accuracy and compatibility profiles) are now available. Still hoping for more frequent official releases from now on, but hopefully this will make it easier for people to get their hands on the latest and greatest.
