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!

Last edited by infidelity on Sat Apr 25, 2015 3:57 pm, edited 2 times in total.

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!

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...)

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.

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.

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.)

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.

> (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

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum