Inside the Multiple Emulator Super System

Developing code to emulate the hardware and functionality of any computer system is a challenge. Multiply that by over 150 systems and you now have some inkling as to what development is like for MESS, the Multiple Emulator Super System.

Started in 1998, this open source program emulates the processors of scores of classic computer systems and video game consoles, all under one program. It does so with varying levels of accuracy, stability, and performance: MESS doesn't emulate certain systems as well as other programs that focus on just a single computer or video game hardware platform. Yet some of its emulation drivers, such as those that virtually reproduce the Color Computer and TI-99 home computers, are considered the best within the emulation programming scene.

If the idea of emulating several things all at once sounds familiar, that's probably because MESS is a spin-off of MAME, the Multiple Arcade Machine Emulator project. In fact, not only does the code for MESS derive from MAME, new code created for MESS has gone back into the MAME source.

MESS emulates several classic computers and video game systems, including the Color Computer 3 (Figure 1). The current lead coordinator of MESS, Nathan Woods, developed its emulation driver.

Figure 1. Color Computer 3 emulation in MESS

The current maintainer for MESS is Nathan Woods, a 28-year-old programmer from Somerville, Massachusetts, who took over the project in 2003. He spoke with us about what it takes to keep MESS in order.

Howard Wen: What's interesting about MESS is that it brings together many emulators under one program. But why do this?

Nathan Woods: The advantages are that you have one single project that can be maintained and ported as a single entity. It is very common for emulators to appear for a certain system, become really good and usable, and then have development cease. One manifestation of this problem is when you have old MS-DOS emulators that run poorly or not at all under Windows. They do not get ported or enhanced, because either the source code is not public, or there is not a critical mass of developers.

HW: How is the MESS code structured--basically, is it a single program that emulates multiple processors, or is it a collection of multiple emulators brought together under one program?

Woods: It is more like the former. MESS's architecture is the same as MAME: a very tight framework in a driver specifies how pluggable CPU cores interact via inputs and callbacks to emulate a system. This framework is the same as the framework that MAME drivers use, augmented by additions for MESS-specific functionality. There is also an OSD layer, which implements OS-dependent code that takes care of interacting with SDL, DirectX, and other OS-specific functionality.

Figure 2. MESS resurrects familiar systems from the bygone, early era of home computers, including the TI 99/4A

HW: What about code optimization? Don't performance and speed take a hit when you're emulating several processors at once under a single set of code?

Woods: You are right; it does. And for both MAME and MESS, performance is a tertiary priority under both portability and maintainability. The CPU cores have a standard interface for reading and writing to memory, and these interfaces, for the most part, work the same whether the CPU core is emulating an Atari 2600, Pac-Man, or a PlayStation.

On standalone emulators, the CPU core can be aware of the underlying memory map and consequently make certain assumptions. But that is pretty much not possible in a generalized emulator.

HW: What language do you use to write MESS? Any reason why you chose it?

Woods: C, because that is what MAME uses. MAME chose C for the reasons that it is fast, portable, and well-supported on target platforms.

HW: Does MESS use outside code or libraries that you or other members of the MESS team did not originally develop?

Woods: The MAME core would technically fall under this category. The MAME core itself uses zlib for ZIP file decompression, and Expat for XML processing.

HW: How closely related are the MESS and MAME codebases, then?

Woods: The codebases are very closely related, to the point that you can almost consider MESS to be a simple fork of MAME, just with different drivers. In fact, it is possible to build both MAME and MESS out of the same source tree. The CPU cores are the same, and the build system decides which one to build. Code is also shared for chips common to both systems. There has been more than one occasion when code was moved verbatim from MESS into MAME when MAME needed to emulate something that MESS already does.

HW: What are the issues one needs to bear in mind when creating an emulator?

Woods: You really need to understand the system you wish to emulate, as well as the techniques used by the software you wish to support. You also need to understand the system not just from the perspective of a user, but what is happening under the hood. It is not enough to know "to set up video mode XYZ, you must put these values in these memory locations;" you have to know what the video system is doing under the hood that creates these video modes. Many pieces of software out there rely on the subtleties in these video modes to work properly.

HW: What major technical challenges has the MESS team faced?

Woods: Probably the biggest technical challenge is not as related to the emulation per se, but the core. It is difficult to have a core framework that is relevant for everything from an Atari 2600 to a [computer] emulation. This is not just the emulation, but coming up with uniform ways to handle floppy disk images and system-specific controls.

Another major technical challenge is the fact that many of these systems are pretty uncommon, and it isn't always obvious how to use them. This can create a situation where MESS developers fail to "see the [entire] donkey;" instead, some of us might see an ear, another a tail, and so on.

In a sense, MAME has it easy because pretty much all arcade systems work roughly the same from the user's point of view; for the most part, they all have coin slots, buttons, and a video display. They do not have floppy drives, printers, and cassette output.

HW: You're talking about devising a unified user interface across the many computer and game console platforms that MESS emulates. What did the MESS team come up with to resolve this?

Woods: It is a matter of getting the subtleties right. When you run different emulators for different systems, you can look at the UI to see things specific for each system. Some systems require options for "soft resets" and "hard resets," and others do not. We've also came up with facilities for describing keyboard-mapping dialogs with graphics, so that someone emulating an NES [Nintendo Entertainment System] can see an NES controller when choosing keyboard mappings.

HW: Which game or computer system that you guys managed to emulate under MESS that is the team's proudest achievement? Why?

Woods: I'm not sure that there really is any answer to that question. Unlike the MAME developers, the MESS developers seem to have their favorite systems and focus largely on them. Personally, I've done the work for the CoCo driver, and am quite pleased with it. Others would probably have other answers.

HW: Which system was the toughest to emulate? And why was it?

Woods: I'd say that they are all pretty tough, and that we could spend large amounts of time on any of them. It is also determined by the demands of the corpus of software for those systems. Some systems really do not have much software that tests the subtleties of that system, while others had big "demo scenes" that knew those systems inside and out, and such software will really test the accuracy of any emulation.

HW: What features do you plan to add to the next immediate versions of MESS?

Woods: I'm writing a Windows GUI to Imgtool, our disk image manipulation utility. Other than that, I'm just chugging away in a cycle of clean-ups and incorporating suggestions from outside the team.

HW: What systems does the team plan to emulate next within MESS?

Woods: We do not really have plans to emulate new systems. Generally, new systems come from outside the development team. We've been more focused on the existing systems, cleaning up neglected drivers, and enhancing the usability of the project overall.

HW: If somebody wants to contribute to your project, what skills from them could you use now?

Woods: Anybody that has the skills to write an emulator would be welcome to either write a driver, or to update the existing driver for their favorite system. To do this, they would need to understand that system rather well.

HW: What advice do you have for those who might want to modify the MESS source?

Woods: Be bold and feel free to check it out, and feel free to ask questions on the MESS [message] board.

A major hurdle with developing MESS drivers is that the framework is very large and not documented as well as would be ideal. Often we find ourselves in a situation where someone who has the skills necessary to write a standalone emulator gets stymied by the complexity and depth of the MESS framework. In such situations, it is advised to ask for the help of the current MESS developers.

HW: What about advice for those who are interested in developing an emulator?

Woods: Make sure that you understand the system you wish to emulate, as well as your own goals. Do you intend to trade speed for accuracy? Depending on your goals, that question is up in the air.

HW: What's your opinion of the open source philosophy of program development, based on your own experience with MESS?

Woods: The most ironic thing about open source development is that it is, in certain ways, more hierarchical than traditional development.

In a software company, you typically have a few developers and a lead developer. While major architectural changes get OKed by the lead developer, the amount of code written by each developer is roughly the same.

In open source development, you often have a "benevolent dictator" who calls almost all the shots, and then a few developers that back them up or have their own sub-projects, then (for lack of a better term) the "groupies"--the large body of testers and early adopters that chime in with their thoughts. I find the resulting counter-intuitive hierarchical nature to be very ironic.

HW: I'm a little unclear as to what you mean by "ironic" here. Do you mean one might initially assume that an open source project is perceived as more "open" in terms of its organization? Why might someone think that?

Woods: That's exactly what I mean. It isn't as much that one might think, "Because this project is open, I can have control over it," as much as the role of the coordinator/benevolent dictator. An open source coordinator is probably much more likely to scrutinize every source code "check-in" than a development manager in a commercial environment.

HW: Regarding the open source style of development, has it helped to organize the MESS team's goals better than if it was a commercial project? The reason why I ask is because of the fact that MESS features such disparate code--it emulates several processors, after all--and I figured keeping everything in such a project organized can easily become, well, a mess if it's not done well.

Woods: You are correct, and there was a period of time when MESS's internals were not as carefully maintained, and that showed in the stability and usability of the final product.

I'm not sure how that particular aspect would be different under a commercial project. What would change is probably the goals themselves. MESS's brightest points tend to be lesser-known systems for which emulators are not as advanced or nonexistent; precisely the systems that would be ignored if we actually needed to make money.

HW: What are your thoughts about the present state of emulation--the hobbyist scene and/or the commercial products out in the market now?

Woods: That's a very general question. I'd probably go as far as to say that the hobbyist and commercial worlds are largely two separate entities that do not overlap, at least for now. No one is making money emulating old 8-bit computer systems, other than a handful of shareware authors, and things like VMware get the majority of their business from corporations. Things might change in the future; maybe Bochs could end up being a worthy substitute for VMware for a commercial entity, but we are not there yet.

Figure 3. MESS also emulates a number of ancient computer systems that are unfamiliar to many people, including the Colour Genie/EG-2000

Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.

Return to the Linux DevCenter.