The newest arrival at Microsoft co-founder Paul Allen’s Living Computer Museum in Seattle is a big one — both literally and figuratively. Weighing more than 10,000 pounds, the Control Data Corporation 6500 is part of a line of machines that were the first to be called “supercomputers.” Each of its three giant bays has its own refrigeration system.

LCM engineering manager Robert Michaels with the CDC 6500.

This particular CDC 6500 was turned off in 1989 after two decades at Purdue University. Now, Allen’s engineers in Seattle are preparing to bring it back to life. The project will take an estimated two years — and there’s no guarantee that the effort will succeed.

“It is a much larger project for us than we’ve ever dealt with … and it’s going to be close to the oldest thing we have in the museum,” said Robert Michaels, engineering manager at the Living Computer Museum. “So it’s a big, big deal for us.”

It’s believed to be the only machine of its type that could be brought back to life. The CDC 6500 was acquired by Allen for an undisclosed sum from the Chippewa Falls, Wis., Museum of Industry and Technology, and carefully shipped across the country to the museum, between the Starbucks headquarters and Seattle’s pro sports stadiums south of downtown.

Working as an engineer at the Living Computer Museum must qualify as one of the most interesting jobs in technology. Ian King, a senior vintage systems engineer who was my tour guide on a recent visit, acknowledged that he’s like a kid in a candy shop.

But restoring the CDC 6500 will be no walk in the park.

The console for the CDC 6500. used by the operator of the machine.

Developed by the late supercomputing pioneer Seymour Cray in the 1960s, the CDC 6500 an example of pure, brute-force computing — a machine that uses any means (and size) necessary to provide the computing power necessary to meet the needs of its users. Its predecessor, the CDC 6600, was first delivered to the Lawrence Livermore Laboratory, providing the computational horsepower required for atomic bomb simulations, and it’s credited for helping to win the Cold War.

The system monitors the refrigeration system for pressure. If something goes wrong, the CDC 6500 will need to be powered off immediately or risk being ruined.

One of the biggest challenges: The machine used liquid coolant — no fans. Each of the three bays has its own refrigeration unit, and the engineers will need to get them working again before the machine can run.

“We have to get the refrigeration system working. We can’t even begin to power it up without it,” said Michaels. “You power it up for a few minutes (without refrigeration) and you’ve got a mess on your hands.”

The museum has already assembled a team to evaluate the refrigeration system and create a plan for bringing it back to life. This will require not only restoring the system inside the CDC 6500 but also constructing an associated cooling system on the roof of the building.

Another challenge: the complex network of cabling that connects the three bays was cut long ago, after the machine was removed from service, and will need to be reconnected as part of the restoration. That’s just one of the obstacles that the Living Computer Museum’s engineers will need to overcome to get the machine running again.

Then there’s the final challenge: No cheating allowed.

Twisted pair cabling, a Seymour Cray signature.

“We have to be careful about authenticity,” Michaels explained. “It’s so easy to emulate various functions of a system. You could easily replace one of these with a Raspberry Pi, and nobody could tell the difference. We want to adhere to authenticity. People have to know that this thing is really what it was.”

If all goes as planned, the restored CDC 6500 will greet visitors when they arrive at the Living Computer Museum in a couple of years.

In the meantime, if you want to follow along, the museum is posting regular updates about the CDC 6500 restoration on its Facebook page, including answers to technical questions about the planned operation of the machine.

Like what you're reading? Subscribe to GeekWire's free newsletters to catch every headline


  • brian myers

    Just for giggles, the author should compare the power of this computer to, say, a current MacBook.

  • Lazowska

    One of the most interesting things about the wiring harnesses that were cut is
    that they are “length-tuned” – bringing the machine up involves getting
    the lengths of the wires between the cabinets exactly right in terms of
    signal propagation delay.

    (Ian King, Utilikilt and all, is an alum of ours – I brought
    150 undergrads down there for an evening last month and Ian held them
    spellbound. Also, there’s something about a 19-year-old that loves a
    keypunch, no matter what decade! Anyone interested enough to read GeekWire should visit the Living Computer Museum – it’s truly extraordinary! And it’s totally hands-on!)

  • David Woods

    wow its amazing how big those computers were, and it wasn’t that long ago

  • JRR2

    I used this very machine when I was an undergrad at Purdue in the early 80s. Still have my Compass manual in my office.

    I’ve also handed out punch cards to young folks today. I’ve saved a few items over the years but I wish I kept more.

  • bwb

    I worked on that very 6500 when I worked for PUCC (Purdue University Computing Center) on the systems staff while an undergrad and a grad student from 1969 – 1973. I wrote what would be considered the kernel of the time sharing subsystem running under the locally developed Mace operating system. With only 65k words of memory available to programs, it was something of an art form to arrange the 15 and 30-bit instructions to pack into the 60-bit words. The nature of procedure call (subroutines on that machine–the family was essentially designed for Fortran) which modified code, made a shared code base among all the timeshare users a challenge. Roger Wagner came up with a wonderful working solution. We supported hundreds of simultaneous users using a TINY TINY fraction of the memory and compute power of one of today’s phones. It is still one of my favorites.

    For the question about power: 1uS memory cycle time core memory, 60 bit words, with 262K words (don’t know why we didn’t say 256k back then). One-compliment machine (had both a plus and minus zero). The fixed disk drive units had two spindles about six feet high, with disks platters about three feet in diameter. The think the heads were on hydraulic actuators. There were also MG sets used to provide power. May have been at 400Hz. The 6500 had 2 CPUs plus 10 PPUs (peripheral processors) which were responsible for all I/O and a fair amount of system control. Each PPU was a 4K 12-bit word core stack.

    • Daiyu Hurst

      I never quite understood (even from the docs I had) the relationship between PROSCY and PIRATE; care to illuminate? I used the system during the 1974 Summer Engineering Seminars.

      • Dennis

        PROCSY (the Purdue Remote Online Computing SYstem) is the overall system for handling remote access. PIRATE is the sub-system for creating, controlling and results handling of batch jobs. Other sub-systems include PED (the Purdue EDitor), PFILES (a persistent file management system), and ALFIE (Algorithmic Language For an Interactive Environment), a extended Basic that I worked on. I shared an office with bwb.

  • Arden White

    Oh my gosh! I wrote code on that computer when I was at Purdue (in the middle 1980s). I feel old.

  • Dennis_Frailey

    I pretty much lived with this system between the time it was installed and the time I graduated at the end of 1970. The 6500 was actually a dual 6400 and this may have been the first one. I did my dissertation research on it (an optimizing compiler) and worked in the computer center doing operating system modifications (deadlock avoidance and some I/O systems, in particular). I spent many a late night in the computer center with this computer and after I left I convinced the folks at my first “real” job to get a similar system.

  • Dennis_Frailey

    Here’s an interesting anecdote about this system. When it was first installed there was a guarantee by Control Data that it would say “up” for a specific amount of time – I think it was 2 hours. Unknown to us at Purdue, there was a known bug in the operating system that caused it to crash shortly after 2 hours, which is why they didn’t guarantee it would be up for 3 hours!

  • Dennis_Frailey

    Here’s another anecdote about this system. It was introduced at about the time that virtual memory was being introduced on the IBM 360 series and virtual memory was all the rage. Unfortunately, virtual memory tended to slow systems down because of overhead and garbage collection. The CDC 6000 systems did not have virtual memory, relying instead on having very fast, very large physical memory (interleaved up to 16 ways) and smart OS memory allocation algorithms. So they were very fast, but you needed to exercise a certain amount of care when programming certain types of large-memory applications. We never had to wait for garbage collection, a fact that meant the CDC 6000 systems tended to beat the pants off of comparably priced competitors. I think of this every time my modern “smart phone” goes into a virtual memory garbage collection binge and leaves me unable to use the device for minutes on end. When i ask tech support for help on this, I can tell that they don’t understand the concept of systems that don’t need virtual memory.

    • Daiyu Hurst

      Lol, ikr? My emulated 6400 starts up faster than my VIZIO SmartTV.

  • Daiyu Hurst

    As a colleague point out, they were not used for “atomic bomb simulations.” They were used to simulate the interior of the sun. ;)

Job Listings on GeekWork