search

mrehkopf / sd2snes

SD card based multi-purpose cartridge for the SNES
http://sd2snes.de
GNU General Public License v2.0
579 stars 114 forks source link

Adding Option(s) to Disable SA-1 Compatibility Hacks #166

Open RPGHacker opened 2 years ago

RPGHacker commented 2 years ago

Recently, I was debugging one of my SMW patches. Its SA-1 version produced a couple of bugs that occured only in the newest versions of BSNES and Higan, but not in older emulators or on an sd1snes. So I ended up investing a lot of time just figuring out whether this was a bug in my patch or in the emulators themselves.

I eventually found out that my patch was writing SA-1 registers from the SNES CPU, which (as far as I know) isn't supposed to be possible. This produced at least one of the bugs I observed. At first I assumed this was a bug in the SA-1 emulation of sd2snes, but someone told me that this is actually an intentional compatibility hack to make a lot of older SMW hacks work on sd2snes that otherwise wouldn't.

Assuming this is true, I'm wondering if it would be possible to add an option to the firmware to allow you to disable these compatibility hacks. I like using my sd2snes specifically for the purpose of debugging code on real hardware. I do this so that I can be reasonably certain that whatever I wrote actually works as intended on anything that's hardware-accurate. Of course as far as the SNES-side of things is concerned, sd2snes has me fully covered in this regard, but naturally the same isn't necessarily true for all the extra CPUs that it has to emulate. I'm fully aware that I can never rely on 100% accurate emulation there. However, if some of these differences are indeed just compatibility hacks, I'm assuming it would be reasonably possible to add a firmware option to at least disable these for a slightly improved emulation accuracy?

This would really go a long way as far as debugging hacks on actual hardware is concerned, and I would appreciate a feature like that a lot.

jon-nielsen commented 2 years ago

Thanks for creating this issue. I think your proposed option would be helpful. My hobby is to create physical repros, and have found that for romhacks involving SA1, the SD2SNES allows things to run that won't work on a real cart. So for accuracy and testing this would be good if possible.

mrehkopf commented 2 years ago

Thanks for these insightful comments, to be honest, having adapted the SA-1 implementation from RedGuy I wasn't aware of such quirks. I know some SA-1 registers are writable from the SNES side but not all. Maybe that's where the differences lie. In my opinion I should add an SA-1 "quirks mode" option that would allow for those older hacks to work but that would default to the more faithful implementation.

RPGHacker commented 2 years ago

Well, to be honest, I'm also not 100% sure if that's actually unsuported.

In this case, the registers in question were the multiplication registers. I asked Vitor Vilela about this, since he has a lot more experience with SA-1, and he also thinks writing to the multiplication registers isn't supported from the SNES CPU - but the only way to really verify this would be to run tests on a cartridge with an actual SA-1. I don't have access to one unfortunately, but I do still have the ROM that produces these issues, in case someone else has and is willing to do some tests.

Anyways, such a "quirks mode" definitely sounds like a great idea, if it's doable.

jon-nielsen commented 2 years ago

Having tried a few of the SA-1 optimized hacks on real carts I can say that some work, and some don't. The ones that don't do work on the SD2SNES - which is obviously a great thing if you just want to play. With Vitor's hacks specifically there's one that is known to exhibit this. Contra 3 as I recall. There's an issue created on his GitHub for SA1-Root concerning this. Another one I suspect is affected is Mega Man X SA1. Again, this works beautifully on SD2SNES as you would expect.