I tried adjusting lag definition on the BSNES 115 core, and started getting some good results. Getting desyncs but I'm not familiar enough with SNES to make anything of them yet.
Link to video
It's a start though.
Thanks to Morilli upgrading the BSNES115 core with the ability to do poll based dumping, I'm making some progress in SNES verifications. Mario All Stars to start:
Link to video
Still some obstacles though, Battletoads desyncs randomly, for unknown reasons.
I think a good direction to look into would be to see which games wait for the audio hardware and which don't. Then at least if something desyncs we can know for sure if it's audio or not.
I have mega Man X V1.1 so I tried the password glitch run, which surprisingly wasn't too hard to resync to BSNES115:
https://tasvideos.org/UserFiles/Info/637786637961602621
Unfortunately the run desyncs at the the second Vile fight. Here is one example (I tried 3 times all with slightly different results):
Link to video
Even though it doesn't work I still think it's cool to see it get that far.
I did some very short test runs of Mega Man X 2 and 3, but both desync within about a minute into the game. Pretty disappointing. Not sure what to suspect here, could be SPC700 or maybe Cx4 isn't emulated 100% correctly.
I got Mario 2 in Mario All Stars working a little while ago, so that's something:
Link to video
I'm now pretty much out of stuff to test here. A lot of runs having inconsistent desyncs seems consistent with previous SNES work. Both the console and emulator sides of the SNES are basically black boxes to me, so I don't really have a clear path forward for now. Back to the drawing board.
I did a short test with Super Mario Kart and got some good results:
https://tasvideos.org/UserFiles/Info/637833028188202675Link to video
I learned a few things making this test. The first is that the 'no entropy' setting doesn't give correct results for this game, as it starts with 2P selected, but I tried many times on console and it always starts with 1P selected. So this movie uses 'low entropy.'
The second is that leaving the SNES plugged in seems to preserve SRAM state on the cart even with the battery removed. When I run the movie multiple times, the selected character is saved from the previous run after power cycle.
Maybe I'll make a test run that unlocks 150cc and see if it works on console.
EDIT: made a movie that unlocks 150cc, but it desyncs in star cup on console, still checking if it's deterministic and what the cause might be.
I made a test run of Super Mario Kart that plays through all cups and unlocks 150cc, but when I played it back on console, it desynced on Vanilla Lake in Star Cup. It would be pretty unusual to get this far and then desync if a sound chip desync was to blame, so I suspected it might be an emulation issue.
So I then made a TAS of just Star Cup, and indeed it desyncs on console at Vanilla lake 1, seemingly deterministically.
https://tasvideos.org/UserFiles/Info/637838147769544788Link to video
I also made a time trial TAS of Vanilla Lake 1, but that synced, so my guess is that ice physics combined with all the CPU work of controlling cpu players and items etc is too much and exposes some DSP1b timing error.
I opened an issue for this in Ares Emulator github.
So, that's another dead end. Expansion chip timings seem to need some work in general.
I made a short test run of Ultimate Mortal Kombat 3, but it desyncs with seconds. The desync is random, so I'm guessing this is another SPC700 related desync given how many audio samples this game uses. Definitely not worth trying to resync the play around TAS.
Morilli was able to make a test build where I can change the clock speed of co-processor chips so I could test the impact on some of the desyncing runs.
The behaviour of MMX3 definitely changes with different CX4 speed, so that's something, but I have no way of measuring what the clock rate of my cart is, so I can't really do too much else except note that it's an important variable.
For SMK Star Cup run, I didn't see any change in behaviour. The default clock rate is 7.6 MHz, and I ran the run at both 7 and 8 MHz with no difference. I'm not sure what the variability of a ceramic oscillator is, but 5% seems like a lot, so I would think if it was the clock rate I would have seen some difference, but it's just a guess, maybe I'll try a wider range. EDIT: the run syncs in a range from 7-8.2 MHz. It desyncs at 7.95 and 8.3 MHz due to bad item RNG on the first level, so seems pretty unlikely this is a clock issue.
I tested two more Super Mario All Stars runs, both desync:
Lost Levels Luigi: Luigi gets hit by a fish in 3-2, seemingly deterministically (3/3 trials.)
Mario 3: Mario gets hit by the second goomba in 1-1, seemingly deterministically (3/3 trials.)
