Despite that the PS 2 is more grunty than the Dreamcast, I still wanted to point out a few areas of the Dreamcast where it had an advantage. Please note that I’ve gone to a heck of a lot of trouble to ensure these specifications are correct! If you think I may have made a slip up, let me know. (All speed related specs are provided for each console’s maximum performance, and hence may vary under a game environment.)

PlayStation 2

128-bit RISC Hitachi SH-4. 200 MHz, 360 MIPS, 1.4 GigaFLOPS (Really only 32 bit though. See below.)

(100 MHz bus, 800+ MB per second bus bandwidth for SH-4.)

128-bit RISC “Emotion Engine.” 294.912 MHz, 6.2 GigaFLOPS (Really only 32 bit though. See below.)
16 MB (26 MB total)
32 MB
3.2 GB per second
3.2 GB per second

45 MHz Yamaha Super Intelligent Sound Processor. 32-bit RISC CPU — 40 MIPS

(Full 3D surround support — 64 ADPCM channels simultaneously. Plus reverb, delay etc.)

48 Channels
2 MB
2 MB
640 × 480 pixels
(1600 × 1200 [Max for Power VR])
640 × 480 interlaced
(1 280 × 1 024 Max.)
8 MB
4 MB
16 777 216
16 777 216

3 500 000 +, fully rendered.

(The SH-4 processor can handle up to a maximum of 10 000 000 polygons per second, but it’s not officially stated by Sega. However the PowerVR restricts the output. Maximum performance in-game may reach over 6 000 000 polygons per second, but this is starting to hype the Dreamcast a little. [The extra PowerVR processor on the Naomi 2 board allows for a greater polygon output with the CPU.])

(Unseen polygons are not drawn. This enhanced feature is not supported on the PS2, and has even been quoted to be slightly better than the technique on the GameCube!)

* 66 000 000 with minimum light shading.
20 000 000 with lighting, textures, z buffering and alpha blending.
No Texture: 3.2 giga-pixels per second
Transparent textured: 120 - 300 mega-pixels per second
150 mega-pixels per second


Customised ~100 MHz Power VR 2nd Generation.
147.456MHz “Graphics Sythesiser”
DRAM bus bandwidth: 48 GB per second.
Triangular Quad Engine, real time coloured lighting, texture mapping, hardware bump mapping, true 3D fog, alpha blending, mip-mapping: (point, bilinear, trilinear, anisotropic), super sampling anti-aliasing, hardware FSAA (full scene anti-aliasing), ARGB gouraud shading, environment mapping (hardware based), hardware modifier volumes (shadow & light), specular effects - hardware translucency sorting, hardware supported z-buffer, single pass render.
(This probably isn’t a full list.)
Texture mapping, lighting, fog, bump mapping, alpha blending, bilinear and trilinear filtering, mip-mapping, multi-pass rendering.
Yes (hardware based) 5:1 (up to 8:1)
Not supported
Custom Yamaha 12× “GD-ROM” (Approximately 1 GB)


(24× CD-ROM)

Customised Windows CE (Programmer Optional)

“Energy saving” 8-bit VMS. 128 KB Memory.

48 × 32 pixel monochrome LCD

PWM 1 channel sound

Memory Card
33.6 kb per second type. Upgradable to Broadband
Probably a modem and broadband connection device that Iím not aware of.
Dreamcast “GD” & Audio CD
PlayStation 2 DVD, PlayStation CD, DVD & Audio CD

And now for some other boring mumbo jumbo:
*Despite the fact that the PS2 can display polygons at a rate of around 66 000 000 per second, it doesn’t have enough video RAM to store any decent amount with a great deal of textures also. The polygons still require about 40 bytes of memory each, and with the lack of texture compression, there isn’t enough memory to hold a great deal of polygons & textures at the same time. It may be able to draw the polygons at a fast rate, but when you don’t have all that much Video RAM to store them, it creates a “bottleneck.” The Dreamcast’s ability to only render the polygons actually visible and compress 20 - 25 MB of textures into it’s 8 MB of video RAM allows it to show highly detailed environments containing a large variety of textures & geometric detail with little effort. The PS2’s “Graphics Synthesiser” processor has no ability to decompress textures in real time, which means that full size textures have to move through a small pipeline between the 32MB main memory and the GS’s 4 MB Video RAM cache. This then translates to a lack of variety in texturing. With the Dreamcast rendering around 58 300 polygons on screen at 3 500 000 polygons per second giving a frame rate of 60 f.p.s. only around 2.2 MB of the Video RAM is used to store the polygons, where the other 5.8 MB is free for texturing & the display. That's about another 1.8 MB over the PS2's total VRAM left over. & with 5:1 compression that’s quite a good bit of room. Now lets take the PS2. At 20 000 000 polygons per second, you'd get about 333 333 polygons on screen at 60 frames per second. Hmm, but if each polygon takes 40 bytes of VRAM that’ll take over 13 MB to store them all. & you can’t store 13 MB of polygons into 4MB of VRAM & still have room for textures now can you? Although there are some programming techniques that can help the severity of the problem, such as updating the VRAM on a constant basis with new textures from the main RAM as the game plays. But this can of course be done with the Dreamcast as well.

Strictly speaking the Dreamcast CPU, and the PlayStation 2 CPU aren’t fully 128-bit. They are actually classed as 32-bit processors. Currently the only CPUs which actually go beyond the 32-bit realm are the likes of processors such as the AMD Athlon 64. The 128 bit part of the Dreamcast’s SH4 is its floating point bus, & consists of four 32-bit instructions which are executed together, apparently. [128-bit computational processing capability.] The floating point unit is 64-bit, and the integer unit is 32-bit. Check out the following address for more accurate details: )