Donkey Kong Country 2 and Open Bus

Donkey Kong Country 2 has a pretty well-known bug in the old SNES emulator ZSNES where some stages have spinning barrels that don’t work properly. One of the earliest pictured here, in the first stage of Krem Quay (third world):

Barrel Bayou

After you jump into the barrel, you’re supposed to be able to completely control its rotation by pressing left and right on the d-pad, with the barrel only rotating while you’re holding left or right. In ZSNES, this is horribly bugged. Tapping left or right makes the barrel spin forever in that direction, until you press the opposite direction…which simply makes it spin forever in the opposite direction.

This is more than just annoying – it makes these stages significantly more difficult than the developers intended, since later on the spinning barrels show up over spikes and other hazards:

Klobber Karnage

This used to be somewhat documented in threads on the ZSNES forums, but those unfortunately seem to have gone offline since last I looked at them, and I can’t find the relevant threads indexed in the Wayback Machine.

This bug is caused by ZSNES not emulating open bus behavior. I believe this was originally discovered by Anomie roughly two decades ago, who subsequently fixed the same bug in Snes9x. This original fix hardcoded the specific addresses to return the values that the game depends on rather than properly emulating open bus, but it fixed DKC2 and probably didn’t break anything else. The bug was never fixed in ZSNES, which is now a long abandoned project (last release in 2007).

Purely out of curiosity, I wanted to dig into this a little more to figure out what exactly in the game code causes these barrels to spin forever in an emulator that doesn’t emulate open bus behavior.

On older platforms like the SNES, reading from an invalid memory address usually does not crash the program. There are cases where accessing specific invalid addresses can cause the hardware to lock up, but I don’t believe this can happen on SNES.

Instead, reading from an invalid address usually triggers open bus behavior, where the CPU re-reads the last value that was put on the data bus. SNES specifically has several different internal buses that can retain different open bus values, but this doesn’t affect DKC2.

The main SNES CPU is a 65C816 (aka 65816). There’s some other hardware around it as part of the Ricoh 5A22 S-CPU package, such as a multiplication/division unit and a DMA unit, but the core CPU is a 65816.

65816 is a 16-bit extension of the 6502, a very popular 8-bit CPU used in many systems including the NES (with slight modifications). The 65816 is mostly backwards compatible with 6502 software, which was not important for the SNES (which has no NES backwards compatibility) but was very important for the Apple IIGS that this CPU was originally designed for.

I personally think the 65816 ISA is pretty awkward. 8-bit vs. 16-bit operation is based on new processor status flags M (accumulator / memory size) and X (index register size) rather than being encoded into opcode bits, so software needs to frequently execute the new instructions SEP (set processor flags) and REP (reset processor flags) to manually adjust register and memory access sizes as needed. This also makes 65816 disassembly extraordinarily painful without tracing execution in an emulator, since some instructions vary in length depending on the current processor flags – e.g. an immediate operand can be either 1 byte (8-bit) or 2 bytes (16-bit).

Beyond that (and slightly more relevant to this post), addressing more than 64 KB of memory requires dealing with memory banking which is not fun. The 65816 has a 24-bit address bus, but most addresses are created by combining an 8-bit bank with a 16-bit offset. This is sort of similar to how the earliest x86 CPUs segment memory into 64 KB segments, except 65816 has no address overlap between different 64 KB memory banks.

24-bit 65816 address

Many instructions still operate using 16-bit addresses internally, like on 6502, plus the program counter is still 16-bit. There’s a new 8-bit program bank register (PBR / K) used for instruction fetches, and a new 8-bit data bank register (DBR / B) used for instructions and addressing modes that produce a 16-bit memory address rather than 24-bit. Software needs to manually track and update these bank registers as needed. There are long jump instructions that simultaneously update PBR and PC, but regular jump instructions and conditional branch instructions cannot jump between different program banks.

The hardware stack and the direct page (65816’s replacement for the zero page) are not banked – they are always located within memory bank $00.

The SNES memory map is very much designed around the 65816’s memory banking. It’s much more useful to think of SNES memory addresses as a separate 8-bit bank and 16-bit offset rather than a single 24-bit address.

When you’re inside one of these spinning barrels, Donkey Kong Country 2 reads from addresses $2000 and $2001 in bank $B3. In some other banks these addresses would map to either the cartridge or RAM, but in bank $B3 they are not mapped to anything, so reading from them is open bus behavior. Why does the game do this?

Here’s a disassembly of the part of the game code that performs the open bus read, generated from an execution trace and then edited a bit for clarity (e.g. replacing the relative branch offset with a label). This is part of a routine that’s executed once per frame, beginning when you release left/right on the gamepad while you’re in a spinning barrel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

; initial state:
;   DBR (data bank) = $B3
;   D (direct page) = $0000
;   M and X flags both clear (16-bit registers and memory)
;   X = $0E9E
;   Y = $0DE2
  lda $48,x
  clc
  adc $0028,y
  sta $32
  eor $48,x
  and $2000       ; 16-bit open bus read!
  beq continue

; this part of the routine will never execute if open bus reads always return 0
  lda #$0000
  sta $0028,y
  lda $32
  clc
  adc #$1000
  and #$e000
  sta $48,x
  rts

continue:
  lda $32
  sta $48,x
  rts

This routine accesses a few memory addresses in the $0000-$2001 range. Some of them are through absolute addressing modes that use the current data bank of $B3, while others use direct page addressing modes that always access bank $00. The direct page itself is located at $0000 here, same as the 6502 zero page.

Banks $B3 and $00 happen to have the same memory map for this $0000-$2001 address range. In banks $00-$3F and $80-$BF, $0000-$1FFF always maps to the first 8 KB of the console’s 128 KB of working RAM (WRAM). $2000-$20FF is entirely unmapped, so the and $2000 instruction is an open bus read.

It’s using a few WRAM addresses here that seem to contain the following, based on what values the game writes to them and what it uses them for:

• $0EE6 ($48 + X=$0E9E): The current barrel orientation
• $0E0A ($0028 + Y=$0DE2): Per-frame rotation amount, as a change to barrel orientation
• $0032: Seems to be used as just a temporary variable

I imagine the exact orientation/rotation locations in WRAM are different for different barrels.

The barrel orientation appears to be on a scale where 0x0000 is pointing straight down, 0x4000 is pointing straight left, etc.

Barrel orientation values

The rotation amount determines the barrel rotation speed. For the barrel I looked at, the game sets the rotation amount to 0x0300 when rotating clockwise and 0xFD00 (-0x0300) when rotating counterclockwise. This makes a full 360 degree rotation take just over 85 frames, a little less than 1.5 seconds at 60 frames per second.

Okay, starting to step through this routine:

1
2
3
4

  lda $48,x     ; $0EE6 - barrel orientation
  clc
  adc $0028,y   ; $0E0A - rotation amount
  sta $32       ; $0032 - temp

This part is straightforward: It loads the current orientation, adds the rotation amount, and stores the result in a temporary variable. It executes CLC (clear carry flag) before ADC (add with carry) because the 65816, like the 6502, does not have an add without carry instruction.

Next is the interesting part:

1
2
3

  eor $48,x     ; $0EE6 - barrel orientation
  and $2000     ; open bus read!
  beq continue

It XORs the updated orientation with the previous orientation, bitwise ANDs the result with an open bus read from $2000, and then branches based on whether the bitwise AND produced zero. The spinning forever bug triggers when the branch is always taken because the bitwise AND result is always zero.

On actual hardware, the 16-bit open bus read from $2000 always returns 0x2020. This is because the last byte read from the bus is always the high byte of the $2000 absolute address encoded in the instruction bytes, little-endian:

2D 00 20

Machine code for and $2000 (3 bytes)

Since the 65816 only has an 8-bit data bus, it implements 16-bit reads by performing two consecutive 8-bit reads, which in this case will both return 0x20. Hence the 16-bit value 0x2020.

So, in practice, that part of the routine behaves equivalently to this:

1
2
3

  eor $48,x     ; $0EE6 - barrel orientation
  and #$2020    ; replace open bus read with constant 0x2020
  beq continue

Moving on, when the AND result is zero and the beq continue branch is taken, it does this:

1
2
3
4

continue:
  lda $32       ; $0032 - temp
  sta $48,x     ; $0EE6 - barrel orientation
  rts

It loads the pre-XOR rotated orientation from the temporary variable, writes it to the permanent orientation location in WRAM, then returns. The rotation will continue next frame.

When the AND is non-zero and the branch is not taken, it does this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  lda #$0000
  sta $0028,y   ; $0E0A - rotation amount

  lda $32       ; $0032 - temp
  clc
  adc #$1000
  and #$e000

  sta $48,x     ; $0EE6 - barrel orientation
  rts

First, it zeroes out the rotation amount. 65816 has a dedicated instruction STZ (store zero) for zeroing out a memory location, but STZ doesn’t support any Y-indexed addressing modes like what the game uses here (absolute indexed Y).

Next, it loads the pre-XOR rotated orientation, adds 0x1000, and masks out all but the highest 3 bits. This is a crude but fast way of approximately rounding to the nearest multiple of 0x2000.

Finally, it writes the rounded orientation to the permanent location in WRAM and then returns.

All together, in a higher level language, this routine is doing this:

1
2
3
4
5
6
7
8

new_orientation = (orientation + rotation) & 0xFFFF
if (orientation ^ new_orientation) & 0x2020 != 0:
    # Approximately round orientation and terminate rotation
    orientation = (new_orientation + 0x1000) & 0xE000
    rotation = 0
else:
    # Continue rotation
    orientation = new_orientation

With the open bus read returning 0x2020, the XOR-then-AND result will be non-zero when adding the rotation amount to orientation changes either bit 5 (0x0020) or bit 13 (0x2000). Given a rotation amount of 0x0300 or 0xFD00, bit 5 is always 0, so only bit 13 can ever change.

For convenience, here’s the orientation values diagram again:

Looking at this, an orientation change of 0x2000 corresponds to a single-step change in cardinal or ordinal direction. This means that bit 13 will change when the barrel either reaches or passes over one of these 8 directions. Whether it changes upon reaching or upon passing over depends on the rotation direction, but it’s not really significant from a player perspective since it’s only a 1-frame difference and only in specific cases.

Rounding to the nearest multiple of 0x2000 ensures that the stopped barrel points exactly in a cardinal or ordinal direction, since it may have passed over the direction on the final rotation frame.

So, if you replace the open bus read with a constant 0x2000, I think this logic makes sense! When you release the d-pad, the barrel continues to rotate in the same direction until it reaches the next cardinal or ordinal direction, and then the rotation stops with the barrel pointing exactly in that direction.

At this point I am pretty sure the open bus read was simply caused by a typo.

I think that and $2000 instruction (absolute addressing) was supposed to be and #$2000 (immediate addressing). and $2000 just happens to work because the 16-bit open bus read from $2000 returns a value that is functionally equivalent to 0x2000 in this logic as long as the per-frame rotation amount always has its lowest 6 bits set to 0.

The incorrect opcode is executed at bank $B3 offset $EDAC, which maps to $33EDAC in the game’s 4 MB of ROM. Changing this byte from 0x2D (AND with absolute addressing) to 0x29 (AND with immediate addressing) makes the spinning barrels work correctly even if open bus reads always return 0. The exact location in ROM probably varies between different revisions of the game; I only looked at one revision.

This was purely an academic exercise since the game works perfectly fine in just about every SNES emulator other than the long-obsolete ZSNES, but my curiosity is satisfied.

Keep your files stored safely and securely with the SanDisk 2TB Extreme Portable SSD. With over 69,505 ratings and an impressive 4.6 out of 5 stars, this product has been purchased over 8K+ times in the past month. At only $129.99, this Amazon’s Choice product is a must-have for secure file storage.

Help keep private content private with the included password protection featuring 256-bit AES hardware encryption. Order now for just $129.99 on Amazon!

Help Power Techcratic’s Future – Scan To Support

If Techcratic’s content and insights have helped you, consider giving back by supporting the platform with crypto. Every contribution makes a difference, whether it’s for high-quality content, server maintenance, or future updates. Techcratic is constantly evolving, and your support helps drive that progress.

As a solo operator who wears all the hats, creating content, managing the tech, and running the site, your support allows me to stay focused on delivering valuable resources. Your support keeps everything running smoothly and enables me to continue creating the content you love. I’m deeply grateful for your support, it truly means the world to me! Thank you!