swh:1:snp:79c9132b4a8931e989e318225e00e088ef6f383d
Tip revision: a8fa8f03b50a72034009439908f1339f4ce94518 authored by Ron Burkey on 06 June 2021, 12:28:21 UTC
Fixed more hyperlinks.
Fixed more hyperlinks.
Tip revision: a8fa8f0
changes.html
<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Virtual AGC Change-Log Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Author" content="Ronald Burkey">
<link rel="icon" type="image/png" href="favicon.png">
<meta name="author" content="Ronald S. Burkey">
<script>
function viewOrHide(year) {
var box = document.getElementById("box" + year);
var table = document.getElementById("table" + year);
table.hidden = box.checked
}
</script>
<script type="text/javascript" src="Header.js"></script>
</head>
<body style="background-image: url(gray3.jpg);">
<script type="text/javascript">
document.write(headerTemplate.replace("@TITLE@","Change-Log").replace("@SUBTITLE@","Software / Website / News"))
</script><br>
<input id="box2021" onchange="viewOrHide(2021)" autocomplete="off"
type="checkbox"><b>Hide 2021 change notes?</b>
<table summary="" id="table2021" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" cellspacing="10"
cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top">2021-06-06<br>
</td>
<td valign="top">
<ul>
<li>On the document-library page, I reset the <img
src="new.png" alt="" width="36" height="16">
indicators — last reset nearly two years ago, so no
wonder they had become pretty useless! They'll
only adorn newly-added documents from today forward.</li>
<li>Added the North American Aviation document "<a
href="Documents/apollo_electrical_installation.pdf">Apollo
Electrical Installation</a>" to the document library,
thanks to Mike Stewart. The document happens to
contain a partial explanation for NAA's CSM
drawing-number scheme, which we didn't previously have,
so our <a
href="ElectroMechanical.html#Additional_Engineering_Drawings">electro-mechanical
page</a> was also updated with some of that
information.</li>
<li>Added <a
href="links.html#Miscellaneous_Mission_Documents">several
documents related to the Apollo 11 flight readiness</a>
review to the document library.</li>
<li>Added a memo titled "<a href="Documents/HSI-38170.pdf">June
5th Apollo Spacecraft Software Configuration Control
Board (ASSCCB) meeting</a>" to the document
library. Yes, sounds pretty dry, I know, but it
contains the full texts for PCR 780 and PCR 815,
relevant (particularly the latter) to the
somewhat-ongoing effort to reconstruct Comanche 67
(Apollo 11 CM) software from Comanche 55 (Apollo 11) <i>et
al</i>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2021-05-30<br>
</td>
<td valign="top">
<ul>
<li>I made some additional clarifications for <a
href="download.html#WebAssembly">the build
instructions for yaAGC's WebAssembly target</a> on the
download page.<br>
</li>
<li>Andy Smith has just completed his rather major effort
to find and correct symbol misspellings in the AGC code
base, as well as correcting various other bits of
formatting discrepancies (vs the original listings) he
found along the way. These changes are now present
in the AGC source-code files in our GitHub software
repository, as well as in the colorized,
syntax-highlighted code listings on this site. In
case you wonder what I mean when I say "major", there
are presently 2575 AGC source-code files, of which
Andy's effort affected 2456 of them. That's not to
say that the files were completely riddled by errors,
but that a single misspelling can infect a large number
of source files. For example, the symbol <tt>ENDDCM</tt>,
misspelled as <tt>ENDOCM</tt>, infected 26 files.
(Naturally, none of these typos resulted in any errors
in the core ropes, which were and remain good.) If
you're curious, <a
href="https://github.com/virtualagc/virtualagc/pull/1147/files">the
complete set of file diffs can be viewed at this link</a>.
Great job, Andy! The only code not affected by
Andy's audit is the Comanche 67 reconstruction I've been
intermittently working on, and of course that's not
because it doesn't have misspellings — which I'll have
to take care of later — but because I've never merged it
into the main branch of the repository.</li>
</ul>
<p>As you may infer from earlier entries in this change log,
Andy employed a smart method for this audit, rather than
relying on the brute-force approach of simply eyeballing
all of the original source listings. His method
instead involved comparing the symbol tables found at the
end of each of the original listings against the symbol
tables output by a modern assembly of the source
files. He used an AGC assembler he had created
himself, which listed the symbols in the same order as the
original assembler did, and formatted the printouts the
same way as the original assembler did, thus making a
comparisons easy. <br>
</p>
<p>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 <i>possible</i> that a much
smaller number of misspellings continue to lurk,
undetected. Admittedly, I kind of doubt it. If
anyone wants to volunteering for the mind-bending task of
checking the symbol tables more closely, I'm sure it would
be appreciated.<br>
</p>
<p>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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2021-05-28<br>
</td>
<td valign="top">On the download page:<br>
<ul>
<li>Clarified some of <a href="download.html#WebAssembly">the
build instructions for yaAGC's WebAssembly target</a>.</li>
<li>Added <a href="download.html#CMake-Based_Builds">a
new section for Virtual AGC's CMake-based build
procedure</a>. This build method has been
available for some time, thanks to Michael Hirsch, but
like a dummy I didn't think to provide any online
documentation for it up to now. I was only
reminded by a crop of recent updates to it. Duh!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2021-05-27<br>
</td>
<td valign="top">Updated the description of the <a
href="download.html#WebAssembly">WebAssembly target</a> 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
computer.<br>
</td>
</tr>
<tr>
<td valign="top">2021-05-26<br>
</td>
<td valign="top">On the download page (and the GitHub code
repository), there's now <a
href="download.html#WebAssembly">a WebAssembly target</a>
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
demo HTML/JavaScript for actually running the simulation in
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.<br>
<br>
You may recall that Shahriar Iravanian had earlier provided
a pure-JavaScript port which serves a similar purpose.
However, the WebAssembly version should be somewhat faster
than the JavaScript version of yaAGC.<br>
</td>
</tr>
<tr>
<td valign="top">2021-04-22<br>
</td>
<td valign="top">Updated <a href="yaYUL.html#Invoking_yaYUL">the
description of yaYUL command-line switches</a> to include
the <tt>--reconstruction</tt> switch, whose was merged
today from the "comanche67" branch of the GitHub repository
into <a
href="https://github.com/virtualagc/virtualagc/tree/master/yaYUL">the
main branch</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2021-04-21<br>
</td>
<td valign="top">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 <tt>POO</tt> (pee oh oh) and <tt>P00</tt>
(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 <i>little</i>
more consistent with YUL and GAP.<br>
<br>
The source code for yaYUL now in the github repository has
these changes to the symbol-table formatting in it.<br>
<br>
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. <img
src="smiley.png" alt="" width="16" height="16">) 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 <a
href="https://github.com/virtualagc/virtualagc/issues/1143">reading
issue #1141 in our github repository</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2021-04-20<br>
</td>
<td valign="top">
<ul>
<li>The link on the Luminary page to the raw scans for the
listing of RETREAD 44 was incorrect (it pointed to
AURORA 12), and has been fixed.</li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/master/yaYUL">The
assembler (yaYUL) in the github repository</a> can now
produce symbol tables of assembled AGC code using the
collation order of the original Apollo-era
assemblers. Up to now, it has simply been using
the native collation (presumably ASCII) of the platform
on which yaYUL is being run. Symbol-table files
(*.symtab) that yaYUL creates for use with a debugger
remain in the native order, since otherwise the debugger
might not be able to interpret them properly. The
original YUL assembler, however, used the native
character encoding of the Honeywell H-800 computer
system on which it ran, and the printed symbol tables in
the assembly listings it created were in that collating
order. Likewise, the original GAP assembler which
succeeded YUL used the native IBM character encoding,
namely EBCDIC, for sorting symbol tables. Thus,
while the assembly listings created by yaYUL had all the
same symbols as those created by YUL or GAP, the symbols
were in a different order, and the symbol tables were
consequently difficult to compare. In general,
after today's update, all versions of the RETREAD,
AURORA, SUNBURST, TRIVIUM, and SOLARIUM programs were
originally assembled with YUL and now use yaYUL's H-800
ordering, while all other versions of AGC programs that
are available to us were originally assembled with GAP
and now use the EBCDIC ordering. Admittedly, I
haven't checked the new assembly listings vs the
original scans in <i>full detail</i>, since the
combined symbol tables of all the AGC versions we now
have available undoubtedly total more than 100,000
symbols. Yikes! Nevertheless, even if there
are some errors, I'm sure yaYUL's symbol-table ordering
is very close to being correct. The colorized HTML
versions of the AGC source code here at the Virtual AGC
website don't yet reflect the H-800/EBCDIC ordering,
because some corrections to the AGC code base are in the
works and I'd like to avoid unnecessary churn.
Once the HTML listings are updated, however, their
symbol table ordering will hopefully match those of the
scanned original assembly listings.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2021-03-30<br>
</td>
<td valign="top">Several new documents have been added to the
library:<br>
<ul>
<li><a href="Documents/apollo12_delco.pdf">AC/Delco Apollo
12 manual</a></li>
<li>"<a href="Documents/mit_20ig_handbook.pdf">Handbook on
the Assembly and Testing of the M.I.T. 20IG
Integrating Gyro Unit</a>". This is a 1956
Instrumentation Lab document, but is interesting for
relevant similarities to the eventual Apollo IMU.</li>
<li>"<a href="Documents/102789076-05-01-acc.pdf">LM
G&C Data Book</a>"<br>
</li>
</ul>
Thanks to Mike Stewart for the first two documents, and to
the Computer History Museum for the final document.<br>
</td>
</tr>
<tr>
<td valign="top">2021-03-27<br>
</td>
<td valign="top">Continued adding mission reports and their
supplements to the <a href="links.html#MissionReports">"Mission
Report" section of our document library page</a>. 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
the <img src="new.png" alt="" width="36" height="16"> icon
I typically put on newly-added library documents had become
pointless. When the icons were there, it just appeared
as though <i>every</i> document was new. Since the
icons weren't helpful under these circumstances, I've
temporarily removed all of them in that section of the
library. <br>
</td>
</tr>
<tr>
<td valign="top">2021-03-26<br>
</td>
<td valign="top">I have found out somewhat belatedly that
"Apollo <i>X</i> Mission Report" documents actually contain
useful info <i>vis-à-vis</i> the guidance system, including
for example some postflight trajectory data. While we
already had a <a href="links.html#MissionReports">"Mission
Report" section of our document library page</a>, 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
the future.<br>
</td>
</tr>
<tr>
<td valign="top">2021-03-25<br>
</td>
<td valign="top">
<ul>
<li>It turns out that we now have the <i>complete</i> <a
href="Documents/HSI-208461.pdf">section 5 (guidance
equations) of the Comanche 72 (Apollo 13 CM) GSOP</a>.
(See yesterday's note about an incomplete
document.) Somehow the file transfer had gotten
bollixed, but UHCL has now given me the full pdf.
Yay!</li>
<li> Also added was "<a href="Documents/19760012111.pdf">Apollo/Saturn
V Postflight Trajectory - AS-512</a>", the post-flight
reconstruction of Apollo 17 launch vehicle
trajectory. (Thanks to Conor Kelly.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2021-03-24<br>
</td>
<td valign="top">Added <a href="Documents/HSI-208461.pdf">the
first half of section 5 (guidance equations) of the
Comanche 72 (Apollo 13 CM) GSOP</a> 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
72 document.<br>
</td>
</tr>
<tr>
<td valign="top">2021-03-22<br>
</td>
<td valign="top">Updated <a
href="httdownload.html#Downloading_and_Building_Virtual_AGC">instructions
on building Virtual AGC from source</a> 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.<i>x</i> (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.<br>
</td>
</tr>
<tr>
<td valign="top">2021-03-21<br>
</td>
<td valign="top">The instructions for <a
href="download.html#Downloading_and_Building_Virtual_AGC">building
Virtual AGC from source code</a> 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
time.)<br>
</td>
</tr>
<tr>
<td valign="top">2021-02-07<br>
</td>
<td valign="top">Building on what I said in yesterday's post,
Dan Kosko has also sent in a couple other docs, now added to
<a href="links.html">our library page</a>:<br>
<ul>
<li>The <a
href="Documents/Saturn_V_Flight_Manual_SA_504.pdf">Saturn
V Flight Manual for SA-504</a>, thus adding to the
collection we already had of Saturn IB and Saturn V
(SA-503, SA-507) flight manuals.</li>
<li>An improved (or at any rate <i>different</i>) scan of
the <a
href="Documents/Lunar%20Excursion%20Module%20Familiarization%20Manual%20-%20LMA790-1.pdf">Lunar
Excursion Module Familiarization Manual</a>. The
thing that stands out about the new scan (as opposed to
<a
href="Documents/LMA790-1-19651015-LunarExcursionModuleFamiliarizationManual.pdf">the
old one</a>) is that <i>some</i> attempt was made to
rejoin wide drawings that the first scan had left as
separate frames. For example, in the old scan,
Figure 3-3 comprises PDF pages 50-52, while in the new
scan it's simply page 41. But the effort to rejoin
the drawings wasn't consistent, so you can certainly
find some large drawings in the new scan that still show
up as 2 or more frames. For example, in the new
scan, Figure 3-26 is 3 pages (PDF 91-93). Even at
that, in the old scan Figure 3-26 is <i>5</i> pages
(PDF pages 122-126). Yikes! So one can't
really complain too hard.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2021-02-06<br>
</td>
<td valign="top">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
it. <img src="smiley.png" alt="" width="16"
height="16"><br>
<br>
We do have a new website addition, though, in the form of a
document added to <a
href="ElectroMechanical.html#Additional_Engineering_Drawings">our
electro-mechanical page</a> (as opposed to our
document-library page). It's North American Aviation's
"<a
href="Documents/CSM%20Functional%20Integrated%20System%20Schematics%20Block%20II%20Revision%20K.pdf">CSM
Functional Integrated System Schematics, Block II</a>".
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,
<i>years</i> before my own unsuccessful efforts to get it.<br>
</td>
</tr>
<tr>
<td valign="top">2021-01-15<br>
</td>
<td valign="top">Paul Koning has sent me some feedback on our
<a href="HowToDigitize.html">How to Digitize page</a>, 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, <i>and</i>
to point out that every recommendation I make is probably
obsolete anyway, now that relatively cheap book scanners
(overhead scanners) are on the market.<br>
</td>
</tr>
<tr>
<td valign="top">2021-01-12<br>
</td>
<td valign="top"> 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 <a
href="QuestForInfo.html#CSDL">entire, one-sentence-long
section</a> on our website page about finding
material. It can't be missed now. Maybe.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2020" onchange="viewOrHide(2020)" autocomplete="off"
checked="checked" type="checkbox"><b>Hide 2020 change notes?</b>
<table summary="" id="table2020" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top">2020-12-24<br>
</td>
<td valign="top">Accurate reconstructions of the <a
href="Colossus.html#Comanche045">source code for Comanche
45</a> <i>and</i> for <a
href="listings/Manche45R2/MAIN.agc.html">Comanche 45/2</a>
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 <a
href="listings/LUM69R2/MAIN.agc.html">Luminary 69/2</a>
has been available for a while. The upshot is:<br>
<br>
<table width="80%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<td valign="middle" align="center"><font
color="#ff0000"><i>We now have complete, final
releases of Apollo 10 AGC source code ... both
LM and CM.</i></font><br>
</td>
</tr>
</tbody>
</table>
<br>
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.<br>
<br>
This is the endpoint in a long series of reconstructions of
missing revisions of Apollo 10 AGC source code, led by Mike
Stewart:<br>
<blockquote><font color="#ff0000">✓</font> Comanche 55
(final release of Apollo 11 CM code, from actual hardcopy)<br>
<blockquote> → <font color="#ff0000">✓</font> Comanche 51
(initial release of Apollo 11 CM code, reconstruction)<br>
</blockquote>
<blockquote>
<blockquote> → <font color="#ff0000">✓</font> Comanche
44 (initial release of Apollo 10 CM code,
reconstruction)<br>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote> → <font color="#ff0000">✓</font>
Comanche 45 (intermediate release of Apollo 10 CM
code, reconstruction)<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote>
<blockquote> → <font color="#ff0000">✓</font>
Comanche 45/2 (final release of Apollo 10 CM code,
reconstruction)<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<blockquote><font color="#ff0000">✓</font> Luminary 69
(initial release of Apollo 10 LM code, from actual
hardcopy)<br>
<blockquote>→ <font color="#ff0000">✓<font
color="#000000"> Luminary 69/2 (final release of
Apollo 10 LM code, reconstruction)<br>
</font></font></blockquote>
</blockquote>
<blockquote>
<blockquote> </blockquote>
</blockquote>
</td>
</tr>
<tr>
<td valign="top">2020-12-15<br>
</td>
<td valign="top">At the top of the <a href="index.html">home
page</a>, 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.<br>
</td>
</tr>
<tr>
<td valign="top">2020-12-14<br>
</td>
<td valign="top">
<ul>
<li>I've completed the reconstruction-justifying
annotations in the Luminary 69/2 (Apollo 10 LM final
release) code, and incorporated feedback on them, so
they're good to go!</li>
<li>The Comanche 51 reconstruction-justifying annotations
I mentioned yesterday have been reviewed, and they're
also good to go!<br>
</li>
<li>I found that the color selection I had made for
visited hyperlinks in the HTML colorized,
syntax-highlighted assembly listings of AGC programs was
no longer working out very well. The color had
apparently been chosen to reduce visual confusion vs the
color of program comments. While it worked well
for that, it was too close to the black text in the
reconstruction-justification annotations I've been
adding to programs like Comanche 44 and 55. I.e.,
in the colorized HTML, once you visited a link in an
annotation, the link became essentially
indistinguishable from the surrounding text in the
annotation. So I've now changed yaYUL (which
generates the HTML) to use default visited-link coloring
instead, and I've regenerated all of the colorized AGC
HTML assembly listings to correct the coloring.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-12-13<br>
</td>
<td valign="top">
<ul>
<li>The justifying annotations I had added to the
reconstructed Comanche 44 code have now been reviewed
and corrected. I'm sure they're probably still not
perfect, but they should at least be useful now and not
lead anybody too far astray.</li>
<li>A first draft of justifying annotations has been added
(or tweaked in some cases) to the reconstruction of
Comanche 51 from last year.</li>
</ul>
<p>Incidentally, in case it isn't obvious, the immediate
goal of the current reconstruction efforts is to arrive at
a <i>complete</i> 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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2020-12-12<br>
</td>
<td valign="top">I've gone through the source code of the
reconstruction of Comanche 44 (derived by Mike from Comanche
51) and added an annotation for <i>each</i> 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 <a
href="listings/Comanche044/MAIN.agc.html">the colorized,
syntax-highlight HTML listing</a>, I think. They'll
probably be in flux for a few days.<br>
</td>
</tr>
<tr>
<td valign="top">2020-12-10<br>
</td>
<td valign="top">We've obtained a copy of the version of the
document <a href="links.html#PGE_COLOSSUS2"><i>Programmed
Guidance Equations for COLOSSUS 2</i> based on Comanche
55</a> ... 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.
<img src="smiley.png" alt="" width="16" height="16">)
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.<br>
<br>
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 <i>exactly</i> what the changes were in
AGC assembly language or interpretive code from Apollo 10 to
Apollo 11, the pseudocode <i>often</i> follows the
assembly/interpretive code closely enough to <i>infer</i>
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. <img src="smiley.png" alt=""
width="16" height="16"> For the rest of us, such as
myself, it at least lets you follow their reasoning.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2020-12-07<br>
</td>
<td valign="top">In my comments about Comanche 44 a couple of
days ago, I mentioned that it had not <i>yet</i> 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.<br>
<br>
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 <i>not</i> 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 <a
href="Colossus.html#Comanche044">the blurb</a> I've added
to the Colossus page!<br>
</td>
</tr>
<tr>
<td valign="top">2020-12-06<br>
</td>
<td valign="top">Support for Comanche 44 has now been added to
the VirtualAGC GUI program.<br>
</td>
</tr>
<tr>
<td valign="top">2020-12-05<br>
</td>
<td valign="top">Apollo 10 AGC Command Module code!<br>
<br>
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.) <br>
<br>
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
<i>do</i> 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 <br>
<ol>
<li>Reconstruct Comanche 51 (unavailable, unflown Apollo
11 code) from Comanche 55 (available, flown Apollo 11
code).</li>
<li>Reconstruct Comanche 44 from Comanche 51 and Colossus
249 (available, flown Apollo 9 code).</li>
<li>Reconstruct Comanche 45 from Comanche 44.</li>
<li>Reconstruct Comanche 45/2 from Comanche 45.<br>
</li>
</ol>
The first step had been completed some time ago. Mike
has now finished the second step, his reconstruction of
Comanche 44 source code. Admittedly, there's a
slightly-dubious issue with it that may need to be revisited
later if additional contemporary Colossus
change-documentation becomes available some time, or — gosh!
— even the actual program listing. But meanwhile, in
lieu of that, the reconstruction is darn good! The
dubious issue I mentioned should not adversely affect
execution of the code. The reconstructed code has all
of the correct memory-bank checksums for Colossus 44; it's
now available in our <a
href="https://github.com/virtualagc/virtualagc/tree/master/Comanche044">GitHub
repository</a> and will be built if you build the Virtual
AGC project from source. You can also see the
colorized, hyperlinked source code in <a
href="Colossus.html#Comanche044">the Apollo 10 entry on
our Colossus page</a>. I have not yet provided the
support in the VirtualAGC GUI program for it, though I'll
get around to doing so soon. Nor has it been flown yet
in a simulated Apollo mission.<br>
</td>
</tr>
<tr>
<td valign="top">2020-11-01<br>
</td>
<td valign="top">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?<br>
<br>
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 <a
href="ElectroMechanical.html#Additional_Engineering_Drawings">our
electro-mechanical page</a>. Of course the NARA
microfilm collection has tens of thousands of these CSM
drawings rather than merely dozens. <i>Eventually</i>
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.</td>
</tr>
<tr>
<td valign="top">2020-10-15<br>
</td>
<td valign="top">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.<br>
<br>
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 <a href="links.html#ASTP">ASTP-specific mission
documents in the library</a>. 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. <br>
<br>
We've also gotten a copy of the "HP-65 Rendezvous Targeting
Checklist", which you'll find at the same hyperlink. <br>
</td>
</tr>
<tr>
<td valign="top">2020-10-05<br>
</td>
<td valign="top">Added 3 documents to the library. Since
it may be a bit tricky to pick them out by eye on <a
href="links.html">the document-library page</a>, partially
due to it being tricky to categorize them precisely, here's
an explicit list:<br>
<ul>
<li>Grumman "<a href="Documents/LED-520-1G.pdf">Design
Criteria and Environments</a>". Provides a
hundred-page summary the Lunar Module's detailed
specifications.</li>
<li>General Electric "<a
href="Documents/ace-sc_operators_manual.pdf" style="">Operator's
manual, Acceptance Checkout Equipment — Spacecraft</a>"
for the CM and LM.<br>
</li>
<li>"<a href="Documents/fcc_manual_as200.pdf">IBM Saturn
IB/V Instrument Unit Technical Manual, Flight Control
Computer</a>". This version of the document
relates to the Saturn IB (AS-20<i>x</i>), whereas you
may recall that the Saturn V (AS-50<i>x</i>) version of
the document was added to the library a few months ago.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-08-13<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2020-08-05<br>
</td>
<td valign="top">Recall from a couple of weeks ago that the LM
AGC software for Apollo 9, namely <a
href="Luminary.html#Sundance306">Sundance 306</a>, was in
the process of being <i>reconstructed</i> from
memory-module dumps in lieu of an actual assembly listing of
the Sundance 306 program. Reconstruction is a 3-phase
process, in which phases 1 and 2 are successively-close
approximations to the exact code, but only phase 3 will be
an exact reconstruction. As you'll recall, phase 1
(which we call SundanceXXX), which is supposed to
functionally match Sundance 306 but not match it octal word
for octal word, had been completed and successfully test
flown. <br>
<br>
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.<br>
<br>
It's admittedly unlikely we'll ever have a full phase 3
reconstruction, in which <i>all</i> 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
<i>tour de force</i>, 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 <i>carpe</i>
that old <i>diem</i>!<br>
</td>
</tr>
<tr>
<td valign="top">2020-07-27<br>
</td>
<td valign="top">Paul Fjeld (thanks, Paul!) has sent us the LM
erasable pad loads for <a
href="Documents/Apollo9LMPadLoad.pdf">Apollo 9</a> and <a
href="Documents/Apollo10LMPadLoad.pdf">Apollo 10</a>.
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 <i>some</i>
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! <img
src="smiley.png" alt="" width="16" height="16"><br>
</td>
</tr>
<tr>
<td valign="top">2020-07-23<br>
</td>
<td valign="top">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 <i>complete</i> 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 <i>every</i>
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:<br>
<ul>
<li>Apollo 4</li>
<li>Apollo 5</li>
<li>Apollo 6</li>
<li>2TV-1</li>
<li>Apollo 8</li>
<li><font color="#ff0000">Apollo 9</font><br>
</li>
<li>Apollo 11</li>
<li>Apollo 15</li>
<li>Apollo 16</li>
<li>Apollo 17</li>
</ul>
<p>The presence of <font color="#ff0000">Apollo 9</font> 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.<br>
</p>
<p>Hand-waving or not, it's an interesting tale.
Long-time followers of this project may recall that the
Apollo 9 CM software (Colossus 249) was the 2nd AGC
software version to which we got access, and was the very
1st CM software version we got. But the principal
objective of the Apollo 9 mission was the first test of
the LM, in Earth orbit. Since the LM software
(Sundance 306) never seemed to be forthcoming, the fact
that we had only the CM software for Apollo 9 never seemed
tremendously exciting. <br>
</p>
<p>Many years passed without much change in this situation,
though <i>eventually</i>, interesting things. The
first stirrings, surprisingly, were in the realm of AGC
hardware rather than software:<br>
</p>
<ol>
<li>We managed to acquire complete electrical schematics
for the AGC, in many different revisions. <br>
</li>
<li>An (mostly-unaffiliated) project to restore a physical
AGC to working order for the 50th anniversary of the
Apollo 11 landing succeeded, ending up with a working
AGC. </li>
<li>The now-working AGC was used, among other things, to <i>dump</i>
the contents of memory modules from various museums and
personal collections. (And there are still more
modules to be dumped eventually, I'm told.) We
benefited from that effort by getting dumps of the
core-ropes from each of the 6 Sundance memory modules
... but <i>not</i> all from the same revision of
Sundance. Thus, instead of dumps of Sundance 306's
memory modules, we had some dumps from Sundance 292,
some from Sundance 302, some from Sundance 306.
And not all mutually-compatible with each other.</li>
<li>As of today, we have something much more exciting in a
software sense: a decompilation of those memory modules,
along with a reconciliation of their incompatibilities —
almost entirely shifts of the addresses fo variables and
code between different revisions. The result is
that we now have a complete, functioning Sundance
program. This program is still not Sundance
306: rather, it is a mogrelization of Sundance
292, 302, and 306. We call it <b>SundanceXXX</b>.
Mongrelized or not, SundanceXXX does function, properly
according to Apollo 9 documentation, and can be used
successfully to fly Apollo 9 missions in Orbiter/NASSP,
as well as in our native VirtualAGC UI.<br>
</li>
</ol>
<p>You can see a full write-up, including the SundanceXXX
source code, on <a href="Luminary.html#Sundance306">our
Luminary page</a>.<br>
</p>
<p>Thanks go to Mike Stewart for this great achievement,
with assistance by Nik Beug, abetted by the
AGC-restoration team, and of course gratitude to those
individuals and museums that allowed Mike to dump their
memory modules.<br>
</p>
<p>The next step in the process is to modify SundanceXXX in
such a way as to fully restore Sundance 306 itself.
Whether this proves possible remains to be seen, and we'll
just have to keep our fingers crossed. But in the
meantime, as I said, SundanceXXX is flyable. If
you're willing to accept it in that vein, we now have a
complete set of Apollo 9 software, albeit one whose
authenticity at the binary level may (hopefully!) be
improved later.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2020-07-05<br>
</td>
<td valign="top">Added <a href="faq.html#dumpster">an
amusing/horrifying anecdote</a> about LVDC documentation
to the FAQ page.<br>
</td>
</tr>
<tr>
<td valign="top">2020-06-27<br>
</td>
<td valign="top">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 <a href="links.html#FCC_schem">the
full write-up there</a>, but here's a summary:<br>
<ul>
<li><a href="Documents/GH-36-MSC-01829-19700220.pdf">Universal
Saturn Launch Vehicle Systems Handbook</a> for launch
vehicles AS-508 and subsequent.</li>
<li><a href="Documents/fcc_manual_as501.pdf">Technical
manual</a> and <a href="Documents/fcc_schematics.pdf">electrical
schematics</a> for the Saturn V and IB Flight Control
Computer (FCC). The former is Saturn V only, while
the latter covers various Saturn IB and V launch
vehicles. Recall that the Flight Control Computer
is an analog computer in the rocket's Instrumentation
Unit that can be controlled by the LVDC or the AGC.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-06-20<br>
</td>
<td valign="top">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 <i>care</i>
about are actually run, I need to make sure the silly tests
I <i>don't</i> 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.<br>
<br>
But I digress. The reason I'm writing today is due to
something found in <a
href="https://digitalsc.lib.vt.edu/Ms1989-029">the
collected papers of Mike Collins</a>, namely most of the <i>Gemini
Operations Handbook</i> 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 <a
href="links.html#Gemini_spacecraft_computer">our document
library</a>, or explore what we know about the Gemini
flight computer on <a href="Gemini.html">our Gemini page</a>,
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.<br>
<br>
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 <i>Final Gemini X Flight
Plan</i>; we already had a partial copy of the <i>Final
Gemini VIII Flight Plan</i>, but different parts parts of
that document are missing, so the two end up somewhat
complementing each other. Also, an MSC noted titled "<a
href="Documents/637614dc4266713c5f596d752881d3ba.pdf">Mission
H-1 Abort from Lunar Powered Descent and Subsequent
Rendezvous</a>"; 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. <img src="smiley.png" alt="" width="16"
height="16"><br>
</td>
</tr>
<tr>
<td valign="top">2020-05-18<br>
</td>
<td valign="top">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 <i>our</i> site.<br>
</td>
</tr>
<tr>
<td valign="top">2020-05-16<br>
</td>
<td valign="top">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.<br>
<br>
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 <i>zero</i>, so
disappointment that things didn't go my way is not much
excuse! At any rate, I've now belatedly taken care of
that:<br>
<ul>
<li><a
href="Documents/AS-503%20Operational%20Trajectory%20Appendix%20A.pdf">Excerpts
from the AS-503 Operational Trajectory document</a>
(namely, the pad loads) have been put in our document
library.</li>
<li>A write-up about the USSRC archives and the
photographic index I made there of LVDC-related material
has been added to our <a href="QuestForInfo.html">Quest
for Info page</a>. Or perhaps I should say
"semi-related"; or "marginally-related"; at any rate,
it's the stuff I was moved to take a picture of.<br>
</li>
</ul>
I've been spending all my time lately on getting the PTC
emulation up and running, so that the PTC ADAPT Self-Test
Program can be run in emulation. Specifically, I'm
working toward getting that original Apollo-era program's
self-test procedures to run, in emulation, in order to
validate our LVDC CPU emulator. Lots and lots of
progress has been made, but there's still a lot to do before
it's ready to go. I mention all this mainly as a
lead-in to point out that the documentation on the LVDC page
has been undergoing a steady revision because of that
effort. (And to excuse the fact that I'm only posting
updates to this site every couple of weeks. <img
src="smiley.png" alt="" width="16" height="16">)<br>
</td>
</tr>
<tr>
<td valign="top">2020-04-29<br>
</td>
<td valign="top">Well, it took a while, but <a
href="https://github.com/virtualagc/virtualagc/tree/master/yaASM.py">our
"modern" LVDC assembler (yaASM.py)</a> has now been
updated to assemble for a PTC target computer.
Moreover, <a
href="https://github.com/virtualagc/virtualagc/tree/master/PTC-ADAPT-Self-Test-Program">the
transcription of the PTC ADAPT Self-Test Program</a> 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, <a
href="LVDC.html">my online redigestion of how LVDC/PTC
assembly-language works</a> 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.<br>
<br>
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 <i>may</i>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2020-04-19<br>
</td>
<td valign="top">
<ul>
<li>You may recall that a month or so ago, we added a copy
of the LM-3 (Apollo 9) <a
href="Documents/LM-3_Systems_Handbook.pdf">Lunar
Module Systems Handbook</a> to our document
library. Today (thanks to Mike Stewart), we've
also been able to add the LM-3 <a
href="Documents/LM-3_Apollo_Operations_Handbook_Vol_I.pdf">Apollo
Operations Handbook</a>. All of these things add
to the tantalizing puzzle of Apollo 9's AGC
software. Way back at the beginning of the Virtual
AGC Project, the Apollo 9 CM software (COLOSSUS 249) was
almost the first AGC software available; we actually had
it at the same time as the Apollo 13 LM software
(LUMINARY 131), but I happened to choose to work with
the LM software first and the CM software second.
So if LUMINARY 131 is our project's α, then COLOSSUS 249
is its β. On the other hand, if the COLOSSUS
printout had been just a little more legible, and the
LUMINARY one a little less so, it could just as easily
have been the other way around. And if that's our
α, what's our ω? Or as discussions of alpha vs
omega always seem to put it, for some unknown reason,
our Ω? Well, <i>right now</i> that's the <a
href="Luminary.html#Sundance306">Apollo 9 LM software
(SUNDANCE 306)</a>. The "tantalizing mystery"
about it is that we don't have the source code for it,
though we do have the complete assembled, executable
form of it; not <i>entirely</i> in the correct
revision, mind you, but rather as a mixture of chunks
from SUNDANCE 292, 302, and 306. The puzzles are
how to recover a fully 306 executable from those bits
and pieces, and how subsequently to recover the source
code? Nobody knows ... yet! Once we do,
though, it will be great since we'll unambiguously have
<i>both</i> the CM <i>and</i> LM software for Apollo
9. α and ω (Ω), baby, the ultimate mystery!<br>
</li>
<li>Work on <a
href="https://raw.githubusercontent.com/virtualagc/virtualagc/master/PTC-ADAPT-Self-Test-Program/PTC-ADAPT-Self-Test-Program.lvdc">the
transcription of the source code for the PTC ADAPT
Self-Test Program</a> has also been proceeding apace,
though it's only about 2/3 completed at the
moment. In retrospect, I can see that these
change-notes on the topic have been rather piecemeal, so
that someone who's following the topic merely from these
notes, rather than from <a
href="LVDC.html#PTC_ADAPT_Self-Test_Program">the LVDC
page's discussion</a>, probably finds it confusing or
uninteresting, or both. Here's an executive
summary that perhaps makes it a little clearer:
The only Launch Vehicle Digital Computer (LVDC) software
we've had until recently is a program called the
AS206-RAM Flight Program which, while amazing in many
ways, <i>may</i> be restricted in distribution by a
U.S. regulation known as ITAR. Thus, out of
caution, I haven't so far been able to post it
online. But a couple of weeks ago, we found <i>another</i>
LVDC program, definitely <i>not</i> restricted by ITAR,
buried in some documents about the LVDC that we had
newly posted online. This new program is the PTC
ADAPT Self-Test Program, or as I call it for short, the
PAST program. What this turns out to be, if you
ignore some technical quibbles, is a program for the
LVDC which is similar in purpose to our "validation
suite" software for the AGC. I.e., it thoroughly
tests the LVDC's instruction set and various other
aspects of the CPU. Consequently, once a LVDC
emulator has been created, running the PAST program on
it may be the key to validating that the LVDC emulator
actually works as intended. Great stuff! But
still, it's just work-in-progress at the moment,
seasoned with speculation, so I don't want to oversell
it too much.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-04-15<br>
</td>
<td valign="top"><a
href="https://raw.githubusercontent.com/virtualagc/virtualagc/master/PTC-ADAPT-Self-Test-Program/PTC-ADAPT-Self-Test-Program.tsv">The
transcription of the "octal listing" for the PTC ADAPT
Self-Test Program</a> 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 <i>don't</i>
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.)<br>
<br>
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.<br>
<br>
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
<i>still</i> 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. <img
src="smiley.png" alt="" width="16" height="16"><br>
</td>
</tr>
<tr>
<td valign="top">2020-04-12<br>
</td>
<td valign="top">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 <a
href="https://github.com/virtualagc/virtualagc/tree/master/PTC-ADAPT-Self-Test-Program">an
almost-empty placeholder folder for it in our GitHub
repository</a>. 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 <a
href="LVDC.html#Pseudo-ops">my online descriptions of LVDC
pseudo-ops</a> and of <a
href="LVDC.html#CPU_Instructions">LVDC CPU instructions</a>
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
href="http://www.ibiblio.org/apollo/ScansForConversion/PTC%20ADAPT%20Self-Test%20Program.zip">a
zipfile of image files</a> for individual pages.<br>
</td>
</tr>
<tr>
<td valign="top">2020-04-11<br>
</td>
<td valign="top">The initial pass at creating <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a> 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 <a
href="http://www.ibiblio.org/apollo/6014999-091.html">the
Apollo 11 LM Guidance System</a>). 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.<br>
<br>
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 <i>other</i>
subassemblies of the guidance system are instead expanded to
a greater or lesser degree.<br>
<br>
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".<br>
<br>
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 <i>some</i> 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!).<br>
<br>
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. <a
href="http://www.ibiblio.org/apollo/6014999-091.html#2003993-031">For
example</a>, 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-<i>xxx</i>) 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.<br>
<br>
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. <img src="smiley.png" alt="" width="16"
height="16"><br>
<br>
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!<br>
</td>
</tr>
<tr>
<td valign="top">2020-04-08<br>
</td>
<td valign="top">
<ul>
<li>An anonymous correspondent has sent me notice of
modified Comanche 55 software (Apollo 11 CM AGC) to
implement the solution of the Google Foo.Bar Coding
Challenge's "Dodge the Lasers" problem. (If you've
never heard of any of those things — other than Comanche
55, of course — join the club! <img src="smiley.png"
alt="" width="16" height="16">) At any rate, you
can be the first kid on your block to view and/or run
the modified code <a href="faq.html#other_websites">by
following the hyperlinks for it on our FAQ page</a>. <br>
</li>
<li>There have been a number of updates to <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a> as well. <br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-04-06<br>
</td>
<td valign="top">
<ul>
<li>Some significant <a href="links.html#LVDC">LVDC/LVDA
documents</a> have been added to the document library,
disguised as maintenance and testing manuals for
laboratory equipment, and hence (embarrassingly)
initially rejected by me years ago when they were
proposed to me for inclusion in the document
library. How silly I was! <br>
</li>
<ul>
<li>Buried in one of the manuals is a large LVDC
self-test program (>50% the size of an LVDC flight
program), but whose "export" is <i>not</i> restricted
by ITAR since it's not guidance software! In
other words, you can actually look at it without
groveling to me personally and showing me your U.S.
citizenship documentation. Actually, the program
is not for the LVDC proper, but rather for a
ground-based device called the PTC, which contains a
"modified" LVDC CPU. But at this point it would
seem to be a reasonable hope that we can largely treat
it as an LVDC program. I expect we'll begin an
effort as well to transcribe the source code so that
the self-test program can be assembled, and perhaps
eventually even be run in simulation. <br>
</li>
<li>Buried in one of the <i>other</i> manuals is a
large set of LVDA electrical schematics, of which we
are otherwise ignorant.</li>
</ul>
<li><a href="LVDC.html#PTC_ADAPT_Self-Test_Program">The
LVDC page</a> has been updated to cover the PTC ADAPT
Self-Test Program (i.e., the software mentioned
above). The information right now is rather
sketchy, and presumably will be updated substantially in
the coming weeks or months.<br>
</li>
<ul>
</ul>
<li>In <a href="AgcDrawingIndexBox470.html">the index for
G&N aperture-card box 470</a>, several revisions
of (D, E, F) of drawing 6007019 had been miscoded as
drawing 6007018; that has been corrected.</li>
<li>Lots and lots of G&N assemblies have had their
bill-of-material information added, fleshing out <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">the
G&N assembly drilldowns</a>. But still
plenty more to do. There's <i>always</i> plenty
more of them to do.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-25<br>
</td>
<td valign="top">
<ul>
<li>Added the <a
href="Documents/LM-3_Systems_Handbook.pdf">LM-3
Systems Handbook</a> (Apollo 9) to our document
library. (Thanks, Mike Stewart!) This is
very timely, considering that we've just recently
acquired all of the top-level engineering drawings for
LM-3. And a bit humbling, since of all the
reference engineering-drawings listed as actual source
material for the Handbook, we have so far acquired none
at all. Still ... give it time!</li>
<li>I've added parts lists for a bunch of G&N system
assemblies, and regenerated <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">the
G&N assembly drilldowns</a> accordingly.
There's still a fair amount of work to do to finish them
up 100%, but it's progress.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-20<br>
</td>
<td valign="top">
<ul>
<li>Completed the process of adding all remaining drawing
titles to the index for LEM engineering-drawing <a
href="LemDrawingIndexBox523.html">box 523</a>.
All LEM indexes are now completely up-to-date with
respect to drawing titles ... until we can begin adding
more scans.<br>
</li>
<li>I noticed belatedly that we now have all upper-level
drawings not just for LM-3 (as mentioned in my preceding
update), but for all LTAs and for LM-1 and LM-2 as
well. (As well as the topmost drawing for LM-4,
but none of the drawings below it.) I've
consequently added <a
href="ElectroMechanical.html#LEM_Engineering_Drawings">an
explicit list of links to all those things</a>, as
opposed to forcing folks to ferret them out for
themselves.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-18<br>
</td>
<td valign="top">Added some (but not yet all) drawing titles
to LEM engineering-drawing <a
href="LemDrawingIndexBox523.html">box 523</a>, the last
aperture-card box I managed to scan before the National
Archives was closed to the public as a COVID-19
precaution. (Hint: There won't be any new LEM
scans until ... sometime.) However, in the process of
adding these titles to the index, I noted that the box
contains the top-level drawings — well, perhaps not the very
topmost drawing; it's difficult to tell — for LM-3 (Apollo
9). <a href="LemDrawingIndexBox523.html#LM-3">They
begin with LDW280-53000</a>. That's nice, given that
it may be quite a while before any more scans can be
made. Better than nothing, anyway.<br>
</td>
</tr>
<tr>
<td valign="top">2020-03-12<br>
</td>
<td valign="top">
<ul>
<li>Added drawing titles to the index for LEM
engineering-drawing <a
href="LemDrawingIndexBox522.html">box 522</a> (scanned
2 days ago).</li>
<li>Added newly-scanned LEM <a
href="LemDrawingIndexBox523.html">box 523</a> (not yet
with drawing titles added to the index page).</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-10<br>
</td>
<td valign="top">
<ul>
<li>Added drawing titles to the index for LEM
engineering-drawing <a
href="LemDrawingIndexBox521.html">box 521</a> (scanned
last week).</li>
<li>Added newly-scanned LEM <a
href="LemDrawingIndexBox522.html">box 522</a> (not yet
with drawing titles added to the index page).</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-09<br>
</td>
<td valign="top">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 <i>every</i> PDF that needs
searchable text added to it, but it's good progress.
(If anyone feels the absolute need for a list, I'll send you
one, but it seems rather pointless to me to post one
online. It's not as if anybody has been clamoring for
this.)<br>
</td>
</tr>
<tr>
<td valign="top">2020-03-07<br>
</td>
<td valign="top">
<ul>
<li>Added grayscale rescans for the illegible B&W
scans in <a href="LemDrawingIndexBox518.html">box 518</a>.
(Actually, for a couple of the Engineering Orders, I
accidentally rescanned the wrong slides. So
there's still a bit of work to do to make it complete
... perhaps I'll get around to doing it someday!)</li>
<li>Added a bunch of revisions of <a
href="links.html#From_MIT_Instrumentation_Laboratory">MIT/IL
document E-1142</a>, the guidance system "weight and
balance" report, to the document library.
Actually, these reports cover a lot more than just
weight and balance, such as electrical draw of different
hardware modules, sizes of AGC software modules,
etc. Each "revision" covers a separate month, or
(early and late in the project) a separate several-month
period. We already had a bunch of these in the
library, but now we have a bunch more ... possibly a
complete set of them, from 1962 through 1969.
Unfortunately, neither these PDF documents, nor
70-FM-145 (added a week or so ago) have searchable text,
due to technical difficulties. I'm sure there are
plenty of other documents in the library about which the
same could be said, so it's not as if it's a tragedy,
but it's slightly annoying.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-04<br>
</td>
<td valign="top">
<ul>
<li>Added drawing titles to the index for LEM
engineering-drawing <a
href="LemDrawingIndexBox520.html">box 520</a> (scanned
yesterday).</li>
<li>Added newly-scanned LEM <a
href="LemDrawingIndexBox521.html">box 521</a> (not yet
with drawing titles added to the index page).</li>
<li>A couple of weeks back, I had changed the location (on
the electro-mechanical page) of the table of LEM
aperture-card boxes, but had foolishly forgotten to
account for the fact that all of the LEM
engineering-drawing index pages continued to use the
obsolete link. The LEM index pages hopefully have
the correct link now, and I've taken the opportunity to
provide a link to the master LEM drawing index file on
those index pages as well.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-03-03<br>
</td>
<td valign="top">
<ul>
<li>Added drawing titles to the index for LEM
engineering-drawing <a
href="LemDrawingIndexBox519.html">box 519</a> (scanned
last week).</li>
<li>Added newly-scanned LEM <a
href="LemDrawingIndexBox520.html">box 520</a> (not yet
with drawing titles).</li>
</ul>
Incidentally, it's worth noting that since the addition of
LEM box 518 a few days ago, the LEM-drawing scanning effort
is now into a region of the aperture-card boxes in which we
have the top-level drawing for LTA-8, and lots of
upper-level drawings for it as well. It's true, I'm
sure, that people in general aren't as interested in LTA-8
as in a "real" LEM — "LTA" stands for Lunar Test Article
—but one shouldn't shouldn't disrespect LTA-8!<br>
</td>
</tr>
<tr>
<td valign="top">2020-03-02<br>
</td>
<td valign="top">Drawing titles added to the index page for
LEM engineering-drawing <a
href="LemDrawingIndexBox518.html">box 518</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2020-03-01<br>
</td>
<td valign="top">Finished added drawing titles to the index
page for LEM engineering drawings box <a
href="LemDrawingIndexBox517.html">517</a>, and indexed all
of its grayscale rescans as well.<br>
</td>
</tr>
<tr>
<td valign="top">2020-02-29<br>
</td>
<td valign="top">
<ul>
</ul>
Updated the index pages for LEM engineering drawing scans to
include the grayscale rescans for aperture-card boxes <a
href="LemDrawingIndexBox511.html">511</a>, <a
href="LemDrawingIndexBox512.html">512</a>, <a
href="LemDrawingIndexBox513.html">513</a>, <a
href="LemDrawingIndexBox514.html">514</a>, <a
href="LemDrawingIndexBox515.html">515</a>, and <a
href="LemDrawingIndexBox516.html">516</a>.</td>
</tr>
<tr>
<td valign="top">2020-02-28<br>
</td>
<td valign="top">
<ul>
<li>And similarly to yesterday, I've uploaded the grascale
rescans for LEM boxes 515 through 517 our Internet
Archive site, though I've not yet updated the
LEM-drawing index pages, but you can directly browse
those scans here: box <a
href="https://archive.org/details/rescans515images">515</a>,
<a href="https://archive.org/details/rescans516images">516</a>,
<a href="https://archive.org/details/rescans517images">517</a>.</li>
<li>Added a new document scan to the document
library: <a href="Documents/70-FM-145.pdf">70-FM-145</a>,
"RTCC Requirements for Apollo 14 (Mission H-3): LOI
Targeting".<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-27<br>
</td>
<td valign="top">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 <a
href="https://archive.org/details/rescans511images">511</a>,
<a href="https://archive.org/details/rescans512images">512</a>,
<a href="https://archive.org/details/rescans513images">513</a>,
and <a href="https://archive.org/details/rescans514images">514</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="top">2020-02-26<br>
</td>
<td valign="top">
<ul>
<li>Added scans for LEM aperture-card <a
href="LemDrawingIndexBox519.html">box 519</a>.</li>
<li>Added drawing titles to index for LEM aperture-card <a
href="LemDrawingIndexBox516.html">box 516</a>, and for
a little less than half of <a
href="LemDrawingIndexBox517.html">box 517</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-25<br>
</td>
<td valign="top">
<ul>
<li>Added scans for LEM aperture-card <a
href="LemDrawingIndexBox518.html">box 518</a>.</li>
<li>Added drawing titles to index for LEM aperture-card <a
href="LemDrawingIndexBox515.html">box 515</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-24<br>
</td>
<td valign="top">
<ul>
<li>Added the drawing titles to the index page and master
index for LEM aperture-card box 514.</li>
<li>Corrected a number of errors in drawing titles that I
hadn't noticed before.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-22<br>
</td>
<td valign="top">
<ul>
<li>Added the drawing titles to the index page for LEM
aperture-card box 513, and made a handful of corrections
associated with that effort.</li>
<li> On the electro-mechanical page, I've separated the
LEM engineering drawings from the miscellaneous
engineering drawings, so that there are now two separate
sections on the page where there was only one
previously: <a
href="ElectroMechanical.html#LEM_Engineering_Drawings">LEM
Engineering Drawings</a> and <a
href="ElectroMechanical.html#Additional_Engineering_Drawings">Additional
Apollo Engineering Drawings</a>. I hope that
will make it a little easier to navigate, if only by an
admittedly <i>very</i> tiny bit.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-21<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2020-02-20<br>
</td>
<td valign="top">Added a complete set of scans of LEM drawings
from aperture-card <a href="LemDrawingIndexBox517.html">Box
517</a>.</td>
</tr>
<tr>
<td valign="top">2020-02-19<br>
</td>
<td valign="top">
<ul>
<li>Added a complete set of scans of LEM drawings from
aperture-card <a href="LemDrawingIndexBox516.html">Box
516</a>. Anyone who loved Box 515 for the fact
that it was beginning to contain higher-level assembly
drawings as opposed to simple fabricated parts will
probably love Box 516 even more. Unfortunately, I
won't get around to manually entering all of the drawing
titles for either of those boxes for a while.<br>
</li>
<li>Grayscale rescans have been completed for the
aperture-cards whose initial B&W scans in Boxes 507
through 510 were illegible, though I probably won't be
able to update the index pages for those boxes (or the
master index) until the weekend. For anyone who
just can't bear to wait that long, and are willing to
browse the scans unindexed, go to <a
href="https://archive.org/details/virtualagcproject">our
Internet Archive site</a> and in the "Search this
Collection" box use the search string "Box 507" (or "Box
508", or ...). Of course, some of the rescans are
<i>still</i> illegible, when the microfilm itself is out
of focus or has some other problem, but for the most
part the rescans have been usable ... albeit with some
effort in a few cases. <br>
</li>
<li>Hartmuth (thanks!) has added in all of drawing titles
for aperture-card Box 512.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-14<br>
</td>
<td valign="top">
<ul>
<li>Added a complete set of scans of LEM drawings from
aperture-card <a href="LemDrawingIndexBox515.html">Box
515</a>. Note that this is now getting into the
LDW280-2<i>XXXX</i> drawings, which seems to include
many higher-level drawings, as opposed to drawings of
small parts like angles or channels or shims.</li>
<li> A duplicate slide for the corrupted drawing
"LDW280-17" from Box 503 has been found in Box 512; it
is really drawing LDW280-17847, and the Box 503 index
has been corrected accordingly.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-12<br>
</td>
<td valign="top">
<ul>
<li>Finished scanning remainder of LEM drawings from
aperture-card <a href="LemDrawingIndexBox513.html">Box
513</a>.</li>
<li>Added a complete set of scans of LEM drawings from
aperture-card <a href="LemDrawingIndexBox514.html">Box
514</a>.</li>
<li>Added a handful of grayscale rescans for
previously-illegible B&W LEM scans from Box 507,
although there are many rescans still needed in that
box.</li>
<li>Finished up added all drawing titles to the index page
for LEM aperture-card Box 511.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-09<br>
</td>
<td valign="top">In Box 510, finished added drawing titles and
marking illegible scans for eventual rescan. Began
performing similar work on Box 511 as well. All of the
previous LEM boxes have contained only simple building-block
parts, except for cards that had accidentally been filed in
the wrong boxes, but in 511 we begin to see some drawing of
significant complexity, such as LDW280-17388 (the
descent-stage fuel-lines diagram, >300 scans) and
LDW280-17389 (the environmental system piping diagram, ~70
scans).<br>
</td>
</tr>
<tr>
<td valign="top">2020-02-07<br>
</td>
<td valign="top">
<ul>
<li>Finished scanning remainder of LEM drawings from
aperture-card <a href="LemDrawingIndexBox512.html">Box
512</a>.</li>
<li>Added scans for 90% or so of LEM drawings from
aperture-card <a href="LemDrawingIndexBox513.html">Box
513</a>.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-04<br>
</td>
<td valign="top">
<ul>
<li>Finished scanning remainder of LEM drawings from
aperture-card <a href="LemDrawingIndexBox511.html">Box
511</a>.</li>
<li>Added scans for 80% or so of LEM drawings from
aperture-card <a href="LemDrawingIndexBox512.html">Box
512</a>.</li>
<li>Completed adding grayscale rescans for illegible
existing B&W images in LEM drawings in aperture-card
Boxes <a href="LemDrawingIndexBox503.html">503</a> and
<a href="LemDrawingIndexBox504.html">504</a>.</li>
<li>On <a href="faq.html">the FAQ page</a>, added a link
to <a
href="Documents/dobson_mosteirin_moonbit_ebook.pdf.pdf"><i>Moonbit</i></a>,
by James E. Dobson and Rena J. Mosteirin. This a
small book of (and about) "<a
href="https://en.wikipedia.org/wiki/Erasure_%28artform%29">erasure
poetry</a>" based on the AGC software. Culture,
baby, culture!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-02-03<br>
</td>
<td valign="top">The aperture-card scanner is finally
available again, so some new scans of LEM drawings have been
added:<br>
<ul>
<li>Aperture-card <a href="LemDrawingIndexBox510.html">Box
510</a> ... not including rescans of images that were
illegible on the first pass through the box. A
little but not all of the index has had drawing-titles
added and illegible scans marked.<br>
</li>
<li>Approximately 75% of aperture-card <a
href="LemDrawingIndexBox511.html">Box 511</a>.</li>
<li>Rescans in grayscale of aperture cards from Boxes 502,
503, 504, 505, 506, and 507. Some cards in 503,
504, and 507 remain to be rescanned.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2020-01-09<br>
</td>
<td valign="top">
<ul>
<li>Added Apollo G&N System assembly-drilldowns for
various assemblies not previously covered. (Still
lots of them to be done for various non-computer G&N
assemblies, even though the AGC and DSKY drilldowns are
pretty complete! But making slow progress over
time.)</li>
<li> Cleaned up the underlying change-log file in other
ways that hopefully will be transparent to the reader.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2019" onchange="viewOrHide(2019)" autocomplete="off"
checked="checked" type="checkbox"><b>Hide 2019 change notes?</b>
<table summary="" id="table2019" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top">2019-12-30<br>
</td>
<td valign="top">Added engineering-drawing titles and marked
illegible scans in LEM aperture-card <a
href="LemDrawingIndexBox502.html">box 502</a>.
(Thanks, Hartmuth!) This actually completes the
indexing for all LEM aperture-card boxes that have been
scanned <i>so far</i>, >15K scans ... but keep in mind
that's only 8 boxes out of the 280 total LEM boxes.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-29<br>
</td>
<td valign="top">
<ul>
<li>Added engineering-drawing titles and marked illegible
scans in LEM aperture-card <a
href="LemDrawingIndexBox509.html">box 509</a>.</li>
<li>I've noticed somewhat belatedly that our Virtual AGC
home page, which brags quite a bit about — excuse me, I
mean humbly mentions, almost as an aside — the various
materials the project provides, failed to mention the
LEM engineering drawings. I've corrected that
oversight.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-12-27<br>
</td>
<td valign="top">Added engineering-drawing titles and marked
illegible scans in LEM aperture-card <a
href="LemDrawingIndexBox508.html">box 508</a>.</td>
</tr>
<tr>
<td valign="top">2019-12-23<br>
</td>
<td valign="top">Added engineering-drawing titles and marked
illegible scans in LEM aperture-card <a
href="LemDrawingIndexBox507.html">box 507</a>. Fixed
a number of erring revision codes and sheet numbers in boxes
503-506 as well.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-22<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-20<br>
</td>
<td valign="top">
<ul>
<li>The engineering-drawing titles for LEM aperture-card <a
href="LemDrawingIndexBox506.html">box 506</a> have
been added. I've also started inventorying and
marking scans which are too illegible for one reason or
another (usually due to being too light to fully read),
so that's been done here as well.</li>
<li>Retroactively marked the illegible scans in LEM
aperture-card box 503, to which I had previously added
the titles a week ago, as well as finding/fixing an
incorrect drawing number or two that I missed on the
first pass through the box.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-12-19<br>
</td>
<td valign="top">
<ul>
<li>A table of 50 or so LEM engineering drawings that was
previously gratuitously stuck at the end of the <a
href="AgcDrawingIndex.html">page for miscellaneous
G&N engineering drawings</a>, for lack of a better
place to put it, has now been removed to its own
dedicated <a href="LemDrawingMiscellaneous.html">page
for miscellaneous LEM engineering drawings</a>.
I suppose this reorganization doesn't need any serious
justification ... nevertheless, it was done because I
now recognize the need to eventually rescan a fairly
significant number of LEM aperture cards whose initial
scans are not legible enough. The new
miscellaneous LEM page will be a good place for those
rescans to live.</li>
<li> Although there will be no "search engine" for the LEM
engineering-drawing scans like the one for the G&N
scans — simply because the search database would be too
big to reasonably load into a browser with the current
situation <i>vis-</i><i>à</i><i>-vis</i> network
bandwidth, computer memory, and so on — I've belatedly
realized that there's no reason I can't provide such an
index as a non-browser file that you can explicitly
download, load into a spreadsheet, etc. So I've
added a <a href="LemDrawingIndex.tsv">master LEM
engineering-drawing index file</a>. I expect
this file will eventually exceed 60MB in size — which
should give you some idea why I don't think you'd want
to load it into your browser — though right now it's in
the neighborhood of just 2MB. Since the project of
scanning the LEM drawings and indexing them is ongoing,
the master-index file is naturally a work-in-progress as
well!</li>
<li>Added the titles for engineering drawings in LEM
aperture-card <a href="LemDrawingIndexBox505.html">box
505</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-12-16<br>
</td>
<td valign="top">Added the scans of LEM engineering drawings
from aperture-card <a href="LemDrawingIndexBox509.html">Box
509</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-14<br>
</td>
<td valign="top">Added the engineering-drawing titles for LEM
<a href="LemDrawingIndexBox504.html">Box 504</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-13<br>
</td>
<td valign="top">
<ul>
<li>Added the scans of LEM engineering drawings from
aperture-card <a href="LemDrawingIndexBox508.html">Box
508</a>. <br>
</li>
<li>Added the engineering-drawing titles in LEM <a
href="LemDrawingIndexBox503.html">Box 503</a>.
This is the first LEM box whose title-addition has been
completed (though Hartmuth is working on Box 502 as
well), and as such is likely to have some teething
problems ... but whether or not that turns out to be the
case, it's still a lot better than having no
titles. A handful of drawing numbers and/or titles
are missing or partial for a variety of reasons, such as
the scan just being too light or the sheets containing
the titles being in aperture-card boxes that haven't yet
been scanned. So expect there will be still be
some improvements in that area in the coming months or
years as additional scans dribble in.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-12-11<br>
</td>
<td valign="top">Added the scans of LEM engineering drawings
from aperture-card <a href="LemDrawingIndexBox507.html">Box
507</a>. 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. <br>
</td>
</tr>
<tr>
<td valign="top">2019-12-10<br>
</td>
<td valign="top">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 <i>numbers</i> (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
them. <br>
</td>
</tr>
<tr>
<td valign="top">2019-12-09<br>
</td>
<td valign="top">Drawing titles corrected for aperture-card
boxes 454, 455, and 456.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-07<br>
</td>
<td valign="top">Drawing titles corrected for aperture-card
boxes 451, 452, and 453.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-06<br>
</td>
<td valign="top">Drawing titles corrected for aperture-card
box 450.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-05<br>
</td>
<td valign="top">Added several boxes of LEM engineering
drawings: <a href="LemDrawingIndexBox504.html">Box
504</a>, <a href="LemDrawingIndexBox505.html">Box 505</a>,
<a href="LemDrawingIndexBox506.html">Box 506</a>. As
indicated in previous comments, the indexes won't initially
include drawing titles, since those have to be manually
input.<br>
</td>
</tr>
<tr>
<td valign="top">2019-12-03<br>
</td>
<td valign="top">Added a couple of RTCC-related <a
href="links.html#Miscellaneous_Mission_Documents">mission-specific
documents</a> (AS-207/208 and AS-503A/504A) to the
document library.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-30<br>
</td>
<td valign="top">With the completion of scans of the MIT
G&N System engineering drawings last week, scanning of
GAEC (Grumman) LM engineering drawings has now
commenced. <br>
<br>
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 <i>still</i> 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 <a href="LemDrawingIndexBox502.html">Box
502</a> and <a href="LemDrawingIndexBox503.html">Box 503</a>.
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.<br>
<br>
<i>Unfortunately,</i> 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.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-22<br>
</td>
<td valign="top">Finished correcting all engineering-drawing
titles for aperture-card boxes 474-477. That <i>doesn't</i>
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 <i>tout suite</i>. <img
src="smiley.png" alt="" width="16" height="16"> <br>
</td>
</tr>
<tr>
<td valign="top">2019-11-21<br>
</td>
<td valign="top">Completed scanning aperture-card <a
href="AgcDrawingIndexBox476.html">box 476</a>, plus <a
href="AgcDrawingIndexBox477.html">box 477</a>. 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 <i>all</i> available CM/LM G&N drawings.
As far as we know. There's always the possibility of
aperture-cards being stashed in the <i>wrong</i> 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.<br>
<br>
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.<br>
<br>
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 <i>eventually</i>
become available via other mechanisms without any
intervention be me (thank goodness!), but "eventually" is a
rather open-ended concept in this case.<br>
<br>
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., <a href="TipueSearch.html">master
engineering search engine or</a> aperture-card box index
pages) as the other drawings. As a result, instead of
including them on <a href="AgcDrawingIndexBox477.html">the
box 477 page</a>, I've segregated them onto <a
href="ElectroMechanical.html#Additional_Engineering_Drawings">a
separate "Additional Engineering Drawing" portal</a>, 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. <img src="smiley.png" alt="" width="16"
height="16"><br>
</td>
</tr>
<tr>
<td valign="top">2019-11-20<br>
</td>
<td valign="top">Completed scanning aperture-card <a
href="AgcDrawingIndexBox475.html">box 475</a> and about
95% of <a href="AgcDrawingIndexBox476.html">box 476</a>. <br>
</td>
</tr>
<tr>
<td valign="top">2019-11-19<br>
</td>
<td valign="top">Completed scanning aperture-card <a
href="AgcDrawingIndexBox474.html">box 474</a> and about
80% of <a href="AgcDrawingIndexBox475.html">box 475</a>.</td>
</tr>
<tr>
<td valign="top">2019-11-18<br>
</td>
<td valign="top">Finished updating JDC document titles in box
473, as well as a few in 474.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-17<br>
</td>
<td valign="top">Updated various JDC document titles in box
473.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-15<br>
</td>
<td valign="top">Completed scanning aperture-card <a
href="AgcDrawingIndexBox473.html">box 473</a> and about
50% of <a href="AgcDrawingIndexBox474.html">box 474</a>.</td>
</tr>
<tr>
<td valign="top">2019-11-14<br>
</td>
<td valign="top">Completed scanning aperture-card <a
href="AgcDrawingIndexBox472.html">box 472</a> and about
40% of <a href="AgcDrawingIndexBox473.html">box 473</a>.
Box 472 is actually the <i>end</i> 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 <a
href="https://archive.org/details/apertureCardBox472GrummanNARASW_images">archive
of their scans</a>, I've made no attempt to actually index
any of them.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-13<br>
</td>
<td valign="top">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 <a href="AgcDrawingIndexBox449.html">index
page for box 449</a>. 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-12<br>
</td>
<td valign="top">Corrected drawing titles for aperture-card
boxes 445 and 446. Various <a
href="Documents/assist.dla.mil/AgcDrawingIndexMilSpec.html">mil-spec
drawings</a> added, as referenced by recently-added
engineering drawings.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-11<br>
</td>
<td valign="top">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 <i>trust</i> the drawing numbers punched in the
aperture cards, and to assume that only the drawing <i>titles</i>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-10<br>
</td>
<td valign="top">Corrected drawing titles for aperture-card
boxes 441 and 442.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-09<br>
</td>
<td valign="top">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 <i>that</i> 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 <i>without</i>
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 <a
href="AgcDrawingIndexBox439.html">box 439 index page</a>,
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
process.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-08<br>
</td>
<td valign="top">Completed scanning Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox470.html">box 470</a>, added the
entire <a href="AgcDrawingIndexBox471.html">box 471</a>,
and about 5% of <a href="AgcDrawingIndexBox472.html">box
472</a>. 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
next week. <br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-06<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox469.html">box 469</a> and added <i>almost</i>
(but not <i>quite</i>) all of <a
href="AgcDrawingIndexBox470.html">box 470</a>.</td>
</tr>
<tr>
<td valign="top">2019-11-05<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox468.html">box 468</a> and added
about the initial 90% of <a
href="AgcDrawingIndexBox469.html">box 469</a>.</td>
</tr>
<tr>
<td valign="top">2019-11-04<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox457.html">box 457</a> and added
about the initial 75% of <a
href="AgcDrawingIndexBox468.html">box 468</a>.
(Boxes 458-467 had already been scanned previously.)<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-03<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-11-01<br>
</td>
<td valign="top">
<ul>
<li>Completed adding Apollo G&N engineering drawings
from aperture-card <a href="AgcDrawingIndexBox456.html">box
456</a> and added about the initial 60% of <a
href="AgcDrawingIndexBox457.html">box 457</a>. A
handful of additional assemblies were also added to the
<a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">assembly
drilldowns</a>.</li>
<li>Modified the instructions for building Virtual AGC on
the Raspberry Pi for the latest version of the operating
system (Raspbian Buster).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-10-31<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox454.html">box 454</a>, added the
entire <a href="AgcDrawingIndexBox455.html">box 455</a>,
and added about the initial 25% of <a
href="AgcDrawingIndexBox456.html">box 456</a>. A
handful of additional assemblies were also added to the <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">assembly
drilldowns</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-29<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox453.html">box 453</a>, and added
the first 95% or so of <a href="AgcDrawingIndexBox454.html">box
454</a>, and added some additional assemblies to the <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">assembly
drilldowns</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-28<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox452.html">box 452</a>, and added
the first 80% or so of <a href="AgcDrawingIndexBox453.html">box
453</a>.</td>
</tr>
<tr>
<td valign="top">2019-10-25<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox451.html">box 451</a>, and added
the first 60% or so of <a href="AgcDrawingIndexBox452.html">box
452</a>.</td>
</tr>
<tr>
<td valign="top">2019-10-24<br>
</td>
<td valign="top">Completed adding Apollo G&N engineering
drawings from aperture-card <a
href="AgcDrawingIndexBox450.html">box 450</a>, and added
the first third or so of <a
href="AgcDrawingIndexBox451.html">box 451</a>. We've
now surpassed 60K scans of engineering drawings in the
library, though that's a little less than 8K unique drawing
numbers.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-23<br>
</td>
<td valign="top">I had intentionally, temporarily omitted 78
scans of North American Aviation "Interface Revisions
Notices" from <a href="AgcDrawingIndexBox431.html">aperture-card
Box 431</a>. 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-22<br>
</td>
<td valign="top">
<ul>
<li>Completed scans of Apollo G&N engineering drawings
from aperture-card <a href="AgcDrawingIndexBox448.html">Box
448</a>.</li>
<li>Added complete scans from <a
href="AgcDrawingIndexBox449.html">Box 449</a>.</li>
<li>Added scans of the initial part of <a
href="AgcDrawingIndexBox450.html">Box 450</a>.</li>
<li>Regenerated <a href="TipueSearch.html">engineering-drawing
search engine</a> and <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-10-21<br>
</td>
<td valign="top">Completed scans from aperture-card <a
href="AgcDrawingIndexBox447.html">Box 447</a>, along with
almost all of of <a href="AgcDrawingIndexBox448.html">Box
448</a>. As usual, the hyperlinks at our Internet
Archive site may take a while to become "live". The <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a> were regenerated.</td>
</tr>
<tr>
<td valign="top">2019-10-18<br>
</td>
<td valign="top">Completed scans from aperture-card <a
href="AgcDrawingIndexBox446.html">Box 446</a>, along with
the initial half (and a tad more) of <a
href="AgcDrawingIndexBox447.html">Box 447</a>. As
usual, the hyperlinks at our Internet Archive site may take
a while to become "live". The <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a> were regenerated.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-17<br>
</td>
<td valign="top">Completed scans from aperture-card <a
href="AgcDrawingIndexBox445.html">Box 445</a>, along with
the initial half (and a tad more) of <a
href="AgcDrawingIndexBox446.html">Box 446</a>. As
usual, the hyperlinks at our Internet Archive site may take
a while to become "live". Various assemblies were also added
to the <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a>.</td>
</tr>
<tr>
<td valign="top">2019-10-16<br>
</td>
<td valign="top">Completed scans from aperture-card <a
href="AgcDrawingIndexBox444.html">Box 444</a> and scanned
the initial 25% or so of <a
href="AgcDrawingIndexBox445.html">Box 445</a>. 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 <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a>.</td>
</tr>
<tr>
<td valign="top">2019-10-15<br>
</td>
<td valign="top">Added scans from remainder of Apollo G&N
engineering drawings from aperture-card <a
href="AgcDrawingIndexBox442.html">Box 442</a>, the
entirety of <a href="AgcDrawingIndexBox443.html">Box 443</a>,
and the initial 5% or so of <a
href="AgcDrawingIndexBox444.html">Box 444</a>. 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 <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">G&N
assembly drilldowns</a>. <br>
</td>
</tr>
<tr>
<td valign="top">2019-10-14<br>
</td>
<td valign="top">Updated the drawing titles for aperture-card
boxes <a href="AgcDrawingIndexBox431.html">431</a> and <a
href="AgcDrawingIndexBox432.html">432</a>, 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 <i>every</i> 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
guess.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-12<br>
</td>
<td valign="top">Added the remainder of the Apollo G&N
engineering drawings from aperture-card <a
href="AgcDrawingIndexBox441.html">Box 441</a>, plus about
the initial 80% of <a href="AgcDrawingIndexBox442.html">Box
442</a>. Some additional updates to <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">assembly
drilldowns</a>. <br>
</td>
</tr>
<tr>
<td valign="top">2019-10-11<br>
</td>
<td valign="top">Added the remainder of the Apollo G&N
engineering drawings from aperture-card <a
href="AgcDrawingIndexBox440.html">Box 440</a>, plus about
the initial 60% of <a href="AgcDrawingIndexBox441.html">Box
441</a>. Some additional updates to <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">assembly
drilldowns</a>. 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
completed.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-10<br>
</td>
<td valign="top">Scanned remainder of <a
href="AgcDrawingIndexBox439.html">Box 439</a> and initial
40% of <a href="AgcDrawingIndexBox440.html">Box 440</a> of
Apollo G&N engineering drawings. Some updates to
the <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">assembly
drilldowns</a>, 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-09<br>
</td>
<td valign="top">Scanned Apollo G&N engineering drawings
from aperture-card <a href="AgcDrawingIndexBox438.html">Box
438</a> (full contents) and <a
href="AgcDrawingIndexBox439.html">Box 439</a> (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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-10-06<br>
</td>
<td valign="top">
<ul>
</ul>
<b>Important note:</b> Email is no longer being
received on the main email account (info@sandroid.org)
associated with this website. I have been trying to
resolve it with my provider for about a week. If
you've sent an email and I have not responded, I apologize
... I haven't seen it yet. My provider claims to be
working on it. But the upshot is that right now it's a
mess. If you are too impatient to wait for a
resolution of the problem, you can email me at <tt>r b u r
k e y 2 0 0 5 @ e a r t h l i n k . n e t</tt>.
(You'll have to remove the spaces from the address, which
I've added in a half-hearted attemped to foil malicious
bots.)<br>
<br>
On a more-positive note:<br>
<ul>
<li>Several new MSC internal notes (64-FM-55, 65-FM-57,
and 64-FM -74) were added to <a
href="links.html#Gemini_spacecraft_computer">the
Gemini section</a> of the document library. They
relate to algorithms (with flowcharts) for computation
of trajectories. Though these were written for
Gemini, they apparently remained the gold standard for
Apollo, and are referenced in some of the Apollo docs
recently added to the library.</li>
<li>Scans for NARA-SW aperture-card Boxes <a
href="AgcDrawingIndexBox431.html">431</a> (partial), <a
href="AgcDrawingIndexBox432.html">432</a>, <a
href="AgcDrawingIndexBox433.html">433</a>, <a
href="AgcDrawingIndexBox436.html">436</a>, and <a
href="AgcDrawingIndexBox437.html">437</a> have been
added to the collection of engineering drawings.
Box 431 is particularly notable because it contains a
number of Rework Instruction Bulletins (RIB), of which
very few have been available previously. Box 431
also physically contains a few dozen Interface Control
Drawings from North American Aviation, but because these
follow a different numbering convention than all of the
MIT/AC/Ratheon/etc. aperture cards scanned so far, I
have not yet worked out how they should be processed or
presented, so I've not yet made them available online
... which is the reason that Box 431 is listed as being
only "partial". Besides that, because of the bulk
of scans that <i>have</i> been added (~9000 microfilm
slides), I've not had the opportunity to fix up the
titles of most of the drawings. For now, most of
the titles just show up in the index in the 21-character
abbreviated forms punched into the aperture cards.
I'll fix them up some time, but it's an ongoing process
and I won't promise any specific time-table.</li>
</ul>
<p>Note that while the newly-added engineering drawings have
been used to update <a href="TipueSearch.html">the
drawing-index page</a> and <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">the
various assembly drilldowns for different G&N System
configurations</a>, the latter have only been <i>partially</i>
updated because their bills-of-material have not yet been
transcribed ... i.e., newly added <i>assemblies</i> 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.<br>
</p>
<ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-09-28<br>
</td>
<td valign="top">
<ul>
<li>NARA-SW aperture-card <a
href="AgcDrawingIndexBox434.html">Box 434</a> has now
been scanned. This box contains just a handful of
items (though with lots of revisions and pages each), so
I'll list them all here. They're all Apollo
guidance & navigation system checkout procedures for
various spacecraft:<br>
</li>
<ul>
<li>Document ND1002323 (revisions J and later), for the
LM, running AURORA software.<br>
</li>
<li>Document ND1002324 (all revisions), for the Block I
CM (specifically, CM-014), running SUNSPOT
software. According to <a
href="hrst/archive/1690.pdf">this document</a> (p.
15), CM-014 was used only for testing and was
eventually scrapped in 1977. Since the CM was
never used for anything other than testing, it's
entirely possible that its AGC still had SUNSPOT ropes
in it when the CM scrapped, and thus it seems possible
that that Block I AGC (or its rope-modules separately)
are still floating around somewhere. In other
words, SUNSPOT may be recoverable by dumping the
contents of those rope modules, if they (and/or their
AGC) are ever found. Unfortunately, I neither
know where the AGC nor its rope modules are, nor do I
know of anyone who has <i>successfully</i> dumped the
contents of Block I rope modules. I wish I did.<br>
</li>
<li>Document ND1002325 (revisions W and earlier), for
the Block II CM, running SUNDIAL C or D software.</li>
</ul>
<li>Similarly, the <i>first half</i> of NARA-SW
aperture-card <a href="AgcDrawingIndexBox433.html">Box
433</a> has also been scanned. It contains many
more documents than Box 434, so I won't list them all
here. They are principally process specifications
and testing procedures. The most-notable document,
I think, is ND1002319, "ACE-S/C Computer Subprogram
Specifications for Apollo CM and LM G&N Testing",
but only through revision L. (Revisions through U
will be in the second half of the box, not yet
available.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-09-27<br>
</td>
<td valign="top">
<ul>
<li>There has been a <a href="links.html#SIMFAM">document
talking about something called "SIMFAM"</a> in our
document library for a quite a while. This is a
memory adapter for the AGC, for ground testing, based on
something called "braid memory" rather than core
memory. Unfortunately, I was unable to find out
much about braid memory myself, but Nikki Stevens
(thanks, Nikki!) has now sent me some info about it, and
I've naturally incorporated an explanation into my
descriptions. (Alas! The info comes from a 1966
IEEE paper, which I fear is still under copyright even
though not so marked, so I don't post the entire paper.)</li>
<li>Various new documents have been added to the document
library, most of them newly scanned (so their
full-resolution scans are in our Internet Archive site
in addition to the low-resolution links below), although
the first one on the list below actually came from NTRS:<br>
</li>
<ul>
<li>68-FM-256, "<a
href="Documents/19740072687_1974072687.pdf">Project
Apollo: Verification of Sundisk Orbital Navigation
Program</a>". This actually contains a lot of
software-related technical detail about SUNDISK 282,
the Apollo 7 flight program. (Thanks, Nik Beug!)<br>
</li>
<li><a href="Documents/68-FM61-230.pdf">68-FM61-230</a>,
changes to 68-FM-23, "Logic and Equations for the
Real-Time Computation of the Lunar Module Descent
Planning Table" (which was already in the library).</li>
<li>68-FM-67, "<a href="Documents/68-FM-67.pdf">Logic
and Equations for the Real-Time Computation of the
LM Launch Targeting and Display</a>".</li>
<li>E-2456, "Apollo Guidance and Navigation Flow
Charts":</li>
<ul>
<li><a href="Documents/E-2456-2D.pdf">Rev. 1, Program
COLOSSUS 2D, COMANCHE 72</a> (full document).</li>
<li><a href="Documents/E-2456-2C.pdf">Rev. -, Program
COLOSSUS 2C, COMANCHE 67</a> (just the flowcharts
changed from COMANCHE 72).</li>
</ul>
</ul>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-09-22<br>
</td>
<td valign="top">Mike has pulled a <a
href="https://en.wikipedia.org/wiki/Hat-trick">hat-trick</a>
by reconstructing the <a href="Luminary.html#Luminary163">LUMINARY
163 and LUMINARY 173</a> source code. Of course,
I've also taken the much simpler step of adding support for
them to the VirtualAGC GUI program. <br>
<br>
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, <a
href="Luminary.html#Luminary178">LUMINARY 178</a>, 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!<br>
<br>
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 <i>based on</i>
173, while the reconstruction of 173 is <i>based on</i>
178. We have confidence in the reconstruction of 178
because its checksums are correct ... but there's a <i>small</i>
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 <i>incorrect</i> memory
bank (from 178) having a <i>correct</i> 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 <i>all</i>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-18<br>
</td>
<td valign="top">
<ul>
<li>Mike Stewart has managed a true <i>tour de force</i>,
by reconstructing and contributing the reconstructed <a
href="Luminary.html#Luminary178">LUMINARY 178</a>
source code. LUMINARY 178, you may recall is the
LM's AGC program for the Apollo 14 mission. It has
been a sore spot for me for a while, in that we've had
the LUMINARY code for all <i>other</i> flown missions —
i.e, Apollo 10-13 and 15-17 — for a long time ... but
not Apollo 14. It has been the only one
missing. This is quibbling a little bit, I admit,
since it ignores Apollo 5 and Apollo 9. But
technically those missions didn't use LUMINARY; Apollo 5
used SUNBURST (which we have!) and Apollo 9 used
SUNDANCE (which we don't!). So I guess the missing
SUNDANCE will now become the sore spot. But I
digress. Finally filling in the gap for Apollo 14
is great no matter how you look at it, but what makes it
a <i>tour de force</i>, is the <i>vast</i> gap that
this fills in terms of software changes. The
Apollo 13 and 15 LM software were LUMINARY 131 and
210, respectively ... that's 79 revisions in between,
with Apollo 14 being smack dab in the middle.
Amazing! So the reconstruction requires figuring
out the changes for something like 30-50
revisions. Getting to the end of that process is
like finding the missing link. It makes the slogan
you see in the website logo ("Apollo Digital
Archaeology") seem quite appropriate. Not only is
the code <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary178">in
the software repository</a> now, but support for it
has been added to the VirtualAGC GUI.<br>
</li>
<li>On a lesser note, I've finally finished proofing the <a
href="LVDC.html">LVDC</a> source code's program
comments. Experience suggests there are still
quite a few errors I missed. Nevertheless, given
that the code has been proofed, and assembles to exactly
the expected core-rope image, I'm finally willing to put
my stamp of approval on it and say that it's
"ready". If only ITAR concerns allowed me to
freely provide it to you .... Sigh!
Well, a lawyer's working on it, and will perhaps
discover that the ITAR fears are overblown. Or
not. At any rate, you can still apply to me on an
individual basis to get the code if you're a "U.S.
person" under the law. Next step:
simulation.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-09-16<br>
</td>
<td valign="top">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
the <img alt="" src="new.png" width="36" height="16">
icon on <a href="links.html">the document-library page</a>),
but the one that particularly stands out for me is
Raytheon's 1969 "<a href="Documents/19700015154.pdf">Final
Report: Apollo Guidance Computer Program Block I (100) and
Block II</a>". Don't be confused by the title referring to
the "program", since the report is <i>not</i> 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 <a
href="explodedDskyBlockII.jpg">an exploded diagram for the
Block II DSKY</a> that I don't recall having seen before,
to the extent that I even pulled it out of the report and
added it to <a href="yaDSKY.html">the DSKY page</a>.
I'm sure there's nothing in the diagram that you can't get
already from the many DSKY <a href="ElectroMechanical.html">engineering
drawings</a> we have, but it may be useful for those of
you who have been working on constructing your own DSKYs.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-15<br>
</td>
<td valign="top">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.<br>
<br>
When I say it's incomplete, I <i>don't</i> 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 <i>could</i> be assembled without
error if a handful of undebugged problems in this
engineering (as opposed to released) version of the code
were fixed.<br>
<br>
No, what I mean is that the Flight Program was not the <i>only</i>
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.<br>
<br>
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 <i>essential</i>
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.<br>
<br>
As usual, <a href="LVDC.html#LVDC_Software">I've written
all this up in more detail on the LVDC page itself</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-13<br>
</td>
<td valign="top">Lots more updates to descriptions of <a
href="LVDC.html">LVDC</a> i/o ports and command words
transmitted to the rocket from mission control.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-11<br>
</td>
<td valign="top">Lots of changes to descriptions of <a
href="LVDC.html">LVDC</a> i/o ports and telemetry.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-10<br>
</td>
<td valign="top">More updates to description of <a
href="LVDC.html#LVDC_Assembly_Language">LVDC assembly
language</a>.</td>
</tr>
<tr>
<td valign="top">2019-09-09<br>
</td>
<td valign="top"><a
href="LVDC.html#yaLVDCASM_the_LVDC_Cross-Assembler">Usage
of the LVDC assembler, yaASM.py, has been documented</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-08<br>
</td>
<td valign="top">Mike Stewart has sent in dumps of rope images
of 4 SUNDANCE physical memory-rope modules. You may
recall that <a href="Luminary.html#SUNDANCE306">SUNDANCE
306</a> 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!<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-07<br>
</td>
<td valign="top">"Final" corrections to my draft description
of <a href="LVDC.html#LVDC_Assembly_Language">LVDC assembly
language</a>, specifically the <tt>DFW</tt>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-09-05<br>
</td>
<td valign="top">
<ul>
<li>Added a copy of <a href="links.html#Checklists">the
Apollo 11 Operations Checklist</a> to the document
library. This was already available at the <a
href="https://history.nasa.gov/afj/ap11fj/a11-csmocindex.html">Apollo
Flight Journal</a>, so please feel free to examine
there instead.</li>
<li>Scanning of the final half of <a
href="AgcDrawingIndexBox435.html">aperture-card Box
435</a> from NARA SW has now been completed.
This batch contains "post-installation checkout
procedures for the the G&N system. The rate of
scanning aperture-care boxes has slowed down somewhat
recently due to circumstances, but is due to pick up
again to a much higher rate in the near future.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-09-01<br>
</td>
<td valign="top">
<ul>
<li>More <a href="LVDC.html">updates</a> to descriptions
of LVDC assembly language, AS206RAM program structure,
and so on.</li>
<li>It turns out that my instructions for <a
href="download.html#Installer_for_Windows">downloading
a Virtual AGC "installer" for Windows</a> may have
been a tad thin in terms of explaining how to actually
run the program once it has been downloaded. So
I've pepped up that explanation to make it a lot more
explicit.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-28<br>
</td>
<td valign="top">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
versions:<br>
<ul>
<li><a href="Documents/apollo14_preliminary_padloads.pdf">Preliminary
Apollo 14 Erasable Load</a></li>
<li><a href="Documents/lum178_simulation.pdf">Aborted
Luminary 178 simulation</a></li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-26<br>
</td>
<td valign="top">
<ul>
<li>Manoel has submitted a couple more 3D models,
2004739A-000 and -021, DSKY front cover. This is
significant because it turns out that model 2004929
(also DSKY front cover) added a couple of weeks ago was
not the one called out for DSKY model 2003994-121 at
all, and that 2004739 is what should be used. This
was not just an oversight, though! The problem is
that drawing 2004739 simply isn't dimensioned very
thoroughly, whereas 2004929 is dimensioned quite
thoroughly, so the hope was that 2004929 would be a good
substitute. Alas, it was not! Some of the
dimensions (specifically the width and height of
openings for the indicator lamps) from drawing 2004929
are not compatible with the other constituent assemblies
in DSKY 2003994-121. Thus while the new models for
2004739 are intended to be exact representations of the
original drawing, there's not enough detail on the
original drawing to insure that; so the new models
contain both elements from 2004929, as well as
measurements which were fortunately able to be gotten
from a physical 2004739 module. Nevertheless, the
potential for error remains and thus the models may need
to be further adjusted over time.</li>
<li>10 new document scans from NARA SW have been
added. Many of them relate to RTCC software
flowcharts for various Apollo 14 G&N computations,
and to GSOP changes from Apollo 13 to 14. Rather
than enumerate those documents here, I'd suggest looking
for the <img alt="" src="new.png" width="36"
height="16"> icon on <a href="links.html">the
document-library page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-22<br>
</td>
<td valign="top">
<ul>
<li>Corrected my <a
href="LVDC.html#LVDC_Assembly_Language">confused
description of LVDC instructions <tt>HOP*, TRA*,
TMI*, TNZ*</tt></a>: I've belatedly realized
that there should be no such instructions in the LVDC
source code, and that the asterisks are added in the
assembly listing to highlight that certain workarounds
have been transparently performed.</li>
<li>Manoel has added a few more <a
href="https://github.com/virtualagc/virtualagc/tree/mechanical/3D-models">3D
models for DSKY parts</a>. It should be noted
that the first two of those models listed below are
created from the <i>external</i> dimensional properties
of "Specification Control Drawings" (SCD). That's
significant because the these assemblies were
manufactured independently, and while they are really
themselves assemblies, the internal characteristics of
the assemblies are (well, <i>were</i>) known only to
the manufacturers of the assemblies. In other
words, there are no available drawings describing their
internal structures. Consequently, you can't
simply 3D print them and expect that they'll do anything
for you, particularly since they contain circuitry not
represented by the 3D models. They'll need to be
reverse engineered in order to reproduce their
electrical and behavioral characteristics. The
third model is also problematic, because we don't have
the latest revision of its original drawing.
That's significant, because most DSKY's specify use of
configuration -001 of the part, while the most-recent
drawing we have covers only up to configuration
-000. Consequently, the 3D model also conforms
only to configuration -000 rather than to the necessary
-001, and therefore also likely requires modification.<br>
</li>
<ol>
<li>1006315A, electroluminescent digital indicator</li>
<li>1006387D, alarm indicator<br>
</li>
<li>2004699A, indicator frame cover<br>
</li>
</ol>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-18<br>
</td>
<td valign="top">Updated <a
href="LVDC.html#LVDC_Assembly_Language">descriptions of
more LVDC pseudo-ops</a>: <tt>ORGDD, DOGD</tt><tt></tt>.</td>
</tr>
<tr>
<td valign="top">2019-08-17<br>
</td>
<td valign="top">Fixed <a
href="LVDC.html#LVDC_Assembly_Language">description of
various LVDC pseudo-ops</a>: <tt>DEQS</tt>, <tt>DEQD</tt>,
<tt>USE INST</tt>, <tt>USE DAT</tt>.<br>
</td>
</tr>
<tr>
<td valign="top">2019-08-16<br>
</td>
<td valign="top">
<ul>
<li>Manoel has added a few more <a
href="https://github.com/virtualagc/virtualagc/tree/mechanical/3D-models">3D
models for DSKY parts</a>. I forgot to mention
yesterday that these are parts for DSKY model
2003994-121 (the final CM DSKY model), though the parts
Manoel has submitted so far seem applicable to all Block
II DSKY models I've checked so far. (Admittedly
not every single one!) I probably should have
mentioned too that the models being added so far are
intended to precisely capture the original Apollo
engineering drawings, and hence do not include any
optimizations for (for example) 3D printing; alternate
3D models with such optimizations may be added in the
future. Also, for those who haven't stayed atop
the behind-the-scenes discussions, it's perhaps useful
information that the models are in <a
href="https://en.wikipedia.org/wiki/ISO_10303-21">STEP</a>
format, which can be imported into most 3D modeling
programs, but specifically into the open-source <a
href="https://www.freecadweb.org/">FreeCAD</a>
modeler. I probably should summarize what those
parts are, too, rather than forcing you to figure it out
for yourself. Here's the complete list so far:</li>
<ul>
<li>2004900A, rear cover</li>
<li>2004919E, adapter plate</li>
<li>2004920-, digital indicator connector plate</li>
<li>2004921A, alarm indicator connector plate</li>
<li>2004929A, front cover</li>
<li>2004968E, front housing</li>
</ul>
<li>Mike has confidently reconstructed yet another AGC
software version, this time <a
href="Colossus.html#ARTEMIS71">Artemis 71</a>.
As you may recall, Artemis 72 is the software actually
flown in the Apollo 15 through 17 Command Modules.
But Artemis 71 was originally intended to do so.
Artemis 72 flew instead, because of a bug fix. As
with all these software reconstructions that have been
appearing lately, we have no actual assembly listing of
Artemis 71 to work from. Nevertheless, the clues
present in the Artemis 72 assembly listing, in concert
with the Artemis 71 memory-bank checksums (which we have
from engineering drawing 2021154), allow us not only to
infer the required changes, but to verify them
afterward. Great work, Mike! The VirtualAGC
GUI program now supports Artemis 71 as well, so you can
run Artemis 71 or browse its source code in VirtualAGC
if you like.</li>
<li><a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">The
Apollo G&N system assembly drilldowns</a> now
include links to the appropriate 3D models of the
associated parts wherever possible (similar to the way
they have already been including links to CAD
transcriptions of associated electrical schematics).<br>
</li>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-15<br>
</td>
<td valign="top">
<ul>
<li>Reworked a lot of the <a
href="LVDC.html#LVDC_Assembly_Language">discussion of
LVDC assembly-language coding</a>, on the basis of my
improved understanding of it, and particularly an
explanation of the LVDC preprocessor.</li>
<li> We've had our first submission of <a
href="https://github.com/virtualagc/virtualagc/tree/mechanical/3D-models">3D
models to our mechanical-drawing repository</a>, for
some DSKY parts. They look pretty swell to
me. Thanks, Manoel da Silva Casquilho!</li>
<li>Unfortunately, Manoel had to deal with some pretty
poorly-written instructions in so far as the
requirements on the 3D models, as well as practically
non-existent instructions on how to actually submit them
to the repository, so I've rewritten quite a lot of <a
href="ElectroMechanical.html#Mechanical_Drawings">the
section on our electro-mechanical page</a> describing
that stuff. Hopefully it's better, but knowing
myself I can't claim to be 100% confident that it is.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-13<br>
</td>
<td valign="top">
<ul>
<li>A handful of documents added to the library a few
weeks ago have now been removed. Well, perhaps a
handful and a half. For the most part, I've done
this by expunging the files themselves, but leaving the
hyperlinks on <a href="links.html">the document library
page</a> and striking them out (<strike>thusly</strike>)
so that it's easy to see what has been removed.
These documents originally came from <a
href="https://www.sti.nasa.gov/">NTRS</a>, but were
removed from NTRS when it was decided by NASA that they
hadn't been approved for release; so now they've been
removed from Virtual AGC too. Sweet! I don't
actually know if it was necessary to remove them, but it
has been done as a precaution. Of the 1000+
documents we provide, who knows how many have thus been
(or will be) taken retroactively out of the public
domain, with no practical way for us to even know about
it or react to it? (Hint: We don't.) Can you
spell "time bomb waiting to go off"? (Hint:
You don't have to. I just spelled it out for
you.) Or perhaps, "closing the stable door after
the horse has bolted"? (Hint: Ditto.)
For what it's worth, I think the documents are available
on <a href="https://archive.org/web/">The Wayback
Machine</a>'s cache of NTRS, if you can figure out how
to find them, and with luck perhaps they'll return here
at some point.<br>
</li>
<li>Speaking of secret knowledge, I've finished my first
pass at transcribing the LVDC AS-206RAM assembly listing
to source code, but am afraid now to post it publicly
because of ITAR and the danger that North Koreans may
start pelting us with Saturn V or Saturn IB rockets if
they get hold of this 50-year-old software
listing. (The projected cost of a <a
href="https://en.wikipedia.org/wiki/Saturn_V">Saturn V</a>
in 2019 dollars is around $726M, but that of a <a
href="https://en.wikipedia.org/wiki/Saturn_IB">Saturn
IB</a> such as would have been used for the AS-206RAM
mission is probably only around $220M. A bargain,
to a thrifty hawk! To be fair, when I wrote those
sentences, they were intended to be biting sarcasm, but
given that <a
href="https://en.wikipedia.org/wiki/LGM-118_Peacekeeper">LGM-118
Minuteman ICBMs</a> would cost perhaps $110M in 2019
dollars it doesn't even seem that far-fetched that some
nut-job would spend $200M for a Saturn IB as an ICBM,
does it?) Fortunately, anyone (who can prove
they're an American) can naturally apply directly to me
to get a copy of the transcribed software.
However, you might want to wait until it's decently
proofed first and the assembler itself is ready.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-08-08<br>
</td>
<td valign="top">
<ul>
<li><a href="LVDC.html#SequenceNumber">Clarified
explanation of LVDC assembler behavior for lines
having no punch-card sequence number</a>.</li>
<li><a href="LVDC.html#Skype">Made procedure for acquiring
LVDC software listing from me quite a bit less painful</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-31<br>
</td>
<td valign="top">
<ul>
<li>Mike has added yet another AGC software
reconstruction, this time of <a
href="Colossus.html#COMANCHE51">the Comanche 51 source
code</a>. Comanche 51 was the program that was
first targeted for the Apollo 11 Command Module, though
it was Comanche 55 that eventually flew in the
mission. Reconstruction of all these intermediate
AGC software versions may strike you as merely an
intellectual game, which I suppose it is in some ways,
but it has serious benefits as well. For example,
I'll remind you that a few days ago we got the Luminary
69/2 reconstruction, and this was actually mission
software (for the Apollo 10 LM) that we hadn't had
originally. In the case of Comanche, the Holy
Grail would be reconstruction of Comanche 45/2, which is
the missing mission software for the Apollo 10 CM.
Having Comanche 51 rather than just Comanche 55 gets us
that much closer to the goal. Even so, getting
from Comanche 51 to 45/2 is quite hard, since we don't
have the level of supporting documentation for Colossus
that we do for Luminary. A reconstruction of 45/2
would be ever so much easier if Margaret Hamilton just
gave us her copy of Comanche 44 ... though that, sadly,
seems less likely with every passing year. But
we'll see what we'll see!</li>
<li><a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">The
G&N assembly drill-downs</a> are once again
up-to-date with respect to all of the
engineering-drawing scans (and CAD transcriptions)
collected so far.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-29<br>
</td>
<td valign="top">
<ul>
<li>Mike has added <a href="Luminary.html#Luminary097">reconstructions
of the Luminary 97 and 98 source code</a>, following
the same procedure as for the Luminary 130 and 69 rev 2
reconstructions over the last couple of days.
There's slightly less confidence in the Luminary 98
reconstruction than in the 97 reconstruction, since back
in 1969 Luminary 98 was just development software <i>en
route</i> from 97 to 99, so its ropes were never
manufactured nor its memory-bank checksums
recorded. However, if Mike's Luminary 98
reconstruction were in error, his 97 reconstruction
would probably be in error as well ... which is unlikely
since all of <i>its</i> memory-bank checksums are
correct! In other words, while we're less
confident of the Luminary 98 reconstruction than in the
97 reconstruction, we still have a pretty high degree of
confidence in it.</li>
<li> On our Luminary page, I long ago hyperlinked the raw
scans of AGC assembly listings stored at our Internet
Archive site. But in some sort of strange mental
conniption, I belatedly find that I never did that on <a
href="Colossus.html">our Colossus page</a>! I
guess it's because so much data was pouring in from Don
Eyles at the time that I was thinking only about the
Lunar Module and not about the Command Module at
all. Well, I have finally taken care of it now!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-28<br>
</td>
<td valign="top">
<ul>
<li>Mike has added a <a href="Luminary.html#LUM130">reconstruction
of the Luminary 130 source code</a>, following the
same process as for yesterday's reconstruction of
Luminary 69 rev 2. Admittedly not quite as
exciting as yesterday's reconstruction if you're only
interested in software actually flown. On the
other hand, it is becoming increasingly obvious that the
more software versions we collect the easier it is to
fill in the gaps between them, so it's nothing to be
pooh-poohed by any means! (Excuse me, I mean
P00H-P00H'ed.) Plus, various Apollo 13 documents
referenced Luminary 130 anyway, and were never revised
for 131, as far as we know. <br>
</li>
<li>The VirtualAGC GUI program has been updated for both
Luminary 69 rev 2 and for Luminary 130.<br>
</li>
<li> I've adjusted the size of the youtube video
thumbnails I've embedded in the tables on the Luminary
and Colossus pages, since I notice they were so big that
when the windows were made smaller the text overflowed
to the right and needed scrollbars to see. I can't
get rid of this effect entirely, but making the
thumbnails smaller mitigated it somewhat.</li>
<li>On <a href="faq.html#other_websites">the FAQ page</a>,
I've added links to Ken Shirriff's writeup of his
article about bitcoin mining on the AGC, as well as to
David Given's writeup of his port of his Cowgol
programming language to the AGC, as well as the
subsequent creation of a lunar lander game (Cowlark)
written in Cowgol. In other words, Cowlark is a
lunar lander game which can be run on the AGC. <img
src="smiley.png" alt="" width="16" height="16"> Fun
stuff, though I'm not sure programming in Cowgol
actually gives you "the AGC programmer experience". <br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-27<br>
</td>
<td valign="top">As you may have noticed in looking at the <a
href="Luminary.html">Luminary</a> and <a
href="Colossus.html">Colossus</a> pages, it sometimes
happens that when somebody gives us a listing of an AGC
program, it may not be <i>quite</i> 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?<br>
<br>
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, <a
href="https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n65/mode/1up">2021151
through 2021154</a>, 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, <i>and</i> 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 <i>descriptions</i> 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 <i>check</i> 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.<br>
<br>
<a href="Luminary.html#LUM69R2">In the case of Luminary 69
Rev 2, Mike Stewart has stepped in and reconstructed it
overnight, using exactly the method described above</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-07-26<br>
</td>
<td valign="top">
<ul>
<li>Added G&N engineering drawing scans from NARA SW
aperture-card boxes <a
href="AgcDrawingIndexBox467.html">467 (final 2/3)</a>
and <a href="AgcDrawingIndexBox435.html">435 (first
half)</a>. Box 435 contains a lot of G&N
system post-installation checkout procedures from North
American Aviation. It has been scanned out of
order because some of the procedures relate to using
SUNDIAL. Another notable procedure therein uses
SOLARIUM for checking out the Block I systems for Apollo
4 and 6. All index pages and the
engineering-drawing search engine have been updated, but
the assembly drilldowns have not yet.<br>
</li>
<li>Added three new documents to <a href="links.html">the
library</a> (thanks, Graham!) concerning AS-503A (an
unflown alternative mission) and Skylab.</li>
<li>Replaced <a
href="LVDC.html#Evolution_of_the_Flight_Software">the
LVDC software sample images</a> with higher-quality
ones of the same pages.</li>
<li>Don Eyles has sent along some scans of two data-card
booklets: an earlier one for the <a
href="Documents/Retread50AuroraSundialBCCards.pdf">Retread
50, Aurora, and Sundial B & C</a> software, and a
later one for just the <a
href="Documents/Aurora88SundialCCards.pdf">Aurora 88
and Sundial C software</a>. Since Aurora and
Sundial were used for checkout of the LM and CM guidance
systems, respectively, I infer from that Retread must
also have been used for system checkouts at some point,
but was then obsoleted. As usual, the full-quality
scans are at our Internet Archive site. (Thanks,
Don!)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-24<br>
</td>
<td valign="top">
<ul>
<li>Yesterday's edition of <a
href="https://theorbitalmechanics.com/show-notes/ron-burkey">The
Orbital Mechanics podcast</a> is an interview with me,
talking about the Virtual AGC project. It sounded
good in my head when I said it, so *cough* *cough* it
must be good on the podcast too!</li>
<li>A few more miscellaneous documents have been added to
the library (thanks, Graham!). Just look for
the <img alt="" src="new.png" width="36"
height="16"> icon.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-23<br>
</td>
<td valign="top">
<ul>
<li>It turns out that my comments yesterday about SUNDIAL
D vs SUNDIAL E in the 2TV-1 mission were
misguided. What I <i>should</i> have been saying
was that the fixed-memory modules (which are what holds
the SUNDIAL program) were different than what what the
engineering documentation led us to believe:
specifically, if you're interested, MIT's AGC contains
software assembly 2021104-051 rather than the
2021104-041 we expected. However, Mike has managed
to find documentation that both of those assemblies held
SUNDIAL E software anyway, so it hardly matters which
one was installed in the computer. Thus I can
happily contradict what I said in yesterday's
entry: We truly do have the software for the 2TV-1
mission! I've altered <a
href="Colossus.html#2TV1">the description on the
COLOSSUS page</a> to reflect that fact.</li>
<li> The VirtualAGC GUI program has now been updated (at
GitHub) to have the 2TV-1 mission as one of the options.</li>
<li>Added a series of documents (thanks, Graham Donald!)
to the library, concerning potential applications of the
LM. Also, quite by chance, I found a <a
href="Documents/R-700.pdf">grayscale scan of document
R-700</a> online that's fantastic, compared to the
B&W scans we already had, because you can actually <i>see</i>
the photographs; naturally I snatched it and stuck it in
the document library too.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-22<br>
</td>
<td valign="top">
<ul>
<li>Much like with the RETREAD 50 AGC software we added a
few weeks ago, <a href="Restoration.html">the AGC
Restoration team</a> has now dumped the rope memory
from the MIT Museum's AGC and has given us the AGC
program SUNDIAL E. This is our first look at
SUNDIAL. SUNDIAL E is close to, but presumably not
exactly the same as, the SUNDIAL D software used for the
2TV-1 mission, so <a href="Colossus.html#2TV1">that's
how I've categorized it on our COLOSSUS page</a>.
In a larger sense, I think that SUNDIAL was generally
used for system checkout of Command Modules, much as
AURORA was for Lunar Modules. We don't have the
source code yet, since the restoration team has been so
busy, but presumably Mike will churn it out for us in
the reasonably-near future by comparing to similar
program versions and judicious disassembly. The
binary is apparently ready-to-run in yaAGC, though I
have not made the necessary changes yet to do so within
the VirtualAGC GUI environment.</li>
<li>At the same time, 3 out of the 6 rope modules for the
program SUNDANCE 302 were dumped, and have been added to
<a
href="https://github.com/virtualagc/virtualagc/tree/master/Sundance302">the
GitHub repository</a>. I've not written up
anything about it on the LUMINARY page yet, though,
because I haven't figured out yet how to go about
describing <i>half</i> of a program. The idea, of
course, is to try and find the other half of it later.<br>
</li>
<li>In thrashing out whether SUNDIAL E was or was not used
in 2TV-1, it became apparent that some of the
compatibility tables in documents ND-1021042 and
ND-1021043 could be used to fill in a couple of
missing-link engineering drawings related to
configurations of SUNDIAL and AURORA, so I've now done
that and regenerated the assembly drilldowns of the
engineering drawings accordingly.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-21<br>
</td>
<td valign="top">
<ul>
<li>Added another couple of documents to <a
href="links.html">the library</a>, this time
peripherally related to Apollo 13. Incidentally, I
was remiss yesterday in not thanking Graham Donald for
sending these docs over to me.</li>
<li>Yesterday's edition of <a
href="http://londonpodcast.net/?p=643">The London
Podcast</a> by presenter Adrian Lacey, among other
things features me talking about the Virtual AGC
Project.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-20<br>
</td>
<td valign="top">Added a handful of notes on lunar descent,
and particularly delta guidance, to <a href="links.html">the
document library</a>. I won't itemize them
individually here. Just look for the <img
src="new.png" alt="" width="36" height="16"> icon.<br>
</td>
</tr>
<tr>
<td valign="top">2019-07-17<br>
</td>
<td valign="top">The scan of the assembly listing of the LVDC
AS-206RAM flight program is now ready. Or at least, <i>a</i>
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.<br>
<br>
<a href="LVDC.html#Evolution_of_the_Flight_Software">As I
explain in more detail on the LVDC page</a>, we are not
certain yet about the <a
href="https://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations">ITAR</a>
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 <i>does</i>
restrict access. So if you want the scanned program
listing, you'll not only have to <strike>email me directly</strike>
apply to me <i>in person</i>, but you'll also have to
provide reasonable proof that you're a U.S. citizen,
tolerate the fact that I'll send you only an encrypted,
identifiable, watermarked PDF, and be okay with the fact
that I'll retain a permanent record of you and of the proof
you provided. That's because ITAR restricts access to
foreigners but explicitly allows distribution to U.S.
citizens. The upshot is that if it turns out ITAR <i>does</i>
restrict access and the listing does end up somehow in
foreign hands, and somebody does show up at my door with a
subpoena ... well, <i>my</i> personal posterior will be
covered, because <i>I</i> will have handed the program only
to verifiable U.S. citizens.<br>
<br>
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.)<br>
</td>
</tr>
<tr>
<td valign="top">2019-07-15<br>
</td>
<td valign="top">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 <a
href="LVDC.html">the LVDC page</a>, as various
speculations have suddenly been converted either to facts or
fantasies. Obviously, many additional relevant changes
are expected in the year future.<br>
</td>
</tr>
<tr>
<td valign="top">2019-07-13<br>
</td>
<td valign="top">
<ul>
<li><a href="LVDC-1967/">More page images of the 1967 LVDC
flight program</a> have come in. I've had to
reorganize the underlying storage of these items a bit
by taking the LVDC page images out of the GitHub
repository. Otherwise, if new images kept coming
in — something of which there's no assurance <i>whatever</i>
— they'd begin to overwhelm it. But the change
should be completely transparent to anyone looking at
the website.</li>
<li> Added <a
href="LVDC.html#Evolution_of_the_Flight_Software">my
analysis as to whether the LVDC software is classified
or as to whether it is illegal under ITAR to "export"
it posting it online</a>. The executive summary
is "no" to the former and "maybe yes, maybe no" to the
latter. Anyone with a better understanding of the
legalities related to this than I am ... <i>please</i>
pass along your wisdom to me!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-12<br>
</td>
<td valign="top">I've added <a
href="LVDC.html#LVDC_Assembly_Language">still more flesh</a>
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.</td>
</tr>
<tr>
<td valign="top">2019-07-11<br>
</td>
<td valign="top">
<ul>
<li>Updated <a href="LVDC.html#Interrupts">the
description of the LVDC's TLC interrupt</a> with a bit
of anecdotal info.</li>
<li><a href="LVDC.html#CPU_Instructions">The description
of the LVDC's STO instruction</a> was shockingly
deficient in terms of how it covers subroutine linkages
— namely, it <i>didn't</i>, and indeed provided
misleading information — so I've fixed it up.</li>
<li>I've added <a href="LVDC.html#LVDC_Assembly_Language">a
lot of descriptive material</a> about what I infer (or
more politely, <i>guess</i>) from the LVDC sample code
about the syntax of LVDC assembly language. This
is particularly true for the many assembly-language
pseudo-ops that have appeared that we've never seen any
references to before ... but it applies to the regular
code as well.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-10<br>
</td>
<td valign="top">A handful of additional source-code pages
from <a href="LVDC.html#Evolution_of_the_Flight_Software">the
1967 LVDC flight program</a> mentioned yesterday have been
added. Alas! All things considered, they've
added more to my confusion than they've subtracted.<br>
</td>
</tr>
<tr>
<td valign="top">2019-07-09<br>
</td>
<td valign="top">
<ul>
<li>Added a link to Ken Shirriff's delightfully absurd
blog article "<a
href="http://www.righto.com/2019/07/bitcoin-mining-on-apollo-guidance.html">Bitcoin
mining on an Apollo Guidance Computer: 10.3 seconds
per hash</a>" to <a href="Restoration.html">the
AGC-restoration page</a>. He does his mining on
the restored physical AGC, but shows you how to do it
with Virtual AGC too.<br>
</li>
<li> And another great treat, <a
href="LVDC.html#Evolution_of_the_Flight_Software">our
first actual IBM LVDC source code</a>, from a 1967
version of the LVDC flight program! It's just a
few pages of trig and square root routines, but you can
see from the snapshots that there's a full (or at least
very substantial) program listing beyond just those few
samples. It probably does not conform 100% to the
syntax of the assembler I wrote for it a decade ago, but
obviously at some point I'll fix up the assembler.
Unfortunately, my anonymous informant does <i>not</i>
indicate that we will be receiving the full listing, and
indeed implies very strongly that we will not. So
I can't you promise anything further. Which is
disappointing. But the very positive takeaway is
that assembly listings of the LVDC flight program do
still exist ... a possibility which previous informants
have poo-pooed up to now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-08<br>
</td>
<td valign="top">
<ul>
<li>I've removed some anecdotal bits of info from <a
href="LVDC.html">the LVDC page</a>, relating to who
wrote the software and how it was written, because I no
longer have confidence in those anecdotes. None of
the technical info has changed.</li>
<li> Added the CAD transcription for drawing 2010062F
(Block II CDU power supply).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-07-03<br>
</td>
<td valign="top">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).<br>
</td>
</tr>
<tr>
<td valign="top">2019-07-01<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-28<br>
</td>
<td valign="top">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 <i>all</i>) 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-27<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-25<br>
</td>
<td valign="top">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 <i>not</i> 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! <br>
<br>
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.<br>
<br>
But it's also based on a circuit-design practice that we
associate only with Block I and <i>early</i> 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!<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-24<br>
</td>
<td valign="top">A couple of problems have cropped up with the
process building Virtual AGC from source: <br>
<ul>
<li>Somehow, one of the files needed for <a
href="Luminary.html#Retread50">Retread50</a> hadn't
gotten into the repository, and this killed the entire
build as soon as it got to that point in the
process. Weird, since our GitHub repository is set
up to do a trial build whenever a commit to it is
performed (which it did, and naturally, failed), and to
email me about failures (which it didn't, as far as I
can tell). At any rate, I've added the missing
file <i>now</i>. <br>
</li>
<li>Also, building Virtual AGC on newer Macs with clang
(which, having only old Macs, I've never had any means
to try) weren't working. But <a
href="download.html#Newer_Macs:_Xcode_with_clang">a
couple of extra instructions have now been added</a>
that may do the trick. Is it a complete fix?
Time will tell. <br>
</li>
</ul>
At any rate, thanks to Gavin Eadie for pointing out the
problems and at least part of the fix!</td>
</tr>
<tr>
<td valign="top">2019-06-22<br>
</td>
<td valign="top"><a
href="ElectroMechanical.html#Appendix:_Signal_Wiring_Diagrams">The
discussion of "signal wiring diagrams"</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-21<br>
</td>
<td valign="top">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
href="ElectroMechanical.html#Further_Information_About_Scanned">a
centralized location on the electro-mechanical page</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-20<br>
</td>
<td valign="top">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 <i>yet</i>
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
about 19.6K.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-18<br>
</td>
<td valign="top">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.)<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-17<br>
</td>
<td valign="top">
<ul>
<li>We have been given a version of the AGC software that
we didn't previously have! The program is RETREAD
50, and you may recall that we already had gotten the
similar program RETREAD 44 from Don Eyles.
However, we've gotten RETREAD 50 in a way completely
different from all other AGC software. We have <i>not</i>
been given an assembly listing for RETREAD 50.
Rather, the AGC-restoration project (which you may have
gotten wind of) was allowed to borrow core-rope modules
containing RETREAD 50 from the Computer History Museum,
thus allowing them to obtain a dump of the ropes, and
(for good measure) regenerating the source code for
it. And we're the beneficiaries! See our <a
href="Luminary.html#Retread50">LUMINARY page</a>
and/or <a
href="https://github.com/virtualagc/virtualagc/tree/master/Retread50">our
GitHub software repository</a>.</li>
<li>In order to properly described how and why we managed
to get RETREAD 50, I found myself writing <a
href="Restoration.html">an entire page devoted to just
a description of the AGC restoration effort</a>.
You'll see that a link to it now appears at the bottom
right of the banner across the top of all our
pages. It's not quite complete yet, but feel free
to check it out!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-06-14<br>
</td>
<td valign="top">
<ul>
<li>Finally have the G&N assembly drilldown fully
up-to-snuff ... just in time to go get more scans next
week and to fall behind with it again.</li>
<li>Added various more Grumman LM drawings to <a
href="AgcDrawingIndex.html#GAEC">the miscellaneous
drawing index page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-06-13<br>
</td>
<td valign="top">Once again, lots more updates to the G&N
assembly drilldowns. I'm <i>almost</i> up-to-date
with all of them, but there's still a tiny bit left to do.<br>
<br>
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.)<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-12<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-11<br>
</td>
<td valign="top">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).<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-10<br>
</td>
<td valign="top">
<ul>
<li>In doing some semi-automated checking of the G&N
assembly drilldowns, I've discovered to my horror that a
lot of drawings that you'd never suspect were assemblies
actually are assemblies. Maybe 90% of them!
I mean, really, who would suspect that something called
a "cover" or a "plate" is really an assembly? I
ask you. I never even bothered to look at
them. The upshot of that is that the assembly
drilldowns I've made are actually nowhere near as
complete as I imagined, since I didn't have any support
for drilling down a bunch of those non-assembly
assemblies (with apologies to Woodward &
Bernstein). So I've made a tentative new beginning
with some updates to the drilldowns, but there's a long
way to go.</li>
<li>But there's a bit of a treat today as well: <a
href="AgcDrawingIndex.html#GAEC">We've gotten a few
top-level LM engineering drawings</a> from the
aperture-card boxes at NARA-SW, and perhaps someday
we'll be able to explore the LM engineering drawings in
much the same way we're now exploring the G&N
engineering drawings. Check them out! One
drawback with them is that while each drawing calls out
the drawings for its sub-assemblies, it does so only by
drawing number and no drawing name. Furthermore,
the drawings themselves have only numbers in their title
blocks, and have no actual titles. So I can't
personally tell you what most of the assemblies
are. Anyone who wants to offer up a solution to
this conundrum, please do so, since it will make
figuring out these assemblies quite difficult!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-06-08<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-07<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-06<br>
</td>
<td valign="top">Lots more updates of indexes and assembly
drilldowns related to the ~1900 engineering-drawing scans
from boxes 464/465 added yesterday.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-05<br>
</td>
<td valign="top"><i>Partial</i> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-04<br>
</td>
<td valign="top">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. <br>
</td>
</tr>
<tr>
<td valign="top">2019-06-03<br>
</td>
<td valign="top">Added links to the AGC/DSKY/G&N
engineering drawings for all missions on the <a
href="Luminary.html">Luminary</a> and <a
href="Colossus.html">Colossus</a> 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
further.<br>
</td>
</tr>
<tr>
<td valign="top">2019-06-02<br>
</td>
<td valign="top">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 <a href="Block1.html">Block I</a> and <a
href="yaDSKY.html">yaDSKY pages</a>, 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-05-31<br>
</td>
<td valign="top"><a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">The
Apollo G&N assembly drilldowns</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-05-27<br>
</td>
<td valign="top"><a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">The
new Apollo G&N assembly drilldowns</a> 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
<i>fully</i> debug the new drilldown.<br>
</td>
</tr>
<tr>
<td valign="top">2019-05-25<br>
</td>
<td valign="top">I haven't made many changes the last couple
of weeks because I've been drastically revamping <a
href="ElectroMechanical.html#Navigate_the_Assembly_Hierarchy_">the
way the electro-mechanical page displays the hierarchy of
engineering drawings</a>. 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
their JSON.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-05-24<br>
</td>
<td valign="top">
<ul>
<li>A variety of drawings for mil-spec parts used by the
AGC/DSKY/G&N mechanical drawings have been posted
online, and can be accessed through a new <a
href="AgcDrawingIndexMilSpec.html">mil-spec parts
index page</a>, or by means of <a
href="TipueSearch.html">the engineering-drawing search
engine</a>.</li>
<li>Document <a
href="Documents/assist.dla.mil/MIL-D-70327.pdf">MIL-D-70327</a>,
called out by almost all AGC/DSKY/G&N electrical
schematics, has been added to <a
href="ElectroMechanical.html#References">the reference
section of the electro-mechanical page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-05-12<br>
</td>
<td valign="top">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 <a
href="ElectroMechanical.html#Browse_the_Available_Engineering">big
AGC/DSKY drilldown table</a>. 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 <i>external</i>
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
nominally.<br>
<br>
A side effect of these problems was that on <a
href="http://www.ibiblio.org/apollo/yaDSKY.html#The_Warning_or_Indicator_Lamps">the
yaDSKY page of the website</a>, 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. <br>
<br>
This issue with Apollo 5 is actually slightly interesting,
in that it turns out there were engineering drawings both
for the configurations MIT <a
href="https://archive.org/stream/AgcApertureCardsBatch20190219Images#page/n82/mode/1up"><i>delivered</i></a>
to NASA and separate engineering drawings for those NASA
actually <a
href="https://archive.org/stream/AgcApertureCardsBatch20190219Images#page/n79/mode/1up"><i>installed</i></a>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-05-11<br>
</td>
<td valign="top">
<ul>
<li>The approaching 50th anniversary of Apollo 11 has
sparked interest from various writers, and in reviewing
some of our online materials so as not to make a
complete fool of myself when talking to them, I can't
help but notice various stuff that is out of date on the
website. Hopefully I've been able to make a dent
in those, though I'm sure I haven't caught everything.</li>
<ul>
</ul>
<ul>
</ul>
<li>Speaking of which, I had apparently forgotten to make
any comments here about the new article by Brian Hayes
in American Scientist magazine, <a
href="https://www.americanscientist.org/article/moonshot-computing">"Moonshot
Computing"</a>. In particular, Virtual AGC gets a
short section of it's own. But size, I've heard,
isn't everything ... so check it out. It's a
terrific article!</li>
<li>On <a
href="http://www.ibiblio.org/apollo/yaDSKY.html#The_Warning_or_Indicator_Lamps">the
yaDSKY page</a>, the mission-by-mission arrangements
of the indicator lamps and their colors were previously
speculative. But by navigating through our
recently-created <a
href="ElectroMechanical.html#Browse_the_Available_Engineering">engineering-drawing
tree</a>, I was able to fill them in for every
mission. It turns out there had been errors in the
DSKY indicator lamps for Apollo 12 and 17, and that I
had never gotten around to specifying the colors at
all. I haven't actually made any changes to the
software related to this fix, but I'll get around to it
at some point. Probably.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-05-10<br>
</td>
<td valign="top">More scans of Apollo G&N engineering
drawings (from aperture-card boxes at NARA SW) added:<br>
<ul>
<li>Previously-partial <a
href="AgcDrawingIndexBox462.html">Box 462</a> now
complete</li>
<li>Entirety of <a href="AgcDrawingIndexBox463.html">Box
463</a></li>
<li>Initial portion of <a
href="AgcDrawingIndexBox464.html">Box 464</a></li>
</ul>
<p>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.<br>
</p>
<p>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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2019-05-08<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005973-">CAD
transcription for drawing 2005973-</a> (indicator
driver module D1-D6 for Block II DSKY 2003994).
See also <a href="KiCad/2005973-">the renderings of the
CAD as image files</a>. <i>But wait</i>, you
say, <i>didn't you just add a <u>different</u> drawing
(2005940A) yesterday and say exactly the same thing
about it?!!!</i> Why yes, I did, thank you for
noticing. DSKY 2003994 is one of only a handful of
cases I've encountered in which there's an inconsistency
in its drawing tree as to which schematic is
applicable. The indicator driver module assembly
(2003952-031) for DSKY 2003994 calls out schematic
drawing 2005940, whereas the relay circuit assembly
(2003910-021) of that selfsame indicator driver module
assembly calls out schematic drawing 2005973
instead. The two schematics are almost, but not
quite, identical. Unfortunately there's no way to
know for certain which is which with the information we
have at present. Often in this case, we'd resort
to looking at AC Electronics document ND-1021042, but it
is <i>also</i> inconsistent, calling out schematic
2005973 in some places, but showing circuitry from
2005940 in others. Nevertheless, there are quite a
few circumstantial reasons to believe that 2005973 is
the correct one ... not least of which that its
signatures are dated later. You can read all of my
reasoning on that, in my usual boring detail, on any of
<a
href="2003950-011.html#2003952-011_INDICATOR_DRIVER_MODULE">the
DSKY 2003994 drawing-tree pages</a>.</li>
<li>Back when I originally did the engineering-drawing
drill-downs for the various AGC and DSKY models that are
listed on <a
href="ElectroMechanical.html#Browse_the_Available_Engineering">the
electro-mechanical page</a>, there were a number of
drill-downs I couldn't complete, due to missing
drawings. Well, there are still missing drawings,
but in the meantime we've acquired lots and lot more
scans than before, so it should be possible to fill in <i>some</i>
of those gaps. While it's still early in the
process of filling in the gaps, here are some of the
assemblies whose drill-downs have been addressed so far:</li>
<ul>
<li>AGC model 2003993-0<i>xx</i> <a
href="2003993-061.html#2003036-031_OSCILLATOR_MODULE_B7">oscillator
module, B7</a>. <br>
</li>
<li>AGC model 2003993-0<i>xx</i> <a
href="2003993-051.html#2003114-021_ERASABLE_DRIVER_MODULE">erasable
driver module, B9-B10</a>. <br>
</li>
<li>AGC model 2003993-0<i>xx</i> <a
href="2003993-041.html#2003140-031_ROPE_DRIVER_MODULE_B16-B17">rope
driver module B16-B17</a>.</li>
<li>DSKY model 2003950-011 <a
href="2003950-011.html#2003909-011_KEYBOARD_MODULE_ASSEMBLY_D8">keyboard
module D8</a>.</li>
<li>DSKY model 2003985-051 <a
href="2003985-051.html#2003909-011_KEYBOARD_MODULE_ASSEMBLY_D8">keyboard
module D8</a>.<br>
</li>
<li><a href="2003950-061.html">DSKY model 2003950-061</a>.</li>
<li>All Block II AGC models, miscellaneous drawings.<br>
</li>
</ul>
<li>Added <a href="Documents/HSI-208617.pdf">MIT/IL
document E-1186</a> to the document library.
Chapter 4 will tell you everything you want to know, I
would suppose, about TDRR's, and will help to explain
the TDDR numbers that pepper the revision blocks in the
Apollo engineering drawings.<br>
</li>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-05-07<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005971-A">CAD
transcription for drawing 2005971</a> (power-supply
module A30-A31 for Block II AGC 2003993). See also
<a href="KiCad/2005971-A">the renderings of the CAD as
image files</a>. Unlike my normal practice, I took
some liberties with this one, in that the latest
revision of the original drawing 2005971 we have is "A",
but it is missing its 2nd sheet (the bill of
materials). I therefore transcribed sheet 1 from
the original 2005971A, but I transcribed sheet 2 from
the original 2005971-, thus producing a hybrid revision
that I call "2005971-A". I've compared the
resistor, capacitor, and inductor values between the two
sheets to insure there are no obvious revision
mismatches between the two sheets, but there's no way to
detect incorrect part numbers for things like diodes and
transistors. Not that it matters too much, since
you probably can't get those diodes or transistors any
longer, but I still don't like it.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005940A">CAD
transcription for drawing 2005940A</a> (indicator
driver module D1-D6 for Block II DSKY 2003994).
See also <a href="KiCad/2005940">the renderings of the
CAD as image files</a>.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-05-06<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005928A">CAD
transcription for drawing 2005928A</a> (interface
module A25-A26 for Block II AGC 2003993 and an
alternative to drawing 2005021C for some AGC 2003200
dash numbers). See also <a href="KiCad/2005928A">the
renderings of the CAD as image files</a>. </li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005929A">CAD
transcription for drawing 2005929A</a> (sense
amplifier module for erasable memory, B14, for Block II
AGC 2003993). See also <a href="KiCad/2005929A">the
renderings of the CAD as image files</a>. </li>
<li>More fixes to the master engineering-drawing index and
search engine.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-05-04<br>
</td>
<td valign="top">The AGC/DSKY/G&N engineering-drawing
index pages I've been creating (i.e., the <a
href="AgcDrawingIndex.html">miscellaneous drawings page</a>
<i>et al.</i>), and the associated <a
href="TipueSearch.html">engineering-drawing search engine</a>,
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 <i>wrong</i>,
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-05-02<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005932A">CAD
transcription for drawing 2005932A</a>
(erasable-memory sense-amplifier module B13 for Block II
AGC 2003993 and an alternative to drawing 2005920B for
some AGC 2003200 dash numbers). See also <a
href="KiCad/2005932A">the renderings of the CAD as
image files</a>. </li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005926A">CAD
transcription for drawing 2005926A</a> (strand-select
module B15 for Block II AGC 2003993 and and an
alternative to drawing 2005924- for some AGC 2003200
dash numbers). See also <a href="KiCad/2005926A">the
renderings of the CAD as image files</a>. </li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-05-01<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005927A">CAD
transcription for drawing 2005927A</a> (alarm module
B8 for some Block II AGC 2003993 and 2003200 dash
numbers). See also <a href="KiCad/2005927A">the
renderings of the CAD as image files</a>. I also
found and fixed a number of boo-boos related to module
B8 in the existing html files and drawing search-engine.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005925A">CAD
transcription for drawing 2005925A</a> (current-switch
module B11 for Block II AGC 2003993 and and an
alternative to drawing 2005005D for some AGC 2003200
dash numbers). See also <a href="KiCad/2005925A">the
renderings of the CAD as image files</a>. <br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-30<br>
</td>
<td valign="top"> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005273-">CAD
transcription for drawing 2005273-</a> (Block II AGC
2003200 module A24 electrical schematics). See also <a
href="KiCad/2005273-">the renderings of the CAD as image
files</a>.</td>
</tr>
<tr>
<td valign="top">2019-04-29<br>
</td>
<td valign="top">
<ul>
<li>Hartmuth Gutsche tells me that <a
href="https://cdm16608.contentdm.oclc.org/digital/collection/p16608coll1">the
Apollo online digital archive of the University of
Alabama at Huntsville</a>, having apparently been
offline for a couple of years, has returned from
whatever limbo it may have been in. It contains
around a thousand documents. I've leafed through
all of them and pulled down 40 or so for <a
href="links.html">our own digital library page</a>
just in case the UAH site decides to disappear
again. You can find them in our library by looking
for the <img alt="" src="new.png" width="36"
height="16"> icon. As you might imagine, though,
given that almost all of this stuff came from Marshall
Space Flight Center, most of the UAH documents relate to
the big rocket, and mostly have little direct relevance
to what's going on here at Virtual AGC. Most of
the ones I pulled relate to Saturn IV-B stage
(containing the Instrumentation Unit, containing the
Launch Vehicle Digital Computer), or to the Apollo
Telescope Mount (Skylab), or to press materials for
Apollo 4 through 7. thanks, Hartmuth!</li>
<li>Thymo van Beers sent me a list of various boo-boos in
my own AGC developer documentation that need to be
fixed, and after lazily sitting on that list for a while
— a couple of months, it looks like — I've finally
gotten around to incorporating his suggestions.
Thanks, Thymo!</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-22<br>
</td>
<td valign="top">The titles in the box 462 index and in the
drawing search engine (and thus <i>all</i> available
engineering drawings) now again correspond to those given in
the drawing title blocks rather than in the aperture-card
metadata.<br>
</td>
</tr>
<tr>
<td valign="top">2019-04-21<br>
</td>
<td valign="top">The new engineering-drawing aperture-card
scans mentioned yesterday (all of <a
href="AgcDrawingIndexBox458.html">box 458</a>, remaining
half of <a href="AgcDrawingIndexBox461.html">box 461</a>,
and first 95% of <a href="AgcDrawingIndexBox462.html">box
462</a>) are now posted and available online, and the
links to them on the associated index pages work. The
<a href="TipueSearch.html">engineering-drawing search engine</a>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-04-19<br>
</td>
<td valign="top">
<ul>
<li>Updated the discussion of aperture cards in <a
href="faq.html">the FAQ</a>.</li>
<li>Added engineering-drawing index pages for
aperture-card boxes 458 and 462, and updated the page
for box 461 to include the previously-unscanned final
half of the box. The changes are completely
preliminary, and probably error-ridden, since although I
have all of the scanned drawings in hand, I haven't
posted them online yet. So the new/updated box
indexes aren't actually of any use yet.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-17<br>
</td>
<td valign="top"> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005272-">CAD
transcription for drawing 2005272-</a> (Block II AGC
2003200 module A23 electrical schematics). See also <a
href="KiCad/2005272-">the renderings of the CAD as image
files</a>.</td>
</tr>
<tr>
<td valign="top">2019-04-16<br>
</td>
<td valign="top">
<ul>
<li>Somewhat pepped up <a href="TipueSearch.html">the
engineering-drawing search page</a> I added yesterday,
so that the search results have much more intuitively
obvious search titles and URLs. Of course, as
always on this site, I make no pretense that "<i>more</i>
intuitively obvious" is the same as merely "intuitively
obvious", and in fact as I recall being taught in
school, I should probably be saying something like "less
intuitively unobvious". But you get the idea.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005268-">CAD
transcription for drawing 2005268-</a> (Block II AGC
2003200 module A18 electrical schematics). See
also <a href="KiCad/2005268-">the renderings of the CAD
as image files</a>.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-15<br>
</td>
<td valign="top">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!<br>
<br>
<div align="center"><a href="TipueSearch.html">Go to the
G&N engineering-drawing title/number search page</a><br>
<br>
</div>
</td>
</tr>
<tr>
<td valign="top">2019-04-13<br>
</td>
<td valign="top">Little problems in <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics">the
electrical CAD transcriptions of AGC/DSKY schematics</a>
had been bothering me, such as wires that weren't <i>precisely</i>
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. <img
src="smiley.png" alt="" width="16" height="16">
"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 <i>entirely</i>
pointless. For anyone unlucky enough to have hardcoded
some links or shortcuts to <a href="KiCad">the PNG files in
our rendered CAD folder</a>, 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-04-10<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005265-">CAD
transcription for drawing 2005265-</a> (Block II AGC
2003200 module A15 electrical schematics). See
also <a href="KiCad/2005265-">the renderings of the CAD
as image files</a>. Revisions "-" and "A" (for
AGC 2003993) differ only in the backplane signal for
connector pin 317.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005267-">CAD
transcription for drawing 2005267-</a> (Block II AGC
2003200 module A17 electrical schematics). See
also <a href="KiCad/2005267-">the renderings of the CAD
as image files</a>. Revisions "-" and "A" (for
AGC 2003993) differ only in the backplane signal for the
inputs and outputs of gate 44462 are no-connects on the
former but not the latter.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-09<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005257-">CAD
transcription for drawing 2005257-</a> (Block II AGC
2003200 module A10 electrical schematics). See
also <a href="KiCad/2005257-">the renderings of the CAD
as image files</a>. There's no electrical
difference from 2005257A (for AGC 2003993).</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005258-">CAD
transcription for drawing 2005258-</a> (Block II AGC
2003200 module A11 electrical schematics). See
also <a href="KiCad/2005258-">the renderings of the CAD
as image files</a>. There's no electrical
difference from 2005258A (for AGC 2003993).</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005253-">CAD
transcription for drawing 2005253-</a> (Block II AGC
2003200 module A12 electrical schematics). See
also <a href="KiCad/2005253-">the renderings of the CAD
as image files</a>. Differs from 2005253A (for
AGC 2003993) only in the backplane signal used for
connector pin 249.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005264-">CAD
transcription for drawing 2005264-</a> (Block II AGC
2003200 module A14 electrical schematics). See
also <a href="KiCad/2005264-">the renderings of the CAD
as image files</a>. There's no electrical
difference from 2005264A (for Verilog simulation) or
2005264B (for AGC 2003993).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-08<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005252-">CAD
transcription for drawing 2005252-</a> (Block II AGC
2003200 module A7 electrical schematics). See also
<a href="KiCad/2005252-">the renderings of the CAD as
image files</a>. There's no electrical
difference from 2005252A (for AGC 2003993).</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005256-">CAD
transcription for drawing 2005256-</a> (Block II AGC
2003200 module A9 electrical schematics). See also
<a href="KiCad/2005256-">the renderings of the CAD as
image files</a>. The difference between this rev
"-" and rev "A" (for AGC 2003993) is that in the latter,
several previously-disconnected gates are connected to
backplane signals, with the net result that the
backplane STRT2 signal is wire-NOR'd with the backplane
signals CLROPE, ROPER, ROPES, and ROPET. However,
this is a change only on the backplane wiring and not
within the module itself, so it is not an electrical
change within the module.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-07<br>
</td>
<td valign="top">The <a href="AgcDrawingIndex.html">miscellaneous
engineering-drawing index</a> had been formatted fine for
the situation in which it was the <i>only</i> 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>I'm</i>
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.)<br>
</td>
</tr>
<tr>
<td valign="top">2019-04-05<br>
</td>
<td valign="top">
<ul>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005263-">CAD
transcription for drawing 2005263-</a> (Block II AGC
2003200 timer module A6 electrical schematics).
See also <a href="KiCad/2005263-">the renderings of the
CAD as image files</a>.</li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/mechanical">Our
GitHub repository now has a "mechanical" branch</a>,
into which I semi-confidently expect 3D models of AGC,
DSKY, and perhaps other G&N system component
fabricated parts (such as baseboards, faceplates,
covers, and so on) to be placed ... hopefully starting
in the relatively near future. But it's just empty
right now except for a README that covers my hopes and
expectations in more detail. There's also a place
there for storing 2D CAD transcriptions of scans of the
original Project Apollo mechanical drawings, but people
have expressed so little interest in that (compared to
interest in 3D models) that we'll probably be able to
count them on the fingers of one toe.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-04<br>
</td>
<td valign="top">
<ul>
<li>Added yet another clever trick (to supplement those
added yesterday to the <a
href="AgcDrawingIndexBox459.html">Box 459</a>, <a
href="AgcDrawingIndexBox460.html">Box 460</a>, <a
href="AgcDrawingIndexBox461.html">Box 461</a>, and <a
href="AgcDrawingIndex.html">miscellaneous G&N</a>
engineering-drawing pages) for fooling our Internet
Archive site into letting you download full-resolution
imagery.</li>
<li> Because of teething difficulties at the beginning of
this process of scanning entire boxes of aperture cards,
there are several instances in type 02 documents in
which page 18 was misinterpreted as page 1, and thus the
page 18 scan overwrote the page 1 scan; similarly, in
which page 28 overwrote page 2 and page 38 overwrote
page 3. This has been fixed in the Box 459, Box
460, and Box 461 indices. I hope. There are
also related cases in which multiple microfilms of the
same drawing appear in the aperture-card boxes, but only
once in our collection due to overwriting of files of
the same name; this will be eliminated in future boxes
(i.e., we'll have access to all of the scans, duplicate
or not), but it doesn't seem worth it to try and fix the
problem in boxes that have already been scanned.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-03<br>
</td>
<td valign="top">
<ul>
<li>Fixed up the (currently partial) index for
aperture-card <a href="AgcDrawingIndexBox461.html">Box
461</a> the full titles of the drawings.</li>
<li>As some sort of asinine tribute to the sickening power
of cut-and-paste for evil, I had apparently titled
drawings 2005251 through 2005273 in <a
href="AgcDrawingIndexBox460.html">Box 460</a> as
"signal wiring diagrams", when they are really "logic
flow diagrams". That's fixed.</li>
<li>On the various engineering-drawing index pages, which
usually provide links to our Internet Archive site for
the individual drawing scans, there are warnings that
using the Internet Archive's "save image as" function
will usually give you an inferior image quality.
However, I've found much better workarounds for that
problem than when I originally wrote the warning, so
I've modified those pages to give better advice about
the workarounds.<br>
</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005262-">CAD
transcription for drawing 2005262-</a> (Block II AGC
2003200 stage branch decoding module A4 electrical
schematics). See also <a href="KiCad/2005262-">the
renderings of the CAD as image files</a>.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005261-">CAD
transcription for drawing 2005261-</a> (Block II AGC
2003200 cross point generator no. I module A5 electrical
schematics). See also <a href="KiCad/2005261-">the
renderings of the CAD as image files</a>.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-04-02<br>
</td>
<td valign="top">For the pages used to provide indices for the
drawings scanned from NARA SW aperture-card <a
href="AgcDrawingIndexBox459.html">Box 459</a> and <a
href="AgcDrawingIndexBox460.html">Box 460</a>, I've
replaced the abbreviated, error-laden drawing titles
originally taken from the aperture-card punches with the <i>actual</i>
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 <a href="AgcDrawingIndex.html">Miscellaneous
drawing index page</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-04-01<br>
</td>
<td valign="top">
<ul>
<li>I've removed the "experimental page" warning at the
top of the pages for <a
href="AgcDrawingIndexBox459.html">Box 459</a> and <a
href="AgcDrawingIndexBox460.html">Box 460</a> MIT/IL
engineering drawings, since as far as I can tell
(without literally checking all 3600 index entries) the
indices are fine. It's definitely worth noting,
though, that the indices were generated from the punches
on the aperture cards holding the microfilms of the
drawings, and that not only is the metadata punched
there not 100% perfect or consistent, but more
importantly, the scanner manufacturer's software that
reads the punches during the scan is subject to all
kinds of problems ... specifically, systematic
substitution of some characters for other
characters. Thus my index-generation software has
to undo a lot of errors introduced by the scanning
software, and that's impossible to do 100%
perfectly. So I just hope it's good enough!
So far, I think it is. Ask me again if I think so
10 boxes or 100 boxes from now.</li>
<li>I've added a page for the scans from <a
href="AgcDrawingIndexBox461.html">Box 461</a>,
although the box is presently incomplete due to issues
with the scanner, which I hope will be resolved fairly
quickly, but am unsure enough of that to post the
partial contents that have already been scanned ...
about half the box. Or to put it more bluntly, the
scanner is broken and needs to be repaired. Box
461 gets into a lot of G&N components we've ignored
previously (IMU, SCT, PIPA, CDU) but it's only a taste
of what's to come.<br>
</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005260-">CAD
transcription for drawing 2005260-</a> (Block II AGC
2003200 timer module A2 electrical schematics).
See also <a href="KiCad/2005260-">the renderings of the
CAD as image files</a>.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005251-">CAD
transcription for drawing 2005251-</a> (Block II AGC
2003200 SQ register and decoding module A3 electrical
schematics). See also <a href="KiCad/2005251-">the
renderings of the CAD as image files</a>.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-03-31<br>
</td>
<td valign="top">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 <a
href="ElectroMechanical.html#Browse_the_Available_Engineering">drilldowns
into their assembly hierarchy</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-03-30<br>
</td>
<td valign="top">As a background task, I'm in the process now
of trying to scan the <i>complete</i> 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
<i>so far</i> 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. <img src="smiley.png" alt=""
width="16" height="16"> 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 <i>too far</i> 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:<br>
<ul>
<li>...</li>
<li><a href="AgcDrawingIndexBox459.html">Index page for
box #459</a> (~1800 drawings)<br>
</li>
<li><a href="AgcDrawingIndexBox460.html">Index page for
box #460</a> (~1800 drawings)<br>
</li>
<li>...</li>
<li><a href="AgcDrawingIndex.html">Miscellaneous index
page</a> (~5000 drawings)</li>
</ul>
<p>Since each aperture-card box corresponds to a specific,
known drawing-number range, hopefully this will still be a
relatively easy system to navigate.<br>
</p>
<p>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 <i>au fait</i> on such stuff.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2019-03-27<br>
</td>
<td valign="top">Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005259-">CAD
transcription for drawing 2005259-</a> (Block II AGC
2003200 scaler module A1 electrical schematics). See
also <a href="KiCad/2005259-">the renderings of the CAD as
image files</a>. 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 <i>me</i> some bother if they hadn't bothered. <img
alt="" src="smiley.png" width="16" height="16"><br>
</td>
</tr>
<tr>
<td valign="top">2019-03-26<br>
</td>
<td valign="top">
<ul>
<li>Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005009A">CAD
transcription for drawing 2005009A</a> (Block II AGC
2003100 strand-select module B15 electrical
schematics). See also <a href="KiCad/2005009A">the
renderings of the CAD as image files</a>. This
is a closely related drawing to 2005924- (for Block II
AGC 2003200), so I corrected various bugs in the
existing 2005924- transcription at the same time.</li>
<li>Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005006-">CAD
transcription for drawing 2005006-</a> (Block II AGC
2003100 erasable memory module electrical
schematics). See also <a href="KiCad/2005006-">the
renderings of the CAD as image files</a>. This
is a closely related drawing to 2005106- (for Block II
AGC 2003200), so I corrected various bugs in the
existing 2005106- transcription at the same time.</li>
</ul>
<p>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.<br>
</p>
<ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-03-25<br>
</td>
<td valign="top">
<ul>
<li>Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005914-">CAD
transcription for drawing 2005914-</a> (Block II AGC
2003100 erasable-memory sense-amplifier modules B13-B14
electrical schematics). See also <a
href="KiCad/2005914-">the renderings of the CAD as
image files</a>. This is a closely related
drawing to 2005920B (for Block II AGC 2003200), so I
corrected various bugs in the existing 2005920B
transcription at the same time.</li>
<li> Added the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005010F">CAD
transcription for drawing 2005010F</a> (Block II AGC
2003100 power-supply modules A30-A31 electrical
schematics). See also <a href="KiCad/2005010F">the
renderings of the CAD as image files</a>. This
is a closely related drawing to 2005916A (for Block II
AGC 2003200), so I made some corrections to 2005916A at
the same time. I also noted that several of the
web-pages for Block II AGC model 2003993 mistakenly
called out drawing 2005010 due to ambiguities in the
original drawings, and so fixed those pages to call out
what I think is the correct drawing (2005971) instead.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-03-22<br>
</td>
<td valign="top">
<p>CAD transcriptions of the electrical schematics for the
Block I DSKY relay modules D7-D14 have been added:<br>
</p>
<ul>
<li>Early model NAV & MAIN DSKY: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006161C">CAD
for drawing 1006161C</a> (plus <a
href="KiCad/1006161C">rendering as image file</a>)</li>
<li>Late model NAV & MAIN DSKY: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1005780-">CAD
for drawing 1005780-</a> (plus <a
href="KiCad/1005780-">rendering as image file</a>)</li>
</ul>
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 relay-module CAD
transcriptions cover <i>all</i> models. But as far as
I can tell with from the available drawings, they do.
The two implementations appear identical at a glance, but
have some pretty significant differences when you start
looking at the details. Unfortunately, they fall into
a kind of "uncanny valley" (yes, I know I'm using the term
incorrectly) in which they are so similar that I felt I
should create 1005780 by adapting the CAD for 1006161, and
yet at the same time so different that I may have ended up
spending more time correcting the adaptation than I would
have simply by transcribing 1005780 from scratch.
Which would make no difference to you, Dear Reader, I
suppose, other than the fact that it means that it would
have been all to easy for me to miss out on
seeing/correcting errors in 1005780 ... which could still be
lurking. On the good side, I suppose, it means that
when I proofed 1005780 I was really doing an extra proofing
of 1006161 by proxy, and thus was able to see (and correct)
errors in it that I hadn't seen in my first proofing of
it. On yet a third hand, however, both of them are so
complex that I won't feel too confident in either of them
until I've seen a simulation of some kind. (The nature
of which is yet to be determined.)<br>
<br>
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.<br>
<br>
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 <i>all</i> of the
specific Block II AGC & DSKY models we're
supporting. <br>
<br>
<a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005028A">The
electrical
schematics for drawing 2005028A (Block II AGC alarm module
B8) have been transcribed to CAD</a>. See
also: <a href="KiCad/2005028A">the renderings of the
CAD as image files</a>. This is for AGC p/n
2003100-021 <i>only</i>, since all other model/dash-numbers
for which we have the corresponding drawings use other
alarm-module circuits from drawings 2005922 or 2005927
instead.<br>
</td>
</tr>
<tr>
<td valign="top">2019-03-20<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006162B">The
electrical
schematics for drawing 1006162B (Block I NAV&MAIN DSKY
decoding module D1-D6 electrical schematics) have been
transcribed to CAD</a>. See also: <a
href="KiCad/1006162B">the renderings of the CAD as image
files</a>. 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
does. <br>
</td>
</tr>
<tr>
<td valign="top">2019-03-19<br>
</td>
<td valign="top">For some reason, even though we acquired the
basic Block I electrical schematics and document ND-1021041
<i>last year</i>, it never occurred to me to update <a
href="Block1.html">the Block I page</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-03-18<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1005730B">Added
the CAD transcription for drawing 1005730B</a>, 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: <a
href="KiCad/1005730B">the renderings of the CAD as image
files</a>. </td>
</tr>
<tr>
<td valign="top">2019-03-15<br>
</td>
<td valign="top">
<p>CAD transcriptions of the electrical schematics for the
Block I DSKY power-supply module have been added:<br>
</p>
<ul>
<li>Early model NAV & MAIN DSKY: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006163G">CAD
for drawing 1006163G</a> (plus <a
href="KiCad/1006163G">rendering as image file</a>)</li>
<li>Late model NAV & MAIN DSKY: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1005756-">CAD
for drawing 1005756-</a> (plus <a
href="KiCad/1005756-">rendering as image file</a>)</li>
</ul>
<p>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 <i>all</i> models. But as far as I can tell
with from the available drawings, they do.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2019-03-14<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006160E">The
electrical
schematics for Block I NAV DSKY (early models 1003458
& 1003524 only) drawing 1006160E, keyboard module
D17, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006160E">the renderings of
the CAD as image files</a>. </li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006150D">The
electrical
schematics for Block I MAIN DSKY (early models 1003459
& 1003540) drawing 1006150D, keyboard module D18,
have been transcribed to CAD</a>. See
also: <a href="KiCad/1006150D">the renderings of
the CAD as image files</a>. </li>
</ul>
Sadly, we don't actually have the electrical-schematic
drawings for <i>later</i> models of either of these Block I
DSKYs. It's worth noting that document ND-1021041 does
have schematics in it for modules <a
href="https://archive.org/stream/apollocommandmodacel_0#page/519/mode/1up">D17</a>
and <a
href="https://archive.org/stream/apollocommandmodacel_0#page/495/mode/1up">D18</a>,
which presumably do represent the final models of the
DSKYs. I've not compared 1006160E and 1006150D in
detail to the schematics in ND-1021041, though a superficial
comparison does show that our schematics for D17 are
definitely not the final form of the design (though D18 may
be).<br>
</td>
</tr>
<tr>
<td valign="top">2019-03-13<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006119D">The
electrical
schematics for Block I AGC drawing 1006119D, rope
sense amplifier module B26 & B27, have been
transcribed to CAD</a>. See also: <a
href="KiCad/1006119D">the renderings of the CAD as
image files</a>. </li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1005700A">The
electrical
schematics for Block I AGC drawing 1005700A, filter
module B5, have been transcribed to CAD</a>. See
also: <a href="KiCad/1005700A">the renderings of
the CAD as image files</a>. This power-supply module
appeared in later Block I AGC models, but seemingly not
in the early models.</li>
</ul>
<p>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 <i>all</i> 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 <a
href="ElectroMechanical.html#Browse_the_Available_Engineering">the
electro-mechanical page</a>. 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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2019-03-12<br>
</td>
<td valign="top">
<ul>
<li>Added (to NARA finding aids on the <a
href="QuestForInfo.html">Quest for Info</a> page) a
document that purports to list all documents processed
by the JSC technical library up to 1988.</li>
<li> Added a handful of <a href="AgcDrawingIndex.html">new
AGC/DSKY engineering-drawing scans</a> which Mike
Stewart and Craig Keithley contributed. Alas,
there's really no good way to point out which ones these
are, so I'd just suggest doing a numerical or textual
search to see if anything you're looking for is there.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-03-11<br>
</td>
<td valign="top">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 <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006118F">drawing
1006118F</a> (plus <a href="KiCad/1006118F">image files</a>)
applying to AGC p/n 1003186 and <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006187A">drawing
1006187A</a> (plus <a href="KiCad/1006187A">image files</a>)
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
ground.<br>
</td>
</tr>
<tr>
<td valign="top">2019-03-08<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006098H">The
electrical
schematics for Block I AGC drawing 1006098H, power-supply
control module B12, have been transcribed to CAD</a>.
See also: <a href="KiCad/1006098H">the renderings of
the CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-03-07<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006086F">The
electrical
schematics for Block I AGC drawing 1006086F, erasable
drivers module B10 and B11, have been transcribed to CAD</a>.
See also: <a href="KiCad/1006086F">the renderings of
the CAD as image files</a>. <br>
<br>
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 <i>agreed</i> 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?<br>
<br>
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 <i>backwards</i>
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.<br>
<br>
<div align="center"><img alt="" src="BackwardsB11.jpg"
width="660" height="441"><br>
</div>
<br>
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!<br>
</td>
</tr>
<tr>
<td valign="top">2019-03-04<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006061C">The
electrical
schematics for Block I AGC drawing 1006061C, erasable
memory stick, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006061C">the renderings of the
CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-03-02<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006074B">The
electrical
schematics for Block I AGC drawing 1006074B,
current-switching stick for erasable memory, have been
transcribed to CAD</a>. See also: <a
href="KiCad/1006074B">the renderings of the CAD as image
files</a>. </td>
</tr>
<tr>
<td valign="top">2019-03-01<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006082F">The
electrical
schematics for Block I AGC drawing 1006082F, driver
service module B7, have been transcribed to CAD</a>.
See also: <a href="KiCad/1006082F">the renderings of
the CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-02-28<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006140L">The
electrical
schematics for Block I AGC drawing 1006140L, clock
oscillator module B6, have been transcribed to CAD</a>.
See also: <a href="KiCad/1006140L">the renderings of
the CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-02-26<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006097F">The
electrical
schematics for Block I AGC drawing 1006097F,
power-switch module B2, have been transcribed to CAD</a>.
See
also: <a href="KiCad/1006097F">the renderings of
the CAD as image files</a>. </li>
<li>All of the CAD drawings so far transcribed for the
Block I and Block II AGC that have depended on reusable
circuit blocks have been "reannotated". The
modules in question are basically all of the analog "B"
modules (as opposed to the digital "A" modules).
What this nonsense statement means is that the reference
designators have been corrected to hopefully agree with
those physically marked on the original modules, as
opposed to using many reference designators arbitrarily
assigned by the KiCad program. If that still
sounds completely opaque ... well, it's something that's
only really meaningful to someone working with actual
AGC B-modules, and not useful to someone who simply
wants to casually look through the schematics (which I
expect is 99% of anybody interested in these CAD
transcriptions of the original schematics at all), so I
won't clutter up this space with further
explanation. Suffice it to say that it's a fix for
an inconsistency with respect to the original design
that has been bugging <i>me</i> for months and months,
so I'm glad that it has finally been taken care of.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-02-24<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006147B">The
electrical
schematics for Block I AGC drawing 1006147B, rope-driver
module B32 & B33, have been transcribed to CAD</a>.
See
also: <a href="KiCad/1006147B">the renderings of the
CAD as image files</a>. <br>
</td>
</tr>
<tr>
<td valign="top">2019-02-20<br>
</td>
<td valign="top">A small but useful <a
href="https://archive.org/details/AgcApertureCardsBatch20190219Images">batch
of engineering-drawing scans from NARA SW</a> was
added. Particularly useful was a much newer revision
of <a
href="https://archive.org/details/AgcApertureCardsBatch20190219Images/page/n79">drawing
6014999 (the index of LM guidance systems)</a> 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 (<a href="2003993-041.html">AGC
2003993-041</a> and <a href="2003994-041.html">DSKY
2003994-041</a>) 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
than before.<br>
</td>
</tr>
<tr>
<td valign="top">2019-02-14<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006199-">The
electrical
schematics for Block I AGC rope strand select module,
namely drawing 1006199-, have been transcribed to CAD</a>.
See also: <a href="KiCad/1006199-">the renderings of
the CAD as image files</a>. 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.
<br>
</td>
</tr>
<tr>
<td valign="top">2019-02-13<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006148E">The
electrical
schematics for Block I AGC rope strand select module,
namely drawing 1006148E, have been transcribed to CAD</a>.
See also: <a href="KiCad/1006148E">the renderings of
the CAD as image files</a>. 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
yet.<br>
</td>
</tr>
<tr>
<td valign="top">2019-02-10<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006099A">The
electrical
schematics for Block I AGC rope strand select module,
namely drawing 1006099A, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006099A">the renderings of the
CAD as image files</a>. 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-02-08<br>
</td>
<td valign="top">CAD transcriptions of the electrical
schematics of interface modules A20/A40 for the later-model
Block I AGCs (1003700, 1003565) <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1005702-">can
be
now be found in our CAD schematics repository</a>.
There is also <a href="KiCad/1005702-">a folder of visual
renderings of those CAD files as images</a>.
Combined with the early-model transcriptions from the 6th, I
think that all Block I AGC models now have transcriptions
for modules A20/A40.</td>
</tr>
<tr>
<td valign="top">2019-02-07<br>
</td>
<td valign="top">CAD transcriptions of the electrical
schematics of interface modules A19/A39 for the later-model
Block I AGCs (1003700, 1003565) <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1005701A">can
be
now be found in our CAD schematics repository</a>.
There is also <a href="KiCad/1005701A">a folder of visual
renderings of those CAD files as images</a>.
Combined with the early-model transcriptions from the 5th, I
think that all Block I AGC models now have transcriptions
for modules A19/A39.<br>
</td>
</tr>
<tr>
<td valign="top">2019-02-06<br>
</td>
<td valign="top">CAD transcriptions of the electrical
schematics of interface modules A20/A40 for the
earliest-model Block I AGCs (1003186, 1003469) <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006535B">can
be
now be found in our CAD schematics repository</a>.
There is also <a href="KiCad/1006535B/">a folder of visual
renderings of those CAD files as images</a>.
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.</td>
</tr>
<tr>
<td valign="top">2019-02-05<br>
</td>
<td valign="top">CAD transcriptions of the electrical
schematics of interface modules A19/A39 for the
earliest-model Block I AGCs (1003186, 1003469) <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006534C">can
be
now be found in our CAD schematics repository</a>.
There is also <a href="KiCad/1006534C/">a folder of visual
renderings of those CAD files as images</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-02-03<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006551-">The
electrical
schematics for Block I AGC module A38, namely drawing
1006551-, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006551-">the renderings of the
CAD as image files</a>. 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. <br>
</td>
</tr>
<tr>
<td valign="top">2019-02-02<br>
</td>
<td valign="top">
<ul>
<li>In the very first Block I AGC schematic drawing I
transcribed to CAD I had stupidly misread a
connector-pin number, and since that very same block of
circuitry appeared identically in the subsequent 17
Block I AGC schematics I've transcribed, I had ended up
propagating the error into 18 CAD drawings. Yay,
me! At any rate, that's now fixed, and shouldn't
have had any effect on anybody anyway, since it was an
"AGC 4" pin number rather than an "AGC 5" pin
number. Still ....</li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006550F">The
electrical
schematics for Block I AGC module A37, namely drawing
1006550F, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006550F">the renderings of
the CAD as image files</a>. This was actually quite a
monster of a task, because the "signal wiring diagram"
associated with it (<a
href="https://archive.org/stream/AgcApertureCardsBatch2Images#page/n17/mode/1up">drawing
1006130-</a>), which is needed for determining
reference designators and input-pin assignments for the
NOR gates, was essentially illegible regardless of how I
attempted to post-process it. Check it out if you
think I'm exaggerating the horrific quality of this
drawing! Of course, I <i>could</i> have just
ignored the wiring diagram completely and arbitrarily
assigned these values without affecting the electrical
functionality in any way, as I've already done for a
couple of schematics in which the wiring diagrams were
missing completely. But for some reason I got the
idea in my head that I could extract the NOR-gate
reference designators and input-pin assignments from the
wiring diagram <i>in spite of</i> the fact that the
drawing itself was illegible. And indeed, it
turned to be <i>almost</i> possible to do that
perfectly. In the end, it turned out that only two
gates which were wired in parallel couldn't be
distinguished from each other, so that for them I had
two reference designators and two gates and didn't know
which went with which. Hardly the worst problem
one could have! In other words, overall the
reverse-engineering of the wiring diagram worked out
quite well. Pointless, I know, since it would seem
so totally unnecessary to anyone not obsessed with
authenticity, but weirdly satisfying in a
digital-archaeology sense. <img src="smiley.png"
alt="" width="16" height="16"><br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-31<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006541B">The
electrical
schematics for Block I AGC module A35, namely drawing
1006541B, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006541B">the renderings of
the CAD as image files</a>. </li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006557D">The
electrical
schematics for Block I AGC module A36, namely drawing
1006557D, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006557D">the renderings of
the CAD as image files</a>. </li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-30<br>
</td>
<td valign="top">
<ul>
<li>Don Eyles has pointed out that I have been a bit too
aggressive in my <a href="index.html#Acknowledgements">acknowledgements
of the original AGC developers</a>, to the point where
I was acknowledging some folks that weren't even AGC
software developers at all. (Specifically, people
who worked on the "all-digital simulation", which was an
important task and a great contribution, but <i>not</i>
AGC software development.) So I've removed some
names that used to be in the acknowledgements. If
you're one of the people affected, my apologies!
If I had some way to cover the all-digital simulation
(and you) here on this site, I would, but my information
about it and my resources are not unlimited.
Particularly the former.</li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006546A">The
electrical
schematics for Block I AGC module A32, namely drawing
1006546A, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006546A">the renderings of
the CAD as image files</a>. </li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-29<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006548-">The
electrical
schematics for Block I AGC modules A30-31, namely drawing
1006548-, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006548-">the renderings of the
CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-01-25<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006559D">The
electrical
schematics for Block I AGC module A29, namely drawing
1006559D, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006559D">the renderings of the
CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-01-21<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006544B">The
electrical
schematics for Block I AGC module A27, namely drawing
1006544B, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006544B">the renderings of the
CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-01-20<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006554-">The
electrical
schematics for Block I AGC module A25, namely drawing
1006554-, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006554-">the renderings of the
CAD as image files</a>. 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.</td>
</tr>
<tr>
<td valign="top">2019-01-19<br>
</td>
<td valign="top">
<ul>
<li>A couple of files whose names differed only in their
case ("device.lib" and "Device.lib") had crept into the
"schematics" branch of our git repository, where they
would sabotage attempts to checkout the schematics in
case-insensitive files-systems (like for Windows or Mac
OS X); I never noticed it, since I use Linux, whose
file-systems aren't crippled in that way. <img
src="smiley.png" alt="" width="16" height="16">
But kidding (or <i>is</i> it?) aside, the reason I'm
mentioning this relatively unimportant fix is that it
involved elimination of a folder of KiCad symbol-library
files, msSchematics/libs/, in which there's a remote
chance someone could be interested in the future.
If so, just consult <a
href="https://github.com/virtualagc/virtualagc/issues/1065">the
original issue report</a> to see how to find the
folder in the repository history.<br>
</li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006555A">The
electrical
schematics for Block I AGC module A24, namely drawing
1006555A, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006555A">the renderings of
the CAD as image files</a>. <br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-17<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006545-">The
electrical
schematics for Block I AGC module A23, namely drawing
1006545-, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006545-">the renderings of the
CAD as image files</a>. 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-01-16<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006553E">The
electrical
schematics for Block I AGC module A22, namely drawing
1006553E, have been transcribed to CAD</a>. See
also: <a href="KiCad/1006553E/">the renderings of the
CAD as image files</a>. </td>
</tr>
<tr>
<td valign="top">2019-01-14<br>
</td>
<td valign="top"><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006540A">The
electrical
schematics for Block I AGC modules A1-A16, namely drawing
1006540A, have been transcribed to CAD</a>, and
cross-checked/corrected against <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006540r">the
CAD
schematics previously recovered from document ND-1021041</a>
before the original drawing became available. <a
href="KiCad">The usual PNG renderings of the CAD files for
both versions are available</a>. The two
implementations do differ slightly, with the difference
being that one backplane signal in the ND-1021041 version
has a higher drive capacity. <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Schematics/1006540A/README.md">You
can read the writeup about the discrepancies here</a>, 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 <i>most</i> of the information on that
topic. <br>
<br>
Only the pages for AGC models <a href="1003700-051.html">1003700-051</a>
and <a href="1003700-071.html">1003700-071</a> 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. <br>
<br>
By the way, this is the <i>last</i> 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 <i>errors</i> 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!<br>
</td>
</tr>
<tr>
<td valign="top">2019-01-12<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006543D">The
electrical
schematics for Block I AGC module A17, namely drawing
1006543D, have been transcribed to CAD</a>, and
cross-checked/corrected against <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006543r">the
CAD
schematics previously recovered from document
ND-1021041</a> before the original drawing became
available. <a href="KiCad">The usual PNG
renderings of the CAD files for both versions are
available</a>. While the two implementations
differ slightly, I believe that that's just due to
errors in ND-1021041, but <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Schematics/1006543D/README.md">you
can read the writeup about the discrepancies here</a>
if you like.</li>
<li>It turns out that <a href="AgcDrawingIndex.html">the
master MIT/IL engineering-drawing index page</a> had
immensely more garbage in it than I imagined
yesterday. It's still big, but it's now a fraction
of the size it was yesterday, as well as eliminating
loading of an external stylesheet I hadn't known about,
so it hopefully will be a tad more responsive than
before. Plus, its table borders had disappeared
when viewed in Chrome for some reason, and I've brought
them back.</li>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006542-">The
electrical
schematics for Block I AGC module A17, namely drawing
1006543D, have been transcribed to CAD</a>, and
cross-checked/corrected against <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006542r">the
CAD
schematics previously recovered from document
ND-1021041</a> before the original drawing became
available. <a href="KiCad">The usual PNG
renderings of the CAD files for both versions are
available</a>. The two implementations differ,
primarily in that there are 7 NOR-gates which are wired
up differently, resulting in 7 changes of polarity in
the backplane signals. Therefore, I think there is
probably a later revision of the schematic that we don't
have. <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Schematics/1006542-/README.md">You
can read the full writeup of the discrepancies here</a>
if you like.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-11<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006549B">The
electrical
schematics for Block I AGC module A26, namely drawing
1006549B, have been transcribed to CAD</a>, and
cross-checked/corrected against <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006549r">the
CAD
schematics previously recovered from document
ND-1021041</a> before the original drawing became
available. <a href="KiCad">The usual PNG
renderings of the CAD files for both versions are
available</a>. The two implementations are
electrically identical.</li>
<li>Because of the WYSIWYG HTML editor I normally use on
this website, the HTML becomes littered with junk like
big blocks of useless crud and thus has to be cleaned up
from time to time to keep this junk from proliferating
too much. Which I've just done. The
improvements in some file-sizes (particularly this
change log page and the MIT/IL drawing-index page) are
semi-dramatic. Unfortunately, the automated
cleaner did mess up a couple of my tables ... all of
which I hopefully found and fixed, though I guess it may
take a while to be sure.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-10<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006552A">The
electrical
schematics for Block I AGC module A28, namely drawing
1006552A, have been transcribed to CAD</a>, and
cross-checked/corrected against <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006552r">the
CAD
schematics previously recovered from document
ND-1021041</a> before the original drawing became
available. <a href="KiCad">The usual PNG
renderings of the CAD files for both versions are
available</a>. My assessment is that the two
versions are essentially the same, though that is open
to interpretation. <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Schematics/1006552A/README.md">There's
a
full analysis of the differences as well</a>.</li>
<li> The way hyperlinks into our Internet Archive site on
<a href="ElectroMechanical.html">the electro-mechanical
page</a> have been treated has increasingly bugged me,
so I've changed the treatment to correspond to how the
engineering drawing index page and the individual pages
for AGC/DSKY models treat them. Alas, it turned
out to be really complex, because of some
inconsistencies in the way those hyperlinks are supposed
to be formatted. I think I've got them all right,
but it's possible there might be some broken links on
the electro-mechanical page that it will be discovered
and fixed over the course of time.</li>
<li><a href="ElectroMechanical.html#Mechanical_Drawings">Information
has
been added to the CAD-file section of the
electro-mechanical page about the expectations for 2D
or 3D transcription of AGC/DSKY mechanical drawings
into CAD form</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-09<br>
</td>
<td valign="top">
<ul>
<li><a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006556A">The
electrical
schematics for Block I AGC module A21, namely drawing
1006556A, have been transcribed to CAD</a>, and
cross-checked/corrected against <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006556r">the
CAD
schematics previously recovered from document
ND-1021041</a> before the original drawing became
available. <a href="KiCad">The usual PNG
renderings of the CAD files for both versions are
available</a>. The remaining differences after
this reconciliation process lead me to believe that
ND-1021041 may have been based on 1006556C ... i.e., a
couple of revisions higher than our latest revision of
the schematic drawing. The match is quite close,
though, with just 3 gates (and associated connector
pins) differing. <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Schematics/1006556A/README.md">There's
a
full analysis of the differences as well</a>.</li>
<li> It also turns out, now that I've worked through a 2nd
drawing, that the Block I signal-wiring diagrams are
don't unambiguously provide the wiring of the logic from
the schematic in all cases, so I've added the necessary
verbiage about that issue to <a
href="ElectroMechanical.html#Appendix:_Signal_Wiring_Diagrams_for_the">the
explanation
of Block I signal-wiring diagrams on the
electro-mechanical page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2019-01-06<br>
</td>
<td valign="top">As foreshadowed in the last note, I have
completed my automated comparison (using <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Scripts/netlistCompare.py">a
newly-written Python script</a>) between <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006547r">the
CAD
files for Block I AGC module A33-A34 that I transcribed
from figures in AC Electronics document ND-1021041 (which
I call 1006547r)</a>, vs <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006547G">the
CAD
files I transcribed from the official MIT/IL drawing
1006547G</a>. 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
href="https://github.com/virtualagc/virtualagc/blob/schematics/Schematics/1006547G/README.md">A
full writeup about the discrepancy has been made</a>.
I
don't claim the automated comparison is perfect, of course,
but I'm happy that it found stuff for me to fix. <img
src="smiley.png" alt="" width="16" height="16"> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-01-04<br>
</td>
<td valign="top">The schematic for the Block I AGC scalar
module (namely drawing 1006547G) has been manually
transcribed to KiCAD placed into our git schematics
repository, <a href="KiCad/1006547G/">along with the usual
PNG rendering thereof</a>. This is the first <i>actual</i>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2019-01-01<br>
</td>
<td valign="top">Completed writing <a
href="ElectroMechanical.html#Appendix:_Signal_Wiring_Diagrams_for_the">the
explanation
about how Block I signal wiring diagrams work</a> on the
electro-mechanical page ... which I think finally brings the
electro-mechanical page to completion, if not necessarily
perfection.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2018" onchange="viewOrHide(2018)" autocomplete="off"
checked="checked" type="checkbox"><b>Hide 2018 change notes?</b>
<table summary="" id="table2018" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top">2018-12-31<br>
</td>
<td valign="top">Well, it took a while, but <a
href="ElectroMechanical.html">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</a>. 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 <i>and</i> 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! <br>
<br>
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:<br>
<ul>
<li>A flat view of the drawing set, ordered by drawing
number and revision.</li>
<li>A hierarchical view of the drawing set, ordered by
G&N (Guidance & Navigation) system type ... or
if you prefer to think of it that way, by Apollo mission
number, or by AGC or DSKY part number. In this
hierarchical view, you navigate through the drawings on
an assembly-by-assembly basis for whatever G&N
system, mission number, or AGC/DSKY part number you feel
like.</li>
</ul>
<p>All other supplemental information provided by the
electro-mechanical page is now subordinated to this basic
drawing-browsing activity.<br>
</p>
<p>Some information that I deemed uninteresting and
distracting was (gasp!) even removed from the page
entirely, and <i>not</i> 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.<br>
</p>
<p>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 <i>all</i> of them.<br>
</p>
<p>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 <i>something</i> 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.<br>
</p>
<p>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! <img
src="smiley.png" alt="" width="16" height="16"><br>
</p>
<p>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 <i>real</i>
Block I drawings instead of having to "recover" schematics
from the bits and pieces in AC Electronics document
ND-1021041. It will be interesting to compare the
real schematics (once they're in CAD) to the "recovered"
ones I made before we discovered that the real drawings
still exist.<br>
</p>
<p>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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2018-12-23<br>
</td>
<td valign="top">As mentioned on the note for the 15th,
there's now <a
href="links.html#Miscellaneous_Microfilmed_Documents">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</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-12-22<br>
</td>
<td valign="top">
<ul>
<li><a href="AgcDrawingIndex.html">The MIT/IL
engineering-drawing index page </a>has been updated
to include all of the engineering drawings I scanned
this week at NARA. There are over 4400 scans in
all now.</li>
<li> Various documents related to midcourse-correction
processor for NASA's RTCC (Real Time Computer Complex)
have been added to the Apollo 11, 13, 14, 15, and 16
items in <a
href="links.html#Miscellaneous_Mission_Documents">the
document library's "miscellaneous mission documents"
section</a>. The full-quality scans are over at
our Internet Archive site as well, though I'm going to
stop providing explicit double-links (local low-quality
plus Internet Archive high-quality). If you wonder
whether a higher-quality version is available for some
document or the other, just head over there and
look. But as far as these particular documents are
concerned, I'm told they're particularly valuable (for
something relating to the RTCC rather than the AGC <img
src="smiley.png" alt="" width="16" height="16">)
because they organize together in one place information
that previously difficult to access because it was
spread out over a number of hard-to-get memos.
Check them out. From my perspective, the document
on abort-plans for Apollo 11 seems particularly
interesting.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-12-16<br>
</td>
<td valign="top"><a href="AgcDrawingIndex.html">The MIT/IL
engineering-drawing index page </a>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
amateurish.<br>
</td>
</tr>
<tr>
<td valign="top">2018-12-15<br>
</td>
<td valign="top">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 <a href="QuestForInfo.html">the
page about NARA (or as it's charmingly titled,
"Documentation Quest! Stalking the Wild AGC")</a>:<br>
<ul>
<li><a href="QuestForInfo.html#2004">The section about my
previous finding aids for NARA</a> has been updated
with the possibly-important info that in 2010, NARA put
all the documents I carefully indexed in 2004 into new
boxes, with different numbers written on them.
Yay!</li>
<li>In 2004, I had scanned all of the title pages of
documents in boxes I thought might be of future
interest, but that there was no time back then to deal
with. For some insane reason I left these scans as
TIFFs which, at least in my browser, you can't directly
view. Similarly, a finding aid from NARA itself
was left in a Microsoft Word format that's not useful in
a web browser. At any rate, I've now converted
these to PNGs and PDF, respectively, making them far
more convenient for web purposes.</li>
<li><a href="QuestForInfo.html#2018">I've added a new
section with finding aids and hopefully-helpful info</a>
about my present efforts at NARA to extract drawings
from "aperture cards".</li>
</ul>
<p>I've also updated our document library page with a couple
of document I scanned from NARA's aperture cards.
There's actually <a
href="links.html#Miscellaneous_Microfilmed_Documents">an
entirely new section on our document library page</a>
with just these two document, also I expect it to grow
somewhat over the remainder of the year.<br>
</p>
<p>Finally, the indices for all drawings scanned this week
(batches 3 through 7) have been added to <a
href="AgcDrawingIndex.html">our MIT/IL Engineering
Drawing Index page</a>.<br>
</p>
<ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-12-09<br>
</td>
<td valign="top">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 <i>main</i> content on <a
href="ElectroMechanical.html">the electro-mechanical page</a>
(namely, drawing trees for the electrical design of specific
AGC/DSKY models) <i>and</i> 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 <a href="AgcDrawingIndex.html">new MIT/IL
AGC/DSKY engineering-drawing page</a>, 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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-12-05<br>
</td>
<td valign="top">
<ul>
<li>Added a TRW document about Apollo 8 flight-program
verification to <a
href="links.html#Miscellaneous_Mission_Documents">the
mission-documents section of our document-library page</a>.</li>
<li>A huge batch of electrical and mechanical drawings has
been added to our electro-mechanical pages, filling in
lots of gaps in our electrical knowledge of the Block I
AGC&DSKY and our mechanical knowledge of the Block
II AGC&DSKY. This is an ongoing process that
is by no means complete. Nor have I integrated the
drawings into the various AGC/DSKY electrical sections
of the electro-mechanical page yet. Nevertheless,
<a href="ElectroMechanical.html#NARA_SW_Batch_1">there's
an index allowing you to access all the new drawings
from our Internet Archive site</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-12-03<br>
</td>
<td valign="top">
<ul>
<li>The revision code for the Block I AGC program Corona,
flown on AS-202, previously unknown, is now known.
It was rev 261. The Corona entry on the Colossus
page has been updated accordingly.</li>
<li>We now have the AC Electronics manual for Apollo
11. (Thanks, James Berry!) Previously, we
had only the Apollo 15 and 16 versions, so it's great to
add Apollo 11 into that mix with its 50th anniversary
looming. The archival-quality page scans are on <a
href="https://archive.org/details/AcElectronicsApollo11">our Internet
Archive site</a>, while the <a
href="Documents/AcElectronicsApollo11.pdf">lower-quality
PDF
with searchable text</a> is here locally in our
document library. The book — which, never having
seen one in person I was surprised to find <i>really</i>
is a "book" rather than a jumble of papers loosely bound
together, printed specifically as what's typically
called a "trade paper edition" book — was purchased in a
used-book store many years ago for $5, after apparently
having been sold by the MSC employee who originally
owned it. Which just goes to show that used-book
stores are great places. But I already knew that.
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-11-30<br>
</td>
<td valign="top">I've been increasingly concerned for a number
of reasons about the way the <a
href="ElectroMechanical.html">electro-mechanical page</a>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-27<br>
</td>
<td valign="top">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
ago.<br>
<br>
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 <i>complete</i> 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.<br>
<br>
At any rate, significant changes have been made to the
electro-mechanical page to accommodate all of this new
material:<br>
<ul>
<li>There's <a href="ElectroMechanical.html#NARA_Block_I">a
completely new Appendix</a>, in which all of the new
Block I drawings are indexed.</li>
<li>Scans of the relevant drawings have been added to each
of following sections, to flesh out the ND-1021041
figure links that were already there:</li>
<ul>
<li><a href="ElectroMechanical.html#1003700">Block I AGC
1003700</a></li>
<li><a href="ElectroMechanical.html#1003707">Block I
main DSKY 1003707</a></li>
<li><a href="ElectroMechanical.html#1003706">Block I nav
DSKY 1003706</a><br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-11-26<br>
</td>
<td valign="top">Added the recovered CAD drawing for 1006556
(Block I AGC module A21, "logic flow S"). Contrary to
my usual habit, I've only made <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006556r">the
CAD
files</a> 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!<br>
<br>
Besides not making the PNG files for this drawing, I'm also
going to pause most of the effort of recovering the <i>rest</i>
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 <img alt=""
src="smiley.png" width="16" height="16">), 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 <i>look</i> 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.<br>
<br>
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.<br>
<br>
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. <img alt=""
src="smiley.png" width="16" height="16"> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-24<br>
</td>
<td valign="top">
<ul>
<li>Steven Hauer was kind enough to send in updated
descriptions and additional photos of his project to
implement a physical AGC and DSKY using Mike Stewart's
groundwork in capturing Block II schematics from the
drawings Eldon Hall contributed plus document
ND-1021042. Naturally, I've updated <a
href="Pultorak.html#Steven_Hauers_Implementation">our
physical-implementations page</a> accordingly.
Looks as though it's running pretty well now, though
it's still a work in progress!<br>
</li>
<li>All of the Block I schematics transcribed from
ND-1021041 so far have been tweaked, particularly
insofar as their power-supply filtering circuits were
concerned. (Somehow I had failed to put in the
values of the filtering capacitors. Yikes!)</li>
<li>Drawing 1006543 has been recovered from
ND-1021041. It is the Block I "logic flow C"
module A17, and is a pot pourri of various stuff, with
the largest contribution being parity logic. <a
href="ElectroMechanical.html#1006543r">Links for the
various CAD and PNG files are here</a>. There
were lots of pin-numbering errors in ND-1021041, so I
had to arbitrarily reassign various signals to
otherwise-unused pins. That's a normal experience
with these drawings, but there were quite a few more
errors than usual, given the relative simplicity of this
module's schematics. I hope the number of wiring
errors doesn't turn out to be comparable!</li>
<li>Drawing 1006542 has been recovered as well. It
is the Block I "logic flow B" module, A18. <a
href="ElectroMechanical.html#1006542r">Here are the
CAD and PNG links</a>. Frankly, in spite of
having spent the day with it, I'm not entirely clear
exactly what the stuff in it is for yet, so I can't give
you a concise buzzword for the module's functionality.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-11-21<br>
</td>
<td valign="top">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
same! (<a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006540r">KiCad
schematics</a>, and PNG renderings of the <a
href="KiCad/1006540r-main.png">main sheet</a> and a <a
href="KiCad/1006540r-tables.png">sheet with tables of
backplane signal names</a>.)<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-19<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-19<br>
</td>
<td valign="top">On the electro-mechanical page, rearranged
the Block I AGC hyperlinks into document ND-1021041 so that
they're a bit more useful.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-18<br>
</td>
<td valign="top">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.<br>
<br>
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. (<a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006552r">KiCad
schematics</a> and PNG renderings of <a
href="KiCad/1006552r-top.png">top-level sheet</a> plus
sheets corresponding to ND-1021041 Figures <a
href="KiCad/1006552r-Fig-4-53.png">4-53</a>, <a
href="KiCad/1006552r-Fig-4-57.png">4-57</a>, <a
href="KiCad/1006552r-Fig-4-59.png">4-59</a>, <a
href="KiCad/1006552r-Fig-4-62.png">4-62</a>, <a
href="KiCad/1006552r-Fig-4-143.png">4-143</a>, and <a
href="KiCad/1006552r-Fig-4-181.png">4-181</a>.) It
went much better than yesterday's drawing, with no obvious
errors in document ND-1021041. <br>
<br>
There <i>is</i> 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 <i>just</i> 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 P<i>M_N</i>,
where <i>M</i> is the module number and <i>N</i> is the
pin number. I supplement that scheme by maintaining a
connectivity database as I go along that tells which of the
P<i>M_N</i> pins are connected to which other P<i>M_N</i>
pins. For example, pins P33_65 and P33_77 in
module A33 are connected to pin P34_53 via the backplane. <br>
<br>
Eventually I'll eliminate the P<i>M_N</i> 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 <i>this</i> stage. For now, for
drawings I've already transcribed, the files <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Scripts/pinsBlockI.txt">pinsBlockI.txt</a>
and <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Scripts/connectionsBlockI.txt">connectionsBlockI.txt</a>
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.<br>
<br>
Finally, as an afterthought <img src="smiley.png" alt=""
width="16" height="16">, I've added the CAD transcription
for Block I AGC drawing 1006549, "Logic Flow J", module
A26. (<a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006549r">KiCad
schematics</a> and PNG renderings for the <a
href="KiCad/1006549r-top.png">top-level sheet</a> and for
sheets corresponding to ND-1021041 Figures <a
href="KiCad/1006549r-Fig-4-61.png">4-61</a> and <a
href="KiCad/1006549r-Fig-4-181.png">4-181</a>.)<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-17<br>
</td>
<td valign="top">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.<br>
<br>
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.<br>
<br>
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 <img src="smiley.png" alt="" width="16"
height="16">, 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.<br>
<br>
With that said, I'm pretty pleased with this very first
drawing. As usual, we have <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006547r">the
KiCad
schematics</a>, along with PNG renderings of them: <a
href="KiCad/1006547r-top.png">top-level sheet</a>, and
sheets roughly corresponding to ND-1021041 Figures <a
href="KiCad/1006547r-Fig-4-59.png">4-59</a>, <a
href="KiCad/1006547r-Fig-4-153.png">4-153</a>, <a
href="KiCad/1006547r-Fig-4-165.png">4-165</a>, and <a
href="KiCad/1006547r-Fig-4-181.png">4-181</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-15<br>
</td>
<td valign="top">Added transcription of drawing 2005012B
(fixed memory module B1-6 for all AGC models). <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005012B">The
KiCad
schematics are here</a>, and we also have PNG renderings
from the CAD for the drawing (<a
href="KiCad/2005012B-p1of2.png">sheet 1</a> and <a
href="KiCad/2005012B-p2of2.png">sheet 2</a>). 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. <img alt=""
src="smiley.png" width="16" height="16"> This is a
significant milestone, though, because<br>
<br>
<table width="60%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<td valign="top"><font color="red">We now have
complete transcriptions to CAD of all of the
original Apollo Program electrical schematics for
AGC p/n 2003200, as well as renderings of them in
PNG form. The digital portions of the
circuitry have been converted to Verilog for
simulation purposes, and the simulated electronics
can run the AGC suite of validation software
without error.</font><br>
</td>
</tr>
</tbody>
</table>
<br>
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
<a href="ElectroMechanical.html">electro-mechanical page</a>.
But
I think it's pretty swell anyway.<br>
<br>
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.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-11<br>
</td>
<td valign="top">Added transcription of drawing 2005106-
(erasable memory module B12 for AGC 2003200). <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005106-">The
KiCad
schematics are here</a>, and <a
href="KiCad/2005106--p1of1.png">the PNG rendering is here</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-10<br>
</td>
<td valign="top">Added transcription of drawing 2005100D (rope
driver modules B16-B17 for AGC 2003200). <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005100D">The
KiCad
schematics are here</a>; as is usual for these last few
modules, there are separate PNG renderings for visual
correspondence to the original (sheets <a
href="KiCad/2005100D-p1of2.png">1</a> and <a
href="KiCad/2005100D-p2of2.png">2</a>) and for electrical
correspondence (<a href="KiCad/2005100D-top.png">top-level
sheet</a> and circuit blocks <a
href="KiCad/2005100D-circuitA.png">A</a>, <a
href="KiCad/2005100D-circuitB.png">B</a>, <a
href="KiCad/2005100D-circuitC.png">C</a>). 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. <img
src="smiley.png" alt="" width="16" height="16"><br>
</td>
</tr>
<tr>
<td valign="top">2018-11-08<br>
</td>
<td valign="top">Added transcription of drawing 2005924-
(strand select module B15, for AGC 2003200). <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005924-">The
KiCad
schematics are here</a>; there are separate PNG renderings
for visual fidelity (<a href="KiCad/2005924--p1of1.png">single
sheet</a>) vs electrical properties (<a
href="KiCad/2005924--top.png">top-level sheet</a> and
circuit blocks <a href="KiCad/2005924--circuitA.png">A</a>,
<a href="KiCad/2005924--circuitB.png">B</a>, <a
href="KiCad/2005924--circuitC.png">C</a>).<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-07<br>
</td>
<td valign="top">
<ul>
<li>Added transcriptions of drawing 2005919A (sense
amplifier module B14, for AGC 2003200). This
module seems to be structurally identical to yesterday's
drawing 2005920B (module B13), but with the backplane
connector pins carrying different signals, so I'm not
sure why it's a separate drawing. For AGC 2003100,
it was actually one single drawing (and module
p/n). Possibly there's some difference I've
overlooked. Moreover, this called my attention to
several errors I had made in the transcription of
2005920B, so I'm a bit uneasy that a few more bugs are
lurking in both .... At any rate, <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005919A">the
KiCad
schematics are here</a>. Likewise, there are
separate PNG renderings for visual fidelity (sheets <a
href="KiCad/2005919A-p1of2.png">1</a> and <a
href="KiCad/2005919A-p2of2.png">2</a>) vs electrical
properties (<a href="KiCad/2005919A-top.png">top-level
sheet</a> and <a href="KiCad/2005919A-circuitA.png">its
sub-circuit</a>).</li>
<li>Hoping to combat the complexity of this website (at
least a little!) added a brief cheat-sheet of hyperlinks
to the top of <a href="index.html">the main page</a>. I
know, I know! I invariably combat complexity by
adding more complexity.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-11-06<br>
</td>
<td valign="top">
<ul>
<li>Added some fun anecdotal info to the description of <a
href="Colossus.html#TRIVIUM">the TRIVIUM program </a>now
residing
on our Colossus page.<br>
</li>
<li>Fixed a wiring bug reported by a correspondent, in the
CAD transcription and PNGs of drawing 2005916A.</li>
<li>Added transcription of drawing 2005005D (current
switch module B11, for AGC p/n 2003100 and 2003200) into
CAD. <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005005D">The
KiCad
schematics are here</a>, and PNG renderings (sheets <a
href="KiCad/2005005D-p1of2.png">1</a> & <a
href="KiCad/2005005D-p2of2.png">2</a>) are also
available.</li>
<li>Added transcription(s) of drawing 2005920B (sense
amplifier module B13, for AGC 2003200). <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005920B">The
KiCad
schematics are here</a>. Like yesterday's
drawing 2005104B, it's not possible to make a CAD
transcription of 2005920B that's both electrically
correct and visually accurate with respect to the
original. Therefore, separate transcriptions have
been made for visual fidelity (PNGs for sheets <a
href="KiCad/2005920B-p1of2.png">1</a> and <a
href="KiCad/2005920B-p2of2.png">2</a>) vs electrical
properties (PNGs for <a href="KiCad/2005920B-top.png">top-level
sheet</a> and <a href="KiCad/2005920B-circuitA.png">its
sub-circuit</a>).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-11-05<br>
</td>
<td valign="top">Added the transcription of drawing 2005104B
(erasable driver module B9&B10, for AGC p/n 2003200)
into CAD. <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005104B">The
KiCad
schematic files are here</a>. 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 <a href="KiCad/2005104B-p1of2.png">1</a> and <a
href="KiCad/2005104B-p2of2.png">2</a>) and the electrical
(<a href="KiCad/2005104B-top.png">top level</a>, circuit
blocks <a href="KiCad/2005104B-circuitA.png">A</a> and <a
href="KiCad/2005104B-circuitB.png">B</a>) are also
available.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-03<br>
</td>
<td valign="top">Drawing 2005922- (alarm module B8, for AGC
p/n 2003200 — or at least, a very close revision to the
desired 2005922A) added. <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005922-">KiCad
schematic
files</a> and PNGs (sheets <a
href="KiCad/2005922--p1of3.png">1</a>, <a
href="KiCad/2005922--p2of3.png">2</a>, and <a
href="KiCad/2005922--p3of3.png">3</a>) all available.<br>
</td>
</tr>
<tr>
<td valign="top">2018-11-02<br>
</td>
<td valign="top">Drawing 2005003E (oscillator module B7, for
AGC p/n 2003200) has been transcribed to CAD. <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005003E">The
KiCad
drawings are available</a>, as well as PNG printouts of
its sheets <a href="KiCad/2005003E-p1of3.png">1</a>, <a
href="KiCad/2005003E-p2of3.png">2</a>, and <a
href="KiCad/2005003E-p3of3.png">3</a>. <br>
</td>
</tr>
<tr>
<td valign="top">2018-11-01<br>
</td>
<td valign="top">Drawing 2005916A (power-supply modules
A30-A31, for AGC p/n 2003200) has been transcribed to
CAD. <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005916A">The
KiCad
drawings are available</a>, as well as PNG printouts of
its <a href="KiCad/2005916A-p1of2.png">sheet 1</a> and <a
href="KiCad/2005916A-p2of2.png">sheet 2</a>. With
this drawing now available, all of the A-modules for AGC
2003200 have now been transcribed to CAD. Next, the B-module
drawings!<a href="KiCad/2005916A-p2of2.png"><br>
</a></td>
</tr>
<tr>
<td valign="top">2018-10-31<br>
</td>
<td valign="top">Similarly to yesterday's update, I added
links into document ND-1021041 for the module electrical
schematics for the <a href="ElectroMechanical.html#1003707">Block
I
main-panel DSKY</a> and <a
href="ElectroMechanical.html#1003706">navigation-panel
DSKY</a>. 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!<br>
</td>
</tr>
<tr>
<td valign="top">2018-10-30<br>
</td>
<td valign="top"><a href="ElectroMechanical.html#1003700">In
the Block I AGC (model #1003700) section of the
electro-mechanical page</a>, 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
schematics.<br>
</td>
</tr>
<tr>
<td valign="top">2018-10-26<br>
</td>
<td valign="top">
<ul>
<li>I've put in a considerable effort creating a software
tool that can statically compare Mike Stewart's
preexisting KiCad/Verilog implementation of the AGC
electronics with the identical-in-spirit but
very-different-in-detail KiCad/Verilog implementation
I've been creating. The two implementations were
effectively identical in behavior in terms of running <a
href="https://github.com/virtualagc/virtualagc/tree/master/Validation">the
AGC
validation-suite software</a> <i>before</i> I started
statically comparing the models, and I'm pleased to say
that even though the static comparison found a
half-dozen or so wiring errors in each of the two
implementations, their behavior is <i>still</i>
effectively identical now that those errors are
fixed. Admittedly, not all of the fixes to Mike's
simulation have been pushed upstream yet, but hopefully
we'll be able to manage that at some point. <img alt=""
src="smiley.png" width="16" height="16"> I'm not
pretending that either implementation is perfect yet,
and I haven't completed my checkout of them, but I think
this is a significant milestone in the journey towards
that goal.<br>
</li>
<li>Due to the schematic wiring-error fixes just
mentioned, as well as to recent improvements in KiCad's
ability to render our schematics, all of <a
href="KiCad/">the PNG images for the schematics I've
been creating</a> have now been re-rendered on the
website (though they're uploading as I write this, and
it may be a while before they manage to finish doing
so). They look a lot prettier, particularly when
viewed on smaller screens or printed on smaller
paper. Even the E-sized drawings are legible when
printed on U.S. letter-sized paper, assuming you're
wearing powerful enough reading glasses, though for my
old eyes, tabloid-sized paper (11"×17") is considerably
more comfortable to read. <img alt=""
src="smiley.png" width="16" height="16"></li>
<li>Some descriptive material on the <a
href="ElectroMechanical.html">electro-mechanical page</a>
and <a href="Verilog.html">hardware-simulation page</a>
has been updated. They're both very much still
works-in-progress, particularly the latter page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-10-20<br>
</td>
<td valign="top">
<ul>
<li>One of the documents from Russ Larson's papers, namely
<a href="Documents/agcis_13_yul.pdf">the YUL
documentation</a> mentioned last time, actually has a
very short Block I AGC sample program called TRIVIUM (by
"IMA NIT-PICKER") attached to the end of it.
Considering that this is only the 2nd Block I AGC
program we've ever seen, after Solarium, that's
reasonably exciting. At any rate, <a
href="Colossus.html#TRIVIUM">TRIVIUM</a> has therefore
been <a
href="https://github.com/virtualagc/virtualagc/tree/master/TRIVIUM">transcribed
to
source code</a>, and added to our repertoire of AGC
programs. Because its purpose was to demonstrate
the usage of YUL, TRIVIUM contained some deliberate
errors that actually made its assembly by YUL (or yaYUL)
fail, so I've also created a version called
"TRIVIUM-repaired" that has those errors fixed, and <a
href="https://github.com/virtualagc/virtualagc/tree/master/TRIVIUM-repaired">added
that
program on github as well</a>.</li>
<li><a href="SCDs/">We've gotten in a heap of SCDs, or
"specification control drawings", for the various
electronic and mechanical components used in the AGC
and DSKY designs</a>. For our purpose, these
basically serve the purpose of manufacturers' datasheets
for the components, and we have them for all but a
handful of the parts used in the electrical/mechanical
design.</li>
<li>The Verilog-based simulation of the AGC electrical
design that I've been mentioning in the last few updates
has reached the point of being <a
href="https://github.com/virtualagc/virtualagc/tree/master/Validation">able
to
run (and <i>pass</i>) the AGC's suite of Validation
software</a> that we use to help insure the accuracy
of yaAGC. That's not to say that it's <i>perfect</i>,
since there are still known discrepancies between the
simulation's behavior at a very-detailed level and Mike
Stewart's earlier, independently-created
simulation. I'm tracking down those errors and
fixing them over time. Also, the even fancier <a
href="https://github.com/virtualagc/virtualagc/tree/master/Borealis">Borealis
software
test suite</a> hasn't yet been tried, since there are
various technical problems with doing so that will need
to be overcome first.</li>
<li>Another AGC schematic has been transcribed, this time
for AGC module A52, drawing 2003305B, the "restart
monitor", and thus added to <a
href="ElectroMechanical.html">the Electro-Mechanical
page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-10-07<br>
</td>
<td valign="top">
<ul>
<li>If you've been following my progress, <a
href="https://github.com/virtualagc/virtualagc/tree/schematics">first
in
transcribing the AGC schematics into CAD, and then in
translating those CAD files into Verilog, and finally
in running a Verilog-based simulation of the AGC</a> —
and admittedly, I don't think that's too many of
you <img src="smiley.png" alt="" width="16"
height="16"> — I've been making good progress, and you
can now actually fire up the full-AGC simulation with
it. There's no erasable or fixed memory
implemented yet, so all the simulation does is basically
to jump to the start vector (address 4000 octal) ... at
which point the "instructions" it starts fetching from
the non-existent rope are nonsense. But still,
just getting to this point is a pretty significant
milestone. Of course, all I'm doing is lagging by
a couple of years <a
href="https://github.com/virtualagc/agc_simulation">what
Mike
Stewart already has already had working</a>, albeit
developed with somewhat different design criteria in
mind, and therefore quite different in terms of details
of the implementation.</li>
<li>And speaking of Mike, you may recall that we've been
getting a vast trove of documentation and software from
Don Eyles the last couple of years, but that
periodically we've mistakenly mentioned that Don's stash
had finally been exhausted. What Don had forgotten
to mention to us, though, is that Russ Larson's and
George Silver's widows had turned over 6-7 boxes <i>each</i>
of <i>their</i> papers, and that Don was mostly
unfamiliar with the contents of those boxes. Mike
immediately hopped on a plane and spent what I suspect
was a subjectively <i>very long</i> long-weekend
indexing those boxes, and then scanning a few items that
seemed most-immediately pressing. The boxes
contained nearly 800 items in total. As a result
of Mike's lost weekend, there are 98 new items in <a
href="links.html">the document library</a> today, with
(presumably) a lot more of the remaining ~700 items to
come in the future as we work out the pragmatic details
of how to accomplish that. Many thanks to all
concerned! Here's an executive summary of the some
of the more-significant items we've got so far, from my
point of view. I think that overall it would be fair to
say that there's an emphasis on AGC hardware vs software
in them:</li>
<ul>
<li><a href="links.html#agcis">4-5 issues of the "AGC
Information Series"</a></li>
<li><a href="links.html#ddmemos">37 "digital development
memos"</a><br>
</li>
<li><a href="links.html#Pad_loads">15 erasable padloads
(Skylab 2 and Apollo 11-17 CM & LM)</a></li>
<li><a href="Documents/agcis_13_yul.pdf">Documentation
of the original YUL assembler</a></li>
<li>"<a href="Documents/contents_of_luminary_1e.pdf">Contents
of
Luminary 1E</a>": A collection of all the
anomaly reports, PCRs, and PCNs related to moving from
LUMINARY 1D (Apollo 14) to 1E (Apollo 15-17). <br>
</li>
<li><a href="Documents/agc_blk2_design_review.pdf">AC
Electronics's review of the Block II AGC electrical
design</a>.</li>
<li><a href="Documents/stg_memo_1542.pdf">A
"comprehensive listing of all G&N system
interface signals, impedances, noise, and marginal
operational requirements"</a>.</li>
</ul>
<li>Updated the discussion about TRW's John Norton on <a
href="faq.html#MoreAmusingStories">the FAQ page</a>.<br>
</li>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-09-29<br>
</td>
<td valign="top">
<ul>
<li>Pepped up <a href="index.html#Acknowledgements">the
acknowledgements section</a> quite a bit, on the basis
of new documents I've gotten, to show more AGC
developers and better-defined responsibilities with
respect to the sections of the code they were
responsible for. It still very incomplete and
unsatisfactory in spite of that.</li>
<li>I'm pleased to note that in the software repository we
now have at least a primitive version of <a
href="https://github.com/virtualagc/virtualagc/blob/schematics/Scripts/dumbVerilog.py">a
KiCad-to-Verilog translator script</a> (in Python)
that works for several of our transcriptions of AGC
modules. Indeed, <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005259A">hardware
simulation
of AGC module A1 (drawing 2005259A)</a> actually works
and behaves identically with what ND-1021042 says it
should. So as far as I can tell right now, that
means that the CAD for module A1 is 100% correct.
But I want to write that up in detail at some point,
with pictures, and haven't done so yet. Plus, it
still leaves us a pretty long way from running a full
simulation of the complete AGC logic. You can't
sneeze at progress, though!</li>
<li>Added a heap of documents Don Eyles sent in, mostly
memos. I believe there were 89 in all, so on the
document-library page I got rid of all the pre-existing
<img src="new.png" alt="" width="36" height="16"> icons
to help them stand out. The vast bulk of them are
in <a href="links.html#DonsLast">the LUMINARY Memos
section</a>, with the remainder, I believe, being in <a
href="links.html#Software_Control_Board_Meeting_Notes">the
SCB
Meeting Notes section</a> and <a
href="links.html#Miscellaneous_Mission_Documents">the
Miscellaneous Mission Documents section</a>.
There's some pretty interesting stuff in there.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-09-23<br>
</td>
<td valign="top">
<ul>
<li>The scans of volume 2 of document ND-1021041 (AC
Electronics Block I manual) have undergone the cleanups
mentioned a few days back, so that document is in its
final form now.</li>
<li>The CAD transcriptions for AGC modules A19-A24 are now
available on <a href="ElectroMechanical.html">the
electro-mechanical</a> page (meaning that A1-A29 are
now all available), for AGC p/n 2003200. They've
also undergone cross-checking and comparison against
Mike Stewart's <a
href="http://apolloguidance.computer/pins">pin
database for the AGC backplane</a> (into which the
modules plug), which is in turn based partially on
Mike's earlier, independent transcription into CAD and
subsequent hardware simulation, so I think we can start
to have a little confidence in these new CAD
transcriptions. (The reason for these new
transcriptions is that Mike's earlier ones weren't
intended to duplicate the visual appearance of the
original schematics, nor to reflect versioning
differences, but merely to relect the final version of
the hardware as accurately as possible.)
Roadmap-wise, this should be the minimal set of drawings
needed for hardware simulation of the AGC logic (as
opposed to its analog characteristics), so that is
something I'm going to start thinking about seriously
now, as well as transcription of all of the drawing
versions that haven't been transcribed yet, extending to
the later model 2003993, and the earlier model 2003100.</li>
<li>The electro-mechanical page has been <i>very slightly</i>
reworked, reorganized, and cut down, so as to make it
friendlier to newcomers. Not much, I admit, but
every bit helps. A little. Maybe.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-09-16<br>
</td>
<td valign="top">Added CAD transcription for drawing 2005268A
(electrical schematics for AGC module A18) to the
electro-mechanical page: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005268A">CAD
files</a>, PNGs generated from CAD (sheets <a
href="KiCad/2005268A-p1of2.png">1</a> and <a
href="KiCad/2005268A-p2of2.png">2</a>), vs the original
scans (sheets <a
href="klabs/history/agc_schematics_block2/logic/a18-1.jpg">1</a>
and <a
href="klabs/history/agc_schematics_block2/logic/a18-2.jpg">2</a>).</td>
</tr>
<tr>
<td valign="top">2018-09-15<br>
</td>
<td valign="top">Added CAD transcription for drawing 2005267A
(electrical schematics of AGC module A17) to the
electro-mechanical page: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005267A">CAD
files</a>, PNGs generated from CAD (sheets <a
href="KiCad/2005267A-p1of2.png">1</a> and <a
href="KiCad/2005267A-p2of2.png">2</a>), vs the original
scans (sheets <a
href="klabs/history/agc_schematics_block2/logic/a17-1.jpg">1</a>
and <a
href="klabs/history/agc_schematics_block2/logic/a17-2.jpg">2</a>).<br>
</td>
</tr>
<tr>
<td valign="top">2018-09-14<br>
</td>
<td valign="top">
<ul>
<li>Added a <a href="links.html#ASTP">handful of new docs
to the document library, mostly for the Apollo-Soyuz
Test Project (ASTP)</a>, of which the gems seem to be
the SKYLARK 48 erasable loads and the users'
guide. Now if only we had a copy of the SKYLARK
program listing, then we'd really have something!</li>
<li><i>Both</i> volumes of AC Electronics manual
ND-1021041 for Block I are now available, including
essentially-complete Block I AGC/DSKY electrical
schematics. Reduced-size scans (<a
href="Documents/apollocommandmodacel.pdf">vol 1</a>
and <a href="Documents/apollocommandmodacel_0.pdf">vol
2</a>) are available, as well as the full-resolution
scans (<a
href="https://archive.org/details/apollocommandmodacel">vol
1</a> and <a
href="https://archive.org/details/apollocommandmodacel_0">vol
2</a>). I am told, though, that additional work
is may be done on both volumes at archive.org, so this
document may change somewhat over the course of the next
week or two. At any rate, thanks, Ken Mortimer!<br>
</li>
<li>Cleaned up <a
href="ElectroMechanical.html#Appendix:_Index_and_Links_to_all_AGC_">the
master
list of links to AGC/DSKY electro-mechanical drawings</a>.
Specifically, I simplified how the links to figures in
ND-1021042 are presented, and completed adding all of
the links into ND-1021042 (in both versions of the
document that we have). I've not yet started
adding Block I links from figures in ND-1021041 into the
table.</li>
<li>And here's <a
href="https://www.livingspace.earth/home/2018/8/for-future-generations">a
cool article about the AGC and people working on
preservation of them</a>. Quite a fun read, not
just with AGCs, but with references to people (and
sometimes pictures of them) familiar to people who
frequent this website. Assuming there are any, of
course.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-09-13<br>
</td>
<td valign="top">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
2003993. <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005912B">CAD
files
here</a>, plus PNGs (<a href="KiCad/2005912B-top.png">main
page</a>, circuits <a href="KiCad/2005912B-circuitA.png">A</a>,
<a href="KiCad/2005912B-circuitD.png">D</a>, <a
href="KiCad/2005912B-circuitP.png">P</a>, <a
href="KiCad/2005912B-circuitR.png">R</a>, <a
href="KiCad/2005912B-circuitXT.png">XT</a>, <a
href="KiCad/2005912B-circuitY.png">Y</a>), vs the original
scans (sheets <a href="AGCHandbook/A27-A29-2005912B-1.jpg">1</a>
and <a href="AGCHandbook/A27-A29-2005912B-2.jpg">2</a>).
Note
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
sub-circuits.<br>
</td>
</tr>
<tr>
<td valign="top">2018-09-12<br>
</td>
<td valign="top">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): <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005021C">CAD
files
here</a>, plus PNGs (<a href="KiCad/2005021C-top.png">main
page</a>, circuits <a href="KiCad/2005021C-circuitXT.png">XT</a>,
<a href="KiCad/2005021C-circuitP.png">P</a>, <a
href="KiCad/2005021C-circuitD.png">D</a>, <a
href="KiCad/2005021C-circuitC.png">C</a>, <a
href="KiCad/2005021C-circuitR.png">R</a>), vs <a
href="AGCHandbook/A25-A26-2005021C-1.jpg">the original
scan</a>. 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.
Fun stuff.<br>
</td>
</tr>
<tr>
<td valign="top">2018-09-11<br>
</td>
<td valign="top">Added a CAD transcription of the electrical
schematics for AGC module A16, namely drawing
2005266-: <a
href="https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005266-">CAD
files
here</a> plus PNGs of sheets <a
href="KiCad/2005266--p1of2.png">1</a> and <a
href="KiCad/2005266--p2of2.png">2</a>, vs the original
scans of <a
href="klabs/history/agc_schematics_block2/logic/a16-1.jpg">1</a>
and <a
href="klabs/history/agc_schematics_block2/logic/a16-2.jpg">2</a>.
(I
suppose I should have been providing similar links to these
notes for <i>all</i> 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 <a href="ElectroMechanical.html">the
electro-mechanical page</a>, I'm afraid you'll just have
to rummage around to find them if you're interested.)<br>
</td>
</tr>
<tr>
<td valign="top">2018-09-10<br>
</td>
<td valign="top">
<ul>
<li>Added an electrical CAD transcription for yet another
revision of AGC module A14, this time for drawing
2005264- (to complete the set started with drawings
2005264A and 2005264B yesterday). This revision
has no particular significance that I know of, but I was
playing around with some bug/feature fixes recently made
to KiCad, and it was simply a convenient drawing to work
with.</li>
<li> Added the CAD transcription of the electrical
schematics for the flight version of AGC module A15
(drawing 2005265A).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-09-09<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-09-08<br>
</td>
<td valign="top">Added the CAD transcriptions for the AGC
electrical schematics for the flight version of modules A8,
9, 10, 11, 12, and 13. <br>
<br>
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):<br>
<br>
<div align="center"><a
href="klabs/history/agc_schematics_block2/logic/a13-1.jpg"><img
src="small-SCAN-2005269-.jpg" alt="Click to enlarge"
width="405" height="320" border="2"> </a><a
href="KiCad/2005269--p1of1.png"><img
src="small-CAD-2005269--.png" alt="Click to enlarge"
width="414" height="320" border="2"></a><br>
</div>
<br>
A good example of the <i>need</i> 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 <i>masked</i> various other types of
potential errors by making it very hard for me to see
them. Proofing will be so important!<br>
<br>
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 <i>practical</i> 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 <i>are</i>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-09-03<br>
</td>
<td valign="top">Added the CAD transcriptions for the AGC
electrical schematics for the flight version of the A7
module.</td>
</tr>
<tr>
<td valign="top">2018-09-02<br>
</td>
<td valign="top">Added the CAD transcriptions for the AGC
electrical schematics for the flight version of the A6
module.</td>
</tr>
<tr>
<td valign="top">2018-09-01<br>
</td>
<td valign="top">Added the CAD transcriptions for the AGC
electrical schematics for the flight version of the A5
module.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-31<br>
</td>
<td valign="top">Began the process of adding links to <a
href="ElectroMechanical.html#Appendix:_Index_and_Links_to_all_AGC_">the
AGC
Handbook index</a> 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
imagined.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-30<br>
</td>
<td valign="top">
<ul>
<li>Added the CAD transcriptions for the AGC electrical
schematics for the flight version of the A4 logic
module.</li>
<li>Updated <a
href="ElectroMechanical.html#Appendix:_Index_and_Links_to_all_AGC_">the
AGC
Handbook index</a> to include the drawings supplied by
Eldon Hall, so that it's more of a master index
now. I hadn't compared Eldon's drawings vs the AGC
Handbook side-by-side before, and was surprised to see
that in Eldon's set there were only 2 drawings (plus one
rev of a drawing) that weren't also in the AGC
Handbook. Of course, there's a very definite
difference in legibility in places, so having both sets
of drawings is still a pretty nice feature.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-08-28<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-26<br>
</td>
<td valign="top">Several CAD transcriptions of AGC electrical
schematics were added to the <a
href="ElectroMechanical.html">electro-mechanical page</a>,
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-20<br>
</td>
<td valign="top">We now have <a href="links.html#ND-1021041">Volume
1
(of 2) of AC Electronics document ND-1021041</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-15<br>
</td>
<td valign="top">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 <a
href="ElectroMechanical.html#2003994">the comments for
them on the electro-mechanical page to reflect those
concerns</a>, but don't think any more-substantive change
is warranted just yet.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-14<br>
</td>
<td valign="top">
<ul>
<li>Realized how a visual-mismatch between the original
scanned AGC/DSKY electrical schematics and the CAD
transcriptions of them could be corrected, and did so on
all of the drawings that have already been transcribed.</li>
<li>Added an <a
href="ElectroMechanical.html#Appendix:_KiCad_for_Virtual_AGC">Appendix
to
the electro-mechanical page</a> to cover various
issues we've discovered in using KiCad with the AGC/DSKY
schematics. Also, reorganized the
electro-mechanical page to be very slightly less
confusing.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-08-13<br>
</td>
<td valign="top">
<ul>
<li>Mike has sent an update to the full (though still very
incomplete) MIT part-number list. Concurrently,
I've decided to change the presentation of that list to
<a
href="ElectroMechanical.html#Electronics_Component_Part_Numbers">a
table directly on the electro-mechanical page itself</a>
rather than as a link to a separate Excel spreadsheet as
it was before. In fact, the master part-number
list is now maintained in our github repo, for
maintenance purposes, and therefore can theoretically be
corrected or extended by someone other than Mike. </li>
<li> Hartmuth has sent along a ton more Apollo and Gemini
files that he had scavenged from NTRS over the years and
that we hadn't already noticed ourselves. About
130 of them by my count. So they've been added to
<a href="links.html">the document library</a>.
This caused me to notice a few links to existing docs
that were messed up, and so I've fixed those; on the
other hand, having added so many new docs at once, I've
undoubtedly messed up quite a few of their links, and
will have to find and fix those in the near future.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-08-12<br>
</td>
<td valign="top">
<ul>
<li>It turns out that in all of the drawings so-far
converted from the AGC Handbook to CAD (namely, drawings
2005902B, 2005903A, 2005952-, and 2005973r), I had
misinterpreted what were supposed to be connector pins
as global nets. Those have all now been
fixed. These schematics now all pass KiCad's ERC
(Electrical Rule Checker), with the happy side effect
that a few connections which didn't quite "connect"
before, due to wire endpoints being physically very
close visually but not actually touching, have been
fixed as well. None of this makes a significant <i>visual</i>
difference in the images created from the CAD files —
mainly, little rectangular boxes with numbers in them
have been replaced by little ovals with the same numbers
in them — but it's a world of difference electrically
and in terms of confidence in the transcription.</li>
<li> All of the available drawings from the AGC Handbook
for the DSKY module D7 power-supply circuit have also
now been transcribed to KiCad, and thus have "pretty"
drawings associated with them on the <a
href="ElectroMechanical.html">electro-mechanical page</a>.
They
actually turn out to all be identical, except that they
have different choices of some resistor and capacitor
values.</li>
<ul>
<li>Drawing 2005921- (for DSKY p/n 2003950).<br>
</li>
</ul>
<ul>
<li>Drawing 2005904C (for the earlier DSKY p/n 2003985).</li>
<li>Drawing 2005904B (a still earlier revision).</li>
<li>And finally, a <i>reconstructed</i> drawing 2005937
(for the later DSKY p/n 2003994), using drawing
2005921- and the circuitry found in AC Electronics
document ND-1021042 as a guide. The need for a
reconstruction is, of course, that we don't have an
actual copy of drawing 2005937 in either the AGC
Handbook or elsewhere. <br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-08-11<br>
</td>
<td valign="top">Added transcribed CAD files (and
pretty-printed image) for the electrical schematics of the
DSKY keyboard module (drawing 2005903A) to the <a
href="ElectroMechanical.html">electro-mechanical page</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-10<br>
</td>
<td valign="top">
<ul>
<li>Made some relatively minor, almost cosmetic changes to
a couple of the CAD schematics added yesterday.
But there were pretty important changes to the <i>reconstructed</i>
schematic 2005973, since Mike Stewart pointed out that
circuit simulations proved that document ND-1021042 was
wrong and drawing 2005952 was correct with respect to
certain circuit characteristics, and thus I was wrong to
trust ND-1021042. <br>
</li>
<li>Mike had also put together a nice spreadsheet of many
(though not all) part numbers for a large number of
resistors, capacitors, and so on used in the electrical
schematics. <a
href="ElectroMechanical.html#Electronics_Component_Part_Numbers">That
spreadsheet
has been added to the electro-mechanical page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-08-09<br>
</td>
<td valign="top">
<ul>
<li>Converted Hartmuth's index into the AGC Handbook pages
into an <a
href="ElectroMechanical.html#Appendix:_Index_and_Links_to_all_AGC_">Appendix
for
our electro-mechanical page</a>, so that it provides
actual links to the individual high-quality scans at our
Internet Archive site. Of course, Hartmuth's
original index (for the lower-size PDF form of the
handbook) is still available.</li>
<li>Experimentally (so far), a handful of the
electrical-schematic drawings have been transcribed to
CAD files using the open-source KiCad system.
These appear in the <a
href="https://github.com/virtualagc/virtualagc/tree/schematics">"schematics"
branch
of the GitHub repo</a>, and have been added to <a
href="ElectroMechanical.html">the electro-mechanical
page of the website</a> as well. The drawings
transcribed so far are of all the available versions of
the DSKY indicator-driver circuit: 2 versions from the
AGC Handbook, plus 1 "reconstructed" but
otherwise-missing version that was recreated by
combining information from the AGC Handbook and AC
Electronics document ND-1021042. The transcribed
drawings are obviously a lot nicer than the 50-year-old
xeroxes of the originals, but also potentially contain
so-far undetected errors not present in the
originals. You pays your money and you takes your
chances!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-08-06<br>
</td>
<td valign="top">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 <a href="links.html">the document library page</a>.
You
can just look for the ones marked <img src="new.png" alt=""
width="36" height="16"> on that page, since I've also
gotten rid of the <img src="new.png" alt="" width="36"
height="16"> icon on all docs added prior to this month,
so Hartmuth's documents are the only ones currently marked.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-04<br>
</td>
<td valign="top">Hartmuth Gutsche has gone through the tedium
of <a href="Documents/AGCHandbookDrawingIndex.xlsx">indexing
the
entire AGC Handbook</a>, 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
I anticipated.<br>
</td>
</tr>
<tr>
<td valign="top">2018-08-01<br>
</td>
<td valign="top">The basis for our new <a
href="ElectroMechanical.html">electro-mechanical page</a>,
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 <i>was</i>) 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 <i>lot</i> 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 href="Documents/agc_handbook_jp2.pdf">a reduced-size
(170MB) PDF appears on the electro-mechanical page</a>
instead. As usual, though, <a
href="https://archive.org/details/agc_handbook_jp2">the
full-quality scans do appear on our Internet Archive page</a>.<br>
<br>
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!<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-31<br>
</td>
<td valign="top">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",
respectively.<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-30<br>
</td>
<td valign="top">Added some nice images and numerous drawing <i>numbers</i>
(but sadly, no actual <i>drawings)</i> to the Block I
tables on the electro-mechanical page.<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-29<br>
</td>
<td valign="top">Various additions and corrections to <a
href="ElectroMechanical.html">the electro-mechanical page</a>,
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-28<br>
</td>
<td valign="top">
<ul>
<li><a href="ElectroMechanical.html">The
electro-mechanical page</a> has undergone various
corrections, and now has its first Block II DSKY
schematics.<br>
</li>
<li>Added AC/Delco Electronics, "<a
href="Documents/apollolunarexcuracel_1.pdf">Apollo
Command Module Block II Primary Guidance, Navigation,
and Control System Manual</a>" (reduced-size for easy
download) to the document library. <a
href="https://archive.org/details/apollolunarexcuracel_1">The
full-quality
scans in our Internet Archive collection</a>.
Thanks to Ken Mortimer!</li>
<li>Added <a href="Documents/HSI-208629.pdf">rev 54 of
E-1142</a> (MIT/IL System Status Report) to document
library.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-07-27<br>
</td>
<td valign="top">The minimal treatment given previously to AGC
electrical schematics has been replaced by a much expanded
treatment on <a href="ElectroMechanical.html">a page
dedicated to AGC/DSKY schematics and mechanical drawings</a>.
A
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-23<br>
</td>
<td valign="top">
<ul>
<li>As students of AGC assembly language know, the AGC
language is actually an intermixture of pure machine
code (called "basic" instructions) and higher-level
instructions ("interpretive" instructions) that are
executed on a built-in interpreter which is itself is
written in basic instructions. In an AGC program
such as LUMINARY or COLOSSUS, a sequence of interpretive
instructions is marked by the fact that it begins with
the basic instruction <tt>TC INTPRET</tt> (to <i>start</i>
a block of interpretive code) or <tt>TC DANZIG</tt> (to
return to interpretive code from a basic-instruction
subroutine called by interpretive code); other
basic instructions precede the <tt>TC INTPRET/DANZIG</tt>,
while interpretive instructions follow it. All
very well and good ... but while INTPRET is clear, why<i><u>DANZIG</u></i>?
Danzig is obviously (or <i>was</i> obviously) the name
of a city in Poland, but is that significant
somehow? Since this is the kind of thing I worry
about, I've wondered about it since the beginning of
this project, about 15 years ago. But on that
issue, today is the day to stop wondering! I now know
why, and you can know why too, if you follow <a
href="assembly_language_manual.html#Danzig">this link
to the explanation I've added to the assembly-language
page</a>.</li>
<li>Enthusiasts may also recall that Hugh Blair-Smith has
graced us with his preliminary notes on what an improved
AGC architecture, which he terms "Block III", might look
like. Well his thinking on the subject, upon which
he has been working with Bruno Muller, have advanced a
lot in the couple of years since we last heard anything
about it. Naturally, <a
href="BlockIII.html#HughsNotes">I've posted the
current thinking on this subject on our Block III page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-07-20<br>
</td>
<td valign="top">Added a favicon for the web-pages.<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-15<br>
</td>
<td valign="top">
<ul>
<li>On the AGC assembly-language page of this site, my
intention was always to create a comprehensive manual
for AGC assembly language. While this was <i>somewhat</i>
successful for the AGC's so-called "basic" instructions,
it turned out to be sadly completely inadequate for the
AGC interpreter language, whose descriptive section was
basically a promisory note for future content that I
ended up never creating. In other words, if you
wanted to read anything about the interpreter
instructions, you couldn't read my lovely verbiage about
it, but would pretty much have to fall back on the
original Instrumentation Lab documents.
Unthinkable! But wait ... suddenly Mark Schulman
(thanks, Mark!) has stepped in to fill the void I
left. He has written just such a guide for the
interpreter language as I envisaged, and has gifted it
to us. <a
href="assembly_language_manual.html#MarkSchulman">I
have basically inserted it verbatim into the
assembly-language page of the website</a>. If
the AGC interpreter is your thing, read and enjoy!</li>
<li>Steven Hauer has sent along a number of nice pictures
of what's basically his implementation of Mike Stewart's
Block II AGC emulator. You can now read Steven's
description and see his pictures <a
href="Pultorak.html#Steven_Hauers_Implementation">on
the physical-implementation page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-07-14<br>
</td>
<td valign="top">Changed the website's logo to read <b>AGC
McAGC Face</b>. Wait ... you can probably tell by
looking in the upper right-hand corner of this page that
that was a lame joke. <img src="smiley.png" alt=""
width="16" height="16"> 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 <a
href="faq.html#Whats_Up_With_the_Logo">on the FAQ page</a>,
if you're interested.<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-12<br>
</td>
<td valign="top"><a
href="Documents/apollolunarexcuracel_0.pdf">Volume 1 of
the 1966 ND-1021042</a> 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 <a href="links.html#LateND1021042">our 1972 version
of volume 1</a> 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!).<br>
</td>
</tr>
<tr>
<td valign="top">2018-07-09<br>
</td>
<td valign="top">Added the earliest (i.e., "no rev") version
of the AC/Delco document ND-1021042, "<a
href="Documents/apollolunarexcuracel.pdf">Apollo Lunar
Excursion Module Primary Guidance, Navigation, and Control
System Manual</a>", 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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-06-09<br>
</td>
<td valign="top">Added <a
href="Documents/collectionoftech00amer.pdf">a collection
of papers on guidance, control, and flight dynamics from a
1967 AIAA conference</a>. At least some of them are
directly related to Apollo guidance.<br>
</td>
</tr>
<tr>
<td valign="top">2018-06-05<br>
</td>
<td valign="top">
<ul>
<li>When I originally created <a href="links.html">the
document library</a>, it was an earlier, more-innocent
time, when men were men, women were women, and what
today seem like relatively small downloads then seemed
like freakingly huge ones. Ah, 2003, will you ever
come again? At any rate, so-called comedy aside,
back then I tended to put a little note next to each of
the hyperlinks to show how many megabytes were in each
document file. Well, times have changed, at least
as far as download sizes are concerned, and those
quaint, old notes warning you about 4MB or 5MB downloads
now just seem silly now that many of our downloads are
hundreds of megabytes. Besides, 90% of the newer
additions to the library no longer had notations like
that anyway. So I've just bit the bullet and
removed all of the old notations about download sizes
and/or document page counts. It's just the right
thing to do!</li>
<li>4 new documents have wended their way to us from UHCL
and have gone into the document library as well.
(I probably won't be able to actually upload them until
later today or tomorrow, though, so don't be
disappointed if their links don't work correctly just
yet.)</li>
<ul>
<li><a href="Documents/HSI-208467.pdf">SIMFAM
Description and Operation</a> — describes a rope
test equipment designed to allow plugging a "braid
memory" into an AGC.</li>
<li><a href="Documents/HSI-208496.pdf">Rope Memory
Module Assembly Processing Procedures</a> — details
of the life of an AGC rope, from release, to SCB, to
assembly, to distribution.</li>
<li><a href="Documents/HSI-25032.pdf">A memo</a>
summarizing the above as a timeline.<br>
</li>
<li><a href="Documents/HSI-208507.pdf">An MIT report
describing ways to make NOR logic circuits more
rad-tolerant</a>. Presumably some of these
techniques were used in the AGC logic design, though
at this point that's just a guess.</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-05-30<br>
</td>
<td valign="top">Added <a href="Documents/LDW370-28001.pdf">Grumman's
Level
III PGNCS drawings for LTA-8</a> 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". <img src="smiley.png" alt="" width="16"
height="16"> A later drawing covering LM-4 through LM-15
was already in our library.<br>
</td>
</tr>
<tr>
<td valign="top">2018-05-26<br>
</td>
<td valign="top">A somewhat later version of the <a
href="Documents/AstrionicsSystemsHandbook_Nov69.pdf"><span
style="font-style: italic;">Astrionics System Handbook,
Saturn Launch Vehicles</span></a> 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..<br>
</td>
</tr>
<tr>
<td valign="top">2018-05-25<br>
</td>
<td valign="top">Thymo van Beers has pointed out that the
documentation for the CPU-Engine API and Backtrace API on <a
href="developer.html">the developer page</a> 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!<br>
</td>
</tr>
<tr>
<td valign="top">2018-05-21<br>
</td>
<td valign="top">The AC Electronics <a
href="Documents/apolloguidancena00acel_0.pdf">Block I
study guide, "G&N System Familiarization"</a> 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 <a
href="https://archive.org/details/virtualagcproject">The
Internet Archive</a>, where you can see the
full-resolution scans if you're so inclined. <br>
</td>
</tr>
<tr>
<td valign="top">2018-05-19<br>
</td>
<td valign="top">Added a nifty <a
href="Documents/apolloguidancena00acel.pdf">AC Electronics
study guide for Block I Guidance&Navigation Hardware
Functions</a> 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. <img
src="smiley.png" alt="" width="16" height="16">)
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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-05-12<br>
</td>
<td valign="top">
<ul>
<li>Added a workaround to the <a
href="download.html#Raspberry_Pi_Raspbian_">Raspberry
Pi build instructions</a> for a bug found in certain
versions of the Raspbian software repository.
(Specifically, for the 2018-04-18 version of Raspbian,
in which Virtual AGC builds but does not run under the
previous instructions.)</li>
<li>In the document library, the icon <img src="new.png"
alt="" width="36" height="16"> now relates to
documents added from May 2018 onward (rather than
January 2018 onward).<br>
</li>
<li>Seven new documents added to the <a href="links.html">document
library</a>, of which the most significant are volumes
3 ("Control Data") and 4 ("Error Analysis") of the
AS-278 GSOP, plus document <a
href="Documents/HSI-208532.pdf">E-1699</a>. The
latter is a description (in the form of a proposal) for
the physical construction of the AGC. The
remaining docs, which I won't list specifically here but
which have arbitrarily been stuck with the <a
href="links.html#AGC_electrical_schematics">electrical
schematics</a>, may or may not be useful in
understanding discrepancies between the electrical
schematics we have vs earlier physical AGC/DSKY units,
but are not of general interest.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-03-23<br>
</td>
<td valign="top">Apparently, on <a href="Colossus.html">the
COLOSSUS page</a>, 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:<br>
<ul>
<li><a href="Documents/HSI-208476.pdf">Guidance,
Navigation, and Control Block II Command and Service
Module Functional Description and Operation Using
Flight Program SUNDISK (Rev. 282)</a></li>
<li><a href="Documents/HSI-208615.pdf">Guidance,
Navigation, and Control Command Module Functional
Description and Operation Using Flight Program
COLOSSUS 2C (COMANCHE 67)</a></li>
</ul>
<p>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 <i>first</i> <i>significant</i> <i>
documentation we've ever gotten</i> about the Apollo 7
software. All three of these documents were written
by AC Electronics residents at the Instrumentation Lab.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2018-03-22<br>
</td>
<td valign="top">Four new documents were added to <a
href="links.html">the document library</a>, most of which
are of lesser significance (from my limited perspective), so
I won't bother itemizing them; just check out the <img
src="new.png" alt="" width="36" height="16"> icons in the
library if you're interested. <br>
<br>
However, <i>one</i> document, titled "<a
href="Documents/HSI-208616.pdf">Guidance, Navigation, and
Control Lunar Module Functional Description and Operation
Using Flight Program LUMINARY (Rev. 116)</a>" (600 pages),
for the Apollo 12 LM, seems <i>quite</i> 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."</td>
</tr>
<tr>
<td valign="top">2018-03-04<br>
</td>
<td valign="top">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:<br>
<ul>
<li>--radio-buttons — For the largest display screens
(with, say, 1024 pixel rows). Mission selection is
the "traditional" way, via radio buttons in the user
interface.</li>
<li>--dropdown — (The default.) For smaller display
screens (with, say, 720 pixel rows). Mission
selection is in the newer way, via a drop-down list.</li>
<li>--squish — For the smallest display screens (with,
say, 480 pixel rows).</li>
</ul>
<p>For use with --squish only, there's also a --maximize
command-line option that maximizes the program at startup.<br>
</p>
<p>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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2018-02-24<br>
</td>
<td valign="top">Two significant documents were added to the
document library:<br>
<ul>
<li>Excerpts from "<a
href="Documents/Apollo11-LM-TimelineBook-excerpts.pdf">Apollo
11
LM Timeline Book</a>" (1969), including handwritten
notes made, I'm told, by Buzz Aldrin. It is a
notable addition to the collection, because we
previously had no final version of the descent
procedures specific to Apollo 11, and the procedures in
this document differ from those cobbled together from
the closest alternatives (Apollo 12 procedures or
preliminary Apollo 11 procedures). This
information is necessary, for example, in making
simulated Apollo 11 landings in NASSP that are faithful
to the 1969 original landing.<br>
</li>
<li><a href="Documents/LDW370-54001.pdf">Level III PGNCS
drawings</a> from Grumman. These are basically
souped-up versions for LM-4 through LM-15 of the LM ICD
documents we already had, with more-detailed
interconnection drawings and pinout information.
They're also significant in a different way, in that
they are scans of "aperture cards" from the National
Archives in Ft. Worth — a resource I had noted many
years ago but had completely ignored, but which is now
revealed as a potential treasure chest ... if only we
could just figure out what that treasure chest contained
so that we could ask for it! <br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-02-06<br>
</td>
<td valign="top">A new document was added to the document
library, "<a href="Documents/19700004488.pdf">Luminary 1B
DAP Preflight Performance Evaluation</a>" (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
href="Documents/apollo12landingd00miti.pdf">a digital
simulation of Luminary 116</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2018-02-05<br>
</td>
<td valign="top">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 <a href="links.html#LVDC">the LVDC section of
the document-library page</a>, 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
<i>entire</i> LVDC program.<br>
</td>
</tr>
<tr>
<td valign="top">2018-02-04<br>
</td>
<td valign="top">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!):<br>
<ul>
<li>"<a href="Documents/SA-515_ICD.pdf">Interface Control
Document: Definition of Saturn SA-513/SKYLAB 1 and
SA-515/SKYLAB Backup Flight Sequence Program</a>".
Notable
for including a pinout of the LVDC and LVDA discrete
inputs, discrete outputs, and interrupts, as well as a
detailed mission-specific timeline of the theoretical
behavior of those signals.<br>
</li>
<li>"<a href="Documents/FlightProgramDevelopment.pdf">Saturn
V
Flight Program Development</a>". Describes the
development process for the LVDC software (in a software
quality assurance sense), as well as giving a very
high-level architectural overview of the software.
Needless to say, most of the specified documentation
developed during this process is missing from our
collection. Among the more-interesting
soundbytes: The LVDC software-development process
<i>for each launch vehicle</i>, took 61 weeks.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-01-19<br>
</td>
<td valign="top">Replaced the photo of the Block I nav-bay
DSKY on <a href="Block1.html#DSKY">the Block I page</a>
with a much better one.<br>
</td>
</tr>
<tr>
<td valign="top">2018-01-17<br>
</td>
<td valign="top">
<ul>
<li>Added 13 <a href="links.html#COLOSSUS_Memos">COLOSSUS
Memos</a> to the document library. We already
had 12 such memos, but they were mixed in with the
LUMINARY Memos, so to make them easier to find I created
an entirely new section on the document library page
exclusively for holding COLOSSUS memos.
Unfortunately, we know that the numbering for COLOSSUS
memos goes up to <i>at least</i> 327, so fact that we
now have 25 of them still leaves quite a few
missing! The new ones cover COLOSSUS revisions 197
through 221, with a few little gaps.</li>
<li>Similarly, I found a couple of SKYLARK Memos memos
lurking amongst the LUMINARY Memos, and referenced them
in <a href="links.html#SKYLARK_Memos_PCRs_and_PCNs">the
SKYLARK Memos</a> section of the document-library
page.<br>
</li>
<li> In dealing with the stuff above, I also happened to
notice that various <a href="links.html#Flight_Plans">mission
flight-plan
documents</a> which we'd previously been missing —
Apollo 7, 10, 13, 14, Skylab, and ASTP —had become
available on elsewhere on the web, so I've raided those
documents from their original homes and added them to
the document library as well. In other words,
nothing new in any larger sense, but now integrated into
our document library. A few other documents were
mined and added in the same way ... just look for the <img
src="new.png" alt="" width="36" height="16"> icon
within <a href="links.html">the document-library page</a>.
One
of the "new" documents, the Apollo Operations Handbook,
Block II Spacecraft, isn't really new, but the copy we
already had seems to have disappeared without a trace
somehow.<br>
</li>
<li>Found a nice picture of the LVDC, which I've dutifully
added to <a href="LVDC.html">the LVDC page</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2018-01-14<br>
</td>
<td valign="top">
<ul>
<li>Added a new document to the document library
page: <a href="links.html#Checklists">"</a><a
href="Documents/HSI-209540.pdf">Saturn Launch Vehicle
Systems Handbook, AS-503</a>" (i.e., for Apollo 8).<br>
</li>
<li>The <img src="new.png" alt="" width="36" height="16">
icon on <a href="links.html">the document library page</a>
now only refers to documents added in January 2018 or
later.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2017" onchange="viewOrHide(2017)" autocomplete="off"
checked="checked" type="checkbox"><b>Hide 2017 change notes?</b>
<table summary="" id="table2017" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top">2017-12-21<br>
</td>
<td valign="top">Added some documents to the library:<br>
<ul>
<li><a href="links.html#Checklists">Apollo 8 checklists</a>,
from the <a
href="https://history.nasa.gov/afj/ap08fj/index.html">Apollo
Flight
Journal</a>. (Actually, the checklists don't
seem to have been posted at AFJ yet, but that's our
source for them.)</li>
<li><i>Apollo Operations Handbook, CSM J-Series Missions,
Volume 2: Operational Procedures</i>, from <a
href="http://www.spacecraft.it/">spacecraft.it</a>.
The
document is marked "Apollo 16", but covers CSM112-115
(i.e., is Apollo 15-17, plus the canceled Apollo 18).
(Actually, the linked website seems to be broken and/or
hijacked, so you can't get the document from there at
this time, but that's the source for it.)</li>
<ul>
<li><a href="Documents/AOH_A16_VOL2_Part_1.pdf">Part 1</a></li>
<li><a href="Documents/AOH_A16_VOL2_Part_2.pdf">Part 2</a><br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-12-20<br>
</td>
<td valign="top">We ended up getting a better scan of the <a
href="ScansForConversion/Colossus237DigitalSimulation-Anomaly45.pdf">CSM/LM
Spacecraft
Operational Data Book</a> mentioned yesterday.<br>
</td>
</tr>
<tr>
<td valign="top">2017-12-18<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-12-17<br>
</td>
<td valign="top">Mainly document additions:<br>
<ul>
<li><a
href="Documents/LMA790-3-LM10-ApolloOperationsHandbookLunarModuleLM10AndSubsequent-Volume1-SubsystemsData-SearchableText.pdf">Searchable-text
version
of the Apollo Operations Handbook for LM 10 and
subsequent (subsystems data)</a>, to complement our
original version of it, which wasn't searchable.
Kudos to Thymo van Beers for arranging to have this
done!</li>
<li><a href="Documents/19750016690.pdf">A document on
simulation of the Saturn's Flight Control Computer</a>.
(Beware!
Not the LVDC.)</li>
<li><a
href="ScansForConversion/Colossus237DigitalSimulation-Anomaly45">Our
first
Apollo-era Colossus digital simulation</a>, for
Colossus 237 (Apollo 8)! Contains pad-loads,
though for the simulation epoch (March 1969) rather than
for the mission launch epoch (December 1968). The
simulation is called "Bailout during Burn (Colossus
Anomaly #45)", and its purpose is presumably
self-explanatory, though I don't think we actually know
the details anomaly #45 at this point.</li>
</ul>
<p>I've also added a Python program called <a
href="https://github.com/virtualagc/virtualagc/blob/master/piPeripheral/humanizeScript.py">humanizeScript.py</a>
to the source-code tree, for analyzing the DSKY playback
scripts (mentioned in the preceding entry) into reasonably
human-friendly form. This is mainly for my purposes
for producing documentation for this website, starting
from logged AGC i/o-channel data from NASSP, but I suppose
it could be useful for other folks as well. Also,
I'm sure that as a first version it probably has a lot of
deficiencies.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2017-12-11<br>
</td>
<td valign="top">For <a
href="https://www.ebay.com/itm/DSKY-with-Integrated-AGC-runs-NASA-MIT-Code/263190750503?hash=item3d47642527:g:IwoAAOSw35lZePeX">the
3D-printed
DSKY with integrated Raspberry Pi running yaAGC</a> 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 <a
href="https://github.com/virtualagc/virtualagc/blob/master/piPeripheral/piDSKY2.py">piDSKY2.py</a>,
it being a Python 3 script rather than the classic yaDSKY
program. Having done that, I began to wonder where the
heck anyone would actually get a meaningful script to run on
the thing, since what you'd really want is realistic data
from an actual mission simulation, rather than something
recorded while just playing around with yaAGC and a
DSKY. <br>
<br>
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 <a
href="https://github.com/virtualagc/virtualagc/blob/master/piPeripheral/convertNasspLog.py">Python
script
for converting Nik's NASSP log format</a> 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. <br>
<br>
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 <a
href="index.html#Canned_pre-recorded_mission_segments">the
introductory list of various fun things you can do with a
Virtual AGC</a> on our home page, as well as describing
how to use the scripting capability <a
href="yaDSKY.html#Canned_Pre-recorded_Mission_Segments">on
our yaDSKY page</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2017-12-09<br>
</td>
<td valign="top">
<ul>
<li><a
href="assembly_language_manual.html#AGC4_Instruction_Set">The
assembly-language
page</a> has listed the operand of the <tt>DV</tt>
instruction as being 12-bit all these years ... but it's
really 10-bit.</li>
<li>The sample code associated with the custom AGC
software and custom AGC peripheral device, as described
on <a href="DIY.html">the do-it-yourself page</a>, have
been cleaned up and extended considerably to improve
their value as examples. Specifically, they now
implement a kind of "clock app" rather than just a clean
coding template.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-12-07<br>
</td>
<td valign="top">A new page, <a href="DIY.html">DIY.html</a>
(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 <i>iDSKY</i>. 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. <i>My</i>
take on that is that it's fine to subvert the normal
functionality of the unit, but that it should be implemented
by writing programs in AGC assembly language to do it!
(Well, I have my ideas about it, and nobody is forced to
agree with me. :-) ) At any rate, this is my
attempt to encourage that. The new page is nowhere
close to being complete, but I think it has enough on it to
be useful.<br>
</td>
</tr>
<tr>
<td valign="top">2017-11-30<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-11-21<br>
</td>
<td valign="top">For <i>me</i> (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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-11-18<br>
</td>
<td valign="top">I've added <a
href="developer.html#A_Template_Program_for_Creating_Simple">some
description
to our developer page of a Python 3 program</a> 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 (<i>very</i>) simple DSKY. <br>
</td>
</tr>
<tr>
<td valign="top">2017-11-16<br>
</td>
<td valign="top">
<ul>
<li>Ryan Callaway has created <a
href="yaAGS.html#A_Taste_of_Whats_Below">a couple of
impressive YouTube videos</a> in which our simulated
Abort Guidance System (AGS), now incorporated in the
Orbiter spacecraft simulator via the NASSP project as
mentioned a month or so ago, is used for some
hypothetical Apollo 12 aborts. Naturally, I've
added links to those videos on our AGS page. Very
cool, Ryan! And given the sad passage 10 days ago
of Dick Gordon, Apollo 12's Command Module Pilot, a
timely memorial as well.<br>
</li>
<li>In the process of watching those videos, I
accidentally discovered a video in which Nik Beug also
uses the Orbiter/NASSP platform to illustrate Don
Eyles's famous mission-saving Apollo 14 fix, in which
the abort-discrete input to the AGC is temporarily
masked during the descent to work around an intermittent
problem that could have inadvertently triggered an
abort. Also cool! Naturally, <a
href="index.html#Solution_to_the_Apollo_14_Final_Exam">I've
added
a link to that video on our main page</a>, to
supplement the discussion there of the famous fix.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-11-15<br>
</td>
<td valign="top">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 <i>might</i> have represented
a complete set of the SKYLARK PCRs that had been implemented
in the SKYLARK software. That idea is now known to be
incorrect, and so those incorrect suggestions have been
removed. The reason we know it's incorrect is that our
copy of the SKYLARK GSOP contains an appendix which lists
(incompletely) the PCRs and PCNs as of March 1972, and it
turns out that there are lots of SKYLARK PCRs and PCNs for
which we don't have the text as of this time.
Alas! At any rate, the PCR table in the document
library has now been updated with this improved PCR/PCN
list.<br>
</td>
</tr>
<tr>
<td valign="top">2017-11-12<br>
</td>
<td valign="top">
<ul>
<li>A bunch of <a
href="links.html#SKYLARK_Memos_PCRs_and_PCNs">PCRs
(Program Change Requests) and a related memo for
SKYLARK were added to the document library</a>.
If you'll recall, SKYLARK is the CM's AGC code for
Apollo-Skylab and Apollo-Soyuz missions.
Unfortunately, we still do not have the SKYLARK code
itself. The PCRs are great, because they usually
contain enough information to actually implement the
code changes. Most of the changes are just
deletion of unnecessary programs, verbs, or routines,
but there are a couple of pretty substantive changes as
well.<br>
</li>
<li>Added a nice <a href="links.html#miscNonComputing">technical
"memorandum",
in just 888 pages, describing all the Saturn launch
vehicles ... up through early 1964</a>. It is
interesting to <i>me</i> primarily because it provides
a little info about the ASC-15, which is the digital
computer that preceded the LVDC and was used on the
Saturn I and Saturn IB launch vehicles that preceded the
Saturn V. The ASC-15, like the LVDC, was developed
by IBM Federal Systems Division in Owego NY, but unlike
the LVDC was a drum-memory computer rather than a
ferrite-core-memory computer. I have briefly
mentioned the ASC-15 on our LVDC page previously, but
only as a guidance computer for the Titan II, since I
had been unaware it was used on some Apollo launch
vehicles. Regardless, the information in the
newly-added memorandum is still quite meager, and I've
not yet altered my comments about the ASC-15 on the LVDC
page. It would be cool to get some deeper
technical info about the ASC-15 first.</li>
<li>Added something called the "<a
href="Documents/SymbolicListingInformation.pdf">Apollo
Guidance Program Symbolic Listing Information for
Block 2</a>" to the document library. This has
been described as "an AGC Bible", and covers lots of
design information about AGC hardware and software in a
single reference, as well as miscellaneous stuff like
the GAP (assembler that replaced YUL) punch-card format.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-10-31<br>
</td>
<td valign="top">
<ul>
<li><a href="LVDC.html">The LVDC page</a> has been changed
in a variety of ways:</li>
<ul>
<li>It no longer indicates that a copy of the LVDC
software resides in the archives of the U.S. Space
& Rocket Center, since that turns out not to be
true.</li>
<li>It now indicates that a major coder of the software
is known (though not yet contacted).</li>
<li>A rough analysis has been added to indicate the
possible (speculative) major versions of the LVDC
software.</li>
</ul>
<li>Various new documents added to <a href="links.html">the
document
library page</a>, of which the highlights are:<br>
</li>
<ul>
<li><a href="Documents/HSI-208387.pdf">CM AGC Interface
Control Document</a> (interface wiring) from North
American Aviation.<br>
</li>
<li>"Launch vehicle flight evaluation reports" for most
missions.</li>
<li>"Launch vehicle operational flight trajectories" for
a couple of missions.</li>
<li>AGC improvment study.<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-10-16<br>
</td>
<td valign="top">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:<br>
<ul>
<li>2010 — Juan Jose has told us about his hardware Block
I simulator, using an FPGA, along with a bunch of
YouTube videos of it in action. This has now been
belatedly added to <a href="Pultorak.html#JuanJose">the
physical implementations page</a>.</li>
<li>2012 — GEMINI on-board computer developer Gene Mertz
scanned and sent me a document called the "<a
href="Documents/GeminiPreliminaryAscentGuidanceSimulationReport.pdf">Preliminary
Ascent
Guidance Simulation Report</a>", for which the DVD
containing hundreds of pages of scans has apparently
been sitting on my desk this whole time,
forgotten. Groan! Well, I suppose the reason
I left it sitting in the to-do box is that there were
dozens of graphs and diagrams that had been split into 3
page each during the scanning. At any rate, I've
now photoshopped all these pages back together for easy
viewing and added the document to the document
library. However, I'd note that the PDF-creation
process seems to have botched the multipage graphs that
I so-laboriously stitched together pretty badly, so the
full-resolution scans I've stored on <a
href="https://archive.org/details/PreliminaryAscentGuidanceSimulationReport">our
project
at the Internet Archive</a> , though 15× larger, are
much, much better for looking at those graphs.<br>
</li>
<li>2012 — GEMINI OBC developer Charlie Leist sent me the
draft of a (modern) document ("<a
href="Documents/Gemini_Peer_Reviews.pdf">Gemini Peer
Reviews</a>") that he and Pat Mooney (Gemini
Programming Manager) wrote, trying to capture how the
software development process worked, but there's a lot
of extra detail about associated matters that I hadn't
seen before as well. I suppose I must have left it
in the to-do list because it was just a "draft".
At any rate, it's in the document library now.<br>
</li>
<li>2012 — Dave Roberts sent word of the problems he was
having with his hardware Block II simulator, a number of
which pointed to bugs in yaAGC, particularly in the DV
instruction, and sent a lot of descriptive material and
even code demonstrating/fixing the problem ... the <i>same</i>
problems Mike Stewart had later with his Block II
simulator, and was gracious enough to fix directly in
yaAGC over the course of the last year. But Dave
was first, and I let him down by parking him on the
to-do list, alas! Anyway, Dave's project has also
finally been added to <a
href="Pultorak.html#DaveRoberts">the physical
implementations page</a>.</li>
<li>Last month — Nik Beug flew a lunar landing in NASSP
using Zerlina, and has shared a video of it, so I've
modified <a href="Luminary.html#Zerlina">the Luminary
page</a> accordingly to link the video. <br>
</li>
</ul>
<p>More to come later, probably.<br>
</p>
<ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-10-14<br>
</td>
<td valign="top">The good NASSP folks have been making an
effort lately to get our AGS (abort computer) simulation
integrated into NASSP, and into checking it out, which is
great! What Ryan Callaway in particular found was that
while a lot of stuff worked, a lot of stuff didn't work
either. Mike Stewart jumped right in and managed to
find a bug I had made in the AGS simulator, yaAGS. So
Ryan now reports that it "looks like all phases of
rendezvous work as advertised in lunar orbit. I used AGS
calculations for every part and ags controlled burns as well
with RR and PGNS as backup/basis of comparison" and "the AGS
aborts the LM beautifully in both DPS and APS aborts".
Which is not to say that yaAGS necessarily is 100% perfect
now, but this one fix has improved its behavior
tremendously. For now, you have to build the software
from source if you want this fix, and it hasn't migrated
into the installer packages for VirtualAGC yet. Great
work, guys!<br>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
</td>
</tr>
<tr>
<td valign="top">2017-10-08<br>
</td>
<td valign="top">The AGS documentation has been reorganized
somewhat for clarity (I hope!), and now appears only on <a
href="yaAGS.html#AGS_Documentation">the AGS page itself</a>
rather than being duplicated on <a
href="links.html#Abort_Guidance_System_AGS">the document
library page</a>. It was simply too irritating to
duplicate it.<br>
</td>
</tr>
<tr>
<td valign="top">2017-08-31<br>
</td>
<td valign="top">
<ul>
<li>The yaYUL bug causing incorrect assembly of Solarium
(for Apollo 4 and 6, but all Block I code in general as
well) on Mac OS X has been fixed in the GitHub repo, so
Solarium 55 is once again a full-fledged member of the
AGC family on all platforms.</li>
<li>The current source tree at GitHub builds on all
platforms listed on <a href="download.html">the
download page</a>, so I've "released" new binary
packages for Ubuntu 14.04, Raspberry Pi, and Windows on
the download page, as well as updating all of the build
instructions for the different platforms. The
VirtualAGC VM has not been updated, and doesn't need to
be re-downloaded; it should simply be updated with the
new Ubuntu 14.04 package. (Admittedly, at the very
last minute, I had to change some of the makefiles to
accommodate the Solaris 11 operating system, and
hopefully that won't mess up the build on all the other
platforms ... but I only did minimal checking to insure
that).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-08-30<br>
</td>
<td valign="top">
<ul>
<li>The transcription of ZERLINA 56 AGC source code from
the scanned printout has now been completed, and
assembles properly with yaYUL, and associated bugs in
the previously transcribed octal rope have been
repaired. (There actually was a single bug in the
octals, which did not affect the checksums, and thus
wasn't previously detected.) In other words,
ZERLINA is ready to go.</li>
<li>ZERLINA now builds by default when building Virtual
AGC from source, and the VirtualAGC GUI app's support
for ZERLINA has been enabled. In fact, all AGC
versions available to us, including the reconstructed
programs LUMINARY 99/0 and LUMINARY 99/2, are now
supported directly in VirtualAGC, and thus none of them
need to be run from the command line.</li>
<li>And, of course, the Luminary page has been updated to
have the colorized, syntax-highlighted ZERLINA 56 source
code on it.</li>
<li>All of the colorized, syntax-highlighted source code
for other AGC versions has <i>also</i> been updated
with the latest improvements.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-08-25<br>
</td>
<td valign="top">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 <i>only</i>
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 <a
href="developer.html#APOLO">those wild patterns are now
listed on the developer page</a>. Some nice images
verifying these patterns on Bruno Muller's hardware DSKY
emulation have also been added to that page.<br>
</td>
</tr>
<tr>
<td valign="top">2017-08-24<br>
</td>
<td valign="top">I'm told that the situation for building
Virtual AGC on Mac OS X is much worse than I imagined, and
that newer Macs now provide clang as the default C compiler,
rather than gcc ... and naturally, Virtual AGC was designed
for the ubiquitous gcc and not for using clang. And
equally naturally, my own Mac is an older one that sensibly
provides gcc as it ought. Well, that's life in the Mac
world, I suppose, of which I have very little
knowledge! <br>
<br>
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. <a
href="download.html#Newer_Macs:_Xcode_with_clang">I've
provided documentation</a> as to how an adventuresome soul
might try out these approaches on a newer Mac.<br>
</td>
</tr>
<tr>
<td valign="top">2017-08-23<br>
</td>
<td valign="top">Note that I really only want to support
VirtualAGC on Ubuntu/Mint/Debian desktop Linux systems,
given that I don't have infinite free time or patience or
knowledge to do otherwise. Nevertheless, I
occasionally check or (or receive user feedback about)
problems on Windows, Mac OS X, Raspberry Pi, alternate
versions of desktop Linux, etc., and do sometimes make an
effort to work around those problems. Over the last
couple of days, I've gotten feedback about some such
compilation problems, and so have made some changes related
to them:<br>
<ul>
<li>Several bug-fixes in <a
href="https://github.com/virtualagc/virtualagc">the
source-code repository</a> for the following problems:</li>
<ul>
<li>Inability to compile on Mac OS X.</li>
<li>Inability to compile zipfile downloads (as opposed
to git clones of the repository).</li>
</ul>
<li><a href="download.html#Linux_">Specific, comprehensive
instructions for compilation on 64-bit Fedora 26</a>
have been added, though I suspect they're probably good
for other Fedora versions as well.</li>
<li><a href="download.html#Mac_OS_X">Temporary change to
Mac OS X compilation instructions</a>, related to the
following problem: There is a bug in yaYUL on Mac
OS X, though just for Block I AGC code, which causes
Solarium (Apollo 4 & 6) to assemble
incorrectly. The instruction changes do not fix
the problem, but simply prevent compilation-failure on
Mac OS X.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-08-20<br>
</td>
<td valign="top">
<ul>
<li>The AP11ROPE scans have been used to cross-check yet
again the program comments in the Luminary 99 source
code. Only a handful of fixes, and the scans are
so clean that I think we can really have quite a lot of
confidence that there are very few lingering errors in
the Luminary 99 source.<br>
</li>
<li>The analysis of the scan of AP11ROPE has also been
completed. The final result of the analysis is
that AP11ROPE and our existing MIT Library scan of
LUMINARY 99 R1 are identical, <i>except</i> that on
page 2 of the listing, the modules on pages 153-489 are
collectively referred to in LUMINARY 99 R1 as "LNYAIDE",
but in AP11ROPE are referred to as "LEMONAID" just as in
LUMINARY 69.</li>
<li>A <a href="Documents/a042186.pdf">pretty amazing
document</a> has been added to the document
library. This is the final technical report from
the MIT Instrumentation Lab in 1977, by then called
Draper Laboratories, to the Rome Air Development Center
(ISIS) at Griffiss Air Force Base. The report
describes the AGC software configuration management
effort, with a lot of detail we hadn't had before,
including numerous statistics and graphs about
development time-frames, number of changes in each of
the flight versions of the code, etc. The
"amazing" part is the description of the amount of
AGC-software related material sent to the
now-unfortunately acronymed ISIS over the years —
magnetic tapes of software, 10,000+ records of
individual software changes — along with the explanation
that ISIS maintained a database of all this
material. If this database still existed and we
could somehow get access to it, it would pretty much
answer all remaining questions about the AGC code.
That's a mighty big "if", of course, and we have no idea
how to go about it.</li>
<li>A couple of tables of AGC software releases have been
added, from the document mentioned above, to the
Luminary and Colossus pages.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-08-09<br>
</td>
<td valign="top">
<ul>
<li>The file of ZERLINA 56 octals is now present <a
href="https://github.com/virtualagc/virtualagc/blob/master/Zerlina56/Zerlina56.binsource">in
the
GitHub repo</a>, proofed and with correct memory-bank
checksums. Thus in principle, you can now build
octal ropes from it, using the oct2bin utility, and run
ZERLINA in the AGC simulator, from the command
line. The proofing process was real torture,
though, with enormous numbers of difficult-to-find
errors, so correct checksums or not, I admittedly won't
feel really good about it until the source-code
transcription is complete.</li>
<li>You may recall that original AGC developer Allan
Klumpp had a printout of LUMINARY 99 that he believed
was the Apollo 11 flight code, but that we have never
had the chance to scan (or examine) this printout.
We do know that he turned out to be mistaken, and that
what he had was LUMINARY 99 Rev 0, whereas it was either
Rev 1 or Rev 2 that actually flew. It turns out
that Mike Stewart has been able to <i>recreate</i> the
source code for Rev 0, even in lieu of having the
hardcopy! We're pretty confident that the
reconstruction is correct, because it makes sense and
has all of the correct memory-bank checksums. It's
<a
href="https://github.com/virtualagc/virtualagc/tree/master/LMY99R0">in
the
GitHub repository</a>. You can theoretically run
it in the AGC simulator, from the command line.
The <a href="listings/LMY99R0/MAIN.agc.html">colorized,
syntax-highlighted source code</a> is also available.<br>
</li>
<li>A completed file of AP11ROPE octals is also now
present <a
href="https://github.com/virtualagc/virtualagc/blob/master/Luminary099/AP11ROPE.binsource">in
the
GitHub repo</a>. As you may recall, there has
been a certain amount of speculation as to which version
of LUMINARY 99 flew in Apollo 11 ... was it LUMINARY 99
Rev 1 as we've been claiming all these years, and as
documentation suggests, or was it LUMINARY 99 Rev 2 as
Jim Kernan (the original "rope mother" for the Apollo 11
LM software) says? The hope was that AP11ROPE
might help resolve this question, given that it was
printed long after Apollo 11 (namely, in 1970) and
purports to be the mission code. Thus if AP11ROPE
were identical to <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary099">our
LUMINARY
99 Rev 1 code</a> it would support the notion that Rev
1 was the one that flew, whereas if it were identical to
<a
href="https://github.com/virtualagc/virtualagc/tree/master/LUM99R2">our
recreated
LUMINARY 99 Rev 2 code</a> (or at least relevantly
different from Rev 1) then it might support the notion
that Rev 2 is the one that flew. Well,
octal-for-octal, it turns out that AP11ROPE <i>is</i>
identical to LUMINARY 99 Rev 1. But it is not
source-code identical; it appears to have been branched
from LUMINARY 99 Rev 0 (not Rev 1) and then modified to
bring it up to date with Rev 1, but not with identical
program comments. That being the case, it doesn't
really imply much about whether Rev 1 or Rev 2 was used
in the actual mission. But it did turn out to be a
nice, clean, easy-to-OCR scan, that should be very easy
to use to route out lingering program-comment errors in
our transcriptions.</li>
<li><a href="Documents/HSI-208424.pdf">A curious
familiarization guide for the AGC</a> has been added
to the document library. I don't know quite what
to make of it.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-07-29<br>
</td>
<td valign="top">
<ul>
<li>Four new documents have been added to <a
href="links.html">the document library</a>, from UHCL
and NARA Southwest, all having to do with ferrite-core
memory-system properties, especially for the MOD 3C
AGC. The <img src="new.png" alt="" width="36"
height="16"> icon in the document library has now
rolled over to July 2017, so these 4 docs are the only
ones marked as "new", and hence are easy to find, so I
won't list them separately here.<br>
</li>
<li>The scans for AGC program listings ZERLINA 56 and
"AP11ROPE" are now available; the scanning was sponsored
by Linden Sims and Vipin Rathor, respectively.
Thanks, guys! Recall that ZERLINA is an "offline
development" program that had been maintained by Don
Eyles for experimenting with different types of
improvements or fixes to LM software, and that AP11ROPE
is actually a different printed copy of (we believe) the
Apollo 11 LUMINARY 99 program we've already had for the
last 10 years. But we're not <i>quite</i> sure
yet that AP11ROPE and LUMINARY 99 are exactly the
same. So we're going to check that (of course!),
as well as to use it to cross-check yet again the
existing transcription of LUMINARY 99. But there's no
need to do a full transcription of AP11ROPE, unless we
find out it's actually different in some way. A
transcription of the AP11ROPE octals will be done,
though, as part of the cross-checking process.
ZERLINA, of course, we <i>will</i> be fully
transcribing to source code, as well as creating an
executable binary of it for the AGC simulator, starting
immediately! At any rate, as usual, the scans are
available both in lower-resolution (smaller-size) JPG
and in archival higher-resolution (larger size) JPEG
2000; the Luminary page details all of this, naturally,
but here are the links, for your convenience:<br>
</li>
<ul>
<li><a href="ScansForConversion/Zerlina56/">Smaller-size
ZERLINA 56 scans</a></li>
<li><a href="https://archive.org/details/zerlina00done">Higher-resolution
ZERLINA
56 scans</a></li>
<li><a href="ScansForConversion/AP11ROPE/">Smaller-size
AP11ROPE scans</a></li>
<li><a href="https://archive.org/details/ap11rope00miti">Higher-resolution
AP11ROPE
scans</a></li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-06-23<br>
</td>
<td valign="top">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 <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files#published-proofing-images-and-completed-proofing">the
GitHub
wiki</a>, for anyone inclined to double-check the work.<br>
</td>
</tr>
<tr>
<td valign="top">2017-06-19<br>
</td>
<td valign="top">
<ul>
<li>The complete <a href="Documents/HSI-208818.pdf">LM-8
Systems Handbook</a> has now been added to our
document library, from scans made by the good folks at
UHCL.</li>
<li>The <img src="new.png" alt="" width="36" height="16">
icon, used in <a href="links.html">the document library</a>,
has now been rolled over from April-or-later to
June-or-later.</li>
<li>A bug in the SUNBURST 37 octal listing (whose release
was mentioned on 5-27, see below) has been fixed.
This was a marvelous and instructive typo in that it was
a <i>single-digit error</i> that nevertheless did <i>not</i>
cause a checksum error at runtime. That's because
of an ambiguity in the checksumming system built into
the AGC code: the checksum of a memory bank must
be equal to either the bank number or else the negative
of the bank number. In this case, the error was in
memory bank 1, and the single error (in which the octal
was off by 2) flipped the bank checksum from +1 to
-1. This is a very rare type of error, but it's
unfortunate that the system had that ambiguity.</li>
<li>And speaking of checksums, it turns out that over the
course of time, the algorithm used by YUL to generate
the memory-bank checksums changed slightly. Prior
to SUNBURST 116, I'm told, only the positive memory-bank
values were used, but after that it was not always
possible to generate the positive memory-bank values,
and thus checksums for negative memory-bank values were
generated when required. yaYUL has thus been
modified with an appropriate new command-line switch to
enforce this difference, allowing the removal of an
annoying workaround in AURORA 12. (The assembly of
both AURORA 12 and SUNBURST 37 are affected by this; the
older RETREAD 44 has no checksums anyway, and so is not
affected.)</li>
<li>And speaking of annoying workarounds, the annoying "<tt>SBANK=</tt>
workaround" has finally been eliminated! One of my
more-irritating failures in writing the yaYUL assembler
originally is that I was unable to figure out the scheme
used by YUL/GAP to generate the so-called "superbank"
bits in various address-generating pseudo-ops; in cases
where the values of the superbits were actually
important to the execution of the program, the bits
generated by yaYUL were fine, but where they did not
affect the execution, they were often wrong, and thus
the code generated by yaYUL did not match the octals
generated by YUL or GAP in those cases unless a handful
of extra <tt>SBANK=</tt> pseudo-ops that weren't
originally present in the assembly language code were
inserted into our source code. Personally, I
simply threw up my hands in disgust with it, deciding to
live with these extra <tt>SBANK=</tt> pseudo-ops, but
over the years several people have worked on incremental
fixes and removal of <tt>SBANK=</tt> pseudo-ops, never
with full success. Certainly, getting the original
source code for YUL helped out a lot. However,
over the weekend, the problem seems to have been
cracked, and the entire AGC code base, including all
code versions that we have, now assembles to the proper
octals, entirely without any extra <tt>SBANK=</tt>
pseudo-ops at all. There seem to have been several
insights that contributed to this breakthrough.
Two stand out to my mind. One is that if you
actually look at a page of an AGC program listing (say,
<a href="ScansForConversion/Luminary210/0059.jpg">page
57 of LUMINARY 210</a>), you may notice (<i>I</i>
never did!) that there's a mysterious notation like <tt>E<i>n</i>
S<i>m</i></tt>, under the page numbers in the upper
right-hand corners of the pages. These turn out to
be the memory-bank bits (including superbank
assumptions) that YUL/GAP <i>thought</i> applied at
that point; this observation gives a lot more visibility
into what YUL is thinking at any given point. The
other observation that stands out is that the
assumptions made by YUL for these bank bits changed at
some point (between SUNBURST 37 and 120), so that a
slightly different rule (and a different yaYUL
command-line switch) applies to earlier code versions
than to later ones. Great work, guys!</li>
<li>Not only that, but the transcription of SUNBURST 37
source code is now complete, though I suppose I should
admit that some of the comments in the code haven't been
full proof-read for typos, so</li>
</ul>
<table cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top" align="center"><font color="red"><b>Transcribed
<a
href="https://github.com/virtualagc/virtualagc/tree/master/Sunburst37">source
code
for Sunburst 37</a> is now available, as well
as <a href="listings/Sunburst37/MAIN.agc.html">syntax-highlighted,
colorized
HTML</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<ul>
<li> SUNBURST 37 now builds by default when the code-base
as a whole is built, and it is now enabled in the
VirtualAGC GUI program.<br>
</li>
<li> As a result of the various changes mentioned above,
the entire set of colorized, syntax-highlighted, HTML
versions of the AGC source code have been updated on
this website. I also noticed that due to some
file-name changes in the past, a handful of these files
hadn't been viewing properly, so I've hopefully fixed
that.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-06-07<br>
</td>
<td valign="top">
<ul>
<li>Fleshed out the writeup of Dario Kubler's DSKY with
new images and videos on <a
href="Pultorak.html#Dario_Kublers_Apollo_16_AGCDSKY">our
physical-implementations
page</a>.</li>
<li>Niklas Beug has provided some fun information about
flying simulated Apollo 5 and Apollo 14 missions, in
spite of the fact that we don't presently have any (CM
or LM) of the Apollo 14 software, and that while we have
the Apollo 5 (LM) software we don't have the necessary
pad loads for it. It turns out that the <a
href="https://github.com/dseagrav/NASSP">NASSP</a>
developers have worked out tricks to create the pad
loads for Apollo 5, and to modify the Apollo 15 CM and
LM software's ephemeris data for Apollo 14, allowing
both of these missions to be flown perfectly
satisfactorily in the Orbiter spaceflight simulator with
the NASSP add-on. I've written up Nik's comments —
or more acurately, cribbed from them verbatum — in the
descriptions of <a href="Luminary.html#Apollo5">SUNBURST
120</a> and <a href="Luminary.html#Apollo14">LUMINARY
178</a> on our Luminary page and of <a
href="Colossus.html#Apollo14">COMANCHE 108</a> on our
Colossus page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-06-06<br>
</td>
<td valign="top">Added a description of Dario Kubler's
physical DSKY to <a
href="Pultorak.html#Dario_Kublers_Apollo_16_AGCDSKY">the
physical-implementations page</a>, 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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-05-27<br>
</td>
<td valign="top">The octals for SUNBURST 37 (<a
href="https://github.com/virtualagc/virtualagc/blob/master/Sunburst37/Sunburst37.binsource">Sunburst32.binsource</a>)
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.)<br>
<br>
We're also transcribing the SUNBURST 37 source code from the
scanned program listing now, so anyone interested in helping
should head over to <a
href="https://github.com/virtualagc/virtualagc/wiki/Sunburst-37-Transcription">the
GitHub
repo</a> and look at the instructions.<br>
<br>
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 <a
href="Luminary.html#Sunburst37">our Luminary page</a>,
you'd probably end up downloading this supposedly-fine PDF.
Well it <i>wasn't</i> 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 <i>now</i>, you'll now find
individual JPG pages. The <i>high-quality</i> 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. <br>
<br>
As a corollary, we now realize that Emerson was wrong, and
that a foolish consistency may <i>not</i> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-05-24<br>
</td>
<td valign="top">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. <a
href="Luminary.html#Sunburst37">See our Luminary page</a>.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-05-23<br>
</td>
<td valign="top">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 <a href="Luminary.html#Sundance306">Luminary
page</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2017-05-22<br>
</td>
<td valign="top">Two new CSM System Handbooks, and one new LM
System Handbook, from the UHCL archives. <a
href="links.html#Systems_Handbooks">See here</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2017-05-16<br>
</td>
<td valign="top">
<ul>
<li>Surprisingly, the scanning of Volume I of the AGC LEM
PGNCS manual (Volume II having appeared yesterday) has
suddenly been finished. <a
href="links.html#AGC_electrical_schematics">See here</a>.
<br>
</li>
<li>The scanning of Don Eyles's digital landing simulation
for Zerlina 56 has <i>also</i> suddenly been
finished. The scanning techs at the Internet
Archive must be busy little bees! Zerlina, as you
may recall, is a non-mission version of Luminary with
which Don was exploring various new concepts for
potential inclusion in Luminary. (The scanning of
Zerlina itself hasn't yet been done, but is scheduled
soon.) At any rate, I had apparently failed to
provide an entry for Zerlina 56 on <a
href="Luminary.html#Zerlina">our Luminary page</a>,
but I've done that now, and you can consult it if can't
wait for Zerlina 56 itself and you want to look at the
digital simulation right away.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-05-15<br>
</td>
<td valign="top">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 <i>does</i> 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. <a
href="links.html#AGC_electrical_schematics">See here</a>.
In
other words, we can now claim to have a full set of Block II
AGC and DSKY schematics. (Though not Block I
schematics so far. Perhaps in the future.)<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-28<br>
</td>
<td valign="top">
<ul>
<li>Nothing to directly to do with the AGC, but Don Eyles
had a couple of old maps of Kennedy Space Center around,
which he says are more detailed than others he has seen
online. He was kind enough to scan them for us, so
they've gone into <a
href="links.html#Something_Completely_Different">our
document library</a> and our Internet Archive
collection.</li>
<li> A few months back, I mentioned a magazine article
about the Virtual AGC project that I think is quite fun,
but I couldn't provide a link since the magazine,
Delayed Gratification, is print-only. However, the
magazine does put a few of their articles online, from
time to time, and at least for the moment that has
happened with this article as well. You can check
it out <a
href="http://www.slow-journalism.com/agc-apollo-guidance-computer-code-that-flew-us-to-the-moon">at
this
link</a>. The writer, Chris Bourn, has also
written <a
href="https://www.primotoys.com/blog/2017/03/coding-as-storytelling/">another
article</a> in which the Virtual AGC project appears,
albeit in just a small role, since the article is about
the relationship of story-telling to computer
programming. (I will mention that the way the
articles ended up being written could give the
impression that the Virtual AGC project is my personal
effort as opposed to a group effort. To anybody
whose feelings might be hurt by that, I apologize in
advance.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-04-26<br>
</td>
<td valign="top">The second (of two) volumes of the Spacecraft
Operational Trajectory for Apollo 14 has arrived from UHCL,
and has been added to <a
href="links.html#Miscellaneous_Mission_Documents">our
document library</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-25<br>
</td>
<td valign="top">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 <i>after</i>
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 <a href="Luminary.html">the
Luminary page</a>, in a way that gets closer to the truth
about Apollo 12 than what I had mistakenly written before.<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-24<br>
</td>
<td valign="top">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 <i>next</i>
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 <a
href="download.html">the download page</a> to update
Midori!<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-23<br>
</td>
<td valign="top">
<ul>
<li>81 LUMINARY Memos (the remainder of Don Eyles's
collection of them) have been added to <a
href="links.html#LUMINARY_Memos">that section of the
document-library page</a>.</li>
<li>The <img src="new.png" alt="" width="36" height="16">
icon in the document library has now rolled over to
April and beyond (as opposed to March and beyond).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-04-21<br>
</td>
<td valign="top">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 <i>after</i> 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
<a href="Luminary.html">the Luminary page</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-20<br>
</td>
<td valign="top">Made a number of requested improvements to
the pre-built VirtualAGC VM, as described near the top of
the <a href="download.html">downloads page</a>. 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, <a
href="download.html#Installer_for_Ubuntu_14.04_32-bit_x86">as
described
here</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-19<br>
</td>
<td valign="top">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,<br>
<ul>
<li><a href="Documents/apollo11landingd00miti_0.pdf">1969
Apollo 11 landing digital simulation</a></li>
<li><a href="Documents/apollo12landingd00miti.pdf">1970
Apollo 12 landing digital simulation</a></li>
</ul>
or else you can see them in their full, highest-quality
glory in <a
href="https://archive.org/details/virtualagcproject">our
Internet Archive collection</a>. Both simulations
were made slightly <i>after</i> the landings themselves.<br>
</td>
</tr>
<tr>
<td valign="top">2017-04-17<br>
</td>
<td valign="top">
<ul>
<li>3 more docs from the UHCL archives were added to the
document library, namely one volume each (from the
two-volume sets) of the operational trajectories for
Apollo 14-16. See <a
href="links.html#Miscellaneous_Mission_Documents">here</a>.</li>
<li>There's a new Linux installation package containing
fixes for the VirtualAGC GUI desktop app, suitable for
installation in the Virtual AGC VM. It's not
listed yet on the download page because I'm waiting for
some feedback from people who are trying it out, but I
think it's likely fine, and anybody who is too impatient
to wait can get it <a
href="Downloads/VirtualAGC-Ubuntu-14.04-32-2017-04-17.tar.xz">here</a>.
I'll
write it up and generate Windows and Raspberry Pi
installers after I'm more comfortable with the changes.
The main change relates to the fact that we've now got
so many different AGC versions available that the app's
main window had become too big to display screens
smaller than about 1280×1024. For screens smaller than
that, the app will now automatically change the format
so as to make its main window a lot smaller. This
works well for displays down to around 800×720 (if there
is such a thing), but for anything smaller than that
you'll still be out of luck. You do lose the
capability of running your own "custom" AGC software
from the smaller-screen version of the GUI. The
changes are just to the VirtualAGC GUI, and not to any
of the simulations, so there's still no guarantee that
you can fit an entire simulation onto a smaller screen.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-04-13<br>
</td>
<td valign="top">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:<br>
<ul>
<li><a href="Documents/HSI-208435-001.pdf">Part 1</a></li>
<li><a href="Documents/HSI-208435-002.pdf">Part 2</a></li>
<li><a href="Documents/HSI-208435-003.pdf">Part 3</a></li>
<li><a href="Documents/HSI-208435-004.pdf">Part 4</a></li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-04-08<br>
</td>
<td valign="top">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 <i>possibly</i> 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:<br>
<ul>
<li><a
href="Documents/programmed-guidance-equations-skylark-001.pdf">Part
1</a></li>
<li><a
href="Documents/programmed-guidance-equations-skylark-002.pdf">Part
2</a></li>
<li><a
href="Documents/programmed-guidance-equations-skylark-003.pdf">Part
3</a></li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-31<br>
</td>
<td valign="top">
<p>The "Programmed Guidance Equations for Colossus 3"
document, divided into 3 parts for size reasons (<a
href="Documents/programmed-guidance-equations-colossus-3-001_text.pdf">Part
1</a>, <a
href="Documents/programmed-guidance-equations-colossus-3-002_text.pdf">Part
2</a>, <a
href="Documents/programmed-guidance-equations-colossus-3-003_text.pdf">Part
3</a>), scanned from the University of Houston Clear
Lake archives, has been added to the document library and
Colossus pages.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2017-03-30<br>
</td>
<td valign="top">
<ul>
<li><a href="links.html">Document library</a>:
Various new documents added.<br>
</li>
<ul>
<li>Several <a href="links.html#ApolloTrainingSlides">Block
I
era sets of Apollo training slides</a>. These
are actually quite extensive and well worth your time,
Block I or not! <i>We</i> got them from <a
href="https://www.reddit.com/r/apollo/comments/5yvn7m/this_is_a_picture_of_my_dad_working_on_the_apollo/">reddit</a>.</li>
<li><a href="links.html#Miscellaneous_Mission_Documents">Several
operational-trajectory
docs (Apollo 13 and 16) and revisions to
operational-trajectory docs (Apollo 12 and 17)</a>,
taken from the archive at the University of Houston,
Clear Lake, amazingly helpful as always.<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-29<br>
</td>
<td valign="top">
<ul>
<li>AGC CPU-simulation features: As you may know,
the AGC had the ability of being able to execute a
different instruction (stored in the B/BRUPT registers)
upon return from an interrupt-service routine (ISR) than
was stored at the actual address at which execution
resumed afterward. In other words an ISR could
load the binary value of the instruction it wanted
executed upon return into the BRUPT register, and even
though the RESUME instruction would cause the program
counter to be loaded correctly, the binary instruction
in BRUPT would be executed, irrespective of the value
stored at the RESUME'd program-counter address.
This was originally not a "feature", but was simply a
consequence of the fact that the next instruction to be
executed is always decoded by the AGC during the
execution of the <i>preceding</i> instruction, and thus
the decoded next instruction needed to be stored
somewhere during an ISR, and subsequently restored after
the ISR had been completed. Considered as a
"feature", this is rather useless for ISRs, since all it
can really do is crash the program or do something else
that's unpleasant, but <i>could</i> be useful for
something like a software-controlled interrupt, such as
the EDRUPT instruction. The EDRUPT instruction,
seemingly created for Ed Smalley's AGC self-test code,
though possibly never used by him at all, was not
something that was really needed for anything, but was
instead created (as Hugh Blair-Smith has said) "because
he could". At any rate, while I originally
intended to implement this same behavior in the AGC CPU
simulator, it caused difficulties for me ... and since
it didn't seem to be used anywhere in the Luminary 131
AGC code I originally worked with, I simply disabled the
feature entirely rather than try to figure out how it
was misbehaving. In other words, for all these
years, yaAGC has simply been ignoring whatever is in the
B/BRUPT registers. At any rate, Mike Stewart, in
his unswerving quest to make yaAGC work <i>correctly</i>
as opposed to well-enough, and to agree in its behavior
with the Block II hardware simulation, has now debugged
this behavior and fully restored B/BRUPT/EDRUPT.
All known self-test software related to this behavior
works correctly, yaAGC does agree with the hardware
simulation, and the restored code has been tested
multiple times in the NASSP Command Module and Lunar
Module simulations. In short, B/BRUPT and EDRUPT
are back, baby! Many thanks to Mike Stewart and
the NASSP gang.</li>
<li><a href="download.html">Downloads page</a>:<br>
</li>
<ul>
<li>Updated the VirtualAGC installer (again!), not only
for Ubuntu (for the VirtualAGC VM), but also for
Raspberry Pi.</li>
<li>We once again have an installer for Windows as
well. I discontinued this some time ago because
it was such a hassle for me to maintain, but it's back
... at least for now. As far as the Mac is
concerned, well that's still too, too much for me to
keep up with, so the installer for that is still
discontinued, and not likely to be reinstated.<br>
</li>
<li>Updated the VirtualAGC VM, which is really what I'd
prefer the casual user to use. While for the
most part the old VM could simply be updated with the
Ubuntu VirtualAGC installer mentioned above, there are
a number of other niceties I've changed, and not
handled by the installer, such as:</li>
<ul>
<li>Added Code::Blocks visual-debugging links to the
desktop for many more AGC versions.</li>
<li>Eliminated the password entry associated with the
screen-saver, which I hadn't realized was enabled.</li>
<li>Replaced of the Firefox web-browser by the Midori
web-browser. While I don't expect anybody to
really be web-browsing from the VirtualAGC VM, the
web-browser is used by VirtualAGC for presenting the
AGC source code, and Midori is insanely faster than
Firefox at doing this, as well as being less
memory-hungry and disk-space hungry. So using
Midori is a win-win-win.</li>
</ul>
<li>It is perhaps notable that the use of installer
programs as such for the VirtualAGC package has now
been discontinued, and what I'm calling "installers"
are really just compressed archives of type "tar.xz",
which the user must manually uncompress. There
is some slight loss of ease for the user, in that
desktop icons and start-menu entries are no longer
created automatically. But there are compelling
reasons behind this move. The principal
motivation is that a tar.xy archive tends to be about
half the size of one of the old installer programs
(currently 20MB vs 40MB), <i>and</i> it's much easier
from a system-maintenance standpoint as well.
Thus, updating the "installers" more often becomes a
more-attractive proposition.<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-27<br>
</td>
<td valign="top">
<ul>
<li>Updated the VirtualAGC GUI program so that it now
includes all of the various improvements to yaAGC,
yaYUL, AGC source code, etc., since its last release
(11/2016). Specifically, all AGC missions that are
available so far are now supported by the GUI program.<br>
</li>
<li>Updated the VirtualAGC installer on <a
href="download.html">the download page itself</a>.
This
can be used to update the 11/2016 version of the
VirtualAGC virtual machine to today's version of the
software. In a few days, I'll probably release an
updated version of the VirtualAGC virtual machine as
well, but since it's so big, I'd prefer to drag my feet
a little on that, to make sure everything is "just so".</li>
</ul>
<ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-26<br>
</td>
<td valign="top">
<ul>
<li>Regarding the <a
href="links.html#Software_Control_Board_Meeting_Notes">SCB
meeting
notes</a> added a couple of days ago, there was a
foul-up and several of them were either missing or
incomplete. That has been corrected. I don't
mean the set is now complete in any absolute sense, but
merely that it is complete with respect to what Don
Eyles was trying to send us.</li>
<li>70+ documents scrounged from NTRS (and one from UHCL)
have been added to the document library as well.
Most of these are more from a desire to avoid the
hit-and-miss and disappearing-document phenomena
associated with NTRS, rather than being of tremendous
individual significance (as far as we know!) right now,
so I won't itemize them. Look in the <a
href="links.html">document library</a> itself if you
want to know what they are. However, from the
perspective of my quick, superficial once-over, a couple
of the highlights are:</li>
<ul>
<li>CSM System Handbook for <a
href="Documents/19730060777_1973060777.pdf">Apollo 4</a>
and <a href="Documents/19720067986_1972067986.pdf">Apollo
7</a>.</li>
<li>MSC Internal Note, "<a
href="Documents/19750065842_1975065842.pdf">Apollo
Reentry Guidance and Navigation Equations and Flow
Logic</a>"</li>
<li>Kollsman Report, "Apollo Optical Subsystem and LM
Alignment Optical Telescope" (3 volumes)</li>
<li><a href="Documents/19750065564_1975065564.pdf"><i>Apollo
-
Soyuz Test Project Operations Handbook
Command/Service/Docking Modules, CSM111/DM 2</i></a><br>
</li>
</ul>
<li>I've noticed for some time that there's a problem when
I add lots of documents to the document library, because
there's really no way to tell at a glance what has been
added recently, and what has been there for a long
time. I'm trying out adding an icon <img
src="new.png" alt=""> next to recent additions to the
document library, with a notation at the top of the
document library page telling what time-frame the icon
is associated with. Right now, for example,
everything added in March of this month (or presumably
later if there is a later) is marked. We'll see
how well it works. I've seen all too many sites
where once something gets marked as "new", it may
continue to be marked as "new" for years and years ...
and obviously, that's not very helpful. At any
rate, this only applies to the document library page,
and not to the website in general.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-24<br>
</td>
<td valign="top">
<ul>
<li>The Block 1 DSKY has been changed at GitHub, in that
the behavior of its flashing VERB/NOUN indicators has
been fixed.</li>
<li>The instructions for running the Block 1 simulation
from a command line, on <a
href="Block1.html#Taking_Solarium_for_a_Spin">the
Block 1 page</a>, had several flaws, which have been
fixed.</li>
<li>The USERS' GUIDE (Rev 1) document mentioned several
days ago, while perfectly legible as it was, has been
rescanned in places to eliminate crud that had gotten
onto the scanner in some places. There's no real
need to re-download it, but if the artifacts on pp. 595
et seq. bother you, then do so.</li>
<li>The VirtualAGC GUI program (in GitHub, but not yet in
the downloadable virtual machine) can now run Luminary
69, 116, 210, and SuperJob AGC versions, instead of
forcing you to run them from the command line. It
also uses 4 different DSKY configurations as opposed to
the previous 2 (LM vs CM), as described on <a
href="yaDSKY.html#The_Warning_or_Indicator_Lamps">the
DSKY page</a>. In practice, this means that
Luminary 210, Luminary 69, and Block 2 software prior to
Apollo 7 are using a different configuration of DSKY
warning lamps than would have been expected previously.</li>
<li>Don Eyles has sent over a few reports of <a
href="links.html#Software_Control_Board_Meeting_Notes">Software
Control
Board meeting notes</a>, now in our document
library. Yes, I know, exceedingly dull,
right? Well, not exactly! As you may recall,
we recently added a series of <a
href="links.html#LUMINARY_Memos">LUMINARY Memos</a> to
the document library ... an effort which is only about
half-completed so far, by the way. One virtue of
these LUMINARY Memos was that <i>if complete</i>, they
could be used to track all AGC software changes, so that
we could get a much-better understanding of the changes
from (say) Luminary 99 to Luminary 116 to Luminary 131
to whatever. Of course, the LUMINARY Memos aren't
entirely complete, either in their coverage of events,
nor in our collection of them. Well, the SCB Notes
have a similar virtue, again if complete, in that they
provide much the same information about software
changes. Moreover, since in theory <i>every</i>
software change had to be approved by the SCB, there
shouldn't be as much of a completeness problem in the
notes themselves, though obviously we have every bit as
much of a problem in the completeness of our collection
of them. In the case of SCB notes, though, they
don't track changes like Luminary 99 → 100, but rather
changes like Luminary 1B → 1C. This still ends up
giving us the mission-to-mission changes, even if not
the fine-grained revision-to-revision changes.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-23<br>
</td>
<td valign="top">Fixed a few more crummy hyperlinks on the
document library page.<br>
</td>
</tr>
<tr>
<td valign="top">2017-03-22<br>
</td>
<td valign="top">
<ul>
<li>It has been pointed out to me that the document
library contained a few of the missions' technical crew
debriefings, but that several more were missing though
available elsewhere. So for the sake of
consistency, the Apollo 12, 13, 14, and 16 technical
crew debriefings have been copied from the <a
href="https://www.hq.nasa.gov/alsj">Apollo Lunar
Surface Journal (ALSJ)</a> into <a
href="links.html#Crew_debriefings">our document
library</a>.</li>
<li>Corrected a few hyperlinks which pointed to files on
my home computer rather than the website.
D'oh! If only I had a dollar for every time I had
had to fix that over the years.</li>
<li>The recent Users' Guide documents from Don Eyles,
mentioned over the last couple of updates, turn out to
have a handful of foldout pages which were getting
messed up in the conversion of the document to
PDF. It has taken me several tries to get right
(the problem being, apparently, that pages with aspect
ratios more-extreme than 2:1 don't work right in the
PDF), but I now have PDFs that I think are fully
working. The fix to the PDFs has messed up those
pages in the online viewer in our Internet Archive
collection (sigh!), but the foldouts still legible
there, and I'm willing to live with that.</li>
<li>I've been chided for making it appear that the
recently-added Programmed Guidance Equation documents
from Don Eyles, for Luminary 1B and 1C, mentioned a few
days ago, weren't very useful. That's a fair
criticism, so I've modified my comments. While it
is true that I think calling these documents the
"Guidance Equations" is misleading, it would also be
true that better titles for them would be "Pseudo-Code
Descriptions of Luminary 1B" and "... 1C". And
that, of course, can make them <i>very</i> valuable for
someone trying to comprehend the Luminary 1B and 1C
programs. As Don said when he gave them to me,
"Now, you know, <i>we</i> [AGC developers] didn't ever
use these documents; they were written afterward for <i>other</i>
people" (or words to that effect, anyway). But <i>we</i>
are the "other people" in this little scenario, so while
these documents may not be so important for Don, they
may indeed be very important for us.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-20<br>
</td>
<td valign="top">
<ul>
<li>The Internet Archive's processing (mentioned in
yesterday's update notice) of Don Eyles's big box of IL
and MSC documents went much faster than I supposed, so
I've now added the compact, text-searchable PDFs for all
these documents into our <a href="links.html">document
library</a> and appropriate places on the <a
href="Colossus.html">Colossus</a> and <a
href="Luminary.html">Luminary</a> pages ... and of
course, yesterday's links to our Internet Archive
collection still work, but you can now find
fully-fleshed out entries there rather than just my huge
archival uploads of the scans.<br>
</li>
<li> It seems as though E-2280 "Solid State DSKY Study"
didn't get added to the document library for some
reason. It has now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-18<br>
</td>
<td valign="top">
<ul>
<li>Added <a href="Block1.html#Blocks_for_All_Occasions">a
link to a nice documentary video</a> about the Block 1
AGC and DSKY.</li>
<li>A few weeks back, original developer Jim Pennypacker
had sent me his copy ("#1") of one of the
Instrumentation Lab documents that we had only
previously had a mutilated copy of ("#114"), namely
R-531, "<a
href="Documents/R-531%20Whole%20Number%20Strapdown%20Computations%20by%20J.%20C.%20Pennypacker_text.pdf">Whole
Number
Strapdown Computations</a>". While I had scanned
the darn thing at the time, and uploaded the
archival-quality scans to our Internet Archive
collection, I had failed to replace the old, bad version
in our document library. D'oh! Well, I've
done it now. It's an interesting concept that
never made it into an actual spacecraft, but well-worth
reading about.<br>
</li>
<li>Niklas Beug has made another video to supplement his
previous Apollo 11 lunar landing simulation video (using
Orbiter/NASSP/VirtualAGC/Luminary99), namely an Apollo
15 simulated lunar landing (using
Orbiter/NASSP/VirtualAGC/Luminary210), and I've linked
it at a couple of a strategic locations. Here's <a
href="https://youtu.be/E301HplyA7A">a direct link to
YouTube</a>. For my taste, it's a lot more
exciting than the Apollo 11 landing (minus the 1201/1202
alarms and the boulder field at the very end of the
Apollo 11 landing, of course), since you get to swoop in
over the mountains; Nik indicates it's his favorite
landing site as well. As far as it being a
favorite landing site is concerned: I don't know if it
depicts a real event or not, but the Apollo 15 episode
of <i>From the Earth to the Moon</i> dramatizes Dave
Scott as arguing for this Hadley-Apennine site (vs a
"safer" landing site) in the decisive site-selection
meeting, presenting the argument that it's worthwhile
exploring beautiful places.</li>
<li>I've done a lot of cross-version checking of our AGC
source code (Luminary 69 vs Luminary 99 vs Luminary 116
vs Luminary 131 vs Luminary 210; Colossus 237 vs
Colossus 249 vs Comanche 55 vs Artemis 72; and Luminary
99 vs Comanche 55), which has not only found various
lingering errors (mostly look-alikes such as '0'⇆'O',
'1'⇆'I', '.'⇆',', and so on), but more-importantly,
insures consistency across AGC versions, hence reducing
spurious "changes" for anybody who is interested in
detailed tracking of changes from one AGC version to the
next. Consequently, I've updated <a
href="listings/">our colorized, syntax-highlighted AGC
program listings</a> yet again.</li>
<li>Don Eyles has sent me a box of huge Instrumentation
Lab and MSC documents, many of them 800-1200 pages,
which I have scanned and uploaded as archival copies to
<a href="https://archive.org/details/virtualagcproject">our
Internet
Archive collection</a>. It will probably take
the Internet Archive a week or so to process them all,
and it is only after they've done so that we'll have
nice, compact PDFs with text-search, that can be
conveniently read, and which I would feel comfortable
putting into our document library. (Yes, it's
shocking, I know, but the Internet Archive has better
software for processing PDF files than I do! Who
would have thunk it?) In the interim, I'll just
give you the links to the Internet Archive pages for the
documents, and if you're really keen to look at them,
you'll just have to download and view the monster PDFs I
uploaded there:</li>
<ul>
<li><a
href="https://archive.org/details/j2-80-E-2448-REV1">E-2448
Rev
1, "Users' Guide to Apollo GN&CS Major Modes and
Routines"</a>. This is essentially a user
manual for the AGC software, essentially for Apollo 13
and/or 14, though the text in the document itself
disavows any connection to specific missions.</li>
<li><a
href="https://archive.org/details/j2-80-E-2448-REV4">E-2448
Rev
4, "Users' Guide to Apollo GN&CS Major Modes and
Routines, Colossus 3 and Luminary 1A"</a>.
This is essentially a user manual for the AGC
software, for Apollo 15, 16, and 17.</li>
<li>E-2471 Rev 2, "Apollo Guidance and Navigation
Flowcharts, Program Luminary 1D (Rev 173)". This
is just what it sounds like: a set of AGC
software flowcharts for Apollo 14:</li>
<ul>
<li><a
href="https://archive.org/details/j2-80-E-2471-REV2-VOL1">Volume
1/2</a>.</li>
<li><a
href="https://archive.org/details/j2-80-E-2471-REV2-VOL2">Volume
2/2</a>.</li>
</ul>
<li>R-567, "Guidance System Operations Plan for Manned
LM Earth Orbital and Lunar Missions Using Program
Luminary 1E". I.e., most of the GSOP for Apollo
15, 16, and 17. A couple of these sections we
already had in a reasonable quality (but now we have
two copies), but we didn't have the bulk of the
document, particularly the huge section 4. And
sections 1 and 6 are still missing.</li>
<ul>
<li><a
href="https://archive.org/details/j2-80-R-567-SEC2-REV12">Section
2
Rev 12, "Data Links"</a></li>
<li><a
href="https://archive.org/details/j2-80-R-567-SEC3-REV8">Section
3
Rev 8, "Digital Autopilot"</a></li>
<li><a
href="https://archive.org/details/j2-80-R-567-SEC4-REV10">Section
4
Rev 10, "Operational Modes"</a></li>
<li><a
href="https://archive.org/details/j2-80-R-567-SEC5-REV11">Section
5
Rev 11, "Guidance Equations"</a>. I would
characterize this more as a theory-of-operation
document for various sections of the AGC software,
but I think the guidance equations are indeed in
there.</li>
<li><a
href="https://archive.org/details/j2-80-R-567-SEC7">Section
7,
"Erasable Memory Programs"</a><br>
</li>
</ul>
<li><a
href="https://archive.org/details/j2-80-MSC-69-FS-4">MSC-69-FS-4,
"Programmed
Guidance Equations for Luminary 1B, Manned LM Earth
Orbital and Lunar Program"</a>. I wouldn't
really describe this as "guidance equations".
The document itself says it should be used in
conjunction with a listing of the AGC software (in
this case, Apollo 12 Lunar Module, and specifically
Luminary 116), and my characterization of it is that
it is a more-detailed, mostly-textual description of
the various objects (specifically variables) appearing
in the software than can be found in the program
comments themselves. In other words, it doesn't
superficially appear to have much to do with "guidance
equations", though admittedly it has >1000 pages,
and I've not read it in detail as of yet.</li>
<li><a
href="https://archive.org/details/j2-80-MSC-70-FS-2">MSC-70-FS-2,
"Programmed
Guidance Equations for Luminary 1C, Manned LM Earth
Orbital and Lunar Program"</a>. This is
basically the Apollo 13 equivalent of MSC-69-FS-4 (see
above). In other words, <i>not</i> guidance
equations, unless they're well-camouflaged.<br>
</li>
</ul>
<li>Finally, the team has finished the transcription of
Luminary 116 from the printed program listing to
source-code files that can be run through the assembler:<br>
</li>
</ul>
<table cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top" align="center"><font color="red"><b>Transcribed
<a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary116">source
code for Luminary 116</a> (Apollo 12 Lunar
Module<br>
AGC) is now available, as well as <a
href="listings/Luminary116/MAIN.agc.html">syntax-highlighted,
colorized
HTML</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-10<br>
</td>
<td valign="top">
<ul>
<li>Removed some unwanted personal references.</li>
<li> Updated syntax-highlighted HTML AGC listings.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-03-03<br>
</td>
<td valign="top">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.<br>
<br>
The explanation is that the <a
href="https://en.wikipedia.org/wiki/Ephemeris">ephemeris</a>
data in Rev 1 is wrong, but not <i>very</i> 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 <i>recreated</i> <a
href="listings/LUM99R2/MAIN.agc.html">Luminary 99 Rev 2</a>
for you, as a mashup of 99 Rev 1 and Luminary 116, and we
provide <i>both</i> 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 <a
href="https://github.com/virtualagc/virtualagc/tree/master/LUM99R2">"LUM99R2"
in
the GitHub source tree</a>, because that's what Jim's
story says he called it, way-back-when.<br>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-03-01<br>
</td>
<td valign="top">
<ul>
<li>Proofing of Luminary 131 comment text (vs our new scan
of the program listing) is finally complete. The
proofing data has also been uploaded (see <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files">our
GitHub
wiki</a> for both a description of the method and a
link to the proofing data), in case you suddenly have an
urge to double-check it. The comments in the
source code undoubtedly still have quite a few errors,
but after the transcription effort for Luminary 116 has
been completed, I intend to do a 3-way check of it vs
Luminary 99 and 131, which should eliminate quite a few
of the remaining errors. This actually means that
all of the fully-transcribed AGC source-code versions
have now been completely proofed in their comment text,
albeit not all to the same standards, due to differences
in printout- and scan-quality.</li>
<li>As usual, the proofing of Luminary 131's comments
revealed various corresponding errors in the source code
for other AGC versions, and those errors have been fixed
as well. Consequently, there have been quite a few
updates (not the least of which is Luminary 131 itself)
in <a href="listings/">the colorized,
syntax-highlighted versions of the the AGC assembly
listings</a>.<br>
</li>
<li>I noticed that a lot of <a href="volunteer.html">the
volunteering page</a> was still out of date, and
hopefully that's fully fixed up now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-22<br>
</td>
<td valign="top">
<ul>
<li>The limitation on following certain hyperlinks on the
staging version of this website, caused as a by-product
of certain improvements (see 2017-02-17), has now been
fixed. I think. If I did it right, all
hyperlinks on the staging website should work, but some
of them will point to the main website rather than the
staging website. Hardly any of you will have
noticed the problem anyway, so you can really just
ignore this note.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-21<br>
</td>
<td valign="top">
<ul>
<li>Quite a few documents salvaged from NTRS were added to
the document library, and linked into the Colossus and
Luminary pages where appropriate. Most were just
random documents spread throughout <a
href="links.html#Miscellaneous">the miscellaneous
guidance&navigation document section of the
document library</a>, and I invite you to browse
through that section, but I don't want to list dozens of
documents individually here. However, there were
also various documents of particular note, the
highlights of which in my mind are:</li>
<ul>
<li>E-1114, "<a
href="Documents/E-1114%20Glossary%20of%20Terms%20and%20Symbols.pdf">Glossary
of
Terms and Symbols</a>"<br>
</li>
</ul>
<ul>
<li>"<a
href="Documents/E-1828%20G&N%20System%20Data%20for%20Mission%20AS-202,%20Development%20Engineering%20Inspection.pdf">G&N
System
Data for Mission AS-202 Development Engineering
Inspection</a>" ... i.e., for "Apollo 3"<br>
</li>
<li>"<a
href="Documents/TRW-67-FMT-548%20Results%20of%20Independent%20Flight%20Software%20Validation%20Test%20of%20the%20BURST116%20Program%20for%20the%20LM-1%20Mission.pdf">Results
of
Independent Flight Software Validation Test of the
BURST116 Program for the LM-1 Mission</a>" ... i.e.,
for Apollo 5<br>
</li>
<li>"<a
href="Documents/Apollo%20Mission%20SA%20501%20Preliminary%20Mission%20Profile.pdf">Apollo
Mission
SA 501 Preliminary Mission Profile</a>" ... i.e.,
for Apollo 4<br>
</li>
<li>"<a
href="Documents/TRW-66-FMT-470%20Independent%20Flight%20Software%20Validation%20Test%20Results%20for%20Mission%20AS-204A.pdf">Independent
Flight
Software Validation Test Results for Mission AS-204A</a>"
... i.e., for Apollo 1<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-20<br>
</td>
<td valign="top">
<ul>
<li>Weirdly, on <a href="Colossus.html">the Colossus page</a>,
I noticed that my description of Apollo 12 didn't show a
Colossus revision number at all, while Apollo 13 showed
Apollo 12's revision number, and Apollo 14 showed Apollo
13's revision number. Yikes! Anyway, that
has been fixed.</li>
<li>Added a couple of nice, new documents to <a
href="links.html">the document library</a>, along with
references to them on the <a href="Luminary.html">Luminary</a>
and <a href="Colossus.html">Colossus</a> pages, where
appropriate:</li>
<ul>
<li><a
href="Documents/R-693%20GSOP%20Skylark%201%20Section%203%20Digitgal%20Autopilots.pdf">Skylark
GSOP,
section 3</a></li>
<li><a
href="Documents/MSC%2069-FM-248%20Spacecraft%20Operational%20Trajectory%20for%20Apollo%2012%20Volum%20I.pdf">Apollo
12
Spacecraft Operational Trajectory</a></li>
</ul>
<li>A number of documents salvaged from NASA's
now-crippled NTRS system are in the process of being
added to the document library, although at this point it
has mainly been <a
href="links.html#Instrumentation_Laboratory_Status">a
bunch of Instrumentation Lab status reports to NASA</a>
... interesting if you are keen on that kind of thing,
but not chock-full of useful technical data. They
<i>do</i> track the number of words of AGC memory used
for implementing various areas of functionality over
time, which had fairly-important design consequences, so
they are certainly useful in that regard.</li>
<li>Belatedly realized that we already had a non-Raytheon
document associated with the experimental Auxiliary
Memory (AM) which the Raytheon-written AGC program
SuperJob (announced here a couple of weeks ago) tests
and demonstrates. The document in question, an
Instrumentation Lab document, E-2254, is actually
extremely informative, so I've linked it in with <a
href="Luminary.html#SuperJob">the general information
about SuperJob on the Luminary page</a>.<br>
</li>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-19<br>
</td>
<td valign="top">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 <a
href="links.html#LUMINARY_Memos">their own section in the
document-library page</a>. There's lots of notable
stuff there, but what stands out for me are:<br>
<ul>
<li>There are many, many memos describing the changes
incorporated into various builds of the Luminary
software, starting with Luminary 4 and ending up with
Luminary 209. Since one of our long-term goals
here is to understand how the AGC software evolved over
time, this is naturally a huge help.</li>
<li>There are a number of memos that give us more insight
into what Zerlina is doing, and how. You may
recall that Zerlina was an experimental program,
branched from Luminary, and used to experiment with a
number of new approaches. Furthermore, we will be
obtaining Zerlina within the next few months, and going
through our usual process of transcribing it into source
code and running it in the AGC simulator. So it's
nice to have some idea of what we can expect it to be
doing.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-17<br>
</td>
<td valign="top">
<ul>
<li>I belatedly realized that some changes made to this
website a few months ago to enable full functionality of
the "staging version" of the website (at our GitHub
repo) actually destroy the ability to correctly mirror
the main website or to run it from local storage without
an internet connection. That has now been
fixed. However, the staging website will no longer
be full-functionality, in the sense that clicking within
it to links in our document library will no longer work,
because the (~11GB) document library is not itself
stored on GitHub.</li>
<li>I also belatedly realized that a different change to
the website a few months ago, using a bit of JavaScript
to make sure the banners on all of the sites pages were
identical and easy to maintain, obviously would not work
if JavaScript was disabled, and would simply make the
site unnavigable. That has been fixed, so that the
site is at least minimally navigable (and displays a
warning message) if JavaScript is disabled in the
browser.</li>
<li>Added a few more factoids to the FAQ (FAQtoids?) about
mirroring the website, privacy concerns, associated
websites, and so forth.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-16<br>
</td>
<td valign="top">
<ul>
<li>Added yet another amusing anecdote about TRW's John
Norton to the FAQ.</li>
<li>For all of the AGC program listings which we've had
scanned in the last 6 months or so (which is a lot!),
we've only been hosting reduced-quality (though
adequate) page images here at our main website, while
the full-quality scans have been available instead at <a
href="https://archive.org/details/virtualagcproject">our
"collection"
in the Internet Archive</a>. However, that
hasn't been quite true for the AGC scans we made <i>prior</i>
to that (Artemis 72, Colossus 237, Colossus 249,
Comanche 55, Luminary 99, Solarium 55). For <i>those</i>
AGC scans, we've been hosting <i>just</i> the
low-resolution imagery. The higher-resolution raw
data from the scans has existed only on my own personal
computers and backups, though you could have gotten it
from me if you asked for it. Well, that situation
has changed, and I've now uploaded all of the raw scan
data to our Internet Archive collection. Now, I'll
have to admit that, archival format or not, the visual
quality is still rotten in comparison to the new scans,
because I didn't understand things like white-balance
settings when I took the pictures. Nevertheless,
all of you (rather than I alone) now have access to the
best-quality imagery available. Furthermore, in
the future, I'll also be doing the same with any image
files sent to me or that I personally scan.
Incidentally, since AGC listings are <i>big</i>
documents in comparison to what the Internet Archive
normally handles, the initial processing on them may not
yet be complete on all of these uploads if you rush over
there right this instant to look at them; if the initial
processing isn't complete, only the actually-uploaded
data (gigantic PDFs 250MB-1.5GB in size) will be
immediately accessible. After the processing is
completed, you also have a convenient online flipbook
viewing interface, a zipfile of JPEG2000 page images,
and a more-compact PDF with searchable text.
Solarium 55 is definitely ready for viewing at the
moment I'm writing this, and the others should gradually
become available over the next few days. Documents
I end up scanning but which turn out not to be suitable
for Virtual AGC proper, will simply remain in the
Internet Archive collection; for example, you'll find <a
href="https://archive.org/details/MSC07857">a Shuttle
document</a> there that I happened to scan while
scanning some AGC-related documents.</li>
<li>I've also been busily correcting all of the metadata
for the scans hosted in our Internet Archive collection,
since we hadn't initially provided very good data at the
time archive.org was making the scans.</li>
<li>Three new documents pertaining to Apollo 4, 5, and 6
have been contributed by AGC developer Jay
Sampson. (Refer to the Sunburst 120 section of the
Luminary page, and the Solarium 54 and 55 sections of
the Colossus page.)</li>
<li>Original AGC developer Jay Sampson has convinced us
that the AGC versions used for these two missions
(Solarium 54 and 55, respectively) are in fact <i>identical</i>
though assigned different build numbers. In other
words, we in fact have the AGC source code for Apollo 4,
even though we didn't know we had it. I won't
proclaim that discovery in a big box just yet,
though! You can read the explanation in <a
href="Colossus.html#Solarium54">the Solarium 54 entry
on the Colossus page</a>.</li>
<li>Original AGC developer Peter Volante has sent me a
variety of organization charts for the Instrumentation
Lab's Apollo development, which help to show how the
organization evolved over time, and how the people
within it moved around. I've added them as
complementary to the list of developers gleaned from the
AGC source code, in <a
href="index.html#Acknowledgements">the
Acknowledgements section of the website's home page</a>.</li>
<li>Some documents salvaged from NTRS were added:</li>
<ul>
<li>Clean copies of R-500, volumes 1 and 2.</li>
</ul>
<li>Added an Internet Archive link to the headers on all
the pages of this site, to take you directly to our
"collection" at archive.org.<br>
</li>
<ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-15<br>
</td>
<td valign="top">A number of new documents for the document
library were added. Highlights are:<br>
<ul>
<li>Abort Guidance System (AGS) (all from UHCL archives):</li>
<ul>
<li><a
href="Documents/17618-H110-RO-00%20LM%20AGS%20Operating%20Manual%20Flight%20Program%208.pdf">LM/AGS
Operating
Manual, Flight Program 8</a><br>
</li>
<li><a
href="Documents/LM%20PGNS-AGS%20Training%20Card.pdf">LM
PGNS/AGS
Training Card</a><br>
</li>
</ul>
<li>Early unmanned missions (all donated by AGC developer
Jay Sampson; see also <a
href="links.html#Miscellaneous_Mission_Documents">the
bits and pieces of Jay's story</a>):</li>
<ul>
<li>Flight 206 Memo #11, "<a
href="Documents/Prelaunch%20Erasable%20Memory%20Load%20Definition%20for%20AS206.pdf">Prelaunch
Erasable
Memo Load Definition for AS206</a>"<br>
</li>
<li>Flight 501 Memo #8, "<a
href="Documents/Programming%20Changes%20rom%20AS-202%20to%20AS-501.pdf">Programming
Changes
from AS-202 to AS-501</a>". This document is
of particular interest, due to the fact that we <i>have</i>
the source code for AS-502 (almost identical to 501)
and <i>may get</i> the octals but not source code for
AS-202, thus theoretically helping us to reconstruct
the source code for AS-202.<br>
</li>
<li>Flight 501 Memo #10, "<a
href="Documents/Summary%20of%20Results%20of%20AS-501%20Digital%20Simulations.pdf">Summary
of
Results of AS-501 Digital Simulations</a>"<br>
</li>
<li>Flight 501 Memo #14, "<a
href="Documents/Final%20Verification%20E-Memory%20Data.pdf">Values
Used
for the Final Verification of the AS-501 Prelaunch
Erasable Memory Data Load on the MIT/IL Digital
Simulator</a>"</li>
<li>Apollo 5: E-2160, "<a
href="Documents/Verification%20Results%20Summary%20for%20LM-1%20Mission.pdf">Verification
Results
Summary for LGC SUNBURST (LM-1 Mission)</a>"</li>
</ul>
<li>Improved (i.e., smaller and searchable) versions of
the 5 LUMINARY Memos Dan Eyles recently supplied us
with.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-12<br>
</td>
<td valign="top">
<ul>
<li>Slight correction to <a
href="faq.html#MoreAmusingStories">the "John Norton
Needs Glasses" story</a>.</li>
<li>Rewrote <a href="Luminary.html#Luminary99Blurb">discussion
of
Apollo 11 LM code (Luminary 99) versioning</a> (which
is an ongoing story right now).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-11<br>
</td>
<td valign="top">
<ul>
<li>I forgot to mention it, but proof-reading the program
comments in Artemis 72 (Apollo 15-17 LM) has now been
completed, and the improved source-code files have been
available in our GitHub repo for a few days. The
quality of the scan or the printout from which the scan
was made was pretty poor, though, so there are likely to
be more errors remaining than in many of the other AGC
versions. Nevertheless, there's a great
improvement.</li>
<li>We have had Luminary 131 (Apollo 13 LM software)
scanned from a copy in Don Eyles's possession.
Old-timers here may recall that the availability of a
Luminary 131 scan was what enabled this entire Virtual
AGC project in the first place, back in the day, and
without it, none of this mighty empire of AGCosity would
exist at all. Nevertheless, there's no getting
around the fact that that original scan was miserable in
quality, barely legible, and practically a study of how
a scan of a color document shouldn't be. In fact,
many of the errors in AGC program comments I mentioned
above, and have been mentioning for the last several
months, stemmed originally from that very unreadability,
but the new scan will now be used to finally eliminate
those errors from our Luminary 131 source-code
files. So we're lucky that we now have a really
great scan. Check it out in our <a
href="ScansForConversion/Luminary131-Eyles">local
"low" quality version</a>, or in <a
href="https://archive.org/details/luminary131agcpr00miti">the
higher-quality
version at archive.org</a>.</li>
<li>New documents in document library:</li>
<ul>
<li><a
href="Documents/NAS9-497_ApolloPrimaryGuidanceNavigationAndControlSystem.pdf">Apollo
Primary
Guidance Navigation and Control System (PGNCS):
Final Report, Contract NAS9-497</a>.</li>
<li><a href="Documents/HSI-41196.pdf">Volume 2 (LM Data
Book), Part 2 (LM 6 and Subs. Launch Mission Rule
Redlines)</a>.</li>
<li><a href="Documents/HSI-209584.pdf">Apollo 5 Mission
(AS-204/LM-1) Spacecraft Operational Trajectory.</a></li>
<li><a href="Documents/HSI-209546.pdf">Apollo 7
Spacecraft Operational Trajectory</a></li>
</ul>
<li>Added various additional comments from one of the
original authors (on the document-library page itself)
for the rendezvous-procedures document I added
yesterday.</li>
<li>Finally got around to putting a table of contents in
the FAQ; it was simply too unwieldy without one.<br>
</li>
<li>Added various material from AGC developers and other
correspondents to the <a
href="faq.html#MoreAmusingStories">Tell Us More
Amusing Stories</a> section of the FAQ.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-02-10</td>
<td valign="top">Added a cool document to the document
library, "<a href="Documents/Mission_G_Rendezvous.pdf">LM
Rendezvous Procedures, G Mission</a>" 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 <i>both</i> 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.</td>
</tr>
<tr>
<td valign="top">2017-02-07</td>
<td valign="top">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: <a href="Documents/satinstunitibm_1.pdf">1</a>,
<a href="Documents/satinstunitibm_2.pdf">2</a>, <a
href="Documents/satinstunitibm_3.pdf">3</a>, <a
href="Documents/satinstunitibm_4.pdf">4</a>, <a
href="Documents/satinstunitibm_5.pdf">5</a>, <a
href="Documents/satinstunitibm_6.pdf">6</a>, <a
href="Documents/satinstunitibm_7.pdf">7</a>. 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.</td>
</tr>
<tr>
<td valign="top">2017-02-04<br>
</td>
<td valign="top" align="center">
<div align="left">
<ul>
<li>Although it's not necessarily usable in the AGC
simulator yet (because the simulated resources for it
don't exist), I think we can now say that</li>
</ul>
</div>
<table cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top" align="center"><font color="red"><b>Transcribed
<a
href="https://github.com/virtualagc/virtualagc/tree/master/SuperJob">source
code
for SuperJob</a> (Raytheon's Auxiliary Memory
test <br>
program) is now available, as well as <a
href="listings/SuperJob/MAIN.agc.html">syntax-highlighted,
colorized
HTML</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<div align="left">
<ul>
<li>Niklas Beug has been looking at the archives of the
University of Houston, Clear Lake (UHCL), and with the
assistance of the very helpful archivists there has
found some documents of interest to us. The
first of these (with apparently more to come) have
arrived, and naturally have immediately been put into
our document library:</li>
<ul>
<li>The previously-missing <a
href="Documents/HSI-208456.pdf">section 5</a>
(Guidance Equations) of the <a
href="Colossus.html#Skylark">Skylark</a>
(Apollo-Skylab and Apollo-Soyuz CM) Guidance System
Operations Plan (GSOP).</li>
<li><a href="Documents/HSI-41539.pdf">CSM/LM
Spacecraft Operational Data Book</a>, volume I,
CSM data book, Part I "Constraints and Performance",
rev 3. (Previously we had only <a
href="Documents/SNA-8-D-027III-Rev2-CsmLmSpacecraftOperationalDataBook-Volume3-MassProperties.pdf">volume
III</a>, Mass Properties, rev 2.)
Interestingly, the document has Appendices for CSM
109 (Apollo 13), 110 (14), 112 (15), 113 (16), and
114 (Apollo 17), though the table of contents says
incorrectly that 109 and 110 have been deleted from
the book.<br>
</li>
</ul>
</ul>
</div>
</td>
</tr>
<tr>
<td valign="top">2017-02-03<br>
</td>
<td valign="top">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 <a
href="ScansForConversion/DigitalSimulationAP11ROPE_color/">color
images</a> as an additional alternative. They're not
uniformly good, but I think they're an improvement over the
full-resolution scan at archive.org.<br>
</td>
</tr>
<tr>
<td valign="top">2017-02-02<br>
</td>
<td valign="top">
<ul>
<li><a
href="ScansForConversion/Apollo17DigitalSimulation/">Another
digital
simulation</a>, this time of the Apollo 17 landing,
also from Don Eyles's personal collection, with the
scanning again financed by Fabrizio Bernardini, is now
available on our Luminary page. Thanks again,
Fabrizio!</li>
<li>I was mildly chided for not including the link to the
local B&W imagery for the Apollo 11 landing's
digital simulation that I announced last time. I
did this intentionally because it's a 92MB PDF file that
I didn't want to be <i>idly</i> downloaded, so I wanted
you to go to the Luminary page if you were interested
... but that's daft reasoning, and all you needed was a
warning that it's a big file. <a
href="ScansForConversion/DigitalSimulationAP11ROPE.pdf">Here's
the
direct link to the PDF</a>. (In contrast, the
Apollo 17 link above is to a folder full of JPGs.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-01-29<br>
</td>
<td valign="top">
<ul>
<li>The first of several <i>digital simulations</i> of
moon landings that we're having scanned from Don Eyles's
personal collection has finally arrived. This
first one, done in 1971, is of an Apollo 11
landing. Thanks to Don and to Fabrizio Bernardini
for financially sponsoring the scanning. Note that
it is presently mislabeled in the full-color scans at <a
href="https://archive.org/details/virtualagcproject">archive.org</a>
as "Luminary 131", and the sponsorship is
misrepresented, but presumably this will be fixed
soon. The scans are also very low-contrast and
hard-to-read, so I've provided reprocessed B&W
imagery to get around that. <a
href="Luminary.html#Kernan">Read the Apollo 11 entry
on the Luminary page</a> for lots more info.</li>
<li>A very interesting AGC program written by Raytheon
rather than the MIT Instrumentation Lab has
surfaced. (It was actually buried as an appendix
to a Raytheon document on the NASA's now-defunct
technical reports server, NTRS, which of course made it
almost but not quite impossible to find. But
better late than never!) We've dubbed this program
"Super Job" because of the markings on it, though it's
hard to believe that Raytheon actually called it
that. At any rate, there's lots more to read about
it on <a href="Luminary.html#SuperJob">the Luminary
page</a>.</li>
<li>The proof-reading of the transcribed source code for
the Luminary 69 program has finally been completed, so
I'm now making an official announcement:</li>
</ul>
<table cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top"><b><font color="red">Transcribed <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary069">source
code</a> for Luminary 69 (Apollo 10 LM) is now
available, as well as <a
href="listings/Luminary069/MAIN.agc.html">syntax-highlighted,
colorized
HTML</a>.</font></b><br>
</td>
</tr>
</tbody>
</table>
<ul>
<li>Due to the fact that some comment-text errors
discovered in proofing Luminary 69 occurred in other AGC
transcriptions as well, there are a number of updates to
the source code and syntax-highlighted HTML for a number
of other AGC versions.<br>
</li>
</ul>
<p><br>
</p>
</td>
</tr>
<tr>
<td valign="top">2017-01-26<br>
</td>
<td valign="top">
<ul>
<li>Have largely rewritten <a
href="faq.html#Is_the_moon_landing_a_hoax">the "hoax"
section of the FAQ</a>. Apparently, when I first
wrote it, I had resorted to a lot of sarcasm that seems
very harsh now, though sadly no-less correct.
There's also new material in it, so the section is
substantially larger than before.</li>
<li> Also added tindallgrams.net to <a
href="faq.html#other_websites">the list of recommended
external sites</a>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-01-25<br>
</td>
<td valign="top">All sponsorship opportunities for the Don
Eyles's scannable materials offered <i>so far</i> — 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.<br>
<br>
I've accordingly removed the giant <b>Volunteering
Opportunity</b> note that had been stuck at the top of the
home page, though you can still <a href="volunteer.html">read
all
about it</a> if you like.<br>
</td>
</tr>
<tr>
<td valign="top">2017-01-24<br>
</td>
<td valign="top">
<ul>
<li>Several early GSOPs (Guidance System Operations
Plans), or sections thereof, have been added to the <a
href="links.html">document library</a> and <a
href="Colossus.html">Colossus pages</a>: 3 different
revisions of the complete AS-202 ("Apollo 3") GSOP,
volume II (though still no volume I) of the Apollo 1/2
GSOP, and volume II (we already had volume 1) of the
Apollo 4 GSOP. There is also an updated rev
(11→14) of the "Digital Autopilots" section of the
Apollo 15-17 GSOP. Incidentally, it may be worth
noting that many documents from the
now-apparently-defunct NASA NTRS technical-documents
server are showing up at <a
href="https://www.archive.org">archive.org</a> (no,
you don't have <i>us</i> to thank for that). It's
a bit tricky finding anything in that collection,
perhaps more so than even the NTRS server was, so if you
find any Apollo or Gemini related software or
software-related docs there that aren't already in our
document library, do let us know.<br>
</li>
<li>Probably more importantly, the transcription of the
Luminary 69 (Apollo 10, mostly) AGC source code has been
completed, <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary069">put
into
GitHub</a>, and assembles properly. Comment-text
proofing still remains, so I guess I'll hold off on
making a big deal of it until that has been completed as
well.<br>
</li>
</ul>
<p><br>
</p>
</td>
</tr>
<tr>
<td valign="top">2017-01-20<br>
</td>
<td valign="top">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 <i>original</i>
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 <i>so</i> 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.<br>
<br>
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) <i>might</i> 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.<br>
<br>
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.<br>
<br>
More than you wanted to know, probably, but having just
finished it, I'm still excited about it!
:-) <br>
<br>
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 <i>last</i> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-01-11<br>
</td>
<td valign="top">I've added a few "new" names to <a
href="index.html#Acknowledgements">the list of AGC
developers</a>, 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 <i>yet</i>
done those latter things.<br>
<br>
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!<br>
<br>
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
href="https://creativecommons.org/publicdomain/zero/1.0/">a
Creative Commons No Rights Reserved license</a>.
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, <a
href="http://www.sitasingstheblues.com/">Sita Sings the
Blues</a> ... 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.)<br>
<br>
Comparably gutsy to Nina's film is Kimiko Ishizaka's release
of her piano renditions of Bach's <a
href="http://www.opengoldbergvariations.org/download">Goldberg
Variations</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2017-01-06<br>
</td>
<td valign="top">
<ul>
<li>The original <a
href="ScansForConversion/Colossus249/"> Colossus
249</a> and <a href="ScansForConversion/Luminary131/">
Luminary 131</a> scanned material which we started
with, way back in 2003, as well as the <a
href="ScansForConversion/Colossus249-Martin/">
improved replacement Colossus 249 scan we made of Fred
Martin's program listing</a>, has been completely
restructured so that it conforms to the same pattern as
all of <a href="ScansForConversion/">the other scanned
AGC program listings</a>: i.e., it now consists
entirely of PNG files, one per each page numbered by the
original assembler, and no PDF files at all. A
side benefit is that while the original print/scan
quality has naturally not improved, the quality of the
images we're providing has nevertheless improved anyway,
whilst decreasing the actual file sizes. At the
same time, page-number references in the <a
href="https://github.com/virtualagc/virtualagc/tree/master/Colossus249">
Colossus 249</a> and <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary131">
Luminary 131</a> transcribed source-code files, which
previously corresponded to the PDF page-numbers in the
gigantic now-irrelevant all-in-one PDF files downloaded
from the now-defunct History of Recent Technology
website, have been changed so that (like all other AGC
source-code listings) they correspond to the page
markings on the original printed pages of the program
listings. My motivation for all of these changes
is that I intend to begin proofing the comment text in
the Colossus 249 and Luminary 131 source-code files by
cross-comparing them with similar AGC versions like
Colossus 237, Comanche 55, and Luminary 99; that kind of
cross-checkout would have been greatly hampered without
the changes. Moreover, if we manage to get Don
Eyle's Luminary 131 listing (<a href="volunteer.html">which
we
don't yet have a sponsor for</a>, by the way), the
checking that that scan would enable would also have
been hampered. However, even without such
motivations, the overall effect of the changes is still
to make the Colossus 249 and Luminary 131 material
better and more accessible.</li>
<li>I guess I've forgotten to mention <i>any</i> of the
newspaper, magazine, or online articles in 2016 in which
our Virtual AGC project played an important role.
Of course, I don't necessarily know about all of them,
since I don't spend a lot of time scouring the web for
news about the project or about myself. The
best-known is probably the article titled <a
href="https://qz.com/726338/the-code-that-took-america-to-the-moon-was-just-published-to-github-and-its-like-a-1960s-time-capsule/">"BURN,
BABY! BURN! The code that took America to the moon was
just published to GitHub, and it’s like a 1960s time
capsule"</a> at Quartz. That one was fun for me,
because various people stopped me or telephoned me to
say "hey, is that you?" But for my taste, the
article which has just appeared in the current issue of
the U.K.'s <a href="http://www.slow-journalism.com/">Delayed
Gratification magazine</a>, called "Houston, we have a
program", is a lot more fun, for a number of
reasons. Not least is that the article is really
about our Virtual AGC project, rather than being
primarily about Apollo 11 or the AGC software for Apollo
11. But also, I think the article is extremely
well-structured and entertaining, much more so than the
endless, detailed blathering I output by the ton here at
our website, so it's a fun read. I congratulate
the writer, Chris Bourn, for the care he took, and the
results he achieved. You may notice I've provided
no link to the article, though. That's because
Delayed Gratification is a print-only magazine,
supported by subscribers rather than ads. They
only put a handful of sample articles online; perhaps
ours will some day be one of those (I hope!), but
perhaps not. The magazine itself has a very
intriguing concept: it is a proponent of something
called "slow journalism", which is basically a throwback
to the old days when journalists were supposed to do
thorough fact checking, editors were supposed to edit,
and so on, as opposed to today's situation, in which
articles are thrown together as quickly as possible
(probably by cutting-and-pasting unsubstantiated
material), in order to maximize online ad revenue.
In contrast, Delayed Gratification boasts that it is the
<i>last</i> to break a story, rather than the <i>first</i>
to do so. There's also an interesting TED talk about the
concept of slow journalism:</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2017-01-02<br>
</td>
<td valign="top">Colossus 237's source-code's comment text has
now been completely proofed, and <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files#published-proofing-images-and-completed-proofing">its
proofing data published online</a>, should you choose to
do a proofing pass on it yourself.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2016" onchange="viewOrHide(2016)" autocomplete="off"
checked="checked" type="checkbox"><b>Hide 2016 change notes?</b>
<table summary="" id="table2016" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top">2016-12-30<br>
</td>
<td valign="top">
<ul>
<li>I had forgotten over the years that our digitized
Luminary 99 (Apollo 11 LM software) was actually missing
almost an entire page (bottom of p. 1472 and top of p.
1473). Of course, we had immediately
reverse-engineered this when we were transcribing the
source code, and knew that our reconstruction assembled
to the correct octal values, but it would still be nice
to have the "correct" version. Fortunately, Don
Eyles was able to supply snapshots (now on <a
href="Luminary.html">the Luminary page</a>) from his
own printout. Gratifyingly, though not
surprisingly, the reconstruction was 100% accurate,
including the comments. (Actually, there was a
typo in the comments, but ignore that; it was 100%
perfect <i>in principle</i>.)</li>
<li>Don has also supplied another LUMINARY Memo, #138, now
in our document library. It describes the Variable
Servicer then being implemented in ZERLINA.</li>
<li>The <a href="Luminary.html">Luminary</a> and <a
href="Colossus.html">Colossus</a> pages have had a
sort of family-tree diagram for a while, in which the
relationships amongst the various AGC programs were
covered ... but only up to Apollo 11. I've taken
it upon myself to recreate that diagram, and extend it
all the way to the end of Apollo, by which I mean
Apollo-Skylab and Apollo-Soyuz. It's a rather
impressive picture, including even the science-project
ZERLINA program, which was outside the main
developmental flow; though even then, I'm told there
were many other such separate programs, such as
DIANA (about which I have a little info but not
enough to include it in the chart), AMELIA, and so on.</li>
<li>By the way, if you want to know more about ZERLINA,
see <a href="volunteer.html">the volunteering page</a>.
Speaking
of which, I had forgotten to include Don Eyles's copy of
LUMINARY 99 as a sponsorship opportunity, but have now
done so.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-12-29<br>
</td>
<td valign="top">The comment text for Solarium 55 has been
completely proofed <a
href="https://github.com/virtualagc/virtualagc/tree/master/Solarium055">
in the GitHub repository</a>, so <a
href="listings/Solarium055/MAIN.agc.html">its colorized,
syntax-highlighted assembly listing</a> has thus been
updated, and <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files#published-proofing-images-and-completed-proofing">its
proofing data published</a>. It has also been removed from
the volunteering page's list of AGC versions requiring
special attention.<br>
</td>
</tr>
<tr>
<td valign="top">2016-12-28<br>
</td>
<td valign="top">
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The full Retread
44 source code is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Retread44">
now available online</a>, as well as <a
href="listings/Retread44/MAIN.agc.html"> the
colorized, syntax-highlighted form of the
source code</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<br>
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.<br>
<br>
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!<br>
<br>
<a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files#published-proofing-images-and-completed-proofing">The
proofing data for both has been published online</a> as
well, for anybody interested in doing additional proofing
passes on them.<br>
<br>
The volunteering page has also been drastically reworked, as
I realized that most the procedures and instructions given
there were drastically out of date.<br>
</td>
</tr>
<tr>
<td valign="top">2016-12-24<br>
</td>
<td valign="top" align="center"> <br>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Luminary 116
(Apollo 12 LM) executable rope is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary116/Luminary116.binsource">now
available online</a></b></font><br>
</td>
</tr>
</tbody>
</table>
<br>
<div align="left"> though, as almost-always for such initial
announcements of rope availability, what this means is
that:<br>
<ul>
<li>The rope-contents have been transcribed, proof-read,
and the bank checksums are correct, but there is an
outside chance that errors can still be found after
the Luminary 116 source code has been fully
transcribed and assembled with yaYUL.</li>
<li>It can be turned into executable form (using the
oct2bin utility) and presumably run in the AGC
simulator (yaAGC) from a command line.</li>
<li>It is not yet integrated into the VirtualAGC GUI
program.</li>
<li>Moreover, <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files#published-proofing-images-and-completed-proofing">visual-proofing
imagery is available</a> for anybody who wants to
(relatively) easily verify the rope for themselves.<br>
</li>
</ul>
</div>
</td>
</tr>
<tr>
<td valign="top">2016-12-23<br>
</td>
<td valign="top">
<ul>
<li>The program-comment text (but not white space) of
Comanche 55 (Apollo 11 CM AGC program) has now been
fully-proofed and corrected in GitHub, and its proofing
data has been <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files">posted
online</a>, though undoubtedly errors remain.
Since the same has already happened with Luminary 99, as
mentioned a few days ago, the complete set of Apollo 11
AGC code has now had its comment text corrected.
This is already paying off, as the corrected comments in
Aurora 12 and Luminary 99 are migrating into the
transcriptions of Retread 44 and Luminary 69 now taking
place. Good riddance, errors!<br>
</li>
<li>Perhaps more excitingly,<br>
</li>
</ul>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Luminary 116
(Apollo 12 LM software) </b></font> <font
color="red"><b>assembly listing page scans are <a
href="ScansForConversion/Luminary116/"> now
available online (smaller images, lower
quality)</a>, as well as <a
href="https://archive.org/details/luminary11600nasa"><font
color="#3333FF"> at archive.org (much larger
images, higher quality)</font></a>.</b></font></td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td valign="top">2016-12-20<br>
</td>
<td valign="top">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. <a
href="https://github.com/virtualagc/virtualagc/wiki/Verifying-Correctness-of-Comment-Text-in-AGC-Source-Code-Files">The
promised wiki article describing the usage of this data
has now also been written</a>. That article provides
specific links to all of the available proofing-data sets.<br>
</td>
</tr>
<tr>
<td valign="top">2016-12-18<br>
</td>
<td valign="top">
<ul>
<li>The program-comment text (but not white space) of
Luminary 99 (Apollo 11 LM AGC program) has now been
fully-proofed and corrected in GitHub, though
undoubtedly errors remain. (Recall the update of a
few days ago that Aurora 12 and Sunburst 120 had already
undergone this correction process.) Because so
many changes are involved, the proofing data (for
Luminary 99, but not yet for Aurora 12 and Sunburst 120)
has also been <a
href="Downloads/Luminary099-CommentProofingData.zip">posted</a>
(note that it's a 115MB download), for anybody
interested in the proofing process, or perhaps
performing additional proofing passes. There will
be an upcoming article on our GitHub wiki regarding
this.<br>
</li>
<li>The colorized, syntax-highlighted version the Luminary
99, Aurora 12, and Sunburst 120 programs presented here
on our <a href="Luminary.html">Luminary page</a> have
been updated with respect to the comment-text
corrections mentioned above.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-12-16<br>
</td>
<td valign="top">
<ul>
<li>The Retread 44 executable is now available in the
GitHub repository (namely, Retread44.binsource, which
needs to be "compiled" with the command "oct2bin
--no-checkums <Retread44.binsource" to actually get
the executable rope image), and in theory can be run in
the AGC simulator. However, Retread 44 precedes
the use of embedded checksums, and hence we cannot <i>yet</i>
be as certain about the correctness as we normally would
be at this point in the process, so I won't dignify this
announcement by putting it in a fancy box.
Transcription of Retread 44 into source code is only in
the early stages.<br>
</li>
<li>Perhaps more excitingly,</li>
</ul>
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The full
Luminary 210 (Apollo 15-17 LM) source code is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary210">
now available online</a>, as well as <a
href="listings/Luminary210/MAIN.agc.html">the
colorized, syntax-highlighted form of the
source code</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<p>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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2016-12-13<br>
</td>
<td valign="top">
<ul>
<li>Don Eyles has sent 4 interesting new documents,
which at the moment are conveniently grouped together <a
href="links.html#Eyles20161212">in our document
library</a>, as well as at the appropriate places on
the Luminary page. 3 are memos describing some
software changes incorporated in Luminary 69 (Apollo 10)
and 131 (Apollo 13). I particularly recommend the
4th, the exegesis of the Apollo 11 1201 and 1202 alarms
... not just for concise coverage of that issue, but for
an extraordinarily clear and easy-to-understand
explanation of the AGC software's multi-tasking
functionality.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-12-12<br>
</td>
<td valign="top" align="center">
<div align="left">
<ul>
<li>While in the past (and continuing into the future!),
we've taken great pains to insure that the functional
source code and executable versions of the AGC program
versions we present here are 100% accurate, we've had
no tools at our disposal and much less luck at
insuring that the <i>comments</i> in these programs
are accurate transcriptions from the original.
This situation has changed somewhat, and we do in fact
have a proofing tool at our disposal now that makes
proofing the program comments both much more efficient
and much more reliable, for those program versions to
which it can be applied. I will write much more
about this in the future, but for right now I'll
merely note that SUNBURST 120 (Apollo 5) and AURORA
have already been through this process, with around
1000 errors fixed in AURORA and around 3000 fixed in
SUNBURST. COMANCHE 55 (Apollo 11 CM) is about
halfway through this process (according to GitHub
logs), and while I've lost count at the moment, I
think the errors fixed in its comments already top
5000. It should be noted that these fixes affect
only the <i>text</i>, without regard to the columnar
alignment (which will hopefully be addressed in the
future). Most of these fixes are trivial
matters, such as the presence or absence of a '.', so
the huge numbers of fixes aren't necessarily alarming
as it seems superficially. The goal is for the
program comments in our source-code files to exactly
match the original assembly listings, right down to
misspellings and typos. These improvements are
currently available in GitHub, and will continue to
become available as the process progresses.</li>
<li>Also, as of today:</li>
</ul>
</div>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Retread
44 </b></font> <font color="red"><b>assembly
listing
page scans are <a
href="ScansForConversion/Retread44/"> now
available online (smaller images, lower
quality)</a>, as well as <a
href="https://archive.org/details/blkiiretreadprog00sher"><font
color="#3333FF">at archive.org (much larger
images, higher quality)</font></a>.</b></font></td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td valign="top">2016-11-29<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-11-26<br>
</td>
<td valign="top" align="center">
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Luminary 069
(Apollo 10 LM) executable rope is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary069">
now available online</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<br>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Luminary 210
(Apollo 15-17 LM) executable rope is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Luminary210">
now available online</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<br>
<div align="left"> (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.)<br>
</div>
</td>
</tr>
<tr>
<td valign="top">2016-11-23<br>
</td>
<td valign="top">
<ul>
<li>The <a href="Luminary.html">Luminary</a> and <a
href="Colossus.html">Colossus</a> pages now have a
marvelous table (taken from document R-700, vol. 3)
giving lots and lots of versioning information about
various AGC programs, which I had previously just been
inferring from textual descriptions in other
documents. Unfortunately, it basically only covers
the timespan of Apollo 5-14, but that's not bad!<br>
</li>
<li>Refer to the notes on <a href="Luminary.html">the
Luminary page</a> for an explanation of the "almost!"
in the announcement below:<br>
</li>
</ul>
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The scans of the
Luminary 069 (Apollo 10 LM ... almost!) assembly
listing are <a
href="ScansForConversion/Luminary069/"> now
available online (smaller images, lower
quality)</a>, as well as <a
href="https://archive.org/details/luminary6900miti"><font
color="#3333FF"> at archive.org (much larger
images, higher quality)</font></a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<ul>
<li>All of the Virtual AGC build-from-source methods on <a
href="download.html">the downloads page</a> (except
the Mac OS X platform, whose instructions aren't
entirely working yet) now create a launcher icon for
Virtual AGC on the Desktop.</li>
<li>In the <a href="links.html">Document Library</a>, a
couple of volumes of R-700, MIT's Role in Project
Apollo, have been added: A 2nd copy of volume 3
(the one we already had being somewhat distorted by the
OCR process, and the 2nd undistorted but somewhat
lighter and lower-contrast), and volume 2, concerning
optical and other subsystems.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-11-22<br>
</td>
<td valign="top">
<ul>
<li>For Luminary 210 (Apollo 15-17) AGC assembly-listing
scanned imagery:</li>
<ul>
<li><a href="ScansForConversion/Luminary210/1149.jpg">
Page 1149 of the reduced-resolution color imagery</a>,
which had a fold that made one of the lines hard to
read, has now been replaced.</li>
<li>A reprocessed form (<a
href="ScansForConversion/Luminary210-BW/">high-contrast
B&W
images at a slightly higher resolution</a>) has been
added. In almost all cases, these images are far
more legible and easier to read, which I hope will
assist the volunteers now transcribing Luminary 210
into source-code form ... they certainly are much
easier for <i>me</i>. Thanks to Mike Stewart
for creating these.</li>
</ul>
<li>There are now workable Solaris build-instructions on
the download page.</li>
<li>Build-instructions for some platforms (Linux, FreeBSD)
now build a desktop icon for Virtual AGC, which makes it
easier to run once it's built.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-11-20<br>
</td>
<td valign="top">
<ul>
<li>On the <a href="Colossus.html">Colossus page</a>, I
made some corrections to the info about the GSOP for the
Skylark program (Apollo-Skylab and Apollo-Soyuz
CM). Specifically, I realized that sections 1 and
2 from the Colossus 3 (Apollo 15-17) GSOP were simply
republished unchanged as part of the Skylark GSOP, and
thus we actually have 3 of the 7 sections of the Skylark
GSOP, rather than just 2 of the sections as I had
previously believed.</li>
<li><a href="download.html#FreeBSD">The instructions for
building Virtual AGC on FreeBSD</a> now work, with the
latest software updates in GitHub.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-11-19<br>
</td>
<td valign="top">
<ul>
<li>The principal Virtual AGC download method, for anybody
who doesn't want to build it from source, and is using
'x86 Linux, Windows, Mac OS X, FreeBSD, or Solaris, is
now a VirtualBox based Virtual Machine that you can <a
href="download.html">download from the downloads page</a>.
The
VM is tailored for running the simulations and doing
visual debugging of AGC code. Though a large
download, this is a very easy way to run Virtual AGC.<br>
</li>
<li>I have been going through the installation/build
instructions on <a href="download.html">the download
page</a>, and updating them, since many of them are
nearly a decade out-of-date. The old instructions
are still preserved as a link to a separate page.
However, the executive summary is that as of right now,
it's really, really hard to build Virtual AGC on Mac OS
X, Solaris, and FreeBSD, and in fact we no longer know
how to do it. (But Windows and Linux are still okay,
though for Windows you do need all of the latest fixes
in the <a
href="https://github.com/virtualagc/virtualagc">GitHub
repository</a> for it to work!)<br>
</li>
<li>As a result of the two items above, the download page
has essentially been completely rewritten, from
beginning to end.</li>
<li>Finally, most-importantly,<br>
</li>
</ul>
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The scans of the
Luminary 210 (Apollo 15-17 LM) assembly listing
are <a href="ScansForConversion/Luminary210/">
now available online (smaller images, lower
quality)</a>, as well as <a
href="https://archive.org/details/luminary21000miti"><font
color="#3333FF"> at archive.org (much larger
images, higher quality)</font></a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td valign="top">2016-11-08<br>
</td>
<td valign="top">
<ul>
<li>In the GitHub repository, the "block1" branch, in
which the Block I AGC and DSKY simulators were being
developed, has been merged into the master branch, and
therefore is now obsolete.</li>
<li>Also in GitHub, the VirtualAGC GUI has been updated,
and is now able to run Solarium 55, Aurora 12, and
Sunburst 120 simulations, rather than forcing you to run
them from the command line. The Solarium 55
simulation is Block I, and therefore uses the Block I
AGC simulator and DSKY simulator (in either its
control-panel or nav-bay versions).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-11-03<br>
</td>
<td valign="top">
<ul>
<li>The AGC source-code (and associated syntax-highlighted
assembly listings) have been refined so that "modern"
program comments are prefixed with "##", while the
original program comments continue to be prefixed merely
by "#". Thus, it is easier to tell at a glance
which comments are original and which are not ...
barring errors on our part, of course!</li>
<li>The assembler (yaYUL) source code at GitHub has had
various bugs fixed which weren't apparent until Sunburst
120 source code was assembled.</li>
<li>And most importantly:</li>
</ul>
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The full
Sunburst 120 (Apollo 5) source code is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Sunburst120">
now available online</a>, as well as <a
href="listings/Sunburst120/MAIN.agc.html">the
colorized, syntax-highlighted form of the
source code</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<p>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.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">2016-10-23<br>
</td>
<td valign="top">
<ul>
<li>Many of the colorized, syntax-highlighted AGC program
listings have been massaged a bit so that their
page-number markings (formerly just program comments)
now stand out a bit more. Hopefully this has had
no side-effects.</li>
<li>The AGC assembler, yaYUL, has now been updated for
AURORA 12's "BLK2" software architecture. (The
yaYUL documentation had previously been updated, but not
the program itself.)<br>
</li>
<li>Finally, and most-importantly,</li>
</ul>
<div align="center">
<table summary="" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The full
Aurora 12 source code is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Aurora12">
now available online</a>, as well as <a
href="listings/Aurora12/MAIN.agc.html">the
colorized, syntax-highlighted form of the
source code</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<div align="left"> <br>
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.<br>
</div>
</div>
</td>
</tr>
<tr>
<td valign="top">2016-10-20<br>
</td>
<td valign="top">
<center>
<ul>
<li>
<div align="left"> Some recent administrative changes
at our GitHub repo have broken the old website name
"https://rburkey2005.github.io/virtualagc", which
has instead become <a
href="https://virtualagc.github.io/virtualagc">https://virtualagc.github.io/virtualagc</a>.
I've
fixed the now-broken links. </div>
</li>
<li>
<div align="left"> More importantly, </div>
</li>
</ul>
<table summary="" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Aurora 12
executable rope is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Aurora12">
now available online</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<table summary="" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The Sunburst
120 executable rope is <a
href="https://github.com/virtualagc/virtualagc/tree/master/Sunburst120">
now available online</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<div align="left"> <br>
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. </div>
</center>
</td>
</tr>
<tr>
<td valign="top">2016-10-13<br>
</td>
<td valign="top">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
that?<br>
</td>
</tr>
<tr>
<td valign="top">2016-10-09<br>
</td>
<td valign="top">
<ul>
<li>The <a href="yaYUL.html#Invoking_yaYUL">documentation
of yaYUL invocation</a> has been updated to cover the
--blk2, --format, and --syntax command-line switches, as
well as to explain the differences between the AGC
systems targeted by the assembler, namely the AGC4,
BLK2, and AGC targets.</li>
<li>The <a href="SourceAnnotations.html">page describing
HTML annotations to syntax-highlighted AGC code
listings</a> (created using the yaYUL --format switch)
has been modified to describe certain exceptions to the
way --format processes AGC source-code lines beginning
with "##" in column 1, and to recommend that all <i>modern</i>
comments added to AGC source code (as opposed to
comments present in the original source code) should
begin with "##" rather than "#".<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-10-06<br>
</td>
<td valign="top">On <a href="yaYUL.html#What_is_YUL">the
yaYUL page, in the discussion about the original YUL
program</a>, 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
that.<br>
</td>
</tr>
<tr>
<td valign="top">2016-10-05<br>
</td>
<td valign="top">The various syntax-highlighted, hyperlinked
AGC program listings (<a
href="listings/Artemis072/MAIN.agc.html">Artemis072</a>, <a
href="listings/Comanche055/MAIN.agc.html">Comanche055</a>,
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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-10-02<br>
</td>
<td valign="top">
<ul>
<li>As mentioned a few days ago, we have the complete rope
contents for AURORA 12 in a form that can be executed on
the yaAGC simulator, though the source-code
transcriptions are not yet complete. You may
recall that AURORA 12 is special, because it is that <i>last</i>
AGC code to contain a complete test suite. Mike
Stewart has been using this to ring out lingering bugs
in yaAGC (as well as in <a
href="Pultorak.html#Mike_Stewarts_Block_II_AGC_Project">his
own
hardware-based AGC simulator</a>), and has indeed
found some problems with boundary cases in the <tt>DV</tt>
instruction, and perhaps some not-so-boudary-case
problems elsewhere (such as the lack of a hardware
"night watchman" mechanism), and has fixed them all in
yaYUL. Thanks also to Niklas Beug for faithfully
testing these in NASSP, to insure that they don't cause
problems there, or perhaps make stuff better that seemed
to be working before. Thus, yaYUL (and I think,
Mike's sim) now pass the AURORA test suite. (Of
course, there are aspects of the test suite that aren't
CPU-specific, I believe, such as IMU tests, and I don't
claim that those pass.) At any rate, Mike has also
updated the <a href="assembly_language_manual.html">description
of
Block II assembly language</a> to describe the various
boundary-case behaviors of the instruction set.</li>
<li>I've added a "bonus offer" to <a
href="volunteer.html">the sponsorship request</a> I
mentioned yesterday.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-10-01<br>
</td>
<td valign="top">The main page now begins with a special help
offer — i.e., an offer for a way <i>you</i> can help <i>us</i>,
and that's about as special as things can get! — which is
explained fully <a href="volunteer.html">on the
volunteering page</a>.<br>
</td>
</tr>
<tr>
<td valign="top">2016-09-29<br>
</td>
<td valign="top"><a
href="assembly_language_manual.html#SECSIZ">An
experimental pseudo-op, SECSIZ,</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-09-28<br>
</td>
<td valign="top">
<ul>
<li>Lately I've been keeping all website changes at <a
href="https://virtualagc.github.io/virtualagc/">the
GitHub version of the website</a>, and not pushing
them to <a href="http://www.ibiblio.org/apollo">the
(main) ibiblio version of the website</a>, because
ibiblio overrides the character-set encoding; thus, some
of the characters (like '—', 'μ', '±', etc.) were messed
up on the ibiblio version but not on the GitHub version.
I finally figured out how to override ibiblio's
override, so I should be able to start pushing changes
to ibiblio.org/apollo again.</li>
<li>I've added a short section to <a
href="LVDC.html#Interaction_with_the_AGC">the LVDC
page</a> describing the interaction of the AGC with
the Saturn rocket. The highlight is a nice video
created by Riley Rainey which you might enjoy watching.</li>
<li>The hopefully fully-correct Aurora 12 rope is now
available at our GitHub repo, though the transcribed
source code for Aurora isn't yet available, so at least
theoretically you can run Aurora in the AGC
simulator. However, that would have to be done
from yaAGC's command line, since Aurora 12 capability
has not yet been integrated into the VirtualAGC GUI
program.</li>
<li>Niklas Beug has been developing a new feature for us,
which is found in <a
href="https://github.com/rburkey2005/virtualagc/tree/scenarios">
the "scenarios" branch of our GitHub repository</a>.
What
these scenarios are "core dumps" — exact copies of the
AGC's "erasable memory" — with the appropriate pad loads
and setups for running simulations of various mission
scenarios. These core dumps are accompanied by nice
writeups of what they are and how to use them. By
loading the core dump into the AGC simulator, you're all
set to go with the corresponding scenario! At the
moment, there are only 4 scenarios, namely the Apollo 9,
11, and 15 launch scenarios and the Apollo 7 rendezvous
scenario (and yes, that's a real thing!), but presumably
the number will grow. Eventually, this feature
will be integrated into the VirtualAGC GUI program, but
for now it's command-line only. Also, the setups
come from NASSP, so you may find it more fulfilling to
use them with NASSP then with "pure" Virtual AGC.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-09-27<br>
</td>
<td valign="top">
<ul>
<li>Continued fleshing-out of <a href="Block1.html">the
Block 1 page</a>, especially the instruction set,
though there is some improved imagery as well.<br>
</li>
<li>More importantly: The two missing page scans
(622 and 623) from Aurora 12 are now available, and
Aurora 12 is "up" again on archive.org.</li>
<li>Still more importantly:<br>
</li>
</ul>
<center>
<table summary="" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>Sunburst 120
(Apollo 5 AGC program) page images are <a
href="ScansForConversion/Sunburst120/"> now
online</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
</center>
<br>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-09-25<br>
</td>
<td valign="top">
<ul>
<li>Niklas Beug has sent us a link to a YouTube video of a
NASSP/Orbiter (which integrates Virtual AGC) simulated
Apollo 11 lunar landing, which I couldn't resist putting
an embedded link to on <a href="index.html">the main
page</a>. There's also a matching lunar ascent
video on his YouTube channel (look for Indianajones91),
though I didn't link it explicitly.</li>
<li>I've been asked where the Aurora 12 scans that are
supposed to be at archive.org are? They had to be
taken down temporarily (although "temporarily" has
stretched into a week, and hasn't ended yet) to add a
couple of missing pages and to reshoot a few pages which
are out of focus. Sorry about that, but it's out
of my hands! They'll return presently, I'm sure.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-09-23<br>
</td>
<td valign="top">
<ul>
<li>Updated Mike Stewart's analysis of the missing modules
in Block 2 schematics slightly.</li>
<li>Began adding detailed description of the instruction
set to the Block 2 page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-09-22<br>
</td>
<td valign="top"> Some big news for today is that<br>
<br>
<div align="center">
<table summary="" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>The
long-awaited <a href="yaYUL.html#What_is_YUL">scans
of
the</a></b> <a
href="yaYUL.html#What_is_YUL"><b><i>original</i></b></a><b><a
href="yaYUL.html#What_is_YUL">YUL assembler</a>
have finally arrived!</b></font></td>
</tr>
</tbody>
</table>
<br>
</div>
At least, they were long-awaited for <i>me</i>, because
until today I saw them for the first and last time almost 12
years ago to the day, and that's why there's no hair left on
my head. (That's my theory, anyway.)<br>
<br>
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 <a
href="links.html">our document library</a>. The
highlights of the additions are:<br>
<ul>
<li><a href="links.html#AGC_electrical_schematics">Block
II AGC schematics</a>.</li>
<li><a href="links.html#AGC_electrical_schematics">LM
interface-control data</a> (interface wiring and
related data) from Grumman.<br>
</li>
<li><a href="links.html#AGC-related_presentations">Videos
and/or texts of talks</a> by AGC developers Hugh
Blair-Smith, Ray Alonso, and Eldon Hall (as well as
Frank O'Brien, Cline Frasier, and Jose Portillo Lugo) at
the MAPLD '04 conference.</li>
<li>Various new documents or cleaner versions of ones we
already have, most-notably perhaps, an Apollo 16 Delco
manual to supplement the existing A15 Delco manual, and
a clean replacement for the mutilated-but-indispensable
(if you're doing Block I work) R-393.<br>
</li>
</ul>
<p>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:</p>
<blockquote>
<div> <a
href="https://github.com/thewonderidiot/agc_hardware">https://github.com/thewonderidiot/agc_hardware</a><br>
</div>
<div> <a
href="https://github.com/thewonderidiot/agc_simulation">https://github.com/thewonderidiot/agc_simulation</a></div>
</blockquote>
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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-09-21<br>
</td>
<td valign="top">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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-09-20<br>
</td>
<td valign="top" align="center">
<div align="left">
<ul>
<li>Ongoing work at our <a
href="https://github.com/rburkey2005/virtualagc">GitHub
repository:</a></li>
<ul>
<li>Onno Hommes continues to improve GUI debugging of
Block 2 AGC software.</li>
<li>Mike Stewart continues to extinguish lingering
bugs in the Block 2 AGC simulator. As you may
know, the NASSP add-on for the Orbiter spacecraft
simulator has incorporated our AGC simulator for
many years. Until the last year or so, they have
been using it just for the Command Module
(apparently without difficulties), but have lately
begun trying to do lunar landings with it and have
been prevented due to the alarms and other problems
caused by the AGC simulator. However, with the
latest fixes, I'm told that they are indeed able to
accomplish a lunar landing without alarms.
Great job, Mike and the NASSP folks (thanks, Niklas
Beug) who have been working on this!</li>
<li>The Block 1 AGC and DSKY simulators, running
Solarium 055, are now essentially working ... which
I mentioned in the last update, but I've been fixing
some fundamental problems with it in the meantime,
so I'm a bit more confident in my statements.</li>
</ul>
<li>And the bigger news:</li>
</ul>
</div>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><font color="red"><b>Aurora 12 page
images are <a
href="ScansForConversion/Aurora12/"> now
online</a>.</b></font><br>
</td>
</tr>
</tbody>
</table>
<div align="left"> <br>
Aurora <i>what</i>? 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. <a href="Luminary.html#AuroraNutshell">Read
more about it on our Luminary page</a>. Or contact
us directly if you would like to help out in the process
of converting Aurora page images to source code!<br>
</div>
</td>
</tr>
<tr>
<td valign="top">2016-09-15<br>
</td>
<td valign="top">
<ul>
<li><a href="BlockIII.html">Hugh Blair-Smith's notes on
"Block III"</a> have been updated once again, this
time with an improved interpreter.</li>
<li><a href="Block1.html">The Block I page</a> has been
considerably expanded, because of the next item.<br>
</li>
<li>The Block I CPU simulator, DSKY simulator, and digital
uplink simulator are new working, in a provisional
sense. What that means is that while you have to
download the source code from <a
href="https://github.com/rburkey2005/virtualagc/tree/block1">
the "block1" branch of our GitHub repository</a>
yourself, that you have to compile the code yourself,
that you have to run it from the command line (as
opposed to from the fancy VirtualAGC GUI), and that the
CPU simulator still has many bugs, and that only one of
the two different DSKY configurations has been simulated
so far, <i>nevetheless</i>, you can in fact run
Solarium 055 on the simulated CPU and interact with it
via the simulated DSKY, or through the simulated digital
uplink, using with some of the sample verbs and nouns
shown in <a
href="Block1.html#Taking_Solarium_for_a_Spin">a new
section on the Block I page</a>. Whew!
Now, <i>that</i> was a sentence that took my breath
away!</li>
<li>A document supporting Block 1, <a
href="Documents/E-1574.pdf">E-1574</a>, which I had
somehow missed before, has been added to the document
library.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-09-02<br>
</td>
<td valign="top">
<ul>
<li><a href="BlockIII.html">Hugh Blair-Smith's notes on
"Block III"</a> have been considerably fleshed-out and
updated.</li>
<li><a
href="Block1.html#John_Pultoraks_Assembler_and_Simulator">Our
port
of John Pultorak's Block I simulator</a> has been
considerably improved <a
href="https://github.com/rburkey2005/virtualagc/tree/block1/yaAGC-Block1-Pultorak">in
our GitHub repository</a>, in particular the ability
to load the Solarium 055 rope and simulate it, and our
description of how to use it has been updated to reflect
that. It is, however, far from perfect.</li>
<li>A copy of LVDC source code is now known, though our
prospect for getting our hands on it seems bleak.
<a
href="LVDC.html#LVDC_Source_Code_Does_Exist_Even_Though">Read
the
description of it</a> to see if you can help us out in
getting it!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-09-01<br>
</td>
<td valign="top">
<ul>
<li>I've been doing a lot of reworking of the descriptive
material on the Block 1 AGC and DSKY. <a
href="Block1.html">The page formerly intended to be
cover Block 1 assembly language</a> has now been
reorganized as a page for "all things Block 1". I
think this is important now that there is valid Block 1
code (Solarium), a Block 1 assembler, prospects
for eventually obtaining the Block 1 Corona core rope,
and so on, and so have been moving Block 1 material from
other pages (like the yaYUL page) onto the Block 1
page. There is much more to come along those lines
in future days.<br>
</li>
<li><a
href="https://github.com/rburkey2005/virtualagc/tree/block1/yaAGC-Block1-Pultorak">There
is now a Block 1 simulator at our GitHub repository</a>,
based on John Pultorak's design, and there's a lot more
discussion of that on the <a href="Block1.html">Block 1
page</a> and the <a href="Pultorak.html">Physical
Implementations page</a> than previously. I
don't claim that it works very well for the purpose of
supplementing the Block 2 simulation at the present
time, but it's something as opposed to nothing ... which
is something.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-26<br>
</td>
<td valign="top">
<ul>
<li>At least for a temporary trial, our web-pages at <a
href="http://www.ibiblio.org/apollo">ibiblio.org</a>
are mirrored to <a
href="https://virtualagc.github.io/virtualagc">github</a>.
There's
more explanation at the top of <a href="faq.html">the
FAQ page</a>, if you're interested.</li>
<li>Fixed a number of broken hyperlinks and incorrect
character encodings on the web-pages.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-24<br>
</td>
<td valign="top"> Well, this has been an interesting
day. I expected to have one significant announcement
today, and instead have two of them. First,<br>
<br>
<div align="center">
<table summary="" style="text-align: left; width: 80%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span
style="font-weight: bold; color: rgb(204, 0,
0);">The Apollo 6 CM AGC Block 1 code is now
fully available in <a
href="https://github.com/rburkey2005/virtualagc/tree/master/Solarium055">
source</a> and <a
href="https://github.com/rburkey2005/virtualagc/blob/master/Solarium055/Solarium055.binsource">binary</a>
form, as well as <a
href="listings/Solarium055/MAIN.agc.html">syntax-highlighted,
colorized
form</a>, and <a href="yaYUL.html">the
assembler (yaYUL)</a> has been updated to
assemble Block 1 source code.</span><br>
</td>
</tr>
</tbody>
</table>
</div>
<br>
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".<br>
<br>
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 <i>not</i>
from Apollo 6 (<b>Solarium 055</b>) as I said, but rather is
the <b>Corona</b> 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 <b>Corona</b> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-08-23<br>
</td>
<td valign="top">
<ul>
<li>A YouTube link to Francois Rautenbach's video of
himself extracting the rope memory contents from the
actual, physical Apollo 6 AGC (namely the binary for the
program Solarium 055) has been added to <a
href="Colossus.html#Known_Software_Versions">on our
Colossus page</a>, under the Solarium 055 entry,
naturally. Of course, as I mentioned a couple of
days ago, the full binary (derived from the assembly
listing rather than from the physical ropes) is <a
href="https://github.com/rburkey2005/virtualagc/blob/master/Solarium055/Solarium055.binsource">available
at our GitHub repository</a>. It would be
interesting to compare the contents of the two sometime,
and if that happens, I'll let you know the results.</li>
<li>Began adding a <a href="Block1.html">Block 1 language
manual</a>, to complement <a
href="assembly_language_manual.html">the existing
Block 2 language manual</a>. It's not very
useful as of yet.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-22<br>
</td>
<td valign="top">
<ul>
<li>The <a href="assembly_language_manual.html">assembly
language manual</a> description of the CPU's L
register has been changed slightly to reflect an updated
understanding of its behavior, and the changes in the
yaAGC simulated CPU's treatment of it which have lately
been committed to our GitHub repository. (Thanks
to Mike Stewart.)<br>
</li>
<li>Because the tables of existing AGC software we have on
the <a href="Colossus.html">Colossus</a> and <a
href="Luminary.html">Luminary</a> pages have grown so
huge and unwieldy, listing everything I've ever found
out about every software version, I've added a very
short summary table in front of each of them, listing
simply the software versions we have in our possession
right now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-19<br>
</td>
<td valign="top">The discussion of CPU utilization in <a
href="download.html#BuildRPI">the Raspberry Pi build
instructions</a> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-08-18<br>
</td>
<td valign="top">A number of goofy hyperlinks fixed.<br>
</td>
</tr>
<tr>
<td valign="top">2016-08-17<br>
</td>
<td valign="top">
<ul>
<li><a href="hrst/archive/967.pdf">Found a reference</a>
which actually lists most of the software version codes
up to Apollo 11 inclusive, and therefore made minor
changes to the corresponding missions on the Luminary
and Colossus pages. Most-significantly, it said
that Solarium 055 was for Apollo 6 and Solarium 054 was
for Apollo 4, which means that I have been in error for
the last 7 years in saying that Solarium 055 was for
Apollo 4. This has entailed numerous website
changes (I don't guarantee I've caught all of them yet),
as well as in the source code for Solarium 055 on GitHub
(and again, I don't guarantee I got them all).<br>
</li>
<li>Status of Solarium055: The Solarium055 was
originally made available as page images in 2009, then
as source-code files and independently-generated binary
files in 2010. However, proofing of the
source-code files and of the binary were never completed
at that time, though the binary was proofed to the
extent that all checksums ("bugger words") were
correct. As of today, <a
href="https://github.com/rburkey2005/virtualagc/blob/master/Solarium055/Solarium055.binsource">a
completely-proofed binary, Solarium055.binsource, is
in the GitHub repository</a>; it is actually identical
to the 2010 binary, in the sense no octal values needed
to be corrected, but can now be regarded as
"correct". The next step is to add the capability
of assembling Block I assembly-language source-code to <b>yaYUL</b>,
but that has barely been started.</li>
<li>Descriptive material about the interpretation of
card-column #1 in the original AGC assembly language,
and the facilities provided by <b>YUL</b> or <b>GAP</b>
for formatting the assembly listing, <a
href="assembly_language_manual.html#ButBlankLines">have
been
supplied by Hugh Blair-Smith</a>.</li>
<li>This change log now has the ability to hide or view
the notes from any given year. The default is to
view the current year, but hide all the others.
Opening or closing them is a javascript feature, so I
guess if you don't have javascript enabled, you're out
of luck viewing previous years. On the other hand,
both this feature and the Google Search bar updated
yesterday are both completely self-contained (i.e., they
don't load additional files of javascript), so it's a
pretty safe feature!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-16<br>
</td>
<td valign="top">
<ul>
<li>A somewhat-whimsical description of the AGC software
naming convention that was apparently edited out of Hugh
Blair-Smith's book has been added to the "<a
href="ForDummies.html">kindler, simpler introduction</a>".</li>
<li>Added a description of the AURORA software to t<a
href="Luminary.html">he Luminary page</a>, because I'm
starting to become optimistic that we might be able to
actually get a copy of it, perhaps even in the near
future. But don't hold your breath.</li>
<li>Apparently, the custom search bar hasn't been working,
perhaps in a long time! Well, it does now, at
least in Chrome and SeaMonkey.</li>
<li>Updated more out-of-date Google Code links to GitHub
links.</li>
<li>Fixed various out-of-date projects for which help was
requested on the volunteering page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-15<br>
</td>
<td valign="top">
<ul>
<li>Apparently, links to Dean Koska's demo of VirtualAGC
on a Palm Pilot had become stale and no longer
worked. Now fixed.</li>
<li>Numerous spelling corrections have been made on <a
href="ForDummies.html">the "kindler, simpler
introduction" page</a>.<br>
</li>
<li>Hugh Blair-Smith, one of the original AGC developers,
has sent along some very unusual material, namely <a
href="BlockIII.html">thoughts he had worked up for a
"Block III" AGC</a>.</li>
<li>Added a link on the FAQ page to <a
href="http://svtsim.com/moonjs/agc.html">Shariar
Iravanian's javascript-based online AGC+DSKY+IMU
simulator</a>.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-14<br>
</td>
<td valign="top">
<table summary="" style="text-align: left; width: 80%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span
style="font-weight: bold; color: rgb(204, 0, 0);">The
Apollo
8 CM AGC code is now fully available in source and
binary form, is provided by the development
snapshot and installer programs, and can be run in
the simulation using the VirtualAGC GUI.</span><br>
</td>
</tr>
</tbody>
</table>
<ul>
<li>(The Apollo 8 CM source code (Colossus 237) has been
available on this site for a number of years, but only
as page images, and was never fully proofed and
corrected prior to now.) <br>
</li>
<li>Bruno Muller has constructed a physical DSKY for
yaAGC/NASSP, and I've added a link <a
href="Pultorak.html#Bruno_Muller">on the Physical
Implementations page</a> to the charming YouTube video
he made of it.</li>
</ul>
</td>
</tr>
<tr>
<td valign="top">2016-08-13<br>
</td>
<td valign="top">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!<br>
</td>
</tr>
<tr>
<td valign="top">2016-08-07<br>
</td>
<td valign="top">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 <i>also</i> 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.<br>
</td>
</tr>
<tr>
<td valign="top">2016-07-31<br>
</td>
<td valign="top"> 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 <i>can</i>
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:<br>
<ul>
<li>Updates to the Gemini page which I made back in 2012
and never got around to posting. Unfortunately, I
no longer know quite how to summarize what those changes
were.</li>
<li>On the download page, the Google Code source-code
repository, which no longer exists except in archival
form, has been replaced by our current GitHub
repository.</li>
<li>On the FAQ page, Hugh Blair-Smith's book, <i>Left
Brains for the Right Stuff</i>, now gets the
well-deserved recommendation it <i>should</i> have had
when Hugh brought the book to my attention before
Christmas last year. Sorry, Hugh!</li>
<li>There's also mention there now of Chris Garry's GitHub
repository, which has been getting a lot of attention
lately.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
<input checked="checked" disabled="disabled" autocomplete="off"
type="checkbox"><b>Hide 2015 change notes? (There aren't any!)</b><br>
<input checked="checked" disabled="disabled" autocomplete="off"
type="checkbox"><b>Hide 2014 change notes? (There aren't any!)</b><br>
<input checked="checked" disabled="disabled" autocomplete="off"
type="checkbox"><b>Hide 2013 change notes? (There aren't any!)</b><br>
<input id="box2012" onchange="viewOrHide(2012)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2012 change notes?</b>
<table summary="" id="table2012" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2012-01-08<br>
</td>
<td style="vertical-align: top;"> Gemini:<br>
<ul>
<li>OBC Assembler updated with new features that allow
some otherwise-illegal coding conventions used by the
original programmers to work.<br>
</li>
<li>New 80-page astronaut-training slides added, covering
the OBC, its peripherals, and software, thanks to Dick
Jasinski and Gene Mertz.<br>
</li>
<li>New version of the Detailed Math Flow for Ascent
Guidance added ... still mid-1963, though. Thanks
to Gene and Dave Mertz.<br>
</li>
<li>Updated OBC software personnel roster. Thanks to
Gene Mertz.<br>
</li>
<li>And miscellaneous other stuff I either don't remember
at the moment or don't think are as significant.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2011" onchange="viewOrHide(2011)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2011 change notes?</b>
<table summary="" id="table2011" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2011-12-27<br>
</td>
<td style="vertical-align: top;"> Gemini:<br>
<ul>
<li>Really stupid bugs in the OBC assembler, emulator, and
test code with regard to using the wrong memory sector
as the residual sector have been fixed. Various other
less-major tweaks and fixes as well.<br>
</li>
<li>The explanation of <a
href="Gemini.html#Evolution_of_the_Flight_Software">Gemini
flight-software
versioning</a> has been completely rewritten, on the
basis of <a href="Documents/GeminiSoftwareHistory.pdf">
new information</a> from Dick Jasinski via Gene Mertz.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2011-12-26<br>
</td>
<td style="vertical-align: top;">Gemini: More bug fixes
to the OBC assembler program, <span style="font-weight:
bold;">yaASM</span>. I think it's pretty close to
100% correct now. I've also created an OBC CPU
emulator called <span style="font-weight: bold;">yaOBC</span>,
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 <a href="Gemini.html#Downloads">executables
for the programs can be downloaded from here</a>.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2011-12-23<br>
</td>
<td style="vertical-align: top;">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 <span
style="font-family: Courier New,Courier,monospace;">CODE</span>
and <span style="font-family: Courier
New,Courier,monospace;">DATA</span> directives in OBC
assembly language slightly. Both the <span
style="font-weight: bold;">yaASM</span> program itself and
the write-ups on the Gemini page have been fixed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2011-12-21<br>
</td>
<td style="vertical-align: top;"> Gemini:<br>
<ul>
<li>Completed essentially all updating with respect to
emailed comments from original OBC developers to date.</li>
<li>Added scan of short memo on modified Euler integration
by Gene Mertz.</li>
<li>Added design flowchart regarding Charlie Leist's OBC
code sample.</li>
<li>Added complete early 1963 scan of the OBC "Math Flow",
with Alden Minnick's handwritten notes on it.</li>
<li>Corrected p. 12 of the Gemini Programming Manual,
regarding allowable operands for the OBC <span
style="font-family: Courier New,Courier,monospace;">PRO</span>
instruction.</li>
<li>Updated the OBC assembler program, <span
style="font-weight: bold;">yaASM</span>, to accept
some additional syntax alternatives with respect to the
<span style="font-family: Courier
New,Courier,monospace;">PRO</span> instruction.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2011-12-20<br>
</td>
<td style="vertical-align: top;"> Gemini:<br>
<ul>
<li>Corrected the way the <span style="font-family:
Courier New,Courier,monospace;">SPQ</span> instruction
was described on the Gemini page, as well as the way the
<span style="font-weight: bold;">yaASM</span> assembler
treated it and the way the way it was written in the
assembler test file.</li>
<li>I'm told that the OBC developer spreadsheet was
unreadable in Microsoft Excel, so it has been replaced
by a PDF file instead.<br>
</li>
<li>Continued working through my long list of scanned
material and information contributed by OBC
developers. Too many little changes to describe
here.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2011-12-18<br>
</td>
<td style="vertical-align: top;"> All things Gemini:<br>
<ul>
<li>Major rewrites and corrections to the CPU/software
related portions of the <a href="Gemini.html">Gemini
Page</a>, as well as updates to the document library,
due to having received a sudden influx of direct
feedback from original Gemini OBC developers Alden
Minnick, Charlie Leist, and Don O'Neill, as well as
continuing feedback from Gene Mertz, and indirect
feedback from other OBC developers. Among other
things, misconceptions with respect to bit ordering and
instruction sequencing have been corrected.<br>
</li>
<li>There's now a very-alpha version of a <a
href="Gemini.html#yaOBCASM_the_OBC_Cross-Assembler">newly-created
Gemini
OBC assembler program</a>. At present, links to
it are on Gemini page and not on the download
page. <br>
</li>
<li>Some very significant documentation additions:</li>
<ul>
<li><a href="Documents/GeminiProgrammingManual.pdf">
"Gemini Programming Manual"</a>, produced originally
during the Gemini project by developers Charlie Leist
and Jim Condell, with some recently reconstructed
missing material by Charlie Leist.</li>
<li><a href="Documents/GeminiOBC-MathFlow-III.pdf">
"Math Flow" diagrams for Catch-up & Rendezvous
software module as of 1966</a>. A Math Flow diagram
is an extremely detailed flowchart for the software.<br>
</li>
<li>(There's also a complete Math Flow diagram for the
entire flight software, as of 1963, but I haven't had
a chance to scan it yet. So that's something to
look forward to.)</li>
<li>The <a
href="Documents/GeminiGeophysicalConstants.pdf">
"official" geophysical constants</a> assumed by the
project.</li>
<li>Handwritten memo from 1962 (I guess by Gene), "<a
href="Documents/WriteupOfProblem6056-26BitOrbitCalculation.pdf">Writeup
of
Problem 6056 — 26 Bit Orbit Calculation</a>".</li>
<li><a href="Documents/GeminiOrbitRateCompensation.pdf">
Handwritten note by Gene Mertz on orbit torquing
rate compensation</a>.<br>
</li>
</ul>
<li>Recently-produced <a
href="Gemini.html#Gemini_Assembly_Language">OBC
source-code samples</a> from OBC developers Alden
Minnick and Charlie Leist, as transcribed from the Math
Flow diagrams. Though not actually contemporary to
the Gemini project itself, these are the first OBC code
samples we've had access to which can be expected to
have any authenticity to them.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2011-07-24<br>
</td>
<td style="vertical-align: top;"> 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:<br>
<ul>
<li>I've <span style="font-style: italic; font-weight:
bold;">not</span> completed the process of porting the
Gemini catch-up and rendezvous simulation program so
that it can be run in a modern machine-independent
Fortran. The problem (aside from my general
laziness) is that the program does some stuff very
specific to the IBM 704/7090/7094 which I don't
understand, and therefore don't understand how to
port. If there's anyone with the time and energy
(or shockingly, the expertise) to handle this, I'd be
grateful. Alternatively, there's a generally
available simulator for that IBM computer system, and
getting the program running on the simulator would also
be a very interesting alternative.</li>
<li>With various people's help (principally Mikael
Uvebrandt and Jim Lawton), the Apollo 8 code (Colossus
237) is almost ready for use, but not quite. It
just requires some effort from me to close the gap and
get it working. Keep your fingers crossed on this
one.</li>
<li>Helmuth Litfin has created software which he calls the
"Ultimate DSKY Simulator", which (surprise!) is intended
to be a DSKY simulation that is accurate in terms of
physical dimensions and appearance, and more accurate in
terms of behavior than my yaDSKY program. For
example, in terms of the former, the Ultimate SDKY would
appear on your computer screen with the same physical
dimensions as a real DSKY. Unfortunately, the
simulator is Windows-only and is not open source, and
I'm not aware of it being presently available for use,
so I can't actually give you a link to it; but I have
seen a preliminary version almost (but not quite) worked
with yaAGC. This is significant because the brief
evaluation did reveal certain flaws in the behavior of
yaDSKY, which Helmuth has explained to me in terms of
the DSKY schematics, and therefore will probably have to
be fixed at some point. The flaw relate
principally to the DSKY's "standby" mode, and the manner
in which the DSKY enters or leaves standby mode. I
can't promise a time-frame for the fixes. If
anybody is interested in the meantime, I can relate the
details to you.<br>
</li>
</ul>
Now for other contributions and communications:<br>
<ul>
<li>A couple of years ago, Fabrizio Bernardini did a
presentation on the AGC (in Italian), and was kind
enough to provide English translations of the material
he created. This pretty-extensive introduction has
been added to our "<a href="ForDummies.html#Fabrizio">Kinder,
Gentler
Introduction</a>" page.</li>
<li>Also a couple of years ago, Dimitris Vitoris sent us
an update to his <a
href="Pultorak.html#Dimitris_Vitoriss_Block_I_and_Block_II">physical
implementation
project</a>, apologising that he was sending the
update and thus adding to my workload at a time when
there seemed to be an "explosion of activity".
(Pretty ironic, right?) I've now added those very
extensive updates.</li>
<li>At the same time, Dimitris also sent along a number of
photos of various things in his personal collection
which may be of interest, including bits and pieces of a
block 1 AGC and DSKY, an LVDC, and an RCA-110A
computer. I've included those photos on the
relevant pages.</li>
<li>I've added a <a href="Gemini.html#Software_Examples">Gemini
OBC
coding example</a> sent in by John Pultorak a couple
of years ago.</li>
<li>Added references on the <a
href="download.html#Downloads">download page</a> to
alternate installation packages provided by Onno Hommes.</li>
<li>Donna Polehn has create and IDE and Block I AGC
implementations (both for an off-the-shelf FPGA board
and a custom one), based on the Pultorak Block I
AGC. I put the appropriate references to it on the
<a href="Pultorak.html#Polehn">physical implementations
page</a>.</li>
</ul>
There's a lot more on the to-do list, but I'm to-done for
to-day, and will hopefully get to them to-morrow.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2010" onchange="viewOrHide(2010)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2010 change notes?</b>
<table summary="" id="table2010" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2010-09-05<br>
</td>
<td style="vertical-align: top;">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 <span
style="font-weight: bold;">gcc</span>. (The porting
isn't yet complete, in that I'm still working on various of
the assembly-language subroutines.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2010-08-26<br>
</td>
<td style="vertical-align: top;">On the Gemini page, corrected
"Ferney Hough" to "Dal G. Ferneyhough, Jr." Also,
added a photo of Gene Mertz <span style="font-style:
italic;">et al</span>., and some additional recollections
from Gene.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2010-08-15<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Due to feedback from Gene Mertz, a number of changes
were made to the reminiscences and homage sections of
the Gemini page.</li>
<li>Some source code for the Gemini 7/6 catch-up and
rendezvous simulation programs has now been extracted
from the "wonderful report" mentioned in the last
entry. It is only in the Subversion repository at
the moment, and isn't yet complete or proofed/debugged,
and so cannot yet be compiled or executed.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2010-08-11<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Eugene Mertz, one of the original Gemini on-board
computer software developers has contributed a wonderful
"<a
href="Gemini.html#The_Gemini_Catch-Up_and_Rendezvous">report</a>"
that is really the complete FORTRAN source code used to
validate algorithms and to simulate flight computer
behavior for the catch-up and rendezvous Gemini flight
phases. Thus while we have no actual Gemini flight
software at the present time, this is the next closest
thing! Many thanks to Gene and to his son Dave for
careful scanning of the document. Although I have
not yet had time to do so, I expect to convert this
FORTRAN code into a compilable/runnable form in the near
future.<br>
</li>
<li>Gene has also supplied various Gemini software
reminiscences and factoids, of which I have provided an
edited version on <a
href="Gemini.html#Reminiscences_and_Factoids_from_the">the
Gemini
page</a>.</li>
<li>Zach Greene has sent along a nice, partial list of the
current locations of the command modules, which I've
added to the <a href="Colossus.html">Colossus page</a>.</li>
<li>Will Ault has complained :-) that I nowhere describe
my own professional background. Ah, silly
boy! I've added an appropriate link on the <a
href="faq.html">FAQ</a>.</li>
<li>On the Gemini page, replaced the Apollo-patch logo
with a Gemini-patch logo instead.</li>
<li>On the reading list of the FAQ page, added Frank
O'Brien's new book, <span style="font-style: italic;">The
Apollo
Guidance Computer: Architecture and Operation</span>.
Go
buy it right now, if you know what's good for you.<br>
</li>
</ul>
Several other people have sent in material that has been
sitting in the queue for far too long. Hopefully, I'll
soon update the website with that material as well. My
apologies for the delays!<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2010-02-20<br>
</td>
<td style="vertical-align: top;">
<table summary="" style="text-align: left; width: 60%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="text-align: center; vertical-align: top;"><span
style="font-style: italic; font-weight: bold;">These
are
the release notes for snapshot 20102020.</span><br>
</td>
</tr>
</tbody>
</table>
<br>
<ul>
<li>The <span style="font-weight: bold;">Artemis</span>
72 (Apollo 15-17 Command Module) program listing has now
been converted completely to source-code files, and has
been debugged so that the assembled binary agrees with
the octal listing from the hardcopy. The existing
Artemis 72 binary that we have been providing since
snapshot 20060110 was found to be in error, and was
corrected in one place! The conversion to source
was done by Hartmuth Gutsche, Onno Hommes, Jim Lawton,
and Sergio Navarro, but Jim took it upon himself to
perform the complete debugging of the source after it
was created and I can attest that this is a large
job. Kudos to all!</li>
<li>Jim Lawton also seems to have single-handedly
converted all of the <span style="font-weight: bold;">Solarium</span>
55 (Apollo 4 Command Module) program listing to
source-code files and octal. (Thanks, Jim!)
We presently have no way to assemble the Block 1 source
code in <span style="font-weight: bold;">yaYUL</span>,
so we don't yet have any way to verify the conversion;
nor can we run the Block 1 binary in <span
style="font-weight: bold;">yaAGC</span> yet. But
first things first.</li>
<li>In a pathetic attempt to say "me too" in a soft,
whimpering voice, I've begun creating a new assembler (<span
style="font-weight: bold;">yaASM</span>) for Gemini
OBC and Apollo LVDC source (if we had any). But it
does nothing useful yet, so it's sheer bravado on my
part to even mention it.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2010-01-30<br>
</td>
<td style="vertical-align: top;">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.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2009" onchange="viewOrHide(2009)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2009 change notes?</b>
<table summary="" id="table2009" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2009-11-12<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Paul Fjeld has managed to come up with the <a
href="Documents/Luminary99PadLoads.pdf"> pad loads for
the Apollo 11 LM</a>, and those are now in the
document library. Thanks, Paul!</li>
<li>Christian Bucher has let me know that the duty cycle
for flashing indicators and digits on the DSKY is 3:1
(high:low) rather than the 1:1 that I've been
using. I've corrected the current <span
style="font-weight: bold;">yaDSKY2</span> program to
fix this, but haven't bothered with the obsolete <span
style="font-weight: bold;">yaDSKY</span>
program. Thanks, Christian!</li>
<li>John Pultorak has sent me a game pack for the
AGC. :) The pack includes a tic-tac-toe game
(1 or 2 players) and a Simon game. I've included
the games in the "Contributed" source tree, but there's
presently no way to actually use them. There are
two problems with trying to use it, and if anybody wants
to fix them I'd be grateful:</li>
<ol>
<li>The code is written in the syntax of John's
assembler rather than <span style="font-weight:
bold;">yaYUL</span>. There are several mods
needed, the principal one being that John's assembler
doesn't have the <span style="font-weight: bold;">yaYUL</span>
limitation of 8-character upper-case labels.</li>
<li>Rather than directly accessing the DSKY via i/o
channels, the code assumes the presence of some
Colossus code (including the executive) to manage this
activity. Figuring out just what portions of
Colossus to prune away to get room for the games is
quite tricky. It was done this way because John
envisaged the game pack as an add-on to Colossus ... a
kind of in-flight entertainment system. :)
However, for our purposes you could just as easily
eliminate all of the Colossus code and directly access
the DSKY.<br>
</li>
</ol>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-09-02<br>
</td>
<td style="vertical-align: top;">Have made most of the PDFs in
the <a href="links.html">Document Library</a> 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.</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-30<br>
</td>
<td style="vertical-align: top;">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.</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-26<br>
</td>
<td style="vertical-align: top;">Since there's now a
site-search bar, I think it's appropriate to make sure that
all of the PDFs in the <a href="links.html">Document
Library</a> 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 <span
style="font-style: italic;">all</span> of the PDFs, and
even longer for Google to reindex them, but I'm making a
start on it as of today.</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-25<br>
</td>
<td style="vertical-align: top;">Added a site-search bar to
the top of every page. It's swell!<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-24<br>
</td>
<td style="vertical-align: top;">Added several "Apollo
Experience Reports" to the <a href="links.html">Document
Library</a>, 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
Apollo 6.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-23<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Finished fleshing out the <a href="Gemini.html">Gemini
page</a>. I think it's pretty usable now, though
I'm sure there's plenty to be done to make it
better. Any mistakes on it now are actual mistakes
as opposed to mere work-in-progress mistakes.<br>
</li>
<li>Added some documents to the <a href="links.html">Document
Library</a>, such as mission reports, press kits, and
some training materials.<br>
</li>
<li>Added some tweaks to the <a href="yaAGS.html">AGS
page</a>, based on a newly-added AGS Design Survey
document.</li>
<li>Added some much better images (drawings, actually) of
the <a href="yaDSKY.html#Block1">Block I DSKYs</a>, in
which all of the labeling on indicator lamps and
what-not are actually readable.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-17<br>
</td>
<td style="vertical-align: top;">Added a <a
href="Gemini.html">Gemini spacecraft computer page</a>,
even though it's empty right now, and added documentation
(all scarfed from the <a
href="http://www.ibiblio.org/mscorbit/document.php">Meadville
Space
Center</a> website) of the Gemini spacecraft computer to
our <a href="links.html">Document Library</a>. This
is partly sheer compulsiveness, but also partially because
John Pultorak has pointed out that the <a href="LVDC.html">LVDC</a>
must be descended from the Gemini computer, simply because
of some very deep similarities between them.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-15<br>
</td>
<td style="vertical-align: top;">Added a <a
href="HowToDigitize.html">"how to digitize" page</a> to
the website.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-14<br>
</td>
<td style="vertical-align: top;">Integrated an <a
href="LVDC.html">LVDC page</a> 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
become useful.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-09<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><a href="ScansForConversion/Colossus237/"> Page images</a>
of the <span style="font-weight: bold;">Colossus</span>
rev. 237 (Apollo 8) program listing are now
available. The program listing was provided by
Fred Martin, and photographed by yours truly.
We're getting quite a backlog now, so I've no idea when
this will become available as source code or will be
usable in the simulator.</li>
<li>Various documents relevant to the LVDC (or more
accurately, to the Saturn 1B/V guidance system) have
been added to the <a href="links.html#LVDC">Document
Library</a>. Many thanks to Barry Silverman for
directing me to these, and to other documents that I
haven't had a chance yet to add.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-06<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><a href="links.html#Space_Guidance_Analysis_SGA_memos">Added
the
remainder of the SGA memos</a>, again contributed by
Fred Martin and scanned by Onno.</li>
<li>Did more reorganization of the <a href="links.html">Document
Library</a>, and added a bunch of scrounged docs from
various sources on the web (flight plans, crew
debriefings, chunks of GSOPs, etc.), including the first
LVDC docs we've had here. Of course, added
appropriate cross-links to the new docs on the <a
style="font-weight: bold;" href="Luminary.html">Luminary</a>
and <a style="font-weight: bold;" href="Colossus.html">Colossus</a>
pages.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-05<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><a href="links.html#Space_Guidance_Analysis_SGA_memos">Added
a
number of additional SGA memos</a>, again contributed
by Fred Martin and scanned by Onno.<br>
</li>
<li>And this time I <span style="font-style: italic;">really</span>
restructured the "links" page so that it is now a "<a
href="links.html">Document Library</a>" page
instead. Everything that wasn't a document was
moved instead the <a href="faq.html">FAQ page</a>.
I
have realized somewhat belatedly that it hasn't been
about "links" for a long time now, and by pretending
that it was I was just keeping people from easily
finding the documents they needed. Well, it should
be a lot easier now. Also, there are planned
improvements (beyond just the continued accumulation)
which should make it yet a better tool in the
future. But we'll have to think about that another
day. I suppose I should note just out of sheer
compulsiveness that I haven't had time to do all of the
processing I'd like to do on the documents now being
uploaded, such as making the text searchable and putting
in document metadata, but all that stuff will hopefully
be added later.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><a href="links.html#Space_Guidance_Analysis_SGA_memos">24
additional
MIT Instrumentation Lab "Space Guidance Analysis"
(SGA) memos</a> were added, courtesy of Fred Martin,
and scanned by Onno. These memos provide that
mathematical underpinnings for the guidance-system
software and procedures.<br>
</li>
<li><a href="links.html">The entire documentation area of
the links page</a> has been restructured, so that
hopefully it's not quite the random hodge-podge of items
and is a little easier to find what you want.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-03<br>
</td>
<td style="vertical-align: top;">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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-08-02<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Various adjustments to account for problems people
have been having using <span style="text-decoration:
underline;">command-line debugging</span> of AGC/AEA
code. (Thanks to John Pultorak for reporting
problems.) Command-line debugging made a lot less
frustrating, but not perfect by any means. Most of
the problems had to do with an optional library called <span
style="font-weight: bold;">libreadline</span>, which
provides may nice features related to command-line
editing and command histories, but (to put it nicely)
was causing us terrible problems.<br>
</li>
<ul>
<li><span style="font-style: italic;">Inability to find
source files in some cases</span>: Changed
pathname generation for source-code files in symbol
tables to account for the possibility of the current
runtime directory being used also as the source-file
directory.</li>
<li><span style="font-style: italic;">Garbage on command
line and/or (in Vista)</span> <span
style="font-weight: bold; font-style: italic;">yaAGC</span><span
style="font-style: italic;">/</span><span
style="font-weight: bold; font-style: italic;">yaAGS</span><span
style="font-style: italic;">crashing</span>:
Made some fixes in the usage of <span
style="font-weight: bold;">libreadline</span> in <span
style="font-weight: bold;">yaAGC</span> and <span
style="font-weight: bold;">yaAGS</span>, and added
various WIN32 checks for spurious returns from the <span
style="font-weight: bold;">libreadline</span>
functions. However, none of it helps the problem
I was trying to fix. Therefore, I have disabled
the <span style="font-weight: bold;">libreadline</span>
support in production Win32 builds, and that seems to
take care of it. (I made no effort to disable <span
style="font-weight: bold;">libreadline</span> in
native Win32 builds. )</li>
<li>But then ... the <span style="font-weight: bold;">libreadline</span>-associated
problems
I see on Linux (inability to use the backspace key,
right-arrow backspaces right over the prompt in <span
style="font-weight: bold;">yaAGC</span>, missing
prompt in <span style="font-weight: bold;">yaAGS</span>)
have finally exasperated me too much. I've
disabled <span style="font-weight: bold;">libreadline</span>
support on all platforms until these unprofessional
irritations can be resolved. On some platforms
this causes loss of the ability to use the up/down
arrows to navigate through the command history, but I
can live with that.</li>
<li>Found and corrected an arbitrarily-short command
line length in the <span style="font-weight: bold;">WinAGC</span>
utility I created to run and monitor the simulation in
Win32. The upshot of this is that when running a
very complex set of simulation options, such as
command-line debugging, the commands to start the
simulation might be truncated and fail, and so the
simulation would abort at startup. Hopefully
this won't happen now.<br>
</li>
</ul>
<li>The main GUI (<span style="font-weight: bold;">VirtualAGC</span>),
when
allowing the user to choose a custom AGC/AEA source or
binary file to assemble and/or simulate, now starts from
the user's home directory (or whatever the equivalent is
on an operating-system by operating-system basis) when
the custom name is blank. It also doesn't allow
directory-changes to bleed through between the different
types of file-dialogs as it has been doing on some
platforms.</li>
<li>Custom AGC/AEA code in the main GUI (<span
style="font-weight: bold;">VirtualAGC</span>):
You were previously able to assemble source code and run
from here, but you couldn't do symbolic debugging or
browse the source-code listing. In other words,
the main GUI is now almost a one-stop shop for assembly
and command-line debugging. You still have to
provide your own editor or, if you want GUI-based
debugging in Code::Blocks (for instance), you still need
to do some manual stuff outside the GUI.<br>
</li>
<li>Added Alberto Galdo's mods (thanks, Alberto!) for
building <span style="font-weight: bold;">yaAGC</span>
for an iPhone. Now, <span style="font-weight:
bold;">yaAGC</span> without a DSKY obviously doesn't
do very much, though in theory you could still run and
debug AGC code from a command line (if the iPhone has
such a thing). Since I don't have an iPhone and
haven't bothered as of yet to download an iPhone
development kit it's an open question if I've properly
implemented Alberto's changes, but at least it's a
start. There are some instructions on the <a
href="download.html#iPhone">download page</a> for
building it.</li>
<li>Added some proofing for Luminary 99 done by Steve
Case. (Thanks, Steve!)</li>
<li>The volunteer team (who will all be acknowledged later
when the Artemis072 source code is completely available)
have added various Artemis072 source files, as well as
making some corrections to existing Luminary099 and
Comanche055 source files.</li>
<li>This dev snapshot (identical to svn 285) was checked
by:</li>
<ul>
<li>Installation and checkout of production builds on:
Ubuntu 8.04 64-bit Linux, Windows Vista, and Mac OS X
10.5.7 Intel.</li>
<li>Native builds and checkout on: Mac OS X 10.5.7
Intel, Windows XP, FreeBSD 7.2 (PCBSD 7.1). Note
that the pathname problems previously reported for
FreeBSD have not been fixed yet, so that problem
persists.<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-31<br>
</td>
<td style="vertical-align: top;">Added scans of the Apollo 8
Flight Plan (<a
href="Documents/FlightPlanApollo8-Martin-sects1-2.pdf">sections
1-2</a> and <a
href="Documents/FlightPlanApollo8-Martin-sects3-5.pdf">
sections 3-5</a>), contributed by Fred Martin.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-30<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Corrected a typo on the assembly-language manual page,
in which I left out the word "not" in saying that
interrupt service routines do [not] save
registers. Thanks to Benjamin Stover for pointing
out this bone-headed error.</li>
<li>Fred Martin, one of the original AGC developers has
sent over a bunch of documents, of which I've had time
to scan the following so far:</li>
<ul>
<li>The Apollo 8 Technical Debriefing (<a
href="Documents/Apollo8-TechnicalDebriefing-Martin-1.pdf">first
half</a> and <a
href="Documents/Apollo8-TechnicalDebriefing-Martin-2.pdf">
second half</a>).</li>
<li>Section 5 ("Guidance Equations") of the Guidance
System Operation Plan (GSOP) for Colossus 2 (Comanche
44, 45). (Sections <a
href="Documents/R-577-Colossus2-Martin-5.1.pdf"> 5.1</a>,
<a href="Documents/R-577-Colossus2-Martin-5.2.pdf">
5.2</a>, <a
href="Documents/R-577-Colossus2-Martin-5.3.pdf"> 5.3</a>,
<a href="Documents/R-577-Colossus2-Martin-5.4.pdf">
5.4</a>, <a
href="Documents/R-577-Colossus2-Martin-5.5.pdf"> 5.5</a>,
and <a
href="Documents/R-577-Colossus2-Martin-5.6789.pdf">
5.6-5.9</a>.) Though as usual I don't have enough
configuration data to be sure, I am willing to provide
a very strong guess that this is for Apollo 10, and
I'm going to treat it as such.</li>
<li><a href="ScansForConversion/Colossus249-Martin/"> A
readable copy of the Colossus 249 assembly listing</a>.
Of
course, we've had a Colossus 249 assembly listing all
along, but the legibility of this new copy is far
superior.<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-27<br>
</td>
<td style="vertical-align: top;">Added some new documents (<a
href="Documents/SGA-Memo-8-71-Robertson.pdf">memo</a> and
<a href="Documents/SGA-Memo-8-71-Addendum-1-Robertson.pdf">
addendum</a>) 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!<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-26<br>
</td>
<td style="vertical-align: top;">
<ul>
<li style="font-weight: bold;">yaYUL</li>
<ul>
<li>Corrected some syntax colorization in AGC code,
where the 2nd interpretive instruction on a line could
be mistaken for a symbol (if there was one of the same
name, which happens pretty frequently).</li>
<li>Made a lot of provisions for Block 1 code, though
nothing that's working yet.<br>
</li>
<li>Added a utility called <span style="font-weight:
bold;">SplitInterp</span> for helping to
reverse-engineer interpretive codes.</li>
</ul>
<li><span style="font-weight: bold;">Comanche055</span>:
Added
some annotations (thanks to Marcus Joachim) related to
lunar and solar ephemerides.</li>
<li><span style="font-weight: bold;">Artemis072</span> and
<span style="font-weight: bold;">Solarium055</span>:
Various
changes related to beginning conversion of page images
to source files.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-24<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaLEMAP</span> was
previously converting AEA source code comments to all
upper-case. It has been fixed so that case is now
preserved in comments. Thanks to Marcin Skoczylas
for pointing out that this was causing a problem when
following the URLs provided in the comments in assembly
listings.<br>
</li>
<li>The story (provided by Don Eyles via Onno Hommes)
about the naming of the BURN BABY BURN Luminary routine
has been added to the annotations of the Luminary 099
source code.</li>
<li><span style="font-weight: bold;">VirtualAGC</span> has
been fixed so that <span style="font-weight: bold;">Colossus</span>
249 is identified with Apollo 9 rather than Apollo
8. The good news here is that I am now expecting <span
style="font-weight: bold;">Colossus</span> 237 (for
Apollo 8) to actually be available soon, so we aren't
really losing Apollo 8.</li>
<li>The naming of all AGC source files has been changed
from *.s to *.agc; that of all AEA source files has been
changed from *.s to *.aea; that of all HTML files
created from source has been changed from *.html to
*.agc.html or *.aea.html. This has been done to
play nicely with the AGA/AEA syntax highlighting which
Google has been nice enough to add. I hope that I
have tracked down all associated links on this website
and fixed them, but I may have missed a few.
Please let me know if you discover any wrong ones.<br>
</li>
</ul>
Note that the changes for <span style="font-weight: bold;">yaLEMAP</span>
and <span style="font-weight: bold;">VirtualAGC</span> are
available in subversion only at the moment, as I haven't
released a new source tarball or binary installers.
However, I am updating the assembly code HTML listings on
the website.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-22<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>I believe that I have been mis-identifying <span
style="font-weight: bold;">Colossus</span> 249 all
these years as being for Apollo 8, but that it was
really for Apollo 9. This correction has been made
on the <span style="font-weight: bold;">Colossus</span>
page, but hasn't made it's way into any software
yet. Thanks to Onno Hommes and Fred Martin.<br>
</li>
<li>The home page has been modified to provide <a
href="index.html#Solution_to_the_Apollo_14_Final_Exam">the
solution
to the Apollo 14 "final exam" problem</a>.
Thanks to Onno Hommes, Don Eyles, and Paul Fjeld.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-18<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>The page images for AGC code for the <a
href="ScansForConversion/Solarium055/"> Apollo 4</a>
and <a href="ScansForConversion/Artemis072/"> Apollo
15-17</a> CM are now available and are online, and <a
href="volunteer.html#Code_Conversion">volunteers are
desired for conversion to source code</a>. There
are lots of people to thank on this one; if you are one
of them, look on the <a href="Colossus.html">Colossus
page</a> to see your name in lights.</li>
<li>The beginnings of a <a href="ForDummies.html">"kinder
and gentler" introductory page</a> has been created,
but really needs to be fleshed out some. (I didn't
want to wait for it to be ready to get the page images
mentioned above online.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-07<br>
</td>
<td style="vertical-align: top;">Stephan Hotto has sent along
a bug-fix the LM-Simulator program. The bug was found
by Riley Rainey. Thanks to both!<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-07-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Building HTML from <span style="font-weight: bold;">yaYUL</span>/<span
style="font-weight: bold;">yaLEMAP</span> now allows
addition of <a href="SourceAnnotations.html">annotations</a>,
with styling.</li>
<li>The <a href="volunteer.html#Source-Code_Annotation">volunteer
page</a> now has a new section, describing addition of
modern annotations to the AGC/AGS source code.</li>
<li>I am finally able to provide some positive advice on
using Virtual AGC on Windows Vista or Windows 7.
Thanks to Brendan O'Rourke for reporting the Vista
problems that triggered the extreme step of my actually
running a copy of Vista ... though I don't know that
"thanks" is really what I want to say here. :-)</li>
<li>Updated the <a href="faq.html">FAQ page</a> with some
delightful sarcasm. (Well, delightful to <span
style="font-style: italic;">me</span> anyway.)</li>
<li>Integrated the fancy new HTML assembly listings with <span
style="font-weight: bold;">VirtualAGC</span>.
(In other words, they fancy new assembly listings appear
when browing source from <span style="font-weight:
bold;">VirtualAGC</span>.) Incorporated them in
the binary installers as well.</li>
<li>Added Onno's syntax-highlighting files to the binary
installers, so that it is no longer necessary to
download them separately if colorizing <span
style="font-weight: bold;">Vim</span>, <span
style="font-weight: bold;">Code::Blocks</span>, <span
style="font-weight: bold;">Kate</span>, etc.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-29<br>
</td>
<td style="vertical-align: top;">(SVN only at the moment,
since no development snapshot released yet.) Building
on Onno's syntax-highlighting ideas, <span
style="font-weight: bold;">yaYUL</span> and <span
style="font-weight: bold;">yaLEMAP</span> 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 <a href="yaAGS.html">yaAGS</a>,
<a href="Luminary.html">Luminary</a>, <a
href="Colossus.html">Colossus</a>, and <a
href="links.html">links</a> pages.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-27<br>
</td>
<td style="vertical-align: top;">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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-20<br>
</td>
<td style="vertical-align: top;">On the "volunteering" page,
I've added a lot of material about proofing tasks (<a
href="volunteer.html#Proofing_of_octal_listings">octal
listings</a> and <a
href="volunteer.html#Proofing_of_comments_in_source-code">program
comments</a>) that I wouldn't mind accepting help
with. Those tasks were previously mentioned, I think,
but were basically left to the imagination.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-18<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>On the <a href="yaDSKY.html">DSKY page</a>, made some
corrections as to which DSKY configurations were used
with which missions, and added a little supporting
evidence for my assertions.</li>
<li>On the <a href="Luminary.html">Luminary page</a>,
added some supporting evidence for my Apollo 9
versioning assertions, thanks to James Kernan.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-17<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>My addition of the "presentation" feature to the <span
style="font-weight: bold;">yaDSKY2</span> program
apparently broke the Windows version of the program, in
that if the optional configuration file the feature uses
is absent, nasty pop-up warnings appear. I've
fixed this in the <a href="download.html#Downloads">current
development
snapshot</a> and Linux/Windows/Mac installers.
Thanks to Brendan O'Rourke for pointing this out!</li>
<li>James Kernan (thanks, Jim!), one of the original AGC
developers, has sent us an answer about some of the
uncertainties in the versioning of the Apollo 11 LM
software. <a href="Luminary.html">I've added his
comments to the <span style="font-weight: bold;">Luminary</span>
page</a>.</li>
<li>Alessandro Cinquemani (thanks, Alessandro!) has sent
some new photos updating his progress on rebuilding John
Pultorak's Block 1 replica, and I've updated the <a
href="Pultorak.html#Whos_Building_Them">Physical
Implementation page</a> with those.</li>
<li>Unfortunately, info on the Block 1 DSKYs hasn't
previously been available easily on this website, so
I've begun the process of collecting it and adding <a
href="yaDSKY.html#Block1">Block 1 info to the <span
style="font-weight: bold;">yaDSKY</span> page</a>.
Of
course, <span style="font-weight: bold;">yaDSKY</span>(<span
style="font-weight: bold;">2</span>) does not as yet
support Block 1, nor does <span style="font-weight:
bold;">yaAGC</span> nor <span style="font-weight:
bold;">yaYUL</span>, so the information is presently
for interest only.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-13<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Apparently, my fix for the non-portability of the
symbol tables (when debugging AGC code) was faulty in
that it broke some aspects of symbolic debugging, as
well as use with <span style="font-weight: bold;">CODE::BLOCKS</span>.
Onno
Hommes has fixed the regressions I created.
Thanks, Onno!</li>
<li>At the request of Fabrizio Bernardini, I've added a
feature to the <span style="font-weight: bold;">yaDSKY2</span>
program that may be of use in <a
href="yaDSKY.html#SpecialEffects">making presentations</a>
using Virtual AGC.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-07<br>
</td>
<td style="vertical-align: top;">
<table summary="" style="text-align: left; width: 80%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span
style="font-weight: bold; color: rgb(204, 0, 0);">The
Apollo
11 LM AGC code is now fully available in source
and binary form, is provided by the development
snapshot and installer programs, and can be run in
the simulation using the VirtualAGC GUI.</span><br>
</td>
</tr>
</tbody>
</table>
It has been only partially proofed—less so than Comanche
055—and so I won't feel great confidence until another
proofing step or two has been done. Nevertheless,
there's no reason (other than sad past experience) to think
that it isn't okay as-is, as all of the memory-bank
checksums are okay.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-06<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Fixed a little bug in <span style="font-weight:
bold;">yaYUL</span>: In the bugger-word table
printed at the end of an assembly listing, the addresses
of the bugger words were being printed as things like
33,01777 rather than 33,3777.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-05<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Fixed a page image (#1294) for Luminary 099 that had a
few lines truncated at the bottom.</li>
<li>Luminary 099 is now complete in svn and assembles
without errors, but I've not debugged it yet.
Undoubtedly it's still full of errors, so I haven't
updated the development snapshot or installers to
include it yet.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-06-01<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>A wrong command-line switch was being passed in a
Makefile, which would cause the native Win32 build to
fail. Thanks to Onno Hommes for noticing
this. I would have sworn I had tested this after
the last relevant change, but apparently did not.
I promise you that with this snapshot I tried native
builds in Linux, Win32 XP, Mac OS X 10.5, FreeBSD 7.2,
and cross-platform builds as well.<br>
</li>
<li>There are also incremental changes for things like
Luminary 99 and syntax highlighting.</li>
</ul>
<br>
I doubt that would justify a new download at this point,
unless you're trying to do native Win32 builds and they're
failing.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-05-23<br>
</td>
<td style="vertical-align: top;">
<table summary="" style="text-align: left; width: 80%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span
style="font-weight: bold; color: rgb(204, 0, 0);">The
Apollo
11 CM AGC code is now fully available in source
and binary form, is provided by the development
snapshot and installer programs, and can be run in
the simulation using the VirtualAGC GUI.</span><br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-05-16<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Almost all of the Comanche 055 source code and a small
amount of the Luminary 099 source code is available in
the <a
href="http://code.google.com/p/virtualagc/source/checkout">subversion
repository</a>, though I didn't feel it was worthwhile
rebuilding the development-snapshot tarball until we're
closer to having something that runs in the simulation.<br>
</li>
<li>The giant PDFs of Colossus 249 and Luminary 131 page
images have been deleted, in favor of reduced-quality
files of individual pages. When I say "reduced
quality", I'm making a statement that is technically
true, but I doubt anyone would see the difference unless
they did a side-by-side comparison and zoomed in by
about 3:1 or 4:1. The orginal giant PDFs
(without the improvements I made in them) are still
available elsewhere online if you want them. This
change has been made to be more consistent with Comanche
055 and Luminary 099, to make it easier for anyone who
might want to volunteer to proof the program comments,
and simply to reduce the disk space taken up. Not
that ibiblio.org has complained or anything, but there's
no value added in wasting the space!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-05-12<br>
</td>
<td style="vertical-align: top;">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 <a
href="http://code.google.com/p/virtualagc/source/checkout">subversion
repository</a>. Work on conversion of Luminary 099
(Apollo LM) page images to source code has not yet begun.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-05-05<br>
</td>
<td style="vertical-align: top;">
<table summary="" style="text-align: left; width: 80%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span
style="font-weight: bold; color: rgb(204, 0, 0);">Page
images
for the Apollo 11 LM and CM AGC code are now in
hand, but the processing necessary for use in the
AGC simulator has not yet been performed. If
you would like to assist in conversion effort,
please visit the <a
href="volunteer.html#Code_Conversion">volunteer
page</a>.</span><br>
</td>
</tr>
</tbody>
</table>
<br>
The hardcopy from which these images were taken is from the
Charles Stark Draper Historical Collection, MIT Museum,
Cambridge, MA.<span class="Apple-converted-space"> </span>
The digital scans were produced by Paul Fjeld. Many
thanks to Debbie Douglas of the <a
href="http://web.mit.edu/museum">MIT Museum</a> 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. </td>
</tr>
<tr>
<td style="vertical-align: top;">2009-05-03<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Now able to do a native build on OpenSolaris.
However, anyone saying it was working on that platform
would have to have a more charitable nature than I.<br>
</li>
<li>Added the <a href="volunteer.html">"volunteer"</a>
web-page and linked it in with the other pages.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-05-02<br>
</td>
<td style="vertical-align: top;">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
little.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-27<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>There is now a <a
href="http://code.google.com/p/virtualagc/source/checkout">subversion
repository</a>, thanks to Onno Hommes. Developer
snapshot tarballs and binary installation packages will
continue to be produced, but the repository may contain
more-recent data than in the snapshots. At some
point in the future, once I become more comfortable with
the repository, I may stop producing the source-code
tarballs.<br>
</li>
<li>Onno Hommes forked the Virtual AGC source tree some
time ago in order to make some extensive changes to the
way debugging of AGC and AGS/AEA programs is done.
These changes relate to the ability to use <span
style="font-weight: bold;">gdb</span> style commands
rather than the command-set I had invented, and to
integrate with GUI debugger front-ends such as <span
style="font-weight: bold;">Code::Blocks</span>.
In other words, Onno made debugging AGC programs a lot
nicer. The source trees have now been
re-merged. <span style="font-weight: bold;">yaAGC</span>
debugging has switched entirely to the new method, and
the "classic" method previously described on the <span
style="font-weight: bold;">yaAGC</span> page has been
eliminated. <span style="font-weight: bold;">yaAGS</span>
debugging is still undergoing change in this direction.</li>
<li>When command-line debugging of AGC/AGS programs is
being done, both <span style="font-weight: bold;">yaAGC</span>
and <span style="font-weight: bold;">yaAGS</span> now
use <span style="font-weight: bold;">readline</span>
style command-editing and command-histories on all
platforms. I had been unable to provide this
feature on several platforms previously.<br>
</li>
<li>There is now a native-Windows build procedure listed
on the download page, again thanks to Onno.</li>
<li>The FreeBSD native build procedure may or may not be
broken. I can't tell, because I've broken my
FreeBSD installation.</li>
<li>I've reduced some 30-second startup delays I
introduced in the last snapshot to 5 seconds. The
delays were based on the worst-case characteristics of
some very slow test machines I am using, but aren't
necessary for more-normal computers. I've instead
added some configuration instructions to the download
page if someone should need the longer delays.</li>
<li>The cross-build instructions given in previous
snapshots were wrong, in that some aspects would work
only if my username and directory setup were used.
Hopefully this is fixed now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-21<br>
</td>
<td style="vertical-align: top;">The <span
style="font-weight: bold;">VirtualAGC</span> 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
difference.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-15<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Can now build Virtual AGC natively in Mac OS X—at
least in 10.5.6 Intel—and I have added the instructions
for doing so on the download page.</li>
<li>Can now build <span style="font-weight: bold;">yaAGC</span>,
<span style="font-weight: bold;">yaAGS</span>, <span
style="font-weight: bold;">yaYUL</span>, and <span
style="font-weight: bold;">yaLEMAP</span> in
OpenSolaris. But I haven't worked out any
instructions for doing so. Perhaps at the next
OpenSolaris release I'll be able to get it fully
working.</li>
<li>Finally got around to talking (on the downloads page)
about Onno's debugger work, and giving a link to Onno's
page. It was a silly oversight not to do so
earlier.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-12<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Dean Koska's YouTube demo of his Palm Centro port of <span
style="font-weight: bold;">yaAGC</span> with his
custom DSKY has been added to the homepage.<br>
</li>
<li>Configuration of the joystick for the ACA simulation,
though simplified from previous times, was still
annoyingly intricate. I've added small GUI program
called <span style="font-weight: bold;">jWiz</span> to
hopefully simplify the configuration process and bring
it a little closer to where it needs to be.
There's a button marked "Handler" next to the <span
style="font-weight: bold;">VirtualAGC</span> checkbox
that enables the ACA, and clicking the button calls up <span
style="font-weight: bold;">jWiz</span>. <a
href="yaTelemetry.html#yaACA"><span
style="font-weight: bold;">jWiz</span> usage is
fully explained</a> in the <span style="font-weight:
bold;">yaACA</span>/<span style="font-weight: bold;">yaACA3</span>
documentation. <br>
</li>
<li>I've also managed to fix the annoying characteristic
of <span style="font-weight: bold;">yaACA</span> that
it couldn't display console output in Windows, and thus
you couldn't see the information you actually needed for
the joystick calibration. But it still doesn't
work in Windows in spite of that, because after its
window loses focus it never sees any more joystick
events.<br>
</li>
<li>The <span style="font-weight: bold;">yaACA2</span>
program, which has a joystick driver based on <span
style="font-weight: bold;">wxWidgets</span>, has been
added. So there are 3 separate ACA simulations to
choose from, and hopefully at least one of them will
work for you. <span style="font-weight: bold;">yaACA2</span>
doesn't seem to work in Mac OS X (though I believe I
recall that it did originally), so at least for now it's
disabled there.<br>
</li>
<li>A lot of work has been done in <span
style="font-weight: bold;">yaTelemetry</span> to
display digital-downlink data in a format that would
more closely correspond to the way ground control data
was displayed in actual missions. The associated
display formats are designated by the names MSK-683,
MSK-966, MSK-1123, and MSK-1137. However, I don't
have it actually working yet, so the extra controls
which have been added to <span style="font-weight:
bold;">yaTelemetry</span> for this purpose are
disabled and grayed-out at present.</li>
<li>In the Mac OS X version, it hasn't previously been
possible to run <span style="font-weight: bold;">yaAGC</span>
or <span style="font-weight: bold;">yaAGS</span> in
debugging mode—and wouldn't have been possible to
configure the joystick using <span style="font-weight:
bold;">jWiz</span>—because of the lack of any
command-line switches in the native <span
style="font-weight: bold;">Terminal</span> program and
the practical inability to use <span
style="font-weight: bold;">xterm</span> properly on
the 10.4 and 10.3 platforms. Therefore, on the Mac
platform we automatically include an open-source
terminal program called <span style="font-weight:
bold;">Terminator</span>, which allows <span
style="font-weight: bold;">VirtualAGC</span> and <span
style="font-weight: bold;">jWiz</span> to add back all
of the missing functionality. It still isn't possible to
use the debugger in 10.3, but it seems to be fine now in
10.4 and 10.5.<br>
</li>
<li>Discovered (and fixed) that the endian conversions
added previously to make symbol tables portable between
Intel and PowerPC platforms weren't yet working.</li>
<li>On the links page I've added a new document, the "<a
href="Documents/SMR-downsampled.tar.bz2">Saturn Ground
Control System Mathematical Subroutine Manual</a>".
Don't
get too excited, because it's not what you think it is:
the "mathematical subroutines" are algorithms for
multiplication, division, trig functions, etc.
Thanks to Dimitri Marinakis for sending this!</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-06<br>
</td>
<td style="vertical-align: top;">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 <span style="font-weight: bold;">yaACA3</span>
simulation program (which superceded the earlier <span
style="font-weight: bold;">yaACA</span> simulation program
for snapshots 20090331 and later), the <span
style="font-weight: bold;">VirtualAGC</span> GUI front-end
now allows for using <span style="font-weight: bold;">yaACA</span>
and <span style="font-weight: bold;">yaACA3</span> somewhat
interchangeably. Basically, it will use <span
style="font-weight: bold;">yaACA3</span> unless it notices
that <span style="font-weight: bold;">yaACA</span> has been
configured, and then it will use <span style="font-weight:
bold;">yaACA</span> instead. The <span
style="font-weight: bold;">yaACA</span> program has also
been tricked up similarly to the <span style="font-weight:
bold;">yaACA3</span> 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. <a
href="yaTelemetry.html#yaACA">Read about it in detail</a>
if you have experienced a non-functional joystick.
(And don't send me any jokes about that, please!)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-05<br>
</td>
<td style="vertical-align: top;">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 <a
href="download.html#FreeBSD">download page</a>. 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 <span
style="font-weight: bold;">VirtualAGC</span>, 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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-04-04<br>
</td>
<td style="vertical-align: top;">
<table summary="" style="text-align: left; width: 75%;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span style="color:
rgb(204, 0, 0);"><span style="font-weight: bold;">Big
Fat
Warning! </span> The Linux <span
style="font-weight: bold;">VirtualAgcUninstall</span>
script included in snapshots 20060226 through
20090317 will delete your /usr/local/bin directory
if you installed Virtual AGC there (or worse, will
delete /usr/bin if that was your installation
directory). Please do not run this script.<span
style="color: rgb(0, 0, 0);"><br>
<br>
The latest releases have a different
uninstaller, and don't have this problem.
I never noticed the problem, because I had been
installing to ${HOME} for a long time before
creating the original uninstaller. Big
thanks to Onno Hommes for pointing out the
problem.</span></span></td>
</tr>
</tbody>
</table>
<span style="color: rgb(204, 0, 0);"><span
style="font-weight: bold;"><br>
</span> <span style="color: rgb(0, 0, 0);">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</span></span>—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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-03-31<br>
</td>
<td style="vertical-align: top;"> 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 <span
style="font-style: italic;">corrections</span> have been
made to material on the the website itself, thanks to
Fabrizio Bernardini:<br>
<ul>
<li>We now know with a higher degree of certainty that
Luminary 1E build 210 was flown in Apollo 17 (and
probably Apollo 15-16), whereas before there was some
dispute that it might have instead been Luminary 1D
build 209. This is significant in the sense that
we're aware of a listing for 1D (and may even get a copy
of it someday), but we're not aware of the existence of
a copy of 1E. As to what the differences between
1D and 1E are, that will await future revelations!
Perhaps there are none.<br>
</li>
<li>We are now aware that AGS Flight Program 8 was used in
Apollo 15-17, rather than in Apollo 14 as previously
supposed. This is significant because we actually
have a copy of Flight Program 8 included within the
project, and it's good to know what we have!<br>
</li>
</ul>
Software-wise, lots of bugs have been fixed and auxiliary
changes associated with those fixes have been made, so that
I'm not even sure I remember them all. Here are some
of the ones that stand out in my mind as particularly
significant:<br>
<ul>
<li>There was an issue in sequencing key-releases with
shifting of buffered keypad data in communications
between <span style="font-weight: bold;">yaDEDA/yaDEDA2</span>
and <span style="font-weight: bold;">yaAGS</span>,
which could basically break AGS communications,
requiring a reboot of the simulation to fix it.
The effect was fairly repeatable if the HOLD key was hit
and then the READ OUT key was hit. I *hope* it's
fixed now. A new --debug-deda switch in <span
style="font-weight: bold;">yaAGS</span> helped me find
this one.</li>
<li>The <span style="font-weight: bold;">yaAGC</span> and
<span style="font-weight: bold;">yaAGS</span> --debug
modes were crippled using the as-distributed symbol
tables for <span style="font-weight: bold;">Luminary</span>
and <span style="font-weight: bold;">Colossus</span>,
because they embedded path names to the source-code
files that were set at compile time ... in other words,
for the symtabs I've been distributing, they pointed to
source files in directories on <span style="font-style:
italic;">my</span> computer.</li>
<li>Moreover, the symbol tables used the natural
endianness of the CPU, meaning that symbol tables
generated on an Intel architecture would not work if I
distributed them to a PowerPC architecture.</li>
<li>There was a bug in the <span style="font-weight:
bold;">yaAGC</span> core-dump and --resume, in which
half the time resuming from a core-dump would cause the
DSKY to become non-responsive. My believe is that
some state information (probably relating to interrupts)
was not being saved in the core-dumps.</li>
<li>I think there was a bug in direction flags
(displacement direction of the control stick from
detent) sent to the AGC by <span style="font-weight:
bold;">yaACA</span> when more than one axis was
displaced. The bug carried over into <span
style="font-weight: bold;">yaACA3</span> (see below)
as well, but I fixed it in both places.<br>
</li>
</ul>
In terms of new features, again there are lots. Some
of the more significant ones are:<br>
<ul>
<li><span style="font-weight: bold;">VirtualAGC</span> has
also been given a capability not present in any software
existing previously to the GUI, in that it can perform
scripted Digital Uplinks to the AGC.</li>
<li><span style="font-weight: bold;">VirtualAGC</span>
integrates AGC/AEA compilation and source-code browsing,
in addition to merely managing the simulation.</li>
<li><span style="font-weight: bold;">yaAGC</span> and <span
style="font-weight: bold;">yaAGS</span> have been
modified so that when in --debug mode they no longer
output status messages like socket connections or
disconnections of peripherals, thus giving an "easier"
to understand debugging experience.</li>
</ul>
While it is basically a feature-neutral change, the ACA
emulation program <span style="font-weight: bold;">yaACA</span>
has been superceded by <span style="font-weight: bold;">yaACA3</span>,
principally to allow the use <span style="font-weight:
bold;">SDL</span> rather than <span style="font-weight:
bold;">Allegro</span> for providing the joystick
interface. The initial motivation for this was that
Paul Fjeld (thanks, Paul!) advised that <span
style="font-weight: bold;">SDL</span>'s joystick code was
more stable than <span style="font-weight: bold;">Allegro</span>'s
on
Mac OS X. However, having made this replacement, I
find some other significant advantages, the two principal
being that there is far less configuration burden (and what
configuration there is I've integrated in a way that won't
be painful for <span style="font-weight: bold;">VirtualAGC</span>),
and
that I find I hadn't noticed before that <span
style="font-weight: bold;">yaACA</span> provides
absolutely no console feedback on Windows, making debugging
that much more painful. I've also taken the
opportunity to use static linking for <span
style="font-weight: bold;">SDL</span>, to avoid
distributing <span style="font-weight: bold;">Allegro</span>'s
dll.
So hopefully it's a win-win-win-win kind of dealio.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-03-17<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaDSKY</span> and <span style="font-weight: bold;">yaDEDA</span>
have been superceded by rewritten replacements <span
style="font-weight: bold;">yaDSKY2</span> and <span
style="font-weight: bold;">yaDEDA2</span> to improve
portability and distributability. Moreover, there is a
completely new <span style="font-weight: bold;">yaTelemetry</span>
program to replace the Digital-Downlink-monitoring
functionality previously kludged into <span
style="font-weight: bold;">yaDSKY</span> (but missing from
<span style="font-weight: bold;">yaDSKY2</span>).<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-03-05<br>
</td>
<td style="vertical-align: top;">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 <span style="font-weight: bold;">VirtualAGC</span>.
This
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 <span style="font-weight: bold;">LM_Simulator</span>
module didn't have its various very-useful help screens.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2009-03-01<br>
</td>
<td style="vertical-align: top;">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 <span style="font-weight: bold;">LM_Simulator</span>
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 (<span style="font-weight: bold;">SimColossus249</span>,
<span style="font-weight: bold;">SimColossus249_lite</span>,
<span style="font-weight: bold;">SimArtemis072</span>, or <span
style="font-weight: bold;">SimArtemis072_lite</span>) 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.<br>
<br>
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.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2008" onchange="viewOrHide(2008)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2008 change notes?</b>
<table summary="" id="table2008" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2008-02-14<br>
</td>
<td style="vertical-align: top;">Added a <a
href="Pultorak.html#Whos_Building_Them">nifty photo</a>
Alessandro Cinquemani has sent in of the Pultorak-style
AGC/DSKY he is constructing.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2008-02-05<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>We've had word of another AGC physical implementation,
by Philip Schmidt. We're not hosting it here,
though we'd be delighted to. <a
href="Pultorak.html#Philip_Schmidts_Block_I_AGC">Check
it out!</a><br>
</li>
<li>Dimitris Vitoris has sent us an update to his AGC
physical implementation, which now includes most of the
'A1' phase of his Block I design. (See <a
href="Pultorak.html#Dimitris_Vitoriss_Block_I_and_Block_II">here</a>.)
Here
is his own description, slightly edited for time and
content, and to fit on your screen:</li>
</ul>
<br>
<div style="margin-left: 40px;">
<div> <font size="2" face="arial,helvetica,sansserif">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</font> <font
size="2" face="arial,helvetica,sansserif">and I'll
have to elevate the displays. Also I plan to
design</font> <font size="2"
face="arial,helvetica,sansserif">my DSKY in such a way
that it can be used in any revision I</font> <font
size="2" face="arial,helvetica,sansserif">plan to make
by just exchanging it's I/O daughterboard.</font> <font
size="2" face="arial,helvetica,sansserif">You'll find
that there are 5 new elements in this revision:</font>
</div>
<ul>
<li><font size="2" face="arial,helvetica,sansserif">DSKY</font></li>
<li><font size="2" face="arial,helvetica,sansserif">Monitoring
and Control Assembly - Driver
Module (MCADM)</font></li>
<li><font size="2" face="arial,helvetica,sansserif">Monitoring
and Control Assembly - Logic
Module (MCALM)</font></li>
<li><font size="2" face="arial,helvetica,sansserif">Monitoring
and Control Assembly - Memory Module (MCAMM)</font></li>
<li><font size="2" face="arial,helvetica,sansserif">Master
Controller</font></li>
</ul>
<div> <font size="2"
face="arial,helvetica,sansserif">The MCAs
are the separated monitoring busses and control
switches from each A0 module. The MC is the main
power distribution hub,</font> </div>
<div> <font size="2" face="arial,helvetica,sansserif">panel
illumination controller and using it you can power
down any or all the monitoring panels at will.</font>
</div>
<div> </div>
<div> <font size="2" face="arial,helvetica,sansserif">I
have attached together with the A1 schematics the
following:</font></div>
<ol>
<li><font size="2" face="arial,helvetica,sansserif">My
custom libraries for the PSA05-12GWA Kingbright
alphanumeric display and for the RS 336-191
illuminated keys. You'll have to put those 2 in the
'lbr' directory of EAGLE before opening the DSKY
schematic (only used there).</font></li>
<li><font size="2" face="arial,helvetica,sansserif">The
datasheets of PSA05-12GWA and HDSP-5601 plus
dimensions and a pic of 336-191. </font>
[Actually, I have held back these datasheets for
copyright reasons. I'll certainly maintain a
private archive of them here, in case someone
absolutely can't get their hands on them in a 'legal'
way—Ron Burkey]<font size="2"
face="arial,helvetica,sansserif"><br>
</font></li>
<li><font size="2" face="arial,helvetica,sansserif">A
draft correction log of A1.</font></li>
</ol>
<div> <font size="2"
face="arial,helvetica,sansserif">As before these
schematics should NOT be considered final and may
contain errors. Looking forward for your comments and
suggestions!</font> </div>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2008-01-13<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>I've discovered a change in the status of the <span
style="font-weight: bold;">CircuitMaker2000</span>
program needed to work with John Pultorak's Block I
schematics, so I've added some textual comments related
to that situation.<br>
</li>
<li>Meanwhile, Dimitris Vitoris has sent some minor
corrections to his own <span style="font-weight: bold;">Eagle</span>-based
Block
I AGC schematics. In his words:</li>
<ul>
<li>
<div> <font size="2" face="arial,helvetica,sansserif">I
forgot to connect 1_CONTROL_BUS Net19 to U45D in
the LOGIC MODULE ALU #5.</font> </div>
</li>
<li>
<div> <font size="2" face="arial,helvetica,sansserif">Also
I named U135 as R135 by mistake which lead to the
comment #4 situation (Logic</font> </div>
<div> <font size="2" face="arial,helvetica,sansserif">Module
section of my changelog). After that it's
R135 again as the original and not R201.</font> </div>
</li>
<li><font size="2" face="arial,helvetica,sansserif">That
thing is so complex my head hurts...</font></li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2008-01-03<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Onno Hommes has updated the AGC <a
href="OnnoHommes/SyntaxAGC-20071231.zip"> source
highlighting</a> so that it includes <span
style="font-weight: bold;">vim</span> (both Linux and
Windows) and <span style="font-weight: bold;">TextPad</span>.
He
also indicates that when all this stuff is installed, <span
style="font-weight: bold;">emacs</span> also
highlights correctly (but he isn't sure why).</li>
<li>Dimitris ("Jim") Vitoris has sent us some electrical
CAD files using the <span style="font-weight: bold;">Eagle</span>
schematic-capture program that provide an alternate
editable form of the physical Block I AGC simulation
pioneered by John Pultorak and available elsewhere on
this site. This is only the first step of what
we're hoping ... keep fingers crossed! ... will be a
physical Block II simulation. <a
href="Pultorak.html#Dimitris_Vitoriss_Block_I_and_Block_II">Check
it
out</a>!<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2007" onchange="viewOrHide(2007)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2007 change notes?</b>
<table summary="" id="table2007" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2007-12-28<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Josef (Jeff) Sipek is now generously mirroring the
Virtual AGC website, and a link to his mirror has been
added on the links page. Thanks, Jeff!
Actually, he has been doing so for some months.</li>
<li>Onno Hommes has sent us some configuration files (and
a nice set of instructions) for adding AGC-specific
syntax-highlighting for the following source-code
editors: <span style="font-weight: bold;">Kate</span>,
<span style="font-weight: bold;">KWrite</span>, <span
style="font-weight: bold;">Kdevelop</span>, and <span
style="font-weight: bold;">Eclipse</span>. You
can now get these from the <a
href="download.html#Extras">download page</a>.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-04-25<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Fixed lots and lots of broken or workable but
ill-formed links throughout the website.</li>
<li>Stephan tells us that v1.0 of his "stand-alone"
Windows executable has some startup problems, and has
sent a revised version of it.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-04-22<br>
</td>
<td style="vertical-align: top;"> Stephan Hotto has sent
version 1.0 of <span style="font-weight: bold;">LM_Simulator</span>,
both in source code and in the Windows "stand-alone"
executable version, with the following notes:<br>
<ul>
<li>FDAI now fully functional! The attitude looks a bit
confusing around \B190 degrees Yaw but that is for the
reason that LM_Simulator does not uses a real
3-dimensional ball to show the attitude. Please keep in
mind that the LM-IMU has its Gimbal Lock Condition on
the Roll-Axis and not on the Yaw-Axis like the Command
Module has.</li>
<li>A Checkbutton in the FDAI window now allows to switch
off the 8-Ball for computers with low performance.
[LM_Simulator's CPU performance has been greatly
improved from a month or two ago, but you still might
like to reduce it some, and updating the 8-ball is the
majority of the CPU time used by LM_Simulator.
Thus, the option for switching it off.]<br>
</li>
<li>FDAI angles are additionally presented as numerical
values.</li>
<li>New lm_configuration.ini parameters:</li>
<ul>
<li>Operationg_System "Windows/Linux" - To allow one
source code for both operating systems.</li>
<li>FDAI_Update_Rate "updates per second" - Choose a
lower value if you experience performance problems.</li>
</ul>
<li>New HTML documentation as well as re-work of the
existing documents. [The HTML documentation is in
the development snapshot under the directory
Contributed/LM_Simulator/Documentation, whereas the
ASCII documentation is in Contributed/LM_Simulator/doc.]</li>
</ul>
Please remember if you're using the development snapshot
(rather than the Windows stand-alone executable) that to
take complete advantage of the pad loads in the latter-day
versions of <span style="font-weight: bold;">LM_Simulator</span>,
you have to copy Contributed/LM_Simulator/LM.core into the
directory from which you intend to run the simulation.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-04-17<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Stephan Hotto has sent over what he refers to as a
"stand-alone" version of the simulation for
Windows. It is a lot easier to install than the
full version of Virtual AGC --- not least because I
don't update the Windows version very often --- but is
very <span style="font-weight: bold;">LM_Simulator</span>-centric.
For
example, it doesn't include the Abort Guidance System
simulation. Check it out on the download page!</li>
<li>I've improved several of the documents in the HRST
archive. Not much, but a little!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-04-16<br>
</td>
<td style="vertical-align: top;">I have found a backdoor into
the <a
href="http://authors.library.caltech.edu/5456/1/hrst.mit.edu/index.html">
"archived" HRST website</a>, and modified the links page
accordingly. However, I'll still continue to host the
documents, because it gives me a chance to improve them.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-04-15<br>
</td>
<td style="vertical-align: top;">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. <a
href="hrst/ArchiveContents.html">I have decided to begin
hosting the documents formerly available from HRST, with
improvements to some of them, here at Virtual AGC.</a>
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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-04-13<br>
</td>
<td style="vertical-align: top;"> 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
<span style="font-weight: bold;">yaAGC</span>, but I
couldn't find it or fix it because I was falsely blaming the
symptoms on the <span style="font-weight: bold;">LM_Simulator</span>
changes. Hooray for laziness! But <span
style="font-weight: bold;">yaAGC</span> is now
fixed. <br>
<br>
If you're iffy about installing the new dev snapshot, here's
the executive summary of changes since 20060110:<br>
<ul>
<li>Builds again in Win32. (Not a behavioral
change.)<br>
</li>
<li>Incorporates patches used by the <span
style="font-weight: bold;">Orbiter</span>
integrators. (Not a behavioral change.)<br>
</li>
<li>Handles the BRUPT register properly, eliminating some
serious problems that occurred when using the digital
autopilot.</li>
<li><span style="font-weight: bold;">LM_Simulator</span>
tremendously improved in terms of bugs, CPU utilization,
and some features.<br>
</li>
</ul>
Enjoy!<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-03-17<br>
</td>
<td style="vertical-align: top;"> Busy Stephan has sent still
another <span style="font-weight: bold;">LM_Simulator</span>
update, as follows:<br>
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>
now has its own RHC/ACA (Rotational Hand Controller) and
THC (Translational Hand Controller). Both are
implemented as simple GUI-Elements (Sliders and
Buttons). [In other words, if the joystick
interface provided by the <span style="font-weight:
bold;">yaACA</span> program doesn't work for your
joystick, or you don't have a joystick, or you're just
not very good at operating the joystick, you can now
replace it with <span style="font-weight: bold;">LM_Simulator</span>.]<br>
</li>
<li>A minor change in the RCS calculation allows now the
usage of translational commands without influencing the
rotation of the vessel.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;"><span style="font-family:
monospace;">2</span>007-03-16<br>
</td>
<td style="vertical-align: top;"> Stephan has sent another <span
style="font-weight: bold;">LM_Simulator</span> update,
which he describes as follows:<br>
<br>
<div style="margin-left: 40px;"> Now the FDAI shows the
correct 8-ball angles - currently with a limitation to:<br>
<div style="margin-left: 40px;"> Yaw: 0Deg \B190Deg<br>
Pitch: 0Deg \B190Deg<br>
Roll: Anyway limited by the Gimbal Lock condition at
0Deg \B185Deg<br>
</div>
<br>
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.]<br>
<br>
The CPU load maximum lies around 20% on an Intel Core Duo
2.13GHz processor.<br>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2007-03-05<br>
</td>
<td style="vertical-align: top;"> 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!<br>
<ul>
<li><span style="font-weight: bold;">yaAGC:</span>
The
AGC architecture allows for a wacky feature using the <span
style="font-family: monospace;">BRUPT</span> register,
in which an interrupt-service routine can place in
instruction into <span style="font-family: monospace;">BRUPT</span>
to be executed upon return from interrupt. In
other words, the instruction executed upon return from
an interrupt doesn't have to be the instruction that's
at the location to which the program returns. I
had implemented this feature, but couldn't figure out
why anyone would want to do anything so crazy, and so
disabled it by default. 'x15' of the group which
has integrated Virtual AGC into the <span
style="font-weight: bold;">Orbiter</span> spacecraft
simulator has discovered that this feature <span
style="font-style: italic;">does</span> need to be
activated for proper operation, as the multi-tasking
performed by the program executive makes use of
it. The effect of turning off this feature is that
the digital autopilot will hit the dreaded <span
style="font-family: monospace;">EDRUPT</span>
instruction, and hence reset the AGC from time to
time. Hence, it is now activated by default.
(You can get this feature without a new download by
compiling Virtual AGC with the command "make
-DALLOW_BSUB".)<br>
</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Stephan
Hotto has sent in a major update, v. 0.8, that he
describes as follows:</li>
</ul>
<ul style="margin-left: 40px;">
<li>Critical Bug Fixes!!!</li>
<li>Implementation of a precise RCS-Thruster simulation by
using the transformation between the U,V and P,Q,R
systems</li>
<li>Complete rework of the IMU/FDAI which had errors in
the coordination transformation between Pilot axes and
Stable Member axes.</li>
<li>CPU load now below 25% on an Intel Core Duo 2.13GHz
processor</li>
</ul>
<div style="margin-left: 40px;"> Additionally, Stephan tells
us:<br>
<br>
<div style="margin-left: 40px;"> 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.<br>
<br>
There was a major bug in the IMU coordination
transformation that caused the DAP instabilities.<br>
<br>
Furthermore, to handle single RCS jet events it was
necessary to transform the U,V jet system into the P,Q,R
pilot axes.<br>
<br>
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.<br>
<br>
To assure the right AGC initialization it is necessary
to stick to the following pre-conditions and steps:<br>
</div>
<ol style="margin-left: 40px;">
<li>yaAGC has to be compiled with: "make
CFLAGS=-DALLOW_BSUB". (This is now the default.)<br>
</li>
<li>The LM.core file delivered with the on hand
LM_Simulator package has to be used because it is
populated with the necessary pad load data</li>
<li>After start of the simulation the following steps
have to be executed (please use the Tutorial as a
reference):</li>
</ol>
<ul style="margin-left: 80px;">
<li>V36E to reset the AGC</li>
<li>V37E 00E to start the idle program. Probably there
is a need to do this a couple of times until PROG
shows 00</li>
<li>V48E (DAP Initialization) -> V21E to change the
value to 21022 (ACA Fine Scaling 4Deg/Sec)</li>
<li>AGC Crew Inputs -> Set "Attitude Hold Mode" to ON</li>
<li>V77E (Rate Command and Attitude Hold Mode)</li>
<li>V61E (DISPLAY DAP FOLLOWING ATTITUDE ERRORS)<br>
</li>
</ul>
<ol style="margin-left: 40px;" start="4">
<li>Now the DAP should enable you to steer the LM.
!!!Please steer slowly to avoid that the simulation
gets overloaded!!!</li>
<li>Use "V49 Crew Defined Maneuver" to let the DAP steer
the LM to the selected attitude</li>
</ol>
</div>
<ul>
<li>hrst.mit.edu, the mother-lode of documentation for the
AGC, has apparently given up the ghost. Links at
the former site imply that an archive site exists at
caltech.edu, but that archive site is apparently "under
construction", and has been for the past six months (as
I write this). I have archived the complete
contents of hrst.mit.edu, so if the caltech.edu
site does not come up eventually, I'll host all of the
old hrst.mit.edu docs myself. If you have an
opinion on this, let me know. (Thanks, Geoff!)</li>
<li>Eugene Dorr has written with such a rave review of
"Computer for Apollo", one documentary from a 2-DVD set
of documentaries called "Mission to the Moon" (available
from <a href="http://www.spacecraftfilms.com">www.spacecraftfilms.com</a>),
that
I feel obliged to mention it even though I have not yet
seen it myself. Apparently, it shows
demonstrations of using the AGC, as well as covering the
AGC's manufacture.</li>
<li>Onno Hommes has written with nice apologia for the
interpreter language used in some AGC programming.
I've made a few changes to the assembly-language manual
based on his comments.</li>
<li>Charles Chapman has pointed out that some of the links
on the yaAGC page were pointing to my local disk, and
weren't web-accessible.</li>
<li>Others have written to mention problems with the
Windows scripts, which I hope to take care of soon.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2006" onchange="viewOrHide(2006)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2006 change notes?</b>
<table summary="" id="table2006" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2006-02-26<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Orbiter</span>:
Various source-code changes have been made to make
integrating new Virtual AGC versions with Orbiter more
routine. (Thanks to Mark Grant.) In case you
haven't been watching the efforts being made in Orbiter,
the integration has been making great strides
lately. There is talk that flying a complete
Apollo 8 mission in Orbiter may be possible in the near
future. Check it out!<br>
</li>
<li>Linux: When building Virtual AGC, 'make install'
now creates an uninstallation script called <span
style="font-weight: bold;">VirtualAgcUninstall</span>.
I
assume this will work on any *nix type system, but I
admit I haven't made any effort to try it out except on
Linux.</li>
<li>Win32: Recent versions haven't being building on
Win32. (Thanks to Peter Joseph for pointing this
out.) This is now fixed.</li>
<li>Mac OS X: Instructions by Fabrizio Bernardini
have been added to the download page for installing the
Virtual AGC binaries on Mac OS X 10.4. Some time
ago I removed the instructions for installing binaries
on Mac OS X, because it just wasn't any easier than
building from source. However, it has apparently
become much easier.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2006-01-10<br>
</td>
<td style="vertical-align: top;"> 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.<br>
<br>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"><span
style="font-weight: bold;">Milestone</span>:
The <span style="font-weight: bold;">Artemis072</span>
(Colossus 3) command-module software from Apollo
15-17 can now be run in the simulation! Simply
use the startup scripts <span style="font-weight:
bold;">SimArtemis072</span> or <span
style="font-weight: bold;">SimArtemis072_lite</span>
wherever the scripts <span style="font-weight:
bold;">SimColossus249</span> or <span
style="font-weight: bold;">SimColossus249_lite</span>
would have been used before. I leave to those
of you who are more expert than I the task of
evaluating it.<br>
</td>
</tr>
</tbody>
</table>
<br>
Unfortunately, it may be quite a long time before the <span
style="font-style: italic;">source code</span> for
Artemis072 is available, so we'll just have to live with
having only the executable for a while.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2006-01-09<br>
</td>
<td style="vertical-align: top;">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.)<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2005" onchange="viewOrHide(2005)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2005 change notes?</b>
<table summary="" id="table2005" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2005-12-24<br>
</td>
<td style="vertical-align: top;">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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-11-06<br>
</td>
<td style="vertical-align: top;">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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-10-29<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC:</span>
If
you use the VIEW command in --debug mode, the value of
the variable will always print at least once now, even
if it doesn't change.</li>
<li>General: I had to make a couple of minor tweaks
to get Virtual AGC to build in OpenSUSE 10.0. Note
that if you upgrade from SuSE 9.x to openSUSE 10.0,
you'll probably need to rebuild <span
style="font-weight: bold;">Allegro</span>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-10-17<br>
</td>
<td style="vertical-align: top;"> 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 <span style="font-weight: bold;">yaAGC</span>
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!)<br>
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:</li>
<ul>
<li>The PCDU and MCDU commands (used by the simulated
IMU to update the CPU counter registers related to
gimbal-angle measurements) have been split into two
separate commands each, one of which is a "fast" count
at 6400 counts per second, and the other of which is a
"slow" count at 400 counts per second. This
replaces the 800 count-per-second buffering used in
the 2005-10-05 snapshot. (But there's some doubt
as to whether it actually works yet!)</li>
<li>The WATCH command (used in --debug mode) has been
fixed so that it accepts symbolic variable names in
addition to numerical addresses.</li>
<li>A new command called VIEW has been added to --debug
mode. It works similarly to WATCH, except that
it displays the values of variables in real time
rather than interrupting execution upon change.<br>
</li>
</ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Stephan
Hotto has sent us v0.7.</li>
<ul>
<li>The timing of the Jet Firing, the timing of the
dynamic simulation, and the FDAI refresh rate have
been decoupled. This reduces the CPU time, as
well as making the firing of the jets snappier.</li>
<li>Fast/Slow Increment/Decrement of the IMU AGC counter
to pass the KALMAN-Filter.</li>
<li>Tutorial extended: "V49E Crew Defined Maneuver
Routine"</li>
<li>Final Gimbal Lock of the FDAI now at >85 degrees</li>
<li>Moment of Inertia factor removed (ini-file and
program)</li>
<li>There is an LM.core file --- i.e., a snapshot of
erasable memory --- in which Stephan has performed a
number of erasable pad loads related to things like
the LM mass. (This contrasts with the default
LM.core, which is all zeroes, and in which nothing is
initialized.) If you want to use it, please copy
it from yaAGC/Contributed/LM_Simulator into the
directory from which you run SimLuminary131.
(Probably your home directory.)</li>
</ul>
<li><span style="font-weight: bold;">yaDSKY</span>
web-page: Some image links were broken.
Thanks to Anthony Rich for pointing them out.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-10-05<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Provides a complementary feature to yesterday's <span
style="font-weight: bold;">LM_Simulator</span> update,
in that it internally buffers all PCDU or MCDU commands
to the CDUX, CDUY, and CDUZ counter registers, and
actually applies them to the counters at an 800 cps
rate. In other words, the simulated IMU can feed
in new angle measurements as fast as it likes, but they
are now applied to the simulated AGC's internal counters
only at an 800 cps rate. The reason for this is
that the real IMU communicated with the real AGC using
an 800 cps signal, and the digital autopilot (DAP) in
the Luminary/Colossus software employs a digital filter
based on this assumed counter update rate. The
filter was intended to eliminate electrical noise and or
noisy angles due to the vibration of the spacecraft, but
it also has been causing rejection of changes to the
CDUX, CDUY, and CDUZ counters that don't conform to the
assumed 800 cps timing. Consequently, the
simulated IMU has been feeding info on the spacecraft
orientation to the simulated CPU, but the DAP has been
rejecting this info. I don't claim that this
change has been extensively tested, though, and an
erasable pad load is needed to set the DAP's "Kalman
filter" characteristics, or else the CDU inputs will
continue to be rejected anyhow. (But I don't quite
know what those pad loads are yet.) Thanks, as
usual, to Stephan for figuring this out.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-10-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Another
v0.6 (but this time really saying 0.6 in the window
title). This should work a little better with
tomorrow's <span style="font-weight: bold;">yaAGC</span>
update, as it is intended to be able to feed in IMU
orientation changes at (at least) and 800 cps rate, so
as to avoid falling behing the AGC software's
expectations about update rates.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-10-03<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Another
update, v0.6, thanks to Stephan Hotto. (The main
window still says "v0.5", but don't worry about
that.) Here are the changes:</li>
<ul>
<li>Documentation revised</li>
<li>Code clean up</li>
<li>Changed the switch handling of the DAP Mode Switch
within the Crew Switch Window.</li>
<li>Rotational Model Moment of Inertia Calculation bases
now on the same hyperbola equation as used by the AGC
state estimator<br>
</li>
<li>Roll, Pitch and Yaw Rate-Indicators added. In the
real LM the data for these indicators came from the
fixed mounted gyro rate assembly unit.<br>
</li>
<li>Error Needles added. The data shown by the error
needles can be switched between 3 modes:<br>
<ol>
<li>DSKY: V61E -> DISPLAY DAP FOLLOWING ATTITUDE
ERRORS. This is the standard mode. The needles
show how far the DAP is away from the wished axes
positions.</li>
<li>DSKY: V62E -> DISPLAY TOTAL ATTITUDE ERRORS
WITH RESPECT TO NOUN 22. Here the needles
display the absolute difference between the entry
shown by V16N22E and V16N20E. Normally used for
automatic positioning.</li>
<li>DSKY: V60E -> DISPLAY VEHICLE ATTITUDE RATES
ON FDAI ERROR NEEDLES. These outputs should
provide the same information as the FDAI rate
indicators do. The Roll, Yaw and Pitch rate shown
by the FDAI bases on a separate Rate Gyro Assembly
fixed mounted to the LM body, whereas the
Information on the needles shown by V60E is
derived from the AGC measurement of the angular
changes. This is also a backup mode in case of a
Rate Gyro Assembly Fault.</li>
</ol>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-09-25<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Stephan
has sent us a new version, designated v0.5. Here
are the changes:</li>
<ul>
<li>Stage Separation</li>
<li>Ascent Engine (Veryfication shows that the engine
exactly reaches the defined delta V).</li>
<li>Extension of the config file by adding the ascent
engine parameter</li>
<li>Elaboration of the Help text</li>
</ul>
<li><span style="font-weight: bold;">yaAGC</span> & <span
style="font-weight: bold;">yaAGS</span>: Several
people have pointed out to me that Virtual AGC no longer
builds properly on their *nix systems, because of new
dependencies I've forgotten to document. Namely,
you now need "readline-devel" and "curses" (or else
"ncurses" with a symbolic link making it appear to be
"curses"). Now documented in the build
instructions.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-09-20<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaDSKY</span>:
"Accelerator keys" have been added, thanks to Christian
Bucher. The hotkeys are: <span
style="font-family: monospace; font-weight: bold;">vne0123456789+-</span>.
Note
that the hotkeys for VERB, NOUN, and ENTR are
lower-case. There are no hotkeys for RSET, CLR,
and PRO.</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:
A
lot of changes, thanks to Stephan Hotto. You
should particularly note the changes to the tutorial (in
the Contributed/LM_Simulator/doc directory).
Here's what Stephan has to say about it:<br>
</li>
</ul>
<div style="margin-left: 40px;">
<ul>
<li>Used the new LM-Coordinates to re-code the whole
IMU-Module</li>
<ul>
<li>IMU Coarse Align</li>
<li>IMU Fine Align</li>
<li>PIPA Vectors</li>
</ul>
<li>Gimbal Lock (Middle Gimbal) on LM-Z-Axis (Roll-Axis)</li>
<li>Complete re-work of the RCS Thruster handling:</li>
<ul>
<li>4 Thruster Mode along X, Y, Z axes</li>
<li>2 Thruster Mode (Minimum Impulse Mode) along X, Y,
Z, U, V axes</li>
</ul>
<li>Remark: THC (Crew-Inputs) activates the correct
thrusters to translate the LM along the X,Y,Z axes.
This increase in speed is not jet reflected within the
IMU PIPAs.</li>
<li>Update of the tutorial to reflect the DAP mode and
data load routines.</li>
</ul>
The summary of these changes is that for some time we've
been trying to correctly match all of the various thrust
and rotational axes of the simulation with the axes
assumed by the Luminary and Colossus, and hopefully have
them all correct now. However, the DAP is not yet
stabilizing the LM even after loading the correct data
(e.g. LM weight) as in the updated tutorial. It just
bounces back and forth around the desired orientation,
until it runs out of fuel. Obviously, we're still
working on figuring that out!<br>
</div>
<ul>
<li>Web: The fragments of Stephan's tutorial (see
above) which had been on the <a href="yaTelemetry.html">yaOtherStuff</a>
page have been removed, and the reader is instead
directed to Stephan's real tutorial in the development
snapshot. (It was too hard to keep the two in
sync.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-09-14<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaACA</span> and <span
style="font-weight: bold;">LM_Simulator</span>:
The sign of yaw has been reversed, thanks to Stephan's
feedback.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-09-09<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
(Thanks
to Stephan Hotto.) The mapping of pitch/yaw/roll
axes to thruster/joystick axes has been modified.
The ATTITUDE HOLD mode thus now actually works (and
attempts to hold the attitude) rather than merely
allowing thrusters to fire. However, there is an
overcompensation, so that the attitude overshoots,
resulting in continual corrections and eventual
exhaustion of fuel. This may be due to mismatch
between the AGC's and IMU's assumptions about the LM's
inertial characteristics. At any rate, it's a big
improvement, but we haven't crossed the finish line yet.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-28<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC:</span>
The freeze-up problem in ATTITUDE HOLD mode has been
fixed, I hope. For anyone who has been holding off
on downloading new development snapshots, I think it's
okay to do so now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-23<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
In "--debug" mode, a "WATCH A V" command has been added,
to allow breaking upon the value stored at an address
changing to a <span style="font-style: italic;">specific</span>
value. (Whereas the already-existing "WATCH A"
simply broke upon <span style="font-style: italic;">any</span>
change.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-22</td>
<td style="vertical-align: top;">
<ul>
<li>In general: All uses of <span
style="font-family: monospace;">unsigned long long</span>
now replaced by <span style="font-family: monospace;">uint64_t</span>,
to make it easier to build Virtual AGC with MS Visual
C++ (which is apparently being done for integration with
<span style="font-weight: bold;">Orbiter</span>).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-21<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:</li>
<ul>
<li>Fixed the calculation of "patterns" in fixed memory
in "--debug" mode.</li>
<li>Added detection of certain types of infinite loops,
for debugging purposes.</li>
<li>The current version of yaAGC has a mysterious
problem. I'm not sure when this problem
began. (I suspect the underlying problem was
always present, but that it was masked by other
problems in versions 20050814 and prior, so that it
was not noticeable.) The problem can be observed
as follows: Suppose you run <span
style="font-weight: bold;">Luminary131</span>, then
you activate ATTITUDE HOLD mode, then you use the hand
controller to fire the thrusters. At some later
time, you'll find that the AGC has become largely
unresponsive, though it still responds in an automatic
way to certain stimuli. The only way of
recovering from this is to restart the
simulation. Fixing this problem is my top
priority at present.</li>
</ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Stephan
has sent over a new version, differing principally in
that it supports combined pitch & roll control from
the hand-controller. <br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-20</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>: <br>
</li>
<ul>
<li>The DELETE command in debugging mode was not
consistent in format with the BREAK command, and (in
fact) was broken for numerical addresses; this is now
fixed.</li>
<li>There had been a problem for some time, in which
activating ATTITUDE HOLD mode caused a program alarm
32000. I think this has now been fixed, with the
advice from a number of people. (Specifically,
Julian Webb, Hugh Blair-Smith, and Mike Higgins.
I hope I haven't forgotten anybody; if so, my
apologies!)<br>
</li>
</ul>
<li>Assembly-language page: Heavily modified the
description of the <span style="font-family:
monospace;">EDRUPT</span> instruction. This
change relates to the latter bullet point above.<br>
</li>
<li>FAQ: Mark Grant has sent me a more exciting
screenshot from the <span style="font-weight: bold;">Orbiter</span>
integration project, showing the DSKY during liftoff.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-17</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Christian Bucher has fixed an embarrassing bug for
me. (For arithmetic with a double-precision
negative value in which the less-significant word was
+0, the more-significant word would have been
arbitrarily converted to -0. Admittedly, I don't
know if this situation ever occurred in practice, but
it's great to have it fixed.) Also, Markus Joachim
has sent a fix for timing in some output pulses
generated by the CPU; the timing error was not
perceptible in a human sense, but caused some program
alarms in the <span style="font-weight: bold;">Orbiter</span>
integration.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-15<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Web-pages: Stephan Hotto send me some nifty
photos of the AGC and DSKY taken at the Computer
Historic Museum in Palo Alto. I've incorporated a
few of these into the <span style="font-weight: bold;">yaAGC</span>
and <span style="font-weight: bold;">yaDSKY</span>
pages. The ones on the <span style="font-weight:
bold;">yaAGC</span> page show some of the inner
construction of the AGC. The one on the <span
style="font-weight: bold;">yaDSKY</span> page is nice
because it's almost head-on, and therefore shows the
relative sizes (of buttons vs. indicator lamps vs.
numerical display) with reasonable accuracy.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-14<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Building <span style="font-weight: bold;">yaAGC</span>
and <span style="font-weight: bold;">yaAGS</span> in
Win32: "x15" points out that the <a
href="http://sources.redhat.com/pthreads-win32/">Pthreads-w32
project</a>, needed for building <span
style="font-weight: bold;">yaAGC</span> and <span
style="font-weight: bold;">yaAGS</span> in Win32, has
changed its library-naming, so that you can't use newer
versions of this library without manually editing a
couple of Virtual AGC makefiles. The stock Virtual
AGC makefiles now auto-select a Pthreads-w32 library
version in a way that's hopefully adequate to obviate
the need for manual editing. Note that I've not
personally had the chance yet to try it out with the
newer versions of Pthreads-w32, so your mileage may
vary.<br>
</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Stephan
has sent over a new version of <span
style="font-weight: bold;">LM_Simulator</span>, with
the following changes:</li>
<ul>
<li>CPU Load reduction</li>
<li>Smaller font to reduce window sizes</li>
</ul>
<li>Luminary page: Some clarifications have been
added, relating to discrepancies in the known versions
of Luminary 099.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-13</td>
<td style="vertical-align: top;">
<ul>
<li>Interoperability with <span style="font-weight:
bold;">Orbiter</span> integration project:
Applied several code fixes provided as feedback from the
<span style="font-weight: bold;">Orbiter</span>
integration. (Thanks to Mark Grant.)
Specifically, header-file changes have been made that
should allow you to link Virtual AGC libraries to C++
code, and some hooks have been added for use by the <span
style="font-weight: bold;">Orbiter</span> integration
but which could theoretically by used for other purposes
as well. (I refer to the <span
style="font-family: monospace;">agc_clientdata</span>
and <span style="font-family: monospace;">ags_clientdata</span>
fields in the <span style="font-family: monospace;">agc_t</span>
and <span style="font-family: monospace;">ags_t</span>
structures.)</li>
<li> <span style="font-weight: bold;">yaAGC</span>'s
or <span style="font-weight: bold;">yaAGS</span>'s
"--debug" mode apparently did not work on some versions
of Windows, but some initialization changes have been
made to fix this. (Thanks to "x15".)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-06<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Apparently, we had been concentrating so much on <span
style="font-weight: bold;">yaAGC</span>'s "--debug"
mode, that we didn't notice that the regular (non-debug)
mode had been broken for several days, and so the usual
startup scripts like <span style="font-weight: bold;">SimLuminary131</span>
didn't work unless <span style="font-weight: bold;">yaAGC</span>
was built without readline support. Jordan has now
fixed this for us.</li>
<li><span style="font-weight: bold;">yaAGC</span> & <span
style="font-weight: bold;">yaAGS</span>: Took
care of some build-platform-specific dependencies in
finding the 'curses' library sometimes needed with the
'readline' library.</li>
<li><span style="font-weight: bold;">Win32</span> with <span
style="font-weight: bold;">Cygwin</span>: For
those of you who think my Win32 build instructions seem
too complex, Virtual AGC now seems to build with <span
style="font-weight: bold;">Cygwin</span>.
(Warning: I haven't yet gotten the <span
style="font-weight: bold;">Allegro</span> library to
install because I'm too lazy to follow the instructions,
so I haven't yet tried <span style="font-weight: bold;">yaACA</span>.)
You
have to install a huge number of <span
style="font-weight: bold;">Cygwin</span> packages
first, but fortunately that's really easy. For
now, I'll just note that you use the Linux build
instructions, and you have to do 'make NOREADLINE=yes",
because for some reason Jordan's command-history stuff
doesn't build. Also, the stuff for shutting down
all of the components of the simulation gracefully
doesn't work, so comment out the line reading "SimStop"
in scripts like <span style="font-weight: bold;">SimLuminary131</span>.
Finally,
the steps to running the simulation are to run "startx"
from a <span style="font-weight: bold;">Cygwin</span>
command line, and then to run <span style="font-weight:
bold;">SimLuminary131</span> or another startup script
from the X-terminal. I'll write up the
instructions for this in detail as I perfect it.</li>
<li>Building, in general: Now have a much better
technique, I think, for detecting the build-platform, so
there's more consistency among the build-instructions on
different platforms.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Artemis072</span>
docs: Thanks to Shelly Kelly and UHCL, we now have
the Colossus 3 Guidance System Operation Plan (GSOP)
scans ... or at least as much of them as can be located
at present. (Sections 4 and 6 are missing, but we
have sections 1-3, 5, and 7.) Section 7 is
particularly interesting, because it documents and
contains AGC assembly listings of all programs loaded
into AGC erasable core memory rather than fixed core
memory. In other words, these are the programs
that were loaded into the "RAM" by the astronauts or via
digital upload from a ground station.</li>
<li><span style="font-weight: bold;">yaAGS, yaLEMAP</span>:
Thanks
to Jordan Slott, symbolic debugging of AGS firmware (via
the "--debug" command-line switch of <span
style="font-weight: bold;">yaAGS</span>) is now
implemented. This also includes a few little
flourishes I forgot to add myself, such as a HELP
command.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-02<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGS</span>:
Courtesy of Jordan Slott, <span style="font-weight:
bold;">yaAGS</span> again has a working --debug mode,
and the command-history support in it seems to work
perfectly.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-08-01<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Jordan Slott has added a few fixes to the recent --debug
mode features. Because of the fixes, 'readline'
support is now enabled by default in the
Makefiles. <br>
</li>
</ul>
<ol>
<ol>
<li>With readline support enabled, hitting ENTER no
longer interrupted execution of the AGC program.
This has been fixed.</li>
<li>Repaired some spurious printing of prompts during
AGC program execution.</li>
<li>"Break" was no longer working. This is now
fixed. [That was my fault, not Jordan's ---
RSB.]</li>
<li><span style="font-weight: bold;">yaAGS</span> now
builds when readline support is enabled, and actually
works in Win32. In other words, you can get a
command history. <span style="font-weight:
bold;">Warning:</span> In Linux, <span
style="font-weight: bold;">yaAGS</span> --debug mode
<span style="font-style: italic;">no longer functions
properly</span>, regardless of whether you compile
with or without readline support. Hopefully that
will be fixed Real Soon Now. (If you need
--debug mode in <span style="font-weight: bold;">yaAGS</span>
under Linux or Mac OS X, please hold off on
downloading the development snapshot, since there are
no improvements in <span style="font-weight: bold;">yaAGS</span>
anyhow.)</li>
<li>There is also an issue with the prompt. When you hit
a breakpoint it does not print a ">" prompt. You
can just hit "enter" to get a prompt. (Actually,
it <span style="font-style: italic;">does</span> work
in Windows, but just not in Linux or presumably Mac OS
X.)<br>
</li>
</ol>
</ol>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-31<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Jordan has added some further frills to the --debug
mode. Here are the notes on the changes:</li>
</ul>
<ol style="margin-left: 40px;">
<li>Added the "files <regex>" debugging command.
This lists the source files matching the given regular
expression. <br>
</li>
<li>Reworked the "break" command. Now "break *address" is
used to add a breakpoint at a memory address, as in <span
style="font-weight: bold;">gdb</span>. The
"break <line>" is used to break at a line number,
whenever <line> can be parsed as an integer.
Update "help break" to reflect this change.</li>
<li>Improved the output from "breakpoints" a bit -- for
those breakpoints specified using a symbol or a line
number, it outputs the <span
class="moz-txt-link-freetext">file:line</span> from
where it can be found. Note that I do not output <span
class="moz-txt-link-freetext">file:line</span> if you
create a breakpoint using a memory address, although I
don't think this would be difficult to do.</li>
<li>Fixed a small bug in "list from,to" where the line
numbers were not being displayed.</li>
<li>Cleaned up some of my old code in symbol_table.c</li>
<li>Added the ability to use libreadline to read in the
debugger command line. The upshot is you get source file
name completion, history, etc. (<span
style="font-weight: bold;">Note</span>: Though
apparently functional, this feature is currently
disabled in the Makefile, because of some conflicts
which prevent yaAGS from building. Hopefully it
can be fixed up soon.)<br>
</li>
</ol>
<ul>
<li>Startup scripts: After performing some upgrades
on my main Linux workstation, I found that the startup
scripts (<span style="font-weight: bold;">SimLuminary131</span>,
etc.) have become unreliable and may randomly shut down
the simulation. (It's a problem in the
relatively-recently-added feature that shutting down any
component of the simulation, such as <span
style="font-weight: bold;">yaDSKY</span>, shuts down
all of the other components, such as <span
style="font-weight: bold;">yaAGC</span> and <span
style="font-weight: bold;">LM_Simulator</span>.)
This should not affect Windows users, but potentially
affect everyone else. I don't know how to fix this
problem with any satisfying degree of certainty, but
workarounds have been added that should reduce the
probability of such a random shutdown to a very low
order of probability.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-30<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span> & <span
style="font-weight: bold;">yaYUL</span>: Jordan
has greatly improved the symbolic debugging, with the
greatest improvement being that (where possible) the
actual source code is displayed rather than disassembled
source code. This lets you see not only program
labels and variable names, but even program
comments. Several versions of <a
href="yaAGC.html#LIST">the LIST command</a> have been
implemented in the debugger, so that you can get various
types of disassemblies. Also, it's all
related to the source files by filename and line number,
so it's cross-referenced much more nicely. I'd say
this feature is now at a completely satisfying stage,
from a user's point of view. <span
style="font-weight: bold;">Note:</span> The
symbol tables created for this functionality are now <span
style="font-weight: bold; font-style: italic;">quite
large</span>. (About 11 megabytes each for <span
style="font-weight: bold;">Luminary131</span> and <span
style="font-weight: bold;">Colossus249</span>.)
Therefore, you'll now find that Virtual AGC is chewing a
lot more disk space than before.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-28<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span> & <span
style="font-weight: bold;">yaYUL</span>: Jordan
Slott (thanks, Jordan!) has sent in a very cool mod that
integrates symbol tables produced by <span
style="font-weight: bold;">yaYUL</span> into the
"--debug" mode of <span style="font-weight: bold;">yaAGC</span>.
The
upshot of this is that in some cases you can use
symbolic names when debugging, rather than being forced
to use absolute numeric addresses all the time.
It's still not fully implemented, but it's pretty
valuable nonetheless. Refer to the <a
href="yaAGC.html"><span style="font-weight: bold;">yaAGC</span>
page</a> to see how to use it. Symbolic
debugging was on my wish list, but I was too lazy to do
anything about it. Besides, it was very brave of
Jordan to poke around in my source code.
(Hopefully there won't be too much emotional
scarring.) This builds and works on both Linux and
Win32, but I haven't had a chance to try it in MacOS X.<br>
</li>
<li>Scans of the Colossus 3 GSOP document have begun
filtering in. (Thanks to Shelly Kelly and U. H.
Clear Lake.) I only have section 1 and a small
chunk of section 2 right now, but more is coming.
(This is nicely coincident, of course, with the fact
that the Colossus 3 source code is also dribbling in,
and the GSOP document is basically the program
documentation.)<br>
</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
Thanks to the availability of the docs mentioned above,
all of the CM digital downlink lists have been
implemented. Therefore, <span style="font-style:
italic;">all</span> of the downlink lists are now
implemented (if not necessarily correctly).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-19</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaACA</span>:
Fixed a bug in variable-declarations that caused
compilation with <span style="font-weight: bold;">gcc</span>
2.9.x to fail (but which <span style="font-weight:
bold;">gcc</span> 3.x hadn't minded).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-17<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
The inconsistency in SBANK bits between the octals
produced by <span style="font-weight: bold;">yaYUL</span>
on Linux vs. Windows platforms has been fixed.
(One octal word in Colossus249 was being assembled
incorrectly in Win32; the incorrect octal word was being
repaired by a workaround in the makefile, but would
actually have executed properly even if it hadn't been
repaired. Now that <span style="font-weight:
bold;">yaYUL</span> is fixed, the workaround in the
Makefile has been removed.) Also, some variable
initializers which did not work properly Linux for
PowerPC has been fixed; this error manifested itself in
assembly-time error messages, but presumably could have
caused incorrect octals as well.</li>
<li>Linux PPC: Virtual AGC now builds and works on
Linux for PowerPC (or at least, on Ubuntu 5.04 for PPC).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-16<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Mac OS X: Now builts completely (including <span
style="font-weight: bold;">yaACA</span>, which hadn't
ever been built before on Mac OS X), and partakes of the
automatic shutdowns recently put into the Win32 and
Linux versions, and is so much more convenient to shut
down. Furthermore, the installation/build
instructions have been completely revamped, so the
simulation is much more convenient to run, and a little
more convenient to build.</li>
<li><span style="font-weight: bold;">yaACA</span>:
There had been a bug in which the raw joystick values as
received from the driver were being used for <span
style="font-weight: bold;">yaAGC</span>, without
applying <span style="font-weight: bold;">yaACA</span>'s
--yaw,
--pitch, and --roll adjustments, or even their default
values; for me, this only affected the Win32 platform
(with the symptom being that in ATTITUDE HOLD, the
thrusters were continually firing to increase yaw), but
it has been fixed for all platforms. The program
has been tweaked so that its timing is much more
convenient in Mac OS X. Also, if it does not find
a joystick on start-up, it keeps trying until it finds
one, so you can plug in the joystick after startup
without having to restart the simulation.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-13<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>MS Windows: A few days ago I was able to modify
the startup scripts (<span style="font-weight: bold;">SimLuminary131</span>,
etc.) in Linux so that: a) they don't open so many
useless windows; and b) they shutdown all of the Virtual
AGC apps and windows when you choose to exit from any
one of them. This is tremendously convenient, and
is theoretically possible in Windows XP Pro, but not
(apparently) in Windows XP Home, or any other version of
Windows. The facilities for doing process
management simply aren't provided in Windows in a form
usable by batch files. So instead, I've written a
program (WinAGC.exe) that accomplishes the same
thing. It's a program that simply runs groups of
programs, and then shuts down all of those programs when
any one of them shuts down. I've revamped all of
the Windows batch files (SimLuminary131.bat, etc.) so
that they take advantage of WinAGC.exe. This
should work in any version of Windows, but I've only
tried it in Windows 98 (first edition), Windows XP Home,
and Windows XP Pro. <br>
</li>
</ul>
<div style="margin-left: 40px;"> 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 <span
style="font-weight: bold;">yaAGC</span> or <span
style="font-weight: bold;">yaAGC</span> 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.<br>
<br>
Another downside is that that <span style="font-weight:
bold;">Allegro</span> and <span style="font-weight:
bold;">Tcl/Tk</span> 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 <span style="font-weight: bold;">yaACA</span>
and <span style="font-weight: bold;">LM_Simulator</span>
cannot be run, rather than ignoring it. (I must say,
though, that you really want to run both of these things,
although admittedly <span style="font-weight: bold;">yaACA</span>
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 <span style="font-weight: bold;">yaACA</span> and/or
<span style="font-weight: bold;">LM_Simulator</span> lines
by the character '#' (without quotes, of course).<br>
</div>
<ul>
<li><span style="font-weight: bold;">yaAGC</span>, <span
style="font-weight: bold;">yaAGC</span>, others:
Some fixes have been made that can prevent the CPU
utililization from shooting up to very high levels under
some circumstances.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-11<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>MS Windows: The startup scripts have some
experimental improvements that <span style="font-style:
italic;">may</span> (in Windows XP Professional only!)
allow automatic shutdown of the simulation when any of
the apps closes. I further <span
style="font-style: italic;">hope</span> that the
scripts continue to work as before in non-XP-Pro
versions of Windows. To activate the new script
feature, you need to set the environment variable XPPRO
to anything non-blank. Since I don't have a
computer with XP Pro available, I haven't been able to
try the new feature out.<br>
</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:
This
is the last version for at least a month, so enjoy now!</li>
<ul>
<li>Fixes a critical bug within DSKY Lite which causes a
serious memory problem and therefore the slows down
handling the socket data when "Attitude Hold" was
activitated. Now <span style="font-weight: bold;">LM_Simulator</span>
does not fall behind in reading socket data anymore.</li>
<li>The simulation of the joystick is very limited jet
and just in an experimental status. The steering
commands are only recognized when they are along the
three axis (Roll, Pitch and Yaw). A combined steering
command (e.g. u or v axis) is not yet
implemented. Also, the calculation of the RCS
fire time is based on the setting within the "Attitude
& Speed Control" window. The simulation just
takes the RCS thruster time and multiplies that time
with the joystick amplitude divided by 57. That
means that a full stick deflection takes the selected
time as RCS fire time.</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-10<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>: <br>
</li>
<ul>
<li>Dynamic CPU Load handling. (It's infinitely
more responsive than in the last version, and you can
ignore the workaround advice I gave on 2005-07-06.)<br>
</li>
<li>All RCS parameter and Moment of Inertia factors are
configurable within the INI file.</li>
<li>The Moment of Inertia and therefore the rotational
model are quite near the real thing. (Data
Source: CSM/LM Spacecraft Operational Data Book Volume
III Mass Properties.) Assumptions made:
Moment of Inertia along all three axes is identical
(which is obviously not completely true for the real
world). MOI change is stable over the whole LM
weight range (which is comparable with real world
behavior).</li>
<li>It now interoperates with <span style="font-weight:
bold;">yaACA</span>, so that when you turn on
attitude-hold, you can see the digital auto-pilot
(DAP) firing thrusters in response to displacement of
the rotational hand-controller (RHS). Of course,
if you don't have a 3D joystick, this will be of
little value to you. Also, the connection has
not yet been made between the thrust outputs of the
CPU and the thrust inputs of the IMU. In other
words, while the IMU can respond to thrust inputs
entered into it manually, it will not yet respond to
the thrust commands generated by the CPU. (By
the way, turning on ATTITUDE HOLD causes a program
alarm 32000---which is a CPU overload---but this is
not <span style="font-weight: bold;">LM_Simulator</span>'s
fault.
We'll worry about this problem later.)<br>
</li>
</ul>
<li><span style="font-weight: bold;">yaACA</span>:
There were lots of bits in input channel 031 that yaACA
was supposed to be setting but was not. It is now,
I hope.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Was incorrectly saving the contents of CM erasables in
LM.core rather than CM.core. In other words, the <span
style="font-weight: bold;">Colossus</span> simulation
would always start up using the <span
style="font-weight: bold;">Luminary</span>
erasables. This is now fixed.<br>
</li>
<li>In general: Virtual AGC has been opening so many
windows on your screen, that it's very difficult not
only to manage them, but also to make sure you get all
of the individual programs closed when you want to exit
the simulation. The startup scripts have now been
modified to that in Linux, so that not only are less
xterms open, but also closing any one of the
applications (like <span style="font-weight: bold;">yaDSKY</span>)
will also close all of the other applications and
windows as well. I only found out how to do this
by accident, and it's awfully convenient! I don't
know how to do this in Windows, but I'm sure I'll figure
it out one of these days. (Of course, if anybody
already <span style="font-style: italic;">knows</span>,
it would be ever so helpful ....)</li>
<li>Mac OS X: I've noticed that (as usual) the Mac
OS X version has become almost impossible to build, and
almost intolerable to use. *Sigh!*<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-09<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Artemis072</span>:
Banks
6-7 of the octal executable are now available, proofed,
and have the correct checksums.</li>
<li><span style="font-weight: bold;">yaACA</span>:
Development continued, because <span
style="font-weight: bold;">LM_Simulator</span> is now
at the point where it wants to have a rotational
hand-controller (RHC). I think <span
style="font-weight: bold;">yaACA</span> is actually
complete.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Modified to accept data from <span style="font-weight:
bold;">yaACA</span>, and to output RHC data for use by
<span style="font-weight: bold;">LM_Simulator</span>, <span
style="font-weight: bold;">yaAGS</span>, etc.
Note that <span style="font-weight: bold;">LM_Simulator</span>
has not yet been modified to take advantage of this
stuff.</li>
<li>Docs: Various RHC-related stuff added or
modified on the developer page and language-manual page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-07</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Tweaked a little to restore erasable 010 upward on
startup (rather than 020 upward). Also, most of
the machinery has been put in place to allow structural
coverage analysis of the executed flight software, but
it is not actually working yet.</li>
<li><span style="font-weight: bold;">Artemis072</span>:
Banks
4-5 of the octal executable are now available, proofed,
and have the correct checksums.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-06<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">LM_Simulator</span>:
(Stephan
continues to be a busy bee.) This is the first
version with a rotation model. (In other words,
rather than adding angular displacements around the
pitch/yaw/roll axes, you can apply thrust around the
pitch/yaw/roll axes. Once you start playing with <span
style="font-style: italic;">that</span>, it's hard to
stop!) The calculation of the "moment of inertia"
by using the LM mass distribution is not yet correctly
implemented. The values used are just
experimental. The calculation of the RCS
propellant consumption depends on the RCS impulse length
and should be correct within in the current simulation
which uses 445N for each thruster and a specific impulse
of 2840MS. The Attitude control uses an impulse
length between 0.05 - 1 second. <span
style="font-weight: bold; font-style: italic;">The CPU
usage has popped up again to very high levels in this
version, and if you're going to use it I'd suggest not
turning on the "output log".</span> However, the
rotational model is so neat to have that I'd be
reluctant to recommend <span style="font-style:
italic;">not</span> using this version.<br>
</li>
<li><span style="font-weight: bold;">Artemis072</span>:
Banks
0-3 of the octal executable are now entered, proofed,
and have correct checksums. Half of bank 043 is
(and has been) in place and proofed, but there's no way
to know if the checksum is okay with only half a bank.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-05<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Now saves the contents of erasable memory when the AGC
"powers down", and restores it when the AGC "powers up",
to preserve things like pad loads. I'm sure there
are other things that need to be restored that I'm not
restoring, or things I'm restoring that I shouldn't be,
since it always starts with OPR ERR now. But we'll
work it all out eventually. For a full explanation
(along with available adjustments) see <a
href="yaAGC.html#Resume">"--dump-time" on the <span
style="font-weight: bold;">yaAGC</span> page</a>.</li>
<li><span style="font-weight: bold;">Artemis072</span>:
Bank
0 of the octal executable has been added and proofed,
but there's still a 1-bit error in it somewhere.<br>
</li>
<li><span style="font-weight: bold;">LM_Simulator</span>
(thanks, Stephan):<br>
</li>
<ul>
<li>Fuel Flow is calculated by using the specific
impulse (3050m/s)</li>
<li>The CPU load has been heavily reduced. (By
about 50%. It's now fast enough to run in Mac OS
X 10.2, which before it was not fast enough for.)<br>
</li>
<li>The simulation initialization values (such as the LM
mass) are configurable within the INI file</li>
<li>The degree character doesn't show up correctly on
some target platforms, and has now been removed from
the FDAI/IMU window.</li>
<li><span style="font-weight: bold;">Tcl</span>
"-smooth" option removed, to allow versions of <span
style="font-weight: bold;">Tcl</span>/<span
style="font-weight: bold;">Tk</span> prior to 8.4 to
be used.</li>
</ul>
<ul>
<li>Now the simulation model for the Descent Engine is
verified by using the Tsiolkovsky rocket equation:<br>
<div style="text-align: center;"> DeltaVelocity =
Specific Impulse * ln(m0/m1), where m0 = Start Mass
and m1 = End Mass </div>
</li>
</ul>
</ul>
<div style="margin-left: 80px;"> 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. </div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Although channel 033 is an input channel, the CPU
writes to it from time to time. Bits 11-15 of the
channel are latched inputs, and the act of writing
(presumably, independent of the value) resets the
latches to 1. What <span style="font-weight:
bold;">yaAGC</span> had been doing is to treat the
channel as an output channel, which obviously is very
different. This is now fixed. (Thanks to
Markus Joachim and Mark Grant for pointing out the
problem.)</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Now
simulates the LM Weight -> Thrust -> Acceleration
-> Velocity relationship. The model does not
yet take in consideration the effect of thrust reduction
by increased velocity (Rocket Equation). (Thanks,
as usual, to Stephan Hotto.)<br>
</li>
<li><span style="font-weight: bold;">Colossus 3</span>:
I've
had small bits and pieces of <span style="font-weight:
bold;">Colossus 3</span> ("Artemis" build 072) in hand
for a while, but it was so little that there was no
point in mentioning it before. It looks like much
more of it is rolling in now, so I'm adding it to the
development snapshot as I convert it to machine-readable
form. <span style="font-weight: bold;">Artemis072</span>
is, of course, the AGC flight software for the CM in
Apollo 15-17. (Thanks to D. Thrust for making this
available!) We are adding the core-rope image
first (before the source code, that is), so that it will
be possible to run the program long before seeing or
assembling the source code. So far, memory banks 2
and 3 are present in the core-rope image and have
correct checksums.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-03</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaDSKY</span> & <span
style="font-weight: bold;">libyaAGC</span>: Made
the formatting of the downlink lists even more flexible,
by providing the option of using user-defined
functions. Made use of these to correct a few
fields in the downlink lists which have already been
completed. All LM downlink lists are now complete,
if not necessarily error-free. CM downlink lists
are barely started.<br>
</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:</li>
<ul>
<li>PIPA handling integrated. Display of Velocity data
(Meter/Second or Feet/Second) within the FDAI.</li>
<ul>
<li>By using the Attitude Simulation Window a velocity
increase in Yaw direction (Main Thrust Axis) will be
separated into the different PIPA (X,Y & Z)
components (one pulse = 0.0585Meter/Second).</li>
<li>For example: If the IMU Z-Axis is parallel to the
Yaw-Axis then the velocity increase goes directly
into the Z-PIPA. To reduce the velocity the LM has
to be rolled for 180\B0 to bring the velocity vector
in the oposite direction.</li>
</ul>
<li>Some spelling corrected ("to -> too").</li>
<li>Socket timeout (from yesterday) removed.<br>
</li>
<li>A lot of algorithm optimization.</li>
<li>The FDAI recognizes now the GIMBAL LOCK.</li>
<ul>
<li>Gimbal Lock reset is possible by "V36E" (AGC
Reset) or the Crew Input "IMU Set to 0\B0"</li>
</ul>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-02<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
My changes yesterday to fix fine-alignment had the
side-effect of causing the alignment changes to look
very jumpy on the FDAI ball. The (relative)
smoothness has now been put back in. Also, the
coarse-alignment is much more smooth-looking than it had
been previously. More importantly, the optics
trunnion & shaft drive is now supported, by means of
new <a href="developer.html#Fictitious_IO_Channels">fictitious
output
channels</a>.<br>
</li>
<li>Stephan has sent a new version of <span
style="font-weight: bold;">LM_Simulator</span>.
Here are the changes:</li>
<ul>
<li>Workarounds added when we believed the
fine-alignment problems were on the <span
style="font-weight: bold;">LM_Simulator</span> side
rather than the <span style="font-weight: bold;">yaAGC</span>
side have been removed. (Specifically, the
angle-increment value is corrected, and the coordinate
transformation has been deactivated.)</li>
<li>Drives the IMU to Zero when the "Zero IMU CDU"
signal is activated. Now the IMU zeros after V36E (AGC
reset) but there are cases where the AGC lefts the
signal active. After using the crew button "Zero
IMU..." the signal goes back to zero.</li>
<li>Drive the IMU only when "Coarse Align Enable of IMU"
is activated. This is really an important change,
because in the "Attitude Hold Mode" the AGC uses the
counters to drive the error needles and the autopilot
misalignment. If the IMU was driven in such cases,
then the FDAI would jump uncontrollably over a small
angle area.</li>
<li>Socket Timeout added. If there is a period longer
than 2 seconds when no data appears on the socket,
then the LM Simulator assumes that the AGC has been
terminated. After showing an error message: "Lost
connection to yaAGC" the program terminates
itself. (This is a slight problem when yaAGC is
run in --debug mode. We are looking at fixes for
that case now.)</li>
<li>Attitude & Speed Control has been changed.
(You don't have the same precise level of control over
roll, pitch, and yaw as before, but it's much easier
to use.)<br>
</li>
</ul>
</ul>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="10" border="1">
<tbody>
<tr>
<td style="vertical-align: middle; text-align: left;">If
I'm
not mistaken, this means we're at a nice
milestone: the IMU simulation in <span
style="font-weight: bold;">LM_Simulator</span> can
now be regarded as functional. (The next level
needed will be to feed spacecraft accelerations and
rotation into the IMU automatically rather than
manually.)<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-07-01<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC:</span>
Well, I was wrong, and there still were fixups that
needed to be made in order to get fine-alignment to
work. That fix is made, but there is still a
little fix that needs to be made in <span
style="font-weight: bold;">LM_Simulator</span> to get
it all finished. (The angles aren't scaled
quite right yet.) <br>
</li>
<li><span style="font-weight: bold;">yaDSKY</span> <span
style="font-weight: bold;">& <span
style="font-weight: bold;">libyaAGC</span></span><span
style="font-weight: bold;">:</span> I've also
done a lot more fixups related to the portability of the
downlink-list parser. The description of how to
take advantage of the portability has been added to the
<a href="developer.html#Downlink_Lists">developer page</a>.
The
LM Coast/Align downlink list is now parsed.<br>
</li>
<li>Well, we have a discussion group now. Or at
least, the software for a discussion group has been
installed and appears to work. I'll mess with it
another day or two, and the let it loose on the
world. I hope that a lot of you---particularly
software developers---will join and exchange ideas.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-30<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Stephan has sent over a new version of <span
style="font-weight: bold;">LM_Simulator</span>.
The changes are:</li>
<ul>
<li>FDAI finalized (Z-Axis added)</li>
<li>A bug fix for counting. [To keep the simulated
angles equal to those of the AGC there is a need for
both an external counter which stores the IMU angles
in high resolution and a counter which counts in angle
increments of (0.01Deg). Previously, only the
latter was used, leading to large angle misalignments
after several attitude changes. Now, there is a
synchronization between the counters, which enables a
sufficient precision in angle handling.]</li>
</ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Previously, there was no use made of the GYROCMD counter
register in gyro torquing during fine-alignment.
Since the GYROCMD register is the central entity in this
operation, that pretty much ruined it. The upshot
of this fix is that IMU fine-alignment should now work
properly.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-29<br>
</td>
<td style="vertical-align: top;">Well, I now like <span
style="font-weight: bold;">yaDSKY</span>'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 <span style="font-weight: bold;">SimLuminary131</span>
and <span style="font-weight: bold;">SimColossus249</span>
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.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-28<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Rewrote a lot of the telemetry-downlink formatting
code I added yesterday. I realized that I could
write it in a way that was much more flexible so that
even though it is used in <span style="font-weight:
bold;">yaDSKY</span>'s "--test-uplink" mode, it could
also be used without change in <span
style="font-weight: bold;">yaTelemetry</span> or other
apps, with mere replacement of a pointer to the function
that does the actual output. In other words, the
code is now completely reusable, and independent of the
output device. Consequently, I feel much more
enthusiastic about going ahead to do more work on it.</li>
<li>Stephan has sent over a new version of <span
style="font-weight: bold;">LM_Simulator</span>.
Here's a summary of the changes, as I understand them:</li>
<ul>
<li>There are now Roll, Pitch and Yaw commands in the
attitude window, which translate into the associated
IMU gimbal angle changes. (Previously, there
were X, Y, Z gimbal-angle commands that simply drove
the gimbal angles without translation.)</li>
<li>There is a kind FDAI ball in the IMU window now,
though Stephan points out that "with TCL/TK there is
no chance to create a <span style="font-style:
italic;">real</span> FDAI ball." (Even so, in my
humble opinion, it seems darned good.)</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-27<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>In <span style="font-weight: bold;">yaDSKY</span>'s
"--test-uplink" mode, I now print out a little of the
downlink lists in more human-friendly form, but there's
just <span style="font-style: italic;">so much</span>
data that the effort of making it human-friendly---i.e.,
printing it with descriptive headings and units, and
scaled properly---is enormous. There are a couple
of thousand data values in the complete collection of
downlink lists (though, admittedly, with some overlap
among the lists). I don't think I'll do much more
of it right now. I have, however, organized the
hooks for doing it into libyaAGC, so the effort isn't
entirely wasted, and is potentially reusable by anyone
who wants to complete the work. I'd be more
excited about doing it myself, if I knew what the
displays on the downlink-telemetry consoles in
mission-control were supposed to look like.<br>
</li>
<li>I have added a couple of new commands (LMSIM and
CMSIM) to the <span style="font-weight: bold;">yaAGC</span>/<span
style="font-weight: bold;">yaDSKY</span> INI
files. These commands tell the simulation whether
it is supposed to be for an LM or a CM. (Odd that
this hasn't been needed until now, isn't it?) The
downlink lists for the LM and CM aren't distinguishable
in some cases without this additional info. (They
would have been distinguishable in real life, because
the telemetry downlink hardware external to the CPU
would have added this identfying info, I think.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-26<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
The digital uplink has now been implemented. I had
to modify the description of it that I added to the
developer page a few days ago, but not by much.</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
I've added a new command-line switch,
"--test-uplink". In this mode, <span
style="font-weight: bold;">yaDSKY</span> emits
uplink-data when keys are pressed instead of emitting
keycodes to its usual CPU input channel 015. This
mode is very convenient for testing the digital uplink,
since the uplink data consists of encoded DSKY keycodes
anyhow. I've noticed that <span
style="font-weight: bold;">yaAGC</span> is very lazy
in updating the DSKY display when receiving uplink data;
indeed, it may or may not update the display.
However, in the absence of other data, I assume this is
a normal property of the <span style="font-weight:
bold;">Luminary</span> and <span style="font-weight:
bold;">Colossus</span> flight software, rather than a
bug in <span style="font-weight: bold;">yaAGC</span>.
This
mode also prints messages when valid downlink data is
detected, so I think it's fair to say that both the
digital uplink and digital downlink are working properly
now. <span style="font-weight: bold;">Note:</span>
If
you want to see something keen you can do with this,
look at section 2.1.2 on p. 2-8 of the <a
href="NARA-SW/R-567-sec2-rev8.pdf"> LM GSOP</a>.
Enter V71E on the DSKY (in --test-uplink mode), and
proceed from there.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-25<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>: I
now properly handle the DOWNRUPT interrupt
request. The practical upshot of this is that the
CPU is now emitting downlink telemetry and/or AEA
initialization packets, whereas it was not doing so
before. You can see the downlink in <span
style="font-weight: bold;">LM_Simulator</span>, but
it's just raw data on i/o channels 034 and 035, and so
isn't very informative as of yet.<br>
</li>
<li>I rationalized the startup scripts somewhat. In
particular, an <span style="font-weight: bold;">LM_Simulator</span>
script is created during installation, and the other
scripts (like <span style="font-weight: bold;">SimLuminary131</span>)
call that script. This shouldn't matter much to
anybody but me, I guess, but it allows <span
style="font-weight: bold;">yaAGC</span>'s --debug
switch to be used again with the scripts. Scripts
like <span style="font-weight: bold;">SimLuminary131</span>
can have up to three command-line arguments, the first
of which is passed (in common) to <span
style="font-weight: bold;">yaDEDA</span> and <span
style="font-weight: bold;">yaDSKY</span>, the second
one of which is passed to <span style="font-weight:
bold;">yaAGC</span>, and the third one of which is
passed to <span style="font-weight: bold;">yaAGS</span>.
Scripts
like <span style="font-weight: bold;">SimLuminary131-lite</span>
have a single optional command-line argument, which is
passed directly to <span style="font-weight: bold;">yaAGC</span>.
The
table below is probably a complete list of the <span
style="font-style: italic;">useful</span> ways you can
use the command-line options with the scripts.
(Though not shown, the <span style="font-weight: bold;">SimColossus249</span>[<span
style="font-weight: bold;">-lite</span>] scripts work
the same way, but obviously without <span
style="font-weight: bold;">yaAGS</span> and the
DEDA.) If you want to do something trickier, you
should probably run the various programs directly rather
than relying on the startup scripts.<br>
</li>
</ul>
<div style="margin-left: 40px;">
<table summary="" style="text-align: left; width: 100%;"
cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"> SimLuminary131<br>
</td>
<td style="vertical-align: top;">Just run the
simulation without options. <span
style="font-weight: bold;">yaDSKY</span> will be
the DSKY simulation and <span style="font-weight:
bold;">yaDEDA</span> the DEDA simulation.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">SimLuminary131
--half-size<br>
</td>
<td style="vertical-align: top;">Same, but <span
style="font-weight: bold;">yaDSKY</span> and <span
style="font-weight: bold;">yaDEDA</span> will be
half-sized.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">SimLuminary131 ""
--debug<br>
</td>
<td style="vertical-align: top;">Run the simulation
with <span style="font-weight: bold;">yaAGC</span>
in debug mode.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">SimLuminary131 ""
"" --debug<br>
</td>
<td style="vertical-align: top;">Run the simulation
with <span style="font-weight: bold;">yaAGS</span>
in debug mode.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">SimLuminary131
--half-size --debug<br>
</td>
<td style="vertical-align: top;">Run the simulation
with <span style="font-weight: bold;">yaAGC</span>
in debug mode, and <span style="font-weight:
bold;">yaDSKY</span>/<span style="font-weight:
bold;">yaDEDA</span> half-sized.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">SimLuminary131
--half-size "" --debug<br>
</td>
<td style="vertical-align: top;">Run the simulation
with <span style="font-weight: bold;">yaAGS</span>
in debug mode, and <span style="font-weight:
bold;">yaDSKY</span>/<span style="font-weight:
bold;">yaDEDA</span> half-sized.</td>
</tr>
<tr>
<td style="vertical-align: top;">
SimLuminary131-lite<br>
</td>
<td style="vertical-align: top;">Just run <span
style="font-weight: bold;">yaAGC</span> and <span
style="font-weight: bold;">LM_Simulator</span> (<span
style="font-style: italic;">without</span> <span
style="font-weight: bold;">yaAGS</span> and <span
style="font-weight: bold;">yaDEDA</span>).
<span style="font-weight: bold;">LM_Simulator</span>
provides the DSKY simulation.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">
SimLuminary131-lite --debug<br>
</td>
<td style="vertical-align: top;">Same, but with <span
style="font-weight: bold;">yaAGC</span> in debug
mode.<br>
</td>
</tr>
</tbody>
</table>
</div>
<div style="margin-left: 80px;"> <br>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-24<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGS</span>: Finally have a sensible <span
style="font-family: monospace;">DVP</span> instruction, I
think. (A rational person could still disagree with
this assessment, I suppose, so you're still invited to
examine the <span style="font-family: monospace;">DVP</span>
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 <span
style="font-family: monospace;">DVP</span>
instruction. Typically, this will be readout of
address 555, which begins spontaneously, and which I can't
turn off.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-23<br>
</td>
<td style="vertical-align: top;">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 <span style="font-weight: bold;">yaAGC</span>. (No
new new <span style="font-weight: bold;">yaAGC</span>
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.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-19<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Added the "lite" options and scripts, to allow
building Virtual AGC without <span style="font-weight:
bold;">yaDSKY</span> and <span style="font-weight:
bold;">yaDEDA</span>, and running it instead with the
DSKY Lite module from <span style="font-weight: bold;">LM_Simulator</span>.<br>
</li>
<li>More changes to <span style="font-weight: bold;">LM_Simulator</span>:</li>
<ul style="font-style: italic;">
<li>--port and --cfg command-line parameters added.<br>
</li>
<li>A fatal bug was fixed in the socket read routine
which increases a counter until eternity in case of no
input on the socket, leading to an array overflow for
the data input array.</li>
<li>Furthermore, I've added the Alarm Codes out of the
Luminary Listing because of the alarm simulation
capabilities of LM Simulator .</li>
<li>FDAI / IMU color corrected</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-17<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>The development snapshot now builds and works in
Windows again. This is thus the first opportunity
to really use <span style="font-weight: bold;">yaAGS</span>,
<span style="font-weight: bold;">yaDEDA</span>, and <span
style="font-weight: bold;">LM_Simulator</span> on that
platform. It does build on Mac OS X, but <span
style="font-weight: bold;">LM_Simulator</span> seems
to run at super-slow speed, and even to slow down <span
style="font-weight: bold;">yaAGC</span>/<span
style="font-weight: bold;">yaDEDA</span> to the point
where those programs don't work, so I'm not sure what's
going on there.<br>
</li>
<li><span style="font-weight: bold;">LM_Simulator</span>:
Well,
Stephan has been a busy little bee. Here is a list
of changes:</li>
</ul>
<div style="margin-left: 40px; font-style: italic;">
<ul>
<li>Blocking behavior of the simulator due to missing
data on the socket has been fixed</li>
<li>CPU load reduced</li>
<li>LM System Input: "IMU Operate with no Malfunction"
is now active by starting the program</li>
<li>To allow a free configuration (e.g. on/off) of
windows or different IP-Addresses to connect to yaAGC
an INI-File has been added (lm_system_simulator.ini)</li>
<li>The window arrangement and content has been
optimized</li>
<li>The IMU Coarse Align and IMU Fine Align is
implemented, although the last one does not work
correctly. (The counter is merely for very small
angles quite proportional to the given angle)</li>
<li>New FDAI/IMU window to monitor the gimbal angles</li>
<li>"Attitude & Speed Control" window to simulate
gimbal angle changes has been added</li>
<li>Tutorial updated</li>
</ul>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-16<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Implemented, I hope, the
behavior of counter-registers CDUXCMD, CDUYCMD, CDUZCMD (and
associated drive-enable bits in output channel 14) needed
for continuing development of the IMU --- in this case, of
IMU coarse alignment. Modified the description on the
developer page of the description of channel 14 needed to
use this feature, as well as the description of the CDUxCMD
registers in the assembly-language manual page.
(Thanks to Stephan Hotto and Markus Joachim for pointing out
this problem and describing the fixes.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-15<br>
</td>
<td style="vertical-align: top;"> In <span
style="font-weight: bold;">yaAGS</span>, I've implemented
the <span style="font-family: monospace;">DVP</span>
instruction according to an algorithm sent to me by Julian
Webb. (Thanks, Julian!) I'm bound to say that
there are a number of things that don't make sense about it
to me, but it does manage to pass the self-test (which no
algorithm I invented was able to do). Anyone who feels
competent to do so is invited to examine the <span
style="font-family: monospace;">DVP</span> instruction in
the function <span style="font-family: monospace;">aea_engine</span>
of the source file aea_engine.c, and give me your insights
on the matter. Otherwise, though, <span
style="font-weight: bold;">yaAGS</span> now passes the
built-in self-test (see, for example, p. 115 of Flight
Program 8), and may therefore be cautiously considered as
working. Probably there are plenty of problems with it
that will surface slowly in the coming months.<br>
<br>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: middle; text-align: left;">
In case it wasn't clear from the comments above, the
complete basic suite of Abort Guidance System
software is now available and (hopefully) working,
in Linux:<br>
<ul>
<li>CPU emulator (<span style="font-weight: bold;">yaAGS</span>)</li>
<li>Data-entry and display emulation (<span
style="font-weight: bold;">yaDEDA</span>)</li>
<li>Flight software source code and executables (<span
style="font-weight: bold;">Flight Program 6</span>
and <span style="font-weight: bold;">Flight
Program 8</span>)</li>
<li>Assembler (<span style="font-weight: bold;">yaLEMAP</span>)<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-14<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>In <span style="font-weight: bold;">yaAGS</span>,
fixed some problems with the <span style="font-family:
monospace;">LRS</span> instruction, and continued
fixing the <span style="font-family: monospace;">DVP</span>
instruction. The <span style="font-family:
monospace;">DVP</span> instruction is better than it
was before, but it's still not totally fixed.</li>
<li>The <span style="font-weight: bold;">SimLuminary131</span>
script now runs not only <span style="font-weight:
bold;">yaAGC</span>, <span style="font-weight: bold;">yaDSKY</span>,
and <span style="font-weight: bold;">LM_Simulator</span>,
but now runs <span style="font-weight: bold;">yaAGS</span>
and <span style="font-weight: bold;">yaDEDA</span> as
well. It's pretty impressive to see them all
running at once. I still haven't attempted
to run <span style="font-weight: bold;">LM_Simulator</span>,
<span style="font-weight: bold;">yaAGS</span>, or <span
style="font-weight: bold;">yaDEDA</span> (or even to
build them) in Windows or Mac OS X yet, so I'm referring
only to Linux here.<br>
</li>
<li>Added a <a href="index.html#QuickStartAGS">very small
tutorial</a> for <span style="font-weight: bold;">yaAGS</span>/<span
style="font-weight: bold;">yaDEDA</span> to the "quick
start" section of the home page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-12<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>In <span style="font-weight: bold;">yaAGS</span>,
fixed problems forming double-precision operands in
general, and sign-generation problems with the <span
style="font-family: monospace;">LRS</span>
instruction. Fixed the handling of overflow in
instructions "<span style="font-family: monospace;">LLS
0</span>" and "<span style="font-family: monospace;">ALS
0</span>". The <span style="font-family:
monospace;">DVP</span> instruction is really messed up
with negative divisors, and I have no clue as to what's
going on with it. However, <span
style="font-weight: bold;">yaAGS</span> can now
communicate with <span style="font-weight: bold;">yaDEDA</span>,
and the CPU emulation works well enough that you can do
things like looking at the results of the self
test. (CLR 4 1 2 READOUT, for anyone who's
interested. The displayed code, +30000, means a
"logic error", such as a bad <span style="font-family:
monospace;">DVP</span> instruction.)<br>
</li>
<li>In <span style="font-weight: bold;">yaAGC</span>,
fixed the handling of the <span style="font-family:
monospace;">DINC</span> unprogrammed sequence, so that
<span style="font-family: monospace;">POUT</span>, <span
style="font-family: monospace;">MOUT</span>, and <span
style="font-family: monospace;">ZOUT</span> signals
are output. (Thanks to Stephan Hotto for pointing
out the problem.)</li>
<li>Also, Stephan has provided a new <a
style="font-weight: bold;" href="yaTelemetry.html">LM_Simulator</a>,
with gyro-tracing functionality.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-11<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>In <span style="font-weight: bold;">yaAGC</span>,
implemented a fictitious output channel 0177 (see the <a
href="developer.html#Table_of_IO_Channels">developer
page</a>) which can be used for simplifying
implementation of emulated gyros.</li>
<li>In <span style="font-weight: bold;">yaAGS</span>,
added the DISASSEMBLE, COUNTS, and PATTERN commands for
debug-mode. Fixed the <span style="font-family:
monospace;">TIX</span> instruction, which was
overwriting memory and causing the problem mentioned two
days ago. But now I find that there is a
fundamental problem in the <span style="font-weight:
bold;">yaAGS</span>/<span style="font-weight: bold;">yaDEDA</span>
interaction through the socket interface; <span
style="font-weight: bold;">yaDEDA</span> only
transmits data to <span style="font-weight: bold;">yaAGS</span>
upon a strobe from <span style="font-weight: bold;">yaAGS</span>,
but there is not enough time between the strobe and the
time the flight program checks the shift register for
the data to be exchanged. Resolving this will take
some thought.<br>
</li>
<li>In the development snapshot, added a version of
Stephan Hotto's <a style="font-weight: bold;"
href="yaTelemetry.html">LM_Simulator</a> program which
he has wrapped as a Windows executable (so that you
don't have to install <span style="font-weight: bold;">Tcl/Tk</span>
to make it work).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-09<br>
</td>
<td style="vertical-align: top;">Lots of work on <span
style="font-weight: bold;">yaAGS</span>, but mainly in the
form of improving debugging (fixing i/o-channel addresses,
editing of memory locations, backtraces, etc.).
Somehow <span style="font-weight: bold;">yaAGS</span>
executes an undefined instruction in displaying to the DEDA,
but I haven't figured out yet how that happens.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-08<br>
</td>
<td style="vertical-align: top;">"Finished" coding <span
style="font-weight: bold;">yaAGS</span>. It doesn't
work, of course. I'll start figuring out why tomorrow.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-07<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Various corrections to <span style="font-weight:
bold;">yaAGS</span>.</li>
<li>Correction of DEDA shift-register bit-ordering in <span
style="font-weight: bold;">yaDEDA</span> and <span
style="font-weight: bold;">yaAGC</span>.<br>
</li>
<li>Stephan Hotto has sent us yet another update to <a
style="font-weight: bold;" href="yaTelemetry.html">LM_Simulator</a>.
Here
are the changes, as described by Stephan:</li>
</ul>
<div style="margin-left: 40px;"> <span style="font-style:
italic;">Fixes:</span><br style="font-style: italic;">
<ul style="font-style: italic;">
<li>Unknown unprogrammed sequences as output of the
AGC/AGS are now handled (hopefully ;-))</li>
<li>Improvement of the DSKY Lite by using real 7-Segment
numbers</li>
<li>Remove of a trace (inserted for development) of an
internal timer which would fill up the Log-Out-Window</li>
<li>Crew Button handling (AOT, Descent) corrected</li>
<li>DSKY PRO button is now working</li>
<li>Time printouts removed</li>
<li>DSKY Labeling and Number Size as well as separation
lines corrected and added.</li>
<li>Most important, the program now merely recognizes
AGC data packages with the following signature: 00...
01... 10... 11... So, the AGS packets shouldn't have a
negative impact any longer.<br>
</li>
</ul>
<span style="font-style: italic;">RHC does not work yet
because beside setting the associated input bit, a
counter must be increased proportional to the stick
angle.</span><br>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-06<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Stephan Hotto has sent us a new version of <a
href="yaTelemetry.html#LM_Simulator_by_Stephan_Hotto"><span
style="font-weight: bold;"> LM_Simulator</span></a>.
Here's
what he has to say about it:<br>
</li>
</ul>
<div style="margin-left: 40px;"> <span style="font-style:
italic;">Bug Fixes:</span><br style="font-style:
italic;">
<ul style="font-style: italic;">
<li>AGC Output has been completely revised. Now I'm
using text labels which will show the different state
of the signals.</li>
<li>LM System Signals and Crew Buttons corrected. I'm
still unsure in some cases.</li>
</ul>
<span style="font-style: italic;">New Features:</span><br
style="font-style: italic;">
<ul style="font-style: italic;">
<li>DSKY LITE is a very simple (awful graphics) but full
functioning DSKY. Due to your extensive description of
the interface it was quite simple to implement.</li>
<li>IMU Simulation has been corrected and accelerated.
The angles are now running between 0\B0 and 360\B0 as
noted by the AGC.</li>
<li>Simple RHC and THC as well as AOT buttons added</li>
<li>Noun & Verbs and first steps of the Tutorial
added.</li>
</ul>
The "DSKY LITE" is, I think, remarkably good, in spite of
Stephan's badmouthing of the graphics.<br>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-05</td>
<td style="vertical-align: top;">
<ul>
<li>Corrected polarity and bit positioning of AGS "input
discretes" on the developer page, in the <span
style="font-weight: bold;">yaDEDA</span> program, and
in "yaAGC --debug-deda".</li>
<li><span style="font-weight: bold;">yaAGS</span> is
coming along very well. I'm now trying it in
--debug mode, and fixing bugs in some of the instruction
set. Shouldn't be too much longer before it's
ready to use with <span style="font-weight: bold;">yaDEDA</span>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Lots more work on <span style="font-weight: bold;">yaAGS</span>.
Getting
close to being ready to try out.</li>
<li>Fixed up the GUI in <span style="font-weight: bold;">yaDEDA</span>
so that it is consistent in sizing with <span
style="font-weight: bold;">yaDSKY</span>.
(Before, I had stupidly made it bigger.) Should
now work in Mac OS X, though I haven't tried it yet.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-03<br>
</td>
<td style="vertical-align: top;">On the <a href="links.html">links
page</a>, updated the status of the integration of Virtual
AGC with the Orbiter simulator again, after receiving some
additional info from Markus Joachim.</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-06-02<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Removed the CVS subdirectories and some symbolic links
from future development snapshots. (Thanks to
Markus Joachim for pointing them out to me.)</li>
<li>On the <a href="links.html">links page</a>, updated
the status of the integration of Virtual AGC with the
Orbiter simulator. (Hint: It's going great,
and there is now a Sourceforge project for it, again
thanks to Markus Joachim.)</li>
<li>There's now a skeleton of a <span style="font-weight:
bold;">yaAGS</span> program. It doesn't do much
yet other than to allow <span style="font-weight:
bold;">yaDEDA</span> to connect to it, load the
selected flight program, and keep accurate time, and
execute a few types of instructions. Lots of
instructions are implemented, but they're all of a
rather simple nature. (But who knows if they're
implemented <span style="font-style: italic;">correctly</span>?
I
haven't quite figured out yet how I'll be testing these
things.)</li>
<li>Stephan Hotto's <span style="font-weight: bold;">LM_Simulator</span>
program is now included in the installation when doing
'make install' (i.e., building from source). The <span
style="font-weight: bold;">SimLuminary131</span>
script runs <span style="font-weight: bold;">LM_Simulator</span>
in addition to <span style="font-weight: bold;">yaAGC/yaDSKY</span>.
You
need to have Tcl/Tk installed to take advantage of this,
but if you don't nothing bad will happen.
Incidentally, Stephan has given me a list of a few
problems he's found so far. I won't bother to put
these in the buglist quite yet; the <span
style="font-weight: bold;">LM_Simulator</span> program
is so new that it's in rapid flux. After it has
settled down some, then I'll start recording bugs for
it.<br>
</li>
</ul>
<span style="font-weight: bold;">Note:</span> This big
bunch of changes isn't without cost. This stuff likely
won't build (or won't build completely) on Windows and Mac
OS X. I'll fix this up soon, but probably not until
I'm happy with <span style="font-weight: bold;">yaAGS</span>.
Therefore,
Windows and Mac OS X users will probably want to stick with
the binary packages, use an earlier source package, or else
just take your chances.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-31<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>On the <a href="developer.html">developer page</a>:
Added
some <span style="font-weight: bold;">yaAGS</span>-specific
functions
to the API, and on a global basis made the applicability
of the API's library functions (<span
style="font-weight: bold;">yaAGC</span> vs. <span
style="font-weight: bold;">yaAGC</span>, CPU vs.
peripheral) much clearer. Also, added a section on
the <span style="font-weight: bold;">yaAGS</span>
core-image file format.</li>
<li>On the <a href="yaTelemetry.html">yaOtherStuff</a>
page, corrected a couple of links (thanks to Fabrizio
Bernardini).</li>
<li>On the <a href="download.html">download</a> page,
added some additional info about the Mac OS X binary
tarball.</li>
<li><span style="font-weight: bold;">yaDEDA</span> seems
to be working, as near as I can understand its operation
at present. Of course, there's no <span
style="font-weight: bold;">yaAGS</span> to operate it,
but I added a command-line switch to <span
style="font-weight: bold;">yaAGC</span> (--debug-deda)
that seems to provide a pretty good test.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-30<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>On the <a href="yaTelemetry.html">yaOtherStuff page</a>,
I've added a "contributed code" section because the
development snapshot now contains a nifty i/o-channel
monitor (on it's way to becoming an IMU simulation)
contributed by Stephan Hotto, called <span
style="font-weight: bold;">LM_Simulator</span>.
It's a work in progress, but is quite useful as it
stands.</li>
<li>The AEA/DEDA interaction is now covered in much more
detail on the <a href="developer.html">developer page</a>.
In
fact, there is an entire section devoted to it.</li>
<li>Scans of Delco's quick-reference cards for Apollo 15
Luminary 1E are now available on the <a
href="links.html">links page</a>, thanks to Fabrizio
Bernardini.</li>
<li><span style="font-weight: bold;">yaDEDA</span> is now
mostly working. With luck I can finish it up
tomorrow. <span style="font-weight: bold;">yaAGS</span>
doesn't exist yet, but because the DEDA is smarter than
the DSKY, you can actually use it and see a lot of what
it does even without <span style="font-weight: bold;">yaAGS</span>.
(Whereas
<span style="font-weight: bold;">yaDSKY</span> is
completely useless without <span style="font-weight:
bold;">yaAGC</span>.) Refer to <a
href="yaAGS.html">the yaAGS page</a> for more detail.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-29<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>More noodling with the <span style="font-weight:
bold;">yaDEDA</span> program ...</li>
<li>The <a href="yaAGS.html">yaAGS page</a> has been
pepped up with additional verbiage, such as:</li>
<ul>
<li>More circumstantial evidence that the two missing
pages of FP6 have been reconstructed correctly.
I thought the evidence was pretty good before, but it
seems conclusive now.</li>
<li>A table of known versions of the AGS flight program.</li>
<li>... and more.<br>
</li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-28<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>There is now a skeleton form of the <span
style="font-weight: bold;">yaDEDA</span>
program. So far it really just shows what the GUI
will be like, but it does have a working socket
interface (in the sense that it can connect to a
server), though it doesn't know what to do with any of
the information it receives on the socket
interface. I haven't made the mods yet that would
allow it to build in Windows, nor have I checked that it
still builds in Mac OS X.</li>
<li>Also, there's some great news. Thanks to Allan
Klumpp, it appears that Luminary 1A 099 (Apollo 11) and
Luminary 1D 209 (Apollo 15-17 we <span
style="font-style: italic;">think</span>) will soon be
available. Now, I don't know whether "soon" will
be two weeks, two months or two years, as I don't yet
have access to these materials. But it's still
great. Yay, Allan! (There are other people
to thank for this as well, but I'll save some of my
praises for when the listings are actually
available.) Any of you folks out there who have <span
style="font-weight: bold;">Luminary</span> or <span
style="font-weight: bold;">Colossus</span> listings
you've been hoarding had better step forward soon if you
want to get any karma points out of this deal!<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-26<br>
</td>
<td style="vertical-align: top;">Allan Klumpp has told me that
there is a descrepancy between the the software version
quoted on the <a href="Luminary.html">Luminary page for
Apollo 15-17</a> vs. his personal recollections and
in-hand documentation. I've added notes to that
effect, along with disclaimers on the <span
style="font-weight: bold;">Colossus</span> and <span
style="font-weight: bold;">Luminary</span> pages to
indicate that I'm not certain how accurate the software
configuration information is.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-24<br>
</td>
<td style="vertical-align: top;">On the <span
style="font-weight: bold;">yaAGS</span> page, added a link
to the complete LM/AGS Design Survey document at klabs.org,
whereas only the block diagrams from that doc are available
locally here on the Virtual AGC site.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-23<br>
</td>
<td style="vertical-align: top;">Minor corrections on
developer and language-manual pages. And a few
additions to the faq page.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-21<br>
</td>
<td style="vertical-align: top;">Finished up the API
documentation. Probably still needs a little work,
such as verifying the sample programs listed, but looks
pretty good.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-18</td>
<td style="vertical-align: top;">Finally began filling in some
of the Virtual AGC Library API stuff on the <a
href="developer.html#libyaAGC.a">developer's page</a>
since, I was surprised to find, some people are actually
interested in it. Still needs a <span
style="font-style: italic;">lot</span> of work, but does
actually contain some useful information.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-17<br>
</td>
<td style="vertical-align: top;">The <a
href="developer.html#sendrecv_Protocol">developer page</a>
now contains a pretty complete discription of the extensions
to the socket protocol which will be needed to implement
yaAGS, yaDEDA, and peripherals, and to allow interaction of
yaAGS with yaAGC. Communication of yaAGC with yaDSKY
and other projected peripherals remains unchanged from
before. I was afraid there would be a lot more fuss
and muss with this than there really was.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-15<br>
</td>
<td style="vertical-align: top;">PR #30 (socket interface to
"unprogrammed" counter sequences completely inoperative) has
been fixed in <span style="font-weight: bold;">yaAGC</span>,
and a special mode (--debug-counter-mode) has been added to
<span style="font-weight: bold;">yaDSKY</span> so that
there's a way for debugging purposes of sending known
counter-commands to <span style="font-weight: bold;">yaAGC</span>
and observing the effect. <br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-14<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>There's now a Mac OS X binary package. It
doesn't conform in any reasonable way to what a normal
Mac OS user would <span style="font-style: italic;">expect</span>,
so probably it's nearly as unusable as the source
package. But at least it does avoid the necessity
of building the program.<br>
</li>
<li>Website: On the links page, corrected the link
to Jos\E9 Portillo Lugo's paper (thanks to Jordan Slott
for pointing out the bad link), and added a link to Don
Eyle's "Tales from the Lunar Module Guidance
Computer". On the FAQ page added another email
contact address, in case somebody has experience
blockage of the normal Virtual AGC email address for
some reason.<br>
</li>
<li>Source code (AGC and Virtual AGC): Corrected a
lot of out-of-date website references, from sandroid.org
to ibiblio.org. However, there are hundreds of
files in this project and the website is referenced in
each one, so I didn't fix them all.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-09<br>
</td>
<td style="vertical-align: top;">I discovered that while
yesterday's Linux binaries do work on a variety of systems
(like SuSE 9.0 & 9.1, Ubuntu 5.04, and Fedora Core 1),
they don't work on older systems (like RedHat 7.3).
With some luck, the Linux binaries I've put up today will
work on a wider variety of systems. <br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-05-08<br>
</td>
<td style="vertical-align: top;">There are now pre-built
Virtual AGC binaries for Linux on the download page.
This has been a long time coming ... which is a shame, since
it turned out to be pretty easy to create them. On the
other hand, I don't guarantee the binaries work on every
platform, though they've worked so far on all of the
platforms I've tried. Your mileage may vary.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-04-30<br>
</td>
<td style="vertical-align: top;">A lot of changes related to
PR #28 have been made. These changes relate only to
building the program on Win32, which was broken.
Various compiler warnings under Linux have also been fixed,
but there's no actual functional change.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-02-27<br>
</td>
<td style="vertical-align: top;">At the request of Markus
Joachim, I have added a "special exception" (as
allowed/required by the GPL) to the license of the source
files yaAGC/yaAGC/*.[ch], allowing linkage to the non-GPL'd
Orbiter SDK libraries. This has been done to allow
distribution of plug-ins relying on <span
style="font-weight: bold;">yaAGC</span> source code for
the Orbiter spacecraft simulator.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-02-13<br>
</td>
<td style="vertical-align: top;"> Added the AGS Performance
and Interface Specifications document to the <a
href="yaAGS.html">AGS page</a>. (Thanks to John
Pultorak and Davis Peticolas.) We've decided not to
provide one of the docs that was originally listed, so<br>
<br>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="text-align: center; vertical-align:
middle;">AGS document entry is now complete.</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-31<br>
</td>
<td style="vertical-align: top;">In <span style="font-weight:
bold;">yaAGC</span>, managed to get rid of the annoying
effect (which appeared only in Linux) whereby stopping <span
style="font-weight: bold;">yaAGC</span> before stopping <span
style="font-weight: bold;">yaDSKY</span> resulted in an
operating-system timeout of a couple of minutes before the
port could be reused (and hence before the simulation could
be restarted).<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-29<br>
</td>
<td style="vertical-align: top;">The AGS Flight Equations
document scan has been added to the AGS page.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-27</td>
<td style="vertical-align: top;">The Mac OS X build
instructions have been simplified a little, and completely
tested on a pristine Mac OS X 10.2.8 system.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-26<br>
</td>
<td style="vertical-align: top;">On the links page, there are
now some <a href="OperatingHandbookLighting.pdf">scans of
tables</a> relating to spacecraft interior and exterior
lighting, thanks to Paul Fjeld.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-25<br>
</td>
<td style="vertical-align: top;">I finally have Virtual AGC
running on pre-Panther versions of Mac OS X -- or at least I
have it running on Jaguar. The instructions are on the
<a href="download.html">download</a> page. My only
problem, it turns out, was finding the right version of X11.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-24</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaLEMAP</span>:
The alignment of fields in the assembly listing is now
better. The format of the output binsource file
has also changed to make audio proofing go a little
faster (by removing leading zeroes).</li>
<li>AGS <span style="font-weight: bold;">FP6</span>
source code: I've proofed the first two blocks of
memory, and the checksums of all three blocks are
correct. I personally believe that the source code
is now 100% complete and correct, although I haven't
proofed the third memory block (4000-7777), because I
believe this block did not change between <span
style="font-weight: bold;">FP6</span> and <span
style="font-weight: bold;">FP8</span>. Anyone
who wants to proof it and make a liar of me, be my
guest! It may take a while for me to get to it.</li>
<li>On the AGS page, the link to the textual (vs. scanned)
listing for AGS <span style="font-weight: bold;">FP8</span>
has been updated (because of the <span
style="font-weight: bold;">yaLEMAP</span> formatting
changes mentioned above).</li>
<li>A link for the textual (vs. scanned) listing for AGS <span
style="font-weight: bold;">FP6</span> has been added
to the AGS page.</li>
</ul>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">This is a nice little
milestone: The AGS cross-assembler and the
source code for AGS Flight Programs 6 and 8 are now
completely available and correct, along with scans
of most documents needed to learn how to write AGS
programs.<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-23<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>The AGS page has been fancied up with various
illustrations and a lot more text (particularly in
discussing the architecture).</li>
<li>The AGS <span style="font-weight: bold;">FP6</span>
source-code data-entry has been completed, but none of
it is debugged. There are no errors or warnings
from the assembler, but only one of the three memory
areas has a correct checksum, so it is known that errors
are present in the source code.<br>
</li>
<li>A big, fancy AGS block diagram has been added, thanks
to John Pultorak.</li>
<li>The AGS FP6 software-test document is now available,
thanks to John Pultorak and Davis Peticolas.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-22<br>
</td>
<td style="vertical-align: top;">The scan of the AGS <span
style="font-weight: bold;">FP6</span> Operating Manual has
been added, as usual thanks to John Pultorak and Davis
Peticolas.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-19<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>The AGS <span style="font-weight: bold;">FP8</span>
source code is now debugged, and its binary proofed
against the scanned listing. Obviously it's always
possible for me to have made mistakes, but I think it's
100% complete and correct now.</li>
<li>Minor changes were made to <span style="font-weight:
bold;">yaLEMAP</span> and <span style="font-weight:
bold;">binLEMAP</span>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-18<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Addition of "<span style="font-family: monospace;">CHECKSUM
RANGE</span>" to <span style="font-weight: bold;">yaLEMAP</span>
for proper assembly of AGS FP8.s. The <span
style="font-family: monospace;">OCT</span> pseudo-op
now conforms to the programmer's manual (though it
actually worked well enough before). Various minor
formatting changes also to make the assembly listing
look prettier.</li>
<li>The AGS <span style="font-weight: bold;">FP8</span>
source code has been through a lot of
proofing/debugging. It now assembles without
errors and the symbol table is probably correct.
However, the binary still has some bugs, since the
checksums are wrong. Comparison with the binary
from the scanned assembly listing has begun.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-17<br>
</td>
<td style="vertical-align: top;">Data entry for AGS Flight
Program 8 source code is complete, but no debugging has been
done on it yet.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-16<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Yesterdays's scans have been cleaned up. The PDF
page numbers now match the numbers marked on the pages,
and the many foldouts in the "programmed equations" have
been processed so that each is a single page rather than
2-3 separate pages.</li>
<li>Approximately half of the AGS FP8 source code has been
entered, but not proofed.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-15<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>The scans of the AGS <span style="font-weight: bold;">FP6</span>
assembly listing and "programmed equations" document are
now available. Again, thanks to John Pultorak and
Davis Peticolas.<br>
</li>
<li>Some (not much) <span style="font-weight: bold;">FP8</span>
source code has been entered.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-1-13<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaLEMAP</span>, in so far as the sample code is
concerned, is fully working. I know that there are a
couple of things appearing in the flight code that I haven't
dealt with yet, because they don't appear to be documented.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-12<br>
</td>
<td style="vertical-align: top;">Continued refinement of AGS
page text. The <span style="font-weight: bold;">yaLEMAP</span>
program is coming along nicely; it can produce a correct
symbol table and a partial assembly of the sample AGS
program from the appendix of the AGS programmer's manual.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-1-11<br>
</td>
<td style="vertical-align: top;">Paul Fjeld has supplied
various factual corrections and some amusing anecdotes for
the AGS page. Also, John Pultorak has scanned yet
another of Davis Peticolas's documents, the AGS simulator
user guide. There is a skeleton program now for the
AGS cross-assembler, <span style="font-weight: bold;">yaLEMAP</span>,
but it's not much yet.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-10<br>
</td>
<td style="vertical-align: top;">Thanks to Davis Peticolas and
John Pultorak, various new AGS document scans are available,
including the complete assembly listing for Flight Program 8
and the program specification for Flight Program 6 (Apollo
11). The utility program <span style="font-weight:
bold;">binLEMAP</span> for keying in AGS binaries has also
been added. The source code and binary
(SampleCodeAGS.s and SampleCodeAGS.binsource) for the sample
program in Appendix A of the AGS programmer's manual have
been added, but will only be of interest in wringing out the
<span style="font-weight: bold;">yaLEMAP</span>
cross-assembler, which doesn't yet exist.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2005-01-09<br>
</td>
<td style="vertical-align: top;">Bunch of website changes,
related to the impending availability of AGS (Abort Guidance
System) material. In fact, the AGS programming-manual
is now available on the new "<a href="yaAGS.html">yaAGS et
al.</a>" page, thanks to Davis Peticolas and John
Pultorak. This page and the Pultorak page have now
been added to the title block, rather than forcing you to
find them on the links page.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2004" onchange="viewOrHide(2004)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2004 change notes?</b>
<table summary="" id="table2004" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">2004-12-30<br>
</td>
<td style="vertical-align: top;">Changed from Pultorak link
(see item below) to a <a href="Pultorak.html">complete page</a>.
The
page contains a lot of supplemental materials which John has
sent me, but which you can't get out of his PDFs, such as
the original CAD files from the schematic capture,
source-code files which you don't need to cut-and-paste, a
part list, and so on.</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-12-19</td>
<td style="vertical-align: top;">Added a link to <span
style="color: rgb(0, 0, 0);">John Pultorak's site</span>
on the <a href="links.html">links page</a>. (Adding a
link normally wouldn't be newsworthy, but the guy has spent
4 years building his own Block I AGC and gives us the
complete plans for it. Does it get any
better?) <br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-11-06<br>
</td>
<td style="vertical-align: top;">Made available a lot of
replacement scans Gary Neff (thanks Gary!) has sent me for
50 garbled pages in the MIT-hosted Colossus 249 assembly
listing. You can get these from the <a
href="Colossus.html">Colossus page</a>. These will
help to clean up a few holes in the Colossus source code,
though I've not yet made those fixes. (Fortunately,
there are not many such places.) Eventually I intend
to merge Gary's scans with a cleaned-up MIT-based scan, so
that the scanned assembly listing will become much more
readable, though (again) I've not yet done so.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-10-23<br>
</td>
<td style="vertical-align: top;">Fixed a website link on the <span
style="font-weight: bold;">Luminary</span> page.
(Thanks to Christian Bucher for pointing out the error.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-10-21<br>
</td>
<td style="vertical-align: top;">Added some additional hints
to the Mac OS X build instructions, thanks to Greg Dunn.<br>
<br>
By the way, some folk have wondered why the pace of updates
has dropped off. I'm a bit burned out and am taking a
little rest. Don't worry, though, I'll snap back soon
(I hope), especially if anybody finds an alternate version
of <span style="font-weight: bold;">Luminary</span> or <span
style="font-weight: bold;">Colossus</span> for me to work
with. :-)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-10-03<br>
</td>
<td style="vertical-align: top;">Drastically reduced the size
of some of the new scanned documents: Excerpts from
CSM 112-114 System Handbook reduced from 120M to a "mere"
20M; LM 7 pad-loads reduced from 5M to 1M. Sorry for
the inconvenience to anybody that downloaded them
earlier. (Note that the earlier downloads were
grayscale rather than b&w, and therefore may be very
slightly more legible.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-10-02<br>
</td>
<td style="vertical-align: top;">Pages 30-50 of Hugh
Blair-Smith's "memo #9", covering AGC microcode have been
provided in text (as opposed to scanned) form on the links
page. This material has been typed and contributed by
none other than Hugh Blair-Smith himself! Several
large schematic foldouts from the <span style="font-style:
italic;">Apollo LM System Handbook</span> for Apollo 17
have been added also, Contributed by Fabrizio Bernardini.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-10-01<br>
</td>
<td style="vertical-align: top;">The G&C section of the <span
style="font-style: italic;">Apollo CSM System Handbook</span>
for CSM-112 through CSM-114 has been added to the links
page. (Contributed by Fabrizio Bernardini.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-28<br>
</td>
<td style="vertical-align: top;">Additional docs added to the
links page. These include the LM-7 (Apollo 13)
pad-loads -- i.e., the values for the AGC erasable
memory. (Contributed by Paul Fjeld.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-25<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Documents: A variety of significant new scanned
documents, or excerts from documents, have been added to
the links page. These have been contributed by
Fabrizio Bernardini and Paul Fjeld, but I have received
more documents from them than I have yet been able to
process.<span style="font-weight: bold;"><br>
</span> <span style="font-weight: bold;">yaUniverse</span>:
Has
been cleaned up a lot, and has a lot more options.
After experimentation, it now has a lot more realistic
default timestep for the numerical integration (6 hours
rather than 1 minute). Consequently, we can get
realistic ephemeris data with a 1-hour rather than a
1-minute timestep, and can therefore tremendously reduce
the ephemeris data in size. For testing purposes,
the Apollo8-epoch ephemeris data is very complete
(including the Earth, Moon, Sun, Mercury, Venus, Mars,
Jupiter, Saturn, Ganymede, Io, Europa, Callisto, Titan,
Tethys, Dione, and Rhea), though ephemeris data for
other missions (not yet created) will only initial data
points.</li>
<li>Documents: A variety of new scanned documents,
or excerts from documents, have been added to the links
page. These have been contributed by Fabrizio
Bernardini and Paul Fjeld, but I have received more
documents from them than I have yet been able to
process.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-23<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaUniverse</span>: Is now capable of
numerically integrating the motions of the heavenly bodies
and spacecraft under gravitational influences. The
previous concept of using fully-tabulated heavenly-body
ephemeris data for the heavenly bodies has now been
discarded because of the large downloads required, and hence
the separate ephemeris downloads have been removed from the
download page. The greatly abbreviated ephemeris files
needed for testing and for determination of initial
positions and velocities of heavenly bodies are now included
directly in the development snapshot.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-21</td>
<td style="vertical-align: top;">Assembly-language
manual: Updated/added descriptions of various
pseudo-ops.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-16<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaACA</span>: The proof-of-concept now builds
(and hence works) in Win32. It still does not
communicate with <span style="font-weight: bold;">yaAGC</span>.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-15<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaACA</span>: Just a start. More of a
proof-of-concept that a hand-controller can be used.
All it does so far is to display the pitch, yaw, and roll
axes of the hand-controller, but at least it does it.
I haven't connected it to <span style="font-weight: bold;">yaAGC</span>
yet, and have only gotten it to work in Linux.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-12<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Win32 zipfile on download page: Well, I don't
know what was behind my inability to create uncorrupted
zipfiles, but it seems to be fixed now. It
affected only the 20040905 and 20040910 files. The
20040912 zipfile should be okay, and contains exactly
the same stuff that the 20040905 file was <span
style="font-style: italic;">supposed</span> to
contain. Sorry for the inconvenience.</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
Added the LM1.ini configuration.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-11<br>
</td>
<td style="vertical-align: top;">The Win32 zipfile from
20040905 is corrupted. (Thanks to D. C. Shoemaker for
pointing this out.) I have now reverted to the
20040819 Win32 zipfile, which is perfectly fine except that
some now-known bugs in Colossus249.bin have not been
fixed. Download the development snapshot to get a
fully-correct version of Colossus. (I find myself
temporarily in the position of not being able to create a
zipfile. Sorry for the inconvenience.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-05<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
Various small tweaks needed for <span
style="font-weight: bold;">Colossus</span>: The
<span style="font-family: monospace;">CADR</span>
pseudo-op can now appear in the midst of interpretive
operands. (Thought this had been done yesterday,
but it was messed up.) Added processing for the "<span
style="font-family: monospace;">=MINUS</span>", "<span
style="font-family: monospace;">MEMORY</span>", and "<span
style="font-family: monospace;">SUBRO</span>"
pseudo-ops (the latter two of which actually do nothing
for us). No longer generates fatal errors for
illegal <span style="font-family: monospace;">EXTEND</span>s,
if
preceded by <span style="font-family: monospace;">INDEX</span>
(since there's no telling at assembly time whether the
code executed after indexing needs an <span
style="font-family: monospace;">EXTEND</span> or
not.) Also, the <span style="font-family:
monospace;">RESUME</span> instruction no longer is
treated as an <span style="font-family: monospace;">EXTEND</span>
for the purpose of detecting fatal errors. The
latter two changes allow us to remove the "--force"
command-line flag from the Makefiles used for assembling
<span style="font-weight: bold;">Colossus249</span> or <span
style="font-weight: bold;">Luminary131</span>.<br>
</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Now completely debugged and, with the
<span style="font-weight: bold;">yaYUL</span> changes
above, assembles correctly. Yay! I had to
add a dozen or so extra <span style="font-family:
monospace;">SBANK=</span> pseudo-ops --- because I am
still unable to determine exactly how <span
style="font-family: monospace;">2CADR</span> <span
style="font-style: italic;">et al.</span> set the
superbank bit --- but I'm willing to live with that.</li>
</ul>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;"> In case it isn't
obvious from what I've written above:
<ol>
<li> <span style="font-weight: bold;">yaYUL</span>
is now complete.</li>
<li>The <span style="font-weight: bold;">Colossus249</span>
core-rope is verified to be 100% accurate.</li>
<li>The <span style="font-weight: bold;">Colossus249</span>
source code is 100% complete and accurate
(except possibly for the program comments).</li>
</ol>
</td>
</tr>
</tbody>
</table>
<br>
<ul>
<li>Website: Downloads of assembly listings created
by <span style="font-weight: bold;">yaYUL</span> for <span
style="font-weight: bold;">Colossus249</span> and <span
style="font-weight: bold;">Luminary131</span>, are now
available on the <a href="links.html">links page</a>,
the <a href="Colossus.html">Colossus page</a>, and the
<a href="Luminary.html">Luminary page</a>, to save the
reader the effort of building them or of downloading the
horrendously huge scans.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
One of the Mac OS X changes broke the Win32 build.
This has been fixed.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-04<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Colossus249</span>
core-rope image: Found a set of <span
style="font-style: italic;">three</span>
mutually-offsetting (i.e., checksum-preserving) errors
in bank 00. And a complementary pair of errors in
bank 12. Yikes!</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: More debugging.
Banks 00-26 (octal) out of 43 now debugged, though there
is an unsupported instruction used in bank 01 (so <span
style="font-weight: bold;">yaYUL</span> needs a tweak
to actually assemble the code).<br>
</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Various small tweaks needed for <span
style="font-weight: bold;">Colossus</span>: The
<span style="font-family: monospace;">DEC</span> and <span
style="font-family: monospace;">2DEC</span> pseudo-ops
previously did not treak -0 differently from +0.
The previous method of treating "<span
style="font-family: monospace;">ERASE <span
style="font-style: italic;">start - end</span></span>"
was incorrect; it is now equivalent to "<span
style="font-family: monospace;">EQUALS <span
style="font-style: italic;">start</span></span>".<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-02<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Website: Numerous small corrections and
rearrangements. Most significantly, there is now a
little more understanding of the <span
style="font-family: monospace;">EDRUPT</span>
instruction, there is more description of the various
proposed peripheral components (<span
style="font-weight: bold;">yaIMU</span>, etc.), and
the former <span style="font-weight: bold;">yaTelemetry</span>
page has been co-opted as a "yaOtherStuff" page to cover
<span style="font-style: italic;">all</span> of the
peripherals (other than <span style="font-weight:
bold;">yaDSKY</span>).</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: More debugging. Down to
about 243 fatal errors now.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-09-01<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Brought the ibiblio site online and automatically
redirected references from sandroid.org/Apollo to
ibiblio.org/apollo. (Keep fingers crossed.)
An important consequence is that the NARA finding aids
are now online rather than requiring a snail-mail CDROM.<br>
</li>
<li>Added a little more data about the original developers
to the <a href="index.html#Acknowledgements">acknowledgements</a>.
(Thanks,
Willard Simmons and Rob Stengel.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: More debugging. Down to
about 345 fatal errors now.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-08-31<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Debugged a lot. Right
now, there are no undefined symbols and about 575 fatal
errors. (Sounds bad, but at the start of the
evening there were, I think, about 700 undefined symbols
and 3000 or 4000 fatal errors.)</li>
<li>Began the process of moving the website to
ibiblio. It's a <span style="font-style: italic;">slow</span>
upload, but perhaps it will finish tomorrow.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-08-30<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>For downloads, I've eliminated
ftp.sandroid.org/Apollo, in favor of
www.sandroid.org/Apollo/Downloads, in preparation for an
expected move of Virtual AGC to ibiblio.org.
Hopefully the links have all been changed properly, and
so there should be no disruption unless somebody has
bookmarks specifically to ftp.sandroid.org. If so,
I apologize. The move will allow us much greater
capacity in terms of providing document scans.</li>
<li>Main makefile: Problem report #26 (spurious
error messages from <span style="font-weight: bold;">yaYUL</span>)
is now hopefully worked around, as far as builds of
Virtual AGC are concerned. (I knew about this bug
before, but didn't know that it was occurring in the
build and causing 'make' to fail. Thanks to Craig
Steffen for pointing this out.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Now 100% complete, though the
code is not yet debugged and the comments have not been
proofed.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">2004-08-29<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>I should have noted also that yesterday's update fixed
a problem in the Linux makefile, relating to installing
non-existent ephemeris data. (It existed on <span
style="font-style: italic;">my</span> machine, so I
didn't notice.)</li>
<li>Some additional bad links were fixed. (Thanks to
Ed Thelen.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
1362 (out of 1505) of the scan 1701.pdf is now
available. (In a sense, all of the source code is
now available, since all of the remaining stuff will be
adapted from similar <span style="font-weight: bold;">Luminary131</span>
files rather than transcribed. However, all that's
happened so far is the copying and not the
adapting. And of course, not the slightest portion
of it has yet been debugged.)<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/28/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Mac OS X Panther: Thanks to Matteo Giani, some
slight changes have made Virtual AGC buildable on Mac OS
X Panther. I suspect, but don't know, that this
will work on earlier versions of Mac OS X as well, if
X11 is first installed. The download page has been
changed to show the build-instructions, along with a
screenshot provided by Matteo.</li>
<li>Fixed a few bad links. (Thanks to Melissa Reid
for pointing them out.)</li>
<li>By the way, the existence of the Apollo 11 <span
style="font-weight: bold;">Luminary</span> and <span
style="font-weight: bold;">Colossus</span> source-code
listings at MIT has now been independently confirmed,
although I was pretty darned sure about it anyway.
(Thanks, Sandy Brown.)<br>
</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
1243 (out of 1505) of the scan 1701.pdf is now
available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/27/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Language manual: Added Peter Adler's theory as
to the history of the <span style="font-family:
monospace;">EDRUPT</span> instruction. Thanks,
Peter; you made me laugh.<br>
</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
1064 (out of 1505) of the scan 1701.pdf is now
available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/26/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code:
Source code through page 1037 (out of 1505) of the scan
1701.pdf is now available.</td>
</tr>
<tr>
<td style="vertical-align: top;">08/25/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code:
Source code through page 1011 (out of 1505) of the scan
1701.pdf is now available.</td>
</tr>
<tr>
<td style="vertical-align: top;">08/24/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaIMU</span>:
Well, it's not much <span style="font-style: italic;">yet</span>,
but it's something. (Namely, Earth/Moon/Sun
ephemeris data for the Apollo 8 mission epoch, and an
untried program for loading that ephemeris data into
memory.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
973 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/23/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code:
Source code through page 951 (out of 1505) of the scan
1701.pdf is now available.</td>
</tr>
<tr>
<td style="vertical-align: top;">08/22/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Website: Added a list to the <a
href="index.html#Acknowledgements">acknowledgements</a>
of as many of the Luminary/Colossus programmers as I
could find reference to.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
915 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/21/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaDSKY</span>:
Added the --delay command-line switch, in an attempt to
address PR#23.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
890 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/19/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaDSKY</span>:
Mr. Paul Fjeld has informed me that the digits in the
DSKY simulation haven't been quite right. (In his
words: "The digits on the [real] DSKY were unique
and very cool.") Since Mr. Fjeld is both an artist
and the Spacecraft Manager for LM-13 at the <a
href="http://www.cradleofaviation.org/exhibits/restorations/lem.html">
Cradle of Aviation Museum</a>, I'm inclined to believe
him. Besides, he prepared an all-new set of images
of the digits and sent them to me, thus saving me most
of the work in changing them. So obviously, the
appearances of the decimal digits have now changed in
the software, and indeed, have changed pretty
dramatically. (For now, though, I'll let all of
the <span style="font-style: italic;">screenshots</span>
on this website stay the way they are, so they're all a
little inaccurate.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
801 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/18/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Developer changes (normal functionality not
affected): My original intention was that <span
style="font-weight: bold;">yaAGC</span> would be
developed in a way that was very independent of the
peripheral devices (like the IMU and DSKY), and somewhat
independent as well from the means of interfacing to the
peripherals. Unfortunately, over time this idea
became corrupted to the point that it really became
impossible for developers to use anything other than the
default socket-based interface (which I still
recommend!), unless the <span style="font-weight:
bold;">yaAGC</span> source code itself was hacked
quite a lot. This has become unacceptable, since
there are a number of groups adapting <span
style="font-weight: bold;">yaAGC</span> to existing
flight simulators, or other purposes, and all of this
independent hacking will make it time-consuming to port
improvements to <span style="font-weight: bold;">yaAGC</span>
into all of these efforts. Therefore:</li>
<ul>
<li>I have separated all socket-based code from
the offending source-code file (agc_engine.c), and
replaced it instead by a simple 3-function API that
should be usable for developing memory-mapped i/o
models, embedded AGC's, or other purposes, <span
style="font-style: italic;">without further
modification to agc_engine.c</span>. <br>
</li>
<li>I have created an embedded demonstration (i.e., of
an AGC as embedded firmware) based on a Motorola
Coldfire microcontroller, using an unmodified
agc_engine.c.<br>
</li>
<li>These concepts will be explained in detail on the <a
href="developer.html">developer page</a>, over the
next week or so, though no details are available there
yet.<br>
</li>
</ul>
<li><span style="font-weight: bold;">yaAGC</span>:
(And speaking of improvements that need to be
back-ported ...) I have noticed that although I
provided all of the hooks for processing external
triggers for counters (such as gimbal CDU counters), I
did not actually implement them. In other words,
if <span style="font-weight: bold;">yaAGC</span>
received a signal to increment a counter register, it
would not actually do so. Hopefully this has been
fixed.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
776 (out of 1505) of the scan 1701.pdf is now available.</li>
<li>Win32 compile: This broke a couple of days ago
without my noticing it. Fixed now.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/17/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Today was a remarkable day for this project, for a
variety of reasons, of which I'll mention only the
following: Up to now, I have feared that only the
<span style="font-weight: bold;">Luminary</span> 131
(Apollo 13 LM) and <span style="font-weight: bold;">Colossus</span>
249 (Apollo 8/9 CM) software listings have survived,
since no other versions have turned up. However,
Mr. Paul Fjeld has told me of the existence of 3
additional AGC software versions, including (apparently)
both the <span style="font-weight: bold;">Luminary</span>
and <span style="font-weight: bold;">Colossus</span>
versions used for Apollo 11. While I don't <span
style="font-style: italic;">have</span> any of these,
so I can't make them available to you, there is now a
much stronger basis for hope that they can be provided
in the future. (Any volunteers in the Boston area
who would like to scan the Apollo 11 program
listings? Let me know.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
760 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/16/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code:
Source code through page 746 (out of 1505) of the scan
1701.pdf is now available.</td>
</tr>
<tr>
<td style="vertical-align: top;">08/15/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Miscellaneous: The <a href="developer.html">developer
page</a> now has a reasonably-detailed table of
suggested port assignments for interconnection of <span
style="font-weight: bold;">AGCs</span> and simulated
peripherals. The <span style="font-weight: bold;">SimLuminary131</span>
startup script has been changed in accordance with these
suggestions, with the bonus side-effect of allowing you
to use <span style="font-weight: bold;">SimLuminary131</span>
and <span style="font-weight: bold;">SimColossus249</span>
simultaneously without conflict.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
682 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/14/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span> and <span
style="font-weight: bold;">Luminary131</span>:
When building the software, a regression test has been
added in which the <span style="font-weight: bold;">Luminary131</span>
source code is assembled with <span style="font-weight:
bold;">yaYUL</span>, and the resulting binary is
checked byte-for-byte against the known-good
binary. This has the helpful side-effect of
creating Luminary131.lst --- i.e., an assembly listing
--- which is much more useful than having to use the
scanned listing (650 Mbytes, 1729.pdf).</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
629 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/13/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span> (and <span
style="font-weight: bold;">yaDSKY</span>), Win32
version: Some problems with socket-connections
between <span style="font-weight: bold;">yaAGC</span>
and <span style="font-weight: bold;">yaDSKY</span> have
been cleared up, so that <span style="font-weight:
bold;">yaAGC</span> can now be expected to detect that
<span style="font-weight: bold;">yaDSKY</span> has been
shut down. This means that if <span
style="font-weight: bold;">yaDSKY</span> is stopped
but <span style="font-weight: bold;">yaAGC</span> is
kept running, <span style="font-weight: bold;">yaDSKY</span>
can be started up again later without problems.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
544 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/12/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Miscellaneous: <br>
</li>
<ul>
<li>All of the Virtual AGC executables (or at any rate,
all of the important ones), display a common version
number separate from the build date, and controlled
from the Makefile. (Right now, the number
happens to be 0.90.) Undoubtedly, this will
evolve further in the future. <br>
</li>
<li>The process of creating the Win32 binary
distribution has been made much easier, and so it
should be easier to keep the binary distro more
up-to-date with the development snapshot.</li>
<li>The <a href="faq.html">FAQ</a> page has been
updated with hints on some of Virtual AGC's quirks.<br>
</li>
</ul>
<li>The <span style="font-weight: bold;">webb2burkey-rope</span>
utility is now part of the installation.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Upon connection of a new peripheral (such as a DSKY),
the peripheral is now updated with all current
i/o-channel settings. (Previously, the peripheral
simply received changes to the i/o channels on an
ongoing basis, but had no knowledge of channel outputs
prior to connection. This was bad on the Win32
platform where --- for some still-unidentified reason
--- peripherals can only be started after <span
style="font-weight: bold;">yaAGC</span> starts.)</li>
<li><span style="font-weight: bold;">Validation</span>:
Because
of the <span style="font-weight: bold;">yaAGC</span>
change mentioned above, it has become possible to remove
the artificial startup delay in the validation suite.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
527 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/11/2004</td>
<td style="vertical-align: top;">
<ul>
<li>Note to anybody who downloaded yesterday's dev
snapshot: somehow, the changes I made yesterday <span
style="font-style: italic;">did not</span> appear in
the snapshot, though the Win32 binary download should be
okay. Oh, well! Hopefully, today's snapshot
will be okay.<br>
</li>
<li>Miscellaneous: The default Win32 install
directory hardcoded into <span style="font-weight:
bold;">yaAGC</span> and <span style="font-weight:
bold;">yaDSKY</span> has been changed (from
/usr/local/bin) to c:/mingw/bin. This should let
command-line switches like --core and --cfg work
properly, instead of forcing full pathnames to be used
with them.<br>
</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
The default <span style="font-weight: bold;">yaDSKY</span>
graphical interface is far too big for any graphics
resolution less than 1024×768. I've therefore now
added another mode to <span style="font-weight: bold;">yaDSKY</span>,
in which interface is only half as big. Use <span
style="font-weight: bold;">yaDSKY</span>'s --half-size
command-line switch to get the smaller interface.
The smaller interface doesn't really look very good,
because it is simply blindly scaled down from the larger
interface, rather than being optimized, but at least
it's usable at 800×600 and 640×480 resolutions.</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
500 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/10/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Miscellaneous: <br>
</li>
<ul>
<li>I now take pity on you poor, deluded Win32 users,
and provide executable binaries for you rather than
forcing you to build Virtual AGC yourself.</li>
<li>I now provide shell scripts (or batch files for
Win32) for running various common configurations of
the simulator. These shell scripts are called <span
style="font-weight: bold;">SimLuminary131</span>, <span
style="font-weight: bold;">SimColossus249</span>,
and <span style="font-weight: bold;">SimValidation</span>.<br>
</li>
<li>Made sure that all executables show a copyright
notice and reference this website.</li>
<li>In Win32, if the build environment is based on <span
style="font-weight: bold;">Msys</span> as I
recommend, you can now just use "make", "make clean",
or "make install", rather than "make -f
Makefile.Win32", "make -f Makefile.Win32 clean", and
so on.</li>
</ul>
<li><span style="font-weight: bold;">yaAGC</span>: <br>
</li>
<ul>
<li>When typing HELP from the --debug command-line, the
help-text was curiously truncated. But the
help-text was far too long to fit on the screen
anyway, so I've now fixed it that the HELP-text is
topic-specific (resulting in much shorter messages).</li>
<li>In Win32, you can now get a debug prompt by hitting
the return while the program is running, just as you
can in Linux. To accomplish this, the program
has become multi-threaded. <a
href="http://sources.redhat.com/pthreads-win32/">POSIX
Threads
for Win32</a> is now an additional requirement for
being able to build Virtual AGC in Win32.</li>
<li>Now that running --debug mode in Win32 makes much
more sense, I've cleaned up the Win32 version of the
register display used in --debug mode.</li>
</ul>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
417 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/09/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaDSKY</span>:
PR #21 fixed. (<span style="font-weight: bold;">yaDSKY</span>
can now be built in SuSE 9.1 again.)</li>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
384 (out of 1505) of the scan 1701.pdf is now available.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/08/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code:
Source code through page 289 (out of 1505) of the scan
1701.pdf is now available.</td>
</tr>
<tr>
<td style="vertical-align: top;">08/07/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Colossus249</span>
source code: Source code through page
217 (out of 1505) of the scan 1701.pdf is now available.</li>
<li><span style="font-weight: bold;">Luminary131</span>
source code: A link to this website has been added
to the header of each source file.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/06/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code: Source
code through page 167 (out of 1505) of the scan 1701.pdf is
now available.</td>
</tr>
<tr>
<td style="vertical-align: top;">08/05/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code: Source
code through page 128 (out of 1505) of the scan 1701.pdf is
now available.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/02/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> source code: Resumed data
entry. Source code through page 36 (out of 1505) of
the scan 1701.pdf is now available.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/01/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
The
timing for polling has been changed, in order to reduce
the PC's CPU utilization. Also, backtrace
references (as originally intended) are no longer
created when not in --debug mode. (In Linux on my
2.8GHz P4, the net effect of these changes is to reduce
the CPU utilization from 90-98% to an immeasurably small
percentage whilst waiting for --debug mode keystrokes,
and to 0-2% whilst running the simulator. In
Windows XP, the CPU utilization is 0.)</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Fixed
a segfault that caused the Win32 version of the
assembler to crash.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/31/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
The
method used of selecting the positive or negative branch
in computing bugger words did not match the method used
by <span style="font-weight: bold;">YUL</span>.
Assembly
of the validation suite was broken by addition of the
bugger words; this is fixed. Numerous additional
fixes, related to selecting coding schemes for
interpretive operands, for avoiding conversion of
constants to addresses until absolutely necessary, for
correct ordering of inversion of interpretive operands
vs. incrementing of interpretive operands, for using
program labels that correspond to operator names like <span
style="font-family: monospace;">TC</span> and <span
style="font-family: monospace;">VN</span>, and so
forth.</li>
<li><span style="font-weight: bold;">Luminary131</span>
source code: Numerous fixes. <br>
</li>
</ul>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">The <span
style="font-weight: bold;">yaYUL</span> program
now assembles <span style="font-weight: bold;">Luminary131</span>
source code to the correct core-rope image.
Therefore, <span style="font-weight: bold;">yaYUL</span>
is now working and the source code for <span
style="font-weight: bold;">Luminary131</span> is
now correct. (However, <span
style="font-weight: bold;">Luminary</span>'s
source-code <span style="font-style: italic;">comments</span>
still need proofing, and <span style="font-weight:
bold;">yaYUL</span> still emits some confusing
errors and warnings.)<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/30/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
Fixes to formatting of the list-file output. Banks
are now terminated with their "bugger words".
Various assembly fixes, particularly to shift operative
instructions.</li>
<li><span style="font-weight: bold;">Luminary131</span>
source code: Numerous fixes. We're now down
to about 35 fatal errors and 765 mis-assembled core-rope
words.</li>
<li>Website: Lots of earlier development snapshots
have been removed in order to save megabytes. I
still have them, if anybody is interested.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/29/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Luminary131</span>
source code: A few minor fixes.</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Implemented the comma-suffix notation for the operands
of interpretive opcodes. We're now down to about
110 fatal assembly errors and about 1020 mis-assembled
core-rope words.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/28/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Luminary131</span>
source code and <span style="font-weight: bold;">yaYUL</span>:
Lots
more fixes of a similar nature to yesterday. The
number of mis-assembled core-rope words is down to about
1430, though the number of fatal errors has increased to
about 350.</li>
<li>The last few snapshots (I think) may have omitted the
core-rope binaries and/or may have included zipfiles of
some of them. Of course, it's perfectly easy to
build the core-ropes, but (on the grounds that people
may not like doing that) the new snaps will include the
core-ropes.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/27/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">bdiffhead</span>:
Added
the --only-super and --lst-super switches.</li>
<li><span style="font-weight: bold;">Luminary131</span>
source code and <span style="font-weight: bold;">yaYUL</span>:
Lots
more fixes of a similar nature to yesterday. The
number of mis-assembled core-rope words is down to about
6040.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/26/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">bdiffhead</span>:
This
is a new utility I've added for displaying the
differences between core-rope files. (It's only
useful for debugging <span style="font-weight: bold;">yaYUL</span>,
<span style="font-weight: bold;">Luminary131</span>
source, and <span style="font-weight: bold;">Colossus249</span>
source.)<br>
</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Added the --force command-line switch. Lots more
tweaks from working with <span style="font-weight:
bold;">Luminary</span>. There are only about
7700 core-rope words (out of about 39,000)
assembled with the wrong value now. (Sounds
bad, but a couple of days ago there were over 15,000
fatal errors, and the core-rope --- if I had bothered to
create it --- would have been 100% wrong.
And <span style="font-weight: bold;">yaYUL</span>
still assembles the <span style="font-weight: bold;">Validation</span>
program correctly, so we're not moving backward either.)</li>
<li><span style="font-weight: bold;">Luminary131</span>
source code. A lot more fixes. There are
only about 90 fatal errors now.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/25/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
The program is still incomplete, but at least it can
generate the symbol table for <span style="font-weight:
bold;">Luminary</span>. (Since there are over
7000 symbols in the program, I don't claim to have
performed an exhaustive check, but the symbols I have
checked are correct.)</li>
<li><span style="font-weight: bold;">Luminary131</span>
source code: A huge number of fixes (100's,
probably) discovered in the course of working on <span
style="font-weight: bold;">yaYUL</span>.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/23/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Validation</span>:
Added
a few seconds delay at startup, to allow running the
test without <span style="font-weight: bold;">yaAGC</span>'s
--debug
switch.</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Continued developing the framework for assembling
interpretive opcodes.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/22/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
Fixed PR #19, in which (somehow) I managed to break the
ability to assemble the validation suite. Put the
framework in place for assembling a lot of the
interpretive instructions --- though quite a bit of the
interpretive instruction stuff doesn't actually assemble
correctly yet (namely, the <span style="font-family:
monospace;">STCALL</span>, <span style="font-family:
monospace;">STODL</span>, <span style="font-family:
monospace;">STORE</span>, and <span
style="font-family: monospace;">STOVL</span>
instructions, and the operands).<br>
</li>
<li>The size of the development snapshot has been creeping
upward because of accidental inclusion of stuff like
output from <span style="font-weight: bold;">yaYUL</span>
and zipfiles of core-ropes. Some of the worst
offenders have been eliminated.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/21/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
Added various instructions-aliases and pseudo-ops:
<span style="font-family: monospace;">CAE</span>, <span
style="font-family: monospace;">CAF</span>, <span
style="font-family: monospace;">COUNT</span>, <span
style="font-family: monospace;">BBCON</span>, <span
style="font-family: monospace;">2CADR</span>, <span
style="font-family: monospace;">2BCADR</span>, <span
style="font-family: monospace;">1DNADR</span>, <span
style="font-family: monospace;">-1DNADR</span>, <span
style="font-family: monospace;">2DNADR</span>, <span
style="font-family: monospace;">-2DNADR</span>, <span
style="font-family: monospace;">3DNADR</span>, <span
style="font-family: monospace;">-3DNADR</span>, <span
style="font-family: monospace;">4DNADR</span>, <span
style="font-family: monospace;">-4DNADR</span>, <span
style="font-family: monospace;">5DNADR</span>, <span
style="font-family: monospace;">-5DNADR</span>, <span
style="font-family: monospace;">6DNADR</span>, <span
style="font-family: monospace;">-6DNADR</span>, <span
style="font-family: monospace;">DNPTR</span>, <span
style="font-family: monospace;">-DNPTR</span>, <span
style="font-family: monospace;">DNCHAN</span>, <span
style="font-family: monospace;">-DNCHAN</span>.</li>
<li><span style="font-weight: bold;">Luminary131</span>:
Various
typos fixed in source code.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/20/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Apparently I had forgotten to
implement <span style="font-weight: bold;">yaAGC</span>'s
--port=N command-line switch, so it wasn't possible to run
two instances of <span style="font-weight: bold;">yaAGC</span>
simultaneouly --- or at least not to run them and expect
both to connect to peripherals. (After daily snapshot
posted.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/20/2004<br>
</td>
<td style="vertical-align: top;"> Found complementary errors
in bank 02 of <span style="font-weight: bold;">Colossus249</span>
binary. (Lest anybody be suspicious as to how
complementary errors could have been found in both <span
style="font-weight: bold;">Colossus249</span> and in <span
style="font-weight: bold;">Luminary131</span> --- see
changes for 07/02/04 --- and wonder how many more of them
are lurking, I'd like to point out the following fact:
the banks in which complementary errors were found were
happened to be banks that I proofed before I honed my
proofing technique. So while I was somewhat surprised
to find these errors, I was not astounded to find
them. All of the remaining banks were proofed somewhat
better.)<br>
<br>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">Goto-pooh (V37E00E)
now works in the CM sim. As far as I know, the
CM sim is now working as well as the LM sim
is. Woo-hoo! </td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/19/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>A few additional fixes for Win32 builds that work on
some systems (with some versions of make) but not on
others.</li>
<li>Fixed some goofed-up instructions in the "quick start"
section for running the sims.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/19/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Now at v0.86; this is the version I intend for intial
announcement on freshmeat, in time for 35th anniversary
of the lunar landing, which is tomorrow. Added the
--interleave command-line switch (and associated
internal goo) to work around the incredible sluggishness
I've seen when running the simulation on slower
PC's. Reworked some of the data displays in
--debug mode to fit into the width of crippled Win32
command lines. The number of ports scanned for
socket connections is now 10 rather than 5.<br>
</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
Reworked the --help messages to fit into the width
of crippled Win32 command lines.</li>
<li>The simulation is now known to work on Windows 98.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/19/2004<br>
</td>
<td style="vertical-align: top;">Website changes: Lots
of screenshots added on the home page. Also, added
Frank O'Brien's amusing correction to the FAQ page.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/18/2004<br>
</td>
<td style="vertical-align: top;">The Win32 version now builds
again, and is known to run (at least on Windows XP).
The system is also known to work in a distributed
configuration (with <span style="font-weight: bold;">yaAGC</span>
on one computer, either Linux or Win32, and <span
style="font-weight: bold;">yaDSKY</span> on another
computer, either Linux or Win32). Minor cleanups of
the website have also been made.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/17/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Validation</span>:
Added
some delay loops in the validation suite to work around
some quirks in the prototype of Julian's
sim. Fixed the polarity of the PRO key,
which was inverted.<br>
</li>
<li><span style="font-weight: bold;">ControlPulseSim</span>:
Added
the <span style="font-family: monospace;">BZF</span>
pulses, the extra control pulses needed to handle it,
and handling for the br1,br2 flags (though I don't think
the latter are correct).</li>
<li><span style="font-weight: bold;">yaDSKY</span> and
*.ini: Added the control signals for the ALT and
VEL indicators to LM.ini. (Thanks to Julian Webb
for this info.) Also, finally got around to
eliminating the PRIO DISP and NO DAP indicators from
LM.ini; I've known they were bogus for about 8 months,
so it's about time! Fixed a bug in which bit 10 of
channel 13 could be used to turn on all of the DSKY
lights. Fixed the polarity of the PRO key, which
was inverted.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Final contents of L register now explicitly
overflow-corrected after <span style="font-family:
monospace;">DCA</span>, <span style="font-family:
monospace;">DCS</span>, and <span style="font-family:
monospace;">DXCH</span> instructions. The
default values of input channels 30-33 (octal) have now
been changed to reflect the fact that they contain
low-polarity signals rather than high-polarity signals.<br>
</li>
</ul>
<div style="text-align: center;">
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top; text-align: left;">Most
of
the various super-annoyances I've been having,
like the LM sim crashing 100 seconds after
power-up, and not being able to change major modes
in either the CM or LM sim have now suddenly
disappeared. <span style="font-weight:
bold;">yaAGC</span> and <span
style="font-weight: bold;">yaDSKY</span> now
appear to be <span style="font-style: italic;">working</span>
for the LM with only minor caveats.<br>
</td>
</tr>
</tbody>
</table>
<br>
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/16/2004<br>
</td>
<td style="vertical-align: top;">I've now had my first look at
the executable for Julian Webb's sim. In order to run
the validation suite on Julian's sim, I've created a
conversion program called <span style="font-weight: bold;">webb2burkey-rope</span>,
in the Luminary131 directory, which converts the core-rope
files between Julian's format and mine.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/16/2004<br>
</td>
<td style="vertical-align: top;">There was major code rework
done in <span style="font-weight: bold;">yaAGC</span>, with
the intention of making the L register (and possibly other
registers) 16 bits. The new code seems to work exactly
as well as the old code, in that stuff which worked before
still works, and stuff which didn't work before still
doesn't. The validation test does fail the D--LCHK
test now, as it ought to (considering the nature of the
changes). There are numerous comments concerning this
change that will have to propagate into the spec (language
manual), but which haven't done so yet.<br>
<br>
Also, the LOG command was added to --debug mode.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/14/2004<br>
</td>
<td style="vertical-align: top;">Added a new utility program
called <span style="font-weight: bold;">ControlPulseSim</span>,
which simulates some (but not all of the "control pulses" of
the CPU --- i.e., the microcode). From experimenting
with this and from discussions with Julian Webb, it seems
probable that at least the L register (and possibly all
erasable memory) will have to be made 16-bits. This
means that instructions like "<span style="font-family:
monospace;">CA L</span>" and "<span style="font-family:
monospace;">CS L</span>" don't presently work properly
when overflow is involved.<br>
<br>
... Or else, it means that the description of control-pulses
in Blair-Smith is not entirely accurate. It
contradicts some later docs (like Smally), so this is
possible. Must think more deeply ....<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/13/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Validation: Added error sub-codes and single
exit points to all of the tests that were written before
I thought of doing this.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/13/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Spec (language manual): Extensive changes, due
to the change of Q from 15 bits to 16 bits.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
All addition operations changed to work on full 16-bit
(non-overflow-corrected) values when the data source is
A or Q.</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
Fixed (I hope) the intermittent bogus display of +/-
signs.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/12/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaAGC</span>:
Added 16th bit to Q register. The correct
1-second delay now appears with "monitor" verbs (rather
than the bogus 2 minute 43.85 second updates we were
seeing earlier).<br>
</li>
<li><span style="font-weight: bold;">yaDSKY</span>:
Fixed a bug in the OPR ERR indicator introduced
yesterday, in which rather than a lit OPR ERR, we'd see
a dark KEY REL indicator where the OPR ERR was supposed
to be.</li>
<li>Validation: Smally's COUNTCHK, D--LCHK, O-UFLOW
added.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/11/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Website: Rearranged text between the FAQ page
and the home page. Add a "Quick Start" section to
the home page, illustrating some of the things you can
do with the simulation.</li>
<li><span style="font-weight: bold;">yaDSKY</span> and
*.ini: Added i/o-channel mappings mappings for the
GIMBAL LOCK, PROG, NO ATT, TRACKER, and STBY
indicators. Fixed the DSKY's reaction to channel
13, which previously was clearing the display any time
the DSKY-test bit was not set. The OPR ERR and KEY
REL indicators now flash. When flashing VERB/NOUN
is activated, we now flash the digits rather than the
VERB/NOUN labels above the digits. The flashing
rate has been changed from 1 cycle per second to 1.5
cycles per second.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/10/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Website: Fixed the links page so that it's
easier to get to spaceborn.dk's (Ron Noteborn's)
javascript DSKY simulation.<br>
</li>
<li>Validation: More stuff from Smally:
MSUCHK. Also, added error sub-codes to make it
easier to track down which specific test caused the
error.</li>
<li>Spec (language manual): The <span
style="font-family: monospace;">MSU</span> instruction
now says that overflow is cleared rather than set as a
result of the operation. In <span
style="font-family: monospace;">DCA</span> and <span
style="font-family: monospace;">DCS</span>, the
special cases of "<span style="font-family: monospace;">DCA
L</span>" and "<span style="font-family: monospace;">DCS
L</span>" are covered.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
The <span style="font-family: monospace;">MSU</span>
instruction has been "fixed"; this fix is dubious since
it is "to the test" rather than from the functional
description. The cases of "<span
style="font-family: monospace;">DCA L</span>" and "<span
style="font-family: monospace;">DCS L</span>" have
been added. And --- yikes! --- fixed a major
problem, in that I forgot to inhibit interrupts while
overflow is present; the result was intermittent loss of
overflow/underflow. By analogy with <span
style="font-family: monospace;">BZF</span> and <span
style="font-family: monospace;">BZMF</span> (see notes
for 07/08/2004), "<span style="font-family: monospace;">CCS
A</span>" has been changed so that +overflow is
treated as a +non-zero and -overflow is treated as a
-non-zero.<br>
</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Fixed <span style="font-family: monospace;">INDEX</span>
for the case in which the operand is a constant rather
than a program label.<br>
</li>
</ul>
<table summary="" style="width: 75%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="6" border="1">
<tbody>
<tr>
<td style="vertical-align: middle; text-align:
justify;">The CPU's instruction set is still buggy,
but at least there's a little more functionality
than previously. We can now run <span
style="font-weight: bold;">Luminary</span>'s or <span
style="font-weight: bold;">Colossus</span>'s
show-banksum program. (<span
style="font-weight: bold;">Luminary</span> will
freeze up about 100 seconds after power-up for some
reason, so it's probably better to try this with <span
style="font-weight: bold;">Colossus</span>.)
What the show-banksum program does is to
successively display checksum information about the
various banks of memory.</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/09/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Validation: Added Smally's DAS+INCR. The
validation program has become too large to fit into
fixed-fixed memory, so I've now split it up to use both
fixed-fixed and common-fixed.</li>
<li>Spec (language manual): The <span
style="font-family: monospace;">DAS</span> and <span
style="font-family: monospace;">DDOUBLE</span>
instructions have been changed so that the signs of the
less-significant and more-significant words of the sum
no longer need to match. In <span
style="font-family: monospace;">DV</span> with
dividend and divisor equal in magnitude, the remainder
is (and has been) the divisor; but we no longer say in
this case that the sign of the remainder is adjusted to
match the dividend.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Changed to match the spec changes mentioned
above. Also, when the <span
style="font-family: monospace;">DV</span> instruction
had a remainder of 0, it was always being treated as
zero without distinguishing between +0 and -0.<br>
</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Implemented the <span style="font-family: monospace;">2FCADR</span>
pseudo-op.</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/08/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Validation: Continued, with Smally's TC+TCF,
CCSCHK, BZMFCHK, RESTORE1, RESTORE2, RESTORE3, BZFCHK,
DXCH+DIM.</li>
<li>Spec (language manual): Changed to indicate that
positive or negative overflow block <span
style="font-family: monospace;">BZF</span> and that
positive overflow blocks <span style="font-family:
monospace;">BZMF</span>.<br>
</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Fixed the instructions <span style="font-family:
monospace;">CA</span> and <span style="font-family:
monospace;">CS</span> so that they re-edit the editing
registers. The spec changes mentioned above were
made in the CPU also.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/07/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Validation: Continued, by adding stuff
(particularly MPNMBRS and DVCHECK) from Smally (E-2065).</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Fixed the aliases for the <span style="font-family:
monospace;">ZL</span> and <span style="font-family:
monospace;">ZQ</span> instructions.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
The sign of the remainder for one weird case of the <span
style="font-family: monospace;">DV</span> instruction
has been fixed (and changed in the spec). A bug in
various types of DP arithmetic when the most-significant
or least-significant word is -0 has been fixed.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/06/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Validation: Continued by writing test code for
the <span style="font-family: monospace;">MASK</span>,
<span style="font-family: monospace;">READ</span>, <span
style="font-family: monospace;">WRITE</span>, <span
style="font-family: monospace;">RAND</span>, <span
style="font-family: monospace;">WAND</span>, <span
style="font-family: monospace;">ROR</span>, <span
style="font-family: monospace;">WOR</span>, and <span
style="font-family: monospace;">RXOR</span>
instructions.</li>
<li>Added instructions for using the validation suite to
the download page.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/05/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL</span>:
Had not been retaining the extracode flag after an <span
style="font-family: monospace;">INDEX</span>
instruction. Also, now add a notation in the
output list-file that shows where include-files end.<br>
</li>
<li>Validation: Continued.</li>
<li><span style="font-weight: bold;">yaAGC</span>: <span
style="font-family: monospace;">DXCH</span> was
deliberatedly not doing overflow-correction on the
accumulator before; now it is. Also, it was
incorrectly detecting the case "<span
style="font-family: monospace;">DXCH L</span>" (which
permutes the A, L, and Q registers).<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/04/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">yaYUL:</span>
Tweaked error messages so that they are formatted
similarly to <span style="font-weight: bold;">gcc</span>
error messages. (Useful when working in an IDE
that takes you directly to errors in the source
code.) For multi-word pseudo-ops like <span
style="font-family: monospace;">2DEC</span>, only the
first word was being written to the binary; this is
fixed.<br>
</li>
<li>Validation suite: continued to improve.</li>
<li><span style="font-weight: bold;">yaAGC</span>:
Handling of the 16th accumulator bit by the <span
style="font-family: monospace;">DCOM</span>
instruction has been fixed. Fixed handling of
signs in conversion of certain values from internal DP
representation to AGC DP representation. The <span
style="font-family: monospace;">DAS</span> instruction
was not leaving the correct values in the accumulator or
L register.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/03/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li>Have begun writing a "validation suite" program in AGC
assembly langauge, which I can use to test the
implementation of the AGC instructions one by one rather
than waiting to encounter them doing something flaky in
<span style="font-weight: bold;">Luminary</span>.<br>
</li>
<li><span style="font-weight: bold;">yaYUL</span>:
Now writes out the core-rope if there are no fatal
errors. Didn't do this earlier, since I was
waiting for a complete version of <span
style="font-weight: bold;">yaYUL</span> that could
assemble the <span style="font-weight: bold;">Luminary</span>
or <span style="font-weight: bold;">Colossus</span>
binary perfectly. We're not at that stage yet, but
I needed a way to assemble the validation program
mentioned above. (In other words, <span
style="font-weight: bold;">yaYUL</span> is capable of
assembling the validation program.) Also fixed a
bug in which the <span style="font-family: monospace;">INDEX</span>
instruction wasn't assembled properly with symbolic
operands.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/02/2004<br>
</td>
<td style="vertical-align: top;">
<ul>
<li><span style="font-weight: bold;">Luminary131</span>
core-rope image: PR #8 has been fixed. (<span
style="font-weight: bold;">Note</span>: The
core-rope image is now <span style="font-style:
italic;">known to be correct</span> not merely by the
indirect evidence of correct checksums, but because it
has been compared byte for byte with an image created
independently by Julian Webb. Thanks, Julian!)</li>
<li><span style="font-weight: bold;">yaAGC</span>: A
serious bug in the <span style="font-family:
monospace;">SU</span> instruction has been fixed, in
that the wrong operand address was being used.</li>
<li><span style="font-weight: bold;">yaAGC</span> --debug
mode: A bunch of new script files (for use with
the FROMFILE command) have been prepared. There is
one for each instruction type, and what they do is to
delete the "patterns" used to trap on those instruction
types.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">07/01/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span> --debug mode: Enlarged the
number of allowed breakpoints (watchpoints, patterns)
dramatically (from 32 to 256), in order to account for the
possibility of trapping upon executing a lot of different
instruction-type patterns. Allowed for nesting
FROMFILE commands. Fixed it so that COREDUMP and
FROMFILE don't automatically convert filenames to upper
case. Added scripts (usable by FROMFILE) for every
instruction type. Debug-mode commands beginning
with the character '#' are now discarded. Added a lot
more flags to the PATTERN command.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/30/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span> --debug mode: The concept of a
"PATTERN" has now been defined. This is like a
breakpoint, but halts upon finding a pattern in the
instruction code rather than at an address. The
FROMFILE command has also been defined, in order to take
debugging commands from a file rather than the
keyboard. I hope to use these in conjunction
with each other, to track down the remaining broken
instructions.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/13/2004<br>
</td>
<td style="vertical-align: top;">In <span style="font-weight:
bold;">yaAGC</span> --debug mode, fixed the sign of an
octal value displayed by GETOCT.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/11/2004<br>
</td>
<td style="vertical-align: top;">The Win32 version compiles
again (at least on Windows 98), but the Win32 version of <span
style="font-weight: bold;">yaAGC</span> is broken.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/09/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Fixed a couple of problems with
the <span style="font-family: monospace;">MP</span>
instruction: If the accumulator was +0 or -0 and the
other factor was not, then neither the accumulator nor the L
register was updated to contain the product. Also, if
the factors were non-zero but of the opposite sign, the
product was messed up.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/08/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Added primitive watchpoint
capability to the --debug mode.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/05/2004<br>
</td>
<td style="vertical-align: top;"> Assembly-language manual
documentation tweaks (de-inhibiting of interrupts for <span
style="font-family: monospace;">GOJ</span> or <span
style="font-family: monospace;">EDRUPT</span>). <span
style="font-weight: bold;">yaAGC</span>: Fixed <span
style="font-family: monospace;">TCAA</span>, <span
style="font-family: monospace;">ZL</span>, and <span
style="font-family: monospace;">ZQ</span>
instructions. Closed up some conditions previously
resulting in the zero register (7) being overwritten with a
non-zero value. <span style="font-weight:
bold;">yaDSKY</span>: Digit ND2 wasn't being
displayed --- instead, it was overwriting ND1. <br>
<table summary="" style="width: 75%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="6" border="1">
<tbody>
<tr>
<td style="vertical-align: middle; text-align:
justify;"> Today is a pretty big milestone, since
both <span style="font-weight: bold;">Luminary</span>
and <span style="font-weight: bold;">Colossus</span>
now (sometimes) accept input (such as nouns and
verbs) from the DSKY, and display information on the
DSKY. Alas! there are still bugs in <span
style="font-weight: bold;">yaAGC</span> that keep
it from doing anything really useful yet. But
up until today the DSKY just sat there and did
nothing, like a lump of virtual metal, so it's still
exciting.<br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/04/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: In --debug mode, now continues
to try to service client (<span style="font-weight: bold;">yaDSKY</span>)
connects or disconnects while waiting for keyboard input at
the debugger.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/02/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: In --debug mode, the BREAK and
DELETE commands didn't work properly in and around
superbanks, nor did the breakpoints themselves. The
wrong datatypes (unsigned vs. signed) were used for the EB,
FB, and BB registers in some places, causing the automatic
mirroring of BB into FB/EB to fail. The unused bits of
FB, EB, and BB were removed also.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">06/01/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Fixed indexed instructions for
negative indices. Also, the instruction executing
after <span style="font-family: monospace;">RESUME</span>
had been taken from the BBRUPT register, whereas it should
have been taken from BRUPT.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/31/2004<br>
</td>
<td style="vertical-align: top;">Instruction set in <span
style="font-weight: bold;">yaAGC</span> now essentially
rewritten against v0.50. Still not fully working, but
seems more convincing than before.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/29/2004<br>
</td>
<td style="vertical-align: top;">Finished drafting everything
I want to say in the assembly-language manual about how
machine code is processed. This is v0.50.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/25/2004<br>
</td>
<td style="vertical-align: top;">Finished documenting all of
the "basic" instructions (as opposed to the "extracode"
instructions), except that a few of the implied-address-code
instructions remain to be done.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/24/2004<br>
</td>
<td style="vertical-align: top;">Continued documenting the AGC
instruction set. So far I have <span
style="font-family: monospace;">CCS, DAS, EXTEND, INHINT,
RELINT, RESUME, RETURN, TC, TCF, XLQ, XXALQ,</span> but <span
style="font-family: monospace;">DAS</span> still needs a
few loose ends tied up.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/23/2004<br>
</td>
<td style="vertical-align: top;">Continued updating counter
descriptions in the assembly-language manual.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/22/2004<br>
</td>
<td style="vertical-align: top;">Added quite a lot of text to
the assembly-language manual, under the <a
href="assembly_language_manual.html#CPU_Architecture_Registers">CPU
architecture</a> section. (I think I really need to
finish most of this manual before proceeding further with
the emulator, because it's simply too hard to keep trying to
pull this info out of the original Apollo docs. I need
to pull the info from the Apollo docs into my own definitive
description of how the AGC works, so that my definitive
description can act as a set of requirements.) The <span
style="font-family: monospace;">send/recv</span> protocol
has also been modified so that it includes "counter pulse"
inputs to the CPU in addition to i/o-channel data, and the
assembly-language manual has a new (but incomplete) section
on the "unprogrammed sequences" associated with these
counter updates.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/20/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC:</span> Now update the Z register to
c(Z)+1 prior to decoding the instruction.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/19/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Made major fixes to the AD and
TS instructions, but there's still a lot more to do along
the same lines, I think.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/18/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: On the basis of some comments
in Luminary131 source code, output channel 7 now retains
bits 5-7 rather than just bit 7. Timers TIME5 and
TIME6 and their interrupts have now been implemented
(including the T6RUPT enable in output channel 013), though
I don't have enough info about these timers to know if I've
done it correctly. The interrupt for keypad input from
the DSKY is now implemented, and seems to work (and the ISR
reads back the right code from the input channel). (I
haven't included the PRO key in it, and don't know if I'm
supposed to.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/18/2004<br>
</td>
<td style="vertical-align: top;">The 'snapshot' target in the
makefile has now been modified so that future development
snapshots will have datastamps in the names. From now
on, new development snapshots won't overwrite old ones.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/17/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Added INTOFF, MASKON, and
MASKOFF commands to the --debug mode; INTERRUPT was
changed to INTON. Implemented timer registers SCALER1,
SCALER2, TIME1, TIME2, TIME3, and TIME4, as well as the
interrupts for TIME3 and TIME4.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/15/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: The interrupt-vector/RESUME
mechanism added yesterday was a little over-zealous, in that
it automatically saved and restored the A, L, Q, and BB
registers (in ARUPT, LRUPT, QRUPT, and BBRUPT); actually,
the interrupt-service code is supposed to do this if it
wants it done. My RESUME instruction was also broken,
as it continued to be decoded as INDEX 017. I've
changed the --debug mode's backtrace mechanism a little, in
that a RESUME instruction removes all of the backtrace-table
entries for the ISR. (Otherwise, the backtrace table
would become completely full with ISR stuff, and we'd never
be able to use backtraces to debug non-interrupt code.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/14/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Many instructions (particularly
DTCB and DTCF) which arithmetically modified the Z register
were broken. (I'm not sure they're all fixed now, but
a lot of them are.) The interrupt mechanism has now
been implemented, though no events have yet been configured
to trigger interrupts. The --debug mode now has the
commands INTERRUPTS and INTERRUPT to (respectively) view the
interrupt-request flags and to set an interrupt-request
flag. The BACKTRACES command also accounts for
branches due to interrupts.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/14/2004<br>
</td>
<td style="vertical-align: top;">The 'configure' script now
allows the command-line switches "--help" and "--prefix", so
that installation can be done to any directory. <br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/13/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>: Fixed addressing of
superbanks. Fixed the --debug mode EDIT command, which
I apparently broke yesterday. The emulation actually
manages to get to the AGC self-check code now, though it
doesn't seem to work right.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/12/2004<br>
</td>
<td style="vertical-align: top;">Primitive backtracing
ability added to <span style="font-weight: bold;">yaAGC</span>
--debug mode.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/10/2004<br>
</td>
<td style="vertical-align: top;">(After 20040510
snapshot.) Fixed synchronization of BB, FB, and EB
registers in --debug editing. Also fixed faulty
display in --debug of addresses in superbanks.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/10/2004<br>
</td>
<td style="vertical-align: top;">Various issues related to the
virtual i/o channels were fixed: <span
style="font-weight: bold;">yaAGC</span>'s handling of i/o
channels was incorrect, in that it internally used the wrong
numeric format for them, so none of them worked properly;
moreover, while <span style="font-weight: bold;">yaAGC</span>
read the virtual input port, it never actually wrote to the
virtual output port (except in --debug-dsky mode). As
a separate issue, both <span style="font-weight: bold;">yaAGC</span>'s
and
<span style="font-weight: bold;">yaDSKY</span>'s handling of
the PRO key was wrong, in that the wrong bitflag was used
for it. It looks like i/o channels are now handled
correctly, not only in normal mode, but in --debug mode and
in --debug-dsky mode. In experimenting with this, I
noticed that it is impossible in --debug mode to ever find
the PRO key pressed by checking "edit c32", because the PRO
key sets this bit when the <span style="font-weight: bold;">yaDSKY</span>
key is pressed, and then clears the bit when released.
Therefore, using "edit c32" will always find the bitflag
associated with PRO cleared. But you can see that it
works if you debug <span style="font-weight: bold;">yaAGC</span>
itself with <span style="font-weight: bold;">gdb</span>.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/09/2004<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span>'s --debug mode now has a command
("getoct") for converting numeric values to/from the AGC's
native format.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/08/2004<br>
</td>
<td style="vertical-align: top;"> Made various changes to make
the --debug mode of <span style="font-weight: bold;">yaAGC</span>
easier:<br>
<ol>
<li>The disassembler now shows opcodes for the
implied-address instructions, like "<span
style="font-family: monospace;">SQUARE</span>" instead
of "<span style="font-family: monospace;">MP A</span>"
and "<span style="font-family: monospace;">RETURN</span>"
instead of "<span style="font-family: monospace;">TC Q</span>".</li>
<li>When <span style="font-family: monospace;">INDEX</span>
is used with an instruction, the disassembler decodes
and shows the instruction with the index added (along
with a notation "w/i"), instead of leaving the user to
deduce it.</li>
<li>The timing used (i.e., the number of machine cycles in
a given period of real-time) was messed up when --debug
mode was used, since the time spent waiting at the
debugger prompt was not accounted for.</li>
<li>The timing also was not previously right with the
--resume switch, since the time used prior to generating
the core-dump wasn't accounted for.</li>
<li>The construct <span style="font-family: monospace;">sysconf(_SC_CLK_TCK)</span>
is now used in place of <span style="font-family:
monospace;">CLK_TCK</span>. This is required for
new compiler versions. I don't know if it will
break under older compilers or not. I <span
style="font-style: italic;">think</span> I've fixed it
to work with Win32 also.<br>
</li>
</ol>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/06/2004<br>
</td>
<td style="vertical-align: top;">'make install' now copies
*.ini, Luminary131.bin, and Colossus249.bin to the
installation directory (which is hard-coded as
/usr/local/bin, so it's not totally perfect).
Meanwhile, <span style="font-weight: bold;">yaAGC</span>
and <span style="font-weight: bold;">yaDSKY</span> will now
look in the installation directory for files specified with
the --cfg and --core switches, if not found in the current
directory. (These suggestions are due to Christian
Bucher.) Also, <span style="font-weight: bold;">yaAGC</span>
had not been displaying error messages when the file for
--cfg wasn't found, and this has been corrected. The
instruction "DXCH L", which is not unambiguously defined by
the docs, has changed in a way that conforms to comments in
the Luminary131 source. (Refer to address 33,03514, p.
888.) Fixed a potential divide-by-0 in the DV
instruction, but my impression is that my DV instruction
right now is completely wrong anyhow.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/05/2004<br>
</td>
<td style="vertical-align: top;">Continued working on <span
style="font-weight: bold;">yaAGC</span>. Some fixes
to INDEX, to CCS A, and to CCS with comparison values of
-1. Added S and N as synonyms for STEP and NEXT in the
debugger.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/04/2004<br>
</td>
<td style="vertical-align: top;">Continued working on <span
style="font-weight: bold;">yaAGC</span>. Fixed some
bugs in AD, DCA, and CS.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">05/01/2004<br>
</td>
<td style="vertical-align: top;">Fixed problem reports 3, 4,
and 5. Thanks to Christian Bucher for pointing
out the problems.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">04/29/2004<br>
</td>
<td style="vertical-align: top;">Lot of links broken.
Thanks to Christian Bucher for pointing this out.
Hopefully I got them all.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">01/02/2004<br>
</td>
<td style="vertical-align: top;">More CDROM-only
NARA-Southwest finding-aids links.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">01/01/2004<br>
</td>
<td style="vertical-align: top;">Added a bunch of CDROM-only
links for NARA-Southwest finding-aids I've created.<br>
</td>
</tr>
</tbody>
</table>
<br>
<input id="box2003" onchange="viewOrHide(2003)" checked="checked"
autocomplete="off" type="checkbox"><b>Hide 2003 change notes?</b>
<table summary="" id="table2003" style="width: 90%; text-align:
left; margin-left: auto; margin-right: auto;" hidden=""
cellspacing="10" cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;">12/30/2003<br>
</td>
<td style="vertical-align: top;">Added scans of Skylab and
Apollo-Soyuz training "data cards", and the report <span
style="font-style: italic;">The Apollo 11 Adventure</span>,
to the links page. Various corrections to the web
pages as well.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">12/25/2003<br>
</td>
<td style="vertical-align: top;">The <span
style="font-weight: bold;">Luminary</span> 1C (Rev. 131)
GSOP document is now complete and online---about 2300 pages,
45M. Merry Christmas!<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">12/22/2003<br>
</td>
<td style="vertical-align: top;">The <span
style="font-weight: bold;">Colossus</span> 1A (Rev. 249)
"guidance system operation plan" (GSOP) document is now
complete---and about 1840 pages, 43M in size.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">12/20/2003<br>
</td>
<td style="vertical-align: top;">Changed the documents
mentioned in the item below to PDFs (rather than TIFFs), and
added section 3 and half of section 4 to the <span
style="font-weight: bold;">Colossus</span> "operations
plan".<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">12/19/2003<br>
</td>
<td style="vertical-align: top;">On the links page, I've begun
adding scans of documentation not available elsewhere on the
Internet, or else previously available only in a corrupted
form. So far, I've added multi-page TIFFs of the
<span style="font-style: italic;">AGC4 Basic Training</span><span
style="font-style: italic;">Manual</span><span
style="font-style: italic;">,</span> the <span
style="font-style: italic;"><span style="font-style:
italic;">Preliminary MOD 3C Programmers Manual</span></span>,
and sections 1 and 2 of the <span style="font-style:
italic;"><span style="font-style: italic;">Guidance System
Operations Plan for Manned CM Earth Orbital and Lunar
Missions Using Program Colossus 1 (Rev. 237) and Program
Colossus 1A (Rev. 249)</span></span><span
style="font-style: italic;">.</span></td>
</tr>
<tr>
<td style="vertical-align: top;">12/01/2003<br>
</td>
<td style="vertical-align: top;">Mr. Gary Neff has provided
some scans of a page in <span style="font-weight: bold;">Luminary</span>
131 and two pages in <span style="font-weight: bold;">Colossus</span>
249 which had previously provided obstacles to validating
the <span style="font-weight: bold;">Luminary</span> source
code and the <span style="font-weight: bold;">Colossus</span>
core-rope image. The small amount of
previously-missing <span style="font-weight: bold;">Luminary</span>
source code has been added to the file P20-P25.s.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/30/2003<br>
</td>
<td style="vertical-align: top;">For <span
style="font-weight: bold;">yaAGC</span> debug-mode, have
added the ability to interactively halt execution, in
Linux. I don't know if this works in *BSD or in MacOS
X, but I know that it doesn't work in Win32.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/29/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaAGC</span> now supports all instructions;
however, it is still only minimally debugged. Erasable
memory and i/o-channel space now overlap properly. The
--debug mode has now been beefed up with a core-dump option
for erasable memory and i/o channels, so that execution of
the AGC program can be later resumed at a specific
point. Have now written the memory-map section for the
assembly-language manual.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/28/2003<br>
</td>
<td style="vertical-align: top;">Lots and lots of improvements
to <span style="font-weight: bold;">yaAGC</span>:
Many
more instructions implemented, bugs fixed, more debugging
commands added. Still not really working yet,
though. A detailed explanation of the new debugging
mode has been added to the <span style="font-weight: bold;">yaAGC</span>
page.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/26/2003<br>
</td>
<td style="vertical-align: top;">Resumed work on <span
style="font-weight: bold;">yaAGC</span>. The CPU
timing has now been corrected (previously it just ran as
fast as it could go). Added a primitive debugging mode
in which you can look at the AGC registers, single-step
through the AGC code, see disassembled AGC instructions,
etc.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/25/2003<br>
</td>
<td style="vertical-align: top;">The <span
style="font-weight: bold;">Colossus</span> 249 binary is
now completely reconstructed, and presumably ready for
use! (I.e., whenever <span style="font-weight: bold;">yaAGC</span>
is actually ready.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/23/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: All banks are now
completely proofed. However: Because the bugger
word for bank 35 was missing from the PDF, I've constructed
the bugger word on the assumption that the rest of my
proofed data is correct. Also, bank 36 requires more
demanding reconstruction (at location 36,2734), which I've
not yet completed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/22/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 43 (octal)
has now been proofed. Banks 35-42 have all been
through a first-proof, but none of them are error-free
yet. I've invented a technique (described in
Colossus249.binsource) through which it <span
style="font-style: italic;">may</span> be possible to make
bank 36 error-free, which has previously been thought
impossible without additional scans (see bug report #1).<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/18/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 34 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/17/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 32,33 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/16/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 27,30,31
(octal) now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/15/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 23,24,25,26
(octal) now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/14/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 22 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/13/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 20,21
(octal) now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/12/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 16,17
(octal) now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/10/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 15 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/09/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 14 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/08/2003<br>
</td>
<td style="vertical-align: top;">Added an Acknowledgements
section to the home page. <span style="font-weight:
bold;">Colossus249</span> binary: Bank 13 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/05/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 12 (octal)
now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/04/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 10,11
(octal) now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">11/03/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 7 now
proofed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/02/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 4,5,6 now
proofed. Added the CheckDec utility program.
There's now a Makefile under Luminary131, which builds
Oct2Bin, CheckDec, and the Luminary131 binary.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">11/01/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 0,1 now
proofed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/31/2003<br>
</td>
<td style="vertical-align: top;">Fixed a bunch of web links.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/29/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Bank 3 now
proofed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/28/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Now complete, but
not proofed. There are unrecoverable problems with it,
not solvable by proofing, in that the "bugger word" from
bank 35 and the values at addresses 2634 and 2734 of bank 36
are unknown.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/26/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 7-32 (octal)
are now in place, but not proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">10/25/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Colossus249</span> binary: Banks 0-6 are now
in place, but only bank 2 has been proofed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/22/2003<br>
</td>
<td style="vertical-align: top;">Instead of providing separate
instructions and methods for building each of the
executables, a single set of scripts/makefiles/instructions
is now provided to build/install all of the executables as a
single batch job.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/21/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaDSKY</span> and <span style="font-weight: bold;">yaAGC</span>
now actually work the same in Win32 as in Linux (and,
indeed, can be mixed-and-matched).<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/20/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaDSKY</span> and <span style="font-weight: bold;">yaAGC</span>
now build in Win32, and run. (However, the socket
communications don't work well enough for them to be fully
operational.)<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">10/19/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">yaDSKY</span> indicator lights have been modified,
so that instead of all being amber when lit, they are mostly
white when lit instead. (Only TEMP, GIMBAL LOCK, PROG,
RESTART, TRACKER, ALT, and VEL are amber now.) A lot
of descriptive text has been added to the website in the
form of a "howto" for building <span style="font-weight:
bold;">glade</span>/<span style="font-weight: bold;">gtk+</span>
programs under Windows, with the idea of eventually having
Win32 versions of <span style="font-weight: bold;">yaDSKY</span>
and <span style="font-weight: bold;">yaTelemetry</span>,
and possibly Mac OS X versions at some point.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">09/07/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Oct2Bin</span> has been changed to make it a lot
clearer whether messages are errors or just information.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">09/06/2003<br>
</td>
<td style="vertical-align: top;"><span style="font-weight:
bold;">Luminary131</span> binary (Luminary131.bin and/or
Luminary131.binsource) now completely proofed and
(presumably) ready for action! Of course, until <span
style="font-weight: bold;">yaAGC</span> (or <span
style="font-weight: bold;">yaYUL</span>) is ready, it's
not good for much.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">09/04/2003<br>
</td>
<td style="vertical-align: top;">29 (of 36) memory banks of
the <span style="font-weight: bold;">Luminary131</span>
binary now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">09/03/2003<br>
</td>
<td style="vertical-align: top;">26 (of 36) memory banks of
the <span style="font-weight: bold;">Luminary131</span>
binary now proofed.</td>
</tr>
<tr>
<td style="vertical-align: top;">09/02/2003</td>
<td style="vertical-align: top;">21 (of 36) memory banks of
the <span style="font-weight: bold;">Luminary131</span>
binary now proofed.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">09/01/2003<br>
</td>
<td style="vertical-align: top;">Now have the complete <span
style="font-weight: bold;">Luminary131</span> binary, but
only the first 15 banks (out of a total of 36) are
proofed. The other banks are known to contain errors.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/27/2003<br>
</td>
<td style="vertical-align: top;">Now have some (small) chunks
of <span style="font-weight: bold;">Luminary131</span> and
<span style="font-weight: bold;">Colossus249</span>
binary. Download page completely rewritten, so that
now there are some sensible downloads.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/20/2003<br>
</td>
<td style="vertical-align: top;">To the best of my knowledge,
<span style="font-weight: bold;">yaDSKY</span> is now fully
operational. Not all of the output-channel bits
controlling the indicator lamps have been identified yet,
but these will be added to configuration files LM.ini,
CM.ini, CM0.ini (which are complete except for this
information) rather than to <span style="font-weight:
bold;">yaDSKY</span> itself. The "--debug-dsky" mode
has been added to <span style="font-weight: bold;">yaAGC</span>
to allow testing of <span style="font-weight: bold;">yaDSKY</span>.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/16/2003<br>
</td>
<td style="vertical-align: top;">The web pages are now
up-to-date with all of the info I've systematized from the
original Apollo docs.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">08/10/2003<br>
</td>
<td style="vertical-align: top;"> Resuming development
.... I spent an enormous amount of effort on the
project for the first couple of months, but completely
burned myself out before getting any results that I felt
like inflicting on the geek community, and have had to veg
out since then to recover. At this point, I have the
following:<br>
<ul>
<li>Complete <span style="font-weight: bold;">Luminary131</span>
source code (but still presumably with lots of typos),
and no binaries.</li>
<li>A 90%-complete <span style="font-weight: bold;">yaYUL</span>
assembler.</li>
<li>A 95%-complete <span style="font-weight: bold;">yaDSKY</span>
simulation.</li>
<li>The framework of the <span style="font-weight: bold;">yaAGC</span>
emulator.</li>
<li>Some rewritten documentation.<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">04/04/2003<br>
</td>
<td style="vertical-align: top;">Got the idea for this
project, whilst watching the movie <i>Apollo 13</i>.</td>
</tr>
</tbody>
</table>
<br>
<hr style="width: 100%; height: 2px;">
<center> <br>
<span style="color: rgb(84, 89, 93); font-family: sans-serif;
font-size: 11.05px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
16.575px; orphans: auto; text-align: center; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display:
inline !important; float: none; background-color: rgb(255, 255,
255);"> This page is available under the <a
href="https://creativecommons.org/publicdomain/zero/1.0/">Creative
Commons
No Rights Reserved License</a></span><i><font size="-1"><br>
<br>
<a href="http://www.ibiblio.org"><img style="border: 0px solid
; width: 300px; height: 100px;" alt="Virtual AGC is hosted
by ibiblio.org" src="hosted.png" width="300" height="100"></a><br>
</font></i> </center>
<br>
<br>
</body>
</html>
