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