It is currently Sat Sep 23, 2017 11:59 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page 1, 2, 3, 4, 5 ... 12  Next
Author Message
PostPosted: Sat Apr 25, 2015 1:57 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 325
Location: FL
Two new projects! Hooray! (They're both forks of byuu's programs so I'm putting them both in this thread. Why not?)

bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging.

Screenshots: 1 2 3 4 5

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

Non-debugging features:

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

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

See the project on GitHub for more info and source.

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

xkas-plus is my fork of the xkas v014 assembler. Among other changes, its biggest new features are:
Assembling directly to an IPS patch
Table file support
SNES ExLoROM / ExHiROM support
Ability to export defines and labels to a separate file (supports FCEUX and VICE debug symbols or regular assembly includes)
Additional architecture/platform support:
    MOS 6502 (NES, C64, etc)
    WDC 65C02 and CSG 65CE02 (untested)
    Hudson HuC6280 (TurboGrafx-16 / PC Engine, untested)
    Sony SPC700 (SNES sound chip, syntax subject to change before release)

See the project on GitHub for more info and source.

Download
xkas-plus v14+1 (Windows)


Last edited by Revenant on Mon Dec 19, 2016 8:23 pm, edited 9 times in total.

Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 2:33 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2947
Location: Tampere, Finland
Cool to see some work on SNES debuggers.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 3:12 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
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.

Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 3:17 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 760
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?


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 6:48 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 325
Location: FL
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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 6:57 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
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!


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 7:20 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 325
Location: FL
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...)


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 7:37 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
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!


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:16 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
> 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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 2:13 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 325
Location: FL
byuu wrote:
This looks really cool! Thanks a million for putting this together!
Hopefully with this, we can finally abandon the era of closed-source debuggers (Geiger's Snes9X fork, no$sns)

Very glad to hear you like it! :) I still feel like it's pretty rough around the edges but I think it's at the point where people could get some real use out of it. (Apparently ikari_01 has already been using it for debugging sd2snes / MSU-1 stuff, which is cool!)

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

It also occurred to me that (to my knowledge) there have never been any debuggers with proper SA-1 or SuperFX break/step support, so that seemed like another necessity (and I thank you for bsnes 073 having that Super FX disassembler tucked away, it was a good starting point :P)

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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 2:50 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
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.)


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 2:54 am 
Offline
User avatar

Joined: Mon Mar 02, 2015 1:11 am
Posts: 75
Location: Australia (PAL)
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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 3:32 am 
Offline

Joined: Sun Aug 11, 2013 6:07 am
Posts: 57
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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 3:34 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
Revenant wrote:
bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging.

Fantastic, thanks a lot for making this! :D

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

LOL! :lol:

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 5:38 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
> (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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 171 posts ]  Go to page 1, 2, 3, 4, 5 ... 12  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group