Last week's article discussed how the Super Nintendo's Video system feeds the TV's CRT. Today I'll summarize what I understand of the hardware generating these graphics.

A precious resource is Jonathon Donaldson's schematics of the SNES. If you have a large monitor, I recommend to take a minute and look at it in fullscreen to appreciate it in all its glory.

I find this schematics so beautiful that I printed it in A1 size and framed it!

If we zoom into the graphic system, we find four chips. One is called the Pixel Processing Unit 1 (PPU1), labeled 5C77. Another is called the Pixel Processing Unit 2 (PPU2), labeled 5C78. The two remaining are 8-bit 32KiB SRAM chips.

In later revisions, Nintendo fused the CPU, the PPU1, and PPU2 into one massive ASIC. These 1-CHIP versions were less prone to failure but came with their own set of issues^[1].

Jonathon grouped the lines with color code so we can convert the schematic into a drawing.

We can infer a lot just by looking at the labels.

• We find the R, G, A, and CSYNC from last week on PPU2, which indicates the video signal is generated there. Likely the palettes are stored there as well.
• In Orange, we see the PPU1 is able to address the VRAM. The PPU2 has only access to the data lines (cyan). This indicates that the PPU1 is the brain while the PPU2 has a role of compositor doing the heavy lifting.
• In Blue, we see not only control lines between the PPU1 and PPU2 but also colors which seem to indicate the PPU1 is streaming "pixels" and syncing with the PPU2.
• In Magenta and Brown we find the system 8-bit data bus and 8-bit address bus. This shows the CPU can send commands to both chips.
• The rest of the system has no direct access to the VRAM. All writes operations from the system bus to the VRAM must go through the PPU1.

This design with one chip making the decision via the address lines and a compositor chip blindly displaying what is coming on the data lines is similar to how Capcom designed their arcade CPS-1, responsible for SF2, Final Fight, Ghouls 'n Ghosts, and many more.

Capcom PPUs, the CPS-A and CPS-B (from The Book of CP-System)

There are three RAMs in the graphic system^[2].

• The VRAM is where the sprites assets, tile assets and tilemap are stored^[3].
• The Object Attribute Memory (OAM) defining the properties of all 128 sprites^[4].
• The CGRAM is where the palette of 256 x 15-bit colors is stored^[5].

The address lines from the PPU1 to the VRAM are weird. This is not a standard arrangement. If you are not well-versed in RAM chips (like me) here is a quick summary to understand the weirdness.

The VRAM chips in the SNES are LH5P832. The datasheet^[6] describes standard pinouts.

• VCC   : Power.
• GND   : Ground.
• A0-A14: Address lines (2¹⁵ = 32,768 = 32KiB).
• D0-D7 : 8-bit data line.
• CS    : Chip Select to enable the chip for R or W.
• WE    : To write to the chip.
• OE    : To read from the chip.

Nintendo engineers could have built a system by using the two RAM chips in serial mode, with A15 from the PPU used to CS the chips. This would have resulted in an 8-bit data bus.

Because they wanted more throughput, they could have created an interleave to build a 16-bit data bus.

But they went further than a 16-bit data bus. They created a system where the RAM chips can be addressed individually...yet shared the pin A14. What is going on here?

Mode 7 (Super Ghouls 'n Ghosts)

The reason for this weird design is that the VRAM is accessed differently, depending on the graphic mode.

In mode 0-6, the PPU1 always accesses two consecutive 8-bit values. That means both the address buses hold the same value on each chip.

Things are different in Mode 7. Because in this mode the background can be rotated and scaled (see animation on the right), the data access is no longer linear.

Since the PPU1 can no longer "predict" where the data to access will be, and bulk retrieve it 16-bit at a time, it needs the flexibility of two address bus.

Moreover, in Mode 7 only 16KiB in each VRAM chip are used, which means A14 is always set to 0^[7].

John McMaster decapped and scanned the PPUs in Oct 2020^[8].

PPU-1	PPU-2

Members of the snesdev.org community have started to identify areas^[9][10] .

PPU-1	PPU-2

So far only five areas have been attributed.

• The 512 bytes OAM (Object Attribute Memory, 1 and 2) describe the sprites in the scene.
• The 256 x 9 bits linebuffer (5 and 6). Learn about line-buffering in part 2.
• The 480 bytes color palette colors in the area 15.

Some of these guesses look off (shouldn't CGRAM be 512 bytes?). When I was researching the topic I was surprised that so little of the internals of the PPUs was known. Given the popularity of the SNES, I expected someone with the time and the skills would have done it by now. That hero has yet to show up.

In the next article, we study how tilemap and sprites are rendered.

^	[ 1]	SNES 1CHIP has disadvantages
^	[ 2]	Super Nintendo: Reading and writing PPU memory
^	[ 3]	SNES Dev: Tilemaps
^	[ 4]	SNES Dev: Sprites
^	[ 5]	SNES Dev: Palettes
^	[ 6]	LH5P832 datasheet
^	[ 7]	PPU1 VRAM, Discuss the purpose of VA14
^	[ 8]	Twitter: S-PPU1 (SNES Picture Processing Unit)
^	[ 9]	Identifying regions of PPU die photo
^	[10]	Internal OAM address sprite evaluation