Alien Invasion

This is a Space Invaders game for the ZX81/TS1000, written by Dave Edwards, that relies heavily on a large Z80 machine code routine embedded in line 0’s REM statement. The machine code (loaded at address 16516 and called via RAND USR) handles the main game engine including alien movement, collision detection, and rendering, while the BASIC layer manages scoring, lives, difficulty levels, and the AY/beeper sound effects generated through direct port manipulation via POKE to addresses 32767 (A) and 32766 (D). Three difficulty levels are offered (Beginner, Advanced, Expert), each affecting alien speed and the number of waves before the game ends. The score display uses inverse-video digit characters constructed by adding 128 to character codes, and the high-score name entry with persistent storage across playthroughs is handled entirely in BASIC. Sound generation uses a noteworthy technique: subroutine at line 850 drives an I/O port in a tight FOR-NEXT timing loop, reading frequency and duration data from the string arrays C$, F$, and L$.

---

Program Analysis

Program Structure

The program is divided into distinct functional regions:

1. Line 0: A large REM statement containing the entire Z80 machine code game engine (approximately 800+ bytes of hex-encoded opcodes).
2. Lines 1–5: Title/author REMs, a decorative inverse-video banner line, a GOTO 10 bypass, and a SAVE line.
3. Lines 10–95: Initialisation — USR call to machine code setup, variable initialisation, difficulty level selection, and POKE-based configuration of machine code parameters.
4. Lines 100–278: Main game loop — wave management, score display, USR calls into the machine code engine, and result dispatching.
5. Lines 280–590: End-game handling — base destroyed, planet invaded, score extraction, high-score comparison, and name entry.
6. Lines 600–799: Sound and utility subroutines, including the tone-generation engine and level-specific configuration POKEs.
7. Lines 800–828: Machine code parameter patch subroutines (modifying bytes within the REM block at runtime).
8. Lines 830–990: Port-driven sound player subroutine using string tables.
9. Lines 991–996: Score extraction from machine code memory.
10. Lines 999–1010: REM byte-count label, SAVE, and RUN.

Machine Code Engine

The program stores its entire Z80 machine code payload in the REM statement at line 0. This is the standard ZX81/TS1000 technique for embedding machine code: the REM body begins at a known offset from the start of BASIC, and RAND USR 17374 (line 10) jumps directly into it. The engine handles the core game loop: alien grid movement, player cannon control, missile/bomb physics, collision detection, and display rendering — tasks that would be impossibly slow in interpreted BASIC at arcade speed.

A second entry point at USR 16516 (line 130) initialises the game field, and USR 16622 (line 170) advances alien movement by one step. The return value from USR 17640 (line 200) encodes the game state: 1 = base hit, 2 = invasion, other = still playing.

Runtime Machine Code Patching

Several subroutines (lines 800–828) modify bytes inside the REM block at runtime using POKE to addresses in the 17000–17700 range, effectively patching machine code instructions or data tables to alter game behaviour. This is used to switch between game modes (e.g., toggling between two firing patterns or speed tables). For example, line 820 POKEs address 17677 with 230 (Z80 opcode AND) and address 17678 with 112, overwriting a previously patched instruction. Lines 800–818 patch complementary code paths for different fire rates.

Sound Generation

The sound subroutine at lines 830–990 drives I/O ports directly using two fixed addresses stored in variables A (32767) and D (32766). Frequency data is encoded as character codes in the string F$, timing/duration data in L$, and a secondary channel parameter in C$. For each note step N from P to Q, the subroutine:

• POKEs port A with 7 (select register), port D with 255 (silence all channels)
• POKEs register 4 with CODE F$(N) (tone frequency)
• POKEs register 5 with CODE C$(N) (second channel data)
• POKEs register 7 with 251 (enable output)
• Executes a FOR/NEXT delay loop timed by CODE L$(N)-2

This is consistent with driving an AY-3-8910 or compatible sound chip via I/O ports, as found on the TS2068 and certain ZX81 sound expansions.

Difficulty and Wave System

The variable L (1–3) controls difficulty. It is written to address 17223 via POKE for the machine code to use, and also affects the BASIC-side wave counter: the game advances to the next wave when S equals 5-L (so Expert requires only 2 waves per life, Beginner 4). Alien speed is configured at line 90 by POKEing 65+(4-L)*25 to address 17626, giving values 90, 65, or 40 for levels 1–3 respectively. The cannon starting X-position is set at line 110 as 67+33*L.

Score Extraction

The score is not maintained in a BASIC variable during play but is stored inside machine code memory. The subroutine at lines 991–996 extracts it by reading four consecutive bytes relative to a pointer held at addresses 16396–16397 (the BASIC variable area pointer), subtracting 156 from each byte and weighting them as powers of 10. This implies the machine code stores the score as four BCD-like digits packed into display character codes (156 being an offset into the character set).

High Score Display

The high score display string H$ is initialised to five inverse-zero characters ("%0%0%0%0%0"). When a new high score is set, the score is converted via STR$ and each digit character code has 128 added (lines 540), converting it to an inverse-video digit for display in the header line. The player’s name N$ is stored in a BASIC variable and persists for the session.

Key BASIC Idioms

• POKE A,x / POKE D,y — using numeric variables for frequently-used port addresses avoids re-parsing literal numbers in the hot sound loop.
• X AND X>0 (line 190) — the classic ZX81 idiom for MAX(X,0): if X>0 is true (=1), result is X; if false (=0), result is 0.
• 2**(S+1)*2**(L+1) (line 180) — uses ZX81’s ** (exponentiation) to compute scaling factors for the alien speed threshold.
• RAND USR — used throughout instead of plain USR to discard the return value (RAND ignores its argument when it is an integer result of USR).
• 10**(N+1) (line 994) — uses exponentiation for place-value weighting during score extraction.

String Tables for Music/Sound

Variable	Role	Encoding
C$	Channel 2 tone / noise data	Block graphic characters, values read via CODE
F$	Frequency register values	Mixed printable and token characters
L$	Note duration (loop count = CODE-2)	Block graphic / symbol characters

Notable Anomalies

• Line 14 (F$) and line 15 (L$) contain BASIC keyword tokens (e.g., RND, CHR$, IF) embedded as string literals. On the ZX81/TS1000, these are stored as single-byte token codes in the string data and are read back with CODE, yielding values in the 192–255 range — used intentionally as frequency and duration data.
• The subroutine at line 790 shares its first two lines (790–791) with the level-configuration POKEs that fall through from line 95 (GOSUB 790+10*L): for L=1, entry is at 800; for L=2, at 810; for L=3, at 820. Line 790 itself is also the tail of the wave-configuration block (lines 790–799). This means the GOSUB dispatch cleverly reuses code for both purposes.
• The delay loop at line 600 (FOR N=1 TO 30 / NEXT N) is a simple busy-wait pause with no display or sound activity — used as a brief pause after end-game messages.