arstechnica.com
gotta go precisely the right speed Why SNES hardware is running faster than expectedand why its a problem Cheap, unreliable ceramic APU resonators lead to "constant, pervasive, unavoidable" issues. Kyle Orland Mar 15, 2025 6:00 am | 2 Sir, do you know how fast your SNES was going? Credit: Getty Images Sir, do you know how fast your SNES was going? Credit: Getty Images Story textSizeSmallStandardLargeWidth *StandardWideLinksStandardOrange* Subscribers only Learn moreIdeally, you'd expect any Super NES consoleif properly maintainedto operate identically to any other Super NES unit ever made. Given the same base ROM file and the same set of precisely timed inputs, all those consoles should hopefully give the same gameplay output across individual hardware and across time.The TASBot community relies on this kind of solid-state predictability when creating tool-assisted speedruns that can be executed with robotic precision on actual console hardware. But on the SNES in particular, the team has largely struggled to get emulated speedruns to sync up with demonstrated results on real consoles.After significant research and testing on dozens of actual SNES units, the TASBot team now thinks that a cheap ceramic resonator used in the system's Audio Processing Unit (APU) is to blame for much of this inconsistency. While Nintendo's own documentation says the APU should run at a consistent rate of 24,576 Hz (and the associated Digital Signal Processor sample rate at a flat 32,000 Hz), in practice, that rate can vary just a bit based on heat, system age, and minor physical variations that develop in different console units over time.Casual players would only notice this problem in the form of an almost imperceptibly higher pitch for in-game music and sounds. But for TASbot, Allan "dwangoAC" Cecil says this unreliable clock has become a "constant, pervasive, unavoidable" problem for getting frame-accurate consistency in hardware-verified speedruns.Not to spec Cecil testing his own SNES APU in 2016. Credit: Allan Cecil Cecil testing his own SNES APU in 2016. Credit: Allan Cecil Cecil says he first began to suspect the APU's role in TASBot's SNES problems back in 2016 when he broke open his own console to test it with an external frequency counter. He found that his APU ran just a bit faster than Nintendo's specifications, an inconsistency that could cause the console to throw out unpredictable "lag frames" if and when the CPU and APU load cycles failed to line up in the expected manner. Those lag frames, in turn, are enough to "desynchronize" TASBot's input on actual hardware from the results you'd see on a more controlled emulator.Unlike the quartz crystals used in many electronics (including the SNES's more consistent and differently timed CPU), the cheaper ceramic resonators in the SNES APU are "known to degrade over time," as Cecil put it. Documentation for the resonators used in the APUalso seems to suggest that excess heat may impact the clock cycle speed, meaning the APU might speed up a bit as a specific console heats up. The APU resonator manual shows slight variations in operating thresholds based on heart and other factors. Credit: Ceralock ceramic resonator manual The APU resonator manual shows slight variations in operating thresholds based on heart and other factors. Credit: Ceralock ceramic resonator manual The TASBot team was not the first group to notice this kind of audio inconsistency in the SNES. In the early 2000s, some emulator developers found that certain late-era SNES games don't run correctly when the emulator's Digital Signal Processor (DSP) sample rate is set to the Nintendo-specified value of precisely 32,000 Hz (a number derived from the speed of the APU clock). Developers tested actual hardware at the time and found that the DSP was actually running at 32,040 Hz and that setting the emulated DSP to run at that specific rate suddenly fixed the misbehaving commercial games.That small but necessary emulator tweak implies that "the original developers who wrote those games were using hardware that... must have been running slightly faster at that point," Cecil told Ars. "Because if they had written directly to what the spec said, it may not have worked."Survey says...While research and testing confirmed the existence of these APU variations, Cecil wanted to determine just how big the problem was across actual consoles today. To do that, he ran an informal online survey last month, cryptically warning his social media followers that "SNES consoles seem to be getting faster as they age." He asked respondents to run a DSP clock measurement ROM on any working SNES hardware they had lying around and to rerun the test after the console had time to warm up.After receiving 143 responses and crunching the numbers, Cecil said he was surprised to find that temperature seemed to have a minimal impact on measured DSP speed; the measurement only rose an insignificant 8 Hz on average between "cold" and "hot" readings on the same console. Cecil even put his own console in a freezer to see if the DSP clock rate would change as it thawed out and found only a 22 Hz difference as it warmed back up to room temperature. A sample result from the DSP sample test program. Credit: Allan Cecil A sample result from the DSP sample test program. Credit: Allan Cecil Those heat effects paled in comparison to the natural clock variation across different consoles, though. The slowest and fastest DSPs in Cecil's sample showed a clock difference of 234 Hz, or about 0.7 percent of the 32,000 Hz specification.That difference is small enough that human players probably wouldn't notice it directly; TASBot team member Total estimated it might amount to "at most maybe a second or two [of difference] over hours of gameplay." Skilled speedrunners could notice small differences, though, if differing CPU and APU alignments cause "carefully memorized enemy pattern changes to something else" between runs, Cecil said.For a frame-perfect tool-assisted speedrun, though, the clock variations between consoles could cause innumerable headaches. As TASBot team member Undisbeliever explained in his detailed analysis: "On one console this might take 0.126 frames to process the music-tick, on a different console it might take 0.127 frames. It might not seem like much but it is enough to potentially delay the start of song loading by 1 frame (depending on timing, lag and game-code)." Cecil's survey found variation across consoles was much higher than the effects of heat on any single console. Credit: SNES SMP Speed test survey Cecil's survey found variation across consoles was much higher than the effects of heat on any single console. Credit: SNES SMP Speed test survey Cecil also said the survey-reported DSP clock speeds were also a bit higher than he expected, at an average rate of 32,078 Hz at room temperature. That's quite a bit higher than both the 32,000 Hz spec set by Nintendo and the 32,040 Hz rate that emulator developers settled on after sampling actual hardware in 2003.To some observers, this is evidence that SNES APUs originally produced in the '90s have been speeding up slightly as they age and could continue to get faster in the coming years and decades. But Cecil says the historical data they have is too circumstantial to make such a claim for certain."We're all a bunch of differently skilled geeks and nerds, and it's in our nature to argue over what the results mean, which is fine," Cecil said. "The only thing we can say with certainty is the statistical significance of the responses that show the current average DSP sample rate is 32,076 Hz, faster on average than the original specification. The rest of it is up to interpretation and a certain amount of educated guessing based on what we can glean."A first stepFor the TASBot team, knowing just how much real SNES hardware timing can differ from dry specifications (and emulators) is an important step to getting more consistent results on real hardware. But that knowledge hasn't completely solved their synchronization problems. Even when Cecil replaced the ceramic APU resonator in his Super NES with a more accurate quartz version (tuned precisely to match Nintendo's written specification), the team "did not see perfect behavior like we expected," he told Ars.Beyond clock speed inconsistencies, Cecil explained to Ars that TASBot team testing has found an additional "jitter pattern" present in the APU sampling that "injects some variance in how long it takes to perform various actions" between runs. That leads to non-deterministic performance even on the same hardware, Cecil said, which means that "TASBot is likely to desync" after just a few minutes of play on most SNES games. The order in which these components start when the SNES is reset can have a large impact on clock synchronization. Credit: Rasteri The order in which these components start when the SNES is reset can have a large impact on clock synchronization. Credit: Rasteri Extensive research from Rasteri suggests that these inconsistencies across same-console runs are likely caused by a "very non-deterministic reset circuit" that changes the specific startup order and timing for a console's individual components every time it's powered on. That leads to essentially "infinite possibilities" for the relative place where the CPU and APU clocks start in their "synchronization cycle" for each fresh run, making it impossible to predict specifically where and when lag frames will appear, Rasteri wrote.Cecil said these kind of "butterfly effect" timing issues make the Super NES "a surprisingly complicated console [that has] resisted our attempts to fully model it and coerce it into behaving consistently." But he's still hopeful that the team will "eventually find a way to restore an SNES to the behavior game developers expected based on the documentation they were provided without making invasive changes..."In the end, though, Cecil seems to have developed an almost grudging respect for how the SNES's odd architecture leads to such unpredictable operation in practice. "If you want to deliberately create a source of randomness and non-deterministic behavior, having two clock sources that spinloop independently against one another is a fantastic choice," he said.Kyle OrlandSenior Gaming EditorKyle OrlandSenior Gaming Editor Kyle Orland has been the Senior Gaming Editor at Ars Technica since 2012, writing primarily about the business, tech, and culture behind video games. He has journalism and computer science degrees from University of Maryland. He once wrote a whole book about Minesweeper. 2 Comments
