Aaron's MAME Memories Part 1

Part 1: My First Driver

It wasn't long after discovering MAME that I realized something was missing: my all-time favorite arcade game, Mappy. Yes, that's right, the cute little Japanese police mouse dodging the cute "naughty folks" called meowkies, and their ringleader Goro. There's something about the game that just clicked with me when the local 7-11 installed it for a few months back in 1983. I had even gone so far as to import a copy of Namco Museum 2 for the PlayStation in order to play the game. But here was my chance to do it right — running the original arcade code in MAME.

When I started, I didn't know much about the 6809 microprocessor, but after spending many of my teenage years cutting my teeth on 8080 and 8086 assembly, it wasn't too tough to pick it up. I started with the Super Pac-Man driver written by John Butler, which was the first 6809-based Namco game included with MAME. Unfortunately, it only had one 6809 and Mappy ran on two, so I knew it wasn't going to be a simple drop-in. I then blended some elements from the Galaga driver written by Nicola Salmoria. Galaga didn't run on a 6809, but it did run on multiple CPUs: 3 Z80's to be exact. In the end, after surmounting the MAME learning curve, there were three tricky things about adding Mappy to MAME: the I/O chip, the scrolling video, and the sound.

The I/O chip was figured out by simple reverse engineering. Namco used a similar chip on all its early games, and it was responsible for a number of tasks: reporting inputs from the joysticks and buttons, tracking and counting coins, reporting DIP switch settings, and even keeping score in some cases. So I copied the I/O chip implementation out of the Super Pac-Man driver and rearranged its responses to operate in a way that the Mappy code was happy with.

As I mentioned before, my Mappy driver was based on the Super Pac-Man driver. But there was a big difference: Mappy scrolled the screen left and right; Super Pac-Man had no scrolling. I figured out quickly enough that Mappy had twice as much video RAM as its cousin, so it seemed logical to me that there must be some mechanism for giving the video hardware some offset to apply to the background. Unfortunately, it wasn't clear at all: I was looking for some register where the main CPU would write a scroll offset while the game was playing, and I just wasn't seeing anything.

Well, it turned out that this was my first encounter with one of the common tricks of arcade hardware design: using the address bits as data. If you've ever looked closely at a microprocessor, you've seen that it has lots and lots of pins. Most of those pins are dedicated to running two busses on a system: the address bus and the data bus. Whenever the microprocessor wants to write to memory, it specifies the address of the memory location on the address bus, and specifies the data it wants to write on the data bus. Then it sends a signal to the RAM chips which instruct them to read the address and data from these two busses, and to store the data into RAM at the address specified.

On typical microprocessors in the Mappy era, there were 16 pins dedicated to the address bus, allowing the chip to access 2¹⁶ = 64k worth of memory. And on these processors, there were generally 8 pins for the data bus, meaning each memory access loaded or stored 8 bits (1 byte) of data. This is one of the reasons why these processors are known as 8-bit microprocessors.

So, back to scrolling. I was expecting to see the game write to a specific address (that is, use a very specific pattern of bits on the address bus) with the scroll value specified on the data bus. But what I actually discovered was that Mappy was writing the scroll value to the address bus instead, and not using the data bus at all! They had blocked off a whole range of addresses from $3800 to $3FFF, and were using the lower 11 bits of the address as a scroll value. Thus, any memory access to that range would alter the scroll position of the screen. I must say, it took many days to figure this out and wrap my mind around the concept. As a software developer, it didn't make a whole lot of sense to me, but once I looked at it from a hardware developer's perspective, the logic of it was much clearer.

The sound was the trickiest part. If you've ever played Mappy, you know that the catchy music is really an important part of the game. I had the main driver done, and probably could have submitted it as-is, since at the time sound was a luxury in MAME. But in the end, I resisted my desire for instant gratification and set to work on the sound. Fortunately, I had a big clue: sound had already been added to earlier Namco games, like Pac-Man and Galaga. The problem was, their sound system was too simple to handle the complex melodies of Mappy — the classic Namco sound system only supported 3 simultaneous "voices", and it was quite obvious that Mappy needed more.

The way the Namco sound system works is quite simple. Each "voice" has a set of registers associated with it; these registers control the frequency of playback, the volume, and select one of 8 waveforms to play. These waveforms come from a small PROM on the board, and are each 32 samples long. These samples are then fed through a DAC at the requested frequency, and the sum total is sent to the speaker.

To get sound in Mappy, I guessed that the sound system was probably similar to the classic Namco system, just with more voices added. The problem was made more difficult because the registers for the 3-voice sound system were only 4-bits wide, while the new sound system used 8-bit registers. It didn't take too long to find out where in memory the sound registers were — you could see them getting accessed when you inserted a credit. However, it took quite a number of false starts and wrong guesses before I finally figured out how the frequency and volume were encoded in those registers. Eventually, I discovered that the new sound system supported 8 simultaneous "voices". I was blown away the first time I heard the familiar strains finally coming from my Mac's speaker.

Overall, it took a good month and a half to two months of late night coding to get Mappy up and running to spec, but soon I had done it: my first MAME driver. I sent it in to the current maintainer, Mirko Buffoni, and waited with heightened anticipation for a response.

Unfortunately, the response I got was not the "Wow, you are an emulation god!" I was hoping for; instead it was something more along the lines of "Oh crap, I've been working on a driver for the same game!" Thus it suddenly became very obvious that some kind of coordination was needed between MAME developers. That wasn't to come for a few more months yet. In the meantime, Mirko blended his driver with mine, and I went off to work on adding sound to Super Pac-Man, since I was eventually able to determine that it used a very similar sound system to Mappy.

<< Part 0: The Beginning

Table of Contents

Part 2: What's a Schematic? >>