Let's Emulate Space Invaders

Introduction

Foreword

Emulating any system can be a daunting task, even to experienced software engineers. MAME can provide a good starting point, but can itself be quite daunting to get into. This series of articles should provide some insight into the way MAME works on a driver level and provide a good starting point for anyone who wants to contribute to pre-existing drivers in MAME.

What It Is

• An explanation of the most common structures found in drivers.
• A step-by-step guide on how to emulate a single game in MAME.
• A good starting point for a larger guide on the MAME source base.

What It Isn't

• A guide on how to write an emulator.
• A guide on how to work with MAME's core systems.
• A guide on how to port MAME to other systems.
• A pipe.

Writing It

Source Structure

There are two directories in the MAME codebase that are relevant for writing a driver; the rest should be ignored unless one is porting MAME to a different platform - in which case, good luck. The two directories are:

• /src/mame - All MAME-specific subsystems (drivers, sound boards, video boards, etc.) go here.
• /src/emu - All code libemu subsystems (CPU cores, audio chips, etc.) go here.

Under each of these are several subdirectories. Since there is some overlap, and since only some are relevant to writing a driver, only a subset of them will be described. They are:

• ./audio - Audio board drivers go here. in /src/mame only.
• ./cpu - CPU cores and disassemblers go here. In /src/emu only.
• ./includes - Headers for entire systems go here. In both directories.
• ./layout - MAME artwork layouts go here. Only necessary for games that have unusual screen layouts.
• ./machine - Non-CPU IC and subsystem drivers go here. In /src/mame only.
• ./sound - Sound IC drivers go here. In /src/emu only.
• ./video - Video board drivers go here in /src/mame, video IC drivers go here in /src/emu.

Driver Structure

Any driver in MAME typically consists of:

• A memory map for each CPU.
• A list of input devices and DIP switches.
• A MACHINE_CONFIG structure to define a PCB's hardware configuration.
• A ROM_START/ROM_END structure to define the ROM configuration for a game.
• A GAME() or GAMEX() macro to define an accessor for the game itself.
• Some form of video emulation, whether via a generic method or custom VIDEO_START/VIDEO_UPDATE functions.

Some drivers may involve other subsystems, such as timers and devices, but they are not strictly necessary in the most basic form of a driver.