restoration, software


As anyone familiar with LCM+L knows, the museum initially grew out of Paul Allen’s personal collection of vintage computers. Many of the larger systems in the collection reflected his own experiences with computers beginning in when he was still in high school. Among the systems he used then were System/360 mainframes manufactured by IBM, most of them stodgy batch processing systems with little appeal for a young man who had been exposed to interactive computing on systems from General Electric and Digital Equipment Corporation. There was, however, one member of the family which was different, IBM’s entry into the world of timeshared interactive computing, the System/360 Model 67.

The heart of the difference between the 360/671 and other members of the System/360 family is the operating system, composed of two independent parts. CP-67, the control program, provides timeshared access to all of the system’s features in the form of “virtual machines”; CMS, the Cambridge Monitor System, runs in each user’s own virtual machine and provides the interactive facilities for programming, text editing, and everything else the user might want to accomplish. The combination was known as CP/CMS.2

I came to work for Paul Allen in 2003, to improve and expand his collection and eventually to turn it into a museum. The wish list we developed was large, and of course included several models of the System/360, including and especially the 360/67. The quixotically intense search met with minimal success for years because IBM almost never sold their large computers, instead leasing them to customers so as to control the supply: IBM did not want to compete against their own products for market share. This meant that retired systems rarely made their way into the hands of collectors; they were instead sold overseas, leased to new customers, or scrapped. For a while, the best we could do was the lights panel from the console of a 360/91 from which all circuitry (rich in gold) had been removed.

The first major break came with a story on the Australian Broadcasting Company’s web site about the impending demise of systems owned by the Australian Computer Museum Society.3 My colleague Keith Perez contacted the ACMS and learned that they owned a 360/40, which they were not interested in deaccessioning. This conversation continued for a while, then tapered off until 2011, when Keith encountered an acquaintance of Tony Epton, president of the ACMS, while on a business trip to Sainte-Nazaire, France. The ensuing renewed discussions resulted in another colleague, Ian King, making a side trip to Perth in February before returning from a trip to Adelaide to have a look at an IBM 7090 system.4 Ian visited the barn in which the ACMS was storing two 360/40 systems, and recommended that we purchase one of them. The system arrived in Seattle in September 2011.

Once the 360/40 arrived, we brought in a retired IBM Customer Engineer to assess its prospects for restoration. At this point we learned something important about IBM mainframes of the 1960s and 1970s: No two are exactly alike, and without the system specific Automated Logic Diagrams (ALDs) which document how it was assembled, the chances of restoring one to operating condition are greatly reduced. The former CE also noted the amount of dust caked on the circuitry–the system had been stored in a barn in a desert–which would decrease the likelihood of a successful restoration. He passed on the opportunity to work on the project.

In 2012, we acquired three IBM systems (a 360/20, a 360/44, and a 360/65) from the American Computer Museum5 in Montana, none in working condition: The internal disk drive in the Model 44 had broken loose from its housing and was held in place by a piece of rope, and the internal console cables of the Model 65 had all been cut. The 360/65 was particularly painful: More than a dozen bundles of 50 to 100 identical wires each were made useless. Neither system could be repaired with our facilities.

Bob Barnett, the museum’s business manager, also located a 360/65 in Virginia which belonged to one of the principals at Sine Nomine Associates, David Boyes. David had contacts within IBM who he believed could be helpful in arranging for LCM+L to obtain licenses for the software we wanted to run, and was eager to help us put up a large System/360.6

The 360/20 is a 16-bit minicomputer only marginally related to the main System/360 line. As a stopgap, to be able to say we had a running System/360, the one we acquired from the American Computer Museum was restored to running condition by an enthusiastic pair of contractors, Glen Hermmannsfeldt and Craig Arno, with help from Keith Hayes and Josh Dersch of LCM+L; it was displayed in the Computer Room from 2015 to 2017, initially while the restoration work was done and then as an example of a small batch system. As is often done for vintage systems at LCM+L, virtual peripherals–a card reader and punch–were created for the 360/20.

By 2015, the desire for an IBM system capable of providing a timesharing experience led to the acquisition of a 4341 system7 from Paul Pierce of Portland, Oregon.8 By this time, we had established an ongoing dialogue with the team who had successfully restored an IBM 1401 at the Computer History Museum (CHM) in California. One of the members of the team introduced us to Fundamental Software Inc.9 Faced with the task of restoring 40-year-old tape and disk drives, or creating our own emulations, we decided that we would instead acquire an FSI FLEX-CUB to provide disks, tapes, and terminal services to the 4341.

Jeff Kaylin was given the task of making the 4341 CPU run. Beginning in July 2015, he spent seven months getting the power system into working condition; first power up was on 12 February 2016.

Once the system was working to this extent, we ordered a FLEX-CUB from FSI and began attaching 3278 terminals to the built-in controller for testing. Also at this time, David Boyes informed us that he had arranged licensing for the VM/SP HPO operating system for us.

The FLEX-CUB arrived at LCM+L on 1 June 2016, with a minimal VM/370 installation in place courtesy of our friends at FSI. After some phone consultations with FSI Support, we were able to IPL10 the system into VM/370. Three weeks of getting additional terminals configured followed, with discussions of the OS configuration between FSI and me, replacements of capacitors and CRTs in terminals, and so on. Progress halted on 20 June, when Jeff arrived on a Monday morning to find the system halted with the words CHECK STOP and an error code on the console.

We obtained an 8in diskette with diagnostics from FSI. Memory tests showed that the memory was working; swapping of boards with spares commenced. The power sequence was a suspect for a long time. Jeff began making schematics for the various boards in order to understand where faults might occur that matched the diagnostic callouts. For two months, Jeff wrestled with the system with no progress.

Our consultant from CHM advised Cynde Moya, our Collections Manager, of the existence of 4341 and 4361 systems housed in a warehouse in Sacramento, California. I spoke with the owner, Daniel de Long, and learned that he had a working 4361 plus spares in the form of another 4361 and two 4331s. I traveled to Sacramento a week later to have a look, seeing the 4361 IPLed and running under DOS/VSE.11 After some discussion, the 4361 equipment began arriving at LCM+L on 2 November 2016.

In December 2016, Jeff began pulling the power supplies out of the 4361, to check the capacitors. All were within tolerance, but since 2004 our policy has always been to replace all aluminum electrolytic capacitors in any device we restore.12 The new capacitors were installed and the power supplies replaced in the chassis in the remaining weeks of 2016.

In mid-January 2017, the newly refurbished 4361 replaced the 4341 in the Computer Room. FSI, who have been very helpful throughout the project, advised us on how to cable the FLEX-CUB to the new system. A different power outlet was installed to accommodate the different plug on the 4361.

When the power button was pushed, the built-in floppy drives’ motor spun, but stopped as soon as the button was released. Jeff tried attaching the operator console, with no change in behavior. A phone call to Dan de Long revealed that the system was wired for 230V rather than 208V, necessitating either a change in the room wiring or a reconfiguration of the system’s power supplies; the latter was a simple matter of changing jumpers on four transformers to provide single-phase 208V, after which the system powered up and stayed up.

Power issues continued to plague Jeff. The first supply in the system would come up, with its test point providing 1.5V as expected, and all the proper voltages supplied; the second and thrid supplies showed no voltages. Going through the ALDs allowed him to trace through all four supplies with no luck in determining the problem.

After a couple of weeks, I suggested that Jeff contact Dan again, who pointed out that the system requires that a printer be attached in order to complete the power sequence. We ordered capacitors for the printer, and had additional outlets installed under the raised floor. The printer was ready to go a month later, after degraded old foam insulation was replaced along with the power supply rebuild.13

With the printer installed, the system would now power up, but the printer would not stay powered on. A long correspondence, with pictures, commenced between Jeff and Dan. This went on from mid-March to mid-May, when a suggestion to swap the cables on the floppy disk drives led to the replacement of one drive. The system would now perform an Initial Microcode Load (“IML”), after which it suggested running the Problem Finder diagnostic tool. Progress! A few more days of fiddling about (bad breakers in the power supplies, etc.) led to the indicator lights on the console keyboard signalling “Power Complete”.

Jeff cabled the FLEX-CUB to the 4361, and changed some system settings on the console to allow it to run VM/370 instead of DOS/VSE. I sent the FLEX-CUB configuration which had been set up for the 4341 to Fundamental Software; they sent one back which had the proper incantations for the 4361 instead and installed it for us remotely.

After I checked over Jeff’s revised settings on the console, we tried to IPL the system, which could not find the configured IPL device. The Problem Finder tool likewise did not find it. I reviewed the FLEX-CUB configuration, and did not find anything problematic there, so stopped for the evening, asked Jeff to locate the Operating Procedures manual for the 4361, and sent pictures to FSI of the console screen showing the Unit Control Words (UCWs) defined for the devices attached to the system. The next day, I got back suggestions for updated UCWs and updated the settings on the console while Jeff moved the channel cables to their new places. Although the system still did not come up, it did report channel status on the console so we knew the system was alive.

The next day, I revised the UCWs again on advice from FSI, to change the controllers on all disks and tapes to 3880s. Several attempts to IPL the system were unsuccessful, but in the mean time we attached more 3278/3279 terminals and got the correct keyboards on them. A day later, after telling the system that the 3279-2A display was a 1052 Selectric-style printing terminal with no printer attached and another IPL, we were prompted for date and time; FSI advised issuing the command CP ENABLE ALL to make the attached terminals live in the system. FSI did little more configuration on the FLEX-CUB, and they and I were able to log on to the MAINT account! That was the end of May, 2017.

Now my task of installing a full operating system began. Several weeks of reading manuals ensued, along with the installation of the Hercules emulator14 on a Windows desktop and on a Linux server. By the end of June, 2017, I had the public domain VM/370 running on both, a task made simpler due in equal parts to the existence of turnkey installations and an active Hercules community.15 In particular, the members of the Hercules-VM group have been very helpful over the last year, offering suggestions, advice, software, and general excitement for our project.

I reached out to David Boyes to ask that he put us in touch with his IBM contact for licensing VM/SP, the preferred version of VM/CMS for our hardware. David wrote back to me that his contact was no longer at IBM, but that he would try to find us the proper person to talk to; he also told me that the tapes he had preserved had been shipped off to CHM a while back, and that he was asking that images be made. A week later, I had the name of IBM’s Product Manager for z/VM and Related Products,16 George Madl, and sent him a message outlining LCM+L’s mission and place of the 4361 and VM/SP in the museum’s offerings. He forwarded the request to Glenda Ford in IBM’s licensing department. Glenda shepherded the request through IBM’s processes for four months and by mid-November had worked out a very favorable license with reasonable restrictions (no support, no commercial use of the system, no fees).

While waiting for an answer to the license question, I moved on with planning for VM/SP, starting with a review of the differences between VM/370 and VM/SP installation. As the weeks went by, I proposed a backup plan in which we would begin by installing VM/370, and upgrade to VM/SP when the licensing came through. This took us to the end of 2017.

In January 2018, with help from FSI, I configured eight 3350 disk drives on the 4361. As we worked together to finalize the new setup, they set up a production VM/370 system on three drives, along with an emulated card reader and punch and an emulated printer. (We even uncovered a bug in the FLEX-CUB software, so the benefit was not all in one direction!) I set up guest accounts for two users who had been asking since the 4341 restoration began, and collected their impressions.

For further planning, I returned to the Hercules emulator, looking at access to language processors and other utilities. I planned to provision our new VM/370 from the prebuilt Hercules disk images, so had to learn the ins and outs of DDR (the DASD Dump/Restore program).17 I added three more 3350 disks to the system, in order to hold the desired contents from the Hercules ready-built VM/370 system. I had to remember to re-IPL the system in order to make the new drives available; the 1970s had no concept of “plug-and-play” peripherals.

It became clear that the integration of the Hercules “6-pack” (made up of six 3350 disk images) was very tight, and the simplest way forward might be to install these images onto our FLEX-CUB disks via DDR. I consulted with the H390-VM mailing list, who concurred in that idea. However, at this point two people came forward with offers of assistance.

One of the architects of the Hercules “6-pack VM” system had available the installation tapes for VM/SP Release 5, which was our original target for the 4361. He provided us with images of the tapes and images of 3350 disks onto which the installation files had been placed, and gave us a hand from the UK in getting things set up under Hercules.

The other is Drew Derbyshire, one of the VM/370 beta testers. Drew is a contract programmer with 10 years’ experience in the VM/CMS world, including a long stint working on the CP nucleus for IBM. He is also local to Seattle, and a member of LCM+L, so was well placed to help us move forward with the installation and configuration of VM/SP for our particular purpose.

On 1 March 2018, I was able to IPL the 4361 under VM/SP, having copied the installation disk images over to the FLEX-CUB with help from FSI and our helpers. These were still 3350s, so I created sixteen new 3380-K disk images on the FLEX-CUB, a total of just under 20GB of storage space,18 as the first step in making the system available to the public by 1 April.

At this point Drew, as a contractor, and I began a fruitful working relationship, trading configuration notes, ideas for further work, and so on. Drew set up a Hercules mimic of the 4361’s exact configuration in order to experiment when the museum was not open. This was helpful when the 4361’s disks were clobbered due to errors in configurations, and Drew did the artwork for the VM/SP splash page on display terminals connecting to the system.

Over the next 10 weeks, Drew and I built CP nucleuses19 with different parameter settings, different numbers of terminals defined, 3380 disks instead of 3350, and so on. In mid-May, the 4361 had a machine check, which Jeff and I traced down over the next week to a memory issue.20 Jeff pulled memory modules from the 4341 to replace those called out by the IBM diagnostics; I began backing up all the disks to tapes, taking the system down every night and bringing it up the next morning.

The interruption was annoying because the developer/maintainer of the Stanford Pascal Compiler was installing his program on the system when the memory fault occurred. Once that was repaired, Drew and he completed testing of the installation and declared it good.

I booted the 4361 on Friday evening, 18 May 2018, for a test run over the weekend. Drew accidentally crashed it from a remote location on Saturday morning, but brought it back up during open hours at LCM+L. The system ran for a week without incident, so I posted an invitation to the H390-VM list for anyone interested to apply for a beta account. This was as much to test the account management software Drew had written as to shine a light on any blind spots we had with regard to software for the casual user.

Since 1 June 2018, Drew has installed the PL/I Optimizing Compiler, Fortran/VS, and other pieces of software to make the system more hospitable. In addition, one of the beta test users installed a version of the IND$FILE file transfer program by cutting and pasting a hexadecimal dump of the binary program into his directory, then let us know about it to install for general use. Drew has made great use of it to make updates from his Hercules testbed to the running 4361.

Future possibilities include installing RSCS and NJE, the remote-job entry subsystem for VM, to create a BITNET-style network site,21 and creating subsidiary virtual machines running other interactive operating systems such as the Michigan Terminal System or the McGill University MUSIC timesharing system, so stay tuned for further developments!


The DEC 340 Monitor, Ship It

Playing Spacewars.

Spacewars on a 30E Monitor

My last article explained that the DEC 340 Monitor pointed at and shot dots from an electron gun to light up spots on its screen. That was my magic chant, the method of how the DEC 340 drew its pictures as a collection of dots.

Every picture a DEC 340 ever showed was made of dots flashed onto its radar tube by the tube electron gun. Reproducing the technology that poked those dots onto the tube is what I do now. It is a fascinating puzzle to solve, even inspiring,

     Now is the winter of my discontent
     Made glorious summer by this DEC of 340;
     And all distracting clouds that lowered upon my dome
     Into the deep sea must be buried.

Or else I won’t get it done.  I don’t have full documentation and parts are missing.  It is a puzzle I don’t have all the pieces for; the challenge of coming up with missing puzzle pieces and getting them to work and fit together, inspires me, but that’s not enough. It must consume me with passion! A hero’s journey has begun and heroes can’t be distracted. There is no time for it.  The devil is in the details and there are a lot of details in this project.  Trying to keep track of all of them is challenging so I make it fun.  This blog series will catch up to the actual work of that challenge later but for now I need to describe the scenery a bit more.  I hope a transistor will appear in my next installment but I have to set the background for them or they aren’t very interesting characters.  They can be captivating entertainers but you have to get them in the right venue or they won’t amuse.  More background is needed.

Designing the original DEC 340 may have been an easier job then mine.  Don’t think that is a complaint, it is only an observation.  The DEC 340 circuits were already in use in a preceding DEC monitor, a monitor that DEC designers had full documentation for.  This was a monitor they could touch and turn on.  The designers had drawings and net-lists which described how all the plug in System Design Modules were interconnected to create the monitor.  The most useful document I have, is this one.

Many thanks to a reader who upon reading the first article of my series supplied this link.  The copy I had must have been a copy of a copy of a copy and was relatively illegible.  This one is crisp and clean.  Many thanks.

The document is a maintenance manual intended for limited distribution.  It has a lot of good information but it is not an engineering file that would have everything I need to know to reconstruct a DEC 340.  It contains documents which give a good understanding of how the DEC 340 works.  It is detailed enough to perform maintenance on the machine.  It’s my Rosetta Stone.   I’m using it to translate old to new, after enough pondering and understanding.

Rosetta Stone

DEC engineers had all the bright and shiny System Design Modules that they needed, building blocks from which the DEC 340 is made.  The DEC 340 was an evolutionary design which evolved from the DEC 30E, an earlier DEC monitor. The original 340 design did not start from scratch. The designers had a working monitor and a clear goal.  I have a DEC 30E manual similar to the DEC 340 manual.  It has information that describes some of the missing chips off my stone.

The goal seems to have been to improve DEC 30E performance. Other considerations may have motivated a new design, but circuitry differences tell me that performance enhancement was the big goal.

The 340 was built on top of the 30E design.  The DEC 340 has additional circuitry the 30E did not have but all the tube driving circuits the DEC 30E had were found inside a DEC 340.  A 30E is shown at the top of this article playing Spacewars. The DEC 30E used the same tube as the DEC 340 and a 30E manual was good to find.  It documents the tube neck circuitry better than the 340 manual does.

It may be that designing the 340 was an easier job because the 30E monitor already existed but I’ll guess the original 340 designers were also told something like, ‘you’ll have it done by next Tuesday right’? That not actually being a question. A complication of course, which at the end of the day would make their job a lot harder than mine. Especially if tomorrow were already Tuesday.

The 30E used the DEC point and shoot method of drawing dots on its screen like the DEC 340 and later DEC monitors did, but the 30E could not show as many dots on a screen as a 340. The DEC 340 uses tricks to get more dots on its screen.  Displaying Spacewars makes for a great photo, but I don’t see a star field of dots as much of a performance test.  I’d like to see how it did at rendering a few sentences.  I suspect a few sentences would push 30E hardware to it’s limit.  Magnetic deflection of Cathode Ray Tube beams is band limited.  Band limited means the yoke magnetic field can’t be changed as fast we need it to be, to steer a pointed-at spot around as fast as we want.  Spending a few moments considering how many dots are in a picture made up of all dots, and how much time is allowed to draw them all to prevent screen flicker, shows how fast an ideal DEC 340 tube yoke needs to be.

In a DEC 340, a square in the center of the CRT is used for display. It is a little less than 10 inches on a side, and each point in the square has a unique ten bit X and Y address. Ten bit addressing allows for 1024 X  and 1024 Y values.  Spots outside this center screen square can’t be pointed at.

If only one fiftieth of a second is allowed before a screen must be redrawn or it flickers, an all white screen needs to point and shoot at more than fifty million dots in a second, because there are over a million dots in an all white screen.  This allows for less than twenty nanoseconds of time to draw a dot. Point and shoot magnetic deflection can’t keep up so an all white screen on a DEC 340,  that does not flicker, is impossible. But a whiter screen than that which can be drawn on a DEC 30E is possible with a DEC 340.  Improvements were made.

In the computer room at the Living Computer Museum, in Seattle Washington, there is a CDC 6500 with a working DD 60 display attached. The tubes in that display use electrostatic deflection, which does not have the inherent bandwidth problem that magnetic deflection has. The DD 60 displays are also large pieces of furniture. A tube which uses electrostatic deflection has to be about three times longer than it is wide or the electron beam will only make a small square in the center of its screen.  An electron beam has only a very brief time in which to be deflected as it passes between two electrically charged deflection plates, the resulting deflection angle is limited.

A vintage monitor made by Hewlett Packard, the HP 1300, got around the geometry problem by a special (and patented) innovation, a special grid inside its CRT which enlarges a picture on the screen. The Living Computer Museum has a DEC PDP computer with a working HP1300 attached. It is a custom implementation used at the University of Oregon as a research device for many years. The HP1300 was a monitor, but it was not a computer monitor. The HP1300 requires external X and Y voltages with a gate signal to move the beam around and to turn it on and off. The CRTs in HP1300s look like old TV tubes, wider than they are tall, but internally they are more like oscilloscope tubes with electrostatic deflection plates. To me, they have a one of a kind special delight because of the innovation.

Electrostatic deflection, for whatever reason, was not an option for DEC, so the best that could be done with magnetic deflection was attempted. The goal was to make something useful. Thinking of a computer monitor as a device to represent photo images, and not as something that only outputs useful data at the time, was a figment of somebody’s imagination. Probably more than one somebody had the same figment, but practically it was for the time, a wild dream. Digital images could not be read from a sea of cheap memory as they are today. At the time the DEC 340 was made, everything in an image was programmed.  There were no digital cameras. Computer monitors were a different animal and people thought of them totally differently than they do today.  Drawing a line took time, Drawing two lines took more time.  Not everything in a picture had the same ‘cost’ but all modern computer monitor pictures do have the same ‘cost’, a cost that modern hardware has no problem keeping up with.  The time it takes to read a image from memory.  Things were different in the days of tube monitors like the DEC 340.

A DEC 30E takes thirty five microseconds to set X and Y magnetic fields to point to a spot on the screen. With 1048576 points in a square, that is more than 1000 times slower than we need to light up every point in a display screen square sans any flicker. I guessed at fifty refreshes a second, but that is a reasonable guess. Improvement in response time is obviously desirable, and a 1000 to 1 ratio is a lot of room for improvement. Is the picture as bleak as it could be? The answer to that question, it turns out, is no.

A DEC computer at the time, would need several microseconds to set X and Y values of a point. Several microseconds is not a lot different than the 35 microseconds it takes for a 30E magnetic field to settle on a pointed-at value.  Certainly a lot less than a 1000 to 1 ratio.  Not much 30E speed improvement is needed before a DEC computer that a DEC 30E attached to limits performance not the 30E monitor.  This is similar to the weakest link in a chain being the link that defines how strong a chain is.  Magnetic deflection would not be the limiting factor once the 30E could be made to outperform a DEC PDP computer. The DEC 340 attempted to implement that improvement. Two different things were done to get more spots on the screen.

The response time to settle the magnetic field between adjacent points was reduced by blending an open loop response with a closed loop response. That’s engineering talk most of you won’t have a clue about understanding and I’ll let that be my concentration the next time I write an article installment. The 30E was an entirely closed loop device. I’ll let that be my first sentence for the next installment. I’ll go from there.

The second thing that was done was to make the interface between the DEC 340 and a host computer more elaborate so entire lines could be easily described.  A program that draws lines and dots is going to obviously be shorter than one that draws just dots.  The DEC 340 takes line segments and calculates point positions on these lines by itself, to draw the lines as points. The DEC 340 is a programmable device able to take some of the burden of ‘vector’ programming away from the host computer it’s attached to. The DEC 340 could be set in different modes to ease information transfer between its host computer and free up CPU clock cycles.  Description of these modes will wait for a future day because that has to do with device logic, for now I’m concentrating on the electronics that drive the CRT.

Once DEC marketing saw something describing improved performance,  I’ll guess pressure to ‘ship it‘ inside the DEC eco-sphere must have been intense.  Getting into the details of the electronic circuits that produce that magnetic deflection speedup, I’ll do in my next installment.


The DEC 340 Monitor, Magic Chant

Previously I introduced my DEC 340 monitor restoration project.  I promised then to describe how the DEC 340 monitor worked.

I will, but that explanation won’t mean much without some context first.  After the context the special magic that makes the DEC 340 different from other computer monitors will be revealed.

High definition images are ubiquitous now and a comfortable magic hides the mystery and complexity of what it takes to show a picture on a computer screen to us.  High definition images are everywhere and they use a refined magic that took a century to evolve.  The story began in 1869 with the Crookes tube.

Crookes Tube (High Definition Computer Image)

The DEC 340 monitor story is part of the story of this magic.  The technology used in the DEC 340, a few steps back from what we now have, had limitations unknown today.  My personal fascination with the DEC 340 is about what was done to overcome these limitations.

Today’s flat panels depend on high speed digital electronic circuits which did not exist when the DEC 340 was built.  These circuits would later become the technical background of modern computing as we know it and without them computers as we know them could not exist.

Cheap memory, being able to hold a supercomputer in the palm of your hand, the ability to process images in real time, and the ability to make flat panel monitors with high definition images all resulted from the revolutionary technical innovation of packages of small high speed digital electronic circuits.

Today’s world has the technology to give us realistic images but in the world the the DEC 340 comes from nothing much better could be done.  The DEC 340 used discrete components, the only available.  A cell phone today made from similar discrete components would be as big as a car and would cost more.  It also would not work.

Size and the speed of light would prevent its circuits from operating fast enough to do the jobs they need to do.  In electronics where speed is important, size matters and smaller is better for high speed.

Two components in the DEC 340 are huge.  The radar tube and a magnetic yoke around the radar tube neck that steers an electron beam around to paint a picture can’t be made smaller.  The size of the magnetic yoke limits the complexity of an image which can be drawn.  Yokes have a property called inductance which I will describe, and inductance goes up with size.  Inductance slows things down.  This will be important later.

I look at the DEC 340 circuits.  They are fascinating just the way they look but the more I study them the more interesting they get.  Component colors on the parts don’t get brighter, the metal shinier, or anything like that, but my appreciation for these circuits grows with time.  The circuits are not sloppy.  Lots of effort went into their design and they pushed the limits of what could be done with bipolar transistor technology, then, and even now. These circuits had to do as much as they could in a very short period of time.  They were designed to push the limit of what can be done.

Between today’s flat panels and the DEC 340, computer monitors of a different kind existed.  These monitors were raster scan devices.  They used Cathode Ray Tubes CRTs like the DEC 340 did but these tubes were like old TV tubes and worked the same basic way.  Internal storage of pictures in computer memory files even today reflects a raster-like form.  Information off picture files once had to be read sequentially to form lines for these raster scan monitors.  The information was stored in a way that directly supported raster-scan formats.  Raster scan monitors are a link between monitors like the DEC 340 and the computer monitors we have today.

Raster Scanner

Raster scan monitors would be the backbone of computer displays for many years and television did exist when the DEC 340 was built.  But to use a television display with a computer needs cheap memory which had not yet been invented.  Raster scanning was not a viable option for computers in the early 1960’s.  Memory cost too much.

A bit is needed for every spot on the screen in a raster scan device.  The DEC 340 screen would need to store 1024 bits for each horizontal line and there would be 1024 lines to read out in every scan.  That would be 1048576 bits total.  A trivial amount of memory today, but that is more memory than a PDP 7 even shipped with.  PDP 7s only had 73728 bits or 4 K words on delivery.  It could be expanded but only to 64 K words.

TV of the era was an all analog process and involved no digital storage at all.  A TV camera recorded an image by tracing a raster on a camera screen and a receiver reproduced this camera generated raster on its screen in real time by duplicating the intensity variations produced at the camera.

Video tape storage was possible but this only recorded an analog copy of an image and practically was only the same as a real time analog signal but delayed.  A TV receiver could not tell the difference between the two.  Digital manipulation of a raster image could not be done until enough memory was available to store an entire screen of image data so it could be later read out.  It would take a few years before technology could catch up and provide enough cheap memory to store data for an analog video signal.

Cathode Ray Tube monitors be they raster scan devices or devices like the DEC 340 have an electron gun that shoots a very thin beam of electrons down the center of the tube so that a spot in the center of the screen glows if the beam is on.  Without a magnetic deflection yoke this spot would stay in the center of the screen and could not move.  That is not very interesting, but for me it will be a very satisfying thing to see when I get that far.

A magnetic yoke is needed to deflect the electron beam to other places on the CRT screen.  This magnetic deflection yoke moves the spot lit up on the screen around by current variations that change the magnetic field around the tube.

Current changes can’t be made infinitely fast because the yoke has the property of inductance which I mentioned earlier and inductance tries to keep yoke currents from changing.  Inductance is like momentum which tries to keep you going forward when you try and stop running.  Inductance wants to keep current flowing like momentum wants to keep motion going.

A CRT picture is made by moving the spot on the screen that is lit up around so fast its motion is invisible.  The entire traced path looks lit up all at once.  Turning the electron beam on and off while the spot scans turns the illuminated spot on and off.  These methods mixed together allow an image to be drawn on a CRT screen.

Inductance in the magnetic yoke limits how fast yoke current can change and the whole picture has to be redrawn as soon as the whole picture is finished being drawn or it blinks out.  The limit on how fast the spot can move limits the complexity of any picture that can be shown.  A raster scan covers the entire screen and breaks it up into horizontal lines.  Inductance limits the number of lines that can be drawn but a useful number in a raster is achievable.

Raster Scan

A Raster Scan

All the electronics has to do in a raster scan monitor is reproduce the raster and turn the beam on where the picture to be shown overlays the raster.  Picking a raster that electronic circuits can support easily can be a judicious choice making electronic design of a raster scan monitor a well defined problem.  The raster is a repetitive pattern the yoke currents simply retrace over and over.  This is different and simpler than what the DEC 340 does.  The pattern traced depends on the picture in a DEC 340.  The more complicated the picture the more complicated a pattern that draws it must be.

Only a short period of time is available to draw a picture.  A spot lit up by the CRT electron beam will go dark quickly once the electron beam is removed.  For a picture to remain visible it must be continually redrawn.  With only a short time to draw a picture before it has to be redrawn or the screen flickers, and with the complexity of a traced pattern dependent on picture content, DEC 340 electronics had to be made as fast as possible.  Unlike a raster scan where good enough electronics is just fine.

Unlike a raster device, positioning the electron beam is done by computer code running a computer program with instructions to control the DEC 340 in an attached computer.  The decision to refresh the screen is also made by program code.  The alternative to a raster scan is called a random or vector scan because a vector monitor can draw an arbitrary line or ‘vector’ of any length in any direction starting from any point on the screen. Enough such lines when displayed together make a picture.  When memory is an issue a vector representation of a picture will generally save space.  Location direction and length will define a line.  In the picture below only information for five lines is needed.  The arrows are only showing movement and are not displayed.  Saving this picture in vector form will save a lot of memory over a raster equivalent.

A Vector Scan

The DEC 340 interestingly is neither a vector device nor a raster scan device though it is very much like a vector monitor.  The DEC 340 points to a spot on the screen.  The electron gun is fired for half a microsecond or half a millionth of a second after the magnetic yoke field stops changing when a point on the screen is pointed at.  The magnet field currents are then set to point to a new place and another dot on the screen is lit up for half a microsecond.

Enough such dots displayed together make a picture.  Different modes can be set in the DEC 340 to make writing to the screen easier.  Two different ‘vector’ modes allow a vector to be specified which is then rendered automatically by the 340 as a series of inter- connected dots to make a line.  The distinction is that in the DEC 340 only dots are created to make a picture.  Yoke currents never change when a spot is being lit up.

A DEC 340 ‘dot’ program with more complexity than an equivalent raster picture is not hard to imagine since a raster scan never crosses itself in a scan.  Circuits in the DEC 340 however get pushed to their limit because the path between dots can easily cross over and over again.  The dots can be selected in any order so different paths of different complexity could render the same picture.

This time I’ve presented a basic description of how the DEC 340 works.  It is quite a bit different than computer monitors which came later but its design was the best that could be done at that time for any reasonable cost.  It was a good design for the technology of the day.  Next time I’ll be getting into some details of the design enhancements made to increase the speed at which DEC 340 ‘dots’ can be drawn.  Remembering that the more dots we can draw in a given time the more complex a 340 display image can be.  I’ll be comparing the DEC 340 monitor with an earlier DEC monitor, the DEC 30E.


restoration 11 comments on The DEC 340 Monitor, The Introduction

The DEC 340 Monitor, The Introduction

My big project this year is to get a DEC 340 monitor working. Here is a picture of one of them.

The DEC 340 was a very early and rare computer monitor dating from the mid 60’s used of course, on DEC computers, their PDP series. Two cabinets of rack mounted electronics.  The 340 is historic and was used in some early work that pioneered modern computer graphic techniques.  It is quite a bit different from Cathode Ray Tube (CRT) monitors used by personal computers we were all familiar with a few years ago.  In comparison it is alien technology.  All circuits are implemented using discrete components and there are no integrated circuits anywhere in the design.  The discrete components themselves are unusual dating from the early days of transistor use.

The DEC 340 I have to work on is missing the cabinet on the right.  It seems to have been lost in the sands of time.  The cabinet with the big tube on the left is the one we have.  It is covered inside and out by a thin layer of rouge desert dust.  A peek inside the cabinet and the dust suggests our DEC 340 could have crashed onto the desert outside Roswell, New Mexico as part of a flying saucer or come from the surface of Mars as alien technology.  My peek inside had looked strange, alien.  It took me a few moments to understand what I had seen.  Then I had an a-ha moment.  I realized this is how DEC computer engineers of the time did analog electronics.  Everything is packaged the same way discrete digital circuits of the day were, as digital circuits of the time had to be connected together because of their complexity and size.  Circuit cards of components in racks of connectors connected to back-planes carried buses of signals in digital circuits but analog signals may not like the same kind of connections as digital connections do.  They may require different considerations.  I’m not used to seeing analog signals jumping from place to place as if electronic noise did not matter.

I can’t be critical because DEC 340 analog electronics obviously worked, but path length is usually kept short when making analog connections.  This keeps noise pick up to a minimum and signals clean.  I was surprised by what I saw in the 340 but DEC did not make radios or TVs.  DEC built computers and I figure their engineers had to do things a certain way.  Maybe even if they knew better.  The layout which to me looks odd must have made somebody happy.  Having all the electronics which connect to the CRT at least be in the same cabinet seems to have been the only concession made to analog design considerations but since it worked that’s OK.  Scrounging for documentation I found that DEC had used the same CRT in other monitors and essentially the same drive electronics on the tube itself, so whatever problems they had only needed to be solved once.  That was a good discovery,  some of that documentation helps me out.

Our 340 is incomplete with parts missing and actually came from a junkyard in Australia where it had been sitting outside for a while.  Arid conditions somewhat preserved this DEC 340 but sadly it is incomplete.  Our 340 is a carcass of missing pieces and this incompleteness enhances the feeling it is something from another world.  Original components to build up missing circuit boards and for repair of  circuits we have can not all be found.  Old components are often not made of the materials modern components are and sometimes they do not age well.  Arid also does not mean it is always dry.

We have the magnetic deflection yoke and tube.  Essential parts which I can’t re-manufacture.

The Sixteen Inch Radar Tube

But an entire cabinet of components is missing.  Racks of digital circuit cards which made the DEC 340 a processing device all on its own.  Circuits which offloaded details of drawing from the host computer to which it was attached to lighten the host processing load.  For these circuits we have only paper documentation.  Output from the missing circuits drove circuits which controlled a big round sixteen inch radar CRT around which the DEC 340 was built.  These circuits I have because they are analog circuits that were mounted close to the display CRT to minimize electrical interference.  These circuits were in the same cabinet as the CRT; the only cabinet we have.  Within the cabinet the analog circuits were implemented using Digital Equipment System Building Block technology where space allowed.

System Building Blocks, are circuit boards mounting discrete components with a heavy duty 22 pin gold plated connector on one end to create a ‘block’ that can be used to build a ‘system’.  The three sides without the connector are wrapped by an aluminum band.  System Building Blocks plugged into a rack mount which could hold up to 25 blocks.  Twenty five side by side connectors were interconnected on each rack mount to create a back-plane which resembled the way typical computer circuits of the day were implemented.  That resemblance aside, System Building Blocks implemented both analog and digital circuits in implementations which today would be called ‘mixed signal’.  Here is one of our modules with dust gently brushed off and blown away by compressed air.

A 1575 System Building Block

The transistors and diodes used in these circuits became obsolete long ago. Some were made of germanium which was only used as a semiconductor material in the early years of semiconductor electronics. Silicon is used almost exclusively as a semiconductor now. Silicon is a superior semiconductor for common uses, but in the early days of transistors.  Germanium was a semiconductor of choice. Techniques for working with silicon had yet to be perfected.  I can get vintage germanium parts but they are expensive and hard to find.  The numbers on the silicon transistors used I have not seen before.  The vacuum tube era had just come to an end when the DEC 340 was built. Transistors were new and the ones used in the DEC 340 became quickly obsolete and are uncommon.

I would have to pay a lot for replacements, those I could find. There are vendors who specialize in old parts. They don’t have everything.  I would have a great deal of problems replacing components with original parts or parts with even similar specifications.  Diodes this old when put on a curve tracer can sometimes look more like a resistor than a diode.  Gray corrosion coats component leads.  I am concerned about the diodes and transistors which have leads that were not gold plated.  The hermetic seal on some of those components is sure to have failed.  The plating on the steel rack which holds the circuit cards shows spots of corrosion documenting that condensation has visited the components.

I only have one rack of circuit cards that contain System Building Block cards like that shown above. These circuits control to the CRT.  All of the other electronics are missing.  An entire cabinet full of card racks. All the signals to the cards I do have came from this second cabinet of cards that I only have paper documentation for.  A second rack mounted below the first was cooled by forced air and is show here.  The components on this rack are part of System Building Block schematics with components too big and which ran too hot to be mounted onto System Building Block circuit cards in a rack that takes thin plug in cards mounted side by side.  Shown here are these two rack mounts removed from the cabinet they came in.  A patch panel which jumped wires to the CRT from these racks is also shown.  It was mounted in space inside the cabinet behind the racks and holds components on the other side.

The Electronic Carcass (removed from rack)

So what to do? My first decision upon reviewing the documentation and physical parts I had was to decide to reproduce the electronic circuits using modern components on new circuit cards. I might enjoy getting the original electronic circuits working but it is too risky and I do not have them all to begin with. I look at the glass diodes on the circuit cards and cringe. I don’t trust any of them. They have experienced morning dew and have corroded. We already know that the glass seal on old diodes can fail with time and a desert is not needed for that. Even if the diodes work I’d not trust them to keep working for long.  Working on stuff knowing replacements are not available is scary. I would not want to plug in a one of a kind circuit and see smoke.  I also know that the traces on circuit boards this old lift very easy so it is easy to damage these circuit boards when changing components.  Even a little heat can turn circuit boards this old brown and lift traces.

Reproducing the function of all the original circuits seems my best path. I located schematics for all the circuits so I can understand how they work and work together. My goal is to get the big radar tube working as it once did. Accomplishing that task using modern components based on original schematics will be fine and if something burns up I can replace it. Had the whole 340 made it to the desert to be found I might have decided to get the old circuits working and scramble for parts but with half our 340 missing, building all the electronics from scratch seems the best way to go for my best chance of success.  That the DEC System Building Blocks were made using a proprietary connector has no small influence on my decision.  I can create work alike versions using printed circuit cards which plug into easily obtained edge connectors but mixing and matching that arrangement just to accommodate the few System Building Blocks I do have makes no sense at all.  It will be far easier to rebuild everything around a common connector that I can get than to rebuild the back plane using half new and half old parts which are actually incompatible in physical size to begin with.

Another consideration is the issue of interface.  The original System Building Block circuits interfaced to DEC equipment logic levels which range from ground to a negative voltage.  We will be implementing the DEC 340 logic functions using modern technology which uses logic of a positive voltage, so I need equivalent System Building Blocks which interface to positive voltage.  None exist, the only way I am going to get those is if I make them.  A level of voltage translation circuitry between existing cards might cause timing problems best avoided.  Another reason not to use the cards I have but to make work alike copies is the extra work of translating voltages cancels out the cost and work of reproducing circuits with voltage translation built in.  As will be explained in basic operation, for its time, the DEC 340 was a high performance device and I must pay close attention to timing requirements.

Will it really be a DEC 340? Yes it will. The tube will be original or an original replacement (I found one at a surplus store) and the deflection coil, which drove the tube, will be original as there are no replacements for that anywhere to be found. Function of the original DEC 340 will be achieved in a work alike reproduction driving an original tube.  The electronics will reproduce the function of the original and if parts fail, replacements will be available.

This article introduces my big project for the year but I have been working on it for a while.  I have been creating schematics of the circuits I need and have been planning how it all goes together.  I have been buying parts I know I will use.  My original plan with this blog post was to write about the circuit on the 1575 System Building Block I show above.    It is a fascinating and interesting circuit that I had to understand in great detail to implement right.  I can base my circuits on original circuit topology and honor the basic method and forms but using new components with characteristics that don’t match exactly means I have to check that all the math works out right.  This changes the values on some resistors and capacitors, so components are biased correctly.  I simulate the circuits in a circuit analysis program so they have the best chance of working without needing later adjustments after I build them.

I could not write about the 1575 System Building Block circuit without introducing my project.  I still need to describe the basic operation of the DEC 340 before discussing the operation and function of the 1575 circuit.  Understanding a circuit is a lot more fun if you know what it is used for.  I find it can make the difference between being fascinating and boring, though the 1575 circuit is fascinating on its own.  In my next blog post I’ll describe basic operation of the DEC 340.  Eventually I will explain what Q4 and Q5  do in the 1575 circuit.  They are in the center of the below schematic.

1575 System Building Block Schematic

In the original circuit they are germanium transistors in a place where germanium seems to actually be a better circuit choice as will be explained.  It is an unusual circuit I have only seen a few times in my life and the way it works is subtle.  It is used to switch a voltage under very specific requirements.  It is fascinating because it seems to work better than it should and some thought on transistor physics is needed to understand why. I will be implementing two missing DEC 340 Digital to Analog converters and a 1575 type circuit takes the voltages produced by these D to A converters to feed downstream amplifiers.  But first I’ll describe the basic operation of the DEC 340 and how it differs from the later computer monitors which became the mainstream standard for many years.



Testing old technology

I have 4500 modules in the CDC 6500, and it isn’t always easy to debug them in the machine, because convincing the machine to wiggle its lines so I can check each transistor on a particular module is difficult.

In order to make this problem a little easier, I have built a cordwood module tester:

It has taken a couple of revisions to get the pin drivers correct, but it does useful things for me when I need it to. The three cables going out the back go to a Mesa Electronics 7i80 FPGA board, which I use for driving signals to the module under test. I have written some hardware for the FPGA, in VHDL, that knows how to talk to the tester board.

I have also written an assembler in Perl, to assemble stimulus commands I write, to the appropriate VHDL that gets included into the FPGA. Here is a sample of what I feed into the assembler:

# P14 = T70 negative pulse
# P17 = clock gate
# set the pins:
p1=h p2=h p3=h p4=h p5=h p6=h p7=h p8=h p9=h p10=h p11=h p12=h p13=h p14=h p15=h p16=h p17=h
p18=h p19=h p20=h p21=h p22=h p23=h p24=h p25=h p26=h p27=h p28=h
# scope sync pulse on unused pin
# run clocks for a bit...
P14=h P17=L

Each line represents what it should do for the next 20 nano-seconds. This results in a table that gets glued together with some header and trailer bits to create the VHDL input file. Here is the output listing:

 # P14 = T70 negative pulse
 # P17 = clock gate
 # set the pins:
 0 0ns 0xffe0000 p1=0 p2=0 p3=0 p4=0 p5=0 p6=0 p7=0 p8=0 p9=0 p10=0 p11=0 p12=0 p13=0 p14=0 p15=0 p16=0 p17=0
 1 20ns 0x0000000 p18=0 p19=0 p20=0 p21=0 p22=0 p23=0 p24=0 p25=0 p26=0 p27=0 p28=0
 # scope sync pulse on unused pin
 2 40ns 0x0000000 p1=0
 3 60ns 0x0000001 p1=1
 # run clocks for a bit...
 4 80ns 0x0000001 P17=0
 5 100ns 0x0002001 P14=1
 6 120ns 0x0000001 P14=0
 7 140ns 0x0000001 P14=0
 8 160ns 0x0010001 P14=0 P17=1
 9 180ns 0x0012001 P14=1
 10 200ns 0x0010001 P14=0
 11 220ns 0x0010001 P14=0

The listing shows the memory location, what time that instruction should execute, the actual bits in hexadecimal notation, and what the source file said.

This handy little tool has enabled me to fix 4 out of 5 of the UA modules I had replaced in the CDC, and to know what was wrong with the other one.

hardware, restoration

Detecting Nothing

The IBM360/30 gets stuck in a microcode loop.  The documentation indicates that a branch should be taken if the Z-bus is zero, and the branch should be taken.  The branch is not being taken.

A previous annoyance was that the microcode would stop at address 0xB46.  As the documentation indicates for that location, it is checking that a register is zero.  Hmm… checking for zero?  That is the problem with the loop not stopping.  So I dug deeper into this stop.  There was a stuck bit!  And here is what I found:

The circuit is an AND-OR-Invert gate and the output of the AND was high.  The above circuit is the AND gate.  If any of the inputs on the bottom go low the output should go low.  The output was not going low.  However, there is nothing on this circuit to force it low, but rather it allows the output to go low.  So, the problem was the input to the OR gate:

Aha!  That transistor with an X on it is not good.  Fortunately, we have spares of this SLT module, and replacing it fixed the problem with the first microcode stop.  However, the microcode loop with the non-taken branch is still not working as documented.  Dig deeper…


IBM360-30 Read Only Storage

The IBM360-30 uses Printed Card Capacitor storage for microcode.

The cards were created by printing Silver ink on Mylar:

Or etched copper:

304 cards make up the microcode.  I scanned them all.

My procedure was to remove one card, clean it, scan it, and then replace it before removing the next card.  My original thought was to clean the cards thoroughly using water, possibly with soap, as the machine was stored in a damp location.  However, the cards turned out to be quite clean, and only required wiping.

Scans were captured at 24-bit color, 600-bpi resolution.  The captured area was 3.15″ x 7.25″, and saved as .BMP files (24MByte).  I used different color backgrounds, and chose the sky-blue background as providing the best contrast for my eyes.  Processing of the images used the Blue channel.  Determining a threshold of hole/not hole was tricky, as there were two types of card, and each card had two areas to decode: the first 10 columns as card ID, and columns 11 through 70 for microcode data.  Registration of the scans was quite consistent for row alignment, but column alignment was variable.  Only one card needed adjustment vertically, but all card images were trimmed to align the first column.  Data was decoded from the card images and stored in a card archive.

hardware, restoration

Chasing the Pesky Ratio!

It seems like I did something really silly! I had to come up with some goals for 2018. I hate this time of year, I think everybody does. OK, what can I put down that is measurable and achievable? How about keeping the CDC6500 running more than 50% of the time? That might work. Oops, did I hit the send button?

“Hey, Daiyu: How do I tell what users have been on the machine?” Daiyu Hurst is my systems programmer, who lives Back East somewhere. If it is on the other side of Montana from Seattle, it is just “Back East” to me. She lives in one of those “I” states, Indiana, or Illinois, not Idaho, I know where that is. After a short pause, she found the appropriate incantations for me to utter, and we have a list of who was on the machine, and when they logged in. I had to use Perl to filter out those lines, but that was pretty easy.

What is all this other gobble-de-gook in this file:

 03.14.06.AAAI005T. UCCO, 4.096KCHS. 
 03.16.09.AAAI005T. UCCO, 4.096KCHS. 
 03.18.11.AAAI005T. UCCO, 4.096KCHS. 
 03.20.12.AAAI005T. UCCO, 4.096KCHSUCCO, 4.096KCHS. 
 05.00.30.SYSTEM S. ARSY, 1, 98/01/24.
 05.00.30.SYSTEM S. ADPM, 11, NSD.
 05.00.30.SYSTEM S. ADDR, 01, LCM, 40.
 05.00.44.SYSTEM S. SDCI, 46.603SECS.:
 05.00.44.SYSTEM S. SDCA, 0.032SECS.:
 07.32.30.SYSTEM S. ARSY, 1, 98/01/24.
 07.32.30.SYSTEM S. ADPM, 11, NSD.
 07.32.30.SYSTEM S. ADDR, 01, LCM, 40.
 07.33.07.AAAI005T. ABUN, BRUCE, LCM.:
 07.33.37.SYSTEM S. SDCI, 116.108SECS.:
 07.33.37.SYSTEM S. SDCA, 0.078SECS.:
 07.33.37.SYSTEM S. SDCM, 0.005KUNS.:
 07.33.37.SYSTEM S. SDMR, 0.004KUNS.:

The line with “ARSY” in it is when I booted the machine, at 5:00 this morning, from home. It crashed before I got in, and I booted it again at 7:32. Then we get to 7:33:07, and the “ABUN” line, where I login from telnet.

From the first few lines we can see that the machine appeared to still be running and putting things in its accounting log at 3:20, but it crashed before it could print a message about 3:22.

OK from this, I can mutter a few incantations at PERL, and come up with something like:

1054 Booted on 98/01/23 @ 07.39.30
 Previous uptime: 0 days 5 hours 59 minutes
 Down time: 0 days 17 hours 28 minutes
 1065 Booted on 98/01/23 @ 13.38.30
 Previous uptime: 0 days 1 hours 23 minutes
 Down time: 0 days 4 hours 35 minutes
 1068 Booted on 98/01/23 @ 14.12.30
 Previous uptime: 0 days 0 hours 0 minutes
 Down time: 0 days 0 hours 33 minutes
 1392 New Date:98/01/24
 1498 Booted on 98/01/24 @ 05.00.30
 Previous uptime: 0 days 13 hours 7 minutes
 Down time: 0 days 1 hours 40 minutes
 1503 Booted on 98/01/24 @ 07.32.30
 Previous uptime: 0 days 0 hours 0 minutes
 Down time: 0 days 2 hours 31 minutes

Last uptime: 0 days 0 hours 1 minutes

Total uptime: 2 days, 1 hours 37 minutes in: 0 months 7 days 0 hours 14 minutes
Booted 15 times, upratio = 0.29

Here is where the hunt for the Pesky Ratio comes in: See that last line? In the last week, the CDC has been running 29% of the time. That isn’t even close to 50%. I KNOW the 6000 series were not the most reliable machines of their time, but really: 29%?

What has been going on? A week ago, I was having trouble keeping the machine going for more than a couple of minutes. Finally, it occurred to me I might see how the memory was doing, and it wasn’t doing well. It took me a while to find why bit 56 in bank 36 was bad. I had to explore the complete wrong end of the word for a while, before I realized that end worked, and I should have been looking at the other end. I chased it down to Sense Amplifier (PS) module 12M40. When I put it on the extender, the signal would come and go, as I probed different places. I noticed that I had re-soldered a couple of via rivets before, so I re-soldered ALL the via rivets on the module.

What do I mean “via rivets”? In those days, either one of two things were true: either they didn’t have plated through holes in printed circuit boards, or they were too expensive. None of the CDC 6500 modules I have looked at have plated through holes. Most of the modules do have traces on both sides of the two PCBs that the module is made with. How did they get a signal from one side to the other? They put in a tiny brass rivet! Near as I can tell, all the soldering was done from the outside of the module, and most of the time the solder would flow to the top of the rivet somehow. Since I have found many of these rivets not conducting, I have to assume that the process wasn’t perfect.

After soldering all the rivets on this module, I put it back in the machine, and we were off and running. Monday, I booted the machine at 8:11, and it ran till 2:11. When I got in yesterday, the machine wouldn’t boot. Testing memory again found bit 56 in bank 36 bad again! I put module 12M40 on the extender, and the signal wasn’t there. I poked a spot with the scope, and it was there. I poked, prodded, squeezed, twisted and tweaked, and I couldn’t get it to fail.

This is three times for This Module! I like to keep the old modules if I can, but my Pesky Ratio is suffering here! I took the machine back down, and brought it back up with only 64K of memory, and pulled out the offending module:

There are 510 of these PS modules in the machine, three for each of the 170 storage modules, or about 10% of all the modules in the machine. Having a spare would be nice. My next task will be to make about 10 new PS modules.

In the time I have been writing this post, the display on the CDC has gone wonky again. This appears to happen when the Perpheral Processors (PP’s) forget how to skip on zero for a while. Once this happens, I can’t talk coherently to channel 10 or PP11. I have a few little tests that copy themselves to all the PP’s, and they will all work, except the last one: PP11.

I have yet to write a diagnostic that can catch the PP’s making the mistake that I can see on the logic analyzer once a day or so. Right now the solution seems to be to wait a while, and the problem will go away again. This is another reason while the Pesky Ratio is so difficult to hunt, but I fix what I can, when I can.

Onward: One bug at a time!



hardware, restoration

Surface-Mount Prototyping

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).