El Apollo Guidance Computer ( AGC ) fue un ordenador digital producido para el programa Apollo que se instaló a bordo de cada módulo de comando Apollo (CM) y módulo lunar Apollo (LM). El AGC proporcionó interfaces electrónicas y de computación para la guía, navegación y control de la nave espacial. [3] El AGC fue el primer ordenador basado en circuitos integrados de silicio . [ cita requerida ] El rendimiento del ordenador era comparable al de la primera generación de ordenadores domésticos de finales de los años 1970, como el Apple II , el TRS-80 y el Commodore PET . [4]
El AGC tiene una longitud de palabra de 16 bits , con 15 bits de datos y un bit de paridad . La mayor parte del software del AGC se almacena en una memoria especial de solo lectura conocida como memoria de núcleo trenzado , creada tejiendo cables a través y alrededor de núcleos magnéticos , aunque hay disponible una pequeña cantidad de memoria de núcleo de lectura/escritura .
Los astronautas se comunicaban con el AGC mediante una pantalla numérica y un teclado llamado DSKY (por "display and keyboard", que se pronuncia "DIS-kee"). El AGC y su interfaz de usuario DSKY fueron desarrollados a principios de los años 1960 para el programa Apolo por el Laboratorio de Instrumentación del MIT y volaron por primera vez en 1966. [5]
Los astronautas volaron manualmente el Proyecto Gemini con palancas de control , pero las computadoras volaron la mayor parte del Proyecto Apolo, excepto brevemente durante los aterrizajes lunares. [6] Cada vuelo a la Luna llevaba dos AGC, uno en el módulo de comando y el módulo lunar Apolo , con la excepción del Apolo 7 , que era una misión en órbita terrestre, y el Apolo 8 , que no necesitaba un módulo lunar para su misión en órbita lunar. El AGC en el módulo de comando era el centro de su sistema de guía, navegación y control (GNC). El AGC en el módulo lunar ejecutaba su PGNCS (sistema primario de guía, navegación y control) Apolo , con el acrónimo pronunciado como pings .
Cada misión lunar tenía dos computadoras adicionales:
El AGC fue diseñado en el Laboratorio de Instrumentación del MIT bajo la dirección de Charles Stark Draper , con el diseño de hardware dirigido por Eldon C. Hall . [2] Los primeros trabajos de arquitectura vinieron de JH Laning Jr. , Albert Hopkins , Richard Battin , Ramon Alonso, [7] [8] y Hugh Blair-Smith. [9] El hardware de vuelo fue fabricado por Raytheon , cuyo Herb Thaler [10] también estaba en el equipo de arquitectura.
Según Kurinec et al., los chips se soldaron a las placas en lugar de soldarse como podría esperarse. [11] Los dibujos del módulo lógico de la computadora de guía Apollo especifican soldadura por resistencia. [12] [13]
Tras el uso de chips de circuitos integrados (CI) en la Plataforma de Monitoreo Interplanetario (IMP) en 1963, la tecnología de CI se adoptó posteriormente para el AGC. [14] La computadora de vuelo Apolo fue la primera computadora en utilizar chips de CI de silicio . [15]
Mientras que la versión Block I utilizaba 4.100 circuitos integrados, cada uno de los cuales contenía una única compuerta NOR de tres entradas , la versión Block II posterior (utilizada en los vuelos tripulados) utilizaba unos 2.800 circuitos integrados, en su mayoría compuertas NOR duales de tres entradas y un número menor de expansores y amplificadores de detección. [16] : 27, 266 Los circuitos integrados, de Fairchild Semiconductor , se implementaron utilizando lógica de resistencia-transistor (RTL) en un paquete plano . Se conectaron mediante envoltura de cable y luego el cableado se incrustó en plástico epoxi fundido. [16] : 129
El uso de un único tipo de CI (el NOR3 dual) en todo el AGC evitó los problemas que plagaron otro diseño temprano de computadora con CI, la computadora de guía Minuteman II , que usaba una mezcla de lógica de diodo-transistor y puertas lógicas de diodo . [ cita requerida ] Las puertas NOR son puertas lógicas universales a partir de las cuales se puede hacer cualquier otra puerta, aunque al costo de usar más puertas. [17]
La computadora tenía 2048 palabras de memoria de núcleo magnético borrable y 36 864 palabras de memoria de núcleo magnético de solo lectura . [16] : 27, 90–93 Ambos tenían tiempos de ciclo de 11,72 microsegundos. [16] : 27 La longitud de palabra de memoria era de 16 bits: 15 bits de datos y un bit de paridad impar . El formato de palabra de 16 bits interno de la CPU era de 14 bits de datos, un bit de desbordamiento y un bit de signo ( representación de complemento a uno ). [16] : 35–37
_used_on_F-8_DFBW_DVIDS683588.jpg/1280px-Apollo_display_and_keyboard_unit_(DSKY)_used_on_F-8_DFBW_DVIDS683588.jpg)
La interfaz de usuario del AGC era DSKY , que significa pantalla y teclado y que normalmente se pronuncia "DIS-kee". Tiene una serie de luces indicadoras, pantallas numéricas y un teclado estilo calculadora . Los comandos se ingresaban numéricamente, como números de dos dígitos: Verbo y Sustantivo . Verbo describía el tipo de acción que se debía realizar y Sustantivo especificaba qué datos se veían afectados por la acción especificada por el comando Verbo.
Cada dígito se mostraba a través de una pantalla electroluminiscente de siete segmentos de alto voltaje (especificada como 530 nm [18] ); estos eran accionados por relés electromecánicos , lo que limitaba la tasa de actualización. También se podían mostrar tres números con signo de cinco dígitos en octal o decimal , y generalmente se usaban para mostrar vectores como la actitud de la nave espacial o un cambio de velocidad requerido ( delta-V ). Aunque los datos se almacenaban internamente en unidades métricas , se mostraban como unidades habituales de los Estados Unidos . Esta interfaz de estilo calculadora fue la primera de su tipo.
El módulo de mando tiene dos DSKY conectados a su AGC: uno situado en el panel de instrumentos principal y un segundo situado en el compartimento de equipamiento inferior, cerca de un sextante utilizado para alinear la plataforma de guía inercial . El módulo lunar tenía un solo DSKY para su AGC. Un indicador de actitud del director de vuelo (FDAI), controlado por el AGC, estaba situado encima del DSKY en la consola del comandante y en el LM.
La referencia de tiempo del AGC provenía de un reloj de cristal de 2,048 MHz . El reloj se dividió por dos para producir un reloj de cuatro fases de 1,024 MHz que el AGC utilizó para realizar operaciones internas. El reloj de 1,024 MHz también se dividió por dos para producir una señal de 512 kHz llamada frecuencia maestra ; esta señal se utilizó para sincronizar los sistemas externos de la nave espacial Apolo.
La frecuencia maestra se dividió a su vez mediante un escalador , primero por cinco utilizando un contador de anillo para producir una señal de 102,4 kHz. Luego, esta se dividió por dos a través de 17 etapas sucesivas llamadas F1 (51,2 kHz) a F17 (0,78125 Hz). La etapa F10 (100 Hz) se realimentó al AGC para incrementar el reloj de tiempo real y otros contadores involuntarios utilizando Pinc (que se analiza a continuación). La etapa F17 se utilizó para ejecutar de forma intermitente el AGC cuando estaba funcionando en modo de espera .
El AGC tenía cuatro registros de 16 bits para uso computacional general, llamados registros centrales :
DVinstrucciones y la dirección de retorno después de TClas instruccionesMPlas instruccionesTambién había cuatro ubicaciones en la memoria central, en las direcciones 20 a 23, denominadas ubicaciones de edición porque todo lo que se almacenaba allí salía desplazado o rotado una posición de bit, excepto una que se desplazaba siete posiciones de bit a la derecha, para extraer uno de los códigos operacionales interpretativos de siete bits que se empaquetaban de a dos por palabra. Esto era común a los AGC del bloque I y del bloque II.
La AGC contaba con registros adicionales que se utilizaban internamente en el curso de su funcionamiento:
El formato de instrucción utilizaba 3 bits para el código de operación y 12 bits para la dirección. El bloque I tenía 11 instrucciones: TC, CCS, INDEX, XCH, CS, TS, AD, y MASK(básicas), y SU, MPy DV(extra). Las primeras ocho, llamadas instrucciones básicas , eran accedidas directamente por el código de operación de 3 bits. Las tres últimas se denominaban instrucciones de código extra porque se accedía a ellas ejecutando un tipo especial de TCinstrucción (llamada EXTEND) inmediatamente antes de la instrucción.
Las instrucciones del AGC del Bloque I consistieron en lo siguiente:
TC(control de transferencia)TCinstrucción podía utilizarse para llamadas a subrutinas.CCS(contar, comparar y saltar)CCSes un salto de cuatro vías, dependiendo de los datos en el registro A antes del DABS. Si el registro A era mayor que 0, CCSsalta a la primera instrucción inmediatamente después de CCS. Si el registro A contenía más cero, CCSsalta a la segunda instrucción después de CCS. Menos que cero hace que se salte a la tercera instrucción después de CCS, y menos cero salta a la cuarta instrucción después de CCS. El propósito principal del conteo era permitir que un bucle ordinario, controlado por un contador positivo, terminara en a CCSy TCa al principio del bucle, equivalente a un IBM 360. La BCTfunción de valor absoluto se consideró lo suficientemente importante como para ser incorporada en esta instrucción; cuando se usaba solo para este propósito, la secuencia después de CCSera TC*+2, TC*+2, ADUNO. Un efecto secundario curioso fue la creación y el uso de CCSagujeros cuando se sabía que el valor que se estaba probando nunca era positivo, lo que ocurrió con más frecuencia de lo que uno podría suponer. Eso dejó dos palabras completas desocupadas, y un comité especial fue responsable de asignar constantes de datos a estos agujeros.INDEXINDEXse puede utilizar para sumar o restar un valor de índice a la dirección base especificada por el operando de la instrucción que sigue INDEX. Este método se utiliza para implementar matrices y búsquedas en tablas; dado que la adición se realizó en ambas palabras completas, también se utilizó para modificar el código de operación en una instrucción siguiente (código adicional) y, en raras ocasiones, ambas funciones a la vez.RESUMEINDEX( INDEX25). Esta es la instrucción que se utiliza para regresar de las interrupciones. Hace que la ejecución se reanude en la ubicación interrumpida.XCH(intercambio)TS.CS(limpiar y restar)TS(transferencia a almacenamiento)TSTambién detecta y corrige desbordamientos de tal manera que propaga un acarreo para suma/resta de precisión múltiple. Si el resultado no tiene desbordamiento (los 2 bits más a la izquierda de A son iguales), no sucede nada especial; si hay desbordamiento (esos 2 bits difieren), el más a la izquierda va a la memoria como bit de signo, 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. Siempre que el desbordamiento es un evento posible pero anormal, el TSfue seguido por un TCpara la lógica de no desbordamiento; cuando es una posibilidad normal (como en la suma/resta de precisión múltiple), el TSes seguido por CAFCERO ( CAF= XCHa memoria fija) para completar la formación del acarreo (+1, 0 o −1) en la siguiente palabra de precisión más alta. Los ángulos se mantuvieron en precisión simple , las distancias y velocidades en precisión doble y el tiempo transcurrido en precisión triple.AD(agregar)AD. El hecho de que el desbordamiento sea un estado en lugar de un evento perdona extensiones limitadas de desbordamiento cuando se suman más de dos números, siempre que ninguno de los totales intermedios exceda el doble de la capacidad de una palabra.MASKMP(multiplicar)DV(dividir)SU(sustraer)Las instrucciones se implementaban en grupos de 12 pasos, llamados pulsos de temporización . Los pulsos de temporización se denominaban TP1 a TP12. Cada conjunto de 12 pulsos de temporización se denominaba subsecuencia de instrucción . Las instrucciones simples, como TC, se ejecutaban en una sola subsecuencia de 12 pulsos. Las instrucciones más complejas requerían varias subsecuencias. La instrucción de multiplicación ( MP) utilizaba 8 subsecuencias: una inicial llamada MP0, seguida de una MP1subsecuencia que se repetía 6 veces y, a continuación, terminaba con una MP3subsecuencia. Esto se redujo a 3 subsecuencias en el Bloque II.
Cada pulso de temporización en una subsecuencia podía activar hasta 5 pulsos de control . Los pulsos de control eran las señales que realizaban el trabajo real de la instrucción, como leer el contenido de un registro en el bus o escribir datos del bus en un registro.
La memoria AGC del bloque I se organizó en bancos de 1 kilopalabra. El banco más bajo (banco 0) era de memoria borrable (RAM). Todos los bancos por encima del banco 0 eran de memoria fija (ROM). Cada instrucción AGC tenía un campo de dirección de 12 bits. Los bits inferiores (1-10) direccionaban la memoria dentro de cada banco. Los bits 11 y 12 seleccionaban el banco: 00 seleccionaba el banco de memoria borrable; 01 seleccionaba el banco más bajo (banco 1) de memoria fija; 10 seleccionaba el siguiente (banco 2); y 11 seleccionaba el registro de banco que podía usarse para seleccionar cualquier banco por encima del 2. Los bancos 1 y 2 se llamaban memoria fija-fija , porque siempre estaban disponibles, independientemente del contenido del registro de banco. Los bancos 3 y superiores se llamaban fijos-conmutables porque el banco seleccionado estaba determinado por el registro de banco.
El Bloque I AGC inicialmente tenía 12 kilopalabras de memoria fija, pero luego se amplió a 24 kilopalabras. El Bloque II tenía 36 kilopalabras de memoria fija y 2 kilopalabras de memoria borrable.
El AGC transfirió datos hacia y desde la memoria a través del registro G en un proceso llamado ciclo de memoria . El ciclo de memoria tomó 12 pulsos de temporización (11,72 μs). El ciclo comenzó en el pulso de temporización 1 (TP1) cuando el AGC cargó la dirección de memoria que se buscaría en el registro S. El hardware de memoria recuperó la palabra de datos de la memoria en la dirección especificada por el registro S. Las palabras de la memoria borrable se depositaron en el registro G mediante el pulso de temporización 6 (TP6); las palabras de la memoria fija estuvieron disponibles mediante el pulso de temporización 7. La palabra de memoria recuperada estuvo entonces disponible en el registro G para el acceso del AGC durante los pulsos de temporización 7 a 10. Después del pulso de temporización 10, los datos en el registro G se volvieron a escribir en la memoria.
El ciclo de memoria del AGC se producía de forma continua durante la operación del AGC. Las instrucciones que necesitaban datos de la memoria tenían que acceder a ellos durante los pulsos de temporización 7 a 10. Si el AGC cambiaba la palabra de memoria en el registro G, la palabra modificada se escribía de nuevo en la memoria después del pulso de temporización 10. De esta forma, las palabras de datos circulaban continuamente de la memoria al registro G y luego de nuevo a la memoria.
Los 15 bits inferiores de cada palabra de memoria contenían instrucciones o datos de AGC, y cada palabra estaba protegida por un decimosexto bit de paridad impar. Este bit se establecía en 1 o 0 mediante un circuito generador de paridad, de modo que un recuento de los 1 en cada palabra de memoria siempre produciría un número impar. Un circuito de verificación de paridad probaba el bit de paridad durante cada ciclo de memoria; si el bit no coincidía con el valor esperado, se asumía que la palabra de memoria estaba dañada y se encendía una luz de alarma de paridad en el panel.
El AGC tenía cinco interrupciones vectoriales :
El AGC respondió a cada interrupción suspendiendo temporalmente el programa actual, ejecutando una breve rutina de servicio de interrupción y luego reanudando el programa interrumpido.
El AGC también tenía 20 contadores involuntarios . Se trataba de posiciones de memoria que funcionaban como contadores ascendentes o descendentes, o registros de desplazamiento. Los contadores se incrementaban, decrementaban o desplazaban en respuesta a las entradas internas. El incremento ( Pinc ), decremento ( Minc ) o desplazamiento ( Shinc ) se gestionaba mediante una subsecuencia de microinstrucciones insertadas entre dos instrucciones regulares cualesquiera.
Las interrupciones se podían activar cuando los contadores se desbordaban. Las interrupciones T3rupt y Dsrupt se producían cuando sus contadores, controlados por un reloj de hardware de 100 Hz, se desbordaban después de ejecutar muchas subsecuencias Pinc. La interrupción Uprupt se activaba después de que su contador, al ejecutar la subsecuencia Shinc, hubiera desplazado 16 bits de datos de enlace ascendente al AGC.
El AGC tenía un modo de ahorro de energía controlado por un interruptor de modo de espera permitido . Este modo apagaba la alimentación del AGC, excepto el reloj de 2,048 MHz y el escalador. La señal F17 del escalador encendía la alimentación del AGC y lo encendía nuevamente en intervalos de 1,28 segundos. En este modo, el AGC realizaba funciones esenciales, verificaba el interruptor de modo de espera permitido y, si aún estaba habilitado, apagaba la alimentación y volvía a dormir hasta la siguiente señal F17.
En el modo de espera, el AGC dormía la mayor parte del tiempo; por lo tanto, no estaba activo para ejecutar la instrucción Pinc necesaria para actualizar el reloj de tiempo real del AGC a intervalos de 10 ms. Para compensar, una de las funciones que realizaba el AGC cada vez que se activaba en el modo de espera era actualizar el reloj de tiempo real en 1,28 segundos.
El modo de espera fue diseñado para reducir la potencia entre 5 y 10 W (de 70 W) durante el vuelo a mitad de camino, cuando no se necesitaba el AGC. Sin embargo, en la práctica, el AGC se dejó encendido durante todas las fases de la misión y esta función nunca se utilizó.
El AGC tenía un bus de lectura de 16 bits y un bus de escritura de 16 bits. Los datos de los registros centrales (A, Q, Z o LP) u otros registros internos podían enviarse al bus de lectura con una señal de control. El bus de lectura se conectaba al bus de escritura a través de un búfer no inversor, por lo que cualquier dato que apareciera en el bus de lectura también aparecía en el bus de escritura. Otras señales de control podían copiar los datos del bus de escritura de nuevo a los registros.
Las transferencias de datos funcionaban de la siguiente manera: para mover la dirección de la siguiente instrucción del registro B al registro S, se emitía una señal de control RB (lectura B); esto hacía que la dirección se moviera del registro B al bus de lectura y luego al bus de escritura. Una señal de control WS (escritura S) movía la dirección del bus de escritura al registro S.
Se podían leer varios registros en el bus de lectura simultáneamente. Cuando esto ocurría, los datos de cada registro se introducían en el bus mediante la operación OR inclusiva. Esta función OR inclusiva se utilizaba para implementar la instrucción Mask, que era una operación AND lógica . Como el AGC no tenía la capacidad nativa de realizar una operación AND lógica , pero podía realizar una OR lógica a través del bus y podía complementar (invertir) datos a través del registro C, se utilizó el teorema de De Morgan para implementar el equivalente de una AND lógica . Esto se logró invirtiendo ambos operandos, realizando una OR lógica a través del bus y luego invirtiendo el resultado.
El software AGC se escribió en lenguaje ensamblador AGC y se almacenó en la memoria de la cuerda . La mayor parte del software estaba en la memoria de la cuerda de solo lectura y, por lo tanto, no se podía cambiar durante el funcionamiento, [20] pero algunas partes clave del software se almacenaron en la memoria de núcleo magnético de lectura y escritura estándar y los astronautas podían sobrescribirlas utilizando la interfaz DSKY, como se hizo en el Apolo 14 .
Un sistema operativo simple en tiempo real diseñado por J. Halcombe Laning [21] que consistía en el 'Exec', un programador de trabajos por lotes que utilizaba multitarea cooperativa , [22] y un programador preventivo controlado por interrupciones llamado 'Waitlist' que programaba 'tareas' controladas por temporizadores, controlaba la computadora. Las tareas eran hilos cortos de ejecución que podían reprogramarse para volver a ejecutarse en la lista de espera, o podían iniciar una operación más larga iniciando un 'trabajo' con el Exec. Los cálculos se realizaban utilizando el sistema métrico , pero las lecturas en pantalla estaban en unidades de pies, pies por segundo y millas náuticas, unidades a las que estaban acostumbrados los astronautas del Apolo. [23]
El AGC tenía un sofisticado intérprete de software, desarrollado por el Laboratorio de Instrumentación del MIT , que implementaba una máquina virtual con pseudoinstrucciones más complejas y capaces que el AGC nativo. Estas instrucciones simplificaban los programas de navegación. El código interpretado, que presentaba trigonometría de doble precisión , aritmética escalar y vectorial (16 y 24 bits), incluso una MXVinstrucción (matriz × vector), podía mezclarse con el código AGC nativo. Si bien el tiempo de ejecución de las pseudoinstrucciones se incrementó (debido a la necesidad de interpretar estas instrucciones en tiempo de ejecución), el intérprete proporcionó muchas más instrucciones de las que AGC admitía de forma nativa y los requisitos de memoria eran mucho menores que en el caso de agregar estas instrucciones al lenguaje nativo de AGC, lo que requeriría memoria adicional incorporada en la computadora (en la década de 1960 , la memoria era muy cara). La pseudoinstrucción promedio requería alrededor de 24 ms para ejecutarse. El ensamblador, llamado YUL por un prototipo temprano de Christmas Computer , [24] impuso transiciones adecuadas entre el código nativo y el interpretado.
Un conjunto de rutinas de interfaz de usuario controladas por interrupciones, llamadas "Pinball", proporcionaban servicios de teclado y pantalla para los trabajos y tareas que se ejecutaban en el AGC. Se proporcionaba un conjunto de rutinas accesibles para el usuario que permitían a los astronautas visualizar el contenido de varias ubicaciones de memoria en octal o decimal en grupos de 1, 2 o 3 registros a la vez. Se proporcionaban rutinas de "monitorización" para que el operador pudiera iniciar una tarea para volver a mostrar periódicamente el contenido de ciertas ubicaciones de memoria. Se podían iniciar trabajos.
Los principios de diseño desarrollados para el AGC por el Laboratorio de Instrumentación del MIT , dirigido a fines de la década de 1960 por Charles Draper , se convirtieron en fundamentales para la ingeniería de software , en particular para el diseño de sistemas más confiables que dependían de software asincrónico, programación de prioridades, pruebas y capacidad de decisión humana en el circuito . [25] Cuando se definieron los requisitos de diseño para el AGC, no existían el software y las técnicas de programación necesarios, por lo que tuvieron que diseñarse desde cero. Muchos de los algoritmos de trayectoria y guía utilizados se basaron en trabajos anteriores de Richard Battin . [21] El primer vuelo del módulo de comando fue controlado por un paquete de software llamado CORONA cuyo desarrollo fue dirigido por Alex Kosmala. El software para misiones lunares consistió en COLOSSUS para el módulo de comando, cuyo desarrollo fue dirigido por Frederic Martin, y LUMINARY [26] en el módulo lunar dirigido por George Cherry. Los detalles de estos programas fueron implementados por un equipo bajo la dirección de Margaret Hamilton . [27] Hamilton estaba muy interesado en cómo interactuarían los astronautas con el software y predijo los tipos de errores que podrían ocurrir debido a un error humano. [22] [27] En total, el desarrollo del software en el proyecto comprendió 1400 años-persona de esfuerzo, con una fuerza laboral máxima de 350 personas. [21] En 2016, Hamilton recibió la Medalla Presidencial de la Libertad por su papel en la creación del software de vuelo.
El software de la computadora de guía Apollo influyó en el diseño del Skylab , el transbordador espacial y los primeros sistemas de aviones de combate con control de vuelo por cable. [28] [29]
La computadora de guía Apolo ha sido llamada "El cuarto astronauta" por su papel en ayudar a los tres astronautas que confiaron en ella: Neil Armstrong , Buzz Aldrin y Michael Collins . [30]
En 1966 se diseñó una versión del Bloque II del AGC. Mantuvo la arquitectura básica del Bloque I, pero aumentó la memoria borrable de 1 a 2 kilopalabras. La memoria fija se amplió de 24 a 36 kilopalabras. Las instrucciones se ampliaron de 11 a 34 y se implementaron canales de E/S para reemplazar los registros de E/S del Bloque I. La versión del Bloque II es la que realmente voló a la Luna. El Bloque I se utilizó durante los vuelos no tripulados del Apolo 4 y 6 , y estuvo a bordo del desafortunado Apolo 1 .
La decisión de ampliar la memoria y el conjunto de instrucciones para el Bloque II, pero manteniendo el restrictivo código de operación de tres bits y la dirección de 12 bits del Bloque I tuvo interesantes consecuencias de diseño. Se emplearon varios trucos para incluir instrucciones adicionales, como tener direcciones de memoria especiales que, cuando se hiciera referencia a ellas, implementarían una determinada función. Por ejemplo, una INDEXdirección a 25 activaba la RESUMEinstrucción para regresar de una interrupción. Del mismo modo, INDEX17 realizaba una INHINTinstrucción (inhibir interrupciones), mientras que INDEX16 las rehabilitaba ( RELINT). Otras instrucciones se implementaron precediéndolas con una versión especial de TCllamada EXTEND. Los espacios de direcciones se ampliaron empleando los registros Bank (fijo) y Ebank (borrable), de modo que la única memoria de cada tipo que podía direccionarse en un momento dado era el banco actual, más la pequeña cantidad de memoria fija-fija y la memoria borrable. Además, el registro bank podía direccionar un máximo de 32 kilopalabras, de modo que se requería un registro Sbank (superbanco) para acceder a las últimas 4 kilopalabras. Todas las llamadas a subrutinas entre bancos debían iniciarse desde una memoria fija a través de funciones especiales para restaurar el banco original durante el retorno: esencialmente un sistema de punteros lejanos .
El AGC del Bloque II también tiene la EDRUPTinstrucción (el nombre es una contracción de Ed's Interrupt , en honor a Ed Smally, el programador que la solicitó). Esta instrucción no genera una interrupción, sino que realiza dos acciones que son comunes al procesamiento de interrupciones. La primera acción, inhibe futuras interrupciones (y requiere una RESUMEinstrucción para habilitarlas nuevamente). En la segunda acción, el ZRUPTregistro se carga con el valor actual del contador de programa (Z). Solo se usó una vez en el software Apollo, para configurar la secuencia de terminación del ciclo DAP en el piloto automático digital del módulo lunar . [31] Se cree que es responsable de los problemas para emular el software LEM AGC Luminary.
.jpg/1280px-AS11-36-5391_(21710608621).jpg)
El PGNCS generó advertencias imprevistas durante el descenso lunar del Apolo 11 , con el AGC mostrando una alarma 1202 ("Desbordamiento ejecutivo - NO HAY CONJUNTOS BÁSICOS"), [32] y luego una alarma 1201 ("Desbordamiento ejecutivo - NO HAY ÁREAS DE VACÍO"). [33] [ cita requerida ] La respuesta del AGC a cualquiera de las alarmas fue un reinicio suave. La causa fue un flujo rápido y constante de robos de ciclos espurios del radar de encuentro (que rastreaba el módulo de comando en órbita), dejado intencionalmente en espera durante el descenso en caso de que fuera necesario para un aborto. [34] [35]
Durante esta parte de la aproximación, el procesador normalmente estaría cargado casi al 85%. Los 6.400 ciclos adicionales por segundo añadieron el equivalente al 13% de carga, dejando justo el tiempo suficiente para que todas las tareas programadas se ejecutaran hasta su finalización. A los cinco minutos de descenso, Buzz Aldrin dio a la computadora el comando 1668 , que le indicaba que calculara y mostrara periódicamente DELTAH (la diferencia entre la altitud detectada por el radar y la altitud calculada). [nb 1] El 1668 añadió otro 10% a la carga de trabajo del procesador, lo que provocó un desbordamiento ejecutivo y una alarma 1202. Después de recibir el "GO" de Houston, Aldrin volvió a introducir el 1668 y se produjo otra alarma 1202. Al informar de la segunda alarma, Aldrin añadió el comentario "Parece que aparece cuando tenemos un 1668 en ascenso". El software AGC había sido diseñado con programación de prioridades y se recuperaba automáticamente, eliminando las tareas de menor prioridad, incluida la tarea de visualización 1668 , para completar sus tareas críticas de guía y control. El controlador de guía Steve Bales y su equipo de apoyo, que incluía a Jack Garman, emitieron varias llamadas de "GO" y el aterrizaje fue exitoso. [36]
El problema no era un error de programación en el AGC, ni tampoco un error del piloto. Era un error de diseño de hardware periférico que ya había sido conocido y documentado por los ingenieros del Apolo 5. [37] Sin embargo, debido a que el problema sólo había ocurrido una vez durante las pruebas, concluyeron que era más seguro volar con el hardware existente que ya habían probado, que volar con un sistema de radar más nuevo pero en gran parte no probado. En el hardware real, la posición del radar de encuentro estaba codificada con sincros excitados por una fuente diferente de 800 Hz CA que la utilizada por la computadora como referencia de tiempo. Las dos fuentes de 800 Hz estaban sincronizadas en frecuencia pero no en fase, y las pequeñas variaciones aleatorias de fase hicieron que pareciera como si la antena estuviera "oscilando" rápidamente en posición, a pesar de que estaba completamente estacionaria. Estos movimientos fantasmas generaron la rápida serie de robos de ciclo.
El software y el diseño informático de J. Halcombe Laning salvaron la misión de aterrizaje del Apolo 11. De no haber sido por el diseño de Laning, el aterrizaje se habría abortado por falta de un ordenador de guía estable. [37] [38]
El AGC formó la base de un sistema experimental fly-by-wire (FBW) instalado en un F-8 Crusader para demostrar la viabilidad del FBW controlado por computadora. El AGC utilizado en la primera fase del programa fue reemplazado por otra máquina en la segunda fase, y la investigación realizada en el programa condujo al desarrollo de sistemas fly-by-wire para el transbordador espacial . El AGC también condujo, aunque indirectamente, al desarrollo de sistemas fly-by-wire para la generación de cazas que se estaban desarrollando en ese momento. [39]
En 2003, Ron Burkey inició el Proyecto AGC Virtual, con el objetivo de recuperar el código fuente del Apollo Guidance Computer (AGC) y construir un emulador funcional. [40] [41] Como parte de este proyecto, el código original, transcrito y digitalizado a partir de copias impresas de la década de 1960, [42] se puso a disposición a través del Proyecto AGC Virtual y el Museo del MIT . [43] Este esfuerzo ganó renovada atención a mediados de 2016 cuando el ex pasante de la NASA Chris Garry subió el código a GitHub, generando un importante revuelo mediático. [44] [45] [46]
Historias destacadas