What Those ZX Spectrum Loading Noises Actually Meant

0:12You're hearing Manic Miner arrive.

0:19Each short wave is a zero. Each long wave is a one. Fill a tape with zeros and it sounds like this. Make every bit a one, and it's an octave lower. The same amount of data takes twice as long.

0:40Silence wasn't zero. Zero was a busy signal, and it was the quicker one. Those noises were numbers, on their way to becoming a game.

0:57The Manic Miner sound we've just heard comes from Bug-Byte's nineteen eighty-three release, loaded on a 48K Spectrum. It uses the loading program built into the machine, the ROM loader. Its rules tell us what that familiar noise means. And I want you to watch the border as closely as you listen to the sound. The tape reaches the loader as a signal it reads as either high or low, and each change it finds between the two makes it switch the border colour. Red and cyan during the steady tone. Blue and yellow during the data.

1:44A change from high to low, or low to high, is an edge. The interval between two edges is a pulse, and on the border that interval appears as one stripe. One high pulse and one low pulse make a complete cycle. During the data, one cycle carries one bit, either zero or one. So a high signal doesn't mean one, and a low signal doesn't mean zero. Both kinds of bit go high and low. What distinguishes them is the time they take. A one lasts twice as long as a zero.

2:35That long opening whine is the pilot tone. It's a steady stream of equal pulses, repeating at about eight hundred complete cycles a second. It gives the loader a recognisable signal before the numbers begin. The ROM first waits almost a second. Then it wants two hundred and fifty-six consecutive pilot cycles before it'll look for the start of the data. That counting takes about another third of a second. The built-in saving routine writes more pilot than that: about five seconds before a header, the short block carrying the file's name and length, and two seconds before the block containing its contents. Those are the long, steady stretches you remember.

3:25Two unusually short pulses end the pilot. They're the synchronisation pulses, the signal that the steady tone is over and the bits are about to start. Together they mark the boundary. They aren't one of the data bits. A normal file comes in two blocks. First comes its header. Then a block containing the actual contents. Each has its own pilot and sync. That's why the familiar whine can come back several times during one game. Eight bits make a byte. Each block begins with a flag byte saying which kind of block it is: zero for a header, two hundred and fifty-five for data. Each ends with a check byte, which the loader later uses to test whether the block arrived intact. And while the Spectrum searches the headers, it prints the names it finds.

4:29The two test tones contained the same number of bytes: every byte in the first was eight zeros, and every byte in the second was eight ones. Each position is worth twice the position to its right, so those eight ones add up to two hundred and fifty-five. On screen, that's written as F F. Hexadecimal is a compact way of writing the same byte. Once the data mixes short and long cycles, it no longer makes either pure tone. The shape of the sound changes. If a pattern keeps repeating, the whole pattern can become a lower buzz.

5:11That byte alternates zero and one. Its pattern repeats every two bits, so the buzz repeats about six hundred and eighty-two times a second. The next example, hexadecimal C zero, has a much longer repeating pattern and a much lower buzz. You aren't just hearing two fixed notes being selected.

5:35A byte's loading time depends on how many of its bits are ones. Rearrange those same bits and its repeating pattern can change without changing that time. So two bytes can take equally long to arrive and still sound different when they're repeated.

6:06Now let's open up the Manic Miner tape we've been hearing. It has three files, each with a header and its contents. The first is a tiny program written in the Spectrum's built-in BASIC language. It makes the screen black and loads the next two files. Its final USR command tells the processor where to start the game.

6:31The next file isn't a drawing of Miner Willy, the character you control. It's just two hundred and fifty-six bytes of colour information for the middle third of the screen. There's no picture underneath. Each colour cell covers a small patch of the screen and gives it two colours: ink for drawn pixels, and paper for the background. With no picture underneath, the cell shows only its paper colour. Nearly every one of these colour cells is set to flash. Flashing swaps the ink and paper colours. The paper colours spell MANIC. The ink colours spell MINER. So the same little block of data gives you two alternating words.

7:22A lot of those bytes are the same C zero pattern we just heard. They set both colours to black, with flashing and brightness enabled. They still have a sound on tape, even though both flashing phases look black.

7:41The whole little block takes just over three seconds of signal, pilot included. The game isn't running an animation while you wait. The screen's flashing colours are doing the work while the ROM carries on loading. I like the economy of that. The main block's pilot begins about twenty-eight seconds into the tape. Its bytes begin just after thirty seconds. It's thirty-two K of bytes, written one after another into memory. There's much more in that screech than the program's instructions.

8:18First come working areas and tables of values, then the instructions that start the game. After those come its two tunes. At about thirty-seven and a half seconds, the tape delivers the first byte of the tune you'll hear in the Central Cavern. Keep that byte in mind. We'll follow all sixteen of its pulses into memory. Then the game's main instructions arrive. Nearly half their bits are ones. Listen to that greater share of long cycles as the memory cursor moves through the instructions. Even within a single block, the flow into memory isn't a fixed-speed conveyor belt.

9:03At fifty-seven seconds, something rather different begins: remnants of source code written by Manic Miner's author, Matthew Smith. These are pieces of the written program, not the machine instructions the processor runs. The tape saves the whole thirty-two K block in one piece, so it also carries this leftover text in a region marked unused in the game's memory map. Its first surviving lines are source text for the sound loop that will later play our tune byte.

9:38They include the source text for the cheat-code check. Your speaker was playing that too.

9:57A scrolling message used by the game follows. Then come the title screen's colours. Listen for a brief low buzz made by one byte repeated again and again.

10:13Next comes the title picture. Last come the twenty caverns. The twenty caverns alone take about ninety-eight seconds, an average of about four point nine seconds per cavern. So a large part of your wait was the places Willy would eventually explore. Let's hear two of those places at their original speed. Listen to the texture change when we cut from the Central Cavern's bytes to the different pattern of the Final Barrier, at the other end of the block.

10:54I can hear those as two different places now. For comparison, imagine the whole thirty-two K main block filled with random values. On average, that whole block would contain an even mix of zeros and ones and take about a hundred and ninety-two seconds. Nearly a third of Manic Miner's bytes are zeros, not empty memory, and the loader stores them like any others. Only about a quarter of all its bits are ones. Its faster zero cycles bring the data in at about a hundred and sixty-two seconds. Manic Miner's own data loads about thirty seconds faster than that comparison. So the Spectrum's tape doesn't have one fixed data rate. The contents help decide how long you wait.

11:45Now follow the tune byte we marked on the tape, through the Spectrum's input and the ROM loader, into memory. At this point, the Spectrum doesn't recognise it as a tune. At its EAR socket, the cassette signal gives the processor a high or low state to read. That state is one bit in an input port, a place the processor can read to find out what's happening outside it. The loading program keeps reading that input and watching for it to change. It measures the wait by counting trips around a little loop of instructions. The longer the wait, the longer the pulse.

12:28The timings are counted in processor clock ticks, called T-states. After finding an edge, the ROM waits three hundred and fifty-eight ticks without checking the input. Then it runs a loop that takes fifty-nine ticks per pass while the picture isn't being drawn. While the picture is being drawn, the ULA, the chip that draws it, can hold up the input read, so some passes take longer. Each pass increases the counter until the state changes. For each data bit, the ROM times both pulses. The counter starts from a preset value rather than zero. If the result is above two hundred and three, the ROM calls the bit a one. At that value or below, it's a zero.

13:21Across this Manic Miner block, zeros finish with counts from a hundred and eighty-eight to a hundred and ninety. Ones finish between two hundred and sixteen and two hundred and nineteen. That leaves a clear gap between the two kinds of bit. It doesn't need every pulse to land on one exact clock tick. I didn't expect the two groups to separate quite so cleanly.

13:51Eight decoded bits are collected in one of the processor's small working stores. When the eighth bit arrives, the finished byte is written into memory at the current destination. That destination moves on by one for the next byte. That's the connection between a measured cycle and a new value in the game's memory.

14:17The tune byte's destination is memory address thirty-four thousand, one hundred and eighty-eight. It's the first entry in Manic Miner's in-game tune, In the Hall of the Mountain King. On tape it occupies eight cycles, which means sixteen pulses. On the tape, it takes less than five thousandths of a second. We've slowed it down so you can follow it. This isn't its original pitch.

14:54The first cycle gives the ROM a count of two hundred and seventeen. That's over the line, so it's a one. The seven remaining cycles give counts between a hundred and eighty-eight and a hundred and ninety. Seven zeros. The working store begins with a single one at its right-hand end. That's a starter bit, not part of the incoming byte. As the real bits enter, the starter bit moves left. Watch it reach the end.

15:33When the eighth bit comes in, the starter bit falls out. Each place in a byte is worth twice the place to its right. Here, only the leftmost place is one, so the value is a hundred and twenty-eight. On screen, that's written as eighty in hexadecimal. That value is now in memory. The byte's in place, but the rest of the game still has to arrive. Once the whole block passes its check, the little BASIC program starts the game's code. The loader decoded this byte by counting turns of a loop. The game now uses the same idea to play it: the speaker changes state every hundred and twenty-eight turns of its sound loop, and that delay sets the note's pitch. The loading sound hasn't been kept as a recording. Its number is controlling the timing of a new sound.

16:39After watching the number arrive, I can't hear that first note in quite the same way.

16:45Change one of that byte's zeros into a one by lengthening both pulses of its cycle. That bit position is worth thirty-two, so the byte rises from a hundred and twenty-eight to a hundred and sixty. The ROM writes the wrong value into memory and carries on.

17:10The ROM says nothing until the end, more than two and a half minutes after the wrong byte arrived. By then, the rest of the block has already been written. The ROM has been checking as it goes, but it can't give this verdict until the last byte.

17:34The check byte is often called a checksum, but it isn't an ordinary sum. It uses exclusive OR. Starting at zero, each incoming byte flips the running check wherever that byte has a one. The tape's final check byte is chosen to bring the result back to zero. Change one bit anywhere in the block and one position in that final result is wrong.

18:07Letters are stored as bytes too. The capital C at the start of Central Cavern and the small c differ in this same bit position. Change it, and the two errors flip the same position in the check twice, so they cancel. This time there's no error report. The game starts with the wrong first note and a slightly less imposing cavern name.

18:42Two wrongs have made a load the ROM is happy with. Its check catches one wrong bit, but two wrong bits in the same position can cancel anywhere in the block. We've deliberately matched these two errors. That shows a limit of the check, not how often real tapes went wrong. Remember the wait after an edge, when the ROM isn't looking? A spike just fifty-five clock ticks long, placed inside that wait, goes completely unseen. The game loads correctly.

19:22Lose one edge instead, joining two short pulses into one, and the decoder pairs the later edges wrongly. In this thirty-two K block, nineteen thousand, two hundred and ninety-eight bytes are wrong. The ROM reports a loading error.

19:39That makes me wince. One lost edge can upset the rest of the block. A tiny spike can do nothing at all. What matters is what the decoder actually notices.

20:11That click isn't interference. It's part of the signal. Pairs of short pulses keep interrupting the pilot. Each group contains two hundred and fifty pilot pulses, which is only a hundred and twenty-five complete cycles. The ROM wants two hundred and fifty-six consecutive cycles. A short pulse sends it back to the start. So every click resets its progress before it can get far enough. The ordinary loader never reaches the sync.

20:47David Aubrey-Jones told the computer games magazine CRASH that he'd grown frustrated with how long the standard loader took. He combined his ideas with fellow designer David Looker's system to make Speedlock, an anti-piracy technique that could also load faster. Its first commercial use was Ocean's nineteen eighty-four Daley Thompson's Decathlon. We're using the original large-box Day One tape, the first of two tape loads that divide the game's ten events across two days. Its preserved tape identifies the loader as Speedlock One. Two BASIC programs come in at the ROM's normal speed. Then it starts clicking. Speedlock is listening for a different pattern. It looks for those two short pulses, then a run of two hundred and fifty pilot pulses, followed by its own pair of long sync pulses. The very interruption that defeats the ROM helps the custom loader recognise what it's waiting for. The second program never calls machine code with USR. Yet about a tenth of a second after its block ends, the processor is running a routine hidden inside it.

22:04A short routine unscrambles a hidden loader near the top of memory. Then control passes into what it has made.

22:18Once it's unscrambled, the hidden loader looks familiar: it's a rewrite of the ROM's edge-counting loader. It leaves out the ROM's test for the BREAK key, which makes its sampling loop shorter. And it uses its own pulse timings and decision values. Its data pulses are about two thirds as long as the ROM's. A zero cycle is still a pair of short pulses, and a one cycle a pair of longer ones. With every transition closer together, the same idea sounds tighter and higher, and it carries the data faster. I expected the click itself to be the speed trick. After its sync, Speedlock reads a seven-bit opening code. It must have the value a hundred and sixteen. Anything else, and the computer restarts at once. With that opening code accepted, Speedlock loads a small first block, then the big main block.

23:22Shorter pulses should mean less waiting. But a straight race between Manic Miner and Decathlon wouldn't be fair, because they don't contain the same amount of data. The fair race uses Decathlon's big main block twice. Under Speedlock, its data takes about a hundred and sixty-eight seconds. Encode exactly the same bytes at the ROM's timings and they'd take about two hundred and fifty-four seconds. That's about eighty-six seconds saved on the same contents. Because its pulses are about two thirds as long, this Speedlock loader delivers the bits about one and a half times as fast as the ROM.

24:13The same-bytes race separates the loader from the contents. Whole tapes are a different comparison. Manic Miner takes about three minutes and twelve seconds. Decathlon's Day One takes about three minutes and thirty, but carries nearly half as many bytes again. Then Day Two needs another three and a half minutes. Faster bits didn't necessarily mean a shorter evening beside the cassette player.

24:47In nineteen eighty-seven, a new Speedlock version added a loading countdown, which the Decathlon tape we've heard didn't have. Aubrey-Jones told CRASH: “Well, how else would you know if you’ve got time to brew a cuppa?”

25:01The small first block contains just twenty bytes of contents. Then comes an apparently uneventful gap. While the loader counts, the border is black. With no edges arriving, there are no stripes.

25:25The processor is still working. For about one point three four seconds, the loader counts edges in two hundred and fifty-five short windows. On the original signal, every count is zero.

25:44Cut the gap from almost two seconds to one, and the next clicking pilot begins while that counting is still happening. The loader compares counts from the early windows with counts from later ones, and now those later counts rise. But the loader doesn't stop there. It loads all of Decathlon's main block, taking another two minutes and forty-seven seconds of data. Only after all that does it restart the computer. A wrong bit in the main block has the same delayed result: the whole block loads, then the machine restarts without an R Tape loading error message.

26:35So does any noise make the gap fail? It isn't demanding perfect silence. The one-second gap fails because the next pilot drives the later counts far above the early ones. A gap of a second and a half passes. So does the gap with irregular clicks, because its early and late totals stay within the accepted relationship. The loader is comparing those groups of counts, not merely asking whether it heard any noise. Back on the original tape, the full gap passes the test and Decathlon's main block loads straight into memory, byte for byte.

27:17For twenty-one seconds, picture bytes arrive. Most of the display stays black, though the bottom two rows begin to appear in white near the end. Watch what happens when the colour bytes follow.

27:55Most of that picture had already arrived before it appeared. Twenty-two of its twenty-four rows were black on black. The bottom two still had white ink on black paper, so their lines appeared first. The colour bytes revealed the rest. With a good load, the loader erases part of itself by overwriting three hundred and seventy-four bytes of its own code, then jumps into the game.

28:29You know what you're hearing now. Now you'll hear both loading sounds at their proper speed: Decathlon's click and its gap, then Manic Miner's blocks in tape order.

29:07If you'd like to hear more of what these machines were really doing, subscribe to Retro Computer TV.