Sprite Demo

This program demonstrates a sprite animation engine for the Spectrum by loading a pre-drawn screen and a machine code routine, then repeatedly invoking it via RANDOMIZE USR. Before entering the animation loop, it patches six pairs of addresses in the machine code block (at addresses around 41516–41556) using DATA statements, writing 16-bit little-endian values split into low and high bytes via the two DEF FN functions. The core sprite engine, called SPRITES, is noted as public domain and originates from the Zeus Source Files Disk. A 60-frame pause between iterations provides a timed display cycle.

---

Program Structure

The program is organized into a short linear sequence: a decorative REM banner, two DEF FN helper definitions, two LOAD statements to bring in binary assets, setup code, and then an infinite animation loop. The main loop occupies lines 70–100, with supporting data at line 110.

1. Lines 10: Multi-line REM banner (documentation only).
2. Lines 20–30: Define byte-splitting functions.
3. Lines 40–50: Load screen and machine code assets from tape/disk.
4. Line 60: Set border to black.
5. Lines 70–100: Patch machine code, pause, loop.
6. Line 110: DATA for address/value pairs used in patching.

Asset Loading

Line 40 loads a SCREEN$ file named spritedemP, filling the display file with a pre-drawn background. Line 50 loads a CODE block named spritedemQ at address 41000, placing the machine code sprite engine into RAM. The engine entry point is at 41568, invoked by RANDOMIZE USR 41568 on line 70.

DEF FN Byte-Splitting Idiom

Two DEF FN functions implement 16-bit little-endian decomposition:

• FN a(x) — returns the high byte: INT(x/256)
• FN b(x) — returns the low byte: x - INT(x/256)*256, equivalent to x MOD 256

This is a standard Spectrum BASIC technique for writing 16-bit addresses or values into memory one byte at a time, since BASIC has no native word-POKE facility.

Runtime Machine Code Patching

Line 80 is the most technically significant section. After a RESTORE, it reads six address/value pairs from the DATA at line 110 and writes each 16-bit value into the machine code block as a little-endian word:

POKE a,   FN b(b)   ' low byte at address a
POKE a+1, FN a(b)   ' high byte at address a+1

This patches six consecutive word-sized locations spaced 8 bytes apart (41516, 41524, 41532, 41540, 41548, 41556), likely updating sprite data pointers or animation frame addresses within the SPRITES engine before each invocation. The target values (42623, 42926, 41723, 42027, 42331, 43226) are addresses within the loaded CODE block, suggesting a table of sprite descriptors or frame buffers.

Animation Loop

The loop on lines 70–100 is minimal: call the machine code routine, pause for 60 frames (approximately one second at 50 Hz), and repeat. The RESTORE on line 80 resets the DATA pointer each iteration so the same six pairs are re-patched on every cycle, which implies the machine code may modify those locations during execution and they must be restored to their initial state.

DATA Table

Patch Address	16-bit Value	Low Byte	High Byte
41516	42623	127	166
41524	42926	110	167
41532	41723	187	162
41540	42027	235	163
41548	42331	27	165
41556	43226	154	168

Notable Observations

• The use of RANDOMIZE USR rather than PRINT USR or a direct call is the conventional Spectrum idiom for invoking machine code that does not need to return a value to BASIC.
• The 8-byte spacing between patched addresses suggests a structured record layout within the sprite engine, possibly a sprite descriptor table with fields such as x, y, and data pointer.
• No error trapping is present; if the LOAD operations fail the program will halt rather than recover gracefully.
• The SPRITES engine is explicitly noted as public domain in the REM, suggesting it was intended for community reuse independent of this demo wrapper.