Every Super Nintendo console should run at the same speed. They were all built in factories with the same components so they should all operate at the steady clip mandated by Nintendo all those years ago. Except, apparently, the SNES is speeding up as it gets older.
The matter was brought to the public’s attention by the [TASBot] team, a group within the speedrunning community. If anyone was going to notice vintage consoles suddenly running a hair faster, you could bet it would be the speedrunners. Soon enough, a call was put out to crowdsource some data. Submitters were asked to run a set piece of code to test the DSP sample rate on consoles when cold and warm, to get the best idea of what was going on.
As reported by Ars Technica, the group seems to have pinned down the problem to the SNES’s Audio Processing Unit. It’s supposed to run at 24.576 MHz, with a sample rate of 32,000 Hz. However, over the years, emulator developers and speedrunners had noticed that 32,040 Hz seemed to be a more realistic figure for what real consoles were actually running the DSP sample rate at. Developers found that building emulators to run the DSP at this rate was important to run commercial games as expected, suggesting the hardware might have always been a little faster than expected.
However, more recently, it seems that the average speed of the DSP sample rate has increased further. The average result collected by [TASBot] from modern consoles is 32,076 Hz. What’s more interesting is the range of submitted figures—from 31,976 Hz to 32,349 Hz. It seems that the DSP’s ceramic resonator—used instead of a quartz crystal—might degrade over time, causing the speedup. [TASBot] team members also tested temperature changes, but only found a 32 Hz variation from a frozen SNES to one at room temperature.
The fact that console components degrade over time isn’t exactly news; we’ve featured plenty of articles on leaky batteries and corroded traces. Still, for speedrunners, the idea that the hardware standard itself can shift over time? It’s like feeling quicksand under your feet. What even is reality anymore?
[Thanks to s7726 for the tip!]
vs.
Uh – is that supposed to be 0,32 Hz? or mHz?
(interesting otherwise)
The S-curve plot looks like about 10 Hz between the warm and cold lines of best fit, with some squinting. Since the cold line is room temperature, and the warm line is “warmed up” so about 40 deg.C, going from freezer (-40 deg.C) to room temperature sounds reasonable at 32 Hz.
Also there is the source at the grist under “Single console from frozen”, which you can find from the arstechica caption under the s curve – I make it 32 Hz too.
Doh.
I stumbled over (your “Brits”) “.” instead of “,” as the decimal separator (plus not noticing a “missing” kilo or mega).
As in F=~32(k)Hz vs. variation=32(k)Hz which made no sense.
Brits use ‘.’, as in 8k2. O,5kg is more Euro?
Why decimal separators, at all? 🤔
32000 Hz for sampling rate is just fine, it’s readable the way it is.
Space is the only good separator
Sincerely, France
You already knew what it meant, stop trying to be special
this comment is a very mean roast (needlessly mean) but i agree with the sentiment
we want you at your smartest when you post. don’t pretend to be dumber than you are to correct the article
Thank you for this. Context >> Pedantry
Eww, comma as a decimal separator.
I think you just need to normalize the speedrun results. For every speedrun, you need to know the DSP frequency of the machine that it was done on, and call it F. Then if you divide the expected DSP frequency of 32’000 Hz by F, you get a factor that you can multiply the raw speedrun time by to get the time it would have taken to run the speedrun on a machine that runs at 32’000 Hz. Then you have a number that you can compare with other speedruns that have been normalized in the same way. If we call the raw speedrun time R then the formula for doing this would be: Normalized speedrun time = (32’000/F)*R
It might not work if the overall system speed isn’t directly proportional to the DSP speed, but it probably is.
I guess everywhere that I said DSP frequency just pretend that I said DSP sample rate
It’s not that simple (and also in someways not that problematic either). The SNES CPU has its own quartz resonator which doesn’t have this problem, so the system runs the same speed in general, but sound playback happens at a slightly different base frequency, and things like memory transfers to the DSP also happen slightly faster or slower than they should.
My understanding at this point is it occasionally causes the CPU and APU/DSP to drop or skip a frame when they get out of sync. The concern isn’t that speed runs times will be off significantly, but that an aspect of speedrunning that was taken for granted to have consistent and repeatable behavior.. actually doesn’t
Quartz crystal oscillators tend to drift lower in frequency as they age so if there are sync issues between DSP and CPU they’d become more pronounced over time.
Knowing speedrunners, its just a matter of time until some artificially age their hardware in baking ovens or something just to queeze out the last few milliseconds.
Or replace the resonator with one that is just slightly faster
The wild thing is that right before this story broke, I was remembering my NES would glitch like crazy when it overheated. And I wondered what would be involved to make an emulator that is cycle accurate that reproduces overheated console behavior. I know BSNES is highly accurate, maybe such a project could handle temperature coefficients and effects? It is out of my league, but I thunk it
It is a old wisdom, that if you are dismantling something, leave the crystals in your store. If you are building something, use those old chrystals. Measure and adjust them. All crystalls change over time.
Ceramic resonators are NOT quartz crystals. They’re a whole other beast.
tbh, considering that ceramic resonators have crap precision to begin with, I wouldn’t be surprised if ALL the snes consoles have always had such a large spread and there simply hasn’t ever been such a large census taken before. call me back in 20 years when you can actually demonstrate that it’s changed.
As someone pointed out above, it’s also being measured against the CPU’s quartz crystal, where quartz crystals tend to slow down over time. it’s possible that the quartz crystals on average are slower, rather than the ceramic resonators being faster.
That’s not really possible. The quartz oscillator may slow down infinitesimally over time, but it drives all the timing-critical NTSC or PAL video signals in addition to the CPU clock. If it drifts more than a tiny bit, you get sync issues, black and white output, or no video at all. Even if you don’t notice your game running slightly too fast or slow, you’d notice that.
The SNES even has an adjustable trim capacitor to tweak its master clock – presumably in case it did drift over time.
As far as your first point, it’s unfortunate there is no equivalent empirical data from 20+ years ago, but the DSP system was being very thoroughly reverse engineered by emulator developers and compared to real hardware. The research that resulted in the “magic” 32040hz sample rate for emulation back around ~2007 really does suggest that SNES resonators have been getting worse since then.
Not to mention that this is the expected behavior of ceramic resonators over time.
No, the use of 32040 does not imply anything of the sort.
We don’t know how many SNESes were tested, we don’t know how how they chose 32040 at all. There’s certainly no reason to think that it’s the mean that they found.
It could be as simple as they sampled a small population and 32040 was the lowest they saw. 32040 is comfortably 1.5σ below the mean in the modern data.
MuRata used to have a document on their website about how PZT resonators in the 25MHz grade, just like this one, tended to run fast. I haven’t been able to find it again.