Playstation 2 Architecture

Supporting imagery

---

A quick introduction

The Playstation 2 was not one of the most powerful consoles of its generation, yet it managed to achieve a level of popularity unthinkable for other companies.

This machine is nowhere near as simple as the original Playstation was, but we will see why it didn’t share the same fate of previous complicated consoles.

At the heart of this console we find a powerful package called Emotion Engine or ‘EE’ designed by Sony and running at ~294.91 MHz. This chipset contains multiple components, one of them being the main CPU. The rest are at the CPU disposal to speed up certain tasks.

The leader

The main core is a MIPS R5900-compatible CPU with lots of enhancements. This is the first chip that starts executing instructions after the console is turned on. The processor provides the following features:

• MIPS III ISA: A 64-bit RISC instruction set. Wait, is it me or this is the same ISA found on a competitor’s console?. Not quite, Sony enhanced the ISA by adding some instructions from MIPS IV (prefetch and conditional move) along with their own SIMD extension called multimedia instructions.
• 32 128-bit extra registers: Another enhancement. They are better managed using multimedia instructions and are very useful for vector processing.
  • These registers are accessed through a 128-bit bus, while the rest of the CPU uses an internal 64-bit bus.
• 2-way superscalar: Up to two instructions are executed in parallel.
• 24 KB L1 cache: Divided into 16 KB for instructions and 8 KB for data.
  • It also implements a prefetch function to cache instructions and data before they are requested. This is done by including extra circuitry that can identify which places in memory are more often requested.
• 16 KB of Scratchpad RAM: Also known as ‘Fast RAM’.
• Memory management unit: Interfaces memory access with the rest of the system.

The core is complemented with a dedicated floating point unit (identified as ‘COP1’) that accelerates operations with 32-bit floating point numbers (also known as floats in C). This is a peculiar block as it doesn’t follow the IEEE 754 standard, most evident with its absence of infinity (computed as 0 instead). For more information, check out Krysto’s ‘Nightmare on Floating-Point Street’ (link in the ‘Sources’ section).

A recognisable memory choice

Next to the Emotion Engine are two blocks of 16 MB of RAM, giving a total of 32 MB of main memory. The type of memory used is RDRAM (déjà vu!) which is accessed through a 16-bit bus.

At one corner of the Emotion engine there is a powerful DMA Controller or ‘DMAC’ that transfers data between main memory and Scratchpad; or between main memory and any component inside the EE.

Data transfers are done in batches of 128-bits, but here is the interesting part: Every eight batches, the main bus is temporarily unlocked. This leaves a small window to perform other DMA transfers in parallel (up to ten) or let the CPU use the main bus. This modus operandi is called slice mode and is one of the many modes available on this DMA unit. Bear in mind that while slice mode reduces stalls on the main bus, it does so at the cost of slowing down the overall DMA transfer.

Preventing past mishaps

Whether we want it or not, with the amount of traffic happening inside the Emotion Engine, this design will eventually suffer the consequences of the Unified memory architecture or ‘UMA’. That is… multiple independent components trying to access main memory at the same time, causing congestion. Well, to correct these issues, Sony alleviated the constant need for memory by:

• Wrapping their processors with lots of cache. Thus, only requiring access to main memory if absolutely necessary.
  • 99% of cache/scratchpad mentions in this article will be for this reason.
• Adding a 128-byte Write Back Buffer: Very similar to the Write Gather Pipe, but instead of waiting until it’s 25% full, it will check the state of the bus (i.e congested or free) first.

This sounds very convenient for applications that can benefit from cache, but what about those tasks, such as manipulating Display Lists, which shouldn’t use cache at all? Luckily, the CPU provides a different memory access mode called UnCached, which only uses the Write Back Buffer. Thus, it will not waste cycles correcting the cache (product of cache misses).

Furthermore, the UnCached accelerated mode is also available. This one adds a buffer for speeding up read of continuous addresses in memory.

Other interesting bits

Inside the same Emotion Engine package, there is yet-another processor called Image Processing Unit or ‘IPU’, this time designed for image decompression. As the successor of the MDEC, the IPU can be useful when a game needs to decode an MPEG2 movie without jamming the main CPU.

Long story short, the game sends compressed image streams to the IPU (hopefully using DMA) which is then decoded in a format that the GPU can display. The PS2’s operating system also relies on the IPU to provide DVD playback.

Finally, the IPU also operates compressed High-resolution textures, which saves CPU usage and reduces large transfers.

---

Co CPUs

It’s been two years since the rivals presented their latest offering. If you read the former article and just started reading this one, I presume you are still waiting for ‘the thing’ that makes the PS2 as powerful as it seemed back then. Now, let me introduce a very important set of components Sony fitted in the Emotion Engine, the Vector Processing Units or ‘VPU’.

Architecture

A Vector Processing Unit is a small independent processor designed to operate vectors. In particular, vectors made of four floats. These processors are so fast that they only spend one cycle per operation, which can be extremely convenient for geometry processing. Though they exhibit similar unstandardised behaviour to the CPU’s FPU.

VPUs are made of the following components:

• Some Vector Unit Memory or ‘VU Mem’: Used as a working space for the Vector unit. It stores values needed to be operated and/or the results of previous operations.
• A Vector Unit: The core of the processor. It contains some memory (called Micro Memory) to store a program (called Microprogram) which instructs the unit on how to operate the data found in ‘VU Mem’.
  • It implements a 64-bit ISA and the execution unit is split into two parallel sub-units. The first one multiplies or adds floats, while the other one divides floats or operates integers. This enables to operate both floats and integers concurrently.
• A Vector Interface: Automatically decompresses vertex data coming from main memory in a format the Vector unit can understand. This unit can also transfer microprograms to Micro Memory.

Functionality

To start working, the vector unit needs to be ‘kickstarted’. For this, the main CPU is in charge of supplying the microcode.

There are two VPUs fitted in the Emotion engine, but they are arranged differently, giving way to different uses and optimisations.

Infinite worlds

A useful approach that can be exploited with these units is procedural generation. In other words, instead of building the scene using hard-coded geometry, let the VPUs generate it using algorithms. In this case, the VPU computes mathematical functions to produce the geometry which is then interpreted by the GPU (i.e. triangles, lines, quadrangles, etc) and ultimately used to draw the scene.

Compared to using explicit data, procedural content is ideal for parallelised tasks, it frees up bandwidth, requires very little storage and it’s dynamic (programmers can set parameters to achieve different results). There are certain areas that can highly benefit from this technique:

• Complex surfaces (e.g. spheres and wheels).
• World rendering (e.g terrains, particles, trees).
• Bezier curves (a very popular equation in computer graphics which is used to draw curves), these are turned into a Bezier patch (explicit geometry) and supports different degrees of precision based on the level of detail required.

On the other side, procedural content may struggle with animations and, if the algorithm is too complex, the VPU might not generate the geometry at the required time.

To sum up, procedural rendering is not a new technique, but thanks to the VPUs, it opens the doors to further optimisations and richer graphics. Nonetheless, is not a simple technique to implement and Sony R&D published various papers describing different approaches to use on their console.

You define the workflow

With these new additions, programmers now have a lot of flexibility to design their graphics engines. In fact, there are multiple research papers published which benchmark popular pipeline designs.

Here are some examples of graphics pipelines set up with different optimisations:

These have been so far examples from the theoretical point of view, but in order to explain a more ‘practical’ implementation, I’m going to refer to a video Jon Burton published regarding the development of one of their PS2 games.

There are many more examples out there, but to sum things up: It is now up to the programmer to find the optimal setup, and that, is a good thing.

---

Graphics

Considering all the work done by the Emotion Engine, is there something left? The last step actually: Display!

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.

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

Here are characters from new game series, these were modelled with high levels of detail from the ground up:

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 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.

---

Audio

The new audio chip is an incremental update of the old SPU called… SPU2! Improvements include the inclusion of 2 MB of internal memory and 48 channels available (two times the original amount).

The SPU2 is made of two sound processors inside, referred as CORE0 and CORE1; and running at ~36.86 MHz. Each one processes 24 channels.

Curiously enough, these are still two independent processors and to configure them, you have to alter their registers. However, Sony warned developers that both sets of registers have to be set with 1/48000 seconds of gap. If you hurry too much, the behaviour of the SPU2 becomes unpredictable!

The SPU2 inherits the same effects available from the original SPU. The memory provided is used as a ‘work area’: You can store raw waveform data and allocate extra space to process it and apply effects on it.

Finally, the chip can mix all channels to provide stereo output. Now, here is the interesting part: The SPU2 can feed itself the mixed stereo sample as new input, this enables to EE to access it (to mix it with even more audio, for instance), or keep adding more effects (such as reverb, echo and delay).

The audio signal is outputted through two mediums:

• Digital Audio: Referred as the Sony/Philips Digital Interface or ‘S/PDIF’.
• Analog Audio: Goes through the digital-to-analogue converter and ends at the Multi A/V port.

The I/O of the PS2 is not complicated, yet multiple revisions of this console completely changed various internal and external interfaces.

To start with, there’s a dedicated processor that arbitrates the communication between different components, this CPU is no other than the original MIPS R3000-based core found in the Playstation 1. This time, it’s called IOP and runs at 37.5 MHz using a 32-bit bus.

The IOP communicates with the Emotion Engine using a specialised I/O interface called System Interface or ‘SIF’, both endpoints use their DMA units to transfer data between each other. The IOP also contains its own memory used as buffer.

The IOP gives access to the front ports, DVD controller, SPU2, the BIOS ROM and the PC card slot.

Inherited compatibility

By including the original CPU, we can suspect PS1 compatibility would eventually happen somehow. Conveniently enough, the IOP happens to include the rest of the components that formed the CPU subsystem of the PS1. Moreover, the core can be under-clocked to run at PS1 speed. Unfortunately, the SPU2 has changed too much for the PS1, but for that, the Emotion Engine is ‘repurposed’ to emulate the old SPU.

In later revisions of this console, the IOP was replaced with a PowerPC 401 ‘Deckard’ and 4 MB of SDRAM (2 MB more than before), backwards compatibility persisted but through software instead.

Available interfaces

This console kept the previous front ports that were included in the original Playstation, it also featured a couple of ‘experimental’ interfaces that looked very promising at first.

On the back of the console we also had a slot for PC cards, you could buy the ‘Network Adaptor card’ from Sony that provided two extra ports. One for connecting an ethernet cable, and another one for plugging in a proprietary and external ‘Hard Disk Drive Unit’, also sold by Sony. Having a drive allowed games to store temporary data (or permanently install themselves there) for faster load times. Just a few games used this feature, though.

The ethernet transceiver supplied supports transfer rates of up to 100 Mbps (12.5 MB/s). However, the observed rate is notoriously lower (down to 2 MB/s in some cases). The explanation for that is relatively simple: To achieve a usable network communication, one is required to implement all the layers of the standard ‘OSI Model’; and the transceiver is just one piece of the puzzle. The rest is often delegated to the IOP (thus, done in software) but due to the IOP’s limited performance, this results in bottlenecks. There are multiple ways to tackle this and a previous discussion on ps2-home.com provides very insightful info, if you are curious (see the ‘Sources’ section).

Interactive accessories

The new version of their controller, the DualShock 2, is a slightly improved version of DualShock. During the days of the original Playstation, multiple revisions of the original controller were released featuring different features (and also bringing fragmentation to the market). Now, for the benefit of developers, there was a single controller that unified all the previous properties.

---

Operating System

There’s a 4 MB ROM chip fitted on the motherboard that stores a great amount of code used to load a shell menu that the users can interact with, but it also provides system calls to simplify I/O access, games rely on this.

Upon boot, the CPU will execute instructions in ROM which in turn will:

1. Initialise the hardware.
2. Load a Kernel into RAM, this will handle system calls and also provide multi-threading support (cooperative and priority-based).
3. Start the IOP processor and send it modules, these will enable the IOP to handle the hardware of this console. At the end, the IOP will be put in a ‘waiting for command’ state.
   • The use of modules allows Sony to release new hardware revisions of the PS2 without changing the IOP, lowering production costs.
4. Load ‘OSDSYS’, the program that displays the splash animation and the shell menu.

Interactive shell

The functionality of the PS2 shell is pretty much in pace with the other 6th gen. consoles.

---

Games

It is unprecedented the level of popularity this system achieved during the noughties, at the end of its lifespan (2013, after 13 years!) the game library was filled with 1850 titles.

Development ecosystem

Sony provided the hardware and software to assist game development.

On the software side, there was the Playstation 2 SDK which included:

• The Emotion Engine toolchain: A set of C and C++ compilers, assemblers, linkers and debuggers used to control each element of the EE. The main CPU was mainly programmed using C/C++, however, performance-critical components like the vector units were programmed using assembly (microcode/macrocode) instead.
  • The pack also included an ‘Emotion Engine simulator’ which could roughly test out the code without sending it to the real hardware, although the simulator wasn’t as accurate as the physical EE chip.
  • All of these tools worked on Linux, Solaris and Windows. The latter one ran through the Cygnus environment.
• Low-level libraries: Interfaced many system functions (using BIOS calls).
• ‘Analysis’ tools to profile performance usage.
• Additional tools to connect with the official development hardware.

On the hardware side, Sony provided studios with dedicated hardware to run and debug games in-house. The initial devkits were bare boards stacked together to replicate the un-released hardware of the PS2. Later kits (named Development Tool), had a more presentable appearance, enhanced I/O and combined workstation hardware (running RedHat 5.2) with PS2 hardware to build and deploy the game in the same case.

The combination of the Devkit, the official SDK and Codewarrior (a famous IDE) was one of the most popular setups.

Medium

The disc drive can read both DVDs and CDs, so games could be distributed using either format, but for obvious reasons you will find most titles in DVD format.

In terms of speed, CD-ROMs are read at 24x speed (so 3.6 MB/s) and DVD-ROMs are read at 4x speed (5.28 MB/s).

Network service

As you have seen, the networking features of this consoles weren’t standardised until later revisions, which arrived four years later after the first release. Similarly, game studios were in charge of providing the necessary infrastructure if they decided to provide online services (like multiplayer). In later years, Sony deployed the Dynamic Network Authentication System or ‘DNAS’, it wasn’t an online server, but an authentication system to prevent pirated games from connecting online.

An unusual kind of game

Apart from all these games with their fancy graphics, Sony released a Linux distribution based on ‘Kondara’ (which is in turn based on Red Hat 6) available in two DVDs (first disc called ‘Runtime Environment’ and the second one called ‘Software Packages’) along with a VGA adapter, USB Keyboard and Mouse; plus some developer manuals. The pack was known as Linux Kit and you could run the OS by booting the first DVD and then proceed like any old school Linux environment. You obviously needed a Hard drive fitted in the console to install the Linux distro. Once installed, the first DVD was always required to boot this OS.

Linux Kit included compilers targeting the EE (gcc 2.95.2 with glibc 2.2.2) and assemblers targeting the vector units, along with a window system (XFree86 3.3.6) ‘accelerated’ in the Graphics Synthesizer. Overall, this sounds like an interesting environment. In fact, one of the research papers I read to write this article was carried out using this setup.

---

Anti-Piracy and Homebrew

There’s quite a lot to talk about here, so let’s start with the DVD reader, shall we.

Copy protection

This section was particularly concerning for game studios, since this console used a very affordable format disc to store games and was at extreme risk of being pirated.

Exploits discovered

Having explained the most critical part of this console, let’s take a look at multiple methods discovered that could bypass the protection mechanisms.

A semi-permanent software unlock

Some time ago, it was discovered that the BIOS of this console could be upgraded using the Memory Card, this function was never used in practice, but neither removed (at least during most of the console’s lifespan). With this, hackers realised that if they find a way to install particular software into the MemoryCard, then the BIOS would always load it at boot. This discovery led to Free MCBoot, a program presented as ‘upgrade data’ which replaces the original shell with one that can execute Homebrew.

Bear in mind these changes are not permanent, a Memory Card with ‘Free MCBoot’ installed must be inserted prior the console’s startup. Additionally, this software needs to be installed somehow, so another exploit (e.g. disc swapping) is required to bootstrap the installer.

More disc tricks

The same year after the release of Free MCBoot, another trick was discovered: Disguising games as DVD movies, effectively allowing unauthorised game copies to be read without requiring a modchip.

This only required to patch the game image by adding dummy metadata and partitions only used by DVD movies. Then, when the burned copy is inserted on the console, the drive won’t reject it, but it won’t execute the game either. However, with the help of a Homebrew program called ESR, the game could be kickstarted.

---

That’s all folks

Congratulations and thank you for reaching the end of the article! To be honest, there was so much to talk about that I wondered if readers would eventually get tired of Playstation-related stuff after finishing this.

Anyway, in all seriousness, I do hope you discovered new things after reading this article and if you have any comments, don’t hesitate to drop me a mail.

Until next time!
Rodrigo