Looking inside a 1970s PROM chip that stores data in microscopic fuses

The MMI 5300 was a memory chip from the early 1970s, storing 1024 bits in tiny fuses.1 Unlike regular RAM chips, this was a PROM (Programmable Read-Only Memory); you programmed it once by blowing fuses and then it held that data permanently. The chip I examined originally cost $70 and was built by MMI (Monolithic Memories Incorporated), a leading PROM manufacturer at the time.

The highly magnified photo below shows the chip's silicon die. The metal layer on top of the silicon is most visible in this photo; the transistors and resistors fabricated from silicon are underneath. The wires around the edges are the 16 bond wires between the silicon die and the external pins. In the upper left, the 1024 bits of data are stored in a 33×33 array of diodes and fuses. (I'll explain the extra row and column below.) This chip is built from NPN transistors, unlike the MOS transistors used in most modern chips.

Die of the MMI 5300 PROM chip, holding 1024 bits of information. Click image for a larger version.

To produce the die photo, I started with the chips below, in their 16-pin ceramic packages; the 5300 and 6300 chips are essentially the same.2 Since the chips were in ceramic packages, I could decap the chip simply by knocking the metal lid off with a chisel, revealing the silicon die.

The MMI 5300 and 6300 PROM chips are in ceramic packages. The chips have 1974 and 1973 date codes.

In the photo below, the silicon die is mounted very off-center in the package. It's unclear if that is intentional or sloppy manufacturing. Tiny bond wires connect the die to the metal contacts of the package.

The MMI 5300 PROM with the lid removed, exposing the die.

Inside the chip

The diagram below shows the main parts of the chip, with the pins labeled. The chip stores 1024 bits as 256 4-bit words. The 8 address lines A0-A7 select one of the 256 words, and the bits are output on pins Out1-Out4. The Program pin is used to store data in the chip by blowing fuses. The Vcc and ground pins power the chip.

Die of the 5300 PROM with components labeled.

The 1024 bits of data are stored in a 33×33 array of diodes and fuses. Note that the data array only takes up about a quarter of the chip; the rest of the chip holds the supporting circuitry. Below the data array, address decode circuitry used the address lines to select one of 32 columns in the array. To the right, DTL multiplexers4 reduced the 32 rows of output to the 4 desired outputs. The output drivers amplified these signals and sent them to the output pins.

The fuses

The chip stored data in tiny fuses. An intact fuse represented a 1, while a blown fuse represented a 0. Thus, the chip was shipped containing all 1's, and the user programmed the chip by blowing fuses where a 0 bit was required. The fuses were fabricated from tiny regions of Nichrome metal that heat up and melt under high voltage. (Nichrome is a nickel-chromium alloy that has much higher resistance than typical metals, causing it to heat up. It is commonly used in applications such as toasters.)

A closeup of the fuses (purple) that store data. Inset circle shows a magnified fuse, showing the tiny horizontal crack indicating the fuse was blown.

The fuses are visible in the die photo above; they are the purple regions between the metal wiring. The fuses are very small, about 8µm long. I expected a blown fuse would vaporize entirely, but instead a blown fuse contains a tiny crack roughly 700 nm wide. (This is the wavelength of red light, so the crack is just barely visible under the microscope.)

Address decoding

The PROM stored 1024 bits as 256 words of 4 bits. However, the bits are physically arranged in a 33×33 grid since a square memory grid is more efficient than a highly-rectangular one. To access the memory, address bits A3-A7 select one of the 32 columns. The selected 32 bits in the column go through the multiplexers at the right, which select one bit out of each group of eight, based on address bits A0-A2. The four selected bits become the four outputs. Thus, addressing has two parts—one to select the column and one to select the four output bits—and they have separate circuitry,

Column selection uses 32 NAND gates, implemented with multiple-emitter transistors.3 (The N and P silicon regions of the transistors are visible as rectangular boxes, with the brownish metal layer on top connecting the regions together.) Each NAND gate has a different combination of address bits A3-A7 either inverted or uninverted, so each address activates a different NAND gate, selecting the associated column. You can see the binary counting in the emitters. The A7' and A7 lines alternate connections every column. The A6'/A6 connections alternate every two columns, while A5'/A5 alternate every four, and so on.

Part of the column address decoder. Each (vertical) transistor decoded a particular address, determined by which address lines are connected to the emitters. There were 32 columns in total.

The data array consists of a diode and fuse for each bit. (Without diodes, the bits would all be shorted together.) If the fuse is present, a low signal on the selected column will pull the corresponding row low through the diode (indicating a 1). If the fuse is blown, the row will remain high (indicating a 0). Thus, by blowing fuses, bits are programmed into the memory array. The diodes themselves are mostly hidden under the metal layer below. The column select lines run vertically in the silicon under the metal layer; the metal stripes on top reduce the resistance.

12 bits in the memory array. Each bit has a diode and fuse between a column select line and a row line.

Programming

To program the PROM, the user melted the necessary fuses one at a time using carefully-controlled high voltage pulses. After selecting the desired address, 27 volts was applied to the programming pin (a much higher voltage than the typical 5V TTL level). After a carefully-timed interval, the desired output was brought to 20 volts for a few microseconds to blow the fuse. (The timing and voltages needed to be precise so the fuse would blow without damaging other parts of the chip.) The process was repeated for each desired 0 bit. Customers used a PROM programmer such as shown below to perform these operations automatically.

The Data I/O PROM programmer. It had sockets of various sizes (turquoise) to hold different sizes of chips. This programmer cost about $6000. Photo: Michael Holley.

For the most part, reading a fuse and blowing a fuse used the same circuitry; the difference was the output pin circuit, which could either output a bit or sink a large current to blow the fuse, depending on the programming mode.5 The transistors along the programming path were larger than regular transistors to handle the larger current. For example, the diagram below compares the multiplexer NPN transistors to a typical NPN transistor on the chip. Also note that the 8 transistors in a multiplexer share a single collector (the multiplexer output).

Eight transistors in a multiplexer (left) compared to a typical NPN transistor (right). The metal layer was removed for this photo. The remaining oxide gives the transistors a colored appearance. N-doped silicon appears darker.

Testing

Before examining this chip, I didn't consider how difficult it was for the manufacturer to test a PROM. Most chips can be extensively tested before shipping to the customer, but you can't test the PROM fuses without irreversibly programming the chip. Even testing the address decode logic is difficult; since the chip is manufactured with all 1's, you'd read the same result even if the address circuitry is broken.

The chip included an extra row and column of fuses for testing.

To support testing, the chip contains an extra row and column of fuses.6 As a result, the storage grid was 33×33, rather than the 32×32 grid you'd expect. Half of the test fuses were missing, so reading the correct pattern of 0's and 1's tested the address decoders. By blowing test fuses and reading the results, the programming characteristics could be tested. The datasheet says that the chips should have a programming yield of over 95%. Compared to most integrated circuits, this is a high failure rate, but it's understandable given the difficulties of testing the chip.

Unused circuitry

One interesting feature of the 5300 die is that it has some transistors that aren't connected to anything else in the chip. The diagram below shows some of the unused transistors in the output circuitry. There are no metal connections from these transistors to the rest of the chip, making them apparently useless.

The output driver circuitry has some unused transistors, marked with arrows.

The reason for these unused transistors is that the same silicon layout could be used for slightly different PROM chips, depending on how the metal layer was wired up. The 5300 PROM had open-collector outputs, but a tri-state version (6301) was also available.7 Both chips used the same silicon die, but had small modifications to the metal layer to wire the transistors differently. Since the 5300 didn't need output transistors to pull the output to 1, these were left unconnected, yielding the unused circuitry seen above.

Conclusion

PROM chips were an important part of early computer systems, often holding the boot code, but their popularity peaked in the early 1980s as they were replaced by erasable PROM (EPROM) chips. EPROM chips had a distinctive quartz window over the die; shining ultraviolet light on the chip erased it, so it could be reused. EPROMs in turn were replaced by electrically-erasable PROMs (EEPROMs), similar to flash memory. To see how much technology has improved, consider that the 6300 PROM chip cost $70 in 1971 and stored 128 bytes. Now you can get a 128 GB flash drive for under $20: a billion times the storage, plus you can write it more than once.

Die with the metal stripped off to expose the silicon. This makes the structure of the transistors visible. The thin remaining oxide layer produces a rainbow effect in some areas.

I announce my latest blog posts on Twitter, so follow me @kenshirriff for future articles. I also have an RSS feed. Thanks to Marc Verdiell for supplying the chip.

Notes and references

1. For more information on the chip, see the MMI Bipolar LSI Databook chapter 2. ↩

2. The 6300 was the commercial 1K PROM, while the 5300 was the same chip specified for the military temperature range (-55 °C to +125 °C). The 6200/5200 was a compatible ROM chip, so you could design your system using the 6300 PROM and then drop in a mask-programmed ROM when everything was working. (A mask-programmed ROM was cheaper, but needed to be manufactured in large quantities.) ↩

3. Multiple-emitter transistors may seem strange, but they are used in the common 7400-series TTL chips. ↩

4. I suspect that diode-transistor logic was used instead of TTL for the output multiplexer because the simpler DTL circuit worked better with the high programming voltages. The DTL circuitry uses very large resistors biased to the programming voltage. They are visible near the right side of the die. ↩

5. The current path for reading and programming bits is as follows. When reading a bit, the output driver circuit was pulled to ground through a multiplexer transistor, the (intact) fuse, the associated diode, and finally the column select transistor. To blow a fuse, the programming pulse disabled the output driver circuits and transistors connected the output pins directly to the multiplexers. Then the high voltage pulse on the output pin followed the same path as before (multiplexer transistor, fuse, diode, column select transistor and ground), but the much higher current blew the fuse, permanently switching the bit to 0. ↩

6. One interesting question is how the test fuses are accessed. There are no test points on the chip; from the circuitry it appears that these fuses are accessed by applying unusual voltages to some of the pins. To access the row of test fuses at the top of the chip, the programming pin is raised to a higher voltage. To read or write the column of test fuses at the left of the chip, address pin A6 is pulled higher. This allows the row select logic, output drivers and programming circuitry to be tested. (These actions are undocumented and based on my reverse engineering.) ↩

7. The motivation for using tri-state or open-collector outputs is that often multiple memory chips were connected together to create a larger memory. The problem was how to combine the outputs. One solution was "open collector" outputs: essentially an output is either 0 or "nothing", and an external resistor pulls the output to 1 if it's not 0. A second solution was tri-state outputs: an output can be 0, 1, or "nothing" if not enabled. Since only one output was enabled at a time, the outputs could be tied together. ↩

Apollo Guidance Computer: Dipstiks and reverse engineering the core rope simulator

Onboard the Apollo spacecraft, the revolutionary Apollo Guidance Computer helped navigate to the Moon and land on its surface. The AGC's software was physically woven into permanent storage called core rope memory. We1 are restoring an Apollo Guidance Computer (below), which is missing the core ropes, but instead has core rope simulator boxes. These boxes were used during development and ground testing to avoid constantly manufacturing ropes. The core rope simulator is undocumented, so I reverse-engineered it, built an interface, and we used the simulator to run programs on our Apollo Guidance Computer. But we ran into some complications along the way.

The Apollo Guidance Computer with the cover removed, showing the wire-wrapped backplane. At the back, rope simulator boxes are visible in the core rope slots. The interface boards at the front are modern.

The AGC's core ropes

The Apollo Guidance Computer held six core rope modules, each storing just 6 kilowords of program information (about 12 kilobytes).2 Core rope modules were a bit like a video game ROM cartridge, holding software in a permanent yet removable format. Programs were hard-wired into core rope by weaving wires through magnetic cores. A wire passed through a core for a 1 bit, while a wire going around a core was a 0 bit. By weaving 192 wires through or around each core, each core stored 192 bits, achieving much higher density than read/write core memory that held 1 bit per core.

Detail of core rope memory wiring from an early (Block I) Apollo Guidance Computer. Photo from Raytheon.

Manufacturing a core rope was a tedious process that took about 8 weeks and cost $15,000 per module. Skilled women wove the rope by hand, threading a hollow wire-filled needle back and forth through the cores, as shown below3. They had the assistance of an automated system that read the program from a punched tape and positioned an aperture over the matrix of cores. The weaver threaded the needle through the aperture to install the wire in the right location. Once completed, the core rope was mounted in a module along with hundreds of resistors and diodes and encased in epoxy to make it solid for flight. (See my earlier article on core rope for details.)

A woman weaving a core rope memory, wiring software into read-only memory.

The core rope simulator

Since weaving a core rope was a time-consuming and expensive process, an alternative was required during development and ground testing. In place of the core ropes, NASA used rope simulators4 that allowed the AGC to load data from an external system. Our Apollo Guidance Computer was used for ground testing so it didn't have core ropes but instead had a core rope simulator. The simulator consists of two boxes that plugged into the AGC's core rope slots, each box filling three rope slots. These boxes are visible in the upper-left side of the AGC below, with round military-style connectors for connection to the external computer.

The core rope simulators are installed in the left side of the AGC in place of the real core ropes. Two round connectors on the left allowed the simulators to be connected to an external computer that provided the data.

Although we have extensive documentation for the Apollo Guidance Computer, I couldn't find any documentation on the simulator boxes. Thus, I had to reverse engineer the boxes by tracing out all the circuitry and then figuring out what the boxes were doing. From the outside, the boxes didn't reveal much. One end of each box has a round MIL-Spec plug for connection to an external system. The other end has three groups of 96 pins that plugged into the AGC. Each group of pins took the place of one core rope module.

Each core rope box communicated with the external system via a round 39-pin connector. Each box had three sets of 96 pins that plugged into the AGC, replacing three rope modules.

Opening up the boxes showed their unusual construction techniques. Part of the circuitry used high-density cordwood construction which mounted components vertically through holes in a metal block. On either side of the block, the component leads were welded to point-to-point wiring. Other circuitry in the boxes used standard integrated circuits (7400-series TTL). But unlike modern printed circuit boards, the chips were mounted inside plastic units called Dipstiks and wire-wrapped together.

A rope simulator box, partially disassembled. The round external connector is visible at the right, and the pins to connect to the AGC at the left. Analog circuitry with cordwood construction is center-left. To the right, several Dipstik modules are visible, white with rows of pins.

Cordwood construction

Cordwood construction was extensively used in the Apollo Guidance Computer for analog circuitry, and the cordwood construction in the rope simulators is similar (below). The white circles in the center are the ends of resistors and diodes mounted vertically through the module, with connections welded on either side. These components are stacked together densely, like wood logs, giving cordwood construction its name. Pulse transformers are under the large gray circles. Similar pulse transformers are on the other side of the module with their orange, yellow, red, and brown wires emerging from the holes. The black wires connect the cordwood circuitry to the digital logic. At the top of the photo, the posts have diodes and resistors mounted behind them, along with connections to the pins that plug into the AGC.

A closeup of the cordwood circuitry in a rope simulator box.

The main purpose of the cordwood circuitry was to provide electrical isolation between the Apollo Guidance Computer's circuitry and the rope simulator boxes. In modern circuitry, this function would be implemented with optoisolators but the rope simulator used small pulse transformers instead. Because each box receives signals directed to three different rope modules, numerous diodes merge the three signals into one. Resistors control the current through the pulse transformers.

Reverse-engineering the analog cordwood circuitry was a pain. First, none of the components were visible since they are embedded in the module. I had to use a multimeter to try to figure out what the components were. Second, since cordwood construction has connections on both sides, I spent a lot of time flipping the box back and forth to find the connection I wanted. Finally, I couldn't come up with a good way of drawing a diagram of cordwood construction without ending up in a maze of lines.

Digital logic and the Dipstiks

The Dipstik was a plug-in module introduced in 1968 to simplify prototyping with integrated circuits. It replaced printed circuit boards with a packaging system that provided twice the density. (See this vintage Dipstik ad.) The idea of the Dipstik was a plastic connector block with wire-wrap pins on the bottom for wiring up the circuit. The integrated circuits were clipped into a carrier that fit into the connector block. The carrier had solder lugs on top for additional components, such as decoupling capacitors. (The photo below shows Dipstik modules with one IC carrier removed. Each carrier held 5 integrated circuits.) The pins of the integrated circuit were sandwiched between contacts on the carrier and contacts on the connector block. It seemed like a great idea but turned out to be unreliable. As the plastic flexed and bowed out, the contacts with the pins became unreliable. (This was a problem both for contemporary Dipstik users and for us decades later.) The Dipstik was a stock market failure.

A Dipstik package opened up. The carrier (left) holds the ICs, and is inserted into the connector block (right). Photo courtesy of Marc Verdiell.

The photo below shows the wire-wrapped connections on the underside of the Dipstiks. Tracing this was extremely tedious since I couldn't follow a wire through the sea of identical blue wires. Instead, I had to beep everything out with a multimeter to find what was connected to what. Then I could construct a schematic diagram of the logic circuitry and ponder what it was doing.5 In total, the rope simulator used about 50 ICs.

Each rope simulator box contains complex circuitry. On the left, wire-wrapped wiring connects the TTL integrated circuits. On the left, the analog components are mounted using cordwood construction. At the back, two voltage regulators in large metal TO-3 packages are mounted on a heat sink.

Based on the dates on the components, the simulator boxes were built in 1971. Even though this is just a few years after the design of the AGC, the technology in the simulator boxes is much more advanced, illustrating the rapid changes in IC design between the mid-1960s and the early 1970s. The AGC was built with simple integrated circuits, each containing two NOR gates and built with primitive resistor-transistor logic (RTL). The simulator boxes, on the other hand, were built from more complex 7400-series chips6 containing up to a dozen TTL (transistor-transistor logic) gates. Unlike the obsolete flat-pack integrated circuits in the AGC, the simulator boxes used DIP (dual in-line package) ICs, a packaging style that is still in use.

Results of reverse engineering

After tracing out all the circuitry, I figured out how the rope simulator worked and created a schematic.

Essentially, one box decodes the address being accessed, while the second box sends the desired data to the AGC. (I'll call these the "address box" and "data box".)7

The address box takes the rope signals and converts them into a binary address. This task is not straightforward because the signals it receives are 14-volt high-current pulses designed to flip the rope cores. These pulses are also separated in time since some flip the core and others flip the core back. Finally, the pulses sent to the ropes are not a simple address, but also signals to select one of the 6 rope modules, signals to select one of 12 strands in a module.

The address box uses pulse transformers to convert the 14-volt pulses into TTL signals. It has a bunch of AND-OR logic to convert the signals into a binary address. (This is not trivial because each module holds 6 kilowords, not a power of 2, so a lot of bit manipulation is required.) A flip flop latches the address when it is available. Finally, resistor-capacitor one-shots control the timing, determining from the various signals when the address is ready and when the result should be sent to the AGC.

The data box is simpler. It receives 16 bits of data from the external system and sends signals to the AGC's sense amplifiers simulating the millivolt output from a core. These signals are generated via pulse transformers. The address box and data box communicate with each other via wires on the AGC backplane.

The boxes communicate with the external system via differential signals, to avoid picking up noise on long cables. The boxes contain LM109 5-volt regulators to power their TTL circuits. One box receives unregulated DC through the external connector, and sends unregulated DC to the other box through the AGC's backplane wiring. (This seems strange to me.)

With the address box opened, the wire-wrapped circuitry is visible.

The BeagleBone interface

Once I had reverse-engineered the core rope simulator, the next step was to build an interface that could provide program data to the simulator. I used a BeagleBone, a tiny single-board Linux system. The advantage of the BeagleBone is that it includes fast microcontrollers that could respond to the AGC's memory requests quickly, in real time. (I've written about the BeagleBone's PRU microcontrollers before, and used them to make a Xerox Alto Ethernet interface.)

The interface to the rope simulator consists of a board plugged into a BeagleBone. The two cables from the interface board go to the two simulator boxes.

I designed an interface board that plugged into the BeagleBone. The board is pretty straightforward: some AM26C32 differential line receivers to convert the differential signals from the simulator into 3.3V logic signals for the BeagleBone, and some AM26C31 differential line drivers to send signals to the simulator.8 I designed the board in KiCad and PCBWay manufactured it. They are a sponsor of our AGC restoration, so send them some business :-)

I wrote some software that runs on the PRU, the BeagleBone's microcontroller. This software is basically a state machine that waits for an address from the simulator box, waits for the timing signal, reads the word from BeagleBone RAM, and sends the word to the simulator box. The software is on Github.

Problems with the core rope simulator

The core rope simulator boxes were not built to the standard of the Apollo Guidance Computer, and I ended up spending a lot of time debugging them.10 Many welds in the cordwood circuitry were broken and needed to be soldered. (I don't know if the welds went bad over time or if we broke connections while reverse engineering.) We also found a short circuit on a Dipstik and a bad IC.

Debugging the simulator boxes. We're used Marc's vintage Tektronix 7854 scope (1980) to examine the pulse transformer's differential signals. The problem turned out to be a broken connection in the cordwood circuitry. Behind the AGC are the power supplies for the AGC and the rope simulator.

The Dipstiks were the worst problem, as many of the contacts between a Dipstik and the IC were intermittent. The problem was that the IC pins are sandwiched between contacts in the Dipstik carrier and contacts in the Dipstik connector block. The plastic Dipstiks tended to bow outwards, resulting in intermittent bad contacts. By bending the IC pins into S curves, Marc was able to keep the pins in contact with both sides, at least for a little while. But after a few hours, the soft IC pins would bend back and connections became unreliable again, so we don't have a good long-term fix.

The most interesting problem was a race condition between two signals from the AGC that should have dropped simultaneously. They fed two ends of a pulse transformer coil, so the transformer should have produced no signal. However, one signal dropped a bit slower than the other, causing a glitch pulse from the pulse transformer.5 Unfortunately, the digital logic in the simulator box was asynchronous, so the glitch latched a bad address bit into the box's flip flops, causing an access to the wrong memory location. Eventually, we tracked the problem down and put capacitors across the offending signals to filter out the glitch. Unfortunately, we used capacitors that were a bit too large and delayed the address signal too much in other circumstances, causing different errors. We put in smaller capacitors and we were finally able to successfully run programs on the AGC, using the vintage core rope simulator.

Conclusion

The Apollo Guidance Computer used core ropes for program storage. Since it wasn't practical to constantly manufacture core ropes during development, rope simulators were used in place of the core rope modules. I reverse-engineered the rope simulator and built a BeagleBone-based interface to drive it. We successfully ran programs on the AGC through the rope simulator. The rope simulator, however, had many problems and wasn't very reliable.

We will be demonstrating the Apollo Guidance Computer next week to celebrate the 50th anniversary of the Moon landing. Come see these historic demos at the Cradle Of Aviation Museum (Long Island) on July 18 and the MIT Museum on July 20.

@CuriousMarc made a video (below) showing our work with the core rope simulator. I announce my latest blog posts on Twitter, so follow me @kenshirriff for future articles. I also have an RSS feed. My rope simulator files are on Github. Thanks to PCBWay for sponsoring this board.

Notes and references

1. The AGC restoration team consists of Mike Stewart (creator of FPGA AGC), Carl Claunch, Marc Verdiell (CuriousMarc on YouTube) and myself. The AGC that we're restoring belongs to a private owner who picked it up at a scrapyard in the 1970s after NASA scrapped it. For simplicity, I refer to the AGC we're restoring as "our AGC". ↩

2. The AGC was a 15-bit machine: each word consisted of 15 data bits and a parity bit. While a word that isn't a power of two may seem bizarre now, computers in the 1960s were designed with whatever word size fit the problem. ↩

3. The original caption on the photo was: "Space age needleworker 'weaves' core rope memory for guidance computers used in Apollo missions. Memory modules will permanently store mission profile data on which critical maneuvers in space are based. Core rope memories are fabricated by passing needle-like, hollow rod containing a length of fine wire through cores in the module frame. Module frame is moved automatically by computer-controlled machinery to position proper cores for weaving operation. Apollo guidance computer and associated display keyboard are produced at Raytheon Company plant in Waltham, Massachusetts." Caption and photo are from a Raytheon document, courtesy of Transistor Museum. ↩

4. Several different core rope simulators were built for the AGC. The AGC monitor provided a debugging console with lights and switches along with the rope simulator. The Portafam was a rope simulator that could load programs from magnetic tape. While these rope simulators had some documentation, unfortunately, I couldn't find any documentation on the Raytheon rope simulator that we had, so I had to reverse engineer everything. ↩

5. I figured out all the circuitry except for two mysteries. The first mystery is the parity circuit, using two uncommon 74180 parity generator chips. These are not used for the memory parity bit, which is supplied externally. They do not check the address parity supplied by the AGC. It appears that based on an external switch they will optionally replace address bit 7 with the parity of the other address bits. Lacking an address bit, the system would then be unusable. We left the parity switched off and everything worked fine.

   The second mystery is a transistor that looks like it would amplify the strand select signal. The problem is that the transistor's collector isn't connected to anything, so the transistor is unpowered and doesn't function. When we encountered timing issues with the strand select signal, we powered up this transistor to see if it helped, but it made things worse. In addition, the transistor appears to have been added to the cordwood circuitry at a later date. We ended up ignoring the transistor. ↩

6. The TTL chips in the interface boxes were 5400-series chips. These are the military version of the well-known 7400-series, identical except operating over a wider temperature range. ↩

7. The split into "address box" and "data box" isn't exact. Due to the way the rope slots are wired, the data box determines which of the 6 modules are being addressed and provides this information to the address box. ↩

8. I had some difficulty getting the round MIL-spec 20-39S connectors to attach to the simulator boxes, since they have unusual keying. There are a zillion slightly-different variants of these connectors, many costing hundreds of dollars. I ended up getting connectors off eBay and Marc milled the keying off so the connectors worked. I used 25-pair Amphenol telco cables between the BeagleBone and the simulator. Soldering the wires to the connectors was more of a pain than I expected. ↩

9. Viewing the pulse transformer signals on a scope was difficult because you need to see the small differential signal across the transformer. Since we didn't have a differential probe for the modern scopes, we used Marc's vintage scope that did have a differential probe. (You might think you could subtract the two signals with a modern scope, but the problem was that the difference was much smaller than the common-mode voltage, so you essentially get zero when you subtract.) ↩

10. We built some infrastructure to help debug the simulator boxes. I tested the boxes extensively outside the AGC, using an Arduino and a power transistor to generate test signals. I added debugging code to the BeagleBone to detect when something went wrong, and illuminated a status LED on my interface board. I also used the BeagleBone to generate an oscilloscope trigger signal at a known-bad address, letting us see the analog signals at that specific point. Mike wrote some FPGA code to check the data from the simulator box against the data the AGC should have read, detecting whenever something went wrong. Finally, I logged the addresses that the BeagleBone saw, while Mike logged that addresses that the AGC was sending. By comparing the addresses, we could see which addresses were bad.

    I learned a few lessons from my interface board that I'll apply to future boards. Putting an RGB status LED on the board was my best idea, since it made it much easier to tell what was happening. I should have exposed the BeagleBone's serial port connector on my interface board. As it was, if I ran into any problems booting the BeagleBone, I had to pull off the interface board, attach the FTDI serial adapter, fix the problem via the serial console, remove the serial adapter, and then reinstall the interface board. Finally, I should have exposed a couple generic I/O pins for functions such as oscilloscope triggering. Instead, I had to solder temporary wires onto my interface board. ↩

Bitcoin mining on an Apollo Guidance Computer: 10.3 seconds per hash

We've been restoring an Apollo Guidance Computer1. Now that we have the world's only working AGC, I decided to write some code for it. Trying to mine Bitcoin on this 1960s computer seemed both pointless and anachronistic, so I had to give it a shot. Implementing the Bitcoin hash algorithm in assembly code on this 15-bit computer was challenging, but I got it to work. Unfortunately, the computer is so slow that it would take about a million times the age of the universe to successfully mine a Bitcoin block.

The Apollo Guidance Computer powered up. The cover is off, showing the computer's purple wire-wrap wiring of the backplane. We built the interfaces that are plugged into the front of the computer. At the back, vintage core rope simulator boxes are visible in the core rope slots.

The Apollo Guidance Computer was developed in the 1960s for the Apollo missions to the Moon. Onboard the Apollo spacecraft, these computers provided guidance, navigation, and controlled the engines. In an era when most computers ranged from refrigerator-sized to room-sized, the Apollo Guidance Computer was small enough to fly in space. One of the very first computers to use integrated circuits, the AGC was 70 pounds and under a cubic foot in size.

The output from the Bitcoin mining program, displayed on the Display/Keyboard (DSKY). The display shows part of the Bitcoin hash in octal. The DSKY is a modern replica, hooked up to the genuine AGC.

The Apollo Guidance Computer also pushed the boundaries of software engineering under the leadership of Margaret Hamilton. It had a cutting-edge real-time operating system that supported multiple prioritized jobs2 along with fault detection and handling. Much of the software was in assembly language but the AGC also had an interpreter designed for navigation algorithms. The interpreter implemented a virtual machine that provided vector and matrix arithmetic along with trigonometry and double- and triple-precision numbers.

How Bitcoin mining works

As the leading digital currency, Bitcoin has received a lot of attention in the past few years. The Bitcoin system can be thought of as a ledger that keeps track of who owns which Bitcoins, and allows them to be transferred from one person to another. The revolutionary feature of Bitcoin is there's no central machine or authority keeping track of things. Instead, the records are spread across thousands of machines on the Internet, and the system works with nobody in charge.

To ensure everyone agrees on which transactions are valid, Bitcoin uses a process called mining—about every 10 minutes a block of outstanding transactions is mined, which makes the block "official". Bitcoin mining is designed so it takes an insanely huge amount of computational effort to mine a block, so nobody can take over the mining process. Miners compete against each other, generating trillions and trillions of random "hashes" until someone finds a lucky one that starts with 18 zeros.3 This hash forms a successfully mined block, and then everyone moves on to the next block. The idea is that getting 18 zeros in a row randomly is extremely unlikely, so it takes a huge number of tries before someone succeeds. It's kind of like a lottery, where miners keep trying until someone "wins", but finding a valid hash is less likely than finding a single grain of sand out of all the sand on Earth.

Each time a block is successfully mined, new Bitcoins are created; currently, a successful miner gets 12.5 new Bitcoins (worth $140,000) as well as transaction fees. The possibility of receiving $140,000 every 10 minutes motivates miners to build datacenters full of specialized hardware using huge amounts of electricity.4

Structure of a Bitcoin block. The data in yellow is hashed to yield the block hash, which becomes the identifier for the block. The block is linked to the previous block by including the previous block's hash, forming the blockchain. The Merkle root is a hash of all the transactions in the block.

The diagram above shows what actually goes into a block that is mined. The yellow part is the block header (which gets hashed), and it is followed by the transactions that go into the block. Each block contains the hash of the previous block, causing all the blocks to be linked together forming the blockchain. On the right, you can see that the hash above was successful because it starts with lots of zeros.

To summarize the mining process: you collect new Bitcoin transactions and create a header as in the diagram above. You generate the cryptographic hash of the block. If by some incredible chance the result starts with 18 zeros you send the block into the Bitcoin network and "win" $140,000 in Bitcoin. Otherwise, you change the header slightly and try again as fast as possible. When someone else succeeds in mining the block, you start over from the new block and new transactions.5

The SHA-256 hash algorithm used by Bitcoin

Where do these hashes come from? Bitcoin mining is based on cryptography, with a "hash function" that converts a block of data into an essentially random hash value. The hash algorithm is designed to be simple to implement, but cryptographically secure: there's no known short cut to finding a successful hash other than trying zillions of hashes through brute force. In particular, Bitcoin uses a standard cryptographic hash function called SHA-256.6 This algorithm is so simple you can literally do it by hand, but it manages to scramble the data entirely unpredictably.

The SHA-256 algorithm can be described in about a page of pseudocode. It consists of a scrambling step called a "round", repeated 64 times. The diagram below shows one round, which takes eight 4-byte hash values, A through H, performs a few operations, and generates new values for A through H. As can be seen from the diagram, only A and E are changed in a round, while the others are just shifted over. Even so, after 64 rounds the input data will be completely scrambled, generating the unpredictable hash output.

This diagram shows the computations during one round of SHA-256. This process is repeated 64 times. Source: Wikipedia created by kockmeyer, CC BY-SA 3.0.

The operations in SHA-256 are simple bit operations. The red boxes above indicate 32-bit addition, generating new values for A and E. The Ch "choose" box chooses bits from F or G, based on the value of input E. The Σ "sum" boxes rotate and sum bits. The Ma "majority" box looks at the bits in each position of A, B, and C, and selects whichever value is in the majority. The K_t values are constants. The input data enters the algorithm through the W_t values. These operations can be easily implemented on a computer using simple arithmetic and logic operations.7 (The operations can also be easily implemented in a custom logic circuit, which is why Bitcoin mining chips are popular.)

The Apollo Guidance Computer's processor

The AGC doesn't have a microprocessor, as it was built years before microprocessors were developed. Instead, the processor is built from about 5600 NOR gates. These gates were combined to make circuits such as flip flops for registers, binary adders, control logic, and so forth. The AGC was one of the first computers to use integrated circuits; each integrated circuit held two NOR gates. The computer had 24 logic modules similar to the one below. Each logic module had 120 integrated circuits (240 NOR gates). For example, the registers and ALU were implemented with four modules, each implementing 4 bits of the processor.

A logic module from the Apollo Guidance Computer. The module consists of 120 integrated circuits, each one implementing two NOR gates. Photo courtesy of Mike Stewart.

The computer's architecture was unusual by modern standards: it used a 15-bit word, along with parity. (Back then, computers often had a word size that fit the application, not necessarily a power of 2.) The AGC had just 2K words of RAM, along with 36K words of ROM. Its ROM was constructed from core rope memory. (I wrote about the AGC's RAM core memory here and core rope here).

The Apollo Guidance Computer was slow even by 1960s standards; it could perform about 40,000 additions per second. (In the AGC's defense, this was an era when most computers ranged from refrigerator-sized to room-filling, so the AGC did well for its size.) The AGC's main strength was I/O: it had hundreds of I/O connections to provide real-time control of the spacecraft.

Implementing SHA-256 on the Apollo Guidance Computer

My implementation of the SHA-256 hash algorithm implementation follows the pseudocode pretty closely. I ran into some difficulties, though, since the AGC's instruction set lacks many features of modern computers. For instance, the AGC (like many 1960s computers) didn't have a stack, so you had to keep track of the return address for each subroutine call.

Another complication was that the SHA-256 algorithm uses 32-bit unsigned numbers, while the AGC used 15-bit signed numbers in obsolete 1's complement form, so even addition required some tricky code. To fit a 32-bit number into the AGC, I split each word into a 4-bit chunk and two 14-bit chunks. (I used 14-bit chunks and not 15-bit chunks because I needed to use unsigned arithmetic.)

The next issue was that the AGC has very limited memory. The AGC, like most computers of the 1960s, used magnetic core memory, storing each bit in a tiny magnetized ferrite ring. Since core memory was fairly bulky, the AGC had just 2K words (approximately 4K bytes) of RAM. The AGC's addressing scheme made things more complicated since you could only access 256 words unless you used an inconvenient bank switching mechanism. The problem is that the SHA-256 algorithm uses eight (32-bit) hash values, a 64-word message table, and 8 words of intermediate values. These three arrays alone used up 240 AGC words, leaving about 16 words for everything else (temporary values, subroutine return addresses, loop counters, pointers, etc.) I managed to get everything to fit in one bank by reusing these 16 words for multiple purposes, but I spent a lot of time debugging problems when a variable clobbered a location still in use.

For RAM, the Apollo Guidance Computer used this 2 kiloword core memory module.

Most modern computers have shift and rotate instructions to manipulate words, but the AGC instead used three special registers. Writing to a special register would cycle the value right one bit, shift the value right, or cycle the value left. The SHA-256 algorithm uses many 32-bit shifts and rotates, which I had to convert into loops using the 15-bit cycle register. The point is that a shift operation like x>>10 is trivial in C, but I needed to implement a whole subroutine to do it on the AGC.

Our Apollo Guidance Computer and replica DSKY. The computer's I/O connectors are visible at the front of the computer. six core rope slots at the back are empty. The photo is an homage to this classic AGC photo.

To keep the instruction set and code size small, the AGC had some instructions with side effects you wouldn't expect. For example, the TS (Transfer to Storage) instruction wrote a value to memory, which seems straightforward. But if the previous addition had an overflow (i.e. a carry), TS also skipped the next instruction and loaded the accumulator with a +1 or -1. In other words, simply writing a value to memory could result in a jump in control flow and register modification. The purpose of this was to handle carries for multiple-precision arithmetic, but most computers simply implement this with an "Add with carry" instruction.

Running the program

The video below shows my Bitcoin program running on an actual Apollo Guidance Computer with the results displayed on our DSKY (Display/Keyboard). The DSKY had a simple numeric keypad with buttons large enough for astronauts to use with gloves on. The computer displayed output numerically; astronauts had to know if the output was feet, seconds, degrees, or something else. We used a replica DSKY created by Carl since nobody would let us use a real DSKY.8

The Apollo Guidance Computer had a very simple user interface through the DSKY. An astronaut selected an action pressing the "Verb" key, entering a verb number, and pressing "Enter". The astronaut selected a target for the action by entering a "Noun". (Astronauts had a reference card listing all the verbs and nouns.) I added Bitcoin mining as Verb 65 in a program called Borealis9; you can see Mike enter Verb 65 at the beginning of the video.

The Apollo Guidance Computer took 5.15 seconds for one SHA-256 hash. Since Bitcoin uses a double-hash, this results in a hash rate of 10.3 seconds per Bitcoin hash. Currently, the Bitcoin network is performing about 65 EH/s (65 quintillion hashes per second). At this difficulty, it would take the AGC 4×10^23 seconds on average to find a block. Since the universe is only 4.3×10^17 seconds old, it would take the AGC about a million times the age of the universe to successfully mine a block.

Given the astronomical difficulty of mining, you might wonder how I successfully mined a block. For this demonstration, I simply used as input a block that had been successfully mined in the past, specifically block #286819. Thus, the algorithm succeeded quickly, but since it was an old block, I didn't make any money off it.

To put the AGC's mining performance in perspective, a USB stick miner performs 130 billion hashes per second. The stick miner costs under $70, compared to $150,000 for the Apollo Guidance Computer. For its time, the Apollo Guidance Computer was an extremely compact, low-power system, using 55 watts and taking up under a cubic foot of space. The USB miner, though, uses 12 watts and fits in your hand. The enormous difference in performance is due to the exponential increase in computer speed described by Moore's law as well as the advantage of custom Bitcoin mining hardware.

Programming the AGC—then and now

In the 1960s, code for the AGC was written on punch cards, and assembled onto tape using a software system called YUL. This system was more advanced than you'd expect for the 1960s, including a source control system to track and incorporate changes. For flight, the software was woven into core ropes, with wires physically going around cores for a 0 or through cores for a 1. In other words, each core rope was custom-manufactured, with the data stored in the weaving pattern of the wires. This provided high-density, reliable ROM storage, but required weeks of manufacturing.

Detail of core rope memory wiring from an early (Block I) Apollo Guidance Computer. Photo from Raytheon.

Since it wasn't practical to manufacture a new core rope for every change, a different approach was used during development. A core rope simulator allowed a program to be fed into the AGC from external storage. This simulator was part of the refrigerator-sized monitor (below), which provided a debugging interface to the AGC through a test connector on the AGC. The monitor allowed programmers to set breakpoints, single-step, examine registers, and so forth, using lights and switches.

The AGC monitor provided a debugging interface to the AGC as well as a core rope simulator. See User's guide to the AGC monitor.

In my case, I wrote the software on my laptop and assembled it with yaYUL, a modern version of YUL written by the Virtual AGC team. I tested the software on a simulated AGC using the Code::Blocks IDE11, which provides debugging features somewhat similar to what the monitor provided in the 1960s. To run the code on the real AGC, we obviously didn't manufacture core ropes. We have vintage core rope simulator boxes, but they turned out to be extremely unreliable. Fortunately, Mike Stewart built a board to load code into the AGC using the same AGC test connector originally used by the monitor.

AGC code can be developed in an IDE. The debugger makes it much easier to develop code. The IDE communicates with the virtual DSKY.

Conclusion

I implemented the SHA-256 hash algorithm and ran it on the Apollo Guidance Computer that we're restoring, taking 10.3 seconds per hash. This isn't my first experiment with absurd Bitcoin mining. I tried mining by hand with pencil and paper; this had a hash rate of 0.67 hashes per day. Using an IBM punch card mainframe computer from the early 1960s got the hash rate up to 80 seconds per hash. My fastest implementation was on a Xerox Alto (the famous 1973 computer that inspired the Macintosh), which performed 1.5 hashes per second. Thus, the Apollo Guidance Computer outperformed the older transistor-based IBM computer but not the Alto.

My Bitcoin mining experiments by hand, on a punch-card mainframe, and on a Xerox Alto.

The Apollo program cost 25.4 billion dollars as of 1973, equivalent to about 150 billion dollars today. The current market cap of Bitcoin is 200 billion dollars, so if NASA had been mining Bitcoins, they could have paid for the whole Apollo program and still had money left over. One flaw in this plan is the Apollo Guidance Computer's low performance, since mining a block would take much more than the lifetime of the universe.

My code is available on Github; the mining code is in BITCOIN.agc. CuriousMarc has a series of AGC videos which you should watch for more information on the restoration project. I announce my latest blog posts on Twitter, so follow me @kenshirriff for future articles. I also have an RSS feed. Thanks to Mike Stewart for supplying images and extensive information.

Notes and references

1. The AGC restoration team consists of Mike Stewart (creator of FPGA AGC), Carl Claunch, Marc Verdiell (CuriousMarc on YouTube) and myself. The AGC that we're restoring belongs to a private owner who picked it up at a scrap yard in the 1970s after NASA scrapped it. For simplicity, I refer to the AGC we're restoring as "our AGC".

   The Apollo flights had one AGC in the command module (the capsule that returned to Earth) and one AGC in the lunar module. In 1968, before the Moon missions, NASA tested a lunar module with astronauts aboard in a giant vacuum chamber in Houston to ensure that everything worked in space-like conditions. We believe our AGC was installed in that lunar module (LTA-8). Since this AGC was never flown, most of the modules were not potted with epoxy. ↩

2. Because the AGC supported multiple programs at once, my code needed to periodically call NEWJOB to see if there were any other waiting jobs to run. To ensure reliability, the AGC constantly checked to make sure a faulty program doesn't take over the system. Thus, I needed to give other jobs the chance to run or else my job would get killed. ↩

3. At the current Bitcoin difficulty level, about 1 in 10^22 hashes will be successful at mining a block; a valid hash must start with approximately 18 zeros. The mining difficulty changes periodically to keep the time between blocks at approximately 10 minutes. As mining hardware gets faster, the difficulty factor is automatically updated to make mining more difficult so miners can never really catch up. ↩

4. A while back I estimated that Bitcoin mining uses about as much electricity as the entire country of Cambodia. One paper puts mining's energy consumption comparable to Ireland's electricity usage. A recent estimate is that Bitcoin mining uses more electricity than Switzerland. ↩

5. I've simplified a lot of details in my discussion of Bitcoin algorithms. For in-depth information on Bitcoin and mining, see my articles Bitcoins the hard way and Bitcoin mining the hard way. ↩

6. Bitcoin uses "double SHA-256" which simply consists of applying the SHA-256 function twice. I could have implemented the double-hash in the AGC code, but I ran out of time; I got the basic hash working at 4 am the night before we sent the AGC back to Houston. How to upload transactions into the AGC is also left as an exercise for the reader. ↩

7. While SHA-256 is easy to implement, that's not the case for all the cryptography used by Bitcoin. To create a Bitcoin transaction, the transaction must be signed with elliptic curve cryptography. This requires 256-bit modular arithmetic, which is about as hard as it sounds. Even a simple implementation is 1000 lines of C. Needless to say, I decided not to implement signing in assembly language on the AGC. ↩

8. Many people have asked if we talked to Fran Blanche about the DSKY. Yes, we have. ↩

9. The Aurora program was used to extensively test the operation of the Apollo Guidance Computer in the Lunar Module. I wrote the Bitcoin code as part of Borealis, a modern version of Aurora slightly cleaned up. The code for Aurora and Borealis includes a table of verb definitions so it was straightforward for me to add Verb 65 for my Bitcoin code. In the video, you can see Mike enter Verb 65 to start the Bitcoin program. I also took advantage of the Executive's octal display routine to show the output. This routine is accessed through Verb 05 Noun 01, which is why you'll see that on the display at the end of the video. ↩

10. At the end of the video clip, the display shows 8 octal triples indicating the hash: 00000/00000/00000, 00000/00000/00000, 00007/21221/23740, 00017/35565/05002, 00002/20333/04715, 0o00002, 0o33226, 0o05227, 00004/05367/35221, 00005/00252/14222. (The 11111/11111/11111 value is just a signal that all values have been displayed.) Converting these to hex and reversing the bytes yields the 8-byte Bitcoin hash: 00000000 00000000 e067a478 024addfe cdc93628 978aa52d 91fabd42 92982a50. Note the multiple zeros at the beginning of the hash; this is what makes the hash valid. ↩

11. The Virtual AGC project has developed simulations of the AGC, DSKY, and YUL assembler, so you can experiment with the AGC system. While you can do this from the command line, debugging is much, much easier if you use the Code::Blocks IDE. You can download a VirtualBox environment with everything set up here. In the folder "AGC Visual Debugging", double-click on Borealis to start Code::Blocks. You can edit code in the IDE (or with an editor). Then "Build → Build" compiles the code and "Debug → Start" runs code in the debugger. "Tools → DSKY" starts up a DSKY window to interact with the AGC. "Debug → Debugging windows → Memory dump" lets you look at memory contents. The IDE lets you set breakpoints, single-step through code, examine memory, and so forth. For more information on AGC code development, see this page. ↩

12. The Bitcoin protocol is a mish-mash of big-endian and little-endian values. It inconveniently reverses the byte order of the SHA-256 hash, so while the hash from the algorithm ends with zeros, the Bitcoin hash starts with zeros. I displayed the hash to match the Bitcoin order. ↩

Software woven into wire: Core rope and the Apollo Guidance Computer

Onboard the Apollo spacecraft, the revolutionary Apollo Guidance Computer helped navigate to the Moon and land on its surface. One of the first computers to use integrated circuits, the Apollo Guidance Computer was lightweight enough and small enough (70 pounds and under a cubic foot) to fly in space. An unusual feature that contributed to its small size was core rope memory, a technique of physically weaving software into high-density storage. In this blog post, I take a close look at core rope and the circuitry that made it work.1

Detail of core rope memory wiring from an early (Block I) Apollo Guidance Computer. Photo from Raytheon.

The Apollo Guidance Computer (AGC) had very little memory by modern standards: 2048 words of RAM in erasable core memory and 36,864 words of ROM in core rope memory. In the 1960s, most computers (including the AGC) used magnetic core memory for RAM storage, but core ropes were unusual and operated differently. Erasable core memory and core rope both used magnetic cores, small magnetizable rings. But while erasable core memory used one core for each bit, core rope stored an incredible 192 bits per core, achieving much higher density.2 The trick was to put many wires through each core (as shown above), hardwiring the data: a 1 bit was stored by threading a wire through a core, while the wire bypassed the core for a 0 bit. Thus, once a core rope was carefully manufactured, using a half-mile of wire, data was permanently stored in the core rope.

The Apollo Guidance Computer. The empty space on the left held the core rope modules. The connectors on the right linked the AGC to the rest of the spacecraft.

We3 are restoring the Apollo Guidance Computer shown above. The core rope modules (which we don't have)4 would be installed in the empty space on the left. On the right of the AGC, you can see the two connectors that connected the AGC to other parts of the spacecraft, including the DSKY (Display/Keyboard). By removing the bolts holding the two trays together, we could disassemble the AGC. Pulling the two halves apart takes a surprising amount of force because of the three connectors in the middle that join the two trays. The tray on the left is the "A" tray, which holds the logic and interface modules. The tray on the right is the "B" tray, which holds the memory circuitry, oscillator, and alarm. The six core rope modules go under the metal cover in the upper right. Note that the core ropes took up roughly a quarter of the computer's volume.

The AGC is implemented with dozens of modules in two trays. The trays are connected through the three connectors in the middle.

How core rope works

At a high level, core rope is simple: sense wires go through cores to indicate 1's, or bypass cores to indicate 0's. By selecting a particular core, the sense wires through that core were activated to provide the desired data bits.

Magnetic cores have a few properties that made core memory work.7 By passing a strong current along a wire through the core, the core becomes magnetized, either clockwise or counterclockwise depending on the direction of the current. Normally the cores were all magnetized in one direction, called the "reset" state, and when a core was magnetized the opposite direction, this is called the "set" state. When a core flips from one state to another, the changing magnetic field induces a small voltage in any sense wires through the core. A sense amplifier detects this signal and produces a binary output.

The key advantage of core rope is that many sense wires pass through a single core, so you can store multiple bits per core and achieve higher-density storage. (In the case of the AGC, each core has 192 sense wires passing through (or around) it5, so each core stored 12 words of data.) This is in contrast to regular read/write core memory, where each core held one bit.

Core rope used an unusual technique to select a particular core to flip and read. Instead of directly selecting the desired core, inhibit lines blocked the flipping of every core except the desired one. In the diagram below, the current on the set line (green) would potentially flip all the cores. However, various inhibit lines (red) have a current in the opposite direction. This cancels out the set current in all the cores except #2, so only core #2 flips.

This diagram illustrates how core rope memory worked. Simplified diagram from MIT's Role in Project Apollo vol III, Fig. 3-12

In the diagram above, only the sense lines (blue) passing through core #2 pick up an induced voltage. Thus, the weaving pattern of the sense lines controls what data is read from core #2. To summarize, the inhibit lines control which core is selected, and the sense wires woven through that core control what data value is read.

The inhibit lines are driven from the address lines and arranged so that all inhibit lines will be inactive for just the desired core. For any other address, at least one inhibit line will be activated, preventing the core from flipping and being read. 6

The AGC's core ropes

The Apollo Guidance Computer contained six core rope modules, each storing 6 kilowords of program information. The AGC was a 15-bit machine: each word consisted of 15 data bits and a parity bit. (While a word that isn't a power of two may seem bizarre now, computers in the 1960s were designed with whatever word size fit the problem.8) Each module contained 512 cores, each storing 12 words of data. That is, each module had 192 (12×16) sense wires going either through or around each core. Each group of 16 sense wires for a word was called a "strand", so there were 12 strands.

AGC with rope modules. A rope module is partially inserted into one of the 6 slots in the AGC. Photo © Draper Labs via Caltech.

The photo above shows how the core rope modules slid into the Apollo Guidance Computer; the pins on the end of each module meshed with connectors in the AGC. The core rope module below (and its companion) held an early Lunar Module program called Retread 50. We took our AGC to the Computer History Museum to read the data from these modules and we put the results online.

This core rope module held the Retread 50 software for the Apollo Guidance Computer. This module is from the Computer History Museum.

The 512 cores in each module were arranged physically as two layers of 256 cores (but electrically as four planes of 128 cores).9 A set and reset line went through all the cores in a plane, allowing a particular plane in the module to be selected.6 The photo below shows the interior of a core rope module. One layer of 256 cores is visible, with the tiny wires threaded through them. (The second layer of 256 cores is underneath.) Note that the cores only take up about half the module space. Surrounding the cores are hundreds of resistors and diodes that were used to select the desired word.10: These components were mounted with cordwood construction, with the components installed vertically through holes in the module.

Inside a core rope. The 32×8 cores visible form a layer of 256 cores; a second layer is underneath. Photo from CHM/Raytheon CN-4-421-C.

The photo below shows one of the Retread 50 modules from the Computer History Museum with the cover removed. The cores were encased (potted) in protective epoxy to protect them during flight, so the cores are not visible.

A core rope module with the cover removed. This module is at the Computer History Museum.

Manufacturing the core rope

Wiring of the core rope was a tedious process that took about 8 weeks and cost $15,000 per module. As a result, the computer code needed to be frozen months in advance and last-minute patches to the code were not possible.11 The core ropes (and the AGC) were manufactured by Raytheon in Waltham, Massachusetts. Many of the women building the ropes were hired from the local textile industry for their sewing skills; other skilled women came from the Waltham Watch Company, a company that also helped with the high-precision gyroscopes used on the Apollo missions.12

Much of the core rope wiring (address inhibit wires, set, reset, etc.) was the same for all core rope modules. Two women passed a needle back and forth through the cores to create this wiring. The needle was hollow and contained the necessary length of wire. The clip above (from Computers for Apollo via xpascal) shows this process.

"Space age needleworker 'weaves' core rope memory for guidance computers used in Apollo missions. Memory modules will permanently store mission profile data on which critical maneuvers in space are based. Core rope memories are fabricated by passing needle-like, hollow rod containing a length of fine wire through cores in the module frame. Module frame is moved automatically by computer-controlled machinery to position proper cores for weaving operation. Apollo guidance computer and associated display keyboard are produced at Raytheon Company plant in Waltham, Massachusetts." Caption and photo are from a Raytheon document, courtesy of Transistor Museum.

To store the desired binary data, the core rope's sense lines were threaded through or around cores in the proper sequence. Originally, this wiring was done entirely manually, which was slow and error-prone. Raytheon improved the process by combining automated positioning with manual threading. First, the program's assembly code was fed into an assembler called YUL that produced a Mylar punched tape. An automated system (above, below) read this tape and step-by-step moved the proper core into position. A woman manually threaded the sense line through an aperture into the indicated core. The aperture then jogged down to pull the wire around a nylon pin, moving the wire out of the way for the next sense wire to be threaded. Once all the cores were threaded, the nylon pins were removed and the final core rope module was tested by an automated system, again controlled by punched tape.

A woman wiring sense lines in a core rope. She is threading the wire through a white circular aperture that indicates the core to wire. Source: Raytheon CN-4-20C / Smithsonian Institution WEB15435-2016.

Core rope circuitry

Core rope required a lot of digital and analog circuitry to drive and read the ropes. This section briefly describes this circuitry and shows the modules that implemented it. The bottom four modules in the picture below (Sense Amplifier, Strand Select, and two Rope Drivers) implemented the analog circuitry. Logic modules (in the "A" tray shown earlier) decoded the address into rope, module, and strand select signals. We carefully tested the analog and digital modules individually before powering up the AGC.

Tray B of the Apollo Guidance Computer. The erasable memory module is the large black module. Most of the other modules on the left are support for the erasable (RAM) and fixed (core rope) memory. The core rope modules would slide into the right hand side under the metal cover.

Sense Amplifier Modules

When a core flipped (either in fixed memory or erasable memory), the changing magnetic field induced a weak signal in a sense line, one sense line for each bit in the word. This signal needed to be amplified and converted to a logic signal; this was the job of the sense amplifiers. The sense amplifiers were implemented using a custom sense amplifier IC. (The AGC used only two different types of integrated circuits, the sense amplifier and a dual NOR gate.) The AGC had two identical sense amplifier modules; one (in slot B13) was used by the erasable core memory, while the other (B14) was used by the fixed core rope memory.

The photo below shows a sense amp module. Eight sense amplifiers are visible and eight other sense amplifiers are on the other side of the module. The sense amplifiers required carefully-tuned voltage levels for bias and thresholds so the modules included voltage regulation circuitry (center and right in photo). On top of the module (front in the photo), you can see the horizontal lines of the nickel ribbon that connected the circuits; it is somewhat similar to a printed circuit board.

Sense amplifier module with the top removed. Note the nickel ribbon interconnect at the top of the module.

The closeup photo below shows the module's cordwood construction. In this high-density construction technique, components were inserted into holes in the module. Resistors and capacitors passed through from one side of the module to the other, with one lead on either side. On each side of the module, components were connected by point-to-point wiring. This wiring was welded, not soldered. White insulating sleeves were placed over the wires to prevent short circuits.

Closeup of the sense amplifier module for the AGC. The sense amplifier integrated circuits are at the top and the reddish pulse transformers are below. The pins are at the bottom and the wires at the top go to the nickel ribbon, which is like a printed circuit board.

Near the top of the photo are two amplifier integrated circuits in metal cans. Below are two reddish pulse transformers. An output driver transistor is between the pulse transformers.13 Only the ends of resistors are visible, due to the cordwood construction. At the top of the module are connections to the nickel ribbon interconnect. Modules that were flown on spacecraft were potted in plastic so the components were protected against vibration. Since our AGC was used on the ground, most modules were unpotted and the components are visible.

Address decoding

Address decoding for the core rope required a fair amount of logic for two reasons. The first problem was the AGC's instructions used 12-bit addresses, which could only address 4 kilowords of storage. Since the AGC had 36 kilowords of fixed memory and 2 kilowords of erasable memory, it used a complex system of bank registers and mapping logic to convert a 12-bit address into the correct physical memory location. The second problem was that each core rope module held 6 kilowords, which is not a power of two. Thus, moderately complex decoding circuitry was required to generate module and strand select signals from the address.

The core rope addressing, control, and timing logic is spread across several logic modules. Most of the address decoding was implemented in logic module A15. Other core rope logic is in modules A6, A8, and A14. Photo courtesy of Mike Stewart.

The AGC's logic circuitry (including the processor) was implemented with NOR gates. Each integrated circuit implemented two NOR gates using RTL (resistor-transistor logic), an early logic family. These ICs were costly; they cost $20-$30 each (around $150 in current dollars). There wasn't much inside each IC, just six transistors and eight resistors. Even so, the ICs provided a density improvement over the planned core-transistor logic, making the AGC practical. The decision to use ICs in the AGC was made in 1962, amazingly just four years after the IC was invented. The AGC was the largest consumer of ICs from 1962 to 1965 and ended up being a major driver of the integrated circuit industry.

Each IC contained two NOR gates implemented with resistor-transistor logic. From SCD 2005011.

Strand select

The strand select module in position B15. Photo from Mike Stewart.

The address decoding logic described above produced signals indicating the desired strand and module. These logic-level signals needed to be converted to 14-volt pulses to drive the core rope modules. This task was performed by the strand select module, which consisted of transistor driver circuits using NPN and PNP transistors. The resistors in these circuits were individually selected to produce exactly the desired currents.

A closeup of the strand select module, showing its cordwood construction.

Rope driver

The rope driver modules generated the high-current pulses (up to 450mA) necessary to flip the cores. Like the strand select module, the rope driver modules used NPN and PNP transistor driver circuits with carefully-selected resistors to ensure the desired current. They also used inductors to control the pulse shape, necessary to keep switching noise from overwhelming the small signals generated by the cores. The modules generated 16 inhibit signals (7 address bits and parity, along with complements) as well as two core set signals and four core reset signals.

The rope driver modules in B16 and B17 provided high-current pulses to the rope module. Photo from Mike Stewart.

The core rope simulator

Unfortunately, the core ropes were missing from the Apollo Guidance Computer we are restoring. Instead, this AGC has core rope simulator boxes in place of the ropes. The purpose of these simulator boxes was to feed code into an AGC for development and ground testing without requiring a new core rope to be manufactured every time. The simulator allowed an external computer to supply data words in place of the core rope, allowing the AGC to run arbitrary programs.

The core rope simulators are installed in the left side of the AGC in place of the real core ropes. Two round connectors on the left allowed the simulators to be connected to an external computer that provided the data.

The simulator consists of two boxes that plugged into the AGC's core rope slots. These boxes are visible in the upper-left side of the AGC above, with round military-style connectors for connection to the external computer. One box exported address information each time the AGC performed a core rope read, while the other box fed 16 data bits into the AGC, "tricking" the AGC into thinking it had read from core rope. I built an interface from the core rope simulator boxes to a Beaglebone and will write more about that project later.

Conclusion

Core memory was the most common storage technology for computers in the 1960s. However, the Apollo Guidance Computer also used core ropes for read-only storage, an uncommon storage technique that achieved high density but required considerable labor. Core ropes made it possible to fit complex software into the compact physical space of the AGC. While 36K of code seems ludicrously small by modern standards, it held enough code to navigate and land on the Moon. And now, decades later, we can recover this code from core rope modules and learn more about it.

Marc has a series of AGC videos; the video below discusses the core rope simulators. I announce my latest blog posts on Twitter, so follow me @kenshirriff for future articles. I also have an RSS feed. See the footnotes for more information sources15. Thanks to Mike Stewart for supplying images and extensive information.

Notes and references

1. Prototype core rope memories had a single bundle of wire that looked similar to a rope. The final core rope memories didn't look as rope-like, but kept the name. ↩

2. The core rope memory achieved a density of 1500 bits per cubic inch, including the driving hardware and packaging. This was about 5 times the density of erasable core memory. See MIT's Role in Project Apollo vol III pages 91 and 274.

   The cores in core rope were not regular ferrite cores, but permalloy ribbon wound around a non-magnetic steel bobbin. If you're used to ferrite cores, winding a metallic ribbon around a bobbin may seem like a strange way to make a core, but that was how the earliest cores were built, until ferrite cores started to be used in the early 1950s. The ferromagnetic materials used in wound-ribbon cores were developed by Germany in World War II and used by the German navy in magnetic amplifiers. After the war, American personnel brought back the material along with a rolling mill, and started US manufacturing under the name Deltamax. In other words, core memory had its origin in Nazi technology captured by the US. See Memories that shaped an industry, pages 39-40, 52, 87, 90.

   The cores used in the core rope were rather large, .249" in diameter, about 5 times the diameter of the cores used in the erasable core memory. (In comparison, some IBM 360 mainframes of the same era used tiny cores that were .021" in diameter.) When a rope core flipped, it yielded a fairly large voltage pulse of 215-430 mV. Properties of the cores were defined in NASA specification control drawing SCD-1006320. ↩

3. The AGC restoration team consists of Mike Stewart (creator of FPGA AGC), Carl Claunch, Marc Verdiell (CuriousMarc on YouTube) and myself. The AGC that we're restoring belongs to a private owner who picked it up at a scrap yard in the 1970s after NASA scrapped it. For simplicity, I refer to the AGC we're restoring as "our AGC".

   The Apollo flights had one AGC in the command module (the capsule that returned to Earth) and one AGC in the lunar module. In 1968, before the Moon missions, NASA tested a lunar module with astronauts aboard in a giant vacuum chamber in Houston to ensure that everything worked in space-like conditions. We believe our AGC was installed in that lunar module (LTA-8). Since this AGC was never flown, most of the modules were not potted with epoxy. ↩

4. Yes, we know about Francois and the rope modules he read; those are ropes for the earlier Block I Apollo Guidance Computer and are not compatible with our Block II AGC. Also, many people have asked if we talked to Fran about the DSKY. Yes, we have. ↩

5. Mike Stewart pointed out that a core wouldn't have all 192 sense wires passing through it. Because the system used odd parity, at most 15 of the 16 bits can be high. Thus, at most 180 sense wires would pass through a core. ↩

6. The Apollo Guidance Computer had one additional pair of inhibit lines for address parity so all non-matching cores will have at least two inhibit lines activated. (If a core was one line away from being activated, the parity would also be different, yielding two active inhibit lines.) The purpose of this was to ensure that every non-selected core received two inhibit signals and was solidly inhibited. Otherwise, a core with just one inhibit line high might receive a bit of net set current, changing its magnetism slightly and introducing noise.

   Note that 7 address lines select one of 128 cores. Each module consists of four (logical) planes of 128 cores, yielding 512 cores. To select one of the four planes, four different reset lines are used, to reset just the core in the desired plane. Thus, only that plane is read. Two set lines are used, one to set cores in planes A and B, and one for planes C and D. To avoid setting cores in two planes, the reset line in the undesired plane was activated at the same time as the set line, blocking the set in that plane. The obvious approaches would be to use four set lines (one per plane), or one set line (and use reset to block the others). I don't know why they used two set lines.

   Each module also had a "clear" line that passed through all the cores. This was similar to reset, but was needed due to a complexity of the AGC's opcode decoding. To fit more opcodes into a 15-bit instruction, the AGC used "quartercode" instructions. The idea was that some instructions didn't make sense on a fixed memory address, such as increment. The AGC would perform an entirely different instruction in that case, allowing a larger instruction set. The problem was that by the time instruction decoding had decided that the instruction didn't apply to the specified address, the read of fixed memory had already started, and the core was set. The "clear" line allowed this core to be reset so it wouldn't interfere with the desired read. I don't know why the existing reset lines couldn't be used for this purpose. (Summary and details.) The schematic is here. ↩

7. If you are familiar with regular core memory (i.e. erasable RAM core memory), there are many similarities, but also many important differences. First, erasable core memory was arranged in a grid, and a particular core was selected by energizing an X line and a Y line in the grid. Second, erasable core memory stored a single bit per core, with the direction of magnetization indicating a 0 or 1. Core rope, on the other hand, stored many bits per core, with a 0 or 1 depending on if a sense wire goes through the core or not. The cores in core rope were much larger, since about 200 wires went through each core, while erasable core memory typically had 3 wires through each core. Finally, erasable core memory used the inhibit line for writing a 0, while core rope used inhibit lines for addressing. ↩

8. For more information on why the Apollo Guidance Computer used 15-bit words, see MIT's Role in Project Apollo vol III page 32. The short answer is they required about 27-32 bits accuracy for navigation computations, and about 15 bits for control variables. Using a 15-bit word for small values and double-precision values for navigation provided sufficient accuracy. A 14-bit word was too small. A 17- or 18- bit word would simplify some things but increase costs. ↩

9. Core rope memory in the earlier Block I Apollo Guidance Computer was configured slightly differently. The memory was folded into 4 layers of 128 cores instead of 2 layers of 256 cores. As a result, the Block I rope modules had a different shape: roughly square in cross-section, unlike the flat Block II modules. In early Block I modules, each core had 128 sense wires (8 words) threaded through it, yielding 4K words per module. With 6 modules, an early Block I AGC had 24K words of rope storage. In later Block I AGCs, the rope modules provided more storage: 192 sense wires (12 words) per core, yielding 6K words per module. Thus, 24K of rope storage required just 4 modules. For the Block II computers used for the Moon missions, 6 modules × 512 cores per module × 192 bits per core ÷ 16 bits per word = 36864 (36K) words in total. ↩

10. Selection of a particular module and strand was done through a resistor/diode biasing network using hundreds of resistors and diodes in each module. The diagram below shows how this network operated. The selected strand line was pulled high, while the selected module line was pulled low. This resulted in current (red) through the selected strand and through the sense amplifier transformer. The remaining diodes were reverse-biased, so no current flowed. A voltage pulse on the sense wire through the selected core perturbed the current flow, resulting in a voltage imbalance across the sense amplifier transformer. This signal was detected by the sense amplifier, resulting in a 1 bit. (This circuit is rather confusing; you might expect the circuit to be a loop through the sense wire and the sense amplifier transformer, but instead, the currents are flowing towards the 0-volt module line in the middle. Study the directional arrows carefully to see how the current flows. The current from a flipped core is essentially superimposed on this current flow.)

    

    A particular strand and module were selected by a resistor/diode network. The non-selected diodes were reverse-biased, blocking those signals from the sense amplifiers. Based on MIT's Role in Project Apollo vol III, Fig. 3-13

    The resistor and diodes in the left green box were repeated once for each strand (i.e. 192 times in each module), while the resistor and diodes in the right box were repeated once for each sense line (i.e. 16 times in each module). ↩

11. The need to freeze the software design weeks in advance was viewed as a feature: "The inability to change the program without rebuilding one or more modules provides an effective management tool for the control of software changes. It also provides another incentive to make the software error free." See MIT's Role in Project Apollo vol III page 274. Much of the information in this section on core rope manufacturing is from One Giant Leap. The 1965 video Computers For Apollo shows AGC manufacturing process (including core ropes) in detail. ↩

12. There are interesting gender issues behind the manufacture of core rope and core memory that I'll only mention briefly. The core rope has been referred to as LOL memory, referencing the "Little Old Ladies" who assembled it, but this name erases the women of color who also assembled core ropes. (I'm also not convinced that the LOL name was used at the time.) The software for a particular flight was managed by "rope mother" who was generally male (although the famous Margaret Hamilton was rope mother on LUMINARY). Also see Making Core Memory: Design Inquiry into Gendered Legacies of Engineering and Craftwork.

    ↩

    Women weaving a core rope. Raytheon photo, via BBC.

13. The sense amplifier output circuitry is a bit confusing because the erasable core memory (RAM) and fixed rope core memory (ROM) sense amp outputs were wired together to connect to the CPU. The RAM had one sense amp module with 16 amplifiers in slot B13, and the ROM had its own identical sense amp module in slot B14. However, each module only had 8 output transistors. The two modules were wired together so 8 output bits are driven by transistors in the RAM's sense amp module and 8 output bits are driven by transistors in the ROM's sense amp module. (The motivation behind this was to use identical sense amp modules for RAM and ROM, but only needing 16 output transistors in total. Thus, the transistors are split up 8 to a module.) ↩

14. I'll give a bit more detail on the sense amps here. The key challenge with the sense amps is that the signal from flipping a core is small and there are multiple sources of noise that the sense line can pick up. By using a differential signal (i.e. looking at the difference between the two inputs), noise that is picked up by both ends of the sense line (common-mode noise) can be rejected. The differential transformer improved the common-mode noise rejection by a factor of 30. (See page 9-16 of the Design Review.) The other factor is that the sense line goes through some cores in the same direction as the select lines, and through some cores the opposite direction. This helps cancel out noise from the select lines. However, the consequence is that the pulse on the select line may be positive or may be negative. Thus, the sense amp needed to handle pulses of either polarity; the threshold stage converted the bipolar signal to a binary output.

    

    Schematic of the circuitry inside a sense amplifier IC.

    The sense amplifier (above) was a custom integrated circuit designed by Sperry Rand in 1962. This chip pushed the state of the art for analog ICs and it may be the first integrated circuit amplifier. The sense amp chips initially cost $200 each, equivalent to $1700 now. ↩

15. For more information on the AGC, the Virtual AGC site has tons of information on the AGC, in particular the ElectroMechanical page has lots of schematics and drawings. There's a video of Eldon Hall, designer of the AGC, disassembling our AGC in 2004. Eldon Hall's book Journey to the Moon describes development of the Apollo Guidance Computer in detail, and was very helpful for this blog post. If you want to try a simulated AGC in your browser, see moonjs.

    The Apollo manuals provide detailed information on the memory system. The manual has a block diagram of the AGC's memory system. Engineering drawings of the AGC's core rope are here. Fixed memory is described in the AC Electronic LM Manual volume 2 starting at 4-594 and a core rope wiring diagram is here. Sense amplifiers: description, schematics. Strand and module select circuits: description, schematic, schematic. Set circuit: description, description, schematic, schematic. Reset circuit: description, description, schematic. Inhibit circuit: description, schematic. Address decoder: description, schematic. ↩