If you've blocked our ad, please consider unblocking it.
We promise it isn't annoying. No flash, no sound, ever.
This page details bugs of Pac-Man (Arcade).
Level 256 Split Screen
Perhaps one of the most infamous bugs, the game renders garbage at Level 256. It is commonly referred to as "Split Screen" due to the right half of the screen looking garbled, while the left half is still intact.
The bug was originally analyzed and documented by Don Hodge on his website, where he also proposes a possible fix.
Why the Bug Happens
This happens due to a bug in the code responsible for retrieving the number of fruits to draw at the bottom right corner of the screen. Inside the routine, it loads the number of the current level (being 0-based and thus 255 for Level 256, or 0xFF in hexadecimal), then increases it by one.
0x2BF0 LD A,(#4E13) ; Loads the current level number stored at 0x4E13 into register A. 0x2BF3 INC A ; Increases the register by one.
In the case of Level 256, this overflows the register and makes it loop back to 0 (0x00) since a byte cannot hold a number higher than 255, simply restarting from 0 if that is the case. The code does not check if an overflow has happened (which could be possible due to a so-called carry flag set in the CPU registers). In fact, it simply uses the resulting number in a check on which fruits to draw.
The check is done to compute the offset into a table which holds the fruits to draw. Levels 3-4 for example both draw an Orange, thus this "fruit table" is required to look up these duplicate occurrences of fruits. The table holds the following fruits in this order:
- Orange (1st occurrence)
- Orange (2nd occurrence)
- Apple (1st occurrence)
- Apple (2nd occurrence)
- Grape (1st occurrence)
- Grape (2nd occurrence)
- Galaxian (1st occurrence)
- Galaxian (2nd occurrence)
- Bell (1st occurrence)
- Bell (2nd occurrence)
- Key (1st occurrence)
- Key (2nd occurrence)
- Key (3rd occurrence)
- Key (4th occurrence)
- Key (5th occurrence)
- Key (6th occurrence)
- Key (7th occurrence)
- Key (8th occurrence)
The problem with the check now is that it only expects values starting at 1, which is the value for the first level (internally Level 0, then being increased by one). Due to the overflow with 0xFF, the check gets value 0 - something the programmers did not expect.
So what does the check do exactly with the number it gets?
- When the value is lower than 8, it draws fruits starting with the Cherry from the first level. A loop is used to draw only the fruits from the first to the given value (since only the Cherry and not more should be seen in Level 1).
- If the value is between 8 and 18, it uses the current level number as the current offset into the fruit table. Remember that fruits scroll starting with Level 8, as a maximum of 7 fruits are drawn, so only the most recent 7 are visible.
- If the value is above 18, it always starts drawing fruits from the first Key. According to the fruit table, it will always draw 7 Keys then (there's no reason for an 8th Key to be in it, but it happens to be).
0x2BF4 CP #08 ; Is the value lower than 8? (yes for level 256, being 0x00). 0x2BF6 JP NC,#2C2E ; No: Compute another offset into the fruit table (the code at 0x2C2E is not shown here). 0x2BF9 LD DE,#3B08 ; Yes: Places the offset to the cherry in the fruit table in the DE register.
So far, this is still not a big issue. However, the aforementioned loop is coded in a way it does not work together with value 0. To implement a loop in assembly language, the counter is stored in register B. It is decremented at the end of the loop and then checked if it is 0 to stop the loop from being started over again.
0x2BFC LD B,A ; Prepare the loop, store the counter in B. Initialize it with the value we got before. 0x2BFD LD C,#07 ; (Prepare a loop drawing black tiles to cover old fruits.) 0x2BFF LD HL,#4004 ; Stores the location in video memory where to draw the first fruit (0x4004) in register HL. 0x2C02 1A LD A,(DE) ; Start of the loop (stores the value of the fruit table in register A). ... Fruit drawing code. Replaces 4 tiles on screen (fruits are of 2x2 tiles size) in order of the video memory ... 0x2C14 INC HL ; After current fruit is drawn, increase HL twice to point to tile of the next fruit. 0x2C15 INC HL 0x2C16 DEC C ; (Update the loop to draw the black tiles to cover old fruits.) 0x2C17 DJNZ #2C02 ; Decrements B (the loop counter) by 1. Exits if it is 0, otherwise runs the loop again.
In Level 256, the loop counter is initialized with 0 from the start (line 0x2BFC). When decremented to possibly restart the loop again (line 0x2C17), it underflows back to 255 (since a byte can't hold values lower than 0, thus 0 minus 1 results in 255, or 0xFF). The loop now repeats as often as required to bring 255 back to 0.
How the Garbage Is Placed
What this means is that the game is now instructed to loop over the fruit drawing code 256 times - these are by far too many fruits to draw. Running out of entries in the fruit table (which also point to the video memory holding the graphics of the fruits to draw), it starts accessing other parts of the video memory, grabbing seemingly random tiles of graphics and drawing them onto the screen into increasing video memory locations.
But why does this actually cause the right half of the screen to be overwritten? This is because the video memory in Pac-Man is not laid out as in modern computers (which are increasing video memory locations from top left to bottom right). It is separated into three parts:
- Video memory starts with the fruit bar at the bottom. It consists of two rows of tiles, the first tile starting at the top-right tile of the first fruit. The tile offsets increases towards the left, then into the second line.
- The maze, following the fruit bar directly in memory. The first tile is at the top right corner and then runs down before proceeding into the next column (unlike the fruit bar which is row-major).
- The score bar at the top, laid out like the fruit bar, following the maze memory.
As said, when the fruit drawing routine is looped 256 times, it moves forward in video memory. The first line of the fruit bar is completely filled with fruits from right to left. Then it continues drawing fruits into the second line of the fruit table. Here it already begins drawing the lower parts of the fruits into the right-most column of the maze, from top to bottom (due to the transpose of the maze video memory), since that is what the game thinks would be the "third" line of the fruit table. It then proceeds drawing fruits starting from the "third" line of the fruit table, which - as we know - is the first column of the maze. It starts scrambling the 2nd column at this time, too. Even if there would be real fruits to draw now, they would look split into 4 parts since the memory is transposed compared to the fruit bar, and the fruit drawing routine of course does not care about that.
The game continues drawing until more than half of the maze video memory has been overwritten with garbled data, and B finally becoming 0 before it is checked to end the loop. In fact, the game has no code or bug which exactly trashes "half" the maze; it just happens to be about (but actually more than) 50% of the maze memory.
Causing the Level To Be Unfinishable
To finish a level, the game checks if 244 dots have been eaten.
When the maze memory is being overwritten by the fruits - which are drawn at level start and every time a life is lost - most dots are erased with it. Only 9 tiles still get a dot flag written to.
Every time the player loses a life (assuming he still has some in this high level), the fruits are redrawn, and the possibly eaten dots are placed again in the garbled area. The player can reach a maximum of 6 lives in this game, and even when bringing them all into Level 256, causing the 9 dots to be placed again 6 times at each death, there are still not enough dots to eat to finish the level, and thus the level end never triggers.
It can be manually triggered with a hardware dip switch (the "Rack Test" feature), which throws the game back into Level 1 with the scores still intact, though of course this is not seen as "normal" gameplay. There are some leftover graphics in the bottom corners of the screen which do not get redrawn under normal circumstances and actually stay visible until the machine is reset.
Wrong Ghost Behavior When Pac-Man Faces Up
Use information (especially add images similar to the ones) from Don Hodges' page.
When the ghosts switch from scatter mode into chase mode to attack Pac-Man, each one uses a different logic to actually target him:
- Blinky (red ghost) directly targets the tile the Pac-Man actor is seen on.
- Pinky (pink ghost) targets the spot 4 tiles in front of Pac-Man's mouth (e.g. 4 tiles away from the direction he is pointing to).
- Inky (cyan ghost) targets the spot 2 tiles in front of Pac-Man's mouth, then adds the distance from that spot to Blinky to it.
- Clyde (orange ghost) only targets Pac-Man like Blinky when he is further away than 8 tiles, otherwise switches to scatter mode.
Pinky and Inky's logics have a bug, however, which causes them to compute the tile in front of his mouth incorrectly when Pac-Man is pointing up. It turns out that this will actually compute the tile not only 3 (or 1) tiles away from his mouth, but also 4 (or 2) tiles to the left of it.
To understand the bug, it is required to know how the distance to a tile afar is represented in memory. Basically, a 16-bit directional vector is used as seen in the following table. These values only make sense when remembering that the origin of the coordinate system of the maze is at the top-right rather than top-left, and that 0xFF to 0x80 means -1 to -127 in an 8-bit value (while 0x00 to 0x7F is 0 to 127).
|Direction||Mathematical representation||Memory representation|
|Up||(0, -1)||(0x00, 0xFF) = 0x00FF|
|Down||(0, 1)||(0x00, 0x01) = 0x0001|
|Left||(1, 0)||(0x01, 0x00) = 0x0100|
|Right||(-1, 0)||(0xFF, 0x00) = 0xFF00|
To now compute more than 1 tile afar into a specific direction, the game simply multiplies the vector by the required distance. Purposefully making use of the values overflowing when multiplying the Right vector, this seems to result in the correct distance vector. Let's see the results when trying to retrieve the spot 4 tiles down, left, or right:
|Direction||Original vector||Resulting vector (multiplied by 4)|
|Down||0x0001||0x0004 = (0x00, 0x04) = (0, 4)|
|Left||0x0100||0x0400 = (0x04, 0x00) = (4, 0)|
|Right||0xFF00||0xFC00 (overflowing 4 times) = (0xFC, 0x00) = (-4, 0)|
However, this does not work out when multiplying the Up vector, as no overflow happens since the value is treated of 16-bit size:
|Direction||Original vector||Resulting vector (multiplied by 4)|
|Up||0x00FF||0x03FC (not overflowing) = (0x03, 0xFC) = (3, -4)|
Since a 16-bit value can take more than just 0xFF and the multiplication is done in 16-bit, the value does not overflow and instead "spills over" into the X offset, making the direction not only go 4 tiles up, but also 3 tiles left.
Inky uses the same buggy logic, he computes a tile offset 1 to the left when trying to get the spot 2 tiles up.
Passing Through Ghosts Without Getting Hurt
Due to the way the collisions with ghosts are detected, it is possible to pass through ghosts when approaching them exactly in the frame where Pac-Man and the ghost both switch the tiles they're seen on by the collision detection code. Requiring this to happen on the exact frame, this happens very rarely, though it has been incorporated in professional level solving patterns (Billy Mitchell once executed a Cherry level pattern abusing this glitch several times in one run).
Frightened Ghost Behavior Isn't Really Random
The frightened (blue) ghosts use a pseudo random number generator (PRNG) to decide which direction to take at an intersection. However, this PRNG is reset every time a level starts or a life is lost, so their behavior is predictive when moving exactly the same as Pac-Man (like it is done with level solving patterns).
This is not generally seen as a bug and might be intended by the developers, though it could be a programming oversight as well.