Let us move on and dissect another front on which conspiracy theorists go so far as to display the full extent of their incompetence in electronics and computing: the alleged "impossibility" for the Apollo onboard computers to handle space navigation and the lunar landing. The deniers' argument is as trivial as it is flawed: they compare the software memory of the Apollo Guidance Computer (AGC) and of the Lunar (Module) Guidance Computer (LGC) with that of a modern smartphone, and conclude that, with just a few dozen kilobytes, you could not even send an e-mail, let alone land on the Moon! This simplistic and childish approach reveals a complete inability to tell raw computing power from extreme engineering optimization…

The AGC (the Command Module's Apollo Guidance Computer) and the LGC (the Lunar Module's Lunar Guidance Computer) were by no means "primitive" devices in the derogatory sense of the word: they represented the absolute cutting edge of 1960s microelectronics, being among the first computers in the world to use integrated circuits. They were, to all intents and purposes, the direct ancestors of the microprocessors found in today's modern computers, the very ones that deniers use every day to reveal to the world, via the Internet and social media, their complete ignorance of these subjects. This pioneering technology, which replaced thousands of individual transistors with small chips made of NOR logic gates, made it possible to squeeze the computing, comparison and sequencing functions (whose circuit boards, back then, filled an entire room here on Earth) into an aluminum case measuring 61 x 32 x 15 cm. A unit weighing just 32 kg, with a volume of only 30 cubic decimeters, cooled by water and ethylene glycol, capable of turning guided spaceflight, timed to the millisecond, into physical reality.

To understand how the AGC and the LGC could perform such complex maneuvers with minimal resources, we need to look at their functions and their peculiar memory architecture. Their wiring diagrams can be freely consulted, downloaded and reproduced at this link, and the same goes for the software "Colossus" for the AGC and "Luminary" for the LGC, written by Margaret Hamilton's team to make them work, which can be downloaded from this other link. It is up to the deniers to prove that they could NOT work: a proof we have, by the way, been waiting for for many years…

The memory, for example, was divided into a volatile part (Erasable Memory, the equivalent of modern RAM) for temporary calculations and a fixed memory known as Core Rope Memory, the equivalent of modern ROM. This fixed memory was a masterpiece of textile and computer engineering: the program code was literally "woven" through ferrite cores by skilled women workers, nicknamed the "Little Old Ladies". If a wire passed through a ferrite ring, it represented logic state "1"; if it passed around the outside, logic state "0".

Detail of the Apollo Command Module's AGC. The gray slots visible on this side of the computer housed the rope memories, into which the program code for the lunar mission was "woven". Photo courtesy of NASA.	Detail of a program slot of the Command Module's AGC. Each computer could hold up to 6 slots, each containing part of the programs needed for the mission. Photo courtesy of NASA.	Once opened, each program slot laid bare the heart of the technology used to store the program: the rope memories. Photo courtesy of NASA.
Magnified, the rope memories showed what they really were: an intricate logic network of interwoven copper wires that either passed or did not pass through a small magnetic ferrite ring. Photo courtesy of NASA.	The Command Module's AGC and the Lunar Module's LGC were two computers with essentially identical hardware: the only difference was the program stored in the rope memories. These programs were called Colossus for the AGC and Luminary for the LGC. Both were written by Margaret Hamilton's team; in the photo, the scientist stands next to the printed listings. Photo courtesy of NASA.	Each rope memory was built by hand, woven by the Little Old Ladies, a team of women who translated each single bit into a wire passing inside or outside the ferrite rings. Each slot was then rigorously tested on the ground to make sure it contained no dangerous bugs that might crash the computer in the middle of the mission. If a bit was wrong, the rope memory concerned was unpicked and re-sewn correctly. Photo courtesy of NASA.

This structure was not simply a read-only memory, but a logical fortress: since the data were physically wired into copper, the memory was completely immune to cosmic radiation and could not be erased or corrupted by voltage spikes or software errors. It was, to all intents and purposes, firmware "carved" into metal, so robust that it can still be made to work today: just watch the videos of electronics engineer Marc Verdiell, known as CuriousMarc, who recently brought one back to life after it had lain in a dusty NASA warehouse, getting it running again more than 50 years after it was built (try that with a modern computer)…

Let us be ruthlessly clear about the deniers' ideas: comparing Apollo's AGC with a home PC or a smartphone is technically wrong, shameful and utterly meaningless! Modern computers are general-purpose machines that waste over 90% of their resources on extremely heavy graphical interfaces 90% of a modern PC's memory resources are taken up by the gorgeous graphics we can no longer do without, and by a substantial undergrowth of applications that make possible all the interactions we consider perfectly normal…
(made of beautiful desktop wallpapers in 4K or even 8K, icons, animations and three-dimensional environments whose only purpose is to make every application look appealing and modern) and on multitasking operating systems (such as Windows, macOS, Linux or Android), whose sole purpose is to make an extremely complex machine such as a PC, a tablet or a smartphone accessible even to the most inept human being ever to walk the face of the Earth! They also waste processing cycles on the complex network protocols needed to connect to the Internet or to Wi-Fi, and on powering a hidden multitude of applications and support drivers that hold up this whole jumble, allowing touch screens to respond to our fingers, multicolor displays to light up showing us interfaces, videos and photos, keyboards and mice to collect input, and peripherals to print or to make multimedia experiences unique and satisfying. The AGC, on the other hand, did NOT have to display icons, nor did it have to let Aunt Pina from Pavullo, a graduate of the school of hard knocks, video-call via WhatsApp her niece Lina in Timbuktu while stirring the pasta sauce on the stove, to fill her in on her latest Facebook-sourced Moon-hoax discoveries (which not even the Soviet KGB ever managed to make!), nor upload videos or stream Hi-Fi music on Spotify: it was a pure calculator that had to solve the differential equations of celestial mechanics. Period! Anyone working today in microcontroller programming (such as ARM STM32, Microchip PIC, AVR, ESP32 or Teensy) or with PLCs (Programmable Logic Controllers) in industry knows perfectly well how much power lies in a few kilobytes of Assembly code, as long as it is free from the "fat" of the extremely heavy user interfaces we have grown used to and, at the same time, addicted to…

To bring down once and for all this ridiculous denialist farce about the tiny memory of the AGC, consider that 72 kilobytes of pure machine code (the total fixed memory available in the Apollo computers), or of combinational logic language such as Ladder, can hold an enormous number of operations. Since a single basic instruction takes up just a few bytes, 72 KB is enough to hold tens of thousands of instructions: status checks, Boolean operations and complex mathematical calculations (such as exponential, derivative, integral, logarithmic or trigonometric functions), executed cyclically and in real time. With that amount of pure sequential logic, stripped of any useless graphical frills, an industrial PLC can comfortably control the critical systems of a nuclear reactor: from millisecond-by-millisecond monitoring of pressure sensors, to complex management of the PID control loops of the cooling pumps, right up to the delicate sequences that automatically insert the control rods into the core to regulate the operating power or in an emergency (scram). And this is just one of countless possible examples! The sophisticated PLCs running industrial production lines in every sector, as well as the avionics computers that fly airliners every day with display graphics reduced to the bare essentials in order to optimize performance in favor of the mathematical processing needed for flight, run complex algorithms written in low-level languages (Assembly, C, C++) and stored on very low-capacity solid-state memories. Sizes that, compared with the gigabytes devoured by the operating systems of our home PCs, can only make you smile. This lightness of code, however, in no way limits their computing power or their ability to oversee operations of monstrous complexity, with all due respect to the unwitting Moon-landing deniers.

A modern industrial PLC essentially runs firmware of just a few kilobytes of code, stored in solid-state memory. Freed from heavy graphical interfaces (here delegated to so-called HMIs), it can operate at the highest level, carrying out even very complex functions.	Modern Aircraft Flight Computers (AFC) also run highly complex firmware that controls the flight functions of an entire airplane. Yet their programs, written in low-level code, are stored on solid-state memories of quite modest capacity.	Look at the cockpit of a modern airliner and you will notice straight away that the flight-data displays use graphics reduced to the bare essentials. This greatly relieves the AFCs of the burden of useless fancy interfaces, focusing resources on computing and processing, to the benefit of efficiency and safety.

In the same way, the Apollo software (just like the complex listings written for today's embedded devices mentioned above) was a gem of mathematical efficiency, written to talk directly to the hardware with no intermediate layers, no ifs and no buts. This architecture allowed the processor (built entirely from NOR logic gates!) to devote every single clock cycle to guidance and navigation calculations, to acquiring spatial data from the Inertial Measurement Unit (IMU) and to meticulous control of the thrusters. All of this without the frills of "trendy" modern technology, as celebrated as it is deeply misunderstood by today's general public. The Apollo program's logic hardware was raw computation, pure control, redundant architecture, efficient and proof against bugs and external interference, including the most extreme kind, such as cosmic radiation. That and nothing else!

The crew interacted with these computers through the DSKY (Display and Keyboard), an interface based on a system of "Verbs" and "Nouns". The astronauts did not "click" on intuitive commands, Detail of the AGC's DSKY, installed on the large control console of the Apollo Command Module. Photo courtesy of NASA.Detail of the LGC's DSKY, installed in the center of the Lunar Module's guidance console. Photo courtesy of NASA.but had to talk to the hardware at an extremely low level, memorizing strings of codes in octal notation to query the machine or give it instructions. The choice of octal was by no means random, but dictated by an essential need for optimization. The AGC's internal registers processed 15-bit words. For a human being, reading or entering binary strings of fifteen zeros and ones under the tremendous stress of spaceflight would have been cognitive suicide, leading to inevitable and deadly typing errors. On the other hand, converting the data into decimal would have wasted precious processing cycles and scarce memory. The solution was a perfect mathematical compromise: since in base eight each digit represents exactly three bits, a whole AGC word could be translated and keyed in by the astronaut using exactly five octal digits, allowing the computer to read the keyboard without complex software conversions. The language devised by MIT had a syntax as rigid as it was essential: the Verb specified the action, such as code 06 to display a value or 16 to monitor it continuously, while the Noun specified the memory register or variable, such as code 33 for the engine ignition time or 62 for inertial velocity and altitude. If an astronaut wanted to know his rate of descent, he did not look for a cute icon, but had to key in quick succession the Verb key, the digits 1 and 6, the Noun key, the digits 6 and 8, and finally the Enter key, so that the computer would start updating the electroluminescent display with the requested data. This way of working required almost total technical training and logical understanding, something utterly unimaginable today for the vast majority of people, not to mention the whole army of Moon-hoax fanatics. Today these people discredit the founding technologies of electronics and computing, calling them, with pitiful ignorance, "unfit for space travel", completely unaware that every single pixel of their modern tablets stands on the shoulders of those ferrite giants, built precisely to perform brilliantly in the hardest and most hostile environment humans have ever ventured into: outer space and the lunar surface!

But the deniers' biggest logical blunder is believing that the AGC was the only computing unit of the Apollo program. In reality, it was the operational terminal of a monumental computing hierarchy. One of the IBM System/360 mainframes at Houston's Mission Control Center, used to analyze spacecraft telemetry and compute state vectors for the AGC and LGC of the Apollo missions. Photo courtesy of NASA.At Mission Control in Houston, NASA deployed IBM System/360 mainframes, machines that filled entire rooms and were among the most powerful computers of their time. These giants processed the telemetry sent by the spacecraft, computed precise trajectories and returned updated "state vectors", which were uplinked by radio directly to the onboard computer (or, when necessary, keyed in by hand by the astronauts on the DSKY) for real-time corrections. The AGC and LGC onboard computers were therefore lean, essential computers: primordial autopilots, sequencers, precision timers, signal acquisition units and comparators optimized for local execution and safety, while the raw power remained on the ground. Denying that the AGC could do its job means ignoring the difference between a recreational operating system and a safety-critical control system: the physics of the universe does NOT require gigabytes of RAM and ROM to reach the Moon; all it takes is flawless Boolean logic, which can even be inexorably imprinted in the thin copper wires and ferrite cores of a 1960s rope memory!

Before closing this chapter, we must take the scalpel to one last, hilarious technical detail that is perhaps the clearest proof of the computer illiteracy of those who dispute the Moon landings: the legend of the phantom 36 kilobytes! Skimming through NASA's original technical manuals, deniers (and, sadly, a large crowd of superficial popularizers too) regularly stumble over the abbreviation "36K", used to indicate the capacity of the AGC's fixed memory. Most conspiracy theorists, whose computer literacy ends at the touch screen of their smartphone, read that "36K" and, out of a pathetic conditioned reflex, automatically add a "B", instantly turning the figure into 36 kilobytes (36 KB). On this glaring misreading they then build the whole mocking narrative about the spacecraft's computational impossibility. But 1960s aerospace engineering did not speak the commercial language of 1990s personal computers at all! Far from it! The fundamental unit of measurement of the Apollo architecture was not the ordinary 8-bit "byte", but the "word". In computing, the letter "K" does not mean "kilobyte": it simply stands for the binary multiplier 1024. The AGC's ferrite-core fixed memory consisted of exactly 36,864 words: dividing this number by 1024 gives the perfect whole number 36. And there is the mystery solved: the "36K" printed on the historical documents means 36K words (36 × 1024 = 36,864), not 36 kilobytes! Since the AGC architecture did not work in 8-bit blocks but used 16-bit words (15 data bits plus 1 parity bit for hardware error checking), each single word physically corresponded to two modern bytes. Unassailable mathematics therefore dictates that, to obtain the real capacity in bytes, you have to multiply by two. The 36,864 words of the Apollo Guidance Computer translate into 73,728 bytes in total, that is, exactly 72 kilobytes. Exactly double what the denialist pamphlets trumpet so carelessly! 

Claiming to unmask humanity's greatest engineering achievement by declaring a Moon landing "technically impossible" on the basis of hardware specifications one knows nothing about, and, worse still, whose unit of measurement one cannot even read, does not expose any government conspiracy: it only reveals deep technical ignorance!

Ultimately, the denialist thesis of Apollo's computational impossibility is just yet another by-product of a technologically spoiled society that mistakes computing power for "ability". Claiming that the Moon landing was faked because the AGC had less memory than a modern microwave oven is the intellectual equivalent of arguing that the pyramids cannot exist because the Egyptians had no electric cranes. The conspiracy theorist, unable to grasp the elegance of Assembly code that speaks directly to physics, prefers to take refuge in the ridiculous suspicion of a staged hoax, proving that the only truly obsolete and malfunctioning hardware in this story is his own way of reasoning, stuck in a loop of logical errors that, to stay on topic, not even a hard reboot could ever fix.