Dreamcast Technical Pages
Console Comparison - DC vs GC vs Xbox

Here is a comparison using proportional graphs to help show the differences between the Dreamcast and the new generation consoles from Nintendo and Microsoft. The use of proportional graphs will help highlight the differences in power between these three consoles, and will help show what level of increases were made in each area from the DC generation to the current generation. Note that the comparisons below are based on maximum quoted specs, and the effective results can be a lot lower in game situations.

General Specifications
General Specifications SEGA
First Introduction November 1998
September 14,
2001 (Japan)
November 15th, 2001 (North America)
February 22, 2002 (Japan)
US Release Date September 9th, 1999 November 18th, 2001 November 15th, 2001
CPU 200 MHz
Hitachi SH-4
485 MHz
733 MHz
Intel PIII (1)
L2 Cache on CPU 0 KB 256 KB 128 KB
GPU 100 MHz
VideoLogic PVR2
162 MHz
ATI "Flipper"
233 MHz
Total External + Internal Memory 26 MB 43 MB (2) 64 MB
Game Media 12 cm
GD-ROM disk
1 GB
8 cm
optical disk
1.5 GB
12 cm
DVD-ROM disk
4.7 GB
Hard Drive none none 8 GB
Communications 56k modem
(US model)
modem & LAN expansion ethernet connector
US Introduction
Retail Price
$199 $199 $299
(1) Xbox CPU is a derivative of the PIII processor with 128 KB of L2 cache, instead of the 256 KB on a regular PIII. (2) Includes 1 MB texture cache, and 2 MB frame (draw) buffer.

Graph Calculations

Note: all the proportional graphs below were calculated like this: Largest square is 250 x 250 pixels. The smaller squares are a ratio of the larger square, based on the values being compared. 

Here is an example between the Xbox and the GC using the CPU MIPS rate:
250 x 250 pixels = 62,500 pixels
Xbox 1985 MIPS / GC 1125 MIPS = ~1.76 (comparative ratio)
62,500 / 1.76 = 35,511 pixels
Square Root of 35,511 pixels is 188 pixels. So a square of 188 pixels on each side.


DC (360 MIPS) vs GC (1125 MIPS) vs Xbox (1985 MIPS)
DC 200 MHz Hitachi SH-4.
GC 485 MHz IBM PowerPC.
Xbox 733 MHz Intel PIII.

Note: the MIPS rating is based on Dhrystone 2.1, which is a benchmark used to compare the integer capability of each CPU, and not the floating point ability.

GC result provided by Nintendo, and the Xbox result taken from 733 MHz PIII results found on the net.

CPU advances appear to be modest compared to the  GPU advances, as you can see with the fill-rate graphs below, where the DC is a much smaller square.

The Xbox GPU also has two Vertex Shaders (processors) which can do a lot of work that the CPU would have to do. The GC does not have these special graphics processors.

Pixel Fill Rate - MPixels/sec

DC (100 MP/s) vs GC (648 MP/s) vs Xbox (932 MP/s)
DC has 1 rendering pipeline.
GC has 4 rendering pipelines.
Xbox has 4 rendering pipelines.

As you can see the GC and Xbox are vastly more powerful than the DC when it comes to texturing.

The graph does not take into account the different techniques that the three architectures use to render only visible pixels (hidden surface removal (HSR)). The DC GPU uses "infinite planes", and both the GC and Xbox use some kind of early Z-buffer check. It is known that the DC's GPU "infinite plane" method is superior to the two other architectures early Z-buffer checks. So the DC is closer to the two other architectures in rendering than the graph indicates, but the difference is still quite substantial.

Texel Fill Rate - MTexels/sec

DC (100 MT/s) vs GC (648 MT/s) vs Xbox (1864 MT/s)

Texel is short for texture element. A texel is an individual pixel that is part of a texture.
DC has 1 pipeline with 1 texel unit.
GC has 4 pipelines with 1 texel unit per pipeline.
Xbox has 4 pipelines with 2 texel units per pipeline.

As you can see the GC and Xbox are vastly more powerful than the DC when it comes to multi-texturing, which is very important for light/shadow maps, bump mapping, gloss & dirt maps, etc.

The Xbox seems to be in a league of it own when it comes to multi-texturing with it's 1864 MT/sec rate. This will allow bump mapping to be standard in games, where as they were not present in the vast majority of DC games even though the DC's GPU had bump mapping capability.

Rendering Bandwidth - GigaBytes/sec

DC (0.8 GB/s) vs GC (2.2 GB/s) vs Xbox (5.6 GB/s)
All rendering on the DC is from a dedicated graphics memory, while on the GC and Xbox, the rendering chip has to share bandwidth with the CPU.

To estimate how much bandwidth the GC and Xbox have for rendering, these calculations were used:

GC: total main memory bandwidth is 2.6 GB/s - 0.8 GB/s (CPU bandwidth) + 0.4 GB/s (on-chip texture cache advantage, on-chip frame (draw) buffer and Z-buffer advantage, 1T-SRAM faster access advantage, sound chip has separate buffer and larger 256 KB CPU cache) =  2.2 GB/s

Xbox: total main memory bandwidth is 6.4 GB/s - 0.8 GB/s (CPU bandwidth) = 5.6 GB/s

Note: the above calculations are just rough estimates to give us some ideal on how the consoles compare to each other.

The GC's 1 MB frame (draw) buffer with it's 7.68 GB/s bandwidth is effective for supporting multi-sampling anti-aliasing. Has to use two 640 x 240 buffers though to achieve this, as the frame buffer's memory is limited to 1 MB. Problem with this, is that the resolution will look not as sharp. The frame (draw) buffer's 7.68 GB/s bandwidth is also very effective for supporting environment mapping allowing real environment reflections on objects, water surfaces, glass, etc. Most environment mapping on the DC was faked using a small texture that roughly represented the environment. 

As you can see with the above fill-rate graphs, both the GC and Xbox have much greater increases in fill-rate over the DC, then they do in bandwidth. Rendering is driven by how much bandwidth is available.

Total Memory - MegaBytes

DC (26 MB) vs GC (43 MB) vs Xbox (64 MB)
The smallest increase in all these graphs from the DC generation to the current generation is in memory! It is quite surprising considering how cheap memory has become, and the fact the new consoles increased polygon and multi-texturing requirements are going to need a lot of memory. Both GC and Xbox should have at least twice as much memory then what both Nintendo and Microsoft have decided on.

GC's total memory is 40 MB, but I also included the texture cache and frame buffer memories, since they do add to the total as textures can be "locked" in the cache, and the frame (draw) buffer, and Z-buffer saves having them in main memory. The GC stores it's frame (display) buffer in main memory.

Texture Space (Compressed Textures) - MegaBytes

DC (5 MB:30 MB) vs GC (12 MB:72 MB) vs Xbox (45 MB:270 MB)
Uncompressed: Compressed
Let's examine the amount of texture space available in a typical game level. Texture compression will be taken into account. The DC supports VQ compression at a ratio of 5:1 to 8:1 depending on the texture mix in memory as the size of the texture greatly effects the compression ratio. Both the GC and Xbox support S3TC texture compression with a ratio of 6:1 for 24-bit textures. S3TC advantage over the DC's VQ compression, is that it allows transparencies to be compressed also.

Let's assume a typical level in a GC or Xbox game has these requirements: 4 MB for code, 4 MB for sound, 3 MB for frame buffer and Z-buffer, and 8 MB for polygons + lighting information.

DC: 8 MB of graphics memory, so 8 MB - 1.2 MB (double buffered 16-bit frame buffer) - ~2 MB (polygon data "infinite planes") leaves 5 MB for textures. DC used VQ compression for texture data, so the 5 MB of graphics memory could hold 25 to 40 MB of textures depending on the compression ratio and that varied depending on the size of the textures being compressed. Lets assume 30 MB average for textures. Code and sound data where in separate memories on the DC, and did not impact the 8 MB of graphics memory.

GC: 24 MB of main memory, 1 MB of texture cache, and 2 MB for the frame buffer and Z-buffer, so 27 MB - 4 MB (code) - 3 MB (frame buffer and Z-buffer) - 8 MB (polygon data) leaves 12 MB for textures. S3TC texture compression at a ratio of 6:1 for 24-bit textures gives us a total of 72 MB of textures. GC has 16 MB of sound memory to hold the 4 MB of sound in our example, and that memory's extra free space cannot hold textures.

Xbox: 64 MB main memory, so 64 MB - 4 MB (code) - 4 MB (sound) - 3 MB (frame buffer and Z-buffer) - 8 MB (polygon data) leaves 45 MB for textures. S3TC texture compression at a ratio of 6:1 for 24-bit textures gives us a total of 270 MB of textures! Almost 10 times bigger than the DC!

Textures Per Frame - MegaBytes/Frame

DC (0.8 GB/s:5 MB) vs GC (2.2 GB/s:12 MB) vs Xbox (5.6 GB/s:45 MB)
External Bandwidth: Total Uncompressed Textures In Memory
Here we will see if these systems are powerful enough to render in a single frame all the textures they have in memory. The only way for a system to do this, is to have lots of external bandwidth to it's main memory. Will not bother with a graph, as it will look the same as the rendering bandwidth graph above. Note that no game will probably ever face this scenario, but it is interesting to see what console limits are the highest, and thus the easiest for developers to take advantage of.

- typical game level example listed above to provide total amount of textures available
- main memory external bandwidth figures listed above

DC: 0.8 GB/s / 5 MB = 160 FPS with 30 MB of textures (compressed) per frame or 4.8 GB/s of textures (compressed)
GC: 2.2 GB/s / 12 MB = 183 FPS with 72 MB of textures (compressed) per frame or 13.2 GB/s of textures (compressed)
Xbox: 5.6 GB/s / 45 MB = 124 FPS with 270 MB of textures (compressed) per frame or 33.5 GB/s of textures (compressed)

The magic number is 60 frames per second, and all three systems can render their entire amount of textures in memory every frame. GC is number one in frames per second, but that is only because it's total texture amount is more than three times smaller than the Xbox. Based on the typical game level example that we used, the GC has the most bandwidth to render all it's textures in memory, and extra bandwidth for other operations (polygon processing), for a game running at 60 fps. Since all the results were above 60 FPS, they all are comparable to each other, but Xbox is the best because it can do the most textures per frame, while sustaining a frame rate of 60 frames.

Why the Playstation 2 is so poor at texturing. Some facts to consider:
- PS2 GPU's (GS) external bandwidth is 1.2 GB/s (64-bit @ 150 MHz bus to CPU (EE))
- PS2 GPU cannot deal with compressed textures over the above bus in real-time, as the GPU has no hardware to deal with compressed textures. The CPU (EE) can support compressed textures, but cannot deliver those textures to the GPU compressed, it has to uncompress them and thus taking up lots of bandwidth over the GPU bus.
- Will assume 4 MB for code, 8 MB for polygon and lighting information, so leaving 20 MB for textures out of PS2's 32 MB of total main memory.

PS2: 1.2 GB/s / 20 MB = 60 FPS with 20 MB of textures per frame

A 60 FPS result is not good enough! Any polygon processing will affect that rate, so the PS2 has to either render even less textures per frame or have the game run at a lower frame rate. The more polygons the PS2 wants to render the greater the impact will be against the amount of textures it can render each frame.

Note: the PS2's GPU has 4 MB of on-chip eDRAM, and after the frame buffers and z-buffers take up 3 MB, that leaves 1 MB for textures. This extra 1 MB adds a little more to the above result, but not a significant amount.


It looks like the GC cannot beat the Xbox in a single area, as even the polygon rate and the disk capacity, which I did not show, are also much bigger than the GC. All can be a bit misleading, as the GC has plenty of polygon throughput and fill-rate to have games that have rich detailed environments. Well at least GC has the advantage of price, since it will be $199 US versus Xbox's $299 US price.

It will be interesting to see if the GC's architecture of:
Gamecube Xbox
Texture Cache Yes, 1 MB Yes (1)
On-chip Frame (draw) Buffer Yes, 1 MB No
On-chip Z-Buffer Yes, 1 MB No (2)
1T-SRAM Yes, 10 ns or lower No
Separate Sound Buffer Yes, 16 MB No
256 KB CPU cache Yes No, 128 KB
(1) Xbox's GPU does have a texture cache but it is quite small and estimated to be around 128 KB.
(2) Uses a lossless compressed Z-buffer.

is enough to overcome Xbox's 3.4 GB/s rendering bandwidth advantage.

A weakness in the GC design is that a huge chunk of it's total memory, 16 MB worth, cannot be used to hold textures for immediate rendering, as that memory is dedicated memory for the sound processor and the CPU. There is not much that even the CPU can do with this memory, as it only has 81 MB of bandwith available, due to it's small 8-bit interface. Nintendo should have strongly considered having a total of 48 MB of 1T-SRAM instead of 24 MB.

As you can see, the use of these graphs is an excellent way to give a visual representation of the differences between the DC generation and the new generation. The fact that the DC is such a small square in almost all the graphs shows that the increases being made in the new generation is quite substantial.