Computer (museum) registers [was RE: Modules for LINC-8]

On 3. feb.. 2009, at 20.51, Pontus wrote: That PDP-7 is in Oslo. However, it is not in operable condition. Long story follows: The PDP-7 was my first real retrocomputing project. In retrospect, it was probably a massively bad call for a first project! Before I began, I didn't even know what a capacitor was. The machine was in the university library in which I was hanging out. It was a better use of time than attending class. Although my grades suffered, I never did really have trouble justifying skipping a school FrontPage class for deciphering the inner workings of a computer. :-) Before I touched anything, I took the maintenance and user manuals with me to a week-long holiday at my family's summerhouse, and I still remember the deep effect the F-77A service manual had on me. (now there's a sentence you don't hear every day...) I'd been a computer geek before this, but I had never quite understood computers past the level of "I input some mnemonics, and then magic happens inside the chip". A few years later, I saw a video of Steve Wozniak explaining how he "fell in love" with the PDP-8 as he read the manual. He exactly described my own feelings. Although I had idly programmed computers since I was 12 (Well, since age 9 if you count BASIC - but one doesn't, does one...) this was the first computer I felt I could *understand*, and it made a lasting impression on me and gave me a lasting fascination with retrocomputing as a way of "understanding" computers and computer engineering in a way that is simply not possible with the vastly more capable but yet somehow less interesting modern systems. The PDP-7 documentation was "describing a world" which was immensely fascinating to me. Anyway, back to the machine itself. Having read up on it, and consulted with electronics engineers (funny how those seem to be abundant in a CS/EE building, huh...) and also this mailing list, I found that the best course of action was to reform the capacitors in the PSUs, and then test the PSUs under a dummy load. The capacitors all held a charge marvelously, and were surprisingly close to their labelled capacitance. The PSUs were all within spec - not bad for a system that hadn't seen power since 1977! When initially powered up the CPU was completely dead. I managed to locate a few problems with individual components and swapping the boards for working ones. (There was a cache of spare flip-chips - and I refused to allow a PDP-7 to become my first soldering job!). One of my first repairs, and the one that really got the system going, was swapping out a B204 -- IIRC, the faulty board had an off-value resistor -- in the main timing chain. By the time I was "done", the CPU was able to fetch, decode, and execute arithmetic, conditional branch, and OPR instructions - and those were just the ones I tested. However, when I STARTed the CPU, the system looped at location 0. I quickly found out why: The physics department had, to deal with an increase in I/O load, created their own Automatic Priority Interrupt (The paper I read described it as "a poor man's API" - I think it was submitted to DECUS). The professor who used the machine is quite tall, over 2 meters, at least - and is described by many as "Norway's (largest/greatest) scientist". One time in the 1970s, he and a colleague of comparable stature were at a DECUS or DECworld or somesuch meeting. The conferancier, when receiving them, asked - "Are all Norwegians this tall!?". Immediately, his colleague replied - "No - we were the only ones who could fit on the plane.". :-) The PMAPI was built out of 74-series circuitry. Of course, when the system was decommissioned only a few years later, 74-series logic was both bloody expensive and general-purpose, so those boards were removed. As a result of this, the CPU always loops on an active-low IRQ from the I/O rack. The absence of any I/O left me unable to test any of the other peripheral devices. The paper tape reader would start when asked to by the CPU (The binary load feature necessitated some direct glue between the controller and the CPU), The Teletype would transmit correct codes as read by the I/O rack status lamps. The TTY itself (a KSR33) had a missing codebar reset bail, and eventually the H-bar broke (wow, it's been 4 years and I still remember the name of the damned parts. The Teletype manual was also a fascinating read.) The core memory could store and recall worst-case noise patterns entered into the system by a program I wrote which I stepped through while holding in "CONTINUE". Considering how inexperienced and unknowledgeable I was, I'm damned glad I never managed to make anything catch fire, and as a bonus, I think I really got quite far all things considered. The wall-like learning curve was very interesting to climb and I'm a happier person for it. Regards, -Tore :)