Resurrecting a PDP-12 in Duluth

 In this video, Kyle and I demonstrate how the flip chip tester (FCT) works. Enjoy!

A quick update on our FC testing project.  We are about 2/3 of the way through testing all the flip chips that are currently testable with Warren's tester. We have approximately five columns left to test in the bottom half of the backplane. Previously I reported that we had a failing 103, and two failing 216s.  After I asked Vince and Michael to help me understand how to interpret the errors from the tester, and and they consulted DEC documentation, they realized that the test for the 103 had a bug. Vince updated the test vectors and tested one of his 103s, and it worked. I got the fix to the M103 test, and that solved that problem. Today, one of my students and I tested a bunch of chips in the first column of the lower half. Shortly after I left, he discovered an M617 that fails.  So, there's another one to fix. But honestly, I love getting news like this, because these are all fixable things, and once they're fixed the machine should be much more functional and reliable

  Today's task: get our Flip Chip Tester (FCT) up and running. For those who don't know, Flip Chips (in DEC parlance) are small circuit boards with a handle opposite an edge connector, about the size of a 3x5 card, that have a small number of discrete components on it. Each Flip Chip provides a specific set of components to a machine. The one pictured here is an M617, which provides six four-input NAND gates (two per IC). The Flip Chip would be inserted into a slot, and a wire-wrap backplane would connect it to power, ground, and upstream and downstream components. One of my favorite things to explain to students is how the PDP-12's CPU can quite literally be repaired. When FCs go bad, it's usually because some IC on the FC has failed. Of course, you can just swap out the whole FC (if you have a spare). However, they can also be easily repaired if you know what to replace and you have equivalent IC packages. Enter the Flip Chip Tester. Before he died, Warren Stearns pro

I'm hoping to do a series of articles / threads about how the PDP-12 works, by diving into its instruction set and other low-level behaviors. Here's the first one! The PDP-12 is a combination of the LINC and the PDP-8 -- both 12-bit machines. The practice was to describe memory using four octal (3-bit) values (rather than, say, 3 hexadecimal values). So, 111111111111 in binary is octal 7777 (not 0xFFF ) and 101010101010 in binary is 5252 (not 0xAAA ). The PDP-12 runs in either LINC mode or PDP-8 mode at any given time, but you can arbitrarily switch between modes (and instruction sets) at any time, using ops PDP (0002) in LINC and LINC (6141) in 8-mode. Some hardware only works in LINC mode, so this is quite common. The LINC and the PDP-8 are single-accumulator machines, and so is the PDP-12. I.e., it has one general purpose register -- the AC. Instead of multiple registers, many ops can refer to core (RAM) addresses 1-15 and use them somewhat like modern registers. Don'

Hello all!  It's been a while since we've posted any updates, and this is long overdue. After sitting for a few long months with no use (it was a very busy semester), the PDP-12 is still working great! Although, it seems that the problem with the Teletype Receiver or Transmitter Flip Chips may be coming back (see earlier post  here .) We may need to do some more testing on those cards. Which, brings me to the main purpose of this post, Warren's Flip Chip Tester! The Flip Chip Tester had been one of Warren's projects for a number of years and after he passed away, a production version of the board was created by Vince (The same person who made our RS-232 interface and baud rate generator Flip Chips.) Warren's version was designed for a hardware parallel port and Windows XP, running in the DOS command line. Mike Thompson from RICM has been developing a GUI version of the program and made modifications for the board to run from USB. We are cu

The keyboard is now greased, oiled, and (hopefully) ready to go! I decided to remove all of the keys and all of the codebars (the metal strips with notches in them under the keys) to make oiling easier. Almost every point where two parts have contact (like the pivots on the ends of the codebars or the contact points where the keys hit a metal spring under the keyboard) needed a few drops of oil. A precision oiler was incredibly helpful and sped things up immensely, while minimizing the oil spilled on the table... In the last post I mentioned replacing the ESC key with the ALT MODE key from a different keyboard. I decided to keep the original ESC key after all. This decision was made because the two keys were not identical as I thought, and on each keyboard the CTRL keys had a different design as well. I assume that the ESC key would be coded the same as the ALT MODE key, but to be safe I left it as it was. In the future I may consider swapping the CTRL keys and the ESC/ALT MODE keys