←back to thread

Donkey Kong Country 2 and Open Bus

(jsgroth.dev)
264 points colejohnson66 | 3 comments | 30 Jun 25 15:01 UTC | HN request time: 0.711s | source
Show context
anonymousiam ◴[30 Jun 25 16:23 UTC] No.44425088[source]▶
I started reading this to understand Open Bus, which was capitalized in the title, so I assumed it was a proper name for some old bus protocol/standard that I'd never heard of.

After reading, I realized that he just meant that the bus was "open" as in not connected to anything, because the address line decoders had no memory devices enabled at the specified address ($2000).

It's pretty funny that the omission of the immediate mode (#) went unnoticed until the obsolete emulator didn't behave in the same way as the real hardware when reading <nothing> from memory.

His solution of changing the instruction to use immediate addressing mode (instead of absolute) would have the consequence of faster execution time, because the code is no longer executing a read from memory. 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.

replies(2): >>44425347 #>>44425690 #
wk_end ◴[30 Jun 25 16:47 UTC] No.44425347[source]▶
> 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-go...

replies(2): >>44425657 #>>44425715 #
1. BearOso ◴[30 Jun 25 17:12 UTC] No.44425657[source]▶
There'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.
replies(1): >>44426273 #
2. NobodyNada ◴[30 Jun 25 18:16 UTC] No.44426273[source]▶
It'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.

replies(1): >>44426938 #
3. BearOso ◴[30 Jun 25 19:26 UTC] No.44426938[source]▶
The 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.