←back to thread

Donkey Kong Country 2 and Open Bus

(jsgroth.dev)
264 points colejohnson66 | 2 comments | 30 Jun 25 15:01 UTC | HN request time: 0.442s | 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. shadowgovt ◴[30 Jun 25 17:16 UTC] No.44425715[source]▶
In 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.
replies(1): >>44426172 #
2. wk_end ◴[30 Jun 25 18:03 UTC] No.44426172[source]▶
Yeah, 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.