Ring Buffer

A ring buffer, or circular buffer, reuses a fixed block of memory by wrapping its position back to the start. The memory is not physically circular: the program treats the slot after the last one as the first. G. H. Gable explained this arrangement to BYTE readers in January 1977.¹

A queue with a limit

For a queue, one position marks where the next item will be written and another marks where the next item will be read. Each advances and wraps independently. Already stored items do not need to be shifted towards the start after every read.¹

Equal read and write positions create an ambiguity: is the buffer empty, or has writing caught up with reading? Gable describes leaving one slot unused to distinguish those cases. With that convention, an eight-slot array holds at most seven queued items.¹

A ring buffer cannot absorb unlimited input. When it fills, the program needs a policy: wait for room, reject new input, or overwrite older data where losing it is acceptable. Which choice is appropriate depends on what the buffer holds.

Remembering a sound

A ring can also hold a rolling history rather than a queue awaiting consumption. The AGEXM.SRC music engine in Dean Belfield’s archive of donated Follin source contains a concrete example.²

Its echo table, ECTA, reserves 49 bytes and initialises sixteen three-byte records. The write position advances and wraps through AND 15, retaining the low four bits and therefore a position from 0 to 15. The read position subtracts a delay and applies the same mask. This masking shortcut works for a sixteen-entry ring because sixteen is a power of two.³

Each record stores three values from the live sound state. Reading an older record supplies values for the delayed voice, with two values reduced before reuse. The ring remembers sound parameters; it is not a recording of digital audio samples.³

The write position itself sits inside an instruction’s operand and is updated there. This is self-modifying code: the engine changes a byte in its own instructions to retain the position.³

When the consumer stops

Commodore’s Amiga ROM Kernel Reference Manual: Exec gives a practical warning. Calling Wack from a program stops multitasking while interrupts continue. Some interrupt handlers keep putting data into buffers, but the device tasks which normally process it cannot run. Too much input can therefore overflow or wrap those buffers.⁴

Fixed storage and wraparound solve memory reuse. They do not remove the need to handle a reader that falls behind.

See also

• Audio programming
• Self-modifying code
• Tim Follin

Footnotes

1. G. H. Gable, “Using Interrupts to Speed Up an ELM”, BYTE, January 1977, pp. 108–109, figure 2 and the circular-buffer discussion. This is a period explanation, not a claim that the structure originated in 1977. ↩ ↩² ↩³

2. Dean Belfield, archive-follin README, describing source donated by Tim Follin and recovered from Tatung Einstein development disks. ↩

3. AGEXM.SRC, ECTA, ECF1, POINT and DELAY. The filename alone does not establish the exact shipped game version or the duration of one update. ↩ ↩² ↩³

4. Commodore-Amiga, Amiga ROM Kernel Reference Manual: Exec, chapter 8, “Getting to Wack”, p. 84. Published manual, available here as a transcription. ↩