Sprite

This program loads a Z80 machine code sprite engine into RAM starting at address 64776, just below the CLEAR boundary set at 64767. The routine is poked into a 256-byte buffer region at 65024–65280 (initialized to 253), and a jump vector is installed at 65021–65023 to redirect execution into the sprite handler. A checksum verification step sums all 217 data bytes and compares the result against 30092, halting with an error message if the DATA has been corrupted. The sprite can be enabled by calling RAND USR 64776 and disabled by POKEing address 64898 with the value 1.

---

Program Analysis

Program Structure

The program is organized into three logical phases:

1. Memory initialization (lines 35–50): Sets the CLEAR boundary, fills a 256-byte workspace at 65024–65280 with the value 253, and installs a three-byte Z80 jump instruction (JP nn, opcode 195) at address 65021 pointing to 65027 (low byte 27, high byte 253).
2. Machine code loading and verification (lines 60–150): Reads 217 bytes from DATA statements, POKEs them into addresses 64776–64992, accumulates a checksum, and halts with an error if the sum does not equal 30092.
3. Data block (lines 1000–1210): Contains the raw Z80 opcodes for the sprite engine.

Memory Map

Address Range	Purpose
64776–64992	Z80 sprite engine machine code (217 bytes)
64898	Sprite enable/disable flag (POKE 1 to disable)
65021–65023	JP instruction redirecting to sprite handler
65024–65280	Sprite workspace buffer, pre-filled with 253 (0xFD)

Machine Code Entry and Control

The sprite routine is invoked via RAND USR 64776, which executes the machine code at address 64776 as a Z80 subroutine. The pre-fill value 253 (0xFD) for the workspace buffer is significant: in Z80 instruction encoding, 0xFD is the IY register prefix, suggesting the workspace may be structured to hold IY-indexed data or act as a self-modifying code region. The jump at 65021 with opcode 195 (0xC3) is a standard Z80 JP nn, routing control from a fixed hook point into the sprite handler.

Examining the DATA reveals several recognizable Z80 sequences: 243 (DI), 251 (EI), 201 (RET), and 237,86 (IM 1) / 237,94 (IM 2), indicating the routine manipulates interrupt mode — consistent with a software sprite that hooks the interrupt service routine to redraw itself every frame.

Interrupt-Driven Sprite Technique

The sequence 243,237,94,62,254,237,71 at the start of the code block decodes as DI / IM 2 / LD A,254 / LD I,A, which sets up interrupt mode 2 with the high byte of the interrupt vector table pointing to page 0xFE (65024 in decimal). Combined with the 253-filled buffer at 65024–65280, this creates an IM 2 vector table where every entry points to address 0xFDFD — within the pre-filled workspace — a classic technique for installing a stable IM 2 interrupt handler. The JP at 65021 then redirects that interrupt to the actual sprite routine.

Checksum Verification

Lines 60–150 implement a simple additive checksum over all 217 DATA bytes, comparing the result to the hardcoded value 30092. This is a practical integrity check to detect DATA entry errors, which were a common problem when typing in programs from printed listings. No polynomial or CRC is used — just a straight integer sum — but it is sufficient to catch most single-byte transcription errors.

Key BASIC Idioms

• CLEAR 64767 raises the RAMTOP, protecting the machine code area from BASIC’s memory manager and preventing the routine from being overwritten by the stack or string space.
• RESTORE 1000 explicitly resets the DATA pointer to line 1000 before the READ loop, making the loader re-runnable without restarting the program.
• The FOR loop at line 40 fills a 257-byte region (65024 to 65280 inclusive) — note this is 257 iterations, slightly more than one 256-byte page, which may be intentional to ensure the vector table page is fully populated.

Notable Anomalies

Line 40 iterates from 65024 to 65280 inclusive, which is 257 bytes rather than 256. Since the interrupt vector page at 0xFE spans 65024–65279, the extra byte at 65280 (0xFF00) is written but falls outside the vector table page and is harmless. The STOP at line 9998 acts as a program terminator after the loader completes, preventing fall-through into any subsequent code.