Why is BSNES the only emulator that works all the time?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Why is BSNES the only emulator that works all the time?

Post by psycopathicteen »

I just tried testing the "supersaw lead" demo on every emulator, and once again BSNES is the only one it works on. It's probably either the interrupts or SPC700 that's doing it. This isn't the first time I had this problem.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Why is BSNES the only emulator that works all the time?

Post by creaothceann »

It's probably because it's cycle accurate. Did you test forks?

psycopathicteen wrote:every emulator
...


EDIT: The file is 262,143 bytes in size, maybe that one missing byte is throwing things off?
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
jbo_85
Posts: 13
Joined: Wed Apr 01, 2009 12:03 pm
Location: Langara

Re: Why is BSNES the only emulator that works all the time?

Post by jbo_85 »

creaothceann wrote:
psycopathicteen wrote:every emulator
...
Popular emulators:
* bsnes v0.87
Other emulators:
* higan v0.94
:shock:
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Why is BSNES the only emulator that works all the time?

Post by psycopathicteen »

I found out it didn't work in higan, because after the initial SPC load, I immediately zeroed $2142 and $2143 and forgot that they are supposed to be where the SPC700 initially jumps to. So I got rid of the stz $2142 and stz $2143 from my code, and modified the spc700 side code so that it expects the jump address instead of #0, and it works for both Higan and ZSNES. All that's left is SNES9x, which in my experience is a piece of crap.
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Why is BSNES the only emulator that works all the time?

Post by HihiDanni »

For my own framework I'm shooting for bsnes/higan and snes9x compatibility. People using snes9x in place of bsnes for performance reasons seems to be a fairly common occurrence, so I want to support that configuration. It'd allow more people to be able to run my game and I think that's a good thing.

On the latest bsnes-plus, my system has trouble keeping up when I have the screen flooded with sprites. A couple times I even mistook this as my framework causing slowdown on the SNES system itself. But as it turns out, emulator FPS falls to 50 when all the hardware sprites are being used (though it depends on sprite size). I should probably note that the "performance/compatibility" profile does not seem to have this problem, but this is inadvisable for developer testing.

Personally, I've actually found that snes9x is more tolerant of programming bugs in my codebase. I've had total crash corruption bugs reproduced by bsnes-plus that snes9x is unaffected by (or just crashes more cleanly).

I can see justification for emulation issues outside bsnes/higan for cutting-edge, envelope pushing stuff, but for simpler things like doing a basic SPC upload, emulation issues in semi-proficient emulators that can otherwise handle other games doing the same thing is indicative of underlying issues in your code. Anything that relies unnecessarily on specific timing or other low-level details is going to reduce reliability and code reusability. What if your game has some exceptional circumstance where the system is kept busy for a significant amount of time but you have code that needs to run in a very specific scanline? You are going to miss that time window.

I know there's the drive to push hardware limits, but I think we should also strive for more reliable and robust solutions when we don't need to be doing weird things with the hardware.

Maybe not 100% relevant to the post but those are my two cents I guess.

Edit: Oh yeah, there's also the possibility that it only works on bsnes because that's the only one you test with, since you mentioned it broke on higan. Testing development against a single target when there is intention to support multiple configurations can be deceiving at the very least.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Why is BSNES the only emulator that works all the time?

Post by Near »

So the reason the older bsnes works more often is because it was the best combination of accurate but not stringent.

Register randomization came later on, and it exposes endless amounts of bugs, both in homebrew as well as in real commercial software.
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Why is BSNES the only emulator that works all the time?

Post by HihiDanni »

I have no idea how compatibility profiles work, but an interesting idea would be to have compatibility flags, so users could enable/disable potentially breaking features. Or is the implementation between profiles too different to just toggle certain aspects on or off? Additionally, how do the "accuracy" and "compatibility" profiles differ in terms of rendering sprites? Given the amount of work that presumably goes into rendering even a single scanline of the sprite layer, I imagine it could easily become a bottleneck. I might be totally wrong here.

Looking in my game, it seems like there are mainly two things that don't get initialized like they should: the DMA registers, and the fixed color value. That latter one seems to be giving some other homebrew trouble as well. Might as well make the fix in my own codebase at least.

Edit: Looks like the fixed color bug, at least in Neviksti's InitSNES, is that register $2132 is covered in a for loop that zeroes out various registers, but a zero write to this register in fact does nothing. It should be writing $e0 instead.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Post Reply