The Dreamcast
Released on 29/11/1998 in Japan, 09/09/1999 in America and 14/10/1999 in Europe
Showing revision 'VA1'
While the official docs state that the system contains 128KB of flash memory, this motherboard happens to include a 256KB EEPROM chip for some reason instead
Battery and controller ports are found in a daughterboard called 'Front panel'
Important data buses are labelled with their width and speed.


Sega’s new console brought many features developers and users could appreciate. Whilst being their last attempt in the console market, some of the technologies debuted here carried on through future mainstream devices.


It comes without surprise that Hitachi was chosen again to develop their CPU, if you’ve been reading the previous article then… Lo and behold! I present you the next-gen SH processor called SH-4 running at a whopping 200 MHz.

So, what’s actually interesting about this new CPU? Well, we have the following:

Extra work

Apart from the common chores CPUs are tasked to do (handling the game’s logic, enemy’s AI, commanding the GPU, etc), the SH-4 will be also involved in the majority of the graphics pipeline by processing geometry data, such as conducting perspective transformations. As a result, it includes a 128-bit SIMD unit that accelerates operations with vectors.

Improving memory access

The CPU includes a dedicated Memory Management Unit or ‘MMU’ for virtual addressing, this is helpful since the physical memory address space of this CPU happens to be 29-bit wide. So with the help of four TLBs, programmers can use 32-bit addresses without hitting performance penalties.

Since only 29 bits are needed for addressing, the extra three bits are used for memory protection, alternating the memory map and circumventing cache, respectively.

It’s worth mentioning that this is up to the programmer to decide whether to use or not, games for this system certainly don’t need memory protection and the MMU has to be manually enabled at boot.

No UMA but…

While this system is not designed around the strict Unified Memory Architecture like a well-known competitor, it does delegate I/O access to the GPU.

That means that if the CPU has to fetch anything that’s beyond its own dedicated RAM or a serial interface which is also connected too, it will have to request the GPU (and wait if necessary).

Special queries

This CPU also features a unique functionality called Parallel I/O or ‘PIO’ that is used to manipulate multiple I/O locations at the same time. Sega wired up these pins so the CPU can manipulate the GPU’s video mode (more details about this later).


The GPU package is custom-made chip called Holly running at 100 MHz, it’s designed by VideoLogic (now known as Imagination Technologies) and manufactured by NEC. Holly’s 3D core happens to be Videologic’s PowerVR2 (also called ‘PowerVR Series2’ and ‘CLX2’).

Sonic Adventure (1999)

VideoLogic chose an alternative approach for the construction of their 3D engine called Tile-Based Deferred Rendering or ‘TBDR’, which instead of rendering a whole frame at once (like traditional Immediate Mode Renderers or ‘IMR’ do), it divides the rendering area into multiple sections called ‘tiles’ and carries out the rendering process on each tile individually, then the result is combined to draw the final frame.

This innovative design brings interesting advantages:

  • Can be greatly parallelised, which significantly reduces bandwidth and power usage.
  • Implements a clever solution to the visibility problem, consisting in automatically sorting the polygons from front to back and then performing z-tests at the first stages of the pipeline. The combination of these tasks not only solve the original problem, but it also prevents overdraw (rasterisation of hidden polygons) which wastes resources and degrade performance.

It’s no surprise that Imagination took this technology forward to build most of the smartphone’s GPUs since this approach proved to be very efficient.


Let’s take a look at the two main components of this GPU:

Tile Accelerator

Architecture of the Tile Accelerator

Before the whole rendering process starts, an extra component known as the Tile Accelerator does a bit of pre-processing first. It starts by allocating 32x32 tile bins where the geometry will be rendered at each bin respectively.

Then, the Tile Accelerator will:

  1. Grab the geometry data and drawing commands issued by the CPU (either using DMA or traditional transfers).
  2. Compile this data into an internal format.
  3. Distribute the geometry on each bin based on its coordinates. Clipped geometry will be discarded as well.
  4. Generate the resulting Display Lists.

These Display Lists will be interpreted by the 3D engine.

PowerVR2 Core

Architecture of the PowerVR2 Core

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

  1. The Image Synthesis Processor or ‘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 they are located behind a 2D polygon (also called Mask).
    • Notice how these tests are effectively carried out at the start of the pipeline. By contrast, previous consoles using z-buffers discarded the geometry at the end of the pipeline. The ISP’s approach prevents processing the geometry that will eventually be discarded, thereby saving resources.
  2. The Texture and Shading Processor or ‘TSP’ applies colouring and shading over the tile area. It also provides multiple effects (more details later on).

After the operation is completed, the rendered tile is written to the main frame-buffer in VRAM. This process is repeated until all tiles are finished, after that the resulting frame-buffer is picked by the Video encoder and sent through the video signal.

The big picture

Apart from the clear architectural difference, the Texture and Shading Processor comes with many capabilities that give one an idea of how distant this console is from the old Saturn. Here are a few:

Gaining detail

Holly can now draw ~10 times more polygons than its predecessor, here’s a Before & After example that shows how model designs are not that limited any more. Try to fiddle with them!

Sonic R (1997) for the Saturn
298 triangles
Sonic Adventure (1999) for the Dreamcast
1001 triangles

Video Modes

The video system was designed to support multiple types of screens and formats, thus the video encoder outputs to a single-shaped socket that supports the following type of signals:

Now, the Dreamcast can’t encode all of these at the same time, so the GPU and the Audio processor contain a register called Image Mode that coordinates which required video/audio buses will be activated in order to generate the requested signal. The CPU detects which type of cable is inserted (by checking which bits of the video connector are active) and writes the required values on the GPU which then will be forwarded to the Audio processor.

Since VGA is strictly a progressive type of signal (as opposed to the traditional interlaced), some compatibility issues arose with games which were only designed for interlaced video, these explicitly state in their code that won’t display on VGA, so the CPU will block the game until the user swaps out the VGA cable for another type.

Unified I/O Access

The GPU also includes another module for handling most of the I/O called System Bus. It provides the following interfaces:


The Audio functionality is handled by a custom chip called AICA made by Yamaha, it’s an improved version of the SCSP used in the Saturn and composed of four components:


We’ve come so far since the days of the Mega Drive/Genesis, in order to show how much progress was made in sound synthesis, here’s an example of two games, one for the Mega Drive and the other for the Dreamcast, that used the same composition:

Sonic 3D Blast (1996) for the Mega Drive
Sonic Adventure (1999) for the Dreamcast
There's only two channels since it's just a PCM stereo sample

Staying alive

Somehow this chip is also responsible for providing a Real Time Clock or ‘RTC’ to the BIOS, it’s also connected to a clock battery in order to continue working without AC power.

Operating System

During the console’s lifespan, there has been two different OS that could run on the Dreamcast:

Classic Shell

The 2 MB of ‘System ROM’ stores a BIOS that runs a small shell when the console is switched on.

Shell after booting without a disc

It contains a simple graphical user interface to allow the user to perform basic but necessary tasks like:

  • Start the game, if it hasn’t already.
  • Manipulate the save data stored in the VMU (more details about this device later!).
  • Play music, if there’s an Audio CD inserted.
  • Change some settings (Date, Time, Sound, etc).

Windows CE

Since the console was announced, it has been mentioned to run Windows CE (a stripped down version of Windows designed for handheld devices), although this can be a little deceiving because the user won’t actually see a PDA system on this console.

Windows CE logo stamped on the front of the case

In reality, the purpose of this system was very similar to what Nintendo did with their console: Provide programmers with a fair layer of abstraction in order to simplify certain operations.

In this case, Microsoft worked with Sega to bring Windows CE to the Dreamcast. The result was a subset of CE with the minimal components needed to provide graphics, audio, debugging and compatibility with software like Microsoft’s star IDE… Visual Studio.

Some developers found this a very attractive tool since the audio-graphics framework included with CE was no other than DirectX 6, thus thousands of PC games of that era could -in theory- be easily ported for the Dreamcast.

In reality, the architectural differences between the Dreamcast and the conventional PC were too great to ignore, in addition, embedding this system increased the game’s loading time (after all, the ‘OS’ had to be loaded from a disc) and Windows CE happened to eat a substantial part of resources from the Dreamcast (not surprisingly, PCs were already suffering from that).

At the end, Windows CE was just another choice for developers to embed in their game, nonetheless, the number of Dreamcast games written using Windows APIs & DirectX ended up being considerable.


Development was mainly done in C or C++: At first, C was the recommended choice since the available C++ compilers were initially very limited in functionality.

Sega also provided development hardware in the form of a PC-like tower called the Sega Katana Development Box, it’s still Dreamcast hardware with enhanced I/O for development. It also came with a CD containing the official Katana SDK that can be installed on a Windows PC.

In the case developers chose Windows CE as their main framework instead (by switching to Dragon SDK), they also had DirectX 6.0 and Visual C++ 6.0 available to make their games.


Games are stored in GD-ROMs, which are just CD-ROM with a higher density of pits (reaching 1 GB of capacity). The speed is 12x which is not too shabby compared to the Saturn’s 2x CD reader.

Online platform

Dreamcasts shipped with a modem module installed which games could use to ‘call’ a dial-up service for online gaming, Sega provided two services: SegaNet (used in America and Japan) and Dreamarena (the European counterpart).

Players had to first register with a service by using an extra disc that came with some games called DreamKey, it basically provided a web browser used to register an account. Initially, DreamKey came a pre-configured service depending on the region, later revisions allowed users to alter its ISP settings to connect to any of them.

There was also a Keyboard and Mouse available to buy just in case the user fancied surfing the internet like in a PC.

Unfortunately, SegaNet and Dreamarena were discontinued two years after launch, games that exclusively relied on them are unusable unless such services are emulated using extra tools (like the DreamPi, a Raspberry Pi image that replicates them with the help of some servers maintained by a community of users).

Interactive memory card

Another innovative feature that this console included was the Visual Memory Unit or ‘VMU’, it is attached to the controller and, apart from serving as a memory card, it’s a fully-fledged device that includes:

VMU detached from the controller
Controller without VMU attached
Controller with VMU attached
  • A Sanyo LC86K87: An 8-bit low power CPU.
  • A 32x48 Monochrome LCD with four additional icons: Commanded using 196 B of XRAM as frame-buffer.
  • Two serial connectors: One for IN and the other for OUT.
  • Six physical buttons: Used when the VMU is detached from the controller.
  • A 16 KB Mask-ROM: Stores the BIOS-IPL.
  • 64 KB of Flash: 32 KB for storing a single program (transferred from the console) and the other 32 KB for keeping Dreamcast’s saves.
  • 512 B of RAM: 256 B are reserved for the system, leaving only 256 B available for the program.

The VMU has two modes of operation:

Anti-Piracy & Homebrew

The usage of the proprietary GD-ROM helped to stop the ability of making unauthorised copies of games and running them on other consoles.

Games are also region-locked meaning that the console will refuse to run a game if it’s from a different region than the console.

Defeating it

In practice, the anti-piracy measures resulted to be utterly useless. This was due to Sega leaving a huge door opened: MIL-CD.

Music Interactive Live-CD or ‘MIL-CD’ is another format created by Sega that extended the Audio-CD format by adding an interactive program on it… and the Dreamcast is compatible with it.

Now, someone discovered that after managing to rip the contents of a GD-ROM and modifying its format to adhere to the MIL-CD, burning it on a conventional CD and putting in on the Dreamcast would just work. This let a unstoppable wave of burned discs and ISOs on the net.

Some problems surfed afterwards: Although GD-ROMs can store 1 GB of data, CD-ROMs can only fit ~700 MB, so how could ‘rippers’ fit big games on a CD? By compressing music and graphics until it fits, they may even try to split it in two discs. After all, inside discs there are just files and folders!

That’s all folks

A Dreamcast I had to get in order to write lots of stuff here
Not too bad for its age!

Hope you enjoyed reading the article, I’ve just finished writing it during the start of my final year at uni.

I’ll probably be very busy from now on, but I do enjoy writing these articles so hopefully you’ll get the next one in a few weeks!

Until next time!

Sources / Keep Reading




Operating System





This article is part of the Architecture of Consoles series. If you found it interesting please consider donating, your contribution will be used to get more tools and resources that will help to improve the quality of current articles and upcoming ones.

Donate with PayPal
Become a Patreon

A list of desirable tools and latest acquisitions for this article are tracked in here:

## Interesting hardware to get (ordered by priority)

- Nothing else, unless you got something in mind worth checking out

## Acquired tools used

- A Dreamcast console with controllers and VMUs (£40)
- A game (Sonic Adventure, £9)


Always nice to keep a record of changes.

## 2020-04-10

- Expanded Hidden-Surface Removal section.

## 2020-03-01

- More content about texture effects and audio processing.

## 2019-10-24

- Added some 3d models to fiddle with.

## 2019-10-09

- Correction + Additions regarding GPU transparency, SegaNet and the SDK, thanks /r/dreamcast!

## 2019-10-08

- Added SIMD core 

## 2019-10-07

- It's alive!

Rodrigo Copetti

Rodrigo Copetti

Hope you enjoyed the article! If you want to know more about the author tap here and if you'd like to support him tap here instead