• Two Skylab-3 checklists
• Delco booklets for Apollo 15 and 17
• Section 4.2 through the end of the OWS Design Data Document for Skylab (sadly the guy I got this from has no idea where everything before section 4.2 went, but he's pretty sure he never had them).
• Apollo 10 Commentary, which is largely transcripts from the mission
• Mission J1 G&N Error Analysis
• Case History of the Apollo Guidance Computer - we already have a scan of this, but it's one of those that was ravaged by OCR text replacement
• The final report on the assembly and test of five IRIGs with size R-4 ball bearings

• I realize belatedly that I've been handling fixes to Virtual AGC stupidly.  There's a problem-reporting system associated with our GitHub repository, but if someone has directly reported a problem to me I've just tried to handle it directly with them, and if that's successful there's never any problem report generated.  Why that's dumb is that since there's no paper trail on it, there's no good way for anyone to know what problems have been fixed in what revisions of Virtual AGC, or even if they've been fixed at all, and hence no way for them to know if it's worth updating their Virtual AGC installation.  Even I don't know, half of the time.  D'oh!  Please create problem reports, even if you're going to communicate with me directly.  If you don't, then I'll have to do it for you, and I'm really lazy so I don't want to!  For myself, I'll try to make a better effort on this, until it loses its urgency and I forget all about it.
• I realized this while dealing with problems reported directly to me that the LM_Simulator component of Virtual AGC doesn't work in the latest version of Tcl/Tk, and that Tcl/Tk doesn't work at all in any recent version of Mac OS.  While researching the fixes that had to be made, I realized I had no way to backtrack through earlier versions of Tcl/Tk to see if my fixes would break LM_Simulator in them or not.  It's not the same thing as the problem-reporting issue in Virtual AGC, of course, but it pointed a big "j'excuse!" finger directly at me anyway.  Speaking of which, issues #1234 and #1235 (the Tcl/Tk/Mac OS problems just mentioned) have been dealt with, and you should check them out if you've experienced either problem.  Not only that, but it turns out that up to now the installation instructions for Windows haven't mentioned that Tcl/Tk needs to be installed (issue #1237).  So that's fixed too.
• Some corrections were made (issue #1238) in the drawing-tree drilldown for AGC model 1003565 and to the guidance-system drilldowns containing it (principally, mission AS-202).
  
• Okay, enough of the meae culpae!  Mike Stewart has sent over a few new documents for the library, all of them Pratt&Whitney reports on Apollo CSM fuel cells.
  

Aside:  I don't know if that's correct Latin or not, since I've forgotten all the Latin I learned 50 years ago, but it's more fun than "mea culpas" as most google hits recommend.  See here.  I think "mea culpas" actually makes the most sense, though, on the notion that "mea culpa", in spite of its appearance and history, to English speakers is nowadays a single English word rather than two Latin words.    As for the French, I have even less excuse for "j'excuse!" since I don't recollect ever learning any French at all.  But I digress.

... our little project is wrapping up successfully.  It has been an absolute joy to program on this computer.  We'll be presenting a talk about bare-metal programming of the AGC at next weekend's Vintage Computer Festival here in Switzerland.  I'll send you the video once they post it.

The tic-tac-toe game is fully functional and available here.  The + and - buttons switch between one or two player mode.  The reset button starts a new game. ...  There's also a random die (D6) application in the same directory that serves as a good demo of minimal DSKY I/O, alarm suppression, and random number generation.

• I've noticed that the description on our developer page about how to use the our library functions agc_xxxx() to create your own AGC emulator in place of yaAGC inaccurately describes how the critical function agc_engine() is supposed to be used.  If you actually used my instructions — and somebody was! —, it would have worked but the timing wouldn't have synchronized with real time very well.  That's fixed now.  You may wonder why you'd want to do such a thing anyway!  It's the kind of thing you'd want to do if, for example, you were making a model control panel which embedded an AGC emulation within it rather than as a separate program.
  
• Mike has sent over 3 new documents for the library.
• The page concerning Verilog-based digital simulation of the AGC electronics is undergoing substantial rework due to the issues I mentioned a couple of days ago.  I mention it not to call those changes to your attention — they're not ready yet! — but rather to point out that the page isn't currently fully reliable.  Alas, my workflow doesn't allow me to easily post the changes I mentioned above without posting the incomplete Verilog-page changes as well. 
  

• "Apollo Soyuz Test Project (ASTP) Manual".  This is one of the series of books in our library, published by Delco Electronics, seemingly one for each mission, that provide elaborate technical summaries of the flight software and hardware subsystems of the CM/LM guidance systems.
• The LVDC Equation Defining Document (EDD) for AS-501 (i.e., Apollo 4).  What's so exciting about this is that it's the very first Saturn V EDD we've gotten, in contrast to the Saturn IB EDD already in our library.  Apollo 4 was the very first Saturn V mission, so I suppose we can expect that the EDD had a few teething difficulties.  For example, the memo that formally approved this EDD warns us not to take the EDD too literally, because "since [publication], 45 engineering change requests and 49 engineering change proposals have been processed in regard to the 501 flight program".  Still, I'm not going to turn up my nose at it!

There have also been various corrections to the main website page and the download page, thanks to Gavin Eadie.

• Mike has sent over a few new docs for the main document library and the shuttle library.  Check them out!
• Having had the chance to look at it in some detail after mostly ignoring it for a long time, I have come to realize that Virtual AGC's installation instructions and graphical-interface applications (such as the simulated DSKY and the telemetry monitor) had rotted somewhat over time.  While still mostly functional, they had nevertheless degraded from "acceptable" to "positively crummy".  This was partially due to neglect on my part.  But it was also partially due to the relentless march of time, over the course of which operating systems had evolved, and software libraries which I had depended upon had been obsoleted and replaced by other versions of those libraries that didn't work quite the same way.  Then too, there was the availability of 4K displays for desktop systems, with the consequence that software not prepared for 4K had acquired very, very tiny user interfaces.  The upshot of all this is that I have spent a fair amount of time revising all of the graphical user interface (GUI) code for Virtual AGC programs, so that these programs now look fine on all of the Linux/Mac/Windows systems to which I have access, with either "normal" or 4K displays.  To support the possibility of high-DPI displays, these programs now all rely upon a new environment variable (AGC_SCALE) which can be assigned a number such as 1.5 or 2.0, the default being 1.0, by which the sizes of all of the Virtual AGC user interfaces are new automatically scaled.  The same scale is applied to all Virtual AGC programs, but doesn't affect any non-Virtual-AGC programs.
• Another thing is the transcriptions we've provided of AGC/DSKY electrical-schematic drawings into computer-aided design (CAD) files for use in the open-source KiCad EDA system.  When those transcriptions were done back in 2018 or 2019, KiCad v.5 was still a new thing, whereas nowadays KiCad v.8 is current and v.9 is in development ... but the format for the schematic files was 100% changed at v.6.  While the new versions of KiCad can still read my old v.5 transcriptions and convert them to the new format, as always with these things the conversion isn't guaranteed to be 100% perfect.  Mostly; but not quite.  So I've put in quite a bit of work — recall, or be informed, that there are about 140 transcribed drawings, most of them with multiple sheets — doing the manual adjustments to make sure those conversions are indeed exactly right after all!
• And then there's our Verilog-based digital simulation of the AGC electronics, based on the CAD transcriptions I just mentioned.  Well, it turns out that the Python scripts used to process the schematics in order to produce the needed Verilog source-code files don't understand the new format of KiCad's schematic files!  So Verilog simulations will be on hold for a while until I fix up those Python scripts.  Hopefully that'll be in the not-too-distant future, but I haven't started on it yet.
• And speaking of Python scripts, most of our Python scripts are written for Python 3, but a few older scripts based on Python 2 have persisted, since it has always been possible to install both Python 3 and Python 2 on your computer and have them coexist in harmony.  Or rather, it had been possible to do that until recently.  Some newer operating systems like Ubuntu 24 not only don't install Python 2 in their default configuration, but don't allow you to install Python 2 at all, not even as an option.  Or at least not without circumventing the steps they've taken to stop you from doing it, and thus taking the chance of breaking your system in the process.  Apparently, that lack of Python 2 bothers nobody but oddballs like me.  The bottom line is that all Python 2 scripts in Virtual AGC have to be converted to Python 3.  I've done some of them so far.  Others will take longer.
• And yet one more thing!  Eight or nine years ago, tired of supporting all of these various computer platforms (Windows, Mac OS, FreeBSD, Solaris, ...) which I never use personally if I can help it, I got the bright idea of dropping direct support for them, but instead providing Virtual AGC as a virtual machine (VM) that could be downloaded and run in hypervisors such as VirtualBox on any of these platforms.  And the VM worked great, I think.  Unfortunately, after some point I stupidly forgot to continue providing updated versions of Virtual AGC for that VM.  Yikes!  So the VM had become very out-of-date.  Not only that, but I've also found that since it was now based on such an old operating system (32-bit Ubuntu 14.04), I no longer could update Virtual AGC for the VM even if I got my motivational ducks in a row.  Virtual AGC simply requires a more-modern environment than 10-year-old 32-bit Ubuntu in the old VM to build and run.  Solution?  A new VM!  I've replaced that old VM with a completely new feature-packed VM that not only has more capabilities, but also by design can be very-easily updated without my having had to prepare such updates for them in advance!  In other words, users of the new VM will be protected from my future indolence after this burst of energy on my part has dissipated.  The key is that the new VM doubles as a very stable build machine for Virtual AGC, a capability which the old VM did not have, due to having been pared down to its bare essentials.  All of this stuff is thoroughly written up on a completely-revised and simplified download page, which has thrown out almost all of the old, useless stuff that's no longer supported, while hopefully better illustrating the use of the new. 
  
• An added bonus is that the download page now includes something lacking up to now, namely build-instructions for Virtual AGC on Mac OS Sequoia that will (probably) work with any other recent versions of Mac OS too.

Another way of looking at most of the mumbo-jumbo above is that I want the new VM to be as perfect as humanly possible, and to provide as much of the Virtual AGC functionality that I enjoy on my own computer as it possibly can, without any of the hassle on users' parts that I have to endure for myself.  And to do that, I had to make sure that everything in Virtual AGC that was no longer up to my standards (as minimal as you may think them) was perfected at the same time.  The extent to which I've succeeded is always debatable, I suppose, but I'm very pleased with the result.

• HALSFC page
  
• XCOM-I page
  

• Added 38 documents to the main library, all of them astrionics memos from 1965 through 1969, related to the Saturn launch vehicle, and of course its computing system.  I say that they're all "memos", but a few are really substantial (unnumbered) documents enclosed in memos.  Mike sent me these nearly 3 months ago, and I've just been so busy that I simply lost track of how much time had passed while I sat on them.  Sorry!
• Added 3 documents I got (today!) to the Shuttle library.  These documents all relate largely or entirely to what are called Simulation Data Files (SDF).

Surprisingly, that's actually all tied together.  The reason I've been too busy to look at the Astrionics memos I mentioned is that I've been completely consumed by Shuttle-related work I've been doing.  As I've mentioned in other updates here, I've been working on a compiler (which I call XCOM-I) for the XPL programming language as it was extended in an undocumented fashion by a company called Intermetrics.  The reason is that Intermetrics wrote a compiler for a computer language called HAL/S in this extended form of XPL.  That HAL/S compiler, called HAL/S-FC, was needed to compile the flight software for the Space Shuttle, since that flight software was written in HAL/S.

And the reason I have time today for those memos is that just yesterday I reached a milestone on XCOM-I:  Not only can it now compile HAL/S-FC, but HAL/S-FC can itself compile HAL/S programs, and produce object code from them!  Or at least, it can compile the one HAL/S test program I throw at it.  The HAL/S test program I throw at it is called HELLO.hal, and I'll let you guess what it does.  Unfortunately, even though HAL/S-FC can compile HELLO.hal, what you get out of that process is (of course!) a program that runs only on one of the Space Shuttle's IBM AP-101S computers, not on your personal computer.  And lacking any way to run AP-101S programs at the moment, there's therefore no way yet to actually run the compiled HELLO program.  The same would be true, of course, if I compiled the Space Shuttle's flight software.  But progress is being made, one step at a time!  I'm hoping that Dan Weaver, who as I've mentioned before has written a very nice IBM 360 simulator, will be writing a (very similar) AP-101S simulator.  At that point, we could run the compiled HELLO or other compiled HAL/S program and really start cooking!

As to why any of that is relevant, as promised, to the SDF-related documentation added to the Shuttle library today ... well, that's another mouthful-and-a-half of explanation.  HAL/S-FC, the HAL/S compiler, actually consists of seven separate "passes" or "phases", each of which is a stand-alone program.  The seven stand-alone programs are run in succession to perform a complete compilation.  Of course, you the user don't really have to worry about all that nonsense if you're not interested in it, since you simply experience HAL/S as a single command, and that command worries about all of the details of fitting the separate passes together.

Nevertheless, when I say that XCOM-I can compile HAL/S-FC, I mean that it can compile each of the seven separate programs comprising HAL/S-FC.  The AP-101S object code is not spit out until the fifth pass, which is called PASS2.  (Go figure!)  That leaves two compiler passes (called PASS3 and PASS4) which I haven't run yet.  PASS3 and PASS4 are entirely devoted to production of Simulation Data Files (SDF).  SDFs were what were used as input to the digital simulation system that simulated running the Shuttle flight software.  They're quite fancy.  I'm told by the author of PASS3 and PASS4, Craig Schulenberg, that never has any other compiler of any kind produced such complete data in support of simulation.

My own desired next step in the compiler development is to run the compiler passes related to SDF generation.  Simultaneously the SDF documents appear in the Shuttle library.  Nifty!  Kismet!  Whether that's truly what I do next is TBD, but that's my whim at the moment.

By the way, this is all being written up on the XPL page of the website, basically in real time as I'm working on it.  Which means that it's a poorly-organized mess at the moment.  Still, it's there if anybody wants to read it.  I hope that it won't be too much longer before the compiler is debugged to the point where I can bless it as completely working, and proceed to put the documentation in order.  Of course, wishes don't always come true.  And anyone who's familiar with my writing style — just take a gander at this blog entry! — will realize that it still may not be very readable once I've reorganized it.  But at least it will be more readable than it is now.  I hope.

1. Use XCOM-I (my XPL/I compiler) to compile the source code for XCOM45, giving me an executable version of XCOM45 that runs on my Linux computer.  Call that version XCOM45-linux.
2. Use XCOM45-linux to again compile the source code for XCOM45.  Since the original XCOM45 ran on an IBM 360 computer, this gives us an IBM 360 version of XCOM45.  Call that version XCOM45-360.
3. Use XCOM45-360, running in an IBM 360 simulator, to compile the source code for XCOM45 yet again.  This gives us yet another IBM 360 version of XCOM45.  Call that version XCOM45-360A.
4. If all went well, XCOM45-360 and XCOM45-360A should be byte-for-byte identical ... and they are.  Voilà!  XCOM45 can compile itself, 100% accurately.  But more importantly for us, XCOM-I must have been working pretty well to make that happen.

If you have read that description closely — and who wouldn't have wanted to do that? — it barely mentions an important fact that I've neglected up to now in this blog, which is that our software repository now contains a very lightweight IBM 360 simulator called sim360.  This was not written by me, or anyone at Virtual AGC, but was instead written by Dan Weaver and barely mentioned on his own website.  (See if you can find sim360 on the website.  Give yourself a cookie as a reward if you can.)  There are several reasons it's significant for us:  A not inconsiderable advantage it has over full-scale IBM 360 simulators such as Hercules is that you don't have to know anything about operating an IBM 360 to use it.  Nor does it require any potentially-copyrighted software from (say) IBM that would prevent integrating it with open-source software.  But perhaps best of all, it's so lightweight that it probably technically can be incorporated into (say) Orbiter or the VirtualAGC GUI relatively easily, and can be adapted (if any adaptation is needed) to run IBM AP-101S code rather than IBM 360 code.  Admittedly I'm looking down the road a bit, but it seems to me as though sim360 provides a superior technical path to running Space Shuttle flight software in a spaceflight simulator.  As for the legality of that path (or any path) under ITAR, I make no claims.

Aside:  Ego compelled me to at least roughly try to figure out how close my own reconstruction effort in advance of having dumps from physical memory modules had been.  Counting just the substantive changes — i.e., things which would have affected the core-rope image stored in the memory modules, vs things that would not have, like changes to program comments or global spelling changes for program labels — and counting only the number of source-code files containing differences between Mike's and mine, I find 68 files with no differences, 16 with differences, and 1 about which I'm undecided.  Of course, not all of these files are of comparable sizes or complexities.  Nor did I count how many of them were unchanged relative to Comanche 55 (Apollo 11).  In other words, I got 80% of the files right and 20% not-so-right.  Which means ... well, precisely zip.  I'll give myself a blue ribbon for participation.

Aside:  Apparently, there's a newish policy, in which when you renew your domain every year, you have to validate the identity information given to the registrar.  As opposed to the last 20 years or so, when you didn't have to do any of that.  At least for my service, the validation process involves an exchange of emails to my personal email account, and the validation emails to my personal email address never arrive.  Which I had no way to even know about, since I didn't know I was supposed to get any validation emails anyway.  Not responding to the emails results in the domain being "locked" or "suspended", so that even though you've paid for the domain renewal, the domain simply doesn't work.  Hence no website for that domain, and no emails to it either.  Fun, huh?  And since my paycheck doesn't depend on any of this, I'm unlikely to discover the problem for quite a while; about 5 weeks of lost service in this case.

Aside:  Here's a hint to anyone thinking about creating their own open-source project:  Maintenance is a bitch!  In my case, I rarely hear of issues until literally decades after I wrote the code having those issues in them, at which point I'm scarcely qualified to fix them.  (And that's putting it charitably.  After all that time, the code may as well have been written by a deranged stranger.)  My advice is to get a team like Mike and Nik your side, so that you won't have to hear about the problems until they're already fixed.  Good luck with that, by the way.  Just my 2¢.

1. Actual original flight-software source code and/or object code.  I now have some of the source code and all of the GPC (IBM AP-101S) object code in hand, in some version which I don't care to specify at the moment.  Does that sound a bit weak and wishy-washy, given my normal tendency to bombard you with every detail and every speculation that crosses my fevered brain?  You're right, it is!  The problem is that I've received this material on condition that I preserve it and can personally access it for compiler development, but that I not show it to anybody else.  Or at least, not yet.  Nor do I have any timetable on when I will be able to make to do so.  Moreover, this confidentiality obligation is on top of whatever ITAR restrictions may limit distribution.  Besides which, I can't even get any legal action started on the ITAR front until I'm given permission to show the source code to the attorneys.  Why have I teasing you like this, given that I can't give you access to any of it?  I still think it's good news.  I have reason to believe that I will be able to make the material available at some point — at least if you're a "U.S. Person" for ITAR purposes — even if I don't know when that will be.  And I think that I would want to know about it if I were the one reading this update rather than writing it. 
2. HAL/S compiler/emulator development for compiling/running the flight software source code.  Anyone who has been following my posts on the topic will recall that there have been two independent but somewhat-complementary lines of attack:  first, a completely-homegrown HAL/S compiler/interpreter/emulator; and second, a port of the original HAL/S compiler from its now completely-obsolete XPL language into the modern Python language.  Each of these approaches is partially working and partially unimplemented.  But both are on hold at the moment, due mainly to the fact that their development is very exhausting; I've simply burnt myself out on it.  Plus, the compilers aren't entirely useful without the missing portions of the flight-software source code I'm still awaiting.  So I'm taking a break from HAL/S compiler development right now.
   
3. Distribution roadmap.  The question looming over all of this is how to distribute executable flight software in some manner that's useful for use in spacecraft simulators such as Orbiter, if there are ITAR restrictions?  Personally, I would argue that if object code is distributed in a form that cannot be executed on the original Space Shuttle software, and cannot be reverse engineered in such a way as to make it so-executable, then it should be fine.  For example, the original HAL/S compiler was able to compile flight software into object code either for an AP-101S target or for an IBM 360 target, and IBM 360 object code would seem to me to be ITAR compliant.  However, not everyone agrees with me.  It has occurred to me, though, that ultimately it's not my responsibility nor that of the Virtual AGC Project to distribute code that's executable on a spacecraft simulator anyway.  If/when I'm at liberty to distribute the flight-software source code to ITAR-qualified individuals who are involved in spacecraft simulation, they can use they can use their own judgement to produce object code they deem distributable without ITAR rish, or not.  In other words, it's largely Somebody Else's Problem.

On a different note, Mike has sent along a new stash of Apollo documents, which I've added to the main document library.  As usual, here's his summary:

Despite the missing module B23 and data loss from the other five, what we do have is fascinating and there's a lot to learn from it. For one, it has the same SXT-ON switch checking code as described in the memo "Programming Changes from AS-202 to AS-501", exactly like Corona:

This means that this version of Sunspot was meant for Block I Series 0 systems.... and this is possibly a major contributing factor for one of the later releases of Sunspot, which would have actually flown with a Series 100 system.

Sunspot also, like Corona, contains the mysterious Midcourse Navigation Game. Except in Sunspot, it's not broken dead code. Its issues have been fixed and it is now tied into four new extended verbs, V64 through V67.

There's also a lot of changes in PINBALL that mirror what we see in Colossus. Which means a lot of those things are not Block II changes, but rather were introduced in Block I for Sunspot and ported over. It's pretty remarkable seeing Block I implementations of these things.

Afterthought:  It's curious that I chose STS-26 as an example, since I see belatedly that it still mixes together documents from STS-26 proper vs STS-51-F due to miscategorization, as does STS-27.  Well, there's always tomorrow for fixing that!

• Made some corrections on the AGS page and in the comments in the document library (AGS verification testing for LM-4), related to the use of AGS Flight Program 4 vs 5 in Apollo 10.
• Mike sent over a scanned binder of 59 Block II LM and CM Power & Servo module Assembly (PSA) procurement specifications.  I've added it to the document library, but it's better viewed on our engineering-drawing page, because it's indexed there.
  

• VL70-730102 - Orbiter OV-102 Display and Control Panel Configuration. This is an engineering drawing from Rockwell showing the panel configuration for Columbia.
• Saturn S-IVB-512 Stage Flight Evaluation Report
• ND-1021037, Apollo Guidance & Navigation Equipment Familiarization Manual, Chapter 5, Computer Subsystem — a somewhat short but good introduction to the Block I Series 0 computer design
• Skylab I & II Program Description — this is another one of the AC/Delco books that we have listed in our document library as "Apollo 15 Manual", "Apollo 16 Manual", etc. This one's all about Skylark. Apparently "Program Description" is the proper name for these things, because unlike the Apollo books, the Skylab/ASTP ones have their titles printed on the spine.
• A set of LEM structural sketches, mostly for LM-4. These are excerpts from a big binder I found that also includes sketches for a bunch of Grumman aircraft.
• Apollo Portable Life Support and Oxygen Purge Systems — this is another little booklet from Hamilton Standard, to go along with the LM Environmental Control Subsystem one I sent a scan of a bit back.
• Apollo 10 Thermodynamic Analysis for LM Landing Radar Antenna Assembly
• ACE-S/C Description Manual

• Slides and supplementary material for a course called "Basic HAL/S Programming".
• Slides for a course called "AP-101S Assembly Language Introduction".
• Slides for a course called "AP-101S Patch Fundamentals".
• "HAL/S Compiler Test Results Report".

My personal experience with slide-show presentations is that seeing the slides outside the context of the presentation is often worthless, since the meat of the presentation is usually the words from the presenter's mouth rather than the eye candy on the slides.  However, that's not true of the first two courses mentioned above, and they're actually valuable stand-alone resources ... particularly the "Basic HAL/S Programming" course that's so relevant to what I'm working on now.  It's quite a substantial addition to our little collection of HAL/S programmer training materials, and should be either the first or second stop for anybody interested in learning about HAL/S.  (The other stop being Ryer's book, Programming in HAL/S, which incidentally I've been updating with comments of my own which I hope are helpful. I notice that my annotations don't show up in Chrome or Firefox, even if I turn enable the annotation settings.  I suppose that may be a blessing to some of you.   But if you want to actually view my annotations, you may have to download the document and experiment to find a PDF viewer that shows annotations.)

I mentioned some months back that I had again acquired a big backlog of documents for the Shuttle library.  I haven't forgotten them, but I haven't had any time to process them or even look at them yet, because they're not really relevant to HAL/S or its compiler.

• Those of you who follow the LVDC action will know that the "Equation Defining Document" (EDD) is the principal documentation for the LVDC's flight program, but that up to now we've had only Parts I and II of Revision A of the Saturn IB portion of the EDD.  We've now added Revisions C, D, and K, though unfortunately only the changed pages.  Most significant, though, is that we now also have complete Parts III and IV of Revision K.  Revision K, by the way, is for the Apollo-Soyuz Test Program (ASTP) mission.  Taken altogether, that's hopefully the complete Saturn IB EDD, more or less.  Alas, we still have no Saturn V version of the EDD.
• We now have documentation of the LVDC Preflight Program, not to mention several revisions of the software-verification plan for it, though unfortunately no source code.  Given that up to now we've had only inferences about the Preflight Program, without any documentation or indeed any admission from any of the original developers that they even knew anything whatsoever about it, that's a huge leap forward.  This information is from the "Generalized Flight Program" (GFP) era, though, and there's reason to believe that the Preflight Program may have been simplified somewhat in that era, vs what it had been in the earlier period when each LVDC Flight Program was more customized.  Thus this Preflight Program documentation is useful in relation to our LVDC Flight Program software listings for AS-512 and AS-513, but less so — and perhaps considerably so — for the AS-206RAM Flight Program.
• We have documentation for ASTEC and ACAPE programs ... which is significant, but which I admit requires some explanation.  "ASTEC" stands for "Aerospace System Test and Evaluation Complex", and essentially comprises the ground test equipment related to the LVDC.  The Programmable Test Controller (PTC) is one component of this collection of equipment.  I can't claim to have fully digested this new document, unless skimming it briefly so that I can meaninglessly parrot to acronyms qualifies as digesting it.  But if I understand correctly, the ASTEC or ACAPE program ran on the PTC, which was in turn attached to an LVDA and an LVDC running the Preflight Program.  ASTEC or ACAPE were each used to test or debug the simultaneously-running Preflight Program.  I don't know that my PTC simulator supports this configuration — actually, I sure it doesn't at the moment — but since we lack source code for ASTEC and ACAPE, that's not yet an urgent problem.  The new document has only flowcharts for ASTEC and ACAPE.

Another quick note about the new EDD documents mentioned above:  You may recall that about 3 months ago I was excited by the notion that LVDC Flight Program flowcharts could be regenerated by mysterious markings in the AS-512 and AS-513 source code, and that I had worked myself up the point of writing software to generate these flowcharts and to publish them. (See the 2023-07-27 entry below.)  Well, part of the reason I was motivated to do that is because we didn't have Part III of the EDD, because Part III does indeed contain flowcharts.  Now that we do have Part III, we have the exciting prospect of discovering how misguided or how prescient I was.  Well, perhaps "exciting" isn't exactly the word I'm looking for.  "Terrifying" is perhaps what I should be going for. 

I should clarify that I have not made a flowchart comparison before writing this, and am looking at it right now, in real time, as I'm writing this ... and the verdict is that the flowcharts don't look extremely similar.  On the other hand, there's some obvious resemblance.  Part of the problem, I'm sure, is that in comparing my Saturn V flowcharts to these Saturn IB flowcharts, we're not seeing apples-to-apples; even the names of the subroutines may differ.  In other words, maybe the flowcharts shouldn't match.  Well, who knows? Here's a cherry-picked result from the ACCELEROMETER READ subroutine that makes my flowcharts look especially good; but don't imagine this is a typical example.  An excerpt from my automated flowchart is on the left, and one from IBM's document is on the right.  It's heartening, I think, that where the text is comparable, it matches.

 

• A new stash of ~150 Shuttle documents has arrived from Cooper, but I haven't even looked at them yet, let alone posted any.  The upshot is that my Shuttle-document backlog is glutted again, so presumably I'll be migrating the new backlog gradually into the Shuttle Library in the next few days or weeks.
  
• James Pelster has fixed up some bugs in our Block I DSKY emulation, which he discovered while working on his own Block I AGC software emulation.  Thanks, James!  Emulations rock ... at least if you're going to use them to correct my software bugs for me. 
• Mike has sent along a couple of AGC-related documents too, both of which are now in the main Document Library.  Here are Mike's own assessments:

• Revision A of the LM-2 Apollo Operations Handbook, Volume II. We already have a scan of the basic revision; this revision changes no pages other than the table of contents, but it adds the entirety of section 9, which the basic revision totally omitted.
  
• Revision B of the LM PGNCS Study Guide, Computer Utility Programs. We already have a very poor-quality, OCR-corrupted scan of the basic revision. There's no change log, but this revision B appears to be an almost complete rewrite; it is based off of a Sundance 202 program listing, while the original was based off of Sunburst 14. Notably, it gives us pretty good documentation for a lot of later software features, including what appears to be quite good coverage of the display interface routines, which is something we didn't have before.

• Nik has pointed out a couple of documents that may be relevant to the LVDC Digital Command System (DCS) work I'm doing right now, at Colin Mackellar's tribute site devoted the Honeysuckle Creek Tracking Station in Australia, so those docs have been pulled into the main Document Library as well.  (Which reminds me that I need to go and rewatch The Dish.  It's nominally about Parkes rather than Honeysuckle Creek, though the Wikipedia article says it does appropriate some stuff that really happened at Honeysuckle Creek.  Highly recommended in any case.)
  

• Added "Saturn V Technical Information Summary" documents to the library for three missions (Apollo 5, 8, 9).
• More changes to the LVDC page's section on viewing telemetry, including alternative telemetry-viewing software.
• Lots of updates to the LVDC page's section on the Digital Command System, though that section should probably be regarded as "under construction", so I wouldn't exactly rush over there to look at it.
  

• Added the Apollo 11 LM Systems Activation Checklist to the document library.
• Added an incomplete rough draft of a tutorial on LVDC software flowcharts.  This is a notion I don't want to talk about just yet, but for which I have high hopes.
  

• A few WORK directives need to be added to the LVDC source code to provide information to the assembler that I wish the assembler could deduce for itself.  WORK directives are my own invention, and don't exist in the original LVDC assembly language.  PTC ADAPT SELF-TEST and AS-206RAM need no such added directives, fortunately, but I was forced to add two of them to AS-512 and three of them to AS-513.  Most of them I actually know how to get rid of, I think, but so far the cost of the programming effort to do so just isn't worth it to me.
• There is a mismatch between the way the original assembler and the modern assembler round decimal numbers, so that for a very small percentage of decimal constants, the original and modern assemblers disagree in the least significant bit in the octal object code.  I'm inclined to regard these discrepancies as due to bugs in the original assembler's arithmetic, but trying to offload blame from myself back onto 1960's and 1970's IBM FSD is pointless: The modern assembler is supposed to mimic the original, and as long as it can't mimic this rounding bug (if it is indeed a bug), the modern assembler cannot be fully complete.  There are 19 of these rounding errors in AS-512 and 11 in AS-513, out of 1000+ decimals, but there are none in AS-206RAM or PTC ADAPT SELF-TEST.  At the moment, the modern assembler simply has a command-line switch (--fuzzy) that avoids reporting these as errors, thus letting you ignore them.
  

• As you may recall, a few months back Mike Stewart was able to get dumps of core-rope memory modules for the Block I AGC programs Sunrise 45 and Sunrise 69, which were system-test programs used (among other things) for acceptance tests of Block I guidance-system equipment.  Mike was able to fairly-quickly provide us with a reconstruction of Sunrise 45 source-code, although Sunrise 69 proved somewhat more challenging to a then-depleted Mike (I guess even he must have his limits) and thus has been languishing for quite a while.  But the time is now ripe, even if the Sunrise 69 source code itself may still be a bit green, and so it's finally being made available today.  There may be a few more ad hoc program labels in it that mightn't exactly match the original code than usual, but rest assured that the source code assembles correctly and is considerably better than nothing if you want to study the code!  The "new" source code is now in our software repository, and you can see our usual colorized, syntax-highlighted version of it by looking at the improved Sunrise 69 write-up on the Colossus page.
• Similar comments can be made about the source code for Corona 261, which was the Block I flight software for the unmanned AS-202 mission, the very first Apollo mission flown with a working AGC.  Core-rope memory modules were dumped a while back, but a source-code reconstruction wasn't instantly at hand.  On the other hand, why should we have expected an instant reconstruction?  As it happens, part of the reason for the short delay is that the dump of the physical memory modules was a more-difficult affair than usual, and the uncertainty that the dump was exact was greater than usual, even though we thought it was very-likely correct.  So Mike felt he had to make renewed efforts to see if the dump needed correction.  Those efforts are now concluded, and we do indeed believe that the original dump was fine.  Reconstructed Corona source code is thus now available, and you can either download it from the software repository, or view the colorized version of it provided with the improved Corona 261 write-up on the Colossus page.
• The initial transcription of the LVDC flight software for mission AS-512 (Apollo 17) was completed about a month ago, but in such cases there's always the suspicion that there may be typos in it ... bugs.  As it turns out, there were.  Lots of them!  There are a number of techniques for correcting such bugs, such as lots and lots of proof-reading.  Well, we didn't do that!  I'm sorry to say that for whatever reason — possibly the potential ITAR restrictions on "export" of this software — the pool of potential volunteers for such LVDC-related activities is far smaller than what I've experienced in the past for similar AGC-related activities.  In other words, the rate of progress is far slower because the workload rests on fewer shoulders.  That's my excuse.  As it happens, though, the best technique we have for debugging such source-code transcriptions is not proof-reading, but rather assembly of the source code and (automated) checking that the octal listing produced by the assembler is identical to the octal listing transcribed from the original printout.  That process is now complete, and so I regard the AS-512 transcription as debugged.  Any of you who have been given a link to the LVDC assembly listings by demonstrating you're legally qualified to view them can access that transcribed source code in the git repository at that link.  A handful of corrections were also made to the transcribed octal listing, so if attempts to run AS-512 code in the LVDC CPU emulator failed in the past, perhaps they might succeed now.  Of course, this particular debugging technique cannot detect errors in program comments, so those must either be tolerated or eventually corrected by other means.
• The assembler-aided debugging for the AS-512 LVDC flight program was delayed for about a month because the LVDC assembler I wrote for processing the AS-206RAM flight program no longer fully worked as-is for AS-512.  For one thing, a number of new syntactic features had been added to the LVDC assembly language in the intervening years (1972 vs 1967), and those had to be supported in the assembler.  But that was the least of my concerns!  Unlike AGC or AGS assembly language, where what you see is what you get, the LVDC assembler performs a number of activities behind the scenes that are not explicitly tied to the source code.  The upshot of that is that there's a lot of object code and allocated memory after an LVDC assembly that was generated entirely by the assembler itself.  Since the aim of the the modern LVDC assembler system is to produce object code that agrees 100% with the original LVDC assembler, it's necessary not only to figure out what all of that extra stuff is, but to generate the extra stuff in exactly the same way.  And since there is no documentation available to us about LVDC assembly language or the original LVDC assembler, figuring all that out is not only tricky ... it may even be a fool's errand.  Today, though, I'm tentatively saying that the modern assembler has been updated and is working, subject to provisions discussed below.  At the very least, it can be used with AS-512 source code, AS-206RAM source code, and PTC ADAPT Self-Test Program source code.  Unlike LVDC flight software, the modern LVDC assembler is not regarded as potentially in thrall to ITAR, so you can get it in the software repository and see updated usage instructions on the LVDC page.
  

As I mentioned, there are certain provisos in saying that the modern LVDC assembler now "works".  In fact, there are three quirks that you have to live with if you want to assemble AS-512 source code.  They aren't terribly bad, but they're annoying and I hope to eliminate them.  At some point.  Two of the quirks are addressed inserting a WORK ROOF or WORK BLOCK directive, altogether one of each, into the source code; while those are too technical to discuss here, you can read about them on the LVDC page if you like.  The third quirk is that in AS-512 there's a handful of locations — well, 19 of them, so that's nearly two handfuls and two footfuls — at which the original assembler rounded floating-point or fixed-point decimal numbers in a way that I cannot understand, with the result that (from my perspective) they are wrong in the least-significant bit.  Understand that I'm referring to literally thousands of locations in AS-206RAM and AS-512 at which such rounding is occurring, so this rounding error rarely happened ... but it happened sometimes.  Personally, I think this was a (probably-undetected) bug in the original assembler, perhaps related to insufficient arithmetical precision in the computer running the assembler program.  But that's not really a mitigating factor:  The modern assembler needs to reproduce the bugs of the original, no questions asked, rather than stubbornly attempting to be "correct".  Thus in the end, saying that the modern assembler "works" depends on how much you're willing to discount these 2 workarounds and 19 rounding discrepancies!

• Four documents added to the library.  (Thanks, Cooper.)
  

• Added a new document (thanks, Mike) to the library, related to the equipment for handling telemetry data.
• Added the WORK directive to the description of LVDC assembly language.  That's my own invention, hopefully temporary, for instructing the assembler to take various actions for which I haven't yet worked out an appropriate theory of operation or algorithmic basis for letting the assembler decide for itself.  Here's an example:  The original LVDC assembler, it appears to me, did not always correctly round fractional decimal values in converting them to binary, so those values may not agree with ones assembled by the modern assembler; until I work out why, I can temporarily add WORK directives to the AS-512 or AS-513 source code to enforce the appropriate (or inappropriate from my point of view) rounding by the modern assembler.  After I eventually do figure it out, I can recode the modern assembler to act the same way as the original assembler, and remove the WORK directives.
  

MY2    DEC     2.0B27

• Five new documents added to the library:  A newer revision of the Apollo 14 Lunar Module Systems Handbook, an Apollo 13 Mission Techniques doc, and several Apollo Experience Reports.  (Thanks, Mike and Cooper!)
• Some fixes on the LVDC page (changes to the D and P formats in the description of FORM).

• Both volumes of the LM-4 (Apollo 10) Operations Handbook has been added to the document library, though unfortunately one of the volumes has only changed pages.  Admittedly, the changes are perhaps 40% of the book.
• Some fixes on the LVDC page (description of BLOCK).
  

• A couple of early versions of the primary reference document about the S-IVB Instrumentation Unit were added to the library.
• A link to the Vostok Supersite was added to the FAQ page.
  

• Updated the Gemini page, showing of the various computation modules evolved on a software version ("math flow") basis.  (Thanks, Amy Collins!)
• Added a couple of documents to the document library.
• And a couple of new documents for the Shuttle library as well.  But no, that doesn't mean I'm at the point of trying to clear up the backlog of Shuttle documents I'm sitting on or that I know about; it was just more convenient for me at this moment to add these particular documents to the library than to add them to the backlog.
  

• Added 16 more documents from my backlog to the library.  They're a real miscellany, without any overarching theme, from Gemini through Apollo through F-8 digital fly-by-wire, so I won't try to be more specific about them here.
• Added dedicated Skylab 1 and RTCC sections to the document library.
  

• The document library now includes a volume of the ASTP Operational Data Book (thanks Mike!), as well as 19 additional files from my backlog.  All of the latter are RTCC requirements for various types of processing for specific missions and situations (such as Earth-orbit insertion for Apollo 10 and 11).
• The "Official Virtual AGC GitHub repository" link on the FAQ page was pointing off into la-la land ... without winning me any Oscars in the process.  Fixed now.  It had been unchanged since I first put it there, years and years ago, and since it had never been reported until now, I guess that question hadn't been asked all that frequently.  (Thanks Chris Speidel!)
  

• Added 8 documents to the library from my backlog queue, generally having to do with RTCC, MCC, and MSFN.  There's a lot of info in some of these documents about the "universal command system" (UCS) digital data (and its formats) being passed around the network.  But admittedly, I've not really been aware of UCS until recently — i.e., I don't know much about it — so I don't guarantee that the info is new or unique.
• Various updates to descriptions of LVDC assembly-language pseudo-ops, including REQ, BLOCK, new variants of ORG, and new variants of FORM and invocations of forms.  Some but not all of these have already been implemented in the assembler itself.
  
• Eliminated some long-obsolete materials that had been unexpectedly lurking as unlinked-to phantoms on the web-server but which could still be accessed from a search engine like Google.  There's probably even more stuff like that, but ... well, the website is really big now, so they're really hard to find.  (Thanks to Matt McKrell!)
  

• 01 Upper, color=amber: CH OVRIDE
• 01 Lower, color=green: SCS CONT
• 02 Upper, color=red: CMC WARN
• ...
• 18 Lower, color=red: P01 ENBL

Pretty nifty, no?  The only drawback is that the document doesn't tell us what slogans like "CH OVRIDE" may mean, nor what's displayed on the two CRT monitors (LOC 6 and LOC 7), so we need to look elsewhere ... oh well, too bad, so sad!  Some of that stuff is pretty obvious, though, and perhaps some of the remainder is in the many, many missing manuals of the documentation tree that I mentioned above.

A slightly-different scan (bigger grayscale vs the older, smaller B&W) of the Lunar Module Abort Guidance System Design Survey document has been added as well.  Perhaps it's better than the old one, perhaps not.

It purports to be the first release of the document, and may be more applicable to early missions (especially Apollo 7) than the copies we currently have.

• A 1963 document called the "Apollo System Specification", which is just what it sounds like.  For example, section 4.4.5.3.4 tells that "[the LEM's] general purpose digital machine shall
  have the capability of performing all LEM guidance problem computations, vehicle sequencing, and timing trajectory, and shall conduct diagnostic tests of itself and checkout routines of
  other LEM subsystems".  (Thanks to Cooper Lushbaugh.)
  
• Ten or so "Apollo Mission Techniques" documents.  (Thanks to Cooper Lushbaugh.)
  
• A complete sample program in the MAC computer language (see below).  (Thanks to Mike Stewart.)
  
• A bunch of Tindallgrams (see below).

MAC (MIT Algebraic Compiler) was a computer language somewhat like FORTRAN (though fancier in some ways) that theoretically would have been useful for scientific computing.  Apparently, MIL/IL tested out potential AGC algorithms by coding them and running them in MAC before coding them for the AGC.  I've often heard about it in the past, but basically haven't thought about it too much.  Lately, though, we've gotten a fair amount of very early code written in MAC (not yet posted here!), so in preparation for dealing with that MAC code I've been looking into it a little bit.  When my understanding is more complete, I'll probably write it up for the site in my typical wordy, overblown style, but I haven't done so yet; that's probably why this post is so long!  (The "sample MAC program" I'm posting today, by the way, isn't the incoming MAC code I mean, as it's not even from Apollo.)

At any rate, I was shocked to realize that for all I've heard about it, up to this point we (the Virtual AGC Project) haven't had any code in MAC or any documentation about MAC other than superficial references to it.  Moreover, I've found no available information online about MAC that's deeper than the "this computer language used to exist" variety.  Of course, googling for "mac", as you may imagine, does not produce incredibly helpful results; thanks a lot, Apple!  Fortunately, the language itself appears (at least superficially) to be quite easy to understand even without documentation, particularly now that I've been steeped in the HAL/S language used for the Space Shuttle flight software ... but I'd still prefer to have the documentation.  And it's not as if the MAC language is secret or proprietary. It's simply that nobody ever seemed to bother.  Which is a shame, considering that (as I say) we have incoming code actually written in it!

With that said, we have found some MAC documentation.  But the news about it isn't rosy:  Everything I've found so far is trapped in the MIT Library, and as near as I can tell, the MIT Library doesn't let anyone look at MIT Library materials except MIT staff, students, and faculty.  And sometimes, if you're really lucky, researchers from affiliated institutions.  What happens in the MIT Library stays in the MIT Library.  As one of the non-elite myself, I therefore have no means of accessing any of these materials.  Nor do I have any such elite folks on a string to go and fetch such material for me.  The Library does have a searchable database, though, so they can have a giggle while dangling a list of the materials I can't access over my outstretched arms.  For example, here are some of the juicy items you find:

• "The MAC Algebraic Language System", by Hal Laning and James Miller (1970), 23 pages, MIT/IL report R-681.
  
• "The MAC Primer", by Henry B. Brainerd (1966), 39 pages, MIT/IL doc E-2044.  It relates to using MAC on the Honeywell computer that MIT/IL used before switching over to IBM computers.
• "The MAC-360 Primer", also by Brainerd (1969), 63 pages, MIT/IL doc E-2393.  It's the IBM-based document that superseded E-2044.
• ... and others

But enough of that!  Regarding Tindallgrams, while I've mentioned them briefly somewhere on the site, I don't think I've posted any of them, or at least not many.  At any rate, a lot of folks consider them very useful sources of information.  ALSJ has posted a lot of them that apparently came from the UHCL archives, so there isn't too much need for reposting them here.  But I'm nothing if not compulsive (or is it obsessive?), and some of the UHCL/ALSJ files are lacking a searchable text layer, so now that this gap in the Tindallgram race has been pointed out to me, I naturally need to OCR where necessary and repost!  Apparently, Bill Tindall wrote around 1100 of these memos for Gemini and Apollo, and what I'm posting today is a half-dozen PDFs of a portion of them.  Not that anything is being intentionally excluded, you understand, but merely that only a portion of the memos seem to have survived.  There's now a dedicated "Tindallgrams" section in the document library.

Finally, the initial transcription of the AS-512 LVDC flight program has been completed.  Thank you to all participants!  However, neither has it been proof-read for typos nor has it been debugged via assembly (and comparison of the assembly to the separately-transcribed octal listing).  I expect — or perhaps more accurately, dread — that the assembler will itself require updates as the debugging process proceeds.  At any rate, that's next on my agenda, beginning tomorrow and continuing until who knows when?  My expectation is that the AS-513 LVDC flight program can be cut-and-pasted from the AS-512 LVDC flight program to a great extent, so I don't anticipate any work to begin on the AS-513 flight-program transcription until the AS-512 source code has been rendered as error-free as possible.

I do expect to make some improvements to the LVDC assembler along the way:  principally, giving it an option for producing color-coded, syntax-highlighted, hyperlinked, HTML assembly listings, much as the AGC and AGS assemblers have already been doing for many, many years now.  I skipped this feature the first time around, when the LVDC assembler was only used for the AS-206RAM flight program, because fear of ITAR prevented me from "exporting" the nifty HTML assembly listings online and thus it didn't seem to be worth the effort.  But someday I hope I can post the the LVDC software online, and even in the near term while I'm afraid to do so, souped-up assembly listings turn out to be such a very helpful study tool that I prefer not to do without them.  I've become addicted to the syntax highlighting ever since I saw the LVDC color-coding scheme Mike created for the vim text editor, even though I've not been using vim myself for my contributions to the transcribed source code.

[A] new study guide ... — CM PGNCS System Mechanization. It is extremely good and I'm very excited about it. The last ~140 pages are focused on the AGC. Compared to ND-1021042 and ND-1021043, it has less schematics but it does a significantly better job of explaining how and why — so it is a great companion for those documents. It would have been suuuper useful to have during the AGC restoration or while I was building the rope reader.

• The transcription effort for the AS-512 LVDC flight program has not yet finished, but the window for volunteering to assist has now closed.  Thanks to everyone who has assisted!
• Nik Beug has made a terrific video of essentially an entire simulated AS-202 mission, using the newly-available Corona 261 software and the Orbiter spaceflight-simulation system with a special Block I branch of the NASSP add-on.  Watch it!
  

• Corrected some oversights in my Corona 261 descriptions added yesterday.
• Corrected (I hope!) the misspelling in several places of Larry McGlynn's name.  Sorry about that, Larry!  My brain knew your name, but my fingers didn't.
  
• On the Colossus page, rewrote the description of the Solarium 55 to indicate that it had been used for both Apollo 4 and Apollo 6.  We've known this for a long time, but the text on the Colossus page (and elsewhere on this site) had doggedly continued with our original erroneous assertion that Solarium 54 had been used for Apollo 4.  Hopefully this is now fixed everywhere; probably not, but hopefully.
  

• The LVDC transcription guidelines have continued to be updated, and the transcription effort for the LVDC AS-512 (Apollo 17) flight program has continued apace, though I've not bothered to report on it in this space.  If you happen to be interested in the progress, there's a spreadsheet that tracks the transcription.  The short answer is that it's proceeding well, without difficulty other than expenditure of time and effort.  After the transcription is completed, which isn't something very close to happening at the moment, I'm sure that there will be updates to the LVDC assembler required, at which point we'll be able to debug the transcribed source code and octal listing.  But that's probably thinking too far ahead.
• Speaking of things that I haven't been reporting on, there's a huge backlog of Space Shuttle documentation sitting in my inbox that I haven't gotten around even to looking at because of the time being spent instead on the LVDC software.  I mention it only because one might wonder why there has been a transition from continual Shuttle-Library additions to the present dearth. 
  
• Longtime readers may recall that we got flustered a few years back with the notion that the AGC software for the AS-202 mission might become available.  You may also recall that AS-202 was the first flown mission with an AGC — albeit Block I — and hence this software (Corona 261 by name) was the first ever flown AGC software.  Well, it has taken a while (seven years!), but we finally have it in hand.  Not the source code, mind you, but a dump of the executable from the physical memory modules.  Thanks to collector Jimmie Loocke, the owner of the modules, and to Mike Stewart, as usual, for dumping them.  It's great to finally get that particular monkey off of our back!  Of course, given the nature of this sad, old world, in which things seldom work out perfectly, there were more than the usual number of difficulties in performing this dump, so we're not yet entirely sure it's 100% accurate even though its memory-bank checksums are perfect.  On the other hand, there's every expectation both that the source code will be recoverable, and that the process of doing so will uncover errors in the dump.  So life's not all bad.  In the meantime, you can run Corona 261 as it is right now in either the VirtualAGC GUI or in Orbiter+NASSP, though I'm not in a position to explain the latter any farther than that.  At any rate, you can read more on our Colossus page.
  

• Both the AS-512 and AS-513 flight-program "octals" (i.e., the executable machine code) have been transcribed and are available in the local git repository.  While they've been through one or two proofing passes each, they're still not regarded as error-free.  Both are estimated (by statistical methods) to still contain on the order of 3 undetected/uncorrected errors, and to need one additional proofing pass each to reach an estimated ~0.1 errors.  Of course, they may be error-free in spite of that right now, and in any case may be run in emulation to a certain extent right now.  Recall, though, that there are conditions under which these Flight Programs make calls to the so-called Preflight Program, which is not present, so even if error-free these programs could only be emulated to a certain extent before the absence of the Preflight Program became problematic.
• Two of the 77 source-code files for AS-512 have been transcribed, namely SECOND OPPORTUNITY INITIALIZE and GFP EXECUTIVE CONTROL PROGRAM, and are present in the git repository.
• None of the 70 source-code files for AS-513 have been transcribed.  It's possible that the two AS-512 files so-far transcribed are identical or substantially identical to their AS-513 namesakes, but I'm not aware of it one way or the other.
  
• And just for completeness, though it hasn't been "news" for over three years, our original AS-206RAM flight program had its octals and all 23 of its source-code files transcribed into the git repository long ago.

Alas, all Space Shuttle work is on hold as long as I'm involved in this LVDC processing.

• So far, no spaceflight-simulation folks have shown the slightest interest in this notion, so there's no guarantee they would even bother to integrate a LALMAT emulator even if it existed.
• We might end up finding out that it's perfectly okay with ITAR to export the actual LVDC source code anyway, in which case any development time spent on LALMAT would be wasted.
• As long as the LVDC source code remains restricted under ITAR (if it even is restricted), many of those people who would otherwise be most-enthusiastic about working with it have little motivation for participating in LALMAT development.
  
• But mainly, I'm personally completely swamped, and there's no possibility of developing LALMAT myself as long as I'm neck-deep in Space Shuttle stuff.  Developing LALMAT requires volunteers to do so.

I guess the executive summary is that if there are any "U.S. persons" keen to help transcribing the AS-512 and AS-513 listings into source code, and/or specifying LALMAT and coding an LVDC-to-LALMAT assembler and a high-performance LALMAT emulator, then you should make yourselves known!

The first two are new (much better) scans of the Apollo Mission Simulator Instructor Handbook, volumes I and II, which are already in the library. Volume I is the same revision as the one in the library, while Volume II is a slightly later revision than the one we already have. The third is a nifty little booklet about the Lunar Module Environmental Control Subsystem by Hamilton Standard. It's filled with lots of technical details, sketches, and numbers, some of which we don't have from other sources.

• New pages dedicated to my "modern" version of the Space Shuttle HAL/S compiler and (a new thing they didn't have back in the day) HAL/S interpreter have been added to the website.  The compiler/interpreter itself is undergoing frequent changes in our software repository, and it's nowhere near complete or debugged.  Development is pretty time-consuming, which is partially why I haven't been posting much lately.  But in spite of that the HAL/S interpreter is in a form that allows playing around with HAL/S ... if you're very, very tolerant of the kinds of problems you encounter using super-bleeding-edge works in progress.  I felt it was time to write up something more-definitive than the vague comments previously on our Shuttle page, particularly as I will likely want help at some point turning this preliminary version of the compiler, and the associated emulator built into the interpreter, into an advanced form that can produce efficient Shuttle code and run it fast.  That effort is actually something that could begin right now, if anybody was pounding on my door to help with it; or more helpful at this point, willing just to take it entirely under their own wing without interference from me!  Alas, I still have received no actual HAL/S flight-software source code whatsoever, so keep your fingers crossed on that.
• Mike got the "Apollo Operations Handbook" (volume 1) for LM-2 somewhere and so I've added it to the document library.  Though predating our operations handbook for LM-3, it's apparently bigger, with lots more foldouts.  Go figure!
  

HAL/S > DECLARE I INTEGER, X SCALAR, Y SCALAR;
HAL/S > X = 50.26;
HAL/S > Y = 100.92;
HAL/S > I = 3 X - Y;
HAL/S > WRITE(6) 'The result of 3 X - Y,', 3 X - Y, ', converted to an integer, is:', I;
        The result of 3 X - Y, 49.86 , converted to an integer, is: 50
HAL/S >

• A couple of docs were added to the Shuttle library.
• I've added reference source code to the software repository for the XCOM XPL compiler and associated utilities, though it's for an earlier version than used in Space Shuttle software development.  Recall that the Space Shuttle's HAL/S compiler is written in XPL.
  
• I've also added partial source code to the repository, in a mixture of XPL and IBM Basic Assembly Language (BAL), for HAL/S-FC compiler release 32V0 (PASS 32.0 / BFS 17.0).  This source-code batch, I believe, contains all compiler code except passes 2 through 4.  Thus it has code for stuff such as tokenizing, parsing, optimization, creating output listings, and the runtime library, but is missing code for executable-code generation and probably other stuff I'm not cognizant of at the moment.  I also have related stuff in hand that I've omitted from the repository for now, like JCL, macros possibly related to digital simulation, and sample assembly listings of a few source files, because I'm not really too sure yet about what it all is or how to present it appropriately.  I hope to add the missing passes 2-4 later so as to complete the source code, but those have not been supplied to me as of yet.
  
• The Shuttle page has also been updated somewhat to cover these additions.
  

• I've corrected the Shuttle library somewhat, to be more-scrupulous about indicating which software versions ("Operational Increments") and which shuttle missions particular documents apply to, as well as indicating better what the publication dates were vs the specific document-revision levels.  Due to those corrections, I also found that it made some sense to add dedicated sections on the Shuttle library page for software versions like OI-30, OI-34, and so on.  Of course, we're still in early days here, Shuttle-wise, so all of these sections are rather sparse, or even empty.
  
• I've also continued fleshing out the Shuttle library.  There are several worthwhile additions, of which the most-notable in my book is JSC-18820, the "Data Processing System Systems Brief".  In Apollo terms, the most-direct comparison I'd draw is to the AC Electronics manuals that concisely presented any and all technical details about the guidance systems in one giant manual for each Apollo mission.  The DPS Systems Brief plays a similar role for the Shuttle's computer systems.  For example, it explicitly covers the details of database message packets received by the General Purpose Computers (GPC) or emitted by them, which is information I've really wanted but have found nary a hint in any other document so far.
  

yaDSKY2 --cfg=LM0.ini --port=19797
yaAGC --core=Aurora88.bin --port=19797 --cfg=LM0.ini

• I've continued to flesh out the Shuttle document library I mentioned a week or so ago ... sometimes, though rarely, even with documents seemingly unavailable anywhere else.  I've also noticed that a number of the documents had no searchable-text layer, so I've corrected that.
• One correspondent (thanks, Frank Kannemann!) pointed out that there was actually a short online course that he says is based on Virtual AGC.  He suggested adding a link to it.  Which I've now done, in the "Video" section of the FAQ page.  Actually, I owe Frank an apology because his email sat in my box for nearly 2 years without me taking any action on it.  I have no excuse.  Well, his email did arrive the afternoon of January 6, 2021; perhaps there was some other distraction that had gotten my attention.  Yes, let's blame it on that, and not on my own laziness!
• Unfortunately, I don't have even that feeble excuse for letting Patrick Fuch's email in my to-do list for nearly as long.  He took the trouble to stitch together the individual frames of a few of our AGC engineering drawings, with which I've now updated the electro-mechanical page.  Thanks, Patrick!
• Nearly three years ago, Frank Pound sent me instructions for running the AGC CPU emulator (yaAGC) in a docker container.  Now in this case, I didn't do anything about it because I wasn't sure exactly what I should do.  So I've still done nothing with it now.  But it's a very interesting idea, so I didn't want to retire it without at least blogging about it ... if this change-log is indeed a "blog".  The difficulty with docker, as I understand it — and I'll freely admit that by now my understanding could be very out-of-date — is that while you can run a command-line program like yaAGC or yaAGS under docker, you can't run graphical programs like yaDSKY2.  Frank's insight was that you can still run the graphical components like yaDSKY2 or yaDEDA natively, but that yaAGC or yaAGS can run in docker and still communicate with the graphical components normally.  Since it's usually the graphical components that are difficult to port or build platform-independently, specifically on Mac OS X, I'm not sure what that gets you.  On the other hand, these days, it's becoming more and more clear to me that the emulations of the graphical components can be done perfectly satisfactorily in Python, and much more easily than they have been done so far using other tools like wxWidgets, in which case they would be perfectly portable across any platforms that had Python; and which would make providing the command-line components like yaAGC as dockerfiles would be very sensible.  Well, that's neither here nor there, since the various Virtual AGC graphical programs have not so far been turned into Python programs.  And that assumes you can even run the Linux software in docker containers on Mac OS X or Windows.    But it makes you think.  Or at least, it make me think, and wish.

By the way, these are not the only things I found languishing in my to-do list.  There are still a dozen or so, with oldest being from 2011 (!).

• Speak of the devil!  The potential availability of the LM131 rev 1 software mentioned yesterday has become reality today!  So you won't have to (re)read yesterday's rather lengthy note, I'll just remind you that LM131 rev 1 software is what was actually flown in the LM's AGC in Apollo 13 ... in contrast to the slightly-earlier Luminary 131 software that has been our nearest stand-in for the Apollo 13 flight software for the last 19 years.  Our Luminary page's writeup on it has been updated accordingly.  And what a writeup it is!  I'd highly recommend it to anyone.    The VirtualAGC GUI has been updated to support LM131 rev 1 as well, though taking advantage of that requires rebuilding Virtual AGC from source.
• I've also arranged for all of the physical dumps of AGC rope-memory modules in the new "Rope-Module Dump Library" (RMPL) I mentioned yesterday to be appear in the "Software Listings and Dumps" section (and possibly other sections) of our document library page as well, because it just seems like the right thing do do.  All of the dumps will show up for a while in the "Recently Added" section as well, even though we had some of them on hand before, since they had never shown up in the library before.
  

• SUNRISE 45
  
• SUNRISE 69
• LM131 rev 1
  

• The WebAssembly port of Virtual AGC has been updated (thanks, Michael Franzl!) and the WebAssembly section of the download page has been updated accordingly.  It's great if you're looking for browser-based implementations, so if you haven't done so before, be sure to check out Michael's live demo.  Just remember to select which AGC software version you want to run before messing around with the DSKY, or else you won't see much happen.
  
• There have been some security-related changes at ibiblio.org (which hosts the Virtual AGC website).  While I've tested the site and given ibiblio support my thumbs up, there's always a possibility I've overlooked something, so if you notice irregularities beyond the usual in how this site operates, do let me know.
  

• AGC:  24"×12.5"×6" → 24.250"×12.433"×5.974" and 70.1 pounds (which stays the same).
• DSKY:  8"×8"×7" → 8.124"×8.000×6.91" and 17.5 pounds → 17.8 pounds.

Thus, in one respect, almost everything changed.  But you can't really say the original numbers were "wrong"; everything turned out to basically correct, as long as you know to round to the nearest half-pound or half-inch.  Which is something neither I nor Wikipedia, nor anybody else thought to mention. 

But it does point out a problem with the Virtual AGC website, in that I occasionally (often? usually?) just don't say where the individual factoids come from.  I can't help but wonder if the website doesn't need a complete review of the provenance of the information and (perhaps) a bunch of supporting footnotes, factoid by factoid, like Wikipedia has.  Since I'm lazy, I'm going to have to ponder that for a while rather than doing anything about it immediately.

These are all part of the Apollo Mission Simulator Maintenance and Repair Procedures Manual for the SC-012 (Apollo 1) configuration. The AMS was the CM simulator the astronauts trained in at the cape. The first three books constitute both volumes of the basic manual, while the fourth is volume 1 of a manual dedicated to the Visual System, which implemented the window/sextant/etc. views with projectors, mirrors, and models. Together they're about 3400 pages total of detailed design and troubleshooting info, over 1000 of which are foldout schematics.

• Section 4 of the Luminary 116 GSOP. This appears to be our first GSOP section explicitly for Luminary 116.
• Revision 2 of section 7 of the Skylark GSOP. We already have the first revision of this section; this revision adds some ASTP-specific EMPs.
• The SA-502 Flight Sequence Program ICD.

The latter document relates to the LVDC, LVDA, and the time base for Saturn guidance.

I should clarify my last change-log entry, and say that it's not so much that Python 2 is a requirement, as that the method Python's documentation recommends for finding the default installation of Python (whether 2 or 3) doesn't work on a number of systems, and this causes the build process to fail.  Whether the disclaimers I added in the last change are adequate to address the problem or not remains to be seen.

• The Apollo 13 Flight Director log, which which comprises the flight directors' hand-written logs throughout the entire mission.  I'm told that in addition to Andy, we have the University of Houston, Clear Lake, archives to thank for this.
• The other 54 documents relate to the development of the Integrated Mission Control Center (IMCC), and particularly the Mission Control Center (MCC) in Houston, the Mission Operations Wing (MOW), and Real Time Computer Complex (RTCC).  So there's lots of stuff about evaluating the various contractors' bids and performance, notes from folks like Chris Kraft as to how the whole thing should work, and so on.  It's thus not directly related to any missions.  There are so many of these things that the document library now has a new section dedicated to the IMCC.

Anyway, thanks to Andy and to UHCL!

In an unrelated matter, I've also modified the document library's "Electrical and Mechanical Design" section to slightly improve the representation of engineering drawings in the document library.  The problem with representing engineering drawings in the the context of the library is that there are hundreds of thousands of such engineering drawings, but those many individual drawings can't be presented well in the document library, which is essentially just a list of documents that you can scroll through.  Nobody wants to scroll through hundreds of thousands of drawings.  Or for that matter, load a page having hundreds of thousands of links into a browser!  Just the few thousand documents the library already has is slow enough!  So in the past, the document library essentially just provided a disclaimer that bailed on engineering drawings.

Well, it does still essentially bail on them!  But most of our engineering drawings originally came from scans of "aperture card boxes" from the National Archives, so the improvement to the library is that it now lists each of the aperture-card boxes that has already been scanned, along with the range of drawing numbers in each of those boxes.  That's feasible, since each box only holds ~1800 slides, so there are many less boxes than there are drawings, and it doesn't clog up the document library page to list them all.

Admittedly this is a minor improvement that isn't of enormous use right now.  But that's partially because scanning the aperture-card boxes was put on hold a couple of years ago due to the pandemic, so no new boxes of scans have been added to our website for a long time.  When scanning eventually resumes, however, any newly scanned boxes will now show up in the document library's "recent additions" and will have badges, just like any other newly-added document in the library does.  That wouldn't have happened before.

• The ACE-S/C Operator's Manual, dated June 1, 1966. We already have a scan of the initial release of this document -- this appears to be the first revision after that one.
• ACE-S/C Operator Course Study Guides. This is a much larger document that goes into much more detail about how the Acceptance Checkout Equipment actually works.
• OCP-B-63005-LTA-8, Checklist and Procedure - Vehicle Support Systems Installation Chamber B. This is the as-run procedure used to wire up LTA-8 to all of the associated ground support equipment in its thermal-vacuum test.
• LPC 4-1, Procedure for the Preparation and Processing of the Test Preparation Sheet... a charmingly named procedure to prepare the sheet that you use to prepare for a test. Notably for us, it includes a listing of numeric "Spacecraft Categories" (e.g. 280 = Vehicle Structure), and so it can be used as a partial decoder for Grumman engineering drawings in which the first three digits after the LDW are this category.

For whatever reason, the ACE-S/C Operator Course Study Guides seemed rather compelling, though I can't give you any good reason for saying so.  Fortunately, I was able to tear my attention away from it long enough to write this little note you're reading right now.

I did notice while doing so that the ACE-S/C Operator's Manual, along with the earlier revision of it that were already in the library, remain uncategorized.  I.e., they appear in the library only in the vast section (entitled "Everything") that enumerates all of the documents in the library, rather than in any of the much smaller special-purpose sections like "Programmers' Manuals", "Math Flow", or "Digital Group Memos".  So you'd never find such uncategorized documents without a text search.  I can't help wonder how many of the 2600+ documents filed in the library are like this?

But wait!  Why wonder, when I can just do a little software magic to find out? (... Time passes ....)  If you look in the library's Everything section from now on, you'll find that uncategorized documents appearing only in the library section are marked with the emoji 😮, and that there's a summary at the very end of the section of how many such documents there are.  As of this moment, it turns out that there are 584 inadequately-categorized documents out of 2639 total.  Quite a lot.  But not as bad as I feared.

• Apollo Training course A-324 slides on the various CSM sequential systems (SECS, EDS, LES, ELS)
• The Preliminary Reliability Profile report for mission 204A (i.e. Apollo 1)
• A report on communication system performance during AS-202
• A communications performance and coverage analysis for Apollo 5 / LM-1

• The final pre-flight thermal analysis for LM-3
• A training document for the CSM mechanical subsystems
• An odd set of Block II CSM slides? It's missing the first 300+ pages and I have no idea what it is exactly.... it kind of strikes me as design review material or something like that. It came in a big lot with other more interesting things that I've already sent over. But it has things that are interesting in their own right, like some CSM drawing trees, listings of ICDs for subsystems, and rundowns of Block I/II differences.
• A lovely set of photographs of Apollo 6's instrument unit.

As far as the "odd set of Block II CSM slides" is concerned, while I haven't had the chance to look at them too closely yet, I'd add that the most-notable part to me so far is the following illustration (which I'm showing in reduced form):

• The Lunar Module Mission Simulator Instructor's Handbook Volume I, Simulator Description. This manual contains detail on every switch and display, as well as information about how all of the subsystems are simulated.
• The Proposal for LEM Mission Simulator Volume II, Technical Addendum: Glossary of Symbols. Despite the unimpressive name, this document includes a lot of flowcharts showing the mathematical equations backing the LMS.

• LTA-8 (thermal-vacuum testing)
• LM-7, 8, and 9 (Apollo 13, 14, and the unflown LM on display at KSC)
• LM-10 and subsequent (Apollo 15+)

[To Mike's comments, I'd add that while a lot of folks would think it's natural to just skip the LTA-8 version and move right on to the Apollo 13+ versions, the LTA-8 version is in far better shape than the other two versions.  So where the documents overlap, it may still be worthwhile consulting the LTA-8 version even if you don't actually care about LTA-8 specifically.]

• Removed links to its super-duper poor PDF, leaving behind a link only to the "merely" super-poor highest-quality scans at our archive.org site; and
• Correspondent "jumpjack" has been trying to decipher it, so I've added a link to their notes on the topic in our GitHub repository's issue list.

Obviously the dream (in lieu of finding a better copy of the document) would be a fully-legible transcription of it.  Whether that will ever happen, I can't say.  It turns out there actually is a prospect for getting a better copy of the document, but that prospect is vague, without any definite roadmap for doing so, so I wouldn't hold my breath!

On a completely different topic (but also thanks to "jumpjack"), I've set up a feature in our GitHub repository called "Discussions".  Virtual AGC Discussions on GitHub work like a souped-up version of our Virtual AGC mailing list, which frankly has been a source of problems over the years.  So if I can move away from the mailing list to something that's not only better but also less of a problem for me, it's a win-win!  Admittedly, since I just now set it up, there's no content on it yet other than my welcoming thread.  There are bound to be some teething problems.  Anyway, I invite you to use it.

• A partial revision to the SA-513/SL-1 Launch Mission Rules Input Document. While it's not the full version, it is interesting in that it is first document of this type for us.
• Revision H of V34-90001, the Elementary Functional Integrated System Schematics for the Block II Design Reference Mission. We already have the later and more accurate revision K, but this early one shows some interesting differences along the development history of the CSM.

Besides that, you may notice that there's a digital simulation of an Apollo 11 landing that appears among the recent additions to the library.  But don't get excited, because it's not new.  It's simply that I've been told (thanks to correspondent "jumpjack") that the PDF I had formerly linked as the preferred document version was unreadable.  Consequently, I've substituted a link to a more-legible version.  But it's the same physical hardcopy and scan.

• Regarding the AGS, there have been a couple of changes, both thanks to a reader identifying themself as "spacex15":
• A potential fix has been put into place for a bug in the treatment by yaAGS (the Abort Guidance System's CPU emulator) of overflow in the 'MPR' opcode.  I say "potential" merely because the AGS documentation is not extensive enough to unambiguously tell us that the fix is fully correct.  But I've been told that the bug affects radar updates by the AGS in NASSP, and that the fix fixes that (or at least makes it better than it was), so I'm inclined to think the change is a pretty good one.
• The encoding of the decimal integer -1 and the fixed point number -1.0 differ from each other in the AGS, and this explains a discrepancy in the documentation of how the AGS encodes -1 that I had written a few nasty words about on the AGS web-page.  Well, semi-nasty.  Well, not gushing with praise.  Well, I had said the AGS documentation was wrong.  So I've toned down my language a tad to simply point out the reason for the documentation's discrepancy, rather than applying the W-word to it.
  
• I've been told (thanks Thymo van Beers!), and verified for myself, that certain hyperlinks on the website have stopped working in the last week or so.  I refer to links that are targeted at folders on the website, as opposed to specific files on the website, thus allowing you to see the contents of the folders for yourself without my having to go to the effort of creating web-pages.  For example, a couple of weeks ago, a hyperlink like this one would have allowed you to browse the contents of a folder that contains all of the colorized, syntax-highlighted listings of AGC software we've transcribed ... whereas now, it just gives a "403 Forbidden" error.  To be clear, the files themselves are still accessible from hyperlinks to them on our web-pages; it's just that you can't browse through them on your own by viewing the folder's directory listing.  Fortunately, there aren't too many links like this that people would find helpful, so for most people this is probably not even an inconvenience; but for some it's a real irritation.  Presumably this is some change ibiblio.org has made globally for security reasons, and I don't immediately have any workaround for it.  The "staging" version of the website exhibits the same problem, so presumably GitHub is using the same webserver security restrictions in this regard as ibiblio.  At any rate, the problem has been kicked upstream to ibiblio.org's support team.  Hopefully they'll be able respond (some day) with helpful information, at which point the links will start working again.  For now, though, I fear it's just something that must be endured.
• On a more-pleasant note, a couple of Grumman documents Mike Stewart got from somewhere have been added to the document library:
• OCP-B-90000-B-1, the LTA-8 Manrating Test. This is the full test procedure for the 1968 manned thermal vacuum tests of LTA-8 in Houston's Chamber B.
• OCP-B-90008-LM-2, the LM-2 Landing Simulation Test Post Test Baseline -- which is a confusing title. In April 1968, LM-2 underwent a drop test. After being attached to the drop fixture, it underwent a full system functional test to establish vehicle health. It was then dropped to simulate a landing, and then essentially the same test was run again to make sure everything still worked correctly after the shock and stresses of a simulated landing. This as-run procedure is for that post-drop functional retest.

• A handful of PCRs and PCNs
• DG Memo 145, "A Manual Abort Guidance Procedure Based On Range and Altitude Measurements", is a really interesting early memo by Allan Klumpp that presents a mechanical geared calculator for LM abort and CSM rendezvous.
• A set of memos related to the DPS throttle oscillation problem caused by an incorrect THROTLAG value.
• A set of memos concerning an unexpected yaw at the end of P64.
• E-1551, "Functions and Mechanization of the Apollo Guidance and Navigation System", contains early diagrams and descriptions of the inertial subsystem and its interfaces to the AGC.
• A few "Luminary Development Note" memos, which have good detail on testing.
• Most of the "Luminary Project Memos", which were started by Russ Larson around the time of Luminary 1D. They're mostly procedural meeting scheduling, but some of them have good/useful information.
• Another set of XDE (Engineering Design Information Exhibit) documents, concerning the AGC, CDU, PIPAs, optics.
  

• ACB-40 for Luminary 1B, which looks like it was formerly missing
• Some Apollo 17 checklist/procedure documents
• Something called "Apollo Block II Command Module and LEM Guidance Navigation and Control System Mechanization and Block Diagrams", which turns out to be pretty much entirely foldouts containing 2015xxx and 6015xxx engineering drawings in foldout form -- plus a handful of drawings that had not (yet?) been assigned a drawing number.
• E-1087, the Documentation Handbook and Plan, which looks potentially very interesting and useful in a meta/archival kind of way.
• The very first revision of the LEM Familiarization Manual, which describes an extremely early version containing a front document port instead of a front hatch.
• A technical description for the Traverse Gravimeter designed by MIT/IL for later missions
• A set of MIT Management Development Plan meeting notes, with lots of more management-y type stuff like delivery dates, personnel assignments, etc.
• Assorted other memos and documents

• John's description of the actual OBC architecture.
• His description of his own simulator for it, which he called the Simple Gemini Spacecraft Computer (SGSC).  His is a hardware simulation rather than a software simulation, so his description includes circuit diagrams rather than software.
  
• An extremely brief coding example of how to assemble OBC assembly-language into a form in which it can be executed on is simulator.

Since John didn't provide an assembler, his coding example is hand assembled.  Of course, we have an OBC assembler, though I doubt it's in as debugged a form as our LVDC assembler.  Still, I'm sure it could be pepped up to a 100% working state, if anyone chooses to build the OBC simulator and wants to run some code on it.  By the same token, I suppose you could adapt John's OBC simulator into an LVDC assembler, and that might be even better.

Either an OBC or LVDC hardware simulator would be of great use in debugging our software-based OBC/LVDC simulators.  It wasn't until Mike Stewart came along with his Block II AGC hardware simulation and ran it side-by-side with our software AGC simulator that we (well ... to be honest, he) was truly able to ring the bugs out of both of them.

• 3 new documents added to the Document Library page.  The prizes are AGC telemetry dumps from the Apollo 11 and Apollo 12 landings, formatted in a relatively friendly way for human consumption, and with some hand-written annotations.
• More progress on Comanche 67 reconstruction, now with 8 memory banks having correct checksums, and the number of overflowing banks reduced to 2.  With a total of 36 memory banks, and only 8 cleared, there's a long way to go.  But better 8 than never.
  

• In the Document Library, lots more titles of PCRs, PCNs, and Software Anomaly Reports were found and added.
• Some progress has been made in the Comanche 67 reconstruction recently, in that we now have 6 memory banks with correct checksums, whereas a week ago there were only 4.  On the other hand, there are now 3 memory banks which overflow at assembly time (which is more than before).  But progress is progress, however slow and halting.  All of the known PCRs, PCNs, and Software Anomaly Reports pertaining to Comanche 67 have been reanalyzed from scratch, without reference to the analysis that had been done before.  The ongoing investigation is now temporarily but systematically being documented in a wiki framework, and it's much cleaner to work with and follow than the confused mess the old documentation (as an "issue" in our github repository) had been.  I guess using appropriate tools really does affect the quality of the work.  Who would have guessed?  But even using appropriate tools doesn't compensate very well for a lack of appropriate information.
  

SUNDISK PCR’s Approved at SCB ! ! !

There was a flurry of excitement among SCB members when a SUNDISK PCR was introduced. The excitement subsided when the members found out that only the GSOP was being changed.

• Various miscellaneous improvements to the document-library page, including a new mission-specific LTA-8 section, additions to various other sections based on improved characterization of some documents (an ongoing process), and additions/fixes to the table of known AGC software releases for rope manufacture (another ongoing process).
• It had been pointed out to me that I had been playing fast and loose with the naming of certain AGC software revisions, and that this could lead to confusion ... particularly confusion as to flight software, which is the worst kind of confusion.  So I've hopefully fixed up the Luminary and Colossus pages to cover up my faux pas in this regard.  The specifics are that the flight programs MANCHE45, MANCHE72, LUM69, LMY99, and LM131 (and the development software LUM131) for Apollos 10, 11, and 13 were not, strictly speaking, revisions of COMANCHE and LUMINARY, but were rather side-development branches from them, and thus bear different program names and incompatible revision levels.  Indeed, LUM131 was branched from LUMINARY 131, and then LM131 was branched (again!) from LUM131.  It makes for a more-confusing story, but a more-accurate one than I (and some of the contemporary memos) had been telling.
  

• Rewrote the opening blurbs for the Document Library's sections on PCRs/PCNs and ACB Requests/Software Anomaly Reports.  It turns out it's helpful to actually find out what things are before writing about them.  Who knew?
• Speaking of the Document Library, you'll find hundreds of supposedly recently-added documents today.  Actually, not a single one of them is truly new to the library.  It's just that I belatedly realized that over time I had accumulated quite a few PDFs which were lacking searchable text.  So I've added searchable text to them, and now they're interpreted as being "new".  In point of fact, I did this to every PDF file on the website that needed it, not just those in the library.  Ultimately, 716 PDF files in all were fixed up; but only 232 of them show up among the recently added to the Document Library, which is about 8% of the library.  The principal advantage to having searchable text is that these files will now show up more usefully in our Google search bar (at the top of every page of the website).  As it happens, they showed up in the search results even before I added searchable text to them, but if they were hundreds of pages long they were simply useless once you opened them up locally because you could never search within them to find what Google had promised you they contained.  I guess that Google must do its own OCR'ing process when it finds unsearchable PDFs, even though it ends up being of limited use when your documents are longer than 1-2 pages.  This will be better.
• For reasons with which I won't bore you, I've put together a table of all AGC programs/revisions which I could find had been released for manufacturing of their core-rope memory modules.  This table is pretty big, and I've added it to the lead-in for the Assembly Listings section of our Document Library.  If I recall correctly, nearly 75 software revisions of Luminary, Colossus, and other programs like Skylark, Sundance, and so on, were manufactured as ropes; leaving 500-1000 revisions for which ropes were not manufactured.  (Recall that there were 210 revisions of Luminary, 249 of Colossus 1, 108 of Colossus 2, 72 of Colossus 3, 88 of Aurora, ..., well, you get the idea.)  I had previously begun our Luminary and Colossus pages with much-more-abbreviated release data, so I've rewritten the openings of the Luminary and Colossus pages to remove that abbreviated discussion and instead point to the big table.
  

• Another load of 26 documents from Don Eyles's stash added to the Document Library.
• More nailing-down and additional explication that SOLARIUM 55 was used in Apollo 4 as well as Apollo 6.  Our huge stash of G&N engineering drawings nails this down, which I'd regard that as the most-convincing argument yet.
  

• Kondoization of the Colossus page has been completed, as well as cleanups of yesterday's work on the Luminary page.  If you have beefs, lay them on me!
• Up to now, we've speculated (and have had good reason to do so) that SOLARIUM 55 was the software used in both the Apollo 6 and Apollo 4 unmanned missions, even though in theory Apollo 4 used SOLARIUM 54.  I now regard our speculation as a proven fact, and have altered the descriptions on the Colossus page and the Document Library page accordingly.  (In brief, I have belatedly noticed that Table 4-I of report R-700, vol. 3, simply says it was used on both, and unambiguously identifies our SOLARIUM 55 source-code listing, by both name and part number, as being the software it's referring to.)
• Spent a little more effort trying to track down the SUNSPOT revision number that would have been used for Apollo 1.  No luck with that, but I did find what I can assert with reasonable confidence is a log-section by log-section allocation of fixed memory; i.e., the list of log sections in the program, and how many words of memory each of them took.  I've added this info the Colossus page ... which now that it's Kondoized, doesn't affect the comfort in navigating the page.  A great discovery!  I can write and write endlessly detailed discussions (which I'd never have the patience to read myself), and as long as they're on the Colossus or Luminary pages, I don't have to worry about how incredibly boring they must be.  An amazing innovation indeed.
  

• Fixed up links on several pages to point to the new Document Library rather than the old.  But there is a lot more cleanup to do in that respect.
• Realized that neither the new nor the old Document Library page had a section for Block I specific documents.  I've corrected that — new page only, of course!
• Realized that none of the Apollo mission-specific sections of the (new) Document Library page included the LUMINARY or COLOSSUS Memos related to the software changes leading up to the software releases for those missions.  Nor indeed, any documents keyed by the missions' software revisions (as opposed to mission number).  So I fixed that.  But there may be more work to do in that area, particularly in regard to PCR/PCNs and Software Anomalies.
• I've "Kondoized" the big table of LUMINARY revisions on our Luminary page.  I haven't actually removed anything from it, except incidentally, but I've reorganized it by liberally taking advantage of the mission-specific sections on our improved Document Library page and by superficially shortening up most of my long-winded descriptions of the various Luminary revisions with lots of "Read more" buttons.  So the end result seems much less intimidating and seems easier to navigate.  I'll probably Kondoize the Colossus page as well tomorrow, if time permits.
  

• The old page was very unsystematic in how it presented bibliographic entries, whereas the new page is perfectly regular in how it formats entries ... within the constraint, of course, that the information it wants display doesn't always exist.
  
• New entries are easier to find.  No more foolish  icons!  Instead, there's simply a section (Recently Added Documents) that lists the last couple months of items, from newest to oldest.  Which means that I can also stop listing the "significant" new entries here in this change log.
  
• Items may appear in several relevant sections of the library, if they're all relevant, rather than just appearing in whatever (single) section I had a whim to put it.  (And then being unfindable if I had chosen poorly.)  For example, the Apollo 17 guidance-equation document would appear both in the section on guidance equations and the section on Apollo 17, and maybe in other sections as well.
• All of the documents on the Virtual AGC site are included, whereas before, some very important items like the AGC program listings appeared only on the LUMINARY and COLOSSUS pages, and didn't show up on the library page at all.  Similarly for the engineering drawings such as the AGC or DSKY electrical schematics.  If you were to look (say) at the Apollo 17 section on the replacement document-library page, you'd find all documentation we have about Apollo 17, including the electrical and mechanical diagrams for the AGC/DSKY (and the remainder of the Apollo 17 G&N system) and the AGC and AGS software listings.
• The replacement page has more information about the documents than the old page, but doesn't insist on cluttering your screen with a lot of it.  For example, if you can hover the mouse cursor over the link for a document, a small pop-up will tell you the download size and who contributed the document to us.  No more enormous screen space taken up by my profuse thanks to people you've never heard of!  The thanks are still there, but fat less intrusive.

And so on.  I won't continue to rant about it, since if you're not interested, you won't care, and if you are interested, you can certainly discover whatever you like or don't like about it yourself.  My point was simply that the thing looks remarkably similar to the old thing, but seems to me to be greatly improved.  And certainly easier for me to maintain.  Which is good, since I've fallen behind again in adding new documents, whilst I was spending all that time reworking the document-library page from scratch!

• Over 16 years ago, Fabrizio Bernardini had sent in images of Apollo 15 LGC Data Cards, which I had simply posted as a folder of JPGs all this time ... very tough to page through or download with a browser!  So last week, I had silently replaced the folder of JPGs with a PDF.  (Perhaps even more irritating, Fabrizio had apparently originally sent me higher-resolution images than I actually posted, so it would have been nice to make the PDF from those higher-resolution images.  If only I could find them, 16 years later!)
• Nearly 3 years ago, James Berry let me scan his AC Electronics Apollo 11 manual.  But I was crushed for time, and couldn't spend the time processing the imagery that I should have, so I ended up posting a crummy PDF back then.  Today, I've done the extra work, and have replaced that crummy PDF with a less-incompetent one.  (Of course, if I were scanning it today, the raw scanned imagery itself would have been much better as well.  In the end, you can't win!)
  

• New flight procedures in the Apollo 17 portion of the "Miscellaneous Mission Documents" library section.
• New flight checklists in the Apollo 17 portion of the "Flight Data Files" library section.
• A new Flight Crew G&N Dictionary in the Apollo 9 portion of the "Flight Data Files" library section.

The first two groups are from our continuing series of scans (by Mike Stewart) of Don Eyles's seemingly-endless collection.  It is the final item, however, which stands out for me in this batch. By the way, many thanks to the Echoes from Apollo website for sending me the images, not without suffering a bit of inconvenience in doing so, I imagine! The G&N Dictionary documents, in case you haven't looked at them before — we currently had only the ones for Apollo 11, 12, 13, and 17 missions — are a kind of quick-reference for the crew for everything G&N related, and as such, most of the information in them is pretty reasonably accessible anyway ... if you happen to have the AGC source code or other significant documentation for the mission.  But not everything in the G&N Dictionary is so readily accessible for us.  In fact, some of the information in it is unique at the present time.  Why?  Well, because it covers not only AGC use, but also Abort Guidance System (AGS) usage, including not only basic procedures for using the AGS software for various tasks; it contains lists of some octal addresses of variables in the AGS software as well.  And while we have the AGS software used for some Apollo missions — namely, Apollo 11, 12, 15, 16, and 17 — we do not have the AGS software for Apollo 5, 9, 10, 13, or 14.  Consequently, at least some of the the information summarized in the Apollo 9 Flight Crew G&N Dictionary is the only information we have about AGS Flight Program 3 at present.  Whether we're clever enough to actually use that information for anything remains to be seen. 

• The SC-012 (Apollo 1) guidance and control data book
• A graphic of the erasable memory map for LUMINARY 204 (which was getting very close to the final revision, 210)
  

• The "User's Guide for the General Assembler Program (GAP)".  Even though we almost invariably call the AGC assembler program "YUL" on this site, YUL was just the original version of the assembler, and was only used for early AGC software like RETREAD or SOLARIUM.  YUL was superseded by GAP, which was an entirely new program, which ran on an entirely different computer model.  Most the AGC program listings we have were thus intended to be assembled by GAP, rather than by YUL.  The GAP User's Guide is quite a treasure trove of information.
• A memo by Jack Garman, the "Apollo 11 Post-Flight Summary".
• Section 7 ("Erasable Memory Programs") of SKYLARK's GSOP document.  SKYLARK, if you'll recall, is the AGC software for the Skylab and ASTP missions.  Since we don't have the actual AGC software listings for those missions, every little bit of relevant documentation is precious.
• And various little odds-and-ends I won't bore you with that are relevant to my ongoing struggle to recreate the COMANCHE 67 source code.  Well, I'll bore you with one thing, because it illustrates the way that valuable info can be hidden in the most unlikely places:  The GAP User's Guide I mentioned above has an Appendix containing a complete octal dump of one of COMANCHE 67's memory banks, and partial dumps of two other banks.  Who woulda thunk it?
  

• Apollo 7 Final Flight Plan.  (Previously, we had only the preliminary plan.)
• A better scan of AGC4 Memo #9, on which our AGC emulator (yaAGC) is principally based.  But also, a later revision of the Memo and an "appendix" to a separate previously-unknown Memo #8 (but not the body of Memo #8) explaining the AGC's control pulses similarly to Memo #9.
  

I notice that I've been giving no credit for all these new docs.  Mike has gone to Boston and has been getting stuff from the MIT Museum and from Don Eyles's secret stash, the latter of which I had foolishly thought was exhausted long ago.  Thank goodness Marie Kondo had never gotten her evil clutches on Don.  (Joke!  Sort of.)

In the event that someone in the far distant future reads this, and wonders just what I'm talking about, Marie Kondo is a currently-influential advocate of making your life better by ruthlessly eliminating clutter.  Which would have been an absolute disaster for the Virtual AGC Project.  If you knew the stories developers have told me even within the last few weeks of the material which had been thrown away because it was taking up too much room in the house ... well, you'd be heartbroken.  I won't tell you, though.  It's too devastating.

• There has been some significant restructuring and rewriting of the Apollo 11 LM software on our Luminary page.  The software revisions presented there have changed: Luminary 96 (new reconstruction!) has been added and Luminary 99 rev 2 has been dropped.  (Of course, all source code has remained unchanged, and Luminary 99 rev 1 continues to be correctly continues to be presented as the flown revision.)  The presentation before the change was strongly influenced by some recollections of AGC developer Jim Kernan, who maintained that there was a Luminary 99 rev 2, even though all documentary evidence denied its existence; so I had presented a reconstruction of Luminary 99 rev 2 based on Jim's story, even while asserting that it had never been flown.  However, Mike Stewart has just found a software anomaly report (LNY-59), not only allowing him to reconstruct the previously-missing revision Luminary 96, but also to conclude (with Don Eyles concurring) that Jim Kernan's recollections apply not to Luminary 99 rev 1/2, but to Luminary 96/97 instead.  So as I said, Luminary 96 is now in, Luminary 99 rev 2 is a fantasy and is out!
• In our software repository, Luminary 96 is now built by default and 99 rev 2 is not, while the VirtualAGC GUI program has been updated to add Luminary 96 and remove Luminary 99 rev 2.  Moreover, the AGS tips in the GUI have been fixed to account for the fact that Apollo 12 is now known to use AGS Flight Program 6 rather than 7 (see entry from 2021-08-03) ... although the GUI software apparently does not pick the AGS Flight Program version on the basis of the Apollo mission number, just leaving it up to the discretion of the user, so I suppose that's something I'll want to look at in the future.
  
• I'm in the process of slowly integrating new info about the LVDC software ... although so far it's more about the LVDC software developers than about the software itself.  I expect a number of changes to the LVDC page in the near future, though probably no earth-shattering revelations.  It's a work in progress.
  

• There has been a slight reorganization in the document library, in that the "Checklists" section has been renamed "Flight Data Files (Checklists, G&N Dictionaries, ...)", and some documents previously residing elsewhere have been moved to it.  There are several overlapping rationales.  Apparently, "flight data files" is the generic term for all flown documentation, including both checklists (of which several more were added today, and of which I'm told to expect an influx in the relatively near future) and G&N dictionaries (of which several were added a couple of weeks ago, and an additional one was added today).  Thanks to Nik Beug for the new docs and the suggested reorganization.
• Nik has dropped an additional gift on us, in that he has completed his work on simulating the unmanned Apollo 4 mission in the Orbiter spaceflight simulator's NASSP add-on, using the actual Block 1 AGC SOLARIUM software.  Check out his videos.
  

• Added to the mission-specific section of the document library some samples of an important class of document that I had previously been unaware of, or perhaps for which I hadn't had sufficient vision to recognize their value.  I'm referring to the "Flight Crew G&N Data Dictionary" (or sometimes "LM G&N Data Dictionary).  These documents include mission-specific information such as star charts, lists of AGC programs, verbs, and nouns, and concise explanations of using those for various procedures, and so on.  Of course, many of those things are available elsewhere in one form or another, making their collection into a separate document somewhat less exciting.  What isn't available elsewhere — so far as I know right now — is that the Data Dictionaries also provide the same kind of information for the LM's abort guidance computer (AGS).  And since the AGS does not use numbered programs or "nouns" and "verbs" the way the AGC does, all of the AGS programs and variables are listed specifically by numerical address.  Of course, for any version of the AGS Flight Program for which we actually have source code, we already know those numerical addresses directly from the code.  But for the Flight Program versions for which we have no program listing?  Then the associated Data Dictionary is the only available source, I think, for this very specific AGS info.  At the moment, we have the Data Dictionaries only for Apollo 11 and 12 (AGS Flight Program 6) and Apollo 13 (AGS Flight Program 7).  And among those, we already had the source code for Flight Programs 6 anyway.  But we have no source code for Flight Program 7, nor any obvious prospect for acquiring one; hence making the Apollo 13 Data Dictionary of unique value for insight into AGS Flight Program 7.  As far as other versions of the Data Dictionary are concerned, of particular interest in regard to AGC would be the versions for Apollo 10 (AGS Flight Program 5), Apollo 9 (AGS Flight Program 3), and Apollo 5 (AGS Flight Program 2).  There are pictures of random pages from other Data Dictionary versions on the internet, but I've had no luck obtaining any of their full content, or even any response to inquiries on the subject.  Unfortunately, this seems to be the kind of document which tends to be auctioned off, thus permanently disappearing from public view, or even in some cases being split apart in order to use the star charts decoratively on plaques!
  
• Added some notes to the AGS page about potentially reconstructing AGS Flight Program 7.  The prospect is slim, to say the least, but ....
  
• The build instructions for yaAGC's WebAssembly target have changed slightly, due to changes in Michael Franzl's WebAssembly port.
• Nik Beug has recently been working toward the goal — not complete yet! — of integrating the Virtual AGC Block 1 CPU emulator (yaAGCb1) into the NASSP add-on for the Orbiter spaceflight simulator.  The eventual goal, of course, is to be able to fly the Apollo 4 and Apollo 6 unmanned missions in NASSP/Orbiter, though since these were unmanned missions they naturally don't require a crew, and will probably be most interesting to people — particularly unqualified ones such as myself — as video captures of the simulated mission.  Naturally, Nik has been uncovering problems that I had been too daft to notice when I wrote the Block 1 emulator.  Meanwhile, Mike Stewart has been trying to run the SOLARIUM program's self-check in yaAGCb1, which I had also neglected to do myself!  And he has also uncovered problems with yaAGCb1 while trying to do so.  Recall that SOLARIUM 55 is the Block 1 AGC software that was actually used in Apollo 6, and probably in Apollo 4 as well.  Fortunately for us, or at least for me, Mike has been industriously fixing the yaAGCb1 problems he has found, which has also fixed the problems Nik has encountered in NASSP.  So far!  To reiterate, this does not mean that all problems in yaAGCb1 have been fixed yet, nor that the Block 1 AGC emulation in NASSP is ready to go.  But it does represent substantial progress, and does mean that anyone who's interested in the Block 1 AGC emulator would be well-advised to download the latest version of it rather than continue using the one that has been in the software repository for the last 3-4 years.  (By the way, you may recall that there are actually two Block 1 emulators in our repository:  my yaAGCb1 program and John Pultorak's yaAGC-Block1 program with my corrections in it.  Mike's new corrections to yaAGCb1 have not been migrated to yaAGC-Block1, but it is unlikely that John's program would have suffered from the same specific defects as my independently-written program would have anyway.)

This is the power of open-source software, friends!  Regardless of any little *cough!* "competence deficit" of the original author of the open-source software, it's always possible for someone else to step in and correct whatever problems there may be.

• On the document-library page, I reset the  indicators — last reset nearly two years ago, so no wonder they had become pretty useless!  They'll only adorn newly-added documents from today forward.
• Added the North American Aviation document "Apollo Electrical Installation" to the document library, thanks to Mike Stewart.  The document happens to contain a partial explanation for NAA's CSM drawing-number scheme, which we didn't previously have, so our electro-mechanical page was also updated with some of that information.
• Added several documents related to the Apollo 11 flight readiness review to the document library.
• Added a memo titled "June 5th Apollo Spacecraft Software Configuration Control Board (ASSCCB) meeting" to the document library.  Yes, sounds pretty dry, I know, but it contains the full texts for PCR 780 and PCR 815, relevant (particularly the latter) to the somewhat-ongoing effort to reconstruct Comanche 67 (Apollo 11 CM) software from Comanche 55 (Apollo 11) et al.
  

• I made some additional clarifications for the build instructions for yaAGC's WebAssembly target on the download page.
  
• Andy Smith has just completed his rather major effort to find and correct symbol misspellings in the AGC code base, as well as correcting various other bits of formatting discrepancies (vs the original listings) he found along the way.  These changes are now present in the AGC source-code files in our GitHub software repository, as well as in the colorized, syntax-highlighted code listings on this site.  In case you wonder what I mean when I say "major", there are presently 2575 AGC source-code files, of which Andy's effort affected 2456 of them.  That's not to say that the files were completely riddled by errors, but that a single misspelling can infect a large number of source files.  For example, the symbol ENDDCM, misspelled as ENDOCM, infected 26 files.  (Naturally, none of these typos resulted in any errors in the core ropes, which were and remain good.)  If you're curious, the complete set of file diffs can be viewed at this link.  Great job, Andy!  The only code not affected by Andy's audit is the Comanche 67 reconstruction I've been intermittently working on, and of course that's not because it doesn't have misspellings — which I'll have to take care of later — but because I've never merged it into the main branch of the repository.

As you may infer from earlier entries in this change log, Andy employed a smart method for this audit, rather than relying on the brute-force approach of simply eyeballing all of the original source listings.  His method instead involved comparing the symbol tables found at the end of each of the original listings against the symbol tables output by a modern assembly of the source files.  He used an AGC assembler he had created himself, which listed the symbols in the same order as the original assembler did, and formatted the printouts the same way as the original assembler did, thus making a comparisons easy. 

Which is not to say that he compared every entry of every symbol table.  No, he merely compared the first row of each column on each page of the symbol table, which is adequate to catch the vast majority of problems.  But not all!  So it's still possible that a much smaller number of misspellings continue to lurk, undetected.  Admittedly, I kind of doubt it.  If anyone wants to volunteering for the mind-bending task of checking the symbol tables more closely, I'm sure it would be appreciated.

When Andy started this audit, Virtual AGC's assembler (yaYUL) neither sorted the AGC symbols in precisely the same collating sequence as the original assemblers (YUL, GAP) and Andy's assembler, nor formatted/paginated the symbol tables similarly.  Andy has woken me up to the value of this, and as you may recall from a change-log entry a month or two ago, yaYUL now sorts, formats, and paginates symbol tables in a way that facilitates such comparisons.  That's one of the changes incorporated as of today in the colorized, syntax-highlighted AGC listings on this site.

• Clarified some of the build instructions for yaAGC's WebAssembly target.
• Added a new section for Virtual AGC's CMake-based build procedure.  This build method has been available for some time, thanks to Michael Hirsch, but like a dummy I didn't think to provide any online documentation for it up to now.  I was only reminded by a crop of recent updates to it.  Duh!
  

• The link on the Luminary page to the raw scans for the listing of RETREAD 44 was incorrect (it pointed to AURORA 12), and has been fixed.
• The assembler (yaYUL) in the github repository can now produce symbol tables of assembled AGC code using the collation order of the original Apollo-era assemblers.  Up to now, it has simply been using the native collation (presumably ASCII) of the platform on which yaYUL is being run.  Symbol-table files (*.symtab) that yaYUL creates for use with a debugger remain in the native order, since otherwise the debugger might not be able to interpret them properly.  The original YUL assembler, however, used the native character encoding of the Honeywell H-800 computer system on which it ran, and the printed symbol tables in the assembly listings it created were in that collating order.  Likewise, the original GAP assembler which succeeded YUL used the native IBM character encoding, namely EBCDIC, for sorting symbol tables.  Thus, while the assembly listings created by yaYUL had all the same symbols as those created by YUL or GAP, the symbols were in a different order, and the symbol tables were consequently difficult to compare.  In general, after today's update, all versions of the RETREAD, AURORA, SUNBURST, TRIVIUM, and SOLARIUM programs were originally assembled with YUL and now use yaYUL's H-800 ordering, while all other versions of AGC programs that are available to us were originally assembled with GAP and now use the EBCDIC ordering.  Admittedly, I haven't checked the new assembly listings vs the original scans in full detail, since the combined symbol tables of all the AGC versions we now have available undoubtedly total more than 100,000 symbols.  Yikes!  Nevertheless, even if there are some errors, I'm sure yaYUL's symbol-table ordering is very close to being correct.  The colorized HTML versions of the AGC source code here at the Virtual AGC website don't yet reflect the H-800/EBCDIC ordering, because some corrections to the AGC code base are in the works and I'd like to avoid unnecessary churn.  Once the HTML listings are updated, however, their symbol table ordering will hopefully match those of the scanned original assembly listings.
  

• AC/Delco Apollo 12 manual
• "Handbook on the Assembly and Testing of the M.I.T. 20IG Integrating Gyro Unit".  This is a 1956 Instrumentation Lab document, but is interesting for relevant similarities to the eventual Apollo IMU.
• "LM G&C Data Book"
  

• It turns out that we now have the complete section 5 (guidance equations) of the Comanche 72 (Apollo 13 CM) GSOP. (See yesterday's note about an incomplete document.)  Somehow the file transfer had gotten bollixed, but UHCL has now given me the full pdf.  Yay!
• Also added was "Apollo/Saturn V Postflight Trajectory - AS-512", the post-flight reconstruction of Apollo 17 launch vehicle trajectory.  (Thanks to Conor Kelly.)
  

• The Saturn V Flight Manual for SA-504, thus adding to the collection we already had of Saturn IB and Saturn V (SA-503, SA-507) flight manuals.
• An improved (or at any rate different) scan of the Lunar Excursion Module Familiarization Manual.  The thing that stands out about the new scan (as opposed to the old one) is that some attempt was made to rejoin wide drawings that the first scan had left as separate frames.  For example, in the old scan, Figure 3-3 comprises PDF pages 50-52, while in the new scan it's simply page 41.  But the effort to rejoin the drawings wasn't consistent, so you can certainly find some large drawings in the new scan that still show up as 2 or more frames.  For example, in the new scan, Figure 3-26 is 3 pages (PDF 91-93).  Even at that, in the old scan Figure 3-26 is 5 pages (PDF pages 122-126).  Yikes!  So one can't really complain too hard.
  

✓ Comanche 55 (final release of Apollo 11 CM code, from actual hardcopy)

→ ✓ Comanche 51 (initial release of Apollo 11 CM code, reconstruction)

→ ✓ Comanche 44 (initial release of Apollo 10 CM code, reconstruction)

→ ✓ Comanche 45 (intermediate release of Apollo 10 CM code, reconstruction)

→ ✓ Comanche 45/2 (final release of Apollo 10 CM code, reconstruction)

✓ Luminary 69 (initial release of Apollo 10 LM code, from actual hardcopy)

→ ✓ Luminary 69/2 (final release of Apollo 10 LM code, reconstruction)

• I've completed the reconstruction-justifying annotations in the Luminary 69/2 (Apollo 10 LM final release) code, and incorporated feedback on them, so they're good to go!
• The Comanche 51 reconstruction-justifying annotations I mentioned yesterday have been reviewed, and they're also good to go!
  
• I found that the color selection I had made for visited hyperlinks in the HTML colorized, syntax-highlighted assembly listings of AGC programs was no longer working out very well.  The color had apparently been chosen to reduce visual confusion vs the color of program comments.  While it worked well for that, it was too close to the black text in the reconstruction-justification annotations I've been adding to programs like Comanche 44 and 55.  I.e., in the colorized HTML, once you visited a link in an annotation, the link became essentially indistinguishable from the surrounding text in the annotation.  So I've now changed yaYUL (which generates the HTML) to use default visited-link coloring instead, and I've regenerated all of the colorized AGC HTML assembly listings to correct the coloring.
  

• The justifying annotations I had added to the reconstructed Comanche 44 code have now been reviewed and corrected.  I'm sure they're probably still not perfect, but they should at least be useful now and not lead anybody too far astray.
• A first draft of justifying annotations has been added (or tweaked in some cases) to the reconstruction of Comanche 51 from last year.

Incidentally, in case it isn't obvious, the immediate goal of the current reconstruction efforts is to arrive at a complete set of final releases Apollo 10 mission software.  I made a cute chart showing how all the reconstruction efforts and software versions flow together, and it's now included as part of the Apollo 10 entry on the Colossus page.

1. Reconstruct Comanche 51 (unavailable, unflown Apollo 11 code) from Comanche 55 (available, flown Apollo 11 code).
2. Reconstruct Comanche 44 from Comanche 51 and Colossus 249 (available, flown Apollo 9 code).
3. Reconstruct Comanche 45 from Comanche 44.
4. Reconstruct Comanche 45/2 from Comanche 45.
   

• Grumman "Design Criteria and Environments".  Provides a hundred-page summary the Lunar Module's detailed specifications.
• General Electric "Operator's manual, Acceptance Checkout Equipment — Spacecraft" for the CM and LM.
  
• "IBM Saturn IB/V Instrument Unit Technical Manual, Flight Control Computer".  This version of the document relates to the Saturn IB (AS-20x), whereas you may recall that the Saturn V (AS-50x) version of the document was added to the library a few months ago.
  

• 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.

• 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.
  

• 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.
  

• 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.
  

• 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 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).

• 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).

• 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".
  

• 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.
  

• 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.
  

• 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!
  

• 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.
  

• Added engineering-drawing titles and marked illegible scans in LEM aperture-card box 509.
• I've noticed somewhat belatedly that our Virtual AGC home page, which brags quite a bit about — excuse me, I mean humbly mentions, almost as an aside — the various materials the project provides, failed to mention the LEM engineering drawings.  I've corrected that oversight.
  

• The engineering-drawing titles for LEM aperture-card box 506 have been added.  I've also started inventorying and marking scans which are too illegible for one reason or another (usually due to being too light to fully read), so that's been done here as well.
• Retroactively marked the illegible scans in LEM aperture-card box 503, to which I had previously added the titles a week ago, as well as finding/fixing an incorrect drawing number or two that I missed on the first pass through the box.
  

• A table of 50 or so LEM engineering drawings that was previously gratuitously stuck at the end of the page for miscellaneous G&N engineering drawings, for lack of a better place to put it, has now been removed to its own dedicated page for miscellaneous LEM engineering drawings.  I suppose this reorganization doesn't need any serious justification ... nevertheless, it was done because I now recognize the need to eventually rescan a fairly significant number of LEM aperture cards whose initial scans are not legible enough.  The new miscellaneous LEM page will be a good place for those rescans to live.
• Although there will be no "search engine" for the LEM engineering-drawing scans like the one for the G&N scans — simply because the search database would be too big to reasonably load into a browser with the current situation vis-à-vis network bandwidth, computer memory, and so on — I've belatedly realized that there's no reason I can't provide such an index as a non-browser file that you can explicitly download, load into a spreadsheet, etc.  So I've added a master LEM engineering-drawing index file.  I expect this file will eventually exceed 60MB in size — which should give you some idea why I don't think you'd want to load it into your browser — though right now it's in the neighborhood of just 2MB.  Since the project of scanning the LEM drawings and indexing them is ongoing, the master-index file is naturally a work-in-progress as well!
• Added the titles for engineering drawings in LEM aperture-card box 505.
  

• Added the scans of LEM engineering drawings from aperture-card Box 508.
  
• Added the engineering-drawing titles in LEM Box 503.  This is the first LEM box whose title-addition has been completed (though Hartmuth is working on Box 502 as well), and as such is likely to have some teething problems ... but whether or not that turns out to be the case, it's still a lot better than having no titles.  A handful of drawing numbers and/or titles are missing or partial for a variety of reasons, such as the scan just being too light or the sheets containing the titles being in aperture-card boxes that haven't yet been scanned.  So expect there will be still be some improvements in that area in the coming months or years as additional scans dribble in.
  

• Completed adding Apollo G&N engineering drawings from aperture-card box 456 and added about the initial 60% of box 457.  A handful of additional assemblies were also added to the assembly drilldowns.
• Modified the instructions for building Virtual AGC on the Raspberry Pi for the latest version of the operating system (Raspbian Buster).
  

• Completed scans of Apollo G&N engineering drawings from aperture-card Box 448.
• Added complete scans from Box 449.
• Added scans of the initial part of Box 450.
• Regenerated engineering-drawing search engine and G&N assembly drilldowns.
  

• Several new MSC internal notes (64-FM-55, 65-FM-57, and 64-FM -74) were added to the Gemini section of the document library.  They relate to algorithms (with flowcharts) for computation of trajectories.  Though these were written for Gemini, they apparently remained the gold standard for Apollo, and are referenced in some of the Apollo docs recently added to the library.
• Scans for NARA-SW aperture-card Boxes 431 (partial), 432, 433, 436, and 437 have been added to the collection of engineering drawings.  Box 431 is particularly notable because it contains a number of Rework Instruction Bulletins (RIB), of which very few have been available previously.  Box 431 also physically contains a few dozen Interface Control Drawings from North American Aviation, but because these follow a different numbering convention than all of the MIT/AC/Ratheon/etc. aperture cards scanned so far, I have not yet worked out how they should be processed or presented, so I've not yet made them available online ... which is the reason that Box 431 is listed as being only "partial".  Besides that, because of the bulk of scans that have been added (~9000 microfilm slides), I've not had the opportunity to fix up the titles of most of the drawings.  For now, most of the titles just show up in the index in the 21-character abbreviated forms punched into the aperture cards.  I'll fix them up some time, but it's an ongoing process and I won't promise any specific time-table.

Note that while the newly-added engineering drawings have been used to update the drawing-index page and the various assembly drilldowns for different G&N System configurations, the latter have only been partially updated because their bills-of-material have not yet been transcribed ... i.e., newly added assemblies are not yet drilled down.  The additions to the drilldowns have the most impact on Block I G&N Systems, but all Block II and LM G&N Systems have been affected to one degree or another as well.

• NARA-SW aperture-card Box 434 has now been scanned.  This box contains just a handful of items (though with lots of revisions and pages each), so I'll list them all here.  They're all Apollo guidance & navigation system checkout procedures for various spacecraft:
  
• Document ND1002323 (revisions J and later), for the LM, running AURORA software.
  
• Document ND1002324 (all revisions), for the Block I CM (specifically, CM-014), running SUNSPOT software.  According to this document (p. 15), CM-014 was used only for testing and was eventually scrapped in 1977.  Since the CM was never used for anything other than testing, it's entirely possible that its AGC still had SUNSPOT ropes in it when the CM scrapped, and thus it seems possible that that Block I AGC (or its rope-modules separately) are still floating around somewhere.  In other words, SUNSPOT may be recoverable by dumping the contents of those rope modules, if they (and/or their AGC) are ever found.  Unfortunately, I neither know where the AGC nor its rope modules are, nor do I know of anyone who has successfully dumped the contents of Block I rope modules.  I wish I did.
  
• Document ND1002325 (revisions W and earlier), for the Block II CM, running SUNDIAL C or D software.
• Similarly, the first half of NARA-SW aperture-card Box 433 has also been scanned.  It contains many more documents than Box 434, so I won't list them all here.  They are principally process specifications and testing procedures.  The most-notable document, I think, is ND1002319, "ACE-S/C Computer Subprogram Specifications for Apollo CM and LM G&N Testing", but only through revision L.  (Revisions through U will be in the second half of the box, not yet available.)
  

• There has been a document talking about something called "SIMFAM" in our document library for a quite a while.  This is a memory adapter for the AGC, for ground testing, based on something called "braid memory" rather than core memory.  Unfortunately, I was unable to find out much about braid memory myself, but Nikki Stevens (thanks, Nikki!) has now sent me some info about it, and I've naturally incorporated an explanation into my descriptions.  (Alas! The info comes from a 1966 IEEE paper, which I fear is still under copyright even though not so marked, so I don't post the entire paper.)
• Various new documents have been added to the document library, most of them newly scanned (so their full-resolution scans are in our Internet Archive site in addition to the low-resolution links below), although the first one on the list below actually came from NTRS:
  
• 68-FM-256, "Project Apollo: Verification of Sundisk Orbital Navigation Program".  This actually contains a lot of software-related technical detail about SUNDISK 282, the Apollo 7 flight program.  (Thanks, Nik Beug!)
  
• 68-FM61-230, changes to 68-FM-23, "Logic and Equations for the Real-Time Computation of the Lunar Module Descent Planning Table" (which was already in the library).
• 68-FM-67, "Logic and Equations for the Real-Time Computation of the LM Launch Targeting and Display".
• E-2456, "Apollo Guidance and Navigation Flow Charts":
• Rev. 1, Program COLOSSUS 2D, COMANCHE 72 (full document).
• Rev. -, Program COLOSSUS 2C, COMANCHE 67 (just the flowcharts changed from COMANCHE 72).

• Mike Stewart has managed a true tour de force, by reconstructing and contributing the reconstructed LUMINARY 178 source code.  LUMINARY 178, you may recall is the LM's AGC program for the Apollo 14 mission.  It has been a sore spot for me for a while, in that we've had the LUMINARY code for all other flown missions — i.e, Apollo 10-13 and 15-17 — for a long time ... but not Apollo 14.  It has been the only one missing.  This is quibbling a little bit, I admit, since it ignores Apollo 5 and Apollo 9.  But technically those missions didn't use LUMINARY; Apollo 5 used SUNBURST (which we have!) and Apollo 9 used SUNDANCE (which we don't!).  So I guess the missing SUNDANCE will now become the sore spot.  But I digress.  Finally filling in the gap for Apollo 14 is great no matter how you look at it, but what makes it a tour de force, is the vast gap that this fills in terms of software changes.  The Apollo 13 and 15 LM  software were LUMINARY 131 and 210, respectively ... that's 79 revisions in between, with Apollo 14 being smack dab in the middle.  Amazing!  So the reconstruction requires figuring out the changes for something like 30-50 revisions.  Getting to the end of that process is like finding the missing link.  It makes the slogan you see in the website logo ("Apollo Digital Archaeology") seem quite appropriate.  Not only is the code in the software repository now, but support for it has been added to the VirtualAGC GUI.
  
• On a lesser note, I've finally finished proofing the LVDC source code's program comments.  Experience suggests there are still quite a few errors I missed.  Nevertheless, given that the code has been proofed, and assembles to exactly the expected core-rope image, I'm finally willing to put my stamp of approval on it and say that it's "ready".  If only ITAR concerns allowed me to freely provide it to you ....   Sigh!  Well, a lawyer's working on it, and will perhaps discover that the ITAR fears are overblown.  Or not.  At any rate, you can still apply to me on an individual basis to get the code if you're a "U.S. person" under the law.  Next step:  simulation.
  

• Added a copy of the Apollo 11 Operations Checklist to the document library.  This was already available at the Apollo Flight Journal, so please feel free to examine there instead.
• Scanning of the final half of aperture-card Box 435 from NARA SW has now been completed.  This batch contains "post-installation checkout procedures for the the G&N system.  The rate of scanning aperture-care boxes has slowed down somewhat recently due to circumstances, but is due to pick up again to a much higher rate in the near future.
  

• More updates to descriptions of LVDC assembly language, AS206RAM program structure, and so on.
• It turns out that my instructions for downloading a Virtual AGC "installer" for Windows may have been a tad thin in terms of explaining how to actually run the program once it has been downloaded.  So I've pepped up that explanation to make it a lot more explicit.
  

• Preliminary Apollo 14 Erasable Load
• Aborted Luminary 178 simulation

• Manoel has submitted a couple more 3D models, 2004739A-000 and -021, DSKY front cover.  This is significant because it turns out that model 2004929 (also DSKY front cover) added a couple of weeks ago was not the one called out for DSKY model 2003994-121 at all, and that 2004739 is what should be used.  This was not just an oversight, though!  The problem is that drawing 2004739 simply isn't dimensioned very thoroughly, whereas 2004929 is dimensioned quite thoroughly, so the hope was that 2004929 would be a good substitute.  Alas, it was not!  Some of the dimensions (specifically the width and height of openings for the indicator lamps) from drawing 2004929 are not compatible with the other constituent assemblies in DSKY 2003994-121.  Thus while the new models for 2004739 are intended to be exact representations of the original drawing, there's not enough detail on the original drawing to insure that; so the new models contain both elements from 2004929, as well as measurements which were fortunately able to be gotten from a physical 2004739 module.  Nevertheless, the potential for error remains and thus the models may need to be further adjusted over time.
• 10 new document scans from NARA SW have been added.  Many of them relate to RTCC software flowcharts for various Apollo 14 G&N computations, and to GSOP changes from Apollo 13 to 14.  Rather than enumerate those documents here, I'd suggest looking for the icon on the document-library page.
  

• Corrected my confused description of LVDC instructions HOP*, TRA*, TMI*, TNZ*:  I've belatedly realized that there should be no such instructions in the LVDC source code, and that the asterisks are added in the assembly listing to highlight that certain workarounds have been transparently performed.
• Manoel has added a few more 3D models for DSKY parts.  It should be noted that the first two of those models listed below are created from the external dimensional properties of "Specification Control Drawings" (SCD).  That's significant because the these assemblies were manufactured independently, and while they are really themselves assemblies, the internal characteristics of the assemblies are (well, were) known only to the manufacturers of the assemblies.  In other words, there are no available drawings describing their internal structures.  Consequently, you can't simply 3D print them and expect that they'll do anything for you, particularly since they contain circuitry not represented by the 3D models.  They'll need to be reverse engineered in order to reproduce their electrical and behavioral characteristics.  The third model is also problematic, because we don't have the latest revision of its original drawing.  That's significant, because most DSKY's specify use of configuration -001 of the part, while the most-recent drawing we have covers only up to configuration -000.  Consequently, the 3D model also conforms only to configuration -000 rather than to the necessary -001, and therefore also likely requires modification.
  
1. 1006315A, electroluminescent digital indicator
2. 1006387D, alarm indicator
   
3. 2004699A, indicator frame cover
   

• Manoel has added a few more 3D models for DSKY parts.  I forgot to mention yesterday that these are parts for DSKY model 2003994-121 (the final CM DSKY model), though the parts Manoel has submitted so far seem applicable to all Block II DSKY models I've checked so far.  (Admittedly not every single one!)  I probably should have mentioned too that the models being added so far are intended to precisely capture the original Apollo engineering drawings, and hence do not include any optimizations for (for example) 3D printing; alternate 3D models with such optimizations may be added in the future.  Also, for those who haven't stayed atop the behind-the-scenes discussions, it's perhaps useful information that the models are in STEP format, which can be imported into most 3D modeling programs, but specifically into the open-source FreeCAD modeler.  I probably should summarize what those parts are, too, rather than forcing you to figure it out for yourself.  Here's the complete list so far:
• 2004900A, rear cover
• 2004919E, adapter plate
• 2004920-, digital indicator connector plate
• 2004921A, alarm indicator connector plate
• 2004929A, front cover
• 2004968E, front housing
• Mike has confidently reconstructed yet another AGC software version, this time Artemis 71.  As you may recall, Artemis 72 is the software actually flown in the Apollo 15 through 17 Command Modules.  But Artemis 71 was originally intended to do so.  Artemis 72 flew instead, because of a bug fix.  As with all these software reconstructions that have been appearing lately, we have no actual assembly listing of Artemis 71 to work from.  Nevertheless, the clues present in the Artemis 72 assembly listing, in concert with the Artemis 71 memory-bank checksums (which we have from engineering drawing 2021154), allow us not only to infer the required changes, but to verify them afterward.  Great work, Mike!  The VirtualAGC GUI program now supports Artemis 71 as well, so you can run Artemis 71 or browse its source code in VirtualAGC if you like.
• The Apollo G&N system assembly drilldowns now include links to the appropriate 3D models of the associated parts wherever possible (similar to the way they have already been including links to CAD transcriptions of associated electrical schematics).
  

• Reworked a lot of the discussion of LVDC assembly-language coding, on the basis of my improved understanding of it, and particularly an explanation of the LVDC preprocessor.
• We've had our first submission of 3D models to our mechanical-drawing repository, for some DSKY parts.  They look pretty swell to me.  Thanks, Manoel da Silva Casquilho!
• Unfortunately, Manoel had to deal with some pretty poorly-written instructions in so far as the requirements on the 3D models, as well as practically non-existent instructions on how to actually submit them to the repository, so I've rewritten quite a lot of the section on our electro-mechanical page describing that stuff.  Hopefully it's better, but knowing myself I can't claim to be 100% confident that it is.
  

• A handful of documents added to the library a few weeks ago have now been removed.  Well, perhaps a handful and a half.  For the most part, I've done this by expunging the files themselves, but leaving the hyperlinks on the document library page and striking them out (thusly) so that it's easy to see what has been removed.  These documents originally came from NTRS, but were removed from NTRS when it was decided by NASA that they hadn't been approved for release; so now they've been removed from Virtual AGC too.  Sweet!  I don't actually know if it was necessary to remove them, but it has been done as a precaution.  Of the 1000+ documents we provide, who knows how many have thus been (or will be) taken retroactively out of the public domain, with no practical way for us to even know about it or react to it?  (Hint: We don't.)  Can you spell "time bomb waiting to go off"?  (Hint:  You don't have to.  I just spelled it out for you.)  Or perhaps, "closing the stable door after the horse has bolted"?  (Hint:  Ditto.)  For what it's worth, I think the documents are available on The Wayback Machine's cache of NTRS, if you can figure out how to find them, and with luck perhaps they'll return here at some point.
  
• Speaking of secret knowledge, I've finished my first pass at transcribing the LVDC AS-206RAM assembly listing to source code, but am afraid now to post it publicly because of ITAR and the danger that North Koreans may start pelting us with Saturn V or Saturn IB rockets if they get hold of this 50-year-old software listing.  (The projected cost of a Saturn V in 2019 dollars is around $726M, but that of a Saturn IB such as would have been used for the AS-206RAM mission is probably only around $220M.  A bargain, to a thrifty hawk!  To be fair, when I wrote those sentences, they were intended to be biting sarcasm, but given that LGM-118 Minuteman ICBMs would cost perhaps $110M in 2019 dollars it doesn't even seem that far-fetched that some nut-job would spend $200M for a Saturn IB as an ICBM, does it?)  Fortunately, anyone (who can prove they're an American) can naturally apply directly to me to get a copy of the transcribed software.  However, you might want to wait until it's decently proofed first and the assembler itself is ready.
  

• Clarified explanation of LVDC assembler behavior for lines having no punch-card sequence number.
• Made procedure for acquiring LVDC software listing from me quite a bit less painful.
  

• Mike has added yet another AGC software reconstruction, this time of the Comanche 51 source code.  Comanche 51 was the program that was first targeted for the Apollo 11 Command Module, though it was Comanche 55 that eventually flew in the mission.  Reconstruction of all these intermediate AGC software versions may strike you as merely an intellectual game, which I suppose it is in some ways, but it has serious benefits as well.  For example, I'll remind you that a few days ago we got the Luminary 69/2 reconstruction, and this was actually mission software (for the Apollo 10 LM) that we hadn't had originally.  In the case of Comanche, the Holy Grail would be reconstruction of Comanche 45/2, which is the missing mission software for the Apollo 10 CM.  Having Comanche 51 rather than just Comanche 55 gets us that much closer to the goal.  Even so, getting from Comanche 51 to 45/2 is quite hard, since we don't have the level of supporting documentation for Colossus that we do for Luminary.  A reconstruction of 45/2 would be ever so much easier if Margaret Hamilton just gave us her copy of Comanche 44 ... though that, sadly, seems less likely with every passing year.  But we'll see what we'll see!
• The G&N assembly drill-downs are once again up-to-date with respect to all of the engineering-drawing scans (and CAD transcriptions) collected so far.
  

• Mike has added reconstructions of the Luminary 97 and 98 source code, following the same procedure as for the Luminary 130 and 69 rev 2 reconstructions over the last couple of days.  There's slightly less confidence in the Luminary 98 reconstruction than in the 97 reconstruction, since back in 1969 Luminary 98 was just development software en route from 97 to 99, so its ropes were never manufactured nor its memory-bank checksums recorded.  However, if Mike's Luminary 98 reconstruction were in error, his 97 reconstruction would probably be in error as well ... which is unlikely since all of its memory-bank checksums are correct!  In other words, while we're less confident of the Luminary 98 reconstruction than in the 97 reconstruction, we still have a pretty high degree of confidence in it.
• On our Luminary page, I long ago hyperlinked the raw scans of AGC assembly listings stored at our Internet Archive site.  But in some sort of strange mental conniption, I belatedly find that I never did that on our Colossus page!  I guess it's because so much data was pouring in from Don Eyles at the time that I was thinking only about the Lunar Module and not about the Command Module at all.  Well, I have finally taken care of it now!
  

• Mike has added a reconstruction of the Luminary 130 source code, following the same process as for yesterday's reconstruction of Luminary 69 rev 2.  Admittedly not quite as exciting as yesterday's reconstruction if you're only interested in software actually flown.  On the other hand, it is becoming increasingly obvious that the more software versions we collect the easier it is to fill in the gaps between them, so it's nothing to be pooh-poohed by any means!  (Excuse me, I mean P00H-P00H'ed.)  Plus, various Apollo 13 documents referenced Luminary 130 anyway, and were never revised for 131, as far as we know. 
  
• The VirtualAGC GUI program has been updated for both Luminary 69 rev 2 and for Luminary 130.
  
• I've adjusted the size of the youtube video thumbnails I've embedded in the tables on the Luminary and Colossus pages, since I notice they were so big that when the windows were made smaller the text overflowed to the right and needed scrollbars to see.  I can't get rid of this effect entirely, but making the thumbnails smaller mitigated it somewhat.
• On the FAQ page, I've added links to Ken Shirriff's writeup of his article about bitcoin mining on the AGC, as well as to David Given's writeup of his port of his Cowgol programming language to the AGC, as well as the subsequent creation of a lunar lander game (Cowlark) written in Cowgol.  In other words, Cowlark is a lunar lander game which can be run on the AGC. Fun stuff, though I'm not sure programming in Cowgol actually gives you "the AGC programmer experience".
  

• Added G&N engineering drawing scans from NARA SW aperture-card boxes 467 (final 2/3) and 435 (first half).  Box 435 contains a lot of G&N system post-installation checkout procedures from North American Aviation.  It has been scanned out of order because some of the procedures relate to using SUNDIAL.  Another notable procedure therein uses SOLARIUM for checking out the Block I systems for Apollo 4 and 6.  All index pages and the engineering-drawing search engine have been updated, but the assembly drilldowns have not yet.
  
• Added three new documents to the library (thanks, Graham!) concerning AS-503A (an unflown alternative mission) and Skylab.
• Replaced the LVDC software sample images with higher-quality ones of the same pages.
• Don Eyles has sent along some scans of two data-card booklets:  an earlier one for the Retread 50, Aurora, and Sundial B & C software, and a later one for just the Aurora 88 and Sundial C software.  Since Aurora and Sundial were used for checkout of the LM and CM guidance systems, respectively, I infer from that Retread must also have been used for system checkouts at some point, but was then obsoleted.  As usual, the full-quality scans are at our Internet Archive site.  (Thanks, Don!)
  

• Yesterday's edition of The Orbital Mechanics podcast is an interview with me, talking about the Virtual AGC project.  It sounded good in my head when I said it, so *cough* *cough* it must be good on the podcast too!
• A few more miscellaneous documents have been added to the library (thanks, Graham!).  Just look for the  icon.
  

• It turns out that my comments yesterday about SUNDIAL D vs SUNDIAL E in the 2TV-1 mission were misguided.  What I should have been saying was that the fixed-memory modules (which are what holds the SUNDIAL program) were different than what what the engineering documentation led us to believe:  specifically, if you're interested, MIT's AGC contains software assembly 2021104-051 rather than the 2021104-041 we expected.  However, Mike has managed to find documentation that both of those assemblies held SUNDIAL E software anyway, so it hardly matters which one was installed in the computer.  Thus I can happily contradict what I said in yesterday's entry:  We truly do have the software for the 2TV-1 mission!  I've altered the description on the COLOSSUS page to reflect that fact.
• The VirtualAGC GUI program has now been updated (at GitHub) to have the 2TV-1 mission as one of the options.
• Added a series of documents (thanks, Graham Donald!) to the library, concerning potential applications of the LM.  Also, quite by chance, I found a grayscale scan of document R-700 online that's fantastic, compared to the B&W scans we already had, because you can actually see the photographs; naturally I snatched it and stuck it in the document library too.
  

• Much like with the RETREAD 50 AGC software we added a few weeks ago, the AGC Restoration team has now dumped the rope memory from the MIT Museum's AGC and has given us the AGC program SUNDIAL E.  This is our first look at SUNDIAL.  SUNDIAL E is close to, but presumably not exactly the same as, the SUNDIAL D software used for the 2TV-1 mission, so that's how I've categorized it on our COLOSSUS page.   In a larger sense, I think that SUNDIAL was generally used for system checkout of Command Modules, much as AURORA was for Lunar Modules.  We don't have the source code yet, since the restoration team has been so busy, but presumably Mike will churn it out for us in the reasonably-near future by comparing to similar program versions and judicious disassembly.  The binary is apparently ready-to-run in yaAGC, though I have not made the necessary changes yet to do so within the VirtualAGC GUI environment.
• At the same time, 3 out of the 6 rope modules for the program SUNDANCE 302 were dumped, and have been added to the GitHub repository.  I've not written up anything about it on the LUMINARY page yet, though, because I haven't figured out yet how to go about describing half of a program.  The idea, of course, is to try and find the other half of it later.
  
• In thrashing out whether SUNDIAL E was or was not used in 2TV-1, it became apparent that some of the compatibility tables in documents ND-1021042 and ND-1021043 could be used to fill in a couple of missing-link engineering drawings related to configurations of SUNDIAL and AURORA, so I've now done that and regenerated the assembly drilldowns of the engineering drawings accordingly.
  

• Added another couple of documents to the library, this time peripherally related to Apollo 13.  Incidentally, I was remiss yesterday in not thanking Graham Donald for sending these docs over to me.
• Yesterday's edition of The London Podcast by presenter Adrian Lacey, among other things features me talking about the Virtual AGC Project.
  

• More page images of the 1967 LVDC flight program have come in.  I've had to reorganize the underlying storage of these items a bit by taking the LVDC page images out of the GitHub repository.  Otherwise, if new images kept coming in — something of which there's no assurance whatever — they'd begin to overwhelm it.  But the change should be completely transparent to anyone looking at the website.
• Added my analysis as to whether the LVDC software is classified or as to whether it is illegal under ITAR to "export" it posting it online.  The executive summary is "no" to the former and "maybe yes, maybe no" to the latter.  Anyone with a better understanding of the legalities related to this than I am ... please pass along your wisdom to me!
  

• Updated the description of the LVDC's TLC interrupt with a bit of anecdotal info.
• The description of the LVDC's STO instruction was shockingly deficient in terms of how it covers subroutine linkages — namely, it didn't, and indeed provided misleading information — so I've fixed it up.
• I've added a lot of descriptive material about what I infer (or more politely, guess) from the LVDC sample code about the syntax of LVDC assembly language.  This is particularly true for the many assembly-language pseudo-ops that have appeared that we've never seen any references to before ... but it applies to the regular code as well.
  

• Added a link to Ken Shirriff's delightfully absurd blog article "Bitcoin mining on an Apollo Guidance Computer: 10.3 seconds per hash" to the AGC-restoration page.  He does his mining on the restored physical AGC, but shows you how to do it with Virtual AGC too.
  
• And another great treat, our first actual IBM LVDC source code, from a 1967 version of the LVDC flight program!  It's just a few pages of trig and square root routines, but you can see from the snapshots that there's a full (or at least very substantial) program listing beyond just those few samples.  It probably does not conform 100% to the syntax of the assembler I wrote for it a decade ago, but obviously at some point I'll fix up the assembler.  Unfortunately, my anonymous informant does not indicate that we will be receiving the full listing, and indeed implies very strongly that we will not.  So I can't you promise anything further.  Which is disappointing.  But the very positive takeaway is that assembly listings of the LVDC flight program do still exist ... a possibility which previous informants have poo-pooed up to now.
  

• I've removed some anecdotal bits of info from the LVDC page, relating to who wrote the software and how it was written, because I no longer have confidence in those anecdotes.  None of the technical info has changed.
• Added the CAD transcription for drawing 2010062F (Block II CDU power supply).
  

• Somehow, one of the files needed for Retread50 hadn't gotten into the repository, and this killed the entire build as soon as it got to that point in the process.  Weird, since our GitHub repository is set up to do a trial build whenever a commit to it is performed (which it did, and naturally, failed), and to email me about failures (which it didn't, as far as I can tell).  At any rate, I've added the missing file now. 
  
• Also, building Virtual AGC on newer Macs with clang (which, having only old Macs, I've never had any means to try) weren't working.  But a couple of extra instructions have now been added that may do the trick.  Is it a complete fix?  Time will tell. 
  

• We have been given a version of the AGC software that we didn't previously have!  The program is RETREAD 50, and you may recall that we already had gotten the similar program RETREAD 44 from Don Eyles.  However, we've gotten RETREAD 50 in a way completely different from all other AGC software.  We have not been given an assembly listing for RETREAD 50.  Rather, the AGC-restoration project (which you may have gotten wind of) was allowed to borrow core-rope modules containing RETREAD 50 from the Computer History Museum, thus allowing them to obtain a dump of the ropes, and (for good measure) regenerating the source code for it.  And we're the beneficiaries!  See our LUMINARY page and/or our GitHub software repository.
• In order to properly described how and why we managed to get RETREAD 50, I found myself writing an entire page devoted to just a description of the AGC restoration effort.  You'll see that a link to it now appears at the bottom right of the banner across the top of all our pages.  It's not quite complete yet, but feel free to check it out!
  

• Finally have the G&N assembly drilldown fully up-to-snuff ... just in time to go get more scans next week and to fall behind with it again.
• Added various more Grumman LM drawings to the miscellaneous drawing index page.
  

• In doing some semi-automated checking of the G&N assembly drilldowns, I've discovered to my horror that a lot of drawings that you'd never suspect were assemblies actually are assemblies.  Maybe 90% of them!  I mean, really, who would suspect that something called a "cover" or a "plate" is really an assembly?  I ask you.  I never even bothered to look at them.  The upshot of that is that the assembly drilldowns I've made are actually nowhere near as complete as I imagined, since I didn't have any support for drilling down a bunch of those non-assembly assemblies (with apologies to Woodward & Bernstein).  So I've made a tentative new beginning with some updates to the drilldowns, but there's a long way to go.
• But there's a bit of a treat today as well:  We've gotten a few top-level LM engineering drawings from the aperture-card boxes at NARA-SW, and perhaps someday we'll be able to explore the LM engineering drawings in much the same way we're now exploring the G&N engineering drawings.  Check them out!  One drawback with them is that while each drawing calls out the drawings for its sub-assemblies, it does so only by drawing number and no drawing name.  Furthermore, the drawings themselves have only numbers in their title blocks, and have no actual titles.  So I can't personally tell you what most of the assemblies are.  Anyone who wants to offer up a solution to this conundrum, please do so, since it will make figuring out these assemblies quite difficult!
  

• A variety of drawings for mil-spec parts used by the AGC/DSKY/G&N mechanical drawings have been posted online, and can be accessed through a new mil-spec parts index page, or by means of the engineering-drawing search engine.
• Document MIL-D-70327, called out by almost all AGC/DSKY/G&N electrical schematics, has been added to the reference section of the electro-mechanical page.
  

• The approaching 50th anniversary of Apollo 11 has sparked interest from various writers, and in reviewing some of our online materials so as not to make a complete fool of myself when talking to them, I can't help but notice various stuff that is out of date on the website.  Hopefully I've been able to make a dent in those, though I'm sure I haven't caught everything.
• Speaking of which, I had apparently forgotten to make any comments here about the new article by Brian Hayes in American Scientist magazine, "Moonshot Computing". In particular, Virtual AGC gets a short section of it's own.  But size, I've heard, isn't everything ... so check it out.  It's a terrific article!
• On the yaDSKY page, the mission-by-mission arrangements of the indicator lamps and their colors were previously speculative.  But by navigating through our recently-created engineering-drawing tree, I was able to fill them in for every mission.  It turns out there had been errors in the DSKY indicator lamps for Apollo 12 and 17, and that I had never gotten around to specifying the colors at all.  I haven't actually made any changes to the software related to this fix, but I'll get around to it at some point.  Probably.

• Previously-partial Box 462 now complete
• Entirety of Box 463
• Initial portion of Box 464

These boxes mostly continue with electrical and mechanical drawings of CM/LM guidance-system components like the CDU (coupling data unit), PIPA (pulsed integrating pendulum accelerometer), SXT (sextant), SCT (scanning telescope), and so on.

I also eliminated some information that was redundant across all of the box-index pages, because that info (however well-intentioned) was making it quite difficult to add new index pages.

• Added the CAD transcription for drawing 2005973- (indicator driver module D1-D6 for Block II DSKY 2003994).  See also the renderings of the CAD as image files.  But wait, you say, didn't you just add a different drawing (2005940A) yesterday and say exactly the same thing about it?!!!  Why yes, I did, thank you for noticing.  DSKY 2003994 is one of only a handful of cases I've encountered in which there's an inconsistency in its drawing tree as to which schematic is applicable.  The indicator driver module assembly (2003952-031) for DSKY 2003994 calls out schematic drawing 2005940, whereas the relay circuit assembly (2003910-021) of that selfsame indicator driver module assembly calls out schematic drawing 2005973 instead.  The two schematics are almost, but not quite, identical.  Unfortunately there's no way to know for certain which is which with the information we have at present.  Often in this case, we'd resort to looking at AC Electronics document ND-1021042, but it is also inconsistent, calling out schematic 2005973 in some places, but showing circuitry from 2005940 in others.  Nevertheless, there are quite a few circumstantial reasons to believe that 2005973 is the correct one ... not least of which that its signatures are dated later.  You can read all of my reasoning on that, in my usual boring detail, on any of the DSKY 2003994 drawing-tree pages.
• Back when I originally did the engineering-drawing drill-downs for the various AGC and DSKY models that are listed on the electro-mechanical page, there were a number of drill-downs I couldn't complete, due to missing drawings.  Well, there are still missing drawings, but in the meantime we've acquired lots and lot more scans than before, so it should be possible to fill in some of those gaps.  While it's still early in the process of filling in the gaps, here are some of the assemblies whose drill-downs have been addressed so far:
• AGC model 2003993-0xx oscillator module, B7.
  
• AGC model 2003993-0xx erasable driver module, B9-B10. 
  
• AGC model 2003993-0xx rope driver module B16-B17.
• DSKY model 2003950-011 keyboard module D8.
• DSKY model 2003985-051 keyboard module D8.
  
• DSKY model 2003950-061.
• All Block II AGC models, miscellaneous drawings.
  
• Added MIT/IL document E-1186 to the document library.  Chapter 4 will tell you everything you want to know, I would suppose, about TDRR's, and will help to explain the TDDR numbers that pepper the revision blocks in the Apollo engineering drawings.
  

• Added the CAD transcription for drawing 2005971 (power-supply module A30-A31 for Block II AGC 2003993).  See also the renderings of the CAD as image files. Unlike my normal practice, I took some liberties with this one, in that the latest revision of the original drawing 2005971 we have is "A", but it is missing its 2nd sheet (the bill of materials).  I therefore transcribed sheet 1 from the original 2005971A, but I transcribed sheet 2 from the original 2005971-, thus producing a hybrid revision that I call "2005971-A".  I've compared the resistor, capacitor, and inductor values between the two sheets to insure there are no obvious revision mismatches between the two sheets, but there's no way to detect incorrect part numbers for things like diodes and transistors.  Not that it matters too much, since you probably can't get those diodes or transistors any longer, but I still don't like it.
• Added the CAD transcription for drawing 2005940A (indicator driver module D1-D6 for Block II DSKY 2003994).  See also the renderings of the CAD as image files.

• Added the CAD transcription for drawing 2005928A (interface module A25-A26 for Block II AGC 2003993 and an alternative to drawing 2005021C for some AGC 2003200 dash numbers).  See also the renderings of the CAD as image files.
• Added the CAD transcription for drawing 2005929A (sense amplifier module for erasable memory, B14, for Block II AGC 2003993).  See also the renderings of the CAD as image files.
• More fixes to the master engineering-drawing index and search engine.
  

• Added the CAD transcription for drawing 2005932A (erasable-memory sense-amplifier module B13 for Block II AGC 2003993 and an alternative to drawing 2005920B for some AGC 2003200 dash numbers).  See also the renderings of the CAD as image files.
• Added the CAD transcription for drawing 2005926A (strand-select module B15 for Block II AGC 2003993 and and an alternative to drawing 2005924- for some AGC 2003200 dash numbers).  See also the renderings of the CAD as image files.

• Added the CAD transcription for drawing 2005927A (alarm module B8 for some Block II AGC 2003993 and 2003200 dash numbers).  See also the renderings of the CAD as image files.  I also found and fixed a number of boo-boos related to module B8 in the existing html files and drawing search-engine.
• Added the CAD transcription for drawing 2005925A (current-switch module B11 for Block II AGC 2003993 and and an alternative to drawing 2005005D for some AGC 2003200 dash numbers).  See also the renderings of the CAD as image files.
  

• Hartmuth Gutsche tells me that the Apollo online digital archive of the University of Alabama at Huntsville, having apparently been offline for a couple of years, has returned from whatever limbo it may have been in.  It contains around a thousand documents.  I've leafed through all of them and pulled down 40 or so for our own digital library page just in case the UAH site decides to disappear again.  You can find them in our library by looking for the icon.  As you might imagine, though, given that almost all of this stuff came from Marshall Space Flight Center, most of the UAH documents relate to the big rocket, and mostly have little direct relevance to what's going on here at Virtual AGC.  Most of the ones I pulled relate to Saturn IV-B stage (containing the Instrumentation Unit, containing the Launch Vehicle Digital Computer), or to the Apollo Telescope Mount (Skylab), or to press materials for Apollo 4 through 7. thanks, Hartmuth!
• Thymo van Beers sent me a list of various boo-boos in my own AGC developer documentation that need to be fixed, and after lazily sitting on that list for a while — a couple of months, it looks like — I've finally gotten around to incorporating his suggestions.  Thanks, Thymo!

• Updated the discussion of aperture cards in the FAQ.
• Added engineering-drawing index pages for aperture-card boxes 458 and 462, and updated the page for box 461 to include the previously-unscanned final half of the box.  The changes are completely preliminary, and probably error-ridden, since although I have all of the scanned drawings in hand, I haven't posted them online yet.  So the new/updated box indexes aren't actually of any use yet.
  

• Somewhat pepped up the engineering-drawing search page I added yesterday, so that the search results have much more intuitively obvious search titles and URLs.  Of course, as always on this site, I make no pretense that "more intuitively obvious" is the same as merely "intuitively obvious", and in fact as I recall being taught in school, I should probably be saying something like "less intuitively unobvious".  But you get the idea.
• Added the CAD transcription for drawing 2005268- (Block II AGC 2003200 module A18 electrical schematics).  See also the renderings of the CAD as image files.

• Added the CAD transcription for drawing 2005265- (Block II AGC 2003200 module A15 electrical schematics).  See also the renderings of the CAD as image files.  Revisions "-" and "A" (for AGC 2003993) differ only in the backplane signal for connector pin 317.
• Added the CAD transcription for drawing 2005267- (Block II AGC 2003200 module A17 electrical schematics).  See also the renderings of the CAD as image files.  Revisions "-" and "A" (for AGC 2003993) differ only in the backplane signal for the inputs and outputs of gate 44462 are no-connects on the former but not the latter.
  

• Added the CAD transcription for drawing 2005257- (Block II AGC 2003200 module A10 electrical schematics).  See also the renderings of the CAD as image files.  There's no electrical difference from 2005257A (for AGC 2003993).
• Added the CAD transcription for drawing 2005258- (Block II AGC 2003200 module A11 electrical schematics).  See also the renderings of the CAD as image files.  There's no electrical difference from 2005258A (for AGC 2003993).
• Added the CAD transcription for drawing 2005253- (Block II AGC 2003200 module A12 electrical schematics).  See also the renderings of the CAD as image files.  Differs from 2005253A (for AGC 2003993) only in the backplane signal used for connector pin 249.
• Added the CAD transcription for drawing 2005264- (Block II AGC 2003200 module A14 electrical schematics).  See also the renderings of the CAD as image files.  There's no electrical difference from 2005264A (for Verilog simulation) or 2005264B (for AGC 2003993).
  

• Added the CAD transcription for drawing 2005252- (Block II AGC 2003200 module A7 electrical schematics).  See also the renderings of the CAD as image files.  There's no electrical difference from 2005252A (for AGC 2003993).
• Added the CAD transcription for drawing 2005256- (Block II AGC 2003200 module A9 electrical schematics).  See also the renderings of the CAD as image files.  The difference between this rev "-" and rev "A" (for AGC 2003993) is that in the latter, several previously-disconnected gates are connected to backplane signals, with the net result that the backplane STRT2 signal is wire-NOR'd with the backplane signals CLROPE, ROPER, ROPES, and ROPET.  However, this is a change only on the backplane wiring and not within the module itself, so it is not an electrical change within the module.
  

• Added the CAD transcription for drawing 2005263- (Block II AGC 2003200 timer module A6 electrical schematics).  See also the renderings of the CAD as image files.
• Our GitHub repository now has a "mechanical" branch, into which I semi-confidently expect 3D models of AGC, DSKY, and perhaps other G&N system component fabricated parts (such as baseboards, faceplates, covers, and so on) to be placed ... hopefully starting in the relatively near future.  But it's just empty right now except for a README that covers my hopes and expectations in more detail.  There's also a place there for storing 2D CAD transcriptions of scans of the original Project Apollo mechanical drawings, but people have expressed so little interest in that (compared to interest in 3D models) that we'll probably be able to count them on the fingers of one toe.
  

• Added yet another clever trick (to supplement those added yesterday to the Box 459, Box 460, Box 461, and miscellaneous G&N engineering-drawing pages) for fooling our Internet Archive site into letting you download full-resolution imagery.
• Because of teething difficulties at the beginning of this process of scanning entire boxes of aperture cards, there are several instances in type 02 documents in which page 18 was misinterpreted as page 1, and thus the page 18 scan overwrote the page 1 scan; similarly, in which page 28 overwrote page 2 and page 38 overwrote page 3.  This has been fixed in the Box 459, Box 460, and Box 461 indices.  I hope.  There are also related cases in which multiple microfilms of the same drawing appear in the aperture-card boxes, but only once in our collection due to overwriting of files of the same name; this will be eliminated in future boxes (i.e., we'll have access to all of the scans, duplicate or not), but it doesn't seem worth it to try and fix the problem in boxes that have already been scanned.
  

• Fixed up the (currently partial) index for aperture-card Box 461 the full titles of the drawings.
• As some sort of asinine tribute to the sickening power of cut-and-paste for evil, I had apparently titled drawings 2005251 through 2005273 in Box 460 as "signal wiring diagrams", when they are really "logic flow diagrams".  That's fixed.
• On the various engineering-drawing index pages, which usually provide links to our Internet Archive site for the individual drawing scans, there are warnings that using the Internet Archive's "save image as" function will usually give you an inferior image quality.  However, I've found much better workarounds for that problem than when I originally wrote the warning, so I've modified those pages to give better advice about the workarounds.
  
• Added the CAD transcription for drawing 2005262- (Block II AGC 2003200 stage branch decoding module A4 electrical schematics).  See also the renderings of the CAD as image files.
• Added the CAD transcription for drawing 2005261- (Block II AGC 2003200 cross point generator no. I module A5 electrical schematics).  See also the renderings of the CAD as image files.

• I've removed the "experimental page" warning at the top of the pages for Box 459 and Box 460 MIT/IL engineering drawings, since as far as I can tell (without literally checking all 3600 index entries) the indices are fine.  It's definitely worth noting, though, that the indices were generated from the punches on the aperture cards holding the microfilms of the drawings, and that not only is the metadata punched there not 100% perfect or consistent, but more importantly, the scanner manufacturer's software that reads the punches during the scan is subject to all kinds of problems ... specifically, systematic substitution of some characters for other characters.  Thus my index-generation software has to undo a lot of errors introduced by the scanning software, and that's impossible to do 100% perfectly.  So I just hope it's good enough!  So far, I think it is.  Ask me again if I think so 10 boxes or 100 boxes from now.
• I've added a page for the scans from Box 461, although the box is presently incomplete due to issues with the scanner, which I hope will be resolved fairly quickly, but am unsure enough of that to post the partial contents that have already been scanned ... about half the box.  Or to put it more bluntly, the scanner is broken and needs to be repaired.  Box 461 gets into a lot of G&N components we've ignored previously (IMU, SCT, PIPA, CDU) but it's only a taste of what's to come.
  
• Added the CAD transcription for drawing 2005260- (Block II AGC 2003200 timer module A2 electrical schematics).  See also the renderings of the CAD as image files.
• Added the CAD transcription for drawing 2005251- (Block II AGC 2003200 SQ register and decoding module A3 electrical schematics).  See also the renderings of the CAD as image files.

• ...
• Index page for box #459 (~1800 drawings)
  
• Index page for box #460 (~1800 drawings)
  
• ...
• Miscellaneous index page (~5000 drawings)

Since each aperture-card box corresponds to a specific, known drawing-number range, hopefully this will still be a relatively easy system to navigate.

I know that most people would handle this by setting up a database, so as to be able to find everything by browsing or searching the database rather than having hard-coded HTML tables of link data, but I'm philosophically committed to having a standalone website that doesn't need any software on the backend server, and hence could be (for example) downloaded to anybody's local system.  Unfortunately, since (due to storage requirements) almost all of the engineering-drawing scans have been put onto our Internet Archive site rather than this main Virtual AGC site anyway, that principle is already invalidated.  But still, my philosophy, website-wise, is "the dumber the better" in terms of its software requirements.  And I'm sure that's obvious to anyone looking at this site who's au fait on such stuff.

• Added the CAD transcription for drawing 2005009A (Block II AGC 2003100 strand-select module B15 electrical schematics).  See also the renderings of the CAD as image files.  This is a closely related drawing to 2005924- (for Block II AGC 2003200), so I corrected various bugs in the existing 2005924- transcription at the same time.
• Added the CAD transcription for drawing 2005006- (Block II AGC 2003100 erasable memory module electrical schematics).  See also the renderings of the CAD as image files.  This is a closely related drawing to 2005106- (for Block II AGC 2003200), so I corrected various bugs in the existing 2005106- transcription at the same time.

Incidentally, unless I'm confused somehow, I think these are the last CAD transcriptions of electrical schematics for the early Block II AGC model 2003100.

• Added the CAD transcription for drawing 2005914- (Block II AGC 2003100 erasable-memory sense-amplifier modules B13-B14 electrical schematics).  See also the renderings of the CAD as image files.  This is a closely related drawing to 2005920B (for Block II AGC 2003200), so I corrected various bugs in the existing 2005920B transcription at the same time.
• Added the CAD transcription for drawing 2005010F (Block II AGC 2003100 power-supply modules A30-A31 electrical schematics).  See also the renderings of the CAD as image files.  This is a closely related drawing to 2005916A (for Block II AGC 2003200), so I made some corrections to 2005916A at the same time.  I also noted that several of the web-pages for Block II AGC model 2003993 mistakenly called out drawing 2005010 due to ambiguities in the original drawings, and so fixed those pages to call out what I think is the correct drawing (2005971) instead.
  

CAD transcriptions of the electrical schematics for the Block I DSKY relay modules D7-D14 have been added:

• Early model NAV & MAIN DSKY:  CAD for drawing 1006161C (plus rendering as image file)
• Late model NAV & MAIN DSKY:  CAD for drawing 1005780- (plus rendering as image file)

CAD transcriptions of the electrical schematics for the Block I DSKY power-supply module have been added:

• Early model NAV & MAIN DSKY:  CAD for drawing 1006163G (plus rendering as image file)
• Late model NAV & MAIN DSKY:  CAD for drawing 1005756- (plus rendering as image file)

Because the availability of the original drawings for the Block I DSKYs isn't 100% complete at present, I can't state with 100% certainty that these CAD transcriptions cover all models.  But as far as I can tell with from the available drawings, they do.

• The electrical schematics for Block I NAV DSKY (early models 1003458 & 1003524 only) drawing 1006160E, keyboard module D17, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.  
• The electrical schematics for Block I MAIN DSKY (early models 1003459 & 1003540) drawing 1006150D, keyboard module D18, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.  

• The electrical schematics for Block I AGC drawing 1006119D, rope sense amplifier module B26 & B27, have been transcribed to CAD.  See also:  the renderings of the CAD as image files. 
• The electrical schematics for Block I AGC drawing 1005700A, filter module B5, have been transcribed to CAD.  See also:  the renderings of the CAD as image files. This power-supply module appeared in later Block I AGC models, but seemingly not in the early models.

Unless I've slipped up somewhere, which is entirely possible, this completes the CAD transcriptions for all electrical schematics for all supported Block I AGC models.  (Not DSKYs ... I haven't started on those yet.)  Since it's easy to read this statement as meaning that all Block I AGC schematics have been converted to CAD, which isn't true, let me parse it out a little more fully. We "support" only the 8 different Block I AGC models listed on the electro-mechanical page.  For two of those models (1003469-011 & 1003700-011) we don't even have the specific original electrical schematics for module A23 (namely drawing 1006125), while for two other models (1003700-051 & -071) we don't have the electrical schematics for module A29 (drawing 1005763), so naturally there are no CAD transcriptions for those particular modules in those particular AGC models.  Nevertheless, that's a lot of drawings transcribed to CAD, and remarkably good coverage of the Block I AGC electrical design!  I'm sure there are still plenty of boo-boos, such as slightly inconsistent signal names from one module to the next, that will need to be worked out over time.

• Added (to NARA finding aids on the Quest for Info page) a document that purports to list all documents processed by the JSC technical library up to 1988.
• Added a handful of new AGC/DSKY engineering-drawing scans which Mike Stewart and Craig Keithley contributed.  Alas, there's really no good way to point out which ones these are, so I'd just suggest doing a numerical or textual search to see if anything you're looking for is there.
  

• The electrical schematics for Block I AGC drawing 1006097F, power-switch module B2, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.
• All of the CAD drawings so far transcribed for the Block I and Block II AGC that have depended on reusable circuit blocks have been "reannotated".  The modules in question are basically all of the analog "B" modules (as opposed to the digital "A" modules).  What this nonsense statement means is that the reference designators have been corrected to hopefully agree with those physically marked on the original modules, as opposed to using many reference designators arbitrarily assigned by the KiCad program.  If that still sounds completely opaque ... well, it's something that's only really meaningful to someone working with actual AGC B-modules, and not useful to someone who simply wants to casually look through the schematics (which I expect is 99% of anybody interested in these CAD transcriptions of the original schematics at all), so I won't clutter up this space with further explanation.  Suffice it to say that it's a fix for an inconsistency with respect to the original design that has been bugging me for months and months, so I'm glad that it has finally been taken care of.
  

• In the very first Block I AGC schematic drawing I transcribed to CAD I had stupidly misread a connector-pin number, and since that very same block of circuitry appeared identically in the subsequent 17 Block I AGC schematics I've transcribed, I had ended up propagating the error into 18 CAD drawings.  Yay, me!  At any rate, that's now fixed, and shouldn't have had any effect on anybody anyway, since it was an "AGC 4" pin number rather than an "AGC 5" pin number.  Still ....
• The electrical schematics for Block I AGC module A37, namely drawing 1006550F, have been transcribed to CAD.  See also:  the renderings of the CAD as image files. This was actually quite a monster of a task, because the "signal wiring diagram" associated with it (drawing 1006130-), which is needed for determining reference designators and input-pin assignments for the NOR gates, was essentially illegible regardless of how I attempted to post-process it.  Check it out if you think I'm exaggerating the horrific quality of this drawing!  Of course, I could have just ignored the wiring diagram completely and arbitrarily assigned these values without affecting the electrical functionality in any way, as I've already done for a couple of schematics in which the wiring diagrams were missing completely.  But for some reason I got the idea in my head that I could extract the NOR-gate reference designators and input-pin assignments from the wiring diagram in spite of the fact that the drawing itself was illegible.  And indeed, it turned to be almost possible to do that perfectly.  In the end, it turned out that only two gates which were wired in parallel couldn't be distinguished from each other, so that for them I had two reference designators and two gates and didn't know which went with which.  Hardly the worst problem one could have!  In other words, overall the reverse-engineering of the wiring diagram worked out quite well.  Pointless, I know, since it would seem so totally unnecessary to anyone not obsessed with authenticity, but weirdly satisfying in a digital-archaeology sense. 
  

• The electrical schematics for Block I AGC module A35, namely drawing 1006541B, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.
• The electrical schematics for Block I AGC module A36, namely drawing 1006557D, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.

• Don Eyles has pointed out that I have been a bit too aggressive in my acknowledgements of the original AGC developers, to the point where I was acknowledging some folks that weren't even AGC software developers at all.  (Specifically, people who worked on the "all-digital simulation", which was an important task and a great contribution, but not AGC software development.)  So I've removed some names that used to be in the acknowledgements.  If you're one of the people affected, my apologies!  If I had some way to cover the all-digital simulation (and you) here on this site, I would, but my information about it and my resources are not unlimited.  Particularly the former.
• The electrical schematics for Block I AGC module A32, namely drawing 1006546A, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.

• A couple of files whose names differed only in their case ("device.lib" and "Device.lib") had crept into the "schematics" branch of our git repository, where they would sabotage attempts to checkout the schematics in case-insensitive files-systems (like for Windows or Mac OS X); I never noticed it, since I use Linux, whose file-systems aren't crippled in that way.   But kidding (or is it?) aside, the reason I'm mentioning this relatively unimportant fix is that it involved elimination of a folder of KiCad symbol-library files, msSchematics/libs/, in which there's a remote chance someone could be interested in the future.  If so, just consult the original issue report to see how to find the folder in the repository history.
  
• The electrical schematics for Block I AGC module A24, namely drawing 1006555A, have been transcribed to CAD.  See also:  the renderings of the CAD as image files.
  

• The electrical schematics for Block I AGC module A17, namely drawing 1006543D, have been transcribed to CAD, and cross-checked/corrected against the CAD schematics previously recovered from document ND-1021041 before the original drawing became available.  The usual PNG renderings of the CAD files for both versions are available.  While the two implementations differ slightly, I believe that that's just due to errors in ND-1021041, but you can read the writeup about the discrepancies here if you like.
• It turns out that the master MIT/IL engineering-drawing index page had immensely more garbage in it than I imagined yesterday.  It's still big, but it's now a fraction of the size it was yesterday, as well as eliminating loading of an external stylesheet I hadn't known about, so it hopefully will be a tad more responsive than before.  Plus, its table borders had disappeared when viewed in Chrome for some reason, and I've brought them back.
• The electrical schematics for Block I AGC module A17, namely drawing 1006543D, have been transcribed to CAD, and cross-checked/corrected against the CAD schematics previously recovered from document ND-1021041 before the original drawing became available.  The usual PNG renderings of the CAD files for both versions are available.  The two implementations differ, primarily in that there are 7 NOR-gates which are wired up differently, resulting in 7 changes of polarity in the backplane signals.  Therefore, I think there is probably a later revision of the schematic that we don't have.  You can read the full writeup of the discrepancies here if you like.

• The electrical schematics for Block I AGC module A26, namely drawing 1006549B, have been transcribed to CAD, and cross-checked/corrected against the CAD schematics previously recovered from document ND-1021041 before the original drawing became available.  The usual PNG renderings of the CAD files for both versions are available.  The two implementations are electrically identical.
• Because of the WYSIWYG HTML editor I normally use on this website, the HTML becomes littered with junk like big blocks of useless crud and thus has to be cleaned up from time to time to keep this junk from proliferating too much.  Which I've just done.  The improvements in some file-sizes (particularly this change log page and the MIT/IL drawing-index page) are semi-dramatic.  Unfortunately, the automated cleaner did mess up a couple of my tables ... all of which I hopefully found and fixed, though I guess it may take a while to be sure.
  

• The electrical schematics for Block I AGC module A28, namely drawing 1006552A, have been transcribed to CAD, and cross-checked/corrected against the CAD schematics previously recovered from document ND-1021041 before the original drawing became available.  The usual PNG renderings of the CAD files for both versions are available.  My assessment is that the two versions are essentially the same, though that is open to interpretation.  There's a full analysis of the differences as well.
• The way hyperlinks into our Internet Archive site on the electro-mechanical page have been treated has increasingly bugged me, so I've changed the treatment to correspond to how the engineering drawing index page and the individual pages for AGC/DSKY models treat them.  Alas, it turned out to be really complex, because of some inconsistencies in the way those hyperlinks are supposed to be formatted.  I think I've got them all right, but it's possible there might be some broken links on the electro-mechanical page that it will be discovered and fixed over the course of time.
• Information has been added to the CAD-file section of the electro-mechanical page about the expectations for 2D or 3D transcription of AGC/DSKY mechanical drawings into CAD form.
  

• The electrical schematics for Block I AGC module A21, namely drawing 1006556A, have been transcribed to CAD, and cross-checked/corrected against the CAD schematics previously recovered from document ND-1021041 before the original drawing became available.  The usual PNG renderings of the CAD files for both versions are available.  The remaining differences after this reconciliation process lead me to believe that ND-1021041 may have been based on 1006556C ... i.e., a couple of revisions higher than our latest revision of the schematic drawing.  The match is quite close, though, with just 3 gates (and associated connector pins) differing.  There's a full analysis of the differences as well.
• It also turns out, now that I've worked through a 2nd drawing, that the Block I signal-wiring diagrams are don't unambiguously provide the wiring of the logic from the schematic in all cases, so I've added the necessary verbiage about that issue to the explanation of Block I signal-wiring diagrams on the electro-mechanical page.
  

• A flat view of the drawing set, ordered by drawing number and revision.
• A hierarchical view of the drawing set, ordered by G&N (Guidance & Navigation) system type ... or if you prefer to think of it that way, by Apollo mission number, or by AGC or DSKY part number.  In this hierarchical view, you navigate through the drawings on an assembly-by-assembly basis for whatever G&N system, mission number, or AGC/DSKY part number you feel like.

All other supplemental information provided by the electro-mechanical page is now subordinated to this basic drawing-browsing activity.

Some information that I deemed uninteresting and distracting was (gasp!) even removed from the page entirely, and not provided separately.  I don't know that I've ever done anything like that before.  It was only the table of serial numbers for AGCs and DSKYs that was removed, though, and I felt the information was buggy and too difficult to correct, so I don't actually think losing it is much of a loss at all.  If anyone disagrees and thinks it was valuable in some way, drop me a line.

Now that the drawings are arranged in this fashion, I'll have to somewhat modify my prior claims that we now have all of the DSKY and AGC schematics.  There are so many engineering drawings needed for any given model of AGC or DSKY that there's no single AGC or DSKY model for which we have anything like a full set of drawings.  Naturally, I'd like to have a complete set, not just for some AGC/DSKY model, but for all of them.

On the other hand, all of the models are generally so similar — after all, all of the AGCs in either of the two "blocks" can run the same software as any of the others, mostly, so how different could they really be? — that there's a lot of mixing and matching among different unit types that you can do.  In that sense, we have most of the drawings in so many different versions, you can almost always find something that will work for you if you don't have the specific drawing you want, either electrically or mechanically.  In that sense, you could say we not only have have all of the drawings, but have them many times over.

What?  You think that sounds specious?  It's a glass-half-full glass-half-empty thing here, people, work with me to overlook the problems! 

At any rate, over the course of 2019 I'll be working to fill in the gaps in the AGC/DSKY drawing-set as much as possible.  There's also the possibility of extending it to other G&N components such as the CDU, since NARA has drawings for basically all of the G&N components.  And I'll also return to transcribing the Block I schematics into CAD, which is what I was doing before I started spending every day over at NARA.  It will be a lot easier now that I actually have real Block I drawings instead of having to "recover" schematics from the bits and pieces in AC Electronics document ND-1021041.  It will be interesting to compare the real schematics (once they're in CAD) to the "recovered" ones I made before we discovered that the real drawings still exist.

Finally, as usual, I'll note that since the changes to the electro-mechanical page are so sweeping, it's unavoidable that there are bugs in it, particularly in the new drawing trees.  Hopefully we'll be able to clean those up in a timely fashion.

• The MIT/IL engineering-drawing index page has been updated to include all of the engineering drawings I scanned this week at NARA.  There are over 4400 scans in all now.
• Various documents related to midcourse-correction processor for NASA's RTCC (Real Time Computer Complex) have been added to the Apollo 11, 13, 14, 15, and 16 items in the document library's "miscellaneous mission documents" section.  The full-quality scans are over at our Internet Archive site as well, though I'm going to stop providing explicit double-links (local low-quality plus Internet Archive high-quality).  If you wonder whether a higher-quality version is available for some document or the other, just head over there and look.  But as far as these particular documents are concerned, I'm told they're particularly valuable (for something relating to the RTCC rather than the AGC ) because they organize together in one place information that previously difficult to access because it was spread out over a number of hard-to-get memos.  Check them out.  From my perspective, the document on abort-plans for Apollo 11 seems particularly interesting.
  

• The section about my previous finding aids for NARA has been updated with the possibly-important info that in 2010, NARA put all the documents I carefully indexed in 2004 into new boxes, with different numbers written on them.  Yay!
• In 2004, I had scanned all of the title pages of documents in boxes I thought might be of future interest, but that there was no time back then to deal with.  For some insane reason I left these scans as TIFFs which, at least in my browser, you can't directly view.  Similarly, a finding aid from NARA itself was left in a Microsoft Word format that's not useful in a web browser.  At any rate, I've now converted these to PNGs and PDF, respectively, making them far more convenient for web purposes.
• I've added a new section with finding aids and hopefully-helpful info about my present efforts at NARA to extract drawings from "aperture cards".

I've also updated our document library page with a couple of document I scanned from NARA's aperture cards.  There's actually an entirely new section on our document library page with just these two document, also I expect it to grow somewhat over the remainder of the year.

Finally, the indices for all drawings scanned this week (batches 3 through 7) have been added to our MIT/IL Engineering Drawing Index page.

• Added a TRW document about Apollo 8 flight-program verification to the mission-documents section of our document-library page.
• A huge batch of electrical and mechanical drawings has been added to our electro-mechanical pages, filling in lots of gaps in our electrical knowledge of the Block I AGC&DSKY and our mechanical knowledge of the Block II AGC&DSKY.  This is an ongoing process that is by no means complete.  Nor have I integrated the drawings into the various AGC/DSKY electrical sections of the electro-mechanical page yet.  Nevertheless, there's an index allowing you to access all the new drawings from our Internet Archive site.
  

• The revision code for the Block I AGC program Corona, flown on AS-202, previously unknown, is now known.  It was rev 261.  The Corona entry on the Colossus page has been updated accordingly.
• We now have the AC Electronics manual for Apollo 11.  (Thanks, James Berry!)  Previously, we had only the Apollo 15 and 16 versions, so it's great to add Apollo 11 into that mix with its 50th anniversary looming.  The archival-quality page scans are on our Internet Archive site, while the lower-quality PDF with searchable text is here locally in our document library.  The book — which, never having seen one in person I was surprised to find really is a "book" rather than a jumble of papers loosely bound together, printed specifically as what's typically called a "trade paper edition" book — was purchased in a used-book store many years ago for $5, after apparently having been sold by the MSC employee who originally owned it.  Which just goes to show that used-book stores are great places.  But I already knew that.

• There's a completely new Appendix, in which all of the new Block I drawings are indexed.
• Scans of the relevant drawings have been added to each of following sections, to flesh out the ND-1021041 figure links that were already there:
• Block I AGC 1003700
• Block I main DSKY 1003707
• Block I nav DSKY 1003706
  

• Steven Hauer was kind enough to send in updated descriptions and additional photos of his project to implement a physical AGC and DSKY using Mike Stewart's groundwork in capturing Block II schematics from the drawings Eldon Hall contributed plus document ND-1021042.  Naturally, I've updated our physical-implementations page accordingly.  Looks as though it's running pretty well now, though it's still a work in progress!
  
• All of the Block I schematics transcribed from ND-1021041 so far have been tweaked, particularly insofar as their power-supply filtering circuits were concerned.  (Somehow I had failed to put in the values of the filtering capacitors.  Yikes!)
• Drawing 1006543 has been recovered from ND-1021041.  It is the Block I "logic flow C" module A17, and is a pot pourri of various stuff, with the largest contribution being parity logic.  Links for the various CAD and PNG files are here.  There were lots of pin-numbering errors in ND-1021041, so I had to arbitrarily reassign various signals to otherwise-unused pins.  That's a normal experience with these drawings, but there were quite a few more errors than usual, given the relative simplicity of this module's schematics.  I hope the number of wiring errors doesn't turn out to be comparable!
• Drawing 1006542 has been recovered as well.  It is the Block I "logic flow B" module, A18.  Here are the CAD and PNG links.  Frankly, in spite of having spent the day with it, I'm not entirely clear exactly what the stuff in it is for yet, so I can't give you a concise buzzword for the module's functionality.
  

• Added transcriptions of drawing 2005919A (sense amplifier module B14, for AGC 2003200).  This module seems to be structurally identical to yesterday's drawing 2005920B (module B13), but with the backplane connector pins carrying different signals, so I'm not sure why it's a separate drawing.  For AGC 2003100, it was actually one single drawing (and module p/n).  Possibly there's some difference I've overlooked.  Moreover, this called my attention to several errors I had made in the transcription of 2005920B, so I'm a bit uneasy that a few more bugs are lurking in both ....  At any rate, the KiCad schematics are here.  Likewise, there are separate PNG renderings for visual fidelity (sheets 1 and 2) vs electrical properties (top-level sheet and its sub-circuit).
• Hoping to combat the complexity of this website (at least a little!) added a brief cheat-sheet of hyperlinks to the top of the main page. I know, I know!  I invariably combat complexity by adding more complexity.
  

• Added some fun anecdotal info to the description of the TRIVIUM program now residing on our Colossus page.
  
• Fixed a wiring bug reported by a correspondent, in the CAD transcription and PNGs of drawing 2005916A.
• Added transcription of drawing 2005005D (current switch module B11, for AGC p/n 2003100 and 2003200) into CAD.  The KiCad schematics are here, and PNG renderings (sheets 1 & 2) are also available.
• Added transcription(s) of drawing 2005920B (sense amplifier module B13, for AGC 2003200).  The KiCad schematics are here.  Like yesterday's drawing 2005104B, it's not possible to make a CAD transcription of 2005920B that's both electrically correct and visually accurate with respect to the original.  Therefore, separate transcriptions have been made for visual fidelity (PNGs for sheets 1 and 2) vs electrical properties (PNGs for top-level sheet and its sub-circuit).
  

• I've put in a considerable effort creating a software tool that can statically compare Mike Stewart's preexisting KiCad/Verilog implementation of the AGC electronics with the identical-in-spirit but very-different-in-detail KiCad/Verilog implementation I've been creating.  The two implementations were effectively identical in behavior in terms of running the AGC validation-suite software before I started statically comparing the models, and I'm pleased to say that even though the static comparison found a half-dozen or so wiring errors in each of the two implementations, their behavior is still effectively identical now that those errors are fixed.  Admittedly, not all of the fixes to Mike's simulation have been pushed upstream yet, but hopefully we'll be able to manage that at some point.   I'm not pretending that either implementation is perfect yet, and I haven't completed my checkout of them, but I think this is a significant milestone in the journey towards that goal.
  
• Due to the schematic wiring-error fixes just mentioned, as well as to recent improvements in KiCad's ability to render our schematics, all of the PNG images for the schematics I've been creating have now been re-rendered on the website (though they're uploading as I write this, and it may be a while before they manage to finish doing so).  They look a lot prettier, particularly when viewed on smaller screens or printed on smaller paper.  Even the E-sized drawings are legible when printed on U.S. letter-sized paper, assuming you're wearing powerful enough reading glasses, though for my old eyes, tabloid-sized paper (11"×17") is considerably more comfortable to read. 
• Some descriptive material on the electro-mechanical page and hardware-simulation page has been updated.  They're both very much still works-in-progress, particularly the latter page.
  

• One of the documents from Russ Larson's papers, namely the YUL documentation mentioned last time, actually has a very short Block I AGC sample program called TRIVIUM (by "IMA NIT-PICKER") attached to the end of it.  Considering that this is only the 2nd Block I AGC program we've ever seen, after Solarium, that's reasonably exciting.  At any rate, TRIVIUM has therefore been transcribed to source code, and added to our repertoire of AGC programs.  Because its purpose was to demonstrate the usage of YUL, TRIVIUM contained some deliberate errors that actually made its assembly by YUL (or yaYUL) fail, so I've also created a version called "TRIVIUM-repaired" that has those errors fixed, and added that program on github as well.
• We've gotten in a heap of SCDs, or "specification control drawings", for the various electronic and mechanical components used in the AGC and DSKY designs.  For our purpose, these basically serve the purpose of manufacturers' datasheets for the components, and we have them for all but a handful of the parts used in the electrical/mechanical design.
• The Verilog-based simulation of the AGC electrical design that I've been mentioning in the last few updates has reached the point of being able to run (and pass) the AGC's suite of Validation software that we use to help insure the accuracy of yaAGC.  That's not to say that it's perfect, since there are still known discrepancies between the simulation's behavior at a very-detailed level and Mike Stewart's earlier, independently-created simulation.  I'm tracking down those errors and fixing them over time.  Also, the even fancier Borealis software test suite hasn't yet been tried, since there are various technical problems with doing so that will need to be overcome first.
• Another AGC schematic has been transcribed, this time for AGC module A52, drawing 2003305B, the "restart monitor", and thus added to the Electro-Mechanical page.
  

• If you've been following my progress, first in transcribing the AGC schematics into CAD, and then in translating those CAD files into Verilog, and finally in running a Verilog-based simulation of the AGC — and admittedly, I don't think that's too many of you  — I've been making good progress, and you can now actually fire up the full-AGC simulation with it.  There's no erasable or fixed memory implemented yet, so all the simulation does is basically to jump to the start vector (address 4000 octal) ... at which point the "instructions" it starts fetching from the non-existent rope are nonsense.  But still, just getting to this point is a pretty significant milestone.  Of course, all I'm doing is lagging by a couple of years what Mike Stewart already has already had working, albeit developed with somewhat different design criteria in mind, and therefore quite different in terms of details of the implementation.
• And speaking of Mike, you may recall that we've been getting a vast trove of documentation and software from Don Eyles the last couple of years, but that periodically we've mistakenly mentioned that Don's stash had finally been exhausted.  What Don had forgotten to mention to us, though, is that Russ Larson's and George Silver's widows had turned over 6-7 boxes each of their papers, and that Don was mostly unfamiliar with the contents of those boxes.  Mike immediately hopped on a plane and spent what I suspect was a subjectively very long long-weekend indexing those boxes, and then scanning a few items that seemed most-immediately pressing.  The boxes contained nearly 800 items in total.  As a result of Mike's lost weekend, there are 98 new items in the document library today, with (presumably) a lot more of the remaining ~700 items to come in the future as we work out the pragmatic details of how to accomplish that.  Many thanks to all concerned!  Here's an executive summary of the some of the more-significant items we've got so far, from my point of view. I think that overall it would be fair to say that there's an emphasis on AGC hardware vs software in them:
• 4-5 issues of the "AGC Information Series"
• 37 "digital development memos"
  
• 15 erasable padloads (Skylab 2 and Apollo 11-17 CM & LM)
• Documentation of the original YUL assembler
• "Contents of Luminary 1E":  A collection of all the anomaly reports, PCRs, and PCNs related to moving from LUMINARY 1D (Apollo 14) to 1E (Apollo 15-17).
  
• AC Electronics's review of the Block II AGC electrical design.
• A "comprehensive listing of all G&N system interface signals, impedances, noise, and marginal operational requirements".
• Updated the discussion about TRW's John Norton on the FAQ page.
  

• Pepped up the acknowledgements section quite a bit, on the basis of new documents I've gotten, to show more AGC developers and better-defined responsibilities with respect to the sections of the code they were responsible for.  It still very incomplete and unsatisfactory in spite of that.
• I'm pleased to note that in the software repository we now have at least a primitive version of a KiCad-to-Verilog translator script (in Python) that works for several of our transcriptions of AGC modules. Indeed, hardware simulation of AGC module A1 (drawing 2005259A) actually works and behaves identically with what ND-1021042 says it should.  So as far as I can tell right now, that means that the CAD for module A1 is 100% correct.  But I want to write that up in detail at some point, with pictures, and haven't done so yet.  Plus, it still leaves us a pretty long way from running a full simulation of the complete AGC logic.  You can't sneeze at progress, though!
• Added a heap of documents Don Eyles sent in, mostly memos.  I believe there were 89 in all, so on the document-library page I got rid of all the pre-existing icons to help them stand out.  The vast bulk of them are in the LUMINARY Memos section, with the remainder, I believe, being in the SCB Meeting Notes section and the Miscellaneous Mission Documents section.  There's some pretty interesting stuff in there.
  

• The scans of volume 2 of document ND-1021041 (AC Electronics Block I manual) have undergone the cleanups mentioned a few days back, so that document is in its final form now.
• The CAD transcriptions for AGC modules A19-A24 are now available on the electro-mechanical page (meaning that A1-A29 are now all available), for AGC p/n 2003200.  They've also undergone cross-checking and comparison against Mike Stewart's pin database for the AGC backplane (into which the modules plug), which is in turn based partially on Mike's earlier, independent transcription into CAD and subsequent hardware simulation, so I think we can start to have a little confidence in these new CAD transcriptions.  (The reason for these new transcriptions is that Mike's earlier ones weren't intended to duplicate the visual appearance of the original schematics, nor to reflect versioning differences, but merely to relect the final version of the hardware as accurately as possible.)  Roadmap-wise, this should be the minimal set of drawings needed for hardware simulation of the AGC logic (as opposed to its analog characteristics), so that is something I'm going to start thinking about seriously now, as well as transcription of all of the drawing versions that haven't been transcribed yet, extending to the later model 2003993, and the earlier model 2003100.
• The electro-mechanical page has been very slightly reworked, reorganized, and cut down, so as to make it friendlier to newcomers.  Not much, I admit, but every bit helps.  A little.  Maybe.
  

• Added a handful of new docs to the document library, mostly for the Apollo-Soyuz Test Project (ASTP), of which the gems seem to be the SKYLARK 48 erasable loads and the users' guide.  Now if only we had a copy of the SKYLARK program listing, then we'd really have something!
• Both volumes of AC Electronics manual ND-1021041 for Block I are now available, including essentially-complete Block I AGC/DSKY electrical schematics.  Reduced-size scans (vol 1 and vol 2) are available, as well as the full-resolution scans (vol 1 and vol 2).  I am told, though, that additional work is may be done on both volumes at archive.org, so this document may change somewhat over the course of the next week or two.  At any rate, thanks, Ken Mortimer!
  
• Cleaned up the master list of links to AGC/DSKY electro-mechanical drawings.  Specifically, I simplified how the links to figures in ND-1021042 are presented, and completed adding all of the links into ND-1021042 (in both versions of the document that we have).  I've not yet started adding Block I links from figures in ND-1021041 into the table.
• And here's a cool article about the AGC and people working on preservation of them.  Quite a fun read, not just with AGCs, but with references to people (and sometimes pictures of them) familiar to people who frequent this website.  Assuming there are any, of course.
  

• Added an electrical CAD transcription for yet another revision of AGC module A14, this time for drawing 2005264- (to complete the set started with drawings 2005264A and 2005264B yesterday).  This revision has no particular significance that I know of, but I was playing around with some bug/feature fixes recently made to KiCad, and it was simply a convenient drawing to work with.
• Added the CAD transcription of the electrical schematics for the flight version of AGC module A15 (drawing 2005265A).
  

• Added the CAD transcriptions for the AGC electrical schematics for the flight version of the A4 logic module.
• Updated the AGC Handbook index to include the drawings supplied by Eldon Hall, so that it's more of a master index now.  I hadn't compared Eldon's drawings vs the AGC Handbook side-by-side before, and was surprised to see that in Eldon's set there were only 2 drawings (plus one rev of a drawing) that weren't also in the AGC Handbook.  Of course, there's a very definite difference in legibility in places, so having both sets of drawings is still a pretty nice feature.
  

• Realized how a visual-mismatch between the original scanned AGC/DSKY electrical schematics and the CAD transcriptions of them could be corrected, and did so on all of the drawings that have already been transcribed.
• Added an Appendix to the electro-mechanical page to cover various issues we've discovered in using KiCad with the AGC/DSKY schematics.  Also, reorganized the electro-mechanical page to be very slightly less confusing.
  

• Mike has sent an update to the full (though still very incomplete) MIT part-number list.  Concurrently, I've decided to change the presentation of that list to a table directly on the electro-mechanical page itself rather than as a link to a separate Excel spreadsheet as it was before.  In fact, the master part-number list is now maintained in our github repo, for maintenance purposes, and therefore can theoretically be corrected or extended by someone other than Mike.
• Hartmuth has sent along a ton more Apollo and Gemini files that he had scavenged from NTRS over the years and that we hadn't already noticed ourselves.  About 130 of them by my count.  So they've been added to the document library.  This caused me to notice a few links to existing docs that were messed up, and so I've fixed those; on the other hand, having added so many new docs at once, I've undoubtedly messed up quite a few of their links, and will have to find and fix those in the near future.
  

• It turns out that in all of the drawings so-far converted from the AGC Handbook to CAD (namely, drawings 2005902B, 2005903A, 2005952-, and 2005973r), I had misinterpreted what were supposed to be connector pins as global nets.  Those have all now been fixed.  These schematics now all pass KiCad's ERC (Electrical Rule Checker), with the happy side effect that a few connections which didn't quite "connect" before, due to wire endpoints being physically very close visually but not actually touching, have been fixed as well.  None of this makes a significant visual difference in the images created from the CAD files — mainly, little rectangular boxes with numbers in them have been replaced by little ovals with the same numbers in them — but it's a world of difference electrically and in terms of confidence in the transcription.
• All of the available drawings from the AGC Handbook for the DSKY module D7 power-supply circuit have also now been transcribed to KiCad, and thus have "pretty" drawings associated with them on the electro-mechanical page.  They actually turn out to all be identical, except that they have different choices of some resistor and capacitor values.
• Drawing 2005921- (for DSKY p/n 2003950).
  
• Drawing 2005904C (for the earlier DSKY p/n 2003985).
• Drawing 2005904B (a still earlier revision).
• And finally, a reconstructed drawing 2005937 (for the later DSKY p/n 2003994), using drawing 2005921- and the circuitry found in AC Electronics document ND-1021042 as a guide.  The need for a reconstruction is, of course, that we don't have an actual copy of drawing 2005937 in either the AGC Handbook or elsewhere.
  

• Made some relatively minor, almost cosmetic changes to a couple of the CAD schematics added yesterday.  But there were pretty important changes to the reconstructed schematic 2005973, since Mike Stewart pointed out that circuit simulations proved that document ND-1021042 was wrong and drawing 2005952 was correct with respect to certain circuit characteristics, and thus I was wrong to trust ND-1021042.
  
• Mike had also put together a nice spreadsheet of many (though not all) part numbers for a large number of resistors, capacitors, and so on used in the electrical schematics.  That spreadsheet has been added to the electro-mechanical page.
  

• Converted Hartmuth's index into the AGC Handbook pages into an Appendix for our electro-mechanical page, so that it provides actual links to the individual high-quality scans at our Internet Archive site.  Of course, Hartmuth's original index (for the lower-size PDF form of the handbook) is still available.
• Experimentally (so far), a handful of the electrical-schematic drawings have been transcribed to CAD files using the open-source KiCad system.  These appear in the "schematics" branch of the GitHub repo, and have been added to the electro-mechanical page of the website as well.  The drawings transcribed so far are of all the available versions of the DSKY indicator-driver circuit: 2 versions from the AGC Handbook, plus 1 "reconstructed" but otherwise-missing version that was recreated by combining information from the AGC Handbook and AC Electronics document ND-1021042.  The transcribed drawings are obviously a lot nicer than the 50-year-old xeroxes of the originals, but also potentially contain so-far undetected errors not present in the originals.  You pays your money and you takes your chances!
  

• The electro-mechanical page has undergone various corrections, and now has its first Block II DSKY schematics.
  
• Added AC/Delco Electronics, "Apollo Command Module Block II Primary Guidance, Navigation, and Control System Manual" (reduced-size for easy download) to the document library.   The full-quality scans in our Internet Archive collection.  Thanks to Ken Mortimer!
• Added rev 54 of E-1142 (MIT/IL System Status Report) to document library.
  

• As students of AGC assembly language know, the AGC language is actually an intermixture of pure machine code (called "basic" instructions) and higher-level instructions ("interpretive" instructions) that are executed on a built-in interpreter which is itself is written in basic instructions.  In an AGC program such as LUMINARY or COLOSSUS, a sequence of interpretive instructions is marked by the fact that it begins with the basic instruction TC INTPRET (to start a block of interpretive code) or TC DANZIG (to return to interpretive code from a basic-instruction subroutine called by interpretive code);  other basic instructions precede the TC INTPRET/DANZIG, while interpretive instructions follow it.  All very well and good ... but while INTPRET is clear, whyDANZIG?  Danzig is obviously (or was obviously) the name of a city in Poland, but is that significant somehow?  Since this is the kind of thing I worry about, I've wondered about it since the beginning of this project, about 15 years ago.  But on that issue, today is the day to stop wondering! I now know why, and you can know why too, if you follow this link to the explanation I've added to the assembly-language page.
• Enthusiasts may also recall that Hugh Blair-Smith has graced us with his preliminary notes on what an improved AGC architecture, which he terms "Block III", might look like.  Well his thinking on the subject, upon which he has been working with Bruno Muller, have advanced a lot in the couple of years since we last heard anything about it.  Naturally, I've posted the current thinking on this subject on our Block III page.
  

• On the AGC assembly-language page of this site, my intention was always to create a comprehensive manual for AGC assembly language.  While this was somewhat successful for the AGC's so-called "basic" instructions, it turned out to be sadly completely inadequate for the AGC interpreter language, whose descriptive section was basically a promisory note for future content that I ended up never creating.  In other words, if you wanted to read anything about the interpreter instructions, you couldn't read my lovely verbiage about it, but would pretty much have to fall back on the original Instrumentation Lab documents.  Unthinkable!  But wait ... suddenly Mark Schulman (thanks, Mark!) has stepped in to fill the void I left.  He has written just such a guide for the interpreter language as I envisaged, and has gifted it to us.  I have basically inserted it verbatim into the assembly-language page of the website.  If the AGC interpreter is your thing, read and enjoy!
• Steven Hauer has sent along a number of nice pictures of what's basically his implementation of Mike Stewart's Block II AGC emulator.  You can now read Steven's description and see his pictures on the physical-implementation page.
  

• When I originally created the document library, it was an earlier, more-innocent time, when men were men, women were women, and what today seem like relatively small downloads then seemed like freakingly huge ones.  Ah, 2003, will you ever come again?  At any rate, so-called comedy aside, back then I tended to put a little note next to each of the hyperlinks to show how many megabytes were in each document file.  Well, times have changed, at least as far as download sizes are concerned, and those quaint, old notes warning you about 4MB or 5MB downloads now just seem silly now that many of our downloads are hundreds of megabytes.  Besides, 90% of the newer additions to the library no longer had notations like that anyway.  So I've just bit the bullet and removed all of the old notations about download sizes and/or document page counts.  It's just the right thing to do!
• 4 new documents have wended their way to us from UHCL and have gone into the document library as well.  (I probably won't be able to actually upload them until later today or tomorrow, though, so don't be disappointed if their links don't work correctly just yet.)
• SIMFAM Description and Operation — describes a rope test equipment designed to allow plugging a "braid memory" into an AGC.
• Rope Memory Module Assembly Processing Procedures — details of the life of an AGC rope, from release, to SCB, to assembly, to distribution.
• A memo summarizing the above as a timeline.
  
• An MIT report describing ways to make NOR logic circuits more rad-tolerant. Presumably some of these techniques were used in the AGC logic design, though at this point that's just a guess.

• Added a workaround to the Raspberry Pi build instructions for a bug found in certain versions of the Raspbian software repository.  (Specifically, for the 2018-04-18 version of Raspbian, in which Virtual AGC builds but does not run under the previous instructions.)
• In the document library, the icon now relates to documents added from May 2018 onward (rather than January 2018 onward).
  
• Seven new documents added to the document library, of which the most significant are volumes 3 ("Control Data") and 4 ("Error Analysis") of the AS-278 GSOP, plus document E-1699.  The latter is a description (in the form of a proposal) for the physical construction of the AGC.  The remaining docs, which I won't list specifically here but which have arbitrarily been stuck with the electrical schematics, may or may not be useful in understanding discrepancies between the electrical schematics we have vs earlier physical AGC/DSKY units, but are not of general interest.
  

• Guidance, Navigation, and Control Block II Command and Service Module Functional Description and Operation Using Flight Program SUNDISK (Rev. 282)
• Guidance, Navigation, and Control Command Module Functional Description and Operation Using Flight Program COLOSSUS 2C (COMANCHE 67)

These are, of course, the super-awesome Apollo 7 CM and Apollo 12 CM documents corresponding to the super-awesome Apollo 12 LM document added yesterday.  Not only is this super-awesome (had I mentioned that already?), but this is actually the first significant documentation we've ever gotten about the Apollo 7 software.  All three of these documents were written by AC Electronics residents at the Instrumentation Lab.

• --radio-buttons — For the largest display screens (with, say, 1024 pixel rows).  Mission selection is the "traditional" way, via radio buttons in the user interface.
• --dropdown — (The default.)  For smaller display screens (with, say, 720 pixel rows).  Mission selection is in the newer way, via a drop-down list.
• --squish — For the smallest display screens (with, say, 480 pixel rows).

For use with --squish only, there's also a --maximize command-line option that maximizes the program at startup.

There are no installers for this new program version as of yet, but I'll get around to it sometime if I hear no complaints in the meantime.

• Excerpts from "Apollo 11 LM Timeline Book" (1969), including handwritten notes made, I'm told, by Buzz Aldrin.  It is a notable addition to the collection, because we previously had no final version of the descent procedures specific to Apollo 11, and the procedures in this document differ from those cobbled together from the closest alternatives (Apollo 12 procedures or preliminary Apollo 11 procedures).  This information is necessary, for example, in making simulated Apollo 11 landings in NASSP that are faithful to the 1969 original landing.
  
• Level III PGNCS drawings from Grumman.  These are basically souped-up versions for LM-4 through LM-15 of the LM ICD documents we already had, with more-detailed interconnection drawings and pinout information.  They're also significant in a different way, in that they are scans of "aperture cards" from the National Archives in Ft. Worth — a resource I had noted many years ago but had completely ignored, but which is now revealed as a potential treasure chest ... if only we could just figure out what that treasure chest contained so that we could ask for it! 
  

• "Interface Control Document: Definition of Saturn SA-513/SKYLAB 1 and SA-515/SKYLAB Backup Flight Sequence Program".  Notable for including a pinout of the LVDC and LVDA discrete inputs, discrete outputs, and interrupts, as well as a detailed mission-specific timeline of the theoretical behavior of those signals.
  
• "Saturn V Flight Program Development".  Describes the development process for the LVDC software (in a software quality assurance sense), as well as giving a very high-level architectural overview of the software.  Needless to say, most of the specified documentation developed during this process is missing from our collection.  Among the more-interesting soundbytes:  The LVDC software-development process for each launch vehicle, took 61 weeks.
  

• Added 13 COLOSSUS Memos to the document library.  We already had 12 such memos, but they were mixed in with the LUMINARY Memos, so to make them easier to find I created an entirely new section on the document library page exclusively for holding COLOSSUS memos.  Unfortunately, we know that the numbering for COLOSSUS memos goes up to at least 327, so fact that we now have 25 of them still leaves quite a few missing!  The new ones cover COLOSSUS revisions 197 through 221, with a few little gaps.
• Similarly, I found a couple of SKYLARK Memos memos lurking amongst the LUMINARY Memos, and referenced them in the SKYLARK Memos section of the document-library page.
  
• In dealing with the stuff above, I also happened to notice that various mission flight-plan documents which we'd previously been missing — Apollo 7, 10, 13, 14, Skylab, and ASTP —had become available on elsewhere on the web, so I've raided those documents from their original homes and added them to the document library as well.  In other words, nothing new in any larger sense, but now integrated into our document library.  A few other documents were mined and added in the same way ... just look for the icon within the document-library page.  One of the "new" documents, the Apollo Operations Handbook, Block II Spacecraft, isn't really new, but the copy we already had seems to have disappeared without a trace somehow.
  
• Found a nice picture of the LVDC, which I've dutifully added to the LVDC page.
  

• Added a new document to the document library page:  "Saturn Launch Vehicle Systems Handbook, AS-503" (i.e., for Apollo 8).
  
• The icon on the document library page now only refers to documents added in January 2018 or later.
  

• Apollo 8 checklists, from the Apollo Flight Journal.  (Actually, the checklists don't seem to have been posted at AFJ yet, but that's our source for them.)
• Apollo Operations Handbook, CSM J-Series Missions, Volume 2: Operational Procedures, from spacecraft.it.  The document is marked "Apollo 16", but covers CSM112-115 (i.e., is Apollo 15-17, plus the canceled Apollo 18). (Actually, the linked website seems to be broken and/or hijacked, so you can't get the document from there at this time, but that's the source for it.)
• Part 1
• Part 2
  

• Searchable-text version of the Apollo Operations Handbook for LM 10 and subsequent (subsystems data), to complement our original version of it, which wasn't searchable.  Kudos to Thymo van Beers for arranging to have this done!
• A document on simulation of the Saturn's Flight Control Computer.  (Beware! Not the LVDC.)
• Our first Apollo-era Colossus digital simulation, for Colossus 237 (Apollo 8)!  Contains pad-loads, though for the simulation epoch (March 1969) rather than for the mission launch epoch (December 1968).  The simulation is called "Bailout during Burn (Colossus Anomaly #45)", and its purpose is presumably self-explanatory, though I don't think we actually know the details anomaly #45 at this point.

I've also added a Python program called humanizeScript.py to the source-code tree, for analyzing the DSKY playback scripts (mentioned in the preceding entry) into reasonably human-friendly form.  This is mainly for my purposes for producing documentation for this website, starting from logged AGC i/o-channel data from NASSP, but I suppose it could be useful for other folks as well.  Also, I'm sure that as a first version it probably has a lot of deficiencies.

• 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.
  

• 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.
  

• 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.
  

• 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 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.

• Several bug-fixes in the source-code repository for the following problems:
• Inability to compile on Mac OS X.
• Inability to compile zipfile downloads (as opposed to git clones of the repository).
• Specific, comprehensive instructions for compilation on 64-bit Fedora 26 have been added, though I suspect they're probably good for other Fedora versions as well.
• Temporary change to Mac OS X compilation instructions, related to the following problem:  There is a bug in yaYUL on Mac OS X, though just for Block I AGC code, which causes Solarium (Apollo 4 & 6) to assemble incorrectly.  The instruction changes do not fix the problem, but simply prevent compilation-failure on Mac OS X.
  

• 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:
  
• Smaller-size ZERLINA 56 scans
• Higher-resolution ZERLINA 56 scans
• Smaller-size AP11ROPE scans
• Higher-resolution AP11ROPE scans

• 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

• 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.
  

• 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.
  

• 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.)
  

• 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).
  

• 1969 Apollo 11 landing digital simulation
• 1970 Apollo 12 landing digital simulation

• 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.
  

• Part 1
• Part 2
• Part 3
• Part 4

• Part 1
• Part 2
• Part 3

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.

• Document library:  Various new documents added.
  
• Several Block I era sets of Apollo training slides.  These are actually quite extensive and well worth your time, Block I or not!  We got them from reddit.
• Several operational-trajectory docs (Apollo 13 and 16) and revisions to operational-trajectory docs (Apollo 12 and 17), taken from the archive at the University of Houston, Clear Lake, amazingly helpful as always.
  

• 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:
• CSM System Handbook for Apollo 4 and Apollo 7.
• MSC Internal Note, "Apollo Reentry Guidance and Navigation Equations and Flow Logic"
• Kollsman Report, "Apollo Optical Subsystem and LM Alignment Optical Telescope" (3 volumes)
• Apollo - Soyuz Test Project Operations Handbook Command/Service/Docking Modules, CSM111/DM 2
  
• 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.
  

• 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:
• E-2448 Rev 1, "Users' Guide to Apollo GN&CS Major Modes and Routines".  This is essentially a user manual for the AGC software, essentially for Apollo 13 and/or 14, though the text in the document itself disavows any connection to specific missions.
• E-2448 Rev 4, "Users' Guide to Apollo GN&CS Major Modes and Routines, Colossus 3 and Luminary 1A".  This is essentially a user manual for the AGC software, for Apollo 15, 16, and 17.
• E-2471 Rev 2, "Apollo Guidance and Navigation Flowcharts, Program Luminary 1D (Rev 173)".  This is just what it sounds like:  a set of AGC software flowcharts for Apollo 14:
• Volume 1/2.
• Volume 2/2.
• R-567, "Guidance System Operations Plan for Manned LM Earth Orbital and Lunar Missions Using Program Luminary 1E".  I.e., most of the GSOP for Apollo 15, 16, and 17.  A couple of these sections we already had in a reasonable quality (but now we have two copies), but we didn't have the bulk of the document, particularly the huge section 4.  And sections 1 and 6 are still missing.
• Section 2 Rev 12, "Data Links"
• Section 3 Rev 8, "Digital Autopilot"
• Section 4 Rev 10, "Operational Modes"
• Section 5 Rev 11, "Guidance Equations".  I would characterize this more as a theory-of-operation document for various sections of the AGC software, but I think the guidance equations are indeed in there.
• Section 7, "Erasable Memory Programs"
  
• MSC-69-FS-4, "Programmed Guidance Equations for Luminary 1B, Manned LM Earth Orbital and Lunar Program".  I wouldn't really describe this as "guidance equations".  The document itself says it should be used in conjunction with a listing of the AGC software (in this case, Apollo 12 Lunar Module, and specifically Luminary 116), and my characterization of it is that it is a more-detailed, mostly-textual description of the various objects (specifically variables) appearing in the software than can be found in the program comments themselves.  In other words, it doesn't superficially appear to have much to do with "guidance equations", though admittedly it has >1000 pages, and I've not read it in detail as of yet.
• MSC-70-FS-2, "Programmed Guidance Equations for Luminary 1C, Manned LM Earth Orbital and Lunar Program".  This is basically the Apollo 13 equivalent of MSC-69-FS-4 (see above).  In other words, not guidance equations, unless they're well-camouflaged.
  
• 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:
  

• Removed some unwanted personal references.
• Updated syntax-highlighted HTML AGC listings.
  

• 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.
  

• Quite a few documents salvaged from NTRS were added to the document library, and linked into the Colossus and Luminary pages where appropriate.  Most were just random documents spread throughout the miscellaneous guidance&navigation document section of the document library, and I invite you to browse through that section, but I don't want to list dozens of documents individually here.  However, there were also various documents of particular note, the highlights of which in my mind are:
• E-1114, "Glossary of Terms and Symbols"
  
• "G&N System Data for Mission AS-202 Development Engineering Inspection" ... i.e., for "Apollo 3"
  
• "Results of Independent Flight Software Validation Test of the BURST116 Program for the LM-1 Mission" ... i.e., for Apollo 5
  
• "Apollo Mission SA 501 Preliminary Mission Profile" ... i.e., for Apollo 4
  
• "Independent Flight Software Validation Test Results for Mission AS-204A" ... i.e., for Apollo 1
  

• 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:
• Skylark GSOP, section 3
• Apollo 12 Spacecraft Operational Trajectory
• 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.
  

• 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.
  

• Abort Guidance System (AGS) (all from UHCL archives):
• LM/AGS Operating Manual, Flight Program 8
  
• LM PGNS/AGS Training Card
  
• Early unmanned missions (all donated by AGC developer Jay Sampson; see also the bits and pieces of Jay's story):
• Flight 206 Memo #11, "Prelaunch Erasable Memo Load Definition for AS206"
  
• Flight 501 Memo #8, "Programming Changes from AS-202 to AS-501".  This document is of particular interest, due to the fact that we have the source code for AS-502 (almost identical to 501) and may get the octals but not source code for AS-202, thus theoretically helping us to reconstruct the source code for AS-202.
  
• Flight 501 Memo #10, "Summary of Results of AS-501 Digital Simulations"
  
• Flight 501 Memo #14, "Values Used for the Final Verification of the AS-501 Prelaunch Erasable Memory Data Load on the MIT/IL Digital Simulator"
• Apollo 5:  E-2160, "Verification Results Summary for LGC SUNBURST (LM-1 Mission)"
• Improved (i.e., smaller and searchable) versions of the 5 LUMINARY Memos Dan Eyles recently supplied us with.
  

• Slight correction to the "John Norton Needs Glasses" story.
• Rewrote discussion of Apollo 11 LM code (Luminary 99) versioning (which is an ongoing story right now).
  

• 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:
• Apollo Primary Guidance Navigation and Control System (PGNCS): Final Report, Contract NAS9-497.
• Volume 2 (LM Data Book), Part 2 (LM 6 and Subs. Launch Mission Rule Redlines).
• Apollo 5 Mission (AS-204/LM-1) Spacecraft Operational Trajectory.
• Apollo 7 Spacecraft Operational Trajectory
• 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.
  

• 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:

• 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.
  

• 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.
  

• 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:

• I had forgotten over the years that our digitized Luminary 99 (Apollo 11 LM software) was actually missing almost an entire page (bottom of p. 1472 and top of p. 1473).  Of course, we had immediately reverse-engineered this when we were transcribing the source code, and knew that our reconstruction assembled to the correct octal values, but it would still be nice to have the "correct" version.  Fortunately, Don Eyles was able to supply snapshots (now on the Luminary page) from his own printout.  Gratifyingly, though not surprisingly, the reconstruction was 100% accurate, including the comments.  (Actually, there was a typo in the comments, but ignore that; it was 100% perfect in principle.)
• Don has also supplied another LUMINARY Memo, #138, now in our document library.  It describes the Variable Servicer then being implemented in ZERLINA.
• The Luminary and Colossus pages have had a sort of family-tree diagram for a while, in which the relationships amongst the various AGC programs were covered ... but only up to Apollo 11.  I've taken it upon myself to recreate that diagram, and extend it all the way to the end of Apollo, by which I mean Apollo-Skylab and Apollo-Soyuz.  It's a rather impressive picture, including even the science-project ZERLINA program, which was outside the main developmental flow; though even then, I'm told there were many other such separate programs, such as DIANA  (about which I have a little info but not enough to include it in the chart), AMELIA, and so on.
• By the way, if you want to know more about ZERLINA, see the volunteering page.  Speaking of which, I had forgotten to include Don Eyles's copy of LUMINARY 99 as a sponsorship opportunity, but have now done so.
  

• The program-comment text (but not white space) of Comanche 55 (Apollo 11 CM AGC program) has now been fully-proofed and corrected in GitHub, and its proofing data has been posted online, though undoubtedly errors remain.  Since the same has already happened with Luminary 99, as mentioned a few days ago, the complete set of Apollo 11 AGC code has now had its comment text corrected.  This is already paying off, as the corrected comments in Aurora 12 and Luminary 99 are migrating into the transcriptions of Retread 44 and Luminary 69 now taking place.  Good riddance, errors!
  
• Perhaps more excitingly,
  

• The program-comment text (but not white space) of Luminary 99 (Apollo 11 LM AGC program) has now been fully-proofed and corrected in GitHub, though undoubtedly errors remain.  (Recall the update of a few days ago that Aurora 12 and Sunburst 120 had already undergone this correction process.)  Because so many changes are involved, the proofing data (for Luminary 99, but not yet for Aurora 12 and Sunburst 120) has also been posted (note that it's a 115MB download), for anybody interested in the proofing process, or perhaps performing additional proofing passes.  There will be an upcoming article on our GitHub wiki regarding this.
  
• The colorized, syntax-highlighted version the Luminary 99, Aurora 12, and Sunburst 120 programs presented here on our Luminary page have been updated with respect to the comment-text corrections mentioned above.
  

• The Retread 44 executable is now available in the GitHub repository (namely, Retread44.binsource, which needs to be "compiled" with the command "oct2bin --no-checkums <Retread44.binsource" to actually get the executable rope image), and in theory can be run in the AGC simulator.  However, Retread 44 precedes the use of embedded checksums, and hence we cannot yet be as certain about the correctness as we normally would be at this point in the process, so I won't dignify this announcement by putting it in a fancy box.  Transcription of Retread 44 into source code is only in the early stages.
  
• Perhaps more excitingly,

Regarding the latter point, it is worth noting that the Artemis 072 (Apollo 15-17 CM) code has been available for a few years now, so that it is possible in theory to fly an entire simulated Apollo 15-17 mission ... if the AGC were the only issue involved in doing so.

• Don Eyles has sent 4 interesting  new documents, which at the moment are conveniently grouped together in our document library, as well as at the appropriate places on the Luminary page.  3 are memos describing some software changes incorporated in Luminary 69 (Apollo 10) and 131 (Apollo 13).  I particularly recommend the 4th, the exegesis of the Apollo 11 1201 and 1202 alarms ... not just for concise coverage of that issue, but for an extraordinarily clear and easy-to-understand explanation of the AGC software's multi-tasking functionality.
  

• The Luminary and Colossus pages now have a marvelous table (taken from document R-700, vol. 3) giving lots and lots of versioning information about various AGC programs, which I had previously just been inferring from textual descriptions in other documents.  Unfortunately, it basically only covers the timespan of Apollo 5-14, but that's not bad!
  
• Refer to the notes on the Luminary page for an explanation of the "almost!" in the announcement below:
  

• All of the Virtual AGC build-from-source methods on the downloads page (except the Mac OS X platform, whose instructions aren't entirely working yet) now create a launcher icon for Virtual AGC on the Desktop.
• In the Document Library, a couple of volumes of R-700, MIT's Role in Project Apollo, have been added:  A 2nd copy of volume 3 (the one we already had being somewhat distorted by the OCR process, and the 2nd undistorted but somewhat lighter and lower-contrast), and volume 2, concerning optical and other subsystems.
  

• For Luminary 210 (Apollo 15-17) AGC assembly-listing scanned imagery:
• Page 1149 of the reduced-resolution color imagery, which had a fold that made one of the lines hard to read, has now been replaced.
• A reprocessed form (high-contrast B&W images at a slightly higher resolution) has been added.  In almost all cases, these images are far more legible and easier to read, which I hope will assist the volunteers now transcribing Luminary 210 into source-code form ... they certainly are much easier for me.  Thanks to Mike Stewart for creating these.
• There are now workable Solaris build-instructions on the download page.
• Build-instructions for some platforms (Linux, FreeBSD) now build a desktop icon for Virtual AGC, which makes it easier to run once it's built.
  

• On the Colossus page, I made some corrections to the info about the GSOP for the Skylark program (Apollo-Skylab and Apollo-Soyuz CM).  Specifically, I realized that sections 1 and 2 from the Colossus 3 (Apollo 15-17) GSOP were simply republished unchanged as part of the Skylark GSOP, and thus we actually have 3 of the 7 sections of the Skylark GSOP, rather than just 2 of the sections as I had previously believed.
• The instructions for building Virtual AGC on FreeBSD now work, with the latest software updates in GitHub.
  

• The principal Virtual AGC download method, for anybody who doesn't want to build it from source, and is using 'x86 Linux, Windows, Mac OS X, FreeBSD, or Solaris, is now a VirtualBox based Virtual Machine that you can download from the downloads page.  The VM is tailored for running the simulations and doing visual debugging of AGC code.  Though a large download, this is a very easy way to run Virtual AGC.
  
• I have been going through the installation/build instructions on the download page, and updating them, since many of them are nearly a decade out-of-date.  The old instructions are still preserved as a link to a separate page.  However, the executive summary is that as of right now, it's really, really hard to build Virtual AGC on Mac OS X, Solaris, and FreeBSD, and in fact we no longer know how to do it. (But Windows and Linux are still okay, though for Windows you do need all of the latest fixes in the GitHub repository for it to work!)
  
• As a result of the two items above, the download page has essentially been completely rewritten, from beginning to end.
• Finally, most-importantly,