| << Part 4: The Joy of Common Hardware | Table of Contents | Part 6: Timing Is Everything >> |
Part 5: MAME Of Borg
One of the things MAME has often been accused of is the "assimilation" of other arcade emulators. At the time MAME started, there were quite a few other arcade emulators, each with its own little fiefdom. For Atari vector games, there was Neil Bradley's EMU. For the Bally/Midway MCR games, there was Mike Cuddy's KEM. For Gauntlet there was Neil Corlett's MGE. And for a number of other games, there was Dave Spicer's Sparcade. Other multi-arcade emulators came and went as well, such as CAGE, HiVE, RAGE, Retrocade, System 16, JAS, Callus, etc. But very few of them lived on much beyond their first few releases.
Why? Well, there are several reasons. The first is completeness. If you're developing an emulator to run a particular gaming system, and you successfully emulate all the games that run on that system, what's left to do? I suppose you could tweak the UI or try optimizing the code more, but that's much less fun than trying to emulate something new. Take a look at EMU, for example. Once the Atari vector games were all emulated succesfully, really what else was there to add? The emulator was for all practical purposes done, version 1.0. But if you stop making releases of your product, it gets quickly forgotten in the wake of all the other new emulator releases that happen all the time.
Another reason the other emulators tended to fade away over time was because they were closed source, which meant that there was a limited group of people working on them. In many cases, they were written by just a single author. As a programmer, I have to admit that it's pretty boring working on the same thing for too long. I know that a lot of the other emulator authors just got tired of working on their projects, deciding to move onto newer, more interesting projects. And because the emulators weren't open source, there was little opportunity for someone else to come along and take up the cause. Furthermore, many of the closed source projects were DOS or Windows-only and had no interest in supporting ports to other systems, like the Mac.
Which brings me to the real reason I hopped onto the "assimilation" bandwagon without a second thought. I was a Mac user, and there were very few good arcade emulators for the Mac, except for MacMAME. In fact, apart from a couple of single-game emulators and the very nice Vectorama, MacMAME was really the only game in town. I knew as soon as I first used MacMAME that I wanted to help contribute the project. I quickly discovered that not only was MAME open source, but it was also very cross-platform friendly. From the beginning, Nicola was interested in making MAME portable, and happily accepted submissions from people on any platform.
So, having just finished up Dig Dug II, a new preliminary driver appeared on the freshly-formed MAME mailing list. It was a driver for Tapper, being developed by Chris Kirmse, one of the original MAME32 developers. In fact, looking back at my original reaction to Chris's driver, I was pretty excited:
Just plugged in the code on the Mac and it works great! Excellent work! I've been waiting to play Tapper for a long time; hopefully the other MCR games will be easy after getting this one going :-)
(Thu, 14 Aug 1997)
The first pass at the Tapper driver was missing palette RAM handling (and a few other things), and it turns out my previous experience with Mappy scrolling came in handy. You see, Tapper runs on an 8-bit Z80 CPU, but each entry in its palette is 9 bits long: 3 bits for red, 3 bits for green, 3 bits for blue. One way the hardware designers could have handled this would be to split each palette entry into two bytes, maybe putting the red and green components in one byte, and the blue in another byte. But, being hardware engineers, they were more clever than that! What they did was they encoded 8 of the bits into the data being written to the palette RAM, and the 9th bit was encoded in the low bit of the address. So, if the 9th bit was to be a 0, you would write the low 8 bits to an even address, and if the 9th bit was 1, you would write the low 8 bits to an odd address. The use of address lines as data was exactly what I had to deduce when I wrote the Mappy driver.
Another issue that showed up when adding Tapper is that it used a dynamic palette. It may seem odd to think about now, but at the time, MAME didn't really have the ability to support dynamic palettes. If you look at its history, MAME was derived from Nicola's original Multi-Pac emulator. And as I explained in Part 3, Pac-Man (and its brethren) used a fixed colortable/palette lookup system to generate their colors. This meant that all possible colors were encoded in a constant color PROM, and so when the color PROM data was loaded, MAME was able to know up front which colors were going to be used.
Not so with Tapper. The game program was free to select any 16 colors it wanted from a possible palette of 512. Each pixel in the sprite and background graphics selected one of these 16 colors, thus requiring only 4 bits to encode each pixel. Furthermore, you could achieve cool full screen effects just by changing one entry in the color table. For example, if you had encoded color 0 to mean "black", and drew graphics that mostly used color 0, then you would get a display that was primarily black. However, just by changing the encoding of color 0 to mean "red" instead, you could instantly turn all the black parts of the display to red. And for the low-end processors used in early games, this was used to great effect. Eventually this technique came to be called "color cycling", because often games would cycle an entire sequence of colors through one of these palette entries, producing dynamic flashy rainbow effects that looked pretty impressive for the day.
(Of course, such effects can be overused: Williams was notorious for this. Try spacing out on the attract mode for Blaster for a while; with all the excessive color cycling, you'll probably be feeling ill in just a minute or two!)
Now, PC (and Mac) video hardware works the same way when running in 256-color mode. Except that on the PC, you can select 256 colors from a possible palette of 256,000 or so, which means that it's easy to support dynamic palettes of 256 or fewer entries. So when the Williams games were added to MAME, the authors added some hacks to allow us to pass the color cycling data directly to the PC's hardware. By doing this, color cycling actually became "free" to emulate, since when the games changed a palette entry in the emulation, the Williams driver would just tell the PC hardware to change the corresponding palette entry on the PC's video hardware.
Well, being a Mac guy, having a nice hardware hack for PCs wasn't really going to help me out much. Furthermore, it made the assumption that the video hardware on the machine running MAME was using a 256-color mode with dynamic palettes, which wasn't always the case on the Mac. So it was at this time that I first proposed and implemented an official MAME call to allow dynamic palette changing in MAME:
The second change is the implementation of osd_modify_pen(), which should be used for all color cycling. In the next day or two I'll send out new williams, tutankham, and tapper drivers that actually take advantage of this, but for now, I've included what I think should be the proper implementation for DOS and Windows (based on copying code out of the williams driver). Mac users should just write a quick stub until my new palette remapping code is stabilized.
(Mon, 18 Aug 97)
By adding this feature, it allowed the OS-dependent code (that's what the "osd" means in osd_modify_pen) to do whatever it took to simulate the color cycling feature. As it turns out, dynamic palettes were the norm in most arcade games, rather than the exception, and so eventually MAME would end up with a system that was optimized for dynamic palettes. But that's a story for another chapter.... :-)
| << Part 4: The Joy of Common Hardware | Table of Contents | Part 6: Timing Is Everything >> |