Saturn Lander

Saturn Lander is a lunar-lander-style game set above a procedurally drawn Saturn landscape, where the player must guide a spacecraft to a safe touchdown using horizontal and vertical thrust controls. The terrain is rendered using a series of PLOT and DRAW commands that build a jagged mountain silhouette across the bottom of the screen, while a ring system and planet body are drawn in UDG characters loaded from DATA statements. Machine code routines are POKEd into memory starting at address 32000 via a hex-string decoder in lines 9502–9590, which converts ASCII hex pairs (with letters offset by 7) into raw bytes. The lander sprite is drawn and erased using OVER 1 mode, allowing flicker-free movement without explicit background restoration. Landing success is determined by checking POINT values beneath the craft’s feet and testing that horizontal velocity is within 0.25 and the altitude is low enough (SY≤5).

---

Program Analysis

Program Structure

The program is divided into several functional regions:

1. Lines 3–16: REM header block with title and attribution.
2. Lines 17–32: Scene drawing — Saturn’s surface terrain via PLOT/DRAW, and the ring/atmosphere belt.
3. Lines 35–55: UDG-based planet and ring graphics printed at fixed screen positions.
4. Lines 60–200: Main game loop — lander physics, sprite drawing, collision detection, and input handling.
5. Lines 1000–1060: Crash sequence with flashing explosion, score display, and restart.
6. Lines 2000–2030: Successful landing sequence with score calculation.
7. Lines 8900–9070: Initialization routine — prints controls, loads UDG pixel data from DATA statements.
8. Lines 9502–9700: Machine code loader — decodes hex strings from DATA and POKEs bytes into memory.
9. Lines 9998–9999: SAVE and VERIFY the program with auto-run from line 8900.

Machine Code Usage

Four machine code routines are loaded into high memory via a hex-string decoder (lines 9502–9590). The DATA lines at 9610–9640 contain the start address followed by a hex string, terminated by "N" (next block) or "S" (stop). Each two-character hex pair is decoded: if a character’s CODE is above 64 (i.e., it is a letter A–F), 7 is subtracted to bridge the gap between ASCII digits and uppercase letters, yielding the correct nibble value. The formula 16*CODE A$ + CODE A$(2) - 816 reconstructs each byte.

The routines are placed at:

Address	Called at	Purpose (inferred)
32000	Line 35 (RANDOMIZE loop)	Seed/timing utility
32100	—	Secondary utility
32200	Line 75	Called each game loop iteration (likely delay/sync)
32300	Line 35	Called in RND seed loop

Line 35 uses LET L=USR 32300 inside a FOR/NEXT loop with a random iteration count to introduce timing randomness at startup. Line 75 calls USR 32200 each game loop cycle, likely as a frame-rate limiter or display sync routine.

UDG Graphics

Lines 9000–9070 load 128 bytes of pixel data into the UDG area starting at USR "A", defining 16 custom characters (UDGs \a through \p). These are used in line 51 to build the string r$ which paints Saturn’s rings and cloud bands across the screen at rows 4, 8, 12, 15, and 17. The ring pattern string is 60 characters wide — wider than the 32-column display — and a rotation trick in line 45 (R$(15 TO )+R$( TO 14)) shifts the string by 14 characters before printing the second copy, creating a visual offset between ring rows for a curved perspective effect.

Note that line 50 defines R$ using plain ASCII letters, which is immediately overwritten by line 51 using the actual UDG escape sequences. Line 50 appears to be a commented-out or leftover draft that has no runtime effect since line 51 redefines the same variable.

Sprite Drawing and Collision Detection

The lander sprite is drawn by subroutine at line 18, which uses PLOT to set six pixels forming a small spacecraft shape. The program uses OVER 1 (XOR mode) throughout: drawing the sprite a second time at the same position erases it. This is the standard ZX Spectrum flicker-free sprite technique — line 70 calls the subroutine to erase the old position, then lines 71 onward update coordinates and redraw.

Collision detection uses POINT to sample eight pixels around the lander’s bounding area (line 80). If any of these return 1 (lit pixel), the craft has hit an obstacle and the crash routine at line 1000 is triggered. Landing detection (line 65) checks three specific pixels just below the landing legs; if all three are set, the craft is over the landing pad region.

Safe landing conditions (line 2000) additionally require ABS HU <= 0.25 (near-zero horizontal velocity) and SY <= 5 (close to ground level).

Physics Model

The game uses a simple Euler-integration physics model. Each loop iteration:

• HU (horizontal velocity) is incremented by ±0.25 per keypress of “1” or “3”, clamped to ±3.
• VV (vertical velocity) increases by 0.25 each frame (gravity), reduced by 0.5 when “2” is held (upward thrust net = −0.25).
• Position is updated: SX = SX + HU, SY = SY - VV.
• A ceiling check on line 68 resets VV to 0 if SY > 165.

Velocities are displayed each frame via PRINT #1 (the lower status line), truncated to two decimal places using the idiom INT(x*100)/100.

Score Mechanism

The score variable S is incremented each game loop by 1 - (INKEY$ <> ""): it counts up every frame that no key is pressed, and does not increment when thrust is applied. This penalizes fuel use. On a successful landing, the displayed score is 200 - S, rewarding quick, efficient landings. On a crash, raw S is shown with no inversion.

Crash Animation

Lines 1000–1040 implement a 30-frame explosion: alternating OVER states (even/odd frame) flash an X-pattern drawn with PLOT/DRAW in INK 2 (red). Simultaneously, OUT 254 drives the speaker border port with value 55 on even frames and 0 on odd frames, producing a buzzing crash sound without BEEP.

Notable Anomalies

• Line 50 defines R$ with plain ASCII letters; line 51 immediately redefines it with UDG characters. Line 50 is dead code at runtime.
• Line 24 contains DRAW OVER 0;16,-1 mid-sequence, locally switching OVER mode off for one segment of the terrain outline — this is syntactically valid as an inline attribute change within a DRAW statement.
• The DATA at line 9050 references the variable DATUM (as a BASIC expression, not a literal), meaning one byte of the UDG data is taken from whatever value DATUM held at the end of the preceding READ loop (the last value read in line 9010). This is likely unintentional but produces a consistent result since DATUM is deterministic after the loop.
• Line 8905 describes controls as “1-left, 2-right, 0-up” but the actual game logic in lines 76–77 uses “1”, “3”, and “2” for left, right, and up respectively. The instructions at line 8905 are incorrect.
• Line 8000 contains a bare STOP between the landing success routine and the initialization block, acting as a guard to prevent falling through into the setup code during normal play.