4 ms·
> It's probably now faster by about 2us through that blob of code, but maybe this only matters on bare metal and not the emulator, which is probably not time-pe
by wk_end 1y ago
> It's probably now faster by about 2us through that blob of code, but maybe this only matters on bare metal and not the emulator, which is probably not time-perfect anyway.
(Some) SNES emulators really are basically time-perfect, at this point [0]. But 2us isn't going to make an appreciable difference in anything but exceptional cases.
[0] https://arstechnica.com/gaming/2021/06/how-snes-emulators-got-a-few-pixels-from-complete-perfection/ https://arstechnica.com/gaming/2021/06/how-snes-emulators-go...
- BearOso 1y agoThere's actually some issues with clock drift, and speculation whether or not original units had an accurate crystal or varied significantly in timing. The only way to figure that out is to go back and ask the designers what the original spec was, and who knows if they remember. So they're not really time-perfect, because the clock speeds can vary as much as a half-percent.
- NobodyNada 1y agoIt's mostly the audio clock that is suspectible to drift. Everything except the audio subsystem is derived from a single master clock, so even if the master clock varies in frequency slightly, all the non-audio components will remain in sync with each other. That means the 2 clock cycles could theoretically make an observable difference if they cause the CPU to miss a frame deadline and cause the game to take a lag frame. But this is rather unlikely.
- BearOso 1y agoThe CPU has shown some variation, but yes, it's the APU that has a ceramic clock source that isn't even close to the same among units. Apparently those ceramic resonators have a pretty high variation, even when new. When byuu/near tried to find a middle-ground for the APU clock, the average turned out to be about 1025296 (32040.5 * 32). Some people have tested units recently and gotten an even higher average. They speculate that aging is causing the frequency to increase, but I don't really know if this is the case or if there really was that much of a discrepancy originally. It does cause some significant compatibility issues, too, like with attraction mode desyncs and random freezes.
- shadowgovt 1y agoIn general, even SNES games are still doing frame-locking, right? i.e. if you save 2us you're just lengthening the amount of time the code is going to wait for a blanking signal by 2us.
- wk_end 1y agoYeah, exactly. It'd have to be really exceptional cases. For example, exactly one game (Air Strike Patrol) has timed writes to certain video registers to create a shadow effect, but 2us is so minor I don't think it'd appreciably effect even that. Or, like, the SNES has an asynchronous multiplier/divider that returns invalid results while the computation is on-going, so if you optimized some code you might end up reading back garbage. IIRC ZSNES actually had basically no timing; all instructions ran for effectively one cycle. ZSNES wasn't an accurate emulator, but it mostly worked for most games most of the time.