It is currently Sat Nov 18, 2017 10:59 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 12  Next
Author Message
PostPosted: Thu Apr 30, 2015 4:51 am 
Offline

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


Top
 Profile  
 
PostPosted: Sat May 16, 2015 3:47 pm 
Offline

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


Top
 Profile  
 
PostPosted: Fri May 22, 2015 9:18 pm 
Offline

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

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


Top
 Profile  
 
PostPosted: Sat May 23, 2015 2:38 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 95
Location: Sweden
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.. (:
Image

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?


Top
 Profile  
 
PostPosted: Sat May 23, 2015 10:00 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
Revenant wrote:
https://youtu.be/fZPjFJGzI88


Real Piano Hero 4-player coop mode.


Top
 Profile  
 
PostPosted: Sat May 23, 2015 11:04 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Huh, fading out only lowers the volume, it doesn't stop playback after it goes mute.


Top
 Profile  
 
PostPosted: Tue May 26, 2015 2:57 pm 
Offline

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


Top
 Profile  
 
PostPosted: Wed May 27, 2015 3:30 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 95
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Wed May 27, 2015 11:09 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
Will the new refresh rate for the memory viewer, also be applied to the palette and vram viewers?

Still anxiously awaiting the next build! :-)


Top
 Profile  
 
PostPosted: Wed May 27, 2015 11:29 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed May 27, 2015 1:54 pm 
Offline

Joined: Wed Jul 09, 2008 8:46 pm
Posts: 238
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.


Top
 Profile  
 
PostPosted: Wed May 27, 2015 2:54 pm 
Offline

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


Top
 Profile  
 
PostPosted: Wed May 27, 2015 4:52 pm 
Offline

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


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 12:11 pm 
Offline

Joined: Thu Feb 26, 2015 2:37 am
Posts: 38
I'm wondering, will bsnes-plus and bsnes-classic ever get x64 or accuracy builds?


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 9:21 pm 
Offline

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 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