Tuesday, January 17th, 2012
In 2008 I built a prototype software emulator for the Dreamcast that could run on an Xbox 360. Although an ambitious goal, I had a few advantages in that I worked at Microsoft on the Xbox 360 project, had access to internal tools, and could seek help from Sega if necessary. This project was challenging however, due to the asymmetries of the two hardware platforms, the highly tuned nature of the target games, and the security models of both platforms.
Hardware Emulation
My initial concept was to design the emulator to be as high level as possible. This meant that instead of emulating the intimate details of each component of the system, I would try to intercept messages as early as possible and provide a high level alternative. For example, the emulator carefully watched calls to known operating system routines (such as memory and file IO), and then simply detoured execution off to native Xbox 360 routines to service the requests. In order for this process to work however, I would still need hardware emulation of many core components such as the CPU, GPU, memory, and the AICA sound system.
The Sega Dreamcast used a Hitachi SH-4 CPU, which had a 16 bit instruction size, bankable registers, delay slot execution, and a basic floating point unit. The CPU also supported traditional memory management systems but luckily these were not needed for games (only for WinCE). In almost every way, the PowerPC 970 CPU of the Xbox 360 was significantly faster and more flexible, which made CPU emulation relatively straightforward.
The graphics was the hard part. The Dreamcast used a PowerVR2 tile based renderer which was significantly different from the ATi "Xenos" chip in the Xbox. This meant that a significant amount of CPU work was required in order to translate drawing commands, textures, and graphics resources into formats that the Xbox 360 GPU could understand (and to do so quickly).
After a few months the basic hardware components were running (with varying levels of completeness), and the emulator was able to boot and execute simple test programs. This stage of the development process was greatly aided by the Dreamcast homebrew community. Having the ability to write, compile, and test with simple Dreamcast applications was an invaluable way of debugging the emulator.
After several more months of development and testing of the emulator against basic homebrew apps, I was ready to begin testing against full homebrew games. At this point I encountered the second significant challenge of this project: the highly tuned nature of the games.
Title Tuning
When developing games for the PC or any highly abstracted platform, the developer must concede a certain amount of flexibility and power in order to ensure that their game functions properly across all hardware that conforms to the platform interface. On a console however, with a fixed hardware platform, developers are often free to "fit" their game more closely to the hardware.
Historically, as consoles have become more complex, manufacturers have chosen to provide a more abstracted interface to developers. This reduces -- but does not eliminate -- the developers' ability to "overfit" their games to the console. In the case of the Dreamcast, with its single core architecture, many developers were tempted to rely upon specific timings for bandwidth and processing operations in order to glean additional performance. This meant that for several games my emulator needed to be cycle accurate in order to maintain the integrity of the game state. If the emulator ran too quickly or too slowly, cameras would clip through walls, physics simulations would be off, and the game would be unplayable.
Security
The final challenge to the development of this emulator was the security models of both platforms. At the time I was unable to find any commentary on the runtime security systems of the Dreamcast, so much of what I learned was through simple experimentation. The boot process of the Dreamcast appeared to involve a number of integrity checks. The system would write a series of values to MMIO registers, and then expect a particular response within an allotted time interval. If the response (fabricated by the emulator) failed to provide the correct value, the system would hang.
Similarly, the security model of the Xbox 360 was designed to prevent execution of unauthorized code (games, operating systems, etc.). A byproduct of this is that games are unable to allocate code pages and execute dynamically created instructions. For the emulator, this meant that JIT reassembled code was impossible, and instructions would need to be interpreted -- at a significant performance cost. (Note that I considered alternatives involving pre-processing of the Dreamcast binaries but never pursued them.)
Conclusions
The construction of the emulator was a tremendous learning experience. It produced a prototype and proof of concept, as well as a number of interesting demos and videos. If I had to sum the high level lessons of this project, it would look something like:
The process of building an emulator (often) involves a tremendous amount of research
The larger the asymmetries between the host and target platforms, the greater the effort required to build a well performing emulator
GPU emulation may require a large amount of pre-processing cycles on the CPU
Properly emulating a single game is a huge achievement. Emulating the entire game library may be orders of magnitude more difficult
The Dreamcast is a difficult system to emulate, but it is by no means impossible. Modern PCs have more than enough performance to get the job done with a high degree of accuracy (as demonstrated by nullDC and a number of other excellent HLEs), and it is the emulation community that manages to sustain older platforms long after their time has passed.
Unfortunately, the task of emulation becomes more difficult as we move into the multi-core and massively parallel era of console systems, but with recent breakthroughs in JIT compilers and other research, there's always reason to be optimistic.
More Information
For more information about this project, see my Dreamcast Emulator Project page.
