Page Two

Implementation The block diagram of Dreamcast is shown in Figure 3. The main board includes a 200-MHz, two-way superscalar reduced-instruction-set computing CPU; a 100-MHz system ASIC with rendering core; a 67-MHz sound chip; two 64-Mbit SDRAMs; and five 16-Mbit SDRAMs. The 64-bit-wide, 100-MHz system bus between the CPU and the ASIC can transfer polygon data at up to 8 million stripped triangles per second.

Figure 3. System block diagram.

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

Yamaha developed the audio chip used by Dreamcast. We used principles of intelligent subsystems and real-time decompression throughout the design. It therefore has an ARM7 CPU core, to allow it to generate sound independently, and a memory controller for local SDRAM, which can be used to store ADPCM-compressed sound samples. This chip was originally designed using a 0.35-micron process and has now moved to 0.25 micron.

By the end of 1999 the die size and package of these chips will be as follows:

• CPU, 6.5 mm x 6.5 mm in a 256-pin ball grid array;
• system ASIC, 8.9 mm x 13.14 mm in a 500-pin tape ball grid array;
• sound, 4.0 mm x 4.0 mm in 100-pin quad flatpack.

This chipset, which is currently the minimum number needed to achieve the game console's functionality, is mounted on one side of a small (159 mm x 142 mm), four-layer printed circuit board. The two chips that dissipate the most power are cooled using aluminum heat sinks connected to a cooling fan (originally heat pipes were used). Such cooling is essential to integrate high-performance chips and other utilities in a very small enclosure.

GD-ROM

For the game program's main delivery media, we used an optical disc as it is best for mass production, delivery cost, and accommodating large-size game programs. Currently, normal CD-ROM media has a 650-Mbyte storage capability requiring two or more discs for some large games. DVD-ROM is a possible solution because of its large storage capacity, however the high manufacturing cost of the drive makes it impractical for a low-cost game console. In addition, DVD-R technology and DVD production tools are only just appearing with the price, quality, and stability required for games development.

The chosen solution is a double-density CD-ROM system called GD-ROM (gigabyte-disc read-only memory), developed jointly by Sega and Yamaha. The internal volume comprising double-density media is roughly 1 Gbyte and surrounds a normal density compact disc media near the disc's center. Mass producing this media at a similar cost to a normal CD-ROM is not difficult because the same stamping machine and materials are used with minimal changes.

It was more difficult to develop and deploy the media of the GD-R (gigabyte-disc record once) and its burner. Sega had to internally develop technologies such as the GD-drive emulator for software development and the disc copier and verifier units. Despite the development issues, we felt the benefits of using a higher density format were great, and this idea has subsequently proved itself in the field.

Modem

A system with a CPU as powerful as the SH-4 normally uses a software modem, but this is not a good solution for a real-time system such as a game console. The game application takes about 100% of the CPU's time and, consequently, cannot tolerate interruptions to graphics generation. Therefore, we chose Conexant Systems' controller-less modem, letting the modem's DSP perform the real-time communications. Depending on the communication purpose, the application can choose whether the SH-4 CPU carries out layer-2 modem functions like compression and error detection. For games, because communication latency is more important than overall data throughput, high-level protocols are not required, whereas Web browsing and e-mail require high throughput and an error-free connection.

Visual Memory

The Visual Memory design was in large part driven by the need to provide an extremely low-cost unit because we expect that most Dreamcast users will need several devices. The final design uses an 8-bit Sanyo CPU with 128-Kbyte flash ROM, a 48 x 32 liquid crystal display, audio sounder, battery compartment, x-y direction pads, button switches, and a connector that allows interfacing to Dreamcast, Naomi, and other Visual Memory devices.

Naomi

The arcade market is not as price sensitive as that of the home console, allowing us to double the system, video, and audio memory sizes. The arcade market also places greater emphasis on fast access times than on easily and quickly changeable software. Therefore, we replaced the GD-ROM with a flash ROM board. This board contains up to 160 Mbytes of data and an advanced filing system provides emulation of the GD-ROM. Because of this high degree of compatibility between the Dreamcast and Naomi, porting games is straightforward with most changes due to different market needs rather than different hardware configurations.

System environment

Dreamcast incorporates a boot ROM that is used for such tasks as Visual Memory data management, playing CD music, and system option configuration. The boot ROM's critical task is to load the main operating system from GD-ROM. A Dreamcast customized Microsoft Windows CE operating system is available that is heavily optimized for games delivery. The adapted Windows CE provides a custom DirectX API and many other Microsoft technologies such as dynamic link libraries, allowing rapid porting of games between PCs and Dreamcast without sacrificing performance. Microsoft's Visual C++ facilitates this porting by providing a common development environment between the two platforms.

Due to the high-performance, integration, and complexity of the system hardware, direct hardware programming is not a viable option. Consequently, Dreamcast supports operating systems such as Windows CE, several of Sega's own library APIs, and various middleware APIs, all of which are coordinated and distributed by Sega to ensure quality and future hardware compatibility.

Final performance

With Dreamcast, we achieved our design goal of a small video game console with a tenfold improvement in video and sound capability, coupled with expandability, flexibility, and connectivity achieved at our target cost. The video-rendering capability is 20-50 times higher than the previous generation of consoles. Recent tests by Sega, using the company's graphics libraries proved that Dreamcast uses 100% of the CPU and rendering engine's ability and delivers 6 million textured and lit polygons per second. Although game logic and physics reduce peak graphic performance, the performance of recent 3D titles for the system from many companies clearly demonstrates the platform's graphics superiority.

The MPEG-1 decoding engine, fully tuned, requires less than 40% of the CPU cycles to decode 320 x 240-resolution MPEG-1 images. This allows the creation of hybrid images by superimposing 3D polygons over the video, or vice versa. If sufficient CPU cycles are available, resolutions of 640 x 320 and 320 x 480 are also supported. Other technologies including video compression, sound and voice compression, and voice recognition are available as middleware libraries to allow development of high-quality, innovative entertainment products.

Although the system supplies only 8 Mbytes of unified memory for texture, polygon list, and video buffer, the real-time decoding engine for vector quantization-compressed texture provides roughly the equivalent of an additional 18 Mbytes for texture storage. Vector quantization texture compression is used in most games without noticeable degradation of texture quality.

The sound subsystem can generate 64 voices with ADPCM real-time decoding, and internal DSP effects, and provides ten times the performance of the previous (already advanced) Saturn sound system.

The flexibility designed into the architecture is proving effective. Software titles use the Visual Memory for both data storage and stand-alone games to enhance the product and enable parts of the product to exist away from the Dreamcast. GD-ROM titles access online servers and thereby create online gaming communities by allowing remote multiplayer gaming, sharing data, and game play results.

Table 1 summarizes the key aspects and performance of Dreamcast.

 Dreamcast has superlative graphics and sound-generation capabilities making it a well-balanced video game console. Its design promotes a new style of gaming and facilitates the creation of a networked entertainment community. It is a network terminal with the advantages of using a TV as a monitor and having a user interface with no language barrier. In the future, as new technologies become available the successful implementation of the systems flexibility concept will allow realization of many new applications.

References

1. F. Arakawa et al.,  "SH-4 RISC Multimedia Microprocessor," IEEE Micro, Vol. 18, No. 2, Mar./Apr. 1998, pp. 26-34.
2. VideoLogic, "PowerVR Technical Backgrounder," 1999, http://www.powervr.co.uk/Support/documents/pvrbacknew.pdf

Shiro Hagiwara is a general manager responsible for the system environment of video game consoles in Sega Enterprises' Hardware Development and Manufacturing Division. He focuses on development and technical support of game programming tools, libraries (including middleware, drivers, and operating systems), and the development of major LSI devices in the game console. He received a BS, MS, and PhD in electrical engineering from Hokkaido University at Sapporo, Japan. He is a member of the Institute of Electronics, Information, and Communication Engineers, Japan.

Ian Oliver is managing director of Cross Products, the United Kingdom-based subsidiary of Sega Enterprises that designed the debugging hardware, software debugger, GD-ROM emulation tools, and many other aspects of the Dreamcast software development environment. He received a BSc in computer science from Leeds University in the United Kingdom and has a background in 3D games software development.

Direct comments concerning this article to Shiro Hagiwara at Sega Enterprises, Hardware Development and Manufacturing Division, Tokyo, Japan. 1-2-12 Haneda, Ohta-ku, Tokyo, Japan 144-8531; HagiwaraS@soj.sega.co.jp.
Micro Home