Pac-Man (Mark Burkley's C translation of the ROM)

In chase mode each Pac-Man ghost steers toward its own target tile. Blinky targets Pac-Man's tile. Pinky targets Pac-Man's tile plus 4 times his direction vector, and Inky takes Pac-Man's tile plus twice the vector, doubles it, and subtracts Blinky's tile. The Z80 does both sums as 16-bit adds of a packed two-byte tile and vector (add hl,hl, add hl,de), so a carry out of the low byte's axis spills into the other axis; away from such a carry, Pinky's target is 4 tiles ahead of Pac-Man and Inky's starts 2 ahead. Clyde targets Pac-Man's tile while the squared distance between them is 64 or more, that is 8 tiles or farther, and otherwise heads for his scatter corner. The translation reads MAME's pacman set, Midway's release. pac-man/ghost-targets

About: Pac-Man Enemy targeting

{
 "pinkyMultiple": 4,
 "inkyMultiple": 2,
 "clydeRadius": 8
}

The C translation computes each axis apart, so it drops the carry between the packed bytes; the statement follows the Z80. Which byte holds which axis, and so which directions carry, isn't read here.

Cited by: Enemy targeting, Pac-Man

findBestOrientation_2966 turns a target into a move: it tries the four directions in turn, skips the reverse of the ghost's current one and any that points into a maze wall, and keeps the one whose next tile has the smallest squared distance to the target; on a tie the later direction wins. pac-man/steering

About: Pac-Man Enemy targeting

Cited by: Enemy targeting, Pac-Man

A mode counter at $4DC1 runs from 0 to 7: on even values the ghosts head for fixed scatter tiles, on odd values they chase. ghostsChangeOrientation_0e36 counts time and steps the counter when the count meets a 16-bit entry for the current mode, then flags all four ghosts to reverse. At 7 it stops, so the game holds four scatter phases and leaves the fourth chase phase on for good. The count pauses while Pac-Man is powered up. pac-man/modes

About: Pac-Man Enemy targeting

{
 "scatterPhases": 4,
 "chasePhases": 4
}

The C names the counter NONRANDOM_MOVEMENT and the table DIFFICULTY_TABLE; the durations sit in ROM data the repo doesn't include, so the atlas states no times.

Cited by: Enemy targeting, Pac-Man

A frightened ghost picks a random direction from random_2a23, which steps a pointer as $p\leftarrow (5p+1)mod8192$ and returns the byte at that address, so the game's own first 8 KB of ROM serve as the random table. The direction is the low 2 bits; a reversal or a wall sends it on to try the next one. pac-man/frightened-rng

About: Pac-Man Random number generator

{
 "multiplier": 5,
 "increment": 1,
 "modulus": 8192
}

The repo's comment adds that the movement differs "unless original ROM data is used", since the table is the ROM itself.

Cited by: Pac-Man

Pac-Man awards one extra life when the score reaches the DIP-switch setting: 10,000, 15,000, or 20,000 points, or never. The table holds BCD thousands (10, 15, 20, and $FF for none). After each score change the code compares the score's ten-thousands and thousands digits with the setting, and a flag bit stops a second award. pac-man/bonus-life

About: Pac-Man Extra life

[
 10000,
 15000,
 20000
]

Cited by: Extra life

Each new level advances a pointer one entry along a difficulty table until the entry reads $14 (20). The DIP switch picks the table: one runs 0, 1, 2, … 20 and reaches 20 on level 21; the other, which the comment calls hard, runs 1, 3, 4, 6, 7, 8, … 17, 20 and reaches 20 on level 16. Each entry selects a 6-byte record at $0796 that sets, among other things, the movement pattern and the ghosts' counters for leaving the house. pac-man/difficulty

About: Pac-Man Difficulty ramp

{
 "normal": 21,
 "hard": 16
}

Cited by: Difficulty ramp

Pac-Man keeps one high score, three BCD bytes at $4E88. After every change to a player's score it compares the score with it from the top byte down and, if the score is higher, copies the 3 bytes over and redraws it. pac-man/high-score

About: Pac-Man High score

Cited by: High score

The level byte at $4E13 starts at 0 and gains 1 per level, so on level 256 it holds 255. The routine that draws the fruit row loads it and adds 1, and that inc a wraps to 0; 0 passes the "fewer than 8" test, and the draw loop, a djnz counted by that 0, makes 256 passes instead of at most 7. Each pass draws a fruit at HL, writes its color $400 higher, and moves HL on 2 bytes, so from $4004 the loop steps across about 512 bytes of the 1 KB video RAM at $4000 and the matching span of color RAM at $4400. pac-man/level-256

About: Pac-Man Kill screen

Value: 256 fruit-loop passes on level 256

The C translation drops the inc a (it reads int level = P1_LEVEL;), so it wouldn't reproduce this; the claim rests on the kept Z80 lines. How many bytes each fruit draw writes (2B8F, 2B80) isn't read, and what the screen shows on level 256 is not stated here.

Cited by: Kill screen