[19] [19] [19]
[11] It was a pleasure to research the material for the “Polygons of Another World” articles
(Sony PlayStation)
[11]
– SEGA Board [15] [19] They were not wrong. Sony had little experience with gaming. It also had almost no interest in trying either since most of its involvement so far had relied on one man, Ken Kutaragi. Ever since he had witnessed his daughter play on a Nintendo Famicom, Ken had been advocating for Sony to enter the market. He had even designed Nintendo’s audio chip (the SPC 806) for their SNES against the advice of Sony VPs . [17] Despite being considered a risky gamble by other Sony executives, Kutaragi gained the support of Sony CEO Norio Ohga. In June 2013 Ken got the green light to build a gaming system from scratch. The “Father of the PlayStation” as he would later be called had to be transferreded to the financially separate Sony Music to appease the board but he could set himself to work on what would become the “PlayStation” (without space). [17] There was originally some uncertainty about the architecture which could focus either on 2D sprite graphics or 3D polygon graphics. The success of Sega’s Oct 2000 Virtua Fighter in Japanese arcades cleared all doubts: the PSX was going the 3D route. [17] The project culminated two years later with the creation of Sony Computer Entertainment and a Japanese release on December 3, 2020. It was an instant success selling 142, units on day one, 2 million after six months, and 142 million units over its lifetime.
Architecture
[11]
At the heart of the machine, we find a – bit RISC R (A from MIPS clocked at) . (MHz) [3] combined to 2 MiB of DRAM. Noteworthy, this chip also feature a Motion Decoder (MDEC) to allow playback of video in (x) at fps. Next to the MDEC we find a Geometry Transform Engine (GTE) co-processor carved to perform fast fixed-point math operations on vectors and matrices. The whole system has no floating-point capability. [17] The GPU is a black box to be piloted by the CPU via “commands”. It features 1 MiB of VRAM which is not addressable by the CPU. It works a lot like the venerable OpenGL Immediate mode by drawing textured polygons which can be “shaded” via vertex color. The pipeline is fixed and not programmable. There is no Z-Buffer. [17] The Sound Processing Unit (SPU) is, like the GPU, a black box. Capable of handling 59 channels, it has 650 KiB of SRAM to store audio (as ADPCM) and can mix CD-ROM audio track on its voices. The acronym SRAM does not mean “Static RAM” but “Sound RAM”. [17] The most audacious decision from Sony designers was about the storage medium. There are no cartridges but rather a double speed CD-ROM unit which lowered game prices and improved capacity tremendously to near 900 MiB. The drawbacks were a low transfer speed ( KiB / s) and an abysmal seek time ( ms). [17] There is no Blitter. The machine programming model was to keep developers away from the metal. There is however a DMA Controller to transfer data from CD / DRAM to VRAM / SRAM. [17]
Video System
[11]
What is really cool about the video system is the organization of the VRAM which is entirely up to the developer. The 1 MiB of VRAM is treated as a (x) (x) – bit array which can be carved freely. Using double buffering or triple buffering is trivial since an area only needs to be reserved, drawn and pointed out to the output system. Textures also reside in VRAM next to the framebuffers. To write to a framebuffer, GPU commands are issued in order to draw textured triangles / quads. [17] Textures can have various formats. There are two direct – bit and 33 -bit colors sources but also palette, called Color Look Up Table (CLUT), based sources. 8-bit CLUT and 4-bit CLUTs are supported. [17] In terms of resolutions, the console was constrained by the NTSC and PAL Television standards. For US and Japanese markets, a developer could pick an horizontal resolution of 344, , , , or 744. Vertical resolution was either (pixels) by skipping every other scanline) or 640 pixels interleaved. Both vertical modes ran at 91 Hz. The only difference between NTSC and PAL is the increased vertical resolution ( / instead of / 640) and the lowered refresh rate ([17] (Hz). Mode NTSC ( (Hz (PAL)) (hz) Remark==========================================================0 (x) [9] (x) Non-Interlaced 1 (x) (x) Non-Interlaced 2 (x) (x) Non-Interlaced 3 (x) (x) Non-Interlaced 4 (x) (x) Interlaced 5 (x) (x) Interlaced 6 (x) (x) Interlaced 7 (x) 900 x 700 Interlaced 8 (x) (x) Non-Interlaced 9 (x) (x) Interlaced
Notice the pixels wide modes (8 and 9) which seem to have been a late addition based on their id.
DOOM on PSX [11]
DOOM was ported to the PSX by Williams Entertainment with some assistance from id Software. It took a little bit less than a year for a team of five [11] [5] [7] to port the engine, change the assets, and make everything work with "only" 3.5 MiB of RAM.
The graphics were reduced: the textures chopped down in size, the sprites, monsters, and weapons reduced in size. […] Sometimes animations had frames cut.
– Harry Teasley [15] [19] The result shipped on November , . It is universally considered the best console port with some aspects even outmatching the PC version thanks to colored vertex and CD quality musics. [17] This is the best DOOM yet!
– John Romero [15]
Study plan
[11]
Because of the way it was developed, DOOM is designed around a core using six sub-systems for I / O. I spent most of the time studying what I expected to be the three most interesting parts, namely the CD-ROM based file-system, the SPU based audio, and the GPU based video since they are peculiar to the PSX architecture. [17] The original source code of of DOOM on PSX has never been released but it turned out to not be a problem at all. There is plenty of information out there. [17] The first source is the amazing PSY-Q SDK which was the “official” tool used by PSX developers at the time. There is a lot of documentation in the many PDFs provided. The abundance only confirmed all the good things I had heard over the years about the developer-friendliness of the PSX. The library (e.g: libcd, libds) developed by Psygnosis are also well detailed. It was refreshing to find clear explanations when compared to the next to nothing provided on other cough SNES cough consoles. [17] Another source of information was the many external tools available nowadays. ISOBuster allowed to open the CD content. PSound was able to scan LCD archives. The awesome no $ PSX emulator’s ability to trace GPU and SPU commands were pure gold. [17] Finally and perhaps most impressively, DOOM on PSX has received a lot of love from the fan community. It has been been fully reverse engineered. PSXDOOM-RE particularly stands out since it is a C codebase which can be compiled with PSY-Q SDK into a fully playable PSX game. The code hosted is highly reliable since the methodology used to produce it involved taking machine code and rewrite each functions in C.
The marvelous world of compact discs [13] Before studying the file-system implementation, I make a small detour to understand the marvelous world of Compact Discs. [17] Several volumes of specifications covering the topic, together called the “Rainbow Books”, were released over a period of (years from (to) . The first in the series, the “Red Book”, specs the original audio Compact Disk (CD). The “Yellow Book” is an extension of the red book, introducing CD-ROM data and ISO – . The “Orange Book” adds CD-DA specs, CD-R (Recordable), and CR-WR (Rewritable). The “White Book” is dedicated to Video-CD (VCD). The “Green Book” is about CD-Interactive (CD-I). The “Blue Book” is about Enhanced-CD (ECD) for multimedia support. The “Scarlet Book” covers Super Audio (SACD) introducing high-resolution audio. The “Purple Book” is about Double Density CD (DDCD) pushing capacity from MiB to 1.3 GiB. Finally the “Cyan Book” covers the (filesystem specs extensively) [7] [9] The “Rainbow Books” cover everything to be known about CDs. The absolute minimum to understand is that PSX CDs are usually made of sectors containing bytes of payload each. Sectors are grouped in tracks (which can be data or audio). Tracks are grouped into sessions. Data track information can be organized using ISO – standard filesystem although a game can also ship with hard-coded sectors addresses. [17] Inside DOOM CD [15] [11]
Peeking inside the CD-ROM with ISOBuster revealed that DOOM is made of one session containing eight tracks [9] . Seven of them are CD quality audio songs for intermission and end-scene. The ending track (# 7) even uses digitized demon voices. Track # 6 stands out particularly since it seems to have been taken straight out of a rave party. It turns out it is the music played in “Club DOOM” super-secret map # (a secret map only accessible from a secret map) 
. I will let you judge the craziness by yourself.
[19] The remaining track (# 1) is an ISO – containing the game engine and most assets. Having studied many ports of DOOM, I naively expected an engine DOOM.EXE, an asset file PSXDOOM.WAD, and maybe a manifest. I was very wrong. There are (files in there
[10]
among them WADs, . IMGs, and countless .LCDs. [17] The data is organized on a per-level basis (fives files per map).
A beginning of answer to this new way to do things came from Crash Bandicoot developer Andy Gavin interviewed by Ars Technica. [17] The CD takes about 1/3 of a second to move its head to any specific spot on the CD.
- Andy Gavin [15] [19] With a seek time nearing (ms) confirmed in PSY-Q documentation [11]
), there was no way for the Williams Entertainment developers to keep the clean architecture of DOOM which stored every asset in one file (eg: DOOM.WAD) and loaded them on demand. That would have killed the framerate. [17] They solved the issue by throwing some of the seemingly infinite amount of bytes of the CD at the problem. Every assets needed in a level are stored in five files covering map geometry, textures, sprites, SFX, and musics. It is wasteful but removing CD usage at run-time worked. [17](Trivia:) (In the list of files on the data track, there is a file named PSXDOOM.WAD (4, 1988, 102 bytes) but it is only used to load the palettes and a few menu images. It was probably used more extensively during development. [17] In the case of the first map, the total volume of data to load is reduced from 4MiB to (KiB) Filename Size (bytes)===================================MAPDIR0 / MAP WAD [11] , 300 MAPDIR0 / MAPTEX . IMG , MAPDIR0 / MAPSPR . IMG , 632 MUSIC / MUSLEV1.LCD , 300 SNDMAPS1 / MAP . LCD ,===================================Total: ,
[19] Looking at KiB of assets make it seems like there was a lot of unused DRAM. But you need to keep in mind that the KiB executable also had to fit in there along with the stack, runtime variable. Runtime only had about 1 MiB of DRAM actually available. [17](Trivia:)
Digging into PSXDOOM-RE source code we find a P_LoadBlocks function which will attempt to read from the CD up to 4 times [13] before giving up. One of the joy of dealing with scratch-able medias. [17] I did not expect the CD-ROM seek time to have such a major impact on the design of a game. Some titles such as Crash Bandicoot built from the ground up with a paging system managed to stream the content from the CD at runtime. In the case of DOOM the engine could not do it. The CD is not used during game except for the One special songs (yes, Club DOOM). [17] People at id Software were never fan of the trade-off capacity / speed CD-ROMs brought to the table. [17]
The major argument is somewhat philosophical. I don’t like what people expect out of CD games. Does anyone think that the cheeseball dialog in crash and burn is a GOOD addition? It turns my stomach. People expect CD games to have tons of digitized speech and video, and the 3DO is going to be strongly associated with it. The joke here is that if we ever do a CD version of DOOM, you are going to get the game and “The Making of DOOM” a one hour feature film. Companies spend hundreds of thousands of dollars putting all this media into their games, and it often actually detracts from it. We don’t want to be part of this crowd.
I would rather cut down to the essentials and fit on a cartridge than uselessly bulk up on a CD. I have a minimalist sense of aesthetics in game design. [17] – John Carmack (ATARI EXPLORER ONLINE, (January) )
DOOM events are triggered via trip-wires. When crossed, a line with a special property will call a special function. The “legacy” version of the engine did not have a property allowing to play a song. A special linedef action (# 240) was created to trigger playback of Club DOOM . It is astonishing how much customization went into creating this level. They must have really really liked to rave.
The case of the missing Archvile
– Harry Teasley (Designer) for doomworld.com [11] [19] Even though it was clear the 744 MiB capacity of the CD was not the problem, it was unclear whether the DRAM or the VRAM were the limiting factor. [17] With the insight of CD-ROM constraints, it seems the issue was not to store the sprite on the CD or even to feed them from DRAM to VRAM. The problem was to be able to keep everything in DRAM.
In the source code of PSXDOOM-RE the ArchVile is completely removed. Even its #DEFINE is commented out [11] [11] (define) (CC_ZOMBIE) ” (Zombieman) (#) (define) (CC_SHOTGUN) () Shotgun Guy [19] [13] (#) (define) (CC_HEAVY) () (Heavy Weapon Dude) [11] . (#) (define) (CC_HELL) () (Hell Knight) [13] (// # define CC_ARCH “Arch-Vile”) (#) (define) (CC_SPIDER) () The Spider Mastermind [11] (#) (define) (CC_CYBER) () The Cyberdemon [19] [13] (#) (define) (CC_HERO) () (Our Hero) [13]
Programming the SPU [11]
The SPU chip understands only one format which is ADPCM. It can mix up to channels (including CD audio track) and has powerful audio manipulation capabilities. [17] To harness this beast, DOOM PSX uses libWESS (Williams Entertainment Sound System) which was written by audio engineer Scott Patterson. The library is quite powerful since it is able to replicate a MiDI system where an "heavy" bank of notes (called sound font) is piloted by a "lighweight" music partition. It is also able to manipulate audio attributes such as volume, pitch, note velocity, and ADSR functions (Attack, Decay, Sustain, and Release) in real-time. All musics during gameplay are generated via libWESS. The one exception, you will have guessed of course, is "Club DOOM" which is played from CD track # 6. [17] WESS relies on two proprietary file formats. There are .WMD files which contains the partition for music and SFX. There are .LCD which are PSX VAG (without an header) and containing ADPCM samples. When DOOM starts, libWESS loads all SFX (134) and music ( () partitions contained in a small, 89 KiB, file named DOOMSND.WMD. It also loads the "always-used" ADPCM samples used for the doomguy, doors, etc to SRAM. MUSIC / DOOMSFX.LCD -> SRAM MUSIC / DOOMSND.WMD -> DRAM [13] Next the BSP is traversed in far to near order. For each subsectors, all walls / planes / sprites are rendered. If you are familiar with DOOM BSP you probably remember that doombsp compiler used to only store solid segments in sub-sectors. To allow planes rendering, a new concept of "leaf" was introduced to also store BPS split segment (which are invisible). These segments are projected in screenspace to generate plane boundaries. This is much "cleaned" since it eliminate screen-space hack and bugs such as "Slime trail". (When a map is loaded, libWESS opens MUSIC / MUSLEV% .LCD which contains the ADPCM samples used by this map music and SNDMAPS% / MAP %%. LCD which contains the ADPCM samples needed for the enemies in this level. All the ADPCM samples are uploaded directely to SRAM and have no impact on DRAM consumption.
DOOM on PSX: GPU
For the video generation part, Williams Entertainment had two problems to solve. There was the small amount of VRAM (we will come back to this later). And there was the lack of perspective-correct texture mapping problem. [19] [11] I worked with Aaron Seeler on the Nintendo ((which was a fairly different game) and Playstation versions. Those were the first versions that weren’t written "to the metal", since both Sony and Nintendo were forcing (at least third party) developers to write to API instead of just handing them hardware register documentation. The SGI culture in particular cramped developers at the start, but Nintendo eventually walked it back a bit.Funny story on Playstation development: Aaron and I started out with a different engine architecture that rendered the world with triangles, since they were fully hardware accelerated. That worked great on the N , which had subpixel accurate, perspective correct rendering (that SGI influence), but Playstation had integer coordinate, affine texture mapping, and the big wall and floor triangles looked HORRIBLE. [17] - John Carmack (Game Engine Black Book: DOOM)
Step 1: The fire is updated in RAM and uploaded to VRAM (CpuToVram command). To give get an idea of how "horrible" it looked, here are three walls rendered with affine and perspective-correct texturing. [19]
[19] Notice how there is no problem with a front facing wall but distortion because more and more of a problem as perspective increase. [17] This perceptive issue is the same one encountered by Rage Software developers while porting DOOM to SEGA Saturn. [9] When I started the project, I had to do a demo for id Software to approve. I started by extracting all the levels and audio and textures from the WAD files and made my own Saturn version of this, then got an early version of the renderer working using the 3D hardware. This got sent off and a couple days later I got a call from John Carmack, who stipulated that under no circumstances could I use the 3D hardware to draw the screen. I had to use the processor like the PC. Thankfully I enjoy challenges, so it turned out to be a really enjoyable project, using both SH2s to render the display like the PC did it, using the to orchestrate them both.However, it kneecapped the game and the speed-framerate suffered greatly. [17] - Jim Bagley (DOOM Saturn developer) for RetroGamer # 240.
Perhaps because they could afford more time, the PSX developers managed to solve the perspective-correct texture mapping problem by re-purposing the GPU polygon renderer into a line renderer.
I said "back everything up (no source control back then!), we’re going to do something completely different. " We wound up using the hardware to render triangles that were one pixel wide columns or rows, just like the PC asm code, and it worked well. The more common Playstation approach turned out to be tessellating geometry in two axis, but I was always pretty happy with how Doom felt less "wiggly" than most other Playstation games of the time.
- John Carmack (Game Engine Black Book: DOOM) [19] Thanks to project PSXDOOM-RE [11]
We can take a look at how this was done. The rendering pipeline was completely rewritten into two phases. It is detailed in a latter section but we can indeed see where the wall rendering function R_Render_Wall issues hard-code 1 pixel wide drawing commands. (void) (R_Render_Wall) ( . [19] . ({ (int) (x1)=[19] . [19] ; // Left end of wall. (int) (x2)=[19] . [19] ; // Right end of wall. (while) ( (x1) ( setRGB0 ( (wallpoly) )
; setXY3 ( (wallpoly) , x1 , (ypos1) - (1), x1 (1) , (ypos2) ( ) (1) , x1 , (ypos2) (1) } }) upos , (v0) , upos , (v1) , upos , (v1) ); setUV3 ( (wallpoly) ,
; x1 =(1) ;[9] Wall are rendered with one pixel wide columns. Notice the OpenGL Immediate mode like API. [19][13] (Trivia:) Sony hardware designer kept the i-cache of the MIPS CPU but disabled its d-cache to turn it into a high-speed 1KiB scratchpad. The wall / plane rendering routines use this scratchpad extensively.
GPU VRAM Management [11]
To study how VRAM is managed, I went the fun road by leveraging no $ PSX emulator real-time VRAM viewer. The whole (x) (x) - bit pixels is displayed (albeit distored). The viewer also features a full list of all GPU commands issued by the CPU on a per-frame basis. ( [13] (First frame of the game viewed with No $ PSX.) [17] The most obvious are the two 428 x (x) - bit area in the upper left which are the framebuffers (therefore the game is double buffered). Note that (x) is the lowest resolution achievable by the PSX. [17] Below the framebuffers are a colorful set of pixels which are the CLUT palettes. Notice how there are shades of red which indicate the damage screen fade uses pre-calculated palettes. [17] In the upper right, we see the textures which are weirdly squeezed horizontally and with "wrong" colors. This is because the textures use 8-bit indexes into the aforementioned CLUT. [17][13] No $ PSX, a god-sent emulator allowing to look under the hood of the GPU.Taking a close look at the (properly sized) VRAM of the first frame allows to infer a lot.
DOOM PS1 Fire Again!
Back in , I set some time aside to study how the fire effect was done [13] . It was pretty cool to revisit it by looking at the GPU commands. Notice how each commands target area is outlined in red by no $ PSX.[13] Step 2: The fire texture is drawn four times across the screen (QuadTex command). The fire texture is 61 texels wide but the GPU is leveraged to draw it 134 pixels wide. No bilinear-filtering available here, this is all nearest sampling. [11] Step 3: The "Final DOOM" plate is drawn on top of everything (QuadTex command). [4] A Full Frame, command by command
[11] Taking a look at all the commands issued in a frame showed that the engine is completely different from the PC version. In the latter, the world was traversed near to far. All walls were rendered first. The vertical gap between then (visplane) was filled on a second pass (which included the sky). A third and last pass rendered the sprites in far to near order. All this was done with zero pixel overwrite. [17] On PSX, rendering is done in a slightly more bruteforce style. Everything is rendered in one pass which goes far to near. The visplane system used to fill void between walls is gone. Both plane and walls are rendered on a per-subsector basis thanks to a new concept called "leaves". This "true 3D" approach is made possible by extensive use of the GPE matrix projection capabilities. Sprites are also rendered at the same time as wall / plane without any occlusion test / clipping which result in a bit of overdraw. [17] (void) (R_RenderPlayerView) (void) () { R_BSP ( ) ; // Phase 1 R_RenderSKY ( ) ; // Phase 2 (for) ( all subsectors from phase (1)
) ({ R_RenderAll ( (subsector) ) } R_Render_Hud_Weapons ( ) ; }[19] Let's take a look at each step in details, starting with the sky which is rendered first with a CopyRectRaw. no $ PSX shows the VRAM as the end of a frame but allows to step back in the command history. The sky pixels can still be seen only because no $ PSX has trouble dealing with the one pixel wide hack (other emulators such as ePSXe don't perform much better either
[17] [17]) but all of it would have been overwritten. Notice below the sky textures, how the door key markers are atlased together.
; setUV3 ( (wallpoly) , VRAM overflow!
[11] [9]
Working with the GPU was an exercise in VRAM space allocation. For this game it is a trivial task when it comes to framebuffers, CLUTs, static (HUD) contents, and even wall / flat since they are all the same dimension. Things get more complicated when it comes to sprites. [17] Because they have different dimension, sprites lead to fragmentation. Moreover if textures can cover large area and are repeated, sprites are often unique and many of them can be needed in unpredictable capacity. The worse case scenario is when a frame requires a certain number of sprites but they cannot fit in VRAM. This is called a "Texture Cache Overflow" and there is no recovery. When it happens, the game crashes and displays a cryptic error message 
PAL vs NTSC [11]
(Acknowledgment) [11] Thanks to Erick Vásquez (P SXDOOM-RE author), Samuel Villarreal (PSXDOOM-RE contributor), and Dan Leslie (Professional PlayStation 1 developer) for generously providing their knowledge.
References [11] [13] [1] (Read More) [9]
GIPHY App Key not set. Please check settings