Published 2023-03-18
History
MAME started out as emulating arcade games, and because arcades are an extremely diverse category of hardware, MAME had to architect itself to share components within its emulator. Especially in the early days of arcade, each machine was tailored to one game and one game only. As time went on, major arcade developers (eg, Capcom and Konami) started to standardize on their machines, basically building consoles in the shape of large stand-up cabinets. They’d continue to tailor hardware per-game, but with lesser variation than the early “wild west” days of arcades.
Regardless of era, it made sense for MAME to architect itself so that common components between machines could be shared. CPUs such as the MOS 6502, Motorola 68000, and Z80 were common in 1970s and 1980s arcade machines. Rather than duplicating the CPU emulator between each machine, they made singular implementations of these CPUs so that machines sharing them would benefit from the sole source of truth, where bugs and implementation details are managed; often with enough flexibility to adjust emulation for varying clock speeds and ISA versions within a CPU type.
In the early days of MAME, it was recognized that this software architecture could be beneficial for emulation for broader categories of hardware than just “arcade games.” The MESS project (“Multi Emulator Super System”) was born of this recognition: MAME was forked so that a plethora of video game consoles and home computers could be emulated with the same sort of philosophy. The two emulators would share philosophies, and even developers, for many years, until 2015 when both projects were re-merged, shifting MAME’s development goals slightly, and becoming the program that “emulates everything.”
MAME’s goals
Broadly speaking, and has been stated a couple times already, MAME’s goals as a project is to document and emulate many machine types, without restriction to the kind of machine that it emulates. It is still best known for emulating arcade games, but it does not do so at the exclusion of anything else. In pursuit of this, MAME does not take shortcuts in emulation merely to make emulated machines run at full speed at all times. It is much more focused on accurate low-level re-implementations of hardware. This often means that the set of “playable” games on MAME, at full speed, are limited to the mid-1990s and older, but it does also mean that machines don’t suffer emulation inaccuracy issues long after full-speed playability shortcuts have been obsoleted by advances in the real hardware one may run MAME on.
Even for hardware that MAME does not presently run full speed, either due to programming deficiencies or modern CPUs just not having the oomph, MAME is performing documentation work prior to physical hardware dying, interest wanes, or intimate know-how vanishes. MAME can also provide an invaluable resource for development new software on old systems, allowing simple debugging, and provide high confidence that your software will run on the real hardware.
Many emulators, even including MAME, may take shortcuts to bypass copy protection on games. MAME itself has been removing such shortcuts, instead preferring to recreate and emulate the encryption/decryption chips whenever possible. This level of detail demonstrates the lengths that hardware vendors went to prevent copying, highlights some of the ingenuity of the systems, and is a step toward guaranteeing that inputs into MAME have the same outcome as on real hardware.
MAME is also careful to document each of its drivers as being in various conditions, from not working at all, to being fully-functional, and everything in-between. This is at least helpful when gauging when a driver should work as intended or not.
User benefits
All of the above goals play into this, but MAME does offer enticing features for end-users just wanting to play games. All that MAME has to offer is presented with a unified user-interface, consistent command-line options, and unified input assignments. Most settings can be overridden on a per-driver basis (most commonly desirable for inputs that may not be ideal), but the need to do so does not present itself often.
MAME provides tools also to manage save states, input recordings, and video dumps. Not all drivers support save states, and input recordings may desync if one does not start the machine with identical DIP switch and/or NVRAM files, but video dumps work across the board. It is rather an excellent way to manage your games, and even record them with frame-perfect accuracy (even regardless of how fast the emulation happens).
Talk is talk, nothing for machine emulation is better than showing a few examples of what you can do in MAME, with two arcade examples, a game console, and a computer:
Drawbacks
Given that MAME’s scope is effectively unbounded, it has thousands of drivers (emulated machines) available to use. Not all of these are in a functional state. Some drivers are fully functional to the point that they can be proved to have the same output as the original machine given the same inputs. Some drivers get pretty close, but don’t quite go all the way. Some drivers are barely functional, perhaps able to load trivial programs. Some drivers are entirely non-functional, won’t boot anything; often these are skeleton drivers to fill out for documentation purposes but the implementation has not yet been done.
Focus on fixing existing drivers
As might be expected, most of the fully-functional drivers are of the most popular arcade games. It aligns with the original goal of MAME, and popular games get the most developer intention. Plenty of people around to want to play Pac-Man, or Gradius, or Street Fighter II. These games have technical challenges on their own to implement in emulation, and should never be discarded, but the developer focus on them seems to drive away focus from more obscure games, and particularly from non-arcade platforms.
It may be helpful for MAME to document which drivers are in the “NOT WORKING” state, but this standard appears to have various applications. MAME also displays a large red box informing the user of a NOT WORKING status, telling the user that testing reports and bug reports are not necessary, the only thing to do is wait for the driver to improve out of this state.
In the case of the Atari ST and Nintendo GameCube drivers, both of which MAME mark as “NOT WORKING,” the drivers are unable to boot any software, even the firmware, to any sort of usable state. Indeed, the drivers are not working for any purpose. Digging into the source code, the Atari ST does seem to have significant work done for it, but the Nintendo GameCube is at the status of a skeleton driver: preliminary data about the ROMs and hardware architecture and little else.
Two more popular systems that are also marked as “NOT WORKING:” Sony PlayStation and Nintendo 64. The same red box appears, warning the user to not expect to use it as intended. However, if you do load these drivers anyway and use them, something surprising happens: they are functional enough to run popular games. These are non-trivial pieces of software. I can personally attest that Super Mario 64 is beatable in MAME, though I would not recommend it (my average emulation speed: 48%).
I do want to point out that the text in Super Mario 64 is blurry, possibly from not running at the correct resolution. MAME not declaring the Nintendo 64 driver to be in a complete state is appropriate, but I don’t believe either of them to be so incomplete as to be unplayable. (The emulated speed of the Nintendo 64 may do that: 38% in that scene is not pretty…)
MAME is full of drivers for various machines in its source code. Though this may be an exciting look into representing and preserving all that it has, reality is unfortunately less than that. With extremely popular arcade games being fully functional, and very rarely are any home computers or consoles in the same state, the best options for non-arcade machines are often other emulators. Part of this may be a cultural thing, see Focus on non-MAME emulators for my thought on that.
Even very popular and old game consoles from Nintendo are not immune from this effect. While listed merely as “incomplete,” the NES and SNES both are fairly well-documented machines with nigh-on perfect emulators available, but such emulation is not to be found in MAME. Games such as Super Mario Bros. on NES and Super Mario World 2: Yoshi’s Island on SNES have graphical issues in MAME, and these are among some of the most popular entries on the system. The Sega Genesis driver seems to buck the trend, with the best emulation of the console actually being MAME.
Performance
Let’s admit this: MAME’s focus on low-level emulation means that some machines, even if emulated correctly, will not run at full speed on present day hardware. Some code optimization may improve things, but we just aren’t going to do a low-level emulation of, say, 1 GHz processors on current hardware at full speed.
Non-MAME emulators for systems such as the PlayStation 2 and Nintendo Wii are going to continue to be desirable. Emulators focused on running these systems at full speed are going to take all the shortcuts they need in order to achieve the goal. It usually means that code doesn’t have the exact same output as the original hardware, but it does mean you are able to enjoy Super Mario Galaxy at normal speed. They’ll even use native 3D acceleration to draw 3D scenes, providing an easy method for “upscaling” old games that would not run past standard definition on original hardware.
For playing games, MAME is best used with weak (usually old) target hardware. Most arcade systems from the 1970s through 1990s qualify for this. Most video game consoles before the mid-1990s also qualify for this.
Culture
ROM sharing
Time for an elephant in the room: the MAME project, quite rightfully, states itself to be against piracy, encouraging using the emulator only for software that the user owns and has copied himself. Reasonable, right? Copyright infringement should not be encouraged.
In reality, most users of MAME don’t do this. Complete archives of all ROM images that MAME supports are readily available, and it is by far the most common way to use it. While very few legal methods of obtaining ROMs are available cheaply, it is oft ignored. There is very much a “hush hush” attitude around how people get games.
This is manifest in how the complete archives are made. Someone gets a nice piece of hardware---these days, it is most often the rare arcade boards that are added to the emulator---and it is not just supported in MAME, but also available in the complete archive sets. It is extraordinarily unlikely that random other people happen to have the exact hardware that was just added, instead the files are sourced by that original person.
I am all for preservation of old software and hardware of all kinds. I am also all for copyright reform (different topic…), but it is unfortunate that preservation necessitates copyright infringement.
Focus on non-MAME emulators
It is sad to say, and I would like to refrain from actually blaming anyone, but I do believe that reverse-engineerers and emulation developers preferring to make their own projects rather than do it within MAME, is a large reason that MAME gets to be lacking in some of its areas. For arcade systems, MAME is the first program to come to mind. When someone wants to emulate an arcade machine, he’ll pick MAME to do so.
When it comes to video game consoles, MAME is almost never the target chosen. Instead, we have nearly perfected low-level NES emulation in Nestopia, and low-level SNES emulation in Ares (formerly Higan, formerly bsnes). These are fantastic emulation projects, I use them myself, but it is a little bit frustrating that each independent emulation project constitutes a new user interface, new limitations (does it allow input recording? video dumping?), and philosophies.
If instead MAME were the target of any given computer and console emulation developer, we might actually have a really good universal interface for emulating just about anything you’d want to emulate.
Just about. High-level emulation for things like Nintendo 64, Wii, PlayStation 3, et al, still have a good place. From running at full speed to rendering 3D graphics at higher resolutions than the original systems, they can provide an excellent environment for enjoying games from these systems. It’s just unfortunate that in the quest to make commercial games run at full speed, it is rather easy to find homebrew (and a few commercial games, even) that do not function on these emulators and only function on the original hardware. Even if MAME would not run these systems at full speed, a functioning driver could still provide a huge benefit for developing homebrew software, and an avenue for studying why some software may not function in a high-level emulator.
Conclusion
I like MAME a lot. I would not write about it for so long if it were not so, but problems in the project make it feel like it comes short of what it could be. Much of it is related to the culture around emulation in general, and developers not focusing on the project. That’s not a bad thing per se, but it seems often like MAME is overlooked in favor of starting up yet another emulator project.
I would honestly love if MAME was good enough for most of my emulation desires, assuming that a low-level emulation approach is quick enough to still play games at full speed. It is a shame that I still have to reach for independent emulation projects to achieve what I really want.