This is such an interesting peek into the engineering of these sort of systems with very constrained resources at the time. Like any random file you open contains little pragmatic design decisions like this
# THE POSITION OF THE MOON IS STORED IN THE COMPUTER IN THE FORM OF
# A NINTH DEGREE POLYNOMIAL APPROXIMATION WHICH IS VALID OVER A 15
# DAY INTERVAL BEGINNING SHORTLY BEFORE LAUNCH. THEREFORE THE TIME
# INPUT BY THE USER SHOULD FALL WITHIN THIS 15 DAY INTERVAL.
The Apollo program set a requirement for a fourteen day mission from the beginning. None of the missions lasted that long; the longest was Apollo 17 at 12 and a half days.
The Space Shuttle flight software used an interpolating polynomial for the solar ephemeris, with coefficients that were valid 10+ years (I've forgotten the exact number). The solar position was an input to the atmosphere model used to compute on-orbit drag, which itself was itself an interpolating function for data generated by a model with higher fidelity. I could go on. The pattern of using interpolation formulas to save memory and CPU cycles was (is) a common one.
People would be surprised by the amount of data required for on-board guidance and navigation software. Some of it is non-mission specific, but much of it must be generated for each mission. During the Shuttle era, these parameters were called I-Loads (for Initialization, of course) and were a separate memory load from the flight software itself.
The coefficients are stored in writable memory as input data. Only the structure and degree of the polynomial are hard-coded in the program. So if the launch is delayed you just change the data.
Of course, the justification is that compute and memory were at an extreme premium on the spacecraft. Accurately predicting the position of the moon at arbitrary times requires more complicated calculations. You can dramatically optimize the calculation by fitting a polynomial approximation which is valid for the length of the mission. And there's no reason to waste resources fitting that polynomial in space when it could be done on the ground, using much more powerful machines.
The AGC is what tends to get the press. It's easy to forget that the Apollo program relied on a cutting-edge distributed hardware and software stack, most of which was in Mission Control at the Real Time Computing Center.
It wasn't hardcoded. The exact mission parameters (mission clock, moon position, orbital parameters, etc) were uploaded by mission control the morning of the launch. From that point, they had 15 days. The longest Appolo mission was 12.5 days.
Not sure in which video (pretty sure it was one of Marc's videos) it was mentioned, but what I found particularly interesting is that they restored the source code by just cherry picking patches documented elsewhere until the output matched the documented checksums...
This remains to be my go-to example for how YouTube can be a remarkably effective and valuable platform for the kind of enthusiast whose interests have exceeded the bounds of typical documentaries and media produced for the general public.
It’s sadly getting more difficult to surface these kinds of examples, as we’re seeing a lot of lowest common denominators and slop-py channels run by people who only want to be YouTube content mills, rather than people who have expertise to share and who learned to leverage YouTube as a means to those ends.
The purpose of this project is to provide the original flight software and emulations of the onboard guidance computers flown in historical spacecraft, so that the flight software can be run on computers commonly available to the public today. The particular emphasis is on the Apollo Guidance Computer (AGC) flown in lunar missions in the 1960's and 1970's.
Damn, a control panel to input values, probably straight to the CPU. I guess the astronauts didn't have to learn assembly, but imagine a programmer having to recite all the raw code (I guess the commands (verbs) are numeric as well) to debug something, all the way at the moon.
The DSKY was the main input system for the AGC, and commands were inputted using the verb/noun system. Verb says what you want to do, and Noun says what you want to do that verb to.
For example, "Verb 35 Enter" lights every single segment and light on the DSKY, to make sure they're all working. "Verb 16 Noun 17 Enter" displays the IMU measurements, "Verb 16 Noun 36 Enter" displays the current time and "Verb 16 Noun 43 Enter" displays the current GPS lat/long. Verb 16 indicates to display something as decimal, and the noun indicates what to display.
Other commands could be used to input data, or set what program the AGC was running, for example if you wanted to change the current running program to 67, that would be "Verb 37 Enter 67 Enter"
While I know about the DSKY, I keep wondering if they were the first ones, i.e. inventing that way of entering data into a computer and others copied it later on, or if it was a already a more widespread and known pattern and the AGC copied it.
I know that other machines existed that used a similar system. I recall being asked, circa summer 2009 or so, to set up extensions on a quite old PABX that was configured that way.
The PABX was a huge electrical box full of giant PCBs stuck into a backplane (S-100 or maybe something proprietary?). I didn't get a good look tough, the box was mounted under the ceiling, directly above a desk with a terminal that you used for configuring it. There was a binder with laminated, typewritten cards, documenting "verbs" and "nouns" that you entered into a numeric keypad. As said, it worked like the Apollo DSKY, but the "display" was single slot that you had to squint through at just the right angle to make out faint numbers on a mirror, aimed downwards at some back projection thingy.
The funniest thing is that DSKY was, IIRC, a "temporary solution" that became the norm, and despite all the platitudes today it was apparently hated by astronauts.
Yes, 140W USB-C Power Adapter (A3607) has CYPD3135 controller which is based on 32-bit, 48-MHz Cortex M0 CPU with 2 times more RAM (8KB), 128 KB flash and around 500 to 1000 times higher performance.
How does it compare on IO? The normal blurbs rarely give a hard number but the AGC as a flight computer has to interface with quite a few devices. I found one thing that said it had 20 16-bit IO channels which would be well over 300 io pins.
A follow up question, I have never done anything with microcontrollers. How does one attach large amounts of IO to them? Common bus and everyone talks I2C? Multiplexer IC's?
I have been collecting Autonetics artifacts off ebay for decades. What I find interesting about this time period is that Autonetics made 3 different efforts for digital inertial guidance. The first version used vacuum tubes and was never commpleted. The second version used the new discrete components developed by Sprague Electric. This version went into production. Autonetics then set about exploring the lithographic process to shrink the discrete component version into an IC based system. Autonetics essentially built the same computer using 3 different circuit construction methods. Here are some pictures of pieces of all 3 systems. The IC's are from about 1967.
One of the 2 nerds in the photo is Richard Stallman next to the Autonetics D-17B. An early inertial guidance system distributed to universities to study as real time computers after decommissioning.
There are also the hard disks(which the D-17B used as a clock) and gyroscopes that served as inputs.
Great to see the AGC assembly code and knowing that Apollo 11 is coded purely in assembly. Not sure if it has any compiler. Also found https://github.com/virtualagc/virtualagc while searching for compiler.
The assembler you're looking for, is called YUL. [0]
You can find much of that code here [1], but unless you have a Honeywell, it isn't much help. yaYUL is a modern remake, and can assemble most of the Apollo code.
Part of the AGC ROMs implemented a virtual machine for things like matrix multiplication. So, a higher level of abstraction was available but it was still very much coded in its own assembly language.
> knowing that Apollo 11 is coded purely in assembly
Of course. According to Wikipedia, it was introduced in 1966, so it's development must have been started earlier. Also according to Wikipedia higher-level languages like Fortran and Cobol were introduced in 1957/58. They were a cutting-edge technology of the era.
So programmers of the day would have been comfortable with assembly, and the inefficiency and novelty of higher-level languages would have probably been a bad fit for the application.
Well, I have no idea how complete this is, but perhaps a neat Christmas-time-project for anyone with seemingly unlimited tokens to take this and let it build up a simulator, using the real code to drive simulated machinery.
My favorite complaint during development of our simulator was someone who insisted we give them the means to replace the "jingoistic" American markings from the spacecraft so they could pretend the mission was flown by some multinational utopian organization like Starfleet. Of course, that person evaporated when things actually started to work and they would have to actually put effort into their Starfleet artwork instead of just continually trying to start political slapfights on the internet.
The moon hoaxers were boring and unfunny. I remember writing something along the lines of "There is a chance that this will never work because it was all a hoax and never worked in the first place, but I will try anyway because I am an optimist." I think that made them madder than anything else.
The real problem with it turned out to be that while the software is complete it expected data to be provided from both the crew and the ground at different points in the mission. Without this external data (and more importantly, the procedures and processes that generated it) the software is really just a very obtuse desk clock.
Actually making use of the software required years of extra work in document archaeology and reverse engineering the processes and constraints that generated the data used during the flights.
Orion on Artemis has a bunch of really cool stuff like redundant computers but it's certainly jarring to go from Verbs and Nouns of Apollo to seeing them tapping on screens with a GUI
Strange that no one took the effort to fix yaYUL to read the YUL format, but instead of adapting the transcription of the source to match the 'quirks' of yaYUL.
Not the same goals, risks, monetary budget, time budget.
If your goal was to absolutely prevent any errors and you would go great lengths to do it, you would.
Just look at any safety critical systems: medical, transportation. There has been some incidents, but some systems do work really well that are developed today.
I’ve never attempted to calculate it, but I’ve always felt that the money lost from major incidents must outweigh the additional engineering time spent doing things right. Of course, that assumes that the engineering skill exists, and that the deliberate choice is being made to push out sub-optimal code in favor of velocity (which is then negated by the incidents anyway).
Might just be because we still communicate with them, having the source might allow bad actors to control them. Hopefully one day, it could be released once obsolete.
This is such an interesting peek into the engineering of these sort of systems with very constrained resources at the time. Like any random file you open contains little pragmatic design decisions like this
https://github.com/chrislgarry/Apollo-11/blob/master/Comanch...
# THE POSITION OF THE MOON IS STORED IN THE COMPUTER IN THE FORM OF # A NINTH DEGREE POLYNOMIAL APPROXIMATION WHICH IS VALID OVER A 15 # DAY INTERVAL BEGINNING SHORTLY BEFORE LAUNCH. THEREFORE THE TIME # INPUT BY THE USER SHOULD FALL WITHIN THIS 15 DAY INTERVAL.
Better be back home in 15 days! ;)
The Apollo program set a requirement for a fourteen day mission from the beginning. None of the missions lasted that long; the longest was Apollo 17 at 12 and a half days.
The Space Shuttle flight software used an interpolating polynomial for the solar ephemeris, with coefficients that were valid 10+ years (I've forgotten the exact number). The solar position was an input to the atmosphere model used to compute on-orbit drag, which itself was itself an interpolating function for data generated by a model with higher fidelity. I could go on. The pattern of using interpolation formulas to save memory and CPU cycles was (is) a common one.
People would be surprised by the amount of data required for on-board guidance and navigation software. Some of it is non-mission specific, but much of it must be generated for each mission. During the Shuttle era, these parameters were called I-Loads (for Initialization, of course) and were a separate memory load from the flight software itself.
As a space travel geek from decades ago, I would have upvoted you for the user name alone. :-)
The LM landing algorithm was also based on a polynomial, with "time-to-go" as the variable. Problems would occur if that variable went negative.
Given the constant launch delays how could they justify hard coding a 15 day window like this?
The coefficients are stored in writable memory as input data. Only the structure and degree of the polynomial are hard-coded in the program. So if the launch is delayed you just change the data.
Of course, the justification is that compute and memory were at an extreme premium on the spacecraft. Accurately predicting the position of the moon at arbitrary times requires more complicated calculations. You can dramatically optimize the calculation by fitting a polynomial approximation which is valid for the length of the mission. And there's no reason to waste resources fitting that polynomial in space when it could be done on the ground, using much more powerful machines.
The AGC is what tends to get the press. It's easy to forget that the Apollo program relied on a cutting-edge distributed hardware and software stack, most of which was in Mission Control at the Real Time Computing Center.
It wasn't hardcoded. The exact mission parameters (mission clock, moon position, orbital parameters, etc) were uploaded by mission control the morning of the launch. From that point, they had 15 days. The longest Appolo mission was 12.5 days.
And I'm scared to hardcode some negligible config value that will never change
Happy 10-year anniversary to this repo being shared on HN.
Most significant discussion: https://news.ycombinator.com/item?id=12048945, 652 points, 145 comments on July 7, 2016
All previous submissions: https://news.ycombinator.com/from?site=github.com/chrislgarr...
Thanks! Here are the two past submissions with comments:
Apollo 11 Guidance Computer source code for the command and lunar modules - https://news.ycombinator.com/item?id=22367416 - Feb 2020 (30 comments)
Apollo 11 Guidance Computer source code - https://news.ycombinator.com/item?id=12048945 - July 2016 (145 comments)
For an terrific AGC deep dive, I can’t recommend Marc’s restoration videos enough. The work they did was incredible:
https://youtube.com/playlist?list=PL-_93BVApb59FWrLZfdlisi_x...
Not sure in which video (pretty sure it was one of Marc's videos) it was mentioned, but what I found particularly interesting is that they restored the source code by just cherry picking patches documented elsewhere until the output matched the documented checksums...
This remains to be my go-to example for how YouTube can be a remarkably effective and valuable platform for the kind of enthusiast whose interests have exceeded the bounds of typical documentaries and media produced for the general public.
It’s sadly getting more difficult to surface these kinds of examples, as we’re seeing a lot of lowest common denominators and slop-py channels run by people who only want to be YouTube content mills, rather than people who have expertise to share and who learned to leverage YouTube as a means to those ends.
and Master Ken and co...
https://github.com/chrislgarry/Apollo-11/blob/master/Comanch...
I feel like "BEWARE"... is, given the context, what we would now likely call "load-bearing"
(edit: formatting)More here (linked in the repo):
Original scans (featuring Margaret Hamilton!)
https://28gpc.csb.app/
The Virtual AGC Project Spaceborne Computer Systems
https://www.ibiblio.org/apollo/
The purpose of this project is to provide the original flight software and emulations of the onboard guidance computers flown in historical spacecraft, so that the flight software can be run on computers commonly available to the public today. The particular emphasis is on the Apollo Guidance Computer (AGC) flown in lunar missions in the 1960's and 1970's.
Wikipedia on the hardware:
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
For a superb video explaining what the AGC did and what WENT WRONG during the moon landing including the error codes:l, see: https://youtu.be/B1J2RMorJXM?si=Ad1UYojAtee2ktr3
Clicking around the code, it mentions a page with images... even more clicking around got me to this page/image: https://www.ibiblio.org/apollo/Block1.html#DSKY / https://www.ibiblio.org/apollo/Block1ControlPanelDSKY.jpg
Damn, a control panel to input values, probably straight to the CPU. I guess the astronauts didn't have to learn assembly, but imagine a programmer having to recite all the raw code (I guess the commands (verbs) are numeric as well) to debug something, all the way at the moon.
The DSKY was the main input system for the AGC, and commands were inputted using the verb/noun system. Verb says what you want to do, and Noun says what you want to do that verb to.
For example, "Verb 35 Enter" lights every single segment and light on the DSKY, to make sure they're all working. "Verb 16 Noun 17 Enter" displays the IMU measurements, "Verb 16 Noun 36 Enter" displays the current time and "Verb 16 Noun 43 Enter" displays the current GPS lat/long. Verb 16 indicates to display something as decimal, and the noun indicates what to display.
Other commands could be used to input data, or set what program the AGC was running, for example if you wanted to change the current running program to 67, that would be "Verb 37 Enter 67 Enter"
While I know about the DSKY, I keep wondering if they were the first ones, i.e. inventing that way of entering data into a computer and others copied it later on, or if it was a already a more widespread and known pattern and the AGC copied it.
I know that other machines existed that used a similar system. I recall being asked, circa summer 2009 or so, to set up extensions on a quite old PABX that was configured that way.
The PABX was a huge electrical box full of giant PCBs stuck into a backplane (S-100 or maybe something proprietary?). I didn't get a good look tough, the box was mounted under the ceiling, directly above a desk with a terminal that you used for configuring it. There was a binder with laminated, typewritten cards, documenting "verbs" and "nouns" that you entered into a numeric keypad. As said, it worked like the Apollo DSKY, but the "display" was single slot that you had to squint through at just the right angle to make out faint numbers on a mirror, aimed downwards at some back projection thingy.
The funniest thing is that DSKY was, IIRC, a "temporary solution" that became the norm, and despite all the platitudes today it was apparently hated by astronauts.
I think I read somewhere around here the code could be run today on something as low powered as the chip that runs the USB charger for an iphone
So yeah I'd like to see that lol
Ostensibly the ability to run the old lunar navigation code explains where many of these chargers disappeared to.
Yes, 140W USB-C Power Adapter (A3607) has CYPD3135 controller which is based on 32-bit, 48-MHz Cortex M0 CPU with 2 times more RAM (8KB), 128 KB flash and around 500 to 1000 times higher performance.
How does it compare on IO? The normal blurbs rarely give a hard number but the AGC as a flight computer has to interface with quite a few devices. I found one thing that said it had 20 16-bit IO channels which would be well over 300 io pins.
A follow up question, I have never done anything with microcontrollers. How does one attach large amounts of IO to them? Common bus and everyone talks I2C? Multiplexer IC's?
Even that's probably way overkill.
Really cool to see this digitized and archived, it's such an important piece of history and really one of the earliest digital ic bases computers.
I have been collecting Autonetics artifacts off ebay for decades. What I find interesting about this time period is that Autonetics made 3 different efforts for digital inertial guidance. The first version used vacuum tubes and was never commpleted. The second version used the new discrete components developed by Sprague Electric. This version went into production. Autonetics then set about exploring the lithographic process to shrink the discrete component version into an IC based system. Autonetics essentially built the same computer using 3 different circuit construction methods. Here are some pictures of pieces of all 3 systems. The IC's are from about 1967.
One of the 2 nerds in the photo is Richard Stallman next to the Autonetics D-17B. An early inertial guidance system distributed to universities to study as real time computers after decommissioning.
There are also the hard disks(which the D-17B used as a clock) and gyroscopes that served as inputs.
https://www.icloud.com/sharedalbum/#B1iG4TcsmGWIVSf
To see the code in action (and learn many good things about Apollo computer) please watch this: https://www.youtube.com/watch?v=B1J2RMorJXM&pp=ygUPYXBvbGxvI...
Great to see the AGC assembly code and knowing that Apollo 11 is coded purely in assembly. Not sure if it has any compiler. Also found https://github.com/virtualagc/virtualagc while searching for compiler.
The assembler you're looking for, is called YUL. [0]
You can find much of that code here [1], but unless you have a Honeywell, it isn't much help. yaYUL is a modern remake, and can assemble most of the Apollo code.
[0] https://www.ibiblio.org/apollo/Documents/agcis_13_yul.pdf
[1] https://klabs.org/history/software/yul/
Part of the AGC ROMs implemented a virtual machine for things like matrix multiplication. So, a higher level of abstraction was available but it was still very much coded in its own assembly language.
Thanks! Seems actual code for interpreter is in https://github.com/virtualagc/virtualagc/blob/master/Luminar... . I see it is different for each revision/module.
> knowing that Apollo 11 is coded purely in assembly
Of course. According to Wikipedia, it was introduced in 1966, so it's development must have been started earlier. Also according to Wikipedia higher-level languages like Fortran and Cobol were introduced in 1957/58. They were a cutting-edge technology of the era.
So programmers of the day would have been comfortable with assembly, and the inefficiency and novelty of higher-level languages would have probably been a bad fit for the application.
> Not sure if it has any compiler.
What you're looking for is an assembler.
Previously posted by me here - https://news.ycombinator.com/item?id=46182669 - but didn't get any interest, not complaiing, good that it got noticed this time.
Well, I have no idea how complete this is, but perhaps a neat Christmas-time-project for anyone with seemingly unlimited tokens to take this and let it build up a simulator, using the real code to drive simulated machinery.
Or you use the virtualagc project linked in the readme to do the same thing without wasting a bunch of money on tokens.
And miss the chance to rewrite it in Rust?! How dare you, good sir!
My favorite complaint during development of our simulator was someone who insisted we give them the means to replace the "jingoistic" American markings from the spacecraft so they could pretend the mission was flown by some multinational utopian organization like Starfleet. Of course, that person evaporated when things actually started to work and they would have to actually put effort into their Starfleet artwork instead of just continually trying to start political slapfights on the internet.
The moon hoaxers were boring and unfunny. I remember writing something along the lines of "There is a chance that this will never work because it was all a hoax and never worked in the first place, but I will try anyway because I am an optimist." I think that made them madder than anything else.
The real problem with it turned out to be that while the software is complete it expected data to be provided from both the crew and the ground at different points in the mission. Without this external data (and more importantly, the procedures and processes that generated it) the software is really just a very obtuse desk clock.
Actually making use of the software required years of extra work in document archaeology and reverse engineering the processes and constraints that generated the data used during the flights.
Orion on Artemis has a bunch of really cool stuff like redundant computers but it's certainly jarring to go from Verbs and Nouns of Apollo to seeing them tapping on screens with a GUI
As other commenters have pointed out, some of the comments in there are pretty scary. I guess the astronauts didn't have to read the code:
`TC WHIMPER -1 # YES. DONT DO POODOO. DO BAILOUT.`
That could be alright, considering the system architecture. What you don’t want to read is “TOTAL HACK, FIX BEFORE LAUNCH.”
Strange that no one took the effort to fix yaYUL to read the YUL format, but instead of adapting the transcription of the source to match the 'quirks' of yaYUL.
the code that landed humans on the moon has 72k stars on github and your startup's monorepo still can't pass CI on the first try
Not the same goals, risks, monetary budget, time budget.
If your goal was to absolutely prevent any errors and you would go great lengths to do it, you would.
Just look at any safety critical systems: medical, transportation. There has been some incidents, but some systems do work really well that are developed today.
> monetary budget
I’ve never attempted to calculate it, but I’ve always felt that the money lost from major incidents must outweigh the additional engineering time spent doing things right. Of course, that assumes that the engineering skill exists, and that the deliberate choice is being made to push out sub-optimal code in favor of velocity (which is then negated by the incidents anyway).
In 1969, they had not invented lowercase yet.
With our current RAM prices we may soon need to lose lowercase again.
The common Teletype Model 33 that was widely used in that era only supported upper case.
We might never see the code for the Voyagers, though, sadly. It isn't owned by the government, for reasons. You can't FOIA it :(
Might just be because we still communicate with them, having the source might allow bad actors to control them. Hopefully one day, it could be released once obsolete.
The contribution of the 1969 assembly language is appreciated.
A truly great historical artifact of human space adventure
I swear, every few years something like this or exactly this seems to come up on HN
looks like its not hard to read assembly code
yeah. its common myth. Assemblers with labels and macros can be very easy to read and write
It's way easier to learn basics of 6502 or x86 assembly than to learn a new JavaScript framework from scratch.
[flagged]
[dead]
[dead]
Ok, someone evaluate it with Fable and vibecode it better. Remember "make no mistake".