La Computadora de Orientación Apollo ( AGC ) era una computadora digital producida para el programa Apollo que se instalaba 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 . El rendimiento de la computadora era comparable al de la primera generación de computadoras domésticas de finales de la década de 1970, como la Apple II , la TRS-80 y la 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 sólo lectura conocida como memoria central de cuerda , formada entretejiendo cables a través y alrededor de núcleos magnéticos , aunque hay disponible una pequeña cantidad de memoria central de lectura/escritura.
Los astronautas se comunicaban con el AGC mediante una pantalla numérica y un teclado llamado DSKY (para "pantalla y teclado", pronunciado "DIS-kee"). El AGC y su interfaz de usuario DSKY fueron desarrollados a principios de la década de 1960 para el programa Apollo 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 alunizajes. [6] Cada vuelo a la Luna llevaba dos AGC, uno en el módulo de comando y uno en 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 ejecutó su Apollo PGNCS (sistema primario de guía, navegación y control), con el acrónimo pronunciado como pings .
Cada misión lunar contaba con 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 arquitectónicos provinieron 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 era de esperar. [11] Los dibujos del módulo lógico informático Apollo Guidance especifican la soldadura por resistencia. [12] [13]
Tras el uso de chips de circuito integrado (IC) en la Plataforma de Monitoreo Interplanetario (IMP) en 1963, la tecnología IC se adoptó posteriormente para el AGC. [14] La computadora de vuelo Apollo fue la primera computadora en utilizar chips IC de silicio . [15]
Mientras que la versión del Bloque I usó 4100 IC, cada uno de los cuales contenía una única puerta NOR de tres entradas , la versión posterior del Bloque II (utilizada en los vuelos tripulados) usó alrededor de 2800 IC, en su mayoría puertas NOR duales de tres entradas y números más pequeños de expansores y detectores. amplificadores. [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 una envoltura de alambre y luego el cableado se incrustó en plástico epoxi fundido . [16] : 129
El uso de un solo tipo de IC (el NOR3 dual) en todo el AGC evitó los problemas que plagaron otro diseño temprano de computadora IC, la computadora de guía Minuteman II , que usaba una combinación de lógica de diodo-transistor y puertas lógicas de diodo . [ cita necesaria ] Las puertas NOR son puertas lógicas universales a partir de las cuales se puede crear cualquier otra puerta, aunque a costa de utilizar más puertas. [17]
La computadora tenía 2.048 palabras de memoria de núcleo magnético borrable y 36.864 palabras de memoria de núcleo de cuerda de solo lectura . [16] : 27, 90–93 Ambos tenían tiempos de ciclo de 11,72 microsegundos. [16] : 27 La longitud de la palabra de memoria era de 16 bits: 15 bits de datos y un bit de paridad impar . El formato de palabra interno de 16 bits de la CPU era de 14 bits de datos, un bit de desbordamiento y un bit de signo ( representación en complemento de unos ). [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 generalmente 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 . Verb describió el tipo de acción a realizar y Noun especificó qué datos se vieron afectados por la acción especificada por el comando Verb.
Cada dígito se mostraba a través de una pantalla electroluminiscente de siete segmentos verde (especificada como 530 nm [18] ) ; estos eran impulsados 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 normalmente 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 estilo calculadora fue la primera de su tipo.
El módulo de comando tiene dos DSKY conectados a su AGC: uno ubicado en el panel de instrumentos principal y un segundo ubicado en el compartimento inferior del equipo cerca de un sextante utilizado para alinear la plataforma de guía inercial . El módulo lunar tenía un único DSKY para su AGC. Un indicador de actitud del director de vuelo (FDAI), controlado por el AGC, estaba ubicado encima del DSKY en la consola del comandante y en el LM.
La referencia de temporización del AGC provino 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 denominada frecuencia maestra ; Esta señal se utilizó para sincronizar los sistemas externos de la nave espacial Apollo.
La frecuencia maestra se dividió aún más mediante un escalador , primero en cinco usando un contador de anillo para producir una señal de 102,4 kHz. Luego se dividió en dos a 17 etapas sucesivas llamadas F1 (51,2 kHz) a F17 (0,78125 Hz). La etapa F10 (100 Hz) se retroalimentó al AGC para incrementar el reloj en tiempo real y otros contadores involuntarios usando Pinc (que se analiza a continuación). La etapa F17 se usó para ejecutar intermitentemente 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 del remitente después de TClas instrucciones.MPlas instrucciones.También había cuatro ubicaciones en la memoria central, en las direcciones 20 a 23, denominadas ubicaciones de edición porque todo lo que estuviera almacenado allí emergería desplazado o rotado en una posición de un bit, excepto uno que se desplazaba siete posiciones de bit hacia la derecha, para extraer una de las siete posiciones. poco interpretativo op. códigos que estaban empaquetados de dos en 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 durante 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 tenía 11 instrucciones: TC, CCS, INDEX, XCH, CS, TS, ADy MASK(básico), y SU, MPy DV(extra). A las primeras ocho, llamadas instrucciones básicas , se accedía directamente mediante el operador de 3 bits. código. Las tres últimas se denominaron instrucciones extracódigo porque se accedía a ellas realizando 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 podría usarse para llamadas a subrutinas.CCS(contar, comparar y omitir)CCSes un salto de cuatro vías, dependiendo de los datos del registro A antes del DABS. Si el registro A era mayor que 0, CCSsalta a la primera instrucción inmediatamente después CCS. Si el registro A contiene más cero, CCSsalta a la segunda instrucción después de CCS. Menos de cero provoca un salto a la tercera instrucción posterior CCS, y menos cero salta a la cuarta instrucción posterior CCS. El propósito principal del conteo era permitir que un bucle ordinario, controlado por un contador positivo, terminara en a CCSy a TChasta el comienzo del bucle, equivalente a un IBM 360 BCT. La función de valor absoluto se consideró lo suficientemente importante como para incluirla 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 ocurría con más frecuencia de lo que cabría suponer. Eso dejó dos palabras enteras 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 siguiente INDEX. Este método se utiliza para implementar matrices y búsquedas de tablas; dado que la suma se realizó en ambas palabras completas, también se usó para modificar la op. código en una siguiente instrucción (extracódigo) y, en raras ocasiones, ambas funciones a la vez.RESUMEINDEX( INDEX25). Esta es la instrucción utilizada para regresar de una interrupción. Hace que la ejecución se reanude en el lugar interrumpido.XCH(intercambio)TS.CS(borrar y restar)TS(transferir al almacenamiento)TStambién detecta y corrige desbordamientos de tal manera que se propague un acarreo para sumar/restar con precisión múltiple. Si el resultado no tiene desbordamiento (los 2 bits de A más a la izquierda 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 en consecuencia, y el control salta a la segunda instrucción después de TS. Siempre que el desbordamiento es un evento posible pero anormal, TSfue seguido por una TClógica de no desbordamiento; cuando es una posibilidad normal (como en la suma/resta de precisión múltiple), va TSseguido de CAFCERO ( CAF= XCHa memoria fija) para completar la formación del acarreo (+1, 0 o −1) al siguiente nivel superior. palabra de precisión. 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 y no un evento perdona extensiones limitadas de desbordamiento al sumar 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 implementaron en grupos de 12 pasos, llamados pulsos de sincronización . Los pulsos de sincronización se denominaron TP1 a TP12. Cada conjunto de 12 pulsos de sincronización se denominó subsecuencia de instrucciones . Instrucciones simples, como TC, ejecutadas en una única subsecuencia de 12 pulsos. Las instrucciones más complejas requerían varias subsecuencias. La instrucción de multiplicar ( MP) utilizó 8 subsecuencias: una inicial llamada MP0, seguida de una MP1subsecuencia que se repitió 6 veces y luego terminó con una MP3subsecuencia. Esto se redujo a 3 subsecuencias en el Bloque II.
Cada pulso de sincronización en una subsecuencia podrí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 la memoria borrable (RAM). Todos los bancos por encima del banco 0 eran memoria fija (ROM). Cada instrucción AGC tenía un campo de dirección de 12 bits. Los bits inferiores (1-10) se dirigen a la memoria dentro de cada banco. Los bits 11 y 12 seleccionaron el banco: 00 seleccionaron el banco de memoria borrable; 01 seleccionó el banco más bajo (banco 1) de memoria fija; 10 seleccionaron el siguiente (banco 2); y 11 seleccionaron el registro del Banco que podría usarse para seleccionar cualquier banco por encima del 2. Los bancos 1 y 2 se denominaron memoria fija-fija porque siempre estaban disponibles, independientemente del contenido del registro del Banco. Los bancos 3 y superiores se denominaron fijos conmutables porque el banco seleccionado estaba determinado por el registro bancario.
El AGC del Bloque I tenía inicialmente 12 kilopalabras de memoria fija, pero luego se aumentó 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 tiempo (11,72 μs). El ciclo comenzó en el pulso de sincronización 1 (TP1) cuando el AGC cargó la dirección de memoria para ser recuperada en el registro S. El hardware de la 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 sincronizando el pulso 6 (TP6); Las palabras de la memoria fija estaban disponibles al cronometrar el pulso 7. La palabra de memoria recuperada estaba entonces disponible en el registro G para acceso AGC durante los pulsos de temporización 7 a 10. Después de cronometrar el pulso 10, los datos en el registro G se escribían nuevamente en la memoria.
El ciclo de memoria del AGC se produjo continuamente durante el funcionamiento del AGC. Las instrucciones que necesitaban datos de la memoria tenían que acceder a ellos durante los pulsos de sincronización 7 a 10. Si el AGC cambiaba la palabra de memoria en el registro G, la palabra cambiada se escribía nuevamente en la memoria después del pulso de tiempo 10. De esta manera, las palabras de datos circulaban continuamente desde la memoria al registro G y luego regresaban nuevamente 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 estableció en 1 o 0 mediante un circuito generador de paridad, por lo que un recuento de los unos en cada palabra de memoria siempre produciría un número impar. Un circuito de verificación de paridad probó el bit de paridad durante cada ciclo de memoria; si el bit no coincidía con el valor esperado, se suponía que la palabra de memoria estaba corrupta y se encendía una luz del panel de alarma de paridad .
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.
La AGC también tuvo 20 contadores involuntarios . Eran ubicaciones de memoria que funcionaban como contadores ascendentes y descendentes o registros de desplazamiento. Los contadores aumentarían, disminuirían o cambiarían en respuesta a entradas internas. El incremento ( Pinc ), el decremento ( Minc ) o el desplazamiento ( Shinc ) fueron manejados por una subsecuencia de microinstrucciones insertadas entre dos instrucciones regulares cualesquiera.
Se podrían activar interrupciones cuando los contadores se desbordaran. Las interrupciones T3rupt y Dsrupt se produjeron cuando sus contadores, controlados por un reloj de hardware de 100 Hz, se desbordaron después de ejecutar muchas subsecuencias Pinc. La interrupción Uprupt se activó después de que su contador, ejecutando la subsecuencia Shinc, había 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 permitido en espera . Este modo apagó la alimentación del AGC, excepto el reloj de 2.048 MHz y el escalador. La señal F17 del escalador encendió el AGC y el AGC volvió a encenderse en intervalos de 1,28 segundos. En este modo, el AGC realizó funciones esenciales, verificó el interruptor de espera permitido y, si aún estaba habilitado, apagó la alimentación y volvió a dormir hasta la siguiente señal F17.
En modo de espera, el AGC estuvo inactivo la mayor parte del tiempo; por lo tanto, no estaba despierto para realizar 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 despertaba en 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 de 5 a 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 característica 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 podrían conectarse 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 podrían copiar y escribir datos del bus nuevamente en los registros.
Las transferencias de datos funcionaron así: para mover la dirección de la siguiente instrucción del registro B al registro S, se emitió una señal de control RB (leer B); esto provocó 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) movió la dirección del bus de escritura al registro S.
Se podrían leer varios registros simultáneamente en el bus de lectura. Cuando esto ocurría, los datos de cada registro se incluían O se cargaban en el autobús. Esta característica OR inclusiva se utilizó para implementar la instrucción Máscara, que era una operación lógica AND . Debido a que el AGC no tenía capacidad nativa para hacer un AND lógico, pero podía hacer un OR lógico 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 un AND lógico . Esto se logró invirtiendo ambos operandos, realizando un OR lógico a través del bus y luego invirtiendo el resultado.
El software AGC fue escrito en lenguaje ensamblador AGC y almacenado 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 la operación, [20] pero algunas partes clave del software se almacenaban en una memoria de núcleo magnético de lectura y escritura estándar y los astronautas podían sobrescribirlas usando 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 consta de 'Exec', un sistema de programación de trabajos por lotes que utiliza multitarea cooperativa , [22] y un programador preventivo impulsado por interrupciones llamado 'Lista de espera'. ' que programaba 'tareas' controladas por temporizador y controlaba la computadora. Las tareas eran subprocesos cortos de ejecución que podían reprogramarse para su reejecución en la lista de espera, o podían iniciar una operación más larga iniciando un "trabajo" con el ejecutivo. Los cálculos se realizaron utilizando el sistema métrico , pero las lecturas en la pantalla estaban en unidades de pies, pies por segundo y millas náuticas, unidades a las que los astronautas del Apolo estaban acostumbrados. [23]
El AGC contaba con un sofisticado intérprete de software, desarrollado por el MIT Instrumentation Laboratory , que implementaba una máquina virtual con pseudoinstrucciones más complejas y capaces que el AGC nativo. Estas instrucciones simplificaron los programas de navegación. El código interpretado, que presentaba aritmética trigonométrica , escalar y vectorial de doble precisión (16 y 24 bits), incluso una MXVinstrucción (matriz × vector), se podía mezclar con código AGC nativo. Si bien el tiempo de ejecución de las pseudoinstrucciones aumentó (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 fueron mucho menores que en el caso de agregar estas instrucciones al Lenguaje nativo AGC que requeriría memoria adicional integrada en la computadora (en ese momento la capacidad de memoria era muy costosa). La pseudoinstrucción promedio requirió alrededor de 24 ms para ejecutarse. El ensamblador, llamado YUL en honor a uno de los primeros prototipos de Christmas Computer , [24] imponía transiciones adecuadas entre el código nativo y el interpretado.
Un conjunto de rutinas de interfaz de usuario controladas por interrupciones llamado 'Pinball' proporcionaba servicios de teclado y visualización para los trabajos y tareas que se ejecutaban en el AGC. Se proporcionó un conjunto de rutinas accesibles para el usuario para permitir a los astronautas mostrar el contenido de varias ubicaciones de memoria en octal o decimal en grupos de 1, 2 o 3 registros a la vez. Se proporcionaron rutinas de 'monitoreo' para que el operador pudiera iniciar una tarea para volver a mostrar periódicamente el contenido de ciertas ubicaciones de memoria. Se podrían iniciar trabajos.
Los principios de diseño desarrollados para el AGC por el MIT Instrumentation Laboratory , dirigido a finales de la década de 1960 por Charles Draper , se convirtieron en fundamentales para la ingeniería de software , particularmente para el diseño de sistemas más confiables que dependían de software asincrónico, programación de prioridades, pruebas y participación humana. capacidad de decisión en el bucle . [25] Cuando se definieron los requisitos de diseño para el AGC, el software y las técnicas de programación necesarios no existían, 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 consistía 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 errores humanos. [22] [27] En total, el desarrollo de 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 Apollo Guidance Computer influyó en el diseño del Skylab , el transbordador espacial y los primeros sistemas de aviones de combate de vuelo por cable. [28] [29]
La computadora Apollo Guidance ha sido llamada "El cuarto astronauta" por su papel de ayudar a los tres astronautas que confiaban en ella: Neil Armstrong , Buzz Aldrin y Michael Collins . [30]
En 1966 se diseñó una versión del Bloque II del AGC. Conservó 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 en el 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 estaba a bordo del desafortunado Apolo 1 .
La decisión de ampliar la memoria y el conjunto de instrucciones para el Bloque II, pero conservar la restrictiva operación de tres bits del Bloque I. El código y la dirección de 12 bits tuvieron interesantes consecuencias de diseño. Se emplearon varios trucos para incluir instrucciones adicionales, como tener direcciones de memoria especiales que, al ser referenciadas, implementarían una determinada función. Por ejemplo, una INDEXdirección a 25 activó la RESUMEinstrucción para regresar de una interrupción. Asimismo, INDEX17 realizaron alguna INHINTinstrucción (inhibir interrupciones), mientras que INDEX16 las rehabilitaron ( RELINT). Otras instrucciones se implementaron precediéndolas con una versión especial de TCcall EXTEND. Los espacios de direcciones se ampliaron empleando los registros Bank (fijo) y Ebank (borrable), de modo que la única memoria de cualquier tipo que pudiera direccionarse en un momento dado era el banco actual, más la pequeña cantidad de memoria fija-fija y el memoria borrable. Además, el registro bancario podía gestionar un máximo de 32 kilopalabras, por lo que se necesitaba 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 regreso: 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 para interrumpir el procesamiento. La primera acción inhibe más interrupciones (y requiere una RESUMEinstrucción para habilitarlas nuevamente). En la segunda acción, el ZRUPTregistro se carga con el valor actual del contador del 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 al emular el software LEM AGC Luminary.
.jpg/1280px-AS11-36-5391_(21710608621).jpg)
PGNCS generó advertencias imprevistas durante el descenso lunar del Apolo 11 , y el AGC mostró una alarma 1202 ("Desbordamiento ejecutivo - SIN CONJUNTOS DE NÚCLEOS"), [32] y luego una alarma 1201 ("Desbordamiento ejecutivo - NO HAY ÁREAS DE VAC"). [33] [ cita necesaria ] 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 falsos del radar de encuentro (que rastrea 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 del proceso, el procesador normalmente estaría cargado en casi un 85%. Los 6400 robos de ciclo adicionales por segundo agregaron el equivalente a un 13 % de carga, dejando el tiempo suficiente para que todas las tareas programadas se ejecutaran hasta su finalización. Cinco minutos después del descenso, Buzz Aldrin le 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 agregó 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 ingresó nuevamente a 1668 y se produjo otra alarma de 1202 . Al informar de la segunda alarma, Aldrin añadió el comentario "Parece aparecer cuando tenemos un 1668 activo". El software AGC se diseñó con programación prioritaria y se recuperó automáticamente, eliminando 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 soporte, que incluía a Jack Garman , emitieron varias llamadas "GO" y el aterrizaje fue exitoso. Por su papel, Bales recibió la Medalla Presidencial de la Libertad de Estados Unidos en nombre de todo el equipo del centro de control y de los tres astronautas del Apolo. [36]
El problema no fue un error de programación en el AGC, ni tampoco un error del piloto. Se trataba de un error de diseño de hardware periférico que ya había sido conocido y documentado por los ingenieros del Apollo 5. [37] Sin embargo, debido a que el problema solo 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 medida no probado. En el hardware real, la posición del radar de encuentro estaba codificada con sincronizadores excitados por una fuente de 800 Hz CA diferente a la utilizada por la computadora como referencia de tiempo. Las dos fuentes de 800 Hz estaban bloqueadas en frecuencia pero no en fase, y las pequeñas variaciones aleatorias de fase hacían que pareciera que la antena estaba "oscilando" rápidamente en su 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 de la computadora de J. Halcombe Laning salvaron la misión de aterrizaje del Apolo 11. Si no hubiera sido por el diseño de Laning, el aterrizaje habría sido abortado por falta de una computadora de guía estable. [37] [38]
El AGC formó la base de un sistema experimental de vuelo por cable (FBW) instalado en un F-8 Crusader para demostrar la practicidad 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 de vuelo por cable para el transbordador espacial . El AGC también condujo, aunque indirectamente, al desarrollo de sistemas de vuelo por cable para la generación de cazas que se estaban desarrollando en ese momento. [39]
En 2003, Ron Burkey inició un esfuerzo para recuperar el código fuente que impulsaba el AGC y construir un emulador capaz de ejecutarlo, el VirtualAGC. [40] [41] Parte de la gran cantidad de código fuente rescatado como resultado de este esfuerzo fue subido por un ex pasante de la NASA a GitHub el 7 de julio de 2016, atrayendo una importante atención de los medios. [42] [43] El código fuente original del Apollo 11 Guidance Computer fue hecho accesible originalmente en 2003 [44] por el Proyecto Virtual AGC y el Museo del MIT . [45] Fue transcrito y digitalizado a partir de las listas originales de códigos fuente impresos que se hicieron en los años 60. A mediados de 2016, el ex pasante de la NASA Chris Garry subió el código fuente de AGC a GitHub . [46] [47]
Reportajes