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)
64-bit builds (including accuracy) are now available in the OP.
Going forward I'll probably keep publishing both 64 and 32-bit builds (but most likely only 64-bit for accuracy).
Going forward I'll probably keep publishing both 64 and 32-bit builds (but most likely only 64-bit for accuracy).
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Yah for 64-bit for accuracy!!
Does anyone know if BSNES-Classic has a 64-bit for accuracy build now as well?
Does anyone know if BSNES-Classic has a 64-bit for accuracy build now as well?
Re: bsnes-plus and xkas-plus (new debugger and assembler)
If you're using bsnes-plus for development or ROM hacking, you should be aware that PPU register viewing and VRAM/CGRAM/OAM breakpoints only work with the compatibility profile.
I don't have access to an environment to build 64-bit Windows binaries, but as far as I know bsnes-classic should compile for that target if you have the necessary libraries (i.e. Qt 4.8).
The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.
I don't have access to an environment to build 64-bit Windows binaries, but as far as I know bsnes-classic should compile for that target if you have the necessary libraries (i.e. Qt 4.8).
The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
I've uploaded newer 64-bit builds which should be a fair bit faster than the previous ones (blame me not bothering to switch away from outdated sjlj-based tools until now...)
If you were experiencing slower emulation with the x64 builds (especially with coprocessor-based games) that shouldn't be an issue anymore.
I personally did not even own a 64-bit machine until fairly recently, which is one of the reasons I didn't publish 64-bit builds until now (the other being the aforementioned lack of official 64-bit Qt binaries for Windows). But both of those aren't issues for me anymore, and I can keep producing 32-bit builds with the same toolchain, so I'll likely continue to do so until it stops being feasible.
If you were experiencing slower emulation with the x64 builds (especially with coprocessor-based games) that shouldn't be an issue anymore.
I think having 64-bit compatibility and accuracy but only 32-bit compatibility seems like a pretty reasonable default. I think most people at this point would be best-suited by the 64-bit compatibility build, whereas a 32-bit accuracy build would be too underperforming to be worth it (and I doubt many potential users still need the performance profile that much...)AWJ wrote:The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.
I personally did not even own a 64-bit machine until fairly recently, which is one of the reasons I didn't publish 64-bit builds until now (the other being the aforementioned lack of official 64-bit Qt binaries for Windows). But both of those aren't issues for me anymore, and I can keep producing 32-bit builds with the same toolchain, so I'll likely continue to do so until it stops being feasible.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
I gave up on 32-bit builds, myself.
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.
I haven't heard a single complaint from anyone for not having the 32-bit builds anymore. And I usually average around 60,000 downloads a release (it was a 2:1 split on 64-bit vs 32-bit when I released both), so I don't think it's really a big issue anymore.
And as much as I want to drop the performance profile, the bottom-tier computers (Zotac Zbox BI-320, Intel NUC5CPYH, etc) still require it to run at full speed. The 10% speedup for 64-bit mode is quite nice here. Even with that, I still dip to around ~55fps during the Yoshi's Island title screen, but the games themselves are all playable.
Another nice ~10% speedup is to use profile-guided optimizations. But like the 32-bit builds, I just couldn't keep up with all the extra work they require (it was seriously taking me 4-6 hours to put together new release builds at one point), so I stopped doing it.
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.
I haven't heard a single complaint from anyone for not having the 32-bit builds anymore. And I usually average around 60,000 downloads a release (it was a 2:1 split on 64-bit vs 32-bit when I released both), so I don't think it's really a big issue anymore.
And as much as I want to drop the performance profile, the bottom-tier computers (Zotac Zbox BI-320, Intel NUC5CPYH, etc) still require it to run at full speed. The 10% speedup for 64-bit mode is quite nice here. Even with that, I still dip to around ~55fps during the Yoshi's Island title screen, but the games themselves are all playable.
Another nice ~10% speedup is to use profile-guided optimizations. But like the 32-bit builds, I just couldn't keep up with all the extra work they require (it was seriously taking me 4-6 hours to put together new release builds at one point), so I stopped doing it.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Have you tried MinGW-W64? Despite its name, it can make 32-bit builds.byuu wrote:For whatever reason, the 32-bit MinGW project ships with headers from Windows 98.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: bsnes-plus and xkas-plus (new debugger and assembler)
I used to have those exact things in the build instructions for bsnes-plus back when I still used the original MinGW (which is basically dead, for all intents and purposes). Now that I use mingw-w64, I can just make both 64- and 32-bit builds with the same stock toolchain in about 30 seconds total. (I do plan to eventually commit some makefile additions to streamline it a bit for other people, but it definitely beats having to scavenge for fixes to an out-of-date compiler distribution.)byuu wrote:I gave up on 32-bit builds, myself.
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
> Have you tried MinGW-W64? Despite its name, it can make 32-bit builds.
Yes, -m32 produces binaries with miscompiled instructions. This causes lots of weird glitches and outright crashes depending upon what you do. It's probably fine for simple projects, but doesn't work for something as complicated as higan. The NES core seems especially prone to problems.
I guess the SNES core is stable enough for Revenant, so that's good at least.
Yes, -m32 produces binaries with miscompiled instructions. This causes lots of weird glitches and outright crashes depending upon what you do. It's probably fine for simple projects, but doesn't work for something as complicated as higan. The NES core seems especially prone to problems.
I guess the SNES core is stable enough for Revenant, so that's good at least.
-
- Posts: 3
- Joined: Sat Nov 21, 2015 11:05 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Excelent work and congratulations for the Accuracy Build!!!! Please, can you upload an updated x64 accurate build? Air Strike Patrol have a bug in the "Good Luck" message when I launch it in the accuracy profile but with the last compatibility build (2015/11/21) the message shows perfect. Thanks!!!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
If I recall, that "Good Luck" text is supposed to "rotate", but it's on the same BG as the HUD on the left. The compatibility profile caches the BG scroll registers so the message and HUD both end up stationary. And a long time ago with v073 accuracy, the timing was wrong so the effect didn't work right. It's fixed in since probably v078 or so, but ... yeah. I get that I change the internals too much for you to be able to do much besides attempt back-porting fixes. Especially for your specific case where you can't just use the relatively stable Emulator::Interface, but have to tap into all the internal state for the debugger. We're in kind of a lose-lose situation here with all these forks, unfortunately :(
The ASP devs definitely enjoyed toying with the PPUs.
The ASP devs definitely enjoyed toying with the PPUs.
-
- Posts: 3
- Joined: Sat Nov 21, 2015 11:05 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Thanks for the reply!! Well, it's a pity for now. I love the SNES games and I love this emulator for the accuracy but it's open source after all so I can wait for futures releases (for the bsnes-plus version with more Higan capabilities). Thanks again for this awesome work!!!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Out of curiosity, what changed about the timing that fixed that spinning text? I know ASP has been well-known for doing some rather uncommon stuff with the PPU, but I didn't realize the BG scrolling trickery behind that text (or whatever it is) until I tried it for myself. Doing a comparison of the accuracy PPUs in higan and bsnes-plus didn't reveal anything obviously relevant to me, but I'm certainly not all that familiar with the details of either one.byuu wrote:If I recall, that "Good Luck" text is supposed to "rotate", but it's on the same BG as the HUD on the left. The compatibility profile caches the BG scroll registers so the message and HUD both end up stationary. And a long time ago with v073 accuracy, the timing was wrong so the effect didn't work right. It's fixed in since probably v078 or so, but ... yeah.
I did backport the fix you recently made for ATX2, and I know AWJ made some other changes to the PPU a while back, but do you think there are any other potential accuracy issues still worth checking on?
-
- Posts: 3
- Joined: Sat Nov 21, 2015 11:05 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Well, there is a bug in the Super Game Boy emulation: missing sound effects in Game Boy games. For example, unaudible multiple shots sounds with the S weapon in Operation C (Contra) and unaudible percusison effects of the music in Crystal Castle and Cloud Castle of Castlevania 2 Belmont's Revenge.
Last edited by sUPERtOTO009 on Thu Nov 26, 2015 1:26 pm, edited 1 time in total.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
> Out of curiosity, what changed about the timing that fixed that spinning text?
I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.
> do you think there are any other potential accuracy issues still worth checking on?
Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?
Again, bad memory, so I can't really point you at many specifics >_>
I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.
> do you think there are any other potential accuracy issues still worth checking on?
Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?
Again, bad memory, so I can't really point you at many specifics >_>
Re: bsnes-plus and xkas-plus (new debugger and assembler)
IIRC the SD Gundam G-Next problem was a regression that crept in when you changed the SA-1 to use a hardcoded switch table for its address map instead of a Bus object, in an attempt to get back speed that was lost in the post-074 memory system rewrite. bsnes-classic/plus still use the pre-074 memory system (which also means that unlike higan they support SA-1 games with BS-X data pack slots--another casualty of the memory system rewrite)byuu wrote:> Out of curiosity, what changed about the timing that fixed that spinning text?
I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.
> do you think there are any other potential accuracy issues still worth checking on?
Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?
Again, bad memory, so I can't really point you at many specifics >_>