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.)
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.
Not seems to, it does work that way. Battery supplies ~3V microamp current when console is powered off to keep the SRAM in standby mode. When console is powered on, the SRAM receives ~5V milliamp current to enable reads and writes. The battery takes a break and could just as well be disconnected or dead. The switching between supplies isn't instantaneous. The small capacitor on the cart discharges during transitions such as resetting to retain the data.
Alyosha wrote:
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.
You can use this test ROM, ironically hosted by TASBot, on a flashcart to see the S-SMP speed and backwards calculate what the ceramic is running at. I like the big bold letters at the top of the discussion thread saying there is no evidence sound units are getting faster as they age. The TASBot people lacking professional electronics knowledge straight out imagined that the ceramic resonator speeds up consoles. It's not as accurate or precise as a crystal or MEMS but games didn't need extreme accuracy or precision on the audio. No software or FPGA emulator replicates the drift of crystals or the ceramic while the console is running.
Ceramic resonators still exist and almost always bundle in the load capacitance unlike the one on SNES. Either way, typical values are ±0.2% max stability with temperature, ±0.1 max stability with aging and ±0.5% max accuracy. Max in the sense of the worst case.
Class 2 ceramics used on SNES for the crystal and ceramic can lose 10%-20% of capacitance with age but the decline exponentially reduces over time and they were probably 10% tolerance to begin with. The Master Clock rate set by the crystal isn't some constant number either. The TASVideos source saying NTSC SNES is 60.0988138974405 fps is a joke.
The crystals used to generate the Master Clock are 21.47727 MHz ±30ppm and can drift 5ppm in the first year. My SD2SNES flashcart displays the Master Clock frequency and it's slightly different on every bootup. It also drifts slightly while the console is running. In other words, using 15 significant figures is fake accuracy.
21.47727 MHz ±30ppm is 21.47727 * (1 ± 30/1000000) = [21.4779143181, 21.4766256819] MHz. Given the crystal's printed 7 significant figures, we have [21477910, 21476630] Hz with rounding. Using either equivalent formula, NTSC NES and SNES are [60.09702, 60.10060] Hz and not 60.09881387708959 Hz or some arbitrarily greater precision. Some people's Master Clock drift is so great that they lose color in Composite and S-Video. As in, outside that range. Why 2CHIP SNES consoles and CRTs got the conspicuous orange trimpot capacitor. Not a cheap part but paid for itself to save on maintenance.
