EASYsprite Maker

Sprite Maker is a TS2068 BASIC loader and file-management shell for a sprite-editing program, with the bulk of the editor implemented as machine code loaded at address 54906. The BASIC portion handles saving and loading sprite data files by peeking a start address stored at memory locations 64685–64686, then performing CODE saves and loads relative to that dynamic address. Line 120 checks PEEK 23681 to detect whether the machine code is already present before attempting to jump into it via RANDOMIZE USR. The machine code block of 10,630 bytes is saved and loaded separately under the filename “MAKER Mc,” while the BASIC shell auto-runs from line 9990 on load.

A maximum of 255 sprites can be in memory for a TOTAL of up to 10,000 bytes.

---

Program Analysis

Program Structure

The program is divided into several logical blocks:

• Lines 100–150: Initialization — checks for machine code presence and jumps into it via RANDOMIZE USR 54906.
• Lines 1000–1030: Save sprite file routine — calls the filename input subroutine, saves sprite data as CODE, then returns to machine code at address 61994.
• Lines 2000–2040: Load/merge file routine — calls the filename input subroutine, loads CODE data, then jumps to machine code at address 63217.
• Lines 3000–3040: Input file name subroutine — retrieves the dynamic start address and prompts the user for a filename.
• Lines 9000–9999: Bootstrap/save block — clears memory, displays a loading screen, loads the machine code block, and saves both the BASIC and machine code components to tape.

Machine Code Integration

The real sprite editor lives in a 10,630-byte machine code block loaded at address 54906. The BASIC shell calls into this code at three distinct entry points:

Address	Purpose
54906	Main editor entry point
61994	Return point after saving a sprite file
63217	Return point after loading/merging a sprite file

The pattern of PRINT ; before each RANDOMIZE USR call is a common idiom to suppress error messages or ensure clean I/O state before transferring control to machine code.

Dynamic Start Address Detection

In the file name subroutine (line 3020), the sprite data start address is computed at runtime by reading two bytes from fixed memory locations: LET start=PEEK 64685+256*PEEK 64686. This allows the machine code to communicate the current sprite buffer address back to BASIC, making the save and load operations flexible rather than hardcoded to a fixed address. The SAVE at line 1020 uses the hex literal 4E4 (decimal 1252) as both the save base and length calculation anchor: SAVE n$ CODE 4E4, START-4E4, implying the sprite data begins at address 1252 and extends to start.

Presence Check and Guard

Line 120 uses PEEK 23681 to test whether the machine code has been loaded into memory. Address 23681 is a system variable area; if its value is zero the program assumes the machine code is absent, clears the screen, and executes LIST 9999: STOP to display the save/bootstrap lines to the user instead of crashing into unpopulated memory.

Bootstrap and Tape Layout

Line 9990 serves as the auto-run entry point. It sets up the display, prints a loading message, and loads the machine code block by name before calling RUN, which re-enters from line 100. Line 9999 saves both components to tape: the BASIC program with LINE 9990 so it auto-runs, followed immediately by the machine code block “MAKER Mc” of exactly 10,630 bytes starting at 54906, and then verifies both.

Key BASIC Idioms

• INPUT ... LINE n$ is used rather than plain INPUT to capture the filename as a raw string, avoiding the need for quotes.
• The filename length is validated with IF LEN n$>10 THEN GO TO 3000 to prevent overly long tape names.
• CLEAR 65535 on line 9000 followed by NEW is a teardown sequence that resets the system before the save operation.

Potential Anomalies

Line 1010 loops back to GO TO 1010 (which re-calls GO SUB 3000) if the filename is empty, but since line 1010 itself is the caller this results in repeated subroutine calls without returns, which will eventually overflow the GOSUB stack. A cleaner approach would loop within the subroutine or use a different guard structure. Additionally, the LOAD n$ CODE start, 49999-start on line 2030 caps the load length at 49999-start, which may truncate data if the sprite buffer extends beyond that boundary depending on the value stored at 64685/64686.