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!
The system has not one but two Hitachi SH-2 CPUs running at ~28.63MHz each. 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 (which can lead to congestion).
These processors are part of the Hitachi SH7600 brand, a series designed for embedded systems featuring:
The specific CPU model selected for this console, the ‘SH7604’ or just ‘SH-2’, contain the following additions:
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 comes in handy for this occasion.
The system 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.
The console contains an additional coprocessor, the Saturn Control Unit or ‘SCU’ which is composed of two modules:
The SCU comes with 32 KB of SRAM for local use. It’s worth mentioning that the SCU can’t access WRAM-L.
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:
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.
The Video Display Processor 1 (VDP1) is a chip that draws sprites with geometric transformations. 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 256 KB framebuffer 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.
The Video Display Processor 2 (VDP2) specialises in rendering large (4096×4096 pixels) planes with transformations (rotation, scale and translation) applied on them.
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.
As you can see, the architecture of the graphics sub-system is quite complex, so it’s interpreted differently depending on the needs:
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.
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.
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’).
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.
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:
For this reason, most games ended up dramatically ranging in quality since each studio came up with their unique solution.
So far we’ve been using single quadrilaterals to form sprites or background layers. But what if we grab multiple primitives and arrange them to form a more complex figure? This is how 3D models come to fruition.
In a nutshell, the CPUs and SCU are tasked with 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.
Either VDP can draw this new 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 (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.
These are some examples of characters that were re-designed for this console, the models are interactive so do try to fiddle with them!
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. 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.
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 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.
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.
As you may suspect, this just wasn’t viable for some games, so at the end, these had no option but to ditch half-transparency all-together… Although, some studios found ingenious fixes, take a look at these two cases:
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.
The sound subsystem consists of several parts:
The new audio capabilities mean that studios can finally record/produce soundtracks in-house and then bundle it 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 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.
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.
Peripherals are controlled by the SMPC (System Management & Peripheral Control), a micro-controller that also provides a real-time clock and receives commands from the SH-2s.
There’s a cartridge slot used for additional 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.
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). Sega released a Floppy drive that relied on this interface.
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. The disc reader also contains 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, so you can actually access its content from a PC.
A popular method of disabling the copy protection was by installing mod-chips that could trick the CD reader when a burned disc is inserted.
A more sophisticated method for running unauthorised code was published 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 to load Homebrew without depending on the ageing drive.
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: Sega Saturn Architecture - A Practical Analysis - Author: Rodrigo Copetti - URL: https://www.copetti.org/writings/consoles/sega-saturn/ - Date of publication: 03 Aug 2019 - Last modified: 21 Jul 2021 For instance, using the IEEE style: R. Copetti, "Sega Saturn Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://www.copetti.org/writings/consoles/sega-saturn/. [Accessed: day- month- year]. and Harvard style: Copetti, R., 2019. Sega Saturn Architecture - A Practical Analysis. [online] Copetti.org. Available at: https://www.copetti.org/writings/consoles/sega-saturn/ [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) - A PAL/NTSC/JAP Saturn console with a controller (£50 - ?) - An optical drive emulator (only if found at a reasonable price)
Alternatively, you can help out by suggesting changes and/or adding translations.
It's always nice to keep a record of changes.
## 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.