Submitting Source Code

If you're 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" MAME devs.

Acceptable 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 which 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' or 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 which are merely wild guesses about something and which don't 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. There is a wealth of information which should be in source files which would 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 8 characters and have many other limitations. Plus 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 aren't really code changes.
• Cosmetic changes to the source are best left up to the core developers. If your change doesn't 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 should be,if possible, 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 compliment your merged source code. If the data is too large to be safely attached in an email (5 Megabytes), you must provide a link to a server which houses these files. In any case, if neither of these options work, send a message, again to the address shown below, requesting an alternative method of transfer.

Submission Methods

Now being hosted at GitHub, we can now offer a much easier method to submit WIP code externally along with the traditional external .diff submission method we've 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. 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 don't 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. Modernizations of code. By following other modernization examples detailed in recent changelog messages, there are numerous drivers/devices which are not properly set up to take advantage of the current core design, don't meet current standards or 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 look into.

If you're new to emulator programming, these are a far better places to start than trying to tackle the emulation of a game that doesn't 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