<i>34C3 preroll music</i>

Herald: The following talk is about a very
relevant piece of technological 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 ...
<i>laughter</i>

... for the computer part we have Michael
Steil who is the founder of the Xbox Linux

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!

<i>applause</i>

Michael Steil: Welcome! Is this on?
Can you all hear me? Yes.

Welcome to the Ultimate Apollo Guidance
Computer Talk, a.k.a. a comprehensive

introduction into computer architecture.
And operating systems. And spaceflight.

<i>laughter</i>

My name is Michael Steil ...
Christian: ... and I'm Christian Hessmann.

Michael: 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 AGC is a digital computer that
was designed from scratch specifically for

use on board of the Apollo spacecraft to
support the Apollo moon landings 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
kilowords of RAM and 36 kiloword ROM,

words of ROM. It's about the size of
a large suitcase, weighs 32 kilograms and

consumes about 55 watts. Its user
interface is a numeric display and keyboard.

Some historical context: In the
mid 1960s you couldn't just take

an off-the-shelf computer and
put it into a spacecraft.

The first mini computers were
the size of a small fridge -

too heavy, to power-hungry and too slow
for real-time scientific calculations,

even though the industry had come a long
way since the previous decade.

Already 10 years later
though, 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 to
- with the right hardware attached -

fly you to the moon.

C: In the Apollo program, the Apollo
guidance computer was used

in two unmanned test missions, where
it was remote control from the ground,

and three manned test missions, and in
the seven manned landing missions.

Astronauts hated the idea of giving up any
control to a computer,

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 the fuel
for the way back stays in orbit.

So the Apollo spacecraft can be
separated into the lunar module,

the command module and the service module.
The Saturn 5 rocket launches it and

three astronauts from Cape Kennedy
into Earth orbit.

By accelerating at the right time the
translunar 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 braking 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.

<i>Applause</i>

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 command module

and the lunar module is jettisoned. The
remaining command and service module

accelerates at the far side of the
Moon for trajectory towards Earth.

For entry, only the command module remains.
By the way, these excellent visualizations

are from Jared Owen's "How the Apollo
spacecraft works" videos,

which we can highly recommend.

The command and service
module and the lunar module each contained

one a AGC. It was the same hardware,
but attached to partially different

I/O 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 the control engine burns and

monitor or control the
Saturn V during launch.

M: 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 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 one's
complement big-endian arithmetic.

So we'll talk about the instruction set, the
arithmetic model and instruction encoding

as well as the memory model, I/O
operations and counters, and finally the

interrupt model. Machine code instruction
sets vary widely. The instruction set of a

modern ARM processor, which is mainly
optimized for runtime performance

consists of about 400 instructions. Subleq
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 constructions, that 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, I/O instructions
and instructions for dealing with interrupts.

The memory model is the cornerstone
of the instruction set. Memory consists of

4096 cells, numbered in hexadecimal
000 through FFF. Each cell contains a

15 bit word, numbered between 0 and
7FFF. Almost all changes in data -

in memory go through a 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, use K as a

placeholder for a memory address as an
argument. These are cards that are quick

reference of instructions. This is the
generic syntax of the instruction, a short

description, the exact operations in
pseudocode - this one takes a 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 designers 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
comma indirect two zero zero. 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 two
zero zero, reads its contents and copies

it into the accumulator. This is the store
instruction "store", a load indirect two

zero zero comma A. Like with all
instructions the first argument is the

destination - memory - the second one the
source - the accumulator. It looks up

address two 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 a 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
memory dest and subtracts it from the

content of the accumulator and stores the
result back into the accumulator.

The result of every subtraction can be
negative, so we need to talk about how

negative numbers are expressed on the AGC.
Let's look at just 4 bit numbers.

4-bit unsigned integers can express values
from 0 to 15 with sign and value encoding

the uppermost bit corresponds to the sign,
and the remaining 3 bits represent the

absolute value. Consequently, there are
separate values for plus 0 and minus 0.

This encoding is hard to work with, since
the 0 transitions need to be special

cased. One's Complement encoding has the
order of the negative numbers reversed.

The 0 transitions are simpler now, but
there's still two representations of 0.

Modern Two's Complement encoding only has
a single encoding for 0, and it's fully

backwards compatible with unsigned
addition and subtraction. In the 1960s,

computers designed for scientific
calculations are usually One's Complement

and so is the AGC. Unsigned four bit
numbers can express values from 0 to 15.

In One's Complement the values 0 through 7
match the unsigned values 0 through 7, and

the negative size side is organized like
this: Unlike Two's 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 0

are plus 0, with all 0 bits, and minus 0,
with all 1 bits. Addition in the positive

space is equivalent to the unsigned
version, same in the negative space when

mapping signed negative numbers to their
unsigned counterparts. It gets interesting

when we have a 0 transition. Signed 6 - 4
is 6 + (-4) which is unsigned 6 + 11,

which in modulus 16 is 1. We have a carry.
In One's Complement, a carry needs to be

added to the end result, so we get two,
which is correct. The trick to jump over

the duplicate 0 on a zero-transition
by adding the carries is called

the 'end-around-carry'.

An overflow means that the signed result
does not fit into the number space.

Signed 7 + 1 would result in signed -7,
which is incorrect. The same happens

when overshooting negative numbers. After
applying the end-around carry, the result

of signed 7 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 7FFF from memory and adds 1, the result

is 0 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 1 or minus 1 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 1 or

minus 1 to apply the signed carry to a
higher-order word. By storing A to memory,

we now have 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 dedicatet 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 1 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 instructions:

augment and diminish. The increment
instruction adds one to the original value,

the augment instruction adds one
to all positive values and

subtracts 1 from all negative values.
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.
When you multiply 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 endian machine. Assuming the

normalized form, with matching signs, the
effective value is the concatenation of

the two times 14 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 in to B.

Some other instructions also allow
using A and B as a double word register.

Load a b comma indirect two zero zero
looks up addresse two zero zero in

memory and reads the words at this
and the next cell into 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's

an add instruction that works in double
words. And to load and store just the B

register there's an exchange instruction
for that. For working with tables there's

the indexed addressing mode. Any
instruction that takes an address as an

argument can use it. This example 'load A
comma indirect 7 0 0 plus indirect 8 0'

first looks up address 0 8 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's 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 comma double indirect 8 0.
The base is effectively zero 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 programmers know

as a pointer, and 3A0 is the pointer's
different destination.

The instruction performed it indirectly.

By default, instructions are
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 if zero, only jumps if A is zero.
Otherwise it continues with the next

instruction. Similarly, jlez only jumps if
A is negative or zero.

CCS count compare and skip, is a fun one.
It's a four-way fork for execution.

Depending on whether the value in
memory is positive, negative,

plus minus - plus zero, minus zero, it will
jump to one of the next four instructions.

If you know the value is
positive or zero, 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 also puts
the absolute diminished value of the

memory location into A, so it decrements
A, a special case of CCS A can be used for

loops that count down A. The call
instruction. Isn't it for calling

subroutines aka 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, so that

execution continues there. The link
register now contains the return address.

At the end of the subroutine, the RET
instruction effectively copies the

contents of the linked 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,

and restore it 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 A register is used for

memory accesses and all arithmetic. It is
combined with the B register for double

width arithmetic, the program counter to
keep 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 will talk about later. The eight
registers are numbered, that is they are

assigned memory addresses. This means that
the first eight words in memory are

actually occupied by the registers. 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 1 into A. The content of zero can

be loaded into A by just reading from
memory at 7, which is the zero register.

A can be incremented by incrementing
memory at zero and B can be used as

a pointer by reading from double indirect
one. Let's look at memory more closely.

Memory is 4096 words and goes from
000 to FFF. The registers are located at

the very bottom of memory. Including them,
there are 1024 words of RAM,

random access memory, and
three kilowords 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 uppermost quarter is banked. The area
is a window through which one of eight

different banks can be accessed, each 250
words in size. The erasable Bank register

EB points to one of these banks. If EB is
0, Bank 0 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 8 times 256 words of

RAM, two kilowords. ROM is organized
similarly. The lower kiloword is banked.

The fixed bank register FB selects one of
the 32 banks. Support for more than 32

kilowords of ROM was added at the last
minute. The 'superbank' bit can switch the

uppermost eight banks to the second set..
<i>laughter</i>

so that a total of 40 kilowords 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 address encoding. 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 through 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
3 0 0. The same store instruction could be

used to write to the FB register at memory
location 4, to switch the ROM Bank. But

that wouldn't work 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
completely unrelated code that happens

to get 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 existing double word

exchange instruction. Code first has to
load the bank and the program counter into

A and B. Which then call f can atomically
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

merges the information from both other
bank registers. The call far 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 the

different ROM Bank and also directly
switches RAM banks, so that the callee can

immediately access its variables. Return
for both banks returns to the caller,

restoring its RAM Bank configuration. The
unusual ordering of the bank registers was

chosen to 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. There's eight more

special locations in memory above the
registers, 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 top.
The result can then be read back.

ROL rotates left, SHR shifts to the right
duplicating the top bit, and SHR7 shifts

to the right by 7 bits, filling the top
with zeros. 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 over
the memory bus, but computers also talk to

peripheral devices that is the I/O bus.
We've already seen the address space for

memory; there is a second address space
to talk to devices. There are 512 I/O

channels numbered 000 through FFF. Each
channel is 15 bits, and the in and out

instructions can read words from -, and
write words to I/O 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
I/O instructions can work on the whole

word or do boolean operations on them:
AND, OR and XOR. To make boolean

operations also usable between registers,
channels 1 and 2 are actually aliases of

the B and LR registers, which allows for
these instructions. For AND there's also a

dedicated instruction that works on A and
memory. After the registers, the shadow

area, and the editing registers, there's
another special area: the counters. Like

I/O channels, they connect to external
devices but they don't send bits or hold

words back and forth, instead they are
controlled by hardware pulses, or cause

hardware pulses. On every pulse, TIME1
gets incremented for example, while other

counters take the number stored into them
by code and count down, generating pulses.

When I/O devices need to signal the CPU,
thay can interrupt normal execution.

Next to the program counter, which points
to the next instruction, there's the

instruction register which holds the
current opcode. When an interrupt happens,

the CPU copies PC into a special memory
location PC' and IR into IR' and then

jumps to a magic location depending on the
type of interrupt, in this example 814.

When the interrupt handlers finished
servicing the device the iret instruction

will copy PC' and IR' back into PC and IR,
so execution will continue at the original

location. Memory locations eight through
hex F are shadows of the eight registers.

PC and IR are automatically saved by
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 offload,
interrupts will be disabled.

The 11 interrupt handlers have to reside
in fixed ROM starting at 8 0 0.

There are 4 words for each entry.
Typical interrupt entry code saves A and B,

loads A and B with a bank and PC of the
actual handler and jumps there.

Interrupt 0 is special: it's the
entry point on reset.

Next we will enter the interrupt return
instruction, there's an instruction

to cause an interrupt in software,
and instructions to enable and

disable interrupts globally. There is one
more special memory location at hex 37,

the watchdog. This location needs to be
read from or - read from or written to -

at least every 0.64 seconds
otherwise the hardware will decide the

system software is unresponsive and cause
a reset. Now we've seen 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. 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 zero zero and

ROM adresses start with anything but
zero zero. 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. Extend is a prefix.

It changes the meaning of the opcode
of the next instruction ...

<i>laughter</i> ... allowing for a
second set of two-word instructions.

There's one more special call instruction
'call 2' which is 'call LR',

which is the return instruction. But
the CPU doesn't special case this one.

Return is a side-effect of calling memory
at location 2. It executes the instruction

encoded in the LR register, the 12 bit
address with the leading zeros 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. Index is an
actual instruction. The CPU reads from the

given address, 0 8 0 in the example, then
adds its value, 3, to the instruction code

of the following instruction 3 7 0 0 which
is stored in the internal IR register.

Then it uses the resulting instruction
code 3 7 0 3 for the next instruction,

which is a load from 703, the effective
address. If an interrupt occurs after in

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 it's an interrupt return
instruction. Looking at the instruction

set architecture as a whole, 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 destruction can skip several words

and can be outright dangerous if the
instructions following 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 I/O

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 micro coded and uses
integrated circuits, core memory, and core

rope memory. We'll look at the block
diagram and how instructions are

implemented in micro code, 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 to move a single bit
of information, 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 registers,

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 twelve 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 generator 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 write bus. The control signal
WA for example instructs the register unit

to put the contents of A onto the write
bus, and RA makes it read the value on the

bus into A. Memory is also connected to
the write 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 cells value
after read and before a 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,
usually what's encoded instruction, 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

easier 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 result into A, copies the old

value into G, and stores that G into
memory. Division for example takes several

MCT and it's 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 in 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 for interacting with

debugging hardware, and these two control
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 a hundred of

these ICs form a logic module.

24 logic modules and some interface and
power supply modules are connected

together in tray A, which also contains
the I/O and debug connectors.

Tray B contains various driver and amplifier
modules, as well as RAM and ROM.

RAM is implemented as magnetic core memory,
which stores bits in magnetized toroids.

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- or past a ferrite core.
The 500,000 bits per computer were woven

completely by hand. Trays A and B are put
together like this and hermetically

sealed, making for a rather compact
computer. This is its orientation when

installed on the spacecraft, with the six
ROM modules accessible so they could in

theory be replaced during the mission. And
that was the hardware part.

<i>applause</i>
C: Next let's look at the devices.

<i>applause</i>

Let's look at the devices connected
to the computer.

We will look at the core 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 axes of the
spacecraft that can be read from the CDU

counters. Using the gyroscope, the
spacecraft always knows it's attitude,

that is its orientation in space. The
accelerometer adjust acceleration forces

on the three axis. The three values can be
read from the PIPA 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

measures the distance to the ground. The
RADARUPT interrupt will be triggered

whenever a new measurement is available,
and the RNRAD counter contains the new

value. Lunar module's rendezvous radar
measures the distance of the command and

service module during rendezvous. After
setting the two angles and the CDUT and

CDUS counters to point it towards the two
other spacecraft, it will automatically

track it and cause RADARUPT interrupts
when new data is available, which can be

read from the RNRAD counters. The command
module, the service module, and the lunar

module all contain reaction control
system, RCS, jets that emit small bursts

for holding or charging the attitude. On
lunar module, there's one bit for each of

the sixteen jets. Setting a bit to one
will make the jet fire.The system software

uses a dedicated timer, TIME6, and it's
interrupt T6RUPT for timing the pulses.

The user interface is provided by the so
called DSKY which stands for display and

keyboard. It has 19 keys, 15 lamps, and
several numeric output lines.

Keys generate the KEYRUPT interrupts and
the key number can be read

from the KEYIN I/O channel. The numeric
display is driven by the OUT O channel.

There is bidirectional digital radio
communication and S-band between

Mission Control and each spacecraft at a
selectable speed of 1.9 or 51 kbit/s

Data words from Mission Control show up
in the INLINK counter and

trigger interrupt UPRUPT. Data words to be
sent are stored in the I/O channel DNTM1

and the DOWNRUPT interrupt will signal
the program when it can load

the register with the next word. These
were some of the interesting peripherals.

M: The AGC system, the AGC system software

makes it a priority based cooperative -
but also pre-emptive - real-time

interactive fault tolerant computer with
virtual machine support. The topics we'll

talk about are multitasking, the
interpreter, device drivers, and the

waitlist, 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 I/O with its
devices; it services interrupts when a

device wants the computers attention, for
example a key press. 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 a 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
until it terminates and is 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 doing a so-called 'yield',

which makes the AGC a priority scheduled
cooperative multitasking computer.

A job is described by 12 word data
structure in memory, that contains

the PC and both bank's 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 seven
job entries. Minus zero in the priority

word means that the entry is empty. Job
zero is always the currently running one.

When a new job gets created with a higher
priority, the yield operation will

exchange the 12 words so that new job is
job zero. Negating the priority will put a

job to sleep, so yield won't switch to it
again. Negating it again will wake it up.

The first eight words in the job entry can
be used for local storage for the job.

Since it's always job zero 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.
Yield is not an executive function, but a

two instruction sequence that checks the
new job variable in which the executive

always holds the idea of the highest
priority job. If job zero 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. NEWJOB isn't just a variable

in memory, but also the watchdog word. If
it isn't accessed regularly, that is

cooperative multitasking is stuck, the
hardware will automatically reset itself.

A lot of the code in the AGC does
scientific calculations, calculating for

example just the sum of two products of a
scalar and a vector would require hundreds

of instructions in AGC machine code. There
is library code that provides all kinds of

operations on single, double, or triple
precision fixed point values, vectors, and

matrices. It also provides a softer multi-
purpose accumulator, MPAC, which can hold

a double, triple, or a vector, depending
on the mode flag. In C-like pseudo code we

would load the vector into the MPAC,
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
thirty-eight word stack is provided. If a

job uses math code, the MPAC, 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 tructure 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 still be very

verbose, with 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 MPAC it 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 stored in the following two

words, allowing 14 bit addresses. 14 bit
addresses means interpretive code doesn't

have to work this complicated memory layer
anymore. It allows addressing about half

of the ROM at the same time. At the lowest
kiloword 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, interpretive code can be mixed and

matched inside the job. The exit
instruction will continue executing

regular machine code at the next address,
and CALL INTPRET will similarly switch to

interpreter mode. In addition to long-
running math tasks, the system software

also supports device drivers. When a
device needs the computers attention, for

example in case of a DSKY 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's more to
do, it can schedule a job for later. Some

devices need to be serviced regularly. A
120 microsecond timer causes interrupts

that read data and write data... that read
data from and write data to certain

devices. The numeric display of the DSKY
for example only allows updating a few

digits at a time, so its driver is
triggered by the 120 microsecond timer.

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 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 task. The
timer that controls the wait 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 about the

timing, it's all up to components to...
it's up to all the components to cooperate

so the real time goal can be met. The
PINBALL program is the shell of the AGC.

Key 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 form of a

DSKY 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 the mission.

Some kinds of failures triggered by
various hardware watchdogs or by code

make it impossible for normal operations
to continue. In addition to showing

the error code, they also cause a hardware
reset but the system software also 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 the 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 a 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.

C: As we now have a good overview on
architecture, hardware, peripherals, and

system software of the Apollo Guidance
Computer, it's time briefly view on it's

practical use on a mission to the moon. We
will look at the user interface, the

launch sequence, and, once in orbit, the
attitude in 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 after liftoff 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,
key words 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 you say

verb '0 1', which means 'display', noun
'0 2' - 'memory' - 'enter'.

Subroutine 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 is waiting
for input. So you type '2 5', 'enter';

an octal address, and the Apollo Guidance
Computer displays the result.

The memory contents at the address octal
'2 5'. The Apollo Guidance Computer uses

the same concept of verb and noun when
it proactively asks for input.

Verb '6', noun '11' asks for the CSI
ignition time. CSI meaning

Coelliptic Sequence Initiation, we will
come to that later. Special case is when

the Apollo Guidance Computer asks a
yes-or-no question. Verb 99 has the

astronaut confirm engine ignition
with a proceed key.

The astronauts have a complete reference of
all verbs and nouns on paper,

as well as cue cards were the most
important information.

Let's now go through each of the phases
of the mission, starting with a liftoff.

So, we are on our way.
The Apollo Guidance Computer is

in 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 DSKY 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 SaturnV, the Apollo

Guidance Computer is only performing
passive monitoring of the flight. Control

of the SaturnV is with its own launch
vehicle digital computer, and the

instrument unit ring. The DSKY
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 and 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 to imperial units.
<i>laughter and applause</i>

In case of problems with the Saturn
computer, the Apollo Guidance Computer 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 fly... to manualyl
control a 110 meter tall rocket with more

than 30 million Newton of thrust, this is
your chance.

<i>laughter</i>
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 circles
the earth every 88 minutes.

But how do we know where ...
we are in the right orbit?

Well the Apollo guidance computer, as well
as Mission Control, are monitoring

position and velocity, because to get
where we want to be, we first 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 a
celestial body. As an horizon we can

either take that of Earth or Moon and
celestial bodies - well we are in orbit,

we are surrounded by them. So let's just
pick one. Luckily the Apollo guidance

computer already knows the position of 45
of them. The whole optics hardware and the

command and service module can be moved to
point in the general direction of Earth

and moon. 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 landmark line-

of-sight, LLOS, to the nearest body, which
is earth or moon. The astronaut then used

the optics systems to exactly align the
horizon to the LLOS. With the telescope

the astronaut looks for one of the known
stars, points the star line to it and lets

the Apollo guidance computer read the
tuning 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 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

maneuvre. It even lacks the software to
perform positioning in translunar space.

As we are moving, our position changes all
the time. But after 2 location fixes, as

long as we're coasting, we are able to
establish our speed and can determine

future positions by dead reckoning. As
position and velocity are known, future

positions can be extrapolated.
Unfortunately the near extrapolation

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

Encke's 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 was perfectly
capable to fly on its own, but in the end

NASA decided that the primary source for
state vector updates 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 axis. 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 component 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 the hand controllers for thrusters.
Basically both the command 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 when 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 of 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 a 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 translunar
injection happens in the middle of the

second orbit around the earth, so around 2
hours 45 minutes into the flight. This is

still performed by the third stage of the
SaturnV so the Apollo Guidance Computer

once again should only have a passive role
here by monitoring the translunar

injection with the dedicated program P 15.
After separation from the S-IV-B

we are on our way. Since the next
interesting phase is the lunar

landing, let's skip to that one. Once in
lunar orbit, separation between the

command and service module and lunar
module happens four hours and 45 minutes

before landing. 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 docked with the CSM in
case of an emergency. Let's get back to

powered descent. The lunar module AGC has
a special program for that one, P 63,

braking phase. The landing radar has
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. 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, and
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 are on the moon,
we do the usual stuff, small step for man,

jump around plant the flag, and we then
skip directly to the interesting bits

which is liftoff 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 at

slightly faster orbit. There were actually
two different ways for rendezvous. A more

conservative method called Coelliptic
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 liftoff. We have to
align the IMU and we visually monitor the

orbit of the CSM and calculate the
rendezvous data. The Apollo Guidance

Computer has program 22, CSM tracking, for
this purpose. At liftoff minus one hour,

we start program 12, powered ascent, and
feed it with the necessary data, liftoff

time and velocity target. The Apollo
Guidance Computer performs the countdown,

and ask for confirmation, we proceed and
we have liftoff.

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 rendezvous

radar, 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-course burn maneuvers.
On the commander of 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
service module takes over the active role

and activates program 79, final
rendezvous, 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 the

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 a S-band uplink. The first

entry program, P 61, entry preparation,
starts at entry minus 25 minutes. Various

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

initialization. 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 program for re-entry is program 64,
entry, which starts automatically. Program

64 monitors the trajectory, and splashdown
location, and determines the best entry

solution and potential velocity reduction
by invoking two specific programs, either

P 65, entry up control, which basically
makes the current module surf 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 down.
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
drop 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 12 02 program alarm during

powered descent. Normally programs during
powered descent use about 85% of the

processing power of the computer, but due
to an incorrect power supply design, the

rendezvous... of the rendezvous radar
generated an additional twelve thousand

eight hundred involuntary instructions per
seconds, ironically amounting to the exact

additional 15 percent load.
Due to the co-operative multitasking, a

queue of jobs build up, which resulted in
executive overflow and the 12 02 alarm.

The operating system automatically
performed a program abort, all jobs were

cancelled 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 it will ... yep, 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 re-
entry. 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 powered
descend. Real abort activation though

would have to be manually activated via
the DSKY. So this was an overview and how

the mission software was used on a flight
to the moon and back.

<i>applause</i>

M: 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 AGC's 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.
<i>laughter</i>

<i>applause</i>

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.
C: Thank you.

<i>applause and cheering</i>

Herald: Wow that was a densely packed talk.
<i>laughter</i>

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.

<i>applause</i>

<i>postroll music</i>

<i>subtitles created by c3subtitles.de
in the year 2018</i>