Tuesday, January 1, 2019

Planning out keyboard stack installation in DSKY substitute; work on repairing AGC memory module


Keyboard installation

I measured out the required height of the spacers to place the top of the honeycomb just under the faceplate - it must be 55/64" or almost 22mm. I will use a 20mm spacer and a washer or two to ensure that the honeycomb meets the faceplate. I ordered a supply of spacers, screws and nuts to do the assembly.

I still must wait to receive the 19 new plungers, install them in the honeycomb and put the stack together with coil springs inside. This will take almost two weeks due to the production timing at the 3D printing service I used.

The plan is to assemble the stack with the spacers, nuts on top and washers just under the PCB. When it is at the proper height, I will position in to align with the faceplate openings and wedge the board in place.

Checking heights of PCBs inside enclosure
This allows me to mark the bottoms of the spacers on the aluminum case. I will drill an oversize hole in the center of each spacer location, to allow me to screw the stack in place from the back of the DSKY enclosure.

I must complete the cable that will carry the power and signals between the keyboard stack and the display PCB. It has to be hooked to the stack before I screw it down in place.

After screwing down the stack and verifying the location under the faceplate. I will temporarily install the faceplate to use as a guide to glue down my 19 keycaps. Epoxy will be used to hold the cap to the plungers, with some small paper shims helping to center each keycap while the glue sets.


The Apollo Guidance Computer has a 2048 word erasable (RAM) memory that is contained in module B12. On our module, which is potted or sealed, we believe that one of the inhibit lines is broken somewhere inside. We determined this with a continuity test.

In the best case, we will repair the break and make use of the original module when running the AGC. This would require some very careful surgery, minimizing the risk of further damage and limiting the scope of any repair to the minimum area possible.

We hoped to find the broken lead using a very advanced micron resolution CAT scanner designed for connectors, which would have given us 3D images which could definitively identify the exact location of the break in the wire.

Unfortunately, the scanner we wanted to use has a maximum volume for samples which is smaller than the end of the B12 module. We had another scanner lined up here in Silicon Valley but it has the same restrictions.  A set of ordinary X-rays were taken but since they are both flat and low resolution, we couldn't spot the break.

An attempt to use Time Domain Reflectometry (TDR) was also inconclusive. TDR sends sharp but low power pulses down a wire. Any place where the impedance is not perfectly matched will impact the shape seen at the origin. An open circuit will cause a reflection to come back. The time between pulse transmission and reception of the reflection tells you the round trip travel time down the wire.

Our real world module has several places where impedance changes, complicating the use of TDR. Wire is connected to the input pin, producing one discontinuity. We are not sure how the small magnetic cores will affect the pulse, potentially producing some kind of distortion that might appear to be a reflection.

The first try with TDR gave a distance of approximately five inches, which is worrisome as it might be inside the core planes themselves where a repair would be extraordinarily harder than if it was in wire between the pins and the outside of the core planes.

At this point, we still don't have enough information to pin down the location and type of failure, nor can we plan a safe and minimal intervention to repair it.

We are working on a range of other solutions in case the module can't be repaired. More on these later, but first we will attempt to remove the metal cover over the module and see what is exposed and the exact potting we might be facing.

There is also the possibility, although slim, that the lack of connectivity is normal for these modules. We have arranged a chance to test a module at a local museum to cross check against our own.


  1. Sounds like your New Year is off to a great start. I hope it continues just that way!
    I'm finally caught up with your blog, and all the discussion of FPGAs used for disk interfaces, etc. has finally inspired me to pursue that more seriously than I've ever made the time for before. (I've always found it fascinating though.) The engineering shops where I worked happened to always have the EE's do the FPGA work while we did the software. On the recommendation of a friend I searched for some online course in VHDL and wound up signing up with Intel (who now owns Altera I learned) but I've not yet figured out where to start in the maze of stuff. Wish me luck...

    Charlie Carothers

  2. Hi Charlie

    Glad you were inspired as I was years ago. Have you read the ibm1130.blogspot.com blog which covers much of my early efforts with FPGAs as I build a replica of the IBM 1130?

    The temptation is to think of FPGA as programming - in large part because of the hardware design languages used - but that leads to many errors.


  3. G'day Carl,

    Thanks for your updates on the AGC restoration. These guys at Cornell University have large scale high resolution 3D X-Ray imaging services. They should be able to do what you need.


    All the best, Steven

  4. Hi Carl,
    I've read your blog all the way back through 2014, but I'll take a look and see if there is more that I've missed.

  5. It is a separate blog, ibm1130.blogspot.com, instead of rescue1130.blogspot.com (this one).

  6. Thanks, I'm reading or re-reading it. Not sure which at this point. It is fascinating in any case!
    With language constructs like "begin/end", "if", etc. it is easy to see why people confuse VHDL with a procedural language. I think it must have a least some procedural attributes though. Perhaps part of the trick is keeping the differences straight in your head. I think I'm going to search for a different tutorial than what Intel offers, BTW.

    1. What is even more pernicious is that you can use the procedural aspects, it will simulate just fine, but can't be expressed in the fpga.

  7. Wow, that's sorta scary. Sounds like the fpga software needs help.

    I felt your pain as I read through all the disk interface bring up. The gyrations you had to go through to debug that sounded pretty horrific. I guess there's no way to set breakpoints in hardware though. :-) Yeah, I know - I'm thinking too much like the primarily software guy I've mostly been. Trying to put my old hardware hat on again, with non-fpga logic one could put a scope probe at any intermediate level desired. I suppose that can be done with fpgas only to the degree that intermediate signals are assigned to I/O pins. My take is that was a lot of what you were doing during the disk bringup (but ICBW of course). I also tend to believe that what you did with the disk interface is far more complex than anything my EE associates ever did with the fpgas in the systems we worked on.