Retro FAQ: MAME

This is a partner series to our Retro Let's Play FAQ, aiming to assist people finding ways of playing old games from these old systems. All talk of resolutions, PAL vs NTSC and upscaling are covered in the Retro Display Solutions thread.

History:

MAME stands for the Multiple Arcade Machine Emulator. For those not familiar with emulation: it's a method of writing a software layer that intercepts machine-language for a specific CPU, and translates that on-the-fly for a different CPU. Often it requires a host processors many times more powerful than the one being emulated, but the aim is to be able to run native software for very old CPUs on modern systems, and interact with them real time. It requires both the CPU emulation core as well as the Read-Only-Memory (or "ROM") data to accurately emulate the full system.

Beginning life in 1996 as "Multi-Pac", the software written by then solo Italian developed Nicola Salmoria was designed to be modular, and emulate Pac-Man (known in Japan as Puck-Man) as well as a number of clone games and others running on similar hardware.

Soon the project grew in scale, and began emulating a number of CPUs (and games as a result). In parallel, a similar project named MESS (Multi Emulator Super System) was being developed, using MAME code to emulate popular CPUs used in early home computer systems. In recent years, MAME and MESS have merged into the main MAME tree to see the project explode, with dozens of very clever developers contributing to the project.

Today, the project is hosted by "MAMEDev", the team who control the project direction and do the bulk of the development. Regular updates are posted to their "whatsnew" page with progress on various cores, games, decryption, ROM dumps and other efforts:
https://www.mamedev.org/release.html

Project goals:

MAME differs to many other emulators in that it aims to put accuracy above all other goals - including the ability to play a game at all. This means that all emulation is always done purely in software, never using hardware acceleration (3D GPU offloading, etc) as that frequently results in emulation errors in the name of framerate speedups. Despite some criticism from a vocal minority, MAME has proven to survive with this design, with many games once considered "unplayable" due to their design eventually running fine as hardware advancements catch up.

As would be expected, emulating an enormous number of CPUs (everything from common-as-mud Z80 and M68K CPUs to obscure custom chips and anti-piracy encryption systems) is no trivial task. Frequently emulation of certain architectures will stall until a "breakthrough moment" occurs, and an explosion of a particular architecture, game or family of software will occur. When this happens, often more features, chips and components of a game are emulated, and typically MAME performance will *decrease* with each release. While this seems counter-intuitive at face value, it demonstrates that each release is more and more accurate, but at the same time means that for the latest release, typically more powerful hardware is needed.

Conversely, older releases of MAME can be used to run on slower hardware (say, a Raspberry Pi or similar low-end hardware), as long as we recognise that those releases may also include inaccuracies in the emulation. It's always recommended to try newer builds first, however, as they often fix game breaking bugs found in older releases.

Often these builds are labelled either by their version number or year. For example, RetroPie will include MAME 0.53 (an older build before MAME jumped to full 32bit graphics rendering, which runs much better for very old 80s games), or "MAME 2003" (an older build from that year that can play more games from the 90s without requiring enormous processing power).

It should be noted that as the emulator continues in development, often faults in the ROM-dumping process (where physical ROM chips are copied to files) are discovered, and new ROM dumps are often required. With that in mind, older builds of MAME need matching ROMs. So be sure to match your MAME ROMs with your MAME version so that games run properly.

Builds:

MAME itself is open source (previously under its own license, more recently switching to the GPL), and as such many "builds" exist. While it's always recommended to stick with the official build if you're on a modern desktop, many other builds exist to satisfy niche requirements. An example of some builds include:

WolfMAME: includes tools for saving replays of games to share for hiscore attempts

GroovyMAME: Designed to spit out arcade-native resolutions (called "modelines" for analogue displays) to use on arcade monitors. Requires either custom video cards capable of the low-res native arcade modes, or hacked drivers that can under-clock modern GPUs to force low-res modes out

GroovyArcade: A complete Linux distribution designed to host GroovyMAME and use arcade-native resolutions from standard PC hardware.

<Todo - fill in more>

Displays and graphic options:

MAME offers an enormous volume of output display options. Not just for retro analogue displays, but also for modern high def displays. For users of the latter, simple pixel-scaling old games that sat somewhere in the 320x240 resolution range results in images with very jagged edges that are far too sharp for modern displays that are many times higher in pixel count.

Luckily many of us today have PCs with quite powerful image post-processors (also known as "GPUs"), and even on low-end hardware like the Rasberry Pi, realtime effects can be applied to simulate the arcade CRT displays of old, making game artwork look and feel like it did "back in the day".

These post-processing options are entirely subjective, and there's no right or wrong option for these. For many, scanlines and blurring options not only trigger a strong sense of nostalgia, but also bring down the brightness and sharpness of retro graphics to be more inline with what was the designed standard at the time of release.

While simple options like scanlines (making every second horizontal line dark and/or black to simulate the missing line of information when a CRT ran in low-res progressive mode instead of interlaced -see the "Display Solutions Thead" linked at the very top of this document) and bilinear filtering (a fast softening affect for scaled 2D graphics) are some of the simpler effects, MAME employs a tool called "BGFX" to deliver a complex 3D shader language that allows much greater depth of customisation, including things like simulating CRTaperture grill, phosphor bloom, edge geometry curves, and more. Again, these are all subjective and completely unnecessary to enjoy the games, however they can convincingly add to the experience for those who enjoyed the games originally in arcades, or those wanting to simulate that effect for themselves.

Here's Street Fighter III: Third Strike emulated with standard pixel stretching (click for bigger to see the 1920x1080 full HD screenshot):



Now compare with the BGFX CRT shader, including CRT geometry and aperture grill, scanlines and phosphor bloom:



Again, all entirely subjective, but thanks to our powerful modern GPUs, it adds no impact to the actual game emulation.

Controls:

MAME allows for extensive control mapping, and the sheer variety of games (well over 6000 unique games at last count) means that there's quite a lot of different types of devices emulated.

An example of just a few of the inputs that can be used with MAME:

Joysticks and buttons:



Includes both digital and analogue joysticks and arcade buttons. These come in all sorts of styles, like the Japanese ones pictured to US, Australian, Korean and many other styles. Most arcades came with these controls, and games can easily be played on keyboard or gamepad due to the digital nature of the inputs.

Spinner:



A device that rotates on a single axis in complete 360 degrees. Can be smaller spinners that are controlled by fingertips, through to 360 degrees steering wheels for games like overhead racing games.

270 degree wheels:



A wheel locked to around 270 degrees of motion (unable to turn in a full circle). Popular with modern first/third person racing games

Trackball:



A large ball with two axes of analogue motion. Similar in control to a computer mouse, however it allows for the player to spin a heavier trackball to give it a lot of momentum.

Light guns:



Whether via specific light gun hardware, or just mouse pointer, MAME allows for light gun emulation for many arcade gun games.

ROM verification:

I'll include a separate post later on detailing how to verify and rebuild ROM sets between versions of MAME. It's quite complex, and deserves its own dedicated post.

For anyone wanting to do their own reading, head to the ClrMAMEPro website and read their documentation.

Hardware:

Like ROMs, hardware for MAME is an enormous subject in and of itself. I'll aim to cover links to popular vendors and hardware you can use to enhance your retro game playing on MAME in following posts.

 

Last year Bob from RetroRGB interviewed me on his retro-gaming focussed YouTube channel. Here's 90 minutes of dry and boring technical chat we had about lots of things, including MAME.

 

Hmm ads in the start menu...you gave the fuckers the idea. lol

 

Configuring in-game controls

As per the original post, MAME supports all sorts of hardware and inputs. Keyboards, mice (and mouse emulators like trackballs and light guns), joysticks (including standard PC-compatible game devices and console controllers) and many more.

Configuring MAME can be simple enough for a single game, or even many games of the same basic input type (say, if all you have is a joystick and only plan on playing games of that type).

For all the screenshots following, click for larger images.

By default, the "Tab" key on the keyboard brings up the MAME options menu. From here, you'll have several menus.



Firstly, decide if you want to change the controls only for the game you are playing, or for all games. This is useful if you want to define a default (say, standard joystick controls for the bulk of games) or specific exceptions for a single game.





Next, set your UI controls, in particular the buttons that will move around in the menu and select things. By default these are the arrow keys and the enter key on your keyboard. You can change this to whatever you want, like your joystick and first fire button, if you're on an arcade machine. To do so, highlight the control item, press "enter" once, wait a second for the UI show it's selected, then push the key/button you want once. Note that if you change what the UI controls are, this will take effect immediately, and you'll need to switch to that device for further control inputs.



Outside of the UI controls, you can change the in-game controls for each player. MAME supports up to 10 players, which is possible for some of the larger multiplayer mahjong games (not exactly exciting games if you ask me, but each to their own). Typically most arcade games are 1 or 2 player, with quite a few good 3 and 4 player titles out there too.

MAME will store these configs in plain files, which you can edit by hand or copy to other systems. These are stored by default in the first path defined in MAME's "cfg_directory", defined in the mame.ini config text file (easily edited with any standard text file editor). If you don't know what this is, the command "mame -showconfig" under any OS will show you what MAME thinks is its current configuration at the time of execution.

The default controls go into "default.cfg", and per-game/machine config into a file that matches the ROM name (for example, in the screenshots I'm using the Street Fighter III: Third Strike, No CD ROM, which is named "sfiii3n.zip", launched via "mame sfiii3n", and has config stored on my Linux box in ~/.mame/cfg/sfiii3n.cfg . Windows builds will typically store it in a child subdirectory under where ever the mame.exe file is called "cfg", and in the same romname.cfg location.

You can edit these by hand, or delete them if you want to go back to defaults and start the input configuration process again.

MAME Front Ends

MAME itself is a largely command line driven, although recently a very rudimentary menu was added to launch games.

Typically, however, you launch MAME via what's called a "frontend". This is a separate piece of software that is typically customised to how you're presenting MAME - whether it's just loaded on your desktop PC and you have a standard mouse/keyboard interface, or if it's loaded up on an arcade machine and you only have a joystick and buttons to navigate and choose games.

I mentioned in the first post that there are different MAME builds, and some of these do actually contain a GUI. The most notable, and most "official" is MAMEUI, which includes a simple Windows GUI built in. The frontend can be downloaded and installed separately as well, known as IVPlay (maintained by long time author John IV).

http://www.mameui.info/

John IV also maintains an excellent benchmarking page covering MAME performance of different games on different CPUs, which I'll cover more in a later post.

Back to frontends - plenty to choose from, all of them ranging in functionality and complexity. Ready-to-use build like RetroPie contain pre-configured frontends like EmulationStation, which is also a frontend for many other emulators.

Some other popular frontends include:

HyperSpin - a very heavyweight but very pretty frontend supporting Windows and Android only. It supports movies (either as movie files or MNG (moving PNG) files) as previews for games. Very nice to look at, but often many times larger in size than your OS and ROMs combined!

Attract Mode - an open source alternative to HyperSpin, with support for most operating systems (Windows/Mac/Linux/RPi)

Advance Menu - a much older and more basic frontend, it was built as part of the "AdvanceMAME" project, which was an older build designed to support low res (320x240 progressive scan) arcade CRTs. It uses fonts and designs more suited to those resolutions.

 

Excellent thread Mr Elvis with good info for those not familiar with MAME, I love playing all the old games, keep it up.

JSmith

 

pretty sure that mame options menu is where i need to go to fix my mortal kombat audio i just haven't gotten around to googling it yet.

 

I'll go into more detail later, but some things to play with:

* "~" (tilde) brings up MAME's internal volume controls, which can adjust audio per channel. Keep pressing ~ to cycle through options.

* F2 brings up the service menu for most games, in which extra options can be tweaked/set. MK games in particular often need to be reset to factory defaults to work properly. Games like MK and NBA Jam often have volume controls in here, set by software.

* 9 and 0 do different things for different games. For some it's a different coin insert mode, for others a service menu. F2 is more common, but 0/9 are needed for some

* Tab, and then navigate to "dip switches". These will set hardware dip switches if the original arcade board had them instead of a service menu (some had both). You'll sometimes need to exit the game and re-enter to apply these, or just press F3 to reset the game.

 

MAME continues its amazing pace of development, releasing more games and machines being well emulated.

Along with tonnes of new Apple II stuff, the most recent release continues efforts on Game and Watch emulation, including the more expensive tabletop/panorama versions.

Add in a high resolution marquee graphic, and the effect is quite spectacular.

 

Did groovy mame replace advance mame? I never really heard of groovy mame, used to use advance mame to run the arcade monitor in my upright, with custom Rez/clocks running through an S3 virge card. Command line only, but worked soo awesomely for Wonder boy.

 

They're different projects with the same intention (accurate video modes to feed to real CRTs). They both work well with 15KHz and 31KHz+ monitors, where the latter can be double-scanned (two lines sent instead of one, for zero-lag upscaling).

AdvanceMAME is a much older code base. On Linux, AdvanceMAME requires svgalib to work with generate real modelines on an arcade CRT monitor, which itself has been left stale since about 2000-ish. It could use X11 as well, but early versions of that didn't support dynamic modeline generation.

On Windows, AdvanceMAME needed help from something like PowerStrip or other modeline generators to have the modes pre-made, and then could call them at runtime.

GroovyMAME is a much newer code base, and uses a tool called "switchres" to handle the calls to the OS to generate modelines on the fly.

Under Linux, there's GroovyArcade, which is a pre-baked, ready to go distro that has pretty up to date kernel/drivers for supported hardware (ATI/AMD hardware is always your best bet, as the open source drivers and ability for the cards to use a low pixel clock mean they work best on average with real 15KHz CRTs). It can be tested as a LiveCD/LiveUSB, or installed to a hard disk.

Under Windows you still need help from some third party drivers. CRT_Emu_Driver is one set of drivers (again, AMD/ATI only), and Soft15KHz is another that *should* support most cards, however it will depend on the cards pixel clock.

If you're running a digital display (LCD, OLED, etc) in your MAME setup, don't bother with these. But if you're running a CRT and want accurate modelines, GroovyMAME is a good way to get a highly authentic experience.

 

Thanks, that would explain it, last I had my cab running was in 2000.. holy crap... 19 years ago..
Thanks again for the clearup.

 

Your retro toy is now retro itself.

 

this reminds me of a video I saw from Izzy Nobre the other day he was revisiting the Dingoo and said that his retro emulation device was now officially retro - haha.

 

Bumping this with two videos I've done for Retro Let's Plays in the last few months.

The games are largely inconsequential, but within there are tips in these on how to
* Download and install MAME
* Find games on archive.org
* Modify your config files
* Configure controls like gamepads and joysticks
* Use CRT shaders for retro aesthetics
* Configure rotating displays for vertical games
* Use Gsync/Freesync/VRR for smooth gameplay at weird arcade refresh rates like 57 or 59 Hz
* Use the new "low latency" input mode for faster action games

 

Bob from RetroRGB had a long chat with David "Haze" Haywood, 20+ year veteran MAME developer. Loads of content discussed about Haze himself, MAME the project and MAMEDev the team behind it, how he started in the project, how he plays games, etc.



If you need audio-only (no need to watch the video, this one is pretty good to listen to in the background), there are links to downloads and podcast sites in the RetroRGB article:
https://www.retrorgb.com/interview-with-david-mamehaze-haywood.html

 

Due to me losing a few drives. I have to redownload some things. Things seem a bit different then when I last did this.

I just need merged set and datfile? What's this sofware list?

 

ROMs typically come in three pack styles:

1) Split. This is where every individual game/clone/bios has a separate ZIP file, however you need multiple zip files to run certain games. For example, "Street Fighter II: Champion Edition" (sf2ce) was mostly the same as the original "Street Fighter II: The World Warrior" (sf2), but with a few extra chips that arcade operators could add on to existing arcade boards to cover the. With split ROM sets you need both sf2ce.zip and sf2.zip to play Champion Edition.

2) Non-Merged. Each zip contains everything you need for individual games. sf2ce.zip doesn't require sf2.zip. These are simpler, however waste a lot of space with duplicate data.

3) Merged. Each ROM is a parent, and all clones live in the parent. However there is no duplication. So "alcorn.zip" contains all the files required for it's clone "Slap Fight", and there is no separate "slapfght.zip". But "sf2" and "sf2ce" are separate due to not being clones. This means a lot of files appear to be missing (typically only the "World" titles exist, with US/JP "clones" with different names not having separate zip files), and this confuses poorly written front ends that can't read MAME's XML output to find the correct information (good front ends that can read the XML file are fine). It is, however, the most space saving method.

Any of the above can be converted back and forth with ROM managers like ClrMAMEPro or others. You don't need all three.

DAT files can be generated directly from MAME via the -listxml flag.

"Software List" is the console/computer pack. MAME merged with sister project MESS in 2015 to save wasted duplication effort. Despite the name, MAME now emulates everything. The "Software List" pack is the official collection of stuff MAME knows about in its format. Typically not worth getting due to the extreme size.

I tend to get the merged set via torrent for space saving, and it means I can update it in the future by renaming the folder, pointing to the new torrent, and only the changed files come down (typically a few MB only, instead of the full 70GB all over again).

 

Edit: "DAT file" refers to the databases of ROMs and/or software files needed to emulate a game on a machine. The MAME software ships with these databases, tied to a specific version of MAME (where newer versions usually only add a small amount of new stuff). So if you have a "merged set" for a specific version of MAME, it should be able to find everything.

 

"Software List" specific to MAME isn't a DAT file. It's a ROM set.

Confusing name, but they called it that because they're not "ROM" formats per se (a mix of floppy disk images, hard disk images, optical ISOs, etc).

CHDs are the final data type. These are "Compressed Hunks of Data", typically hard disk or optical drive data for arcade systems, using MAME's very clever compression tool that attempts to compress each chunk of raw data using 3 different compressors, and keeping the smallest result. Time consuming to create, but can be used natively without decompression and uses less space than just zip/rar/7z alone.

CHDs are enormous, and generally not with grabbing unless there's a very specific game you want to play that requires one. There are also some games that bypass the need for CHDs - for example: "Street Fighter III Third Strike No-CD". This version removes the need for the matching CHD file, and loads a lot faster too.

 

Thanks - so TL;DR if you just want arcade games, you need MAME plus a set of "MAME ROMs" (merged/split doesn't matter but merged is better these days).

In my install of MAME I see a bunch of external XML files (eg. mame/hash/x68k_flop.xml for the list of supported X68000 floppies), which I assume is the "Software List" metadata from the MESS project. I downloaded a "DAT file" from https://www.progettosnaps.net/dats/MAME/ and it's in XML format, containing the Arcade ROM metadata. But from what I can tell that arcade metadata is compiled into the "mame" binary itself, and I assume dumping it to an external "DAT file" (eg. via "mame -listxml") is mainly to assist ROM library managers. I assume all the CHD metadata is also stored in the mame binary?

I'll defer to you for official/defacto MAME terminology, but to me "Software List" could confusingly refer to the external XML files in the "mame/hash" directory, or the collections (X68000 floppy images, Mega Drive cartridge ROM dumps etc.) of data that the metadata refers to. Just like "ROM" informally means "game data" in end-user terminology, I've also seen sets of these home computer/console dumps labelled "MAME Software List ROMs" .