At $8B60, outside the table RUN_SCRIPT counts its scripts from, is one more in the same format: a PRINT AT near the bottom of the view, then letters between notes. Its letters spell "OWCH!". Nothing refers to it. It would not work as it is either: it has no stream byte at the front, and an end marker sits between the C and the H, so run by the game's own RUN_SCRIPT from a copy with a stream byte put in front, it plays its notes and prints only the first three letters:

Frames $F0-$F3 (at $BC00), between the boy's last pose and the grenade's flight, are never drawn. PROJECT_SPRITES picks an object's frame from +$08: with bit 7 set, the frame is +$08 itself, and nothing writes such a value except the blast frames $F4-$F7 (BLAST_FRAME, CHOOSE_FRAME, THROW_GRENADE); otherwise it is the first frame plus four times +$08 plus the facing, and +$08 is never more than 4 for the people and 1 for the ants. The boy's twenty frames end at $EF and the ants' eight start at $F8. What the four were meant to show -- they are drawn on the sprites page -- is not known.

The grenade's record gives frames $68-$6B as its sprite (at $9A00): a large round bomb with a fuse, stored with the girl's frames. In flight and exploding it is drawn as $F4-$F7 instead, and when it has gone off it goes home -- to x 0, y $40, far outside the city, where it waits for the next throw. Nobody need ever go there, but it is open ground, and anyone who walks out that far finds the big grenade sitting there: watched in the emulator, with the player put two cells from it.

The interrupt routine, INTERRUPT, passes each interrupt to the ROM unless an error is waiting in ERR_NR -- and then, instead, it types RUN and starts the BASIC again (RESTART_BASIC). So BREAK, which the ROM turns into error L between BASIC statements, takes the game back to its title screen rather than stopping it. Watched in the emulator: CAPS SHIFT and SPACE at the girl-or-boy question stopped at RESTART_BASIC with ERR_NR holding $14 (report L), and the title came round again. During play the machine code never lets the ROM look for BREAK, so the same two keys only pick view 0: 30 frames of them changed nothing else.

When either energy reaches 0 (CHECK_GAME_OVER) the level simply starts again: BASIC's line 60 ends the game only when the time has run out, and otherwise line 70 says "Have another go!" and sets the level up afresh, both energies back to 20 -- but not the clock, which only line 20 resets, after a rescue. So there are no lives: every failure costs only the time it took. Watched in the emulator: the player eaten with 968 left on the clock was back at the gate, ready to go, with 968 still on it.

Key 1 goes back to the gate: PLAY returns to BASIC the moment it sees it, and BASIC treats that as a failed attempt. The level is set up again from its DATA (line 100), with 20 grenades and both energies full, and the person to be rescued back at their post -- while the clock runs on from where it was. Watched in the emulator: with 18 grenades, 17 energy and 979 on the clock, pressing 1 gave 20, 20 and 978.

The only randomness in the machine code is RANDOM, a 32-bit shift register at $B428, which decides which way an ant turns when it is not getting closer (and makes the hiss of NOISE). BASIC's line 210 sets it to 1, 1, 1, 1 with the other variables at the start of every level and every retry, so an attempt played with the same keys on the same frames plays out the same, ant for ant. Watched in the emulator: it held 1, 1, 1, 1 at the start of PLAY on a retry, as on a new level.

Every time PLAY finishes normally it copies the first byte of its random number into the ROM's SEED, for BASIC. BASIC calls it as RANDOMIZE USR 32768, and RANDOMIZE then stores its own argument, the USR result, in SEED on top of it -- and the BASIC has no RND anywhere to use either. Watched with a watchpoint on SEED: the write at $802F was followed at once by the ROM's own at $1E5A.

Nothing in the game tests one object against another for collisions. Each ant is a set bit in the city map at CITY_MAP, XORed out by TOGGLE_MAP_BIT before it moves and back in after (MOVE_ANT), so everything else walks into it as into a wall, and a bite is simply finding one's own cell occupied (MOVE_OBJECT). The map in memory changes as the ants walk. See how the game works.

The game is one headerless block of 41984 bytes loaded to $5C00: over the system variables and the BASIC program that is loading it, and on to the top of memory. The loader survives because it never returns to that program -- LD-BYTES returns to LOADED, which switches to its own interrupt routine and types RUN into the game's own BASIC, loaded with everything else.

BASIC's line 90 scores a rescue as the time left on the clock times the number rescued so far, including this one: the same speed is worth ten times as much on the tenth level as on the first. The time left also decides where the next person waits (see the levels).

COUNT_DOWN_TIME takes a tick off the clock every third frame, and there is no frame pacing anywhere: a frame takes as long as the drawing does. The clock's 1001 ticks are 3003 frames, and at the 500,000-600,000 T-states a frame measured for this disassembly (six or seven frames a second) that comes to about eight minutes -- more in a busy view, less in an empty one.

Of the five ants, the first always rests only one frame in 20 (line 140), while the other four rest every other frame until the fourth rescue, and one frame in three or four after it (ANT_TURN). Counted in the emulator over the first 60 frames of level 1: 57 steps for the first ant, 30 for each of the others.