Renumber 1

This program is a BASIC line renumbering utility that operates on the program area in RAM. It loads 120 bytes of Z80 machine code into memory just below the VARS area (using PEEK 23627/23628 to locate it), then uses that code — invoked via USR calls — to scan the program’s line table, relocate line numbers, and patch internal GO TO/GO SUB targets. The user is prompted for the old starting line number, a new starting line number, a step value, and an ending line number; these parameters are POKEd as 16-bit little-endian values into fixed offsets relative to VARS. Line 9999 contains a dense REM statement whose bytes encode additional Z80 machine code or data used by the renumbering engine. The SAVE at line 9989 preserves the program with auto-run from line 1.

---

Program Analysis

Program Structure

The program is organized into three phases:

1. Machine code installation (lines 1–18): 120 bytes are READ from DATA statements and POKEd into RAM immediately below the VARS area.
2. Parameter collection (lines 9991–9996): The user is prompted for the old starting line, new starting line, step increment, and stopping line number.
3. Execution (line 9997): The renumber routine is triggered via USR (VARS-87); on completion line 9998 prints a confirmation message.

Lines 9988–9990 form a save/stop guard: GO TO 9991 skips the SAVE on normal runs, while deliberately running from line 9988 would trigger the SAVE command.

Machine Code Installation

Lines 2–5 compute the load address as PEEK 23627 + 256*PEEK 23628 - 121, which is 121 bytes below the start of the VARS area. This makes the code position-independent with respect to program size — wherever VARS sits in RAM, the machine code lands just beneath it. The 120 bytes are loaded by a simple FOR/READ/POKE loop. The letter b appearing in the DATA lines (e.g., lines 7, 11, 12, 13, 14, 15) is unusual: as a BASIC variable it would evaluate to whatever b currently holds (likely 0), making those bytes effectively zero — these are likely placeholder addresses or zero-valued operands in the Z80 code that are patched at runtime via the POKE statements in lines 9992–9996.

Parameter Passing via Memory Offsets

All parameters are communicated to the machine code through fixed negative offsets from VARS, stored as 16-bit little-endian values. The offsets used are summarized below:

VARS Offset	Parameter	Line POKEd
VARS-120 / VARS-119	Old starting line number	9992
VARS-86 / VARS-85	Address returned by first USR call	9993
VARS-83 / VARS-82	New starting line number	9994
VARS-48 / VARS-47	Step value	9995
VARS-80 / VARS-79	Old stopping line number	9996

Line 9992 also calls USR (VARS-121) to locate the first matching line in the program, storing the resulting address for subsequent renumbering operations. Line 9997 calls USR (VARS-87) to actually perform the renumbering pass.

The REM at Line 9999

Line 9999 contains a long REM statement filled with BASIC keyword tokens and symbol characters. On the Spectrum, REM contents are stored verbatim as bytes in the program area; this REM likely encodes additional Z80 machine code or lookup tables used by the renumbering engine, accessed by the machine code routines at known offsets from the line’s position in memory. This is a standard technique for embedding data or code in a REM without it being executed as BASIC.

Notable Techniques

• VARS-relative addressing: By anchoring all code and data to VARS, the utility works regardless of where the program sits in RAM or how long it is.
• 16-bit little-endian POKE idiom: Q - 256*INT(Q/256) extracts the low byte; INT(Q/256) extracts the high byte — the standard Spectrum BASIC technique for storing integers wider than one byte.
• DATA bytes with variable b: Using the uninitialized variable b (value 0) as a zero placeholder in DATA statements is an unusual approach; it relies on b not being set before the READ loop executes.
• Two-stage USR invocation: The first USR call (line 9993) performs a search/locate pass; the second (line 9997) performs the actual renumbering, allowing the address of the target line to be verified before modification.
• PRINT with double newline '': Lines 9993–9995 use the '' idiom (two consecutive newline characters in PRINT) to add blank lines between prompts for readability.

Bugs and Anomalies

• The use of b in DATA statements (lines 7, 11–15) is potentially fragile. If b were ever assigned a non-zero value before line 3 executes, the machine code bytes would be corrupted. In practice this works because b is never assigned, but it is not robust.
• Line 9996 ends with STOP rather than transitioning to 9997 automatically, meaning the user must manually continue (e.g., with CONTINUE) to trigger the renumber. This appears intentional, giving the user a chance to abort.
• Line 9997 uses IF USR (VARS-87) THEN with no consequent statement, which is legal BASIC (the line simply does nothing visible on a true result) but unusual — the renumber routine’s return value is effectively ignored, and the fall-through to 9998 always occurs.