The Sega Dreamcast introduced many new features over its predecessor (the Saturn) to appeal to both game developers and console gamers. While this was Sega’s last attempt to conquer the console market, some of the technologies which were pioneered in the Dreamcast carried on and into future mainstream devices.
Unsurprisingly, Sega chose Hitachi again to develop their CPU. If you’ve been reading the previous article about the Sega Saturn then, lo and behold, I present you the next generation of SH processor: the SH-4 running at a whopping 200 MHz. So, what’s interesting about this CPU?
The common chores of a game console CPU include handling a game’s logic, running the enemy AI and keeping the GPU fed with instructions. In the Dreamcast, the SH-4 is also involved in the majority of the graphics pipeline, processing geometry data such as computing perspective transformations. As a result, it includes a 128-bit SIMD unit that can accelerate vector operations.
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 bits 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 control memory protection, alternating the memory map and circumventing the cache, respectively.
The programmer decides whether to use these features or not. Games for this system certainly don’t necessarily need memory protection and the MMU has to be manually enabled at boot.
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 dedicated RAM or a serial interface (which is also connected too), it will have to request the GPU and wait if necessary.
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 a 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’).
VideoLogic chose an alternative approach for 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 or ‘IMR’ do), TBDR divides the rendering area into multiple sections called ‘tiles’. Then, it carries out the rendering process on each tile individually and the result is combined to form the final frame.
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 an incredible number of devices, including the first generation of iPhone, the iPhone 3G, the Nokia N95 and the Dell Axim x51.
Let’s take a look at the two main components of the Dreamcast’s GPU:
Before the rendering process starts, a component known as the Tile Accelerator performs pre-processing. It starts by allocating several 32x32 tile bins into which the geometry will be rendered.
Then, the Tile Accelerator will:
These Display Lists are then interpreted by the 3D engine: The PowerVR2.
Here is where the graphics are brought into 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:
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. Once complete, the resulting frame-buffer is picked by the Video encoder and sent through the video signal.
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 notable examples:
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!
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 video/audio buses will be activated to generate the requested signal. The CPU detects the type of cable inserted (by checking which ‘select bits’ of the video connector are active) and writes the required values on the GPU. Finally, the values are 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 that were only designed for interlaced video. These explicitly state in their code that the game won’t display on VGA, so the CPU will block the game until the user swaps out the VGA cable for another type.
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:
To help with development, the official SDK included multiple sound drivers for different needs (sequencing, decoding, etc).
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:
Instead of programming an FM chip, the composers of Sonic Adventure produced their soundtrack in-house and then encoded it to ‘ADX’, a lossy format developed by CRI Middleware. Hence, it only uses two of the 64 PCM channels (stereo).
ADX compression enables the game to decode and stream the data from the GD-ROM to the Sound IC without running out of memory or bandwidth. The driver can be implemented in many ways, as there are multiple multiple approaches to balance the workload of the main CPU and ARM7.
Somehow, this chip is also responsible for providing a Real Time Clock (RTC) to the BIOS, it’s also connected to a clock battery to continue working without AC power.
2 MB of ‘System ROM’ stores a BIOS that bootstraps the game or a small shell when the console is switched on.
The BIOS also contains routines that games use to simplify I/O functions, like reading from the GD-ROM drive.
If there isn’t a valid game disc inserted, the console proceeds to boot the graphic shell.
The shell contains a simple graphical user interface to enable the user to perform basic but necessary tasks like:
Ever since the Dreamcast’s announcement, it was said that the console can run Windows CE: a stripped-down version of Windows designed for use on embedded devices. This is a bit misleading considering some users would expect to see a full Windows CE desktop environment running on their console.
In reality, the purpose of this ‘OS’ was very similar to what Nintendo did with the Nintendo 64: to provide programmers with a fair layer of abstraction to simplify certain operations.
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 and debugging. This included the use of Microsoft’s star IDE, Visual Studio, for development.
Some developers found this option very attractive. Since the audio-graphics framework included with CE was none other than DirectX 6, thousands of PC games of that era could, in theory, be easily ported to the Dreamcast…
However, the architectural differences between the Dreamcast and the conventional PC were too great to ignore. Also, 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).
In the end, ‘Windows CE for Dreamcast’ was just another SDK of choice for developers (it’s commonly referred to as Dragon SDK). Nonetheless, a considerable number of Dreamcast games ended up choosing Windows APIs and DirectX.
The GPU also includes another module for handling most of the I/O called System Bus. It provides the following interfaces:
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. This is Dreamcast hardware with enhanced I/O for development. It also came with a CD containing the official Katana SDK and tools to be installed on a Windows 98 PC.
In the case developers chose the Dragon SDK instead, DirectX 6.0 and Visual C++ 6.0 were also available to them.
Games are stored in GD-ROMs, which are just CD-ROM with a higher density of pits (reaching a gigabyte of capacity). The speed is 12x, which is not too shabby compared to Saturn’s 2x CD reader.
The Dreamcast 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 registered with a service using DreamKey, an extra disc that was bundled with some games. DreamKey provided a web browser to register an account. Initially, DreamKey came a pre-configured service depending on the region, but later revisions allowed users to alter its ISP settings to connect to any of them.
There was also a Dreamcast-branded keyboard and mouse available to buy, just in case the user fancied surfing the net PC-style.
Unfortunately, SegaNet and Dreamarena were discontinued two years after launch. Thus, games that exclusively relied on them became unusable, unless such services are emulated using extra tools (like the DreamPi, a Raspberry Pi image that replicates them with the help of servers maintained by a community of users).
Another innovative feature that the Dreamcast featured was the Visual Memory Unit or ‘VMU’. It is attached to the controller and, aside from serving as a memory card, is a fully-fledged device that includes:
The VMU has two modes of operation:
Using the proprietary GD-ROM format helped to inhibit the production of unauthorised copies of games (and running them on other consoles). Dreamcast games are also region-locked meaning that a console will refuse to run a game intended for a different region.
In practice, the anti-piracy measures were utterly useless due to Sega leaving a huge backdoor open: MIL-CD. Music Interactive Live-CD or ‘MIL-CD’ is a format created by Sega to extend an Audio-CD with interactive programs… and the Dreamcast is compatible with it.
Unauthorised commercial discs (cheat loaders, movie players, etc) disguised as MIL-CDs to run on the console without Sega’s approval. Later on, different hacking communities dissected this exploit and came up with a workaround to boot pirated games using CD-ROMs. This caused an unstoppable wave of ISOs to be released on the net.
Some problems surfaced afterwards: Although GD-ROMs can store a gigabyte of data, CD-ROMs can only fit ~700 MB, so how could ‘rippers’ shrink the bigger games to fit on a CD? By re-compressing music and graphics until it fits. They may even try to split it into two discs. After all, game data is not a single blob anymore (like on an old cartridge), but is now organised hierarchically into files and directories.
I hope you enjoyed reading the article. I 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!
This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But I ask that you reference it properly. Please take a look at the following citation guidelines:
## Academic styles For any referencing style, you can use the following information: - Title of article: Dreamcast Architecture - A Practical Analysis - Author: Rodrigo Copetti - URL: https://www.copetti.org/writings/consoles/dreamcast/ - Date of publication: 07 Oct 2019 - Last modified: 21 Jul 2021 For instance, using the IEEE style: R. Copetti, "Dreamcast Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://www.copetti.org/writings/consoles/dreamcast/. [Accessed: day- month- year]. and Harvard style: Copetti, R., 2019. Dreamcast Architecture - A Practical Analysis. [online] Copetti.org. Available at: https://www.copetti.org/writings/consoles/dreamcast/ [Accessed day month year]. ## Use in multimedia (Youtube, etc) I only ask that you include at least the author's name, title of article and URL of article, using any style of choice. You don't have to include all the information in the same place if it's not feasible. For instance, if you use the article's imagery in a Youtube video, you should state either the author's name or URL of article at the bottom of the image, and then include the complete reference in the video description. ## Appreciated additions If your work has been significantly influenced by any of this site's writings, I'd appreciate if you could dedicate an acknowledgement section, just like I do with the people/communities that helped me. This is of course optional and beyond the requirements of the CC license, but I think it's a nice detail that makes us, the random authors on the net, feel part of something bigger.
This article is part of the Architecture of Consoles series. If you found it interesting then please consider donating. Your contribution will be used to fund the purchase of tools and resources that will help me to improve the quality of existing articles and upcoming ones.
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)
Alternatively, you can help out by suggesting changes and/or adding translations.
It's always nice to keep a record of changes.
## 2021-30-04 - Improved 'Anti-Piracy' section - Added more info on sound drivers. - Fixed 'sources' structure. ## 2020-09-13 - General revamp with grammar fixes and other tweaks, thanks @dpt. ## 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!