Why is BSNES the only emulator that works all the time?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Why is BSNES the only emulator that works all the time?
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.
-
- 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?
It's probably because it's cycle accurate. Did you test forks?
EDIT: The file is 262,143 bytes in size, maybe that one missing byte is throwing things off?
...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
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: Why is BSNES the only emulator that works all the time?
Popular emulators:creaothceann wrote:...psycopathicteen wrote:every emulator
* bsnes v0.87
Other emulators:
* higan v0.94
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Why is BSNES the only emulator that works all the time?
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.
Re: Why is BSNES the only emulator that works all the time?
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.
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
Re: Why is BSNES the only emulator that works all the time?
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.
Register randomization came later on, and it exposes endless amounts of bugs, both in homebrew as well as in real commercial software.
Re: Why is BSNES the only emulator that works all the time?
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.
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