Speaking of drums memory, probably the most curious drum concept is the fast drum for the PDP-1 timesharing systems at BBN and MIT (two of these drums were built in total). To me, it’s a typical Ed Fredkin invention: ingenious, up to the purpose and specific application, but it doesn’t scale well.
The principal idea is about how core memory works: You read by writing a zero to it, collect the pulses emitted by any bit flips, and then you have to restore the original contents by writing it back. And here comes Ed Fredkin’s idea: nothing tells you that it has to be the original value that is written back.
Fredkin’s fast drum had tracks of the length of the PDP-1’s standard core memory (4096 18-bit words) and multiple heads. So, during one rotation of the drum, you could swap the entire memory, just by accessing the memory. The individual memory cells in RAM became a parallel FIFO buffer of sorts: read the contents (to be written to one track), and replace it by the contents coming from the drum (read from another track) in the restore cycle of the memory. With a memory cycle of 5 microseconds, a full swap of the 4096 words was about 20 milliseconds, or nearly instant. (An additional register on the drum kept track of the current rotational index of the drum, to synchronize the memory loop on the PDP-1 with the state of the drum.)
This close-to-instant swap also enabled Ed Fredkin’s timesharing system to swap users on every key stroke, not just on carriage return.
From Ed Fredkin’s oral history:
[Ed Fredkin:] If you typed a key, the time it took to swap out the person who was running and to swap you in to replace him was 20 milliseconds and it had no latency. In other words, normally, with a disc or drum, you have latency. This was zero latency. I invented all this, and it was so efficient. Here’s how it worked. The memory was 4,096 words. The drum that I designed, it had 4,096 words around it. If you looked at the detailed timing diagram of the drum and you looked at the detailed timing diagram of RAM, you discovered you could do this amazing thing, which is what I discovered. You do the read cycle on a word in RAM, so you read this word out, which clears this register. And normally, you’re going to write it back-- read/write, so you still have the memory. Meanwhile, while you’re reading this out, you’re reading a word off of the drum. Now, instead of writing this word back, you write the word back that you got off of the drum, and write this one on the drum in another field. So what you could do is, every memory cycle of the PDP-1 core memory, you would swap one word. Now the reason there was no latency, is that there were 4,096 words around the drum, so when you said “swap”, it looked and said oh, the drum’s on register 2,007, so we start there in RAM. And we just went once around the drum, and we filled our RAM always, so there was no latency, and it was 20 milliseconds. Anyone who copied this idea, swapping, missed that point of it being fast, and they ended up with swapping being an algorithm to make people wait, because they didn’t have fast drums. They did nothing. No one ever did it that way again.
Notably, this instant response was key to interactive timesharing as envisioned by Ed Fredkin:
My criteria was, the thing had to be able to respond to every character you typed. So what does IBM do when they copied swapping? They came up [with the scheme that] the computer will pay attention when you hit the carriage return. See, we had a kind of philosophy that was every character. We wanted interaction, so that if you’re typing, it’s coming up on the screen. They made it so you type a whole line and hit the carriage return. You hit the carriage return and then you wait. I’m sort of a fanatic on making things work fast.
(Ed Fredkin’s oral history: Fredkin, Ed (Edward) oral history | 102630504 | Computer History Museum)
BTW, the drums were built by DEC, following a quite amazingly fast procurement process, about as instant as the operations of the drum:
Meanwhile, John McCarthy was enthusiastic about it, and there was a PDP-1 at MIT. This funny thing happened. There was some meeting at MIT, and Ben Gurley was there. John and I and Ben are in a room, and John says to Ben, “Listen, we want to do this swapping drum. Will you build it?” Ben was a sort of interesting guy. He says, “No one’s given us a purchase order.” John says, “If you had a purchase order, would you build it?” He [Gurley] said, “If I had a purchase order right now, yes, we’d go build it right away.” So John runs out and finds Professor Zimmerman, who is head of RLE, and makes him make MIT give him a purchase order right then. He comes back in the room and says, “Here’s MIT’s purchase order number.” I called Licklider and I described this thing to him and I said, “Get someone to call me with a P.O. number.” What happened is in, like, another 15 minutes Ben Gurley had two purchase order numbers: one from MIT and one from BBN. That’s the way business should be done sometimes.
And the young man who ended up designing the system at DEC happened to go by the name of Gordon Bell.
This also highlights the entirely different approaches, the ones of the military as shown in the video (of which Ken Olsen used to make fun of) and the kind of swift moving, interactive approach featured by DEC. There’s no way, a military system could have found its way into the world like this. And there’s probably also no way, a military grade logistics system could have been designed like this.
(One of the drawbacks of this approach was that the PDP-1 had no memory parity bits and that the contents of RAM and the drum was destructed as you swapped. So, if anything wasn’t working eactly as expected or became subject to any kind of interference, the state progressilvely corrupted and there was no way to detect an error or to recover a known good state.)