<< Part 3: Hunting for Color PROMs Table of Contents Part 5: MAME Of Borg >>

Part 4: The Joy of Common Hardware

One thing that has quickly become clear about these old arcade games is that, by and large, they use off-the-shelf pieces assembled to produce a game. The really unique part of most games is the software, not the hardware (though there are some cases — especially in the really early games — where the hardware was specially designed for a specific game).

Super Pac-Man, originally added by John Butler

It's really this use of common hardware components that makes MAME such a great platform to start emulating a new game with. If you look at the most recent versions of MAME, you'll find that there are over 50 different CPUs and nearly 50 different sound chips emulated. The chances are nowadays that if you pick some random unemulated game from the 1980's or early 1990's, you will already have its CPU and sound chip emulated. All you need to do to finish the driver is figure out the video hardware, and how everything is put together. It really is a lot simpler than it used to be.

Getting back to the story, one of the big challenges of finishing the Mappy driver back in July 1997 was getting the sound working. As I mentioned before, I had to figure out how Namco had converted their 3-voice sound system (used in Pac-Man, Galaga, and Dig Dug among others) into an 8-voice sound system. Once that was finished, it occurred to me that there was another Namco game in MAME that didn't have any sound. And coincidentally, it also used a 6809 for its main CPU, unlike the other games which used Z80's.

That game was Super Pac-Man, which had been contributed to MAME by John Butler, one of my fellow MacMAME enthusiasts. In fact, John had contributed the entire 6809 CPU core, which, looking back at it, was a pretty major contribution! It turns out that the 6809 was hugely popular for arcade games, being used by Williams, Namco, Konami, Exidy, Atari, and a whole host of other game manufacturers.

Dig Dug II, quite similar to Mappy

So the original driver for Super Pac-Man, as contributed by John, didn't have any sound support. But my suspicions were raised: could it use a sound system similar to the one designed for Mappy? Sure enough, it didn't take long looking at how the game was attempting to generate sound to recognize the same patterns of commands that Mappy was using all the time. This was my first MAME experience of two games sharing the same hardware. It was a total thrill to hook up the sound system I had written for another game to Super Pac-Man and hear it work almost perfectly the first time.

What happened next turned out to be even more of a revelation. Around this time, JROK, another arcade emulator author who was going it alone with his own standalone Mappy emulator, created a version of his emulator which supported a game I had never heard of: Dig Dug II. What's more, it was pretty clear that it hadn't taken a lot of extra work to go from Mappy to Dig Dug II.

So, armed with a fresh dump of this game I never knew existed, I took the ROMs and attempted to "mix and match" them into the slots already created for Mappy. It wasn't a 100% perfect match. First off, the code for the main CPU was 8k larger in Dig Dug II than it was in Mappy. Furthermore, there was twice as much graphics data for sprites.

Motos, also quite similar to Mappy

Dealing with the extra code was easy. One nice thing about the 6809 processor is that the bytes at the very top of memory must contain pointers to several important memory locations, such as where the first instruction of code lives, and which code should be executed in the event of an interrupt. For most arcade games that used the 6809, this meant that there was always at least one ROM mapped to those upper addresses, and at the very end of that ROM was a list of addresses (sometimes called a list of "vectors", not to be confused with vector arcade monitors!). Once you've seen what this list looks like, it's dead easy to recognize it.

So, once the ROM with the vectors was identified, it was used in place of the equivalent ROM in Mappy's memory layout. There was only one other ROM with 6809 code in it, so that naturally slotted below the first ROM in the address space. With that much done, I was able to start the emulation going and the code began executing as expected. Of course, in typical Namco fashion, the first roadblock was the usual I/O chip, which I had already figured out for Mappy. Since Namco didn't want operators performing simple ROM swaps to "upgrade" their games, each game had a different variation on the I/O chip, but they all worked in a fairly similar fashion. A bit more reverse engineering got the code past the I/O chip initialization, and the game booted! Here's my initial victory post to the newly-minted MAME message list:

Just so nobody wastes their time, I'm working the Dig Dug 2 driver. It should be done tonight. It's pretty close to being a Mappy drop-in, but it requires some video fixes that I've been aware of for some time. Looks good so far!
(Thu, 31 Jul 97)

Of course, things weren't perfect. Watching the attract mode revealed that the sprites were not drawing correctly. That's when I remembered that there was twice as much sprite data as Mappy. Clearly, there needed to be one more bit in the sprite table that would allow us to specify a sprite index high enough to reach the additional sprites. Conveniently, that extra bit was in a logical location in the sprite table, and removing the code to mask that off allowed the sprites to show up properly.

Tower of Druaga, once again similar to Mappy

One thing you quickly discover about working with games on common hardware is that one individual game usually doesn't exploit all the features of the hardware. For example, in Mappy, when you're on the topmost part of the screen, you can run through the house area. In this case, the sprite graphics, which are normally above the background tilemap, are in some cases drawn behind the tilemap instead. When I wrote the Mappy driver, I wasn't quite sure how this worked, so I took a guess that the topmost area of the screen was just special that way. This produced the correct effect, so I assumed that was good enough.

Well, now we had a mostly working Dig Dug II driver on the same hardware. On the title screen, the logo graphics appear to scroll upwards from behind an invisible wall. Except that in MAME, the logo graphics were fully visible and just appeared to scroll upward for no apparent reason. After looking at the tilemap data and sprite tables, it occurred to me that there was one bit in the tilemap data that was set for a block of tiles in the middle of the screen. It turns out that this bit is also set in the tiles that make up the top part of Mappy's screen as well. From this, I was able to deduce that this bit indicated that the tilemap had priority over the sprites in that region of the screen. With some trial and error, the exact rules for this behavior became evident, and both games displayed their video correctly.

One other nice aspect of games running on common hardware is that there it's not all that uncommon to turn up obscure games running on the same hardware. For an arcade company, it was definitely cheaper to re-use an existing hardware design for a new game. The main downsides were (a) the risk of all the games feeling similar and losing their uniqueness, and (b) an increased likelihood for piracy or easy ROM swapping, which could hurt your sales. But when a new game idea was in development, it was common to prototype the new game on existing hardware to see how well it worked before developing a new custom PCB for it. Also, if a game company was unsure of a game's success, re-using an existing hardware platform was a cheaper route with less financial risk.

So as it turned out, Namco had produced a few more obscure games (at least here in the U.S.) that also ran on the same hardware as Mappy. In fact, it wasn't until the Namco Museum discs for the PlayStation started appearing that many of us had even heard of these games! The first one to show up was called Motos, and it conveniently dropped right into the Mappy driver with the usual I/O chip modifications and an odd video alteration that caused a few digits in the score area to be mapped to different memory locations.

The fourth and final game we discovered on this hardware was The Tower of Druaga, which also mostly dropped right in. Again there was the I/O chip issue, but this game also had an colortable for sprites that was 4 times as big as the other games. Again, it was just a matter of finding the extra 2 bits needed to encode these extra colors in the sprite table, and it looked good.

In the end, I would say this experience with common hardware was a revelation. It is hard work reverse engineering a game to work on MAME. But if doing it once means you can get 2 or 3 or 4 or 12 games going all at once, it is a much more appealing proposition! Plus, each game running on the common hardware tends to exercise different aspects of the system, so by cross-referencing all the games and developing an emulator that successfully runs them all without hackery, you end up with a much more accurate portrayal of how the real hardware operates.

 

<< Part 3: Hunting for Color PROMs Table of Contents Part 5: MAME Of Borg >>