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.
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 address lines from the PP1 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.
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?
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.
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.