Understanding the Apollo Guidance Computer

This year marks the 50th anniversary of three important events in computing. The first of these is the July 1969 landing of Apollo 11 on the moon, the first time human beings landed and walked on another celestial body. This would not have been possible without a large number of computer design and software development techniques that were created for it. Second, 1969 was the year that the ARPAnet first went into operation. Yes, the Internet is basically 50 years old. The third major computing event in 1969 was the beginning of the development of the UNIX operating system. The operating system you’ve been using on tux has its roots in software that Ken Thompson wrote at Bell Labs in 1969.

Your first project assignment is to write a technical paper about some aspect of one of these three events/systems. You are writing for a technical audience, so the paper should not read like a newspaper article or a popular magazine article. It should read like ******an industry technical report or a scientific conference or journal paper. Not only can you choose which of the three interests you the most, but there are dozens of topics within each that you can choose from. The exact topic and focus of your paper is up to you, but the paper must contain substantial technical content. Some of the possible angles you might take include:

1. Explain how the Apollo Guidance Computer (AGC) was designed and how it worked. There are some quite interesting aspects of the design that connect to our study of Boolean Algebra. The types of memory used on the machine were quite interesting. There’s a lot that can be learned digging into the detail at that level.

2. Explain how the ARPAnet Interface Message Processors (IMPs) worked.

3. What technical limitations were present in the PDP-7 that Thompson first started writing UNIX on?
4. Explain the software written for the AGC. There are quite a few interesting techniques that were used to squeeze the functionality needed to fly to the moon into the limited amount of memory. How did they do that? How did the operating system work? How did they handle all the mathematics of flight?

5. Discuss the design of the software that ran on the IMPs.

6. How did Thompson’s original experiments on the PDP-7 evolve into an operating system.

7. Discuss one of the individuals involved in the design and programming of the AGC. Keep in mind that your audience won’t find something purely biographical to be interesting. You need to get into what that person’s technical contriburions were. What drove them? Why were the interested in working on this project? You should include enough technical background on what they did to make their contribution clear and enough detail on what they did to satisfy the curiosity of a technical reader.

8. Focus on one of the dramatic events that occurred during a flight. There were repeated alarms during the descent to the moon on Apollo 11. What’s the story behind those? What was happening in the hardware and software that led to those alarms? What did they do about them? There was what amounted to an in-flight bug fix on Apollo 14. What’s the story behind that? Who figured out the hack and how to deploy it?

9. What led to the migration from the original ARPAnet protocols to the TCP/IP protocols we use today?
10. What was involved in the migration of UNIX from the PDP-7 to the PDP-11 and then to other hardware platforms?

This is by no means an exhaustive list of possible topics. This is just a short list of possibilities to give you some idea of the kind of paper you might want to write. The topic you choose should be driven by what you find so interesting that it makes you want to dig deeper and find out more.

The above is the assignment. However, most of you have never written a technical paper like this. So the rest of this discussion gives you considerations that can help you understand how to approach writing a technical paper. Some of what follows is written assuming you pick the Apollo Guidance Computer as your main focus, but similar considerations apply to the ARPAnet and to UNIX. Start by reading as much as you can on whichever of the three you choose. Then pick something about it that particularly interests you and decide what you want to tell people about it. Remember, the reason you write is to tell people about something that you understand but they don’t. It can be helpful to write out some questions that relate to the specific thing that you want to say. For example, here are some sufficiently technical questions about the AGC.

1. How does the instruction set of the AGC compare to that of the CARDIAC?
2. How many bits or digits does the AGC use in memory and in computations? How big is the memory?
3. What are the registers in the AGC?
4. How does the AGC represent negative numbers?
5. Where does floating point fit into the AGC?
6. Did the AGC run and operating system? How did it work?
7. Did the programmers work in assembly language or in a high-level language?
8. How did the astronauts interact with the AGC?
9. What I/O devices were interfaced to the AGC?

These guidelines will also hopefully be helpful:

1. Students always want to ask, “How long does it have to be?” and never seem satisfied when we answer “As long as it needs to be.” So I’ll walk you though how to think about it. The nine questions listed above should give you a sense of the scope of your paper. If you average one to two paragraphs for each, add an introduction and conclusion, you’ll probably end up with about three to five pages of actual text. Of course, all the “tricks” to make it look longer (big fonts, big margins, double spacing, etc) don’t make the paper any better; they just kill trees. Indeed, outside of lawyers, I don’t ever see anyone using double spacing anymore. Similarly, my most recent writing has been expressed in terms of the number of words, rather than the number of pages. Don’t get carried away thinking “longer is better.” There are currently over 320 students registered for this course. If each one turns in a 10 page paper, that would be 3200 pages for me and the TAs to read. Unnecessary verbosity is not going to improve our mood while grading. To accomplish both the inclusion of substantial technical detail and keeping the size small, make sure you spend your word budget carefully. Avoid filler verbage that doesn’t really say anything.

2. Don’t approach this paper as one where you just repeat facts you find somewhere else. The way to approach this kind of paper is to study the subject at hand (the AGC, the ARPAnet, or UNIX in this case) until you’ve learned something interesting about it. Then the purpose of the paper is to explain that something interesting to others. Don’t start writing until you find yourself telling someone how cool this thing was. This means that you need to start looking at this assignment early. That’s why I’ve made this assignment available three weeks before the due date.

3. Along similar lines, you want to approach this paper the way you would a scientific paper. This is not a newspaper article or article for a popular magazine. In the course of your study to find what to write about, you should read some academic papers on the subject. They should give you a sense of the style of such papers. If this isn’t clear or you’re not sure how an academic paper is written, feel free to talk to the professor or TAs.

4. The paper must be submitted in PDF. I strongly recommend that you spend a little time learning the typesetting system TeX and it’s commonly used macro package LaTeX. (You’ll find that LaTeX has a similar structural feel to HTML.) It will seem a little difficult to learn at first, but it will make your life much easier in the long run when it comes to producing consistent section formatting, acceptable equation formatting, tables, etc. Fighting with a word processor to make equations look better than a 3-year old would draw is no fun at all.

5. You must cite your sources. Failure to do so is plagiarism. Every historical statistic, quotation, graph, etc must have a citation. I don’t particularly care what citation format you use; feel free to use whatever you’ve been taught elsewhere. I would think that you’ll almost certainly need to look at somewhere around 5 to 10 sources to get a really good understanding of the system. Seeing papers with hundreds of citations always raises questions in my mind as to what exactly did the writers get from each one. On the other hand, if you only have 2 or 3 references, then I have to wonder if you understand it to any depth.

6. Wikipedia is not, itself, a reputable source. Any information there that is useful is also cited as originally coming from somewhere else. So in your researching for this paper, if you find something that looks useful on Wikipedia (or other blog/wiki online resources) go to the original sources, determine if they were accurately followed and base your work on them.

7. Good old fashioned books can be reasonable sources. Not everything of interest is found online. In fact, there are several very good books on all of these topics. Yes, they include useful information not found online, but no, I’m not loaning out my copies.

8. At the other extreme, copies of all the AGC schematics and source code are available online, as are early versions of the UNIX source code. Feel free to refer to them.

9. Do not cut and paste from your sources. To let you in on a little secret, we often have a good laugh when we read papers where students have done this. Of course, the laughing stops when we have to deal with the plagiarism. With the exception of short quotes clearly identified as such, it should be all your own words.

10. The objective is not to answer a list of questions exactly. Instead, the list is meant to give you a sense of the scope that you need to cover. You should come up with a similar set of questions for the topic you choose and be sure to answer them in your paper.

11. It’s hard to imagine a useful paper with significant technical content that isn’t organized in sections and subsections. Similarly, if you don’t have any math in your paper, you should really ask whether you’re actually saying anything interesting.

12. Finally, it’s true this isn’t an English class, so we won’t be grading grammar, spelling, etc specifically. However, we will be grading the content of your paper. If your punctuation, spelling, grammar, etc detract from the content of your paper, your grade will reflect it.