247

According to the Wikipedia page for Pac-Man, the highest possible score is 3333360 points. It's called a perfect game and it was achieved by 3 different people already.

What I want to know is: WHY is it exactly 3333360 points? It must be a technical limitation, but this number makes no sense in my opinion.

I know the game has 255 levels. 255 is 11111111 in binary and level 256 (that seems to exist mystically) brings the 8-bit digit to an overflow, which ends in a crash of the game.

But, 3333360 just seems so random.

Ola Ström
  • 420
  • 1
  • 4
  • 10
chaos
  • 2,167
  • 3
  • 16
  • 13
  • 69
    It's not a technical limitation as much as it the score that you happen to get if you eat every pellet and piece of fruit on one life in every level. – Unionhawk Oct 01 '14 at 19:31
  • 24
    The problem is not the fact that it tries to load level 0. The problem is that the number 256 (100000000 in binary) is being stored in memory that has only been allocated to contain 8 bits. The first 1 is therefore written into memory that is assigned to something else, which essentially corrupts the entire game. – Lee White Oct 01 '14 at 21:26
  • 39
    @LeeWhite: That's not quite the issue. The problem is that the code which is supposed to draw the fruits starts out by assuming the number of fruits should match the level number, checks if it's greater than 7, and if so sets it to 7. Then the logic to render the fruits works by repeatedly drawing a fruit, decrementing the number of fruits to draw, and looping until the decrement yields zero. If the level number was zero, the code tries to draw 256 fruits, overwriting display memory beyond the region where the fruits are supposed to go. – supercat Oct 02 '14 at 16:31
  • 28
    @LeeWhite That sounds very unlikely. As a software engineer, I don't know of any CPUs that work that way. If a number overflows, the '1' carried to the left of the number just goes away (and maybe also sets an overflow flag, depending on the architecture.) I'm not aware of any architectures that would overflow a number into the next memory address, especially since math doesn't usually happen directly on data in memory anyway. Math generally happens on data stored in registers and, after the math is complete, the data is written back to memory if needed. – reirab Oct 03 '14 at 14:54
  • 1
    @reirab Isn't that exactly what a buffer overflow is? – willoller Oct 03 '14 at 18:14
  • 9
    @willoller No, it isn't. Integer overflow and buffer overflow are two entirely separate, unrelated concepts. Buffer overflow is the result of failing to check the bounds of allocated memory before writing something to it (or reading something from it, as the case may be.) Integer overflow is when you perform an arithmetic operation that results in a number larger (smaller) than the maximum (minimum) value supported by the data type. Integer overflow does not cause a buffer overflow. It usually just causes the integer to 'wrap around' to the other end of its range of valid values. – reirab Oct 03 '14 at 18:20
  • Lee is saying it's not an integer overflow. If the integer overflows it would still fit in 8 bits. – willoller Oct 03 '14 at 19:29
  • 3
    @reirab: I don't think the situation Lee White is describing can realistically occur on the Z80, but something very similar can occur in code for 8088 used in the original PC. On the 8088, it was not uncommon on the 8088 for hand-written assembly code to use the upper and lower halves of a 16-bit register for different purposes; because e.g. INC BX was one byte but INC BL was two, code wanting to increment just the lower half of a register would often use the former if the existing value was known to be less than 255. If the value was 255, however, the upper byte would get clobbered. – supercat Oct 06 '14 at 17:01
  • 1
    @reirab: A related issue which can happen occasionally on the Z80, but more often on the 6502, is that when code which needs the carry to be clear is preceded by an arithmetic operation which is expected to finish with the carry clear, the programmer may not write an instruction to explicitly set/clear the carry. If the earlier operation has an unexpected carry out, the result of the latter operation may be corrupted as a result. The only likely scenario for that on the Z80 would be with SBC HL,xx` since otherwise math instructions can specify whether to use or ignore incoming carry. – supercat Oct 06 '14 at 17:03

2 Answers2

365

The Pacman Museum has an article about getting 3,333,360 Points. And here's a video of some guy doing level 255 and 256, with important information regarding level 256.

Level 1 through 255

Eating dots: There are 240 regular dots per level, worth 10 points each, Netting 2400 points per level. Additionally, eating the four energizer dots, worth 50 points each, gives you another 200 points.
⇒ 255 × 2600 = 663000

Eating "fruit": There is one edible object per level that only appears for a certain amount of time, twice per level. Depending on the type of fruit, which in turn depends on the level you are playing, you get a different amount of points. In total, you get
⇒ 2 × (100 + 300 + 2 × 500 + 2 × 700 + 2 × 1000 + 2 × 2000 + 2 × 3000 + 243 × 5000) = 2459600

Eating Ghosts: Eating a ghost in the same energizer period gives you 200 points, and double that for every additional ghost you eat (400, 800 and 1600 for the 2nd through 4th ghost, respectively). You can do this 4 times per level, but only up to level 16, and on level 18, since the ghosts don't blink in level 17 and 19+ ⇒ 4 × 3000 × 17 = 204000

Adding these numbers yields 3326600, just 6760 points short of perfect.

Level 256

This odd number can be gotten in the glitched-out level 256.

Screenshot of a normal Pac-Man level Screenshot of a glitched Pac-Man level

Visible Dots: As you can see, a bit more than half of the screen is missing, which means you can only get 112 normal and 2 energizer dots.
⇒ 1220

Single Fruit: Due to the glitched screen, you can only get the key (the "fruit") once
⇒ 5000

Glitched Dots: There are 9 normal dots in the glitched out region that reappear every time you die. At 5 extra lives, you can get them 6 times
⇒ 6 × 90 = 540

Grand Total

(663000 + 1220 + 540 (dots)) + (2459600 + 5000 (fruit)) + (204000 (ghosts)) = 3333360

Community
  • 1
MrLemon
  • 17,375
  • 6
  • 59
  • 83
  • 52
    I started typing the answer, thinking the numbers would add up just fine and they didn't. Took quite some time to find out about the weirdness that is the points in level 256. – MrLemon Oct 01 '14 at 20:57
  • 9
    256 is Quite an Important Number. – Howdy_McGee Oct 02 '14 at 20:23
  • 4
    @Howdy_McGee Especially on an 8-bit processor... – reirab Oct 03 '14 at 14:59
  • 2
    Is the 256th level glitch on purpose - or is that something that is an actual glitch? – RPiAwesomeness Dec 25 '14 at 00:22
  • 5
    @RPi_Awesomeness it's an actual glitch, that has to do with numbers rolling over in binary. 256 is 100000000 in binary, but the number doesn't support more than 8 binary digits, thus cutting of the 1, making it 00000000, which is 0. For some not really related problem, this causes the glitching, rather than putting you in level 0 again. – MrLemon Dec 25 '14 at 22:06
  • Note that in the 20th and 25th Anniversary cabinets, there are 10 edible dots on the glitch side of Level 256, and AFAIK just enough to allow an additional key to spawn if you didn't lose a life before. – Ray Feb 07 '22 at 04:49
42

The score is limited because a glitch occurs on level 256 which overwrites half the screen with garbage. The game won't let a player advance from one board to the next without eating 244 dots and energizers, but the glitch overwrites many of the dots; this will leave the player unable to eat 244 dots and energizers, and thus unable to leave the level. In case you're wondering about why the glitch occurs, the machine code in Pac-Man to draw the fruits is similar to the C code:

unsigned char temp1, temp2;
unsigned char *ptr;

temp1 = level;
if (temp1 > 15) temp1 = 15;
temp2 = temp1;
if (temp2 > 7) temp2 = 7;
ptr = LOWER_RIGHT_ADDRESS;
do
{
  *ptr++ = shapes[temp1--];
} while(--temp);

Note that unlike many machines, Pac Man uses a rather curious screen memory layout which places consecutive bytes horizontally on the top and bottom of the screen, and vertically in the middle. This was most likely done to make it so that when drawing the main portion of the screen, memory addresses would be incremented by a power of two every eight scan lines (note that the "top" of the monitor is at the right side of the picture). Essentially, circuitry converted row/column indices to memory addresses with a mapping similar to:

//Using column values in the range 30 to 1, wrapping after 63...
address = (column & 32) ? 
          (row << 5) | (column & 31) :
          ((28 | (column & 3)) << 5)  | row);

but implemented in circuitry rather than code. This allowed screen addresses to be computed by using a pair of counters and a circuitry to select one of two permutations of those counters' bits. The hardware required to have memory address increase by 36 for each row rather than 32 would have been more complicated by comparison.

supercat
  • 619
  • 4
  • 6
  • 19
    @Kevin: The stated score is the maximum possible in Pac Man because the bug shown above (in C code which is functionally similar to the Z80 code in the game itself) writes useless junk over much of the screen, overwriting the dots the player is supposed to eat. The other answer states what visibly happens to limit the score, but the above indicates (for technically-minded readers) why it happens (and suggests that the 256-level limitation probably wasn't deliberate but instead occurs due to an oversight). – supercat Dec 02 '14 at 16:00
  • 8
    Both answers complement the question exceedingly well. – Shon Jun 20 '15 at 19:01