Apollo Guidance Computer

Apollo Guidance Computer
Información
Tipo	Aviación Ordenador de guiado
Desarrollador	MIT Instrumentation Laboratory
Fabricante	Raytheon
Procesador	Basado en lógica RTL de CI discretos
Fecha de lanzamiento	Agosto de 1966
Descontinuación	Julio de 1975
Datos técnicos
Dimensiones	61x32x17 cm
Peso	31,8 kg
Alimentación	55 W[1]​: 120
Procesador	Basado en lógica RTL de CI discretos
Frecuencia	2,048 MHz
Memoria	palabras de 16-bits, 2048 palabras RAM (memoria de núcleos magnéticos), 36864 palabras de ROM (memoria de núcleos cableados)
Conectividad	DSKY, IMU, Controlador manual, Radar de rendezvous (CM), Radar de aterrizaje (LM), Receptor de telemetría, Controlador del Motor, Reaction Control System
[editar datos en Wikidata]

El Apollo Guidance Computer (por sus siglas, AGC; en español, Computador de Navegación del Apolo) fue un componente fundamental del programa Apolo. Proporcionaba la capacidad de cálculo necesaria para controlar la orientación y la navegación del módulo de mando y del módulo lunar.^[2]​ Este ordenador destaca por haber sido uno de los primeros computadores basados en circuitos integrados. El AGC y su interfaz DSKY se desarrollaron a principios de los 1960 por el MIT Instrumentation Laboratory para el programa Apolo.

A excepción del Apolo 8, que no llevó módulo lunar, cada misión contaba con dos ordenadores AGC, uno en el módulo de mando y otro en el módulo lunar. El AGC del módulo de mando estaba situado en el centro del sistema de navegación y orientación (GNC). El del módulo lunar llevaba su propio sistema primario de orientación, control y navegación del Apolo, conocido por el acrónimo de PGNCS (pronunciado como pings).

Además, cada misión contaba con otros dos ordenadores adicionales:

• El computador digital del lanzador (LVDC), situado en el anillo de instrumentación del cohete Saturno V.
• El sistema de orientación para aborto (AGS) del módulo lunar, para su uso en caso de fallo eventual del LM PGNCS. El AGS se podía usar para despegar desde la Luna, y para reencontrarse con el módulo de mando, pero no para alunizar.

El AGC se diseñó en el MIT Instrumentation Laboratory bajo la dirección de Charles Stark Draper, con el diseño hardware a cargo de Eldon C. Hall.^[1]​ Los primeros trabajos sobre la arquitectura llegaron de manos de J.H. Laning Jr., Albert Hopkins, Ramón Alonso,^[3]​^[4]​ y Hugh Blair-Smith.^[5]​ La empresa Raytheon fabricó el hardware de vuelo, y Herb Thaler^[6]​ también estaba en el equipo de diseño.

El computador de vuelo del Apolo fue el primero en usar circuitos integrados (CI). Mientras que la versión Block I usaba 4100 CIs, conteniendo cada uno una sencilla puerta NOR de 3 entradas, la versión posterior Block II (usada en los vuelos tripulados) empleó 2800 CIs, cada uno con dos puertas NOR de 3 entradas.^[1]​^: 34 Los CIs, de Fairchild Semiconductor, se implementaron usando lógica resistencia-transistor (RTL) en un flat-pack. Fueron conectados mediante enrollamiento, y luego el cableado se incorporó en un molde plástico de epoxy. Al usar un único tipo de integrado (las doble NOR3) para todo el AGC, se evitaron los problemas que plagaban los primeros diseños de computadores basados en CIs, como el computador de guiado Minuteman II, que usaba una mezcla de puertas con lógica diodo-transistor y otras con lógica diodo-resistor.

El computador tenía 2048 palabras de memoria de núcleos magnéticos volátil y 36 kilopalabras de memoria de núcleos cableados de solo lectura. Ambas tenían un ciclo de 11,72 microsegundos. La longitud de la palabra de memoria era de 16 bits: 15 bits de datos y 1 bit de paridad impar. El formato de palabra de la CPU de 16 bits eran 14 bits de datos, 1 bit de overflow, y 1 bit de signo (en representación complemento a uno).

La interfaz de usuario con la que se accedía al AGC era la DSKY (del inglés display and keyboard, en español teclado y pantalla), pronunciado comúnmente como dis-key. Poseía un vector de indicadores luminosos, varios visualizadores numéricos y un teclado tipo calculadora. Los comandos se introducían como números de dos dígitos: Verbo, y Nombre. El Verbo describía el tipo de la acción a realizar y el Nombre especificaba el dato afectado por la acción indicada por dicho verbo.

Los numerales se mostraban a través de visualizadores de siete segmentos electroluminescentes de alto voltaje de color verde. Para controlar estos visualizadores se usaban relés electromecánicos que limitaban su velocidad de refresco (la versión posterior Block II usaban rectificadores controlados de silicio más veloces). En ellos se podían visualizar tres números de 5 dígitos con signo en base octal o decimal, y se usaban típicamente para mostrar vectores tales como la actitud del vehículo espacial o un cambio de velocidad necesario (delta-V). Aunque los datos se almacenaban internamente en unidades métricas, estos se mostraban según el sistema anglosajón de unidades. Esta interfaz tipo calculadora^{[nb 1]}​ fue la primera de su clase, y el prototipo para todas la interfaces de paneles de control similares.

El módulo de mando tenía dos DSKYs conectadas al AGC, una en el panel de instrumentos principal y otra en la bahía de equipos, cerca de un sextante que se usaba para alinear la plataforma de navegación inercial. El módulo lunar tenía una única interfaz DSKY. Unos indicadores de actitud (FDAI), controlados por el AGC, se situaban sobre la DSKY en la consola del comandante y en el LM.

En 2009, se vendió un DSKY por $50 788 en la subasta pública organizada por Heritage Auctions.^[7]​

El cristal oscilador del reloj del AGC tenía una frecuencia de unos 2,048 MHz (2048 kHz). Esta señal se dividía por dos para producir un reloj de 1,024 MHz de cuatro fases que usaba el AGC para realizar las operaciones internas. Además, la señal de 1,024 MHz se dividía por dos para producir una señal de 512 kHz denominada frecuencia maestra; esta señal se usaba para sincronizar los sistemas externos del Apolo.

A su vez, la frecuencia maestra primero se dividía mediante un escalador por cinco, usando un contador en anillo para producir una señal de 102,4 kHz. Luego era dividida por dos a través de 17 etapas consecutivas: desde F1 (51,2 kHz) hasta F17 (0,78125 Hz). La etapa F10 (100 Hz) era retroalimentada hacia el AGC para incrementar el reloj en tiempo real y otros contadores involuntarios usando la instrucción Pinc. La etapa F17 se usaba para cargar intermitentemente el AGC cuando trabajaba en modo standby.

El AGC tenía cuatro registros de 16 bits con propósitos computacionales conocidos como los registros centrales:

A :	El acumulador, para uso general
Z :	El contador de programa - la dirección de la siguiente instrucción a ser ejecutada
Q :	El resto de la instrucción DV, y la dirección de retorno en las instrucciones TC
LP :	El producto inferior en las instrucciones MP

También había cuatro posiciones en la memoria central, en las direcciones 20-23, denominadas posiciones de edición porque lo que estuviera almacenado allí sería devuelto desplazado o rotado un bit, excepto para lo que fuera desplazado a la derecha 7 bits, para extraer uno de los 2 códigos de operación de 7 bits empaquetados en una palabra. Esto era común a los AGC del Bloque I y del Bloque II.

El AGC tenía varios registros adicionales que se usaban internamente durante el transcurso de una operación:

S	Registro de 12 bits de dirección de memoria, la parte inferior de la dirección de memoria
Bank/Fbank	Registro de 4 bits de la ROM, para seleccionar el 1 k de palabras de la ROM cuando se direcciona en el modo conmutable-fijo
Ebank	Registro de 3 bits de la RAM, para seleccionar las 256 palabras de la RAM cuando se direcciona en el modo conmutable-volátil
Sbank (super-bank)	Extensión de 1 bit al Fbank, necesario porque las últimas 4 kilopalabras de la ROM de 36-kilopalabras no es alcanzable usando solo Fbank
SQ	Registro de secuencia de 4 bits; la instrucción actual
G	Registro de 16 bits del buffer de memoria, para mantener la transmisión de palabras de datos desde y hacia la memoria
X	La entrada 'x' del sumador (el sumador se usaba para realizar toda la aritmética complemento a uno) o el incremento del contador de programa (registro Z)
Y	La otra entrada ('y') al sumador
U	No es realmente un registro, sino la salida del sumador (la suma en complemento a 1 del contenido de los registros X e Y)
B	Registro buffer de propósito general, también usado para pre-cargar la siguiente instrucción. Al comienzo de la siguiente instrucción, los bits superiores de B (con el siguiente código de operación) eran copiados a SQ, y los bits inferiores (la dirección) eran copiados a S.
C	No es un registro independiente, sino el complemento a uno del registro B
IN	Cuatro registros de entrada de 16 bits
OUT	Cinco registro de salida de 16 bits

El formato de las instrucciones emplea 3 bits para el código de operación y 12 bits para las direcciones. Block I tenía 11 instrucciones: TC, CCS, INDEX, XCH, CS, TS, AD, y MASK (básicas), y SU, MP y DV (extras). Las ocho primeras, llamadas instrucciones básicas eran utilizadas directamente por el código de operación de 3 bits. El acceso a las últimas tres instrucciones era a través de un tipo especial de la instrucción INDEX llamada EXTEND, justo antes de la instrucción. Las instrucciones del AGC de Block I son:

TC (transfer control)

Salto incondicional a la dirección especificada en la instrucción. La dirección de retorno se almacenaba automáticamente en el registro Q, de forma que la instrucción TC se podía emplear para llamar a subrutinas.

CCS (count, compare, and skip)

Instrucción de salto condicional complejo. El registro A se cargaba con datos recuperados de la dirección especificada en la instrucción. (Debido a que el AGC usa la notación de complemento a 1, existen dos representaciones del 0. Cuando todos sus bits están a 0, se llama +0 [más cero]. Si todos los bits están a 1, se llama -0 [menos cero].) El valor absoluto disminuido (DABS) se operaba y se almacenaba en el registro A. Si el número era mayor de 0, el DABS decrementaba el valor en 1; si el número era negativo se calculaba su complemento antes de ser decrementado (ese es el valor absoluto). Por disminuido se entiende “decrementado pero no por debajo de cero”. Por lo tanto, cuando el AGC ejecuta la función DABS, los números positivos tenderán a +0 y también lo harán los negativos, pero después de informar su valor negativo a través del salto de cuatro vías (a continuación). El último paso en CCS es el salto de cuatro vías, dependiendo del dato del registro A antes del DBAS. Si el registro A era mayor que 0, CCS saltaba a la primera instrucción inmediatamente después de CCS. Si el registro A contenía +0, CCS saltaba a la segunda instrucción después de CCS, y -0 saltaba a la cuarta instrucción después de CCS. El objetivo principal de la cuenta era facilitar los bucles sencillos, controlados por un contador positivo, para acabar en un CCS, y un TC al principio del bucle, equivalente al BCT del IBM 360. La función de valor absoluto se consideró suficientemente importante para ser incorporada dentro de esta instrucción; cuando se usa para solamente esta función, la secuencia después de CCS era TC *+2, TC*+2, AD ONE. Un efecto colateral curioso era la creación y uso de agujeros CCS cuando se sabía que el valor probado nunca sería positivo, que ocurría más a menudo de lo que se esperaba. Eso dejaba dos palabras completas desocupadas y era responsabilidad de un comité especial ubicar valores constantes en esos agujeros.

INDEX

Suma el dato recuperado de la dirección especificada en la instrucción, a la siguiente instrucción. INDEX se puede usar para sumar o restar un índice a la dirección base especificada por el operando de la instrucción siguiente a INDEX. Este método se usa para implementar vectores, matrices y tablas de búsqueda; desde que la suma se hace en ambas palabras completas, también se usaba para modificar el código de operación en una instrucción extra, y en raras ocasiones ambas funciones a la vez.

RESUME

Una particularidad de INDEX (INDEX 25). Esta es la instrucción usada para volver de una interrupción. Provoca que la ejecución vuelva al punto de la interrupción.

XCH (exchange)

Intercambie el contenido de la memoria con el contenido del registro A. Si la dirección de memoria especificada es de memoria de sólo lectura, el contenido de la memoria no se ve afectado, y la instrucción únicamente carga el registro A. Si es una memoria volátil, se alcanza la corrección de desbordamiento (overflow) almacenando el bit más a la izquierda de los 16 bits de A como el bit de signo.

CS (clear and subtract)

Carga el registro A con el complemento a 1 del dato referenciado en la dirección de memoria especificada.

TS (transfer to storage)

Almacena el registro A en una dirección de memoria específica. TS además detecta y corrige desbordamientos de tal forma que puede propagar el acarreo de bits en una suma/resta multi precisión. Si el resultado no produce desbordamiento (los dos bits izquierdos de A con el mismo valor) no ocurre nada especial; si hay desbordamiento (esos dos bits distintos), el 1 más a la izquierda se lleva a la memoria como el bit de signo y el registro A se cambia a +1 o -1 según corresponda, y el control salta a la segunda instrucción después de TS. Como siempre es posible (aunque anormal) que suceda un desbordamiento, la instrucción TS se sigue de una TC a la lógica de no desbordamiento; cuando es una posibilidad normal (como en sumas/restas multi precisión), la instrucción TS va seguida por CAF ZERO (CAF = XCH a memoria fija) para completar la formación del bit de acarreo (+1, 0 o -1) en la siguiente palabra de alta precisión. Los ángulos se mantenían en precisión simple, mientras que las distancias y velocidades se almacenaban en doble precisión y el tiempo transcurrido en tripe precisión.

AD (add)

Añade el contenido de la memoria al registro A y almacena el resultado en A. Los dos bits más a la izquierda de A pueden ser diferentes (desbordamiento) antes o después de AD. El hecho de que el desbordamiento sea un estado más que un evento, perdona amplía las limitaciones del desbordamiento cuando se suman más de dos números siempre y cuando ninguno de los totales intermedios supera el doble de la capacidad de una palabra.

MASK

Ejecuta un AND de bits (booleano) de la memoria con el registro A y almacena el resultado en el registro A.

MP (multiply)

Multiplica el contenido del registro A por el dato de la dirección de memoria referenciada y almacena la parte más significativa del producto en el registro A y la menos significativa en el registro LP. Ambas partes del producto comparten el signo.

DV (divide)

Divide el contenido del registro A por el dato referenciado en la dirección de memoria. Almacena el cociente en el registro A y el valor absoluto del resto en el registro Q. De forma distinta a las máquinas modernas, los números reales se trataban como fracciones (punto decimal justo a la derecha del bit de signo), de manera que se podía producir basura si el divisor no era tan largo como el dividendo; no había protección frente a estas situaciones. En el AGC del Block II, un dividendo de doble precisión comenzaba en A y L (el registro LP del Block II), y el resto, con su signo, se dejaba en L. Esto simplificaba considerablemente la subrutina para la división de doble precisión.

SU (subtract)

Resta (complemento a 1) el dato en la posición de memoria referencia del contenido del registro A, almacenando el resultado en A.

Las instrucciones se implementaban en grupos de 12 pasos, llamados pulsos de temporización (timing pulses). Los pulsos se nombraban de TP1 a TP12. Cada conjunto de 12 pulsos se llamaba subsecuencia de instrucción. Las instrucciones simples, como TC, se ejecutaban en una sola subsecuencia de 12 pulsos. Las instrucciones más complejas necesitaban varias subsecuencias. La instrucción de multiplicación (MP) usaba 8 subsecuencias: una inicial llamapa MP0, seguida de una subsecuencia MP repetida 6 veces y terminada por MP3. Se redujo a 3 subsecuencias en Block II. Cada pulso de temporización (TP) en una subsecuencia podía disparar hasta 5 pulsos de control. Los pulsos de control eran señales que hacía en trabajo de la instrucción, como leer el contenido de un registro en el bus, o escribir datos del bus en un registro.

La memoria del AGC Block I estaba organizada en bancos de 1K palabras (KP). El primer banco (banco 0) era de memoria volátil (RAM). Todos los siguientes bancos eran memoria fija (ROM).

Cada instrucción AGC tenía un campo de direccionamiento de 12 bits. Los bits más bajos (1-10) direccionan la memoria dentro de cada banco. Los bits 11 y 12 seleccionan el banco: 00 selecciona el banco RAM (banco 0), 01 el banco 1 (ROM), 10 el siguiente (banco 2, ROM) y 11 selecciona el registro de banco, que se puede usar para seleccionar cualquier banco por encima del 2. Los bancos 1 y 2 se denominaban bancos de memoria fijo-fijo porque siempre estaban disponibles independientemente del contenido del registro de banco. Los bancos 3 y superior e llamaban fijo-seleccionable porque el banco seleccionado se seleccionaba por el registro de banco.

Originalmente, el AGC Block I tenía 12KP de memoria fija, pero se incrementó posteriormente a 24 KP. El Block II tenía 32 KP de memoria fija y 4 KP de memoria RAM.

El AGC transfería datos desde y hacia la memoria a través del registro G en un proceso llamado ciclo de memoria. El ciclo de memoria duraba 12 pulsos de temporización (11,72 μs), comenzando en el TP1 cuando el AGC cargaba la dirección de memoria a ser leída en el registro S. El hardware de la memoria recuperaba el dato/la palabra de la memoria de la dirección especificada en el registro S. Las palabras de la RAM se depositaban en el registro G en el TP6; las palabras de la ROM estaban disponibles en el TP7. La palabra recuperada de la memoria quedaba disponible en el registro G para el acceso del AGC durante los TP7 a TP10. Después del TP10, el dato existente en el registro G se escribía en la memoria.

El ciclo de memoria del AGC tenía lugar de forma continua durante el funcionamiento del AGC. Las instrucciones que necesitaban datos de la memoria accedían a ellos durante los pulsos TP7-10. Si el AGC cambiaba la palabra de memoria en el registro G, la palabra cambiada era restaurada en memoria tras el pulso TP10. De esta forma, las palabras de datos ciclaban continuamente de la memoria al registro G, y de nuevo a la memoria.

Los 15 bits más bajos de cada palabra contenían instrucciones AGC o datos, usando el bit 16 como bit de paridad. Este bit se ponía a 0 o 1 a través de un circuito de generador de paridad de forma que la suma de 1 en cada palabra en la memoria, siempre fuera un número impar. Para verificar el bit de paridad, se disponía de un circuito de chequeo de paridad que se encargaba de la verificación en cada ciclo de memoria; si el bit no tenía el valor esperado, se asumía que el dato estaba corrompido y se iluminaba la luz de alarma de paridad en el panel.

El AGC tenía un modo de ahorro de energía controlado por un interruptor de standby. Este modo cortaba la corriente del AGC excepto al reloj y al contador de impulsos. La señal F17 del contador de impulsos encendía y apagaba el AGC en intervalos de 1,28 segundos. En este modo, el AGC ejecutaba funciones esenciales, chequeaba el interruptor de standby y si estaba pulsado, cortaba la corriente y volvía a dormir hasta la siguiente señal F17.

En el modo standby el AGC permanecía dormido la mayor parte del tiempo, por lo que no se despertaba para ejecutar la instrucción Pinc necesaria para actualizar el reloj en tiempo real del AGC a intervalos de 10 ms. Para compensarlo, una de las funciones ejecutadas por el AGC cada vez que se despertaba era actualizar el reloj en tiempo real en 1,28 segundos.

El modo standby se diseñó para reducir el consumo de energía de 70 W a unos 5-10 W durante el curso medio del vuelo, cuando el AGC no era necesario. Sin embargo, en la práctica, el AGC se dejó encendido en todas las fases de la misión y nunca se usó esta característica.

El ACG tenía unos buses de lectura y escritura de 16 bits. Los datos de los registros centrales (A, Q, Z o LP), u otros registros internos se podían colocar en el bus de lectura con una señal de control. El bus de lectura se conectaba con el bus de escritura a través de un búfer, de forma que cualquier dato que aparecía en el bus de lectura, también aparecía en el de escritura. Otras señales de control podían copiar los datos del bus de escritura en los registros.

Las transferencias de datos se comportaban de la siguiente manera: para mover la dirección de la siguiente instrucción desde el registro B al registro S, se empleaba una señal de control RB (READ B). Esto causaba que la dirección se moviese del registro B al bus de lectura y de ahí al bus de escritura. Una señal de control WS (WRITE S) movía la dirección desde el bus de escritura al registro S.

Existía la posibilidad de leer simultáneamente varios registros en el bus de lectura. Cuando esto ocurría, los datos de cada registro se incorporaban al bus a por medio de un OR (inclusivo). Este OR se usó para implementar la instrucción MASK que era una operación AND lógica. Debido a que el AGC no tenía posibilidad de hacer un AND lógico, pero sí un OR lógico a través del bus, y se puede invertir datos a través del registro C, según el teorema de De Morgan, se podía implementar un AND lógico a base de OR lógico y NOT, invirtiendo ambos operandos, ejecutando un OR lógico en el bus e invirtiendo el resultado.

Cuando se terminaron de definir los requisitos de diseño del AGC, el software necesario para su desarrollo, así como las técnicas de programación apropiadas no existían, por lo que tuvieron que ser diseñadas desde cero.

El software AGC estaba escrito en lenguaje de programación AGC, y era almacenado en memoria de núcleos cableados. Existía un simple sistema operativo de tiempo real que consistía en el Exec, un sistema de ordenamiento de procesos que podía ejecutar hasta ocho 'tareas' a la vez usando una arquitectura cooperativa multitarea (cada tarea debía periódicamente devolver el control al Exec, que entonces comprobaba si había alguna tarea pendiente con mayor prioridad). También existía un componente de interrupción llamado Waitlist, que podía programar múltiples tareas de una duración determinada. Estos procesos eran cortas listas de código de ejecución que podía autoprogramarse para una nueva ejecución en el Waitlist, o podía lanzar una operación mayor, al iniciar una 'tarea' con el Exec.

La ejecución de los procesos del Exec se basaban en su prioridad. La tarea de menor prioridad, llamada dummy job, se encontraba siempre presente. Realizaba chequeos de diagnóstico y controlaba una luz verde relacionada con la actividad del ordenador en el DSKY: si la aplicación dummy estaba en marcha, significaba que el ordenador no tenía ninguna aplicación más prioritaria, por lo que la luz se encontraba apagada. La aplicación dummy se cancelaba si existía alguna tarea de mayor prioridad pendiente de ejecutar, lo que se indicaba mediante el encendido de la luz de iluminación de la actividad del ordenador.

El AGC también disponía de un sofisticado intérprete de software, desarrollado por el MIT Instrumentation Laboratory, que implementaba una máquina virtual de mayor complejidad y capacidad de pseudo-instrucciones que el AGC nativo. Estas instrucciones simplificaban los programas navigacionales. El código interpretado, que permitía trigonometría de doble precisión, aritmética escalar y vectorial (16 y 24 bits), e incluso instrucciones MXV (matriz × vector), podía mezclarse con código AGC nativo. Mientras que el tiempo de ejecución de las pseudo-instrucciones se incrementaba (debido a la necesidad de interpretar estas instrucciones durante la ejecución) el intérprete proporcionaba muchas más instrucciones de las que el AGC soportaba de forma nativa, y los requisitos de memoria eran mucho más bajos que en el caso de que se incorporaran estas instrucciones al lenguaje de programación nativo del AGC, que requerirían la utilización de memoria adicional en el ordenador (en aquel tiempo la capacidad de memoria era muy cara). El tiempo medio de ejecución de las pseudo-instrucciones era de 24 ms. El compilador y el sistema de control de versión, llamado YUL por el prototipo previo Christmas Computer,^[8]​ aseguraba las transiciones adecuadas entre el código nativo e interpretado.

Una serie de rutinas para interfaz del usuario llamadas Pinball proporcionaban los servicios de display y teclado para realizar las tareas de funcionamiento del AGC. Un extenso conjunto de rutinas de acceso estaban disponibles para permitir al operador (el astronauta) mostrar los contenidos de varios bloques de memoria en formato sistema octal o decimal en grupos de 1, 2, o 3 registros al mismo tiempo. También se proporcionaban rutinas de monitoreo para que el operador pudiera iniciar una tarea para volver a mostrar periódicamente los contenidos de ciertos bloques de memoria. Era posible también iniciar tareas. Las rutinas Pinball conformaban el equivalente (de forma muy aproximada) del núcleo UNIX.

La mayor parte del software se encontraba en memoria de solo lectura y por tanto no podía ser cambiado en ejecución, pero algunas partes determinadas del software estaban almacenadas en memoria de núcleos magnéticos editables, por lo que podían ser sobreescritos por los astronautas utilizando la interfaz DSKY, como de hecho ocurrió durante el vuelo del Apolo 14.

Los principios de diseño del AGC desarrollados por el MIT Instrumentation Laboratory, entonces bajo la dirección de la científica Margaret Hamilton, formarían los cimientos de la llamada "ingeniería de software", un término acuñado por Anthony Oettinger^[9]​^[10]​ - particularmente para el diseño de sistemas más fiables que se apoyaran en software asíncrono, planificación por prioridad, testeo y modelos en los que la capacidad de decisión del humano estuviera presente.^[11]​ El software del AGC software influyó en el diseño posterior del Skylab, el transbordador espacial y los primitivos sistemas de aviónica basados en fly-by-wire.^[12]​^[13]​

En 1966 se diseñó una nueva versión del AGC, llamada Block II (bloque II). Mantenía la misma arquitectura básica del bloque I, pero incrementaba la memoria volátil de 1000 a 2000 palabras. La memoria fija se expandió de 24 000 a 36 000 palabras. Las instrucciones se expandieron de 11 a 34 y se implementaron canales I/O para reemplazar a los registros I/O del bloque I. La versión del bloque II fue la que se utilizó en los vuelos que llegaron a la Luna. El bloque I fue utilizado durante los vuelos no tripulados del Apolo 4 y Apolo 6, así como a bordo del malogrado Apolo 1.

El PGNCS del Apolo generó avisos de error no previstos durante el vuelo de descenso a la superficie lunar del Apolo 11, en la que el AGC mostraba la alarma 1201 ("Executive overflow - no vacant areas") y la alarma 1202 ("Executive overflow - no core sets").^[14]​ Esto se debió a una rápida y continuada corriente de "robos de ciclo" realizados por el radar de aproximación, dejado de forma intencionada en standby durante el descenso en caso de que fuera necesario por un aborto de la maniobra de alunizaje.^[15]​^[16]​

Durante esta parte del descenso, el procesador se debía encontrar normalmente a casi un 85% de carga de trabajo. Los 6.400 ciclos extras por segundo añadieron el equivalente a un 13% de carga, dejando justo la necesaria para que todas las tareas pudieran ejecutarse. A los cinco minutos de iniciar el descenso, Buzz Aldrin programó el ordenador con el comando 1668 que daba instrucciones de calcular y mostrar DELTAH (la diferencia entre la altitud medida con el radar y la calculada por el ordenador). Esto añadió un 10% adicional a la carga de trabajo del procesador, causando un desbordamiento y la alarma 1202. Tras el permiso desde el control de tierra en Houston, que dio luz verde para el alunizaje, Aldrin introdujo de nuevo el comando 1668, y la alarma 1202 volvió a saltar. Cuando informó de la segunda alarma, Aldrin comentó "Parece que aparece cuando tenemos la tarea 1668 en ejecución". Afortunadamente para el Apolo 11, el software del AGC había sido diseñado con control de prioridad. Justo para lo que había sido diseñado, el software se recuperó automáticamente, eliminando las tareas no prioritarias incluyendo el comando 1668, para completar las tareas críticas de control y guiado. El controlador de vuelo Steve Bales y su equipo de apoyo, que incluía a Jack Garman, dio permiso en repetidas ocasiones para la continuidad del alunizaje, y este fue un éxito. Por su trabajo, Bales recibió la Medalla Presidencial de la Libertad en nombre de todo el equipo del centro de control y los tres astronautas del Apolo.^[17]​

El problema no era un error de programación del AGC ni un error de pilotaje, sino en el diseño del hardware periférico que ya había sido detectado y documentado por los ingenieros del Apolo 5.^[18]​ Sin embargo, como el problema había ocurrido una sola vez durante las pruebas, determinaron que era más seguro operar con el hardware existente ya probado, que volar con un sistema de radar más nuevo pero no probado. En el hardware real, la posición del radar de encuentro se codificó con una sincronización excitada por una fuente diferente de CA de 800 Hz diferente a la utilizada por la computadora como referencia de tiempo. Las dos fuentes de 800 Hz fueron enclavadas en frecuencia pero no en fase, y las pequeñas variaciones aleatorias de fase hicieron que pareciera que la antena estaba "oscilando" rápidamente en su posición a pesar de estar completamente estacionaria. Estos movimientos fantasmas generaron la serie rápida de robos de ciclo.

Tras su uso en el programa Apolo, el AGC formó parte de un sistema experimental fly-by-wire (FBW) instalado a bordo de un F-8 Crusader para demostrar la practicidad de un FBW manejado mediante ordenador. El AGC usado en la primera fase del programa fue reemplazado por otro sistema en la segunda fase, y la investigación realizada en el programa derivó en el desarrollo de sistemas FBW para el transbordador espacial. El AGC también sirvió, aunque indirectamente, al desarrollo de sistemas FBW para la generación de cazas que se estaban desarrollando en aquella época.^[19]​

El AGC también fue usado en el Vehículo de rescate de inmersión profunda (DSRV, Deep Submergence Rescue Vehicle) de la Armada de los Estados Unidos.^[20]​

• Apolo PGNCS - el sistema primario de navegación y orientación del Apolo
• AP-101 - computadores (derivados del IBM S/360) que se usaron en el transbordador espacial
• Historia del hardware de computador

• Wikimedia Commons alberga una categoría multimedia sobre Apollo Guidance Computer.

• AGC4 Memo #9, Block II Instructions – The infamous memo that served as de facto official documentation of the instruction set
• Computers in Spaceflight: The NASA Experience – By James Tomayko (Chapter 2, Part 5, The Apollo guidance computer: Hardware)
• Computers Take Flight – By James Tomayko
• The Apollo Guidance Computer - A Users View (PDF) – By David Scott, Apollo mission astronaut
• Lunar Module Attitude Controller Assembly Input Processing (PDF) – By José Portillo Lugo, History of Technology
• The MIT AGC Project – With comprehensive document archive
  • Luminary software source code listing, for Lunar Module guidance computer. (nb. 622 Mb)
  • Colossus software source code listing, for Command Module guidance computer. (nb. 83 Mb)
• National Air and Space Museum's AGC Block I and Dsky
• Annotations to Eldon Hall's Journey to the Moon – An AGC system programmer discusses some obscure details of the development of AGC, including specifics of Ed's Interrupt

• Apollo Guidance Computer Schematics
• AGC Integrated Circuit Packages
• Integrated Circuits in the Apollo Guidance Computer

• Delco Electronics, Apollo 15 - Manual for CSM and LEM AGC software used on the Apollo 15 mission, including detailed user interface procedures, explanation of many underlying algorithms and limited hardware information. Note that this document has over 500 pages and is over 150 megabytes in size.

• Stengel, R., Manual Attitude Control of the Lunar Module, J. Spacecraft and Rockets, Vol. 7, No. 8, Aug 1970, pp. 941–948.
• Source code for Command Module code (Comanche054) and Lunar Module code (Luminary099) as text.

• AGC Replica – John Pultorak's successful project to build a hardware replica of the Block I AGC in his basement. Mirror site: AGC Replica.
• Virtual AGC Home Page – Ronald Burkey's AGC simulator, plus source and binary code recovery for the Colossus (CSM) and Luminary (LEM) SW
• Project Apollo for Orbiter – Addon for Orbiter spaceflight simulator, working towards a full simulation of the CSM and LEM including the Virtual AGC.
• Eagle Lander 3D Shareware Lunar Lander Simulator with a working AGC and DSKY (Windows only)

• Weaving the way to the Moon (BBC News)