Hide 2020 change notes?
The phase 2 reconstruction of Sundance 306 for the Apollo 9 LM, which we call Sundance306ish (see the preceding log entry) has now been test flown in Orbiter/NASSP, thanks to Nik Beug.  Given that the main purpose of the Apollo 9 mission is test flight of the LM, Nik points out that the LM AGC software gets quite a workout as well.  So I think we can now be pretty confident that Sundance306ish works properly, even though only memory banks 36-43 are known to match Sundance 306 octal word for octal word.  The VirtualAGC UI program now uses Sundance306ish for the Apollo 9 LM configuration, in place of the prior phase 1 reconstruction (SundanceXXX).  SundanceXXX can still be flown via the command line, of cource, but not from the UI.
Recall from a couple of weeks ago that the LM AGC software for Apollo 9, namely Sundance 306, was in the process of being reconstructed from memory-module dumps in lieu of an actual assembly listing of the Sundance 306 program.  Reconstruction is a 3-phase process, in which phases 1 and 2 are successively-close approximations to the exact code, but only phase 3 will be an exact reconstruction.  As you'll recall, phase 1 (which we call SundanceXXX), which is supposed to functionally match Sundance 306 but not match it octal word for octal word, had been completed and successfully test flown. 

Well, phase 2 (Sundance306ish), which is supposed to improve on phase 1 (SundanceXXX) by matching the contents of Sundance 306 memory banks 36-43 octal word for octal word, has now been completed as well.  It has not yet been validated by being test flown, though I expect it will be flown (successfully) in the near future.  I won't add support for it to the Virtual AGC GUI program until after a test flight, but you can still look at the code or run it in the AGC simulation via a command line right now.  You can see the full writeup by following the hyperlink above.

It's admittedly unlikely we'll ever have a full phase 3 reconstruction, in which all memory-bank contents or even all memory-bank checksums are correct, no matter how much cleverness Mike and Nik manage to apply to the problem.  I think we'd need extra source material which we don't currently have, such as an actual list of all of the Sundance 306 memory-bank checksums.  Of course, one can't rule getting such a list, nor even the possibility of getting our hands on an actual assembly listing one day ... in which case the reconstruction would remain a magnificent tour de force, but ultimately have been obsoleted.  Still, barring that, it's likely that incremental improvements to Sundance306ish are what's in store for the future regarding the Apollo 9 LM software.  I'd recommend enjoying it as it is, rather than pining to no avail for source material we may never get our hands on.  Gather ye rosebuds and carpe that old diem!
Paul Fjeld (thanks, Paul!) has sent us the LM erasable pad loads for Apollo 9 and Apollo 10.  I.e., the numerical constants that had to be entered into the AGC manually or via telemetry upload, rather than being hard-coded into the AGC's software.  This is pretty timely, considering that the initial reconstruction of the Apollo 9 software just became available a few days ago.  The pad loads, you see, list both the memory addresses and variable names into which the pad-loaded numerical data goes, and thus gives us a way to associate some of the variable names in erasable memory with their physical addresses, independent of the software source code.  I'm told that the addresses in the Apollo 9 pad loads do indeed match the addresses Mike and Nik used in the reconstructed software, though it turns out that one variable was triple precision but had been treated only as double precision in the reconstruction.  So the pad loads provide not only a nice, independent confirmation of the accuracy of the reconstruction, but also have managed to pinpoint a minor error that had to be fixed! 
Although most of the recent updates to this change log have related to the LVDC, it's well to keep in mind that the main focus of this program is to provide the original AGC software, along with means to emulate the AGC, and and thus to run the original AGC software on your own (presumably non-AGC) computer.  And best of all, in some ways, to run that software in the context of a simulated Apollo mission on a spaceflight simulator such as Orbiter/NASSP.  If you want to fly a complete Apollo mission, you ideally want to have the complete AGC software for that mission: i.e., both the CM software and the LM software.  The Holy Grail, of course, would be to have complete sets of AGC software for every Apollo mission.  We haven't quite succeeded in reaching that pinnacle, but I think the results (after 17 years!) are still reasonably impressive.  Much more than I could ever imagine 17 years ago.  Ignoring those missions for which we have partial sets, in which we have the LM software but not the CM software or vice-versa, we have complete software sets (more or less) for the following missions:
  • Apollo 4
  • Apollo 5
  • Apollo 6
  • 2TV-1
  • Apollo 8
  • Apollo 9
  • Apollo 11
  • Apollo 15
  • Apollo 16
  • Apollo 17

The presence of Apollo 9 on that list is new, as of today ... though not without a bit of hand-waving and qualification!  I was actually sent notice of the software's availability a few days ago, in time to write it up for the 51st anniversary of the Apollo 11 landing.  Alas, after last year's general excitement about the 50th anniversary, I didn't even realize the 51st was imminent, so I let the opportunity slip by.  As it happens, almost nobody else in the world apparently remembered this particular birthday, either, so even though I may be an insensitive clod, I guess I'm not the only one at fault.

Hand-waving or not, it's an interesting tale.  Long-time followers of this project may recall that the Apollo 9 CM software (Colossus 249) was the 2nd AGC software version to which we got access, and was the very 1st CM software version we got.  But the principal objective of the Apollo 9 mission was the first test of the LM, in Earth orbit.  Since the LM software (Sundance 306) never seemed to be forthcoming, the fact that we had only the CM software for Apollo 9 never seemed tremendously exciting. 

Many years passed without much change in this situation, though eventually, interesting things.  The first stirrings, surprisingly, were in the realm of AGC hardware rather than software:

  1. We managed to acquire complete electrical schematics for the AGC, in many different revisions. 
  2. An (mostly-unaffiliated) project to restore a physical AGC to working order for the 50th anniversary of the Apollo 11 landing succeeded, ending up with a working AGC. 
  3. The now-working AGC was used, among other things, to dump the contents of memory modules from various museums and personal collections.  (And there are still more modules to be dumped eventually, I'm told.)  We benefited from that effort by getting dumps of the core-ropes from each of the 6 Sundance memory modules ... but not all from the same revision of Sundance.  Thus, instead of dumps of Sundance 306's memory modules, we had some dumps from Sundance 292, some from Sundance 302, some from Sundance 306.  And not all mutually-compatible with each other.
  4. As of today, we have something much more exciting in a software sense: a decompilation of those memory modules, along with a reconciliation of their incompatibilities — almost entirely shifts of the addresses fo variables and code between different revisions.  The result is that we now have a complete, functioning Sundance program.  This program is still not Sundance 306:  rather, it is a mogrelization of Sundance 292, 302, and 306.  We call it SundanceXXX.  Mongrelized or not, SundanceXXX does function, properly according to Apollo 9 documentation, and can be used successfully to fly Apollo 9 missions in Orbiter/NASSP, as well as in our native VirtualAGC UI.

You can see a full write-up, including the SundanceXXX source code, on our Luminary page.

Thanks go to Mike Stewart for this great achievement, with assistance by Nik Beug, abetted by the AGC-restoration team, and of course gratitude to those individuals and museums that allowed Mike to dump their memory modules.

The next step in the process is to modify SundanceXXX in such a way as to fully restore Sundance 306 itself.  Whether this proves possible remains to be seen, and we'll just have to keep our fingers crossed.  But in the meantime, as I said, SundanceXXX is flyable.  If you're willing to accept it in that vein, we now have a complete set of Apollo 9 software, albeit one whose authenticity at the binary level may (hopefully!) be improved later.

Added an amusing/horrifying anecdote about LVDC documentation to the FAQ page.
A bunch of nice technical data relevant to the LVDC (but not specifically about it) has fallen into our laps today, and has been added to our document library.  You can see the full write-up there, but here's a summary:
  • Universal Saturn Launch Vehicle Systems Handbook for launch vehicles AS-508 and subsequent.
  • Technical manual and electrical schematics for the Saturn V and IB Flight Control Computer (FCC).  The former is Saturn V only, while the latter covers various Saturn IB and V launch vehicles.  Recall that the Flight Control Computer is an analog computer in the rocket's Instrumentation Unit that can be controlled by the LVDC or the AGC.
As I mentioned a month or so ago, work is proceeding on PTC/LVDC emulation — so I haven't been idle! — but until it's 100% ready, there's not much excuse for updating this change log.  The PTC/LVDC emulator is actually working quite well now, but I'm immersed in nitpicking details that are of no importance in the larger scheme of things before I can close it out.  For example, the PTC front panel has a printer that the PTC CPU can print to, and in order to get the PTC software's self tests to pass, I not only have to have the emulated printer print the proper stuff (easy!) but also to have the emulated printer emulate the (undocumented) timing of the original physical printer (hard!).  Yes, it's silly, and certainly of no value in terms of LVDC emulation, but the problem is that the PTC software doesn't advance past tests that fail, so if I want to make sure all the self tests I care about are actually run, I need to make sure the silly tests I don't care about pass as well.  Or I can just cheat and comment out the tests I don't like in the original PTC self-test software; I've had to do that a couple of times already, but I'd really prefer not to do that until forced to do so.  The tests that I "care" about, of course, are those that exercise the CPU's instructions and interrupts, and if we can get those right for the PTC CPU, then there's a good chance that they're right for the only-slightly-different LVDC.  PTC emulation good → LVDC emulation good.

But I digress.  The reason I'm writing today is due to something found in the collected papers of Mike Collins, namely most of the Gemini Operations Handbook for Gemini 10.  (Thanks to Johannes Kemppanen for bringing this to my attention!)  These handbooks consist of 3 sections, two of which (Sections II and III) appear in the collection.  The missing Section I would seem to contain the spacecraft's electrical schematics and (presumably) a textual description of the theory thereof.  What's particularly significant insofar as the OBC (Gemini flight computer) is concerned, though, is that ~50 pages of Section II, namely section 2.5.7, comprise a detailed user manual for the flight software.  While we already had section 2.5.7 (and not much else) for Gemini 7, the Gemini 10 version is larger and more detailed.  And of course, has mission-dependent differences.  At any rate, you can explore the Gemini 10 operations handbook in our document library, or explore what we know about the Gemini flight computer on our Gemini page, if you have not already done so.  Gemini flight computer, as you may recall, is a variant of the LVDC used to guide the Saturn rocket, and now that our PTC/LVDC emulation is nearing fruition, our Gemini page and software is probably due for an overhaul to incorporate what has been discovered along the way.  But I'll leave that for another day.

A couple of other items from the Collins collection caught my eye, and so have been added to the document library as well:  A partial copy of the Final Gemini X Flight Plan; we already had a partial copy of the Final Gemini VIII Flight Plan, but different parts parts of that document are missing, so the two end up somewhat complementing each other.  Also, an MSC noted titled "Mission H-1 Abort from Lunar Powered Descent and Subsequent Rendezvous"; that's Apollo 12, and Collins (naturally!) didn't fly on it, but he wrote on the cover that it's "Worth saving because it shows all the 18 cases".  I'll take his word for that, and you probably should too. 
Having received some questions (which I couldn't answer) about the Saturn Flight Control Computer, which was an analog computer in the Saturn Instrumentation Unit that worked in conjunction with the LVDC and LVDA — and the AGC — I realized that there was some confusion online.  On the LVDC page, I had correctly depicted the device with a picture of the Saturn V Flight Control Computer, but online it was possible to find many pictures (incorrectly labeled) that were really of the Saturn I Flight Control Computer, and which looked very different.  (One is a big cylindrical can, while the other is a rectangular box!)  I've updated the LVDC page with labeled pictures of both, to eliminate any confusion coming from our site.
I noticed belatedly (after 11 years!) that I had misspelled Dimitris Vitoris's name on our LVDC page.  Dumb!  In connection with that, I saw that the descriptions I had provided about the photos of LVDC hardware Dimitris had sent us were very much out-of-date with respect to the documentation we now have available.  The descriptions have been corrected and fleshed them out quite a bit, though they're still full of holes that I patched up with speculation.

That also caused me to go back and think about the material I had gathered on my visit to the U.S. Space & Rocket Center archives about 2 1/2 years ago, and to realize that I apparently never made any of it available online afterward.  Well ... there were slim pickings there, compared to what I hoped to find, but not zero, so disappointment that things didn't go my way is not much excuse!  At any rate, I've now belatedly taken care of that:
  • Excerpts from the AS-503 Operational Trajectory document (namely, the pad loads) have been put in our document library.
  • A write-up about the USSRC archives and the photographic index I made there of LVDC-related material has been added to our Quest for Info page.  Or perhaps I should say "semi-related"; or "marginally-related"; at any rate, it's the stuff I was moved to take a picture of.
I've been spending all my time lately on getting the PTC emulation up and running, so that the PTC ADAPT Self-Test Program can be run in emulation.  Specifically, I'm working toward getting that original Apollo-era program's self-test procedures to run, in emulation, in order to validate our LVDC CPU emulator.  Lots and lots of progress has been made, but there's still a lot to do before it's ready to go.  I mention all this mainly as a lead-in to point out that the documentation on the LVDC page has been undergoing a steady revision because of that effort.  (And to excuse the fact that I'm only posting updates to this site every couple of weeks.  )
Well, it took a while, but our "modern" LVDC assembler (yaASM.py) has now been updated to assemble for a PTC target computer.  Moreover, the transcription of the PTC ADAPT Self-Test Program has been completed and debugged, and the transcription of the octals for the PTC ADAPT Self-Test Program has been through a round of additional corrections.  Plus, my online redigestion of how LVDC/PTC assembly-language works has been accordingly updated with all the stuff I found out in the process.  The upshot is that the LVDC assembler not assembles the PTC ADAPT Self-Test Program, with no errors, and the octals generated by the assembly match the transcribed ones 100%.  And the original LVDC AS206-RAM Flight Program still assembles 100% exactly as well, with some improvements to the messages generated by the assembler.

That's a mouthful, but the upshot is that our second "LVDC" program (albeit actually PTC) is available online for your study and even assembly.  It's not subject to ITAR restrictions they our first LVDC program may be.  Since its function is self-test, it will prove invaluable in validating our eventual LVDC/PTC emulator.  Now all we need is an LVDC/PTC emulator, and we can actually run the thing.
  • You may recall that a month or so ago, we added a copy of the LM-3 (Apollo 9) Lunar Module Systems Handbook to our document library.  Today (thanks to Mike Stewart), we've also been able to add the LM-3 Apollo Operations Handbook.  All of these things add to the tantalizing puzzle of Apollo 9's AGC software.  Way back at the beginning of the Virtual AGC Project, the Apollo 9 CM software (COLOSSUS 249) was almost the first AGC software available; we actually had it at the same time as the Apollo 13 LM software (LUMINARY 131), but I happened to choose to work with the LM software first and the CM software second.  So if LUMINARY 131 is our project's α, then COLOSSUS 249 is its β.  On the other hand, if the COLOSSUS printout had been just a little more legible, and the LUMINARY one a little less so, it could just as easily have been the other way around.  And if that's our α, what's our ω?  Or as discussions of alpha vs omega always seem to put it, for some unknown reason, our Ω?  Well, right now that's the Apollo 9 LM software (SUNDANCE 306).  The "tantalizing mystery" about it is that we don't have the source code for it, though we do have the complete assembled, executable form of it; not entirely in the correct revision, mind you, but rather as a mixture of chunks from SUNDANCE 292, 302, and 306.  The puzzles are how to recover a fully 306 executable from those bits and pieces, and how subsequently to recover the source code?  Nobody knows ... yet!  Once we do, though, it will be great since we'll unambiguously have both the CM and LM software for Apollo 9.  α and ω (Ω), baby, the ultimate mystery!
  • Work on the transcription of the source code for the PTC ADAPT Self-Test Program has also been proceeding apace, though it's only about 2/3 completed at the moment.  In retrospect, I can see that these change-notes on the topic have been rather piecemeal, so that someone who's following the topic merely from these notes, rather than from the LVDC page's discussion, probably finds it confusing or uninteresting, or both.  Here's an executive summary that perhaps makes it a little clearer:  The only Launch Vehicle Digital Computer (LVDC) software we've had until recently is a program called the AS206-RAM Flight Program which, while amazing in many ways, may be restricted in distribution by a U.S. regulation known as ITAR.  Thus, out of caution, I haven't so far been able to post it online.  But a couple of weeks ago, we found another LVDC program, definitely not restricted by ITAR, buried in some documents about the LVDC that we had newly posted online.  This new program is the PTC ADAPT Self-Test Program, or as I call it for short, the PAST program.  What this turns out to be, if you ignore some technical quibbles, is a program for the LVDC which is similar in purpose to our "validation suite" software for the AGC.  I.e., it thoroughly tests the LVDC's instruction set and various other aspects of the CPU.  Consequently, once a LVDC emulator has been created, running the PAST program on it may be the key to validating that the LVDC emulator actually works as intended.  Great stuff!  But still, it's just work-in-progress at the moment, seasoned with speculation, so I don't want to oversell it too much.
The transcription of the "octal listing" for the PTC ADAPT Self-Test Program has been completed and proofed.  The "octal listing" is the assembled form of the PTC program, so in principle, if you had an LVDC emulator that supported the slight instruction-set differences between the LVDC and PTC, you could actually run it in simulation right now.  Of course, you don't have such an LVDC emulator (I assume), so that's admittedly not terribly helpful just yet.  (Moreover, I should warn you that even though the transcription has been completely "proofed", there's every reason to believe that it's unlikely to be 100% correct yet.  I relied on OCR for data entry in order to save time, and OCR'ing this kind of material is such an inherently buggy process that during proofing I ended up having to correct nearly 25% of the octals.  Which almost guarantees that a significant number of errors escaped my notice.  My guess is that 10-20 errors were undetected on this first proofing pass.)

But emulation isn't really the purpose of the transcribed octal listing anyway.  Its real purpose is to serve as an eventual cross-check of the transcribed source code for the PTC ADAPT Self-Test program, since when that transcribed source code is assembled using our modern LVDC assembler, it should produce an octal listing identical to the original (transcribed) one.  But transcription of the source code has barely begun at this point, so cross-checking it is hardly an immediate issue!  Personally, I'm not going to revisit proofing of the octal listing until after transcription of the source code, so the octal listing will remain in this proofed-but-probably-still-buggy shadow state for quite a while unless somebody else cares to step forward and take care of it.

Incidentally, the LVDC is essentially a black box, in which electrical inputs are provided and electrical outputs are produced, but there's no user interface, so it's not clear that emulating it outside the context of (say) a full spacecraft simulator like Orbiter/NASSP would be too exciting for anybody.  (Not to mention the fact that we still don't even know whether ITAR would allow us to "export" the LVDC Flight Program to Orbiter/NASSP anyway.  But I just meant it might be not too exciting entertainment-wise.)  Admittedly, the LVDC does have telemetry that could be monitored.  But for the PTC, on the other hand, one of the peripherals it includes is a printer, and the PTC ADAPT Self-Test Program does send output to that printer.  So, perversely, simulating execution of the PTC ADAPT Self-Test program could actually be more fun than simulating execution of an LVDC Flight Program, because we could watch messages appear on the simulated PTC's simulated printer. 
Work on transcribing the source-code for the LVDC PTC ADAPT Self-Test Program has begun, though there's not much to show for it just yet other than an almost-empty placeholder folder for it in our GitHub repository.  In the course of what little progress I've made, I've found a handful of differences from the assembly language that appeared in the AS206-RAM program on which I had patterned the LVDC documentation and assembler, so I've been updating my online descriptions of LVDC pseudo-ops and of LVDC CPU instructions accordingly as I work.  Obviously the assembler will have to be updated as well for these new pseudo-ops and changed CPU instructions, but nothing has been done on that front at the moment. Also, for convenience (mine!), the scanned pages have been extracted from the much larger PDF document in which they originally resided, massaged slightly for appearance, and provided on our LVDC page as a zipfile of image files for individual pages.
The initial pass at creating G&N assembly drilldowns is now complete.  I.e., all parts lists for G&N assemblies traceable in a top-down fashion from the top-level guidance system assemblies have now been entered into the repositories, checked, debugged, and used to regenerate all of the G&N assembly drilldown pages (such as the Apollo 11 LM Guidance System).  Plus, I found that the script which generates the drilldown's web-pages had rotted somehow and begun discarding some items in the parts list that had non-integer quantities (such as cable lengths).  Hopefully, I've fixed that.  That's not to say that the drilldown is "perfect" (even in the very loose sense that that word is now apparently being used by some folks in America), but it does mean that I don't have any ideas right now about how to track down residual errors in the drilldown.  So I feel entitled to say that the work has been completed.

However ... I do have some plans to improve the drilldowns at some point in the future, though not necessarily right away since I have other things I want to take care of first.  Eventually, though, the idea for improvement is that since the existing drilldowns have been generated in a top-down fashion, they run into difficulties whenever there's some G&N subassembly for which we don't have a drawing.  When that happens, none of the sub-subassemblies or components belonging to the missing subassembly will appear in the assembly drilldown.  For instance, if you look the page for the Apollo 11 LM Guidance System mentioned above, you'll see that item #72 in the guidance system parts list is 6011876, "Sunshade and Radar Shield Assembly".  We do not have the drawing for that, and consequently don't know what the Sunshade and Radar Shield Assembly contains; it's just a drawing number and a title, and nothing more.  All of the other subassemblies of the guidance system are instead expanded to a greater or lesser degree.

But wait ... don't abandon hope!  Fortunately, many of the G&N drawings contain not only parts lists for their own components and subassemblies, but also list their own parent drawings; i.e., they provide a list of all of the G&N assemblies in whose parts lists they themselves appear.  This is rather hit-and-miss, and not all drawings do this.  But enough of them do it that it's possible to create a kind of half-baked assembly hierarchy by working from the bottom-up rather than the top-down.  Let's call that a "drill-up".

If a "drill-up" assembly hierarchy were combined with the "drill-down" assembly hierarchy we already have, it should be possible to make a more-complete assembly hierarchy in which some of the missing assemblies (and their contents) are partially filled in.  Alas, making the drill-up will require not only some preparatory thought, but also some software (easy!) and a huge database of the parent assemblies for G&N drawings that list their own parents (very time-consuming to create!).

In just a handful of cases, the most significant of which being the "logic modules" in the Block II AGC, this kind of thing has already been done.  For example, if you trace down through the drawings for the Apollo 11 LM guidance system (drawing 6014999-091), down to the AGC itself (drawing 2003993-031), you'll find that the drawing for the logic modules (2003888-xxx) is missing.  Frustratingly, the logic modules are the critical active portions of the AGC, since they contain all of the digital electronics; i.e., everything that makes the computer compute!  Considering how critical they were, just washing our hands of it at that point and saying "too bad!" didn't seem to be an adequate response.  Luckily, we just happened to discover some of the significant assemblies comprising 2003888, and thus were able to include them in our existing assembly drilldown.  E.g., even though 2003888 is missing from the assembly drilldown, the drilldown still is able to list some of the elements for Logic Module A3 (2003888-031) as being the circuit boards 1006395-005 and 1006395-006, and the electrical schematic 2005251.

However, the existing places in the assembly drilldown where we've been able to do this have really been more a product of luck and desperation than of any systematic effort to work around missing assemblies in general.  The idea of the proposed future "drill up" is to supply such a systematic effort across the entire spectrum of G&N drawings, and to work around missing assemblies wherever possible, rather than merely wherever lucky and desperate. 

As I say, though, this won't be done right away, and I don't have any particular schedule on which I'm contemplating doing it.  Of course, anyone who wanted to help out in creating the database of parent assemblies could help to move it along a little faster!
  • An anonymous correspondent has sent me notice of modified Comanche 55 software (Apollo 11 CM AGC) to implement the solution of the Google Foo.Bar Coding Challenge's "Dodge the Lasers" problem.  (If you've never heard of any of those things — other than Comanche 55, of course — join the club! )  At any rate, you can be the first kid on your block to view and/or run the modified code by following the hyperlinks for it on our FAQ page.
  • There have been a number of updates to G&N assembly drilldowns as well. 
  • Some significant LVDC/LVDA documents have been added to the document library, disguised as maintenance and testing manuals for laboratory equipment, and hence (embarrassingly) initially rejected by me years ago when they were proposed to me for inclusion in the document library.  How silly I was! 
    • Buried in one of the manuals is a large LVDC self-test program (>50% the size of an LVDC flight program), but whose "export" is not restricted by ITAR since it's not guidance software!  In other words, you can actually look at it without groveling to me personally and showing me your U.S. citizenship documentation.  Actually, the program is not for the LVDC proper, but rather for a ground-based device called the PTC, which contains a "modified" LVDC CPU.  But at this point it would seem to be a reasonable hope that we can largely treat it as an LVDC program.  I expect we'll begin an effort as well to transcribe the source code so that the self-test program can be assembled, and perhaps eventually even be run in simulation. 
    • Buried in one of the other manuals is a large set of LVDA electrical schematics, of which we are otherwise ignorant.
  • The LVDC page has been updated to cover the PTC ADAPT Self-Test Program (i.e., the software mentioned above).  The information right now is rather sketchy, and presumably will be updated substantially in the coming weeks or months.
  • In the index for G&N aperture-card box 470, several revisions of (D, E, F) of drawing 6007019 had been miscoded as drawing 6007018; that has been corrected.
  • Lots and lots of G&N assemblies have had their bill-of-material information added, fleshing out the G&N assembly drilldowns.  But still plenty more to do.  There's always plenty more of them to do.
  • Added the LM-3 Systems Handbook (Apollo 9) to our document library.  (Thanks, Mike Stewart!)  This is very timely, considering that we've just recently acquired all of the top-level engineering drawings for LM-3.  And a bit humbling, since of all the reference engineering-drawings listed as actual source material for the Handbook, we have so far acquired none at all.  Still ... give it time!
  • I've added parts lists for a bunch of G&N system assemblies, and regenerated the G&N assembly drilldowns accordingly.  There's still a fair amount of work to do to finish them up 100%, but it's progress.
  • Completed the process of adding all remaining drawing titles to the index for LEM engineering-drawing box 523.  All LEM indexes are now completely up-to-date with respect to drawing titles ... until we can begin adding more scans.
  • I noticed belatedly that we now have all upper-level drawings not just for LM-3 (as mentioned in my preceding update), but for all LTAs and for LM-1 and LM-2 as well.  (As well as the topmost drawing for LM-4, but none of the drawings below it.)  I've consequently added an explicit list of links to all those things, as opposed to forcing folks to ferret them out for themselves.
Added some (but not yet all) drawing titles to LEM engineering-drawing box 523, the last aperture-card box I managed to scan before the National Archives was closed to the public as a COVID-19 precaution.  (Hint:  There won't be any new LEM scans until ... sometime.)  However, in the process of adding these titles to the index, I noted that the box contains the top-level drawings — well, perhaps not the very topmost drawing; it's difficult to tell — for LM-3 (Apollo 9).  They begin with LDW280-53000.  That's nice, given that it may be quite a while before any more scans can be made.  Better than nothing, anyway.
  • Added drawing titles to the index for LEM engineering-drawing box 522 (scanned 2 days ago).
  • Added newly-scanned LEM box 523 (not yet with drawing titles added to the index page).
  • Added drawing titles to the index for LEM engineering-drawing box 521 (scanned last week).
  • Added newly-scanned LEM box 522 (not yet with drawing titles added to the index page).
I've been adding searchable text to some PDFs in our document library that didn't have it before, such as documents E-1142 (mentioned in the previous entry) and 70-LM-145 (added a couple of weeks ago).  A little over 120 documents are affected.  Which is not to say that I've sought out and fixed every PDF that needs searchable text added to it, but it's good progress.  (If anyone feels the absolute need for a list, I'll send you one, but it seems rather pointless to me to post one online.  It's not as if anybody has been clamoring for this.)
  • Added grayscale rescans for the illegible B&W scans in box 518.  (Actually, for a couple of the Engineering Orders, I accidentally rescanned the wrong slides.  So there's still a bit of work to do to make it complete ... perhaps I'll get around to doing it someday!)
  • Added a bunch of revisions of MIT/IL document E-1142, the guidance system "weight and balance" report, to the document library.  Actually, these reports cover a lot more than just weight and balance, such as electrical draw of different hardware modules, sizes of AGC software modules, etc.  Each "revision" covers a separate month, or (early and late in the project) a separate several-month period.  We already had a bunch of these in the library, but now we have a bunch more ... possibly a complete set of them, from 1962 through 1969.  Unfortunately, neither these PDF documents, nor 70-FM-145 (added a week or so ago) have searchable text, due to technical difficulties.  I'm sure there are plenty of other documents in the library about which the same could be said, so it's not as if it's a tragedy, but it's slightly annoying.
  • Added drawing titles to the index for LEM engineering-drawing box 520 (scanned yesterday).
  • Added newly-scanned LEM box 521 (not yet with drawing titles added to the index page).
  • A couple of weeks back, I had changed the location (on the electro-mechanical page) of the table of LEM aperture-card boxes, but had foolishly forgotten to account for the fact that all of the LEM engineering-drawing index pages continued to use the obsolete link.  The LEM index pages hopefully have the correct link now, and I've taken the opportunity to provide a link to the master LEM drawing index file on those index pages as well.
  • Added drawing titles to the index for LEM engineering-drawing box 519 (scanned last week).
  • Added newly-scanned LEM box 520 (not yet with drawing titles).
Incidentally, it's worth noting that since the addition of LEM box 518 a few days ago, the LEM-drawing scanning effort is now into a region of the aperture-card boxes in which we have the top-level drawing for LTA-8, and lots of upper-level drawings for it as well.  It's true, I'm sure, that people in general aren't as interested in LTA-8 as in a "real" LEM — "LTA" stands for Lunar Test Article —but one shouldn't shouldn't disrespect LTA-8!
Drawing titles added to the index page for LEM engineering-drawing box 518.
Finished added drawing titles to the index page for LEM engineering drawings box 517, and indexed all of its grayscale rescans as well.
Updated the index pages for LEM engineering drawing scans to include the grayscale rescans for aperture-card boxes 511, 512, 513, 514, 515, and 516.
  • And similarly to yesterday, I've uploaded the grascale rescans for LEM boxes 515 through 517 our Internet Archive site, though I've not yet updated the LEM-drawing index pages, but you can directly browse those scans here:  box 515, 516, 517.
  • Added a new document scan to the document library:  70-FM-145, "RTCC Requirements for Apollo 14 (Mission H-3): LOI Targeting".
While I haven't had a chance to update the index pages yet, grayscale rescans have been done for those aperture cards in LEM boxes 511 through 514 whose initial B&W scans were illegible.  If you absolutely can't wait for the indexes to be updated (in a few days), you can see the directly browse the rescans at our Internet Archive site:  rescans for box 511, 512, 513, and 514.  The index pages for those boxes do show which rescans were scheduled, but probably do not correctly match the order in which you'll encounter the scans.
  • Added scans for LEM aperture-card box 519.
  • Added drawing titles to index for LEM aperture-card box 516, and for a little less than half of box 517.
  • Added scans for LEM aperture-card box 518.
  • Added drawing titles to index for LEM aperture-card box 515.
  • Added the drawing titles to the index page and master index for LEM aperture-card box 514.
  • Corrected a number of errors in drawing titles that I hadn't noticed before.
  • Added the drawing titles to the index page for LEM aperture-card box 513, and made a handful of corrections associated with that effort.
  • On the electro-mechanical page, I've separated the LEM engineering drawings from the miscellaneous engineering drawings, so that there are now two separate sections on the page where there was only one previously:  LEM Engineering Drawings and Additional Apollo Engineering Drawings.  I hope that will make it a little easier to navigate, if only by an admittedly very tiny bit.
Updated the LEM drawing indexes to include grayscale rescans of those B&W initial scans that were illegible, for the following aperture-card boxes:  Box 507, Box 508, Box 509, Box 510.  (Actually, in Box 509, I somehow forgot to rescan drawing LDW280-14342.  This drawing covers multiple parts, namely LDW280-14342-11, -12, -15, -17, -19, and -21, of which only -19 has impaired legibility and indeed may still be marginally usable ... so I think there might be a pretty significant delay before I get around to correcting my mistake and rescanning it.)  This covers all of the rescans which have been made so far.
Added a complete set of scans of LEM drawings from aperture-card Box 517.
  • Added a complete set of scans of LEM drawings from aperture-card Box 516.  Anyone who loved Box 515 for the fact that it was beginning to contain higher-level assembly drawings as opposed to simple fabricated parts will probably love Box 516 even more.  Unfortunately, I won't get around to manually entering all of the drawing titles for either of those boxes for a while.
  • Grayscale rescans have been completed for the aperture-cards whose initial B&W scans in Boxes 507 through 510 were illegible, though I probably won't be able to update the index pages for those boxes (or the master index) until the weekend.  For anyone who just can't bear to wait that long, and are willing to browse the scans unindexed, go to our Internet Archive site and in the "Search this Collection" box use the search string "Box 507" (or "Box 508", or ...).  Of course, some of the rescans are still illegible, when the microfilm itself is out of focus or has some other problem, but for the most part the rescans have been usable ... albeit with some effort in a few cases.
  • Hartmuth (thanks!) has added in all of drawing titles for aperture-card Box 512.
  • Added a complete set of scans of LEM drawings from aperture-card Box 515.  Note that this is now getting into the LDW280-2XXXX drawings, which seems to include many higher-level drawings, as opposed to drawings of small parts like angles or channels or shims.
  • A duplicate slide for the corrupted drawing "LDW280-17" from Box 503 has been found in Box 512; it is really drawing LDW280-17847, and the Box 503 index has been corrected accordingly.
  • Finished scanning remainder of LEM drawings from  aperture-card Box 513.
  • Added a complete set of scans of LEM drawings from aperture-card Box 514.
  • Added a handful of grayscale rescans for previously-illegible B&W LEM scans from Box 507, although there are many rescans still needed in that box.
  • Finished up added all drawing titles to the index page for LEM aperture-card Box 511.
In Box 510, finished added drawing titles and marking illegible scans for eventual rescan.  Began performing similar work on Box 511 as well.  All of the previous LEM boxes have contained only simple building-block parts, except for cards that had accidentally been filed in the wrong boxes, but in 511 we begin to see some drawing of significant complexity, such as LDW280-17388 (the descent-stage fuel-lines diagram, >300 scans) and LDW280-17389 (the environmental system piping diagram, ~70 scans).
  • Finished scanning remainder of LEM drawings from  aperture-card Box 512.
  • Added scans for 90% or so of LEM drawings from aperture-card Box 513.
  • Finished scanning remainder of LEM drawings from  aperture-card Box 511.
  • Added scans for 80% or so of LEM drawings from aperture-card Box 512.
  • Completed adding grayscale rescans for illegible existing B&W images in LEM drawings in aperture-card Boxes 503 and 504.
  • On the FAQ page, added a link to Moonbit, by James E. Dobson and Rena J. Mosteirin.  This a small book of (and about) "erasure poetry" based on the AGC software.  Culture, baby, culture!
The aperture-card scanner is finally available again, so some new scans of LEM drawings have been added:
  • Aperture-card Box 510 ... not including rescans of images that were illegible on the first pass through the box.  A little but not all of the index has had drawing-titles added and illegible scans marked.
  • Approximately 75% of aperture-card Box 511.
  • Rescans in grayscale of aperture cards from Boxes 502, 503, 504, 505, 506, and 507.  Some cards in 503, 504, and 507 remain to be rescanned.
  • Added Apollo G&N System assembly-drilldowns for various assemblies not previously covered.  (Still lots of them to be done for various non-computer G&N assemblies, even though the AGC and DSKY drilldowns are pretty complete!  But making slow progress over time.)
  • Cleaned up the underlying change-log file in other ways that hopefully will be transparent to the reader.

Hide 2019 change notes?
Hide 2018 change notes?
Hide 2017 change notes?
Hide 2016 change notes?
Hide 2015 change notes? (There aren't any!)
Hide 2014 change notes? (There aren't any!)
Hide 2013 change notes? (There aren't any!)
Hide 2012 change notes?
Hide 2011 change notes?
Hide 2010 change notes?
Hide 2009 change notes?
Hide 2008 change notes?
Hide 2007 change notes?
Hide 2006 change notes?
Hide 2005 change notes?
Hide 2004 change notes?