Hide 2017 change notes?
For the 3D-printed DSKY with integrated Raspberry Pi running yaAGC that I've mentioned obliquely a couple of times in the last few of days, I had been asked to provide some sort of a facility for playing back pre-scripted AGC output-channel commands ... i.e., for controlling the DSKY from a script rather than from yaAGC, for things such as museum exhibits.  So I added a primitive recording and playback capability to that DSKY program, which is called piDSKY2.py, it being a Python 3 script rather than the classic yaDSKY program.  Having done that, I began to wonder where the heck anyone would actually get a meaningful script to run on the thing, since what you'd really want is realistic data from an actual mission simulation, rather than something recorded while just playing around with yaAGC and a DSKY. 

The answer to that, it seemed to me, was to see if NASSP could log data about AGC-to-DSKY output-channel transactions or if not, could someone add it for me?  Well, Nik Beug was kind enough to not only pep up NASSP's logging capabilities to meet my needs, but also to send me the log for a sample mission segment, namely an Apollo 8 launch.  So with a slight amount of work throwing together a little Python script for converting Nik's NASSP log format to the format I needed, I now had the ability to "play back" an Apollo 8 launch on the 3D DSKY.  Yay, and thanks Nik!  Hopefully we'll have a lot more of these scripts in the future.

Now, unfortunately, not everybody is going to be able to have one of the 3D-printed DSKYs, so my next thought was this:  Why not modify yaDSKY2 so that it can play back these scripts?  So ... now it can!  The way it works is that if you click on yaDSKY2's PROG indicator lamp with a mouse, you get a file dialog that allows you to choose a canned script for playback.  Naturally, I've added this to the introductory list of various fun things you can do with a Virtual AGC on our home page, as well as describing how to use the scripting capability on our yaDSKY page.
  • The assembly-language page has listed the operand of the DV instruction as being 12-bit all these years ... but it's really 10-bit.
  • The sample code associated with the custom AGC software and custom AGC peripheral device, as described on the do-it-yourself page, have been cleaned up and extended considerably to improve their value as examples.  Specifically, they now implement a kind of "clock app" rather than just a clean coding template.
A new page, DIY.html (for "do it yourself") has been added, intended to be a simple tutorial on writing and running your own custom AGC programs to do stuff the AGC was never intended to do.  As if I could write anything "simple"!  This is prompted by the introduction onto the market of functional 3D-printed DSKY look-alikes with integrated Raspberry Pi computers running Virtual AGC.  It should probably be called an iDSKY.  With units such as that, there seems to be a lot more interest in having the DSKY do cute stuff that's not necessarily directly AGC related than there is in pepping up the pure software simulation.  Probably because there's more of a motivation to get value for your dollar, since the physical devices are costly while the software simulation is entirely free.  My take on that is that it's fine to subvert the normal functionality of the unit, but that it should be implemented by writing programs in AGC assembly language to do it!  (Well, I have my ideas about it, and nobody is forced to agree with me.  :-) )  At any rate, this is my attempt to encourage that.  The new page is nowhere close to being complete, but I think it has enough on it to be useful.
An early version of the Luminary 1C Programmed Guidance Equations document has been added to the document library.  We already had a later version of the 1C document, as well as having the 1B document, so this is a kind of "missing link" between them, I guess.
For me (your own mileage may vary) building Virtual AGC from source was failing due to compiler warnings on the Raspbian Stretch operating system, though continued to succeed on the (older) Raspbian Jessie operating system.  This has been fixed in the github repository, and the Raspberry Pi build-procedure on our download page duly updated.
I've added some description to our developer page of a Python 3 program which can be used as the basis for quickly creating a simple, low-performance simulated peripheral device for use with yaAGC.  Basically, it handles the details of connecting the peripheral to yaAGC and of parsing the information passed between them, leaving the developer with the task of determining what's supposed to happen to data to/from the AGC's input/output channels.  The basic motivation is that this might be a good way to throw together physical implementations of AGC peripherals, without having to concern oneself with C++ or cross-platform graphical toolkits or other complicating factors, by embedding a Raspberry Pi in them, and running a variation of this Python 3 script on the Pi.  There's also a sample Python 3 script that illustrates how to use this technique to create a (very) simple DSKY.
  • Ryan Callaway has created a couple of impressive YouTube videos in which our simulated Abort Guidance System (AGS), now incorporated in the Orbiter spacecraft simulator via the NASSP project as mentioned a month or so ago, is used for some hypothetical Apollo 12 aborts.  Naturally, I've added links to those videos on our AGS page.  Very cool, Ryan!  And given the sad passage 10 days ago of Dick Gordon, Apollo 12's Command Module Pilot, a timely memorial as well.
  • In the process of watching those videos, I accidentally discovered a video in which Nik Beug also uses the Orbiter/NASSP platform to illustrate Don Eyles's famous mission-saving Apollo 14 fix, in which the abort-discrete input to the AGC is temporarily masked during the descent to work around an intermittent problem that could have inadvertently triggered an abort.  Also cool!  Naturally, I've added a link to that video on our main page, to supplement the discussion there of the famous fix.
The 2017-11-12 entry below, as well as our document-library page, previously contained the suggestion that the SKYLARK Program Change Requests (PCRs) recently added to the document library might have represented a complete set of the SKYLARK PCRs that had been implemented in the SKYLARK software.  That idea is now known to be incorrect, and so those incorrect suggestions have been removed.  The reason we know it's incorrect is that our copy of the SKYLARK GSOP contains an appendix which lists (incompletely) the PCRs and PCNs as of March 1972, and it turns out that there are lots of SKYLARK PCRs and PCNs for which we don't have the text as of this time.  Alas!   At any rate, the PCR table in the document library has now been updated with this improved PCR/PCN list.
  • A bunch of PCRs (Program Change Requests) and a related memo for SKYLARK were added to the document library.  If you'll recall, SKYLARK is the CM's AGC code for Apollo-Skylab and Apollo-Soyuz missions.  Unfortunately, we still do not have the SKYLARK code itself.  The PCRs are great, because they usually contain enough information to actually implement the code changes.  Most of the changes are just deletion of unnecessary programs, verbs, or routines, but there are a couple of pretty substantive changes as well.
  • Added a nice technical "memorandum", in just 888 pages, describing all the Saturn launch vehicles ... up through early 1964.  It is interesting to me primarily because it provides a little info about the ASC-15, which is the digital computer that preceded the LVDC and was used on the Saturn I and Saturn IB launch vehicles that preceded the Saturn V.  The ASC-15, like the LVDC, was developed by IBM Federal Systems Division in Owego NY, but unlike the LVDC was a drum-memory computer rather than a ferrite-core-memory computer.  I have briefly mentioned the ASC-15 on our LVDC page previously, but only as a guidance computer for the Titan II, since I had been unaware it was used on some Apollo launch vehicles.  Regardless, the information in the newly-added memorandum is still quite meager, and I've not yet altered my comments about the ASC-15 on the LVDC page.  It would be cool to get some deeper technical info about the ASC-15 first.
  • Added something called the "Apollo Guidance Program Symbolic Listing Information for Block 2" to the document library.  This has been described as "an AGC Bible", and covers lots of design information about AGC hardware and software in a single reference, as well as miscellaneous stuff like the GAP (assembler that replaced YUL) punch-card format.
  • The LVDC page has been changed in a variety of ways:
    • It no longer indicates that a copy of the LVDC software resides in the archives of the U.S. Space & Rocket Center, since that turns out not to be true.
    • It now indicates that a major coder of the software is known (though not yet contacted).
    • A rough analysis has been added to indicate the possible (speculative) major versions of the LVDC software.
  • Various new documents added to the document library page, of which the highlights are:
    • CM AGC Interface Control Document (interface wiring) from North American Aviation.
    • "Launch vehicle flight evaluation reports" for most missions.
    • "Launch vehicle operational flight trajectories" for a couple of missions.
    • AGC improvment study.
I've been going through my to-do list — i.e., the list of things people emailed me about and that I said I'd take care of Real Soon Now ... but then never actually did anything. Some are astoundingly, forehead-slappingly old.  Many, of course, have resolved themselves over the course of time without any intervention from me.  At any rate, here's a brief rundown for some of the particularly egregious omissions of how they've affected this website or the github repository, in chronological order so that you'll get some sense of my guilt:
  • 2010 — Juan Jose has told us about his hardware Block I simulator, using an FPGA, along with a bunch of YouTube videos of it in action.  This has now been belatedly added to the physical implementations page.
  • 2012 — GEMINI on-board computer developer Gene Mertz scanned and sent me a document called the "Preliminary Ascent Guidance Simulation Report", for which the DVD containing hundreds of pages of scans has apparently been sitting on my desk this whole time, forgotten.  Groan!  Well, I suppose the reason I left it sitting in the to-do box is that there were dozens of graphs and diagrams that had been split into 3 page each during the scanning.  At any rate, I've now photoshopped all these pages back together for easy viewing and added the document to the document library.  However, I'd note that the PDF-creation process seems to have botched the multipage graphs that I so-laboriously stitched together pretty badly, so the full-resolution scans I've stored on our project at the Internet Archive , though 15× larger, are much, much better for looking at those graphs.
  • 2012 — GEMINI OBC developer Charlie Leist sent me the draft of a (modern) document ("Gemini Peer Reviews") that he and Pat Mooney (Gemini Programming Manager) wrote, trying to capture how the software development process worked, but there's a lot of extra detail about associated matters that I hadn't seen before as well.  I suppose I must have left it in the to-do list because it was just a "draft".  At any rate, it's in the document library now.
  • 2012 — Dave Roberts sent word of the problems he was having with his hardware Block II simulator, a number of which pointed to bugs in yaAGC, particularly in the DV instruction, and sent a lot of descriptive material and even code demonstrating/fixing the problem ... the same problems Mike Stewart had later with his Block II simulator, and was gracious enough to fix directly in yaAGC over the course of the last year.  But Dave was first, and I let him down by parking him on the to-do list, alas!  Anyway, Dave's project has also finally been added to the physical implementations page.
  • Last month — Nik Beug flew a lunar landing in NASSP using Zerlina, and has shared a video of it, so I've modified the Luminary page accordingly to link the video.

More to come later, probably.

The good NASSP folks have been making an effort lately to get our AGS (abort computer) simulation integrated into NASSP, and into checking it out, which is great!  What Ryan Callaway in particular found was that while a lot of stuff worked, a lot of stuff didn't work either.  Mike Stewart jumped right in and managed to find a bug I had made in the AGS simulator, yaAGS.  So Ryan now reports that it "looks like all phases of rendezvous work as advertised in lunar orbit. I used AGS calculations for every part and ags controlled burns as well with RR and PGNS as backup/basis of comparison" and "the AGS aborts the LM beautifully in both DPS and APS aborts".  Which is not to say that yaAGS necessarily is 100% perfect now, but this one fix has improved its behavior tremendously.  For now, you have to build the software from source if you want this fix, and it hasn't migrated into the installer packages for VirtualAGC yet.  Great work, guys!
The AGS documentation has been reorganized somewhat for clarity (I hope!), and now appears only on the AGS page itself rather than being duplicated on the document library page.  It was simply too irritating to duplicate it.
  • The yaYUL bug causing incorrect assembly of Solarium (for Apollo 4 and 6, but all Block I code in general as well) on Mac OS X has been fixed in the GitHub repo, so Solarium 55 is once again a full-fledged member of the AGC family on all platforms.
  • The current source tree at GitHub builds on all platforms listed on the download page, so I've "released" new binary packages for Ubuntu 14.04, Raspberry Pi, and Windows on the download page, as well as updating all of the build instructions for the different platforms.  The VirtualAGC VM has not been updated, and doesn't need to be re-downloaded; it should simply be updated with the new Ubuntu 14.04 package.  (Admittedly, at the very last minute, I had to change some of the makefiles to accommodate the Solaris 11 operating system, and hopefully that won't mess up the build on all the other platforms ... but I only did minimal checking to insure that).
  • The transcription of ZERLINA 56 AGC source code from the scanned printout has now been completed, and assembles properly with yaYUL, and associated bugs in the previously transcribed octal rope have been repaired.  (There actually was a single bug in the octals, which did not affect the checksums, and thus wasn't previously detected.)  In other words, ZERLINA is ready to go.
  • ZERLINA now builds by default when building Virtual AGC from source, and the VirtualAGC GUI app's support for ZERLINA has been enabled.  In fact, all AGC versions available to us, including the reconstructed programs LUMINARY 99/0 and LUMINARY 99/2, are now supported directly in VirtualAGC, and thus none of them need to be run from the command line.
  • And, of course, the Luminary page has been updated to have the colorized, syntax-highlighted ZERLINA 56 source code on it.
  • All of the colorized, syntax-highlighted source code for other AGC versions has also been updated with the latest improvements.
I was recently contacted by an graphic artist who was doing a project that involved the binary patterns used to encode characters, specifically in the word "APOLLO", who wondered what the appropriate binary encoding of these characters, easily recognizable by a 1960's engineer, would have been in the Apollo era?  I told her to use EBCDIC encoding.  Then, in a rare fit of humility, I passed the question along to Hugh Blair-Smith as well.  Hugh also said that EBCDIC was the appropriate answer, but then speculated about a separate matter:  Is it possible to actually display the word "APOLLO" (or more accurately, "APOLO") directly on the DSKY itself?  As you may recall, the DSKY was used to display only numbers and blanks, but that doesn't mean it isn't possible for appropriate software to display other patterns as well.  Alas! it turned out not to be possible; none of the characters A, P, or L can be displayed.  In fact, we ended up tracing through the DSKY's electrical schematics to find every possible display pattern, and those wild patterns are now listed on the developer page.  Some nice images verifying these patterns on Bruno Muller's hardware DSKY emulation have also been added to that page.
I'm told that the situation for building Virtual AGC on Mac OS X is much worse than I imagined, and that newer Macs now provide clang as the default C compiler, rather than gcc ... and naturally, Virtual AGC was designed for the ubiquitous gcc and not for using clang.  And equally naturally, my own Mac is an older one that sensibly provides gcc as it ought.  Well, that's life in the Mac world, I suppose, of which I have very little knowledge! 

I've added experimental clang support in the github repository (it works on Linux at least), as well as providing a method of potentially using gcc in spite of the fact that Xcode wants to use clang.  Both are possible approaches to the Mac problem.  I've provided documentation as to how an adventuresome soul might try out these approaches on a newer Mac.
Note that I really only want to support VirtualAGC on Ubuntu/Mint/Debian desktop Linux systems, given that I don't have infinite free time or patience or knowledge to do otherwise.  Nevertheless, I occasionally check or (or receive user feedback about) problems on Windows, Mac OS X, Raspberry Pi, alternate versions of desktop Linux, etc., and do sometimes make an effort to work around those problems.  Over the last couple of days, I've gotten feedback about some such compilation problems, and so have made some changes related to them:
  • The AP11ROPE scans have been used to cross-check yet again the program comments in the Luminary 99 source code.  Only a handful of fixes, and the scans are so clean that I think we can really have quite a lot of confidence that there are very few lingering errors in the Luminary 99 source.
  • The analysis of the scan of AP11ROPE has also been completed.  The final result of the analysis is that AP11ROPE and our existing MIT Library scan of LUMINARY 99 R1 are identical, except that on page 2 of the listing, the modules on pages 153-489 are collectively referred to in LUMINARY 99 R1 as "LNYAIDE", but in AP11ROPE are referred to as "LEMONAID" just as in LUMINARY 69.
  • A pretty amazing document has been added to the document library.  This is the final technical report from the MIT Instrumentation Lab in 1977, by then called Draper Laboratories, to the Rome Air Development Center (ISIS) at Griffiss Air Force Base.  The report describes the AGC software configuration management effort, with a lot of detail we hadn't had before, including numerous statistics and graphs about development time-frames, number of changes in each of the flight versions of the code, etc.  The "amazing" part is the description of the amount of AGC-software related material sent to the now-unfortunately acronymed ISIS over the years — magnetic tapes of software, 10,000+ records of individual software changes — along with the explanation that ISIS maintained a database of all this material.  If this database still existed and we could somehow get access to it, it would pretty much answer all remaining questions about the AGC code.  That's a mighty big "if", of course, and we have no idea how to go about it.
  • A couple of tables of AGC software releases have been added, from the document mentioned above, to the Luminary and Colossus pages.
  • The file of ZERLINA 56 octals is now present in the GitHub repo, proofed and with correct memory-bank checksums.  Thus in principle, you can now build octal ropes from it, using the oct2bin utility, and run ZERLINA in the AGC simulator, from the command line.  The proofing process was real torture, though, with enormous numbers of difficult-to-find errors, so correct checksums or not, I admittedly won't feel really good about it until the source-code transcription is complete.
  • You may recall that original AGC developer Allan Klumpp had a printout of LUMINARY 99 that he believed was the Apollo 11 flight code, but that we have never had the chance to scan (or examine) this printout.  We do know that he turned out to be mistaken, and that what he had was LUMINARY 99 Rev 0, whereas it was either Rev 1 or Rev 2 that actually flew.  It turns out that Mike Stewart has been able to recreate the source code for Rev 0, even in lieu of having the hardcopy!  We're pretty confident that the reconstruction is correct, because it makes sense and has all of the correct memory-bank checksums.  It's in the GitHub repository.  You can theoretically run it in the AGC simulator, from the command line.  The colorized, syntax-highlighted source code is also available.
  • A completed file of AP11ROPE octals is also now present in the GitHub repo.  As you may recall, there has been a certain amount of speculation as to which version of LUMINARY 99 flew in Apollo 11 ... was it LUMINARY 99 Rev 1 as we've been claiming all these years, and as documentation suggests, or was it LUMINARY 99 Rev 2 as Jim Kernan (the original "rope mother" for the Apollo 11 LM software) says?  The hope was that AP11ROPE might help resolve this question, given that it was printed long after Apollo 11 (namely, in 1970) and purports to be the mission code.  Thus if AP11ROPE were identical to our LUMINARY 99 Rev 1 code it would support the notion that Rev 1 was the one that flew, whereas if it were identical to our recreated LUMINARY 99 Rev 2 code (or at least relevantly different from Rev 1) then it might support the notion that Rev 2 is the one that flew.  Well, octal-for-octal, it turns out that AP11ROPE is identical to LUMINARY 99 Rev 1.  But it is not source-code identical; it appears to have been branched from LUMINARY 99 Rev 0 (not Rev 1) and then modified to bring it up to date with Rev 1, but not with identical program comments.  That being the case, it doesn't really imply much about whether Rev 1 or Rev 2 was used in the actual mission.  But it did turn out to be a nice, clean, easy-to-OCR scan, that should be very easy to use to route out lingering program-comment errors in our transcriptions.
  • A curious familiarization guide for the AGC has been added to the document library.  I don't know quite what to make of it.
  • Four new documents have been added to the document library, from UHCL and NARA Southwest, all having to do with ferrite-core memory-system properties, especially for the MOD 3C AGC.  The icon in the document library has now rolled over to July 2017, so these 4 docs are the only ones marked as "new", and hence are easy to find, so I won't list them separately here.
  • The scans for AGC program listings ZERLINA 56 and "AP11ROPE" are now available; the scanning was sponsored by Linden Sims and Vipin Rathor, respectively.  Thanks, guys!  Recall that ZERLINA is an "offline development" program that had been maintained by Don Eyles for experimenting with different types of improvements or fixes to LM software, and that AP11ROPE is actually a different printed copy of (we believe) the Apollo 11 LUMINARY 99 program we've already had for the last 10 years.  But we're not quite sure yet that AP11ROPE and LUMINARY 99 are exactly the same.  So we're going to check that (of course!), as well as to use it to cross-check yet again the existing transcription of LUMINARY 99. But there's no need to do a full transcription of AP11ROPE, unless we find out it's actually different in some way.  A transcription of the AP11ROPE octals will be done, though, as part of the cross-checking process.  ZERLINA, of course, we will be fully transcribing to source code, as well as creating an executable binary of it for the AGC simulator, starting immediately!  At any rate, as usual, the scans are available both in lower-resolution (smaller-size) JPG and in archival higher-resolution (larger size) JPEG 2000; the Luminary page details all of this, naturally, but here are the links, for your convenience:
The SUNBURST 37 AGC program's comment-text has now been completely proofed, and is in the GitHub repo, so the transcription effort for SUNBURST 37 can now be said to be 100% complete.  I've also updated the now-proofed color-coded, syntax-highlighted source code on this website.  As usual, the proofing data (based on octopus/ProoferComments) can be found in the GitHub wiki, for anyone inclined to double-check the work.
  • The complete LM-8 Systems Handbook has now been added to our document library, from scans made by the good folks at UHCL.
  • The icon, used in the document library, has now been rolled over from April-or-later to June-or-later.
  • A bug in the SUNBURST 37 octal listing (whose release was mentioned on 5-27, see below) has been fixed.  This was a marvelous and instructive typo in that it was a single-digit error that nevertheless did not cause a checksum error at runtime.  That's because of an ambiguity in the checksumming system built into the AGC code:  the checksum of a memory bank must be equal to either the bank number or else the negative of the bank number.  In this case, the error was in memory bank 1, and the single error (in which the octal was off by 2) flipped the bank checksum from +1 to -1.  This is a very rare type of error, but it's unfortunate that the system had that ambiguity.
  • And speaking of checksums, it turns out that over the course of time, the algorithm used by YUL to generate the memory-bank checksums changed slightly.  Prior to SUNBURST 116, I'm told, only the positive memory-bank values were used, but after that it was not always possible to generate the positive memory-bank values, and thus checksums for negative memory-bank values were generated when required.  yaYUL has thus been modified with an appropriate new command-line switch to enforce this difference, allowing the removal of an annoying workaround in AURORA 12.  (The assembly of both AURORA 12 and SUNBURST 37 are affected by this; the older RETREAD 44 has no checksums anyway, and so is not affected.)
  • And speaking of annoying workarounds, the annoying "SBANK= workaround" has finally been eliminated!  One of my more-irritating failures in writing the yaYUL assembler originally is that I was unable to figure out the scheme used by YUL/GAP to generate the so-called "superbank" bits in various address-generating pseudo-ops; in cases where the values of the superbits were actually important to the execution of the program, the bits generated by yaYUL were fine, but where they did not affect the execution, they were often wrong, and thus the code generated by yaYUL did not match the octals generated by YUL or GAP in those cases unless a handful of extra SBANK= pseudo-ops that weren't originally present in the assembly language code were inserted into our source code.  Personally, I simply threw up my hands in disgust with it, deciding to live with these extra SBANK= pseudo-ops, but over the years several people have worked on incremental fixes and removal of SBANK= pseudo-ops, never with full success.  Certainly, getting the original source code for YUL helped out a lot.  However, over the weekend, the problem seems to have been cracked, and the entire AGC code base, including all code versions that we have, now assembles to the proper octals, entirely without any extra SBANK= pseudo-ops at all.  There seem to have been several insights that contributed to this breakthrough.  Two stand out to my mind.  One is that if you actually look at a page of an AGC program listing (say, page 57 of LUMINARY 210), you may notice (I never did!) that there's a mysterious notation like En Sm, under the page numbers in the upper right-hand corners of the pages.  These turn out to be the memory-bank bits (including superbank assumptions) that YUL/GAP thought applied at that point; this observation gives a lot more visibility into what YUL is thinking at any given point.  The other observation that stands out is that the assumptions made by YUL for these bank bits changed at some point (between SUNBURST 37 and 120), so that a slightly different rule (and a different yaYUL command-line switch) applies to earlier code versions than to later ones.  Great work, guys!
  • Not only that, but the transcription of SUNBURST 37 source code is now complete, though I suppose I should admit that some of the comments in the code haven't been full proof-read for typos, so
Transcribed source code for Sunburst 37 is now available, as well as syntax-highlighted, colorized HTML.
  • SUNBURST 37 now builds by default when the code-base as a whole is built, and it is now enabled in the VirtualAGC GUI program.
  • As a result of the various changes mentioned above, the entire set of colorized, syntax-highlighted, HTML versions of the AGC source code have been updated on this website.  I also noticed that due to some file-name changes in the past, a handful of these files hadn't been viewing properly, so I've hopefully fixed that.
  • Fleshed out the writeup of Dario Kubler's DSKY with new images and videos on our physical-implementations page.
  • Niklas Beug has provided some fun information about flying simulated Apollo 5 and Apollo 14 missions, in spite of the fact that we don't presently have any (CM or LM) of the Apollo 14 software, and that while we have the Apollo 5 (LM) software we don't have the necessary pad loads for it.  It turns out that the NASSP developers have worked out tricks to create the pad loads for Apollo 5, and to modify the Apollo 15 CM and LM software's ephemeris data for Apollo 14, allowing both of these missions to be flown perfectly satisfactorily in the Orbiter spaceflight simulator with the NASSP add-on.  I've written up Nik's comments — or more acurately, cribbed from them verbatum — in the descriptions of SUNBURST 120 and LUMINARY 178 on our Luminary page and of COMANCHE 108 on our Colossus page.
Added a description of Dario Kubler's physical DSKY to the physical-implementations page, including a cute YouTube video.  Dario sent me most of this info several years ago, but I (stupidly!) failed to write it up; in fact, I think he sent me several more pictures that I need to dig out and include as well.
The octals for SUNBURST 37 (Sunburst32.binsource) are now in the GitHub repo, and have been proofed, and have correct checksums, so SUNBURST 37 can now presumably be run in the AGC simulator.  (None of this is built automatically nor integrated with the VirtualAGC GUI, so to run it you have to create the rope file with "Tools/oct2bin <Sunburst37.bin" and then run yaAGC from a command line whilst specifying the rope file oct2bin.bin for it.)

We're also transcribing the SUNBURST 37 source code from the scanned program listing now, so anyone interested in helping should head over to the GitHub repo and look at the instructions.

As I mentioned in my note from a couple of days ago, instead of locally posting individual page images for SUNBURST 37 in reduced-quality JPG form, which is my normal practice for all other AGC versions, I had instead simply locally reposted the PDF from our Internet Archive collection, thinking that it was "good enough".  In other word if you followed the links on our Luminary page, you'd probably end up downloading this supposedly-fine PDF. Well it wasn't good enough, so ... my apologies!  The PDF has weird artifacts in which some characters were frequently replaced by other characters, such as 'D' in place of 'O'.  Whatever the reason for this weird effect, it's obviously intolerable, so if you follow through the links to our locally-posted reduced-quality images now, you'll now find individual JPG pages.  The high-quality images in our Internet Archive collection don't have this strange problem, and so can be used without fear, but I definitely would not recommend using the PDF found there.

As a corollary, we now realize that Emerson was wrong, and that a foolish consistency may not be the hobgoblin of little minds, if the effect of that consistency is to enforce a tried-and-true method rather than succumbing to untested novelties without having a good reason to do so.
The program listing for AGC program SUNBURST 37 is now available, scanned for our Internet Archive collection from Don Eyle's hoarded copy, and financed by Peter McDermott!  Thanks all.  See our Luminary page.

As you may recall, SUNBURST 37 (also known as SHEPATIN 0) is an early version of the SUNBURST program, never used for any mission, though SUNBURST 120 was used later in the LM's AGC in the Apollo 5 unmanned mission.  Like RETREAD and AURORA, SHEPATIN is another "missing link" in the AGC software's evolutionary development.

As usual, we'll be producing an octal file for this (so that SHEPATIN can be run in the AGC simulator) as well as source-code files (so that we can do nice searching on it, have syntax-highlighted listings, and so on), but that will be a process that takes a bit of time.  Right now, all we have is the scanned pages.

I've departed from my usual practice of providing local low-resolution JPG page images here at our main website, and have instead chosen to use a PDF as the local "low quality, lower size" version of the scanned page images.  (The PDF was good enough, and I didn't feel compulsive enough to insist on turning it into JPGs.  As Emerson said, a foolish consistency is the hobgoblin of little minds.)  As usual, though, the full-quality scanned pages are available in our Internet Archive collection.
Added 3 more sections of the Apollo 9 LM GSOP (we already had 1 section, out of 6 sections total), as well as the AC/Delco study guide associated with that software version.  (Well, actually, the LM's AGC program was SUNDANCE 306 and the study guide is for SUNDANCE 302, but that's close enough for government work.  Literally.)  All were from the UHCL archives.  Added to both the document library page and the Apollo 9 entry on the Luminary page.
Two new CSM System Handbooks, and one new LM System Handbook, from the UHCL archives.  See here.
  • Surprisingly, the scanning of Volume I of the AGC LEM PGNCS manual (Volume II having appeared yesterday) has suddenly been finished.  See here
  • The scanning of Don Eyles's digital landing simulation for Zerlina 56 has also suddenly been finished.  The scanning techs at the Internet Archive must be busy little bees!  Zerlina, as you may recall, is a non-mission version of Luminary with which Don was exploring various new concepts for potential inclusion in Luminary.  (The scanning of Zerlina itself hasn't yet been done, but is scheduled soon.)  At any rate, I had apparently failed to provide an entry for Zerlina 56 on our Luminary page, but I've done that now, and you can consult it if can't wait for Zerlina 56 itself and you want to look at the digital simulation right away.
New documents added to the document-library page, but the most-significant is that our scan of Don Eyles's copy of the AGC LEM PGNCS Manual (Volume II) has now arrived.  As was speculated and hoped-for in advance, it does contain AGC Block II schematics missing from the previously-existing set of individual schematic pages from Eldon Hall's collection.  Moreover, it contains DSKY schematics.  See here.  In other words, we can now claim to have a full set of Block II AGC  and DSKY schematics.  (Though not Block I schematics so far.  Perhaps in the future.)
  • Nothing to directly to do with the AGC, but Don Eyles had a couple of old maps of Kennedy Space Center around, which he says are more detailed than others he has seen online.  He was kind enough to scan them for us, so they've gone into our document library and our Internet Archive collection.
  • A few months back, I mentioned a magazine article about the Virtual AGC project that I think is quite fun, but I couldn't provide a link since the magazine, Delayed Gratification, is print-only.  However, the magazine does put a few of their articles online, from time to time, and at least for the moment that has happened with this article as well.  You can check it out at this link.  The writer, Chris Bourn, has also written another article in which the Virtual AGC project appears, albeit in just a small role, since the article is about the relationship of story-telling to computer programming.  (I will mention that the way the articles ended up being written could give the impression that the Virtual AGC project is my personal effort as opposed to a group effort.  To anybody whose feelings might be hurt by that, I apologize in advance.)
The second (of two) volumes of the Spacecraft Operational Trajectory for Apollo 14 has arrived from UHCL, and has been added to our document library.
I submitted our speculations (mentioned a few days ago) to Don Eyles, about the reason the Apollo 11 and 12 digital simulations from his collection were made after the landings.  While he does not actually remember, he agrees that our speculations about Apollo 11 are probably right, but doesn't entirely like our speculation about Apollo 12 ... partly, I think, because my description introduced errors not in Nik Beug's and Mike Stewart's original explanations to me.  At any rate, I've rewritten both speculations on the Luminary page, in a way that gets closer to the truth about Apollo 12 than what I had mistakenly written before.
In the cross-platform VirtualBox VM which the downloads page recommends for most users, the light-weight browser (Midori) provided with the VM for examining AGC source code and various other purposes, has been exhibiting some anomalous behavior that I hadn't noticed before.  I think this may stem from the fact that in the VM releases I've made so far, a fairly old version of Midori is being used.  While I'll obviously fix this in the next release of the VM, the download page now includes the simple instructions for updating Midori to the latest version, which (so far!) seems to fix the problems that I've been able to reproduce.  In other words, if you have a version of the VirtualAGC VM that uses Midori rather than Firefox, go follow the instructions on the download page to update Midori!
  • 81 LUMINARY Memos (the remainder of Don Eyles's collection of them) have been added to that section of the document-library page.
  • The icon in the document library has now rolled over to April and beyond (as opposed to March and beyond).
As I mentioned a couple of days ago, the newly-added Apollo-era digital simulations of the Apollo 11 and 12 lunar landings were both made after their respective landings ... a few days after for Apollo 11, and a few months after for Apollo 12.  The speculation was that the Apollo 11 simulation was made to help investigate the 1201 and 1202 program alarms experienced during the landing, but we didn't have a speculation about the Apollo 12 simulation.  Well, Nik Beug (and Mike Stewart) have come up with a pretty-convincing explanation, namely that the simulation was for investigating certain proposed changes to the landing code, and the fact that it used Apollo 12 AGC code for that was really just coincidental.  You can read more of the explanation on the Luminary page.
Made a number of requested improvements to the pre-built VirtualAGC VM, as described near the top of the downloads page.  One of the more-significant improvements is an update script that makes it easier to update the VirtualAGC software within the VM.  This script can also be downloaded and used with older versions of the VM, as described here.
Two more lunar landing simulations, both from Don Eyles's personal collection and financially sponsored by Matthew Fite (thanks, Matthew!),  have now arrived.  As usual these days, these have been added to our Luminary page, and you can either view them there in convenient PDF form,
or else you can see them in their full, highest-quality glory in our Internet Archive collection.  Both simulations were made slightly after the landings themselves.
  • 3 more docs from the UHCL archives were added to the document library, namely one volume each (from the two-volume sets) of the operational trajectories for Apollo 14-16.  See here.
  • There's a new Linux installation package containing fixes for the VirtualAGC GUI desktop app, suitable for installation in the Virtual AGC VM.  It's not listed yet on the download page because I'm waiting for some feedback from people who are trying it out, but I think it's likely fine, and anybody who is too impatient to wait can get it here.  I'll write it up and generate Windows and Raspberry Pi installers after I'm more comfortable with the changes. The main change relates to the fact that we've now got so many different AGC versions available that the app's main window had become too big to display screens smaller than about 1280×1024. For screens smaller than that, the app will now automatically change the format so as to make its main window a lot smaller.  This works well for displays down to around 800×720 (if there is such a thing), but for anything smaller than that you'll still be out of luck.  You do lose the capability of running your own "custom" AGC software from the smaller-screen version of the GUI.  The changes are just to the VirtualAGC GUI, and not to any of the simulations, so there's still no guarantee that you can fit an entire simulation onto a smaller screen.
Another nice document from the UHCL archives, this time Delco's manual for the Block II Command Module guidance system.  We already had a fraction of a corresponding Block I document, but this one is about 20× larger than what survived of the Block I document, so it's a bit more useful.  Here's a direct link so you don't have to pore over the Document Library page to find it:
The "Programmed Guidance Equations for Skylark" document, divided into parts for size reasons, obtained from the UHCL archives, has been added to the document library and Colossus pages.  This document is specific to Skylark 48, which we currently believe is the CM AGC program used for Apollo-Skylab (and possibly for Apollo-Soyuz, though we really don't know).  Since we don't actually have any source code for Skylark so far, and since the "Programmed Guidance Equations" are a kind of pseudo-code description of the source code, I guess this is the next-best thing to having the Skylark program itself.  At any rate, here's a direct link:

The "Programmed Guidance Equations for Colossus 3" document, divided into 3 parts for size reasons (Part 1, Part 2, Part 3), scanned from the University of Houston Clear Lake archives, has been added to the document library and Colossus pages.

  • AGC CPU-simulation features:  As you may know, the AGC had the ability of being able to execute a different instruction (stored in the B/BRUPT registers) upon return from an interrupt-service routine (ISR) than was stored at the actual address at which execution resumed afterward.  In other words an ISR could load the binary value of the instruction it wanted executed upon return into the BRUPT register, and even though the RESUME instruction would cause the program counter to be loaded correctly, the binary instruction in BRUPT would be executed, irrespective of the value stored at the RESUME'd program-counter address.  This was originally not a "feature", but was simply a consequence of the fact that the next instruction to be executed is always decoded by the AGC during the execution of the preceding instruction, and thus the decoded next instruction needed to be stored somewhere during an ISR, and subsequently restored after the ISR had been completed.  Considered as a "feature", this is rather useless for ISRs, since all it can really do is crash the program or do something else that's unpleasant, but could be useful for something like a software-controlled interrupt, such as the EDRUPT instruction.  The EDRUPT instruction, seemingly created for Ed Smalley's AGC self-test code, though possibly never used by him at all, was not something that was really needed for anything, but was instead created (as Hugh Blair-Smith has said) "because he could".  At any rate, while I originally intended to implement this same behavior in the AGC CPU simulator, it caused difficulties for me ... and since it didn't seem to be used anywhere in the Luminary 131 AGC code I originally worked with, I simply disabled the feature entirely rather than try to figure out how it was misbehaving.  In other words, for all these years, yaAGC has simply been ignoring whatever is in the B/BRUPT registers.  At any rate, Mike Stewart, in his unswerving quest to make yaAGC work correctly as opposed to well-enough, and to agree in its behavior with the Block II hardware simulation, has now debugged this behavior and fully restored B/BRUPT/EDRUPT.  All known self-test software related to this behavior works correctly, yaAGC does agree with the hardware simulation, and the restored code has been tested multiple times in the NASSP Command Module and Lunar Module simulations.  In short, B/BRUPT and EDRUPT are back, baby!  Many thanks to Mike Stewart and the NASSP gang.
  • Downloads page:
    • Updated the VirtualAGC installer (again!), not only for Ubuntu (for the VirtualAGC VM), but also for Raspberry Pi.
    • We once again have an installer for Windows as well.  I discontinued this some time ago because it was such a hassle for me to maintain, but it's back ... at least for now.  As far as the Mac is concerned, well that's still too, too much for me to keep up with, so the installer for that is still discontinued, and not likely to be reinstated.
    • Updated the VirtualAGC VM, which is really what I'd prefer the casual user to use.  While for the most part the old VM could simply be updated with the Ubuntu VirtualAGC installer mentioned above, there are a number of other niceties I've changed, and not handled by the installer, such as:
      • Added Code::Blocks visual-debugging links to the desktop for many more AGC versions.
      • Eliminated the password entry associated with the screen-saver, which I hadn't realized was enabled.
      • Replaced of the Firefox web-browser by the Midori web-browser.  While I don't expect anybody to really be web-browsing from the VirtualAGC VM, the web-browser is used by VirtualAGC for presenting the AGC source code, and Midori is insanely faster than Firefox at doing this, as well as being less memory-hungry and disk-space hungry.  So using Midori is a win-win-win.
    • It is perhaps notable that the use of installer programs as such for the VirtualAGC package has now been discontinued, and what I'm calling "installers" are really just compressed archives of type "tar.xz", which the user must manually uncompress.  There is some slight loss of ease for the user, in that desktop icons and start-menu entries are no longer created automatically.  But there are compelling reasons behind this move.  The principal motivation is that a tar.xy archive tends to be about half the size of one of the old installer programs (currently 20MB vs 40MB), and it's much easier from a system-maintenance standpoint as well.  Thus, updating the "installers" more often becomes a more-attractive proposition.
  • Updated the VirtualAGC GUI program so that it now includes all of the various improvements to yaAGC, yaYUL, AGC source code, etc., since its last release (11/2016).  Specifically, all AGC missions that are available so far are now supported by the GUI program.
  • Updated the VirtualAGC installer on the download page itself.  This can be used to update the 11/2016 version of the VirtualAGC virtual machine to today's version of the software.  In a few days, I'll probably release an updated version of the VirtualAGC virtual machine as well, but since it's so big, I'd prefer to drag my feet a little on that, to make sure everything is "just so".
  • Regarding the SCB meeting notes added a couple of days ago, there was a foul-up and several of them were either missing or incomplete.  That has been corrected.  I don't mean the set is now complete in any absolute sense, but merely that it is complete with respect to what Don Eyles was trying to send us.
  • 70+ documents scrounged from NTRS (and one from UHCL) have been added to the document library as well.  Most of these are more from a desire to avoid the hit-and-miss and disappearing-document phenomena associated with NTRS, rather than being of tremendous individual significance (as far as we know!) right now, so I won't itemize them.  Look in the document library itself if you want to know what they are.  However, from the perspective of my quick, superficial once-over, a couple of the highlights are:
  • I've noticed for some time that there's a problem when I add lots of documents to the document library, because there's really no way to tell at a glance what has been added recently, and what has been there for a long time.  I'm trying out adding an icon next to recent additions to the document library, with a notation at the top of the document library page telling what time-frame the icon is associated with.  Right now, for example, everything added in March of this month (or presumably later if there is a later) is marked.  We'll see how well it works.  I've seen all too many sites where once something gets marked as "new", it may continue to be marked as "new" for years and years ... and obviously, that's not very helpful.  At any rate, this only applies to the document library page, and not to the website in general.
  • The Block 1 DSKY has been changed at GitHub, in that the behavior of its flashing VERB/NOUN indicators has been fixed.
  • The instructions for running the Block 1 simulation from a command line, on the Block 1 page, had several flaws, which have been fixed.
  • The USERS' GUIDE (Rev 1) document mentioned several days ago, while perfectly legible as it was, has been rescanned in places to eliminate crud that had gotten onto the scanner in some places.  There's no real need to re-download it, but if the artifacts on pp. 595 et seq. bother you, then do so.
  • The VirtualAGC GUI program (in GitHub, but not yet in the downloadable virtual machine) can now run Luminary 69, 116, 210, and SuperJob AGC versions, instead of forcing you to run them from the command line.  It also uses 4 different DSKY configurations as opposed to the previous 2 (LM vs CM), as described on the DSKY page.  In practice, this means that Luminary 210, Luminary 69, and Block 2 software prior to Apollo 7 are using a different configuration of DSKY warning lamps than would have been expected previously.
  • Don Eyles has sent over a few reports of Software Control Board meeting notes, now in our document library.  Yes, I know, exceedingly dull, right?  Well, not exactly!  As you may recall, we recently added a series of LUMINARY Memos to the document library ... an effort which is only about half-completed so far, by the way.  One virtue of these LUMINARY Memos was that if complete, they could be used to track all AGC software changes, so that we could get a much-better understanding of the changes from (say) Luminary 99 to Luminary 116 to Luminary 131 to whatever.  Of course, the LUMINARY Memos aren't entirely complete, either in their coverage of events, nor in our collection of them.  Well, the SCB Notes have a similar virtue, again if complete, in that they provide much the same information about software changes.  Moreover, since in theory every software change had to be approved by the SCB, there shouldn't be as much of a completeness problem in the notes themselves, though obviously we have every bit as much of a problem in the completeness of our collection of them.  In the case of SCB notes, though, they don't track changes like Luminary 99 → 100, but rather changes like Luminary 1B → 1C.  This still ends up giving us the mission-to-mission changes, even if not the fine-grained revision-to-revision changes.
Fixed a few more crummy hyperlinks on the document library page.
  • It has been pointed out to me that the document library contained a few of the missions' technical crew debriefings, but that several more were missing though available elsewhere.  So for the sake of consistency, the Apollo 12, 13, 14, and 16 technical crew debriefings have been copied from the Apollo Lunar Surface Journal (ALSJ) into our document library.
  • Corrected a few hyperlinks which pointed to files on my home computer rather than the website.  D'oh!  If only I had a dollar for every time I had had to fix that over the years.
  • The recent Users' Guide documents from Don Eyles, mentioned over the last couple of updates, turn out to have a handful of foldout pages which were getting messed up in the conversion of the document to PDF.  It has taken me several tries to get right (the problem being, apparently, that pages with aspect ratios more-extreme than 2:1 don't work right in the PDF), but I now have PDFs that I think are fully working.  The fix to the PDFs has messed up those pages in the online viewer in our Internet Archive collection (sigh!), but the foldouts still legible there, and I'm willing to live with that.
  • I've been chided for making it appear that the recently-added Programmed Guidance Equation documents from Don Eyles, for Luminary 1B and 1C, mentioned a few days ago, weren't very useful.  That's a fair criticism, so I've modified my comments.  While it is true that I think calling these documents the "Guidance Equations" is misleading, it would also be true that better titles for them would be "Pseudo-Code Descriptions of Luminary 1B" and "... 1C".  And that, of course, can make them very valuable for someone trying to comprehend the Luminary 1B and 1C programs.  As Don said when he gave them to me, "Now, you know, we [AGC developers] didn't ever use these documents; they were written afterward for other people" (or words to that effect, anyway).  But we are the "other people" in this little scenario, so while these documents may not be so important for Don, they may indeed be very important for us.
  • The Internet Archive's processing (mentioned in yesterday's update notice) of Don Eyles's big box of IL and MSC documents went much faster than I supposed, so I've now added the compact, text-searchable PDFs for all these documents into our document library and appropriate places on the Colossus and Luminary pages ... and of course, yesterday's links to our Internet Archive collection still work, but you can now find fully-fleshed out entries there rather than just my huge archival uploads of the scans.
  • It seems as though E-2280 "Solid State DSKY Study" didn't get added to the document library for some reason.  It has now.
  • Added a link to a nice documentary video about the Block 1 AGC and DSKY.
  • A few weeks back, original developer Jim Pennypacker had sent me his copy ("#1") of one of the Instrumentation Lab documents that we had only previously had a mutilated copy of ("#114"), namely R-531, "Whole Number Strapdown Computations".  While I had scanned the darn thing at the time, and uploaded the archival-quality scans to our Internet Archive collection, I had failed to replace the old, bad version in our document library.  D'oh!  Well, I've done it now.  It's an interesting concept that never made it into an actual spacecraft, but well-worth reading about.
  • Niklas Beug has made another video to supplement his previous Apollo 11 lunar landing simulation video (using Orbiter/NASSP/VirtualAGC/Luminary99), namely an Apollo 15 simulated lunar landing (using Orbiter/NASSP/VirtualAGC/Luminary210), and I've linked it at a couple of a strategic locations.  Here's a direct link to YouTube.  For my taste, it's a lot more exciting than the Apollo 11 landing (minus the 1201/1202 alarms and the boulder field at the very end of the Apollo 11 landing, of course), since you get to swoop in over the mountains; Nik indicates it's his favorite landing site as well.  As far as it being a favorite landing site is concerned: I don't know if it depicts a real event or not, but the Apollo 15 episode of From the Earth to the Moon dramatizes Dave Scott as arguing for this Hadley-Apennine site (vs a "safer" landing site) in the decisive site-selection meeting, presenting the argument that it's worthwhile exploring beautiful places.
  • I've done a lot of cross-version checking of our AGC source code (Luminary 69 vs Luminary 99 vs Luminary 116 vs Luminary 131 vs Luminary 210; Colossus 237 vs Colossus 249 vs Comanche 55 vs Artemis 72; and Luminary 99 vs Comanche 55), which has not only found various lingering errors (mostly look-alikes such as '0'⇆'O', '1'⇆'I', '.'⇆',', and so on), but more-importantly, insures consistency across AGC versions, hence reducing spurious "changes" for anybody who is interested in detailed tracking of changes from one AGC version to the next.  Consequently, I've updated our colorized, syntax-highlighted AGC program listings yet again.
  • Don Eyles has sent me a box of huge Instrumentation Lab and MSC documents, many of them 800-1200 pages, which I have scanned and uploaded as archival copies to our Internet Archive collection.  It will probably take the Internet Archive a week or so to process them all, and it is only after they've done so that we'll have nice, compact PDFs with text-search, that can be conveniently read, and which I would feel comfortable putting into our document library.  (Yes, it's shocking, I know, but the Internet Archive has better software for processing PDF files than I do!  Who would have thunk it?)  In the interim, I'll just give you the links to the Internet Archive pages for the documents, and if you're really keen to look at them, you'll just have to download and view the monster PDFs I uploaded there:
  • Finally, the team has finished the transcription of Luminary 116 from the printed program listing to source-code files that can be run through the assembler:
Transcribed source code for Luminary 116 (Apollo 12 Lunar Module
AGC)  is now available, as well as syntax-highlighted, colorized HTML.

  • Removed some unwanted personal references.
  • Updated syntax-highlighted HTML AGC listings.
Lately, there has been some confusion as to whether the Luminary 99 source code we have been providing is actually the code that flew in the Apollo 11 LM or not, due to AGC developer Jim Kernan's recollections that there are three different revisions of that particular code (Luminary 99, Luminary 99 Rev 1, and Luminary 99 Rev 2), and the only version we actually have is Luminary 99 Rev 1.  Well, on the balance of the surviving evidence, what we currently believe is that Luminary 99 Rev 1 did indeed fly in Apollo 11, but also that Jim's recollection is correct and that there's a Rev 2 that is "better" in a certain way, but which didn't fly.  But we have no physical printout for Rev 2.

The explanation is that the ephemeris data in Rev 1 is wrong, but not very wrong, and certainly good enough for a lunar landing.  Nevertheless, we know what the correct ephemeris should be, because it's identical to Apollo 12 and 13, so to celebrate that fact, we've artificially recreated Luminary 99 Rev 2 for you, as a mashup of 99 Rev 1 and Luminary 116, and we provide both Rev 1 and Rev 2 for you.  You can view the source code or simulate either one to your heart's content.  You can take your pick.  It's called "choice", friends!  We've named Luminary 99 Rev 2 "LUM99R2" in the GitHub source tree, because that's what Jim's story says he called it, way-back-when.

We have also received new information about where a program listing for Comanche 44 exists.  Comanche 44 did not fly on a mission, but Comanche 45 Rev. 2 (which is 2 months younger) flew in the Apollo 10 command module, so if we can get our hands on Comanche 44 some day, it may be the closest thing we'll ever have to Apollo 10 Command Module software.  At any rate, the Colossus page has been updated with this info.
  • Proofing of Luminary 131 comment text (vs our new scan of the program listing) is finally complete.  The proofing data has also been uploaded (see our GitHub wiki for both a description of the method and a link to the proofing data), in case you suddenly have an urge to double-check it.  The comments in the source code undoubtedly still have quite a few errors, but after the transcription effort for Luminary 116 has been completed, I intend to do a 3-way check of it vs Luminary 99 and 131, which should eliminate quite a few of the remaining errors.  This actually means that all of the fully-transcribed AGC source-code versions have now been completely proofed in their comment text, albeit not all to the same standards, due to differences in printout- and scan-quality.
  • As usual, the proofing of Luminary 131's comments revealed various corresponding errors in the source code for other AGC versions, and those errors have been fixed as well.  Consequently, there have been quite a few updates (not the least of which is Luminary 131 itself) in the colorized, syntax-highlighted versions of the the AGC assembly listings.
  • I noticed that a lot of the volunteering page was still out of date, and hopefully that's fully fixed up now.
  • The limitation on following certain hyperlinks on the staging version of this website, caused as a by-product of certain improvements (see 2017-02-17), has now been fixed.  I think.  If I did it right, all hyperlinks on the staging website should work, but some of them will point to the main website rather than the staging website.  Hardly any of you will have noticed the problem anyway, so you can really just ignore this note.
  • Weirdly, on the Colossus page, I noticed that my description of Apollo 12 didn't show a Colossus revision number at all, while Apollo 13 showed Apollo 12's revision number, and Apollo 14 showed Apollo 13's revision number.  Yikes!  Anyway, that has been fixed.
  • Added a couple of nice, new documents to the document library, along with references to them on the Luminary and Colossus pages, where appropriate:
  • A number of documents salvaged from NASA's now-crippled NTRS system are in the process of being added to the document library, although at this point it has mainly been a bunch of Instrumentation Lab status reports to NASA ... interesting if you are keen on that kind of thing, but not chock-full of useful technical data.  They do track the number of words of AGC memory used for implementing various areas of functionality over time, which had fairly-important design consequences, so they are certainly useful in that regard.
  • Belatedly realized that we already had a non-Raytheon document associated with the experimental Auxiliary Memory (AM) which the Raytheon-written AGC program SuperJob (announced here a couple of weeks ago) tests and demonstrates.  The document in question, an Instrumentation Lab document, E-2254, is actually extremely informative, so I've linked it in with the general information about SuperJob on the Luminary page.
Don Eyles has squirreled away ~200 "LUMINARY Memos", out of the ~250 such memos that are known to exist.  These are documents that the MIT Instrumentation Lab used to track the development of the Luminary software.  Don has scanned around half of these for us so far, with the other half presumably forthcoming within the next few months.  To handle this vast glut of incoming documents, I've given them their own section in the document-library page.  There's lots of notable stuff there, but what stands out for me are:
  • There are many, many memos describing the changes incorporated into various builds of the Luminary software, starting with Luminary 4 and ending up with Luminary 209.  Since one of our long-term goals here is to understand how the AGC software evolved over time, this is naturally a huge help.
  • There are a number of memos that give us more insight into what Zerlina is doing, and how.  You may recall that Zerlina was an experimental program, branched from Luminary, and used to experiment with a number of new approaches.  Furthermore, we will be obtaining Zerlina within the next few months, and going through our usual process of transcribing it into source code and running it in the AGC simulator.  So it's nice to have some idea of what we can expect it to be doing.
  • I belatedly realized that some changes made to this website a few months ago to enable full functionality of the "staging version" of the website (at our GitHub repo) actually destroy the ability to correctly mirror the main website or to run it from local storage without an internet connection.  That has now been fixed.  However, the staging website will no longer be full-functionality, in the sense that clicking within it to links in our document library will no longer work, because the (~11GB) document library is not itself stored on GitHub.
  • I also belatedly realized that a different change to the website a few months ago, using a bit of JavaScript to make sure the banners on all of the sites pages were identical and easy to maintain, obviously would not work if JavaScript was disabled, and would simply make the site unnavigable.  That has been fixed, so that the site is at least minimally navigable (and displays a warning message) if JavaScript is disabled in the browser.
  • Added a few more factoids to the FAQ (FAQtoids?) about mirroring the website, privacy concerns, associated websites, and so forth.
  • Added yet another amusing anecdote about TRW's John Norton to the FAQ.
  • For all of the AGC program listings which we've had scanned in the last 6 months or so (which is a lot!), we've only been hosting reduced-quality (though adequate) page images here at our main website, while the full-quality scans have been available instead at our "collection" in the Internet Archive.  However, that hasn't been quite true for the AGC scans we made prior to that  (Artemis 72, Colossus 237, Colossus 249, Comanche 55, Luminary 99, Solarium 55).  For those AGC scans, we've been hosting just the low-resolution imagery.  The higher-resolution raw data from the scans has existed only on my own personal computers and backups, though you could have gotten it from me if you asked for it.  Well, that situation has changed, and I've now uploaded all of the raw scan data to our Internet Archive collection.  Now, I'll have to admit that, archival format or not, the visual quality is still rotten in comparison to the new scans, because I didn't understand things like white-balance settings when I took the pictures.  Nevertheless, all of you (rather than I alone) now have access to the best-quality imagery available.  Furthermore, in the future, I'll also be doing the same with any image files sent to me or that I personally scan. Incidentally, since AGC listings are big documents in comparison to what the Internet Archive normally handles, the initial processing on them may not yet be complete on all of these uploads if you rush over there right this instant to look at them; if the initial processing isn't complete, only the actually-uploaded data (gigantic PDFs 250MB-1.5GB in size) will be immediately accessible.  After the processing is completed, you also have a convenient online flipbook viewing interface, a zipfile of JPEG2000 page images, and a more-compact PDF with searchable text.  Solarium 55 is definitely ready for viewing at the moment I'm writing this, and the others should gradually become available over the next few days.  Documents I end up scanning but which turn out not to be suitable for Virtual AGC proper, will simply remain in the Internet Archive collection; for example, you'll find a Shuttle document there that I happened to scan while scanning some AGC-related documents.
  • I've also been busily correcting all of the metadata for the scans hosted in our Internet Archive collection, since we hadn't initially provided very good data at the time archive.org was making the scans.
  • Three new documents pertaining to Apollo 4, 5, and 6 have been contributed by AGC developer Jay Sampson.  (Refer to the Sunburst 120 section of the Luminary page, and the Solarium 54 and 55 sections of the Colossus page.)
  • Original AGC developer Jay Sampson has convinced us that the AGC versions used for these two missions (Solarium 54 and 55, respectively) are in fact identical though assigned different build numbers.  In other words, we in fact have the AGC source code for Apollo 4, even though we didn't know we had it.  I won't proclaim that discovery in a big box just yet, though!  You can read the explanation in the Solarium 54 entry on the Colossus page.
  • Original AGC developer Peter Volante has sent me a variety of organization charts for the Instrumentation Lab's Apollo development, which help to show how the organization evolved over time, and how the people within it moved around.  I've added them as complementary to the list of developers gleaned from the AGC source code, in the Acknowledgements section of the website's home page.
  • Some documents salvaged from NTRS were added:
    • Clean copies of R-500, volumes 1 and 2.
  • Added an Internet Archive link to the headers on all the pages of this site, to take you directly to our "collection" at archive.org.
A number of new documents for the document library were added.  Highlights are:
  • I forgot to mention it, but proof-reading the program comments in Artemis 72 (Apollo 15-17 LM) has now been completed, and the improved source-code files have been available in our GitHub repo for a few days.  The quality of the scan or the printout from which the scan was made was pretty poor, though, so there are likely to be more errors remaining than in many of the other AGC versions.  Nevertheless, there's a great improvement.
  • We have had Luminary 131 (Apollo 13 LM software) scanned from a copy in Don Eyles's possession.  Old-timers here may recall that the availability of a Luminary 131 scan was what enabled this entire Virtual AGC project in the first place, back in the day, and without it, none of this mighty empire of AGCosity would exist at all.  Nevertheless, there's no getting around the fact that that original scan was miserable in quality, barely legible, and practically a study of how a scan of a color document shouldn't be.  In fact, many of the errors in AGC program comments I mentioned above, and have been mentioning for the last several months, stemmed originally from that very unreadability, but the new scan will now be used to finally eliminate those errors from our Luminary 131 source-code files.  So we're lucky that we now have a really great scan.  Check it out in our local "low" quality version, or in the higher-quality version at archive.org.
  • New documents in document library:
  • Added various additional comments from one of the original authors (on the document-library page itself) for the rendezvous-procedures document I added yesterday.
  • Finally got around to putting a table of contents in the FAQ; it was simply too unwieldy without one.
  • Added various material from AGC developers and other correspondents to the Tell Us More Amusing Stories section of the FAQ.
2017-02-10 Added a cool document to the document library, "LM Rendezvous Procedures, G Mission" by Grega and Neily, which should be very useful for anyone wanting to fly simulated G or H missions, and likely J missions ... i.e., Apollo 11-17, though 11 and 15-17 are the only ones of those for which we have both the CM and LM software at present, and hence the only ones for which you could presently do a rendezvous.  Thanks to Clark Neily for sending this!  Even if you're not interested in rendezvous procedures, check out the document's title page for a real hoot.   More material related to this topic will be forthcoming in the near future.
2017-02-07 A very significant LVDC-related document has been added to the document library, namely IBM's "Saturn Instrument Unit LVDC Equation Defining Document (EDD) for the Saturn IB Flight Program", divided into 7 PDFs due to its size:  1, 2, 3, 4, 5, 6, 7.  Thanks to Riley Rainey for acquiring this, and the University of Alabama Huntsville's M. Louis Salmon Library for making it available at the U.S. Space & Rocket Center archive.
  • Although it's not necessarily usable in the AGC simulator yet (because the simulated resources for it don't exist), I think we can now say that
Transcribed source code for SuperJob (Raytheon's Auxiliary Memory test
program) is now available, as well as syntax-highlighted, colorized HTML.

  • Niklas Beug has been looking at the archives of the University of Houston, Clear Lake (UHCL), and with the assistance of the very helpful archivists there has found some documents of interest to us.  The first of these (with apparently more to come) have arrived, and naturally have immediately been put into our document library:
    • The previously-missing section 5 (Guidance Equations) of the Skylark (Apollo-Skylab and Apollo-Soyuz CM) Guidance System Operations Plan (GSOP).
    • CSM/LM Spacecraft Operational Data Book, volume I, CSM data book, Part I "Constraints and Performance", rev 3.  (Previously we had only volume III, Mass Properties, rev 2.)  Interestingly, the document has Appendices for CSM 109 (Apollo 13), 110 (14), 112 (15), 113 (16), and 114 (Apollo 17), though the table of contents says incorrectly that 109 and 110 have been deleted from the book.
As I mentioned a few days ago, our scan of the 1971 simulation of the Apollo 11 landing leaves somewhat to be desired in terms of the readability of the text ... it's just too light for comfortable reading, because the printout was too light.  Thus, to compensate for that, I had provided a highly-processed B&W PDF that is much-more readable.  Well, I've now done some additional processing on the color images, to enhance the readability to the best of my admittedly-meager abilities, so I've posted the reprocessed color images as an additional alternative.  They're not uniformly good, but I think they're an improvement over the full-resolution scan at archive.org.
  • Another digital simulation, this time of the Apollo 17 landing, also from Don Eyles's personal collection, with the scanning again financed by Fabrizio Bernardini, is now available on our Luminary page.  Thanks again, Fabrizio!
  • I was mildly chided for not including the link to the local B&W imagery for the Apollo 11 landing's digital simulation that I announced last time.  I did this intentionally because it's a 92MB PDF file that I didn't want to be idly downloaded, so I wanted you to go to the Luminary page if you were interested ... but that's daft reasoning, and all you needed was a warning that it's a big file.  Here's the direct link to the PDF.  (In contrast, the Apollo 17 link above is to a folder full of JPGs.)
  • The first of several digital simulations of moon landings that we're having scanned from Don Eyles's personal collection has finally arrived.  This first one, done in 1971, is of an Apollo 11 landing.  Thanks to Don and to Fabrizio Bernardini for financially sponsoring the scanning.  Note that it is presently mislabeled in the full-color scans at archive.org as "Luminary 131", and the sponsorship is misrepresented, but presumably this will be fixed soon.  The scans are also very low-contrast and hard-to-read, so I've provided reprocessed B&W imagery to get around that.  Read the Apollo 11 entry on the Luminary page for lots more info.
  • A very interesting AGC program written by Raytheon rather than the MIT Instrumentation Lab has surfaced.  (It was actually buried as an appendix to a Raytheon document on the NASA's now-defunct technical reports server, NTRS, which of course made it almost but not quite impossible to find.  But better late than never!)  We've dubbed this program "Super Job" because of the markings on it, though it's hard to believe that Raytheon actually called it that.  At any rate, there's lots more to read about it on the Luminary page.
  • The proof-reading of the transcribed source code for the Luminary 69 program has finally been completed, so I'm now making an official announcement:
Transcribed source code for Luminary 69 (Apollo 10 LM) is now available, as well as syntax-highlighted, colorized HTML.
  • Due to the fact that some comment-text errors discovered in proofing Luminary 69 occurred in other AGC transcriptions as well, there are a number of updates to the source code and syntax-highlighted HTML for a number of other AGC versions.

  • Have largely rewritten the "hoax" section of the FAQ.  Apparently, when I first wrote it, I had resorted to a lot of sarcasm that seems very harsh now, though sadly no-less correct.  There's also new material in it, so the section is substantially larger than before.
  • Also added tindallgrams.net to the list of recommended external sites.
All sponsorship opportunities for the Don Eyles's scannable materials offered so far — there are other, smaller docs remaining, but they aren't cataloged yet — are now taken.  So if you were keen to help with that ... too bad!  I like to think there will be more opportunities in the future.  And it's great news.

I've accordingly removed the giant Volunteering Opportunity note that had been stuck at the top of the home page, though you can still read all about it if you like.
  • Several early GSOPs (Guidance System Operations Plans), or sections thereof, have been added to the document library and Colossus pages: 3 different revisions of the complete AS-202 ("Apollo 3") GSOP, volume II (though still no volume I) of the Apollo 1/2 GSOP, and volume II (we already had volume 1) of the Apollo 4 GSOP.  There is also an updated rev (11→14) of the "Digital Autopilots" section of the Apollo 15-17 GSOP.  Incidentally, it may be worth noting that many documents from the now-apparently-defunct NASA NTRS technical-documents server are showing up at archive.org (no, you don't have us to thank for that).  It's a bit tricky finding anything in that collection, perhaps more so than even the NTRS server was, so if you find any Apollo or Gemini related software or software-related docs there that aren't already in our document library, do let us know.
  • Probably more importantly, the transcription of the Luminary 69 (Apollo 10, mostly) AGC source code has been completed, put into GitHub, and assembles properly.  Comment-text proofing still remains, so I guess I'll hold off on making a big deal of it until that has been completed as well.

As you may have seen in the notes made here over the last few months, I have been in the process of proofing and correcting the comment text in the various source-code transcriptions we have made of the AGC program listings available to us.  Hitherto, we had no efficient way to do this, but had developed a tool for doing so that worked quite well on most of the of program listings, with newer scans tending to work much better than older ones ... hence in doing this proofing, I found myself working backward in time, progressing from the latest AGC scans to the earliest, finally reaching the original scans with which the Virtual AGC project started, namely Colossus 249 (Apollo 9 CM) and Luminary 131 (Apollo 13 LM), as well as the somewhat-later Artemis 72.  The scans (or the associated printouts from which the scans were made, or the destructive OCR processing done on them) for Colossus 249 and Luminary 131 are so bad that the "efficient" proofing tool cannot be applied at all, while Artemis 72 is highly questionable.  Thus, a different and more time-consuming proofing process was required.

I have just completed proofing Colossus 249, and the results are available in GitHub now.  What has been done with it is to note that Colossus 237 (which preceded it chronologically by a short time), and Comanche 55 (which followed it chronologically) had already been proofed using the "efficient tool".  A 3-way side-by-side "diff" between the transcribed source code from these three AGC program versions was done.  This highlighted places where errors (many, many errors) might exist.  An extremely-large number of errors was corrected in Colossus 249 in this way, along with a (much smaller) number of errors that lingered in the already-proofed  Colossus 237 and Comanche 55.

This proofing process also benefited from the availability of an alternate scan of Colossus 249, not available originally, but available nowadays from the collection of AGC developer Fred Martin.  Thus, many parts of the original scan that were garbled to the point of illegibility, could now be filled in with absolute certainty.

More than you wanted to know, probably, but having just finished it, I'm still excited about it!  :-)  

A similar 3-way proofing of Luminary 131's comment text awaits availability of comment-proofed source-code Luminary 116 and Zerlina (derived from Luminary 145), neither of which is available now, but both of which are expected to be available within a few months.  Unfortunately, for Artemis 72, the last Colossus version, there is no prospect of a 3-way diff with predecessor and successor versions, but merely a 2-way diff against a predecessor version that may not be a closely-related as we would hope, so it will probably come last of all.  But we'll see what we'll see.
I've added a few "new" names to the list of AGC developers, relayed to me by developer Henry Noble, who also wasn't yet on the list.  This reminds me that the original list I made only took into account the names I found within Luminary 131 and Colossus 249 ... whereas we actually have lots and lots more AGC listings now, so I should go through all of them and pull out more names!  And, I ought to add their affiliations, when they're known; thus Henry worked at Raytheon.  But I haven't yet done those latter things.

The web-pages themselves have been internally cleaned-up in terms of their HTML coding.  Hopefully, this has been done in a way that is 100% transparent to anybody viewing them, but it's always possible that problems might have been introduced in the process.  Obviously, let me know if you see anything funkier than you expect!

The licensing on all of the pages has also changed, from what (in the U.S.) would have been an implicit copyright by me (Ron Burkey), with all rights reserved, to a Creative Commons No Rights Reserved license.  This is equivalent to being in the Public Domain in the U.S., and is the closest equivalent to that in parts of the world where the concept of the public domain is not recognized.  I learned this from something Nina Paley wrote in connection to her marvelous animated film, Sita Sings the Blues ... which, if you've not seen it, you should!  She had originally released it for free under the Creative Commons Attribution Share Alike License, which already was unbelievably brave, but still had the effect of reserving some legal rights for herself.  But she later concluded that since she knew she wasn't going to sue anybody for breaching the license anyway, what was the point of reserving any rights?  So she simply changed the licensing in the same manner I am doing now.  (Of course, I don't claim to have to have the guts she does, since I derived no financial benefit from this website anyway, so the licensing is irrelevant to my checkbook.)

Comparably gutsy to Nina's film is Kimiko Ishizaka's release of her piano renditions of Bach's Goldberg Variations under this same CC0 license.  Highly recommended.  I'm not sure of the licensing used for her later recordings of Book I the Well-Tempered Clavier or the Art of Fugue, though Wikipedia claims that the Well-Tempered Clavier has indeed been released to the public domain as well.  Kimiko is a German-Japanese, former Olympic bronze medalist in powerlifting, and concert pianist, which is pretty interesting in itself.
  • The original Colossus  249 and Luminary 131 scanned material which we started with, way back in 2003, as well as the improved replacement Colossus 249 scan we made of Fred Martin's program listing, has been completely restructured so that it conforms to the same pattern as all of the other scanned AGC program listings: i.e., it now consists entirely of PNG files, one per each page numbered by the original assembler, and no PDF files at all.  A side benefit is that while the original print/scan quality has naturally not improved, the quality of the images we're providing has nevertheless improved anyway, whilst decreasing the actual file sizes.  At the same time, page-number references in the Colossus 249 and Luminary 131 transcribed source-code files, which previously corresponded to the PDF page-numbers in the gigantic now-irrelevant all-in-one PDF files downloaded from the now-defunct History of Recent Technology website, have been changed so that (like all other AGC source-code listings) they correspond to the page markings on the original printed pages of the program listings.  My motivation for all of these changes is that I intend to begin proofing the comment text in the Colossus 249 and Luminary 131 source-code files by cross-comparing them with similar AGC versions like Colossus 237, Comanche 55, and Luminary 99; that kind of cross-checkout would have been greatly hampered without the changes.  Moreover, if we manage to get Don Eyle's Luminary 131 listing (which we don't yet have a sponsor for, by the way), the checking that that scan would enable would also have been hampered.  However, even without such motivations, the overall effect of the changes is still to make the Colossus 249 and Luminary 131 material better and more accessible.
  • I guess I've forgotten to mention any of the newspaper, magazine, or online articles in 2016 in which our Virtual AGC project played an important role.  Of course, I don't necessarily know about all of them, since I don't spend a lot of time scouring the web for news about the project or about myself.  The best-known is probably the article titled "BURN, BABY! BURN! The code that took America to the moon was just published to GitHub, and it’s like a 1960s time capsule" at Quartz.  That one was fun for me, because various people stopped me or telephoned me to say "hey, is that you?"  But for my taste, the article which has just appeared in the current issue of the U.K.'s Delayed Gratification magazine, called "Houston, we have a program", is a lot more fun, for a number of reasons.  Not least is that the article is really about our Virtual AGC project, rather than being primarily about Apollo 11 or the AGC software for Apollo 11.  But also, I think the article is extremely well-structured and entertaining, much more so than the endless, detailed blathering I output by the ton here at our website, so it's a fun read.  I congratulate the writer, Chris Bourn, for the care he took, and the results he achieved.  You may notice I've provided no link to the article, though.  That's because Delayed Gratification is a print-only magazine, supported by subscribers rather than ads.  They only put a handful of sample articles online; perhaps ours will some day be one of those (I hope!), but perhaps not.  The magazine itself has a very intriguing concept: it is a proponent of something called "slow journalism", which is basically a throwback to the old days when journalists were supposed to do thorough fact checking, editors were supposed to edit, and so on, as opposed to today's situation, in which articles are thrown together as quickly as possible (probably by cutting-and-pasting unsubstantiated material), in order to maximize online ad revenue.  In contrast, Delayed Gratification boasts that it is the last to break a story, rather than the first to do so. There's also an interesting TED talk about the concept of slow journalism:

Colossus 237's source-code's comment text has now been completely proofed, and its proofing data published online, should you choose to do a proofing pass on it yourself.

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?
Hide 2003 change notes?

This page is available under the Creative Commons No Rights Reserved License

Virtual AGC is hosted
              by ibiblio.org