A Lua Não Foi Conquistada Só com Foguetes.
Quando software pilotava uma nave
Hoje reclamamos quando um container cai em produção.
Em 1969, um bug podia matar três pessoas a 300 mil quilômetros da Terra.
Pouco antes do pouso da Apollo 11 na Lua, o computador de bordo começou a emitir alarmes inesperados: 1201 e 1202.
Nenhuma interface bonita. Nenhum log detalhado. Apenas números.
Ainda assim, o sistema continuou rodando. Priorizou tarefas críticas, descartou processos secundários e manteve o controle da nave.
Esse comportamento não foi sorte. Foi engenharia de software em estado puro.
O código que fez isso acontecer foi escrito nos anos 60, rodava em um computador com aproximadamente 2 KB de RAM e 36 KB de memória fixa, e hoje pode ser estudado publicamente.
Não como lenda, mas como código real, linha por linha.
Neste artigo, vamos olhar para esse software não como peça de museu, mas como aquilo que ele realmente é: um dos sistemas mais bem projetados já escritos.
O Apollo Guidance Computer: limites absurdos, responsabilidade total
O Apollo Guidance Computer (AGC) não foi projetado para ser rápido, bonito ou flexível.
Ele foi projetado para não errar.
Fisicamente, ele ocupava algo próximo de uma caixa de sapatos.
Logicamente, era ainda menor:
~2 KB de RAM (memória volátil)
~36 KB de memória fixa (core rope memory)
Clock em torno de 1 MHz
Nenhum sistema operacional no sentido moderno
Tudo ali era conhecido, medido e previsto.
Não existia “tratamento genérico de erro”.
Cada falha possível tinha que ser imaginada antes, porque, depois do lançamento, não havia patch, rollback ou hotfix.
Core Rope Memory: código literalmente tecido
Um detalhe que parece ficção científica, mas é pura engenharia:
O código do AGC não era apenas gravado.
Ele era tecido fisicamente em fios de cobre.
Cada bit era definido pelo caminho do fio através de núcleos magnéticos:
fio passando pelo núcleo → bit 1
fio contornando o núcleo → bit 0
Isso tornava a memória:
extremamente confiável,
imune à radiação,
impossível de alterar depois de pronta.
Em outras palavras: commit definitivo em hardware.
Esse detalhe muda completamente a forma como o software era escrito.
Não havia espaço para improviso. O código precisava ser correto na primeira vez.
O código que saiu da Terra
O AGC rodava um software escrito majoritariamente em Assembly AGC, uma linguagem criada especificamente para aquele hardware.
Nada de abstrações confortáveis.
Nada de garbage collector.
Nada de alocação dinâmica despreocupada.
Cada instrução tinha peso, custo e consequência.
E, ainda assim, o sistema implementava conceitos que hoje chamamos de:
escalonamento de tarefas,
priorização,
preempção,
degradação em caso de sobrecarga.
Os famosos alarmes 1201/1202 não significavam falha total.
Significavam: “estou ocupado demais, vou manter apenas o essencial”.
Esses números foram alarm codes emitidos pelo Apollo Guidance Computer (AGC) enquanto Neil Armstrong e Buzz Aldrin estavam descendo em direção à superfície lunar no módulo lunar Eagle. Durante o pouso, o computador começou a receber mais dados do que podia processar ao mesmo tempo (algo que hoje chamaríamos de overload). Ele então começou a disparar alarmes, especificamente os códigos 1201 e 1202, que significavam algo como executando fora de tempo ou excesso de ciclos de processamento não essenciais.
O que torna isso notável é que:
Os alarmes interromperam temporariamente o que estava sendo feito.
O computador não desligou nem falhou completamente.
Ele continuou priorizando tarefas críticas de navegação e controle, descartando tarefas menos importantes, e permitiu que o pouso prosseguisse.
Após a análise da equipe de terra (Mission Control), ficou claro que esses alarmes não eram fatais para o pouso, e os astronautas foram orientados a continuar.
Este episódio é frequentemente citado em engenharia de software como um exemplo real de degradação graciosa (graceful degradation) e fail-safe operations: o sistema lidou com uma situação de sobrecarga, não caiu e manteve a missão em andamento.
Esse comportamento é visível no código. Não como teoria, mas como lógica explícita.
E nesse ponto chegamos aos culpados por isso, a equipe de Margaret Hamilton.
Margaret Hamilton: quando software ganhou nome e responsabilidade
Nos anos 1960, quando programação ainda era vista como trabalho secundário, Margaret Hamilton liderava o desenvolvimento do software de voo do Apollo Guidance Computer no MIT Instrumentation Laboratory.
Não como coadjuvante. Como arquiteta.
Foi ela quem cunhou o termo “software engineering”, não por vaidade, mas por necessidade. Era preciso convencer a NASA de que software não era um detalhe frágil, e sim um sistema crítico, capaz de falhar, matar ou salvar uma missão inteira.
Durante o pouso da Apollo 11, quando os alarmes 1201 e 1202 surgiram por sobrecarga do computador, o software fez exatamente o que sua equipe havia projetado:
descartou tarefas secundárias, manteve o essencial e continuou funcionando.
Não foi sorte. Foi decisão de projeto.
Hamilton também projetou o sistema pensando em erro humano, algo radical para a época. O software não culpava o astronauta. Ele se protegia.
Hoje falamos em tolerância a falhas, prioridade de tarefas, degradação graciosa.
Em 1969, isso significava voltar para a casa.
Quem quiser entender por que software não é “apenas código” deveria começar por ela.
O resto da indústria ainda está tentando alcançá-la.
Virtual AGC, ibiblio e o caminho até o GitHub
Décadas depois, esse software quase se perdeu.
O que restou foram listagens em papel, scans e documentação técnica espalhada.
O projeto Virtual AGC, hospedado no ibiblio, nasceu para resolver isso:
reconstruir, preservar e tornar executável o software original da Apollo.
A partir desse trabalho monumental surgiu o repositório:
Ele organiza o código do módulo lunar da missão Apollo 11, com comentários originais, estrutura navegável e fidelidade histórica.
Não é um remake.
É uma edição crítica de um software que já cumpriu sua missão.
Uma palhinha do código que levou humanos à Lua
O software do Apollo Guidance Computer não foi escrito para ser elegante.
Foi escrito para não falhar.
Aqui está um trecho realista do Assembly do AGC, no estilo do que aparece no código original da Apollo 11:
BANK 10
SETLOC DISPLAYS
BANK COUNT 10/DSPLA PRIOLARM INHINT # * * * KEEP IN DISPLAY ROUTINES BANK
TS L # SAVE ALARM CODE CA BUF2 # 2 CADR OF PRIOLARM USER
TS ALMCADR
CA BUF2 +1
TC PRIOENT +1 # * LEAVE L ALONE
-2SEC DEC -200 # *** DONT MOVE
CAF V05N09
TCF PRIODSPR
Explicando cada linha:
BANK 10
SETLOC DISPLAYS
BANK
Aqui estamos dizendo ao AGC:
“Tudo o que vem agora está no banco 10, na região chamada DISPLAYS.”
O AGC não tinha memória plana. Ele funcionava por bancos de memória, trocados manualmente.
SETLOC DISPLAYS define o ponto lógico onde esse código será montado, ou seja, rotinas de interface com o astronauta. Nada menos.
O segundo BANK confirma o contexto. É uma espécie de “selo”: estamos nesse banco e ponto final.
COUNT 10/DSPLA
O assembler do AGC mantinha contadores de uso de memória.
Aqui ele está registrando que este código consome espaço da área DSPLA (display), no banco 10.
PRIOLARM INHINT # * * * KEEP IN DISPLAY ROUTINES BANK
Esse é o rótulo da rotina: PRIOLARM.
INHINT significa Inhibit Interrupts - inibir interrupções.
Tradução humana:
“Enquanto eu estiver lidando com alarmes prioritários, ninguém interrompe.”
Isso faz todo o sentido. Você não quer que uma interrupção qualquer atrapalhe a atualização de um alarme crítico exibido ao astronauta.
TS L # SAVE ALARM CODE
TS = Transfer to Storage.
O conteúdo atual do acumulador (A) é salvo em L.
L aqui funciona como uma variável temporária.
O comentário já entrega o papel: salvar o código do alarme.
Esse valor vai ser usado logo adiante.
CA BUF2 # 2 CADR OF PRIOLARM USER
TS ALMCADR
CA BUF2 carrega no acumulador o conteúdo de BUF2.
O comentário diz tudo:
BUF2 contém o CADR (Central Address) do “usuário” do PRIOLARM, ou seja, quem deve ser notificado ou chamado quando esse alarme dispara.
Esse endereço é salvo em ALMCADR.
Em termos modernos:
é como armazenar um callback para tratamento do alarme.
CA BUF2 +1
TC PRIOENT +1 # * LEAVE L ALONE
Aqui entra um detalhe elegante.
BUF2 +1 provavelmente contém outro parâmetro ou dado associado ao handler do alarme.
TC PRIOENT +1 transfere o controle para dentro da rotina PRIOENT, mas não no início, entra deslocado em +1.
Isso é controle cirúrgico de fluxo.
Nada de chamadas genéricas. O código sabe exatamente em que ponto entrar.
O comentário “LEAVE L ALONE” indica que essa entrada específica não sobrescreve o registrador L, que guarda o código do alarme.
Estado preservado.
-2SEC DEC -200 # *** DONT MOVE
DEC -200 define uma constante: provavelmente -2 segundos, em unidades internas de tempo do AGC.
O comentário “DONT MOVE” não é brincadeira.
Mover essa constante quebraria sincronização de tempo em rotinas de display e alarme.
Esse tipo de linha revela algo precioso: o código está acoplado ao tempo físico da missão.
CAF V05N09
CAF = Clear and Add Fixed.
Carrega no acumulador o valor constante V05N09.
Esse nome não é arbitrário.
No AGC, VxxNyy se refere a códigos de verbos e substantivos do DSKY (a interface numérica usada pelos astronautas).
Aqui estamos preparando o comando de display que será mostrado.
TCF PRIODSPR
TCF = Transfer Control to Fixed.
Salto direto para a rotina PRIODSPR, que cuida da exibição prioritária no display.
Sem retorno implícito.
Sem abstração.
O fluxo é explícito, direto e final.
Em resumo
Esse trecho:
desativa interrupções,
preserva o código do alarme,
resolve quem deve tratá-lo,
mantém estado com extremo cuidado,
prepara o comando correto de exibição,
e transfere o controle para o sistema de display prioritário.
Tudo isso com poucas linhas, nenhuma margem de erro e responsabilidade total.
Esse código não “avisa” o astronauta.
Ele interrompe o universo interno da nave para dizer:
“Algo importante está acontecendo. Olhe agora.”
E depois, silenciosamente, continua funcionando.
É código no “nível sobrevivência”.
O detalhe que muda tudo
Esse software rodava em um ambiente onde:
não existia sistema operacional no sentido moderno,
não existia proteção de memória,
não existia possibilidade de reiniciar “só pra ver se volta”.
O AGC funcionava porque tudo era previsível.
- Cada ciclo de CPU.
- Cada palavra de memória.
- Cada salto de execução.
Quando, durante o pouso lunar, tarefas secundárias começaram a sobrecarregar o sistema, o computador não entrou em pânico.
Ele descartou o que não era essencial e manteve o controle da nave.
Por que só uma palhinha do código?
Você viu o tamanho da pilha de código ao lado de Margaret... brincadeiras à parte, esse código não deve ser consumido como curiosidade rasa.
Ele merece contexto, tempo e respeito.
O Noir Code não tenta explicar o AGC por completo.
Ele apenas abre a porta e acende uma lâmpada fraca.
Quem quiser ir além deve ir direto às fontes originais:
o repositório Apollo-11, com o código organizado e preservado,
o projeto Virtual AGC, com simulador, documentação e material histórico.
Aqui fica apenas o eco das instruções.
O resto está lá fora, ainda funcionando, décadas depois, como um lembrete silencioso de que software bem feito pode atravessar o espaço.
No NoirCode, o futuro é digital, e você já faz parte dele!
.webp)