How the Sinclair ZX81 Stored Array Data in Memory

The Sinclair ZX81, renowned for its extreme hardware minimalism, managed data storage through a highly compact yet restrictive memory architecture. This article explores the specific mechanisms Sinclair BASIC employed to handle arrays within the computer’s notoriously limited RAM, detailing the five-byte floating-point structure, the variable memory map, and the overhead costs that dictated programming strategies during the early 1980s.

The Constraint of Limited RAM

When launched in 1981, the Sinclair ZX81 came with only 1KB of internal RAM, which was shared between the program code, system variables, the display file, and user data. For programmers, this meant that every byte counted. Unlike modern systems that allocate memory dynamically from a large heap, the ZX81 utilized a contiguous memory model where the program text grew from the bottom up and variables grew from the top down. Arrays, being collections of variables, had to fit into whatever remaining space existed between the program and the system’s upper memory limit, often leading to “Out of Memory” errors with surprisingly small datasets.

Five-Byte Floating-Point Structure

A critical factor in array storage was the data type used by Sinclair BASIC. The ZX81 did not support integer variables; all numerical data was stored as floating-point numbers. Each number occupied five bytes of memory: one byte for the exponent and four bytes for the mantissa. This design choice simplified the CPU’s arithmetic logic but incurred a heavy storage penalty. Consequently, a single-dimensional array with just ten elements consumed 50 bytes of RAM, not including the memory required to store the array’s name and dimension information. This lack of integer support forced developers to optimize algorithms carefully to avoid exhausting the available memory.

Variable Area and Array Layout

Arrays were stored within the variable area of the memory map, immediately following the end of the program lines. When an array was dimensioned using the DIM command, the BASIC interpreter reserved a contiguous block of memory. The storage structure began with a header containing the array’s name and the number of dimensions. Following this header, the actual data elements were stored sequentially in row-major order. For a multi-dimensional array, such as a 10x10 grid, the interpreter calculated the memory offset based on the indices provided, allowing for direct access to any element without needing to traverse the entire list, provided the memory address calculation did not exceed the available RAM top.

Implications for Developers

The rigid memory structure of the ZX81 required programmers to plan their data usage before writing code. Because the display file could consume nearly 1KB of memory in standard mode, many developers switched to fast mode or manipulated memory directly to reclaim space for arrays. Understanding that each element cost five bytes allowed experienced users to calculate the maximum possible size of an array before running the program. This tight integration of hardware constraints and software design defined the ZX81 programming experience, making memory management the most significant challenge in developing complex applications for the platform.