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.
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.
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.
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.
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.
In Sept  … 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:
Programming languages (BCPL, Smalltalk, Lisp, and Mesa)
Networking and distributed computing
Desktop publishing, word-processing and laser printing
The Graphical User Interface (GUI)
Computer-generated music and audio
Computer-generated graphics and animation
Computer-aided circuit design
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:
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:
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:
An option for the PDP-12 was an XY point display. This replaced the oscilloscope option that was used in the LINC and LINC-8 systems. There were two models of XY point displays available from DEC: the VR-14 and VR-12. While they appear similar to each other, they are quite different internally. The PDP-12 at LCM+L came with a VR-14, and it was stock. In fact, it was so stock that it had the most common failure: blown power transistors in the X deflection amplifier and a blown main fuse. After studying the schematics in the pdp-12 directory on bitsavers, the power transistors were replaced, pads freshly greased, fuses replaced and the VR-14 came back to life .. for a while.
It seemed to run for 3 months at a time, though it would fail consistently with a blown power transistor in the X deflection. The power transistors are 2N4399 and 2N5302 and are used in pairs. When one fails, it almost always takes out the other. In fact, the DEC documentation states that all power transistors should be replaced as their failure may cause the others to become marginal.
After running the VR-14 (our exhibit for the PDP-12 is the AD-12 interactive ‘Kaleidoscope’) for about a year with some failures we needed to find a way to make the stock VR-14 more reliable. After some searching, we came across a bit of a rare but very interesting 11 page document from 1972 called: “VR14 and VR20 troubleshooting procedures“. The introduction goes a little like this:
When servicing a VR14 or VR20 Display, it is relatively easy to replace a faulty component and obtain a display on the screen. However, this method of maintenance usually fails to eliminate the problem that caused the component failure. Until the cause is found and corrected, fuses and transistors may have to be replaced almost on a weekly basis. The purpose of this document is to provide procedures to determine the cause of a component failure.
This document then goes on to describe 6 ECOs which change a few resistor values, drops the voltage of the main supply and moves the location of the X deflection amplifier to improve cooling. Even after doing all this, you may still run into failures, but our VR-14 ran for over a year without failures.
So we wanted to improve upon this and we determined that the 2N4399 can be replaced with the higher rated 2N5684G and the 2N5302 can be replaced with the higher rated 2N5686G.
The modified G836 board.
There are also ECOs for the two A225 XY deflection flipchips documented in the Troubleshooting Procedures. If you perform these ECOs and also use our suggested power transistors, you’ll make your VR14 much more reliable and enjoyable.