The Story of Mel is a classic piece of hacker lore about Mel Kaye, an early programmer who wrote machine code for a drum memory computer. Mel eschewed compilers and assemblers, writing raw binary. He famously programmed instructions so they would physically align with the rotating drum's read head at the exact millisecond they were needed. When a coworker tried to fix Mel's seemingly erratic code, the program broke; Mel's hacks were perfectly timed masterpieces.
An Epic from the Early Days of Usenet
In May 1983, an astronomer and software developer named Ed Nather posted an essay written in free verse to the Usenet newsgroup net.followup. Titled "The Story of Mel, a Real Programmer," the piece resonated across the early computing community and quickly achieved mythic status. It was composed as a response to Ed Post's popular satirical essay, "Real Programmers Don't Use Pascal," which celebrated the rugged ethos of early computer engineers who bypassed modern conventions to write bare-metal code.
Nather's account chronicled his time working alongside Melvin Kaye at the Royal McBee Computer Corporation during the late 1950s and 1960s. Kaye had authored the demonstration programs for the company's LGP-30 computer, including a popular blackjack simulation. When Nather was later tasked with inspecting and modifying Kaye's code, he discovered a style of programming so intimately bound to the computer's physical mechanics that it defied conventional software practices of the era.
Over the decades, the text circulated widely across bulletin boards, computer science departments, and the Jargon File. While written with poetic cadence and lighthearted humor, Nather's story is fundamentally a technical document illustrating a transitional period in computing: the shift from idiosyncratic, machine-level craftsmanship to standardized high-level software engineering.
The Physics of Drum Memory
To understand Mel Kaye's feats, one must understand the hardware he was programming: the Royal McBee LGP-30. Manufactured in the mid-1950s, the LGP-30 did not possess random-access electronic memory as modern systems do. Instead, its primary storage was a magnetic drum, a metal cylinder coated with magnetic material that spun continuously at roughly several thousand revolutions per minute.
Data on a drum computer was recorded in circular tracks divided into sectors. Fixed read and write heads sat suspended above the rotating surface. If a program needed to retrieve a number or execute the next instruction, the central processor had to wait until the exact sector containing that information physically spun under the read head. If an instruction executed slightly too slowly, the drum would pass the desired location, forcing the processor to wait an entire rotation before the data became accessible again.
This mechanical constraint made software efficiency directly proportional to physical rotational mechanics. A poorly arranged program could run dozens of times slower than an optimized one simply because it spent the vast majority of its operating time idling, waiting for the magnetic surface of the drum to come around.
Optimum Programming in Raw Machine Code
To mitigate rotational latency, the LGP-30's architecture used an instruction format where each instruction specified not only the operation to perform and the data address, but also the location of the next instruction to execute. This enabled a technique known as "optimum programming." Programmers would scatter instructions across non-consecutive sectors of the drum, timing their placement so the next instruction would arrive beneath the read head precisely as the previous one finished executing.
While many programmers utilized an optimizing assembler—a software tool designed to calculate these sector offsets automatically—Mel Kaye refused to use one. He viewed the assembler as an unnecessary intermediary that added overhead and produced suboptimal arrangements. Instead, Mel calculated every rotation, timing gap, and sector offset in his head, writing his programs directly in raw hexadecimal machine code without symbols or comments.
Because he operated without an assembler, Mel treated the memory drum as a unified canvas. He did not separate code from data in the way modern software architectures mandate; numbers, addresses, and executable instructions were interchangeable values stored across the tracks of the drum.
The Mysterious Non-Terminating Loop
The turning point in Nather's account occurs when Royal McBee requested a modification to Mel's blackjack program. Marketing representatives wanted the program altered so that if an executive or salesperson toggled a specific sense switch on the console, the machine would cheat in the player's favor, ensuring high-value clients won their demonstration games. Because Mel had left the company, the task fell to Nather.
As Nather traced the machine code to locate where the card logic was handled, he encountered an assembly of bizarre programming techniques. In one routine, he found a loop that lacked any conditional test to exit. In standard programming, a loop must evaluate a condition—such as checking whether an index counter has reached zero—to determine when to break out. Mel's loop appeared to run indefinitely, which should have frozen the computer.
Upon deeper analysis, Nather realized that Mel was deliberately overflowing an address register. Mel had arranged the loop to increment a memory address on each pass. When the address incremented past the highest available sector on the drum, the numerical value overflowed into the opcode field of the machine word. This arithmetic artifact transformed what had been an increment instruction into a conditional jump instruction, breaking the loop at the exact instant the data processing finished.
Negative Delays and Hardware Timing
In another section of the code, Nather found what appeared to be an outright error: an instruction set to execute with an impossible timing delay. When Nather calculated the execution time of the preceding instruction, he realized the target sector would arrive under the read head slightly before the processor was ready, theoretically forcing a full drum rotation of wasted time.
Believing he had discovered a mistake left behind by Mel, Nather adjusted the sector address by one position to give the processor sufficient time to catch the read head on the immediate revolution. When he ran the revised program, however, the blackjack simulation ground to a halt, running sluggishly and failing to keep pace with the console display.
Nather had overlooked the physical timing margins of the hardware. Mel had discovered that the electronic read circuitry possessed a subtle propagation delay that allowed the processor to read data slightly ahead of its rated clock cycle under specific voltage conditions. Mel had not made an error; he had exploited an undocumented electrical quirk of the LGP-30 to save a millisecond. Correcting the "mistake" had actually ruined the delicate physical synchronization.
The Legacy of Bare-Metal Mastery
Confronted with the astonishing, fragile brilliance of Mel Kaye's code, Ed Nather chose not to insert the requested cheating switch. In his poem, Nather decided that compromising such pristine mechanical craftsmanship to let a salesman cheat at cards was an insult to the art of programming, opting instead to leave the original program intact.
The story remains an enduring piece of computer folklore because it captures an extinct era of software engineering. As computer memory transitioned from rotating drums to magnetic core and solid-state transistors, and as compilers became vastly superior to manual machine coding, the need to program for physical rotational latency disappeared.
Today, software development relies on layers of abstraction, portable code, and automated optimization. While these advances made modern computing scalable and reliable, Mel Kaye stands as the archetypal symbol of a time when programmers held the entire physical reality of a machine in their minds, executing feats of logic that blurred the boundary between software and physics.
Key takeaways
•The Story of Mel was written by astronomer Ed Nather in 1983 as a free-verse Usenet post celebrating the bare-metal programming style of Melvin Kaye.
•Mel Kaye programmed the Royal McBee LGP-30, a computer that relied on a rotating magnetic drum where software speed depended on timing instructions to the drum's physical rotation.
•Kaye eschewed assemblers and compilers, writing raw machine code that exploited hardware quirks, self-modifying instructions, and intentional arithmetic overflows to achieve extreme efficiency.
•The story highlights the historical transition from highly individualized, hardware-dependent programming to modern structured software and portable compilers.