Yes, the Apollo guidance computer was what we would call an embedded controller. You don't need a lot of computing power to do that. However, for the actual argument we're going to need a lot more than, "I'm really smart and I say it can't be done." There are a lot of demonstrably smart people who very firmly believe it can be done, and can bring receipts.
First among them are books written by Don Eyles and others by Eldon Hall. But not least of all them is Curious Marc on YouTube, whose team led by Mike Stewart found an old AGC on a trash heap and restored it to function. I met him briefly in 2019; I think he probably forgot more about computer science last night over a beer than I ever knew. His YouTube channel is replete with people who have the original hardware in hand and considerable computer and electrical engineering experience. They're working from the original system specifications.
The Luminary code is out there on GitHub and there is at least one full-scale software emulator out there. If the claimant is a software guy, maybe he can tell us why P63, P64, and P65 are not up to the task. The claim, "The computer wasn't powerful enough," is typically made by people with only modern general-purpose computer experience—none in historical computer architectures and none in embedded systems. The Incredulous Expert character has been around since I started looking at these claims in the 1990s and never seems to be as smart as he claims.
I can't imagine anyone who actually knows the claims made about the AGC seriously saying it lacked the "means." It had the ability to pick off gimbal angles from the IMU. It's straightforward free-body dynamics to convert that to spacecraft attitude and compare that to a set point (9 multiplications). The mathematical foundation is a straightforward proportional-differential controller, part of industrial automation since the 1940s. The outputs are "discretes," commands to initiate and stop control moments in the cardinal directions. There was actually a separate discrete logic bank that controlled the actual jets; it could compensate for the loss of a thruster. The computer just says, "Hm, I've measured my pitch angle as being outside the hysteresis and getting worse in the up direction. Send the PITCH DOWN command to the jet logic and hold it there until the pitch rate is positive." (2 comparisons and 1 memory write, etc.) It's important to understand how many tasks were performed by custom electronics that today we would contemplate doing in software. The above is the operation of the DAP in ATT HOLD mode (one of three modes). It's an always-running task that only needs to happen every 0.1 second in order to keep the ship oriented properly during accelerated flight. It's inactive during unaccelerated flight.
The thrust program is a separate task. Its inputs are accelerometer data from the IMU and altitude data from the landing radar. The radar operates on its own and uses an interrupt to "poke" the altitude directly into the computer's memory at 800 Hz. The computer doesn't need it that frequently, but it's up to date at any given moment; the computer just has to read it. The other input (in manual mode) is the pilot's desired descent rate. The output is a single value: the actual actuator position for the pintle throttle on the DPS. I recall this runs at 10 Hz, but my memory may be fuzzy. But it's 2 comparisons and possibly one memory write.
The DPS gimbaling is a separate low-priority task. The DAP increments a counter for each direction every time it has to fire. If one counter is consistently higher than the other, this program has four outputs: screwjack motor commands in each direction along two engine gimbal axes. Here again you have auxiliary electronics that handle turning the screwjack motors on and off at the commanded chi angle. Six comparisons and possibly two memory writes.
The higher level programs P63-P66 simply feed desired set points into the higher-frequency control tasks according to either a time-based schedule or in coarse response to inputs from various sensors. These are very slow-paced operations. This is incidentally how modern autopilots work, so this isn't a strange proposition to anyone who has actually programmed flying machines (which I suspect your claimant hasn't).
P63's job is to get the LM from "high gate" to "low gate." These "gates" are simply altitude, forward speed, vertical speed, and attitude parameters that need to be met in order to transition to a new program. "Initiating powered descent" simply means pulling the trigger on P63 from orbit. P63 operates according to a physics model that prioritizes residual orbital behavior, but integrates downward ballistic behavior—orbital braking. The ship is heads-down so that the pilot can view the surface and engine facing the direction of travel to maximize braking thrust. Its input is a programmed set of desired velocity states. Its output is throttle set-point and attitude set-point. The goal is to adjust altitude orbitally and downrange position in order to arrive at "low gate." This is straightforward closed-loop control. (Most software-only people have zero experience in control theory.)
P64's job is to get the LM from "low gate" to a laterally-stationary position some 100 feet above the landing site and descending at a rate within a certain range. This program has a very coarse (one nautical mile granualarity) map of terrain variation near the landing site. So it does have terrain avoidance in the grossest sense, but not enough to avoid boulders and craters. It operates according a physics model that ignores orbital behavior and focuses strictly on ballistic physics. Its input is the programmed landing point in 2D coordinates (latitude and longitude), which the pilot may change (but doesn't have to) by using the joystick. P64 has to find the 3D coordinates (latitude, longitude, and altitude from theoretical lunar center) by interrogating its terrain map for those coordinates and estimating the local terrain variation. This is so its notion of "100 feet above the surface" isn't really 30 feet below it. It uses a bilinear interpretation method for this, but has to do it only once when the landing point is redesignated.
The ship has rolled over on its back and pitched forward (again, just a program feeding desired attitude set-points to the DAP). This lets the crew see the landing site and lets the landing radar point at the ground. The DPS is now pointing more down than forward. P64 wants to alter the descent rate and forward motion according to a preset series of conditions so as to arrive at the landing point at an altitude of 100 feet and descending at a certain rate. That's a simple set of comparisons: Am I too high? Am I too low? Am I dropping faster or slower than I should be (proportional-differential control)? Is my downrange velocity and deceleration appropriate for the time-to-go for the landing point? Because pitch angle, throttle setting, altitude, descent rate, and forward travel rate are all coupled, the program response through its various discrete set-points is non-trivial, but these are figured out ahead of time. Control laws in coupled variables are child's play for people who have actually studied engineering.
It's important to realize that neither of these programs needs to be furiously computing things at zillions of times per second in order to achieve this, just as you don't need to make micro adjustments to your steering wheel every millisecond in order to stay on the road. Most of these programs just sat and waited for the ship to cover the distance, checking every couple of seconds to see whether any of the parameters had drifted out of tolerance.
P65 is the auto-land program, which no one used but which could have been used in theory to land an uncrewed LM. In a hypothetical unmanned mission, it would have reduced the descent rate over the remaining 100 feet of altitude in order to achieve a small rate of descent, a zero lateral rate, and a perfectly vertical attitude at an altitude of six feet, whereupon it cuts the DPS. Again the DPS is doing the heavy lifting here (pun intended). P65 just sets a vertical attitude for it to hold and frobs the throttle setting up and down to maintain the proper altitude-and-descent-rate profile.
P66 was the manual landing program, which all the pilots used. The DAP switches to a different attitude hold mode but takes its set-point from the hand controller. The throttle switches to manual. This is a dirt-simple program. I suspect your claimant has a completely wrong-headed idea about what computing tasks actually needed to be done.
The scenario where ground computers are doing the heavy computing has more to do with orbital flight mode. The big number crunching was done at Lawrence Livermore lab on the CDC 6600, which was about as powerful as a Pentium 90 CPU. These intermediate results could be fed to the RTCC computers—IBM 70x and 360 series—to (more slowly) finish, and then desired orbital flight parameters can be uploaded to the AGC.
