I thought I’d glue a surface-mount 7414 onto a resistor pack, just to make it easier to prototype. Then I thought, hmm… a resistor pack would be useful to pull down signals when the driving logic hasn’t be initialized.
So, here is the picture:
I soldered wires onto the resistor pack first, then submerged them in water so they wouldn’t come undone when I soldered the other end.
Works like a charm (0.1″ prototyping spacing).
The museum had a big event a few weeks ago, celebrating the 45th anniversary of the 1st “Intergalactic Spacewar Olympics.” Just a couple of weeks before said event, the museum acquired a beautiful Digital Equipment Corporation Lab-8/e minicomputer and I thought it would be an interesting challenge to get the system restored and running Spacewar in time for the event.
As is fairly obvious to you DEC-heads out there, the Lab-8/e was a PDP-8/e minicomputer in a snazzy green outfit. It came equipped with scads of analog hardware for capturing and replaying laboratory data, and a small Tektronix scope for displaying information. What makes this machine perfect for the PDP-8 version of Spacewar is the inclusion of the VC8E Point Plotting controller and the KE8E Extended Arithmetic Element (or EAE). The VC8E is used by Spacewar to draw the game’s graphics on a display; the EAE is used to make the various rotations and translations done by the game’s code fast enough to be fun.
The restoration was an incredibly painless process. I started with the power supply which worked wonderfully after replacing 40+ year old capacitors, and from there it was a matter of testing and debugging the CPU and analog hardware. There were a few minor faults but in a few days everything was looking good, so I moved on to getting Spacewar running.
But which version to choose? There are a number of Spacewar variants for the PDP-8, but I decided upon this version, helpfully archived on David Gesswein’s lovely PDP-8 site. It has the advantage of being fairly advanced with lots of interesting options, and the source code is adaptable for a variety of different configurations — it’ll run on everything from a PDP-12 with a VR12 to a PDP-8/e with a VC8E.
I was able to assemble the source file into a binary tape image suited for our Lab-8/e’s hardware using the Palbart assembler. The Lab-8/e has a VC8E display and the DK8-EP programmable clock installed. (The clock is used to keep the game running at a constant frame-rate, without it the game speed would vary depending on how much stuff was onscreen and how much work the CPU has to do.) These are selected by defining VC8E=1 and DKEP=1 in the source file
Loading and running the program yielded an empty display, though the CPU was running *something*. This was disappointing, but did I really think it’d be that easy? After some futzing about I noticed that if I hit a key on the Lab-8/e’s terminal, the Tektronix screen would light up briefly for a single frame of the game, and then go dark again. Very puzzling.
My immediate suspicion was that the DK8-EP programmable clock wasn’t interrupting the CPU. The DK8-EP’s clock can be set to interrupt after a specified interval has elapsed, and Spacewar uses this functionality to keep the game running at a steady speed — every time the clock interrupts, the screen is redrawn and the game’s state is updated. (Technically, due to the way interrupts are handled by the Spacewar code, an interrupt from any device will cause the screen to be redrawn — which is why input from the terminal was causing the screen flash.)
I dug out the DK8-EP diagnostics and loaded them onto the Lab-8/e. The DK8-EP passed with flying colors, but Spacewar was still a no go. I decided to take a closer look at the Spacewar code, specifically the code that sets up the DK8-EP. That code looks like this (with PDP-12 conditional code elided):
/SUBROUTINE TO START UP CLOCK /MAY BE HARDWARE DEPENDENT /THIS IS FOR KW12A CLOCK - PDP12 /OR PROGRAMABLE PDP8E CLOCK DK8EP CLSK=6131 /SKIP IF CLOCK CLLR=6132 /LOAD CONTROL CLAB=6133 /AC TO BUFFER PRESET CLEN=6134 /LOAD ENABLE CLSA=6135 /BIT RESET FLAGS STCLK, 0 CLA CLL /JUST IN CASE TAD (-40 /ABOUT 30CPS CLAB /LOAD PRSET CLA CLL TAD (5300 /INTR ON CLOCK - 1KC CLLR CLA CLL JMP I STCLK
The bit relevant to our issue is in bold above; the CLLR IOT instruction is used to load the DK8-EP’s clock control register with the contents of the 8’s Accumulator register (in this case, loaded with the value 5300 octal by the previous instruction). The comments suggest that this sets a 1 Khz clock rate, with an interrupt every time the clock overflows.
I dug out the a copy of the programming manual for the DK8-EP from the 1972 edition of the “PDP-8 Small Computer Handbook” (which you can find here if you’re so inclined). Pages 7-28 and 7-29 reveal the following information:
The instruction we’re interested in is the CLDE (octal 6132) instruction: (the Spacewar code defines this as CLLR) “Set Clock Enable Register Per AC.” The value set in the AC by the Spacewar code (from the octal value 5300) decodes as:
(Keep in mind that the PDP-8, like many minicomputers from the era, numbers its bits in the opposite order of today’s convention, so the MSB is bit 0, and the LSB is bit 11.) So the comments in the code appear to be correct: the code sets up the clock to interrupt, and it should be enabled and running at a 1Khz rate. Why wasn’t it interrupting? I wrote a simple test program to verify the behavior outside of Spacewar, just in case it was doing something unexpected that was affecting the clock. It behaved identically. At this point I was beyond confused.
But wait: The diagnostic was passing — what was it doing to make interrupts happen?
The above is a snippet of code from the DK8E family diagnostic listing, used to test whether a clock overflow causes an interrupt as expected. The JMS I XIOTF instruction at location 2431 jumps to a subroutine that executes a CLOE IOT to set the Clock Enable Register with the contents in AC calculated in the preceding instruction. (Wait, CLOE? I thought the mnemonic was supposed to be CLDE?) The three TAD instructions at locations 2426-2430 define the Clock Enable Register bits. The total sum is 4610 octal, which means (again referring to the 1972 Small Computer Handbook):
So this seems pretty similar to what the Spacewar code does (at a different clock rate) with one major difference: Bit 8 is set. Based on the description in the Small Computer Handbook having bit 8 set doesn’t make a lot of sense — this test isn’t testing channels 1, 2, or 3 and this code doesn’t configure these channels either. Also, the CLOE vs CLDE mnemonic difference is odd.
All the same, the bit is set and the diagnostic does pass. What happens if I set that Clock Enable Register bit in the Spacewar code? Changing the TAD (5300 instruction to TAD (5310 is a simple enough matter (why, I don’t even need to reassemble it, I can just toggle the new bits in via the front panel!) and lo and behold… it works.
But why doesn’t the code make any sense? I thought perhaps there might have been a different revision of the hardware or a different set of documentation so I took a look around and finally found the following at the end of the DK8-EP engineering drawings:
Oh hey look at that why don’t you. Bit 8’s description is a bit more elaborate here: “Enabled events in channels 1, 2, or 3 or an enabled overflow (bit 0) cause an interrupt request when bit 0 is set to a one.” And per this manual, setting bit 0 doesn’t enable interrupts at all! To add insult to injury, on the very next page we have this:
That’s definitely CLOE, not CLDE. The engineering drawings date from January 1972 (first revision in 1971), while the 1972 edition of the PDP-8 Small Computer Handbook has a copyright of 1971, so they’re from approximately the same time period. I suspect that the programming information given in the Small Computer Handbook was simply poorly transcribed from the engineering documentation… and then Spacewar was written using it as a reference. There is a good chance given that this version of Spacewar supports a multitude of different hardware (including four different kinds of programmable clocks) that it was never actually tested with a DK8-EP. Or perhaps there actually was a hardware change removing the requirement for bit 8 being set, though I can find no evidence of one.
So with that bug fixed, all’s well and our hero can ride off into the sunset in the general direction of the 2017 Intergalactic Spacewar Olympics, playing Spacewar all the way. Right? Not so fast, we’re not out of the woods yet. Stay tuned for PART TWO!
The CDC 6500 has been down since last Friday, so that will be a week in 3 hours. What have I been doing during that time? Let me tell you:
The first thing I noticed was that my PP memory test, called March, wasn’t working. The first real thing it does, after getting loaded into PP0, is copy itself to the next PP in line. In order to do that, it increments 3 instructions to point to the next channel from the one that got loaded in from the deadstart system. After it has self-modified its program properly, it runs those instructions to do the actual copy. The very first OAN instruction it tried to execute hung, this is not supposed to happen.
I spent 3 days looking at this problem before I started drawing timing diagrams of the channel address being selected by the various PPs. The PPs each have their own memory, but they all share the same execution hardware in chassis 1. This makes it a little hard to look at, as a PP is running 1uS cycles, the hardware is running 100nS cycles, and each PP gets a 100nS Slot to do his thing. As I was looking at PP0s slot time, and what channel he was trying to push some data to, it looked like it was getting done at the wrong time. When I plotted out 1uS of all the channel address bits, I finally noticed that PP0 was addressing channel 0, PP1 was addressing channel 1… and PP11 was addressing channel 11, and back to PP0.
The strange thing about that was that that is the way the system starts at deadstart time. Every PP sucks on the channel with his number. The deadstart panel lives off of the end of channel 0, PP0 sucks up everything the deadstart panel put on channel 0, stores it into memory, and when the panel disconnects, because he has run out of program to send, the PP starts executing the program.
Wait a minute here: the program was supposed to have incremented the 3 channel instructions, so they would be pointing to channel 1, why is PP0 still looking at channel 0? Rats: the channel hardware is doing fine, but the increment isn’t working! 3 days to prove something wasn’t the problem!
OK, so the increment isn’t working, what is it doing? I spent a while writing little bits of code to test various ways of incrementing a location of memory, and then Daiyu Hurst reminded me about a program she had generated for me that was a stand-alone version of the PP verification program that runs on the beginning of most deadstart tapes. OK, what does that do?
It hangs at location 6. It did that because it failed a ZJN (jump on zero) instruction. Why is that? The accumulator wasn’t zero. Hmm, instruction 1 was LDN 0, which loads the accumulator with 0! Why doesn’t that work? After another day, or so, I prove to myself that it actually does work, and 0 gets loaded into the accumulator at the end of instruction 1. Another thing that isn’t the problem!
What’s next? The next instruction is UJN 2, (unconditional jump 2 locations forward) which being at location 2, should jump to 4, which it does. It is not supposed to change the contents of the accumulator, but it does!
There are 2 inputs to the “A” adder, the A input is selected to be A, and the B input is zeros. All 12 of the inputs to the A side are zero. Wait: aren’t there 18 bit in the accumulator, what about those other 6 bits? Ah: bit 14 is a 1!
It will not sit still! I chase bit 14 for a while, and it starts working, but a different bit is failing now! I chased different bits around the loop for a while, put module K01 on the extender to look, and the test started passing! This worked for a while. I had the PPs test memory, and that worked, but if I had CP0 test memory, it didn’t like it. When I got back from lunch, it had gone back to failing my LDN 0 test. I put some secret sauce on the pins of module K01, and we are back to trying to run other diagnostics.
I remembered I was having trouble with the imaginary tape drives, to I tried booting from real tape, and I get to the part where it tests memory, and that fails. OK, we have some progress.
That was then, this is now, and we are back to failing to LDN 0. I found that bit 0 for the “B” input of the A adder was not correct. It seems that a via rivet was not conducting between the collector of Q30 and Q32 to the base of Q19 on my friend the QA module in K01. I resoldered all the via rivets, and the edge pins, just for good measure.
Central Memory still doesn’t work, but I can run some diagnostics again!
To paraphrase Sherlock Holmes: When you eliminate all the things the problem isn’t, you are left with what the problem is!
Bruce Sherry
In restoring the Bendix G-15 vacuum tube computer, I have uncovered a phenomena which is requiring us to replace over 3000 germanium diodes. These diodes appear to have lost their hermetic seal and the atmospheric contamination has caused their leakage current to rise to very high levels as they reach a normal operating ambient temperature of approx. 40 degrees C. Because these diodes are used in the clamp circuits that generate the 20 volt logic swing of the computer, the combined low impedance of the approx. 3000 diodes ends up shorting out the -20 volt power supply after 5 to 10 minutes of power-on time.
We have replacement diodes on order, and this should resolve the power supply issue.
Interestingly though, the failed diodes exhibit another interesting phenomena which this engineer hasn’t seen before. Hooking up a diode to an ohmmeter to measure its leakage current, and heating the diode to about 40 degrees C, causes the diode leakage, measured as resistance, to go from a few thousand ohms to a few tens of ohms. If the ohmmeter remains connected and the diode is allowed to cool to normal ambient, the low resistance measurement persists. If the ohmmeter is disconnected briefly and then reconnected, the diode leakage current returns to its nominal few thousand ohms.
Here is what has been going on on the CDC 6500: More Memory!
I’m sure the computer purity police will come and take me away, but this is what I have been doing. We are now up to 22 new storage module replacements, 17 of which you can see here. There are 3 more in chassis’s 9 and 10, and PP0 and PP1 each have one in chassis 1. I have 3 more to finish assembly of, when the parts come in later today.
Of the twenty units I have used in Central Memory, they are all involved in getting the First Location of banks 20 to 37 working, and that is all that works so far. If I try to test the second location, the first location fails. I don’t think the other three boards will get me through the second location, so I will probably be going out for more modules later today, or maybe next week.
My poor little milling machine has been working its bearings to the bone making Storage Modules sides and fronts. Since it doesn’t have “rigid tapping” (read automatic tapping), I started doing that by hand, but eventually I figured out a way to have the milling machine supply the energy to turn the tap, while I manually told it which direction to turn it.
So far, all the modules built have had the surface mount assembly done outside the Museum, and we have installed the pins and transformers. I may see about trying to convince other folks to do the through hole assembly and the machining.
Things are improving, we have moved from 65536 locations of memory to 65552 locations that work. Unfortunately it doesn’t work well enough to let the machine run with it out there, I still have to completely disable the upper 64K in order to have the machine boot.
Bruce Sherry 20170630
I have been worried that I would have to re-manufacture a module because I just couldn’t fix it. The time has come! I found this PZ module in chassis 10, while chasing memory problems. This one causes all 6 bits that go through it to fail my tests. I have traced it down to what appears to be an open base on Q26, which I have circled in the picture. OK, what’s the problem? Q26, as you can see is in the middle of the card. When I have had to replace middle transistors in the past, the front bracket has been held on with 6 little 2-56 screws. You don’t see any screws on this module other than the ones that hold it in place, do you?
This module coming from chassis 10, means it is newer, since Purdue upgraded from 64K to 128K several years after they got the machine. Instead of screws, this module is riveted together, and the rivets are soldered, as are most of the modules in Bay 3 which holds chassis’ 9-12.
Awkward.
Bruce Sherry
Update: I managed to get it far enough apart to change the offending transistor, and failed to break it completely, so now it works, without the 3 weeks of my time to re-manufacture it, not to mention the 3-4 weeks for the manufacturing process to actually produce the replacement.
BS
In this series of articles I’ll go into the Alto in detail — the low-level hardware implementation and microcode, the software and languages and ideas that this hardware made possible, and the environment at Xerox PARC where the Alto was designed and used. But before we dive down to the bedrock, let’s start with a bit of background.
Alto History
In the early 1970s, Alan Kay, a computer scientist at PARC, had a vision of a personal portable computer that he called the Dynabook. In many ways, Dynabook was similar to modern laptops or tablets – it weighed under two pounds, contained a keyboard, display, and pointing device, and had a tablet form-factor. The goal of the Dynabook was to be “a personal computer for children of all ages,” a portable educational computer. Kay’s vision wasn’t technically feasible at the time – but the vision behind it was a driving force for the research he lead both during his tenure at PARC and beyond.
In 1972 Kay proposed the idea of building a small personal computer (which he termed “KiddiComp”) to allow experimenting with the kinds of ideas he envisioned for the future Dynabook – in particular user interface design, education and computer-literacy for children. This was centered around a programming language he called “Smalltalk” which made use of unique hardware for the time: A high-resolution bitmapped display with a pointing device. Unfortunately, when Dr. Kay submitted a proposal to the management at PARC to get a few KiddiComp systems built, he was denied funding.
Enter Butler Lampson and Chuck Thacker. When PARC’s request for the purchase of a DEC PDP-10 for their research work was turned down in 1971 these two brilliant engineers figured they could design and build their own PDP-10 within eighteen months. And they did – MAXC (pronounced “Max”) was a microcoded recreation of the PDP-10 architecture using semiconductor memory rather than core, and a pair of them were used at PARC for the next decade. By 1972 Lampson and Thacker were both itching for a new project.
From Alan Kay’s “Early History of Smalltalk”:
In Sept [1972] … Butler and Chuck came over and asked: "Do you have any money?" I said, "Yes, about $230K for NOVAs and CGs. Why?" They said, "How would you like us to build your little machine for you?" I said, "I'd like it fine. What is it?" Butler said: "I want a '$500 PDP-10', Chuck wants a '10 times faster NOVA', and you want a 'kiddicomp'. What do you need on it?" I told them most of the results we had gotten from the fonts, painting, resolution, animation, and music studies. I asked where this had come from all of a sudden and Butler told me that they wanted to do it anyway, that Executive "X" [the executive who shot down Kay’s KiddiComp request] was away for a few months on a "task force" so maybe they could "Sneak it in", and that Chuck had a bet with Bill Vitic that he could do a whole machine in just 3 months. "Oh," I said.
Thacker and crew started the skunkworks project on November 22, 1972 and by April of 1973 the first Interim Dynabook (aka Alto) was up and running and displaying graphics:
The Alto featured a bitmapped display of 606×808 pixels with the approximate dimensions of an 8.5”x11” sheet of paper, 64KW (in 16-bit words) of semiconductor memory, a microcode clock rate of 170ns (approximately 6Mhz) and local storage of 2.5MB on a removable pack. In 1974 the design and implementation of Ethernet networking was completed, and became standard Alto hardware. All of this was implemented in a couple hundred ICs and fit under a desk. Over the next 10 years, approximately 2,000 Altos were manufactured for use within PARC and at research labs and universities around the world.
The Alto was designed as a research vessel for efforts within PARC, and in that regard it was an astounding success. Over the next decade, the Alto was involved in experiments in:
Most famously, the Alto (running Smalltalk) served as the inspiration for the modern Graphical User Interface. As the story goes, in 1979 teams from both Apple and Microsoft saw what PARC had been working on and were inspired, integrating aspects of what they saw into the Macintosh and Windows, respectively.
Smalltalk was important in early computer education and HCI studies and lives on to this day in the Squeak programming language.
The Mesa programming language originated on the Alto and was instrumental in the development of the Xerox Star desktop environment.
The Bravo word processor introduced WYSIWYG editing to the world and is in many respects the great-grandfather of Microsoft Word – Bravo’s author Charles Simonyi took what he’d learned from Bravo with him to Microsoft when he left PARC in the early 1980s.
The Ethernet networking research done with the Alto at PARC lead to the definition of Ethernet as an industry standard and was a major influence on the design of TCP/IP and associated networking protocols.
The Alto’s success was due in no small part to its clever, minimalist hardware design. This design made the Alto extremely flexible and easily adaptable to whatever crazy idea or experiment that needed to be investigated.
In the forthcoming articles in this series, I will go into detail about the Alto’s hardware and demonstrate how the Alto achieved this flexibility.
I installed all the fixes into the PCB design, and decided that, just maybe, I should check to see if it worked as Central Memory.
Arrgggghhh! It doesn’t.
I noticed yesterday that address bit 10 & 11 LED’s were backwards, and I just found that I had swapped them at the module pins. It is fixed on the next revision.
OK, now I am really confused: when I have the new memory in 5A01, bit 2 in bank 10 doesn’t work well. Swapping sense amps does nothing. Moved it from 5A01 to 5D01 and it works fine. I have seen it fail there, but not in the last half hour. I may need to decrease the output limiting resistors to help the sense ampllifiers.
A weekend has passed, and the new module still seems to work in 5D01. I may finish the layout, and build another round of boards. I am pretty sure I can fix the sense problems with resistor value changes.
Here is a closer view of the module as it currently exists:
Bruce Sherry 4/3/2017 8:22:32 AM
Where are we, and how did we get here? When we last left our hero, the last part for the new memory module was about to come in.
I couldn’t just sit there and admire my handiwork, I HAD to plug it in! The bad news was it didn’t work, the good news was that nothing blew up! OK, what works and what doesn’t? The addresses all seem to work, the read and write pulses seem to work, along with the chip enable.
Output data seemed to have a problem: I had decided to use ‘541 inverting buffers, with 10K ohm pull downs so I could generate small positive pulses, kind of like what the sense amp was looking at. One problem was that when the output was turned off, the level was floating at about 2V! This is not right, according to the spec, the leakage was supposed to be 5 micro-amps, which with a 10K pull down might end up with 0.05V. I swapped out the 10K’s for 470 Ohm resistors, and things looked a bit better.
I had decided, based on playing with some PS sense amplifier modules that maybe I could get away with capacitively coupling to one side of the differential pair that ends up being both ends of the sense wire through the core mat. As I looked at what the sense amps were seeing in the machine, the amps were not liking what I was doing: the levels were going all over the place.
OK, what do I do now? Do I generate the other polarity of signal? Do I shoot myself? The sense amp wants to see something like a wire between the two pins of the inputs. Hmm, we have a small boat load of core modules that we reclaimed from a gold reclaimer. Each one of the back modules has 64 nice Genuine CDC pulse transformers, would they be usable? The secondary is pretty much a wire into which a signal can be induced with the primary.
I extricated about 15 transformers from a board, and kluged them onto my memory. Does that work” No! Well, let’s see: Some of the data bits look like they have reasonable pulses, but some don’t. I found a transformer wire that hadn’t gotten soldered on properly. Eventually I found a couple of transformers wired in one pin off. Now I had pulses on all the pins, but come were positive, and some were negative.
I compared the real core module, and the pulse on the read portion of the cycles was always positive. In my investigation of the PS modules, I had convinced myself that the polarity didn’t matter. Maybe it does? I rewired all the transformers to be the same polarity, which I thought I had done, but reality came up and slapped me in the face saying: No, no!
Now all the bits are positive, except ONE! I must have missed that one somehow. Back upstairs to fix that one. They all have the right kind of pulses, but I get pulses for zeros, and the real one does pulses for ones! Yesterday I convinced myself that I had the data upside down, and changed the data drivers from ‘541’s to ‘540’s, so I guess I was wrong. I Hate it when that happens! After swapping back the ‘541’s, the pulses were all there, and in the right places!
Now SMM came up, and here is a picture of module with PMM, the PP memory test, running:
That’s Cool! What about the OS? Here we have the bench, with the laptop which has the console, and you can still see the module in Chassis 1:
Bruce Sherry 3/30/2017 2:56:10 PM
We have been running the CDC 6500 for about a year, with only half of its memory. There are 170 Core Memory Modules in the machine, and so far I have declared about 20 of them as being bad. Some it might be possible to tune into working, but some are just dead.
The plan has been to design a replacement module when the time came to get the rest of the memory working, and it seems that time is now. A couple of weeks ago, I spent some Quality Time examining the Peripheral Processsor memory in Chassis 1:
Each cycle lasts about 1 micro-second and includes both a read portion, and a write portion, because reading core is a destructive process, and the data needs to be re-written. The read and write controls are each about 400 nano-seconds, the sense amplifiers look at the read data for about 100nS, and write data is available for the whole period of the write signal, so this is pretty easy with modern components.
I chose to use two 8k by 8bit static rams, and only use half of the space. Timing was produced with some gates, and a delay line.
It took a few days to come up with enough of a schematic to start layout. Here is a picture of the first page of the schematic on the left screen, and the layout with some parts still to be moved onto the board, on the right screen:
The yellow lines indicate connections that haven’t been made yet. It took a few days, but then:
Red lines represent things and wires on the top of the board, whereas blue lines are on the bottom of the board. I didn’t display the two inner planes which hold power and ground. All the yellow lines are gone because I have created the traces to connect all the components.
I sent the board out to be built, ordered all the parts, and went on vacation while everything made it to the Museum. When I got back, I had work to do:
I have the parts, and the board ready to assemble, along with a free program on the laptop, called VisualPlace, which sorts all the parts, and shows me where they go. The red dots on the image of the board are pointing to where I should put the SRAM chips. Several hours later:
I discovered a couple of problems, the first of which is circled in red, and that is I forgot to order one part. The second is that somehow, the connector on the right ended up 0.050″ too narrow:
This is why we build Prototypes! The good thing is that I can still plug it in and learn more about how it is supposed to work, and the other mistakes I made. Here is a picture of the prototype mounted on extenders in chassis 12:
You can see 12 LED’s, in the upper right corner, lit as the addresses go to every module all the time. This being chassis 12, the other two LED’s aren’t lit because we aren’t using the upper half of memory yet. The missing part should arrive in an hour or so, but for now here is a picture of how the new module might look next to an original module:
Bruce Sherry 3/28/2017 9:03:17 AM
