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?


1 Answer 1


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, 2016 at 22:06
  • 1
    Why didn't the developer consider the 0 case?
    – user64742
    Nov 1, 2016 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, 2016 at 7:09
  • @TheGreatDuck It might also very well be that this approached saved on resources. Programmers didn't think of "how to make this the most obviously correct solution" back then - rather, it was more like "how to squeeze this to as little memory as possible" and "how to make this run as fast as possible". Saving one byte in instruction code was done all the time. Also, don't forget that this simply means that level 255 is unplayable - you didn't lose an "infinite game" through this glitch - just one (non-existent) level. Without the glitch, you would just start over from zero again.
    – Luaan
    Nov 1, 2016 at 12:59
  • 4
    @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, 2016 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.