Apollo 11 Guidance Computer source code
github.com
github.com
Further, I believe that the suggested fix is incorrect, or at least insufficient. The Apollo 13 investigation indicated that a list of factors led to the fan wires in the O2 tanks having damaged insulation. However, unless the wires were already short-circuited before stirring, checking continuity first would not have detected the short. Indeed, the tank was stirred twice earlier in the mission without incident. The investigation suggested that operating the fans itself may have eventually moved the wires into contact with each other, which combined with the damaged insulation, finally allowed an electrical arc and the resulting explosion to occur.
The correct fix is to upgrade the thermostatic switches which protect the tank heaters from overheating to accommodate 65 V DC, so that the fan wiring isn't damaged in the first place. In addition, the tank acceptance procedure should be amended to require switch cycling under load.
Source: http://history.nasa.gov/SP-4029/Apollo_13a_Summary.htm
https://www.youtube.com/watch?v=k_OD2V6fMLQ
During the landing, you'll here mention of 1201 and 1202 alarms. Here's what that's about:
http://www.hq.nasa.gov/office/pao/History/alsj/a11/a11.1201-...
Here's 1201 being called:
https://github.com/chrislgarry/Apollo-11/blob/dc4ea6735c4646...
And 1202:
https://github.com/chrislgarry/Apollo-11/blob/dc4ea6735c4646...
Another tidbit. Toward the end you hear mission control say "30 seconds." That's how much fuel is left[1]. Those guys had steel spines.
If you can't get enough of this stuff, I highly recommend "A Man on the Moon" by Andrew Chaikin[2], as well as the HBO mini-series produced by Tom Hanks and based largely on that book, "From the Earth to the Moon"[3]. "Failure Is Not an Option" by Gene Kranz[4] (flight director on Apollo 11 and 13, among other things) is also a good read.
[1] http://www.nasa.gov/mission_pages/apollo/apollo11_audio.html
[2] https://www.amazon.com/Man-Moon-Voyages-Apollo-Astronauts/dp...
[3] https://www.amazon.com/Earth-Moon-Four-Disc-Collectors/dp/07...
[4] https://www.amazon.com/Failure-Not-Option-Mission-Control/dp...
https://www.youtube.com/watch?v=jfj2jqpst_Q&feature=youtu.be...
https://www.theguardian.com/science/2009/jul/16/moon-landing...
I think this one is my favorite module: https://github.com/chrislgarry/Apollo-11/blob/master/THE_LUN...
CAF CODE500 # ASTRONAUT: PLEASE CRANK THE
TC BANKCALL # SILLY THING AROUND
CADR GOPERF1
TCF GOTOP00H # TERMINATE
TCF P63SPOT3 # PROCEED SEE IF HE'S LYING
TC BANKCALL # ENTER INITIALIZE LANDING RADAR
CADR SETPOS1
TC POSTJUMP # OFF TO SEE THE WIZARD ...
CADR BURNBABY## At the get-together of the AGC developers celebrating the 40th anniversary ## of the first moonwalk, Don Eyles (one of the authors of this routine along ## with Peter Adler) has related to us a little interesting history behind the ## naming of the routine.<br> ## <br> ## It traces back to 1965 and the Los Angeles riots, and was inspired ## by disc jockey extraordinaire and radio station owner Magnificent Montague. ## Magnificent Montague used the phrase "Burn, baby! BURN!" when spinning the ## hottest new records. Magnificent Montague was the charismatic voice of ## soul music in Chicago, New York, and Los Angeles from the mid-1950s to ## the mid-1960s.
[1] https://github.com/chrislgarry/Apollo-11/blob/dc4ea6735c4646...
> # THE MASTER IGNITION ROUTINE WAS CONCEIVED AND EXECUTED, AND (NOTA BENE) IS MAINTAINED BY ADLER AND EYLES.
I had to look this up, NOTA BENE is latin for,
observe carefully or take special notice[EDIT] On second thought "HONI SOIT QUI MAL Y PENSE" would be much better ("Shame on whosoever would think badly of it")
Don Eyles Walks Us Through the Lunar Module Source Code
http://hackaday.com/2016/07/05/don-eyles-walks-us-through-th...
> At MET 102:39:31 the best possible confidence builder occurred — throttle down, right on time. "Ah! Throttle down... better than the simulator" commented Aldrin, "Throttle down on time!" exclaimed Armstrong, their excitement palpable. In the official transcript of communications between spacecraft and ground during the powered descent, these are the only exclamation points[11].
goosebumps.
> # Assemble revision 001 of AGC program LMY99 by NASA 2021112-61 > # 16:27 JULY 14, 1969
Likely the printing date but I envisioned the last minute all-nighters right away.
159: BURNBABY
169: B*RNB*B*There's a mod for Kerbal Space Program which gives it real solar system planets and dimensions. (KSP's world is way undersized so things happen faster.)[2]
There's another mod for Kerbal Space Program to give it real dynamics.[3] (KSP doesn't really do dynamics right; the spacecraft is under the gravitational influence of only one body at a time. This is why there's that sudden trajectory change upon Mun capture.)
Someone should hook all that together and do a moon landing in simulation.
[1] http://svtsim.com/moonjs/agc.html [2] https://www.reddit.com/r/KerbalSpaceProgram/comments/1piaqi/... [3] http://forum.kerbalspaceprogram.com/index.php?/topic/62205-w...
TC BANKCALL # TEMPORARY, I HOPE HOPE HOPE
CADR STOPRATE # TEMPORARY, I HOPE HOPE HOPE
TC DOWNFLAG # PERMIT X-AXIS OVERRIDE
https://github.com/chrislgarry/Apollo-11/blob/master/LUNAR_L... GAINBRAK,1 # NUMERO MYSTERIOSO
https://github.com/chrislgarry/Apollo-11/blob/master/LUNAR_L...(A friend of mine, who when in search of a new go-to-programming language instead of Python, was more interested in Swift vs Rust because of this attitude).
This is akin to not liking something because you don't like the people who already like it, despite how much you'd like it otherwise.
Thanks for mentioning this, I certainly will the next time. The last time this came up, this was not an attitude I had previously noticed, although did see a bunch on Hacker News the following week
> This is akin to not liking something because you don't like the people who already like it, despite how much you'd like it otherwise.
I would totally agree with this, but at the same time, while not a technical reason, if one works in primarily a single programming language I can imagine the nature of the community would be a legitimate factor to consider---in this case though as you point out, it would be an inaccurate opinion of the nature of the Rust community.
To your last point, I agree slightly as well but my rebuttal would be that each person chooses how much and at what level to participate in a community they are in and which sub-communities they identify closer with.
I can imagine a person being proficient and working in any language without the need for them to be involved with the community at all, or if they do need to interact do so in a read-only matter.
As I could see from the way my score, on the post that started this discussion fluctuated, this is clearly a topic some are both sensitive about or like find humor in (or both!).
EDIT: I didn't mean to derail the discussion of a fascinating code posting; but I assume the comment I responded to that spawned this tangent, "Have they considered rewriting it in rust?"[3], was a joke made about the other comments on HN to rewrite things in Rust.
[1]: From a pedagogical standpoint, obviously this is a potentially good way of learning a language so if for learning and not pure calorie burn I personally don't see this as wasteful.
[2]: <<possibly exaggeration warning>> I understand there is some motivations within (perhaps a small part) the Rust community to replace the world'S C-systems-code with more secure Rust code.
CA A # SHOULD NEVER HIT THIS LOCATION
The 1969 version of "This should never happen".https://github.com/chrislgarry/Apollo-11/blob/dc4ea6735c4646...
FWIW, I did performance analysis of the guidance computer and the 1202 and 1201 alarms at the start of my ACM Applicative 2016 keynote: https://youtu.be/eO94l0aGLCA?t=4m38s
What are these Dummy Jobs ? And Why did they have to do this instead of just leaving the CPU idle ?
This would require a CPU that was designed to idle.
1. If interrupts not masked, check for interrupt
2. Load instruction
3. Advance instruction pointer
4. Execute instruction
It doesn't ever stop - as soon as the current instruction is finished executing it moves on to the next one. So, if you don't have anything better for the CPU to do, you need to have it spin in a loop of instructions anyway.More modern CPU designs typically include an instruction that means "halt until next interrupt" which actually stops the CPU from fetching and executing instructions.
In your last statement I could see it making sense where the CPU actually halts, but did prior CPUs always run at about the same temperature? Or do these idle processes throw fewer instructions at one time so it's not as overwhelmed?
Basically, yes. But then they typically produced so little heat they had passive heatsinks, up to and including the Pentium II (~20 W TDP) and ATI Rage 128 that I used back in '99.
Is that what made it difficult for us to design processors capable of "idling" ? (ie) completely new hardware design
It's important to realise that there was no good reason to have the ability to stop the CPU in those days - power consumption by the CPU itself was truly trivial compared to the memory and peripherals it was attached to, and those CPUs weren't really damaged or worn out by running continuously. Having the CPU spin in software when there was nothing else to do was perfectly fine.
I want to just leave comments like this and have users be responsible for avoiding said chaos.
It would be fun to do some research into the embedding of higher-level virtual machines in earlier computers. I'm thinking of 'The Interpreter' in the AGC as being an ancestor to 'SWEET16' in the Apple II (https://en.wikipedia.org/wiki/SWEET16), or the 'Graphic Programming Language' (http://www.unige.ch/medecine/nouspikel/ti99/gpl.htm) in the TI-99/4A.
The Apollo Guidance Computer (AGC) was a digital computer produced for the Apollo program that was installed on board each Apollo Command Module (CM) and Lunar Module (LM). The AGC provided computation and electronic interfaces for guidance, navigation, and control of the spacecraft. The AGC had a 16-bit word length, with 15 data bits and one parity bit. Most of the software on the AGC was stored in a special read only memory known as core rope memory, fashioned by weaving wires through magnetic cores, though a small amount of read-write core memory was provided.
Even setting that aside, what is it I'm looking at? Assembly?
It's derived from Ron Burkey's unmaintained Virtual AGC at http://www.ibiblio.org/apollo/, which also hosts many of the manuals and related documents.
But if you really want to be cool, you could build a real AGC from scratch: http://klabs.org/history/build_agc/
I feel like the source is likely clearer than that interface...
AGC Assembly. Here's the manual: http://www.ibiblio.org/apollo/assembly_language_manual.html
I wonder whether there's any way of getting it into one of the autopilots for Kerbal Space Program.
Notably, it includes some unmanned auto-running missions, and some fictional missions, including a hypothetical manned flyby of Venus using the AGC.
Ref: http://www.doneyles.com/LM/Tales.html
Amazing!
These last 3 are software QA.
I had to write down the drivers, and display library for the 128 x 64 lcd display with a simple scheduler, FSM and all!(Hard to mention all the work) Bulk of the work I did was using paper, eraser and pens.
A lot of work in unchartered territory requires paper work. I realized the more I worked on paper the more correct the code was and overall it took faster to write(given fewer bugs).
http://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/
https://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist)
Also was among first to invent scheme that automated the coding and testing from specs for high-reliability. Her case is the only one I follow as I lack data on the rest.
The other recurring theme in the book is the disturbingly short MTTF for flight computers during the mid 1960s. Statistically, NASA had to plan for a computer failure in route to the moon, and so repair-vs-replace became a serious issue. (Yeah, they seriously considered soldering in zero-g.)
For instance, the type of memory was called core rope memory https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
For anyone interested, XPrize winner Karsten Becker talks to popular youtube blogger David Jones about radiation, extreme heat & cold in space and specifically talks about bit flip and how electronic parts are sourced for such endeavors.
https://www.youtube.com/watch?v=7JwNmdV2QPs
Interesting to me was the "paper work" cited in the interview for space harden components. In other words, people are concerned with stuff falling back to Earth (wouldn't it burn up?) or used for not so friendly purposes (war).
Rope and core memory were the standard memory technologies of the day and very likely have not been chosed for they radiation hardness. The fact is, solid state memory became reliable and available in quantities only in the second half of the 1970-ies.
https://github.com/chrislgarry/Apollo-11/blob/master/BURN_BA...
16-bit wordlength
2048 words of RAM (4k 'bytes'/octets) using magnets?!
36,864 words of ROM
Ok this is a actually a really interesting read: https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
PINBALL_GAME_BUTTONS_AND_LIGHTS.s
"A set of interrupt-driven user interface routines called Pinball provided keyboard and display services for the jobs and tasks running on the AGC. A rich set of user-accessible routines were provided to let the operator (astronaut) display the contents of various memory locations in octal or decimal in groups of 1, 2, or 3 registers at a time. Monitor routines were provided so the operator could initiate a task to periodically redisplay the contents of certain memory locations. Jobs could be initiated. The Pinball routines performed the (very rough) equivalent of the UNIX shell." - https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...
And that demo got us to the moon.
"Apparently, nobody had yet arrived at any kind of software requirements for the AGC's user interface when the desire arose within the Instrumentation Laboratory to set up a demo guidance-computer unit with which to impress visitors to the lab. Of course, this demo would have to do something, if it was going to be at all impressive, and to do something it would need some software. In short order, some of the coders threw together a demo program, inventing and using the verb/noun user-interface concept, but without any idea that the verb/noun concept would somehow survive into the flight software. 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."
Remember also that memory was at a terrific premium. I don't have any specific knowledge about the AGC, but there's an interesting story I read once about a memory shortage in another project - Intel's 8080.
(If you'll permit me an OT digression...)
As the story goes, the program space was so tight in the original microcode for the Intel 8080 microprocessor there wasn't room to spare for a one-byte constant in the code! The architects decided that the AAM and AAD instructions in the 8080 set should have a required operand - 0x0A or 10 - so that the instruction could refer to itself and know that you were operating in base 10!
A side effect of this is that the Intel processors could actually execute AAM and AAD instructions in number bases besides 10; Intel had never formally acknowledged that the instructions do this, and so in the NEC V20 or V30 chips - which were supposed to be Intel compatible - you couldn't change the AAM or AAD operand - it had to be 0x0A.
> Is there any reason why they didn't develop one?
“Now you have two problems.”Edit: OK, maybe that deserves explanation. First, an optimizing compiler is a much bigger project than the AGC code. Second, current optimization techniques didn't exist in 1969, even assuming NASA had enough budget for machine(s) to run them. Third, you need to verify the binary anyway, and small source changes (in either the guidance code or the compiler) can lead to large binary changes.
Even today, certain ridiculously-high-performance or super low latency tasks (i.e. embedded devices, high frequency trading) drop down to the assembly level because that small bit of overhead the compiler adds (for such modern coddling conveniences as function calls and type safety) are just too much. It's not crazy, it's just what's needed for that particular job.
With things done this way and documented this why they could (fairly sure did) have the pages printed out on paper and such. And if say there was some bug or new routine that needed to be added mid flight they could go to a key board input (no screen) and with the instructions from the ground reprogram a section or add a new jump point or change a value mid flight.
Remember, computers were not what they are today. They did not have super powerful laptops and such with fancy tools.
The AGC code was stored in ROM. Notably a specific kind of ROM called "rope memory".
Seams you were mostly right about not being able to change it. I was only somewhat right because I assumed it would all be editable. I over estimated the technology they had back then. I would gather from that there was for more fixed code than editable.
Source: https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
Ah, yes right, there was something. I've been fascinated by the AGC by some time¹, yet I completely forget about that. Time to hunt down the mission protocols to understand what this patch did.
------
1: … and the LVDC, which is the computer that controlled the Saturn-V. Because it was based on the computers used in ICBMs still a lot of information about that is classified. A lot of people conjectured that it was a IBM System 360 reshaped, but when actual LVDS board got torn down by electronics nerds over the past couple of years some significant differences to the 360 were discovered.
Specially in these CISC processors.
I've often wondered many things about the cleanliness, maintainability and style of such code (this particular system, in fact). It's fun to be able to actually poke through it.
It's an incredibly well done and at times hilarious narration of the moon mission. (Spoiler: contains a part where Armstrong overrides the automatic control and lands manually)
This is probably my favorite presentation ever.
http://klabs.org/history/ech/agc_schematics/
The CPU is built entirely from 3-input NOR gates.
Edit: .s files indicate:
# Copyright: Public domain.
"This source code has been transcribed or otherwise adapted from digitized images of a hardcopy from the MIT Museum. The digitization was performed by Paul Fjeld, and arranged for by Deborah Douglas of the Museum. Many thanks to both. The images (with suitable reduction in storage size and consequent reduction in image quality as well) are available online at www.ibiblio.org/apollo. "
I mean, I realise that this is the least of the amazing achievements we're talking about here, but yea.. respect :)