How Did the Sinclair ZX80 Store Program Lines in Memory?

The Sinclair ZX80, released in 1980, was renowned for its incredibly limited memory, yet it managed to function as a usable computer through clever engineering. This article explores the specific memory architecture used by the ZX80 to store BASIC program lines, detailing how tokenization and structured line storage allowed the machine to operate within just 1KB of RAM. Readers will gain insight into the byte-level organization that defined early home computing efficiency.

The Constraint of 1KB RAM

To understand the storage mechanism, one must first appreciate the hardware limitations. The base model of the Sinclair ZX80 came with only 1KB of random-access memory. This single kilobyte had to hold the display file, the system variables, the BASIC interpreter stack, and the user’s program itself. With such a tiny capacity, storing text-based BASIC commands in standard ASCII format would have exhausted available space almost immediately. Consequently, Sinclair engineers devised a compressed storage method to maximize every available byte.

Tokenization of Keywords

The primary method used to conserve space was tokenization. When a user typed a BASIC keyword such as PRINT, GOTO, or FOR, the computer did not store the individual letters P-R-I-N-T. Instead, the ROM-based BASIC interpreter immediately converted these keywords into single-byte tokens. For example, the command PRINT might be stored as a single hex value like 0xD1. This reduced a five-character command down to one byte, saving 80% of the space required for that specific word. Only variable names and string literals remained in their standard ASCII format, ensuring that the core logic of the program occupied minimal memory.

Structure of a Program Line

Each line of a BASIC program was stored in a specific structured format within the memory map. A program line was not merely a string of text but a binary record consisting of several distinct parts. First, the line number was stored as a two-byte integer, allowing for line numbers up to 65535. Following the line number was a two-byte length field, which indicated the total size of that specific line including the line number and the end-of-line marker.

After the length bytes, the actual tokenized code was stored sequentially. This section contained the mix of single-byte command tokens and ASCII characters for variables. Finally, each line was terminated by a specific carriage return byte, typically 0x0D. This structure allowed the interpreter to scan through memory quickly, jumping from one line to the next by reading the length field without needing to parse the entire content of the line to find where it ended.

Memory Map Organization

The ZX80 memory was divided into distinct areas. The lower memory addresses were reserved for the system variables and the display file, which was generated dynamically by the CPU since there was no dedicated video RAM. The user’s program lines were stored immediately after the system variables. As the program grew, it expanded upward in memory. Variables created during runtime, such as counters or string data, were stored in a separate area above the program lines. This separation meant that editing a program line often required the system to delete the old line and reinsert the new one, shifting the memory contents to accommodate the change in size.

Efficiency and Legacy

This method of storing program lines was critical to the ZX80’s success as the first computer sold in the UK for under £100. By compressing commands and structuring lines efficiently, Sinclair allowed users to write meaningful programs within a space smaller than a typical text document today. This architecture influenced subsequent models like the ZX81 and the ZX Spectrum, cementing tokenization as a standard technique in early home computing memory management. The ZX80’s approach remains a fascinating example of software engineering optimized for extreme hardware constraints.