Hunting for Color PROMs

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 (211 = 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
(28 = 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?)