Kosmic is a speedrunner who usually focuses on Super Mario Bros., but he’s reached the kill screen in Donkey Kong before. With some help, he’s figured out a way to complete that game’s “kill screen,” the point where it’s usually impossible to continue.
At Level 22 of Donkey Kong, there is a bug that causes the game to only give Mario (nèe Jumpman) 400 bonus timer points to complete the level. (The screen displays 4000, but that’s caused by a different glitch.) Playing normally, that’s not enough time to reach higher than the second girder on-screen.
However. If the player has Mario climb the first broken latter, then hold down for four frames then up for one, Mario will climb up off the top of it by one pixel. Continuing to do this, Mario can continue to ascend the screen. When he reaches Pauline’s height, the game will declare the level completed and move on to the next screen.
As it turns out, the bonus count on the Barrels screen is tied to the barrels that Donkey Kong throws, and the timing on those is somewhat random. If DK is slow at emitting those rolling obstacles, rarely, that will give Mario just enough time to reach Pauline at the top, and advance to the next level.
Doing this physically is essentially impossible. The player would have to waggle the joystick extremely quickly (and loudly), yet with the precise timing to consistently raise Mario’s position, to get him up the screen in time, and even if that worked, he’d still have to be lucky enough that Donkey Kong was slow at rolling barrels. But in emulation, with tool assistance, Kosmic managed to get to the top and finish the level. Then using other tricks and glitches, he managed to finish the next three levels (Elevators, Barrels again and Cement Factory) too, before his luck ran out at the next Barrels screen and he was unable to continue.
I did a search of the blog to make sure I haven’t posted this before. I’m really an obsessive tagger, and it didn’t show up under the tag pacman, so I think it hasn’t been seen here before. Let’s fix that now!
It’s a video from Retro Game Mechanics Explained from six years ago, and it’s 11 1/2 minutes:
Here’s a terse summary of the explanation, that leaves out a lot. Like a lot of 8-bit games (the arcade version uses a Z80 processor), Pac-Man stores the score in one byte, making the maximum it can count to 255. Since it doesn’t use signed arithmetic, it doesn’t use the high bit to signify a minus sign and so flip to negative at 128.
As an optimization, Pac-Man’s code uses the depiction of the maze in the video memory, itself, in the movement of both Pac-Man and the ghosts. If a spot has a maze wall tile, then Pac-Man can’t go there, and the ghosts won’t consider that direction when moving.
At the start of every level, the game performs some setup tasks. It draws the maze anew, including dots, Energizers and walls. One of these tasks is to update the fruit display in the bottom-right corner. It was a common design idiom at some arcade manufacturers, especially at Namco, at the time to depict the level number with icons in some way. Galaga shows rank insignia in the corner; Mappy has small and large balloons and mansions.
Pac-Man’s code shows the bonus fruit for each level, up to seven of them. If you finish more than seven levels, only the most recent seven are shown. If you get far enough eventually this will be just a line of Keys, the final “fruit.”
The code draws them from right to left. There’s three cases (the video goes into much more detail), but generally it starts from the fruit of six minus the current round number, draws it, counts up once and moves left two tiles, draws that one, and so on.
An interesting fact about Pac-Man’s graphics hardware is that the screen doesn’t map as you might expect to the screen! A lot of arcade games have weird screen mappings. Most consumer programmable hardware will map characters horizontally first vertically second, like a typewriter*.
In Pac-Man, the bottom area of the screen comes first in memory, starting at memory location hex $4000 (16384 decimal), and it doesn’t go forward like an English typewriter, but is mapped right to left. The first row of 32 tiles comes at $4000, and the second row is $4020. Then the playfield area is mapped completely differently, in vertical rows going down starting from the top-right of its region, then the next vertical row is the one to the left of that, and so forth to the left edge of the playfield. Then comes the score area at the top of the screen, which are two final rows mapped the same way as the bottom area, right to left.
From the video, this chart shows how Pac-Man’s screen memory is mapped.
When Pac-Man’s score counter overflows, it breaks the check for the limit for only drawing seven fruit, and causes it to draw 256 fruit. This is why the tops of keys are drawn beneath the upper-halves of the fruit at the bottom of the split screen. It also breaks the tile lookup for the fruit.
As it continues writing its missourced fruit tiles in memory, it goes back in memory each time to draw the next fruit, and after the fruit section of the display it keeps going to the left, into the area where Pac-Man’s lives are displayed, then it keeps going and overwrites half of the maze tiles. Then Pac-Man’s lives (and any empty spaces that indicate the lack of lives) are plotted, overwriting fruit after the first ones drawn and obscuring some of the memory corruption.
Since the game’s actors use that data to decide where to move, and where dots and Energizers are placed, it means they can move outside the bounds of the maze, and that there won’t be enough dots for Pac-Man to eat to complete the level. That’s what makes it a kill screen: if Pac-Man loses a life, a few dots will get placed in the maze as the fruit are redrawn, but it’s not enough to bring the dot-eaten count to 244, which triggers the level clear function.
If the fruit-drawing loop didn’t stop at 256 (another artifact of using 8-bit math for the loop), it’d go on to clobber the rest of the maze, the score area at the top of the screen, then color memory (which has already been clobbered by the palette-drawing portion of the loop). Then, going by a memory map of the arcade hardware, it’d hit the game logic RAM storage, which would probably crash the game, triggering the watchdog and resetting the machine.
The visual effect of the split screen is certainly distinctive, enough that since Bandai-Namco has capitalized on its appearance at least once, in the mobile (and Steam and consoles) game Pac-Man 256. I’ve played Pac-Man 256: it’s okay, but, eh. It’s really too F2P unlocky.
* Yes, I just used a typewriter’s operation as a metaphor for something a computer does. It didn’t feel acceptable to use another computer thing as the comparison, since ultimately the reason they do it that way is because typewriters did it that way too. I guess the fact that it’s English reading order would be better to use, but I’m really overthinking it at this point.
