Saturn

e

S☃☃

The is a console released by SEGA in Japan on the November 22, 1994. It is generally seen as an (undeserved, in some eyes) failure, being totally outplayed in the market by Sony's PlayStation. It was released in Japan on November 22, 1994, in the United States on May 11, 1995, and in Europe on July 8, 1995. Though originally scheduled to be released in America in September 1995, SEGA of America moved the release date earlier in the hopes of cashing in on sales that would have gone to the purchase of a PlayStation, which made its debut in North America in September 1995. The Saturn contained a 32-bit video card. Video games were released on CD-ROM.

The SEGA Saturn sold 17 million units worldwide, up until 1998. It was SEGA's most popular console in Japan, coming second place to the PlayStation and beating the Nintendo 64 in that market. In Japan, advertising for the Saturn was frequently provided by cult-favourite Segata Sanshiro. However, the SEGA Saturn failed to gain a similar market share in North America and Europe, regions where it became a distant third behind Sony's PlayStation and the Nintendo 64. The Saturn was followed by the Dreamcast.

In 2009, video game website IGN chose the Saturn to be their 18th best video game console of all time, out of their list of 25.

Dual CPU
The Saturn had impressive hardware at the time of its release, but its design, with two CPUs and six other processors, made harnessing this power difficult for developers accustomed to conventional programming. It increased the complexity of the system.

The Saturn's dual-CPU architecture was the source of some difficulty for developers. The biggest disadvantage was that both processors shared the same bus and were unable to access the memory registers at the same time. As a result, only one processor could utilize system memory at a time. The 4 KiB of cache memory in each CPU was critical to maintaining performance. In general, a very careful division of processing, in addition to the already-challenging task of parallelizing the code, was required to get the most out of the Saturn. One example of how the Saturn was utilized was with Virtua Fighter ' s use of one CPU for each character.

Many of the Saturn's developers, such as Lobotomy Software programmer Ezra Dreisbach, found it difficult to develop for compared to the PlayStation because of its more complex graphics hardware. In order to port Duke Nukem 3D and PowerSlave/Exhumed to the Saturn, Lobotomy Software had to almost entirely rewrite the Build engine to take advantage of the Saturn's unconventional hardware. Also, during testing of an unreleased Quake port for the PlayStation, the Saturn's performance was found to be notably inferior for the game. Other developers have contested that the Saturn's shortcomings in these respects are overstated at best. WARP leader Kenji Eno, when asked how WARP managed to produce the impressive 3D visuals of Enemy Zero (a game originally developed for the PlayStation) on the Saturn, replied, "...the PlayStation and the Saturn aren't that different, so moving it [Enemy Zero] to Saturn wasn't too difficult."

Third-party development was initially hindered by the lack of useful software libraries and development tools, requiring developers to write in assembly language to achieve good performance. At least during early Saturn development, programming in assembly could offer a two to fivefold speed increase over C language. To save development costs and time, some programmers would utilize only one CPU, such as with Alien Trilogy. Sega responded to these criticisms by writing new graphics libraries which were claimed to help make development easier. These libraries were presented as a new operating system by Sega of Japan.

Saturn games also improved with time, as with nearly every other console system. One notable example is the Saturn port of Virtua Fighter 2. For instance, later programming techniques employed by SEGA's AM2 saw an improvement in performance. Video exists of a canceled version of Shenmue - later released on the Dreamcast - running on a stock Sega Saturn. The video was included in the Dreamcast title Shenmue II.

Quadrilaterals
Unlike the PlayStation and Nintendo 64 which used triangles as their basic geometric primitive, the Saturn rendered quadrilaterals with forward texture mapping, similar to the 3DO. This proved to be a hindrance because most of the industry's standard design tools were based on triangles, with independent texture UV coordinates specified per vertex. One of the challenges brought forth by quadrilateral-based rendering was problems with textured surfaces containing triangles. In order to make a triangular shaped object, rendering had a fourth side with a length of zero. This technique proved problematic as it caused texture distortion and required careful reworking to achieve the desired appearance - Sega provided tools for remapping textures from UV space into rectangular tiles. These complications can be seen in the Saturn version of Tomb Raider, in which triangular rocks are not rendered as well as other systems' versions of the game.

If used correctly, the quadrilateral rendering of the Saturn had advantages. It could sometimes better approximate perspective than the PlayStation's triangles (linearly interpolated in screen space), as demonstrated by several cross-platform titles such as Wipeout and Destruction Derby. However, the lack of UV coordinates could produce further problems with clipping textured surfaces - in some games like SEGA Rally the UV's would simply be clamped at the near clip plane, although the polygon outlines were clipped correctly. The quadrilateral-focused hardware and a 50% greater amount of video memory also gave the Saturn an advantage for 2D game engines and attracted many developers of role-playing video games, arcade games and traditional 2D fighting games. With creative programming, later games like Burning Rangers were able to achieve true transparency effects on hardware that used simple polygon stipples as a replacement for transparency effects in the past.

Cartridge
The cartridge slot gave the potential for adding extra RAM or storage devices for saving games to the system.

Two ROM cartridges were released with Sega Saturn games: one with King of Fighters '95 and the other with Ultraman: Hikari no Kyojin Densetsu. The ROM cartridges contained part of the game data because not enough system RAM was available.

Two different RAM cartridges were released for the system; a 1 MB RAM cart by SNK for King of Fighters '96 and a 4 MB RAM cart by Capcom for X-Men vs. Street Fighter and Marvel Super Heroes vs. Street Fighter. A RAM expansion cartridge was also required for the games Groove on Fight & Final Fight Revenge. Both companies were known for their sprite-based 2D competitive fighting games and many of their subsequent games utilized their respective cartridges (such as Vampire Savior: The Lord of Vampire and Cotton 2: Magical Night Dreams).

Processors

 * Two Hitachi SuperH-2 7604 32-bit RISC processors at 28.63 MHz (25 MIPS)—each has 4 kB on-chip cache (4-way associative), of which 2 kB can alternatively be used as directly addressable Scratchpad RAM
 * Hitachi VDP 1 32-bit video display processor (running at 28.63 MHz on NTSC and PAL Systems) for sprites/polygons
 * Yamaha VDP 2 32-bit video display processor (running at 28.63 MHz on NTSC and PAL Systems) for backgrounds/video out
 * Yamaha System Control Unit (SCU) with DSP for geometry processing and DMA controller (running at 14.3 MHz)
 * Motorola 68EC000 sound controller (running at 11.3 MHz / 1.5 MIPS)
 * Yamaha FH1 DSP sound processor, "Saturn Custom Sound Processor" (SCSP), running at 22.6 MHz
 * SH-1 32-bit RISC microcontroller (for the CD-ROM and CD security checks; uses preprogrammed embedded ROM, not programmable by software)
 * Hitachi 4-bit MCU, "System Manager & Peripheral Control" (SMPC)

Memory

 * 1 MiB SDRAM as work RAM for both SH-2 CPUs (faster)
 * 1 MiB DRAM as work RAM for both SH-2 CPUs (slower)
 * 512 KiB VDP1 SDRAM for 3D graphics (Texture data for polygon/sprites and drawing command lists)
 * 2x 256 KiB VDP1 SDRAM for 3D graphics (Two framebuffers for double-buffered polygon/sprite rendering)
 * 512 KiB VDP2 SDRAM for 2D graphics (Texture data for the background layers and display lists)
 * 4 KiB VDP2 SRAM for color palette data and rotation coefficient data (local, on-chip SRAM)
 * 512 KiB DRAM for sound. (Multiplexed as sound CPU work RAM, SCSP DSP RAM, and SCSP wavetable RAM)
 * 512 KiB DRAM as work RAM for the CD-ROM subsystem's SH-1 CPU
 * 32 KiB SRAM with battery back-up for data retention.
 * 512 KiB Mask ROM for the SH-2 BIOS

Audio
Audio generation was provided via a specialized multifunction sound chip developed by Yamaha, the YMF292, also known as the Saturn Custom Sound Processor or SCSP. The SCSP included 32 sound channels with both FM and PCM (up to 44.1 kHz sampling rate) functionality and fully configurable channel linking for modulation purposes, a 128-step DSP, and either 16-or 18-bit digital output to an external DAC. The SCSP was used in conjunction with the Saturn's Motorola 68EC000 co-processor and dedicated audio RAM, and MIDI compliance allowed use of an external MIDI controller, such as a keyboard. The SCSP lacked hardware audio decompression.

Video
The Saturn is equipped with dual custom VDP chips for graphics processing. The VDP1 chip is primarily responsible for sprite generation. Polygon generation is accomplished through manipulation of the sprite engine. Texture mapping and Gouraud shading are also handled by the VDP1.

The VDP1 renders primitives to two 256 kB frame buffers that is most commonly configured as 512x256x16 with a 320x240 visible area. For medium and high-resolution games, a 1024x256x8 frame buffer is used. Games running at 30 frames/s, like Virtua Fighter Remix and Die Hard Arcade, this gives a visible area of 640x240. For games running at 60 frames/s, like Virtua Fighter 2 and Dead or Alive, taking advantage of interlacing allows the two frame buffers to be combined with an effective size of 1024x512 per frame, with a visible area of 640x480. Having two separate frame buffers allows double buffering of the display and provides more time for rendering. The active framebuffer is read out to the display by the VDP2, which can apply data from a coefficient table to modify the scanning process, for effects like rotation, scaling, and general distortion of the entire frame buffer as a single entity.

The SCU (system bus control unit) provides DMA across a dedicated bus commonly labelled as the "B-bus" that the VDP2 and VDP1 are connected to, allowing transfer of data from them to and from main memory. Keep note that transferring data from and to the same bus is prohibited by all 3 SCU DMA levels.


 * Rendering engine for command tables: textured and non-textured polygons, untextured "polygons," "polylines," and lines along with command tables that control the frame buffer.
 * "Sprites" are textured polygons with specific rendering modes:
 * Normal sprite (one point), shrunk/scaled sprite (two points), distorted sprite (four points)
 * Other rendering modes:
 * Overwrite (replace frame buffer contents)
 * Shadow (underlying frame buffer pixels are rewritten with 1/2 brightness, primitive not drawn)
 * Half luminosity (primitive rendered with 1/2 brightness)
 * Half transparency (primitive and underlying framebuffer pixels averaged together)
 * Gouraud shading for RGB-format textures only
 * Dual 256 KiB frame buffers
 * Programmable frame buffer depth of 8 or 16 bits per pixel
 * Automatic erase feature to clear framebuffer with single colour

Some commonly quoted specifications are highly dependent on the rendering modes for the polygons and other factors that burden the system load:


 * 200,000 texture-mapped polygons per second
 * 500,000 flat-shaded polygons per second
 * 60 frames of animation per second
 * VDP1 memory is split: 512 kB for texture data / command lists, 256 kB for one frame buffer and 256 kB for another. Because of the split, it is not possible to use the frame buffer as a texture.
 * The VDP1 has no texture cache, but since texture memory and the frame buffer have separate buses and can be accessed simultaneously, there isn't a speed penalty.
 * The two frame buffers have a high-speed auto-erase feature.
 * Commands are stored in a linked list in RAM, multiple lists can be stored, the list can be processed by the VDP1 without wasting a DMA channel.

The VDP 2 serves as the Sega Saturn's background processor. Certain special effects such as texture transparency and playfield rotation and scrolling (up to five fields at any given time) are handled here.

Both the VDP2 and VDP1 32-bit video display processor has direct access to the both SH-2s, as well as direct memory access (DMA) to both the main and video RAM.


 * Background engine
 * Four simultaneous scrolling backgrounds
 * Uses 8x8 or 16x16 tiles or bitmap display per background
 * Programmable memory access controller for VDP2 VRAM
 * Two simultaneous rotating playfields
 * VDP2 can rotate VDP1 framebuffer position while scanning out to display for rotation effects
 * Color RAM supports 15-bit (32768 colors) and 24-bit (16.7 million colors) display modes
 * Programmable priority at the per-background / per-tile / per-pixel levels
 * Background color tinting/fading, and transparency effects
 * Background blur effect (gradation) to simulate distance

Programmable display resolution:


 * Horizontal sizes of 320, 352, 640, 704 pixels
 * Vertical sizes of 224, 240, 256 scanlines, non-interlaced
 * Vertical sizes of 448, 480, 512 scanlines, interlaced (only PAL consoles support 256 and 512 scanline displays)
 * Hi-Vision (EDTV) and 31 kHz (VGA) display support:
 * 31 kHz: 320×480 or 640×480, non-interlaced (progressive scan)
 * Hi-Vision: 352×480 or 704×480, non-interlaced (progressive scan)

Storage
The Saturn features a double speed CD-ROM drive manufactured by JVC-Victor (some models may have been manufactured by Hitachi or Sanyo). The drive has a transfer rate of 320 KiB/s, and a 512 KiB data cache. Drive related functions are controlled via a single Hitachi SH1 32-bit RISC processor operating at 20 MHz.


 * CD-DA compatible
 * CD+G compatible
 * CD+EG compatible
 * CD single (8 cm CD) compatible
 * Video CD (required optional MPEG add-on), Photo CD, Electronic Books, digital karaoke (optional)

Input/output

 * Two 7-bit bidirectional parallel I/O ports (controller ports)
 * High-speed serial communications port (Both SH2 SCI channels and SCSP MIDI, also used for the Serial port)
 * Cartridge connector
 * Internal expansion port for optional MPEG adapter card (different models available from Sega, JVC, and Hitachi)
 * Composite video/audio (standard)
 * NTSC/PAL RF (optional RF adapter required)
 * S-Video compatible (optional cable required)
 * RGB compatible (optional cable required)
 * EDTV/Hi-Vision compatible (custom cable required, not commonly available)

While the Saturn graphics hardware is capable of VGA (progressive/non-interlaced) video, no existing retail software ever used this mode and the system cannot force any such software to run in this mode. Moreover, neither Sega nor third-party manufacturers produced or sold the cables required to support such high-resolution modes on any type of display.

Power requirements

 * AC120 volts; 60 Hz (US)
 * AC240 volts; 50 Hz (EU/Asia)
 * AC100 volts; 50/60 Hz (JP/TW)
 * 3 volt CR2032 lithium battery to power non-volatile RAM and SMPC internal real-time clock
 * Power Consumption: 25 W
 * Power Consumption: 12 W (JP)

Dimensions (US/European model)

 * Width: 260 mm (10.2 in)
 * Length: 230 mm (9.0 in)
 * Height: 83 mm (3.2 in)

Errata
A VDP1 transparency rendering quirk causes strips of pixels to be rewritten to framebuffer for 2-point (scaled) and 4-point (quadrangle) "sprites", applying the transparency effect multiple times. Rarely seen in commercial games (Robotica explosions), later titles implemented software transparency via direct framebuffer access to correctly render polygons (Dural in Virtua Fighter Kids).

Another technique developed for pseudo-hardware transparency was to rasterize polygons using one or two-pixel-tall sprites with transparency enabled to fill in horizontal spans. Because 2 of the 4 quadrangle points were identical, there was no framebuffer rewrite during rendering.