 So the following talk is about a very relevant piece of technology legacy of our human race. The first piece of computer that landed on our moon and actually it became a metric. People started to compare other architectures, other computers in volumes of multiples of processing speed of this computer. It's rocket science but it's even harder it's computer rocket science. So I'm very happy to have Christian Hessmann or Hessie on stage who is actually a rocket scientist and for the computer part we have Michael Steyer who is the founder of the export linus project and has gathered with this project and many others lots and lots of experience around architectures of computers. So please give a warm round of applause for the ultimate Apollo guidance talk. Is this on? Can you hear me? Yes. Welcome to the ultimate Apollo guidance computer talk aka a comprehensive introduction into computer architecture and operating systems and space flight. My name is Michael Steyer and I'm Christian Hessmann. This talk is number six in a series by various people. The idea is to explain as much as possible about a classic computer system in 60 minutes. The Apollo guidance computer is a digital computer designed from scratch specifically for use on board the Apollo spacecraft to support the moon landing between 1969 and 1972. Developed at MIT between 1961 and 1966, a total of 42 AGCs were built at a cost of about $200,000 each. The base clock is about one megahertz, all data is 15 bits and there are two kilowatts of RAM and 36 kilowatts of ROM. It's about the size of a large suitcase, weighs 32 kilograms and consumes about 55 watts. Its user face is a numeric display and keyboard. Some historical context. In the mid 1960s you can just take it off the shelf computer and put it into a spacecraft. The first mini computers were the size of a small fridge, too heavy, too power hungry and too slow for real time scientific calculations. Even though the industry had come a long way since the previous decade. 10 years later, microcomputers with highly integrated circuits started outclassing the AGC hardware in many regards. There are many reasons that make the AGC especially interesting. The architecture is very 60s and feels very alien to us today. The hardware is very innovative for its time. It has some very interesting and unusual peripherals. Its operating system was revolutionary for its time and the mission software has all the bits, too, with the right hardware attached flyer to the moon. In the Apollo program, the Apollo guidance computer was used in two unmanned test missions where it was remote controlled from the ground in three manned test missions and in the seven manned landing missions. Astronauts hated the idea of giving up any control to a computer, but they wanted to be in charge. And while as a fallback most of the mission could also be flown manually, the mission planners got their way. To understand the purpose and the responsibilities of the Apollo guidance computer, we need to first look at the Apollo mission. The core strategy of the Apollo program was instead of landing the complete spacecraft on the moon for which an extremely large rocket would have been required to only land a much smaller lander while the larger part with a few for the way back stays in moon orbit. So the Apollo spacecraft can be separated into the lunar module, the command module and the service module. The Saturn V rocket launches it and three astronauts from Cape Kennedy into Earth orbit. By accelerating at the right time, the trans-lunar injection moves the spacecraft into a so-called free return orbit, but just coasting it would travel around the moon and back to Earth. Right at the beginning of this three-day journey, the command and service module extracts the lunar module and docks with it. By breaking on the far side of the moon, the spacecraft enters a lunar orbit. After two of the astronauts have climbed into the lunar module and after undocking, the lunar module breaks. This is called powered descent and lands. After taking off again, the lunar module rendezvous with the command and service module and the two astronauts from the lunar module climb into the lunar module and the lunar module is jettisoned. The remaining command and service module accelerates at the far side of the moon for a trajectory towards Earth. For entry, only the command module remains. By the way, these excellent visualizations are from Gerrit Owens how the Apollo spacecraft works videos which we can highly recommend. The command and service module and the lunar module each contained one AGC. It was the same hardware, but attached to partially different IO devices and with the software adapted for the specific spacecraft. The astronauts interact with them through the display and keyboard units which are mounted alongside these hundreds of switches. The computer's responsibilities during the mission are to track the position and speed, the so-called state vector of both spacecraft, stabilize the spacecraft's attitude, calculate and control engine burns and monitor or control the Saturn V during launch. In order to understand how the Apollo guidance computer does all this, we'll look at its architecture, the hardware implementation, some of its interesting peripherals, the system software as well as the mission software. The architecture of the AGC can be described as a von Neumann accumulator machine with 15-bit once complement big Indian arithmetic. So we'll talk about the instruction set, the arithmetic model and instruction encoding as well as the memory model, IO operations and counters and finally the interrupt model. Machine code instruction sets very widely, the instruction set of a modern ARM processor which is mainly optimized for runtime performance consists of about 400 instructions. Subleg is a language mostly of academic interest that shows that a single instruction can be enough to solve the same problems as all other Turing-complete languages. While a more complex construction set can achieve higher code density and contribute to higher performance, it also generally means that the CPU will be drastically more complex. A computer from the early 1960s consisted of only a few thousand transistors as opposed to today's billions which is why this is the sweet spot for the AGC. 36 instructions provided just about the performance that was required for the mission. These are the 36 instructions, some load and store instructions, arithmetic and logic, control flow instructions, IO instructions and instructions for dealing with interrupts. The memory model is the cornerstone of the instruction set. Memory consists of 4,096 cells numbered in hexadecimal 0,000 through FFF. Each cell contains a 15-bit word, number between 0 and 7 FFF. Almost all changes in data in memory go through the 15-bit accumulator, also called the A register. A program can copy words between the accumulator and a memory cell but also add, subtract, multiply and divide values as they are moved around. The data in memory can have many meanings depending on how it is interpreted. These values may represent integers while those three words are meant to be decoded as machine code instructions. Code and data in a single address space make the AGC a so-called von Neumann machine. The CPU's program counter, PC, always holds the address of the instruction to be executed next. The load instruction copies the contents of a given memory cell into the accumulator. The PC goes on to the next instruction. The add instruction adds contents of a given memory cell to the accumulator. And the store instruction copies the value in the accumulator into memory at a given location. The generalized version of these instructions we just saw used K as a placeholder for a memory address as an argument. These are cards, quick reference of instructions. This is the generic syntax of the instruction, a short description, the exact operations in pseudocode. This one takes memory address K and adds it to A, the accumulator. The encoding of the instruction in memory and the number of clock cycles. The original syntax is the name the original design as gave to the instruction. For this talk I have chosen a more modern syntax here on the right, which makes it much more easier, much easier to describe the CPU both to people with and without a background in machine programming. Let's have a look at the instruction set in detail. Here's an example of the load instruction. Load A, indirect 200. On the left you see the set of registers of the AGC. Most operations work with the accumulator, so we will be ignoring the other registers for now. While executing this instruction, the CPU looks at memory at location 200, reads its contents and copies it into the accumulator. This is the store instruction. In the store, load indirect 200, A. Like with all instructions, the first argument is the destination, memory, and the second one, the source, the accumulator. It looks up the rest to a zero zero in memory and copies the contents of the accumulator to that cell. There's also an exchange instruction which can atomically swap the contents of the accumulator and the memory cell. The add instruction will look up the contents of a given memory address and add it to the contents of the accumulator and store the result back into the accumulator. And there's a subtract instruction. It takes the contents of the memory address and subtracts it from the contents of the accumulator and stores the result back into the accumulator. The result of a subtraction can be negative, so we need to talk about how negative numbers are expressed on the AGC. Let's look at just four-bit numbers. Four-bit unsigned integers can express values from zero to 15. With sign and value encoding, the uppermost bit corresponds to the sign, and the remaining three bits represent the absolute value. Consequently, there are separate values for zero, plus zero, and minus zero. This encoding is hard to work with since zero transitions need to be special cased. Once complement encoding has the order of the negative numbers reversed. The zero transitions are simple now, but there are still two representations of zero. Modern twos complement encoding only has a single encoding for zero, and it's fully backwards compatible with unsigned addition and subtraction. In the 1960s, computers designed for scientific calculations are usually once complemented, and so is the AGC. This can express values from zero to 15. In once complement, the values zero through seven match the unsigned values zero through seven, and the negative side is organized like this. Unlike twos complement, the two sides are perfectly symmetrical. So negating a number is as easy as complementing it, that is flipping all the bits. So the two representations of zero are plus zero with all zero bits and minus zero with all one bits. Addition in the positive space is the unsigned version. Same in the negative space when mapping signed negative numbers to their unsigned counterparts. It gets interesting when we have a zero transition. Signed six minus four is six plus minus four, which is unsigned six plus 11, which in module 16 is one. We have a carry. In once complement, a carry needs to be added to the end result. So we get two, which is correct. An overflow means that the signed result does not fit into the number space. Signed seven plus one would result in signed minus seven, which is incorrect. The same happens when overshooting negative numbers. After applying the end around carry, the result of signed seven here is incorrect. The CPU detects this and flags the result. The accumulator has an extra bit to record the information about an overflow. We call it V. So if we have code that reads the value of seven FF from memory and adds one, the result is zero and an overflow is detected. So the accumulator is flagged. The store instruction in addition to writing A to memory does extra work if there's an overflow condition. It clears the overflow condition, writes plus one or minus one into A depending on whether it's a positive or a negative overflow and skips the next instruction. This way the program can detect the overflow and use the plus one or minus one to apply the signed carry to a higher order word. By storing A to memory, there's a double word result. In one's complement negating a number is as easy as flipping every bit in a word. So there's a dedicated instruction for loading and negating a value. LDC, which stands for load complement, reads a word from memory, negates it by inverting all the bits and writes it into the accumulator. Incrementing that is adding one to a word is such a common operation that there's a dedicated instruction that increments a word in memory in place. There is no corresponding decrement instruction. Instead, there are two similar words, augment and diminish. The increment instruction adds one to the original value. The augment instruction adds one to all positive values and subtracts one from all negative values. It effectively increments the absolute value retaining the sign. The diminish instruction decrements positive values and increments negative values. Optimized for scientific calculations, the CPU has dedicated multiplication circuitry. The model instruction reads a word from memory and multiplies it with the accumulator. There are two signed 15-bit words. You need up to 29 bits. That is two words for the result. The complete result will be written into two registers, the upper half into A and the lower half into B. B is a separate 15-bit register, which is mostly used together with the accumulator with instructions that deal with 30-bit data. Double-word values are expressed with the uppermost bits in A, or if in memory at lower addresses, and the lower bits in B, or at higher addresses, making the AGC a big engine machine. Assuming the normalized number of words with matching signs, the effective value is the concatenation of the 2x14 bits of the values. Division also works with double-words. It takes the combination of the A and B registers as the dividend and a word from memory as the divisor. There are also two results, the result and the remainder. The result is written into A and the remainder into B. Some other instructions also allow using A and B as a double-word register. Load A, B, come indirect to 0, 0 looks up address to 0, 0 in memory and reads the words at A and B. The load complement variant does the same but inverts all bits during the load. There is no instruction to store A and B in a single step, but there is a double-word exchange instruction. And finally, there is an add instruction that works in double-words. And to load and store just the B register, there is an exchange instruction for that. For working with tables, there is the indexed addressing mode. Any instruction that takes an address as an argument can use it. This example, load A, write 0, 0, 0 plus indirect A to 0, first looks up address 0, 0, 0 adds it to the base of 7, 0, 0 which results in 7, 0, 2, reads from that address and writes the result into A. What does this mean? There is a table in memory at 7, 0, 0. In the example, it contains multiples of 3. And an index to that table is stored in memory at 0, 8, 0. Which in the example is 2. So we read the entry at index 2 of the table, which is 6. Without a base address, we get the syntax in this example. Load A, double indirect 8, 0. The base is effectively 0 in this case. The CPU will look up the value at 0, 8, 0 in memory, add it to the base of 0, so the value is still the same and read from that address. In this case, memory at 0, 8, 0 effectively stores what C programs know as a pointer. And 3, A, 0 is the pointer's destination. The instruction performed in indirect read. By default it is executed sequentially. The program counter PC, increments as instructions are executed, always pointing to the next instruction. Control flow instructions, like jump and conditional jump, change that. When the CPU hits a jump instruction, it will load its argument into the program counter, which means that execution will continue at that address. JZ, jump of 0, only jumps if A is 0, otherwise it continues with the next instruction. Similarly, JLEZ only jumps if A is 0. It is a four-way fork for execution. Depending on whether the value in memory is positive, negative, plus 0, minus 0, it will jump to one of the next four instructions. If you know the value is positive or 0, you can ignore the other two cases and just fill the first two slots. And if it's supposed to be only negative, you have to skip the first two slots. They should never be reached, but it's good practice for them to fill them with error handlers. Since CCS A is the absolute dimension value of the memory location into A, special case of CCSA can be used for loops that count down A. The call instruction is meant for calling subroutines, a.k.a. functions. It's like a jump instruction, but it saves its origin so the callee can return to it later. For the call instruction, the program counter is incremented first and then copied into the link register, LR. Finally, the argument of the call instruction is copied into the program counter and the register now contains the return address. At the end of the subroutine, the red instruction effectively copies the contents of the link register into the program counter so execution resumes just after the call instruction. If the subroutine wants to call its own subroutine, the program has to save the link register before it's restored afterwards. There's an exchange instruction specifically for this. For additional levels, a stack can be constructed manually using the indexing syntax. So far we've seen the following registers. The first register is used for memory accesses and all arithmetic. It is combined with a B register for double width arithmetic. The program counter keeps track of what to execute and the link register remembers the return address when calling a subroutine. We haven't seen the zero register yet. It always contains zero so when we read from it we get zero and when we write to it the value gets discarded. There are three more registers that we'll talk about later. The eight registers are numbered. That is, they are assigned memory addresses. They can be accessed using the addresses and all instructions that take a memory address. This allows for much greater flexibility in the instruction set. We can load A with the contents of the B register by reading the contents of memory at location one into A. The constant of zero can be loaded into A by just reading from memory at seven, which is the zero register. A can be incremented by incrementing memory at A and B can be used as a pointer by reading from double indirect one. Let's look at memory more closely. Memory is 4,096 words and goes from 0,0,0 to FFF. The registers are located at the very bottom of memory, including them there are 1,024 words of RAM, random access memory and three kilo words of ROM read only memory. The AGC was originally architected to only have this little RAM and ROM, but there's actually more. Let's look at the RAM area. The upper most quarter is banked. The area is a window through which one of eight different banks can be accessed with 250 words in size. The erasable bank register, EB points to one of these banks. If EB is zero, bank zero is visible in the banked area. If EB is five, bank five is visible. Addresses in the fixed area always represent the same RAM cells, but these are not additional cells, but the same as banks zero, one and two. This means that there's a total of eight times 256 words of RAM two kilo words. ROM is organized similarly. The lower kilo word is banked. The fixed bank register selects one of the 32 banks. Support for more than 32 kilo words of ROM was added at the last minute. The super bank bit can switch the uppermost eight banks to a second set so that a total of 40 kilo words are supported by the architecture. The fixed ROM area will always show the same contents as two of the ROM banks. The designers chose banks two and three to simplify addressing coding. In practice, fixed ROM contains core operating system code and fixed RAM core operating system data that have to be available at all times. The remaining functionality is distributed across the different ROM and RAM banks. Switching the RAM bank can be done by writing to the EB register. This is not a separate instruction, but can be expressed by writing A to memory location three. If A is five, writing A into EB will make RAM bank five visible at three zero zero. The same store instruction could be used to write to the FB register at memory location four to switch the code for a common case. If code in one bank wants to call code in another bank by first switching the ROM bank, load FB, and then doing the function call, writing the bank number into FB will switch out the bank the code is currently running on, so it won't be able to execute the call instruction. Instead it will continue running some unrelated code that happens to be the same address on the other bank. To call code on a different bank, FB and PC registers need to be changed atomically. Call F is only a synonym for the same exchange instruction. Code first has to load the bank and the program counter into A and B. Which then call F can automatically move into FB and PC. The same exchange instruction can be used for a far return. It moves the original values back into FB and PC. The two bank registers only hold five and three bits respectively. The other bits are zero. And there's a third bank register, BB, both banks, which merits the transfer from both other bank registers. The call for both banks synonym is a double word exchange instruction that updates the program counter and both banks. Subroutines usually have their private variables on particular RAM banks. Call for both banks passes control to a function on a different ROM bank and also directly switches RAM banks so that the colleague can immediately access its variables. Return for both banks returns to the caller restoring its RAM bank configuration. The unusual ordering will allow for a double word exchange of FB and PC as well as for a double word exchange of PC and BB. Now we've seen all eight registers. And there's eight more special locations in memory above the register, the shadow area, which we'll talk about later. And above those, there are four so-called editing registers, which make up for the missing shift and rotate instructions. When writing a 15-bit value into the ROR editing register, it will be moved to the right by one bit and the lowest bit will be cycled to the left by one bit. ROR can then be read back. ROL rotates left. SHR shifts to the right duplicating the top bit and SHR7 shifts to the right by seven bits filling the top with zero. This is needed for the interpreter system software component that we'll learn about later. We have seen that the CPU is connected to RAM and ROM, the memory bus. But computers also talk to peripheral devices. That is the IO bus. We've already seen the address space to talk to devices. There are 512 IO channels, numbered 0000 through FFF. Each channel is 15 bits and the in and out instructions can read words from and write words to IO channels. For many devices, a channel contains 15 individual control bits. A control bit can, for example, toggle a lamp on a display. The out or instruction sets individual bits and out and clears individual bits. So our instructions can work on the whole board or do Boolean operations on them. And, or, and XOR. To make Boolean operations also usable between registers, channels one and two are actually aliases of the B and LR registers. Which allows for these instructions. For end, there's also dedicated instruction that works on A and memory. After the registers, the shadow area and the editing registers, there's another special area that counters. Like IO channels, they connect to external devices but they don't send bits or whole words back and forth. Instead, they are controlled by hardware pulses or cars hardware pulses. On every pulse time one gets incremented, for example, while other counters take the numbers stored into them by code and count down generating pulses. When IO devices need to signal the CPU, they can interrupt normal execution. Next to the program counter which points to the next instruction, there's the instruction register which holds the current time. When an interrupt happens, the CPU copies PC into a special memory location, PC prime and IR into IR prime and then jumps to a magic location depending on the type of interrupt, in this example 814. When the interrupt handler is finished servicing the device, the IR instruction will copy PC prime and IR prime back into PC and IR so execution will continue at the original location. Memory locations 8 through hex F are shadows of the A registers. PC and IR are automatically saved and interrupts and the remaining registers need to be saved by software if necessary. The overflow condition flag cannot be saved or restored. So while there's an overflow condition until the next store instruction which resolves the overflow interrupts will be disabled. The 11 interrupt handlers have to reside in fixed ROMs starting at 800. There are four words for each entry. Typical interrupt entry code saves A and B. Loads B with a bank and PC of the actual handler and jumps there. Interrupt zero is special, it's the entry point on reset. Next to the interrupt return instruction there's an instruction to cause an interrupt in software and instructions to enable and disable interrupts globally. There's one more special memory location at hex 37, the watchdog. This location needs to be read from or written to at least every .64 seconds, otherwise the hardware will decide the system software is responsive and car to reset. Now we see an instruction set and in the examples we've seen the codes that represent instructions in memory. Let's look at how the encoding works. For the load instruction the upper three bits are the opcode representing the load A and the remaining 12 bits encode the address. This allows for a total of eight instructions, but there are more than eight instructions. RAM addresses always start with 00 and ROM addresses start with anything but 00. So the store instruction, which only makes sense on RAM, only needs to encode 10 address bits instead of 12. Making room for another three RAM only instructions. The same is true for the increment instruction which makes room for three more as well as CCS which shares an opcode with jump which only works on ROM addresses. Since jumps to the bank register don't make much sense, these codes are used to encode STI, CLI and extend. When the code is pre-fixed it changes the meaning of the opcode of the next instruction allowing for a second set of two word instructions. There's one more special call instruction called two, which is callLR which is the return instruction but the CPU doesn't special case this one return is a side effect of calling memory at location two. It executes the instruction encoded in the LR register the 12 bit address with the leading zero decodes into another call instruction which transfers control to the return address. Indexed addressing is achieved by using the index prefix. An indexed instruction consists of two instruction words index and the base instruction. The addressing code in the base instruction is the base address and the index instruction encodes the address of the index. Indexed is an actual instruction. The CPU reads from the given address zero at zero in the example then adds its value three to the instruction code of the following instruction three seven zero zero which is stored in the internal IR register. The resulting instruction code three seven zero three for the next instruction which is a load from seven zero three the effective address. If an interrupt occurs after the index instruction that is no problem because IR contains the effective instruction code which will be saved into IR prime and restored at the end of the interrupt handler. Finally there's one index encoding with a special meaning when the address looks like it's referencing the shadow instruction register is an interrupt return instruction. Looking at the instructions there are many quirky and unusual features when compared to modern architectures. It uses one's complement instead of two's complement it has no status register. The overflow flag can't even be saved so interrupts are disabled until the overflow is resolved. The store instruction may skip a word under certain circumstances the CCS instruction can skip several words and can be outright dangerous if the instructions follow in it use prefixes. There are no shift or rotate instructions but magic memory locations that shift and rotate when writing into them. Most Boolean instructions only work on IO channels indexing is done by hacking the following instruction code and the architecture has no concept of a stack indexing has to be used if one is needed. This was the architecture of the Apollo guidance computer now let's look at how this architecture is implemented in hardware. The hardware implementation runs at one megahertz is microcoded and uses integrated circuits core memory and core rover memory. We'll look at the block diagram and how instructions are implemented in microcode and then about how the schematics map to integrated circuits on modules on trays. This simplified block diagram shows the AGC at the hardware level. Each box contains on the order of 500 logic gates the dotted lines are wires that move a single bit of information and the solid lines are 15 wires that move a data word. These units deal with timing and control and these are the central units. The central register unit stores A, B link register and program counter and the arithmetic unit can add and subtract numbers. The memory components deal with RAM and ROM. The main clock of about one megahertz feeds into the sequence generator which keeps cycling through 12 stages which is one memory cycle MCT. Instructions usually take as many memory cycles as they need memory accesses so load add and store take two cycles and jump takes one. The sequence general contains a collection of 12 step micro programs for each MCT for each instruction like this one for the load instruction. In each step the entries send control pulses to the other units which are connected through the right bus. The control signal WA for example instructs the register units to put the contents of A onto the right bus and RA makes it read the value on the bus into A. Memory is also connected to the right bus. WS will copy the bus contents into the memory address register and RG and WG will read and write the G register which buffers the sales value after read and before write. So in stage 7 for example RG puts the memory buffer onto the bus and WB writes the bus contents into the temporary G register. And in T10 B gets put on the bus and it gets read into the A register. At the beginning of every memory cycle the hardware sends the memory address S and G to memory and copies the contents of that address into G. In the second half of the MCT it stores G back into the same cell. So if we show memory timing next to the microcode as well as the pseudocode version of the load instruction which is easy to read, we can see it loads the value from memory into G copies it into B and then copies it into A. More interesting is the exchange instruction. It saves A to B reads memory into G copies the resultant to A copies the old value into G and stores that G into memory. Division for example takes several MCT and its micro-program is way more complex. But there are more micro-programs than the ones for the machine instructions. Since there is only a single adding unit and the whole computer incrementing and decrementing the counters is done by converting the pulses into special instructions that get injected into the instruction stream. There are 14 of these so called unprogrammed sequences with their own micro-programs some counter shift, some are interacting with debugging hardware and these two control interrupt and the interrupt and reset sequences. The complete schematics are publicly available and fit on just 49 sheets. The whole implementation only uses a single type of gate, a three input NAND gate. Two of these are contained in one integrated circuit. And about 100 of these ICs form a logic module. 24 logic modules and some interface and power supply modules are connected together in Trey A which also contains the IO and debug connectors. Trey B contains various driver amplifier modules as well as RAM and ROM. RAM is implemented as magnetic core memory which stores bits in magnetized torus. Reading a bit clears it so the memory sequencer makes sure to always write the value again after reading it. Without mass storage like tape the AGC has an unusually high amount of ROM. Core rope memory encodes bits by wires that either go through just a ferrite core. The 500,000 bits per computer were woven completely by hand. Trey A and B are put together like this and termitically sealed making for a rather compact computer. This is its orientation when installed in the spacecraft with the six ROM modules accessible so they could in theory be replaced during the mission. And that was the hardware part. Next let's look at the devices connected to the computer. We will look at the quad devices that allow the Apollo guidance computer to maintain the state vector. Some quite special devices you don't see on many other computers and the peripherals used for communication with astronauts and mission control. The gyroscope is the core peripheral that the Apollo guidance computer was originally built around. The Apollo guidance computer rotates it into a certain base position with the CDU command counters and then the gyro detects rotation around the three axis of the spacecraft that can be read from the spacecraft always knows its attitude that is its orientation in space. The accelerometer measures acceleration forces on the three axis. The three values can be read from the Piper counters. The optics on the command module are used to measure the relative position to the celestial bodies. The computer uses the opt command counters to move the optics to point towards the general direction of a star and will read in the astronauts fine tuning through the opt counters. The landing radar sits at the bottom of the lunar module and the radar interrupt will be triggered whenever a new measurement is available and the R and R counter contains the new value. The lunar module's rendezvous radar measures the distance of the command and service module during rendezvous. After setting the two angles in the CDU-T and CDU-S counters to point it towards the other spacecraft it will automatically track it and cause radar interrupt interrupts when new data is available which can be read from the R and R counters. The command module, the service module and the lunar module all contain reaction control that emit small bursts for holding or charging the attitude. On the lunar module there's one bit for each of the 16 jets. Setting a bit to one will make the jet fire. The system software uses a dedicated timer time 6 and it's interrupt T6 interrupt for timing the pulses. The user interface is provided by the so-called disk key which stands for display and keyboard. It has 19 keys, 15 lamps and several numeric output lines. Keys generate the keyrupt interrupt and the key number can be read from the key in IO channel. The numeric output line can be read from the digital radio communication on S-Bunt between mission control and each spacecraft at a selectable speed of 1.9 or 51 kilobits per second. Data words from mission control show up in the in-link counter and trigger interrupt upropped. Data words to be sent are stored in the IO channel DNTM1 and the download on top will signal the program when it can load the register with the next word. These were some of the interesting peripherals. The AGC software makes it a priority-based cooperative but also preemptive, real-time interactive fault tolerant computer with virtual machine support. The topics we'll talk about are multitasking, the interpreter, device drivers and the wait list as well as the user interface and mechanisms for fault recovery. The AGC has many things to do. It does mathematical calculations that can take several seconds and it does IO with its devices. It services interrupts when a device wants the computer's attention, for example it does regular servicing of devices like updating the display and it supports real-time control like flashing a lamp or firing boosters at exactly the right time. There's only single CPU so it must switch between the different tasks. Batch processing, multitasking computers work on long-running jobs one after the other but if some jobs have higher priorities it makes more sense to run a job for only say 20 milliseconds then check the job queues and keep running the highest priority job in the queue and it's removed from the queue. Then keep picking the highest priority job. Jobs have to manually check at least every 20 milliseconds whether there's a higher priority job in the queue by doing a so-called yield which makes the AGC a priority scheduled cooperative multitasking computer. A job is described by a 12 word data structure in memory that contains the PC and both banks register that point to where the job will start or continue running. As well as a word with a disabled flag in the sign bit and a 5-bit priority. The core set consists of 7 job entries minus 0 in the priority word means that the entry is empty. Job 0 is always the currently running one. When a new job cut is created with a higher priority the yield operation will exchange the 12 words so that new job is job 0. Negating the priority will put a job to sleep so yield won't switch it again. Negating it again will wake it up. The first 8 words in the job entry can be used for local storage of the job. Since it's always job 0 that is running these words are always conveniently located at the same addresses in memory. The executive has a set of subroutines that control the job data structures. You can create a new job pointed to by a pair of PC and BB registers of a given priority, change the priority of the current job, put the current job to sleep wake up a given job and terminate the current job. Heal does not an executive function but a two instruction sequence that allows the new job variable in which the executive always holds the idea of the highest priority job. If job 0 is the highest priority job there's nothing to do. If there is a higher priority job it calls the change job subroutine which switches to that job. New job isn't just a variable in memory but also the watchdog word. If it isn't access regularly that is cooperative multitasking stuck the hardware will automatically reset itself. A lot of the code on the AGC does scientific calculations. Calculating two products of a scalar and a vector would require hundreds of instructions in AGC machine code. There's library code that provides all kinds of operations on single double or triple precision fixed point values, vectors and matrices. It also provides a software multi-purpose accumulator M-PAC which can hold a double triple or a vector depending on the mode flag. In C-like pseudocode we would load the vector into the M-PAC, multiply it with a scalar, save it, do the other multiplication and add the result to the saved value. Formulas like this one need to store intermediate results so a 38 word stack is provided. If a job uses math code the M-PAC, the mode field and the stack pointer will be stored in the remaining fields of the core set entry. The stack will be part of a data structure called VAC which will be pointed to by the core set entry. A job can be created with or without a VAC depending on which subroutine it is created with. The machine code version of the example code would be used by many function calls passing pointers. The designers of the AGC software decided to create a new and compact language that will be interpreted at runtime, a virtual machine. The interpretive language is Turing complete and in addition to the M-PAC has two index registers, two step registers and its own link register. The encoding manages to fit two seven bit op codes in one word which allows for 128 op codes and explains why there is a shift right by seven function in the CPU. The two operands are going 14 bit addresses. 14 bit addresses means interpretive code doesn't have to work with this complicated memory layout anymore. It allows addressing about half of the ROM at the same time. At the lowest kilowatt of each half RAM is visible so interpretive code can pick between one of these two memory layouts. This is the complete instruction set. Regular machine code and interpretive code can be mixed and matched inside the job. The exit instruction will continue executing regular machine code and then switch to interpretive mode. In addition to long running math tasks, the system software also supports device drivers. When a device needs the computer's attention, for example, in case of a disk key press, it causes an interrupt. The current job will be interrupted and the interrupt handler will read the device data and return as quickly as possible. If there is more to do, it can schedule a job for later. Some devices need to be serviced regularly. A 120 microsecond timer is triggered. The timer interrupt cycles through eight phases, which distributes the device drivers across time to minimize the duration of one interrupt handler. Some devices need to be driven at exact times. If, for example, a job decides that it needs to flash a lamp twice, it would turn it on immediately and schedule three weightless tasks in the next few days. If a device needs to be serviced regularly, schedule three weightless tasks in the future at specific times. The first one will turn the lamp off, the second one will turn it on again, and the third one will turn it off again. The sorted time deltas of the weightless tasks are stored in the data structure LST1, with the first entry always currently counting down in a timer register, and LST2 contains a pair of PC and BB for each task. There are subroutines to create a new task and end the current time. The timer that controls the weight list has a granularity of 10 milliseconds. Other timers can fire at the same rate, but are offset, and the work triggered by them is designed to be short enough to never overlap with the next potential timer triggered work. This is complicated by device interrupts, which can come in at any time. The duration of an interrupt handler causes latency, and the maximum duration will reduce the allowed time for the timer handlers. The core system software makes no guarantees that it's up to all the components to operate, so the real-time goal can be met. The pinball program is the shell of the AGC. He press interrupts, schedule a job that collects the digits for the command and updates an in-memory representation of what should be on the display. The 120 millisecond timer triggers the display update code. When the command is complete, pinball schedules a new job. Mission control has a remote shell in front of it, and it's connected through the S-band radio. System software that supports human life has to be able to communicate malfunctions and be able to recover from them. The alarm subroutine takes the following word from the instruction stream, displays it, and illuminates the prog light. This should be interpreted as a warning or an error message. The AGC software is full of validity and plausibility checks that help to find bugs during development and help better understanding potential issues during development. In addition to showing the error code, they also cause a hardware reset. But the system offers recovery services. A job can have recovery code for its different phases. During execution, it sets the respective phase, and if an abort happens in any job or task, the currently set up recovery routine gets executed. Which could, for example, clean up and try to work again, or skip to a different phase, or cancel the job altogether. The phase change call sets the current phase for a job in the recovery table. For example, phase 5 for job 4. Each phase is associated with a descriptor of a task or a job with or without a vac. So during normal execution, with several jobs and tasks scheduled, if an abort happens, the core set and wait list are cleared. The contents of the recovery table are activated, scheduling tasks and jobs for all jobs that set up recovery code. Sometimes of failure, though, like corrupted memory, are not recoverable. They cause a fresh start, meaning a full initialization of the system without running any recovery code. And that was the AGC system software. As we now have a good overview on architecture, hardware peripherals, and system software of the Apollo guidance computer, it's time we'll be reviewing its practical use on a mission to the moon. We will look at the user interface, the launch sequence, and once in orbit, the attitude and orbit determination. Further, we will understand how the digital autopilot works and how powered flight is being performed. As soon as we've reached the moon, we look at the lunar landing and the lunar rendezvous of the lift off. And finally, re-entry into Earth's atmosphere. Last but not least, contingencies, or as we like to call them, fun issues. Let's start with the user interface. It is like any command line interface, but since there are only numbers and no letters, keyboards have to be encoded. On a normal system, you might say, display memory, enter. Display is the verb, memory is the noun. On the Apollo guidance computer, display verb 01, which means display noun 02, memory, enter. Subprotein asks for an argument. On a normal system, it might display a prompt, you enter the number, press enter. On the Apollo guidance computer, flashing verb and noun indicate that it is waiting for input. So you type 25, enter, an octal address, and the Apollo guidance computer displays the result, the memory contents at the address octal 25. The Apollo guidance computer uses the same concept of verb and noun when it proactively displays the verb. The Apollo guidance computer asks for the CSI ignition time. CSI means coalyptic sequence initiation. We'll come to that later. A special case is when the Apollo guidance computer asks a yes or no question. The astronaut has the engine ignition with the proceed key. The astronauts have a complete reference of all verbs announced on paper, as well as cue cards with the most important information. Let's now go through each of the faces of the mission, starting with a lift off. The Apollo guidance computer has a passive monitoring mode. With the cutting of the umbilical cables, which you see right about now, it has started the mission clock. In case this trigger fails, one disk key is always prepared with verb 75 and just waiting for enter to manually start the mission timer. We can display the mission elapsed time at any time with verb 16, noun 65. During the flight with the Saturn 5, the Apollo guidance computer is only performing passive monitoring of the flight. Control of the Saturn 5 is with its own system and the instrument unit ring. The disk key automatically shows verb 16, noun 62, which is velocity in feet per second, altitude change rate in feet per second and altitude above pad and nautical miles. Note that the units at the position of the decimal point are implicit. And yes, the whole system was working in metric internally, but for the benefit of the American astronauts, the display procedures converted everything into imperial units. In case of problems with the Saturn computer, we can take over full control of the launch vehicle. In extreme cases, astronauts could even steer the whole stack into orbit themselves with the hand controller. In case you ever wanted to manually control a 110 meter tall rocket with more than 30 million Newton of thrust, this is your chance. In less than 12 minutes, we've gone through the first and second stage and are using a small burn from the third stage to get us into a 185 kilometer orbit which circuits the Earth every 88 minutes. But how do we know where we are in the right orbit? We need to know where we are. To be able to navigate in space, we need to maintain our three-dimensional position and our three-dimensional velocity, the so-called state vector. Let's start with the determination of the position. For this, we need a telescope and a space sextant. The space sextant is very similar to an 18th century nautical sextant. Position is determined by measuring the angle between the horizon and the celestial body. As a horizon, we can either take that of Earth or Earth in our bodies. We are surrounded by them. Luckily, the Apollo guidance computer already knows the position of 45 of them. The optics hardware in the command and service module can be moved to point in the general direction. With the launch of program 52, we command the Apollo guidance computer to rotate the spacecraft to point one axis of the sextant, the so-called land-mark line of sight, LLOS, to the nearest body, the Earth or Moon. The astronaut then uses the optic systems astronaut looks for one of the known stars, points the starline to it and let the Apollo guidance computer read the trunnion and shaft angle. Repeating this one or more times in a different plane gives a three-dimensional position of the vehicle in space. In the lunar module, on the other hand, the whole optics hardware was trimmed down for weight reduction. Any alignment requires rotation of the lunar module. This is mostly used to determine the landing site and support the rendezvous maneuver. It even lacks the software to perform positioning in trans-lunar space. As we're moving, our position changes all the time. But after two location fixes, as long as we're coasting, we're able to establish our speed and can determine future positions by that reckoning. As position and velocity are known, future positions can be extrapolated. Unfortunately, the near-exploitation doesn't work in space as we have gravitational forces which bend our path. Thankfully, there are two mathematical models implemented in the Apollo guidance computer, conic integration based on the Keplerian orbit model on the left, which assumes one perfectly round gravitational body influencing our flight path and anchors integrating method for perturbation, considering multiple bodies with gravitational imbalances. I think this helps to understand why we need a computer on board and can't just fly to the moon with a hand controller. As we see, the Apollo spacecraft is perfectly capable to fly on its own, but in the end, NASA decided that the primary source for state vector update shall be mission control in Houston, measured with three ground stations. Remote programming is done with the Apollo guidance computer in idle and running program 27. Mission control can use its link via S-band to update the state vector. But there's one thing mission control doesn't know better than us, and that's attitude. Attitude is the orientation of the spacecraft in its three axes. Starting from a known attitude, we have to ensure that we can measure any rotation on any axis. That's what gyros are for. They are one of the major components of the IMU, the inertial measurement unit. Three gyroscopes, one per axis, measure any rotation and provide their data to the Apollo guidance computer to keep track of the attitude of the spacecraft. Before we leave Earth orbit, let's quickly discuss the digital autopilot. It is the single biggest program in the Apollo guidance computer with about 10% of all the source code, both in the command and service module as well as the lunar module. The implementations for each vehicle are significantly different, though, due to different flight modes, thruster sets and symmetry of vehicle. As there's no friction in space, the tiniest event would constantly make the spacecraft rotate. The digital autopilot of the Apollo guidance computer uses the jets to maintain the attitude within certain thresholds, so-called dead bands. The autopilot is also used in case the astronauts ever need to use their hand controllers for thrusters, basically both the command and service module and the lunar module have fly-by-wire control. As any thruster could break at any time, the autopilot is capable of calculating the ideal burn mode even with a reduced number of thrusters. It has some simple algorithms for center of gravity and weight distribution as well, which are taken into account in calculating thruster maneuvers. It can do more than that, though. Give it a new attitude and it will calculate the most efficient transfer vector to reach the new attitude. In certain flight modes, it might be required to have a stable rotation, be it for temperature control, monitoring in the landing site or other reasons. The autopilot supports stable constant rolling, which can be directly activated. The autopilot does not only control attitude, it also supports the crew in performing powered flight maneuvers. It calculates the potential solution, which obviously can be overwritten by ground as usual, but still after confirmation, the autopilot automatically fires the engines and keeps a timer for the correct length of time. It does not measure the results of the burn, though. For powered flight, obviously dead reckoning isn't correct anymore, so the Apollo guidance computer contains a subroutine called average G, which takes the input from the IMU, meaning gyro and accelerometer, to compute the change to the state vector. Now that we know how to orient ourselves and how to control the spaceship, it's time we fly to the moon. Usually, the trans-lunar ejection happened in the middle of the second orbit around the Earth, so around two hours 45 minutes into the flight. This is still performed by the third stage of the Saturn V, so the Apollo guidance computer once again should only have a passive role here by monitoring the trans-lunar ejection with a dedicated program P-15. After separation from the S-4B, we are on our way. Since the next externalizing phase is the lunar landing, let's get right through that one. Once in lunar orbit, separation between the combined service module and lunar module happens four hours and 45 minutes before the ending. On the lunar module, directly afterwards, rendezvous equipment like radar, strobe, and VHF are tested, as well as the IMU, which is realigned. Additionally, there's lots of preparation work on the lunar module. One of the main tasks is to prepare the abort guidance system, AGS, which is another more simpler computer that is able to get the lunar module with the astronauts back into orbit and safely dock with the CSM in case of an emergency. Let's get back to power descent. The lunar module, AGS, has a special program for that one, P-60C, breaking phase. The landing radar is switched on and updates the state vector. The Apollo guidance computer controls the burn to reach the correct corridor towards the surface with a minimal amount of fuel. This is fully automatic. The astronauts just sit along for the ride. The lunar module is oriented with its descent engine towards the moon. Visibility for the astronauts is close to zero. The second program, P-64, starts automatically at around 8,000 feet. The lunar module is pitched so that the astronauts can actually see the ground, and the lunar module commander is getting a better understanding of the landing site and can search for a suitable spot. The third program, P-68, keeps the lunar module in a stable attitude above the surface, and the commander manually adjusts the height in one feet per second increments to slowly descend to the surface. Ideally, at that point, the horizontal movement of the lunar module should be zero. After touchdown, the crew manually activates program 68, which confirms to the Apollo guidance computer that, yes, we have indeed landed, ensures that the engine is switched off, terminates the average G-routine, and sets the autopilot in a very forgiving setting to avoid any corrections when it measures the rotation of the moon. The autopilot is not completely switched off, though, as the astronaut might need it in case of an emergency ascent. Well, we're on the moon, we do the usual stuff, small step for man, jump around, plant a flag, and we then skip directly to the interesting bits with this lift off and rendezvous. The rendezvous technique was developed in the Gemini project. Here you can see the Agena rendezvous target in Earth orbit. It follows the principle of an active vehicle, in this case the lunar module, which follows the command and service module and approaches it from below on a slightly faster orbit. There were actually two different ways for rendezvous. A more conservative method called coalyptic rendezvous, which required one and a half orbits for the lunar module to reach the command and service module, but gave ample opportunity for monitoring progress, mid-course corrections, and orbit scenarios. And a more risky direct rendezvous method, which directly aimed the lunar module towards the command and service module, taking less than one orbit until docking. This one was used starting from the Apollo 14 mission, as mission control had more experience and aimed for the shorter, less fuel-intensive method. Preparation had to start two hours before lift off. We have to align the IMU and we visually monitor the orbit of the CSM and calculate the rendezvous data. The Apollo guidance commuter has program 22 CSM tracking for this purpose. At lift off minus one hour, we start program 12, powered ascent, and feed it with the necessary data, lift off time and velocity targets. The Apollo guidance commuter performs the countdown, asks for confirmation, we proceed and we have lift off. The trip into orbit takes only seven and a half minutes, but depending on which method for reaching the target orbit was used, it takes us either one and a half or three and a half hours to come up behind the command and service module. During that time, program 20 is running all the time, measuring the state vector of the other vehicle, the command and service module, via various peripherals, like RONDU, RAIDA, VHF antenna, and the optic system for visual alignment. It calculates the necessary corridor and respective maneuvers required to get the lunar module into an interception course. Multiple other programs run in parallel to perform the necessary mid-curve burn maneuvers. On the command and service module, the pilot is actively tracking the lunar module the whole way up to orbit. The command and service module's computer is calculating the state vector of the lunar module to take over the role of the active vehicle in case anything goes wrong. The approach of the lunar module stops at 50 meter distance, at which point it rotates to point its docking target on top towards the command and service module. At that point in time, the command and service module takes over the active role and activates program 79, final RONDU, which slows down the command and service module to close the distance until docking. Seconds before contact, the autopilot on both spacecraft is switched off to avoid both trying to correct the attitude of the combined spacecraft. So far so good. Time to go home with a trans-Earth injection. We feed the Apollo guidance computer with Earth orbit parameters and let it calculate the burn, which is then activated and controlled. Any kind of potential mid-course corrections are performed the exact same way. Once in orbit around Earth, re-entry parameters are calculated on ground and transferred to the Apollo guidance computer via S-band uplink. The first entry program, P61, entry preparation, starts at entry minus 25 minutes. Barriers landing parameters are requested like latitude and longitude of the splash zone, as well as the velocity and angles to enter the atmosphere. Entering and confirming these values completes program 61 and starts program 62, which basically asks the astronaut to perform a checklist for manual command module, service module separation, which is not controlled by the Apollo guidance computer. After that has been performed, it switches automatically to program 63, entry initially zinged the aliization. At that point, the autopilot is taking care of thruster control to break the command module out of its orbit into Earth's atmosphere. The main programmer for re-entry is program 64, entry, which starts automatically. Program 64 monitors the trajectory and splashes down location and determines the best entry solution and potential velocity reduction by invoking two specific programs, either P65 entry up control, which basically makes the command module serve on the atmosphere to reduce speed and extend the range, or program 66, entry ballistic, throwing us through the atmosphere like a cannonball. The right mixture of the two is decided by program 64. The last program, program 67, final phase performs the final maneuvers to the splash zone. The following steps like parachute deployment and so on are not done by the Apollo guidance computer, but by the ELSC, the Earth Landing Sequence Controller. The job of the Apollo guidance computer is done before deploying the parachutes. So this was a beautiful nominal mission. What can go wrong? Well, let's start with Apollo 11, which had a 1202 program alarm during power descent. Normally, programs during power descent use about 85% of the processing power of the computer, but due to an incorrect power supply design, the roundover of the roundover radar generated an additional 12,800 involuntary instructions per seconds, ironically amounting to the exact additional 15% load. Due to the cooperative multitasking, a queue of jobs built up, which resulted in an executive overflow and the 12.02 alarm. The operating system automatically performed a program abort. All jobs were canceled and restarted. All of this took just a few seconds and landing could commence. Next, Apollo 13. They had an explosion of the oxygen tank in the service module at 55 hours, 54 minutes, 53 seconds, and yeah, correct. 320,000 kilometers from Earth. Fortunately, they could make use of the free return trajectory to get the astronauts back to Earth, but they had to move to the lunar module to survive, as the command and service module was completely shut down, including its Apollo guidance computer. The IMU settings needed to be transferred to the lunar module system first, adapted to the different orientations of the spacecraft. The manual burns and the mid-course corrections were actually done with the abort guidance system on the lunar module due to power constraints with the Apollo guidance computer. Successful reboot of the command and service module computer was luckily done hours before reentry. And last but not least, Apollo 14, which had a floating solder ball in the abort button, which might lead to an unwanted activation of abort, therefore putting the lunar module back into orbit. This was solved within hours by reprogramming the Apollo guidance computer to spoof the execution of a different program, which was not listening to the abort button during the power descent. Real abort activation, though, would have to be manually activated via the disk key. So this was an overview on how the mission software was used on a flight to the moon and back. Now you probably want to run your own code on a real Apollo guidance computer, so you need to know where to find one. 42 computers were built total. Seven lunar module computers crashed onto the moon. Three lunar module AGCs burned up in the Earth's atmosphere. 11 command module computers returned. They're all presumably parts of museum exhibits. And 21 machines were not flown. Little is known about those. One is on display at the Computer History Museum in Mountain View, California, but it is missing some components. Luckily, several emulation solutions are publicly available, as well as a tool chain. And the complete mission source, originally the size of a medium-sized suitcase, is available on GitHub. It takes a village to create a presentation. We would like to thank everyone who helped and supported us. This includes the indirect contributors who wrote the books, the original documentation, the websites, and the software. Thank you very much for your attention. Thank you. Wow, that was a densely packed talk. Thanks, Michael, and thanks, Christian, for this amazing information overload. Please give a warm hand of applause because we can't have a Q&A, unfortunately.