Tuesday, January 17th, 2012
The SEGA Dreamcast has always been one of my favorite consoles. It had a ton of great games, powerful hardware for its time, and lots of innovative — even if underused — features like online support and the VMU.
It's impressive 624 game catalog included exclusive titles like Soul Calibur, Shenmue, Sonic Adventure, Power Stone, Crazy Taxi 2, and Mars Matrix which gave the Dreamcast a reputation for offering a diverse and innovative library that appealed to both hardcore and casual gamers, making it a beloved console despite its short lifespan.
In 2008 I built a prototype emulator for the Dreamcast that could run on the Xbox 360. The goal was to salvage as many Dreamcast games as possible and offer them a second life with improved visuals and online play through Xbox Live. Publishers could make their Dreamcast games available through the Xbox Live Marketplace and run on existing Xbox hardware without modification.
The idea spawned from a conversation I had with Peter Moore at Microsoft in 2006. Peter was at Sega through the Dreamcast launch, and Microsoft had actually collaborated to bring Windows CE and DirectX to the platform almost a decade earlier. In several ways, the Xbox project had advanced the original vision of the Dreamcast through its focus on online, community features, competitive gaming, and of course, challenging the dominance of Sony.
It seemed like the Dreamcast catalog could thrive within the Xbox ecosystem.
After several months of spare time development I pitched Xbox executives on the concept in May 2008. I demonstrated a couple of homebrew Dreamcast games running in 720p and gained initial support to experiment further. Sega was contacted to gauge their interest while a business analysis was conducted. While the technical feasibility was proven, we ultimately didn't pursue the project because the business justification wasn't there. Several factors contributed, including:
Launching a commercial emulator is very difficult. We launched the Xbox 360 Fusion emulator in 2005 to enable backwards compatibility with original Xbox games, and were still dealing with a large maintenance burden years later. Fusion was a very large, challenging, and costly effort despite Microsoft owning both the target and host platforms. The company experienced the vast difference in engineering effort required to build a prototype that sort of works for a few games, and a commercial emulator that supports a large number of games in a stable and fully playable manner.
Market value. The overwhelming majority of Xbox 360 gamers were focused on modern titles like Halo and Gears of War. While some Dreamcast games like Soul Calibur could draw attention, most of the Dreamcast catalog would probably go untouched at any meaningful level. It also turned out that many of the most popular Dreamcast games had either already been ported to Xbox, or had sequels in development.
Our analysis told us what the publishers had already understood: games with a high enough projected ROI were ported individually, and the rest were not. And... that's pretty much the end of the story, but if you'd like to hear more about the prototype itself, read onward!
Although an ambitious goal, I had a few advantages in that I worked at Microsoft on the Xbox 360 graphics team, had access to internal tools, and could seek help from Sega if necessary. Several members of the Dreamcast Win CE crew were also still around.
And if this all wasn't enough, Randy Linden had recently joined the Xbox team and was just a few steps down the hall from me. It would be impossible to capture the depth of his emulation experience in this post, and his advice on several occasions helped simplify my architecture and avoid pitfalls.
Nevertheless, this project was still extremely challenging due to the asymmetries of the two hardware platforms, the highly tuned nature of the 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 ton 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 fun learning experience. It produced a prototype and proof of concept, as well as a number of interesting demos and videos. 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.
