CDC 6500 Memory

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


The SAGA of the DEC VR-14

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.