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

LD A,(#4E13) : Load the level number (at memory address 0x4E13 ) into A . INC A : Increment A . CP #08 : Is A < 8 ? JP NC,#2C2E : If not, jump to large-number fruit handling code. LD DE,#3B08 : Load the address of the cherry into DE . 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:

LD A,(#4E13) : Load 255 into A INC A : Increment 255 to 256 - this overflows to 0 CP #08 : Is 0 less than 8 ? Yes. JP NC,#2C2E : Don't jump to large-number fruit handling code LD DE,#3B08 : Load the address of the cherry into DE 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.