Submitting Source Code

If you are handy with C/C++ and want to help out, there are several ways you can do so. Source code submissions from outside developers are welcome. In fact, many of the more unexpected improvements to MAME come from folks who are not "official" MAMEDevs.

Submissions of ROM dumps by themselves are also welcome if you are not prepared to work on the source code.

When making a submission, please specify if you would like to be credited, and if so under what name.

Submitting ROM or disk dumps

Send new ROM or disk dumps as email attachments to . If the data is too large to be attached safely in an email (5 megabytes), please provide a link to a server that hosts these files. In any case, if neither of these options work, please send a message requesting an alternative method of transfer. A .ZIP container is preferred with a unique filename to easily match up with any pull requests/source submissions.

When dumping a PCB, please include high-quality photographs of the board if possible, enough to read labels on chips, as this is important for documentation and correct emulation of the components. Please include all the dumped chips as a complete set even if some of them match existing data in MAME, as there are often many alternate versions in MAME and it is easy to lose track of which dumps go with which.

When dumping rewritable media such as floppies, hard disks, or flash memory devices, do NOT connect the drive to a modern computer without some form of (ideally hardware-based) write protection in place - modern operating systems like Windows and OS X automatically create hidden files and alter metadata on disks, which can overwrite essential data and has irreversibly damaged rare media in several cases. See e.g. [1] for guidance and please seek help if you are not totally sure what you are doing.

We appreciate all submissions but MAME is a volunteer project and we cannot guarantee that any new dump is added on any particular schedule, or at all.

Acceptable Code Submissions

When working on modifications to MAME, keep the following guidelines in mind:

• We are not interested in adding features to MAME that counteract normal usage of a machine unless it, by adding its core function, adds some tools that a developer can use to further the accuracy of the emulation. Unrealistic enhancements to original output (video/sound) should be avoided. Adding things like hardware cheats or other 'speed hacks' for the sake of performance with the cost of potential inaccuracies are not desired.
• Technical accuracy is our #1 goal. ROM patches or hacks to games are generally not appropriate, as they do not improve our understanding of the hardware. Submissions that are merely wild guesses about something and that do not make sense based on what is known about the hardware will tend to be rejected.
• Contributions do not need to be emulation source code only. For example, there is a wealth of information that should be in source files that could aid in emulation efforts such as hardware research, working out how to extract data or other sources of proven logistical information to allow MAME to be as accurate as possible with its information.
• ROM set naming in MAME is arbitrary. There is no point in submitting changes to ROM set names; they are crammed into eight characters and have many other limitations. Furthermore, it tends to annoy the developers.
• If you think there is a problem in the naming of a game, you should send an email rather than a source code patch. Game names changes are discussed among the developers and are not really code changes.
• Cosmetic changes to the source are best left up to the core developers. If your change does not add anything worthwhile to the actual code, it is not worth your time to submit it.

Submission Guidelines

Before actually sending in a submission, you should make sure that you follow these guidelines:

• All submissions must be compiled in both debug (make DEBUG=1) and non-debug builds using the official build tools (download them from here), and all warnings or errors fixed. This also includes making sure your binary passes internal validation (use -validate at command prompt).
• All submissions, if possible, should be taken from the most current source available at GitHub or the most recent source update. (If you are using Windows, you can get a set of diff/patch tools here.)
• Any romset, software, bios or other code that is not source code that is required for emulation is also required to be sent to the same address listed below (for external .diff submission) to complement your merged source code. If the data is too large to be attached safely in an email (5 megabytes), you must provide a link to a server that hosts these files. In any case, if neither of these options work, please send a message to the address shown below requesting an alternative method of transfer.

Submission Methods

Now that MAME source code is being hosted at GitHub, we can offer a much easier method to submit WIP code externally along with the traditional external .diff submission method we have used for years.

Using GitHub

• You need to create/own a GitHub account and fork the project allowing you to have an up-to-date copy of the source.
• With a valid account, you can then assemble local tree changes and send to our tree as a pull request.
• Please be clear in the comments and limit the amount of actual local tree commits made in order to create your updated code.

Using External .diff

• To create a correct diff, use the following command line below. originaltree is the (src) directory of the original, unmodified sources; modifiedtree is the (src) directory of your updated sources; and patchname.diff is the name of the diff you want to create.

DIFF -Nru originaltree modiifiedtree > patchname.diff

• Once you have a .diff containing your changes, ZIP it up and submit it by sending email to . Please do be verbose in explaining your submission's function as well as noting which handle or name you wish to be known by in the changelog.

All submissions are generally handled first in, first out. Using GIT, you have the opportunity to converse with developers in cases where adjustment of source is requested or required for your submission to be merged. Submissions are most often accepted without too much feedback. You, as an external contributor, are again encouraged to use the Pull Request messaging system in GIT to ask questions related to your submission. Feedback will come in most cases where submitted code has been reviewed and might not meet standards and/or needs to be adjusted in order to be accepted. If you use the email .diff submission for code, there is not much feedback there. If you see that a submission has not been handled within a couple weeks, please contact us. Please note that the Devs are all volunteers for the project and may have varying lengths of time to devote to other peoples' code. Just know that we are doing our best.

Getting Started

MAME is a huge project, and to work on many parts of it requires extensive understanding of C/C++, knowing how the target hardware works, CPU architectures, audio systems, graphics systems, and reverse engineering. These are not easy to come by, and the learning curve is very steep. That said, there are still ways of contributing to MAME that do not require a full top-to-bottom understanding of everything. Here are a couple of suggestions:

1. Add save state support to a driver. The save state system is very modular and pretty straightforward to use. Furthermore, a good number of drivers are not set up to use it right now. Digging into a driver and figuring out what data needs to be preserved in order to resume execution is a great way to learn about MAME.
2. Figure out what unknown DIP switches do. Some of this can be determined by twiddling the DIP switches and watching what happens, but often this is not enough. Delving into the game code to understand how the DIP switches are read and what their values are used for is a good beginning challenge in reverse engineering.
3. Modernization of code. By following other modernization examples detailed in recent changelog messages, there are numerous drivers/devices that are not properly set up to take advantage of the current core design, that do not meet current standards or that do things in outdated ways.
4. Go to MAMETesters and look over the bugs. There are many tricky bugs in there, but there are also many straightforward issues that nobody has yet taken the time to investigate.

If you are new to emulator programming, these are far better places to start than trying to tackle the emulation of a game that does not yet work. Any games that still don't work are usually due to complicated protection or hardware emulation issues and are more than likely going to be a daunting (and discouraging) challenge for someone just getting started.

Back to How MAME Works