Pac-man is a game where you navigate a small yellow circle around a maze, collecting dots and fruit whilst avoiding brightly-coloured monsters, or ghosts. As long as there was at least one 'man left, the game would play forever.

Except... it doesn't. After a few hundred levels, the level suddenly turns into this:

A big glitchy mess on the right-hand side of a Pac-man level

Why would such a dramatic glitch occur?


There are only seven fruit in Pac-man. The way the game calculates the number of fruit to draw is as follows:

  1. LD A,(#4E13): Load the level number (at memory address 0x4E13) into A.
  2. INC A: Increment A.
  3. CP #08: Is A < 8?
  4. JP NC,#2C2E: If not, jump to large-number fruit handling code.
  5. LD DE,#3B08: Load the address of the cherry into DE.
  6. Start the fruit-drawing loop.

(The assembly code is reproduced and explained in detail here, which also includes a patch to remove the glitch.)

This code works fine if the level number is 1, 2, 3, 4... even if it's 0! But if the level number is 255, the implementation's main flaw is exposed:

  1. LD A,(#4E13): Load 255 into A
  2. INC A: Increment 255 to 256 - this overflows to 0
  3. CP #08: Is 0 less than 8? Yes.
  4. JP NC,#2C2E: Don't jump to large-number fruit handling code
  5. LD DE,#3B08: Load the address of the cherry into DE
  6. Start the fruit-drawing loop

The fruit-drawing loop will then proceed to draw a fruit, subtract from the counter, check if it's equal to 0... but subtracting anything from 0 will cause it to underflow to 255. And 255 is not equal to 0.

The loop will dutifully draw fruit on the screen repeatedly until it has finished, by which time it will have drawn "level number + 1" fruit, which is fine when the level number is less than eight, but not when it is 255.

This attempt to draw 256 fruit on the screen, overwriting many other items - such as the precious Pac-dots required to complete the level - whilst doing so, is the cause of this dramatic glitch. No matter what the player does, the "Pac-dots collected" count will never be large enough, so the game cannot progress and ends here. This is why the kill-screen glitch occurs, and the final level of Pac-man will always be impossible to complete.

  • I plan to add more information about the assembly and algorithm specifics soon, but have not got time today.
    – wizzwizz4
    Oct 31 '16 at 22:06
  • 1
    Why didn't the developer consider the 0 case?
    – user64742
    Nov 1 '16 at 2:08
  • Perhaps he thought the player never would complete so many levels. In any case, If you start at one and always count upwards, it's easy to forget that you wind up and 0 eventually again.
    – OmarL
    Nov 1 '16 at 7:09
  • "but subtracting anything from 0 will cause it to underflow and become a very large number." Or 255 to be precise, since judging by the rest of what you wrote, it's stored as an 8-bit unsigned int.
    – Nathaniel
    Nov 1 '16 at 7:22
  • 2
    @TheGreatDuck I'd say they programmer(s) simply made a mistake, which is exactly what a bug is. I don't know too much about the history of this one, but I'm guessing it was too difficult to ship an update for the bug which may have only been found decades after release by which time it was considered a nice little achievement and probably no longer serviced.
    – Arkiliknam
    Nov 1 '16 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.