« Dreamcast Architecture (index)

Dreamcast Architecture

Chapter 4: Graphics


Table of Contents

  1. Organising the content
  2. Architecture
  3. Construction
    1. Tile Accelerator
    2. PowerVR2 Core
  4. The big picture
  5. Gaining detail
  6. Video Modes

The GPU package is a custom-made chip called Holly running at 100 MHz. Unlike previous in-house designs, Sega partnered with VideoLogic (now known as Imagination Technologies) to provide them with a competitive 3D accelerator.

Image
The Holly chip (after removing the thermal pads) and the video encoder.

Inside Holly, we can find VideoLogic's exclusive graphics circuit: the PowerVR2 (also referred to as PowerVR Series2 and CLX2). It's based on their earlier PowerVR GPUs but specifically tailored for the Dreamcast.

Organising the content

8 MB of Video RAM (VRAM) are provided to store the materials that Holly needs to draw on the screen (e.g. textures, frame-buffers, commands, etc.) . The block is installed as four SDRAM chips using a 64-bit bus.

Image
Architecture of Holly.

This memory is only accessed by Holly; the CPU fills it by talking to Holly or the Direct Memory Access (DMA) unit.

Architecture

VideoLogic chose an alternative approach to the construction of their 3D engine called Tile-Based Deferred Rendering (TBDR).

Instead of rendering a whole frame at once, as traditional Immediate Mode Renderers (IMRs) do , TBDR divides the rendering area into multiple sections called 'tiles'. It then carries out the rendering process on each tile individually, and the results are combined to form the final frame .

Image
Sonic Adventure (1999).

This innovative design brings interesting advantages:

It's no surprise that Imagination took this efficient technology forward to build the Series 4 PowerVR cores, which powered a remarkable number of devices, including the first-generation iPhone, the Nokia N95, and the Dell Axim x51.

Construction

Let's take a look at the two main components of the Dreamcast's GPU :

Tile Accelerator

Image
Architecture of the Tile Accelerator.

Before the rendering process begins, a component known as the Tile Accelerator (TA) performs pre-processing. It starts by allocating several 32x32 tile bins into which the geometry will be rendered.

Then, the Tile Accelerator:

  1. Grabs the geometry data and drawing commands issued by the CPU.
  2. Converts this data into an 'internal' format.
  3. Distributes the geometry to each bin according to its coordinates, discarding any clipped geometry.
  4. Generates the Display Lists, which instruct the subsequent components on how and where to draw the geometry.

The resulting Display Lists are then interpreted by the 3D engine: The PowerVR2.

PowerVR2 Core

Image
Architecture of the PowerVR2 Core.

Here is where the graphics are brought to life. The Display Lists received from the TA tell the core to render the geometry of a single tile using an internal frame-buffer. The process is as follows:

  1. The Image Synthesis Processor (ISP) fetches the primitives (either triangles or quads) and performs Hidden-Surface Removal to remove unseen polygons. Then, after calculating its Z-buffers and stencil buffers, the data goes through Depth Testing to avoid rendering polygons that would appear behind others, and Stencil Tests to cull geometry that won't be visible if it lies behind a 2D polygon (also called Mask).
    • Notice how these tests are effectively carried out at the start of the pipeline. In contrast, previous consoles using late z-buffering discard the geometry at the end of the pipeline. The ISP approach prevents processing the geometry that will ultimately be discarded , thereby saving resources.
  2. The Texture and Shading Processor (TSP) applies colouring, shading, and multiple effects across the tile area.
    • Textures are not applied until the tile is exported, meaning that emerging overdraw (if any) will not reduce the fill rate.

Once the operation is complete, the rendered tile is written to the main frame-buffer in VRAM. This process is repeated until all tiles have been rendered. When the full frame is ready, the resulting frame-buffer is picked up by Holly and passed on to the Video encoder, which sends it through the standard video signal.

The big picture

Apart from the clear architectural difference, the Texture and Shading Processor comes with many capabilities that highlight the substantial leap this console makes over the old Saturn. Here are some notable examples:

Gaining detail

Holly can now draw roughly ten times more polygons than its predecessor. Here's a Before & After example that shows how model designs are no longer as constrained. I encourage you to take a closer look at them!

3D model 3D model 3D model
Interactive model available in the modern edition
Sonic R (1997) for the Saturn.
286 triangles (or 185 quadrilaterals).

3D model 3D model 3D model
Interactive model available in the modern edition
Sonic Adventure (1999) for the Dreamcast.
1001 triangles.

Video Modes

The video system was designed to support multiple types of screens and formats. Games typically render 640 x 480-pixel frame-buffers, or half the dimensions/colours if they need more performance. Both are NTSC-friendly resolutions, so European titles have the option of adding letterboxing to fit the PAL specification, or instead rendering 768 x 576-pixel frames (although I'm not aware of any game taking advantage of this).

On the other hand, the video encoder outputs from a unified socket that carries the following signal types:

Now, the Dreamcast can't encode all of these formats at the same time, so both the GPU and the audio processor contain a register named Image Mode. This coordinates which video and audio buses are activated to generate the requested output signal. The CPU detects the type of cable inserted by checking which 'select bits' on the video connector are active, then writes the appropriate values to the GPU. Finally, these values are forwarded to the audio processor.

Because VGA is strictly a progressive-scan format (as opposed to the traditional interlaced video), some compatibility issues arose with games designed exclusively for interlaced timings. Such games explicitly indicate in their code that they can't display on VGA, so the CPU displays an error screen until the user swaps the VGA cable with another type.


Previous: 3. CPU

Next: 5. Audio


Rodrigo Copetti © 2026 RSS Feed

Switch to modern edition

Home · Writings · Support · About author · About website