Saturn Architecture
The Sega Saturn, released on 11/05/1995 in America and 08/07/1995 in Europe
Saturn Architecture
The Sega Saturn, released on 22/11/1994 in Japan
Showing 'VA8' revision which includes all components in a single board
Remaining RAM chips are fitted on the back

A quick introduction

Welcome to the 3D era! Well… sorta. Sega enjoyed quite a success with the Megadrive so there’s no reason to force developers to write 3D games right now.

Just in case developers want 3D, Sega adapted some bits of the hardware to enable polygon drawing as well, hopefully the result didn’t get out of hand!


CPU

The system has not one, but two Hitachi SH-2 CPUs running at ~28.63MHz each. They work in a master-slave configuration (one gives orders, the other waits for them) while sharing the same external bus.

Each SH-2 core features:

Having two CPUs doesn’t mean that it will work twice as fast, in practice it requires very complex programming to efficiently manage CPUs that share the same bus! (here is where cache comes very handy).

The console contains an additional coprocessor, the Saturn Control Unit which is composed of two modules:


Graphics

Before we dive into the details let us go over what had to change in order to bring the next generation of 3D graphics:

Sega’s offering

This console includes two 32-bit proprietary GPUs, each one serving different purposes while working concurrently:

VDP1

VDP1 architecture
VDP1 Architecture

The Video Display Processor 1 or ‘VDP1’ is a custom chip specialised in rendering polygons, it uses quadrilaterals as primitives which means that it can only compose models using 4-vertex polygons.

Textures are applied using an the following algorithms:

  1. Forward Texture Mapping to map the textures into each quad.
  2. Bilinear Approximations to correct unstable textures which are noticeable while moving the camera (called warping).

These textures are also cached in a 512 KB block in order to provide better fill-rates.

The chip also provides these selection of effects:

  • Two shading algorithms (Flat and Gouraud) for lighting.
  • Edge anti-aliasing to smooth out jagged edges.
  • Clipping to avoid rendering unseen polygons.
  • Transparency.

Two 256 KB frame-buffers are available to draw new scenes in the game without breaking the current one being displayed (double-buffering). When the secondary buffer is finished being drawn, it’s then copied to the primary one during special events (like V-Blank) so the user doesn’t notice any intermediate effects.

VDP2

VDP2 architecture
VDP2 Architecture

The Video Display Processor 2 or ‘VDP2’ specialises in rendering large (4096×4096 pixels) planes with the ability of applying transformations (rotation, scale and translation) on them. It can either draw up to four 2D planes and one 3D plane; or two 3D planes.

Its features were technically advanced at the time, algorithms used to accomplish this include:

  • The use of classic tile-maps.
  • Perspective transformations to obtain 3D effects.
  • Multi-texturing to map more than one texture per polygon.
  • Bump-mapping to simulate bumps on the plane’s surface without spending extra polygons.

This chip also contains 4 KB of CRAM allowing to display up to 16.7 millions of colours, the VDP1 is also allowed to access it. The VDP2’s frame is generated by first mixing the VDP1’s frame-buffer with its own ones.

Technically, the VDP2 is also capable of drawing 3D polygons like the VDP1, but since it lacks any shading capabilities it’s conveniently used for backgrounds.


Defining the problem

As you can see the architecture of the graphics sub-system is quite complex, so it’s interpreted differently depending on the needs:

As a powerful 2D console

The capabilities of the Saturn for drawing 2D scenes were huge compared to the MegaDrive or SNES, although they weren’t the main selling point of this console.

Sprites

Sprites
VDP1/Sprites plane
Mega Man X4 (1997)

In this case the VDP1 is tasked to draw plain individual quadrilaterals that are filled with textures (one per polygon), this is how sprites are generated.

Backgrounds

VDP2/Background planes
Mega Man X4 (1997)

The VDP2 is then required to draw multiple background planes that are finally mixed together in a fully coloured scene.

Some functions from the VDP2 can be exploited to create more realistic scenes, such as scaling to simulate a heat wave (see ‘2D plane 2’).

Result

Result
Mixed planes (Tada!)
Mega Man X4 (1997)

Not much mystery here, the VDP2 is tasked with the last step of mixing all frame-buffers and letting the video encoder take it from there.


As a challenging 3D console

Here’s where the Saturn shined and struggled at the same time. While this console had eight processors to take advantage from, it all came down to:

For this reason most games ended up dramatically ranging in quality since each studio came up with their own and unique solution, the possible permutations were almost infinite!

Models

3D Models
3D models of characters without textures or background
Notice the primitives used to build the models
Virtua Fighter Remix (1995)

So far we’ve been using single quadrilaterals to form sprites or background layers. But what if we group multiple primitives to form a more complex figure? This is how 3D models come to fruition.

In a nutshell, the CPU is tasked to formulate a 3D world, then both VDPs will be commanded to project this world into a 2D space.

Textures

3D Scene
Rendered scene with 3D models and backgrounds
Virtua Fighter Remix (1995)

The VDPs compose a 2D space and apply their sprite-based algorithms to stamp textures and effects.

Which chip is ‘in charge’ varies between each game, some prioritised the VDP1 to draw the closest polygons and left the VDP2 to process distant scenery, others found interesting workarounds to task the VDP2 to draw closer polygons (off-loading the amount of geometry fed into the VDP1). The challenge here is to design an efficient pipeline that can display impressive graphics while keeping an acceptable frame-rate.


The new designs

These are some examples of characters that were re-designed for this console, the models are interactive so do try to fiddle with them!

3D model
Sonic in Sonic R (1997)
298 triangles
3D model
Tails in Sonic R (1997)
425 triangles

The transparency issue

The Sega Saturn is capable of drawing half-transparent graphics, however both VDPs aren’t as coordinated as one would expect, so this effect will not work on all textures. As a workaround, games can use use meshes to simulate half-transparency (which, displayed on a composite video TV, would make no difference), however this can’t be applied for all cases. At the end, some games had no option but to skip transparency while others found ingenious fixes. Take a look at these two cases:

Sega's Daytona (1993)
Traveller's Tales' Sonic R (1997)

Apart from my terrible playing, you’ll notice that the background of the first game pops out of nowhere where as the second game accomplished a fading effect. Traveller’s Tales found a workaround by changing the mix ratio’s registers on the VDP2 (used for defining the texture’s alpha) combined with switching the lighting levels as the character gets closer.


Audio

The sound subsystem consists in several components:


Games

The console starts by booting from the IPL (initial program loading) ROM which initialises the hardware and displays the splash screen. Then the game is loaded from the 2x CD-ROM reader, its medium (CD) has a capacity of 680 MB of data.

Development

Sega initially didn’t provide useful software libraries and development tools, so the only way to achieve good performance was through pure assembly. Games are written in a mix of C and various assemblies targeting individual components.

I/O

Peripherals are handled by the SMPC (System Management & Peripheral Control), a micro-controller that also provides a real-time clock and allows the SH-2 to program them.

Expansion

The cartridge slot is used to provide storage (save data) or extra RAM. Another expansion slot is found near the CD Reader, this one expects a ‘Video CD Card’ that, as the name suggests, enables to play Video CD.


Copy protection

Copy protection on CDs is applied by burning special data out of reach from conventional burners, the Saturn CD reader refuses to read the disc if the out-of-reach data is not found. This reader also has a custom SH-1 processor that interfaces with the rest of the system using encrypted communication. It’s worth mentioning that Saturn CDs don’t have any reading protection, you can actually read them with a PC.

One way of disabling the copy protection was by installing mod-chips that could trick the CD reader. Another method to bypass the protection without depending on the CD driver was published in 2016 (almost 20 years later) by exploiting the fact that the Video CD add-on can inject code to the CD subsystem (bypassing the CD reader altogether), this finally allowed load custom code without depending on the ageing reader.


Sources / Keep Reading

General

CPU

Graphics

Copy protection

Photography


Contributing

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.

Paypal

Changelog

## 2019-10-30

- Added 3d models.

## 2019-09-17

- Better wording.

## 2019-09-17

- Added a quick introduction.

## 2019-08-27

- Corrected some explanations.

## 2019-08-09

- Improved wording.

## 2019-08-03

- Ready for publication.

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

rss facebook twitter reddit