London Bridge

London Bridge is a single-player puzzle/strategy game in which the player navigates a piece across a 5-column grid of numbered cells, trying to reach the far side of a simulated bridge before falling into the water. The board is stored in a 66-element array A(), with cells 11–60 holding random values 1–5 (mapped to characters via CHR$(28+value)), and movement is controlled by a 1–9 numeric keypad-style direction input. The subroutine at line 500 uses integer/fractional decomposition of a cell index to calculate screen AT coordinates in a compact 5×10 grid layout, and the scoring system at line 900 rewards diagonal moves and colour-matched cell pairs. FAST/SLOW mode switching is used to speed up the initial board draw before returning to interactive pace.

---

Program Analysis

Program Structure

The program is organised into a clear sequence of phases:

1. Initialisation (lines 1–90): Screen setup, array allocation, bridge art drawn with block graphics, WR value displayed.
2. Board population (lines 90–135): Cells 11–60 in array A() are filled with random integers 1–5; each is rendered on screen via GOSUB 500.
3. Game loop (lines 140–440): Player starts at cell N=8, chooses a direction 1–9, move validity is checked, score is updated, and the loop repeats.
4. Outcome handlers (lines 600–819): Falling into water (line 600) or crossing the bridge (line 800) both offer a replay prompt.
5. Subroutines: Display cell (500), update score (900), short delay (7000), end screen (6000).

Array Layout

Array A(66) serves multiple purposes. Index 1 accumulates the total score. Indices 11–60 represent the 5-column × 10-row bridge grid. Indices beyond 60 represent the far bank. A cell value ≤ 0 indicates an already-vacated or occupied cell; -28 is used as a sentinel for the player’s current position (chosen so that CHR$(28 + A(N)) would produce CHR$(0), effectively a null/invisible character).

Cell-to-Screen Coordinate Mapping (line 500)

The subroutine at line 500 is the most technically interesting part of the program. Given a cell index stored in M, it decomposes the index into row and column using integer and fractional parts:

• LET M=(N-1)/5 — divides index into a mixed number where INT M is the row (0-based) and M-INT M is a fractional column selector (0, 0.2, 0.4, 0.6, 0.8 for columns 0–4).
• PRINT AT 5+INT M, 13+5*(M-INT M); A$ — maps row to screen row 5–14 and column fraction × 5 to screen columns 13, 14, 15, 16, 17.

This single-subroutine approach avoids separate row/column variables and is a compact ZX81 idiom for two-dimensional array display.

Movement Direction Encoding (lines 200–230)

The direction input DIR is a digit 1–9 mimicking a numeric keypad layout. The decoding is:

• LET I=(INT DIR-1)/3 — produces a mixed number where INT I encodes the row delta (0=up, 1=same, 2=down) and I-INT I encodes the column delta.
• LET J=M-INT M+I-INT I — the fractional parts are summed; the bounds check J<0.1 OR J>1.4 catches moves off the left or right edges.
• LET N1=N+5*(INT I-1)+3*(I-INT I)-1 — computes the target cell index from the direction deltas.

Direction 5 (centre key, no movement) is implicitly rejected by the N1<6 guard or the A(N1)<=0 check since it would land back on the player’s own cell.

Scoring System (lines 390–410)

Score for a valid move is calculated at line 390:

• 10*(3-INT I) rewards upward moves (INT I=0 gives 30, same row gives 20, downward gives 10).
• 10*(2-INT I)*(1-INT I) adds a bonus of 20 only for upward moves (both factors non-zero only when INT I=0).
• If the destination cell’s value matches the randomly chosen drop-target cell (A(N1)=A(DROP)), the score is tripled (line 400).

Drop Target Mechanic

Each turn, DROP is a randomly selected occupied cell (lines 160–170). Its numeric value is displayed (line 180) as a hint. If the player moves onto the DROP cell, they fall into the water (line 370 → 600). This creates a risk/reward dynamic: the matching-value bonus encourages targeting cells that may be the trap.

Display Techniques

Inverse video characters (e.g. %A%N%O%T%H%E%R%) are used for the replay prompt, a common ZX81 technique for highlighted text without any attribute system. Block graphic characters (\##) form the bridge towers in the static art drawn at lines 35–80. The FAST/SLOW pair (lines 5/145) speeds up the initial board render.

Delay Subroutine

The subroutine at line 7000 is a simple FOR Z=1 TO 30: NEXT Z busy-wait loop used for pacing at the end-game message screens. The WR=1700 variable displayed on screen (line 50) appears to be a high-score or world record placeholder; it is printed but never updated by game logic.

Anomalies and Notes

• Line 140 sets N=8 as the starting cell, but cells 1–10 are never populated in the board-fill loop (lines 90–135 fill indices 11–60), so the player starts in an unpopulated region — this is intentional as the entry row of the bridge.
• Lines 7500–7530 form a save/restart block that is never reached during normal play.
• The RAND 0 at line 10 seeds the random number generator with the system clock value, ensuring a different board each game.
• The replay logic at lines 650–680 and 811–819 is duplicated almost identically, which could have been refactored into a subroutine.
• Variable WR is set to 1700 and displayed but never compared against A(1), so no actual high-score tracking occurs.