originated

Document categories

AGC-related presentations

Various presentations presented at the MAPLD '04 conference, by AGC developers and other knowledgeable folks



Hugh Blair-Smith, "YUL System - Pass 0": video

Ray Alonso, "Evolutionary Dead Ends": video and text

Eldon Hall, "Historic Disassembly of a Block II Apollo Guidance Computer": video

Cline Frasier, "Digital Autopilot for Apollo: A Radical Change": video and text



Jose Portillo Lugo, "Lunar Module Attitude Controller Assembly Input Processing": text

Also, various still photos related to these folks and their presentations: gallery



AGC software manuals and listings

AGC Users' Guides

This section pertains to a document (E-2448) called "Users' Guide to Apollo GN&CS Major Modes and Routines", presented in several different revisions. While the document itself purports to be general purpose in nature rather than mission-specific, it was nevertheless maintained to remain current, and therefore can be roughly matched (from publication dates and internal information) particularly-relevant missions.



Guidance System Operations Plans (GSOP)

AGC quick-reference cards or data cards

AGC pad loads

Other sources referencing the erasable loads include:



Digital simulations, such as this one for Apollo 17, which include the pad-load data needed for the simulation (though not necessarily identical to what was needed for the actual mission).

Operational data books



AGC Erasable Memory Programs (EMPs)

TBD



AGC Electrical and Mechanical design

The principal references for AGC electrical schematics and mechanical drawings on this website are now the following two pages:



The Electro-Mechanical page, in which the electrical-schematic drawings relevant to specific Block I/II AGC/DSKY models are referenced.

The MIT/IL Engineering Drawing page, in which all of the electrical and mechanical drawings to which we have access are indexed, irrespective of how they interrelate.



See also: System Handbooks and the other AC/Delco documents in the "Miscellaneous" section below.



AGC Information Series

"Published to inform members of the technical staff at MIT and Raytheon about the AGC and the Apollo G & N system", apparently with emphasis on the electronics.



Space Guidance Analysis (SGA) memos

If you are interested in the mathematical underpinnings of the AGC software, then this amazing series of memos from MIT's Instrumentation Lab is the place to look. The memos are in roughly chronological order. It is very interesting to reflect on the fact that these mathematical memos are often written by the very same people whose names you find as authors in the software. The AGC software was written in a time ... or at least a place ... where software was regarded as the expression of mathematical knowledge as opposed to being a mere exercise in the expert employment of programming languages and tools as it is today. It is interesting also to reflect on the nature of the software this approach produced.



Digital Development Memos

These memos primarily relate to the electrical design of the AGC.



LUMINARY Memos, Anomalies, PCRs, and PCNs



COLOSSUS Memos

SKYLARK Memos, PCRs, and PCNs



SKYLARK, if you'll recall, is the AGC software that replaced COLOSSUS (and was adapted from it) in the command modules used for the Apollo-Skylab and Apollo-Soyuz missions. We have the text of a few of the Program Change Requests (PCRs), though unfortunately as of yet, none of the Program Change Notices (PCNs), and just one of the Memos. The table of PCRs and PCNs below mostly comes from Appendix A of Section 2 of the SKYLARK GSOP. (Even so, the GSOP does not list all PCRs and PCNs, and is only current through March 1972.)

It's interesting to note that many of the changes listed in the PCRs are simply deletions of lunar code that would be unnecessary for a CM-to-Skylab mission. I think that a "normal" software-developer perspective on this would be that deletion of the working code, even if the code itself is unnecessary, represents more of a risk in terms of creating undetected breakage than simply leaving the code in place and not using it would be. However, in working with higher-reliability code — disclaimer: my only familiarity with such matters is in working with airborne code in the U.S., which is currently governed by a document called RTCA DO-178C, and thus I don't really know what they thought about it in 1970 in the space biz — there is a concept of "dead code", i.e., code that is never executed under the software requirements, and specifically never tested; the dead code must be completely removed from software beyond the absolute lowest level of criticality. The theory behind this is that if somehow that dead code actually did manage to be executed for some reason, then the result would be bad. I imagine that's the theory behind the removal in SKYLARK as well: i.e., the risk of executing bad code is worse than the risk of undetected breakage. On the other hand, I suppose the removal could be just a matter of trying to reduce the cost, by physically removing a handful of ferrite memory cores and their associated wiring. I wonder what the actual cost tradeoff would have been between lifting those cores into space vs all of the development and testing time associated with the removal?



SCB Meeting Notes

The Software Control Board (or perhaps Software Change Board, or perhaps Software Configuration Board, or even Software Configuration Control Board ... I'm not really sure, but does it really make a difference?) meetings were meetings held between the MIT Instrumentation Lab and the Manned Spacecraft Center, and I presume other parties as needed, to approve or disapprove PCRs (Program Change Requests) and PCNs (Program Change Notices), as well as to report the closure of such items. As such, they can serve (for our purposes) to fill in gaps in LUMINARY Memo or COLOSSUS Memo series in order to track AGC revision-to-revision changes. We don't have many of these, but Don Eyles has given us a few in order to help understand some of the changes in Luminary 131 for Apollo 13 that weren't tracked by the LUMINARY Memos.



Miscellaneous AGC/DSKY Problems and Changes

Various sections above cover problem and change reports for a variety of specific areas of implementation or responsibility (LUMINARY, SKYLARK, SCB resolution, etc.). Reports that don't obviously fit into any of those areas of specification are collected in this section.



AGC/DSKY Inventory

In this section, we collect documents whose primary interest for us is that they discuss the disposition of specific AGC/DSKY units, and/or refer to them or their constituent modules specifically in terms of their part numbers and serial numbers. In other words, anything that allows us to discuss what AGC/DSKY units or their constituent parts (like software) were used for what purposes. There are other documents which also contain such information but which were cataloged before this specific category of documents was invented, so it may take a while before all such information is linked here.



Apollo Experience Reports

Miscellaneous Guidance & Navigation

These items are alphabetical by author, though the "author" is sometimes an organization when no individual authors are listed.



The document was prepared while I was working for Al Hopkins and Ray Alonso at the Instrumentation Laboratory and describes the analysis of the crux of a proposed backup system if the AGC became overloaded during the LEM trajectory. Although the backup method described was never used, the document shows the type of analysis that went on "behind the scenes" in support of the entire mission.



Miscellaneous Microformed Documents

Note: The document scans listed in this section are now obsolete for most practical purposes, because far better scans of the documents have since been provided. Simply use the engineering-drawing search engine to find the "good" scans for most of them. (Document MH01-01380-216 is not in the search engine, but can be found by rummaging through the unindexed scans of North American Aviation Interface Revision Notices.) The material in this section (specifically, the inferior scans) has been retained anyway, but should be regarded as a last resort for trying to resolve legibility problems. I have not changed the explanations accompanying the document links below, even though they do not fully reflect the current situation. The explanations, however, do contain valuable information about how to interpret the "good" scans as well as the "bad" ones. Besides the documents listed in this section, many other documents of a similar nature exist among the engineering-drawing scans, principally though not exclusively in "aperture card" Box 431, Box 433, Box 434, Box 435, and Box 436. You are invited to browse the indices of those boxes and index-pages of all other aperture-card boxes for documents of interest that don't appear elsewhere in this document-library page. However, your searches for such documents will generally be assisted greatly by knowing the desired document number.



This is an unusual section, in that it categorizes documents according where they came from and the technique used to digitize them, rather than the contents of the documents as such. They are collected here, with an apology (in the old sense of the term) that I'm giving once (here!) because I don't care to repeat it over and over again.

In brief, a number of documents were encountered at NARA Southwest that had been converted to "microform" that were deemed significant enough to reproduce for you, but for which I personally have chosen an inferior method of digitization, due to limitations of time and money. I will say that it's better having these scans than not, in lieu of having better ones, but there's no doubt that their quality is shockingly poor. They are mostly, but not entirely, legible. With effort. Perhaps it's worth noting that all of the scans in this section are expected to be replaced by much, much higher-quality scans, probably before the end of 2021.

A fuller explanation of these microform "aperture cards" can be found on our "Documentation Quest!" page, but as a brief example, imagine a 400-page document on aperture cards. At current prices, NARA would be willing to digitize it for you for $1600, or you could go to the facility personally and make a relatively high-quality scan using NARA's equipment for about $160 (plus 12 hours of your own time), or you could go there and make a low-quality scan for free with your own flatbed scanner for $0 (plus 3 hours of your own time). Now, I have scanned many, many engineering drawings from NARA aperture cards using the mid-price option, because it's reasonably cost-effective to do so, and you can see those on the MIT/IL engineering-drawing index page. But for longer documents, for obvious reasons, I chose the free option.

Aperture cards hold photographic negatives, and the document scans I've made from them are presented as-is. I.e., as negatives. They could be easily converted to positives and post-processed with brightness and contrast adjustments that would make them easier to read, but I've chosen not to do so in most cases, because I preferred to get the scans into public view rather than hold onto them for however long it would take to work out the perfect post-processing for them. Plus, most such post-processing results in image rot that I prefer not to incur at this stage. The fact that I've not done this post-processing means that these scans will be perceived as being of even lower quality than they actually are. Perhaps you can figure out the perfect adjustments for me, and let me know how to do it the best way! But there are also true quality issues, in which portions of some scans appear blurry and out of focus, which I presently don't understand. Perhaps some pages will require rescanning in the future for legibility reasons.

Another fun feature of these documents is that rather than containing a nice, contiguous sequence of pages, we instead provide all (or all available) revisions of the document, one after the other: rev "-", followed by rev "A", followed by rev "B", and so on. Consequently, the sequence of pages will often have holes and duplications, though hopefully one could form a complete final-revision document from all of the pages if one were so inclined. If you are so inclined, I'd be happy to accept such a version from you.

Finally, since these documents are being provided only in their "raw" form, I've not attempted to turn them into nice, tidy PDFs, so at the moment, you can see these scans only in their raw forms at our Internet Archive site.

All right, enough of the apology! Here, finally, is a list of the actual documents:



Abort Guidance System (AGS) and its computer (AEA)



Launch Vehicle Digital Computer (LVDC) and other Saturn-related computing material



We have precious little LVDC documentation of any kind, and no LVDC software at all. The Wikipedia article on the LVDC laments that all of the LVDC software has probably vanished and does not exist any longer. Well, I don't believe that. They're smart enough to send a man to the moon, but too stupid to put the documents in a file cabinet afterward? I hope not!



One person intimately connected with the software at an IBM managerial level explained it thusly, chiding me for looking for the software at all. In the first place, he said, the software was classified, so it would have been destroyed immediately after use, and couldn't possible exist any longer. (Really? No bugfixes? No reuse from mission to mission? No possibility at all of NASA ever wanting more Saturn V's in the future? Not the slightest sample, however short, of any LVDC code at all surviving?) Besides, he said, the software would be of no use to anyone at all, since the LVDC depended intimately on the Instrumentation Unit's separate Analog Computer, and without the Analog Computer, the LVDC couldn't do anything. (Really? Then if it was of no conceivable use at all, then why was it classified? Worry over someone independently building a Saturn V in their backyard, complete with an LVDC and an Analog Computer?) Of course, I could just be indulging in wishful thinking: the criticisms may all be correct, whatever my evaluation of them — and the fact that we haven't been able to find any software so far is certainly indirect evidence of that — but it isn't convincing enough to me to cause me to stop looking for the material. I prefer to hope that there's some former LVDC developer somewhere who was proud enough of his work to retain at least a few souvenirs. There's a good alternative explanation of our trouble in finding LVDC software, relative to the "ease" (ha!) of finding AGC (or even AGS) software, and that's simply that the statistical universe of LVDC developers is much smaller than that of AGC developers, and I've never been able to actually find one of them yet. If you know any such LVDC developers, please help us to get in contact with them.



As the title of this section implies, most of the material here is LVDC-related, but some of it is not necessarily about the LVDC specifically. Unfortunately, I haven't really thought of any good way to put this stuff into a useful order or hierarchy, so it's basically just randomly ordered at the moment.



Systems Handbooks

See also: AGC Electrical Schematics.



Operations Handbooks

Operational Data Books

Technical Crew Debriefings

Mission Reports

Flight Plans

Checklists

Familiarization Manuals

Launch Vehicle Flight Evaluation Reports

These documents relate primarily to the Saturn rockets, but one notable feature is that chapter 2 of each document provides a detailed mission timeline for events insofar as they relate to the various stages of the rockets.



Miscellaneous Mission Documents

Note that this section doesn't include things like GSOP documents, Operational Databooks, etc., which have their own sections above, but is simply a catch-all for everything I haven't already listed that's mission specific or specific to a mission class.



Max Faget was a fanatical advocate of the optical tracker as the primary rendezvous navigation sensor. If he had had his way there would have been no rendezvous radar. This was an undocumented chapter in the Apollo program known to those of us who participated as the Rendezvous Wars. Under our tutelage, supported by extensive in-house Monte-Carlo analyses, the Astronaut Office took an uncompromising position on behalf of the radar as the primary rendezvous navigation system.



The wars continued into the Shuttle program, and were lost by our side because the FOD was able to make the case that they could support all rendezvous operations with ground-based tracking, and there was therefore no argument for autonomous on-board capability. Max got his way on the Shuttle, there was no rendezvous radar. By that time I was back in Houston working for a small company under contract to MPAD for orbital operations analysis. I got fired for refusing to lie to Draper about the availability of reference mission data to support some independent analysis they were doing for my former colleagues in SED. Thus ended my involvement in the wars, and I've always treasured those memories.



This document contains nomographs for computing the TPI and M/C maneuvers using LM boresight elevation angle measurements, and raw rendezvous radar data from the tape-meter readout. During the months prior to Apollo 11, I was able to use the GN&C analysis program in Monte-Carlo mode to construct computation tables for the CDH and CSI burns. This was done by perturbing the trajectory about the nominal, and developing power-series expansion functions for the maneuvers in terms of the resulting radar range and range-rate perturbations, obtained from measurements at fixed intervals before each burn. We wanted to be able to verify the on-board maneuver solutions independently of the ground, or in extremis do without them altogether, and still carry out the rendezvous as long as we had an operating radar. Hence our fanatical determination to have the radar as the primary rendezvous sensor.



I'm not sure these nomographic and tabular backups were known to the Instrumentation Lab. They were brute force, but they worked. Never needed, though; the IL software and systems were iron-bottomed and gold-plated... [ellipsis Clark's]



Apollo 12:

E-2456, "Apollo Guidance and Navigation Flow Charts, Program Colossus 2C Comanche 67" (1969). (Full-resolution scan at our Internet Archive site.) Note that this is the "economy" scan ... I only scanned the flowcharts which were different from those for Colossus 2D Comanche 72, which I had previously scanned. (See under Apollo 13 below.) In other words, if you want to work with the Colossus 2C flowcharts you need to start with the Colossus 2D flowcharts and work backwards. By my reckoning, all of the flowcharts are the same between 2C and 2D except for those shown in the following table:

Flowchart Number

Nature of Difference

FC-2100

Changed

FC-2140

Changed

FC-2220

Only in 2D

FC-2235

Only in 2D

FC-2242

Changed

FC-2280

Only in 2D

FC-2283

Only in 2D

FC-2290

Changed

FC-2300

Changed

FC-2310

Only in 2C

FC-2363

Only in 2D

FC-2370

Changed

FC-2390

Changed

FC-2430

Changed

FC-2440

Changed

FC-2595

Only in 2C

FC-2600

Changed

FC-2631

Changed

FC-2640

Only in 2D

FC-2641

Only in 2D

FC-2642

Changed

FC-2650

Changed

FC-2670

Changed

FC-2682

Only in 2C

FC-2683

Changed

FC-2710

Only in 2C

FC-2730

Changed

FC-2760

Changed



Status Reports to NASA

From MIT Instrumentation Laboratory

E-1097, Work Statement for Industrial Support, January 1962



E-1142, "Weight and Balance Reports". Each "revision" covers a nominal one-month period, though the lengths of the covered periods varied over time. But the "revisions" are really separate reports, similar in form but with different content, rather than being incremental changes to a single report. The reports covered whatever was of interest at the time, and not merely weights of components. For example, at different points in time you can find coverage of electrical draw of hardware components, sizes of software modules in specific AGC software revisions, development timelines/progress, technical issues currently being addressed, lists of documents released during the time period, and so forth.



From AC Electronics

From Bellcomm

From Bendix

Lunar Navigation Study Final Report, Volume II, J. T. Broadbent, R. B. Odden, T. T. Trexler, and J. J. Vary, December 1966



From Raytheon

From TRW



General Apollo documents unrelated to computing systems

Press Kits, Press Releases, Press Conferences, Articles



Miscellaneous



Gemini spacecraft computer

Something Completely Different

In this section, we provide some stuff that doesn't directly pertain to any of the computers in Apollo or Gemini. But if the original developers give me interesting and sometimes unique material, or if I find interesting material related to them, I'd like to present it anyway.

