After everything discussed so far, let me tell you that the graphical subsystem of this console is a true feat of engineering. Given its constrained CPU, one might assume the SNES could never cast a shadow on its competitor, which boasts a '32-bit' Motorola 68000. Yet, Nintendo and Ricoh engineers devised clever tricks that exploit the behaviour of CRT displays, effectively expanding the console's capabilities without the need for expensive, state-of-the-art components.
Before diving deeper into this topic, I strongly recommend reading the NES article first, as it introduces key concepts that will be revisited here.
Design
As with any other console of its generation, the Super Nintendo draws graphics using 2D tiles (8 x 8 pixels). The NES initially achieved this through its signature Picture Processing Unit (PPU), which beams the image in sync with a CRT screen. The Super Nintendo follows suit but incorporates more sophisticated techniques to obtain richer results.
The chipset
The Super Nintendo houses two different PPU chips that constitute the graphics subsystem, collectively known as the Super PPU or 'S-PPU'.
The two PPU chips.
Each PPU package serves specific functionality :
- PPU 1: Renders graphics (tiles) and applies transformations such as rotation and scaling.
- PPU 2: Provides visual effects, including windowing, mosaic, and fading, over the rendered graphics.
This separation, from a programming perspective, is redundant, as both chips are effectively treated as a single unit.
Display modalities
The NTSC system outputs a standard resolution of 256 x 224 pixels at ~60 Hz . The European variant, adhering to the PAL specification, outputs 256 × 240 pixels at ~50 Hz. Be that as it may, most games do not utilise the additional pixels and instead display a letterbox (black lines).
Now, here's the tricky part: traditional TVs have an aspect ratio of 4:3. Yet, if you do the math, the Super Nintendo's output resolution has an aspect ratio of 8:7. Consequently, once the image is beamed on the TV, it looks horizontally stretched, resembling a 292 x 224 pixels frame instead (in the case of the NTSC variant) . Put simply, pixels on the Super Nintendo have an aspect ratio of 8:7, rather than being 'perfectly square'.
Rendered frame with a resolution of 256 x 224 pixels. This is what the console sends to the TV.
Stretched frame as seen from the TV (with an apparent resolution of 292 x 224 pixels).
The reasoning behind Nintendo's deviation from the standard aspect ratio boils down to cost. You will soon see that the S-PPU is very rich in functionality, but not fast enough to render everything at the pace of the CRT beam . Rather than adding more circuitry to the board, Nintendo opted to shorten the width of the visible image, allocating extra space for the horizontal blanking period instead.
Nevertheless, some games like 'Chrono Trigger' account for this factor by intentionally using squashed shapes, which then look correct after being stretched by the TV. This, however, remains an exception, since the majority of games take no extra measures to compensate for this effect.
Organising the content
Memory architecture of the S-PPU.
Due to cost and performance reasons, graphics data is distributed across three memory regions:
- 64 KB VRAM (Video RAM): Stores tiles and maps (tables) used to build background layers.
- 512 B CGRAM (Colour Graphics RAM): Fits 512 colour palette entries, with each entry occupying a word (16 bits).
- 544 B OAM (Object Attribute Memory): Contains tables referencing 128 tiles that will be used as sprites, along with their attributes.
VRAM is implemented using two 32 KB chips, each accessed simultaneously via a separate 8-bit bus. This allows the PPU 1 to fetch 16-bit values per cycle, making it particularly efficient for retrieving multiple consecutive pixels in real time . Additionally, each VRAM chip is connected to a dedicated 16-bit address bus, rather than a shared one. This will prove useful when the PPU 1 needs to switch to alternative memory arrangements - something we'll explore in more detail when we talk about 'Mode 7'.
Constructing the frame
Let's now see how a frame is rendered on the console and subsequently displayed on TV. For demonstration purposes, Super Mario World will serve as an example.
Tiles
Some 16x16 Tiles found in VRAM.
Just like its predecessor, the S-PPU uses tiles to build sophisticated graphics. Although, there are significant improvements compared to the original PPU:
- Game cartridges are no longer wired to the PPU, meaning tiles must first be copied to VRAM (similar to Sega's Mega Drive). This is where the DMA unit becomes very handy.
- Tiles are no longer restricted to their traditional dimension (8x8 pixels) - they can now be up to 16x16 pixels wide.
- When tiles are stored in memory, these are compressed based on colour depth (in other words, the number of colours per pixel). The unit of measurement for this is bpp (bits per pixel). The minimum value is 2 bpp, meaning each pixel occupies two bits and has only 4 colours available. The maximum is 8 bpp, allowing for 256 colours per pixel (at the expense of consuming a full byte of memory).
Background
Background Layer 1 (BG1).
Background Layer 2 (BG2).
Background Layer 3 (BG3).
Rendered Background Layer 1 (BG1).
Rendered Background Layer 2 (BG2).
Rendered Background Layer 3 (BG3).
Rendered Background Layers combined.
The Super Nintendo can generate up to four different background planes. Using either 8x8 or 16x16 tiles, blocks are made of 32x32 pixels (2x2 tiles). That being said, each background layer can extend up to 1024x1024 pixels in size (32x32 tiles). The region in VRAM where these layers are configured is called Tilemap, and is structured as a table (continuous values in memory).
Each Tilemap entry contains the following attributes:
- Vertical and horizontal flip values.
- Priority (either
0or1). - Palette reference from CGRAM.
- Tile reference.
As always, these planes are scrollable. However, the number of features available - such as colour depth, number of layers, independent scrolling regions, and size of selection - depends on the Background Mode activated on the S-PPU, which brings us to the next section...
Modes
The S-PPU provides many operations for backgrounds, but these cannot be chosen arbitrarily. Instead, programmers must choose from eight background modes, each offering a distinct set of features :
- Mode 0: 4 layers with 4 colours each.
- The colour palette is particularly bland, as this mode prioritises the highest number of layers.
- Mode 1: 2 layers with 16 colours each + 1 layer with 4 colours.
- One layer can be split into foreground and background.
- This is the most commonly used mode.
- Mode 2: 2 layers with 16 colours each.
- There is an extra effect available: layers can have each of their columns scrolled independently (similarly to the Game Boy wobble effect but applied vertically).
- Mode 3: 1 layer with 256 colours + 1 layer with 16 colours.
- Colours can be defined using RGB values instead of referencing CGRAM.
- Mode 4: Mode 2 and 3 combined (Column scroll + RGB colour mapping).
- The first layer supports 256 colours, while the second is limited to just 4 colours.
- Mode 5: 1 layer with 16 colours + 1 layer with 4 colours.
- The selected area features an outstanding resolution of 512 x 224 pixels, which will be horizontally squashed to fit on the screen (the final output remains 256 x 224 pixels!). This comes at the cost of rendering 16 x 8 pixels tiles as 8 x 8 ones, and 16 x 16 pixels tiles as 8 x 16 ones.
- Furthermore, the vertical resolution can be extended by activating interlacing, reaching 512 x 448 pixels, which now maintains correct proportions with the output frame. In exchange, interlacing applies the same squashing effect to tiles - this time vertically. This is useful when displaying larger amounts of information (e.g. multiplayer or split-screen).
- Mode 6: A combination of Mode 2 and 5 (high resolution + column scrolling), though it is restricted to a single layer with 32 colours.
As you can see, programmers can now decide whether to prioritise colour depth, number of layers, special effects, or resolution.
Sprites
Rendered Sprite layer.
A dedicated memory region called Object Attribute Memory (OAM) stores a table with references of up to 128 sprites, each with the following properties :
- Size: The S-PPU can combine up to 16 tiles into a 4x4 tile quadrant to build a sprite.
- Tile references: Specifies the tiles used to draw the sprite.
- Screen position: Only sprites within the visible area will be rendered.
- Priority: Since multiple layers overlap, the graphic with the highest priority will be shown. Priority is also determined by the background mode in use.
- Colour palette slot: Allows selection from 9 palette slots in CGRAM.
- X/Y Flip: Enables horizontal and vertical flipping.
The S-PPU can render up to 32 sprites per scanline; overflowing this will only make the S-PPU discard the ones with the lowest priority.
Result
Tada!
The S-PPU renders each scanline on-the-fly, first processing the relevant portion of each layer and then mixing them.
One of the key constraints of NES games was that graphical updates could only occur during V-Blank - the brief interval when the CRT beam was returning to the starting point provided a reasonable time frame to reshuffle some tiles without breaking the image.
Well, now thanks to the enhanced capabilities of the SNES, this limitation now takes on a different meaning.
You see, because the new DMA/HDMA units enable programmers to perform memory transfers without waiting for V-Blank , games can now update tiles, colours, and registers without waiting for the entire frame to be drawn. In fact, the possibilities extend even further: since games can now modify S-PPU settings mid-frame, it becomes possible to activate different background modes at different stages within the same frame, unlocking new and original game designs!
That feature
Truth be told, I still haven't mentioned the most important characteristic of this console...
Rendered Background layer.
Allocated Background map.
Rendered frame on the screen.
The first quarter of scan-lines uses another mode to simulate distance, Mode 7 starts at the second quarter (this is possible thanks to HDMA).
Introducing Mode 7, yet another background mode - but this time, with a completely different way of working. While it can only render a single 8 bpp background layer, it provides the exclusive ability to apply the following affine transformations on that plane :
- Translation.
- Scaling.
- Rotation.
- Reflection.
- Shearing.
Mode 7 is controlled via a rotation matrix, which alters its parameters. Without delving into linear algebra, depending on the desired effect, the CPU must perform some trigonometric functions (sine and cosine) to populate the entries of this table accordingly. This is computationally expensive for the 65C816, even when using fixed-point precision. For this reason, with the 5A22, Ricoh integrated multiplication and division registers to offload some cycles.
By the way, you may notice that the list of transformations does not mention perspective, despite its presence in the example game, F-Zero. This effect is achieved by adjusting the rotation matrix at each HDMA call, creating a pseudo-3D effect in the process. This should give you an idea of just how versatile the S-PPU truly is!
Finally, due to the use of affine transformations, it is no longer beneficial to fetch adjacent pixels from VRAM. So, to maintain acceptable bandwidth, the memory map is restructured in a way that benefits the new pipeline. Thus, the first VRAM chip stores the Tilemap (where tiles are referenced), while the second stores the Tileset (where tiles are stored). Considering entries in both tables are 8 bits long, this setup allows the PPU 1 to retrieve references and tiles in a single cycle.
Generous circuits
Since Mode 7 requires additional computations, the PPU 1 incorporates dedicated circuitry to process the rotation matrix. Now, here is the interesting part: it also exposes the registers for developers to access when idle (in other words, when using Mode 0 to 6, or during V-Blank) .
The PPU 1's multiplier is both faster and more capable than the CPU's, as it accepts 16-bit numbers, both positive and negative (signed).
Reflecting on this 30 years later, I must say this concept is an earlier precursor to computer shaders.
More colour magic
Behind every rich frame is a flexible rendering pipeline. Well, if all the previous advancements weren't impressive enough, the S-PPU features a versatile colour blender that enables to customise how layers are merged. Unlike other sprite engines with fixed rendering steps, Nintendo's engineers exposed multiple parameters within the S-PPU's pipeline, enabling developers to alter how certain pixels of different layers interact to form the final frame.
This functionality is collectively known as Color Math , but it is also called 'Screen Addition/Subtraction' - despite also supporting division by two. In any case, this paved the way for realistic transparency, dynamic lighting, and other creative effects.
The lamp sways along with the light, such daunting effect is accomplished by altering the S-PPU's masking options.
The parrot follows you around with a torchlight, which can point to either direction and bounce. This plays very well with the overall atmosphere.
In essence, the process works as follows :
- Internally, the S-PPU houses two rendering pipelines: Main Screen and Sub Screen, where programmers can assign background layers and the sprite layer to each.
- The Sub Screen can also be filled with a solid colour instead of receiving layers.
- High-resolution modes (Mode 5 and 6) consume the Sub Screen's resources, preventing Color Math from working in those modes.
- The pixels of both screens can be masked using individual window parameters.
- The S-PPU separately merges the background layers within Main and Sub Screen, respecting the priority of each layer and window settings.
- Finally, the S-PPU lets programmers decide how to merge the content of Main Screen and Sub Screen. It can add or subtract the two screens, and then divide the result by two (achieving transparency effects).
- Division by two is computationally cheap in digital circuits, as it only requires shifting the value one position to the right.
In the second Donkey Kong Country example, Main Screen consists of a single white layer, while Sub Screen contains the rest of the scenery. However, the latter is encoded with inverted colours. At the last stage of the pipeline, the S-PPU applies subtraction and division, producing a correctly coloured frame with transparency effects and enhanced brightness - effectively simulating the torchlight.
Cause of frame drops
On a different topic - what causes games to lag? When the V-Blank interrupt is triggered to allow graphics updates, the game may still be executing heavy code, causing it to miss the V-Blank window. As a result, graphics cannot be updated until the next V-Blank call, and since the frame remains unchanged, this manifests as a drop in frame-rate .
Conversely, extensive processing during a V-Blank can block the S-PPU from outputting the video signal, as the bus remains occupied. This can lead to black lines appearing during a scan, though this effect is barely noticeable since the frames refresh 50 or 60 times per second.
A convenient video out
All of the aforementioned advancements would be meaningless unless the console could transmit its picture to the TV through a medium both can understand. With the Super Nintendo, the company debuted some sort of universal-but-proprietary connection called Multi Out, capable of carrying many types of signals at the same time, including Composite, S-Video and RGB .
Nintendo bundled a 'Multi Out-to-Composite' cable with the console, as composite video was pretty much the common denominator of TVs at the time.
In Europe, however, the SCART port was widely popular, particularly among set-top boxes and VCRs. A major advantage of SCART is its ability to support multiple signal types, allowing AV equipment to select the most optimal format without compatibility issues. As far as I know, only French consumers were offered an official SCART cable that took advantage of the RGB pins exposed on the Super Nintendo .
Consequently, Nintendo altered the pinout of its PAL consoles to comply with the SCART protocol, replacing the 'composite sync' pin with a 12-volt signal - which instructs the TV to use a 4:3 aspect ratio. Thus, while Multi Out is theoretically universal, RGB cables, if any, are region-specific.
I think the practical benefits of Multi Out have become more apparent in recent years, as it allows users to leverage the RGB output on their modern tellies without tampering with the console's internals. However, unlike Composite and S-Video, RGB requires an extra 'sync' signal. For this, cables can be wired up to capture the sync signal from Composite or S-Video - or for best results, use a dedicated sync line called 'composite sync'. Unfortunately, as noted earlier, the latter signal is exclusive to NTSC consoles.