OAM bug research

[msinger]

Hi,

I got some detail about the reason behind which rows are affected by the OAM bug. I've seen some comments in memory.c that you've already figured out that with some specific timings the first two objects can get corrupted as well. Since you put so much work into figuring all this out, I thought maybe what I found out about this is somewhat interesting to you. Which rows are affected is actually decided by the PPU's address transition that is done while the CPU triggers the bug. The address lines inside the chip all have different lengths and therefore different signal propagation delays. So when the PPU changes the current address it wants to access, the OAM can see multiple different addresses while the address lines change one by one. Those intermediate addresses determine which rows are affected by the corruption.

I figured this out because I'm working on an accurate simulation of a complete DMG-CPU B chip for some years now. (see here: https://github.com/msinger/dmg-sim)
My simulation can predict which memory rows get corrupted, but it does not predict the correct value for the first word of the row. It just copies entire rows. I don't know (yet) what detail I'm missing for that. I ran this example code to trigger corruption:

	ld a, 0x80
	ld (0x40), a  ; enable PPU

	ld bc, 13
	call delay
	nop
	nop
	nop
	nop
	nop
	nop

	ld sp, 0xfdff
	pop bc        ; copies second row over first and third row

	...
delay:
	dec bc
	ld a, b
	or c
	jr nz, delay
	ret

On SameBoy and on a real Game Boy, this produces the following OAM content when it was initialized with Blargg's test pattern:

00000000: 1c 1d 16 17 18 19 1a 1b  ........
00000008: 1c 1d 16 17 18 19 1a 1b  ........    <-- PPU transitions from second row...
00000010: 1c 1d 16 17 18 19 1a 1b  ........         ...to third row and corrupts rows 1, 2 and 3.
00000018: 24 25 26 27 28 29 2a 2b  $%&'()*+
00000020: 2c 2d 2e 2f 30 31 32 33  ,-./0123
00000028: 34 35 36 37 38 39 3a 3b  456789:;
00000030: 3c 3d 3e 3f 40 41 42 43  <=>?@ABC
00000038: 44 45 46 47 48 49 4a 4b  DEFGHIJK
00000040: 4c 4d 4e 4f 50 51 52 53  LMNOPQRS
00000048: 54 55 56 57 58 59 5a 5b  TUVWXYZ[
00000050: 5c 5d 5e 5f 60 61 62 63  \]^_`abc
00000058: 64 65 66 67 68 69 6a 6b  defghijk
00000060: 6c 6d 6e 6f 70 71 72 73  lmnopqrs
00000068: 74 75 76 77 78 79 7a 7b  tuvwxyz{
00000070: 7c 7d 7e 7f 80 81 82 83  |}~.....
00000078: 84 85 86 87 88 89 8a 8b  ........
00000080: 8c 8d 8e 8f 90 91 92 93  ........
00000088: 94 95 96 97 98 99 9a 9b  ........
00000090: 9c 9d 9e 9f a0 a1 a2 a3  ........
00000098: a4 a5 a6 a7 a8 a9 aa ab  ........

This is the wave diagram generated by the simulation:

You can see that the corruption happens around the red vertical marker. The CPU at the bottom is performing a read access. Its rd signal is high and the applied address is 0xFE00. When the CPU outputs an OAM address, the fexx signal near the top rises. This signal inhibits the bit line precharging of the two OAM RAMs (bl_pch_n signals). Because the CPU also performs a read, the word line driver precharging gets also inhibited (wldrv_pch_n). Word lines are the rows of the RAMs; bit lines are the columns.
I documented the SRAM blocks (and all other cells in the chip) here: https://iceboy.a-singer.de/doc/dmg_cells.html#sram
Also a look in the schematics may help understanding things: https://github.com/msinger/dmg-schematics/releases
OAMs are at pages 34 & 35 in the PDF.

The signal vector wl in the diagram above shows which word lines of the RAM are currently enabled. In normal operation, only one word line is enabled at a time. At the point of the corruption however wl is 7. This means that three bit lines are enabled simultaneously: the first, second and third. This causes all bits in these rows to be short-circuited together vertically in their respective columns, forcing them to have an equal state.

We can zoom in to see how this came to be:

We see that the address lines a[6:2] and their complements a_n[6:2] are changing their state one after another. In normal operation, the word line drivers should be precharged during those transitions, which would force all word lines to be disabled. But since the precharge signal is inhibited, the enabled word lines just accumulate with each changing address line.

When we add one additional nop in the code above, then only two rows are affected: The third row gets copied over the fourth row. In the real Game Boy, the first word in the third row is modified like you implemented it in SameBoy before it gets copied.

The following two diagrams show what is happening with this additional nop:

You can see in the zoomed-in version that only one address line needed to change in that situation. That's why there are only two rows involved now.

When the CPU is not reading, but just outputting an OAM address, then only the bit lines are missing their precharge. The word lines are precharged just fine as we can see here in the case of an increment instruction operating on BC that contains 0xfe00:

The diagram shows that the word lines are disabled during the address transition, but the bit lines keep the previous value and transfer it into the next row. In this case the order in which address lines change state doesn't matter, data gets always transferred from one row to the next.

The last diagram shows PUSH BC with SP at 0xFE01:

There are two corruptions going on. In the first one, the CPU just applies the address 0xFE01. In the second, the CPU performs a write operation to 0xFE00. We can see that it doesn't make a difference if the CPU actually writes or not. In both cases only the bit lines miss their precharging. The word lines precharge fine. Only when the CPU issues a read operation (like in the first example) the word line precharge fails.

Like I said, I don't know how those changes in the first word come to be. Maybe I look into this at some time, but first I have to figure out why I can't pass the Blargg dmg_sound test.

I hope this information is useful. I could make some more experiments to see in what order all the address lines change, so that the affected rows can be determined.

I was reading your description about the bug here: https://gbdev.io/pandocs/OAM_Corruption_Bug.html
It still claims that the first two objects are not affected by the bug. Just wanted to let you know, in case you forgot about it.

Regards,
Michael

[LIJI32]

Amazing work! I researched this glitch in an exclusively blackbox manner before since reversing anything lower than the schematics is beyond my skills and toolset, and my explanation of the glitch were mostly handwaving and educated guesses, so it's very nice to see some "real" research being put into it! Looking at my code, it seems to explain why certain rows (e.g. FE40) behave in a more glitched manner than the others (on my DMG, read glitches on that row are non-deterministic, unlike other rows which are fully deterministic) – it's because transitions from row FE38 to FE40 have difference in 4 different bits, meaning you're affected by propagation delays even more. It seems very similar to the LFSR corruption glitch I've been researching recently.

Great work!

[msinger]

Oh, I wasn't aware of the LFSR thingy. Do you know if some of the commonly used test ROMs trigger this? It's probably just audible but not detectable by software, right?

[LIJI32]

There aren't public test ROMs. On CGB and newer, it's software-detectable using the PCM34 register. I have description of the issue in the comments of #397. The tl;dr – channel 4 has a 14-bit counter, and a user-selected bit of that counter is used as the clock for the LFSR. The bit is selected by the upper nibble of NR43, but each bit in that nibble has its own propagation delay (+ there's a "phantom" FF write on CGB-C and older), so writes to NR43 can trigger very quick alterations of the LFSR clock signal and corrupt it in many different ways.

[msinger]

That looks interesting. I'll try to reproduce this once I found the last bug I have in the APU.