||Unlike the AGC software, our documentation
for the AGS (LM's abort computer system) is relatively
meager, to the point where it's tough even to be certain which
of the known versions of the software were used for which
of the Apollo missions. In other words, we
haven't yet uncovered any convenient table in the
contemporary documentation that just lists all of the
installed AGS software versions. Recall that there are
8 known versions of this abort-system "flight software", of
which we have copies of only 2 (namely, Flight Program 6 and
8). Well, Cooper Lushbaugh (thanks, Cooper!) has taken
it upon himself to dig more deeply into the various
abort-system documents than I had done, and to come up with
some of those missing answers. The bad news is that
Apollo 14 turns out to have used Flight Program 7, of which
we don't have a copy. And Apollo 13 may have
used Flight Program 7 too. (But it's still possible
that Apollo 13 may have used Flight Program 6; even Cooper's
extra digging hasn't told us for sure.) As far as
Apollo 11-12 and 15-17 are concerned, though, we seem to
remain on solid ground that they used Flight Programs 6 and
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
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
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.
||On the download page:
||Updated the description of the WebAssembly target on
the download page to cover the exact steps (at least on
Linux Mint 19) for loading the ported yaAGC into the demo
web page, and running the demo web page on the local
||On the download page (and the GitHub code
repository), there's now a WebAssembly target
for building Virtual AGC from source. The WebAssembly
target is a way of running the AGC CPU emulator (yaAGC)
natively within a web-browser. Many thanks to Michael
Franzl for working out how to do this, as well as providing
a browser. This target is not built by default when
you build Virtual AGC, since it relies on some one-time
setups most people wouldn't normally have in place on their
computer systems, but nevertheless can be manually built in
a simple, straightforward fashion.
description of yaYUL command-line switches to include
the --reconstruction switch, whose was merged
today from the "comanche67" branch of the GitHub repository
||I decided to follow up on yesterday's
improvements to the modern assembler's (yaYUL) sorting of
symbol tables. I've revised the format of the symbol
tables so that they end up being much easier to compare them
side-by-side with the original symbol tables created by the
YUL/GAP assemblers. The reason one would want to do
that, it has been pointed out to me, is that comparison of
properly-sorted symbol tables makes it much easier to detect
and correct misprints of symbol names in the transcribed AGC
source code. For example, the difference between
symbols like POO (pee oh oh) and P00
(pee zero zero) may not be very apparent visually a
digitized printout, and won't affect the assembled ropes if
misspelled consistently in any given version of an AGC
program, but will be very obvious in a properly-sorted
symbol table since a misspelled symbol will appear at a
completely different place in the table. Plus, it's
just kind of nice when the output from yaYUL is a little
more consistent with YUL and GAP.
The source code for yaYUL now in the github repository has these changes to the symbol-table formatting in it.
Besides that, an effort to find misspelled symbols in the transcribed AGC source code is actually underway right now, using just the methods I mentioned. I'm not doing this personally, as it preceded the symbol-table changes in yaYUL. (Various folks have amused themselves over the course of time by creating AGC assemblers of their own, rather than using yaYUL, and some of them were cleverer than I in formatting the symbol tables. ) At any rate, I don't see much reason to update the colorized, syntax-highlighted AGC source code on this site until at least a first pass on searching-and-destroying those misspelled symbols has been completed, and thus I haven't done so as of yet. Hopefully that will be in the not-too-distant future. Anyone who's particularly interested can follow the effort by reading issue #1141 in our github repository.
||Several new documents have been added to the
||Continued adding mission reports and their
supplements to the "Mission
Report" section of our document library page. I
expanded the section to include a number of postflight
trajectory documents as well. Over the past couple of
days, the documents added to that section have so
outnumbered the handful which were present originally that
I typically put on newly-added library documents had become
pointless. When the icons were there, it just appeared
as though every document was new. Since the
icons weren't helpful under these circumstances, I've
temporarily removed all of them in that section of the
||I have found out somewhat belatedly that
"Apollo X Mission Report" documents actually contain
useful info vis-à-vis the guidance system, including
for example some postflight trajectory data. While we
already had a "Mission
Report" section of our document library page, I have
now examined that section with new eyes and found it
severely deficient. Anyway, I've pepped up that
section of the library considerably, adding so many
documents that it hardly even seems like the same section
any longer. (I don't claim that this pepping up has
any great value, since all the documents I added were online
elsewhere; all anybody had to do was google them. But
still, it's nice to have stuff collected in one
place.) There are still various missing supplements to
the mission reports that I haven't yet made any effort yet
to find, so the section may still undergo some expansion in
first half of section 5 (guidance equations) of the
Comanche 72 (Apollo 13 CM) GSOP to the document
library, from a scan at UHCL. Fortunately, section 5
has only three PCR/PCN's, but the missing half of the
document will nevertheless likely be seriously inconvenient
if/when we're ever in a position to reconstruct Comanche
72's source code. The "good" news is that the Comanche
67 reconstruction, which is a prerequisite for
reconstructing 72, is seriously languishing right now, so
there's no immediate need for the 2nd half of the Comanche
on building Virtual AGC from source for MacOS X, due
to the fact that (I'm told) the old instructions no longer
work on newer Mac versions. The essential difference
is that wxWidgets 3.1.x (and eventually 3.2) must be
used rather than 2.8 or 3.0. Linux build-from-source
instructions have also been so updated with optional use of
wxWidgets 3.1/3.2, although 2.8 remains the recommended
version. Exploiting this update requires the latest
Virtual AGC source code.
||The instructions for building
Virtual AGC from source code have been updated to
include Slackware 14.2 and Chromebooks. Thanks to Nick
Warne for the info! (I haven't actually personally
tried those platforms. So many platforms ... so little
||Building on what I said in yesterday's post,
Dan Kosko has also sent in a couple other docs, now added to
our library page:
||Apologies for the infrequent site
updates. I've been involved for quite a while in a
possibly-futile attempt to reconstruct Comanche 67 (Apollo
12 CM AGC software); it's making progress, but it's slow,
Slow, SLOW, which is why there's never any news about
We do have a new website addition, though, in the form of a document added to our electro-mechanical page (as opposed to our document-library page). It's North American Aviation's "CSM Functional Integrated System Schematics, Block II". This is a doc I found several years ago at the U.S. Space & Rocket Center archives, but ended up failing to get digitized. Dan Kosko (thanks, Dan!) has followed up on it, finding that the University of Alabama, Huntsville, (thanks, UAH!) had made a beautiful scan of it a decade ago, years before my own unsuccessful efforts to get it.
||Paul Koning has sent me some feedback on our
How to Digitize page, in
which he chides me for recommending the use of the JPG file
format for storing, as opposed to lossless image-file
formats such as PNG. I've updated the page both to
clarify the conditions under which I recommend JPG vs PNG, and
to point out that every recommendation I make is probably
obsolete anyway, now that relatively cheap book scanners
(overhead scanners) are on the market.
|| 17 years ago, Sandy Brown, then associated
with David Mindell's now-defunct HRST website, sent me a
finding aid he had made for AGC-related materials he had
found at the MIT Museum, some of which were used as part of
the foundation for HRST. For some reason, I apparently
didn't think to post his finding aid online and forgot all
about it. A few years ago, Debbie Douglas, the MIT
Museums' curator, sent me this list, which I didn't recall
ever having seen before, and once again I didn't post it
online. Last year, she sent the list to Mike Stewart,
who sent it to me again, at my request. Yet again, I
apparently didn't post the thing online! Or at least,
I've just spent 20 minutes scouring everywhere before
finally finding it (in my email, not online). So if I
had put it online, it's well hidden. Well, the fourth
time's the charm, I hope, and it now has an entire, one-sentence-long
section on our website page about finding
material. It can't be missed now. Maybe.
||Accurate reconstructions of the source code for Comanche
45 and for Comanche 45/2
are now available, complete with annotations justifying the
reconstruction process. I've also updated the
VirtualAGC GUI program, so that it supports of them.
An accurate reconstruction of Luminary 69/2
has been available for a while. The upshot is:
Comanche 45 was the first of the source-code reconstructions in which I personally participated, in a minor way, as opposed to simply providing commentary after the fact. It's a pretty amazing process, in which I have a lot of confidence. I doubt I'm adequately articulate to convey to you just how amazing it is, so I'll just leave it by saying that I wish all of you had the chance to participate and see for yourself. It's quite a learning experience ... and a bit humbling as well.
This is the endpoint in a long series of reconstructions of missing revisions of Apollo 10 AGC source code, led by Mike Stewart:
✓ Comanche 55 (final release of Apollo 11 CM code, from actual hardcopy)
✓ Luminary 69 (initial release of Apollo 10 LM code, from actual hardcopy)
||At the top of the home
page, there's now a nifty picture which I call the AGC
Software Landscape, which graphically depicts the
interrelationship between all of the AGC software we have,
want to have, have reconstructed, are in the process of
reconstructing, or hope to reconstruct in the future.
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.
||I've gone through the source code of the
reconstruction of Comanche 44 (derived by Mike from Comanche
51) and added an annotation for each difference
between it and Comanche 51 justifying the change.
There are a few points which are speculative, but most of it
seems rock solid. Even the speculative points seem
pretty convincing. The annotations look a bit clunky
in the source-code files, but are quite nifty in the colorized,
syntax-highlight HTML listing, I think. They'll
probably be in flux for a few days.
||We've obtained a copy of the version of the
Guidance Equations for COLOSSUS 2 based on Comanche
55 ... i.e., the version based on the Apollo 11
Command Module's AGC software. Many thanks to Mark
Paral, who obtained the document from the Purdue Library,
and to the library itself for permission for us to post it
online. (That permission involved accompanying it with
a legal blurb, so if you click the hyperlink above, it will
take you not to the document, but rather to a place where
you'll have the opportunity of reading the legal notice for
yourself before actually getting to see the document itself.
This is an example of what we've been calling a "Norton
document". It provides, among other things, a
pseudocode form of the AGC software.
Aside from its intrinsic interest due to its relevance to Apollo 11, this document was critical to the just-completed reconstruction of Comanche 44 and is critical to the reconstruction-in-progress of Comanche 45, because the pseudocode description shows change bars for the differences between Comanche 45/2 and Comanche 55. While this doesn't tell you exactly what the changes were in AGC assembly language or interpretive code from Apollo 10 to Apollo 11, the pseudocode often follows the assembly/interpretive code closely enough to infer those changes. Or at least, it lets you infer them if you've developed the level of expertise and determination that Mike and Nik have. For the rest of us, such as myself, it at least lets you follow their reasoning.
I am in the process of trying to add annotations for each of Mike's changes to his reconstructed Comanche 44 source code (relative to Comanche 51), so that a satisfying justification is available for each difference. Since most of those justifications are based on the Norton document, I'm very pleased that it can now be made available. I figure that anything which can inspire a higher degree of confidence in the reconstruction is a good thing! But it's slow-going to add these annotations, and I don't promise the annotations will be completed on any particular timetable.
||In my comments about Comanche 44 a couple of
days ago, I mentioned that it had not yet been flown
in a simulated Apollo 10 mission ... thus implying that it
might be flown soon, thus providing additional confidence in
the validity of the reconstructed software.
What I didn't know, or had stupidly overlooked (as the case may be), was that Comanche 44 has a bug that prevents it from being used with the official Apollo 10 flight procedures as-is. So a test flight of Comanche 44 is probably not imminent, and we'll probably have to wait until Colossus 45 is available. It is still possible to fly a Comanche 44 mission, however, because a workaround was published contemporaneously. If you're interested in flying a simulated Apollo 10 mission using Comanche 44 plus the workaround, do read the blurb I've added to the Colossus page!
||Support for Comanche 44 has now been added to
the VirtualAGC GUI program.
||Apollo 10 AGC Command Module code!
As you may recall, our repositories contain a rather complete set of Lunar Module AGC source code, in the sense that almost all of the actually-flown missions are covered. Our coverage of the Command Module AGC source code is a bit spottier. The Apollo 10 mission is one of those gaps in which we haven't so far had the Command Module software. The software version actually flown on Apollo 10 was Comanche 45/2, though two prior software releases (Comanche 44 and 45) had been earlier targeted for the mission before being obsoleted, and their core-rope modules had already been manufactured. We do not have actual contemporary assembly listings for any of these 3 versions. (A listing for Comanche 44 is known to exist, but we have no access to it, and sadly, it is becoming increasingly unlikely that we ever will.)
You may also recall that Mike Stewart has been methodically trying to fill in many of these gaps in our software collection by reconstructing them from software versions we do have, along with contemporary documentation of version-to-version changes, while exploiting the fact that we have lists of memory-bank checksums of most of the manufactured core-rope modules. In so far as Apollo 10 is concerned, Mike's strategy has been to
||Alas, the National Archives Southwestern
(NARA) branch at which I was scanning LM engineering
drawings prior to closures related to the COVID-19 pandemic
is still closed to volunteers and researchers, and indeed
even the archivists are apparently once again having to work
remotely (after a brief respite in which they were able to
work onsite). Indeed, I've been informed that this
situation is likely to persist into 2021 ... no surprise,
given the sharp rise in infection rates in the U.S. and in
Tarrant County, Texas, the location of the branch. So
who knows when the LM-drawing scanning, or the CSM-drawing
scanning (which the archive was doing on its own without my
participation), will resume?
In the meantime, though, Mike Stewart has somehow gotten his hands on a book of Block I CSM drawings, and has scanned a few dozen of them for us, and I've naturally added them to our electro-mechanical page. Of course the NARA microfilm collection has tens of thousands of these CSM drawings rather than merely dozens. Eventually NARA's CSM scans will be publicly available. At least that's the plan, I'm told. But we don't know when that will be — many years, I project — nor whether we'll be able to afford to acquire many of the scans when they do become available. (The LM scans are free to us under arrangement, but I wasn't able to make any such special arrangement for NARA's CSM scans, and it wouldn't be surprising if the price tag for them turns out to be quite substantial. But who knows? Someday we'll see.) So these few dozen scans are very welcome right now! Not to mention that they're higher quality than scans from NARA microfilm.
||I didn't manage to get the documents
mentioned in the last entry posted online until a couple of
days ago. My apologies! Not (entirely) my fault,
though, since there was a conniption at ibiblio, now fixed,
which blocked all my updates.
I got a request yesterday from a correspondent for HP-65 calculator software. As you may or may not know — I didn't! — an HP-65 calculator was carried on the very last Apollo mission, the Apollo-Soyuz Test Mission (ASTP), as a backup device. Unfortunately, we don't have this software. Indeed, our collection of ASTP material in general is very small. But this request did prompt me to google a bit, in order to find what other ASTP info is available online. In the process, I mined a couple of documents for our document library, namely the ASTP "CSM Rendezvous Book" (in two parts) and "Design Characteristics for Soyuz and Apollo" (in three parts). You'll find them in the ASTP-specific mission documents in the library. The former document contains a lot of timeline data about the information which is supposed to be collected for entry into the HP-65. Also in the process, I found that on our Colossus page I had linked the wrong CSM mass-properties document in the entry for ASTP; now corrected.
We've also gotten a copy of the "HP-65 Rendezvous Targeting Checklist", which you'll find at the same hyperlink.
||Added 3 documents to the library. Since
it may be a bit tricky to pick them out by eye on the document-library page, partially
due to it being tricky to categorize them precisely, here's
an explicit list:
||The phase 2 reconstruction of Sundance 306
for the Apollo 9 LM, which we call Sundance306ish (see the
preceding log entry) has now been test flown in
Orbiter/NASSP, thanks to Nik Beug. Given that the main
purpose of the Apollo 9 mission is test flight of the LM,
Nik points out that the LM AGC software gets quite a workout
as well. So I think we can now be pretty confident
that Sundance306ish works properly, even though only memory
banks 36-43 are known to match Sundance 306 octal word for
octal word. The VirtualAGC UI program now uses
Sundance306ish for the Apollo 9 LM configuration, in place
of the prior phase 1 reconstruction (SundanceXXX).
SundanceXXX can still be flown via the command line, of
cource, but not from the UI.
||Recall from a couple of weeks ago that the LM
AGC software for Apollo 9, namely Sundance 306, was in
the process of being reconstructed from
memory-module dumps in lieu of an actual assembly listing of
the Sundance 306 program. Reconstruction is a 3-phase
process, in which phases 1 and 2 are successively-close
approximations to the exact code, but only phase 3 will be
an exact reconstruction. As you'll recall, phase 1
(which we call SundanceXXX), which is supposed to
functionally match Sundance 306 but not match it octal word
for octal word, had been completed and successfully test
Well, phase 2 (Sundance306ish), which is supposed to improve on phase 1 (SundanceXXX) by matching the contents of Sundance 306 memory banks 36-43 octal word for octal word, has now been completed as well. It has not yet been validated by being test flown, though I expect it will be flown (successfully) in the near future. I won't add support for it to the Virtual AGC GUI program until after a test flight, but you can still look at the code or run it in the AGC simulation via a command line right now. You can see the full writeup by following the hyperlink above.
It's admittedly unlikely we'll ever have a full phase 3 reconstruction, in which all memory-bank contents or even all memory-bank checksums are correct, no matter how much cleverness Mike and Nik manage to apply to the problem. I think we'd need extra source material which we don't currently have, such as an actual list of all of the Sundance 306 memory-bank checksums. Of course, one can't rule getting such a list, nor even the possibility of getting our hands on an actual assembly listing one day ... in which case the reconstruction would remain a magnificent tour de force, but ultimately have been obsoleted. Still, barring that, it's likely that incremental improvements to Sundance306ish are what's in store for the future regarding the Apollo 9 LM software. I'd recommend enjoying it as it is, rather than pining to no avail for source material we may never get our hands on. Gather ye rosebuds and carpe that old diem!
||Paul Fjeld (thanks, Paul!) has sent us the LM
erasable pad loads for Apollo 9 and Apollo 10.
I.e., the numerical constants that had to be entered into
the AGC manually or via telemetry upload, rather than being
hard-coded into the AGC's software. This is pretty
timely, considering that the initial reconstruction of the
Apollo 9 software just became available a few days
ago. The pad loads, you see, list both the memory
addresses and variable names into which the pad-loaded
numerical data goes, and thus gives us a way to associate some
of the variable names in erasable memory with their physical
addresses, independent of the software source code.
I'm told that the addresses in the Apollo 9 pad loads do
indeed match the addresses Mike and Nik used in the
reconstructed software, though it turns out that one
variable was triple precision but had been treated only as
double precision in the reconstruction. So the pad
loads provide not only a nice, independent confirmation of
the accuracy of the reconstruction, but also have managed to
pinpoint a minor error that had to be fixed!
||Although most of the recent updates to this
change log have related to the LVDC, it's well to keep in
mind that the main focus of this program is to provide the
original AGC software, along with means to emulate the AGC,
and and thus to run the original AGC software on your own
(presumably non-AGC) computer. And best of all, in
some ways, to run that software in the context of a
simulated Apollo mission on a spaceflight simulator such as
Orbiter/NASSP. If you want to fly a complete Apollo
mission, you ideally want to have the complete AGC
software for that mission: i.e., both the CM software and
the LM software. The Holy Grail, of course, would be
to have complete sets of AGC software for every
Apollo mission. We haven't quite succeeded in reaching
that pinnacle, but I think the results (after 17 years!) are
still reasonably impressive. Much more than I could
ever imagine 17 years ago. Ignoring those missions for
which we have partial sets, in which we have the LM software
but not the CM software or vice-versa, we have complete
software sets (more or less) for the following missions:
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
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:
You can see a full write-up, including the SundanceXXX
source code, on our
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
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
amusing/horrifying anecdote about LVDC documentation
to the FAQ page.
||A bunch of nice technical data relevant to
the LVDC (but not specifically about it) has fallen into our
laps today, and has been added to our document
library. You can see the
full write-up there, but here's a summary:
||As I mentioned a month or so ago, work is
proceeding on PTC/LVDC emulation — so I haven't been idle! —
but until it's 100% ready, there's not much excuse for
updating this change log. The PTC/LVDC emulator is
actually working quite well now, but I'm immersed in
nitpicking details that are of no importance in the larger
scheme of things before I can close it out. For
example, the PTC front panel has a printer that the PTC CPU
can print to, and in order to get the PTC software's self
tests to pass, I not only have to have the emulated printer
print the proper stuff (easy!) but also to have the emulated
printer emulate the (undocumented) timing of the original
physical printer (hard!). Yes, it's silly, and
certainly of no value in terms of LVDC emulation, but the
problem is that the PTC software doesn't advance past tests
that fail, so if I want to make sure all the self tests I care
about are actually run, I need to make sure the silly tests
I don't care about pass as well. Or I can just
cheat and comment out the tests I don't like in the original
PTC self-test software; I've had to do that a couple of
times already, but I'd really prefer not to do that until
forced to do so. The tests that I "care" about, of
course, are those that exercise the CPU's instructions and
interrupts, and if we can get those right for the PTC CPU,
then there's a good chance that they're right for the
only-slightly-different LVDC. PTC emulation good →
LVDC emulation good.
But I digress. The reason I'm writing today is due to something found in the collected papers of Mike Collins, namely most of the Gemini Operations Handbook for Gemini 10. (Thanks to Johannes Kemppanen for bringing this to my attention!) These handbooks consist of 3 sections, two of which (Sections II and III) appear in the collection. The missing Section I would seem to contain the spacecraft's electrical schematics and (presumably) a textual description of the theory thereof. What's particularly significant insofar as the OBC (Gemini flight computer) is concerned, though, is that ~50 pages of Section II, namely section 2.5.7, comprise a detailed user manual for the flight software. While we already had section 2.5.7 (and not much else) for Gemini 7, the Gemini 10 version is larger and more detailed. And of course, has mission-dependent differences. At any rate, you can explore the Gemini 10 operations handbook in our document library, or explore what we know about the Gemini flight computer on our Gemini page, if you have not already done so. Gemini flight computer, as you may recall, is a variant of the LVDC used to guide the Saturn rocket, and now that our PTC/LVDC emulation is nearing fruition, our Gemini page and software is probably due for an overhaul to incorporate what has been discovered along the way. But I'll leave that for another day.
A couple of other items from the Collins collection caught my eye, and so have been added to the document library as well: A partial copy of the Final Gemini X Flight Plan; we already had a partial copy of the Final Gemini VIII Flight Plan, but different parts parts of that document are missing, so the two end up somewhat complementing each other. Also, an MSC noted titled "Mission H-1 Abort from Lunar Powered Descent and Subsequent Rendezvous"; that's Apollo 12, and Collins (naturally!) didn't fly on it, but he wrote on the cover that it's "Worth saving because it shows all the 18 cases". I'll take his word for that, and you probably should too.
||Having received some questions (which I
couldn't answer) about the Saturn Flight Control Computer,
which was an analog computer in the Saturn Instrumentation
Unit that worked in conjunction with the LVDC and LVDA — and
the AGC — I realized that there was some confusion
online. On the LVDC page, I had correctly depicted the
device with a picture of the Saturn V Flight Control
Computer, but online it was possible to find many pictures
(incorrectly labeled) that were really of the Saturn I
Flight Control Computer, and which looked very
different. (One is a big cylindrical can, while the
other is a rectangular box!) I've updated the LVDC
page with labeled pictures of both, to eliminate any
confusion coming from our site.
||I noticed belatedly (after 11 years!) that I
had misspelled Dimitris Vitoris's name on our LVDC
page. Dumb! In connection with that, I saw that
the descriptions I had provided about the photos of LVDC
hardware Dimitris had sent us were very much out-of-date
with respect to the documentation we now have
available. The descriptions have been corrected and
fleshed them out quite a bit, though they're still full of
holes that I patched up with speculation.
That also caused me to go back and think about the material I had gathered on my visit to the U.S. Space & Rocket Center archives about 2 1/2 years ago, and to realize that I apparently never made any of it available online afterward. Well ... there were slim pickings there, compared to what I hoped to find, but not zero, so disappointment that things didn't go my way is not much excuse! At any rate, I've now belatedly taken care of that:
||Well, it took a while, but our
"modern" LVDC assembler (yaASM.py) has now been
updated to assemble for a PTC target computer.
transcription of the PTC ADAPT Self-Test Program has
been completed and debugged, and the transcription of the
octals for the PTC ADAPT Self-Test Program has been through
a round of additional corrections. Plus, my online redigestion of how LVDC/PTC
assembly-language works has been accordingly updated
with all the stuff I found out in the process. The
upshot is that the LVDC assembler not assembles the PTC
ADAPT Self-Test Program, with no errors, and the octals
generated by the assembly match the transcribed ones
100%. And the original LVDC AS206-RAM Flight Program
still assembles 100% exactly as well, with some improvements
to the messages generated by the assembler.
That's a mouthful, but the upshot is that our second "LVDC" program (albeit actually PTC) is available online for your study and even assembly. It's not subject to ITAR restrictions they our first LVDC program may be. Since its function is self-test, it will prove invaluable in validating our eventual LVDC/PTC emulator. Now all we need is an LVDC/PTC emulator, and we can actually run the thing.
transcription of the "octal listing" for the PTC ADAPT
Self-Test Program has been completed and
proofed. The "octal listing" is the assembled form of
the PTC program, so in principle, if you had an LVDC
emulator that supported the slight instruction-set
differences between the LVDC and PTC, you could actually run
it in simulation right now. Of course, you don't
have such an LVDC emulator (I assume), so that's admittedly
not terribly helpful just yet. (Moreover, I should
warn you that even though the transcription has been
completely "proofed", there's every reason to believe that
it's unlikely to be 100% correct yet. I relied on OCR
for data entry in order to save time, and OCR'ing this kind
of material is such an inherently buggy process that during
proofing I ended up having to correct nearly 25% of the
octals. Which almost guarantees that a significant
number of errors escaped my notice. My guess is that
10-20 errors were undetected on this first proofing pass.)
But emulation isn't really the purpose of the transcribed octal listing anyway. Its real purpose is to serve as an eventual cross-check of the transcribed source code for the PTC ADAPT Self-Test program, since when that transcribed source code is assembled using our modern LVDC assembler, it should produce an octal listing identical to the original (transcribed) one. But transcription of the source code has barely begun at this point, so cross-checking it is hardly an immediate issue! Personally, I'm not going to revisit proofing of the octal listing until after transcription of the source code, so the octal listing will remain in this proofed-but-probably-still-buggy shadow state for quite a while unless somebody else cares to step forward and take care of it.
Incidentally, the LVDC is essentially a black box, in which electrical inputs are provided and electrical outputs are produced, but there's no user interface, so it's not clear that emulating it outside the context of (say) a full spacecraft simulator like Orbiter/NASSP would be too exciting for anybody. (Not to mention the fact that we still don't even know whether ITAR would allow us to "export" the LVDC Flight Program to Orbiter/NASSP anyway. But I just meant it might be not too exciting entertainment-wise.) Admittedly, the LVDC does have telemetry that could be monitored. But for the PTC, on the other hand, one of the peripherals it includes is a printer, and the PTC ADAPT Self-Test Program does send output to that printer. So, perversely, simulating execution of the PTC ADAPT Self-Test program could actually be more fun than simulating execution of an LVDC Flight Program, because we could watch messages appear on the simulated PTC's simulated printer.
||Work on transcribing the source-code for the
LVDC PTC ADAPT Self-Test Program has begun, though there's
not much to show for it just yet other than an
almost-empty placeholder folder for it in our GitHub
repository. In the course of what little
progress I've made, I've found a handful of differences from
the assembly language that appeared in the AS206-RAM program
on which I had patterned the LVDC documentation and
assembler, so I've been updating my online descriptions of LVDC
pseudo-ops and of LVDC CPU instructions
accordingly as I work. Obviously the assembler will
have to be updated as well for these new pseudo-ops and
changed CPU instructions, but nothing has been done on that
front at the moment. Also, for convenience (mine!), the
scanned pages have been extracted from the much larger PDF
document in which they originally resided, massaged slightly
for appearance, and provided on our LVDC page as a
zipfile of image files for individual pages.
||The initial pass at creating G&N
assembly drilldowns is now complete. I.e., all
parts lists for G&N assemblies traceable in a top-down
fashion from the top-level guidance system assemblies have
now been entered into the repositories, checked, debugged,
and used to regenerate all of the G&N assembly drilldown
pages (such as the
Apollo 11 LM Guidance System). Plus, I found
that the script which generates the drilldown's web-pages
had rotted somehow and begun discarding some items in the
parts list that had non-integer quantities (such as cable
lengths). Hopefully, I've fixed that. That's not
to say that the drilldown is "perfect" (even in the very
loose sense that that word is now apparently being used by
some folks in America), but it does mean that I don't have
any ideas right now about how to track down residual errors
in the drilldown. So I feel entitled to say that the
work has been completed.
However ... I do have some plans to improve the drilldowns at some point in the future, though not necessarily right away since I have other things I want to take care of first. Eventually, though, the idea for improvement is that since the existing drilldowns have been generated in a top-down fashion, they run into difficulties whenever there's some G&N subassembly for which we don't have a drawing. When that happens, none of the sub-subassemblies or components belonging to the missing subassembly will appear in the assembly drilldown. For instance, if you look the page for the Apollo 11 LM Guidance System mentioned above, you'll see that item #72 in the guidance system parts list is 6011876, "Sunshade and Radar Shield Assembly". We do not have the drawing for that, and consequently don't know what the Sunshade and Radar Shield Assembly contains; it's just a drawing number and a title, and nothing more. All of the other subassemblies of the guidance system are instead expanded to a greater or lesser degree.
But wait ... don't abandon hope! Fortunately, many of the G&N drawings contain not only parts lists for their own components and subassemblies, but also list their own parent drawings; i.e., they provide a list of all of the G&N assemblies in whose parts lists they themselves appear. This is rather hit-and-miss, and not all drawings do this. But enough of them do it that it's possible to create a kind of half-baked assembly hierarchy by working from the bottom-up rather than the top-down. Let's call that a "drill-up".
If a "drill-up" assembly hierarchy were combined with the "drill-down" assembly hierarchy we already have, it should be possible to make a more-complete assembly hierarchy in which some of the missing assemblies (and their contents) are partially filled in. Alas, making the drill-up will require not only some preparatory thought, but also some software (easy!) and a huge database of the parent assemblies for G&N drawings that list their own parents (very time-consuming to create!).
In just a handful of cases, the most significant of which being the "logic modules" in the Block II AGC, this kind of thing has already been done. For example, if you trace down through the drawings for the Apollo 11 LM guidance system (drawing 6014999-091), down to the AGC itself (drawing 2003993-031), you'll find that the drawing for the logic modules (2003888-xxx) is missing. Frustratingly, the logic modules are the critical active portions of the AGC, since they contain all of the digital electronics; i.e., everything that makes the computer compute! Considering how critical they were, just washing our hands of it at that point and saying "too bad!" didn't seem to be an adequate response. Luckily, we just happened to discover some of the significant assemblies comprising 2003888, and thus were able to include them in our existing assembly drilldown. E.g., even though 2003888 is missing from the assembly drilldown, the drilldown still is able to list some of the elements for Logic Module A3 (2003888-031) as being the circuit boards 1006395-005 and 1006395-006, and the electrical schematic 2005251.
However, the existing places in the assembly drilldown where we've been able to do this have really been more a product of luck and desperation than of any systematic effort to work around missing assemblies in general. The idea of the proposed future "drill up" is to supply such a systematic effort across the entire spectrum of G&N drawings, and to work around missing assemblies wherever possible, rather than merely wherever lucky and desperate.
As I say, though, this won't be done right away, and I don't have any particular schedule on which I'm contemplating doing it. Of course, anyone who wanted to help out in creating the database of parent assemblies could help to move it along a little faster!
||Added some (but not yet all) drawing titles
to LEM engineering-drawing box 523, the last
aperture-card box I managed to scan before the National
Archives was closed to the public as a COVID-19
precaution. (Hint: There won't be any new LEM
scans until ... sometime.) However, in the process of
adding these titles to the index, I noted that the box
contains the top-level drawings — well, perhaps not the very
topmost drawing; it's difficult to tell — for LM-3 (Apollo
begin with LDW280-53000. That's nice, given that
it may be quite a while before any more scans can be
made. Better than nothing, anyway.
||I've been adding searchable text to some PDFs
in our document library that didn't have it before, such as
documents E-1142 (mentioned in the previous entry) and
70-LM-145 (added a couple of weeks ago). A little over
120 documents are affected. Which is not to say that
I've sought out and fixed every PDF that needs
searchable text added to it, but it's good progress.
(If anyone feels the absolute need for a list, I'll send you
one, but it seems rather pointless to me to post one
online. It's not as if anybody has been clamoring for
||Drawing titles added to the index page for
LEM engineering-drawing box 518.
||Finished added drawing titles to the index
page for LEM engineering drawings box 517, and indexed all
of its grayscale rescans as well.
||While I haven't had a chance to update the
index pages yet, grayscale rescans have been done for those
aperture cards in LEM boxes 511 through 514 whose initial
B&W scans were illegible. If you absolutely can't
wait for the indexes to be updated (in a few days), you can
see the directly browse the rescans at our Internet Archive
site: rescans for box 511,
The index pages for those boxes do show which rescans were
scheduled, but probably do not correctly match the order in
which you'll encounter the scans.
||Updated the LEM drawing indexes to include
grayscale rescans of those B&W initial scans that were
illegible, for the following aperture-card boxes: Box
507, Box 508, Box 509, Box 510. (Actually, in Box 509,
I somehow forgot to rescan drawing LDW280-14342. This
drawing covers multiple parts, namely LDW280-14342-11, -12,
-15, -17, -19, and -21, of which only -19 has impaired
legibility and indeed may still be marginally usable ... so
I think there might be a pretty significant delay before I
get around to correcting my mistake and rescanning
it.) This covers all of the rescans which have been
made so far.
||Added a complete set of scans of LEM drawings from aperture-card Box 517.|
||In Box 510, finished added drawing titles and
marking illegible scans for eventual rescan. Began
performing similar work on Box 511 as well. All of the
previous LEM boxes have contained only simple building-block
parts, except for cards that had accidentally been filed in
the wrong boxes, but in 511 we begin to see some drawing of
significant complexity, such as LDW280-17388 (the
descent-stage fuel-lines diagram, >300 scans) and
LDW280-17389 (the environmental system piping diagram, ~70
||The aperture-card scanner is finally
available again, so some new scans of LEM drawings have been
||Added engineering-drawing titles and marked
illegible scans in LEM aperture-card box 502.
(Thanks, Hartmuth!) This actually completes the
indexing for all LEM aperture-card boxes that have been
scanned so far, >15K scans ... but keep in mind
that's only 8 boxes out of the 280 total LEM boxes.
Unfortunately, the aperture-card scanner broke down a couple of weeks ago, and I'm not privy at present to the proposed scheduling for getting it fixed. Actually, what with the intervening Holidays and various other coincidental conditions, I'm not even sure that the scheduling has been addressed yet at NARA. Well, it'll be fixed when it will be fixed, and for now we'll have what we'll have. In the interim, I'm hoping to go back and scan (with a different, slower scanner) the drawings which proved partially or completely illegible on the first attempt. That's about 400 scans. But again, we'll have to see.
||Added engineering-drawing titles and marked illegible scans in LEM aperture-card box 508.|
||Added engineering-drawing titles and marked
illegible scans in LEM aperture-card box 507. Fixed
a number of erring revision codes and sheet numbers in boxes
503-506 as well.
||Retroactively marked the illegible scans in
LEM aperture-card box 504. Apparently this had also
been done for box 505 as well, although I was too daft to
note it, so the upshot of that is that all of the LEM boxes
to which drawing titles have been completely added (namely
503-506, as opposed to the boxes still being processed) have
also had their illegible scans marked for later
rescanning. Each future LEM box will have drawing
titles and illegible-scan markings added concurrently.
||Added the scans of LEM engineering drawings
from aperture-card Box
||Added the engineering-drawing titles for LEM
||Added the scans of LEM engineering drawings
from aperture-card Box
507. Corrected the engineering-drawing titles in
G&N aperture-card boxes 471 and 472. Modulo any
boo-boo's on my part, that means that the drawing titles in
all of the G&N aperture-card boxes are now up-to-date.
||The drawing titles were corrected for
aperture-card boxes 457 and 468-470. For all of these
boxes other than 468, as well as for box 456 (yesterday),
there were additionally dozens of corrections in each box to
drawing numbers (rather than just drawing
titles). Perhaps the scanner had become dirty at that
point without my noticing, and thus was reading the punched
aperture-card metadata unreliably. Or whatever.
Well, live and learn! Fortunately the mistakes were
very regular, so they were relatively easy to spot.
(All the ones I spotted related to 9's having turned into
8's.) Still, I suppose it's possible I missed some of
||Drawing titles corrected for aperture-card
boxes 454, 455, and 456.
||Drawing titles corrected for aperture-card
boxes 451, 452, and 453.
||Drawing titles corrected for aperture-card
||Added several boxes of LEM engineering
504, Box 505,
Box 506. As
indicated in previous comments, the indexes won't initially
include drawing titles, since those have to be manually
||Added a couple of RTCC-related mission-specific
documents (AS-207/208 and AS-503A/504A) to the
||With the completion of scans of the MIT
G&N System engineering drawings last week, scanning of
GAEC (Grumman) LM engineering drawings has now
I've had second thoughts about my earlier comments, wherein I said that I wouldn't bother to index any of the LM drawings, and have decided to go ahead and provide a dedicated index page for each box of LM drawings. Nevertheless, for technical reasons it's still the case that I don't intend to add any of these LM drawings to the master engineering search engine or to provide assembly drilldowns. So the drawings will still be a trifle trickier to access than the G&N drawings in some cases. At any rate, the first couple of boxes are now available, namely Box 502 and Box 503. We won't be reaching the drawing-number range containing the top-level drawings for the LM until boxes 518 through 528, though, which hopefully will happen sometime in January 2020, depending on the breaks. Due to the fact that the metadata for the LM drawings is completely different in form from the metadata I was working with for the G&N system, the process of creating these indices is very much a work in progress that will undoubtedly experience a few initial hiccups.
Unfortunately, the drawing metadata (drawing number, revision code, etc.) on which the box-index pages are necessarily based turns out to be incorrect much more often than I've been accustomed to in the earlier (G&N system) scans. There are dozens of such errors in boxes 502 and 503 alone. The usual error is an incorrect drawing number. Thus it is often the case that due to being mislabeled, a drawing may not only be in the wrong position in the index table for any given box, but may even be in the wrong box entirely. I've made an attempt at correcting these, but given the vast number of scans involved, there's just no way I can do it whilst still performing scans of additional boxes. In other words, I had to give up pretty quickly. Perhaps they can be corrected in the future ... perhaps by someone much more interested in the LEM drawings than I personally am. (Hint!) But don't hold your breath waiting for me to do more than a handful of them myself.
Possibly even worse, the aperture-card punch-data doesn't list any of the drawing titles at all, not even the abbreviated titles as the G&N punch-card metadata did. So at present, all (or almost all) drawing titles are simply listed as blank. Over the course of time, perhaps, those drawing titles can be manually added to the index pages. (Again, hint! Hint!!) As a rule of thumb, I'd say that any entries having a non-blank title in the index have also been double-checked or correct insofar as their other metadata.
||Finished correcting all engineering-drawing
titles for aperture-card boxes 474-477. That doesn't
mean that all titles for all scanned boxes are corrected yet
— even though 477 is the last box scanned so far — but it
does mean that all Job Description Card (JDC) titles have
now been corrected. I just happened to think those
were more interesting than the "regular" drawings I've
scanned in earlier boxes but haven't corrected yet, so I
decided to do them tout suite.
||Completed scanning aperture-card box 476, plus box 477. Note that
boxes 431-477 are the entirety of the Apollo G&N System
engineering drawings stored at the National Archives
Southwest branch in Forth Worth, Texas, and thus I've now
scanned all available CM/LM G&N drawings.
As far as we know. There's always the possibility of
aperture-cards being stashed in the wrong boxes and
therefore remaining undiscovered — indeed, I found a dozen
or so such drawings today — but admittedly, it may be a very
long time (if ever) before such misplaced drawings are
revealed. In other words, I wouldn't hold my
breath! At any rate, the grand total so far is about
90K scans of about 12K unique drawing numbers.
That doesn't mean the work on these G&N drawings has finished. Many of the indices for the boxes still need to have their drawing titles corrected to agree with the drawings' title blocks (as opposed to the aperture cards' punched metadata), and many assemblies represented by the drawings still need to have their bill-of-material information digitized to allow accurate assembly drilldowns; plus, those electrical drawings being transcribed to CAD still need transcription. Nevertheless, the initial work of physically scanning the drawings has finished, and the remaining work on them can proceed without regard to physical access to the archives.
It also doesn't mean that scanning is complete, either. While scanning of guidance & navigation drawings has finished, many additional (non-G&N) unscanned boxes of aperture cards remain. The next step is to scan Grumman's LM engineering drawings, boxes 241-333 and 502-688. A quick calculation shows that there are 280 LM boxes (over 500K scans) vs the 47 G&N boxes (90K scans) ... so it may take quite a while. There are additionally many hundreds of North American CSM boxes, but I'm not currently planning to scan any of those personally; I have reason to believe they may eventually become available via other mechanisms without any intervention be me (thank goodness!), but "eventually" is a rather open-ended concept in this case.
Incidentally, box 477 contained a group of drawings (over 500 of them) not conforming to the pattern of the other G&N drawings. The group included such things as IRNs (Interface Revision Notices) and TDRRs (Technical Data Releases or Revisions). Right now, it's hard for me to deal with these anomalous drawings in the same kind of context (i.e., master engineering search engine or aperture-card box index pages) as the other drawings. As a result, instead of including them on the box 477 page, I've segregated them onto a separate "Additional Engineering Drawing" portal, from which you can still view the scan without any expectation of them being pre-digested by me. Several other groups of anomalous drawings (from boxes 431 and 472, and elsewhere) have been included on that portal as well. I expect that the Grumman LM drawings whose scanning will commence soon will be handled in that same way, simply because it would be incredibly time-consuming for me to treat them comparably to the G&N drawings. In other words, I'm willing to scan non-G&N drawings, but not to fuss with them endlessly. That will be left as an exercise for the reader.
||Completed scanning aperture-card box 475 and about
95% of box 476.
||Completed scanning aperture-card box 474 and about 80% of box 475.|
||Finished updating JDC document titles in box
473, as well as a few in 474.
||Updated various JDC document titles in box
||Completed scanning aperture-card box 473 and about 50% of box 474.|
||Completed scanning aperture-card box 472 and about
40% of box 473.
Box 472 is actually the end of the Apollo G&N
engineering drawings as such, and box 473 marks the
beginning of a series of boxes containing Job Description
Card (JDC) documents. The documents themselves
represent things like test procedures for Apollo G&N
equipment, process instructions pertaining to that
equipment, and so on. Box 472 also contains a couple
dozen Grumman Aircraft Engineering Corporation "interface
revision notices" for the Lunar Module. I don't
understand the system for designating those notices, so
while we link to an archive
of their scans, I've made no attempt to actually index
any of them.
||Corrected the engineering-drawing titles for
aperture-card boxes 447, 448, and 449. Unfortunately,
for box 449, just as there was for box 444 (see the entry
below for 2019-11-11), there is a range of roughly 150 scans
with randomly mispunched aperture-card metadata. I
think I've corrected them, but there were so many of them
that I'm bound to have made a few errors along the
way. Nor (due to the effort involved) did I bother to
move all of the corrected scans around to their proper
positions on the index
page for box 449. In other words, drawing-index
table on the box 449 page is somewhat out of order.
Fortunately, all of the scans are within 5-10 rows in the
index table from where they should actually be located, and
finding them hopefully isn't too much trouble.
Probably I'll revisit that page at some point and finish
fixing it all up nicely.
||Corrected drawing titles for aperture-card
boxes 445 and 446. Various mil-spec
drawings added, as referenced by recently-added
||Corrected drawing titles for aperture-card
boxes 443 and 444. In box 444, there was a
previously-missing drawing (1020428) with mispunched
aperture-card data that had incorrectly identified it (as
1010428). Unfortunately, due to the vast number of
scans being made, time-pressure has so far caused me to
often trust the drawing numbers punched in the
aperture cards, and to assume that only the drawing titles
need to be corrected. In other words, since the titles
are the same for all cards with the same drawing number, I
haven't typically needed to look at every single scan, and
hence haven't really had any way to detect scans with
miscoded drawing numbers or revision codes. Over the
past few days, though, I've been finding such miscodings,
which have usually ended up in the wrong boxes (as 1020428
did), rendering them undiscoverable afterward if the drawing
numbers aren't corrected. So at some point, sadly, I'm
going to have to revisit these scans and look at every
single one of them to see if their drawing numbers and/or
revision codes match the index. At the moment there
are over 80K scans ... and soon to be over 100K for the
Apollo G&N system alone. I can't say I'm looking
forward to that. Anyone to wants to volunteer to help
with that double-checking would be welcomed eagerly.
||Corrected drawing titles for aperture-card
boxes 441 and 442.
||Corrected the drawing titles for
aperture-card boxes 439 and 440 to match the drawings rather
than the aperture-card metadata. Quite aside from the
error-prone nature of this activity, due to it being almost
entirely manual, there was an additional difficulty for box
439. As you may recall, the microfilm slides of the
drawings are taped into "aperture cards", which are computer
punch-cards into which metadata such as the drawing number,
revision code, etc., has been punched. Well, it looks
for all the world as if (back when the aperture cards were
created, whenever that may have been) whoever was
doing it may have dropped a hundred or so of the microfilm
frames on the floor prior to taping them into the cards, and
then picked them up and taped them into the cards without
checking that the slides were still in the correct
order. So for this range of 100 or so scans, the
metadata usually does not match the drawings. The
drawing numbers are often right (but not always) on the
messed-up cards, but the revision codes were usually
wrong. Yikes! (Or Yipe! if you prefer.)
Well, I "corrected" all of that on the box 439 index page,
but with so many of the scans needing to be fixed, who knows
how many errors I missed! What can I say? It's a
||Completed scanning Apollo G&N engineering
drawings from aperture-card box 470, added the
entire box 471,
and about 5% of box
472. Unfortunately, in the case of the latter
two boxes, the scanner began degrading very rapidly toward
the end of the process ... i.e., the scanner requires
cleaning. When that happens, it tends to mean that the
metadata scanned from the cards is often incorrect, which is
precisely what happened in this case. That metadata
(drawing number, revision, sheet number, frame number, etc.)
is used to form the index tables for their respective
web-pages, so errors in the metadata result in a corrupted
index. I've corrected many hundreds of entries in the
indices for boxes 471 and 472 so far, but there's no
guarantee I've caught all of the errors. Hopefully, if
there are errors remaining in the index, they'll be caught
and corrected in the reasonably near future. For now
(alas!) I'm going to curtail scanning activities until the
scanner has been cleaned, because finding/correcting the
drawing index is quite a laborious process. Hopefully
I'll be able to resume scanning again around the middle of
My short-term goal is to finish scanning all of the Apollo G&N boxes (i.e., through box 477) by November 21, which is the last day the U.S. government (and hence the National Archives) is funded. In other words, if the government shuts down on the 21st, then scanning will be impossible for the duration of the shutdown. Personally, I think a shutdown is highly likely. News reports, on the other hand, are so far discounting that possibility. Well, we'll see; I'd be happy to be wrong. At any rate, after box 477 is scanned, then scanning of the (hopefully!) complete set of Grumman Lunar Module aperture cards will commence. I expect that process to take the next couple of years.
||Completed adding Apollo G&N engineering drawings from aperture-card box 469 and added almost (but not quite) all of box 470.|
||Completed adding Apollo G&N engineering drawings from aperture-card box 468 and added about the initial 90% of box 469.|
||Completed adding Apollo G&N engineering
drawings from aperture-card box 457 and added
about the initial 75% of box 468.
(Boxes 458-467 had already been scanned previously.)
||Corrected all engineering-drawing titles in
drawing index for and assembly drilldowns for Box 438 ...
i.e., change them to match the titles on the drawings
themselves rather than the abbreviated titles from the
aperture-card metadata. I used a new software tool to
ease the burden slightly, so I hope that hasn't introduced
any errors on its own. Visual inspection and HTML lint
tools don't reveal any obvious errors, so the new tool
probably works. At any rate, I'm working upward (in
box/drawing numbering), and it will take quite a while
before the corrections catch up the the ongoing scanning.
||Completed adding Apollo G&N engineering
drawings from aperture-card box 454, added the
entire box 455,
and added about the initial 25% of box 456. A
handful of additional assemblies were also added to the assembly
||Completed adding Apollo G&N engineering
drawings from aperture-card box 453, and added
the first 95% or so of box
454, and added some additional assemblies to the assembly
||Completed adding Apollo G&N engineering drawings from aperture-card box 452, and added the first 80% or so of box 453.|
||Completed adding Apollo G&N engineering drawings from aperture-card box 451, and added the first 60% or so of box 452.|
||Completed adding Apollo G&N engineering
drawings from aperture-card box 450, and added
the first third or so of box 451. We've
now surpassed 60K scans of engineering drawings in the
library, though that's a little less than 8K unique drawing
||I had intentionally, temporarily omitted 78
scans of North American Aviation "Interface Revisions
Notices" from aperture-card
Box 431. I had been confused about how to
present them, given the fact that they follow a different
numbering system than all of the other engineering drawings
scanned so far, and that the aperture-card metadata isn't
entirely accurate. Well, a lot of time has passed, and
my confusion persists. So in the end I've handled it
by simply adding a link to their raw scans at our Internet
Archive site, without any attempt to systematically present
them in indexed form at all. Too bad, but better than
nothing! If anybody can figure them out systematically
enough to provide me with a reasonable index of them, I'd be
happy to post it.
||Completed scans from aperture-card Box 447, along with almost all of of Box 448. As usual, the hyperlinks at our Internet Archive site may take a while to become "live". The G&N assembly drilldowns were regenerated.|
||Completed scans from aperture-card Box 446, along with
the initial half (and a tad more) of Box 447. As
usual, the hyperlinks at our Internet Archive site may take
a while to become "live". The G&N
assembly drilldowns were regenerated.
||Completed scans from aperture-card Box 445, along with the initial half (and a tad more) of Box 446. As usual, the hyperlinks at our Internet Archive site may take a while to become "live". Various assemblies were also added to the G&N assembly drilldowns.|
||Completed scans from aperture-card Box 444 and scanned the initial 25% or so of Box 445. At this writing, some of the uploading and online processing at the Internet Archive is still being performed, so some links may take a while to become "live". Various related things (assemblies and individual parts) were also added to the G&N assembly drilldowns.|
||Added scans from remainder of Apollo G&N
engineering drawings from aperture-card Box 442, the
entirety of Box 443,
and the initial 5% or so of Box 444. As
usual, some of these are still in the process of being
uploaded to the Internet Archive or else are still being
processed there at the time I write this, and so may only
become gradually available online. Various related things
(assemblies and individual parts) were also added to the G&N
||Updated the drawing titles for aperture-card
boxes 431 and 432, as well as
associated engineering-drawing search engine and assembly
drilldowns. In the process, I found a weird situation
in which three drawing scans were miscoded (in terms of
drawing number) and swapped between boxes 431 and 463.
I only discovered those by accident, since I can't literally
check every scan ... after all, there are nearly
45,000 engineering-drawing scans right now! The net
result of this particular error was that we had a later
revision of one drawing than we actually knew about, and two
documents which we had thought were incomplete were actually
complete after all. So it's entirely possible that
some additional missing drawings are hidden amongst the
scans, and we'll only find them by chance unless somebody
steps up and does some checking. Well, that's life, I
||Added the remainder of the Apollo G&N
engineering drawings from aperture-card Box 441, plus about
the initial 80% of Box
442. Some additional updates to assembly
||Added the remainder of the Apollo G&N
engineering drawings from aperture-card Box 440, plus about
the initial 60% of Box
441. Some additional updates to assembly
drilldowns. As usual, these may still be in
process at our Internet Archive site, and hence may not be
fully available online until that processing has been
||Scanned remainder of Box 439 and initial
40% of Box 440 of
Apollo G&N engineering drawings. Some updates to
drilldowns, though not fully current yet. Note
that at the time I'm writing this, Box 439 is still in the
process of being prepared to push to archive.org, and Box
440 hasn't been fully processed at archive.org yet, so links
to them in the engineering-drawing search engine and on the
box's index page may not work for another day or so.
||Scanned Apollo G&N engineering drawings
from aperture-card Box
438 (full contents) and Box 439 (initial
15%) added. Plus ongoing updates related to the
process of trying (but not managing fully) to keep indexed
drawing titles and G&N System assembly drilldowns
current with respect to recently-added engineering drawings.
On a more-positive note:
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.
||Mike has pulled a hat-trick
by reconstructing the LUMINARY
163 and LUMINARY 173 source code. Of course,
I've also taken the much simpler step of adding support for
them to the VirtualAGC GUI program.
These were the first and second revisions of LUMINARY targeted for the Apollo 14 mission, and their memory modules were manufactured but not flown. (Instead, LUMINARY 178, the final released version, which Mike managed to finish reconstructing a few days ago, was actually flown.) So in just a few days, we've gone from having essentially nothing for the Apollo 14 Lunar Module, software-wise, to having pretty much everything you'd ever need to know!
It probably goes without saying, but beyond just their intrinsic interest on their own, having the complete set (163 & 173 & 178) further increases our confidence in the reconstruction of each of them individually. That's because the reconstruction of 163 is based on 173, while the reconstruction of 173 is based on 178. We have confidence in the reconstruction of 178 because its checksums are correct ... but there's a small though non-zero chance that an incorrect memory bank could still have a correct checksum. However, it's still unlikelier that you could modify an incorrect memory bank (from 178) having a correct checksum and somehow obtain another bank (from 173) that also had a correct checksum, and then modify that bank again to get still a third bank (from 163) having a correct checksum. Admittedly, that argument doesn't apply to all of the memory banks in the program, since not all of them needed to be reconstructed for each of these software revisions, but it applies to enough of them to give us a good feeling that the reconstruction process does exactly what we hope it's doing.
||A few more documents scraped from NTRS have
been added to the library (thanks to Hartmuth
Gutsche). I won't detail them here (just look for
icon on the document-library page),
but the one that particularly stands out for me is
Raytheon's 1969 "Final
Report: Apollo Guidance Computer Program Block I (100) and
Block II". Don't be confused by the title referring to
the "program", since the report is not about
software. The report is a nice way of getting a
pretty-detailed understanding of all the different hardware
Raytheon produced for the program, including all the AGCs,
DSKYs, and associated ground-support equipment, which is
pretty hard to get piecemeal from other documentation.
I was particularly enamored of an exploded diagram for the
Block II DSKY that I don't recall having seen before,
to the extent that I even pulled it out of the report and
added it to the DSKY page.
I'm sure there's nothing in the diagram that you can't get
already from the many DSKY engineering
drawings we have, but it may be useful for those of
you who have been working on constructing your own DSKYs.
||I've unfortunately discovered that our one
LVDC program listing does not form a complete LVDC
program. Or at least, that's the conclusion I've come
to, and until there's some reasonable independent review of
the code, I fear that my inferences are the only ones that
count. Hopefully I'll eventually turn out to be wrong.
When I say it's incomplete, I don't mean that there are pages missing from the program listing, or anything of that nature. The Flight Program listing we have is completely self-contained, and can be assembled without error ... or at least could be assembled without error if a handful of undebugged problems in this engineering (as opposed to released) version of the code were fixed.
No, what I mean is that the Flight Program was not the only program that needed to be loaded into LVDC core memory to get a complete working system. At the present time, I believe that the missing program would have been the Preflight Program. The Flight Program and Preflight Program would have interacted via certain addresses hard-coded into those programs. Unfortunately, right now, when the Flight Program calls routines that are supposed to reside at those addresses, there's simply nothing there, and chaos would ensue.
For example, I think that one thing the Preflight Program probably had was the self-test routine. Very handy! And very unhandy not to have it. By the same token, a self-test routine is hardly essential to the operation of the system, and it might be possible to make the Flight Program happy simply by sticking some kind of relatively-simple replacement for it at its specified hard-coded address. And all of the other problematic addresses I've seen similarly relate to code that might be painlessly worked around. But I don't have a complete survey of all the offending missing code, and can't really make too positive a claim at this point. Time will tell how serious a problem this turns out to be.
As usual, I've written all this up in more detail on the LVDC page itself.
||Lots more updates to descriptions of LVDC i/o ports and command words
transmitted to the rocket from mission control.
||Lots of changes to descriptions of LVDC i/o ports and telemetry.
||More updates to description of LVDC assembly language.|
of the LVDC assembler, yaASM.py, has been documented.
||Mike Stewart has sent in dumps of rope images
of 4 SUNDANCE physical memory-rope modules. You may
recall that SUNDANCE
306 was the AGC software for the Apollo 9 Lunar
Module, and that we have no copy of the SUNDANCE source
code, but have 3 prior dumps of physical rope-modules.
There are 6 rope modules in total (denoted B1 through B6),
so we now have dumps of every module (plus an extra dump,
which happens to be of module B3). Unfortunately, the
modules that have been dumped are from a mismatched set of
SUNDANCE revisions (292, 302, and 306), and thus don't form
a complete working SUNDANCE 306. In fact, used
together as-is, they don't form a set of ropes that works at
all. Nevertheless, it's entirely possible that one may
be able to create working software from them using judicious
reverse engineering. We'll see!
||"Final" corrections to my draft description
of LVDC assembly
language, specifically the DFW
pseudo-op. Modulo any oversights on my part, I think
the description is probably more-or-less correct, since the
new LVDC assembler produces a word-for-word correct assembly
of the AS-206RAM LVDC source code. However, given that
I haven't yet documented the new assembler itself, nor even
put the finishing touches on it, that don't expect that the
presentation of it is perfect by any means.
||Don Eyles has sent us a couple of Apollo 14
related documents, which are useful for information about
the pad loads, as well as for deducing the locations in
memory of certain variables, which may or may not assist in
the current attempt of reconstructing various AGC software
||Updated descriptions of more LVDC pseudo-ops: ORGDD, DOGD.|
||Fixed description of
various LVDC pseudo-ops: DEQS, DEQD,
USE INST, USE DAT.
||As you may have noticed in looking at the Luminary and Colossus pages, it sometimes
happens that when somebody gives us a listing of an AGC
program, it may not be quite the software revision
used in a flown mission, but since I figure we're never
going to get the exact revision I end up just shrugging and
saying it's good enough. But you know, my "figuring"
has been known to be wrong ... from time to time. Such
is the case with the Lunar Module software for Apollo
10. The actual flown revision was really Luminary 69
Rev 2, whereas the printout we got from Don Eyles was simply
Luminary 69. Does Luminary 69 work when you fly a
simulated Apollo 10 mission? Certainly, no
problem! But it would even better to have the precise
revision used, wouldn't it?
That's were some of the engineering drawings I (my sole contribution to this discussion!) scanned a couple of days ago come in. These drawings, 2021151 through 2021154, astoundingly list all of the memory-bank checksums for lots of AGC programs ... including lots of revisions of programs that we don't have. This information, which may seem rather pointless on the face of it, actually opens up the door for reconstructing a lot of software revisions we don't have. Why? Well, we do have source code for an increasingly-large number of Luminary and Colossus software revisions, and we often have LUMINARY Memos or COLOSSUS Memos that tell us in a descriptive way which changes were made between successive revisions of the software. This is especially true for Luminary. Thus from the descriptions of the changes, we can attempt to back-port those changes (as observed in later revisions of the software) into earlier versions of the software and then check if those changes produced the proper memory-bank checksums! We've done this in the past in the handful of cases where we knew the checksums of unavailable software revisions, but we never had such checksums for a large number of missions to work with before.
In the case of Luminary 69 Rev 2, Mike Stewart has stepped in and reconstructed it overnight, using exactly the method described above. Thanks, Mike, once again! So while yesterday we had Apollo 10 LM software that was "close enough", today we are pretty sure we have the exact software used in the mission.
||Added a handful of notes on lunar descent,
and particularly delta guidance, to the
document library. I won't itemize them
individually here. Just look for the icon.
||The scan of the assembly listing of the LVDC
AS-206RAM flight program is now ready. Or at least, a
perfectly legible scan is ready, though I may make a better
one later. I've actually been taking this opportunity
to try out different digitizing methods, so I've scanned the
thing 4 times so far. That's because I've been very
dissatisfied with the AGC listings I scanned in the past,
and I wanted to perfect my method once and for all.
But because I'm experimenting, the scans aren't quite as
pretty yet as I'd like. Getting better, though.
As I explain in more detail on the LVDC page, we are not certain yet about the ITAR status of this assembly listing: Maybe ITAR restricts who the program can be given to ... and maybe it doesn't. I kind of think it doesn't. I hope we'll eventually find out for sure that it doesn't, and I'll then be able to post the scans online. Unfortunately, until/unless the legal issue is resolved, it's a close enough call that I'll have to assume by default that ITAR does restrict access. So if you want the scanned program listing, you'll not only have to
I've also done a preliminary pass on looking through the listing and have written up all my observations and inferences about the the syntax and pseudo-operations of LVDC assembly language, as well as about the AS-206RAM program itself. That's a prerequisite for getting a working LVDC assembler, which along with transcribing the listing's source code is hopefully the next step. (And no, sorry, once I have transcribed the source code, it won't be freely distributable either until ITAR questions are resolved for the better.)
||The full assembly listing of the 1967 LVDC
flight program mentioned over the course of the last week or
so has suddenly and unexpectedly become available.
Page-image scans haven't been prepared yet, but this
availability has necessitated quite a few changes in the LVDC page, as various
speculations have suddenly been converted either to facts or
fantasies. Obviously, many additional relevant changes
are expected in the year future.
||I've added still more flesh to my inferences about the LVDC assembly listings. I have, however, noticed some holes in my descriptions of whole-line comments and of how SIMPLEX vs DUPLEX memory works, so its clear that not all of what I've written is 100% correct.|
||A handful of additional source-code pages
1967 LVDC flight program mentioned yesterday have been
added. Alas! All things considered, they've
added more to my confusion than they've subtracted.
||Added CAD transcription for drawings 2005938C
(electrical schematic for most Block II AGC rope-driver
modules) and 2005930A (clock oscillator module for several
Block II AGC configurations).
||Finally finished updating all of the
assembly-drilldown support for the engineering drawings
added last week, and specifically for the Block II
IMU. In other words, all engineering-drawing support
is now up-to-date again, until I bring in a new batch of
scans in a few weeks.
||Updated all drawing titles for the scans
added yesterday, so that they correspond to the actual title
blocks of the drawings rather than to abbreviated titles
from the aperture-card metadata on the index pages and in
the engineering-drawing search engine. Some (but not
yet all) assembly-drilldown support was added for
the new drawings as well. The new drawings, by the
way, relate somewhat to the CDU, but largely to the
IMU. The total number of engineering-drawing scans is
close to 22,000 now.
||Some work done on adding engineering-drawing
scans from NARA SW aperture-card boxes 466 (final 4/5 of
box) and 467 (initial 1/3 of box). This is work in
progress and not yet completed.
||Added the electrical CAD transcription for
drawing 2010094-, which is the READ COUNTER MODULE of
apparently all Block II Coupling Data Units (CDUs). In
other words, it is our first CAD transcription of a G&N
schematic not for the AGC or DSKY. It's a real
monster, too, at least in terms of physical size, 130"×34",
though that's mainly because they didn't choose to split the
drawing into multiple sheets, even though physically it
consists of 4 separate, almost-independent
"quadrants". Go figure!
If you've never given the CDU any thought — and I know I hadn't! — it's interesting and eerie the way it shadows the AGC design. In particular, it consist of "modules", plugged into a backplane, with each module being either a regular analog circuit or else a "logic-flow" circuit consisting entirely of NOR gates. I suppose it's reasonable that once they had a design paradigm they'd probably stick with it, but it's still fun to see. The CDU itself converts data from whatever forms it's available in the spacecraft to whatever digital format the AGC needs, and vice-versa, so you can think of it crudely as a set of A/D and D/A converters ... but from an era where such things didn't just come off-the-shelf but had to be designed and implemented anew with each project.
But it's also based on a circuit-design practice that we associate only with Block I and early Block II. For example, the schematic shows no pin numbers for the NOR gates, nor distinguishes between the "A" and "B" gates of the dual-NOR-gate chips. For that information you have to look at an entirely separate drawing, the so-called "signal wiring" diagram. That design practice fortunately fell out of favor quickly in the AGC schematics (thank heaven!), but unfortunately persisted to the very end in the CDU schematics ... or at least in the CDU READ COUNTER MODULE. As a result, I can't claim total confidence of the NOR-gate pin numbers used in the CAD transcription, due to the difficulty of proofreading them; on the up side, though, probably nobody will ever notice if I didn't get some of them quite right!
||A couple of problems have cropped up with the
process building Virtual AGC from source:
discussion of "signal wiring diagrams" had to be
modified slightly for the case of CDU logic-flow diagrams,
and I took the opportunity to make the description easier to
use during the actual CAD-transcription process.
||For maintainability reasons, some general
information about the scans of the G&N engineering
drawings that had been duplicated on each of the
engineering-drawing index pages has been removed from them
and put in a
centralized location on the electro-mechanical page.
Plus, the Internet Archive has finally finished its
processing of drawing-box 465, so all of the hyperlinks to
the drawings should now be working.
||As far as I know, the engineering-drawing
indices, search engine, and G&N assembly drilldowns are
now 100% up-to-date with respect to all so-far-collected
drawing scans, and in particular with respect to the set of
drawings added a couple of days ago. Unfortunately,
the so-called "derive" operation that the Internet Archive
uses to process these drawings has not yet
completed, so hyperlinks into the latter portion of
aperture-card box 465 may not yet be functional.
(Links into box 466, on the other hand, are okay.)
Hopefully it won't take too much longer for the hyperlinks
in box 465 to become available. At any rate, at last
count the collection of engineering-drawing scans stands at
||Aperture-card scans for the final 90% of Box
465 and the initial 20% of Box 466 added on a trial
basis. (Processing not completed yet at archive.org,
titles not fixed yet in drawing index/search, not all
assembly-data entered yet, etc.)
||Once again, lots more updates to the G&N
assembly drilldowns. I'm almost up-to-date
with all of them, but there's still a tiny bit left to do.
Corrected my misspelling of Tim Good's name. (D'oh! It's a short name, so it seems like it would have been easy enough to get right the first time.)
||Lots more updates to the G&N assembly
drilldowns, along the lines mentioned a couple of days
back, I think the Block I drilldowns really are
up-to-date with respect to the drawing collection we have so
far, but that there's still quite a bit of catching up to do
for Block II. On the other hand, that's what I said
about the Block I drilldowns before, so time will tell.
||Some of the textual formatting the
engineering-drawing search engine does in showing its
results has been pepped up some of the new types of drawing
numbers (like Grumman and MIL).
||I've completed all of the assembly-drilldown
support for the new box 464/465 drawings, though there are
undoubtedly bugs in the drilldowns that still need to be
detected and fixed. With the box 464/465 additions, we
now have around 17,500 Apollo G&N engineering-drawing
scans. Next batch ... a couple of weeks from now.
||All of the drawing titles in the recent scans
for aperture-card boxes 464 & 465 are now fully updated
(i.e., they now correspond to the drawing title blocks
rather than the punches on the aperture cards) in the
drawing search engine, the drawing index pages, and the
drawing drill-down pages. Those new drawings, by the
way, turn out to have been primarily for the SCT (scanning
telescope), SXT (sextant), and ground-support equipment
(GSE) like the AGC's computer test set, calibration cart,
and so on. I have also progressed further with the
assembly drilldowns for that stuff, though since the
drilldowns only cover the on-spacecraft G&N systems, I
mean that there's a lot of new drilldown material for stuff
like the SCT and SXT but there is presently no support
whatever for any GSE drilldowns.
||Lots more updates of indexes and assembly
drilldowns related to the ~1900 engineering-drawing scans
from boxes 464/465 added yesterday.
||Partial update with respect to the
completion of scans for aperture-card box 464 and the
beginning of box 465. I.e., some stuff related to
those boxes works and some does not yet.
||Added electrical CAD transcriptions for
drawings 2005934A and 2005942-, though stupidly (on my part)
it turns out that I was confused and didn't realize that the
latter isn't actually used in any of the major assemblies
I'm providing drilldowns for.
||Added links to the AGC/DSKY/G&N
engineering drawings for all missions on the Luminary and Colossus pages. I was
unable fill in the Apollo 1 engineering drawings on the
Colossus page, because with the current information there's
no way to narrow it down to less than a half-dozen or so
configurations. Perhaps after more revisions of the Block I
drawings are scanned, I'll be able to narrow it down a lot
||I realize I've been somewhat lax about
linking in relevant engineering drawings on some of the web
pages that could actually benefit from them, in particular
the Block I and yaDSKY pages, so I've fixed up
those pages somewhat. In some roundabout fashion, that
also rubbed my nose in a couple of DSKY assemblies I forgot
to provide enough info to drill down, so I've fixed them as
well. Comments have also been added to the yaDSKY page
concerning using the engineering drawings for very accurate
recreations of DSKY physical dimensions, coloring,
brightness, and so on. Gene Dorr (thanks, Gene!) has
created an authentic font for DSKY lettering from the
engineering drawings, and thus his font has been linked to
the explanations. Lots of new mil-specs related to
visual DSKY authenticity have been provided as well.
Apollo G&N assembly drilldowns have now been
proofed and corrected. That's not to say that they're
100% perfect, though, since even after laboriously proofing
the part lists ("FIND" tables) about 400 assemblies, I still
managed to find an error in the drilldown of the very first
assembly I looked at! Well, that's how these things
go, I suppose. Even in spite of that I'd say the
drilldowns are now probably pretty reliable with respect to
the engineering drawings we've been able to collect so far,
and hopefully whatever remaining problems there are won't
cause too much pain.
new Apollo G&N assembly drilldowns that I
mentioned in my previous note have now been completed, and
have been fleshed out with lots of mil-spec parts as
well. I've chosen to go ahead and simply remove the
old manually-created drilldowns ... not that they had
nothing to offer, but I don't think they had enough to offer
to justify the added confusion of the presentation.
Both the old and new drilldowns had some errors with respect
to each other, but neither seemed to be obviously better in
that respect. It will be some time before I'm able to
fully debug the new drilldown.
||I haven't made many changes the last couple
of weeks because I've been drastically revamping the
way the electro-mechanical page displays the hierarchy of
engineering drawings. I won't bore you with
details, except to say that generation of this hierarchical
representation is now automated, whereas before it was
entirely manual, and that this will have (and already does
have) tremendous advantages. There is still a lot of
stuff to check (and presumably fix!) in the new
representation, and in particular the Block I data is very
incomplete. Nevertheless, I've decided to take it live
rather than to keep dragging my feet on it. The older,
manually-generated presentation continues to be provided as
a fallback, and will remain until the new presentation firms
up a bit. The presentation-generation software may
also be useful to some users, particularly if they need to
have part-count data, since the software outputs JSON in
addition to HTML. Moreover, there's a comparison
program that can compare two different assemblies, given
The new representation appears to have a lot more missing drawings in it than the old one does, but that's a bit misleading. Many of the missing drawings are SCDs or drawings for G&N components we just haven't been collecting until recently, and therefore the gaps will hopefully fill in significantly as the effort of scanning the engineering-drawing microfilm at NARA SW proceeds. Naturally, they'll never fill in completely.
||It turns out that there have been serious
problems in the top-level AGC and DSKY part numbers for the
LM that I had listed in my big
AGC/DSKY drilldown table. Hopefully those
problems are fixed now, but there is still work to be done
on checking the CM portion of the table. This fix has
the side effect of adding drawing-drilldowns for several
AGC/DSKY parts for which that wasn't previously
possible. Additionally, though, it has been determined
that all of the Block II AGC part numbers previously missing
from the table due to a lack of drawings are really related
to parts with available drawings via external
changes to the AGC rather than internal ones. This has
provided the opportunity to add drilldowns for all of those
previously-missing part numbers as well ... at least
A side effect of these problems was that on the yaDSKY page of the website, the mission-by-mission arrangements of the DSKY indicator lamps and their colors that I posted yesterday also had errors, because they were based on the wrong DSKY part numbers. That has been fixed, with the result (not too surprisingly) that the Apollo 12 LM did have the same indicator lamp arrangement as the other missions, rather than a different one as I claimed yesterday, and Apollo 5 did as well.
This issue with Apollo 5 is actually slightly interesting, in that it turns out there were engineering drawings both for the configurations MIT delivered to NASA and separate engineering drawings for those NASA actually installed in the spacecraft. These two configurations usually call out different AGC and DSKY part numbers. That distinction, along with some other subtleties, escaped me when creating the drilldown table. For example, MIT delivered DSKY 2003985-051 for Apollo 5 (or rather for G&N system 603 for LM-1), which has a rather funky indicator-lamp arrangement; but NASA ended up installing DSKY 2003985-081, which has a "normal" arrangement. Who knew? Well, obviously, a lot of people other than me! There are changes like that across the board, though only this one involved a change in the DSKY's lamps. Just one more reason to be careful, I suppose.
||More scans of Apollo G&N engineering
drawings (from aperture-card boxes at NARA SW) added:
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.
||The AGC/DSKY/G&N engineering-drawing
index pages I've been creating (i.e., the miscellaneous drawings page
et al.), and the associated engineering-drawing search engine,
have had some errors in the drawing titles that have been
getting on my nerves. Recall, there are presently 13K+
scans, and it's really difficult to find the errors!
At any rate, I've created a little python program to track
down certain types of obvious problems in the drawing
indices, and I've been fixing those. Mostly they've
just been trivial things like missing commas that don't make
any difference, but it did manage to find and fix 10-12
drawing titles that were previously completely wrong,
so I'm happy! I'm sure there are still other errors
that I haven't been able to find yet that will only be
detected over the course of time. I only hope I didn't
break the search engine in the process ... but it still
seems to be working for me.
||Added the CAD transcription for drawing 2005273- (Block II AGC 2003200 module A24 electrical schematics). See also the renderings of the CAD as image files.|
||The titles in the box 462 index and in the
drawing search engine (and thus all available
engineering drawings) now again correspond to those given in
the drawing title blocks rather than in the aperture-card
||The new engineering-drawing aperture-card
scans mentioned yesterday (all of box 458, remaining
half of box 461,
and first 95% of box
462) are now posted and available online, and the
links to them on the associated index pages work. The
engineering-drawing search engine
has been updated to include the new scans. However,
the titles shown in the index for box 462 or in the search
engine are still the 21-character abbreviated names from the
aperture-card metadata, rather than the full ones from the
drawings' actual title blocks. So that's something
I'll still want to fix up, hopefully in the near future.
||Added the CAD transcription for drawing 2005272- (Block II AGC 2003200 module A23 electrical schematics). See also the renderings of the CAD as image files.|
||Added a new search page for our large,
growing collection of Apollo G&N engineering-drawing
scans. Basically, you can enter a drawing number or a
search term for the drawing titles, and get back a list of
links directly to the individual scans. It's not
perfect, but it holds the promise of being a lot more
convenient that the method we've had so far of just browsing
around on a selection of overlapping drawing-index pages
until you find what you want. Check it out!
||Little problems in the
electrical CAD transcriptions of AGC/DSKY schematics
had been bothering me, such as wires that weren't precisely
vertical or horizontal, extraneous junctions (fat dots) that
were present because of tiny unnecessary wire segments, tiny
jogs in a wire, and so forth. So I created a little
program (which I cleverly call "eelint") to locate such
problems in the schematic files, after which I then went
through and "fixed" all of them. I also reran ERC
(electrical rule check), netlist generation, and image
rendering on the schematics I fixed, just to make sure I
didn't break stuff in the process of fixing it. I ran
into the slight problem that KiCad ERC had itself broken in
the meantime, so I had to wait a few days for a kind KiCad
developer to make it work for me again.
"Fixed" is in quotes earlier, because I imagine few other
people would be bothered by such trivial stuff, and probably
just think it was unnecessary grinding on my part. On
the plus side, though, KiCad's ERC capability (once it was
working again) had advanced somewhat since I had originally
run it on these schematics, so it also found a handful of
actual electrical problems for me that I was able to
fix. Thus the exercise wasn't entirely
pointless. For anyone unlucky enough to have hardcoded
some links or shortcuts to the PNG files in
our rendered CAD folder, I'm pretty sure that I ended
up changing the names of a few of those files, so you might
want to check your links. My apologies for that.
engineering-drawing index had been formatted fine for
the situation in which it was the only drawing
index, but has become inconsistently formatted with respect
to what are becoming the main drawing index tables (for
aperture card boxes 459, 460, 461, etc.). I have
reformatted it to be consistent with those other index
tables. (This is really less significant for a user of
the website and more significant for the situation I'm
in, of needing to cut-and-paste, merge, and sort to create a
master index table that doesn't explicitly appear on the
website ... but still, it is a change.)
||For the pages used to provide indices for the
drawings scanned from NARA SW aperture-card Box 459 and Box 460, I've
replaced the abbreviated, error-laden drawing titles
originally taken from the aperture-card punches with the actual
titles taken from the title blocks of the drawings. I
haven't had a chance yet to do that for Box 461,
however. I've also changed the titles of the "type 02"
documents (Configuration and Acceptance Test Requirements
documents) on the Miscellaneous
drawing index page to more-accurately reflect what
those documents are. The upshot is that the affected
drawing-index pages now correspond better to the drawings
themselves, and should thus be easier to use.
||Since we're now beginning to have engineering
drawings for G&N system components other than just the
AGC and DSKY, it's appropriate to begin adding drilldowns
into their assembly hierarchy as well ... or at least
to add drilldowns for components that someone has expressed
particular interest in. While I'm as OCD as the next
guy, and sadly probably more so, it's actually quite a lot
of work to provide these drilldowns. And since I'm
pretty work-averse, I'm probably not going to do it for too
many of these G&N components at first. For now,
I've just made the beginning steps associated with adding
support for the CDUs (Coupling Data Units) in the
not-too-distant future. The CDUs manipulate data from
the spacecraft into a format in which the AGC can input it,
and conversely to manipulate data output by the AGC into a
form in which the spacecraft can use it. Think of it
as a set of analog-to-digital and digital-to-analog
converters. In modern terms that sounds like a big "so
what?" But in the Project Apollo era there were no
dedicated ADC or DAC chips, and the CDU is a big deal.
||As a background task, I'm in the process now
of trying to scan the complete set of MIT/IL
electrical and mechanical engineering drawings stored at
NARA SW. Up to now, I have only been picking and
choosing the drawings I thought were absolutely needed, in
order to save time and effort. However, complete scans
have the advantage of overlooking nothing, and of producing
much-more-legible scans. The process will take
years. NARA SW has 1200 boxes, nominally of 2000
"aperture cards" each, with each aperture card holding a
microfilm slide of one scanned page. Only 47 of those
boxes (#431 through #477) have specifically been associated
so far with the MIT/IL G&N drawings for
Apollo. Many of the other boxes are known to be for
Grumman, NAA/Rockwell, etc. So it's unclear just how
many will need to be scanned in the end ... somewhere
between 47 and 1196. The first two of these
complete boxes, #459 and #460, have now become
available. In order to keep our web-pages containing
the drawing indexes from spiraling too far out of
control, this has necessitated a change to the structure of
the drawing indexes. Instead of a single, huge
drawing-index page such as we had previously (which had
about 5000 entries before complete boxes started becoming
available), there will now be a series of such index pages,
each relatively limited in scope:
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 2005259- (Block II AGC
2003200 scaler module A1 electrical schematics). See
also the renderings of the CAD as
image files. This is a closely related drawing
to the previously-transcribed 2005259A (for Block II AGC
2003993), so I corrected various bugs in the existing
2005259A transcription at the same time. Which is good
since I hadn't really proofed 2005259A very well,
apparently, and can now regard it as "proofed".
However, I was unable to find any differences whatever
between 2005259- and 2005259A, other than the fact that the
latter had a different revision written in its revision
block, so it's unclear to my why they felt called upon to
release revision A at all. They certainly could have
save me some bother if they hadn't bothered.
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.
CAD transcriptions of the electrical schematics for the
Block I DSKY relay modules D7-D14 have been added:
This actually completes the CAD transcription of all Block I DSKY schematics, and given that CAD transcription of the Block I AGC schematics had already been completed a couple of weeks ago, that means that I've now finished all of the Block I electrical CAD. Of course, you have to take that "all" with a grain of salt, since there's at least one known missing original drawing (later-model NAV DSKY keypad) which I obviously have not transcribed, and I haven't bothered with creating a schematic for the wiring that interconnects all of the DSKY modules. But I'm pronouncing it "done" anway.
The next goal is filling in all of the gaps in the Block II electrical CAD transcriptions. I had completed Block II AGC model "2003200" (without any specific dash number) about 4 months ago, but the state of our knowledge of the specific engineering-drawing trees for the different AGC/DSKY models was primitive back then ... indeed, practically non-existent. So the task now is to get CAD transcriptions for the drawings for all of the specific Block II AGC & DSKY models we're supporting.
The electrical schematics for drawing 2005028A (Block II AGC alarm module B8) have been transcribed to CAD. See also: the renderings of the CAD as image files. This is for AGC p/n 2003100-021 only, since all other model/dash-numbers for which we have the corresponding drawings use other alarm-module circuits from drawings 2005922 or 2005927 instead.
schematics for drawing 1006162B (Block I NAV&MAIN DSKY
decoding module D1-D6 electrical schematics) have been
transcribed to CAD. See also: the renderings of the CAD as image
files. This drawing appears in earlier Block I
DSKY models. It is unclear whether or not it applies
to later models, because we don't presently have the drawing
of the parent assembly that would tell us whether or not it
||For some reason, even though we acquired the
basic Block I electrical schematics and document ND-1021041
last year, it never occurred to me to update the Block I page with little
details like that. D'oh! I've just been spending
so much effort acquiring engineering drawings and doing CAD
transcriptions that it slipped my mind. Time sure
flies. Anyway, I've update the Block I page somewhat,
but it looks to me as though it may need a thorough-going
overhaul at some point, if/when I get the time to to so.
||Added the CAD transcription for drawing 1005730B, which contains the electrical schematics for the Block I MAIN DSKY G&N failure-detection module. As near as I can tell, this module appears only the later MAIN DSKY models, and doesn't appear in the earlier models or in the NAV DSKY at all. Of course, it makes sense that the NAV DSKY wouldn't need it. See also: the renderings of the CAD as image files.|
CAD transcriptions of the electrical schematics for the
Block I DSKY power-supply module have been added:
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.
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 the CAD transcription for the Block I
AGC sense amplifier modules B13 & B14. Different
versions of this circuit apply to different Block I AGC
variants, with drawing
1006118F (plus image files)
applying to AGC p/n 1003186 and drawing
1006187A (plus image files)
applying to all the rest. The differences between
these two, as far as I noticed, are trivial: a single
resistor value and a few extra connector pins connected to
||The electrical schematics for Block I AGC drawing 1006098H, power-supply control module B12, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
schematics for Block I AGC drawing 1006086F, erasable
drivers module B10 and B11, have been transcribed to CAD.
See also: the renderings of
the CAD as image files.
This turned out to be a bit trickier than usual because of a conundrum I ran into in the process, namely that the connector pins in the schematic are numbered in an impossible way. Literally. And having no idea what that meant, it brought me to a screeching halt, mid-transcription. I was tempted to just call it all a mistake on the original engineer's part, and renumber the connector pins as I liked in the transcribed CAD. But that strategy was a bit tricky to rationalize, since the original drawing was at revision "F" and thus had already been through multiple revisions without this problem (if it was one!) having been detected and corrected. Not only that, but the partial schematics that had been redrawn in AC Electronics document ND-1021041 agreed with the impossible numbering in the schematic, to the extent that ND-1021041 deigned to provide those kind of details. So what was happening? It was maddening! Had the spacetime continuum become not merely warped, but completely bent? Was it a sign at last that those fakers back in the 60's had slipped up, and I finally had the evidence in hand to out the whole fraudulent "moon landing" hoax as a public disgrace? Had I, indeed, finally slipped into madness or senility and needed to be carted away to an institution of some appropriate flavor where I would only be fed soft foods in perpetuity and given pills in little paper cups to be swallowed under the watchful eyes of white-coated people?
Fortunately, no. I asked for help in resolving the problem, and as it often turns out in these situations, Mike Stewart (thanks, Mike!) happened to know something that I didn't know, namely that this circuit module, of which two are used in the Block I AGC, is plugged in backwards in slot B11, even though it is plugged in forwards in slot B10. Thus the pin numbering for module B11 is the opposite of that for module B10, even though the two are physically identical. This entirely resolves the paradox.
And that, children, is how my sanity, the integrity of the Project Apollo, and indeed the entire structure of spacetime, were saved on this day, the Nones of March, in the year of our Lord (or not, if you disagree) 2019!
||The electrical schematics for Block I AGC drawing 1006061C, erasable memory stick, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
||The electrical schematics for Block I AGC drawing 1006074B, current-switching stick for erasable memory, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
||The electrical schematics for Block I AGC drawing 1006082F, driver service module B7, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
||The electrical schematics for Block I AGC drawing 1006140L, clock oscillator module B6, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
schematics for Block I AGC drawing 1006147B, rope-driver
module B32 & B33, have been transcribed to CAD.
also: the renderings of the
CAD as image files.
||A small but useful batch
of engineering-drawing scans from NARA SW was
added. Particularly useful was a much newer revision
6014999 (the index of LM guidance systems) than we had
had before, because this later revision removes all of the
guesswork (and even some literal TBDs) about the flight
models of the LM AGC and DSKY that had previously infested
the electro-mechanical page. I even had to add a
couple of part numbers (AGC
2003993-041 and DSKY
2003994-041) that I had not previously provided
drill-downs for. The whole situation for drilling down
in the LM AGC/DSKY drawing trees is far more satisfactory
schematics for Block I AGC rope strand select module,
namely drawing 1006199-, have been transcribed to CAD.
See also: the renderings of
the CAD as image files. This drawing is for the
later Block I AGC models, 1005565 and 1003700, and completes
the set of module B31 CAD schematics begun yesterday.
The fact that it was almost identical to yesterday's drawing
1006148E (only circuits 40516 an 40517 differing a bit, I
think) sped up the transcription process considerably.
schematics for Block I AGC rope strand select module,
namely drawing 1006148E, have been transcribed to CAD.
See also: the renderings of
the CAD as image files. Note that this is for
the early Block I AGC models 1003186 and 1003469 only,
whereas the later models 1005565 and 1003700 use a different
drawing for module B31 (1006199) that I haven't transcribed
schematics for Block I AGC rope strand select module,
namely drawing 1006099A, have been transcribed to CAD. See
also: the renderings of the
CAD as image files. Like all of the analog
modules transcribed so far that are based on reusable
hierarchical circuit blocks, I haven't yet adjusted the
reference designators in the child circuit blocks to
correspond to those shown on the associated insulator
drawings. When I get around to that, there will be a
script to do the job in an automated fashion. For now,
though, that means that those reference designators on the
child sheets have been chosen arbitrarily by KiCad.
However, in the PNG renderings of the CAD files, they show
up as identical to those shown on the original drawings, and
you have to actually edit those components in KiCad to find
out the actual reference designators used in the netlists.
||CAD transcriptions of the electrical schematics of interface modules A20/A40 for the later-model Block I AGCs (1003700, 1003565) can be now be found in our CAD schematics repository. There is also a folder of visual renderings of those CAD files as images. Combined with the early-model transcriptions from the 6th, I think that all Block I AGC models now have transcriptions for modules A20/A40.|
||CAD transcriptions of the electrical
schematics of interface modules A19/A39 for the later-model
Block I AGCs (1003700, 1003565) can
now be found in our CAD schematics repository.
There is also a folder of visual
renderings of those CAD files as images.
Combined with the early-model transcriptions from the 5th, I
think that all Block I AGC models now have transcriptions
for modules A19/A39.
||CAD transcriptions of the electrical schematics of interface modules A20/A40 for the earliest-model Block I AGCs (1003186, 1003469) can be now be found in our CAD schematics repository. There is also a folder of visual renderings of those CAD files as images. Specifically, these are transcriptions of drawings 1006535B, 1006009G, and portions of 1006088A. The circuitry for later Block I AGC models (1003700, 1003565) were from a different drawing which has not yet been transcribed.|
||CAD transcriptions of the electrical
schematics of interface modules A19/A39 for the
earliest-model Block I AGCs (1003186, 1003469) can
now be found in our CAD schematics repository.
There is also a folder of visual
renderings of those CAD files as images.
Specifically, these are transcriptions of drawings 1006534C,
1006087B, and portions of 1006088A. The circuitry for
later Block I AGC models (1003700, 1003565) were from a
different drawing which has not yet been transcribed.
schematics for Block I AGC module A38, namely drawing
1006551-, have been transcribed to CAD. See
also: the renderings of the
CAD as image files. This happens to be the last
of the Block I AGC logic modules (as opposed to analog and
interface modules) — i.e., all of the logic modules have now
been transcribed to CAD.
||The electrical schematics for Block I AGC modules A30-31, namely drawing 1006548-, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
||The electrical schematics for Block I AGC module A29, namely drawing 1006559D, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
||The electrical schematics for Block I AGC module A27, namely drawing 1006544B, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
||The electrical schematics for Block I AGC module A25, namely drawing 1006554-, have been transcribed to CAD. See also: the renderings of the CAD as image files. Because no signal-wiring diagram was available for the transcription, the NOR-gate reference designators and input-pin assignments were unknown and had to be made arbitrarily. But neither the electrical functionality nor the visual appearance of the schematic is affected by that problem, and it's only of interest to someone interested in duplicating the original physical layout of the electrical components of the module.|
schematics for Block I AGC module A23, namely drawing
1006545-, have been transcribed to CAD. See
also: the renderings of the
CAD as image files. Because no signal-wiring
diagram was available for the transcription, the NOR-gate
reference designators and input-pin assignments were unknown
and had to be made arbitrarily. But neither the
electrical functionality nor the visual appearance of the
schematic is affected by that problem, and it's only of
interest to someone interested in duplicating the original
physical layout of the electrical components of the module.
||The electrical schematics for Block I AGC module A22, namely drawing 1006553E, have been transcribed to CAD. See also: the renderings of the CAD as image files.|
schematics for Block I AGC modules A1-A16, namely drawing
1006540A, have been transcribed to CAD, and
cross-checked/corrected against the
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 do differ slightly, with the difference
being that one backplane signal in the ND-1021041 version
has a higher drive capacity. You
can read the writeup about the discrepancies here, if
you like. This is actually a case where the
availability of the official schematic doesn't necessarily
obviate the need for the ND-1021041 schematic, because the
latter contains a lot of information about backplane signals
that the former does not. In fact, between the two, it
contains most of the information on that
Only the pages for AGC models 1003700-051 and 1003700-071 have been updated with this information, because we don't actually have the particular assembly drawings for the other Block I AGC models that would tell us that 1006540 is the proper schematic and 1006120 is the proper wiring diagram.
By the way, this is the last of the schematics that I "recovered" from ND-1021041 prior to the availability of the true original Block I drawings, so I am now officially caught up and can begin transcribing schematics for Block I AGC/DSKY modules that haven't been dealt with yet. My final judgement on the schematics recovered from ND-1021041 is that ND-1021041 has a lot of errors in it, particularly in so far as connector pins are concerned, so it's good thing we now have the original drawings. But in spite of that, ND-1021041 is almost always correct about everything else, and is a fantastic resource when working with this material. Furthermore, most of the connector-pin errors seemed to have been the result of accidentally occasionally using pin numbers from an earlier version of the device, which is probably not a problem that would occur with the analogous Block II document ND-1021042. Only a couple of things were uncovered that I interpreted as actual electrical errors in ND-1021041, though I had only recovered 7 modules, and 7 modules do not an AGC make. So all in all, good job AC Electronics!
||As foreshadowed in the last note, I have
completed my automated comparison (using a
newly-written Python script) between the
files for Block I AGC module A33-A34 that I transcribed
from figures in AC Electronics document ND-1021041 (which
I call 1006547r), vs the
files I transcribed from the official MIT/IL drawing
1006547G. After fixing up errors in both CAD
files that I found in this process, shockingly few
discrepancies remained. In point of fact, the only
unresolvable discrepancy is that there is one NOR gate being
used as an inverter between two pins on the backplane
connector for which the backplane signal names for the input
and output differ in the two different implementations of
the CAD files ... so the process of recovering the schematic
from ND-1021041 worked quite well for this module. A
full writeup about the discrepancy has been made.
don't claim the automated comparison is perfect, of course,
but I'm happy that it found stuff for me to fix. At
any rate, I'd now consider both these versions of the
A33-A34 schematic to be checked and reasonably reliable, and
will move on the next module rather than tarrying further
with this module.
||The schematic for the Block I AGC scalar
module (namely drawing 1006547G) has been manually
transcribed to KiCAD placed into our git schematics
repository, along with the usual
PNG rendering thereof. This is the first actual
Block I schematic drawing transcribed, since the previous
Block I CAD files (including the scaler module) had instead
been "recovered" from AC Electronics document
ND-1021041. Instead of proofing the CAD transcription,
I think I'll do an automated comparison of its netlist vs
the netlist of the "recovered" schematic (which I had called
1006547r). That may take some doing, since the
reference designators and pin numbers for the NOR gates
won't match between the two, but I think it will be quite
instructive since it will both be checking the transcription
and the accuracy of ND-1021041 at the same time.
||Completed writing the
about how Block I signal wiring diagrams work on the
electro-mechanical page ... which I think finally brings the
electro-mechanical page to completion, if not necessarily
||Well, it took a while, but the electro-mechanical page
has been basically restructured from the ground up and
rewritten to both be a tad simpler and at the same time to
provide far more actual electro-mechanical information
than before. Instead of providing the electrical
drawings for a half-dozen Block II AGC/DSKY models as
before, it provides electro-mechanical drawing trees (i.e.,
electrical and mechanical drawings) for 30 or so
Block I and Block II AGC and DSKY models. And could be
made to provide quite a few more, if there turns out to be
any reason to do so. Admittedly, the drawing coverage
is not perfect, since not only was NARA's coverage of the
drawings a bit spotty, but also I had limited time to scan
them ... and wasn't helped by the fact that the government
(and consequently NARA) was shut down for the last
week. Okay, nothing's perfect!
Incomplete or not, the restructuring provides a much more useful and interesting view of the AGC/DSKY electrical and mechanical design than we had before. The electro-mechanical page is now a portal providing two main ways of browsing the set of available drawings:
All other supplemental information provided by the
electro-mechanical page is now subordinated to this basic
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
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.
||As mentioned on the note for the 15th,
there's now a
section on the document-library page for documents (as
opposed to engineering drawings) that I scanned from the
microform "aperture cards" at NARA Southwest.
This section is now completely up-to-date with respect to
all such scans. (In fact, this entire website is now
up-to-date with respect to all the scanning done at
NARA.) These documents are distinguished by the fact
that time and money pressure caused me to scan them in a
really sleazy fashion, using a portable flatbed scanner,
rather than the fancy NARA equipment, so the document scans
are incredibly poor quality. The results are very
uneven, with many pages having been digitized quite well,
but with the majority having some blurry parts, and a few
pages even being illegible. My excuse is that the
scans are better than nothing, and you wouldn't have them at
all if I hadn't done it that way. So there! Even
so, I think I'll try to improve on my method the next time I
go out for a round of scanning at NARA ... which may be a
very long time, since the government is now in a shutdown
mode that will likely keep NARA closed until 2019, when my
vacation time will be back at zero.
engineering-drawing index page has been completely
replaced by a single unified index, arranged by drawing
number. (Previously, it was a set of "batches", each
one of which was by drawing number.) It doesn't really
affect how you use it too much, but it just seems less
||I've not really been updating the website
lately, even with the huge number of drawings I've been
scanning at NARA SW every day, because I've simply been too
busy and tired out by the process. Nevertheless, I did take
the time today to update the
page about NARA (or as it's charmingly titled,
"Documentation Quest! Stalking the Wild AGC"):
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.
||The vast number of MIT/IL AGC/DSKY
engineering drawings received over the past weeks — not just
those drawings I've been scanning at NARA SW, but various
others that associates have handed me — has both overwhelmed
the main content on the electro-mechanical page
(namely, drawing trees for the electrical design of specific
AGC/DSKY models) and swamped my ability to deal with
the new drawings in any timely fashion. One thing I've
done to deal with that is to split out all of the
drawing-index Appendices formerly on the electro-mechanical
page, onto a new MIT/IL
AGC/DSKY engineering-drawing page, whose sole purpose
is to index those drawings. I've also pepped up my
ability automate the indexing process somewhat, so hopefully
in the coming week(s) I'll be able to stay abreast of the
new incoming drawings on a day-to-day basis. We'll
see. At least for now, I think I'm caught up, and the
index page is complete with respect to all available
drawings in our collection.
||I've been increasingly concerned for a number
of reasons about the way the electro-mechanical page
has been handling links into document ND-1021042, as well as
links to CAD files and the PNG renderings thereof.
Consequently, I've completely restructured that portion of
it. It should now be easier to maintain in the future
and (marginally) less confusing and easier to use right
now. On the bad side, all of the old hyperlinks on
this change-log page to the PNG files rendered from CAD will
no longer work, and I see no particular reason to fix
them. Seems like a small price to pay on a go-forward
basis. Still ... there may be some broken links to
PNGs floating around elsewhere that I'll have to find and
fix at some point.
||Apparently I managed to treat the Universe
right in my last post ... took me long enough to figure out
how to do that! I wish I had known the trick decades
Kidding aside, though, the Instrumentation Lab Block I electrical drawings I alluded to yesterday have magically appeared overnight, and I've incorporated them into our electro-mechanical page. I'm missing a couple of DSKY drawings, so perhaps I messed up when I made my shopping list and will have to try again. At any rate, what has been added is a complete set of the official electrical schematics for the Block I AGC p/n 1003700, and mostly-complete sets (missing the keyboard module) for Block I nav & main DSKYs 1003706 & 1003707. You have to take that with a slight grain of salt, since most of the drawings are actually 1 or 2 revisions off from what we were looking for; but I'm not sure how much confidence we can have that the revisions we were looking for were necessarily the right ones anyway, so that doesn't sound like a great problem. Particularly not when the alternative situation (yesterday!) was that we had none of the Block I official drawings at all. In fact, whether or not we have the precise revisions we were targeting, we have lots and lots of revisions we weren't targeting. A typical example might be that we were targeting rev G of a drawing but only got revs -, A, ..., F. Lest you doubt my word, there are over 200 such drawing scans.
At any rate, significant changes have been made to the electro-mechanical page to accommodate all of this new material:
||Added the recovered CAD drawing for 1006556
(Block I AGC module A21, "logic flow S"). Contrary to
my usual habit, I've only made the
files and haven't bothered with the PNG files, for a
reason which will become apparent in a moment. By the
way, this particular drawing turned out to be a monstrous
effort. It was split out into 23 separate figures in
ND-1021041, but lots and lots of that was little duplicated
blocks of circuitry (presumably for clarity), replete with
errors in terms of connector pin numbering ... all of which
had to be resolved. What fun!
Besides not making the PNG files for this drawing, I'm also going to pause most of the effort of recovering the rest of the Block I schematics from AC Electronics document ND-1021041 for the moment. Why? Well, because of some crazy news I got today. As you know, we don't have the official drawings for the Block I schematics, and that's why I've been resorting to "recovering" them from the blocks of circuitry in ND-1021041's figures. That's obviously not 100% satisfactory (though it's infinitely better than having no schematics at all ), because of the errors and omissions inherent in AC Electronics's redrafting of the drawings, the lack of versioning of the drawings obtained in this way, and the fact that the "recovered" drawings simply look nothing like the originals. But in theory, the recovery process should still produce a very close approximation of the original design, if AC Electronics didn't screw up too badly.
Whatever. The crazy news from today is that it looks like there's a high probability of getting the official drawings themselves in the near future, for both the AGC and the main/nav DSKYs ... all except drawing 1006545 (AGC module A23). So I'll still recover that one from ND-1021041.
Anyway, I don't want to say much more than that right now, since the Universe doesn't like that kind of thing and would probably try to queer the deal if I did. The transcriptions done so far won't be a total waste, of course, since if we do manage to get and transcribe the official drawings, when we can use the recovered drawings to do automated cross-checks of the netlists and what-not. Even so, the time spent on it is time I'm not going to be getting back, unless karma is a real thing.
||Added the recovered Block I CAD drawing from
ND-1021041 for 1006540 (AGC modules A1-A16, "logic flow
bit"). There's one module for each of the 16 bits
(including parity) in the memory/register words, each using
the same physical module, but different signals are input
and output to each of them from the backplane. Plus, a
number of internal signals are presented to the backplane
and can be wired up differently there, creating circuits
that are superficially somewhat different from what you'd
naively expect from the drawing. So while the drawing
itself is deceptively simple, it's actually quite a mess of
different types of signals and a not-necessarily-obvious
circuit topology. Plus, ND-1021041 had a number of
inconsistencies in it. In other words, the usual
warnings about how it's likely there are a lot of errors
that will have to be worked out of the drawing later, yada,
yada, yada. And the usual statement that so far I'm
pleased with it. I don't know why I even bother with
these disclaimers any more, since they're always the
schematics, and PNG renderings of the main sheet and a sheet with tables of
backplane signal names.)
||There had been 3 Block I AGC circuits in
ND-1021041's Figures for which, at first, I hadn't been able
to determine the modules to which they belonged. I
think I've now moved them into the proper modules in the AGC
1003700 section of the electro-mechanical page.
||On the electro-mechanical page, rearranged
the Block I AGC hyperlinks into document ND-1021041 so that
they're a bit more useful.
||I've had second thoughts about the scheme I
mentioned yesterday of simply using KiCad default page
templates for the Block I drawings' title blocks. I've
modified the default somewhat by including a Virtual AGC
logo and project name in the title block, along with some
other changes to slightly reduce the ugliness of the
things. Consequently, the yesterday's transcription of
Block I drawing 1006547 has been tweaked a tad.
Mainly, though , I recovered CAD drawings from document ND-1021041 for Block I AGC schematic drawing 1006552, "Logic Flow N", module A28, which corresponds roughly to a portion of Block II timer module A2. (KiCad schematics and PNG renderings of top-level sheet plus sheets corresponding to ND-1021041 Figures 4-53, 4-57, 4-59, 4-62, 4-143, and 4-181.) It went much better than yesterday's drawing, with no obvious errors in document ND-1021041.
There is a problem with the Block I transcriptions that I forgot to mention yesterday, though, in that ND-1021041 doesn't always list backplane signal names in its schematics when the connectivity is obvious from the drawing, so if you have just the transcribed schematics, you can't deduce all of the backplane connections from it. I'm currently assigning those otherwise-unnamed connector pins with names like PM_N, where M is the module number and N is the pin number. I supplement that scheme by maintaining a connectivity database as I go along that tells which of the PM_N pins are connected to which other PM_N pins. For example, pins P33_65 and P33_77 in module A33 are connected to pin P34_53 via the backplane.
Eventually I'll eliminate the PM_N names entirely, by assigning unique but logically-reasonable or arbitrary names to those as-yet-unnamed backplane nets. That's simply not too convenient at this stage. For now, for drawings I've already transcribed, the files pinsBlockI.txt and connectionsBlockI.txt in our github repository can be used to get lists of block I backplane connector pin names and of backplane nets that aren't yet obvious from the pin names. Fortunately, there aren't too many of them, percentage-wise.
Finally, as an afterthought , I've added the CAD transcription for Block I AGC drawing 1006549, "Logic Flow J", module A26. (KiCad schematics and PNG renderings for the top-level sheet and for sheets corresponding to ND-1021041 Figures 4-61 and 4-181.)
||I've "recovered" or "regenerated" my first
first draft of a Block I AGC schematic drawing, namely
drawing 1006547, "Logic Flow G", modules A33 and A34, which
corresponds roughly to the Block II scaler module A1.
By "recovery", I'm referring to the fact that we don't have
a copy of any of the revisions of the official drawing
1006547, but we do have AC Electronics document
ND-1021041. ND-1021041 seemingly contains the entire
Block I AGC schematics, but redrawn and grouped logically
across a large set of Figures. For example, all of the
schematics for drawing 1006747 seem to be in Figures 4-59,
4-153, 4-165, and 4-181.
There are pluses and minuses to this recovery process. For one thing, ND-1021041 is far more legible than any of our scans of the official AGC schematic drawings. On the other hand, though these schematics are functionally identical (hopefully!) they are by no means visually identical to the originals, so it still leaves us without a clue as to how the originals actually looked. Nor does ND-1021041 have any of the original notes from the drawings, nor the parts lists that usually appeared as tables in the originals. So I've eliminated certain visual conceits in my transcription, such as no longer adding Instrumentation Labs borders or title blocks to them.
And frankly, if my experience so far is in any way representative, ND-1021041 introduced a lot of drafting errors that were not present in the original drawings. Consequently, these "first drafts" are more "drafty" than we're used to , and it will take longer to wring out the errors from them. Though once I've recovered enough of the logic modules to perform Verilog simulations of the logic — i.e., to run Block I software on the simulated electronics — we can obviously start to feel good about the process; but that's somewhere in the distant future right now. Fortunately, a lot of drawing 1006547 should be simulable in a stand-alone fashion, though I haven't done it just yet.
With that said, I'm pretty pleased with this very first drawing. As usual, we have the KiCad schematics, along with PNG renderings of them: top-level sheet, and sheets roughly corresponding to ND-1021041 Figures 4-59, 4-153, 4-165, and 4-181.
||Added transcription of drawing 2005012B
(fixed memory module B1-6 for all AGC models). The
schematics are here, and we also have PNG renderings
from the CAD for the drawing (sheet 1 and sheet 2). I
don't mind telling you that transcription of this one was a
real pain. On the other hand, it's nice to have a
drawing that's actually legible, so that you can get a sense
of what the module is actually doing, rather than just
wondering if you're going blind. This is a
significant milestone, though, because
Sweet! Admittedly, this CAD transcription might benefit from a good proof-reading of the PNG renderings vs the original scans. (Volunteers?) And simulation of some of the the analog circuitry (such as the power supply and oscillators) with some variant of Spice might be nice. In fact, there's no end of extra work that could be done on it. The complete story, as usual, is on our electro-mechanical page. But I think it's pretty swell anyway.
That's not the end of the CAD-transcription story, of course, in that there are two other versions of the Block II AGC with schematic drawings remaining to be transcribed or regenerated, plus the Block I AGC, plus intermediate revisions of the schematic drawings, plus mechanical drawings. May take a while.
In an unrelated development, the comments about the AGC's integrated-circuit usage on the electro-mechanical page have been tweaked to account for the Block I AGC's NOR-gates, as well as sense-amplifier integrated circuits.
||Added transcription of drawing 2005106-
(erasable memory module B12 for AGC 2003200). The
schematics are here, and the PNG rendering is here.
||Added transcription of drawing 2005100D (rope
driver modules B16-B17 for AGC 2003200). The
schematics are here; as is usual for these last few
modules, there are separate PNG renderings for visual
correspondence to the original (sheets 1 and 2) and for electrical
sheet and circuit blocks A, B, C). This is
kind of a milestone, in that all of the AGC (2003200)
modules have been transcribed to CAD other than B1-B6 and
B12, which are the modules that really consist only of
ferrite cores. I'm not sure it makes much sense to
transcribe those anyway, though in a slavish, compulsive
fashion I'll undoubtedly do so, so I'll just hold off for a
while on declaring a true milestone.
||Added transcription of drawing 2005924-
(strand select module B15, for AGC 2003200). The
schematics are here; there are separate PNG renderings
for visual fidelity (single
sheet) vs electrical properties (top-level sheet and
circuit blocks A,
||Added the transcription of drawing 2005104B
(erasable driver module B9&B10, for AGC p/n 2003200)
into CAD. The
schematic files are here. It proved impossible
to make a single transcription that was simultaneously a
good visual representation and an electrically valid
representation of the original drawing. Therefore, two
separate transcriptions were made, one intended to be
visually accurate, and the other intended to be electrically
valid and accurate. The KiCad projects for both
(original.pro and module.pro, respectively) are at the link
just given. PNG files for both the original visual
(sheet 1 and 2) and the electrical
(top level, circuit
blocks A and B) are also
||Drawing 2005922- (alarm module B8, for AGC
p/n 2003200 — or at least, a very close revision to the
desired 2005922A) added. KiCad
files and PNGs (sheets 1, 2, and 3) all available.
||Drawing 2005003E (oscillator module B7, for
AGC p/n 2003200) has been transcribed to CAD. The
drawings are available, as well as PNG printouts of
its sheets 1, 2, and 3.
||Drawing 2005916A (power-supply modules
A30-A31, for AGC p/n 2003200) has been transcribed to
drawings are available, as well as PNG printouts of
its sheet 1 and sheet 2. With
this drawing now available, all of the A-modules for AGC
2003200 have now been transcribed to CAD. Next, the B-module
||Similarly to yesterday's update, I added
links into document ND-1021041 for the module electrical
schematics for the Block
main-panel DSKY and navigation-panel
DSKY. All of these lists of link are only
positioned temporarily, until I can move them into the
document-index Appendix of the electro-mechanical
page. Luckily, this gave me the opportunity to fix a
problem with the descriptions of the Block I DSKYs on the
electro-mechanical page, in that the drawing lists for each
of them indicated that there were 18 circuit modules
(D1-D18), whereas the photographs only showed about half
that many modules, with no obvious spaces where many more of
them could be hidden from view. Well, it's now clear
that 9 of the modules listed were only for the main DSKY
(D4-6, 11-14, 16, 17), and other 9 were only for the NAV
DSKY (D1-3, 7-10, 15, 17). I've fixed my drawing lists
accordingly. Problem solved!
the Block I AGC (model #1003700) section of the
electro-mechanical page, I've added links into
document ND-1021041 for each of the module electrical
schematics. There are probably errors to fix, and the
info will probably be reorganized later on, but for right
now at least, it's a big help in trying to understand any
given Block I AGC module is for. It will certainly be
a big help later on when trying to create CAD schematics for
the various drawings comprising AGC 1003700. I've not
yet done the corresponding indexing of the Block I DSKY
||Added CAD transcription for drawing 2005268A (electrical schematics for AGC module A18) to the electro-mechanical page: CAD files, PNGs generated from CAD (sheets 1 and 2), vs the original scans (sheets 1 and 2).|
||Added CAD transcription for drawing 2005267A
(electrical schematics of AGC module A17) to the
electro-mechanical page: CAD
files, PNGs generated from CAD (sheets 1 and 2), vs the original
scans (sheets 1
||Added CAD transcription of the electrical
schematics for the AGC interface modules A27/A38/A29, namely
drawing 2005912B. This is for AGC p/n 2003200, but is
likely essentially the same as for the flight AGC
here, plus PNGs (main
page, circuits A,
D, P, R, XT, Y), vs the original
scans (sheets 1
that what I call the "main page" of the CAD corresponds to
sheet 2 of the original drawing, while sheet 1 original
drawing is split into 6 separate CAD drawings of
||Added CAD transcription of the electrical
schematics for the AGC interface modules A25 & A26,
namely drawing 2005021C (but for AGC p/n 2003100 and
2003200, rather than the flight AGC 2003993): CAD
here, plus PNGs (main
page, circuits XT,
P, D, C, R), vs the original
scan. This is an interesting design relative to
the drawings I've been adding so far, in the sense that
those prior drawings all provided a "flat" design, whereas
today's is purely hierarchical. In other words, even
though the prior drawings may have consisted of two or three
sheets sometimes, that was really only due to the fact that
the design was simply too big to fit on a single page, so
the designers split it up into more. If you had a big
enough piece of paper, you could have stuck the stuff on all
those sheets onto the one large page with no other
change. With the interface module, however, the design
uses 5 smaller subcircuits, represented by separate CAD
files that appear over and over again in the main
circuit. For example, the "P" subcircuit appears more
than 10 times, while the "C" subcircuit is used over 30
times. Unfortunately, that added complexity causes the
CAD design to look not quite as similar to the original
drawing, but it still is a pretty fair visual approximation.
||Added a CAD transcription of the electrical
schematics for AGC module A16, namely drawing
here plus PNGs of sheets 1 and 2, vs the original
scans of 1
suppose I should have been providing similar links to these
notes for all of the CAD drawings I've been adding
over the last few weeks, but it didn't occur to me.
I'll try to remember to add them for future drawings, but
for those already added to the
electro-mechanical page, I'm afraid you'll just have
to rummage around to find them if you're interested.)
||Added the CAD transcription of module A14, in
the revisions appropriate for both AGCs 2003993 and and
2003200. They differ, as far as I can tell, only in
the captioning of a single connector pin. However, the
2003200 revision of the drawing (namely, drawing 2005264A)
is quite blurry in the scan, and could stand being checked
vs drawing 2005264- (whose scan is quite
sharp). I didn't do that, because I didn't
notice at first that we even had a copy of 2005264-, but I
did compare it to the also-sharp scan of 2005064F.
||Added the CAD transcriptions for the AGC
electrical schematics for the flight version of modules A8,
9, 10, 11, 12, and 13.
If I haven't so commented before, I should mention that for these electrical schematics I've been prioritizing transcription speed — i.e., I'm trying to get a minimally complete set of schematics transcribed and online as soon as possible — relative to accuracy. So while I think the transcriptions are pretty accurate, and they do all pass KiCad's ERC (automated error check), there are undoubtedly errors in them that will only be caught in proofing directly against the scanned drawings. And I haven't done a lot of proofing on them. So, anyone who is interested in participating in such a proof-reading process, feel free to step forward. Fortunately, unlike the schematic entry process itself, it doesn't involve a lot (or any) knowledge of electronics or electronics design tools to do so, and is simply a matter of comparing two drawings side-by-side. For example, here are the original scanned drawing and the CAD-generated drawing for module A13 (click to enlarge):
A good example of the need for proofing is the drawings for modules A8, A9, A10, and A11. These drawings are so similar to each other that only A8 was actually transcribed, while the drawings for A9-A11 were merely adapted from the drawings for A8. This sped things up a lot, sure, and it eliminated a lot of potential errors ... but it also masked various other types of potential errors by making it very hard for me to see them. Proofing will be so important!
As far as the "minimally complete" set of drawings is concerned, I'm referring to AGC p/n 2003200-011 and DSKY p/n 2003950-011, since this is the combination of units for which we can most-plausibly say that we have the exact revisions of all the drawings we need. Earlier and later AGC/DSKY part numbers will follow, and (I think) will all arguably be close enough to being complete drawing sets as desired for any practical purpose, but not in the mindlessly-obvious sense that 2003200/2003950 is complete. The reason my earlier comments (below) refer to all of the CAD drawings being added as the "flight version" even though they're for AGC 2003200 is that many of the drawing revisions for AGC 2003200 really are identical to the drawing revisions for AGC p/n 2003993 (the flown AGC p/n), and the ones added so far are among those. But eventually there will be some drawings added that are close to the flown revision without being 100% identical to them.
||Added the CAD transcriptions for the AGC electrical schematics for the flight version of the A7 module.|
||Added the CAD transcriptions for the AGC electrical schematics for the flight version of the A6 module.|
||Added the CAD transcriptions for the AGC
electrical schematics for the flight version of the A5
||Began the process of adding links to the
Handbook index to the relevant figures in the various
AC Electronics manuals (ND-1021041, ND-1021042) for AGC and
DSKY schematics. In other words, the index will
eventually have links to all available schematic drawings
from not only the AGC Handbook itself, but for Eldon Hall's
set of drawings (as mentioned yesterday), and for AC's
redrafted versions of those (or redrafted versions of
drawings we don't actually have any other access to).
The latter process is just started, and will take a while,
since it turns out to be a lot more time-consuming than I
||CAD transcription of the AGC electrical
schematics for the flight version of the A2 logic module was
added. The version mentioned yesterday was an early
prototype version of it.
||Several CAD transcriptions of AGC electrical
schematics were added to the electro-mechanical page,
versions of the A1, A2, and A3 circuit modules.
Certain portions of the electro-mechanical page were
reworked in accordance to what I've learned by working of
the circuit transcriptions.
||We now have Volume
(of 2) of AC Electronics document ND-1021041.
This document contains, among other things, electrical
schematics (as redrafted by AC Electronics to fit into the
book) of the Block I AGC. Volume 2 is coming in the
near future. From the table of contents, it seems that
Volume 2 will have most of the rest of the Block I AGC
schematics, along with those of the Block I DSKY.
Since up to this point we have had no authentic Block I
electrical schematics of any kind, and have been reliant on
John Pultorak's reimagining of them, this is a great
advance! Thanks to Ken Mortimer and the Mortimer
family for providing this to us.
||Sharp-eyed Mike has pointed out a potential
(but only potential) versioning conundrum for the model
2003994 DSKY's D7 and D8 modules. I've changed the comments for
them on the electro-mechanical page to reflect those
concerns, but don't think any more-substantive change
is warranted just yet.
||Added transcribed CAD files (and
pretty-printed image) for the electrical schematics of the
DSKY keyboard module (drawing 2005903A) to the electro-mechanical page.
||Hartmuth has also passed along 20 or so
documents he had gleaned over the course of time from NTRS,
but which we had missed out on somehow, and I've added these
to the document library page.
can just look for the ones marked on that page, since I've also
gotten rid of the icon on all docs added prior to this month,
so Hartmuth's documents are the only ones currently marked.
||Hartmuth Gutsche has gone through the tedium
entire AGC Handbook, to make it easier to find stuff
in it or to see at a glance what's actually in it, and this
index has been added to the electro-mechanical page.
Thanks, Hartmuth! I was going to do it myself, Real
Soon Now, but it turned out to much realer much sooner than
||The basis for our new electro-mechanical page,
first mentioned a couple of days back, is a notebook called
the AGC Handbook, given to us by Don Eyles. This is
not so much a "document" as it is (or was) an
evolving collection of electrical and mechanical drawings
for the Block II AGC and DSKY. I'm not sure just how
many drawings are in the book, but it has around 550 pages,
and the drawings average around two pages each. So ...
a lot of drawings. At any rate, Mike Stewart
has finished scanning it, and we now have the complete thing
online. In a slight variation from our usual practice,
the document-library page of the website has been bypassed,
so a reduced-size
(170MB) PDF appears on the electro-mechanical page
instead. As usual, though, the
full-quality scans do appear on our Internet Archive page.
It is known that there was a Block I AGC Handbook as well, and presumably later versions of the Block II AGC Handbook covering later versions of the AGC/DSKY, but we don't have any such handbooks. We never heard of them before Don Eyles broached the subject a couple of weeks ago, and so never even knew to look for them. If you know of any AGC Handbooks anywhere, please let us know, so that we can try to fill in the remaining gaps in our collection of electrical schematics!
||Added to the document library page a couple
of portions of documents sent over by Don Eyles and scanned
by Mike Stewart. These are drafts of Section 3 of
volumes 1 and 2 of the AS-278 GSOP, namely the "Block II GNC
System Description" and "LEM PGNC System Description",
||Added some nice images and numerous drawing numbers
(but sadly, no actual drawings) to the Block I
tables on the electro-mechanical page.
||Various additions and corrections to the electro-mechanical page,
but mainly there were three DSKY drawings which we've
managed to locate, so the Block II DSKY electrical
schematics are much more correct than yesterday.
||The minimal treatment given previously to AGC
electrical schematics has been replaced by a much expanded
treatment on a page
dedicated to AGC/DSKY schematics and mechanical drawings.
lot of AGC schematics we never had before have been added to
it. This is just the first draft, though, so there's a
lot more work to do on this new page, and on filling in more
of the previously missing data.
||Added a favicon for the web-pages.
||Changed the website's logo to read AGC
McAGC Face. Wait ... you can probably tell by
looking in the upper right-hand corner of this page that
that was a lame joke. No, the truth is that Eugene
Dorr has designed a number of alternatives to our old logo,
which had simply been one of the NASA Apollo patches.
Several of Gene's designs stood out as clear favorites, but
in the end there were 3 that I couldn't choose
between. So in an amazingly decisive fashion, I now
have the website cycle through those 3 favorites on
successive days of the month. You can read all about
this brave decision-making process on the FAQ page,
if you're interested.
||Volume 1 of
the 1966 ND-1021042 has been added to the volume 2
provided a couple of days ago. I think this addition
is extremely important to anybody interested in simulating
the AGC at the microcode ("control sequences") level,
because our 1972 version
of volume 1 was missing the roughly 175 pages that
discuss the theory of operation of the "control sequences"
but those pages are present in this 1966 version.
Naturally, the content might have changed a little from 1966
to 1972, but I don't think you're going to find a better
discussion of the topic anywhere in our document library, or
elsewhere, at the present time. These documents came
from the Mortimer family collection (thanks, Ken!) and the
scanning at The Internet Archive was financed by Mike
Stewart and me (thanks, us!).
||Added the earliest (i.e., "no rev") version
of the AC/Delco document ND-1021042, "Apollo Lunar
Excursion Module Primary Guidance, Navigation, and Control
System Manual", volume 2, to the document
library. (Volume 1 is currently being scanned, but
won't be available for a while.) We already had a much
later (6 years later!) version of this document as well, and
the differences between the versions are significant.
What's important is that these are basically "theory of
electrical operation" documents for the Block II AGC, and so
lots of evolution in the electrical design can be
seen. What's even more fun is that this version of the
document may correspond to a specific AGC which physically
still exists and could possibly be made to function; but
that's just speculation at the moment, and so we may or may
not have more to say about it at a later time.
||Added a collection
of papers on guidance, control, and flight dynamics from a
1967 AIAA conference. At least some of them are
directly related to Apollo guidance.
III PGNCS drawings for LTA-8 to the document
library. These are basically the detailed wiring
diagrams for the lunar module, showing how all the bits and
pieces of the guidance system (including the AGC) were
interconnected. LTA-8, according to online sources,
was the first production, man-rated lunar module, and was
used for testing purposes rather than flight. The
drawings still internally identify it as a "LEM" rather than
a "LM". A later drawing covering LM-4 through LM-15
was already in our library.
||A somewhat later version of the Astrionics System Handbook,
Saturn Launch Vehicles document has been
added to supplement the earlier version already in our
document library. The newer version relates
essentially to Apollo 12, while the earlier relates
essentially to Apollo 11. Of particular interest, the
LVDC software was apparently significantly changed or even
replaced between those two missions — a fact which I either
didn't know or else had totally forgotten — and the
associated Chapter 11 of the document seems to have been
completely rewritten as a result..
||Thymo van Beers has pointed out that the
documentation for the CPU-Engine API and Backtrace API on the developer page have rotted a
bit over the years, so that the descriptions no longer
coincided exactly with the code. So I've made several
corrections to the text. Thanks, Thymo!
||The AC Electronics Block I
study guide, "G&N System Familiarization" has been
added to the document library. Unlike the companion
document added a couple of days ago, this one is much more
obviously an actual study guide. Both documents (and
more Block I documents to follow) were contributed by the
Mortimer family (thanks, Ken!); Mike Stewart and I (thanks,
Mike and me!) are financing the scanning of these docs at The
Internet Archive, where you can see the
full-resolution scans if you're so inclined.
||Added a nifty AC Electronics
study guide for Block I Guidance&Navigation Hardware
Functions to the document library. Like many
other AC Electronics docs, it's so chock-full of detailed
technical info that it might better be viewed as reference
material rather than the "40 hour" training course it
purports to be. (I think the primary justification for
labeling it as a training course is that every second page
is left blank for the student to make hand-written notes. )
This is the first of several significant documents for the
Block I AGC that we're having scanned by the Internet
Archive right now, so stay tuned for the next few weeks if
you're interested in Block I.
||Apparently, on the
COLOSSUS page, what I've been calling COLOSSUS 2B, 2C,
and 2D (for Apollo 12, 13, and 14) for the last 15 years
should really have been 2C, 2D, and 2E all along. I've
corrected that now. Yikes! What caused the error
to be noticed today is the addition of two new documents in
the document library:
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.
||Four new documents were added to the document library, most of which
are of lesser significance (from my limited perspective), so
I won't bother itemizing them; just check out the icons in the
library if you're interested.
However, one document, titled "Guidance, Navigation, and Control Lunar Module Functional Description and Operation Using Flight Program LUMINARY (Rev. 116)" (600 pages), for the Apollo 12 LM, seems quite significant. According to its preface, "The purpose of this document is twofold. The first is to provide a functional description (operationally oriented) of the LM GNCS hardware and software and the interfaces with other spacecraft systems. The level of detail is that required to identify and define telemetry outputs. Also included are function flow diagrams of the LUMINARY programs and routines together with lists of verbs, nouns, option codes, and checklist codes for this flow. The second purpose is to provide the operational procedures for this hardware and software including nominal airborne condensed checklists, malfunction procedures, and program notes."
||I got a complaint that the VirtualAGC GUI
program wouldn't fit on a 800×480 7" Raspberry Pi
touchscreen. No kidding! Well, that's part of a
larger problem with it, it appears, in that while the
program was attempting to interrogate the screen size and to
adjust it user-interface format appropriately, that feature
doesn't seem to have been working. So I've addressed
both of those problems in the latest source-code updates in
the GitHub repository. Instead of trying to make
adjustments according to the screen size, the VirtualAGC GUI
program now depends on command-line options:
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.
||Two significant documents were added to the
||A new document was added to the document
library, "Luminary 1B
DAP Preflight Performance Evaluation" (thanks to
Hartmuth Gutsche for spotting this doc for us). It's
an evaluation of the results of digital simulation of the
digital autopilot of Luminary 116 (Apollo 12). As it
happens, we already had a digital
simulation of Luminary 116 in our collection as well,
but it was from a somewhat later time and isn't the
simulation from which the report was written, presumably.
||Two new LVDC-related documents were added to
the document library, one sponsored and scanned by Mike
Stewart (thanks Mike!), and one cleverly found in the NTRS
stash by Nik Beug (thanks Nik!). These are presently
at the top of the LVDC section of
the document-library page, and I invite you to read
the descriptions there. However, the more-significant
of the two is a study (in 3 volumes), the "Flight Program
Language Requirement" document, of the feasibility of
replacing the LVDC assembly-language version of the LVDC
software with versions in 4 different programming
languages. As a part of this effort, large chunks (but
not 100%) of the pre-existing LVDC software were actually
ported to those 4 alternate languages, as well as being
flowcharted and described in detail. Thus, though this
document does not provide any LVDC code at all, it
nevertheless provides much more internal detail about the
LVDC software, in almost-usable form, than any other
documentation presently available. Unfortunately, it
is not complete enough in itself to allow reconstructing the
entire LVDC program.
||There are a couple of new LVDC-related
documents which Mike Stewart has managed to track down and
have scanned on his own dime (thanks, Mike!):
||Replaced the photo of the Block I nav-bay
DSKY on the Block I page
with a much better one.
||Added some documents to the library:
||We ended up getting a better scan of the CSM/LM
Operational Data Book mentioned yesterday.
||Added an earlier revision of the CSM/LM
Spacecraft Operational Data Book than we already had.
These books are generic, but have appendices for specific
spacecraft, and this now gives us a complete set of
appendices for the CSMs for Apollo 7-17. Specifically,
though, this new revision gives us the pad loads for the
Apollo 12 CSM, which we had not previously had.
||Mainly document additions:
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
DSKY with integrated Raspberry Pi running yaAGC that
I've mentioned obliquely a couple of times in the last few
of days, I had been asked to provide some sort of a facility
for playing back pre-scripted AGC output-channel commands
... i.e., for controlling the DSKY from a script rather than
from yaAGC, for things such as museum exhibits. So I
added a primitive recording and playback capability to that
DSKY program, which is called piDSKY2.py,
it being a Python 3 script rather than the classic yaDSKY
program. Having done that, I began to wonder where the
heck anyone would actually get a meaningful script to run on
the thing, since what you'd really want is realistic data
from an actual mission simulation, rather than something
recorded while just playing around with yaAGC and a
The answer to that, it seemed to me, was to see if NASSP could log data about AGC-to-DSKY output-channel transactions or if not, could someone add it for me? Well, Nik Beug was kind enough to not only pep up NASSP's logging capabilities to meet my needs, but also to send me the log for a sample mission segment, namely an Apollo 8 launch. So with a slight amount of work throwing together a little Python script for converting Nik's NASSP log format to the format I needed, I now had the ability to "play back" an Apollo 8 launch on the 3D DSKY. Yay, and thanks Nik! Hopefully we'll have a lot more of these scripts in the future.
Now, unfortunately, not everybody is going to be able to have one of the 3D-printed DSKYs, so my next thought was this: Why not modify yaDSKY2 so that it can play back these scripts? So ... now it can! The way it works is that if you click on yaDSKY2's PROG indicator lamp with a mouse, you get a file dialog that allows you to choose a canned script for playback. Naturally, I've added this to the introductory list of various fun things you can do with a Virtual AGC on our home page, as well as describing how to use the scripting capability on our yaDSKY page.
||A new page, DIY.html
(for "do it yourself") has been added, intended to be a
simple tutorial on writing and running your own custom AGC
programs to do stuff the AGC was never intended to do.
As if I could write anything "simple"! This is
prompted by the introduction onto the market of functional
3D-printed DSKY look-alikes with integrated Raspberry Pi
computers running Virtual AGC. It should probably be
called an iDSKY. With units such as that,
there seems to be a lot more interest in having the DSKY do
cute stuff that's not necessarily directly AGC related than
there is in pepping up the pure software simulation.
Probably because there's more of a motivation to get value
for your dollar, since the physical devices are costly while
the software simulation is entirely free. My
take on that is that it's fine to subvert the normal
functionality of the unit, but that it should be implemented
by writing programs in AGC assembly language to do it!
(Well, I have my ideas about it, and nobody is forced to
agree with me. :-) ) At any rate, this is my
attempt to encourage that. The new page is nowhere
close to being complete, but I think it has enough on it to
||An early version of the Luminary 1C
Programmed Guidance Equations document has been added to the
document library. We already had a later version of
the 1C document, as well as having the 1B document, so this
is a kind of "missing link" between them, I guess.
||For me (your own mileage may vary)
building Virtual AGC from source was failing due to compiler
warnings on the Raspbian Stretch operating system, though
continued to succeed on the (older) Raspbian Jessie
operating system. This has been fixed in the github
repository, and the Raspberry Pi build-procedure on our
download page duly updated.
||I've added some
to our developer page of a Python 3 program which can
be used as the basis for quickly creating a simple,
low-performance simulated peripheral device for use with
yaAGC. Basically, it handles the details of connecting
the peripheral to yaAGC and of parsing the information
passed between them, leaving the developer with the task of
determining what's supposed to happen to data to/from the
AGC's input/output channels. The basic motivation is
that this might be a good way to throw together physical
implementations of AGC peripherals, without having to
concern oneself with C++ or cross-platform graphical
toolkits or other complicating factors, by embedding a
Raspberry Pi in them, and running a variation of this Python
3 script on the Pi. There's also a sample Python 3
script that illustrates how to use this technique to create
a (very) simple DSKY.
||The 2017-11-12 entry below, as well as our
document-library page, previously contained the suggestion
that the SKYLARK Program Change Requests (PCRs) recently
added to the document library might have represented
a complete set of the SKYLARK PCRs that had been implemented
in the SKYLARK software. That idea is now known to be
incorrect, and so those incorrect suggestions have been
removed. The reason we know it's incorrect is that our
copy of the SKYLARK GSOP contains an appendix which lists
(incompletely) the PCRs and PCNs as of March 1972, and it
turns out that there are lots of SKYLARK PCRs and PCNs for
which we don't have the text as of this time.
Alas! At any rate, the PCR table in the document
library has now been updated with this improved PCR/PCN
||I've been going through my to-do list — i.e.,
the list of things people emailed me about and that I said
I'd take care of Real Soon Now ... but then never actually
did anything. Some are astoundingly, forehead-slappingly
old. Many, of course, have resolved themselves over
the course of time without any intervention from me.
At any rate, here's a brief rundown for some of the
particularly egregious omissions of how they've affected
this website or the github repository, in chronological
order so that you'll get some sense of my guilt:
More to come later, probably.
||The good NASSP folks have been making an
effort lately to get our AGS (abort computer) simulation
integrated into NASSP, and into checking it out, which is
great! What Ryan Callaway in particular found was that
while a lot of stuff worked, a lot of stuff didn't work
either. Mike Stewart jumped right in and managed to
find a bug I had made in the AGS simulator, yaAGS. So
Ryan now reports that it "looks like all phases of
rendezvous work as advertised in lunar orbit. I used AGS
calculations for every part and ags controlled burns as well
with RR and PGNS as backup/basis of comparison" and "the AGS
aborts the LM beautifully in both DPS and APS aborts".
Which is not to say that yaAGS necessarily is 100% perfect
now, but this one fix has improved its behavior
tremendously. For now, you have to build the software
from source if you want this fix, and it hasn't migrated
into the installer packages for VirtualAGC yet. Great
||The AGS documentation has been reorganized
somewhat for clarity (I hope!), and now appears only on the AGS page itself
rather than being duplicated on the document
library page. It was simply too irritating to
||I was recently contacted by an graphic artist
who was doing a project that involved the binary patterns
used to encode characters, specifically in the word
"APOLLO", who wondered what the appropriate binary encoding
of these characters, easily recognizable by a 1960's
engineer, would have been in the Apollo era? I told
her to use EBCDIC encoding. Then, in a rare fit of
humility, I passed the question along to Hugh Blair-Smith as
well. Hugh also said that EBCDIC was the appropriate
answer, but then speculated about a separate matter:
Is it possible to actually display the word "APOLLO" (or
more accurately, "APOLO") directly on the DSKY itself?
As you may recall, the DSKY was used to display only
numbers and blanks, but that doesn't mean it isn't possible
for appropriate software to display other patterns as
well. Alas! it turned out not to be possible; none of
the characters A, P, or L can be displayed. In fact,
we ended up tracing through the DSKY's electrical schematics
to find every possible display pattern, and those wild patterns are now
listed on the developer page. Some nice images
verifying these patterns on Bruno Muller's hardware DSKY
emulation have also been added to that page.
||I'm told that the situation for building
Virtual AGC on Mac OS X is much worse than I imagined, and
that newer Macs now provide clang as the default C compiler,
rather than gcc ... and naturally, Virtual AGC was designed
for the ubiquitous gcc and not for using clang. And
equally naturally, my own Mac is an older one that sensibly
provides gcc as it ought. Well, that's life in the Mac
world, I suppose, of which I have very little
I've added experimental clang support in the github repository (it works on Linux at least), as well as providing a method of potentially using gcc in spite of the fact that Xcode wants to use clang. Both are possible approaches to the Mac problem. I've provided documentation as to how an adventuresome soul might try out these approaches on a newer Mac.
||Note that I really only want to support
VirtualAGC on Ubuntu/Mint/Debian desktop Linux systems,
given that I don't have infinite free time or patience or
knowledge to do otherwise. Nevertheless, I
occasionally check or (or receive user feedback about)
problems on Windows, Mac OS X, Raspberry Pi, alternate
versions of desktop Linux, etc., and do sometimes make an
effort to work around those problems. Over the last
couple of days, I've gotten feedback about some such
compilation problems, and so have made some changes related
||The SUNBURST 37 AGC program's comment-text
has now been completely proofed, and is in the GitHub repo,
so the transcription effort for SUNBURST 37 can now be said
to be 100% complete. I've also updated the now-proofed
color-coded, syntax-highlighted source code on this
website. As usual, the proofing data (based on
octopus/ProoferComments) can be found in the
wiki, for anyone inclined to double-check the work.
||Added a description of Dario Kubler's
physical DSKY to the
physical-implementations page, including a cute
YouTube video. Dario sent me most of this info several
years ago, but I (stupidly!) failed to write it up; in fact,
I think he sent me several more pictures that I need to dig
out and include as well.
||The octals for SUNBURST 37 (Sunburst32.binsource)
are now in the GitHub repo, and have been proofed, and have
correct checksums, so SUNBURST 37 can now presumably be run
in the AGC simulator. (None of this is built
automatically nor integrated with the VirtualAGC GUI, so to
run it you have to create the rope file with "Tools/oct2bin
<Sunburst37.bin" and then run yaAGC from a command line
whilst specifying the rope file oct2bin.bin for it.)
We're also transcribing the SUNBURST 37 source code from the scanned program listing now, so anyone interested in helping should head over to the GitHub repo and look at the instructions.
As I mentioned in my note from a couple of days ago, instead of locally posting individual page images for SUNBURST 37 in reduced-quality JPG form, which is my normal practice for all other AGC versions, I had instead simply locally reposted the PDF from our Internet Archive collection, thinking that it was "good enough". In other word if you followed the links on our Luminary page, you'd probably end up downloading this supposedly-fine PDF. Well it wasn't good enough, so ... my apologies! The PDF has weird artifacts in which some characters were frequently replaced by other characters, such as 'D' in place of 'O'. Whatever the reason for this weird effect, it's obviously intolerable, so if you follow through the links to our locally-posted reduced-quality images now, you'll now find individual JPG pages. The high-quality images in our Internet Archive collection don't have this strange problem, and so can be used without fear, but I definitely would not recommend using the PDF found there.
As a corollary, we now realize that Emerson was wrong, and that a foolish consistency may not be the hobgoblin of little minds, if the effect of that consistency is to enforce a tried-and-true method rather than succumbing to untested novelties without having a good reason to do so.
||The program listing for AGC program SUNBURST
37 is now available, scanned for our Internet Archive
collection from Don Eyle's hoarded copy, and financed by
Peter McDermott! Thanks all. See our Luminary page.
As you may recall, SUNBURST 37 (also known as SHEPATIN 0) is an early version of the SUNBURST program, never used for any mission, though SUNBURST 120 was used later in the LM's AGC in the Apollo 5 unmanned mission. Like RETREAD and AURORA, SHEPATIN is another "missing link" in the AGC software's evolutionary development.
As usual, we'll be producing an octal file for this (so that SHEPATIN can be run in the AGC simulator) as well as source-code files (so that we can do nice searching on it, have syntax-highlighted listings, and so on), but that will be a process that takes a bit of time. Right now, all we have is the scanned pages.
I've departed from my usual practice of providing local low-resolution JPG page images here at our main website, and have instead chosen to use a PDF as the local "low quality, lower size" version of the scanned page images. (The PDF was good enough, and I didn't feel compulsive enough to insist on turning it into JPGs. As Emerson said, a foolish consistency is the hobgoblin of little minds.) As usual, though, the full-quality scanned pages are available in our Internet Archive collection.
||Added 3 more sections of the Apollo 9 LM GSOP
(we already had 1 section, out of 6 sections total), as well
as the AC/Delco study guide associated with that software
version. (Well, actually, the LM's AGC program was
SUNDANCE 306 and the study guide is for SUNDANCE 302, but
that's close enough for government work.
Literally.) All were from the UHCL archives.
Added to both the document library page and the Apollo 9
entry on the Luminary
||Two new CSM System Handbooks, and one new LM
System Handbook, from the UHCL archives. See here.
||New documents added to the document-library
page, but the most-significant is that our scan of Don
Eyles's copy of the AGC LEM PGNCS Manual (Volume II) has now
arrived. As was speculated and hoped-for in advance,
it does contain AGC Block II schematics missing from
the previously-existing set of individual schematic pages
from Eldon Hall's collection. Moreover, it contains
DSKY schematics. See here.
other words, we can now claim to have a full set of Block II
AGC and DSKY schematics. (Though not Block I
schematics so far. Perhaps in the future.)
||The second (of two) volumes of the Spacecraft
Operational Trajectory for Apollo 14 has arrived from UHCL,
and has been added to our
||I submitted our speculations (mentioned a few
days ago) to Don Eyles, about the reason the Apollo 11 and
12 digital simulations from his collection were made after
the landings. While he does not actually remember, he
agrees that our speculations about Apollo 11 are probably
right, but doesn't entirely like our speculation about
Apollo 12 ... partly, I think, because my description
introduced errors not in Nik Beug's and Mike Stewart's
original explanations to me. At any rate, I've
rewritten both speculations on the
Luminary page, in a way that gets closer to the truth
about Apollo 12 than what I had mistakenly written before.
||In the cross-platform VirtualBox VM which the
downloads page recommends for most users, the light-weight
browser (Midori) provided with the VM for examining AGC
source code and various other purposes, has been exhibiting
some anomalous behavior that I hadn't noticed before.
I think this may stem from the fact that in the VM releases
I've made so far, a fairly old version of Midori is being
used. While I'll obviously fix this in the next
release of the VM, the download page now includes the simple
instructions for updating Midori to the latest version,
which (so far!) seems to fix the problems that I've been
able to reproduce. In other words, if you have a
version of the VirtualAGC VM that uses Midori rather than
Firefox, go follow the instructions on the download page to update
||As I mentioned a couple of days ago, the
newly-added Apollo-era digital simulations of the Apollo 11
and 12 lunar landings were both made after their
respective landings ... a few days after for Apollo 11, and
a few months after for Apollo 12. The speculation was
that the Apollo 11 simulation was made to help investigate
the 1201 and 1202 program alarms experienced during the
landing, but we didn't have a speculation about the Apollo
12 simulation. Well, Nik Beug (and Mike Stewart) have
come up with a pretty-convincing explanation, namely that
the simulation was for investigating certain proposed
changes to the landing code, and the fact that it used
Apollo 12 AGC code for that was really just
coincidental. You can read more of the explanation on
the Luminary page.
||Made a number of requested improvements to
the pre-built VirtualAGC VM, as described near the top of
the downloads page. One
of the more-significant improvements is an update script
that makes it easier to update the VirtualAGC software
within the VM. This script can also be downloaded and
used with older versions of the VM, as
||Two more lunar landing simulations, both from
Don Eyles's personal collection and financially sponsored by
Matthew Fite (thanks, Matthew!), have now
arrived. As usual these days, these have been added to
our Luminary page, and you can either view them there in
convenient PDF form,
our Internet Archive collection. Both simulations were made slightly after the landings themselves.
||Another nice document from the UHCL archives,
this time Delco's manual for the Block II Command Module
guidance system. We already had a fraction of a
corresponding Block I document, but this one is about 20×
larger than what survived of the Block I document, so it's a
bit more useful. Here's a direct link so you don't
have to pore over the Document Library page to find it:
||The "Programmed Guidance Equations for
Skylark" document, divided into parts for size reasons,
obtained from the UHCL archives, has been added to the
document library and Colossus pages. This document is
specific to Skylark 48, which we currently believe is the CM
AGC program used for Apollo-Skylab (and possibly for
Apollo-Soyuz, though we really don't know). Since we
don't actually have any source code for Skylark so far, and
since the "Programmed Guidance Equations" are a kind of
pseudo-code description of the source code, I guess this is
the next-best thing to having the Skylark program
itself. At any rate, here's a direct link:
The "Programmed Guidance Equations for Colossus 3"
document, divided into 3 parts for size reasons (Part
3), scanned from the University of Houston Clear
Lake archives, has been added to the document library and
||Fixed a few more crummy hyperlinks on the
document library page.
||Lately, there has been some confusion as to
whether the Luminary 99 source code we have been providing
is actually the code that flew in the Apollo 11 LM or not,
due to AGC developer Jim Kernan's recollections that there
are three different revisions of that particular code
(Luminary 99, Luminary 99 Rev 1, and Luminary 99 Rev 2), and
the only version we actually have is Luminary 99 Rev
1. Well, on the balance of the surviving evidence,
what we currently believe is that Luminary 99 Rev 1 did
indeed fly in Apollo 11, but also that Jim's recollection is
correct and that there's a Rev 2 that is "better" in a
certain way, but which didn't fly. But we have no
physical printout for Rev 2.
The explanation is that the ephemeris data in Rev 1 is wrong, but not very wrong, and certainly good enough for a lunar landing. Nevertheless, we know what the correct ephemeris should be, because it's identical to Apollo 12 and 13, so to celebrate that fact, we've artificially recreated Luminary 99 Rev 2 for you, as a mashup of 99 Rev 1 and Luminary 116, and we provide both Rev 1 and Rev 2 for you. You can view the source code or simulate either one to your heart's content. You can take your pick. It's called "choice", friends! We've named Luminary 99 Rev 2 "LUM99R2" in the GitHub source tree, because that's what Jim's story says he called it, way-back-when.
We have also received new information about where a program listing for Comanche 44 exists. Comanche 44 did not fly on a mission, but Comanche 45 Rev. 2 (which is 2 months younger) flew in the Apollo 10 command module, so if we can get our hands on Comanche 44 some day, it may be the closest thing we'll ever have to Apollo 10 Command Module software. At any rate, the Colossus page has been updated with this info.
||Don Eyles has squirreled away ~200 "LUMINARY
Memos", out of the ~250 such memos that are known to
exist. These are documents that the MIT
Instrumentation Lab used to track the development of the
Luminary software. Don has scanned around half of
these for us so far, with the other half presumably
forthcoming within the next few months. To handle this
vast glut of incoming documents, I've given them their own section in the
document-library page. There's lots of notable
stuff there, but what stands out for me are:
||A number of new documents for the document
library were added. Highlights are:
|2017-02-10||Added a cool document to the document library, "LM Rendezvous Procedures, G Mission" by Grega and Neily, which should be very useful for anyone wanting to fly simulated G or H missions, and likely J missions ... i.e., Apollo 11-17, though 11 and 15-17 are the only ones of those for which we have both the CM and LM software at present, and hence the only ones for which you could presently do a rendezvous. Thanks to Clark Neily for sending this! Even if you're not interested in rendezvous procedures, check out the document's title page for a real hoot. More material related to this topic will be forthcoming in the near future.|
|2017-02-07||A very significant LVDC-related document has been added to the document library, namely IBM's "Saturn Instrument Unit LVDC Equation Defining Document (EDD) for the Saturn IB Flight Program", divided into 7 PDFs due to its size: 1, 2, 3, 4, 5, 6, 7. Thanks to Riley Rainey for acquiring this, and the University of Alabama Huntsville's M. Louis Salmon Library for making it available at the U.S. Space & Rocket Center archive.|
||As I mentioned a few days ago, our scan of
the 1971 simulation of the Apollo 11 landing leaves somewhat
to be desired in terms of the readability of the text ...
it's just too light for comfortable reading, because the
printout was too light. Thus, to compensate for that,
I had provided a highly-processed B&W PDF that is
much-more readable. Well, I've now done some
additional processing on the color images, to enhance the
readability to the best of my admittedly-meager abilities,
so I've posted the reprocessed color
images as an additional alternative. They're not
uniformly good, but I think they're an improvement over the
full-resolution scan at archive.org.
||All sponsorship opportunities for the Don
Eyles's scannable materials offered so far — there
are other, smaller docs remaining, but they aren't cataloged
yet — are now taken. So if you were keen to help with
that ... too bad! I like to think there will be more
opportunities in the future. And it's great news.
I've accordingly removed the giant Volunteering Opportunity note that had been stuck at the top of the home page, though you can still read all about it if you like.
||As you may have seen in the notes made here
over the last few months, I have been in the process of
proofing and correcting the comment text in the various
source-code transcriptions we have made of the AGC program
listings available to us. Hitherto, we had no
efficient way to do this, but had developed a tool for doing
so that worked quite well on most of the of program
listings, with newer scans tending to work much better than
older ones ... hence in doing this proofing, I found myself
working backward in time, progressing from the latest AGC
scans to the earliest, finally reaching the original
scans with which the Virtual AGC project started, namely
Colossus 249 (Apollo 9 CM) and Luminary 131 (Apollo 13 LM),
as well as the somewhat-later Artemis 72. The scans
(or the associated printouts from which the scans were made,
or the destructive OCR processing done on them) for Colossus
249 and Luminary 131 are so bad that the "efficient"
proofing tool cannot be applied at all, while Artemis 72 is
highly questionable. Thus, a different and more
time-consuming proofing process was required.
I have just completed proofing Colossus 249, and the results are available in GitHub now. What has been done with it is to note that Colossus 237 (which preceded it chronologically by a short time), and Comanche 55 (which followed it chronologically) had already been proofed using the "efficient tool". A 3-way side-by-side "diff" between the transcribed source code from these three AGC program versions was done. This highlighted places where errors (many, many errors) might exist. An extremely-large number of errors was corrected in Colossus 249 in this way, along with a (much smaller) number of errors that lingered in the already-proofed Colossus 237 and Comanche 55.
This proofing process also benefited from the availability of an alternate scan of Colossus 249, not available originally, but available nowadays from the collection of AGC developer Fred Martin. Thus, many parts of the original scan that were garbled to the point of illegibility, could now be filled in with absolute certainty.
More than you wanted to know, probably, but having just finished it, I'm still excited about it! :-)
A similar 3-way proofing of Luminary 131's comment text awaits availability of comment-proofed source-code Luminary 116 and Zerlina (derived from Luminary 145), neither of which is available now, but both of which are expected to be available within a few months. Unfortunately, for Artemis 72, the last Colossus version, there is no prospect of a 3-way diff with predecessor and successor versions, but merely a 2-way diff against a predecessor version that may not be a closely-related as we would hope, so it will probably come last of all. But we'll see what we'll see.
||I've added a few "new" names to the list of AGC
developers, relayed to me by developer Henry Noble,
who also wasn't yet on the list. This reminds me that
the original list I made only took into account the names I
found within Luminary 131 and Colossus 249 ... whereas we
actually have lots and lots more AGC listings now, so I
should go through all of them and pull out more names!
And, I ought to add their affiliations, when they're known;
thus Henry worked at Raytheon. But I haven't yet
done those latter things.
The web-pages themselves have been internally cleaned-up in terms of their HTML coding. Hopefully, this has been done in a way that is 100% transparent to anybody viewing them, but it's always possible that problems might have been introduced in the process. Obviously, let me know if you see anything funkier than you expect!
The licensing on all of the pages has also changed, from what (in the U.S.) would have been an implicit copyright by me (Ron Burkey), with all rights reserved, to a Creative Commons No Rights Reserved license. This is equivalent to being in the Public Domain in the U.S., and is the closest equivalent to that in parts of the world where the concept of the public domain is not recognized. I learned this from something Nina Paley wrote in connection to her marvelous animated film, Sita Sings the Blues ... which, if you've not seen it, you should! She had originally released it for free under the Creative Commons Attribution Share Alike License, which already was unbelievably brave, but still had the effect of reserving some legal rights for herself. But she later concluded that since she knew she wasn't going to sue anybody for breaching the license anyway, what was the point of reserving any rights? So she simply changed the licensing in the same manner I am doing now. (Of course, I don't claim to have to have the guts she does, since I derived no financial benefit from this website anyway, so the licensing is irrelevant to my checkbook.)
Comparably gutsy to Nina's film is Kimiko Ishizaka's release of her piano renditions of Bach's Goldberg Variations under this same CC0 license. Highly recommended. I'm not sure of the licensing used for her later recordings of Book I the Well-Tempered Clavier or the Art of Fugue, though Wikipedia claims that the Well-Tempered Clavier has indeed been released to the public domain as well. Kimiko is a German-Japanese, former Olympic bronze medalist in powerlifting, and concert pianist, which is pretty interesting in itself.
||Colossus 237's source-code's comment text has
now been completely proofed, and its
proofing data published online, should you choose to
do a proofing pass on it yourself.
||The comment text for Solarium 55 has been
in the GitHub repository, so its colorized,
syntax-highlighted assembly listing has thus been
updated, and its
proofing data published. It has also been removed from
the volunteering page's list of AGC versions requiring
This Retread 44 source code, unlike under source-code releases so far, as already been completely proofed in terms of its comment text, so I can proudly present it without a warning label.
Also, the Luminary 210 source code (Apollo 15-17 LM), announced a few weeks ago, has also had its comment text belatedly proofed, so it too is now gloriously warning-free!
The proofing data for both has been published online as well, for anybody interested in doing additional proofing passes on them.
The volunteering page has also been drastically reworked, as I realized that most the procedures and instructions given there were drastically out of date.
though, as almost-always for such initial announcements of rope availability, what this means is that:
||The comment-proofing data for Aurora 12 and
Sunburst 120, as well as the octal-proofing data for
Luminary 210 and Luminary 69, have now been posted online,
to join the Luminary 99 and Retread 44 proofing data
mentioned a couple of days ago. The
promised wiki article describing the usage of this data
has now also been written. That article provides
specific links to all of the available proofing-data sets.
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.
||The Mac OS X build-instructions on the
download page are now functional (with the latest
source-code changes in the GitHub repo), and at least on my
primitive Mac (Mac OS X Lion), Virtual AGC can now be build
for Mac OS X.
(Though transcription of the Luminary 210 assembly-listing scans to source code is not yet completed, and transcription of Luminary 069 to source code has not really begun yet.)
In other words, not only is the Sunburst 120 source code
now available, but the assembler can assemble it without
error, and the executable rope will be word-for-word
identical to the known-good memory rope. Building
from source now assembles Sunburst 120 in addition to all
of the other available AGC versions, though it continues
to be the case that it is not integrated into the
VirtualAGC GUI program, and can only be assembled or run
in the simulator from the command line.
In other words, not only is the Aurora 12 source code now available, but the assembler can assemble it without error, and get the identical executable rope mentioned in the prior update.
Of course, I announced the AURORA 12 rope nearly a month ago, but for some curious reason failed to emphasize it as I normally do for new AGC versions, so I'm doing that now. In fact SUNBURST 120 has been available for a few days as well, though I forgot to update this change-log. In both cases, you still have to explicitly build the rope from the corresponding "binsource" file — "oct2bin <Sunburst120.binsource" or "oct2bin <Aurora12.binsource" — (with the rope being oct2bin.bin afterward), but you can do that and run either or both in yaAGC if you're of a mind to do so. In both cases, the source-code transcription is making progress, but isn't yet ready, so this is the only option if you want to run one of these programs right now rather than waiting for full availability.
||Lots of updates throughout the website, as I
review pages I haven't looked at in a while. Mostly
these are minor updates, though I marvel at some of the
oversights, such as: Not mentioning any of the Gemini
developers who helped me so much in the acknowledgements
section of the main page? Really? How dumb it
yaYUL page, in the discussion about the original YUL
program, pointed out that the original YUL was not
written in the Honeywell 800's ARGUS language, though it was
a Honeywell 800 program, and described the background for
||The various syntax-highlighted, hyperlinked
AGC program listings (Artemis072, Comanche055,
etc.) have all been updated with respect to the current
versions of their corresponding AGC source files, but the
principal change is that the symbol tables appearing at the
ends of the top-level files for these program listings are
now hyperlinked. In other words, if you click on a
link in one of these symbol tables, it takes you directly to
the point where that symbol is defined. This is a big
help, I think, because previously you actually had to know
which file the symbol was defined in, and now you do not.
||The main page now begins with a special help
offer — i.e., an offer for a way you can help us,
and that's about as special as things can get! — which is
explained fully on the
experimental pseudo-op, SECSIZ, has been added to the
yaYUL AGC assembler. This optional pseudo-op may be
useful during the process of transcribing hardcopies or
scans of AGC program listings into ASCII source-code form.
The program listing does have some issues, but nothing that we won't be able to work around. As usual lately, reduced-quality but faster-to-load images are hosted here, while the original-resolution but slow-to-load images are hosted at archive.org. Be aware that the archive.org images may not be stable for the next week or two, as their quality-control system works to fix whatever problems (that they can) with the scans. The imagery here will continue to be available regardless.
|| Some big news for today is that
But also, on a separate note, it has slowly dawned on me that I don't have AGC electrical schematics on our document-library page. I thought I did, but I don't! (No wonder I can never find them.) The Block II schematics, as contributed by Eldon Hall, have been on the klabs.org site for many years, but since NASA no longer funds it, that site is unfortunately now essentially a zombie and one wonders how much longer it will persist. So as of today, I'm now mirroring all relevant AGC material from that site here, in our document library. The highlights of the additions are:
It also seems that there may be a perception on the part of the AGC modeling community, if there is such a thing, that the available Block II AGC schematics are so incomplete that constructing a hardware Block II AGC sim is impossible. (That's why, I've been told, everyone continues to do Block I sims.) Well, Mike Stewart has certainly made a Block II sim that's good enough to help him track down and fix bugs in our own software sim, so while the Block II schematics may not be perfect, they are certainly not so incomplete as to prevent using them for this kind of project. And here are Mike's links to prove it:
As it happens, Mike has given me his evaluation of the completeness/incompleteness of the Block II AGC schematics, and I provide that assessment in the document library as well, for anyone interested in this kind of thing.
||The nav-bay version of the Block 1 DSKY
simulation is now available at GitHub, and the descriptions
on the Block 1 page have been altered accordingly, as well
as adding screenshots of the nav-bay DSKY to the Solarium
demo on that page.
Aurora what? Aurora is a very early version of the Luminary program, prior to any manned missions, prior to any unmanned ones ... though not quite the earliest one, which is called Retread. We will soon be engaged in the process of turning Aurora into source code, assembling it, running it on the simulator, etc., which is a process that takes a considerable amount of time. Read more about it on our Luminary page. Or contact us directly if you would like to help out in the process of converting Aurora page images to source code!
|| Well, this has been an interesting
day. I expected to have one significant announcement
today, and instead have two of them. First,
It is, unfortunately, unclear if the code can ever be run in the AGC simulator or not, but I'll think about it for a while before saying "no".
Second, and perhaps more importantly even though I haven't chosen to color it red, I was wrong in one very significant way about Francois Rautenbach's extractions of the rope-memory contents, and that is that it was not from Apollo 6 (Solarium 055) as I said, but rather is the Corona program from the AS-202 ("Apollo 3") mission, which we do not have already, and have no other prospects for acquiring. Moreover, it is simply in the form of stored electrical waveforms rather than a file of numbers representing the values stored at various memory locations. But perhaps it could be converted, and perhaps the Corona binary can be reverse-engineered back into the form of source code, which we will do if at all possible and present it here. So stay tuned.
||The discussion of CPU utilization in the Raspberry Pi build
instructions has been updated to include the Pi 3,
which has a much-lower utilization than the Pi B+, which was
the only model previously discussed.
||A number of goofy hyperlinks fixed.
||The download page now has Raspberry Pi
pre-built binaries on it, as well as installation
instructions and build instructions for Raspberry Pi,
contributed by Laszlo Morocz and Scott Sumner. Thanks,
Laszlo and Scott!
||The download page has been updated so that it
now provides not only the old Linux installer (which is
known not to work with some newer Linux versions like Linux
Mint 17.3 and Ubuntu 14.04), but also a newer
installer, specifically built for Linux Mint 17.3, and
therefore hopefully working for Ubuntu 14.04 or later as
well. Sadly, I'm not set up to test it as thoroughly
as I used to be on every platform under the sun! There
are also updated build-instructions. The code reflects
corresponding updates to the GitHub repository.
|| Well ... anyone who has looked at this will
notice that this website hasn't been updated in 4
years! The updates today are more to see if I still can
update the site after all this time, rather than anything
substantive. Perhaps more will follow. I
apologize to everyone who has sent me to-do's in the
meantime. They haven't been forgotten, merely
neglected, if that's of any consolation to anybody.
Today's changes are simply:
||Gemini: More bug fixes
to the OBC assembler program, yaASM. I think it's pretty close to
100% correct now. I've also created an OBC CPU
emulator called yaOBC,
which is also pretty close to 100% functional, except there
are presently no physical or emulated peripheral devices to
attach to the CPU yet, so it's purely an emulation of the
CPU in isolation. There is, however, a primitive
command-line based debugger interface included, from which
you can view or edit memory, run the OBC program, single
step, set breakpoints at instructions or data locations in
memory, etc. The source code for these is in
subversion, and executables
for the programs can be downloaded from here.
||Gemini assembler: I
realized somewhat belatedly that I hadn't accounted for
overlaying program modules in memory. this has been
fixed by changing the syntax of the CODE
and DATA directives in OBC
assembly language slightly. Both the yaASM program itself and
the write-ups on the Gemini page have been fixed.
|| All things Gemini:
|| I've been very lax about
updating this site, and so have a pretty large backlog of
stuff to deal with that people have sent me and that has
just been sitting on my to-do list. Sorry about
that! First, a status report:
||In the document library,
provided the multi-page fold-out flowcharts of the Gemini
catch-up and rendezvous simulation program as separate
single-page images. Also, added several documents
related to the IBM 704/7090/7094 systems that I found useful
in porting the program to make it buildable with gcc. (The porting
isn't yet complete, in that I'm still working on various of
the assembly-language subroutines.)
||On the Gemini page, corrected
"Ferney Hough" to "Dal G. Ferneyhough, Jr." Also,
added a photo of Gene Mertz et al., and some additional recollections
||Mike Jetzer pointed out that
all of the links to the Apollo press kits on the
document-library page were wrong. (Thanks,
Mike!) That has been fixed.
||Have made most of the PDFs in the Document Library searchable by adding a background OCR'd text layer. I say "most" because I tried to do all of them, but may have missed a few. If so, I'll catch them later. Have continued the process of adding bookmark panes and metadata (title, author, etc.) to them, but that's a much slower process since it's entirely manual.|
||Re-photographed and re-posted Fred Martin's Colossus 237 program listing. Not that I thought there was anything wrong with what I had, but because I still had the listing in hand and had acquired a better camera. The new photos have much better contrast (the background is lighter and the text is darker), so it's a good improvement.|
||Since there's now a site-search bar, I think it's appropriate to make sure that all of the PDFs in the Document Library have embedded metadata (such as title & author), sidebars with bookmarks to the various sections of the doc (where appropriate), and background OCR to make them searchable (where the document characteristics are compatible with Adobe Acrobat's OCR capability). Obviously it will take a good long while to fix up all of the PDFs, and even longer for Google to reindex them, but I'm making a start on it as of today.|
||Added a site-search bar to
the top of every page. It's swell!
||Added several "Apollo
Experience Reports" to the Document
Library, including reports on the "programers" (yes,
that's the real spelling) which were the automated stand-ins
for crewmen on the unmanned missions Apollo 4, Apollo 5, and
||Added a Gemini spacecraft computer page,
even though it's empty right now, and added documentation
(all scarfed from the Meadville
Center website) of the Gemini spacecraft computer to
our Document Library. This
is partly sheer compulsiveness, but also partially because
John Pultorak has pointed out that the LVDC
must be descended from the Gemini computer, simply because
of some very deep similarities between them.
||Added a "how to digitize" page to
||Integrated an LVDC page into the website.
It's a work in progress, but it has enough info on it now,
and enough corrections and improvements from the
corresponding wikipedia article, that it's starting to
||I no longer observe the
persistent FreeBSD problems I mentioned at the bottom of
yesterday's post, even though I haven't fixed them. I
wonder if perhaps FreeBSD doesn't have to be be rebooted
after building Virtual AGC or something wacky like
that. At any rate, today the FreeBSD native build
seems to be 100% functional and virtualy identical in
behavior to the other builds.
||Added scans of the Apollo 8
Flight Plan (sections
sections 3-5), contributed by Fred Martin.
||Added some new documents (memo and
addendum) describing the detailed method originally
used to find approximations for solar ephemerides data
suitable for use by the AGC. Thanks to Bill Robertson,
one of the original developers!
||Stephan Hotto has sent along
a bug-fix the LM-Simulator program. The bug was found
by Riley Rainey. Thanks to both!
||(SVN only at the moment,
since no development snapshot released yet.) Building
on Onno's syntax-highlighting ideas, yaYUL and yaLEMAP now have an
--html command-line switch which allows them to directly
create HTML of their assembly listings. These are not
only colorized, but also have hyperlinking from wherever
symbols (such as constants or line labels) are used back to
the points where they are defined. The HTML forms of
the listings are available from the yaAGS,
Luminary, Colossus, and links pages.
||On the download page, added a
section about networking problems, to cover problems which
have been observed with Fedora 11, as well as to summarize
potential problems I was already aware of on other
systems. Thanks to Onno Hommes for reporting the
Fedora 11 problem and fix.
||On the "volunteering" page,
I've added a lot of material about proofing tasks (octal
listings and program
comments) that I wouldn't mind accepting help
with. Those tasks were previously mentioned, I think,
but were basically left to the imagination.
I doubt that would justify a new download at this point, unless you're trying to do native Win32 builds and they're failing.
||I've reposted all of the
Comanche 055 (Apollo 11 CM) page images, having processed
them with reduced contrast from previously. The page
images are somewhat less pretty than before, in that the
backround color is darker and much less uniform, but the
text is more legible in the lower-left quadrants of many of
the pages. Although I've not updated the source-code
tarball, around half of the page images have been converted
to source-code files available in the subversion
repository. Work on conversion of Luminary 099
(Apollo LM) page images to source code has not yet begun.
The hardcopy from which these images were taken is from the Charles Stark Draper Historical Collection, MIT Museum, Cambridge, MA. The digital scans were produced by Paul Fjeld. Many thanks to Debbie Douglas of the MIT Museum for having the great foresight to arrange for these images to be made available to us, and to Paul Fjeld for performing the dreary work of creating the digital page images! More on this later.
||The FreeBSD native build is
now working again, to the extent that I'm able to check
it. The build instructions for it have changed a
||The VirtualAGC main screen
has been reworked to take up less space. This is
principally necessary on screens which are 1024×768 and have
a large dock or toolbar at the top or bottom of the
screen. However, I like the new layout better anyway
as it seems more logical to me. There is no functional
||I have had reports of the ACA
(hand-controller) simulation not working on some versions of
Mac OS X, so I have made a change. Instead of always
using the yaACA3
simulation program (which superceded the earlier yaACA simulation program
for snapshots 20090331 and later), the VirtualAGC GUI front-end
now allows for using yaACA
and yaACA3 somewhat
interchangeably. Basically, it will use yaACA3 unless it notices
that yaACA has been
configured, and then it will use yaACA instead. The yaACA program has also
been tricked up similarly to the yaACA3 program in that it now automatically
saves its joystick-related switches to a configuration file,
so that they become the defaults at the next run. Read about it in detail
if you have experienced a non-functional joystick.
(And don't send me any jokes about that, please!)
||I fixed the FreeBSD bugs
mentioned yesterday, and am now willing to say that Virtual
AGC works in FreeBSD. Instructions for building from
source on FreeBSD have been added to the download page. I'd
be lying, though, if I said it was thoroughly tested.
Unfortunately, I only have FreeBSD running in a virtual
machine, and the marriage of FreeBSD (PC-BSD) to VirtualBox
has not proved a happy one for me, so my ability to test the
the FreeBSD installation is very crude. When I say
Virtual AGC "works", I mean that I can run VirtualAGC, that I can
start the simulation, that I can put in verbs and nouns on
the DSKY and it does what I expect it to do, that I can see
telemetry downlinks, and that I can perform digital
uplinks. If anyone wants to send me more data, I'd be
happy to see it, but I've done all I expect to do on the
FreeBSD side in the absence of feedback.
As far as substantive changes are concerned, I fixed a couple of makefile bugs which prevented Virtual AGC from building on FreeBSD. It now builds—and works, as far as basic functionality is concerned—but fails after certain directory manipulations are made, so it still needs some tweaking. However, I've added some build instructions for it on the download page.
|| As far as the website itself
is concerned, various people have sent me interesting and
useful stuff which I've added. I won't detail those
things here, except to say "Thank you!" to Dimitris Vitoris,
Mirko Mattioli, and Onno Hommes. Some important corrections have been
made to material on the the website itself, thanks to
||yaDSKY and yaDEDA
have been superceded by rewritten replacements yaDSKY2 and yaDEDA2 to improve
portability and distributability. Moreover, there is a
completely new yaTelemetry
program to replace the Digital-Downlink-monitoring
functionality previously kludged into yaDSKY (but missing from
||There's now a GUI front-end
that conveniently ties all of the Virtual AGC bits and
pieces together that were previously provided only
incompletely and relatively unsatisfactorily through a few
very simplified command-line scripts. I call this
front-end program VirtualAGC.
program will additionally have convenient installers for
Linux, Windows, and Mac OS X, which is something which has
been lacking up to now. At the same time, I've fixed
the problem that (as previously installed by Virtual AGC)
Stephan Hotto's LM_Simulator
module didn't have its various very-useful help screens.
||The current development
snapshot fixes a bug which has existed since 2007-03-16 in
the development snapshots, but not in any of the binary
downloads (since I've not posted new versions of the binary
downloads in that time period). The bug, very simply,
is that the LM_Simulator
module would abort if used in a CM simulation, even though
it would work in an LM simulation. The upshot of this
is that if you tried to start a CM simulation using any of
the provided scripts (SimColossus249,
SimArtemis072, or SimArtemis072_lite) then
the simulation would abort with an error message. I
suspect that some folks have complained to me about this and
that I blew them off with an explanation that there was
something misconfigured about their computers. If you
complained and I ignored it, I apologize.
Development of Virtual AGC has been on hold for a while, but I expect it to pick up again soon, with a vengeance. (For everyone who has sent me stuff with which to update the website and it has seemingly fallen into a black hole, I'll finally be adding your updates!) So watch this space.
||Added a nifty photo
Alessandro Cinquemani has sent in of the Pultorak-style
AGC/DSKY he is constructing.
I've completed all the subassemblies, which are now in their final form except for the DSKY. I plan to make it a 3 PCB unit; 1 PCB for the mainboard/keyboard, 1 for the LED display/caution & status lights and 1 for the interface daughterboard.That's necessary because the keys I'll use (RS 336-191) are a little tall and I'll have to elevate the displays. Also I plan to design my DSKY in such a way that it can be used in any revision I plan to make by just exchanging it's I/O daughterboard. You'll find that there are 5 new elements in this revision:
The MCAs are the separated monitoring busses and control switches from each A0 module. The MC is the main power distribution hub,
panel illumination controller and using it you can power down any or all the monitoring panels at will.
I have attached together with the A1 schematics the following:
As before these schematics should NOT be considered final and may contain errors. Looking forward for your comments and suggestions!
|| Stephan Hotto has sent
version 1.0 of LM_Simulator,
both in source code and in the Windows "stand-alone"
executable version, with the following notes:
||I have found a backdoor into
"archived" HRST website, and modified the links page
accordingly. However, I'll still continue to host the
documents, because it gives me a chance to improve them.
||As mentioned earlier, MIT's
Dibner Institute, whose website (HRST) formerly hosted most
of the scans of historical AGC documents on which Virtual
AGC is based, has closed and its website is gone. I have decided to begin
hosting the documents formerly available from HRST, with
improvements to some of them, here at Virtual AGC.
Some of the documents---particularly the assembly
listings---have been improved from the versions formerly at
HRST; others will be improved in the future. It may
take a while to find and fix all of the now-broken links, so
if you find any of them let me know.
|| Okay ... I haven't updated
the development snapshot or website since dev snapshot
20060110, mostly from laziness. Agood thing, too,
because since then a very nasty bug had been introduced into
yaAGC, but I
couldn't find it or fix it because I was falsely blaming the
symptoms on the LM_Simulator
changes. Hooray for laziness! But yaAGC is now
If you're iffy about installing the new dev snapshot, here's the executive summary of changes since 20060110:
|| Busy Stephan has sent still
update, as follows:
|| Stephan has sent another LM_Simulator update,
which he describes as follows:
Now the FDAI shows the correct 8-ball angles - currently with a limitation to:
Yaw: 0Deg \B190Deg
Pitch: 0Deg \B190Deg
Roll: Anyway limited by the Gimbal Lock condition at 0Deg \B185Deg
The functionality of the DAP and the dynamic model as well as the displayed FDAI angles can be verified by using the "Crew Defined Maneuver Routine V49". By initiating this routine you must provide the desired destination IMU Gimbal Angles, subsequently the AGC presents you with the associated FDAI angles it steers the LM to (please refer to the Tutorial). Because of the above mentioned limitation those FDAI angles should be in the defined range. [By the "tutorial", Stephan means the Contributed/LM_Simulator/tutorial.txt, which you'll get by downloading the development snapshot of Virtual AGC.]
The CPU load maximum lies around 20% on an Intel Core Duo 2.13GHz processor.
|| Here's a sort of omnibus
update that takes into account stuff people have been
sending me over the last year or so. I apologize to
anybody who sent me something I've forgotten about!
Additionally, Stephan tells us:
The DAP is now stable around all axes and even the "DAP V49 Crew Defined Maneuver" routine steers the LM exactly into the right orientation.
There was a major bug in the IMU coordination transformation that caused the DAP instabilities.
Furthermore, to handle single RCS jet events it was necessary to transform the U,V jet system into the P,Q,R pilot axes.
The whole dynamical model of the LM is now based on the equations used for the DAP state estimator. This approach makes the model very precise and comparable to the real thing.
To assure the right AGC initialization it is necessary to stick to the following pre-conditions and steps:
|| Have added the
SimArtemis072_lite startup script, have tried out Artemis072
in Win32, and have hopefully updated all of the web-pages to
properly reference Artemis072.
Unfortunately, it may be quite a long time before the source code for Artemis072 is available, so we'll just have to live with having only the executable for a while.
||All data entry and proofing
for the Artemis 072 (Colossus 3) executable has been
completed, and some startup scripts have been added for
it. I haven't yet made the necessary mods to the
webpages yet to explain how to use it, nor have I gotten the
chance yet to try it in Windows. Tomorrow,
hopefully. In the meantime: Start the simulation
using the script "SimArtemis072". (I'm really only
posting it today just in case I happen to die overnight,
which I presume is unlikely.)
||I now have in hand the
complete listing of the Colossus 3 (Artemis 072) executable
used in the CM of Apollo 15-17. Thanks to D. Thrust
for providing the scans! It will take me some time to
convert it into machine-readable form so that it can be
executed by the AGC simulator, but I will proceed with it as
quickly as possible. I don't yet have much of the
Colossus 3 assembly-language source code, but hopefully it
will make an appearance as well, in due time.
||Well, I seem to have hit the
jackpot this week, in terms of getting into contact with
some of the original AGC programmers. Eileen Hughes
has sent me the first names of several
programmers---including her own---while Jonathan Addelston
has written to tell me that I was spelling his name
wrong. Sorry about that! The acknowledgement
list on the home page has been corrected.
|| I've been holding onto some
changes for a while, so let's hope I manage to remember them
all. The reason I was holding on is that I have seen
some segfaults in yaAGC
when manipulating the RHC. However, now that I am
trying to fix them, they've magically disappeared. (If
you experience such problems, please send me the files
called "core" and "LM.core". Thanks!)
The downside is that you can no longer use any command-line parameters with the batch files. I've tried to make intelligent choices as to which command-line switches you might want, but if I'm wrong you need to edit one or another of the files SimLuminary131.xeq, SimLuminary131_lite.xeq, SimColossus249.xeq, or SimColossus249_lite.xeq. (These ".xeq" files contain the lists of files, along with their command-line parameters, that are run by WinAGC.exe.) Even then, there are some things you can't accomplish, such as running yaAGC or yaAGC in --debug mode. If you want to do that, I'd suggest setting the environment variable NOWINAGC=yes before running the startup scripts, as this will restore the batch files to their pre-WinAGC glory.
Another downside is that that Allegro and Tcl/Tk are now really requirements rather than options, although I've not had a chance to update the instructions yet. The reason is that the startup scripts will abort if yaACA and LM_Simulator cannot be run, rather than ignoring it. (I must say, though, that you really want to run both of these things, although admittedly yaACA isn't of much use without a "3D game controller" --- i.e., a joystick. Therefore, buy a joystick.) If you absolutely don't want to run these programs, or cannot for some reason, edit the appropriate ".xeq" file and prefix the yaACA and/or LM_Simulator lines by the character '#' (without quotes, of course).
The simulation reaches the correct Delta Velocity of about 2400m/s (about 8000ft/s) after using the complete fuel. The start values I'm using are obtained from the Lunar Module Wikipidia page and the pad load file.
||Well, I now like yaDSKY's ability to
display downlink lists so much that I've split off that
ability from the "--test-uplink" command-line switch, and
added it to a new "--test-downlink" command-line
switch. In fact, "--test-downlink" is used by default
in the SimLuminary131
startup scripts. Of course, the ability to completely
display all downlink lists isn't quite available.
However, the erasable dump downlist is still available, and
the AGS initialization/update downlist is complete.
||yaAGS: Finally have a sensible DVP instruction, I
think. (A rational person could still disagree with
this assessment, I suppose, so you're still invited to
examine the DVP
code in aea_engine.c to offer your opinion.) However,
I've noticed some anomalous behavior that I didn't notice
before, in that the DEDA will freeze up, or readouts will
occur that I can't figure out any way to stop, but it
doesn't seem to have anything particularly to do with the DVP
instruction. Typically, this will be readout of
address 555, which begins spontaneously, and which I can't
||Have now worked out the
details needed for the digital uplink, and have described
them in a new "Fictitious I/O Channel" section on the
developer page. However, I haven't yet implemented it
in yaAGC. (No
new new yaAGC
features are needed for the digital downlink, though I admit
I'm unclear yet on the mechanism used to transfer state
vectors between the CMC and LGC.)