Devon Demon

This program implements a diagonal draughts (checkers) variant called “Devon Demon,” a two-player abstract strategy game where the human plays “X” and the computer plays “O.” The board state is stored directly in memory starting at address 16513, using PEEK and POKE to read and write piece positions, with character codes 52, 61, 27, and 128 representing different board cell states. Lines 30–50 use a self-modifying bootstrap technique: they copy 36 bytes of board-state data from the REM statements at lines 10–20 (offset +42 from address 16514) into the working board area. The computer’s move logic uses a direction array B() with offsets ±5 and ±7 corresponding to diagonal moves on a 6-column board, and includes boundary detection and a simple capture-seeking heuristic.

---

Program Analysis

Program Structure

The program is divided into three broad phases:

1. Bootstrap (lines 10–55): Copies initial board data from the REM statements into the working board area in memory, then jumps to the title/instructions routine.
2. Instructions (lines 1000–1090): Displays the game title and rules, waits for NEWLINE, then jumps to game initialisation at line 60.
3. Game loop (lines 60–710): Initialises state, handles display, processes human and computer moves, and detects win conditions.

Bootstrap and REM-Based Data Storage

Lines 10 and 20 contain REM statements whose character data encodes the initial board layout. The loop at lines 30–50 copies 36 bytes from address 16514+42 = 16556 (inside the REM statement body) to addresses 16514 through 16549, which form the working board array starting at Z=16513 (so cells are at Z+1 through Z+36). This is a classic ZX81 technique for embedding binary or character data inside REM lines to avoid the overhead of DATA/READ statements.

Board Representation

The board is a 6×6 grid stored as 36 consecutive bytes in RAM from address Z+1 to Z+36. Character codes encode cell contents:

Code	Meaning
52	Computer piece (“O”)
61	Human piece (“X”)
27	Empty square
128	Temporary marker during computer move animation

The board is displayed by printing CHR$ PEEK (Z+C) for each cell, relying on the ZX81 character set to render the appropriate glyphs. Column labels A–F are derived by printing CHR$ (C/6+37) at every sixth cell (line 240), and row numbers “1 2 3 4 5 6” are printed at line 260.

Move Input Parsing

The human enters a four-character string such as “A1B2”. Line 340 decodes the source square: D = 6*(CODE A$(1)-38) + CODE(A$(2))-28. Since “A” has ZX81 code 38, CODE A$(1)-38 gives the column index 0–5, multiplied by 6 for the row offset. CODE(A$(2))-28 converts the digit character (“1″=29 in ZX81) to 1–6. Line 350 performs the same calculation for the destination square into E. If the destination holds a computer piece (code 52), the human’s score is incremented (line 360).

Direction Array and Diagonal Movement

Array B() holds four diagonal offsets for a 6-column board:

• B(1)=5 — diagonal down-left
• B(2)=7 — diagonal down-right
• B(3)=-5 — diagonal up-right
• B(4)=-7 — diagonal up-left

These offsets reflect the fact that adjacent diagonal cells differ by 5 or 7 positions in the linear board array on a 6-wide grid (not the expected ±5/±7 for a standard 8-wide board, since rows are 6 cells wide here).

Computer AI

The computer’s move selection (lines 490–590) works as follows:

1. Pick a random board cell F; retry if it does not contain a computer piece (code 52).
2. With 80% probability, select a random direction M from 1–4 (line 530).
3. Apply boundary guards (lines 540–550) to prevent wrapping off the left or right edges of the board.
4. At line 560, check if the cell at F+B(M) is an empty square (27) and the cell beyond it (F+2*B(M)) is not a human piece (61) — if this multi-hop condition is met, jump directly to the capture/move execution at line 620.
5. If the direction is invalid, increment M and try the next; after exhausting all four directions, retry with a new random piece (up to 200 attempts via line 590).

Lines 450–460 also check whether any computer piece can immediately capture a human piece (land on a cell containing 61), providing a simple opportunistic capture before the random-move fallback.

Win Detection

The human wins when S=4 (four computer pieces captured, line 410). The computer wins when N=4 (four human pieces captured, line 650). Both conditions print a result message and STOP.

Notable Techniques and Anomalies

• SLOW/FAST switching: The program toggles between SLOW (display-on) and FAST (display-off) modes around display and computation phases to balance responsiveness and speed.
• Score variable redundancy: LET S=0 appears twice (lines 80 and 90), which is harmless but redundant.
• Loop variable reuse: Variable M is used both as a direction index within the AI loop and as a loop counter in FOR/NEXT at line 440, which could cause confusion but works because the FOR loop at 440 is always completed before M is reassigned at line 490.
• Boundary detection coverage: The edge guards at lines 540–550 only cover specific column positions (F=6,16,30 and F=7,19,31), which correspond to the rightmost and leftmost cells of rows on a 6-wide board. This approach is functional but fragile—it would fail for board sizes other than 6.
• INKEY$ wait idiom: Lines 1060–1070 first flush any held keypress, then wait for NEWLINE (CHR$ 118), a standard ZX81 debounce pattern.
• Counter K: K is incremented at line 510 during the AI’s random-piece search and checked at line 590 (IF M<200), but M rather than K is the variable tested — this means the 200-iteration guard on line 590 actually checks the direction index, not the attempt count, making it effectively always true for a legal board state. The intended exhaustion guard on K is never used.