I added an SPC driver version
April 11, 2014, 01:34:44 am - (Auto Merged - Double Posts are not allowed before 7 days.)
On the topic of detecting emulators for whatever purpose, you'd want to attack something that requires the utmost accuracy. In the past many people used reading the multiplication/division registers before they were ready. Many emulators still aren't perfectly correct there. Other ideas used involved precise h/v counter capturing, proper memory map mirroring etc. Then, there there is the differences in initialization. Even BSNES does not match all the intricacies of the hardware. You do have to be careful not to use a variations that actually differ from real SNES to real SNES.
However, I think the point to detecting an emulator though would be to ensure it meets the accuracy level you need. So, you only need to test for the least common denominator that you require to run your software correctly.
I've already hit two snags in the latest zsnes: the fencepost when storing timer periods counts exclusively. setting a timer period to 148 clocks 149 cycles before the 4-bit counts up in ZSNES, 148 in higan/bsnes. This off-by-one causes one emulator or the other to have a buffer fault because the setting to make it work on one breaks the other. Furthermore in ZSNES the OUTX register (DSP writes a channel's output value to DSP register x9 just before volume adjustment) remains at 0 even when a channel is actively outputting sound and can be heard. The OUTX I can probably make a check for... detecting the timer's off-by-one not so easy (ask the user? is audio skipping? an enable ZSNES hacks option in game's system menu??? [possibly remembering it in SRAM when set]).
Geiger's become completely useless as it just doesn't work right at all now since I switched to using the SPC driver code I wrote. Mind you I think SA-1 is unsupported in Geiger so I knew it was going to be out eventually anyways which sucks because until byuu releases loki Geiger is the only one that lets you see all memory areas at runtime. I updated ZSNES with byuu's patch so it would handle full SA-1 (64-bit) banked games [um, Asar, could you please support exhirom 64mbit wihout kludgery, pretty please???]).
AFAIK the big two (excluding Geiger/Snes9X on account of being inop with my ROM) are ZSNES and higan/bsnes. I could be missing some.
Anyone release yet a SPCTool that works on 64-bit systems yet? One that doesn't give "your version of windows is unable to run..." (meaning it is 16/32-bit/DOS app that won't run on 64-bit). Not that I can really use SPCTool since it has no way to record or playback port inputs from the SNES-side) and of course such would be needed in something like a dynamic player such as streaming audio (same reason ToP's theme is vocal-less when SPC-stated).
Though... looking at this from an emulation standpoint... ROM hacks and homebrews that only work in emulators are actually beneficial because they expose imperfections in emulators.
As previously stated I already found two (three if I count Geiger not properly working at all).
The bad news is ZSNES is unlikely to be updated to fix them any time soon because the tool chains to build it is non trivial.
Geiger looks to be same poop since it's not being actively updated either.
Everyone's waiting for loki I guess.
Seems like it'd be easier and just overall better in every way to write a SPC driver than it would be to fill your SNES code with emulator detection and logic forking code.
I did in fact write just such an SPC driver and BAM the fencepost issue on the timer periods is different between ZSNES/higan so it's not possible to have code that works on both without somehow detecting the off-by-one. The fencepost issue means even the code running on SPC doesn't know if its in sync to the DSP or not!!!