The Magnetic Drum

A magnetic drum is a metal cylinder with a magnetic coating, spinning at a constant speed. Fixed read/write heads sit a hair's breadth from its surface, one per track. Each head can read or record the stretch of coating that passes beneath it. That is the whole idea, and for most of the 1950s it was the main memory of a good many computers.

It is worth understanding in some detail, because it shaped how those machines were programmed, and because the problem it posed has never really gone away.

How it works

The drum's surface is divided into bands around its circumference, called tracks. Each track is divided along its length into sectors, and each sector holds one word. A word is addressed by naming its track and its sector.

The LGP-30 is a representative example. Its drum is 6.5 inches across and turns at about 3700 revolutions per minute. It has 64 tracks of 64 sectors, which gives 4096 words of 32 bits. The heads never move. What moves is the drum, and it never stops.

This has one consequence that matters more than any other: a word can only be read when it passes under its head. At 3700 rpm one revolution takes about 16 milliseconds, so a word you have just missed will not come back for another 16. The time to reach a word depends on where the drum happens to be when you ask. There is no such thing as a fixed access time.

Why it existed

Memory was the hardest part of an early computer to build. The two main alternatives in the late 1940s were mercury delay lines, which stored bits as sound pulses in tubes of mercury and had to be kept at a steady temperature, and Williams tubes, which stored bits as charged spots on a cathode-ray screen and needed constant adjustment. Both were fast by the standards of the day. Both were expensive, fussy, and small.

The drum was none of those things. It was a piece of precision machinery, but conventional machinery: a motor, a cylinder, and a row of heads. It held far more than a delay line or a tube of the same cost, and it kept its contents when the power was off. It was slow, but it was cheap and it worked. For a machine meant to sit in an ordinary office and plug into an ordinary socket, like the LGP-30, nothing else came close.

Strengths and weaknesses

In favour:

• Cheap per word stored, and large for its time.
• Non-volatile: a program left on the drum was still there the next morning.
• Mechanically simple and, once running, reliable.
• Compact enough to make a desk-sized computer possible.

Against:

• Slow. Waiting for the right sector costs, on average, half a revolution.
• Access time depends on position, so the same instruction can take very different times depending on where its operand lives.
• Bits arrive one after another as they pass the head, which is why most drum machines did their arithmetic serially, one bit at a time.
• Moving parts wear, and the head-to-surface gap had to be held to fine tolerances.

What it asked of the programmer

On a drum machine, the order of instructions in memory is also a timetable. Each instruction names the address of the next one, or implies it. If the next instruction sits just beyond the current one on the drum, it arrives when it is wanted. If it sits just behind, the machine waits most of a revolution for it. The same is true of every operand.

So a good programmer did not simply write a correct program. They placed each instruction and each piece of data where the drum would be at the moment it was needed, working out the timing by hand. This was called optimum or minimum-latency programming, and a well-placed program could run several times faster than a naive one of the same logic. On the IBM 650, the best-selling computer of the decade, the job was important enough that IBM's assembler was named after it: SOAP, the Symbolic Optimal Assembly Program, which placed instructions on the drum automatically.

The best-known account of this craft is the Story of Mel, about an LGP-30 programmer whose programs relied on the drum's timing in ways his colleagues could barely follow.

Its place in history

The drum is older than the stored-program computer. Gustav Tauschek patented a drum memory in Austria in 1932. After the war, Andrew Booth in London and Engineering Research Associates in the United States built working drums for early machines, and by the mid-1950s drums were the main memory of a generation of smaller, cheaper computers: the IBM 650, the Bendix G-15, the LGP-30 and others. These were the machines that took computing out of government laboratories and into universities, engineering firms and businesses.

Magnetic core memory, with its fixed and much shorter access time, replaced the drum as main memory from the late 1950s on. The drum did not disappear. It moved one level down, to become the large, slower store behind a small fast one. The Manchester Atlas of 1962 used exactly that arrangement, and moved pages between core and drum automatically. That mechanism is the ancestor of virtual memory in every computer today.

Why it is still worth your time

The specific problem of the drum is gone. The general problem is not. Modern processors spend much of their time waiting for memory, and much of modern performance work is about putting data where it will be when it is needed: caches, prefetching, locality. The drum shows that problem at a scale you can see and count by hand, in milliseconds instead of nanoseconds, with nothing in between to hide it.

A drum machine is also small enough to understand completely. The LGP-30 has 16 instructions and one accumulator. There is no operating system, no compiler and no library. Everything that happens, happens because you arranged it. Learning to program it well means learning what a computer actually does, and that knowledge does not go out of date.

This site exists to make that experience available again: to let you write programs for a real drum machine, watch the drum turn under them, and find out for yourself how good you can get at it. The place to start is the LGP-30 IDE.