Sketchpad

Sketchpad is an interactive pixel-drawing program that lets the user plot points on a black screen using the numeric keypad-style keys (5, 6, 7, 8 for movement) while a cursor tracks position. The program maintains cursor coordinates in variables x1 and y1, updating them incrementally each iteration of the main loop. Three modes are supported: normal draw, reposition (move without drawing, key 1), and delete (erase pixels, key 0 toggled). The PLOT OVER mechanic is central: PLOT OVER 0 sets a pixel, while PLOT OVER 1 XORs it, enabling both drawing and erasing. The instructions are embedded in a REM at line 9999, displayed via LIST 9999 before the program starts, so the user reads them before pressing any key to begin.

---

Program Structure

The program divides into three distinct phases. Lines 1–5 form an introduction sequence: a LIST 9999 displays the instructions stored in the REM at line 9999, then the program waits for any keypress via a tight INKEY$="" loop. Lines 10–25 initialize state variables. Lines 30–75 are the main drawing loop, which runs indefinitely via GO TO 30.

State Variables

Variable	Purpose
x1, y1	Current cursor position (pixel coordinates)
x, y	Delta movement applied each loop iteration
move	0 = draw mode, 1 = reposition (no draw)
retain	1 = reposition mode active (suppresses overwrite of existing pixels)

Key Handling and Movement

Lines 50 and 55 compute movement deltas using Boolean arithmetic — a classic Sinclair BASIC idiom. For example, ((INKEY$="8")*(x1<255)) evaluates to 1 only when key 8 is held and the cursor is within bounds, giving a clean one-liner that avoids multiple IF statements. The four movement keys are 5 (left), 8 (right), 6 (down), 7 (up), matching the arrow-key layout of the keyboard.

Draw and Erase Modes

Line 65 uses PLOT OVER 0 to unconditionally set a pixel at the cursor position. Line 70 then conditionally executes PLOT OVER 1 when move=1 (reposition mode), which XORs the pixel back off, effectively making the cursor invisible and leaving no trail. Delete mode is toggled by key 0 at line 35, which uses NOT move to flip the move flag; when active, the branch at line 60 checks POINT (x1,y1)=1 and skips the PLOT entirely if the pixel is already set, while the XOR in line 70 erases it otherwise.

Notable Techniques

• LIST 9999 at line 2 repurposes the BASIC listing mechanism as a help-text display, showing the instruction REM before the program runs.
• The coordinate update at line 30 (LET x1=x+x1) accumulates deltas, so holding a key causes continuous movement each loop pass.
• Line 45 (IF INKEY$="0" THEN GO TO 45) is a key-release wait after toggling mode with key 0, preventing rapid re-toggling.
• Boundary checks are embedded directly in the Boolean movement expressions at lines 50–55 (x1<255, y1<175, x1>0, y1>0), clamping movement without separate IF guards.
• The non-printing character \{16}\{0} in line 35 is an INK color control sequence embedded in the REM token area, but within a LET statement context it appears to be a stray artifact that does not affect execution since NOT move provides the correct Boolean result.

Potential Anomalies

The embedded control bytes \{16}\{0} in line 35 appear between THEN LET move= and NOT move. These are ink-color escape bytes (INK 0 control sequence) stored inline in the line, which the BASIC tokenizer will attempt to interpret. In practice, the assignment evaluates NOT move correctly, but the stray bytes are irregular and could cause unexpected behavior on some ROM versions. Additionally, because x and y are only reset at lines 20–25 (initialization) and not inside the main loop before lines 50–55, they persist from the previous iteration; however, since lines 50 and 55 always reassign them unconditionally, this is not a practical bug.