Aaron's MAME Memories Part 3

Part 3: Hunting for Color PROMs

One of the more interesting problems in the early days of MAME development was the issue of color PROMs. Many of the early popular games (which is at this point all that MAME was focused on) had a limited, unalterable set of colors that were available to the game's graphic designers. This fixed set of colors is generally referred to as a palette, obviously named after the concept of an artist's palette.

Take, for example, the game Pac-Man. If you were to sit and study the game over time, counting the total number of unique colors, you would find that there are exactly 16 unique colors used in the game. The red, green, and blue weights for each of these 16 colors is stored in a color PROM, that is, a very small ROM that contains color information. Looking again at Pac-Man, here is a snapshot of all 16 colors:

The way this data is layed out in the color PROM looks like this:

Bit	7	6	5	4	3	2	1	0
Color	Blue	Blue	Green	Green	Green	Red	Red	Red

which gives you 3 bits of color resolution for red and green, and 2 bits of color resolution for blue. A total of 8 bits is needed to represent each palette entry, and these are stored in a color PROM that has enough room for 16 8-bit entries.

As an aside: what Pac-Man — and many other games — uses to represent its palette is commonly known as a 3-3-2 colorspace (3 bits red, 3 bits green, 2 bits blue). In general, when you're short on bits, it is best to drop bits first in the blue component, then in the red component. The reason has to do with how we as humans perceive color: we have much more sensitivity to changes in brightness than we do to changes in colors. When looking at a color generated by blending red, green, and blue (i.e., a television screen or computer monitor), the brightness is roughly composed of 6 parts green, 3 parts red, and 1 part blue. Thus, if your blue resolution is a bit less, it isn't as noticeable to the brightness-sensitive parts of your eye, which are dominant.

All right, back to the topic at hand.... As I mentioned in a previous installment, the majority of the games developed in the late 70's/early 80's drew their graphics in two layers. The background layer consisted of a grid, typically divided into 8x8 pixel squares. So, for example, Pac-Man's screen, which is 224 pixels wide by 288 pixels tall, is actually a grid that is 28 tiles wide by 36 tiles tall. On top of that background layer is the "sprite" layer, which is generally a short list of objects that can be placed at aribtrary positions on the screen. This picture illustrates the two layers in a typical Pac-Man scene:

The left hand side is the final, composited image. The middle picture is just the background tilemap. I've "exploded" the view a bit so that you can see the tile boundaries. Notice how there are actually relatively few unique tiles; most of them are the same 8x8 graphic reused over and over. The right hand side shows the sprites; in Pac-Man these are just Pac-Man himself and the four ghosts. If you think about how these objects freely move over the entire screen, you can see why it is advantageous to have the sprite layer, whose objects have complete freedom of movement.

Now how does this relate to colors? Well, the graphics drawn by each tile and each sprite are selected from a list of pre-defined graphics pieces. In the case of tiles, there is one ROM on the Pac-Man board that contains the graphics patterns for 256 individual 8x8 tiles. For sprites, there is a second ROM that contains the graphics patterns for 64 separate 16x16 sprites. Each pixel of these tile and sprite images is described by 2 bits, meaning there are four possible colors that each pixel can be. In the case of sprites, things are even more limited because one of the four colors is "transparent", meaning that you can see the background tilemap underneath that color. For example, when Pac-Man opens his mouth, you can see the tilemap underneath his gaping maw.

So, each tile and each sprite can have 4 colors. But if they could only have the same 4 colors all the time, the screen would look pretty awful. As you can see from the snapshot of the sprite layer above, there are definitely more than 4 colors in evidence there. Furthermore, there are 16 colors available to us, so how can we take a 4-color tile or sprite and give it access to all the colors? The answer is a colortable. A colortable is basically a table that maps the four colors of each tile and sprite into the full 16-color palette. Here is a snapshot of Pac-Man's colortable, which, like the palette, is also stored in a color PROM:

If you count them up, there are a total of 32 possible 4-color combinations. Each color in the colormap is selected from one of 16 in the palette at the top of the page. If you multiply out 32 by 4, you get 128 colortable entries, each of which needs to be 4 bits wide in order to address the 16 colors available in the palette. Since there are 32 colortable entries, you need 5 bits to select one of them. These 5 bits can be specified by the program running the game independently for each tile and sprite on the screen. Thus, it can control which set of 4 colors each tile and sprite on the screen uses.

Now why the heck did I go through all that? Well, in the early days of MAME, color PROMs were very rare. The existing ROM dumps had been focused on the large program and graphics ROMs, and not on these little tiny color PROMs. One of the reasons these were often overlooked is because they look nearly identical to all the other non-ROM TTL chips on a game's circuit board. Think about it this way: a typical program ROM of the day might have held 2k bytes of data. To specify an address to that chip, you need 11 address bits (2¹¹ = 2048 = 2k) and 8 data bits (1 byte = 8 bits). That's at least 19 pins, plus a few control lines. Usually you'd see 24 pins or more on the final package.

In contrast, a color PROM had maybe 256 entries that were 4 bits each. Thus, it would need 8 address lines (2⁸ = 256) and 4 data lines, or 12 pins plus a few control lines. Maybe 16 pins total. Well, let me tell you, there hundreds of standard TTL chips out there that have the same number of pins. Furthermore, the package these PROMs came in was generally the exact same size as a typical TTL chip. So unless you knew what you were looking for, it was pretty easy to overlook the color PROMs.

One final issue that made it difficult to track down color PROMs is that they were often soldered directly to the circuit board. In order to read them, it was then necessary to desolder the chip, read it, and then reattach it to the board. The chances of ruining a good board were high.

So, given that we were stuck without color PROMs, what did we do? Well, we made up our own! In fact, this was one of the most painstaking problems I had to overcome when writing my original Mappy driver. I literally spent hours playing the imported Namco Museum Vol. 2 on my PlayStation, carefully observing the colors, then running back to my computer to try and recreate the same colors. It was a ton of work, let me tell you. First, you had to figure out which colortable entry each entity on the screen was using. Then you had to observe that same entity in the same situation on the "original" (in my case, the closest emulation I knew of). Next, you needed to look at the pixel data for that tile or sprite and see which of the 4 colors is was referring to within that entry. Finally, you have to map that to a palette, and you have to get the colors in the palette as close as you can visually to the original!

In the end, I have to say, I'm reasonably impressed at how close I got. On the left is a snapshot from MAME 0.26, the first version that had my Mappy driver. On the right is the most recent version of MAME. If you look, the only color that's really off is the score. And it turns out that was more of an issue with the Namco Museum than with anything else: it appears that they artifically "overcooked" the peach color in the score to a bright yellow. Probably because it looked better to them. Of course, this again proves that you can't necessarily trust a commercial emulator to provide 100% accuracy!

If you look back at early versions of MAME, you'll see that there are actually quite a lot of games with inaccurate colors. Most of those games probably had hand-crafted colortables and palettes. Fortunately, these days, there is a high awareness of the importance of color PROMs. Thanks to the efforts of quite a lot of patient people out there, MAME finally has proper dumps of color PROMs for most of its games, including Mappy (and hey, we all know that's the most important one, right?)

<< Part 2: What's a schematic?

Table of Contents

Part 4: The Joy of Common Hardware >>