The wildly successful PDP-11 minicomputer was a major influence on the evolution of computing throughout the 1970s. While fondly remembered in modern day emulation, there’s nothing like booting up the real thing, as [Jerry Walker] explores in his video series on restoring a PDP-11/34. Examples of PDP-11 hardware are becoming increasingly rare, which makes restoration and preservation of remaining equipment even more critical. [Jerry] has gone to exhaustive lengths to restore his PDP-11/34 to working condition, painstakingly troubleshooting wire-wrapped backplane and replacing suspect ICs across the entire system. With scant documentation on some of the cards, it was often a matter of sheer will and technical know-how that saw the system eventually come back to life.
If you’ve got a couple of hours, make sure to check out the entire series of videos documentation the restoration over on YouTube. If you’ve ever thought about restoring vintage computers, this series offers an insight into the satisfying yet oh-so-tedious process of chasing down broken traces and faulty logic. Exorcising the demons from decades-old computers is almost never straightforward, but [Jerry] demonstrates that persistence can yield exciting results. After the break is the latest installment of this series, which shows the system booting into the RT-11 operating system from floppy disk.
If you don’t have the time or real estate to restore a real PDP-11, you might want to check out modern hassle-free replicas. Or, if we’ve piqued your interest in restoring minicomputers, don’t miss what we had to say about previous PDP-11 resurrections, like this PDP-11/04.
I worked at DEC Westfield for two summers as a fill-in test tech. The final summer, I acquired from the scrap sales, parts for a VT-05 terminal (non functional, of course). It was basically, a keyboard, a power supply, a Ball CRT module, a housing, and a set of four quad modules with a mini-backplane.
All the parts had issues; some were easy to fix (busted wire or broken connector) and some were more difficult. The mini-backplane was a very expensive item, and this one had an issue with the PCB soldered onto the pins: the plated through holes…weren’t. I spent a couple of weeks with very thin solder, snaling it between the pins, to solder the traces on the inside of the PCB to the backplane pins. But the terminal eventually worked, and I used it for several years before selling it to someone at MIT.
Back in the USAF I worked on several systems with wire-wrapped backplanes. I never had one fail, but given I had a good imagination, I knew troubleshooting would have been a nightmare.
Don’t forget that the team that created VAX/VMS, the successor to the PDP line’s operating systems (there were several: RT-11, RSTS, etc.) went on to apply their knowledge of multitasking and virtual memory to Windows NT.
I’m not sure why you’re using the word “team” to describe what Dave Cutler did at Microsoft. Yes, he was brought from DEC and made lead developer for Windows NT, but it certainly wasn’t a coordinated “team” effort from DEC to M$! I’ve been browsing “Regional Advantage: Culture and Competition in Silicon Valley and Route 128” by AnnaLee Saxenian, in which she basically says DEC, and other northeastern companies, tried to do everything “in-house”, while Silicon Valley “networked”, shuffling ideas (and people) around, contracting out whatever could be done more cheaply, or quickly, elsewhere. I’m curious how this might be reflected in the architecture. Probably quite differently from tracking down vintage PC cards with unique settings and curious incompatibilities with different clone PCs. And different again from S-100 CP/M machines with various kludges and homemade “upgrades”. DEC shouldn’t have died the way it did. Imagine if the internet was built on DECnet instead of old arpanet standards!
I’ve read about that era of computing a lot, my understanding is “Team” is right in the sense that at least a dozen DEC West employees followed Dave Cutler to Microsoft in 1988 and formed the backbone of the NT project.
Microsoft’s own press materials say so: https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/
Likewise, this old ITPro article from ’98 ( https://www.itprotoday.com/compute-engines/windows-nt-and-vms-rest-story ) suggests that “One of Cutler’s conditions for moving to Microsoft was that he could bring around 20 former Digital employees with him, including several Prism hardware engineers.”
I think the discrepancy in numbers is that some of them quit DEC to follow Dave to Microsoft, and some had already been laid off in the PRISM cancellation and were simply hired.
That comment about DECnet sounds like the seed of a fascinating article.
There were a dozen different network stacks back then, they all died because none of them could route. TCP/IP killed all of them because it learned the lessons of the failed networks. None of them had the features for routing and WAN deployment and would have failed miserably if they had tried to be executed on a large scale.
TCP/IP also was the “Internet Explorer” of the *nix world, so to say. It shipped for free with many copies, didn’t it? Another, lesser known protocol was X.25, also.
It’s hard to imagine a WAN based on a network protocol that doesn’t support routing and a max of 255 nodes on one network. DECnet was dropped like a hot potato when tcpip came along.
DECs founder said that they did not think that individuals should own computers.
DEC threw away money by the bushel, chased away good employees and screwed up the economy of Eastern Mass for decades with their massive layoffs. They were a garbage fire of a company that could not go away fast enough.
How are you imagining this company surviving?
That 255 node limit was in DECnet Phase III. Phase IV introduced DECnet Areas 1-63 and greatly expanded the maximum number of nodes. I was supporting Phase IV networks with hundreds of nodes in multiple DECnet areas in the early to mid 1980s, and recall needing to use a separate Ethernet card to support IP before an implementation came out to support DECnet and IP on the same controller.
I supported a few PDP-11/24 based “Pluto” boxes that could be configured as terminal servers, routers, and DECnet-to-SNA application gateways to interconnect with IBM mainframes.
DECnet was a routed protocol, but it was also a network architecture. There were other protocols involved with network booting (MOP DL), remote console (MOP RC), network disks (LAST & LAD). The LAT protocol was used to allow remote terminals and printers by multiplexing terminal traffic to terminal servers, reducing traffic compared to the overhead on telnet based connections.
DECnet Phase-V was actually 3-in-1, it provided OSI protocol, Phase-IV compatibility, and TCP/IP all together.
The main thing going for IP is that it was an open standard, not proprietary like DECnet, Novell IPX or AppleTalk / EtherTalk, for example.
I started watching the restoration videos last night and got sucked in…. Before I knew it, it was 01:30 hours in the morning. The restorer is quite wordy (and knowledgeable) and explains almost every detail however minor and sometimes repeats. Still interesting to see how he went about finding the problems and what could be problems and then testing of course. Had to stop at the memory board testing video…. lots more to go if I want to follow all the way through.
Thanks for the article.
We had a PDP-11 34A at work in the 1970s. It was programmed mostly in FORTRAN with a bit of BASIC thrown in here and there. It was a travel company, and we managed to hook up around 30 VT52 terminals and used it for real-time reservations and ticketing. It ran on RSTS, and even DEC themselves were impressed with how much we could get out of what was quite a humble machine by any standards. I recall it had 2 x RK06 disk drives and it came in the lower grey and blue cabinets. I loved the thing. It was amazingly forgiving and robust.