It is currently Mon Aug 21, 2017 3:02 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11, 12  Next
Author Message
PostPosted: Tue Nov 22, 2016 8:10 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 318
Location: FL
Over a year later, here's a new release, better than ever.

Windows 64-bit compatibility & accuracy
Windows 32-bit compatibility

Things 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]


Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 9:26 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 707
Location: New Mexico, USA
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.


Last edited by jwdonal on Tue Nov 22, 2016 9:38 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 9:36 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18813
Location: NE Indiana, USA (NTSC)
For vblank, wouldn't a read breakpoint on the NMI vector work?


Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 9:39 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 707
Location: New Mexico, USA
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.


Top
 Profile  
 
PostPosted: Tue Nov 22, 2016 10:38 pm 
Offline

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


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 4:54 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 7:48 am 
Offline

Joined: Fri Nov 18, 2016 7:56 am
Posts: 8
Just fyi, the snesfilter.dll with xBRZ filters from bsnes classic also works with this!


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 8:51 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9904
Location: Rio de Janeiro - Brazil
Cool! I love PPU debugging tools!


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 9:10 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed Nov 23, 2016 9:44 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18813
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Wed Dec 14, 2016 10:59 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 707
Location: New Mexico, USA
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.


Top
 Profile  
 
PostPosted: Thu Dec 15, 2016 1:03 am 
Offline
User avatar

Joined: Sat Jul 04, 2009 2:28 pm
Posts: 140
Location: Wunstorf, Germany
+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.) :lol:


Top
 Profile  
 
PostPosted: Thu Dec 15, 2016 2:01 am 
Offline

Joined: Mon Jul 14, 2008 4:02 pm
Posts: 84
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.) :lol:


I know that feeling all too well. :lol:
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. ;)


Top
 Profile  
 
PostPosted: Thu Dec 15, 2016 6:14 am 
Offline

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


Top
 Profile  
 
PostPosted: Thu Dec 15, 2016 8:41 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11, 12  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: greatkreator and 10 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