Considering all the work done by the Emotion Engine, is there something left? The last step actually: Display!
There's a simple but speedy chip specialised in that: The Graphics Synthesizer or 'GS' running at ~147.46 MHz. It contains 4 MB of DRAM embedded inside to do all processing in-house. Thus, removing the need to access the main memory. The embedded RAM (eDRAM) is connected using different buses depending on the type of data needed.
The GS has fewer features than other graphics systems previously reviewed on this site. Nonetheless, it's very fast at what it does.
Architecture and design
This GPU only does rasterisation and that is... Generating pixels, mapping textures, applying lighting and some other effects. This means there are no vertex transformations (these are covered by the VPUs). Also, this is a fixed-function pipeline, so no fancy tweaking or shaders either, you are stuck with a fixed shading model (e.g. Gouraud).

Pipeline design of the Graphics Synthesizer
Looks pretty simple right? Well, let's dive deeper to see what happens at each stage.
Pre-Processing
The Emotion Engine kickstarts the Graphics Synthesizer by filling its embedded DRAM with the required materials (Texture bitmaps and Colour Lookup tables, the latter are also known as 'CLUT'), assigning values on the GS's registers to configure it, and finally, issuing the drawing commands (Display Lists) which instruct the GS to draw primitives (points, lines, triangles, sprites, etc) at specific locations of the screen.
Additionally, the GS will preprocess some values that will be needed for later calculations. Most notably, the Digital Differential Algorithm value, which will be used for interpolations during drawing.
Rasterisation
Using the previous values calculated, the renderer generates pixels from the primitives. This unit can generate 8 pixels (with textures) or 16 pixels (without textures) concurrently, each pixel entry contains the following properties calculated:
- RGBA: Corresponding to the gradient of Red, Green, Blue and Alpha (transparency).
- Z-value: Used for depth testing in later stages.
- Fog: Optional, to simulate fog in the environment.
- Texture properties: Contains the address of the texture in DRAM and other properties (coordinates, level of detail, filter, etc) that will be used in the next stage.
It also performs Scissoring Tests to discard polygons outside the frame area (based on their X/Y values), some pixel properties are forwarded to the 'Pixel testing' stage for further checks. Lighting is also provided by selecting one of the two choices available, Gouraud and Flat.
The pack is then delivered to the 'Texture mapping' engine, but each property is operated by a specialised 'sub-engine', which enables to process of different properties in parallel.
Texturing
This stage is powered by a large Pixel Unit that can compute up to 16 pixels at a time, here textures will be mapped onto the polygons (now pixels). Furthermore, fog and anti-aliasing effects are applied here.
Texture maps are fetched from DRAM in an area defined as Texture buffer, although this is interfaced by a separate area called Texture Page Buffer which seems to serve as a caching mechanism for textures. CLUTs are also mapped using this page system. Both elements are retrieved using a 512-bit bus.
The pixel unit performs perspective correction to map textures onto the primitives (a great improvement considering the previous affine mapping approach). Moreover, it also provides bilinear and trilinear filtering, the latter one is used alongside mipmapped textures.
Testing
Here certain pixels will be discarded if they don't meet several requirements. Having said that, the following tests are carried out:
- Alpha test: Compares the alpha value (transparency) of a pixel against the 'standard' value. This is because in some cases, the alpha value is required to be within a certain range or greater/less than an arbitrary value.
- Destination Alpha test: This checks the pixel's alpha value again before drawing it to the frame buffer.
- Depth Test: Compares the pixel's Z-value against the corresponding Z-value in the Z-buffer. This avoids processing pixels that would be hidden behind other pixels.
Post-Processing
The last stage can apply some effects over our new pixels using the previous frame-buffer found in local DRAM:
- Alpha Blending: Merges colours of the current buffer with the previous one in memory.
- Dithering: Large RGBA values will need to be trimmed, so dithering can be applied to soften the loss of precision.
- Colour Clamping: After applying operations like Alpha Blending, the new RGB value may exceed the valid range (0-255), so clamping sets the value within the range.
- Formatting: This converts the final frame-buffer generated in the pipeline to a format that can be stored in memory.
Finally, the new frame-buffer, along with the updated Z-buffer, are written to memory using a 1024-bit bus.
Even more post-processing
There's a dedicated component inside the GS called Programmable CRT Controller or 'PCRTC' which sends the frame buffer in memory to the Video output, so you can see the frame on TV. But that's not all: It also contains a special block called Merge Circuit that allows to alpha-blend two separate frame buffers (useful if games want to reuse the previous frame to form the new one). The resulting frame can be outputted through the video signal and/or written back to memory.
Better models
With all being said, this surely brought better designs to refresh already-famous characters. Take a look at this 'Before & After':

Interactive model available in the modern edition
Crash Bandicoot (1996) for the PS1.
732 triangles.

Interactive model available in the modern edition
Crash Bandicoot: The Wrath of Cortex (2001).
2226 triangles.
Here are characters from new game series, these were modelled with high levels of detail from the ground up:

Interactive model available in the modern edition
Kingdom Hearts (2002).
2744 triangles.

Interactive model available in the modern edition
Dragon Quest VIII (2004).
2700 triangles.
It's worth mentioning that games like Dragon Quest implemented a custom lighting model called Cel Shading (a term I have mentioned before), however, in my previous articles I explained that the GPU was mainly responsible for this. In the PS2 case, the required colour calculations are presumably done by the Emotion Engine, since the GS isn't as flexible as other GPUs.
Video Output
As stated before, the PCRTC sends the frame buffer through the video signal. The interface can broadcast video using a wide range of formats (to work with TVs from any geographical region) :
- PAL: Sends up to 640x512 pixels at 50 Hz, either progressive (576p) or interlaced (576i).
- No games found in the market use 576p. While some support progressive mode, they do so in 480p mode.
- NTSC: Up to 640x448 pixels at 60 Hz, either progressive (480p) or interlaced (480i).
- VESA: Up to 1280x1024 pixels.
- DTV: Up to the enormous amount of 720x480 pixels in progressive mode or 1920x1080 in interlaced mode.
- By tweaking the PCRTC settings, a game can also force to output in 1080p. However, this mode is undocumented and therefore subject to unpredictable behaviour.
- Does that mean the PS2 can 'display HD'? Technically... yes, but I don't think most game studios risked the performance penalty for a format that wasn't popularised yet.

The right side of the console , as seen from the back. Showing A/C port, Digital audio port and AV Multi Out.
There're quite a lot of modes to choose from, but it all comes down to the format adoption during the early 2000s, which narrows it down to PAL and NTSC. Also, even though PAL provided a higher resolution than NTSC, some European versions of NTSC games resorted to letterboxing to mask the unused horizontal lines and slowed down the refresh rate to fit in the 50Hz limit (I call these 'bad ports'!).
The video-out port (Multi A/V) is very convenient. It carries RGB, Component, S-Video and composite. So, all the important signals are there without requiring proprietary adapters or internal modifications.





