Sega Saturn Architecture

Architecture of Consoles: A Practical Analysis, Volume 5

Rodrigo Copetti

Published by Rodrigo Copetti, 2019.

While every precaution has been taken in the preparation of this book, the publisher assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

SEGA SATURN ARCHITECTURE

First edition. August 3, 2019.

Copyright © 2019 Rodrigo Copetti.

ISBN: 979-8201361051

Written by Rodrigo Copetti.

10 9 8 7 6 5 4 3 2 1

Also by Rodrigo Copetti

Architecture of Consoles: A Practical Analysis

NES Architecture

Game Boy Architecture

Mega Drive Architecture

SNES Architecture

Sega Saturn Architecture

PlayStation Architecture

Game Boy Advance Architecture

Nintendo 64 Architecture

Dreamcast Architecture

GameCube Architecture

Wii Architecture

PlayStation 2 Architecture

Xbox Architecture

Nintendo DS Architecture

Master System Architecture

PC Engine / TurboGrafx-16 Architecture

Virtual Boy Architecture

PSP Architecture

PlayStation 3 Architecture

Xbox 360 Architecture

Wii U Architecture

Sega Saturn Architecture

What can you do with 8 processors?

Rodrigo Copetti

2019-08-03

© 2023 Rodrigo Copetti, CC BY-NC 4.0

1 About this edition

This edition originates from the article initially published on my personal website, it’s been re-styled to take advantage of the capabilities of PDF/eBook documents.

While identical content-wise, interactive widgets have been simplified to work with a static environment - in other words, anything that physical pages allow us, though these will offer a link to the original article in case the reader wants to try the ‘full version’. Please keep this in mind when you see references to interactivity throughout the writings.

As always, the original manuscript of the articles is available on Github to enable readers to report mistakes or propose changes. There’s also a supporting reading list available to help understand the series. The author also accepts donations to help improve the quality of current articles and upcoming ones.

1.1 Open to feedback

Last but not least, for any comments and/or issues regarding this edition of the article, please get in touch using the links provided on the About page.

2 A quick introduction

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

Just in case developers want the extra dimension, Sega adapted some bits of the hardware to enable polygon drawing as well. Hopefully, the result didn’t get out of hand!

3 Suporting Imagery

3.1 Models

Figure 3.1: The Sega Saturn, released on 22/11/1994 in Japan [1]

Figure 3.2: The Sega Saturn, released on 11/05/1995 in America and 08/07/1995 in Europe [1]

3.2 Motherboard

Figure 3.3: Motherboard. Showing ‘VA8’ revision which includes all components in a single board. Remaining RAM chips are fitted on the back [1]

Figure 3.4: Motherboard with important parts labelled.

3.3 Diagram

Figure 3.5: Main architecture diagram.

4 CPU

Just like its close competitors drowned with options during the RISC fever, Sega had to go through all the conundrums of choosing a vendor that could bring up the next generation of games (including those with ‘3D’ capabilities). In the end, the company chose a fresh CPU whose creator was desperately looking for an adopter, the Hitachi SuperH or ‘SH’.

Hitachi’s new creation implemented modern arts such as a RISC instruction set and a pipelined data path, however, Sega wasn’t satisfied by the final product, especially due to the small 16-bit multiplier. Thus, Hitachi synthesised a second revision with a larger multiplier unit and other requirements on Sega’s checklist [2], leading to a new CPU called SH-2.

Even so, Sega couldn’t stand still after hearing what choice of CPU its competitors went for. So, they asked Hitachi to step up the clock frequency of the SH-2 - an impossible task once the chip is already out for manufacturing. Luckily, Hitachi had another trick up in their sleeve, multiprocessing. During the research phase of the SH, the team added minimal circuitry to allow the SH to work with other SHs within the same system at the same time. Upon hearing that, Sega decided on a two-chip configuration for the Sega Saturn. And the rest is history.

4.1 The final product

Having explained the origins, let’s take a look at the shipped product.

This console has not one but two Hitachi SH-2 CPUs running at ~28.63 MHz each [3]. While both physically identical, they are placed in a master-slave state, where the first one may send commands to the second one. This can achieve some degree of parallelism, albeit both sharing the same external bus [4] (which can lead to congestion).

These processors are part of the Hitachi SH7600 brand, a series designed for embedded systems featuring [5]:

SuperH ISA: A special 32-bit RISC instruction set where instructions are 16-bit long. Not only does this design reduce the size of the programs, but since the CPU fetches instructions in 32-bit batches, two instructions can be retrieved in one cycle.

The speciality of compressing instructions to take out half the size was carried on by ARM with Thumb.

Five-stage pipeline: Execution of instructions is divided into five steps or stages. The CPU will queue up to five instructions where each one is allocated in one stage. This allows taking advantage of all the CPU’s resources without idling while also incrementing the number of instructions executed per unit of time.

One multiplication unit: Speeds up multiplication operations with 64-bit/32-bit integers.

32-bit data bus: The external bus is shared across the two CPUs.

4 KB cache: Stores a small number of instructions and data previously fetched from memory to speed up future reads.

The specific CPU model selected for this console, the ‘SH7604’ or just ‘SH-2’, contain the following additions:

One division unit: Speeds up division operations with 64-bit/32-bit integers.

Internal DMA controller: Transfers data from memory independently (without the intervention of the CPU).

Please note that having two CPUs doesn’t mean that games will work twice as fast! In practice, however, this requires very complex programming to efficiently manage CPUs that share the same bus. Cache also plays a critical part in this occasion.

4.2 A divided choice of memory

The Sega Saturn contains a total of 2 MB of RAM for general purpose usage called Work RAM (WRAM). Now, these two megs are split between two very different blocks:

The first one provides 1 MB of SDRAM and due to its fast access rates, this block is also called ‘WRAM-H’.

The other block contains the other megabyte, but it’s named ‘WRAM-L’ since it uses DRAM instead, resulting in lower rates.

4.3 Another processor

If the two SH-2 CPUs weren’t enough, the console contains an additional coprocessor, the Saturn Control Unit or ‘SCU’ which is composed of two modules [6]:

A DMA controller: Arbitrates access to WRAM across the three main buses without the intervention of the CPUs.

A DSP: Used as a fixed-point ‘geometry unit’. Compared to the SH-2, it does matrix/vectors calculations such as 3D transformations and lighting faster. However, it runs at half-speed and its instruction set is more complex. Moreover, it relies on the SH-2’s WRAM to fetch and store data (using the DMA).

On the bright side, the SCU comes with 32 KB of SRAM for local use. On the bad side, the SCU can’t access WRAM-L.

5 Graphics

Since the Saturn is the first ‘3D console’ reviewed for this series, let us first go over the fundamental design changes that made way to the new generation of 3D graphics:

GPU now relies on a frame-buffer: Graphics are no longer required to be rendered on-the-fly. Instead, the GPU reserves a portion of VRAM to draw a bitmap with all the computed geometry requested by the CPU, and then a video encoder picks up that region and outputs it through the video signal.

Consequently, having this reserved ‘working space’ allows the GPU to continue manipulating the bitmap even after finishing rendering the scene, so the CPU may now offload some exhaustive tasks such as lighting and anti-aliasing to the GPU. Here is when the term graphics pipeline starts to gain momentum.

More VRAM required: The use of a frame buffer implies an increment of memory requirements (which is not a big issue anymore), the amount of RAM required for a frame buffer is proportional to the dimension of the screen and the number of colours used. As an example, with 600 KB of VRAM we can contain a frame buffer of 640x480 pixels wide with 32k colours per pixel (16 bpp).

Additionally, programmers are free to organise their VRAM usage: Not every single bit has to be allocated for the frame buffer, so why don’t we also use it to cache textures, render other frame-buffers concurrently and add colour lookup tables to speed things up?

CPU incorporates vector operations: A GPU with 3D capabilities would be incomplete without a proper CPU capable of feeding the required geometry. For that reason, next-gen CPUs include a form of specialised instructions that accelerates vector calculations, these are known as Single instruction multiple data or ‘SIMD’ extension.

In the case of the Saturn, vector operations are accelerated by the Saturn Control Unit (not by the CPUs).

5.1 Sega’s offering

This console includes two proprietary GPUs, each one serving different purposes while working concurrently. Some may argue that the new GPUs are an evolution of the classic VDP, while others may say it’s a complete redesign… I think it’s a bit of both.

Having said that, let’s take a look at the two chips.

5.1.1 VDP1

Figure 5.1: VDP1 Architecture.

The Video Display Processor 1 (VDP1) is a chip that draws sprites with geometric transformations [7]. The results are written onto a frame buffer, which is in turn streamed to the VDP2 for display.

This chip is programmed by sending ‘drawing commands’ to it. So, programmers are provided with 512 KB of dedicated RAM to store these drawing commands and the required materials (textures/tiles, colour lookup tables, etc).

Consequently, the VDP1 is designed to use quadrilaterals as primitives, which means that it can only compose models using 4-vertex polygons (sprites). The chip applies Forward Texture Mapping to connect texture points onto the quadrilateral, in that direction. It doesn’t come with any filtering/interpolation technique, so the calculations are subject to aliasing.

The VDP1 also provides this selection of effects:

Two shading algorithms (Flat and Gouraud) for lighting.

Anti-aliasing: In this case, it duplicates pixels to cover gaps during mapping.

Clipping to discard polygons outside the camera’s viewport.

Transparency to blend two non-opaque bitmaps.

Two 256 KB frame buffer chips are available to concurrently draw new scenes of the game without breaking the current one being displayed. When the secondary buffer is finished being drawn, the VDP1 starts broadcasting the latter instead (page-flipping), and the cycle continues.

5.1.2 VDP2

Figure 5.2: VDP2 Architecture.

The Video Display Processor 2 (VDP2) specialises in rendering large (4096×4096 pixels) planes with transformations (rotation, scale and translation) applied on them [8].

More importantly, the VDP2’s renders on-the-fly (without a frame-buffer) like previous tile-based engines. It can display up to 16.7 million colours (24-bit). This chip is also responsible for displaying the VDP1’s buffer, which can also be transformed and/or mixed with the VDP2’s layers. The VDP2’s ‘frame’ is composed of up to four 2D planes and one 3D plane; or two 3D planes.

This chip relies on tile-maps to compose planes and performs perspective correction for 3D texture mapping, this is a more sophisticated approach which takes into account the depth value to compute rotations.

Effects available include multi-texturing (mapping more than one texture per polygon) and shadowing. With the latter, after the VDP2 receives the sprites generated by the VDP1, it can reduce their brightness and blend them with half-transparency. Nonetheless, the VDP2 only receives a sprite stream from the VDP1 (in pace with the CRT beam) so this function tends to be tricky to encode and operate.

This chip also houses 4 KB of Colour RAM (CRAM) which is used to translate VDP1’s custom colour values (index colours) into 24-bit RGB colours.

Finally, even though the VDP2 is limited to two 3D planes, nothing prevents the CPU from using its VRAM as frame-buffer area to draw additional 2D or 3D graphics in software.

I recommend checking out the sources (at the end of the article) if this section got your attention, since the VDPs have a lot more quirks that are beyond the scope of this article.

5.2 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:

5.3 As a powerful 2D console

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

5.3.1 Sprites

Figure 5.3: Mega Man X4 (1997). VDP1’s Sprites plane.

In this case, the VDP1 is tasked with plotting traditional sprites without any 3D distortion applied.

The CPU sets up the VDP1 by writing over its registers and filling its VRAM with commands and tiles. The process can also be accelerated thanks to the DMA controller.

5.3.2 Backgrounds

Figure 5.4: 2D plane 1.

Figure 5.5: 2D plane 2.

Figure 5.6: 2D plane 3.

Figures: Mega Man X4 (1997). VDP2’s Background planes.

The VDP2 is then instructed to draw background planes. These, along with the sprite layer, are automatically mixed to form a fully coloured scene.

The commanding part is fundamentally similar to the VDP1: Programmers got registers and VRAM to set up accordingly.

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

5.3.3 Result

Figure 5.7: Mega Man X4 (1997). Mixed planes ( Tada! ).

Not much mystery here, the VDP2 is responsible for the last step of sending the processed signal to the video encoder.

The VDP2 operates in sync with the CRT beam, meaning that its computations correspond to the pixels that will be displayed on the next scan line.

5.4 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 of, it all came down to:

Whether programmers would be able to master most of the console’s features during a small time frame (remember the console’s commercial lifespan would be over once its successor is released, or even announced).

Whether their game would be shipped at a reasonable date.

For this reason, most games ended up dramatically ranging in quality since each studio came up with a unique solution.

5.4.1 3D modelling

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

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

To put it in simple terms, classic 2D consoles like the Super Nintendo arranges their graphics (backgrounds and sprites) in quasi-rectangular areas. In some cases, such as with Mode 7, programmers can supply a rotation matrix to apply transformations over some of these areas. The Saturn, by contrast, allows defining 4-point quadrilaterals with arbitrary angles between their edges (Sega calls them ‘distorted sprites’). Then, the VDPs’ texture mapping capabilities paint the quadrilateral’s area with a texture, the latter is scaled to conform to the polygon’s shape.

In terms of operations needed with a 3D game, the CPUs and SCU are assigned to formulating a 3D world and project it in a 2D space. Then, both VDPs are commanded to render it, apply effects and finally broadcast it on TV.

5.4.2 Pixel processing

Figure 5.9: Virtua Fighter Remix (1995). Rendered scene with 3D models and backgrounds.

Either VDP can draw this new (projected) 3D space and stamp textures and effects. Now, 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 (thereby off-loading the amount of geometry fed into the VDP1). The challenge consists in designing an efficient engine that could display impressive graphics while keeping an acceptable frame rate.

5.5 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!

Figure 5.10: Sonic in Sonic R (1997). 185 quadrilaterals. Interactive viewer available in the website edition.

Figure 5.11: Tails in Sonic R (1997). 254 quadrilaterals. Interactive viewer available in the website edition.

While the Saturn is only able to draw quadrangles, you’ll soon notice that these models exhibit two triangles instead of a single quadrangle in ‘Wireframe’ mode. This is because the format used to encode this model (glTF, an open standard for modern 3D modelling), so your modern device can render it, doesn’t support quadrangles at the time of this writing. So, I recommend switching to ‘Surface’ mode to observe the quads.

In some way, this tells you how the current graphics technology can struggle to reproduce their ~30-year-old predecessors!

5.6 An introduction to the visibility problem

When 3D polygons are projected onto a 2D space, it is crucial to determine which polygons are visible from the camera’s position and which are hidden behind [9]. Otherwise, models are not drawn correctly, effects like transparency appear ‘broken’ and ultimately, hardware resources are wasted. This process is widely known as Visible surface determination or ‘VSD’ and it’s a fundamental problem in the world of computer graphics. There are multiple papers published that describe algorithms that tackle this at different stages of the graphics pipeline. Some of them give very accurate results, while others trade precision for better performance.

Now, unlike academic/professional equipment, consumer hardware is incredibly limited, so the choice of algorithm is narrowed down to just a few… or none whatsoever.

Figure 5.12: Project Z-Treme (2019, Homebrew) [10] . This engine ditched Z-sort in favour of a binary space partitioning (BSP) approach, fixing the glitches.

The Sega Saturn approach is what I consider a ‘semi-solved’ case. The VDP1 doesn’t implement any VSD function: You either feed the geometry in the correct order or you get a mess. However, Sega provided a graphics library called ‘SGL’ that implemented a solution called Z-sort or Painter’s algorithm [11] which performs polygon sorting by software.

Essentially, SGL allocates a buffer to sort the polygons based on the distance from the camera (from furthest to nearest), then, issues the display commands to the VDP1 in that order.

One of the issues of Z-sort with 3D spaces is that its distance value (Z-order) is approximated, so graphic glitches may still appear. For this, programmers can skip SGL in favour of implementing their own algorithm.

In later articles, you will see alternative approaches. Some still rely on software, while others are accelerated by hardware.

5.7 The transparency issue

The Sega Saturn is capable of drawing half-transparent graphics, in other words, mixing overlapping layers of colours (blending) to give the illusion we can see through them. Unfortunately, both VDPs aren’t as coordinated as one would expect, so this effect will not work properly when these layers are found in different VDPs.

As a workaround, games can activate the ‘mesh’ property on a texture. With ‘meshed’ textures, the VDP1 sets the odd X/Y texture coordinates as ‘transparent’ (empty). Making it possible to blend other layers using the transparent pixels. Curiously enough, the mesh would appear blurred if the console was connected to the TV using the composite video signal (which was pretty much the standard back then, aside from RF) resulting in an accidental but effective way to accomplish half-transparency [12].

As you may suspect, this just wasn’t viable for some games, so in the end, these had no option but to ditch half-transparency altogether… Although some studios found ingenious fixes, take a look at these two cases:

Figure 5.13: Sega’s Daytona (1993). Interactive viewer available in the website edition.

Figure 5.14: Traveller’s Tales’ Sonic R (1997). Interactive viewer available in the website edition.

Figures: Both games command the VDP1 to draw foreground objects and background scenery. In turn, the VDP2 renders the landscape image far away and the stats in front of the 3D models. Consequently, VDP1 models with half-transparency won’t refract the VDP2’s landscape as the VDP1 is not aware of the VDP2’s frame buffers.

Apart from my terrible gameplay, you’ll notice that the background of the first game pops out of nowhere (no half-transparency) whereas the second game not only accomplished half-transparency but also a fading effect: Traveller’s Tales found a workaround by changing the ‘mix ratio’ registers of the VDP2 (used for defining the texture’s alpha) combined with switching the lighting levels as the character gets closer [13].

6 Audio

The sound subsystem consists of several parts [14]:

Motorola 68EC000: Controls the other components and interfaces with the main CPUs. It runs a sound driver to operate the neighbour components.

Saturn Custom Sound Processor (SCSP): Also referred to as Yamaha YMF292, it’s composed of two modules:

A multi-function sound generator: Processes up to 32 channels with PCM samples (up to 16-bit with 44.1 kHz, a.k.a ‘CD quality’) or FM channels. In the case of the latter, a number of channels are reserved for operators.

A DSP: Applies effects like echo, reverb and chorus. The docs also mention ‘filters’ but I don’t know if it means envelope or frequency filter (i.e. low pass, etc).

512 KB of RAM: Stores the driver, audio data (i.e. PCM samples) and it’s also a working area for the DSP.

6.1 The opportunity

The new audio capabilities mean that studios can finally record/produce soundtracks in-house and then bundle them in the game without having to re-arrange it (as it happened with limited sequencers or chips with strict synthesis methods).

This has been possible thanks to a combination of many factors:

The new storage medium for games (CD-ROM) enables developers to store large soundtracks.

The audio endpoint receives and mixes PCM data with acceptable quality.

The audio subsystem provides enough power and bandwidth to stream PCM data in some compressed form, and then decode it on-the-fly.

7 Operating System

Once the user powers on the console, the first component that starts up is the System Management & Peripheral Control (SMPC), a 4-bit microcontroller that takes care of initialising the neighbouring chips (such as switching on two SH-2s and setting them in a ‘master-slave’ configuration) [15].

Figure 7.1: Japanese version.

Figure 7.2: European and American versions.

Figures: Logo displayed after splash animation finishes.

Afterwards, the master SH-2’s reset vector is set to 0x00000000 [16], which points to an internal ROM containing the Initial Program Loader (IPL). This program performs the following functions [17]:

Finish initialising the hardware.

If there’s a cartridge inserted and it includes a program, continue booting from there.

If the ‘Video CD’ card is inserted, boot it.

If there’s a disc inserted, check that it’s genuine.

While at it, it displays the splash screen animation.

If the disc is genuine, boot the game.

If the disc is not genuine or there’s no disc inserted, run the shell.

7.1 Interactive shell

Alternatively to playing games, the Saturn included a music player called ‘Multiplayer’, from which a save manager can be opened.

Figure 7.3: Interactive shell called ‘Multiplayer’ or ‘Audio CD Control Panel’ .

Figure 7.4: Memory Manager. Moves saves between the cartridge and internal memory.

If a Video CD card is inserted, the player can reproduce MPEG video decoded from the card itself.

7.2 No BIOS?

Unlike the PlayStation whose ROM chip bundled a BIOS, which in turn exposed APIs for programmers to use. The Saturn’s ROM is often called ‘IPL’ presumably since its main job is to bootstrap the game and run the shell. However, the latter still stores some routines (called services) to manipulate the hardware (such as managing save data and power control). It even implements a ‘semaphore’! (used to synchronise operations that involve multiple processors at the same time). Hence, that part of the ROM is called System program.

8 Games

Official Sega Saturn games are loaded from the 2x CD-ROM reader. Its medium, the compact disc (CD), has a capacity of 680 MB and Sega Saturn games follow the ISO 9660 standard for storing data [18]. Additionally, many games store audio tracks next to the data tracks for streaming uncompressed audio while executing the game.

8.1 The Compact Disc (CD)

The CD is an optical medium where information is stored by engraving pits and lands on its polycarbonate surface [19]. Then, an infrared light is beamed from the reader and the reflection produced on the CD’s surface is used to read the information back.

The process of converting digital information (ones and zeroes) into pits and lands and vice versa is not simple by any means, especially since CDs must be robust enough to sustain day-to-day damage and intensive use; and reliable enough to store any kind of information without fear of data loss. Hence, as part of its specification, data is encoded using the Non-Return-to-Zero inverted (NRZi) model, meaning that the bitstream will be all zeroes until a land-to-pit or pit-to-land change is detected, at which a 1 will be appended instead.

This design works well until the reader encounters a sequence of ones (continuous pit and land changes) or long sequences of zeroes (constant pits or lands), at which the sensor will struggle to detect or keep synchronised, respectively. Thus, an additional model called Eight-to-Fourteen (ETF) modulation is applied. With this, a handful of zeroes are padded in-between the encodings, these help the sensor during the reading process.

On top of all this, further mechanisms of error detection may be added, although these are beyond the scope of this article. If you are interested in learning more, you can check out a slide presentation from RWTH Aachen University [19].

8.2 Development

At first, Sega didn’t provide complete software libraries and development tools (in fact, the initial documentation was inaccurate) so the only way to achieve good performance was through harsh assembly.

Later on, Sega released complete SDKs, hardware kits and some libraries to ease I/O and graphics operations. Overall, games are written in a mix of C and various assemblies targeting individual components.

8.3 I/O

Peripheral management and real-time clock are also provided by the aforementioned System Management & Peripheral Control (SMPC). The SMPC is controlled with commands sent by the SH-2s.

8.4 Expansion methods

This console bundles a considerable number of external connectors and interfaces that only received a handful of uses, at most.

Behind the drive there’s a cartridge slot officially used for additional storage (save data) or extra RAM. In Japan and the United Stated, a modem was also offered to provide online functionality.

At the back of the console, there’s a slot for a Video CD Card that performs MPEG decompression for programs/games that support it.

Finally, there’s a mysterious socket at the back of the console called Communication Connector. Sega didn’t publish any documentation for developers, but after some reverse engineering efforts, people discovered that it’s connected to the SCSP’s MIDI pins and the two SH-2’s serial interface (SCI) [20]. In any case, Sega released a Floppy drive that relied on this interface.

9 Anti-Piracy & Homebrew

In response to the easiness of cloning a CD, Saturn added a copy protection system (along with region locking) to control the distribution of games.

Copy protection on CDs is applied by burning special data (called ‘system area’) out of reach from conventional burners, the Saturn refuses to boot the disc as a ‘game disc’ if the out-of-reach data is not found or it’s invalid. The disc reader also contains a custom SH-1 processor that interfaces with the rest of the console using obscured protocols.

It’s worth mentioning that since Saturn CDs follow the ISO9660 (a standard file system for CD data), PCs can read the game disc without problems (but, of course, they can’t execute the game unless they use an emulator).

9.1 Defeat

First of all, the classic method used for disabling the copy protection consisted in installing a mod-chip that could trick the CD reader when a burned disc is inserted. There was also a ‘swap trick’ that consisted in hot-swapping a genuine disc with a burned one just after the protection checks passed… with the risk of damaging the drive!

After the turn of the century, alternative but more sophisticated methods used for running unauthorised code were discovered, for instance:

An exploit in the copy protection mechanism was found and it allowed to boot up any disc game without going through the copy protection checks. This was subsequently in the form of a cartridge called pseudosaturn [21]. Due to the use of the cartridge medium, Action Replay cartridges are often re-flashed with pseudosaturn (though the flasher also needs to be bootstrapped somehow, most commonly through the swap trick).

This method is still being used as of 2022, although a new fork of pseudosaturn named ‘Pseudo Saturn Kai’ is installed instead.

Another method was reported in 2016 (almost 20 years later) by exploiting the fact that the Video CD add-on can inject unencrypted code to the CD subsystem (bypassing the CD reader altogether). This finally allowed users to load Homebrew independently of the ageing drive. The Video CD exploit is commercially distributed in a product called ‘Satiator’ (I’m not sponsored, by the way).

Finally, there’s another commercial alternative that replaces the CD reader with an SD or SATA adapter. The Saturn still thinks it’s reading from a CD, but the ‘CD’ is being emulated by the adapter, which is in turn reading from a disc image [22]. These products are called Optical Drive Emulators (ODE).

10 That’s all folks

Figure 10.1: A Japanese Saturn I acquired to get more material for this article. While the games look fine, it was thanks to the Saturn’s enormous Homebrew library that I was able to understand the real capabilities of this console.

11 Support

If you enjoyed what you read and would like to help out, 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.

You can go to the donation page to find out more.

Along with the donation you can leave a note stating which article in particular you want me to invest in. As a token of gratitude, your name will be included in the credits section of the next article or your nominated one, unless you state otherwise.

11.1 Other ways of contributing

Alternatively, you can help out by suggesting changes on the Github repository and/or adding translations on the Crowdin page.

11.2 Acknowledgments

I want to give a big thanks to the following people for their past donation (which contributed to this article):

Adam Obenauf

Adrian Burgess

Alberto Cordeddu

Alberto Massidda

Alexander Perepechko

Alí El wahsh

Andreas Kotes

Andrew Woods

Antonio Bellotta

Antonio Vivace

BBQ Inc

Ben Morris

Bitmap Bureau

Brenden Kromhout

Carlos Díaz Navarro

Chiang Yi-Ta

Christopher Henderson

Christopher Starke

Cirilla Rose

Colin Szechy

Daniel Cassidy

David Bradbury

David Portillo

David Sawatzke

Dominic Wehrmann

Dudeastic

Duncan Bayne

Dávid Major

Eli Lipsitz

Elizabeth Parks

Eric Haskins

eurasianwolf

Gerald Mueller-Bruhnke

Grady Haynes

Guillermo Angeris

Ifeanyi Oraelosi

Izsak Barnette

Jack Wakefield

Jacob Almoyan

Jaerder Sousa

James Kilner

James Knowler

James Montgomerie

James Osborne

James William Jones

Jan Straßenburg

Jason Strothmann

Jerre van der Hulst

Joe Pugh

Johannes Baiter

John Mcgonagle

Josh Enders

Julius Hofmann

ltlollo

Luke Wren

Manish Sinha

Matthew Butch

MCE

Michael Chi

Michal Borsuk

Nathan Castle

Neil Moore

Nick T.

Oleg Andreev

Olivier Cahagne

Owen Christensen

Parker Thomas

Paul Adamson

Payam Ghoreishi

petey893

Phil Stevenson

Piergiorgio Arrigoni

Racri

rocky

Roger Bolsius

Samuel Shieh

Sanqui

Shoaib Meenai

Simon Pichette

Stephen Molyneaux

Stuart Hicks

Sébastien Lethuaire

Thomas Finch

Thomas Lanner

Thomas Peter Berntsen

Tim Cox

Ulrich Bogensperger

12 Licensing

Just like the contents on the website, all of my writings and multimedia assets authored by me are available under a permissive Creative Commons license. This edition in particular, however, is available under the Creative Commons Attribution-NonCommercial 4.0 International (I had to make it ‘non-commercial’ in order to protect this document from being sold without my authorisation).

The chosen license also means you can use my content for your own work, what I ask is that you reference my work properly. Please pay attention when you quote or paraphrase my work, as you need to explicitly state when you do either. Unfortunately, throughout my time writing the articles, I’ve come upon derivative works that didn’t respect these simple steps (i.e. they don’t specify when they quote me or they don’t provide the complete URL of the article). To be fair, sometimes this is involuntarily but others are the result of lack of care, so I find myself dedicating more text explaining this. On the other side, there are derivative works which have surprised me (in the positive way) with their way of referencing my articles, providing beyond of what the CC license asks for.

Anyway, if you have any doubts, you can check this referencing guide made by the University of Leeds.

13 Changelog

It’s always nice to keep a record of changes.

2022-01-26

Added explanation on how the CD medium works, thanks @david4599

2022-01-26

Added CPU history

Added Operating System section

Expanded Anti piracy section

Expanded Graphics section

2021-05-04

Corrected info about VDPs pipeline and audio channels, thanks @fafling, @XL2 and @TrekkiesUnite118 from SegaXtreme

Improved sources format

Expanded audio section

Updated motherboard and diagram

Added mention of the Communication Connector

2020-04-10

New sub-section explaining the visibility problem

2020-04-08

New memory section, thanks /u/EmeraldNovaGames.

Added more content to the CPU section, thanks Ponut64 from Sega Xtreme.

2020-04-07

Small corrections, thanks /r/SegaSaturn.

2020-02-18

Improved some explanations.

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.

14 Sources

The contents of this document could not have been possible without the research and expertise provided by the works listed here. Some are carried out for commercial purposes while others are entirely volunteer-driven.

[1]

E. Amos, “The vanamo online game museum.” [Online]. Available: https://commons.wikimedia.org/wiki/User:Evan-Amos

[2]

Nikkei Electronics, “The story of the hitachi SH-2 and the sega saturn.” 1997 [Online]. Available: https://www.sega-16.com/forum/showthread.php?33527-The-Story-of-the-Hitachi-SH-2-and-the-Sega-Saturn

[3]

Sega of America, Saturn overview manual.

[4]

Sega of America, Sega saturn dual CPU user’s guide.

[5]

Hitachi, SH-2: SH7604 product brief.

[6]

Sega of America, SCU user’s manual - third version.

[7]

Sega of America, VDP1 user’s manual.

[8]

Sega of America, VDP2 user’s manual - version 1.1.

[9]

Dr. J. T. Bell, “Visible surface determination (overview of different algorithms).” [Online]. Available: https://www.cs.uic.edu/~jbell/CourseNotes/ComputerGraphics/VisibleSurfaces.html

[10]

sonicfangameshq.com, “PROJECT z-TREME (sega saturn) author: SAGE 2019 tech demo.” [Online]. Available: https://web.archive.org/web/20200527233242/https://sonicfangameshq.com/forums/showcase/project-z-treme-sega-saturn-sage-2019-tech-demo.323/

[11]

Sega of America, SGL developer’s manual.

[12]

M. Greer, “The sega saturn and transparency.” [Online]. Available: https://www.mattgreer.org/articles/sega-saturn-and-transparency/

[13]

J. Burton, “Sonic r’s "impossible" fading.” Youtube [Online]. Available: https://www.youtube.com/watch?v=FdD0GvVRSMc

[14]

Sega of America, Saturn SCSP user’s manual.

[15]

yabause.org, “SMPC.” [Online]. Available: https://web.archive.org/web/20190621223925/https://wiki.yabause.org/index.php5?title=SMPC

[16]

yabause.org, “SH-2CPU.” [Online]. Available: https://wiki.yabause.org/index.php5?title=SH-2CPU

[17]

Sega of America, Boot ROM user’s manual.

[18]

Sega of America, Disc format standards - specification sheet.

[19]

Kommunikation und verteilte Systeme, “Lehrstuhl für informatik 4 - optical storage media.” RWTH Aachen University [Online]. Available: http://www-i4.informatik.rwth-aachen.de/content/teaching/lectures/sub/mms/mmsSS07/09_CD_4P.pdf

[20]

Tech Toy Tinker, “Sega saturn development.” [Online]. Available: https://web.archive.org/web/20210509132827/https://techtoytinker.com/sega-saturn-development

[21]

cyberwarriorx, “Pseudosaturn.” [Online]. Available: https://github.com/cyberwarriorx/pseudosaturn

[22]

James a.k.a Professor Abrasive, “Saturn optical drive emulator.” [Online]. Available: http://web.archive.org/web/20191112225106/https://assemblergames.com/threads/saturn-optical-drive-emulator.62274/

Also by Rodrigo Copetti

Architecture of Consoles: A Practical Analysis

NES Architecture

Game Boy Architecture

Mega Drive Architecture

SNES Architecture

Sega Saturn Architecture

PlayStation Architecture

Game Boy Advance Architecture

Nintendo 64 Architecture

Dreamcast Architecture

GameCube Architecture

Wii Architecture

PlayStation 2 Architecture

Xbox Architecture

Nintendo DS Architecture

Master System Architecture

PC Engine / TurboGrafx-16 Architecture

Virtual Boy Architecture

PSP Architecture

PlayStation 3 Architecture

Xbox 360 Architecture

Wii U Architecture