Anyone who is looking for something to run it on could take a look at Block I Apollo Guidance Computer (AGC): How to build one in your basement [1]. The build took one guy four years and a lot of wire-wrap. A fascinating and quite awe-inspiring piece of work.
that guy deserves a medal. 4 years of work and documentation and he gives it to the world. the documentation is pretty good with some incredible pictures and diagrams. now granted i'm not an electrical engineer so i don't know if it is accurate.
It's worth noting that the software, while only 36k machine words long, and the hardware, which was very slow even by the standards of other computers of the 60s, were remarkable works created in only a couple years by huge teams (peak of 800 people working on hardware and 400 on software IIRC).
Its popular to dismiss the AGC as simple and uninteresting, but it was a challenging engineering task, and it never once had a failure in flight.
There's lots of resources on the internet to read more. A great book on the topic is Digital Apollo by David Mindell
That was caused by an actual physical short (in space, conductive bits, usually soldier balls, floating around and shorting things was a big problem), which happened somewhat commonly. I think Apollo 12 nearly aborted the launch because the display was showing all 8s briefly, also caused by a short.
However there truly was never an unknown software bug discovered in flight. Lots of known software bugs had workarounds, partially because there was a hard deadline of about 4 months where the software couldn't be changed before the launch. Pretty amazing.
I would think it's accurate to state that the system never had a failure in flight if it never had a failure in flight, despite how many times it flew.
If you were to compare it to something else, then how many times it flew becomes important. For example, you can't necessarily say that a 100% success rate over 5 attempts is better than a 95% success rate over 100 attempts.
Right. I think I remember Digital Apollo quoting an engineer who estimated, based on their extensive ground testing, that the AGC had a MTBF of about 50,000 hours. That's not particularly good, but considering all the Apollo missions spent only about 1000 hours in space total, it was apparently good enough.
If this kind of thing interests you, there are some great resources here about the Gemini and Apollo guidance computer architecture, including recreations of them: http://www.ibiblio.org/apollo/. I also recommend the book "Digital Apollo" about the role of digital computers in early space flight. I found both fascinating.
I second your recommendation of "Diagital Apollo". A very interesting book.
Two other books worth checking-out are The Apollo Guidance Computer: Architecture and Operation by Frank O'Brien and Journey to the Moon: The History of the Apollo Guidance Computer by Eldon Hall. The latter book is not particularly well written, but the author was the AGC hardware design lead and this book captures a lot of his first-hand knowledge of the hardware development and testing process.
That article calls out this line (among others). I wonder what the actual story behind this comment was. I'm sure it's not as bad as, "I'm just putting this in temporarily and we should fix it before it goes to Mars". It probably means something else.
Yeah, considering the number of people working on this, I can't imagine anything was left to chance. Did the comments have some connotation that was lost to time, was it just joking around, or is there something that the developers seriously weren't sure about?
The Apollo 11 UI module, code named DSKY/PINBALL, was meant as a demonstration unit and never meant to be the actual operating interface for the mission.
"As time passed, and more and more people became familiar with the demo, nobody got around to inventing an improvement for the user interface, so the coders simply built it into the flight software without any specific requirements to do so"
The future will always be duct tape and bubble gum.
"The software for the Apollo Guidance Computer (AGC) and LM Abort
Guidance Computer (AGS) is believed to be in the public domain."
Eh? So is it open source or not?
I doubt someone would come around and claim exclusive copyright on this, but still... Netlib had the same problem, and that's why replacements exist. The ACM still once in a while claims copyright on ancient Fortran code from the late 1960's. Back then it was a blissful golden era when people didn't even think that source code was elligible for copyright.
Given the pocket calculator joke[1] I'm wondering if anyone has built functionally equivalent AGC code on a more modern processor? And by functionally equivalent I mean a black box tester with an Apollo AGC would not be able to tell if it was running the old code or the new code.
Yes it's a 2009 blog post, but I still found it new and interesting.
Especially the "# TEMPORARY, I HOPE HOPE HOPE" comments, so I decided to look into them and hopefully find someone who has a clue to explain...which I did, here's a link for anyone else interested...
So they must have written this simulator without help from source code http://svtsim.com/moonjs/agc.html. While it doesn't strike me as a bad simulator, I wonder if it's right.
Anyone who is looking for something to run it on could take a look at Block I Apollo Guidance Computer (AGC): How to build one in your basement [1]. The build took one guy four years and a lot of wire-wrap. A fascinating and quite awe-inspiring piece of work.
[1] http://klabs.org/history/build_agc/
that guy deserves a medal. 4 years of work and documentation and he gives it to the world. the documentation is pretty good with some incredible pictures and diagrams. now granted i'm not an electrical engineer so i don't know if it is accurate.
Wow. I have no idea what I just read, but it....it was awesome.
Haha... That's pretty amazing...
How about an emulator?
Sure: http://www.ibiblio.org/apollo/
Or, if you want a web-based version (via asm.js): http://svtsim.com/moonjs/agc.html
(I knew about the Burkey version, but the JS port I just found. Ain't the modern world amazing?)
This is a blog linking to a blog linking to the source (from 2009).
http://googlecode.blogspot.com/2009/07/apollo-11-missions-40...
^. Submissions should link to the source as much as possible, instead of reposts.
It's worth noting that the software, while only 36k machine words long, and the hardware, which was very slow even by the standards of other computers of the 60s, were remarkable works created in only a couple years by huge teams (peak of 800 people working on hardware and 400 on software IIRC).
Its popular to dismiss the AGC as simple and uninteresting, but it was a challenging engineering task, and it never once had a failure in flight.
There's lots of resources on the internet to read more. A great book on the topic is Digital Apollo by David Mindell
It never once had a failure in flight, except for the short in Apollo 14, which they managed to hack around mid-flight. Cool story: http://www.ibiblio.org/apollo/#Final_exam_for_the_advanced_s...
That was caused by an actual physical short (in space, conductive bits, usually soldier balls, floating around and shorting things was a big problem), which happened somewhat commonly. I think Apollo 12 nearly aborted the launch because the display was showing all 8s briefly, also caused by a short.
However there truly was never an unknown software bug discovered in flight. Lots of known software bugs had workarounds, partially because there was a hard deadline of about 4 months where the software couldn't be changed before the launch. Pretty amazing.
Digital Apollo is a great read.
> Its popular to dismiss the AGC as simple and uninteresting, but it was a challenging engineering task, and it never once had a failure in flight.
Stating it never failed in flight is jumping the gun a bit, it didn't fly enough times to get a reliable statistic.
I would think it's accurate to state that the system never had a failure in flight if it never had a failure in flight, despite how many times it flew.
If you were to compare it to something else, then how many times it flew becomes important. For example, you can't necessarily say that a 100% success rate over 5 attempts is better than a 95% success rate over 100 attempts.
Right. I think I remember Digital Apollo quoting an engineer who estimated, based on their extensive ground testing, that the AGC had a MTBF of about 50,000 hours. That's not particularly good, but considering all the Apollo missions spent only about 1000 hours in space total, it was apparently good enough.
If this kind of thing interests you, there are some great resources here about the Gemini and Apollo guidance computer architecture, including recreations of them: http://www.ibiblio.org/apollo/. I also recommend the book "Digital Apollo" about the role of digital computers in early space flight. I found both fascinating.
Or check out this for all sorts of info about NASA's probes:
http://history.nasa.gov/SP-480/sp480.htm
I second your recommendation of "Diagital Apollo". A very interesting book.
Two other books worth checking-out are The Apollo Guidance Computer: Architecture and Operation by Frank O'Brien and Journey to the Moon: The History of the Apollo Guidance Computer by Eldon Hall. The latter book is not particularly well written, but the author was the AGC hardware design lead and this book captures a lot of his first-hand knowledge of the hardware development and testing process.
It's not really new, you should have added the suffix "(2009)" to the title.
https://code.google.com/p/virtualagc/source/browse/trunk/Lum...
That article calls out this line (among others). I wonder what the actual story behind this comment was. I'm sure it's not as bad as, "I'm just putting this in temporarily and we should fix it before it goes to Mars". It probably means something else.
Anyone have any idea?
Further down in the same file there's a line:
Yeah, considering the number of people working on this, I can't imagine anything was left to chance. Did the comments have some connotation that was lost to time, was it just joking around, or is there something that the developers seriously weren't sure about?
We invest a lot of code in GUI, which makes me think of:
I'm afraid the holodeck will be society's last invention. - Scott Adams
And this ultimate GUI would require the ultimate coding effort.
The Apollo 11 UI module, code named DSKY/PINBALL, was meant as a demonstration unit and never meant to be the actual operating interface for the mission.
"As time passed, and more and more people became familiar with the demo, nobody got around to inventing an improvement for the user interface, so the coders simply built it into the flight software without any specific requirements to do so"
The future will always be duct tape and bubble gum.
http://www.ibiblio.org/apollo/ForDummies.html
http://code.google.com/p/virtualagc/source/browse/trunk/LICE...
"The software for the Apollo Guidance Computer (AGC) and LM Abort Guidance Computer (AGS) is believed to be in the public domain."
Eh? So is it open source or not?
I doubt someone would come around and claim exclusive copyright on this, but still... Netlib had the same problem, and that's why replacements exist. The ACM still once in a while claims copyright on ancient Fortran code from the late 1960's. Back then it was a blissful golden era when people didn't even think that source code was elligible for copyright.
Given the pocket calculator joke[1] I'm wondering if anyone has built functionally equivalent AGC code on a more modern processor? And by functionally equivalent I mean a black box tester with an Apollo AGC would not be able to tell if it was running the old code or the new code.
[1] "It’s been famously remarked that the on-board systems in Apollo 11 had less computing power than a modern pocket calculator." -- http://apcmag.com/apollo-11-code-goes-open-source.htm
Yes it's a 2009 blog post, but I still found it new and interesting.
Especially the "# TEMPORARY, I HOPE HOPE HOPE" comments, so I decided to look into them and hopefully find someone who has a clue to explain...which I did, here's a link for anyone else interested...
(last comment) http://www.metafilter.com/83450/Apollo-11-Source-Code
"July 23, 2009"
Misleading indeed but is not like realeasing the latest kernel patch, where the code date is important.
Trashy Little Subroutines is going to be my new band's name.
https://code.google.com/p/virtualagc/source/browse/trunk/Lum...
So they must have written this simulator without help from source code http://svtsim.com/moonjs/agc.html. While it doesn't strike me as a bad simulator, I wonder if it's right.
If anyone compiles this; remember to set your turbo button to off or the timings will be wildly inaccurate.
Weird... ISTR hearing something like this a long time ago.
Edit: Nevermind, just saw the date on the article.
NASA open source Apollo 11 code...5 years ago. How about a (2009) guy?
Google Code? That still a thing? It must be enterprise-government-class contracts like this keeping it alive.
It would have been much cooler to see it on Github and people forking away at it.
Time to start my own backyard space program.
please add 2009 to the end of the title