Translating pacman into C

Translating Midway/Namco Pacman into C 

Lots of emulators exist, such as mame, that faithfully recreate the original pacman/puckman gameplay. Additionally, many clones have been created in various programming languages.  But running the original ROM code in an emulator can be done with no understanding of how the original Z80 ROM code actually works. I decided a couple of months ago to translate the Z80 assembly code into C so that I could build the code and run it on my Linux desktop. The result is on github.

This blog is intended to be a record of my findings through the translation journey and hopefully might add to the knowledge base that already exists.

Code conventions

The C code in pacman.c contains the original disassembled Z80 code as comments just before it.  In many cases, there is redundancy in the code but I've left these in as a literal translation.  There are about 10,000 lines of disassembled Z80 code and about 5,000 lines of C code.  These 5,000 lines could easily be reduced by half and produce the same functionality.

Naming conventions

I've created names for the various functions and data structures in the ROM and RAM.  Where possible I've created structs to describe the contents of data tables.  Each function or data table has a name with a suffix of an underscore and the address in ROM.  For example, reset_0000() is the reset vector and FRUIT_DATA_0efd is the fruit data table.

Where I reference a RAM or ROM location, I'm using the Z80 notation, so #001d is a hex address for example.

And Now ...

Now that I have a fully compilable and working Pacman, I can start adding to it.  Maybe a much bigger maze, or more ghosts or an AI Pacman that achieves the best possible score.  Lots of possibilities.  

It might be cool too to add C data structures for the various movement patterns, fruit tables and so on to extend these but also to remove the dependency on the original ROM code.  One issue there though is that the pseudo-random number generator reads bytes from the ROM at random locations.  Unless it has the exact bytes in the ROM it will generate different sequences.

One thing I've done for fun is to draw a line from each ghost to their respective target tile.  It's fun to watch the chase algorithms in action.  Here Clyde and Blinky are directly targeting Pacman's tile, Pinky is aiming for 2 tiles ahead of Pacman and Inky's algorithm (based on the relative positions of Pacman and Blinky) is further ahead of Pacman.




And here are the ghosts in scatter mode heading for their respective corners:


Comments

Post a Comment

Popular posts from this blog

Movement patterns

Image
Tiles, pixels and vectors The pacman screen consists of 28 x 36 "tiles" which are 8 x 8 characters.  The number of pixels is then 224 x 288.  Each character has a 2-byte XY value for their current and next tile as well as a pixel XY position.  The tiles are used primarily when it comes to deciding in what direction a character moves. Each character also has a current and next vector.  This is an XY pair which is determines the direction of movement.  The "origin" is the top right corner. Finally each character has a "target" tile which is the tile they are trying to get to. A table at location #32ff contains two copies of the vectors as follows: direction X vector Y vector Right -1 0 Down 0 1 Left 1 0 Up 0 -1 A current and next orientation flag is maintained for each character. Adding 1 to the orientation flag rotates the character orientation clockwi
Read more
Image
Pacman Audio The distinctive audio sound in pacman is a major part of the game and in translating the Z80 ROM code into C, I got a better understanding of how it works.  This post captures my findings so far. Hardware The hardware is very simple.  It seems to have been simply an 8-bit DAC that plays samples at 96KHz.  A 32-byte memory mapped set of registers is used by the game ROM to play sounds.  It is organised as 3 channels each with a unique waveform, volume and frequency.  Channel 1 has a 20-bit frequency and frequency counter while channels 2 and 3 both have 16-bit frequencies. Each of the registers appears as 8-bits wide to the Z80 CPU but is actually only 4-bits wide.  (I haven't found the sound chip / ROM on the schematic but it may well have been only 4-bits). The highest 4-bits of each register are therefore ignored.  This means setting a 16-bit frequency is done by setting values across 4 registers.  Volume and waveform values are also limited to 4-bits only.
Read more