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).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.
bsnes-plus and xkas-plus (new debugger and assembler)
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
-
- Posts: 490
- Joined: Fri Mar 01, 2013 4:46 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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!
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!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
That or an actual version control library. How hard would it be to adapt Git?Myask wrote: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.Revenant wrote:On-the-fly ROM saving and reloading from the memory editor for quick hacking and testing
Re: bsnes-plus and xkas-plus (new debugger and assembler)
This is gonna be really useful, thanks.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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
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
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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: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.
-
- Posts: 138
- Joined: Mon Mar 02, 2015 1:11 am
- Location: Australia (PAL)
- Contact:
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Thanks for that.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).
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
> 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.
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.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.
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!
-
- Posts: 490
- Joined: Fri Mar 01, 2013 4:46 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Would you happen to have a time frame, for when we can expect a revision to bsnes plus's debugging features?
Thank You!
Thank You!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.
Not yet, though I'm planning to add hotkeys for some of the debugger functionality.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.
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.ARM9 wrote:The MESS debugger has superfx support, I believe it does sa-1 too but I haven't tested it myself.
-
- Posts: 490
- Joined: Fri Mar 01, 2013 4:46 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
I appreciate your hard work! I'll keep checking back every now and then. Thanks for the speedy reply btw!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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...)Optiroc wrote: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.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.
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!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.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...)