Core Rope Simulator box debugging
The core rope simulator boxes that came with the Apollo Guidance Computer were built by Raytheon and designed to cable up to a large console that would host the ROM program in rewritable (RAM) storage. We only had the two boxes inserted in place of the AGC core rope modules. not the large console nor the cables.
After Ken had reverse engineered the boxes and developed a Beaglebone-based driver to serve up the ROM programs to the boxes, we set into the process of debugging. First up, we had to find and repair about a dozen faults, many of them broken wires, as well as reshape IC leads to work in the very unreliable DipStik connectors used in the box.
After the Raytheon hardware was working it was time to test the function of Ken's driver box. It mostly worked right out of the chute, but we had to chase down some defects that caused errors reading certain blocks of memory.
The core rope modules that are normally used with the AGC consist of six separate modules which represent six blocks of 6K words. We will call them R1, R2, S1, S2, T1 and T2. The lowest addresses are in R1 and the highest contained in T2. The faults we experienced were when accessing S2, T1 and T2.
The Raytheon box would latch in the request for a particular module, then which of the 512 cores in that module should be read and which of 12 words from that module are passed into the computer sense amplifiers. What we found was that bad addresses were being latched due to transient short pulses that were due to poor logic design, a race hazard.
We could see the glitch, a pulse on the order of 100 ns compared to the real pulses that occur later and are microseconds in duration. The particular way that the addresses were decoded inside the Raytheon boxes allowed these to pass to the trigger that set flipflops, even though some of the address information had not yet made it through the other gates.
The solution was to add a small capacitor to the trigger line, such that it would ignore pulses that were too short but still lock in addresses when the desired signals arrived. The time constant that would block the glitch kept the integrated very short signal from climbing high enough to trigger the flipflop.
When we inserted a capacitor that was about 100 times too large, it began to delay the real signals - as their leading edge was spread out over a long slope. This caused some other addressing issues, but a capacitor that was just a couple times larger than the glitch did the job perfectly.
These boxes were serial number 3, but it is hard to see how they could have worked correctly on an Apollo Guidance Computer. That is, when the ROM was more than half full. They might have sufficed for small programs that remained in sections R1, R2 and S1. In any case, the core rope simulator works just fine now, letting us run real software such as Luminary 99 that was installed in the LM for the Apollo 11 mission.
Core Rope Module jumpers designed and manufactured
We intend to read existing core rope modules from both museums and private collectors, but a few early sets don't use all six rope modules. The code can fit in just two for Retread 50, as an example, thus four slots are empty. To work properly, jumper plugs must be installed in the four unused slots.
We didn't have any jumpers, but we could work out what was needed. Mike designed some connector housings, built them using a 3D printer, and populated them with the Samtec built Malco Mini-Wasp connectors. He installed small circuit board to complete the jumper circuit, and added handles for insertion and removal. These worked fine, setting us up for the opportunities ahead to read and archive the contents of core rope modules.
The core rope simulator boxes that came with the Apollo Guidance Computer were built by Raytheon and designed to cable up to a large console that would host the ROM program in rewritable (RAM) storage. We only had the two boxes inserted in place of the AGC core rope modules. not the large console nor the cables.
After Ken had reverse engineered the boxes and developed a Beaglebone-based driver to serve up the ROM programs to the boxes, we set into the process of debugging. First up, we had to find and repair about a dozen faults, many of them broken wires, as well as reshape IC leads to work in the very unreliable DipStik connectors used in the box.
After the Raytheon hardware was working it was time to test the function of Ken's driver box. It mostly worked right out of the chute, but we had to chase down some defects that caused errors reading certain blocks of memory.
The core rope modules that are normally used with the AGC consist of six separate modules which represent six blocks of 6K words. We will call them R1, R2, S1, S2, T1 and T2. The lowest addresses are in R1 and the highest contained in T2. The faults we experienced were when accessing S2, T1 and T2.
The Raytheon box would latch in the request for a particular module, then which of the 512 cores in that module should be read and which of 12 words from that module are passed into the computer sense amplifiers. What we found was that bad addresses were being latched due to transient short pulses that were due to poor logic design, a race hazard.
We could see the glitch, a pulse on the order of 100 ns compared to the real pulses that occur later and are microseconds in duration. The particular way that the addresses were decoded inside the Raytheon boxes allowed these to pass to the trigger that set flipflops, even though some of the address information had not yet made it through the other gates.
The solution was to add a small capacitor to the trigger line, such that it would ignore pulses that were too short but still lock in addresses when the desired signals arrived. The time constant that would block the glitch kept the integrated very short signal from climbing high enough to trigger the flipflop.
When we inserted a capacitor that was about 100 times too large, it began to delay the real signals - as their leading edge was spread out over a long slope. This caused some other addressing issues, but a capacitor that was just a couple times larger than the glitch did the job perfectly.
These boxes were serial number 3, but it is hard to see how they could have worked correctly on an Apollo Guidance Computer. That is, when the ROM was more than half full. They might have sufficed for small programs that remained in sections R1, R2 and S1. In any case, the core rope simulator works just fine now, letting us run real software such as Luminary 99 that was installed in the LM for the Apollo 11 mission.
Core Rope Module jumpers designed and manufactured
We intend to read existing core rope modules from both museums and private collectors, but a few early sets don't use all six rope modules. The code can fit in just two for Retread 50, as an example, thus four slots are empty. To work properly, jumper plugs must be installed in the four unused slots.
We didn't have any jumpers, but we could work out what was needed. Mike designed some connector housings, built them using a 3D printer, and populated them with the Samtec built Malco Mini-Wasp connectors. He installed small circuit board to complete the jumper circuit, and added handles for insertion and removal. These worked fine, setting us up for the opportunities ahead to read and archive the contents of core rope modules.
 |
| Rope jumper connector in place |
 |
| Connector removal using handle |
No comments:
Post a Comment