WEBVTT
00:00:00.000 --> 00:00:14.610
34C3 preroll music
00:00:14.610 --> 00:00:21.220
Herald: The following talk is about a very
relevant piece of technological legacy of
00:00:21.220 --> 00:00:27.990
our human race. The first piece of
computer that landed on our moon and
00:00:27.990 --> 00:00:33.619
actually it became a metric. People
started to compare other architectures,
00:00:33.619 --> 00:00:40.610
other computers in volumes of multiples of
processing speed of this computer. It's
00:00:40.610 --> 00:00:46.100
rocket science, but it's even harder: it's
computer rocket science. So I'm very happy
00:00:46.100 --> 00:00:50.920
to have Christian Hessmann, or Hessie, on
stage who is actually a rocket scientist.
00:00:50.920 --> 00:00:52.799
And for the ...
laughter
00:00:52.799 --> 00:00:58.249
... for the computer part we have Michael
Steil who is the founder of the Xbox Linux
00:00:58.249 --> 00:01:02.670
project and has gathered with this project
and many others lots and lots of
00:01:02.670 --> 00:01:06.520
experience around architectures of
computers. So please give a warm round of
00:01:06.520 --> 00:01:09.550
applause for the Ultimate
Apollo Guidance talk!
00:01:09.550 --> 00:01:18.060
applause
00:01:18.060 --> 00:01:22.659
Michael Steil: Welcome! Is this on?
Can you all hear me? Yes.
00:01:22.659 --> 00:01:27.140
Welcome to the Ultimate Apollo Guidance
Computer Talk, a.k.a. a comprehensive
00:01:27.140 --> 00:01:32.359
introduction into computer architecture.
And operating systems. And spaceflight.
00:01:32.359 --> 00:01:34.159
laughter
00:01:34.159 --> 00:01:37.590
My name is Michael Steil ...
Christian: ... and I'm Christian Hessmann.
00:01:37.590 --> 00:01:42.100
Michael: This talk is number six in a series
by various people. The idea is to explain as
00:01:42.100 --> 00:01:46.490
much as possible about a classic computer
system in 60 minutes. The Apollo Guidance
00:01:46.490 --> 00:01:50.860
Computer AGC is a digital computer that
was designed from scratch specifically for
00:01:50.860 --> 00:01:54.580
use on board of the Apollo spacecraft to
support the Apollo moon landings between
00:01:54.580 --> 00:02:01.919
1969 and 1972. Developed at MIT between
1961 and 1966 a total of 42 AGCs were
00:02:01.919 --> 00:02:06.650
built at a cost of about $200,000 each.
The base clock is about one megahertz,
00:02:06.650 --> 00:02:11.289
all data is 15 bits, and there are two
kilowords of RAM and 36 kiloword ROM,
00:02:11.289 --> 00:02:16.480
words of ROM. It's about the size of
a large suitcase, weighs 32 kilograms and
00:02:16.480 --> 00:02:22.130
consumes about 55 watts. Its user
interface is a numeric display and keyboard.
00:02:22.130 --> 00:02:27.080
Some historical context: In the
mid 1960s you couldn't just take
00:02:27.080 --> 00:02:29.580
an off-the-shelf computer and
put it into a spacecraft.
00:02:29.580 --> 00:02:31.771
The first mini computers were
the size of a small fridge -
00:02:31.771 --> 00:02:36.320
too heavy, to power-hungry and too slow
for real-time scientific calculations,
00:02:36.320 --> 00:02:40.040
even though the industry had come a long
way since the previous decade.
00:02:40.040 --> 00:02:43.110
Already 10 years later
though, microcomputers with highly
00:02:43.110 --> 00:02:46.820
integrated circuits started outclassing
the AGC Hardware in many regards.
00:02:46.820 --> 00:02:49.960
There are many reasons that make the AGC
especially interesting:
00:02:51.420 --> 00:02:55.630
The architecture is very 60s and feels
very alien to us today,
00:02:55.630 --> 00:02:58.060
the hardware is very innovative for its time.
00:02:58.060 --> 00:03:01.560
It has some very interesting
and unusual peripherals.
00:03:01.560 --> 00:03:04.770
Its operating system was revolutionary
for its time and
00:03:04.770 --> 00:03:07.880
the mission software has all the bits to
- with the right hardware attached -
00:03:07.880 --> 00:03:09.390
fly you to the moon.
00:03:10.710 --> 00:03:13.360
C: In the Apollo program, the Apollo
guidance computer was used
00:03:13.360 --> 00:03:16.700
in two unmanned test missions, where
it was remote control from the ground,
00:03:16.700 --> 00:03:21.060
and three manned test missions, and in
the seven manned landing missions.
00:03:21.060 --> 00:03:24.500
Astronauts hated the idea of giving up any
control to a computer,
00:03:24.500 --> 00:03:27.120
they wanted to be in charge.
And while as a fallback,
00:03:27.120 --> 00:03:29.170
most of the mission could also
be flown manually,
00:03:29.170 --> 00:03:30.910
the mission planners got their way.
00:03:30.910 --> 00:03:33.420
To understand the purpose
and the responsibilities of the
00:03:33.420 --> 00:03:36.070
Apollo Guidance Computer, we need to
first look at the Apollo mission.
00:03:36.070 --> 00:03:38.980
The core strategy of the Apollo program
was, instead of landing
00:03:38.980 --> 00:03:42.390
the complete spacecraft on the moon,
for which an extremely large rocket
00:03:42.390 --> 00:03:45.240
would have been required, to only
land a much smaller lander
00:03:45.240 --> 00:03:48.750
while the larger part with the fuel
for the way back stays in orbit.
00:03:48.750 --> 00:03:51.870
So the Apollo spacecraft can be
separated into the lunar module,
00:03:51.870 --> 00:03:56.330
the command module and the service module.
The Saturn 5 rocket launches it and
00:03:56.330 --> 00:03:59.140
three astronauts from Cape Kennedy
into Earth orbit.
00:03:59.140 --> 00:04:02.970
By accelerating at the right time the
translunar injection moves the spacecraft
00:04:02.970 --> 00:04:06.750
into a so-called free return orbit,
but just coasting it would travel
00:04:06.750 --> 00:04:09.050
around the moon and back to earth.
00:04:09.050 --> 00:04:11.950
Right at the beginning of this three-day journey
the command and service module
00:04:11.950 --> 00:04:17.190
extracts the lunar module and docks with it.
By braking on the far side of the moon the
00:04:17.190 --> 00:04:22.350
spacecraft enters a lunar orbit. After two
of the astronauts have climbed into the
00:04:22.350 --> 00:04:26.590
lunar module, and after undocking, the
lunar module breaks - this is called
00:04:26.590 --> 00:04:32.850
powered descent - and lands.
00:04:32.850 --> 00:04:36.240
Applause
00:04:36.240 --> 00:04:40.020
After taking off again, the lunar module
rendezvous with the command and service
00:04:40.020 --> 00:04:43.220
module and the two astronauts from the
lunar module climb into the command module
00:04:43.220 --> 00:04:47.240
and the lunar module is jettisoned. The
remaining command and service module
00:04:47.240 --> 00:04:50.520
accelerates at the far side of the
Moon for trajectory towards Earth.
00:04:50.520 --> 00:04:55.010
For entry, only the command module remains.
By the way, these excellent visualizations
00:04:55.010 --> 00:04:58.140
are from Jared Owen's "How the Apollo
spacecraft works" videos,
00:04:58.140 --> 00:05:00.971
which we can highly recommend.
00:05:00.971 --> 00:05:03.530
The command and service
module and the lunar module each contained
00:05:03.530 --> 00:05:07.190
one a AGC. It was the same hardware,
but attached to partially different
00:05:07.190 --> 00:05:11.040
I/O devices, and with the software
adapted for the specific spacecraft.
00:05:11.040 --> 00:05:15.250
The astronauts interact with them through
the display and keyboard units, which are
00:05:15.250 --> 00:05:18.870
mounted alongside these
hundreds of switches.
00:05:18.870 --> 00:05:22.590
The computer's responsibilities
during the mission are to track
00:05:22.590 --> 00:05:26.200
the position and speed, the so called
state vector of both spacecraft,
00:05:26.200 --> 00:05:30.450
stabilize the spacecraft's attitude,
calculate the control engine burns and
00:05:30.450 --> 00:05:34.730
monitor or control the
Saturn V during launch.
00:05:36.810 --> 00:05:40.280
M: In order to understand how the Apollo
guidance computer does all this,
00:05:40.280 --> 00:05:43.900
we'll look at its architecture, the
hardware implementation, some of its
00:05:43.900 --> 00:05:47.520
interesting peripherals, the system
software as well as ...
00:05:47.520 --> 00:05:50.340
the system software as well as
the mission software.
00:05:50.340 --> 00:05:55.290
The architecture of the
AGC can be described as a Von Neumann
00:05:55.290 --> 00:05:59.370
accumulator machine with 15 bit one's
complement big-endian arithmetic.
00:05:59.370 --> 00:06:03.200
So we'll talk about the instruction set, the
arithmetic model and instruction encoding
00:06:03.200 --> 00:06:06.690
as well as the memory model, I/O
operations and counters, and finally the
00:06:06.690 --> 00:06:11.741
interrupt model. Machine code instruction
sets vary widely. The instruction set of a
00:06:11.741 --> 00:06:14.300
modern ARM processor, which is mainly
optimized for runtime performance
00:06:14.300 --> 00:06:18.730
consists of about 400 instructions. Subleq
is a language mostly of academic interest,
00:06:18.730 --> 00:06:22.010
that shows that a single instruction can
be enough to solve the same problems as
00:06:22.010 --> 00:06:25.990
all other turing-complete languages. While
a more complex constructions, that can
00:06:25.990 --> 00:06:30.740
achieve higher code density and contribute
to higher performance, it also generally
00:06:30.740 --> 00:06:34.600
means that the CPU will be drastically
more complex. A computer from the early
00:06:34.600 --> 00:06:38.250
1960s consisted of only a few thousand
transistors as opposed to today's
00:06:38.250 --> 00:06:42.970
billions, which is why this is the sweet
spot for the AGC. 36 instructions provided
00:06:42.970 --> 00:06:46.790
just about the performance that was
required for the mission. These are the 36
00:06:46.790 --> 00:06:50.770
instructions: some load and store
instructions, arithmetic and logic,
00:06:50.770 --> 00:06:56.120
control flow instructions, I/O instructions
and instructions for dealing with interrupts.
00:06:56.120 --> 00:06:59.931
The memory model is the cornerstone
of the instruction set. Memory consists of
00:06:59.931 --> 00:07:04.991
4096 cells, numbered in hexadecimal
000 through FFF. Each cell contains a
00:07:04.991 --> 00:07:10.710
15 bit word, numbered between 0 and
7FFF. Almost all changes in data -
00:07:10.710 --> 00:07:15.960
in memory go through a 15 bit accumulator,
also called the A register. A program can
00:07:15.960 --> 00:07:19.080
copy words between the accumulator and a
memory cell, but also add, subtract,
00:07:19.080 --> 00:07:23.340
multiply and divide values, as they are
moved around. The data in memory can have
00:07:23.340 --> 00:07:26.690
many meanings, depending on how it is
interpreted. These values may represent
00:07:26.690 --> 00:07:29.740
integers, while those three words are
meant to be decoded as machine code
00:07:29.740 --> 00:07:33.090
instructions. Code and data in a single
address space make the AGC a so-called Von
00:07:33.090 --> 00:07:38.140
Neumann machine. The CPU's program counter
PC always holds the address of the
00:07:38.140 --> 00:07:42.310
instruction to be executed next. The
'load' instruction copies the contents of
00:07:42.310 --> 00:07:46.200
a given memory cell into the accumulator.
The PC goes on to the next instruction.
00:07:46.200 --> 00:07:50.220
The 'add' instruction adds contents of a
given memory cell to the accumulator, and
00:07:50.220 --> 00:07:53.159
the 'store' instruction copies the value
in the accumulator into memory at a given
00:07:53.159 --> 00:07:57.830
location. The generalized version of these
instructions we just saw, use K as a
00:07:57.830 --> 00:08:02.729
placeholder for a memory address as an
argument. These are cards that are quick
00:08:02.729 --> 00:08:08.120
reference of instructions. This is the
generic syntax of the instruction, a short
00:08:08.120 --> 00:08:11.460
description, the exact operations in
pseudocode - this one takes a memory
00:08:11.460 --> 00:08:15.190
address k and adds it to a, the
accumulator - the encoding of the
00:08:15.190 --> 00:08:19.639
instruction in memory, and the number of
clock cycles. The original syntax is the
00:08:19.639 --> 00:08:22.949
name the original designers gave to the
instruction. For this talk I have chosen a
00:08:22.949 --> 00:08:27.400
more modern syntax, here on the right,
which makes it much more easier, much
00:08:27.400 --> 00:08:30.990
easier to describe the CPU both to people
with and without a background in machine
00:08:30.990 --> 00:08:34.719
programming. Let's have a look at the
instruction set in detail. Here's an
00:08:34.719 --> 00:08:39.039
example of the load instruction. Load a
comma indirect two zero zero. On the left
00:08:39.039 --> 00:08:42.818
you see the set of registers of the AGC.
Most operations work with the accumulator,
00:08:42.818 --> 00:08:47.069
so we will be ignoring the other registers
for now. While executing this instruction,
00:08:47.069 --> 00:08:50.779
the CPU looks at memory at location two
zero zero, reads its contents and copies
00:08:50.779 --> 00:08:55.670
it into the accumulator. This is the store
instruction "store", a load indirect two
00:08:55.670 --> 00:08:59.009
zero zero comma A. Like with all
instructions the first argument is the
00:08:59.009 --> 00:09:03.041
destination - memory - the second one the
source - the accumulator. It looks up
00:09:03.041 --> 00:09:06.490
address two zero zero in memory and copies
the contents of the accumulator to that
00:09:06.490 --> 00:09:10.110
cell. There's also an exchange
instruction which can atomically swap the
00:09:10.110 --> 00:09:14.870
contents of the accumulator and a memory
cell. The 'add' instruction will look up
00:09:14.870 --> 00:09:18.329
the contents of a given memory address and
add it to the contents of the accumulator
00:09:18.329 --> 00:09:23.049
and store the result back into the
accumulator. And there's a 'subtract'
00:09:23.049 --> 00:09:26.589
instruction. It takes the contents of
memory dest and subtracts it from the
00:09:26.589 --> 00:09:30.720
content of the accumulator and stores the
result back into the accumulator.
00:09:30.720 --> 00:09:34.139
The result of every subtraction can be
negative, so we need to talk about how
00:09:34.139 --> 00:09:39.290
negative numbers are expressed on the AGC.
Let's look at just 4 bit numbers.
00:09:39.290 --> 00:09:44.860
4-bit unsigned integers can express values
from 0 to 15 with sign and value encoding
00:09:44.860 --> 00:09:48.410
the uppermost bit corresponds to the sign,
and the remaining 3 bits represent the
00:09:48.410 --> 00:09:52.869
absolute value. Consequently, there are
separate values for plus 0 and minus 0.
00:09:52.869 --> 00:09:55.589
This encoding is hard to work with, since
the 0 transitions need to be special
00:09:55.589 --> 00:09:59.430
cased. One's Complement encoding has the
order of the negative numbers reversed.
00:09:59.430 --> 00:10:03.709
The 0 transitions are simpler now, but
there's still two representations of 0.
00:10:03.709 --> 00:10:07.389
Modern Two's Complement encoding only has
a single encoding for 0, and it's fully
00:10:07.389 --> 00:10:12.180
backwards compatible with unsigned
addition and subtraction. In the 1960s,
00:10:12.180 --> 00:10:15.670
computers designed for scientific
calculations are usually One's Complement
00:10:15.670 --> 00:10:21.039
and so is the AGC. Unsigned four bit
numbers can express values from 0 to 15.
00:10:21.039 --> 00:10:25.779
In One's Complement the values 0 through 7
match the unsigned values 0 through 7, and
00:10:25.779 --> 00:10:30.320
the negative size side is organized like
this: Unlike Two's Complement, the two
00:10:30.320 --> 00:10:33.589
sides are perfectly symmetrical, so
negating a number is as easy as
00:10:33.589 --> 00:10:40.200
complementing it, that is, flipping all
the bits. So the two representations of 0
00:10:40.200 --> 00:10:45.830
are plus 0, with all 0 bits, and minus 0,
with all 1 bits. Addition in the positive
00:10:45.830 --> 00:10:50.179
space is equivalent to the unsigned
version, same in the negative space when
00:10:50.179 --> 00:10:54.449
mapping signed negative numbers to their
unsigned counterparts. It gets interesting
00:10:54.449 --> 00:11:01.509
when we have a 0 transition. Signed 6 - 4
is 6 + (-4) which is unsigned 6 + 11,
00:11:01.509 --> 00:11:07.970
which in modulus 16 is 1. We have a carry.
In One's Complement, a carry needs to be
00:11:07.970 --> 00:11:11.319
added to the end result, so we get two,
which is correct. The trick to jump over
00:11:11.319 --> 00:11:14.169
the duplicate 0 on a zero-transition
by adding the carries is called
00:11:14.169 --> 00:11:16.329
the 'end-around-carry'.
00:11:16.329 --> 00:11:20.050
An overflow means that the signed result
does not fit into the number space.
00:11:20.050 --> 00:11:24.630
Signed 7 + 1 would result in signed -7,
which is incorrect. The same happens
00:11:24.630 --> 00:11:28.421
when overshooting negative numbers. After
applying the end-around carry, the result
00:11:28.421 --> 00:11:33.190
of signed 7 here is incorrect. The CPU
detects this and flags the result, the
00:11:33.190 --> 00:11:37.429
accumulator has an extra bit to record the
information about an overflow, we call it V.
00:11:37.429 --> 00:11:44.939
So if we have code that reads the value
of 7FFF from memory and adds 1, the result
00:11:44.939 --> 00:11:49.139
is 0 and an overflow is detected, so the
accumulator is flagged. The store
00:11:49.139 --> 00:11:52.580
instruction in addition to writing A to
memory, does extra work if there's an
00:11:52.580 --> 00:11:57.880
overflow condition: it clears the overflow
condition, writes plus 1 or minus 1 into A,
00:11:57.880 --> 00:12:01.970
depending on whether it's a positive or
a negative overflow, and skips the next
00:12:01.970 --> 00:12:05.790
instruction. This way the program can
detect the overflow and use the plus 1 or
00:12:05.790 --> 00:12:10.670
minus 1 to apply the signed carry to a
higher-order word. By storing A to memory,
00:12:10.670 --> 00:12:15.459
we now have a double-word result. In one's
complement negating a number is as easy
00:12:15.459 --> 00:12:19.069
as flipping every bit in a word so there's
a dedicatet instruction for loading and
00:12:19.069 --> 00:12:22.160
negating a value. ldc, which stands for
'load complement', reads a word from
00:12:22.160 --> 00:12:27.610
memory, negates it by inverting all the
bits and writes it into the accumulator.
00:12:27.610 --> 00:12:31.730
Incrementing, that is adding 1 to a word,
is such a common operation that there's a
00:12:31.730 --> 00:12:35.509
dedicated instruction that increments a
word in memory in place. There is no
00:12:35.509 --> 00:12:38.879
corresponding decrement instruction.
Instead, there are two similar instructions:
00:12:38.879 --> 00:12:43.140
augment and diminish. The increment
instruction adds one to the original value,
00:12:43.140 --> 00:12:46.410
the augment instruction adds one
to all positive values and
00:12:46.410 --> 00:12:51.019
subtracts 1 from all negative values.
Effectively increments the absolute value
00:12:51.019 --> 00:12:54.819
retaining the sign. The diminish
instruction decrements positive values and
00:12:54.819 --> 00:13:00.360
increments negative values. Optimized for
scientific calculations, the CPU has
00:13:00.360 --> 00:13:04.420
dedicated multiplication circuitry. The
model instruction reads a word from memory
00:13:04.420 --> 00:13:09.019
and multiplies it with the accumulator.
When you multiply two signed 15 bit words,
00:13:09.019 --> 00:13:13.139
you need up to 29 bits, that is two words,
for the result. The complete result will
00:13:13.139 --> 00:13:17.149
be written into two registers, the upper
half into A and the lower half into B.
00:13:17.149 --> 00:13:21.420
B is a separate 15 bit register which is
mostly used together with the accumulator
00:13:21.420 --> 00:13:26.540
with instructions that deal with 30 bit
data. Double word values are expressed
00:13:26.540 --> 00:13:29.709
with the uppermost bits in A, or, if in
memory, at lower addresses, and the lower
00:13:29.709 --> 00:13:34.299
bits in B, or at higher addresses, making
the AGC a big endian machine. Assuming the
00:13:34.299 --> 00:13:38.290
normalized form, with matching signs, the
effective value is the concatenation of
00:13:38.290 --> 00:13:42.290
the two times 14 bits of the values.
00:13:42.290 --> 00:13:45.990
Division also works with double words.
It takes the combination of
00:13:45.990 --> 00:13:49.540
the A and B registers as the dividend
and a word from memory as the divisor.
00:13:49.540 --> 00:13:52.659
There are also two results:
the result and the remainder.
00:13:52.659 --> 00:13:55.230
The result is written into A and
the remainder in to B.
00:13:55.230 --> 00:13:59.590
Some other instructions also allow
using A and B as a double word register.
00:13:59.590 --> 00:14:02.959
Load a b comma indirect two zero zero
looks up addresse two zero zero in
00:14:02.959 --> 00:14:06.439
memory and reads the words at this
and the next cell into A and B.
00:14:06.439 --> 00:14:09.899
The load complement variant does the same
but inverts all bits during the load.
00:14:09.899 --> 00:14:12.749
There is no instruction to store A and B
in a single step,
00:14:12.749 --> 00:14:16.149
but there is a double word
exchange instruction. And finally there's
00:14:16.149 --> 00:14:21.079
an add instruction that works in double
words. And to load and store just the B
00:14:21.079 --> 00:14:26.459
register there's an exchange instruction
for that. For working with tables there's
00:14:26.459 --> 00:14:29.730
the indexed addressing mode. Any
instruction that takes an address as an
00:14:29.730 --> 00:14:35.610
argument can use it. This example 'load A
comma indirect 7 0 0 plus indirect 8 0'
00:14:35.610 --> 00:14:42.519
first looks up address 0 8 0, adds it to
the base of 7 0 0, which results in 7 0 2,
00:14:42.519 --> 00:14:47.069
reads from that address and writes the
result into A. What does this mean?
00:14:47.069 --> 00:14:51.399
There's a table in memory at 7 0 0. In the
example, it contains multiples of 3, and
00:14:51.399 --> 00:14:56.309
an index to that table is stored in memory
at 0 8 0, which in the example is 2.
00:14:56.309 --> 00:15:00.529
So we read the entry at index 2 of
the table, which is 6.
00:15:00.529 --> 00:15:03.799
Without a base address, we get
the syntax in this example:
00:15:03.799 --> 00:15:08.319
load A comma double indirect 8 0.
The base is effectively zero in this case.
00:15:08.319 --> 00:15:13.490
The CPU will look up the value at 0 8 0
in memory, add it to the base of 0,
00:15:13.490 --> 00:15:16.989
so the value is still the same.
And read from that address.
00:15:16.989 --> 00:15:21.480
In this case, memory at 0 8 0 effectively
stores what C programmers know
00:15:21.480 --> 00:15:25.200
as a pointer, and 3A0 is the pointer's
different destination.
00:15:25.200 --> 00:15:28.780
The instruction performed it indirectly.
00:15:29.600 --> 00:15:32.600
By default, instructions are
executed sequentially.
00:15:32.600 --> 00:15:36.249
The program counter PC increments as
instructions are executed, always pointing
00:15:36.249 --> 00:15:39.949
to the next instruction. Control flow
instructions like jump and conditional
00:15:39.949 --> 00:15:44.609
jump change that. When the CPU hits a jump
instruction, it will load its argument
00:15:44.609 --> 00:15:49.079
into the program counter, which means that
execution will continue at that address.
00:15:49.079 --> 00:15:53.389
jz, jump if zero, only jumps if A is zero.
Otherwise it continues with the next
00:15:53.389 --> 00:15:57.629
instruction. Similarly, jlez only jumps if
A is negative or zero.
00:15:57.629 --> 00:16:03.449
CCS count compare and skip, is a fun one.
It's a four-way fork for execution.
00:16:03.449 --> 00:16:06.820
Depending on whether the value in
memory is positive, negative,
00:16:06.820 --> 00:16:11.050
plus minus - plus zero, minus zero, it will
jump to one of the next four instructions.
00:16:11.050 --> 00:16:14.209
If you know the value is
positive or zero, you can ignore
00:16:14.209 --> 00:16:16.480
the other two cases and just
fill the first two slots.
00:16:16.480 --> 00:16:20.430
And if it's supposed to be only negative,
you have to skip the first two slots.
00:16:20.430 --> 00:16:23.879
They should never be reached, but
it's good practice for them to fill them
00:16:23.879 --> 00:16:29.029
with error handlers. Since CCS also puts
the absolute diminished value of the
00:16:29.029 --> 00:16:34.489
memory location into A, so it decrements
A, a special case of CCS A can be used for
00:16:34.489 --> 00:16:38.680
loops that count down A. The call
instruction. Isn't it for calling
00:16:38.680 --> 00:16:42.609
subroutines aka functions. It's like a
jump instruction but it saves its origin,
00:16:42.609 --> 00:16:45.809
so the callee can return to it later. For
the call instruction, the program counter
00:16:45.809 --> 00:16:49.869
is incremented first, and then copied into
the link register LR. Finally, the
00:16:49.869 --> 00:16:52.930
argument of the call instruction is copied
into the program counter, so that
00:16:52.930 --> 00:16:57.440
execution continues there. The link
register now contains the return address.
00:16:57.440 --> 00:17:00.939
At the end of the subroutine, the RET
instruction effectively copies the
00:17:00.939 --> 00:17:05.010
contents of the linked register into the
program counter, so execution resumes just
00:17:05.010 --> 00:17:08.690
after the call instruction.
If the subroutine wants to call
00:17:08.690 --> 00:17:11.500
its own subroutine, the program has to
save the link register before,
00:17:11.500 --> 00:17:15.071
and restore it afterwards. There's an
exchange instruction specifically for this.
00:17:15.071 --> 00:17:18.580
For additional levels, a stack can be
constructed, manually,
00:17:18.580 --> 00:17:20.400
using the indexing syntax.
00:17:20.400 --> 00:17:24.010
So far we've seen the following
registers: the A register is used for
00:17:24.010 --> 00:17:27.839
memory accesses and all arithmetic. It is
combined with the B register for double
00:17:27.839 --> 00:17:31.731
width arithmetic, the program counter to
keep track of what to execute and the link
00:17:31.731 --> 00:17:34.830
register remembers the return address when
calling a subroutine. We haven't seen the
00:17:34.830 --> 00:17:38.519
zero register yet. It always contains
zero, so when we read from it, we get zero
00:17:38.519 --> 00:17:42.280
and when we write to it the value gets
discarded. There are three more registers
00:17:42.280 --> 00:17:46.330
that we will talk about later. The eight
registers are numbered, that is they are
00:17:46.330 --> 00:17:50.610
assigned memory addresses. This means that
the first eight words in memory are
00:17:50.610 --> 00:17:53.940
actually occupied by the registers. They
can be accessed using the addresses and
00:17:53.940 --> 00:17:57.900
all instructions that take a memory
address. This allows for much greater
00:17:57.900 --> 00:18:01.559
flexibility in the instruction set: we can
load A with the contents of the B register
00:18:01.559 --> 00:18:05.440
by reading the contents of memory at
location 1 into A. The content of zero can
00:18:05.440 --> 00:18:09.690
be loaded into A by just reading from
memory at 7, which is the zero register.
00:18:09.690 --> 00:18:14.190
A can be incremented by incrementing
memory at zero and B can be used as
00:18:14.190 --> 00:18:20.499
a pointer by reading from double indirect
one. Let's look at memory more closely.
00:18:20.499 --> 00:18:26.719
Memory is 4096 words and goes from
000 to FFF. The registers are located at
00:18:26.719 --> 00:18:31.140
the very bottom of memory. Including them,
there are 1024 words of RAM,
00:18:31.140 --> 00:18:35.100
random access memory, and
three kilowords of ROM, read-only memory.
00:18:35.100 --> 00:18:38.820
The AGC was originally architected to
only have this little RAM and ROM,
00:18:38.820 --> 00:18:42.220
but there's actually more.
Let's look at the RAM area.
00:18:42.220 --> 00:18:45.960
The uppermost quarter is banked. The area
is a window through which one of eight
00:18:45.960 --> 00:18:50.540
different banks can be accessed, each 250
words in size. The erasable Bank register
00:18:50.540 --> 00:18:56.040
EB points to one of these banks. If EB is
0, Bank 0 is visible in the banked area.
00:18:56.040 --> 00:19:01.309
If EB is five, bank five is visible.
Addresses in the fixed area always
00:19:01.309 --> 00:19:05.100
represent the same RAM cells, but these
are not additional cells, but the same as
00:19:05.100 --> 00:19:09.030
banks zero, one and two. This means that
there's a total of 8 times 256 words of
00:19:09.030 --> 00:19:15.690
RAM, two kilowords. ROM is organized
similarly. The lower kiloword is banked.
00:19:15.690 --> 00:19:22.280
The fixed bank register FB selects one of
the 32 banks. Support for more than 32
00:19:22.280 --> 00:19:26.090
kilowords of ROM was added at the last
minute. The 'superbank' bit can switch the
00:19:26.090 --> 00:19:28.330
uppermost eight banks to the second set..
laughter
00:19:28.330 --> 00:19:32.880
so that a total of 40 kilowords are
supported by the architecture.
00:19:32.880 --> 00:19:36.799
The fixed ROM area will always show the
same contents as two of the ROM banks, the
00:19:36.799 --> 00:19:42.169
designers chose banks two and three to
simplify address encoding. In practice,
00:19:42.169 --> 00:19:46.850
fixed ROM contains core operating system
code, and fixed RAM core operating system
00:19:46.850 --> 00:19:49.870
data, that have to be available at all
times. The remaining functionality is
00:19:49.870 --> 00:19:55.059
distributed across the different ROM and
RAM banks. Switching the RAM Bank can be
00:19:55.059 --> 00:19:58.960
done by writing through the EB register.
This is not a separate instruction but can
00:19:58.960 --> 00:20:04.279
be expressed by writing A to memory
location three. If A is five, writing A
00:20:04.279 --> 00:20:09.580
into EB will make RAM Bank five visible at
3 0 0. The same store instruction could be
00:20:09.580 --> 00:20:13.659
used to write to the FB register at memory
location 4, to switch the ROM Bank. But
00:20:13.659 --> 00:20:17.670
that wouldn't work for a common case.
If code in one bank wants to call code in
00:20:17.670 --> 00:20:21.559
another Bank, by first switching the
ROM Bank, load FB, and then doing
00:20:21.559 --> 00:20:26.059
the function call, writing the bank number
into FB will switch out the bank the code
00:20:26.059 --> 00:20:29.230
is currently running on, so it won't
be able to execute the call instruction.
00:20:29.230 --> 00:20:32.010
Instead it will continue running some
completely unrelated code that happens
00:20:32.010 --> 00:20:34.110
to get the same address on
the other bank.
00:20:34.110 --> 00:20:37.220
To call code on a different Bank,
FB and PC registers need
00:20:37.220 --> 00:20:41.889
to be changed atomically. call f is only a
synonym for the existing double word
00:20:41.889 --> 00:20:47.490
exchange instruction. Code first has to
load the bank and the program counter into
00:20:47.490 --> 00:20:55.750
A and B. Which then call f can atomically
move into FB and PC. The same exchange
00:20:55.750 --> 00:20:59.340
instruction can be used for a far return:
it moves the original values back into FB
00:20:59.340 --> 00:21:06.360
and PC. The two Bank registers only hold
five and three bits respectively. The
00:21:06.360 --> 00:21:10.659
other bits are zero and there's a third
bank register, BB, both banks, which
00:21:10.659 --> 00:21:15.000
merges the information from both other
bank registers. The call far both banks
00:21:15.000 --> 00:21:18.140
synonym is a double word exchange
instruction that updates the program
00:21:18.140 --> 00:21:22.769
counter and both banks. Subroutines
usually have their private variables on
00:21:22.769 --> 00:21:26.500
particular RAM banks. Call for both banks
passes control to a function on the
00:21:26.500 --> 00:21:29.870
different ROM Bank and also directly
switches RAM banks, so that the callee can
00:21:29.870 --> 00:21:33.890
immediately access its variables. Return
for both banks returns to the caller,
00:21:33.890 --> 00:21:39.160
restoring its RAM Bank configuration. The
unusual ordering of the bank registers was
00:21:39.160 --> 00:21:43.299
chosen to allow for a double word exchange
of FB and PC, as well as for a double word
00:21:43.299 --> 00:21:49.149
exchange of PC and BB. Now we've seen all
eight registers. There's eight more
00:21:49.149 --> 00:21:52.210
special locations in memory above the
registers, the shadow area, which we'll
00:21:52.210 --> 00:21:56.179
talk about later. And above those, there
are four so-called editing registers,
00:21:56.179 --> 00:22:00.029
which make up for the missing shift and
rotate instructions. When writing a 15 bit
00:22:00.029 --> 00:22:05.660
value into the ROR editing register, it
will be moved to the right by one bit, and
00:22:05.660 --> 00:22:09.670
the lowest bit will be cycled to the top.
The result can then be read back.
00:22:09.670 --> 00:22:17.330
ROL rotates left, SHR shifts to the right
duplicating the top bit, and SHR7 shifts
00:22:17.330 --> 00:22:20.890
to the right by 7 bits, filling the top
with zeros. This is needed for the
00:22:20.890 --> 00:22:25.760
interpreter system software component that
we'll learn about later. We have seen that
00:22:25.760 --> 00:22:29.669
the CPU is connected to RAM and ROM over
the memory bus, but computers also talk to
00:22:29.669 --> 00:22:34.580
peripheral devices that is the I/O bus.
We've already seen the address space for
00:22:34.580 --> 00:22:39.529
memory; there is a second address space
to talk to devices. There are 512 I/O
00:22:39.529 --> 00:22:44.550
channels numbered 000 through FFF. Each
channel is 15 bits, and the in and out
00:22:44.550 --> 00:22:48.980
instructions can read words from -, and
write words to I/O channels. For many
00:22:48.980 --> 00:22:53.690
devices, a channel contains 15 individual
control bits. A control bit can for
00:22:53.690 --> 00:22:58.639
example toggle a lamp on a display. The
'out OR' instruction sets individual bits,
00:22:58.639 --> 00:23:03.580
and 'out AND' clears individual bits. So
I/O instructions can work on the whole
00:23:03.580 --> 00:23:10.400
word or do boolean operations on them:
AND, OR and XOR. To make boolean
00:23:10.400 --> 00:23:15.320
operations also usable between registers,
channels 1 and 2 are actually aliases of
00:23:15.320 --> 00:23:21.860
the B and LR registers, which allows for
these instructions. For AND there's also a
00:23:21.860 --> 00:23:27.299
dedicated instruction that works on A and
memory. After the registers, the shadow
00:23:27.299 --> 00:23:31.909
area, and the editing registers, there's
another special area: the counters. Like
00:23:31.909 --> 00:23:36.090
I/O channels, they connect to external
devices but they don't send bits or hold
00:23:36.090 --> 00:23:39.961
words back and forth, instead they are
controlled by hardware pulses, or cause
00:23:39.961 --> 00:23:44.630
hardware pulses. On every pulse, TIME1
gets incremented for example, while other
00:23:44.630 --> 00:23:51.220
counters take the number stored into them
by code and count down, generating pulses.
00:23:51.220 --> 00:23:55.190
When I/O devices need to signal the CPU,
thay can interrupt normal execution.
00:23:55.190 --> 00:23:58.509
Next to the program counter, which points
to the next instruction, there's the
00:23:58.509 --> 00:24:02.520
instruction register which holds the
current opcode. When an interrupt happens,
00:24:02.520 --> 00:24:08.570
the CPU copies PC into a special memory
location PC' and IR into IR' and then
00:24:08.570 --> 00:24:12.340
jumps to a magic location depending on the
type of interrupt, in this example 814.
00:24:12.340 --> 00:24:16.059
When the interrupt handlers finished
servicing the device the iret instruction
00:24:16.059 --> 00:24:20.530
will copy PC' and IR' back into PC and IR,
so execution will continue at the original
00:24:20.530 --> 00:24:26.690
location. Memory locations eight through
hex F are shadows of the eight registers.
00:24:26.690 --> 00:24:30.360
PC and IR are automatically saved by
interrupts and the remaining registers
00:24:30.360 --> 00:24:35.330
need to be saved by software if necessary.
The overflow condition flag cannot be
00:24:35.330 --> 00:24:40.120
saved or restored, so while there's an
overflow condition until the next store
00:24:40.120 --> 00:24:44.019
instruction, which resolves the offload,
interrupts will be disabled.
00:24:44.019 --> 00:24:49.960
The 11 interrupt handlers have to reside
in fixed ROM starting at 8 0 0.
00:24:49.960 --> 00:24:54.609
There are 4 words for each entry.
Typical interrupt entry code saves A and B,
00:24:54.609 --> 00:25:00.319
loads A and B with a bank and PC of the
actual handler and jumps there.
00:25:00.319 --> 00:25:04.160
Interrupt 0 is special: it's the
entry point on reset.
00:25:04.160 --> 00:25:07.799
Next we will enter the interrupt return
instruction, there's an instruction
00:25:07.799 --> 00:25:11.019
to cause an interrupt in software,
and instructions to enable and
00:25:11.019 --> 00:25:15.960
disable interrupts globally. There is one
more special memory location at hex 37,
00:25:15.960 --> 00:25:20.830
the watchdog. This location needs to be
read from or - read from or written to -
00:25:20.830 --> 00:25:23.940
at least every 0.64 seconds
otherwise the hardware will decide the
00:25:23.940 --> 00:25:29.539
system software is unresponsive and cause
a reset. Now we've seen an instruction set
00:25:29.539 --> 00:25:33.039
and in the examples we've seen the codes
that represent instructions in memory.
00:25:33.039 --> 00:25:37.070
Let's look at how the encoding works. The
load instruction, the upper three bits are
00:25:37.070 --> 00:25:41.790
the opcode representing the load a and the
remaining 12 bits encode the address.
00:25:41.790 --> 00:25:44.610
This allows for a total of eight
instructions but there are more
00:25:44.610 --> 00:25:48.570
than eight instructions. RAM addresses
always start with zero zero and
00:25:48.570 --> 00:25:53.560
ROM adresses start with anything but
zero zero. So the store instruction,
00:25:53.560 --> 00:25:57.100
which only makes sense on RAM, only
needs to encode 10 address bits instead
00:25:57.100 --> 00:26:02.620
of 12, making room for another
three RAM-only instructions.
00:26:02.620 --> 00:26:05.539
The same is true for the increment
instruction, which makes room for
00:26:05.539 --> 00:26:10.310
three more, as well as CCS which shares
an opcode with jump, which only works
00:26:10.310 --> 00:26:15.779
on ROM addresses. Since jumps to the
bank register don't make much sense
00:26:15.779 --> 00:26:21.310
these codes are used to encode STI, CLI
and extend. Extend is a prefix.
00:26:21.310 --> 00:26:23.570
It changes the meaning of the opcode
of the next instruction ...
00:26:23.570 --> 00:26:28.389
laughter ... allowing for a
second set of two-word instructions.
00:26:28.389 --> 00:26:33.990
There's one more special call instruction
'call 2' which is 'call LR',
00:26:33.990 --> 00:26:37.510
which is the return instruction. But
the CPU doesn't special case this one.
00:26:37.510 --> 00:26:42.009
Return is a side-effect of calling memory
at location 2. It executes the instruction
00:26:42.009 --> 00:26:45.960
encoded in the LR register, the 12 bit
address with the leading zeros decodes
00:26:45.960 --> 00:26:52.200
into another call instruction which
transfers control to the return address.
00:26:52.200 --> 00:26:56.929
Indexed addressing is achieved by using
the index prefix. An indexed instruction
00:26:56.929 --> 00:27:00.480
consists of two instruction words, index
and the base instruction. The addressing
00:27:00.480 --> 00:27:03.690
code in the base instruction is the base
address and the index instruction encodes
00:27:03.690 --> 00:27:08.809
the address of the index. Index is an
actual instruction. The CPU reads from the
00:27:08.809 --> 00:27:14.549
given address, 0 8 0 in the example, then
adds its value, 3, to the instruction code
00:27:14.549 --> 00:27:19.830
of the following instruction 3 7 0 0 which
is stored in the internal IR register.
00:27:19.830 --> 00:27:23.980
Then it uses the resulting instruction
code 3 7 0 3 for the next instruction,
00:27:23.980 --> 00:27:29.880
which is a load from 703, the effective
address. If an interrupt occurs after in
00:27:29.880 --> 00:27:33.200
the index instruction, that is no problem
because IR contains the effective
00:27:33.200 --> 00:27:36.339
instruction code which will be saved into
IR Prime and restored at the end of the
00:27:36.339 --> 00:27:40.490
interrupt handler. Finally there's one
index encoding with a special meaning.
00:27:40.490 --> 00:27:42.950
When the address looks like it's
referencing the shadow instruction
00:27:42.950 --> 00:27:47.060
register it's an interrupt return
instruction. Looking at the instruction
00:27:47.060 --> 00:27:50.230
set architecture as a whole, there are
many quirky and unusual features when
00:27:50.230 --> 00:27:53.470
compared to modern architectures. It uses
One's Complement instead of Two's
00:27:53.470 --> 00:27:57.809
Complement; it has no status register; the
overflow flag can't even be saved so
00:27:57.809 --> 00:28:01.900
interrupts are disabled until the overflow
is resolved; the store instruction may
00:28:01.900 --> 00:28:06.610
skip a word under certain circumstances;
the ccs destruction can skip several words
00:28:06.610 --> 00:28:11.049
and can be outright dangerous if the
instructions following it use prefixes;
00:28:11.049 --> 00:28:14.379
there are no shift or rotate instructions
but magic memory locations that shift and
00:28:14.379 --> 00:28:18.889
rotate when writing into them; most
boolean instructions only work on I/O
00:28:18.889 --> 00:28:23.039
channels; indexing is done by hacking the
following instruction code, and the
00:28:23.039 --> 00:28:28.400
architecture has no concept of a stack,
indexing has to be used if one is needed.
00:28:28.400 --> 00:28:32.929
This was the architecture of the Apollo
guidance computer, now let's look at how
00:28:32.929 --> 00:28:36.460
this architecture is implemented in
hardware. The hardware implementation runs
00:28:36.460 --> 00:28:40.320
at one megahertz, is micro coded and uses
integrated circuits, core memory, and core
00:28:40.320 --> 00:28:43.310
rope memory. We'll look at the block
diagram and how instructions are
00:28:43.310 --> 00:28:46.999
implemented in micro code, and then about
how the schematics map to integrated
00:28:46.999 --> 00:28:52.890
circuits on modules on trays. This
simplified block diagram shows the AGC at
00:28:52.890 --> 00:28:57.190
the hardware level. Each box contains on
the order of 500 logic gates. The dotted
00:28:57.190 --> 00:29:01.340
lines are wires that to move a single bit
of information, the solid lines are 15
00:29:01.340 --> 00:29:07.049
wires that move a data word. These units
deal with timing and control, and these
00:29:07.049 --> 00:29:11.370
are the central units. The central
register unit stores A, B, link registers,
00:29:11.370 --> 00:29:16.409
and program counter, and the arithmetic
unit can add and subtract numbers. The
00:29:16.409 --> 00:29:22.090
memory components deal with RAM and ROM.
The main clock of about one megahertz
00:29:22.090 --> 00:29:25.450
feeds into the sequence generator which
keeps cycling through twelve stages, which
00:29:25.450 --> 00:29:31.340
is one memory cycle, MCT. Instructions
usually take as many memory cycles as they
00:29:31.340 --> 00:29:35.899
need memory accesses, so load, add, and
store take two cycles, and jump takes one.
00:29:35.899 --> 00:29:39.519
The sequence generator contains a
collection of 12 step micro programs for
00:29:39.519 --> 00:29:44.690
each MCT, for each instruction, like this
one for the load instruction. In each
00:29:44.690 --> 00:29:51.740
step, the entries send control pulses to
the other units, which are connected
00:29:51.740 --> 00:29:57.059
through the write bus. The control signal
WA for example instructs the register unit
00:29:57.059 --> 00:30:01.399
to put the contents of A onto the write
bus, and RA makes it read the value on the
00:30:01.399 --> 00:30:06.630
bus into A. Memory is also connected to
the write bus. WS will copy the bus
00:30:06.630 --> 00:30:10.349
contents into the memory address register,
and RG and WG will read and write the G
00:30:10.349 --> 00:30:15.720
register, which buffers the cells value
after read and before a write. So in stage
00:30:15.720 --> 00:30:24.629
7 for example RG puts the memory buffer
onto the bus, and WB writes the bus
00:30:24.629 --> 00:30:30.000
contents into the temporary G register.
And in T10, B gets put on the bus and it
00:30:30.000 --> 00:30:33.899
gets read into the A register. At the
beginning of every memory cycle the
00:30:33.899 --> 00:30:37.860
hardware sends the memory address S,
usually what's encoded instruction, to
00:30:37.860 --> 00:30:42.330
memory and copies the contents of that
address into G. in the second half of the
00:30:42.330 --> 00:30:47.999
MCT it stores G back into the same cell.
So if we show memory timing next to the
00:30:47.999 --> 00:30:50.440
microcode, as well as the pseudocode
version of the load instruction which is
00:30:50.440 --> 00:30:55.470
easier to read, we can see it loads the
value from memory into G copies it into B
00:30:55.470 --> 00:30:59.049
and then copies it into A. More
interesting is the exchange instruction.
00:30:59.049 --> 00:31:05.519
It saves A to B, reads memory into G,
copies the result into A, copies the old
00:31:05.519 --> 00:31:11.210
value into G, and stores that G into
memory. Division for example takes several
00:31:11.210 --> 00:31:15.460
MCT and it's micro program is way more
complex. But there are more micro programs
00:31:15.460 --> 00:31:18.799
than the ones for the machine
instructions. Since there is only a single
00:31:18.799 --> 00:31:21.580
adding unit in the whole computer,
incrementing and decrementing the counters
00:31:21.580 --> 00:31:26.070
is done by converting the pulses into
special instructions that get injected
00:31:26.070 --> 00:31:30.539
into the instruction stream. There are 14
of these so-called unprogrammed sequences
00:31:30.539 --> 00:31:34.749
with their own micro programs. Some counter
shift, some are for interacting with
00:31:34.749 --> 00:31:40.869
debugging hardware, and these two control
the interrupt and reset sequences.
00:31:40.869 --> 00:31:46.079
The complete schematics are publicly
available and fit on just 49 sheets.
00:31:46.079 --> 00:31:51.119
The whole implementation only uses a single
type of gate, a three input NAND gate.
00:31:51.119 --> 00:31:54.870
Two of these are contained in one
integrated circuit, and about a hundred of
00:31:54.870 --> 00:31:57.700
these ICs form a logic module.
00:31:59.580 --> 00:32:03.730
24 logic modules and some interface and
power supply modules are connected
00:32:03.730 --> 00:32:06.999
together in tray A, which also contains
the I/O and debug connectors.
00:32:06.999 --> 00:32:11.370
Tray B contains various driver and amplifier
modules, as well as RAM and ROM.
00:32:11.370 --> 00:32:16.061
RAM is implemented as magnetic core memory,
which stores bits in magnetized toroids.
00:32:16.061 --> 00:32:19.800
Reading a bit clears it, so the memory
sequencer makes sure to always write the
00:32:19.800 --> 00:32:24.080
value again after reading it.
Without mass storage, like tape, the AGC
00:32:24.080 --> 00:32:29.960
has an unusually high amount of ROM.
Core Rope Memory encodes bits by wires that
00:32:29.960 --> 00:32:35.190
either go through- or past a ferrite core.
The 500,000 bits per computer were woven
00:32:35.190 --> 00:32:40.429
completely by hand. Trays A and B are put
together like this and hermetically
00:32:40.429 --> 00:32:45.019
sealed, making for a rather compact
computer. This is its orientation when
00:32:45.019 --> 00:32:50.440
installed on the spacecraft, with the six
ROM modules accessible so they could in
00:32:50.440 --> 00:32:54.529
theory be replaced during the mission. And
that was the hardware part.
00:32:54.529 --> 00:33:00.699
applause
C: Next let's look at the devices.
00:33:00.699 --> 00:33:04.610
applause
00:33:04.610 --> 00:33:08.090
Let's look at the devices connected
to the computer.
00:33:08.090 --> 00:33:10.921
We will look at the core devices
that allow the Apollo guidance computer to
00:33:10.921 --> 00:33:14.260
maintain the state vector, some quite
special devices you don't see on many
00:33:14.260 --> 00:33:17.759
other computers, and the peripherals used
for communication with astronauts and
00:33:17.759 --> 00:33:21.799
Mission Control. The gyroscope is the core
peripheral that the Apollo guidance
00:33:21.799 --> 00:33:24.800
computer was originally built around. The
Apollo Guidance Computer rotates it into a
00:33:24.800 --> 00:33:28.600
certain base position with the CDU command
counters, and then the gyro detects
00:33:28.600 --> 00:33:31.930
rotation around the three axes of the
spacecraft that can be read from the CDU
00:33:31.930 --> 00:33:35.470
counters. Using the gyroscope, the
spacecraft always knows it's attitude,
00:33:35.470 --> 00:33:39.799
that is its orientation in space. The
accelerometer adjust acceleration forces
00:33:39.799 --> 00:33:45.509
on the three axis. The three values can be
read from the PIPA counters. The optics on
00:33:45.509 --> 00:33:49.419
the command module are used to measure the
relative position to the celestial bodies.
00:33:49.419 --> 00:33:53.220
The computer uses the OPT command counters
to move the optics to point towards the
00:33:53.220 --> 00:33:56.669
general direction of a star, and will read
in the astronauts fine-tuning through the
00:33:56.669 --> 00:34:00.640
OPT counters. The landing radar sits at
the bottom of the lunar module and
00:34:00.640 --> 00:34:03.649
measures the distance to the ground. The
RADARUPT interrupt will be triggered
00:34:03.649 --> 00:34:07.009
whenever a new measurement is available,
and the RNRAD counter contains the new
00:34:07.009 --> 00:34:11.562
value. Lunar module's rendezvous radar
measures the distance of the command and
00:34:11.562 --> 00:34:15.550
service module during rendezvous. After
setting the two angles and the CDUT and
00:34:15.550 --> 00:34:18.980
CDUS counters to point it towards the two
other spacecraft, it will automatically
00:34:18.980 --> 00:34:22.250
track it and cause RADARUPT interrupts
when new data is available, which can be
00:34:22.250 --> 00:34:26.780
read from the RNRAD counters. The command
module, the service module, and the lunar
00:34:26.780 --> 00:34:30.960
module all contain reaction control
system, RCS, jets that emit small bursts
00:34:30.960 --> 00:34:34.870
for holding or charging the attitude. On
lunar module, there's one bit for each of
00:34:34.870 --> 00:34:38.469
the sixteen jets. Setting a bit to one
will make the jet fire.The system software
00:34:38.469 --> 00:34:44.189
uses a dedicated timer, TIME6, and it's
interrupt T6RUPT for timing the pulses.
00:34:44.189 --> 00:34:47.560
The user interface is provided by the so
called DSKY which stands for display and
00:34:47.560 --> 00:34:51.861
keyboard. It has 19 keys, 15 lamps, and
several numeric output lines.
00:34:51.861 --> 00:34:55.050
Keys generate the KEYRUPT interrupts and
the key number can be read
00:34:55.050 --> 00:34:59.630
from the KEYIN I/O channel. The numeric
display is driven by the OUT O channel.
00:34:59.630 --> 00:35:02.500
There is bidirectional digital radio
communication and S-band between
00:35:02.500 --> 00:35:06.970
Mission Control and each spacecraft at a
selectable speed of 1.9 or 51 kbit/s
00:35:06.970 --> 00:35:10.210
Data words from Mission Control show up
in the INLINK counter and
00:35:10.210 --> 00:35:15.071
trigger interrupt UPRUPT. Data words to be
sent are stored in the I/O channel DNTM1
00:35:15.071 --> 00:35:17.690
and the DOWNRUPT interrupt will signal
the program when it can load
00:35:17.690 --> 00:35:23.550
the register with the next word. These
were some of the interesting peripherals.
00:35:25.070 --> 00:35:29.520
M: The AGC system, the AGC system software
00:35:29.520 --> 00:35:32.490
makes it a priority based cooperative -
but also pre-emptive - real-time
00:35:32.490 --> 00:35:37.410
interactive fault tolerant computer with
virtual machine support. The topics we'll
00:35:37.410 --> 00:35:40.740
talk about are multitasking, the
interpreter, device drivers, and the
00:35:40.740 --> 00:35:45.540
waitlist, as well as the user interface,
and mechanisms for fault recovery. The AGC
00:35:45.540 --> 00:35:49.020
has many things to do. It does
mathematical calculations that can take
00:35:49.020 --> 00:35:52.900
several seconds, and it does I/O with its
devices; it services interrupts when a
00:35:52.900 --> 00:35:56.890
device wants the computers attention, for
example a key press. It does regular
00:35:56.890 --> 00:36:01.110
servicing of devices, like updating the
display, and it supports real-time
00:36:01.110 --> 00:36:05.820
control, like flashing a lamp or firing
boosters at exactly the right time.
00:36:05.820 --> 00:36:09.520
There's only a single CPU, so it must
switch between the different tasks.
00:36:09.520 --> 00:36:13.680
Batch processing multitasking computers
work on long-running jobs one after the
00:36:13.680 --> 00:36:17.720
other, but if some jobs have higher
priorities it makes more sense to run a job
00:36:17.720 --> 00:36:21.140
for only - say 20 milliseconds - then
check the job queues and keep running
00:36:21.140 --> 00:36:24.830
the highest priority job in the queue
until it terminates and is removed
00:36:24.830 --> 00:36:29.300
from the queue, then keep picking the
highest priority job.
00:36:29.300 --> 00:36:32.560
Jobs have to manually check at least
every 20 milliseconds whether
00:36:32.560 --> 00:36:36.110
there's a higher priority job in the queue
by doing doing a so-called 'yield',
00:36:36.110 --> 00:36:41.370
which makes the AGC a priority scheduled
cooperative multitasking computer.
00:36:41.370 --> 00:36:44.790
A job is described by 12 word data
structure in memory, that contains
00:36:44.790 --> 00:36:48.690
the PC and both bank's register that point
to where the job will start or continue
00:36:48.690 --> 00:36:55.170
running, as well as a word with a disabled
flag in the sign bit and a 5 bit priority.
00:36:55.170 --> 00:36:59.120
The core set consists of seven
job entries. Minus zero in the priority
00:36:59.120 --> 00:37:03.100
word means that the entry is empty. Job
zero is always the currently running one.
00:37:03.100 --> 00:37:07.040
When a new job gets created with a higher
priority, the yield operation will
00:37:07.040 --> 00:37:12.070
exchange the 12 words so that new job is
job zero. Negating the priority will put a
00:37:12.070 --> 00:37:16.510
job to sleep, so yield won't switch to it
again. Negating it again will wake it up.
00:37:16.510 --> 00:37:20.530
The first eight words in the job entry can
be used for local storage for the job.
00:37:20.530 --> 00:37:23.250
Since it's always job zero that is
running, these words are always
00:37:23.250 --> 00:37:27.840
conveniently located at the same addresses
in memory. The executive has a set of
00:37:27.840 --> 00:37:32.790
subroutines that control the job data
structures. You can create a new job
00:37:32.790 --> 00:37:37.190
pointed to by a pair of PC and BB
registers of a given priority, change the
00:37:37.190 --> 00:37:41.430
priority of the current job, put the
current job to sleep, wake up a given job,
00:37:41.430 --> 00:37:45.931
and terminate the current job.
Yield is not an executive function, but a
00:37:45.931 --> 00:37:50.190
two instruction sequence that checks the
new job variable in which the executive
00:37:50.190 --> 00:37:54.070
always holds the idea of the highest
priority job. If job zero is the highest
00:37:54.070 --> 00:37:57.450
priority job there's nothing to do. If
there is a higher priority job, it calls
00:37:57.450 --> 00:38:02.120
the change job subroutine which switches
to that job. NEWJOB isn't just a variable
00:38:02.120 --> 00:38:05.990
in memory, but also the watchdog word. If
it isn't accessed regularly, that is
00:38:05.990 --> 00:38:10.280
cooperative multitasking is stuck, the
hardware will automatically reset itself.
00:38:10.280 --> 00:38:14.500
A lot of the code in the AGC does
scientific calculations, calculating for
00:38:14.500 --> 00:38:18.610
example just the sum of two products of a
scalar and a vector would require hundreds
00:38:18.610 --> 00:38:22.971
of instructions in AGC machine code. There
is library code that provides all kinds of
00:38:22.971 --> 00:38:27.370
operations on single, double, or triple
precision fixed point values, vectors, and
00:38:27.370 --> 00:38:32.570
matrices. It also provides a softer multi-
purpose accumulator, MPAC, which can hold
00:38:32.570 --> 00:38:36.240
a double, triple, or a vector, depending
on the mode flag. In C-like pseudo code we
00:38:36.240 --> 00:38:40.610
would load the vector into the MPAC,
multiply it with a scalar, save it, do the
00:38:40.610 --> 00:38:45.650
other multiplication, and add the result
to the saved value. Formulas like this one
00:38:45.650 --> 00:38:50.930
need to store intermediate results, so a
thirty-eight word stack is provided. If a
00:38:50.930 --> 00:38:54.160
job uses math code, the MPAC, the MODE
field, and the stack pointer will be
00:38:54.160 --> 00:38:58.040
stored in the remaining fields of the Core
Set Entry. The stack will be part of a
00:38:58.040 --> 00:39:02.700
data tructure called VAC, which will be
pointed to by the Core Set Entry. A job
00:39:02.700 --> 00:39:06.450
can be created with, or without a VAC,
depending on which subroutine it is
00:39:06.450 --> 00:39:11.530
created with. The machine code version of
the example code would still be very
00:39:11.530 --> 00:39:15.100
verbose, with many function calls passing
pointers. The designers of the AGC
00:39:15.100 --> 00:39:18.080
software decided to create a new and
compact language that will be interpreted
00:39:18.080 --> 00:39:22.450
at runtime, a virtual machine. The
interpretive language is turing-complete
00:39:22.450 --> 00:39:26.710
and in addition to the MPAC it has two
index registers, two step registers, and
00:39:26.710 --> 00:39:31.030
its own link register. The encoding
manages to fit two seven bit op codes in
00:39:31.030 --> 00:39:35.290
one word, which allows for 128 op codes
and explains why there is a 'shift right
00:39:35.290 --> 00:39:39.720
by seven' function in the CPU. The two
operands are stored in the following two
00:39:39.720 --> 00:39:44.540
words, allowing 14 bit addresses. 14 bit
addresses means interpretive code doesn't
00:39:44.540 --> 00:39:48.970
have to work this complicated memory layer
anymore. It allows addressing about half
00:39:48.970 --> 00:39:53.080
of the ROM at the same time. At the lowest
kiloword of each half, RAM is visible, so
00:39:53.080 --> 00:39:57.900
interpretive code can pick between one of
these two memory layouts. This is the
00:39:57.900 --> 00:40:01.580
complete instruction set, regular machine
code, interpretive code can be mixed and
00:40:01.580 --> 00:40:04.570
matched inside the job. The exit
instruction will continue executing
00:40:04.570 --> 00:40:08.870
regular machine code at the next address,
and CALL INTPRET will similarly switch to
00:40:08.870 --> 00:40:13.190
interpreter mode. In addition to long-
running math tasks, the system software
00:40:13.190 --> 00:40:17.001
also supports device drivers. When a
device needs the computers attention, for
00:40:17.001 --> 00:40:21.160
example in case of a DSKY key press, it
causes an interrupt. The current job will
00:40:21.160 --> 00:40:24.290
be interrupted, and the interrupt handler
will read the device data and return as
00:40:24.290 --> 00:40:29.401
quickly as possible. If there's more to
do, it can schedule a job for later. Some
00:40:29.401 --> 00:40:34.390
devices need to be serviced regularly. A
120 microsecond timer causes interrupts
00:40:34.390 --> 00:40:38.450
that read data and write data... that read
data from and write data to certain
00:40:38.450 --> 00:40:42.520
devices. The numeric display of the DSKY
for example only allows updating a few
00:40:42.520 --> 00:40:48.350
digits at a time, so its driver is
triggered by the 120 microsecond timer.
00:40:48.350 --> 00:40:51.930
The timer interrupt cycles through eight
phases, which distributes the device
00:40:51.930 --> 00:40:56.941
drivers across time to minimize the
duration of one interrupt handler. Some
00:40:56.941 --> 00:41:00.810
devices need to be driven at exact times.
If for example a job decides that it needs
00:41:00.810 --> 00:41:05.330
to flash a lamp twice, it would turn it on
immediately and schedule three weightless
00:41:05.330 --> 00:41:10.630
tasks in the future at specific times. The
first one will turn the lamp off, the
00:41:10.630 --> 00:41:15.940
second one will turn it on again and the
third one will turn it off again. The
00:41:15.940 --> 00:41:21.010
sorted time deltas of the weightless tasks
are stored in the data structure LST1,
00:41:21.010 --> 00:41:24.590
with the first entry always currently
counting down in a timer register, and
00:41:24.590 --> 00:41:29.630
LST2 contains a pair of PC and BB for each
task. There are subroutines to create a
00:41:29.630 --> 00:41:34.690
new task and end the current task. The
timer that controls the wait list has a
00:41:34.690 --> 00:41:39.251
granularity of 10 milliseconds. Other
timers can fire at the same rate, but are
00:41:39.251 --> 00:41:42.950
offset, and the work triggered by them is
designed to be short enough to never
00:41:42.950 --> 00:41:47.000
overlap with the next potential timer
triggered work. This is complicated by
00:41:47.000 --> 00:41:50.820
device interrupts, which can come in at
any time. The duration of an interrupt
00:41:50.820 --> 00:41:55.560
handler causes latency and the maximum
duration will reduce the allowed time for
00:41:55.560 --> 00:41:59.090
the timer handlers. The core system
software makes no guarantees about the
00:41:59.090 --> 00:42:04.120
timing, it's all up to components to...
it's up to all the components to cooperate
00:42:04.120 --> 00:42:10.270
so the real time goal can be met. The
PINBALL program is the shell of the AGC.
00:42:10.270 --> 00:42:14.160
Key press interrupts schedule a job, that
collects the digits for the command and
00:42:14.160 --> 00:42:18.380
updates an in-memory representation of
what should be on the display. The 120
00:42:18.380 --> 00:42:23.150
millisecond timer triggers the display
update code. When the command is complete
00:42:23.150 --> 00:42:27.940
PINBALL schedules a new job. Mission
Control has a remote shell in form of a
00:42:27.940 --> 00:42:34.070
DSKY connected through the s-band radio.
System software that supports human life
00:42:34.070 --> 00:42:37.830
has to be able to communicate malfunctions
and be able to recover from them.
00:42:37.830 --> 00:42:40.940
The alarm subroutine takes the following
word from the instruction stream,
00:42:40.940 --> 00:42:44.530
displays it, and illuminates the prog
light. This should be interpreted as
00:42:44.530 --> 00:42:48.590
a warning or an error message.
The AGC software is full of validity and
00:42:48.590 --> 00:42:51.550
plausibility checks that help to find
bugs during development and help
00:42:51.550 --> 00:42:54.250
better understanding potential issues
during the mission.
00:42:54.250 --> 00:42:58.080
Some kinds of failures triggered by
various hardware watchdogs or by code
00:42:58.080 --> 00:43:01.830
make it impossible for normal operations
to continue. In addition to showing
00:43:01.830 --> 00:43:05.950
the error code, they also cause a hardware
reset but the system software also offers
00:43:05.950 --> 00:43:10.500
recovery services. A job can have recovery
code for its different phases.
00:43:10.500 --> 00:43:15.080
During execution it sets the respective
phase and if an abort happens in any
00:43:15.080 --> 00:43:20.540
job or task, the currently set up recovery
routine gets executed which could
00:43:20.540 --> 00:43:25.070
for example clean up and try the work
again, or skip to a different phase, or
00:43:25.070 --> 00:43:30.070
cancel the job altogether. The phase
change call sets the current phase for a
00:43:30.070 --> 00:43:34.310
job in the recovery table, for example
phase 5 for job 4. Each phase is
00:43:34.310 --> 00:43:39.900
associated with a descriptor of a task or
a job with or without a VAC. So during
00:43:39.900 --> 00:43:44.150
normal execution with several jobs and
tasks scheduled, if an abort happens, the
00:43:44.150 --> 00:43:47.900
core set and wait list are cleared, the
contents of the recovery table are
00:43:47.900 --> 00:43:52.210
activated, scheduling tasks and jobs for
all jobs that set up recovery code.
00:43:52.210 --> 00:43:56.670
Sometimes a failure though, like corrupted
memory, are not recoverable. They cause a
00:43:56.670 --> 00:44:00.330
fresh start, meaning a full initialization
of the system without running any recovery
00:44:00.330 --> 00:44:05.030
code.
And that was the AGC system software.
00:44:07.630 --> 00:44:11.350
C: As we now have a good overview on
architecture, hardware, peripherals, and
00:44:11.350 --> 00:44:14.550
system software of the Apollo Guidance
Computer, it's time briefly view on it's
00:44:14.550 --> 00:44:18.930
practical use on a mission to the moon. We
will look at the user interface, the
00:44:18.930 --> 00:44:22.580
launch sequence, and, once in orbit, the
attitude in orbit determination. Further
00:44:22.580 --> 00:44:26.130
we will understand how the digital
autopilot works, and how powered flight is
00:44:26.130 --> 00:44:30.280
being performed. As soon as we've reached
the moon, we look at the lunar landing and
00:44:30.280 --> 00:44:34.380
the lunar rendezvous after liftoff and
finally re-entry into Earth's atmosphere.
00:44:34.380 --> 00:44:38.000
Last but not least contingencies, or as we
like to call them, "fun issues".
00:44:38.000 --> 00:44:41.761
Let's start with the user interface.
It is like any command-line interface but
00:44:41.761 --> 00:44:44.921
since there are only numbers and no letters,
key words have to be encoded.
00:44:44.921 --> 00:44:48.540
On a normal system you might say
'display memory', 'enter'.
00:44:48.540 --> 00:44:52.190
Display is the verb, memory is the noun.
On the Apollo guidance computer you say
00:44:52.190 --> 00:44:57.150
verb '0 1', which means 'display', noun
'0 2' - 'memory' - 'enter'.
00:44:57.150 --> 00:45:01.320
Subroutine asks for an argument. On a
normal system it might display a prompt,
00:45:01.320 --> 00:45:03.830
you enter the number, press 'enter'.
On the Apollo Guidance Computer, flashing
00:45:03.830 --> 00:45:09.350
'verb' and 'noun' indicate that is waiting
for input. So you type '2 5', 'enter';
00:45:09.350 --> 00:45:12.602
an octal address, and the Apollo Guidance
Computer displays the result.
00:45:12.602 --> 00:45:16.690
The memory contents at the address octal
'2 5'. The Apollo Guidance Computer uses
00:45:16.690 --> 00:45:19.840
the same concept of verb and noun when
it proactively asks for input.
00:45:19.840 --> 00:45:24.100
Verb '6', noun '11' asks for the CSI
ignition time. CSI meaning
00:45:24.100 --> 00:45:27.980
Coelliptic Sequence Initiation, we will
come to that later. Special case is when
00:45:27.980 --> 00:45:31.230
the Apollo Guidance Computer asks a
yes-or-no question. Verb 99 has the
00:45:31.230 --> 00:45:35.010
astronaut confirm engine ignition
with a proceed key.
00:45:35.010 --> 00:45:37.950
The astronauts have a complete reference of
all verbs and nouns on paper,
00:45:37.950 --> 00:45:41.160
as well as cue cards were the most
important information.
00:45:41.160 --> 00:45:45.510
Let's now go through each of the phases
of the mission, starting with a liftoff.
00:45:45.510 --> 00:45:49.530
So, we are on our way.
The Apollo Guidance Computer is
00:45:49.530 --> 00:45:53.500
in passive monitoring mode. With the
cutting of the umbilical cables, which you
00:45:53.500 --> 00:45:58.150
see right about ... now, it has started
the mission clock. In case this trigger
00:45:58.150 --> 00:46:01.690
fails, one DSKY is always prepared with
verb 75 and just waiting for 'enter' to
00:46:01.690 --> 00:46:04.940
manually start the mission timer. We can
display the mission elapsed time at any
00:46:04.940 --> 00:46:10.570
time with verb 16, noun 65. During the
flight with the SaturnV, the Apollo
00:46:10.570 --> 00:46:13.521
Guidance Computer is only performing
passive monitoring of the flight. Control
00:46:13.521 --> 00:46:16.660
of the SaturnV is with its own launch
vehicle digital computer, and the
00:46:16.660 --> 00:46:20.520
instrument unit ring. The DSKY
automatically shows verb 16, noun 62,
00:46:20.520 --> 00:46:24.110
which is velocity in feet per second.
Altitude change rate in feet per second,
00:46:24.110 --> 00:46:27.960
and altitude above pad and nautical miles.
Note that the units and the position of
00:46:27.960 --> 00:46:31.590
the decimal point are implicit, and yes
the whole system was working in metric
00:46:31.590 --> 00:46:35.300
internally but for the benefit of the
American astronauts the display procedures
00:46:35.300 --> 00:46:41.740
converted everything to imperial units.
laughter and applause
00:46:41.740 --> 00:46:45.731
In case of problems with the Saturn
computer, the Apollo Guidance Computer can
00:46:45.731 --> 00:46:49.050
take over full control of the launch
vehicle, in extreme cases astronauts could
00:46:49.050 --> 00:46:52.601
even steer the whole stack into orbit
themselves with the hand controller. In
00:46:52.601 --> 00:46:56.300
case you ever wanted to fly... to manualyl
control a 110 meter tall rocket with more
00:46:56.300 --> 00:46:59.020
than 30 million Newton of thrust, this is
your chance.
00:46:59.020 --> 00:47:01.540
laughter
In less than 12 minutes we've gone through
00:47:01.540 --> 00:47:04.820
the first and second stage and are using a
small burn from the third stage to get us
00:47:04.820 --> 00:47:09.190
into a 185 kilometer orbit which circles
the earth every 88 minutes.
00:47:11.050 --> 00:47:13.800
But how do we know where ...
we are in the right orbit?
00:47:13.800 --> 00:47:16.810
Well the Apollo guidance computer, as well
as Mission Control, are monitoring
00:47:16.810 --> 00:47:20.200
position and velocity, because to get
where we want to be, we first need to know
00:47:20.200 --> 00:47:24.210
where we are. To be able to navigate in
space, we need to maintain our
00:47:24.210 --> 00:47:26.990
three-dimensional position, and our
three-dimensional velocity,
00:47:26.990 --> 00:47:30.360
the so-called state vector. Let's start
with the determination of the position.
00:47:30.360 --> 00:47:34.670
For this we need a telescope and a space
sextant. The space sextant is very similar
00:47:34.670 --> 00:47:37.430
to an 18th century nautical sextant.
Position is determined by measuring
00:47:37.430 --> 00:47:41.320
the angle between the horizon and a
celestial body. As an horizon we can
00:47:41.320 --> 00:47:45.310
either take that of Earth or Moon and
celestial bodies - well we are in orbit,
00:47:45.310 --> 00:47:48.720
we are surrounded by them. So let's just
pick one. Luckily the Apollo guidance
00:47:48.720 --> 00:47:52.720
computer already knows the position of 45
of them. The whole optics hardware and the
00:47:52.720 --> 00:47:55.830
command and service module can be moved to
point in the general direction of Earth
00:47:55.830 --> 00:47:59.260
and moon. With the launch of program 52,
we command the Apollo guidance computer to
00:47:59.260 --> 00:48:02.840
rotate the spacecraft to point one axis of
the sextant, the so-called landmark line-
00:48:02.840 --> 00:48:07.310
of-sight, LLOS, to the nearest body, which
is earth or moon. The astronaut then used
00:48:07.310 --> 00:48:11.590
the optics systems to exactly align the
horizon to the LLOS. With the telescope
00:48:11.590 --> 00:48:14.490
the astronaut looks for one of the known
stars, points the star line to it and lets
00:48:14.490 --> 00:48:17.800
the Apollo guidance computer read the
tuning and shaft angle. Repeating this one
00:48:17.800 --> 00:48:20.960
or more times in a different plane gives a
three-dimensional position of the vehicle
00:48:20.960 --> 00:48:25.130
in space. In the lunar module on the other
hand, the optics hardware was trimmed down
00:48:25.130 --> 00:48:28.380
for weight reduction. Any alignment
requires rotation of the lunar module.
00:48:28.380 --> 00:48:31.610
This is mostly used to determine the
landing site and support the rendezvous
00:48:31.610 --> 00:48:36.130
maneuvre. It even lacks the software to
perform positioning in translunar space.
00:48:36.130 --> 00:48:40.100
As we are moving, our position changes all
the time. But after 2 location fixes, as
00:48:40.100 --> 00:48:43.170
long as we're coasting, we are able to
establish our speed and can determine
00:48:43.170 --> 00:48:47.010
future positions by dead reckoning. As
position and velocity are known, future
00:48:47.010 --> 00:48:50.720
positions can be extrapolated.
Unfortunately the near extrapolation
00:48:50.720 --> 00:48:54.450
doesn't work in space as we have
gravitational forces which bend our path.
00:48:54.450 --> 00:48:57.090
Thankfully there are two mathematical
models implemented in the Apollo Guidance
00:48:57.090 --> 00:49:00.400
Computer: Conic integration based on the
Keplerian orbit model on the left, which
00:49:00.400 --> 00:49:04.640
assumes one perfectly round gravitational
body influencing our flight path, and
00:49:04.640 --> 00:49:08.060
Encke's integrating method for
perturbation considering multiple bodies
00:49:08.060 --> 00:49:12.080
with gravitational imbalances. I think
this helps to understand why we need a
00:49:12.080 --> 00:49:15.610
computer on board and can't just fly to
the moon with a hand controller. As we
00:49:15.610 --> 00:49:19.020
see, the Apollo spacecraft was perfectly
capable to fly on its own, but in the end
00:49:19.020 --> 00:49:22.150
NASA decided that the primary source for
state vector updates shall be Mission
00:49:22.150 --> 00:49:25.580
Control in Houston, measured with three
ground stations. Remote programming is
00:49:25.580 --> 00:49:28.621
done with the Apollo guidance Computer in
idle, and running program 27. Mission
00:49:28.621 --> 00:49:32.590
Control can use its link via s-band to
update the state vector. But there's one
00:49:32.590 --> 00:49:36.450
thing Mission Control doesn't know better
than us, and that's attitude. Attitude is
00:49:36.450 --> 00:49:39.880
the orientation of the spacecraft in its
three axis. Starting from a known
00:49:39.880 --> 00:49:44.041
attitude, we have to ensure that we can
measure any rotation on any axis.
00:49:44.041 --> 00:49:48.020
That's what gyros are for. They are one of
the major component of the IMU,
00:49:48.020 --> 00:49:51.740
the inertial measurement unit. Three
gyroscopes, one per axis measure any
00:49:51.740 --> 00:49:54.810
rotation and provide their data to the
Apollo Guidance Computer to keep track of
00:49:54.810 --> 00:49:59.350
the attitude of the spacecraft. Before we
leave Earth orbit, let's quickly discuss
00:49:59.350 --> 00:50:02.490
the digital autopilot. It is the single
biggest program in the Apollo Guidance
00:50:02.490 --> 00:50:05.690
Computer, with about 10% of all the source
code both in the command and service
00:50:05.690 --> 00:50:09.080
module as well as the lunar module. The
implementations for each vehicle are
00:50:09.080 --> 00:50:12.140
significantly different though, due to
different flight modes, thruster sets,
00:50:12.140 --> 00:50:16.950
and symmetry of vehicle. As there's no
friction in space, the tiniest event would
00:50:16.950 --> 00:50:20.580
constantly make the spacecraft rotate. The
digital autopilot of the Apollo Guidance
00:50:20.580 --> 00:50:24.150
Computer uses the jets to maintain the
attitude within certain thresholds,
00:50:24.150 --> 00:50:28.420
so-called dead bands. The autopilot is
also used in case the astronauts ever need
00:50:28.420 --> 00:50:31.970
to use the hand controllers for thrusters.
Basically both the command service module
00:50:31.970 --> 00:50:35.400
and the lunar module have fly-by-wire
control. As any thruster could break at
00:50:35.400 --> 00:50:39.250
any time, the autopilot is capable of
calculating the ideal burn mode even with
00:50:39.250 --> 00:50:42.750
a reduced number of thrusters. It has some
simple algorithms for center of gravity and
00:50:42.750 --> 00:50:45.920
weight distribution as well, which are
taken into account when calculating
00:50:45.920 --> 00:50:50.360
thruster maneuvers. It can do more than
that, though. Give it a new attitude and
00:50:50.360 --> 00:50:54.320
it will calculate the most efficient
transfer vector to reach the new attitude.
00:50:54.320 --> 00:50:58.120
In certain flight modes it might be
required to have a stable rotation, be it
00:50:58.120 --> 00:51:01.240
for temperature control, monitoring of the
landing site, or other reasons. The
00:51:01.240 --> 00:51:05.510
autopilot supports stable constant
rolling, which can be directly activated.
00:51:05.510 --> 00:51:08.380
The autopilot does not only control
attitude, it also supports the crew in
00:51:08.380 --> 00:51:12.030
performing powered flight maneuvers. It
calculates a potential solution, which
00:51:12.030 --> 00:51:15.600
obviously can be overwritten by ground as
usual, but still, after confirmation the
00:51:15.600 --> 00:51:18.880
autopilot automatically fires the engines
and keeps a timer for the correct length
00:51:18.880 --> 00:51:23.590
of time. It does not measure the results
of the burn though. For powered flight
00:51:23.590 --> 00:51:27.220
obviously dead reckoning isn't correct
anymore, so the Apollo Guidance Computer
00:51:27.220 --> 00:51:30.960
contains a subroutine called average G,
which takes the input from the IMU,
00:51:30.960 --> 00:51:35.500
meaning gyro and accelerometer, to compute
the change to the state vector. Now that
00:51:35.500 --> 00:51:38.770
we know how to orient ourselves, and how
to control the spaceship, it's time we fly
00:51:38.770 --> 00:51:42.300
to the moon. Usually the translunar
injection happens in the middle of the
00:51:42.300 --> 00:51:46.120
second orbit around the earth, so around 2
hours 45 minutes into the flight. This is
00:51:46.120 --> 00:51:49.680
still performed by the third stage of the
SaturnV so the Apollo Guidance Computer
00:51:49.680 --> 00:51:52.280
once again should only have a passive role
here by monitoring the translunar
00:51:52.280 --> 00:51:56.220
injection with the dedicated program P 15.
After separation from the S-IV-B
00:51:56.220 --> 00:51:59.350
we are on our way. Since the next
interesting phase is the lunar
00:51:59.350 --> 00:52:04.210
landing, let's skip to that one. Once in
lunar orbit, separation between the
00:52:04.210 --> 00:52:07.380
command and service module and lunar
module happens four hours and 45 minutes
00:52:07.380 --> 00:52:11.450
before landing. On the lunar module,
directly afterwards, rendezvous equipment
00:52:11.450 --> 00:52:15.150
like radar, strobe and VHF are tested, as
well as the IMU, which is realigned.
00:52:15.150 --> 00:52:18.560
Additionally there's lots of preparation
work on the lunar module. One of the main
00:52:18.560 --> 00:52:22.580
tasks is to prepare the abort guidance
system, AGS, which is another, more
00:52:22.580 --> 00:52:25.450
simpler computer, that is able to get the
lunar module with the astronauts back into
00:52:25.450 --> 00:52:29.600
orbit and safely docked with the CSM in
case of an emergency. Let's get back to
00:52:29.600 --> 00:52:33.220
powered descent. The lunar module AGC has
a special program for that one, P 63,
00:52:33.220 --> 00:52:37.600
braking phase. The landing radar has
switched on and updates the state vector.
00:52:37.600 --> 00:52:40.460
The Apollo Guidance Computer controls the
burn to reach the correct corridor towards
00:52:40.460 --> 00:52:44.510
the surface with a minimal amount of fuel.
This is fully automatic, the astronauts
00:52:44.510 --> 00:52:47.910
just sit along for the ride. The lunar
module is oriented with its descent engine
00:52:47.910 --> 00:52:52.040
towards the moon, visibility for the
astronauts is close to zero. The second
00:52:52.040 --> 00:52:55.920
program, P 64, starts automatically at
around 8,000 feet. Lunar module is pitched
00:52:55.920 --> 00:52:58.900
so that the astronauts can actually see
the ground and the lunar module commander
00:52:58.900 --> 00:53:01.650
is getting a better understanding of the
landing site and can search for a suitable
00:53:01.650 --> 00:53:06.570
spot. The third program, P 68, keeps the
lunar module in a stable attitude above
00:53:06.570 --> 00:53:10.740
the surface and the commander manually
adjusts the height in one feet per second
00:53:10.740 --> 00:53:13.870
increments, to slowly descend to the
surface. Ideally at that point, the
00:53:13.870 --> 00:53:17.310
horizontal movement of the lunar module
should be zero. After touchdown the crew
00:53:17.310 --> 00:53:21.480
manually activates program 68, which
confirms to the Apollo guidance computer
00:53:21.480 --> 00:53:24.790
that yes, we have indeed landed, and
ensures that the engine is switched off,
00:53:24.790 --> 00:53:28.350
terminates the average G routine, and sets
the autopilot in a very forgiving setting,
00:53:28.350 --> 00:53:32.460
to avoid any corrections when it measures
the rotation of the moon. The autopilot is
00:53:32.460 --> 00:53:35.700
not completely switched off though, as the
astronaut might need it in case of an
00:53:35.700 --> 00:53:39.340
emergency ascent. Well we are on the moon,
we do the usual stuff, small step for man,
00:53:39.340 --> 00:53:42.940
jump around plant the flag, and we then
skip directly to the interesting bits
00:53:42.940 --> 00:53:46.950
which is liftoff and rendezvous. The
rendezvous technique was developed in the
00:53:46.950 --> 00:53:50.950
Gemini project. Here you can see the Agena
rendezvous target in Earth orbit. It
00:53:50.950 --> 00:53:54.030
follows the principle of an active
vehicle, in this case the lunar module,
00:53:54.030 --> 00:53:56.870
which follows the command and service
module and approaches it from below at
00:53:56.870 --> 00:54:00.980
slightly faster orbit. There were actually
two different ways for rendezvous. A more
00:54:00.980 --> 00:54:04.320
conservative method called Coelliptic
rendezvous which required one and a half
00:54:04.320 --> 00:54:07.470
orbits for the lunar module to reach the
command and service module, but gave ample
00:54:07.470 --> 00:54:11.610
opportunity for monitoring progress, mid-
course corrections, and orbit scenarios.
00:54:11.610 --> 00:54:14.660
And a more risky direct rendezvous method
which directly aimed the lunar module
00:54:14.660 --> 00:54:18.780
towards the command and service module,
taking less than one orbit until docking.
00:54:18.780 --> 00:54:22.430
This one was used starting from the Apollo
14 mission, as Mission Control had more
00:54:22.430 --> 00:54:28.140
experience and aimed for the shorter, less
fuel intensive method. Preparation had to
00:54:28.140 --> 00:54:32.290
start two hours before liftoff. We have to
align the IMU and we visually monitor the
00:54:32.290 --> 00:54:35.720
orbit of the CSM and calculate the
rendezvous data. The Apollo Guidance
00:54:35.720 --> 00:54:40.350
Computer has program 22, CSM tracking, for
this purpose. At liftoff minus one hour,
00:54:40.350 --> 00:54:44.130
we start program 12, powered ascent, and
feed it with the necessary data, liftoff
00:54:44.130 --> 00:54:48.640
time and velocity target. The Apollo
Guidance Computer performs the countdown,
00:54:48.640 --> 00:54:52.140
and ask for confirmation, we proceed and
we have liftoff.
00:54:52.140 --> 00:54:55.200
The trip into orbit takes only seven and a
half minutes but depending on which method
00:54:55.200 --> 00:54:58.300
for reaching the target orbit was used, it
takes us either one and a half, or three
00:54:58.300 --> 00:55:01.710
and a half hours to come up behind the
command and service module. During that
00:55:01.710 --> 00:55:04.810
time, program 20 is running all the time,
measuring the state vector of the other
00:55:04.810 --> 00:55:08.270
vehicle, the command and service module,
via various peripherals like rendezvous
00:55:08.270 --> 00:55:12.370
radar, VHF antenna, and the optic system
for visual alignment. It calculates the
00:55:12.370 --> 00:55:15.530
necessary corridor and respective
maneuvers required to get the lunar module
00:55:15.530 --> 00:55:18.800
into an interception course. Multiple
other programs run in parallel to perform
00:55:18.800 --> 00:55:22.920
the necessary mid-course burn maneuvers.
On the commander of service module, the
00:55:22.920 --> 00:55:25.730
pilot is actively tracking the lunar
module the whole way up to orbit. The
00:55:25.730 --> 00:55:28.580
command and service module's computer is
calculating the state vector of the lunar
00:55:28.580 --> 00:55:31.850
module, to take over the role of the
active vehicle, in case anything goes
00:55:31.850 --> 00:55:35.290
wrong. The approach of the lunar module
stops at 50 meter distance, at which point
00:55:35.290 --> 00:55:39.050
it rotates to point its docking target on
top towards the command and service
00:55:39.050 --> 00:55:42.700
module. At that point in time the command
service module takes over the active role
00:55:42.700 --> 00:55:46.590
and activates program 79, final
rendezvous, which slows down the command
00:55:46.590 --> 00:55:50.240
and service module to close the distance
until docking. Seconds before contact, the
00:55:50.240 --> 00:55:54.620
autopilot on both spacecraft is switched
off to avoid both trying to correct the
00:55:54.620 --> 00:55:58.740
attitude of the combined spacecraft. So
far so good, time to go home with the
00:55:58.740 --> 00:56:02.310
trans-earth injection. We feed the Apollo
guidance computer with Earth orbit
00:56:02.310 --> 00:56:05.910
parameters and let it calculate the burn
which is then activated and controlled.
00:56:05.910 --> 00:56:09.080
Any kind of potential mid-course
corrections are performed the exact same
00:56:09.080 --> 00:56:14.210
way. Once in orbit around Earth, re-entry
parameters are calculated on ground and
00:56:14.210 --> 00:56:17.260
transferred to the Apollo guidance
computer via a S-band uplink. The first
00:56:17.260 --> 00:56:21.720
entry program, P 61, entry preparation,
starts at entry minus 25 minutes. Various
00:56:21.720 --> 00:56:25.280
landing parameters are requested, like
latitude and longitude of the splash zone,
00:56:25.280 --> 00:56:28.631
as well as the velocity and angles to
enter the atmosphere. Entering and
00:56:28.631 --> 00:56:31.940
confirming these values completes program
61, and starts program 62, which basically
00:56:31.940 --> 00:56:35.850
asks the astronaut to perform a checklist
for manual command module - service module
00:56:35.850 --> 00:56:39.420
- separation, which is not controlled by
the Apollo guidance computer. After that
00:56:39.420 --> 00:56:42.750
has been performed it switches
automatically to program 63, entry
00:56:42.750 --> 00:56:47.630
initialization. At that point, the
autopilot is taking care of thruster
00:56:47.630 --> 00:56:51.250
control to break the command module out of
its orbit into Earth's atmosphere. The
00:56:51.250 --> 00:56:57.030
main program for re-entry is program 64,
entry, which starts automatically. Program
00:56:57.030 --> 00:57:00.490
64 monitors the trajectory, and splashdown
location, and determines the best entry
00:57:00.490 --> 00:57:04.570
solution and potential velocity reduction
by invoking two specific programs, either
00:57:04.570 --> 00:57:08.630
P 65, entry up control, which basically
makes the current module surf on the
00:57:08.630 --> 00:57:13.250
atmosphere to reduce speed and extend the
range, or program 66, entry ballistic,
00:57:13.250 --> 00:57:16.411
throwing us through the atmosphere like a
cannonball. The right mixture of the two
00:57:16.411 --> 00:57:22.020
is decided by program 64. The last
program, program 67, final phase, performs
00:57:22.020 --> 00:57:25.190
the final maneuvers to the splash down.
The following steps, like parachute
00:57:25.190 --> 00:57:28.790
deployment and so on, are not done by the
Apollo guidance computer but by the ELSC,
00:57:28.790 --> 00:57:32.200
the Earth Landing Sequence Controller. The
drop of the Apollo guidance computer is
00:57:32.200 --> 00:57:36.721
done before deploying the parachutes. So
this was a beautiful nominal mission, what
00:57:36.721 --> 00:57:42.320
can go wrong? Well let's start with Apollo
11, which had a 12 02 program alarm during
00:57:42.320 --> 00:57:46.380
powered descent. Normally programs during
powered descent use about 85% of the
00:57:46.380 --> 00:57:49.950
processing power of the computer, but due
to an incorrect power supply design, the
00:57:49.950 --> 00:57:53.100
rendezvous... of the rendezvous radar
generated an additional twelve thousand
00:57:53.100 --> 00:57:57.080
eight hundred involuntary instructions per
seconds, ironically amounting to the exact
00:57:57.080 --> 00:58:01.210
additional 15 percent load.
Due to the co-operative multitasking, a
00:58:01.210 --> 00:58:07.700
queue of jobs build up, which resulted in
executive overflow and the 12 02 alarm.
00:58:07.700 --> 00:58:11.180
The operating system automatically
performed a program abort, all jobs were
00:58:11.180 --> 00:58:14.860
cancelled and restarted. All of this took
just a few seconds, and landing could
00:58:14.860 --> 00:58:20.090
commence. Next, Apollo 13. They had an
explosion of the oxygen tank in the
00:58:20.090 --> 00:58:25.120
service module at 55 hours 54 minutes 53
seconds and it will ... yep, correct,
00:58:25.120 --> 00:58:29.230
320,000 kilometers from Earth. Fortunately
they could make use of the free return
00:58:29.230 --> 00:58:32.402
trajectory to get the astronauts back to
earth but they had to move to the lunar
00:58:32.402 --> 00:58:35.750
module to survive, as the command and
service module was completely shut down,
00:58:35.750 --> 00:58:39.030
including its Apollo Guidance Computer.
The IMU settings needed to be transferred
00:58:39.030 --> 00:58:42.200
to the lunar module system first, adapted
to the different orientations of the
00:58:42.200 --> 00:58:45.790
spacecraft. The manual burns and the mid-
course corrections were actually done with
00:58:45.790 --> 00:58:48.630
the abort guidance system on the lunar
module, due to power constraints with the
00:58:48.630 --> 00:58:52.170
Apollo Guidance Computer. Successful
reboot of the command and service module
00:58:52.170 --> 00:58:57.650
computer was luckily done hours before re-
entry. And last but not least, Apollo 14,
00:58:57.650 --> 00:59:00.630
which had a floating solder ball in the
abort button, which might lead to an
00:59:00.630 --> 00:59:03.450
unwanted activation of abort, therefore
putting the lunar module back into orbit.
00:59:03.450 --> 00:59:06.810
This was solved within hours, by
reprogramming the Apollo Guidance
00:59:06.810 --> 00:59:10.010
Computer, to spoof the execution of a
different program, which was not listening
00:59:10.010 --> 00:59:13.290
to the abort button during the powered
descend. Real abort activation though
00:59:13.290 --> 00:59:18.830
would have to be manually activated via
the DSKY. So this was an overview and how
00:59:18.830 --> 00:59:23.270
the mission software was used on a flight
to the moon and back.
00:59:23.270 --> 00:59:32.350
applause
00:59:32.350 --> 00:59:36.440
M: Now you probably want to run your own
code on a real Apollo Guidance Computer,
00:59:36.440 --> 00:59:41.100
so you need to know where to find one.
42 computers were built total.
00:59:41.100 --> 00:59:46.410
Seven lunar module computers crashed onto
the moon. Three lunar module AGC's burned
00:59:46.410 --> 00:59:50.470
up in the Earth's atmosphere, 11 command
module computers returned.
00:59:50.470 --> 00:59:55.520
They're all presumably parts of museum
exhibits. And 21 machines were not flown.
00:59:55.520 --> 00:59:59.180
Little is known about those. One is on
display at the Computer History Museum
00:59:59.180 --> 01:00:02.240
in Mountain View, California, but it is
missing some components.
01:00:02.240 --> 01:00:07.290
Luckily several emulation solutions are
publicly available, as well as a tool chain.
01:00:07.290 --> 01:00:11.740
And the complete mission source, originally
the size of a medium-sized suitcase,
01:00:11.740 --> 01:00:17.080
is available on github.
laughter
01:00:17.080 --> 01:00:25.700
applause
01:00:25.700 --> 01:00:29.430
It takes a village to create a presentation.
We would like to thank everyone who
01:00:29.430 --> 01:00:32.990
helped and supported us. This includes
the indirect contributors, who wrote
01:00:32.990 --> 01:00:35.940
the books, the original documentation,
the websites, and the software.
01:00:35.940 --> 01:00:39.560
Thank you very much for your attention.
C: Thank you.
01:00:39.580 --> 01:00:53.020
applause and cheering
01:00:53.020 --> 01:00:58.080
Herald: Wow that was a densely packed talk.
laughter
01:00:58.080 --> 01:01:06.260
Thanks Michael, and thanks Christian, for
this amazing information overload.
01:01:06.260 --> 01:01:11.410
Please give a warm hand of applause,
because we can't have a Q&A, unfortunately.
01:01:11.410 --> 01:01:20.108
applause
01:01:20.108 --> 01:01:35.448
postroll music
01:01:35.448 --> 01:01:41.301
subtitles created by c3subtitles.de
in the year 2018