Crasher

This is an arcade-style dodging game where the player moves a car left and right across the bottom of the screen to avoid rapidly changing road conditions. The program defines three custom UDG characters (UDGs “a”, “b”, and “c”) via POKE into USR addresses, using DATA blocks containing pixel patterns. Collision detection is performed using SCREEN$ and ATTR checks at line 120 and 155 rather than coordinate arithmetic, a common Spectrum BASIC technique. The title screen loops with a randomized border color effect via OUT 254 and plays continuous BEEP tones while waiting for a keypress on keys “5” or “8”. A high-score melody is stored as NOTE/DURATION pairs in DATA statements starting at line 9040 and replayed via BEEP in a READ loop.

---

Program Analysis

Program Structure

The program is organized into several functional regions:

1. Lines 1–10: Initialization — calls UDG setup subroutine at 8010, dimensions the screen buffer string i$ (704 chars = 22 rows × 32 cols), sets high score h=100, jumps to the attract loop.
2. Lines 20–160: Main game loop — resets score and positions, cycles through 11 scoring rounds (FOR s=0 TO 10), moves the falling object, reads player input, checks for collision.
3. Lines 200–243: End-of-round and attract screen — shows score, plays death tune, branches to high-score routine if appropriate, redisplays title and waits for “5” (play) or “8” (toggle noise).
4. Lines 245–249: Noise-off wait state — waits for “5” to play or “8” to resume noise loop.
5. Lines 500–550: High-score celebration — prints congratulatory message, plays a tune from DATA, updates h.
6. Lines 8010–8070: UDG loader — pokes pixel data into UDG addresses for characters “a”, “b”, “c”.
7. Lines 9040–9080: Music DATA for high-score tune (note, duration pairs).
8. Lines 9500–9510: Screen-clear subroutine — uses i$ to OVER 1 print 704 spaces, then CLS, resetting attributes cleanly.
9. Line 9998: SAVE with auto-run.

UDG Character Definitions

Lines 8010–8070 define three UDGs by reading DATA bytes and POKEing them into memory starting at USR "a" through USR "c"+7. The loop iterates over all 24 bytes (3 UDGs × 8 bytes each).

UDG	Data (hex approx.)	Role
\a (UDG “a”)	0,62,8,62,28,62,28,0	Falling ball/object
\b (UDG “b”)	255,170,213,170,213,170,213,255	Left half of paddle
\c (UDG “c”)	255,171,85,171,85,171,85,171,255 (9 bytes — see anomaly)	Right half of paddle

Note: the DATA block for UDG “c” at line 8060 contains nine values rather than eight. The loop runs from USR "a" to USR "c"+7, which is exactly 24 iterations, so the ninth value (171) is read but never POKEd — it is effectively ignored. This is a minor data anomaly but causes no runtime error.

Game Mechanics

The falling object’s column c starts at 12 and is fixed; its row r is updated each iteration with a random walk: r decrements if rnd=1 and r>1, or increments if rnd=0 and r<20. This produces a side-to-side drift rather than a downward fall — the variable names r (row) and c (column) are used in a somewhat reversed sense from convention.

Player input is read at line 110: keys “5” (left) and “8” (right) move the catcher column c. The program also polls PEEK 23560 (the last key pressed system variable) to detect key 9 (ASCII 57) as a repeat-prevention guard, then resets it to 54 (key “6”) at line 115 — an unusual choice for debouncing.

Collision Detection

Two checks are used in sequence:

• Line 120: SCREEN$ (16,c) — if the cell at the car’s screen position is not a space, a collision is flagged and the game jumps to line 200 (game over). A non-space result means the paddle is under the ball.
• Line 155: ATTR (16,c) — checks the attribute byte; value 122 corresponds to BRIGHT 1, PAPER 4, INK 2 (the wall’s color scheme). If the attribute doesn’t match, the car crashed and the game ends.

Using both SCREEN$ and ATTR together provides a more robust test than either alone, though in practice the SCREEN$ check at line 120 will catch most misses before line 155 is reached.

Screen-Clear Subroutine (Line 9500)

Rather than simply calling CLS, this subroutine PRINTs the 704-character string i$ (initialized as spaces by DIM) with OVER 1 at position 0,0, effectively XORing the existing screen contents before clearing. This technique removes any lingering INK/PAPER attribute color bleed that a plain CLS might leave in certain display states. It also resets POKE 23624,0 (the scroll counter).

Attract Screen and Sound Loop

The attract loop at lines 240–249 plays a sweeping BEEP tone (notes 3 to 6, step 0.5) while randomly changing the border color via OUT 254, INT(RND*7). Two states are implemented: noise-on (line 240 loop) and noise-off (lines 247–249 wait loop), toggled by pressing “8”. Pressing “5” at any point jumps to line 20 to start the game.

High-Score Routine

The high-score subroutine (lines 500–550) plays a 15-note melody stored as interleaved NOTE, DURATION pairs in DATA lines 9040–9080. The READ loop at line 540 uses a slightly unusual construction: IF INKEY$="" THEN NEXT n: GO TO 510 — note that line 510 does not exist, which causes the program to fall through to the next available line (line 530 area). This is a deliberate GO TO non-existent line technique to restart the display portion without re-entering the subroutine fully. However, there is a potential issue: RESTORE 9040 is called each time, and the loop variable n is reused, which could interact with the outer game loop’s use of n in some edge cases.

Notable BASIC Idioms

• Boolean arithmetic for movement: r=r-(rnd=1 AND r>1)+(rnd=0 AND r<20) uses the Spectrum’s TRUE=1/FALSE=0 convention to avoid IF statements.
• Similarly, c=c+(INKEY$="8")-(INKEY$="5") moves the paddle in one expression.
• POKE 23692,12 sets the scroll count to suppress the “scroll?” prompt during the game loop.
• The title screen text at line 235 uses block graphic escape sequences to render a decorative logo banner.