Bounce

This program implements a bouncing ball animation entirely in Z80 machine code, embedded in REM statements and executed via RAND USR 16908. The machine code manipulates display memory directly, using 16-bit address arithmetic to move a ball sprite around the screen and handle boundary collisions. Two REM lines carry the full binary payload: the first (line 0) contains the primary routine, and the second also line 0 (a known multi-line-zero trick) stores additional data tables and vectors. Line 2 contains patching notes for the developer, listing key addresses and byte values used to redirect execution flow. The program loops continuously via GOTO 1, re-entering the machine code on each pass.

---

Program Analysis

Program Structure

The listing is minimal at the BASIC level, with almost all logic residing in Z80 machine code stored in REM statements:

1. Line 0 (first) — REM with an inverse-video title “BOUNCE”.
2. Line 0 (second) — REM containing the full machine code payload (approximately 280+ bytes of Z80 opcodes encoded as hex escapes).
3. Line 1 — RAND USR 16908 transfers control to the machine code at address 16908 (0x420C), which falls inside the second REM line’s data area.
4. Line 2 — Developer commentary listing patch addresses and byte values needed to relocate or hook the routine.
5. Lines 3–4 — SAVE followed by GOTO 1 to continuously re-run the animation.

Machine Code Entry and Memory Layout

RAND USR 16908 (decimal) equals USR 0x420C. On a TS2068/ZX Spectrum, the system variables area ends well below this, so 0x420C lands squarely in the second REM line’s payload. The code sets up its own internal pointers using absolute 16-bit addresses (22 xx xx = LD (nnnn),HL; 2A xx xx = LD HL,(nnnn)), making the routine position-dependent at these fixed addresses.

Display Memory Access

The machine code accesses display RAM directly. Several instruction sequences load HL or DE with addresses in the 0x4000–0x5AFF range (the Spectrum/TS2068 display file and attribute area). The pattern 19 (ADD HL,DE) combined with 71 (LD (HL),C) and short DJNZ loops (10 Fx) is a classic tight sprite-drawing idiom, writing pixels row by row across display lines.

Key Z80 Idioms Identified

• 11 xx xx / 19 — Load DE with a stride value and repeatedly add to HL to step through display memory rows.
• 10 Fx — DJNZ short loops for pixel/attribute row iteration.
• ED 5B xx xx — LD DE,(nnnn) to fetch ball position from a workspace variable.
• 22 xx xx / 2A xx xx — Store/recall 16-bit ball coordinates in fixed workspace locations.
• 7E B7 — LD A,(HL); OR A to test a display cell for non-zero content (collision detection).
• C3 xx xx — Unconditional JP used for main loop branches and dispatch.
• 18 xx — Relative JR for short local branches.
• E5/E1 — PUSH HL/POP HL used to preserve the ball’s address across sub-operations.

Bounce / Collision Logic

The routine reads the ball’s current screen address from a workspace cell, draws the ball, then tests the target cell’s content. When OR A finds the cell non-zero (another pixel already present, i.e., a wall or boundary), the velocity component is negated by branching to an alternate delta-add path. The direction vectors appear to be stored as signed 16-bit offsets (e.g., 0x004D, 0xFF B0) applied via ADD HL,DE to the current display address, giving horizontal and vertical movement independently.

Data Tables

Near the end of the second REM block, a sequence of values 21 22 23 24 25 1C 1D 1E 1F 20 21 22 23 24 25 1C appears to be a lookup table, likely encoding the ball sprite shape or a cyclic animation frame table, referenced by an index that increments on each frame.

Developer Patch Notes (Line 2)

Line 2 is a plain-text memo to the programmer listing addresses and patch bytes:

Label	Address	Value/Note
CDE702	—	Opcode bytes for a JP 0x02E7-style hook
Q 217D40	0x407D	Workspace pointer (ball position low byte?)
222940	0x4029	LD (0x4029),HL — stores a vector
C3FC02	—	JP 0x02FC — likely a BASIC interpreter re-entry

GOTO Loop

GOTO 1 at line 4 creates an infinite BASIC loop that re-executes RAND USR 16908 on each iteration. In practice the machine code itself contains an internal loop (18 C8, 18 C1, C3 91 40, etc.) and never returns to BASIC during normal animation; the GOTO serves as a safety net if the routine ever exits cleanly.

Potential Anomalies

• Two lines both numbered 0 — the second silently shadows or appends to the first depending on the interpreter’s line-lookup behaviour; this is intentional to pack the code before line 1.
• The routine uses absolute addresses throughout, so it is not relocatable without the patches documented in line 2.
• The SAVE "1023%7" on line 3 is reached via fall-through from line 1 only if RAND USR returns, which under normal operation it does not.