Gunner

Gunner is a shooting gallery game where the player moves a cannon left and right along the bottom of the screen, firing upward at two scrolling rows of random alphabetic characters. The scrolling text is stored in a single one-dimensional string array DIM A$(1,6000), with a window into it advancing by two characters per frame to create the horizontal scroll effect. Characters are drawn from CHR$(166) to CHR$(191), corresponding to the ZX81’s block-graphic and letter characters. The player scores points based on the ASCII value of the character hit (R-165), making letters deeper in the alphabet worth more. A special “@@ ” target occasionally appears in the scroll; if it reaches the leftmost visible position without being shot, the round ends.

---

Program Analysis

Program Structure

The program begins with a title/instructions block (lines 500–600) before jumping back to initialization. The main game loop runs from line 60 onward, with the bullet flight handled inline rather than in a subroutine.

1. Lines 1–2: REM header and GOTO 500 to skip to the title screen.
2. Lines 5–15: Initialize high score, cannon height, and the large scroll buffer array.
3. Lines 20–40: Pre-fill odd-indexed positions 1–65 of A$ with random characters (CHR$ 166–191).
4. Lines 45–135: Main game loop — display scores, draw the two scrolling rows and the cannon, handle keyboard input.
5. Lines 140–210: Bullet movement upward; uses PEEK of the display file to detect hits.
6. Lines 250–310: Hit processing — calculate score, erase the hit character from the scroll buffer, reset bullet.
7. Lines 350–470: End-of-round sequence; checks high score, prompts replay.
8. Lines 500–600: Title screen and instructions.
9. Lines 700–710: SAVE and RUN trailer.

Scroll Buffer Design

All scrolling data lives in DIM A$(1,6000), a single-row string array 6000 characters wide. The pointer N starts at 2 and increments by 2 each frame. The display routine prints A$(1,N TO N+31) on row 3 and A$(1,N+33 TO N+65) on row 5, giving two 32-character wide lanes. New characters are appended at A$(1,N+65) each frame, so the buffer grows rightward as the game progresses. Because N only increments, the program will eventually exhaust the 6000-character buffer after approximately 2967 frames without a round end.

Hit Detection via PEEK

Rather than tracking bullet-vs-character coordinates algebraically, the game uses a direct display-file inspection technique. Lines 155–156 place the print position at the bullet’s location, PEEK the display file address from system variables at addresses 16398–16399, read the character code already at that screen cell, then overprint with ".". If the PEEKed value R is non-zero (i.e., something other than a space was already there), a hit is registered.

• PEEK 16398 + 256 * PEEK 16399 gives the address of the current print position in the display file.
• A score contribution of R - 165 is calculated, so CHR$(166)=’A’ scores 1, up to CHR$(191) scoring 26.

Special Target (“@@”)

Approximately once every 40 frames (INT(RND*40)=10), the character appended to the buffer is the two-character sequence \@@ (rendered as a block-graphic pair). Line 95 checks whether A$(1,N+1) equals this token; if so, the round ends with a “got away” message. This means the special target must scroll entirely off the left edge of the visible window without being shot to trigger the loss condition.

Cannon Rendering

The cannon graphic occupies two screen rows: row 21 shows " \.: " (the barrel, using ZX81 block graphics) and row 20 shows " . " (the base). The horizontal position is controlled by variable Z, clamped between 1 and 28 by lines 110–120. Keys 5 and 8 move left and right; key 7 fires.

Bullet Flight

The bullet is a single "." character that travels from row 19 upward to row 3 in steps of 2 (H decrements by 2 per frame). Flag variable X tracks whether a bullet is in flight: X=1 means in-flight, X=0 means idle. When X<>0, keyboard input is skipped (line 105), so the player cannot move or fire again until the bullet resolves.

Score Erasure on Hit

When a hit occurs, the program attempts to blank the character in the scroll buffer at the appropriate offset. Line 280 handles a hit on row 3 (H=3) using A$(1,N+(Z-1))=" ", and line 290 handles row 5 (H=5) using A$(1,N+(32+Z))=" ". The index arithmetic is approximate and may be off by one depending on exact scroll position, which can cause occasional visual artifacts.

Notable Bugs and Anomalies

• The odd-index pre-fill loop (lines 20–40, STEP 2) only populates positions 1, 3, 5, …, 65, leaving even positions as null bytes (CHR$ 0). This means the initial scroll contains interleaved garbage/null characters until the per-frame append (line 80) fills the buffer further right.
• The bullet height variable H is initialized to 19 at line 8 but is reset to 19 only at line 300 (after a hit). A missed shot that reaches row 3 resets X=0 at line 200 but does not reset H, so the next shot starts from wherever H was last left (row 1 or 3), not from row 19. This is a definite bug.
• The INPUT at line 430 accepts full words “YES”/”NO” as well as single letters, but the GOTO loop is only re-entered if none of the four options match, meaning any other input is also silently accepted and falls through — the condition logic at line 460 then treats an unrecognized answer as “no”.
• The DIM A$(1,6000) on line 10 declares a two-index string array but is accessed throughout with single-index slice notation A$(1,…). This is valid ZX81 syntax for a 1-row string array.

Key Variables

Variable	Role
A$	6000-character scroll buffer
N	Current read offset into scroll buffer
Z	Cannon horizontal position (column)
H	Bullet vertical position (row)
X	Bullet in-flight flag (0=idle, 1=in-flight)
S	Current score
HS	High score (persists across rounds)
R	PEEKed character code at bullet position