Procediamo con la dissezione di un altro fronte su cui i teorici del complotto si spingono fino a palesare tutta la loro incompetenza elettronica e informatica: la pretesa "impossibilità" per i calcolatori di bordo delle missioni Apollo di gestire la navigazione spaziale e l'allunaggio. L'argomentazione dei negazionisti è tanto banale quanto fallace: confrontano la memoria software dell'Apollo Guidance Computer (AGC) e del Lunar (Module) Guidance Computer (LGC) con quella di uno smartphone moderno, concludendo che, con poche decine di kilobyte, non si possa nemmeno inviare un'e-mail, figurarsi allunare! Questo approccio semplicistico e infantile rivela una totale incapacità di distinguere tra potenza di calcolo bruta e ottimizzazione ingegneristica estrema ...

L'AGC (Apollo Guidance Computer del Modulo di Comando) e l'LGC (Lunar Guidance Computer del Modulo Lunare) non erano affatto strumenti "primitivi" nel senso dispregiativo del termine, ma rappresentavano l'avanguardia assoluta della microelettronica degli anni '60, essendo i primi computer al mondo a utilizzare i circuiti integrati. Questi erano a tutti gli effetti i progenitori diretti dei microprocessori che oggi costituiscono i moderni computer, gli stessi che i negazionisti usano quotidianamente per rivelare al mondo, via Internet e via social, la loro completa ignoranza su questi argomenti. Questa tecnologia pionieristica, che sostituiva migliaia di singoli transistor con piccoli chip a porte logiche NOR, permise di comprimere le funzioni di calcolo, comparazione e sequenziamento (le cui schede elettroniche, a quei tempi sulla Terra, occupavano un'intera stanza) in un contenitore di alluminio di 61 x 32 x 15 cm. Un apparato pesante appena 32 kg, con un volume di soli 30 decimetri cubi, raffreddato ad acqua e glicole etilenico, in grado di rendere realtà fisica il volo spaziale guidato e temporizzato al millisecondo.

Per comprendere come l'AGC e l'LGC (i cui schemi elettrici sono liberamente consultabili, scaricabili e riproducibili a questo link, così come i codici software "Colossus" per l'AGC e "Luminary" per l'LGC, scritti dal team di Margaret Hamilton per consentirne il funzionamento, disponibili per il download a quest'altro link e di cui spetta ai negazionisti dimostrare che NON potessero funzionare, dimostrazione tra l'altro che stiamo ancora aspettando da tanti anni ...) potessero compiere manovre così complesse con risorse minime, bisogna analizzare le loro funzionalità e la loro peculiare architettura di memoria.

Quest'ultima, ad esempio, era divisa in una parte volatile (Erasable Memory, l'equivalente delle RAM moderne) per i calcoli temporanei e in una memoria fissa nota come Core Rope Memory, l'equivalente delle moderne ROM. Questa memoria fissa era un capolavoro di ingegneria tessile e informatica: il codice del programma era letteralmente "tessuto" attraverso nuclei di ferrite da operaie specializzate, soprannominate "Little Old Ladies". Se un filo passava all'interno di un anello di ferrite, rappresentava lo stato logico "1"; se passava all'esterno, lo stato logico "0".

Particolare del computer AGC del Modulo di Comando Apollo. Gli slots grigi che appaiono su questo lato del computer erano dedicati a contenere le rope memory con "tessuto" il codice di programma necessario alla missione lunare in corso. Foto cortesia NASA.	Particolare di uno slot di programma del computer AGC del Modulo di Comando. Ogni computer poteva contenere sino a 6 slots contenenti ciascuno una parte dei programmi necessari alla missione. Foto cortesia NASA.	Una volta scoperchiato, ogni slot di programma metteva a nudo l'essenza della tecnologia di immagazzinamento delle informazioni di programma: le rope memory. Foto cortesia NASA.
Se ingrandite a dovere le rope memory si mostravano per quello che erano: un'intricata rete logica costituita da fili di rame intrecciati che potevano intersecare o meno un anellino magnetico di ferrite. Foto cortesia NASA.	Sull'AGC del Modulo di Comando e su LGC del Modulo Lunare erano presenti due computer sostanzialmente identici nell'hardware. L'unica cosa che differiva era il programma ospitato sulle rope memory. Questi prendevano il nome di Colossus per l'AGC e Luminary per LGC. Entrambi furono scritti dal team di Margaret Hamilton, nella foto la scienziata appare con la versione stampata dei codici. Foto cortesia NASA.	Ogni Rope Memory veniva costruita a mano grazie al lavoro di tessitura eseguito dalle Little Old Ladies, un team di Signore che si occupavano di trasdurre i singoli bit in passaggi interni o esterni agli anellini di ferrite. Ogni slot veniva poi severamente testato a terra per verificare l'assenza di pericolosi bug che avrebbero potuto piantare il computer nel bel mezzo della missione. Se un bit era sbagliato si provvedeva a scucire la rope memory in causa e a ricucirla correttamente. Foto cortesia NASA.

Questa struttura non era semplicemente una memoria di sola lettura, ma una fortezza logica: essendo i dati fisicamente cablati nel rame, la memoria era totalmente immune alle radiazioni cosmiche e non poteva essere cancellata o corrotta da sbalzi di tensione o errori software. Era, a tutti gli effetti, un firmware "scolpito" nel metallo, tanto robusto che ancora oggi è possibile farlo funzionare: si veda questo link ai video dell'ingegnere elettronico Marc Verdiell soprannominato CuriosusMarc che recentemente ne ha resuscitato uno proveniente da un magazzino polveroso della NASA, facendolo funzionare di nuovo dopo più di 50 anni dalla costruzione (provateci con un computer moderno) ...

Occorre essere spietatamente chiari in merito alle idee dei negazionisti: il confronto tra l'AGC di Apollo e un PC domestico o uno smartphone è tecnicamente scorretto, vergognoso e totalmente privo di senso! I computer moderni sono macchine generaliste che sprecano oltre il 90% delle loro risorse per gestire pesantissime interfacce grafiche Il 90% delle risorse di memoria di un moderno PC sono assorbite dalle grafiche superbe di cui oggi non possiamo più fare meno, nonché da un sostanzioso sottobosco di applicazioni che rendono possibili tutte le interazioni che reputiamo normalissime ..
(fatte di bellissimi sfondi desktop anche in 4K o 8K, icone, animazioni e ambienti tridimensionali mirati unicamente a rendere accattivante e moderna ogni applicazione eseguita) e sistemi operativi multitasking (come Windows, macOS, Linux o Android), il cui unico scopo è rendere accessibilissima una macchina estremamente complessa come un PC, un tablet o uno smartphone, anche all'essere umano più inetto che abbia mai solcato la faccia della Terra! Sprecano inoltre cicli di calcolo per elaborare complessi protocolli di rete necessari ad accedere a Internet o al Wi-Fi, nonché per alimentare una moltitudine sommersa di applicazioni e driver di supporto che sorreggono tutto questo marasma, permettendo ai touch screen di reagire alle nostre dita, ai display multicolore di illuminarsi mostrandoci interfacce, video e fotografie, alle tastiere e ai mouse di raccogliere dati e alle periferiche di stampare o rendere le esperienze multimediali uniche e appaganti. L'AGC, al contrario, NON doveva mostrare icone, non doveva permettere a zia Pina da Pavullo, laureata all'università della strada, di videochiamare via WhatsApp la nipote Lina a Timbuktu mentre mescola il sugo sui fornelli, per ragguagliarla sulle sue ultime scoperte luna-complottiste facebookiane (a cui nemmeno il KGB sovietico è mai arrivato!), né caricare video o riprodurre brani musicali Hi-Fi su Spotify: era un calcolatore puro che doveva risolvere equazioni differenziali di meccanica celeste. Punto! Chiunque oggi si occupi di programmazione di microcontrollori (come gli ARM STM32, i Microchip PIC, gli AVR, gli ESP32 o i Teensy) o di PLC (Programmable Logic Controller) in ambito industriale, sa perfettamente quanta potenza risieda in pochi kilobyte di codice Assembly, purché sgravati dal "grasso" delle pesantissime interfacce utente a cui siamo abituati e, allo stesso tempo, assuefatti ...

Per far crollare definitivamente questo ridicolo teatrino negazionista delle dimensioni di memoria infime degli AGC, basti pensare che con soli 72 kilobyte di puro codice macchina (la memoria fissa complessiva disponibile nei computer del programma Apollo) o di linguaggio logico combinatorio come il Ladder, si ha a disposizione un'infinità di operazioni potenziali. Poiché una singola istruzione base occupa pochissimi byte, 72 KB equivalgono a decine di migliaia di controlli di stato, operazioni booleane e calcoli matematici complessi (come funzioni esponenziali, di derivazione, di integrazione, logaritmiche o trigonometriche) elaborati ogni secondo. Con una mole simile di pura logica sequenziale, spogliata da qualsiasi inutile orpello grafico, un PLC industriale può tranquillamente governare i nodi critici di un reattore nucleare: dal monitoraggio millisecondo per millisecondo dei sensori di pressione, alla gestione complessa dei cicli di controllo PID delle pompe di raffreddamento, fino alle delicate sequenze di inserimento automatico delle barre di controllo nel nocciolo per la regolazione della potenza d'esercizio o in caso di emergenza (scram). E questo è solo uno degli innumerevoli esempi possibili! I sofisticati PLC che governano le filiere produttive industriali di ogni settore, così come i computer avionici che pilotano quotidianamente gli aerei di linea con una grafica ai display ridotta all'essenziale per ottimizzare le prestazioni a favore del calcolo matematico necessario al volo, eseguono algoritmi complessi scritti in linguaggi di basso livello (Assembly, C, C++) e immagazzinati su memorie a stato solido di bassissima capacità. Dimensioni che, se raffrontate ai gigabyte divorati dai sistemi operativi dei nostri PC domestici, non possono che far sorridere. Questa leggerezza del codice, tuttavia, non ne limita in alcun modo le capacità di calcolo né l'abilità di sovrintendere a operazioni di mostruosa complessità, con buona pace degli ignari negazionisti dell'allunaggio.

Un moderno PLC industriale esegue sostanzialmente un firmware risicato a pochi kilobyte di codice contenuto in una memoria allo stato solido. Lo sgravio di pesanti interfacce grafiche (in questo caso delegate alle cosiddette HMI) gli permette di operare ai massimi livelli eseguendo funzionalità anche profondamente complesse.	Anche i moderni Aircraft Flight Computer (AFC) sono dotati di firmware altamente complessi che permettono il controllo delle funzioni di volo di un intero aeroplano. Tuttavia il loro programmi scritti in codice di basso livello è memorizzato su memorie allo stato solido non eccessivamente capienti.	Se si osservano i moderni cockpit degli aerei di linea si noterà subito che i display di visualizzazione dei dati di volo, sono risicati ai valori essenziali di grafica. Questo permette di sgravare notevolmente gli AFC dal peso di inutili interfacce superbe, concentrando le risorse sulla capacità di calcolo e sull'elaborazione, a tutto vantaggio dell'efficienza e della sicurezza.

Allo stesso modo, anche il software dell'Apollo (al pari dei complessi listati dedicati agli attuali dispositivi embedded sopraccitati) era un gioiello di efficienza matematica, scritto per interagire direttamente con l'hardware senza strati intermedi, senza se e senza ma. Questa architettura permetteva al processore (realizzato unicamente con singole porte logiche NOR!) di dedicare ogni singolo ciclo di clock ai calcoli di guida e navigazione, all'acquisizione dei dati spaziali tramite la Piattaforma di Misura Inerziale (IMU) e al controllo meticoloso dei propulsori. Tutto questo senza i fronzoli della tecnologia moderna "di tendenza", tanto acclamata quanto intimamente incompresa dal grande pubblico odierno. L'hardware logico del programma Apollo era calcolo crudo, controllo puro, architettura ridondata, efficiente e a prova di bug e interferenze esterne, comprese le più estreme come le radiazioni cosmiche. Tutto questo e nient'altro!

L'equipaggio interagiva con questi calcolatori tramite il DSKY (Display and Keyboard), un'interfaccia basata su un sistema di "Verbi" (Verb) e "Sostantivi" (Noun). Gli astronauti non "cliccavano" su comandi intuitivi, Particolare del DSKY dell'AGC, installato sulla grande console di controllo del Modulo di Comando Apollo. Foto cortesia NASA.Particolare del DSKY di LGC, installato al centro della console di guida del Modulo Lunare. Foto cortesia NASA.ma dovevano parlare con l'hardware a un livello estremamente basso, imparando a memoria stringhe di codici in numerazione ottale per interrogare la macchina o impartirle istruzioni. La scelta dell'ottale non fu affatto casuale, ma dettata da un'irrinunciabile necessità di ottimizzazione. I registri interni dell'AGC elaboravano parole a 15 bit. Per un essere umano, leggere o inserire stringhe binarie composte da quindici zeri e uni sotto il tremendo stress di un volo spaziale sarebbe stato un suicidio cognitivo, portando a inevitabili e letali errori di digitazione. D'altro canto, convertire i dati in formato decimale avrebbe sprecato cicli di calcolo preziosi e memoria esigua. La soluzione fu un compromesso matematico perfetto: poiché nel sistema in base otto ogni cifra rappresenta esattamente tre bit, una parola intera dell'AGC poteva essere tradotta e digitata dall'astronauta utilizzando esattamente cinque cifre ottali, permettendo al computer di leggere la tastiera senza complesse conversioni software. Il linguaggio ideato dal MIT era strutturato su una sintassi tanto rigida quanto essenziale: il Verbo indicava l'azione specifica, come il codice 06 per visualizzare un dato o il 16 per monitorarlo costantemente, mentre il Sostantivo indicava il registro di memoria o la variabile, come il codice 33 per il tempo di accensione del motore o il 62 per la velocità inerziale e l'altitudine. Se un astronauta voleva conoscere la propria velocità di discesa, non cercava un'icona ammiccante, ma doveva digitare in rapida sequenza fisica il tasto Verb, i numeri 1 e 6, il tasto Noun, i numeri 6 e 8, e infine il tasto Enter, affinché il computer iniziasse ad aggiornare il display elettroluminescente coi dati richiesti. Questa modalità operativa richiedeva una preparazione tecnica e una comprensione logica pressoché totale, una cosa assolutamente inimmaginabile al giorno d'oggi per la stragrande maggioranza delle persone, nonché per tutta la schiera dei fanatici del complotto lunare. Costoro oggi screditano le tecnologie progenitrici dell'elettronica e dell'informatica definendole purtroppo con penosa ignoranza "inappropriate a viaggiare nello spazio", ignorando completamente che ogni singolo pixel dei loro moderni tablet poggia sulle spalle di quei giganti di ferrite, costruiti proprio per operare brillantemente nell'ambiente più difficile e ostile in cui l'uomo sia mai andato: lo spazio cosmico e la superficie lunare!

Ma l'errore logico più grossolano dei negazionisti è credere che l'AGC fosse l'unica unità di calcolo del programma Apollo. In realtà, esso era il terminale operativo di una gerarchia di calcolo monumentale. Uno dei supercomputer IBM System360 in dotazione all'MCC di Houston utilizzato per l'analisi della telemetria delle navicelle e il calcolo dei vettori di stato per l'AGC e LGC delle missioni Apollo. Foto cortesia NASA.Al Mission Control di Houston, la NASA schierava i super-computer IBM System/360, macchine che occupavano intere sale e possedevano la massima potenza di calcolo disponibile all'epoca sulla Terra. Questi mastodonti elaboravano i dati telemetrici inviati dalle navicelle, calcolavano le traiettorie di precisione e restituivano agli astronauti i "vettori di stato" aggiornati, che venivano poi inseriti manualmente nell'AGC dagli astronauti in missione per le correzioni in tempo reale. I computer di bordo AGC e LGC erano dunque dei calcolatori di minima, degli autopiloti primordiali, dei sequenziatori, dei temporizzatori di precisione, degli acquisitori di segnali per l'elaborazione e dei comparatori ottimizzati per l'esecuzione locale e la sicurezza, mentre la potenza bruta risiedeva a terra. Negare che l'AGC potesse compiere il suo ruolo significa ignorare la differenza tra un sistema operativo ludico e un sistema di controllo critico: per la fisica dell'universo NON servono gigabyte di RAM e ROM per andare sulla Luna, serve solo una logica booleana infallibile che può anche risultare impressa inesorabilmente nei piccoli cavi di rame e nelle ferriti di una Rope Memory degli anni '60!

Prima di chiudere questo capitolo, è doveroso affondare il bisturi su un ultimo, esilarante dettaglio tecnico che rappresenta forse la certificazione più incisa dell'analfabetismo informatico di chi contesta le missioni lunari: la leggenda dei fantomatici 36 Kilobyte!!! Leggendo frettolosamente i manuali tecnici originali della NASA, i negazionisti (e purtroppo anche una folta schiera di divulgatori superficiali) inciampano regolarmente nella sigla "36K", utilizzata per indicare la capacità della memoria fissa dell'AGC. La stragrande maggioranza dei teorici del complotto, la cui cultura informatica si limita al touch screen del proprio smartphone, legge quel "36K" e, per un patetico riflesso condizionato, aggiunge automaticamente una "B", traducendo istantaneamente il dato in 36 Kilobyte (36 KB). Su questo madornale e grossolano errore di lettura, costruiscono poi l'intera narrazione derisoria sull'impossibilità di calcolo del veicolo spaziale. Ma l'ingegneria aerospaziale degli anni '60 non parlava affatto la lingua commerciale dei personal computer degli anni '90! Tutt'altro! L'unità di misura fondamentale dell'architettura dell'Apollo non era il banale "byte" a 8 bit, ma la "Parola" (Word). In ambito informatico puro, la lettera "K" non significa "Kilobyte", ma rappresenta semplicemente il moltiplicatore binario 1024. La memoria fissa a nuclei di ferrite dell'AGC era composta esattamente da 36.864 parole: dividendo questo numero per 1024 pertanto, si ottiene il numero intero perfetto 36. Ed ecco svelato il mistero: quel "36K" stampato sui documenti storici significa 36.000 Parole, non 36 Kilobyte! Poiché l'architettura dell'AGC non ragionava in blocchi da 8 bit, ma utilizzava parole da 16 bit (15 bit di dati effettivi più 1 bit aggiuntivo di parità per il controllo degli errori hardware), ogni singola "Parola" corrispondeva fisicamente a due byte moderni. L'inappellabile matematica impone quindi che per ottenere la reale capacità in byte, occorra moltiplicare per due. Le 36.864 parole dell'Apollo Guidance Computer si traducono in 73.728 byte complessivi, ovvero esattamente 72 Kilobyte. Il doppio esatto di quanto strombazzato a vanvera sui pamphlet negazionisti! 

Pretendere di smascherare il più grande traguardo ingegneristico dell'umanità decretando "tecnicamente impossibile" un allunaggio sulla base di specifiche hardware di cui non si sa nulla e ancor peggio non si è nemmeno in grado di leggere l'unità di misura, non svela alcuna cospirazione governativa: dimostra unicamente che l'unico sistema irrimediabilmente obsoleto e malfunzionante è la logica di chi muove l'accusa!

In ultima analisi, la tesi negazionista dell'impossibilità informatica di Apollo è solo l'ennesimo sottoprodotto di una società tecnologicamente viziata che scambia la potenza di calcolo per "abilità". Pretendere che l'allunaggio sia un falso perché l'AGC aveva meno memoria di un forno a microonde moderno è l'equivalente intellettuale del sostenere che le piramidi non esistano perché gli egizi non avevano le gru elettriche. Il teorico del complotto, incapace di concepire l'eleganza di un codice Assembly che parla direttamente alla fisica, preferisce rifugiarsi nel ridicolo sospetto di una messinscena, dimostrando che l'unico hardware realmente obsoleto e malfunzionante, in questa storia, è proprio il loro modo di ragionare, rimasto incastrato in un loop di errori logici che, per rimanere in tema, nemmeno un riavvio forzato dei sistemi potrebbe mai correggere.