Of course this does not mean we cannot overclock it...
Well, its rather safe to say, that the SGX is capable of 166Mhz without using the term overclocking. Also, another little detail i noticed, some doc's refer to the SGX, some talk about 10M, and other 14M, but few have any clock reference to it. If you assume the 10M are at 110Mhz, and recalculate to 166Mhz core, its almost 15M ( 14.9xx ). Might indicate the discrepancy between reports based on this SGX core.
From the look of it, they downclocked it to 110Mhz, for extra power saving. The same as the Cortex A8, running at 500/600Mhz, while most accounts seem to confirm that 900Mhz is no sweat at all.
Also, found this in a old thread of 2003 regarding the DC:
Topic @ http://forum.beyond3d.com/showthread.php?t=6199&page=4
"How Many Polygons Can the Dreamcast Render?
Let's help clear up some of the confusion that centers around the Dreamcast's polygonal rate. When SEGA first introduced the Dreamcast back in November 1998, they indicated that the machine could do 3 million polygons per second, which is a sustainable rate that could be gotten through software running on the machine at that time.
I shall direct your attention to this article at IEEE Micro, of which these quotes come from:
The CPU was clearly an important part of the Dreamcast specification, and selection of the device was a lengthy and carefully considered process. Factors considered included performance, cost, power requirements, and delivery schedule. There wasn't an off-the-shelf processor that could meet all requirements, but Hitachi's SH-4 processor, which was still in development, could adapt to deliver the 3D geometry calculation performance necessary. The final form has an internal floating-point unit of 1.4 Gflops, which can calculate the geometry and lighting of more than 10 million polygons per second. Among the features of the SH-4 CPU is the store queue mechanism that helps send polygon data to the rendering engine at close to maximum bus bandwidth.1 The final device is implemented using a 0.25-micron, five-layer-metal process.
The system ASIC combines a PowerVR rendering core with a system bus controller, implemented using a 0.25-micron, five-layer-metal process. Imagination Technologies (formerly VideoLogic) provided the core logical design and Sega supplied the system bus. NEC provided the ASIC design technologies and chip layout, including qualification for 100-MHz operation. Fill rates are a maximum of 3.2 Gpixels per second for scenes comprising purely opaque polygons, falling to 100 million pixels per second when transparent polygons are used at the maximum hardware sort depth of 60. Overall rendering engine throughput is 7 million polygons per second, but in Dreamcast, geometry data storage becomes the limiting factor before pixel engine throughput.
You're only as fast as your slowest component, so the DC is rated at 7 million polygons per second maximum sustainable rate, and in a game situation, would most likely be rated around 5 to 6 million polygons per second depending on how good a top developer would be at squeezing performance out of the system. I consider a rate lower than 7 mpps, simply because other game code has an effect on the polygon rate. The more complex the game AI is, the lower the polygon rate that the machine can achieve.
Note, the above quote contains some information, which could be easily misunderstood, as the above article states:
Fill rates are a maximum of 3.2 Gpixels per second for scenes comprising purely opaque polygons, falling to 100 million pixels per second when transparent polygons are used at the maximum hardware sort depth of 60.
No 3D game today even comes close to having an opaque overdraw of 60 times! It's more like 2 to 3 times of overdraw, so the comparative pixel rate would be 100 million to 300 million pixels per second maximum. I indicate comparative, as that means how an "infinite plane" architecture would be compared to a traditional architecture that renders every polygon in a scene.
Here is a very interesting comment:
Overall rendering engine throughput is 7 million polygons per second, but in Dreamcast, geometry data storage becomes the limiting factor before pixel engine throughput.
Let see, if the Dreamcast can render more polygons then it can store, and I will use 6 mpps as an example:
6,000,000 (polygons) / 60 (frames per second) = 100,000 polygons per scene
100,000 x 40 Bytes (size of polygon) = ~4 MB
Since the Dreamcast only has 8 MB of video memory, that is a lot of memory!
8 MB - 1.2 MB (640x480x16-bits double buffered frame buffer) - 4 MB (polygon data) = 2.8 MB
Only 2.8 MB left for textures, and even with VQ compression that is not very much. At 3 mpps per second, there is 5.8 MB available for textures, and that is much better. Just shows you, that there is not much point in creating a game engine on the DC that does more than 3 million polygons per second. Anyway 90 percent of the developers out there cannot even get over a million polygons per second on the Dreamcast."
The last part seem to confirm what drkIIRaziel was talking about.
maciek_urbanski, the site is back online from logicpd: http://www.logicpd.com/products/som/ti/omap35x