||I got a complaint that the VirtualAGC GUI
program wouldn't fit on a 800×480 7" Raspberry Pi
touchscreen. No kidding! Well, that's part of a
larger problem with it, it appears, in that while the
program was attempting to interrogate the screen size and to
adjust it user-interface format appropriately, that feature
doesn't seem to have been working. So I've addressed
both of those problems in the latest source-code updates in
the GitHub repository. Instead of trying to make
adjustments according to the screen size, the VirtualAGC GUI
program now depends on command-line options:
For use with --squish only, there's also a --maximize
command-line option that maximizes the program at startup.
There are no installers for this new program version as
of yet, but I'll get around to it sometime if I hear no
complaints in the meantime.
||Two significant documents were added to the
||A new document was added to the document
library, "Luminary 1B
DAP Preflight Performance Evaluation" (thanks to
Hartmuth Gutsche for spotting this doc for us). It's
an evaluation of the results of digital simulation of the
digital autopilot of Luminary 116 (Apollo 12). As it
happens, we already had a digital
simulation of Luminary 116 in our collection as well,
but it was from a somewhat later time and isn't the
simulation from which the report was written, presumably.
||Two new LVDC-related documents were added to
the document library, one sponsored and scanned by Mike
Stewart (thanks Mike!), and one cleverly found in the NTRS
stash by Nik Beug (thanks Nik!). These are presently
at the top of the LVDC section of
the document-library page, and I invite you to read
the descriptions there. However, the more-significant
of the two is a study (in 3 volumes), the "Flight Program
Language Requirement" document, of the feasibility of
replacing the LVDC assembly-language version of the LVDC
software with versions in 4 different programming
languages. As a part of this effort, large chunks (but
not 100%) of the pre-existing LVDC software were actually
ported to those 4 alternate languages, as well as being
flowcharted and described in detail. Thus, though this
document does not provide any LVDC code at all, it
nevertheless provides much more internal detail about the
LVDC software, in almost-usable form, than any other
documentation presently available. Unfortunately, it
is not complete enough in itself to allow reconstructing the
entire LVDC program.
||There are a couple of new LVDC-related
documents which Mike Stewart has managed to track down and
have scanned on his own dime (thanks, Mike!):
||Replaced the photo of the Block I nav-bay
DSKY on the Block I page
with a much better one.
||Added some documents to the library:
||We ended up getting a better scan of the CSM/LM
Spacecraft Operational Data Book mentioned yesterday.
||Added an earlier revision of the CSM/LM
Spacecraft Operational Data Book than we already had.
These books are generic, but have appendices for specific
spacecraft, and this now gives us a complete set of
appendices for the CSMs for Apollo 7-17. Specifically,
though, this new revision gives us the pad loads for the
Apollo 12 CSM, which we had not previously had.
||Mainly document additions:
I've also added a Python program called humanizeScript.py
to the source-code tree, for analyzing the DSKY playback
scripts (mentioned in the preceding entry) into reasonably
human-friendly form. This is mainly for my purposes
for producing documentation for this website, starting
from logged AGC i/o-channel data from NASSP, but I suppose
it could be useful for other folks as well. Also,
I'm sure that as a first version it probably has a lot of
3D-printed DSKY with integrated Raspberry Pi running yaAGC
that I've mentioned obliquely a couple of times in the last
few of days, I had been asked to provide some sort of a
facility for playing back pre-scripted AGC output-channel
commands ... i.e., for controlling the DSKY from a script
rather than from yaAGC, for things such as museum
exhibits. So I added a primitive recording and
playback capability to that DSKY program, which is called piDSKY2.py,
it being a Python 3 script rather than the classic yaDSKY
program. Having done that, I began to wonder where the
heck anyone would actually get a meaningful script to run on
the thing, since what you'd really want is realistic data
from an actual mission simulation, rather than something
recorded while just playing around with yaAGC and a
The answer to that, it seemed to me, was to see if NASSP could log data about AGC-to-DSKY output-channel transactions or if not, could someone add it for me? Well, Nik Beug was kind enough to not only pep up NASSP's logging capabilities to meet my needs, but also to send me the log for a sample mission segment, namely an Apollo 8 launch. So with a slight amount of work throwing together a little Python script for converting Nik's NASSP log format to the format I needed, I now had the ability to "play back" an Apollo 8 launch on the 3D DSKY. Yay, and thanks Nik! Hopefully we'll have a lot more of these scripts in the future.
Now, unfortunately, not everybody is going to be able to have one of the 3D-printed DSKYs, so my next thought was this: Why not modify yaDSKY2 so that it can play back these scripts? So ... now it can! The way it works is that if you click on yaDSKY2's PROG indicator lamp with a mouse, you get a file dialog that allows you to choose a canned script for playback. Naturally, I've added this to the introductory list of various fun things you can do with a Virtual AGC on our home page, as well as describing how to use the scripting capability on our yaDSKY page.
||A new page, DIY.html
(for "do it yourself") has been added, intended to be a
simple tutorial on writing and running your own custom AGC
programs to do stuff the AGC was never intended to do.
As if I could write anything "simple"! This is
prompted by the introduction onto the market of functional
3D-printed DSKY look-alikes with integrated Raspberry Pi
computers running Virtual AGC. It should probably be
called an iDSKY. With units such as that,
there seems to be a lot more interest in having the DSKY do
cute stuff that's not necessarily directly AGC related than
there is in pepping up the pure software simulation.
Probably because there's more of a motivation to get value
for your dollar, since the physical devices are costly while
the software simulation is entirely free. My
take on that is that it's fine to subvert the normal
functionality of the unit, but that it should be implemented
by writing programs in AGC assembly language to do it!
(Well, I have my ideas about it, and nobody is forced to
agree with me. :-) ) At any rate, this is my
attempt to encourage that. The new page is nowhere
close to being complete, but I think it has enough on it to
||An early version of the Luminary 1C
Programmed Guidance Equations document has been added to the
document library. We already had a later version of
the 1C document, as well as having the 1B document, so this
is a kind of "missing link" between them, I guess.
||For me (your own mileage may vary)
building Virtual AGC from source was failing due to compiler
warnings on the Raspbian Stretch operating system, though
continued to succeed on the (older) Raspbian Jessie
operating system. This has been fixed in the github
repository, and the Raspberry Pi build-procedure on our
download page duly updated.
||I've added some
description to our developer page of a Python 3 program
which can be used as the basis for quickly creating a
simple, low-performance simulated peripheral device for use
with yaAGC. Basically, it handles the details of
connecting the peripheral to yaAGC and of parsing the
information passed between them, leaving the developer with
the task of determining what's supposed to happen to data
to/from the AGC's input/output channels. The basic
motivation is that this might be a good way to throw
together physical implementations of AGC peripherals,
without having to concern oneself with C++ or cross-platform
graphical toolkits or other complicating factors, by
embedding a Raspberry Pi in them, and running a variation of
this Python 3 script on the Pi. There's also a sample
Python 3 script that illustrates how to use this technique
to create a (very) simple DSKY.
||The 2017-11-12 entry below, as well as our
document-library page, previously contained the suggestion
that the SKYLARK Program Change Requests (PCRs) recently
added to the document library might have represented
a complete set of the SKYLARK PCRs that had been implemented
in the SKYLARK software. That idea is now known to be
incorrect, and so those incorrect suggestions have been
removed. The reason we know it's incorrect is that our
copy of the SKYLARK GSOP contains an appendix which lists
(incompletely) the PCRs and PCNs as of March 1972, and it
turns out that there are lots of SKYLARK PCRs and PCNs for
which we don't have the text as of this time.
Alas! At any rate, the PCR table in the document
library has now been updated with this improved PCR/PCN
||I've been going through my to-do list — i.e.,
the list of things people emailed me about and that I said
I'd take care of Real Soon Now ... but then never actually
did anything. Some are astoundingly, forehead-slappingly
old. Many, of course, have resolved themselves over
the course of time without any intervention from me.
At any rate, here's a brief rundown for some of the
particularly egregious omissions of how they've affected
this website or the github repository, in chronological
order so that you'll get some sense of my guilt:
More to come later, probably.
||The good NASSP folks have been making an
effort lately to get our AGS (abort computer) simulation
integrated into NASSP, and into checking it out, which is
great! What Ryan Callaway in particular found was that
while a lot of stuff worked, a lot of stuff didn't work
either. Mike Stewart jumped right in and managed to
find a bug I had made in the AGS simulator, yaAGS. So
Ryan now reports that it "looks like all phases of
rendezvous work as advertised in lunar orbit. I used AGS
calculations for every part and ags controlled burns as well
with RR and PGNS as backup/basis of comparison" and "the AGS
aborts the LM beautifully in both DPS and APS aborts".
Which is not to say that yaAGS necessarily is 100% perfect
now, but this one fix has improved its behavior
tremendously. For now, you have to build the software
from source if you want this fix, and it hasn't migrated
into the installer packages for VirtualAGC yet. Great
||The AGS documentation has been reorganized
somewhat for clarity (I hope!), and now appears only on the AGS page itself
rather than being duplicated on the document
library page. It was simply too irritating to
||I was recently contacted by an graphic artist
who was doing a project that involved the binary patterns
used to encode characters, specifically in the word
"APOLLO", who wondered what the appropriate binary encoding
of these characters, easily recognizable by a 1960's
engineer, would have been in the Apollo era? I told
her to use EBCDIC encoding. Then, in a rare fit of
humility, I passed the question along to Hugh Blair-Smith as
well. Hugh also said that EBCDIC was the appropriate
answer, but then speculated about a separate matter:
Is it possible to actually display the word "APOLLO" (or
more accurately, "APOLO") directly on the DSKY itself?
As you may recall, the DSKY was used to display only
numbers and blanks, but that doesn't mean it isn't possible
for appropriate software to display other patterns as
well. Alas! it turned out not to be possible; none of
the characters A, P, or L can be displayed. In fact,
we ended up tracing through the DSKY's electrical schematics
to find every possible display pattern, and those wild patterns are now
listed on the developer page. Some nice images
verifying these patterns on Bruno Muller's hardware DSKY
emulation have also been added to that page.
||I'm told that the situation for building
Virtual AGC on Mac OS X is much worse than I imagined, and
that newer Macs now provide clang as the default C compiler,
rather than gcc ... and naturally, Virtual AGC was designed
for the ubiquitous gcc and not for using clang. And
equally naturally, my own Mac is an older one that sensibly
provides gcc as it ought. Well, that's life in the Mac
world, I suppose, of which I have very little
I've added experimental clang support in the github repository (it works on Linux at least), as well as providing a method of potentially using gcc in spite of the fact that Xcode wants to use clang. Both are possible approaches to the Mac problem. I've provided documentation as to how an adventuresome soul might try out these approaches on a newer Mac.
||Note that I really only want to support
VirtualAGC on Ubuntu/Mint/Debian desktop Linux systems,
given that I don't have infinite free time or patience or
knowledge to do otherwise. Nevertheless, I
occasionally check or (or receive user feedback about)
problems on Windows, Mac OS X, Raspberry Pi, alternate
versions of desktop Linux, etc., and do sometimes make an
effort to work around those problems. Over the last
couple of days, I've gotten feedback about some such
compilation problems, and so have made some changes related
||The SUNBURST 37 AGC program's comment-text
has now been completely proofed, and is in the GitHub repo,
so the transcription effort for SUNBURST 37 can now be said
to be 100% complete. I've also updated the now-proofed
color-coded, syntax-highlighted source code on this
website. As usual, the proofing data (based on
octopus/ProoferComments) can be found in the
GitHub wiki, for anyone inclined to double-check the
||Added a description of Dario Kubler's
physical DSKY to the
physical-implementations page, including a cute
YouTube video. Dario sent me most of this info several
years ago, but I (stupidly!) failed to write it up; in fact,
I think he sent me several more pictures that I need to dig
out and include as well.
||The octals for SUNBURST 37 (Sunburst32.binsource)
are now in the GitHub repo, and have been proofed, and have
correct checksums, so SUNBURST 37 can now presumably be run
in the AGC simulator. (None of this is built
automatically nor integrated with the VirtualAGC GUI, so to
run it you have to create the rope file with "Tools/oct2bin
<Sunburst37.bin" and then run yaAGC from a command line
whilst specifying the rope file oct2bin.bin for it.)
We're also transcribing the SUNBURST 37 source code from the scanned program listing now, so anyone interested in helping should head over to the GitHub repo and look at the instructions.
As I mentioned in my note from a couple of days ago, instead of locally posting individual page images for SUNBURST 37 in reduced-quality JPG form, which is my normal practice for all other AGC versions, I had instead simply locally reposted the PDF from our Internet Archive collection, thinking that it was "good enough". In other word if you followed the links on our Luminary page, you'd probably end up downloading this supposedly-fine PDF. Well it wasn't good enough, so ... my apologies! The PDF has weird artifacts in which some characters were frequently replaced by other characters, such as 'D' in place of 'O'. Whatever the reason for this weird effect, it's obviously intolerable, so if you follow through the links to our locally-posted reduced-quality images now, you'll now find individual JPG pages. The high-quality images in our Internet Archive collection don't have this strange problem, and so can be used without fear, but I definitely would not recommend using the PDF found there.
As a corollary, we now realize that Emerson was wrong, and that a foolish consistency may not be the hobgoblin of little minds, if the effect of that consistency is to enforce a tried-and-true method rather than succumbing to untested novelties without having a good reason to do so.
||The program listing for AGC program SUNBURST
37 is now available, scanned for our Internet Archive
collection from Don Eyle's hoarded copy, and financed by
Peter McDermott! Thanks all. See our Luminary page.
As you may recall, SUNBURST 37 (also known as SHEPATIN 0) is an early version of the SUNBURST program, never used for any mission, though SUNBURST 120 was used later in the LM's AGC in the Apollo 5 unmanned mission. Like RETREAD and AURORA, SHEPATIN is another "missing link" in the AGC software's evolutionary development.
As usual, we'll be producing an octal file for this (so that SHEPATIN can be run in the AGC simulator) as well as source-code files (so that we can do nice searching on it, have syntax-highlighted listings, and so on), but that will be a process that takes a bit of time. Right now, all we have is the scanned pages.
I've departed from my usual practice of providing local low-resolution JPG page images here at our main website, and have instead chosen to use a PDF as the local "low quality, lower size" version of the scanned page images. (The PDF was good enough, and I didn't feel compulsive enough to insist on turning it into JPGs. As Emerson said, a foolish consistency is the hobgoblin of little minds.) As usual, though, the full-quality scanned pages are available in our Internet Archive collection.
||Added 3 more sections of the Apollo 9 LM GSOP
(we already had 1 section, out of 6 sections total), as well
as the AC/Delco study guide associated with that software
version. (Well, actually, the LM's AGC program was
SUNDANCE 306 and the study guide is for SUNDANCE 302, but
that's close enough for government work.
Literally.) All were from the UHCL archives.
Added to both the document library page and the Apollo 9
entry on the Luminary
||Two new CSM System Handbooks, and one new LM
System Handbook, from the UHCL archives. See here.
||New documents added to the document-library
page, but the most-significant is that our scan of Don
Eyles's copy of the AGC LEM PGNCS Manual (Volume II) has now
arrived. As was speculated and hoped-for in advance,
it does contain AGC Block II schematics missing from
the previously-existing set of individual schematic pages
from Eldon Hall's collection. Moreover, it contains
DSKY schematics. See here.
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.)
||The second (of two) volumes of the Spacecraft
Operational Trajectory for Apollo 14 has arrived from UHCL,
and has been added to our
||I submitted our speculations (mentioned a few
days ago) to Don Eyles, about the reason the Apollo 11 and
12 digital simulations from his collection were made after
the landings. While he does not actually remember, he
agrees that our speculations about Apollo 11 are probably
right, but doesn't entirely like our speculation about
Apollo 12 ... partly, I think, because my description
introduced errors not in Nik Beug's and Mike Stewart's
original explanations to me. At any rate, I've
rewritten both speculations on the
Luminary page, in a way that gets closer to the truth
about Apollo 12 than what I had mistakenly written before.
||In the cross-platform VirtualBox VM which the
downloads page recommends for most users, the light-weight
browser (Midori) provided with the VM for examining AGC
source code and various other purposes, has been exhibiting
some anomalous behavior that I hadn't noticed before.
I think this may stem from the fact that in the VM releases
I've made so far, a fairly old version of Midori is being
used. While I'll obviously fix this in the next
release of the VM, the download page now includes the simple
instructions for updating Midori to the latest version,
which (so far!) seems to fix the problems that I've been
able to reproduce. In other words, if you have a
version of the VirtualAGC VM that uses Midori rather than
Firefox, go follow the instructions on the download page to update
||As I mentioned a couple of days ago, the
newly-added Apollo-era digital simulations of the Apollo 11
and 12 lunar landings were both made after their
respective landings ... a few days after for Apollo 11, and
a few months after for Apollo 12. The speculation was
that the Apollo 11 simulation was made to help investigate
the 1201 and 1202 program alarms experienced during the
landing, but we didn't have a speculation about the Apollo
12 simulation. Well, Nik Beug (and Mike Stewart) have
come up with a pretty-convincing explanation, namely that
the simulation was for investigating certain proposed
changes to the landing code, and the fact that it used
Apollo 12 AGC code for that was really just
coincidental. You can read more of the explanation on
the Luminary page.
||Made a number of requested improvements to
the pre-built VirtualAGC VM, as described near the top of
the downloads page. One
of the more-significant improvements is an update script
that makes it easier to update the VirtualAGC software
within the VM. This script can also be downloaded and
used with older versions of the VM, as
||Two more lunar landing simulations, both from
Don Eyles's personal collection and financially sponsored by
Matthew Fite (thanks, Matthew!), have now
arrived. As usual these days, these have been added to
our Luminary page, and you can either view them there in
convenient PDF form,
our Internet Archive collection. Both simulations were made slightly after the landings themselves.
||Another nice document from the UHCL archives,
this time Delco's manual for the Block II Command Module
guidance system. We already had a fraction of a
corresponding Block I document, but this one is about 20×
larger than what survived of the Block I document, so it's a
bit more useful. Here's a direct link so you don't
have to pore over the Document Library page to find it:
||The "Programmed Guidance Equations for
Skylark" document, divided into parts for size reasons,
obtained from the UHCL archives, has been added to the
document library and Colossus pages. This document is
specific to Skylark 48, which we currently believe is the CM
AGC program used for Apollo-Skylab (and possibly for
Apollo-Soyuz, though we really don't know). Since we
don't actually have any source code for Skylark so far, and
since the "Programmed Guidance Equations" are a kind of
pseudo-code description of the source code, I guess this is
the next-best thing to having the Skylark program
itself. At any rate, here's a direct link:
The "Programmed Guidance Equations for Colossus 3"
document, divided into 3 parts for size reasons (Part
3), scanned from the University of Houston Clear
Lake archives, has been added to the document library and
||Fixed a few more crummy hyperlinks on the
document library page.
||Lately, there has been some confusion as to
whether the Luminary 99 source code we have been providing
is actually the code that flew in the Apollo 11 LM or not,
due to AGC developer Jim Kernan's recollections that there
are three different revisions of that particular code
(Luminary 99, Luminary 99 Rev 1, and Luminary 99 Rev 2), and
the only version we actually have is Luminary 99 Rev
1. Well, on the balance of the surviving evidence,
what we currently believe is that Luminary 99 Rev 1 did
indeed fly in Apollo 11, but also that Jim's recollection is
correct and that there's a Rev 2 that is "better" in a
certain way, but which didn't fly. But we have no
physical printout for Rev 2.
The explanation is that the ephemeris data in Rev 1 is wrong, but not very wrong, and certainly good enough for a lunar landing. Nevertheless, we know what the correct ephemeris should be, because it's identical to Apollo 12 and 13, so to celebrate that fact, we've artificially recreated Luminary 99 Rev 2 for you, as a mashup of 99 Rev 1 and Luminary 116, and we provide both Rev 1 and Rev 2 for you. You can view the source code or simulate either one to your heart's content. You can take your pick. It's called "choice", friends! We've named Luminary 99 Rev 2 "LUM99R2" in the GitHub source tree, because that's what Jim's story says he called it, way-back-when.
We have also received new information about where a program listing for Comanche 44 exists. Comanche 44 did not fly on a mission, but Comanche 45 Rev. 2 (which is 2 months younger) flew in the Apollo 10 command module, so if we can get our hands on Comanche 44 some day, it may be the closest thing we'll ever have to Apollo 10 Command Module software. At any rate, the Colossus page has been updated with this info.
||Don Eyles has squirreled away ~200 "LUMINARY
Memos", out of the ~250 such memos that are known to
exist. These are documents that the MIT
Instrumentation Lab used to track the development of the
Luminary software. Don has scanned around half of
these for us so far, with the other half presumably
forthcoming within the next few months. To handle this
vast glut of incoming documents, I've given them their own section in the
document-library page. There's lots of notable
stuff there, but what stands out for me are:
||A number of new documents for the document
library were added. Highlights are:
|2017-02-10||Added a cool document to the document library, "LM Rendezvous Procedures, G Mission" by Grega and Neily, which should be very useful for anyone wanting to fly simulated G or H missions, and likely J missions ... i.e., Apollo 11-17, though 11 and 15-17 are the only ones of those for which we have both the CM and LM software at present, and hence the only ones for which you could presently do a rendezvous. Thanks to Clark Neily for sending this! Even if you're not interested in rendezvous procedures, check out the document's title page for a real hoot. More material related to this topic will be forthcoming in the near future.|
|2017-02-07||A very significant LVDC-related document has been added to the document library, namely IBM's "Saturn Instrument Unit LVDC Equation Defining Document (EDD) for the Saturn IB Flight Program", divided into 7 PDFs due to its size: 1, 2, 3, 4, 5, 6, 7. Thanks to Riley Rainey for acquiring this, and the University of Alabama Huntsville's M. Louis Salmon Library for making it available at the U.S. Space & Rocket Center archive.|
||As I mentioned a few days ago, our scan of
the 1971 simulation of the Apollo 11 landing leaves somewhat
to be desired in terms of the readability of the text ...
it's just too light for comfortable reading, because the
printout was too light. Thus, to compensate for that,
I had provided a highly-processed B&W PDF that is
much-more readable. Well, I've now done some
additional processing on the color images, to enhance the
readability to the best of my admittedly-meager abilities,
so I've posted the reprocessed color
images as an additional alternative. They're not
uniformly good, but I think they're an improvement over the
full-resolution scan at archive.org.
||All sponsorship opportunities for the Don
Eyles's scannable materials offered so far — there
are other, smaller docs remaining, but they aren't cataloged
yet — are now taken. So if you were keen to help with
that ... too bad! I like to think there will be more
opportunities in the future. And it's great news.
I've accordingly removed the giant Volunteering Opportunity note that had been stuck at the top of the home page, though you can still read all about it if you like.
||As you may have seen in the notes made here
over the last few months, I have been in the process of
proofing and correcting the comment text in the various
source-code transcriptions we have made of the AGC program
listings available to us. Hitherto, we had no
efficient way to do this, but had developed a tool for doing
so that worked quite well on most of the of program
listings, with newer scans tending to work much better than
older ones ... hence in doing this proofing, I found myself
working backward in time, progressing from the latest AGC
scans to the earliest, finally reaching the original
scans with which the Virtual AGC project started, namely
Colossus 249 (Apollo 9 CM) and Luminary 131 (Apollo 13 LM),
as well as the somewhat-later Artemis 72. The scans
(or the associated printouts from which the scans were made,
or the destructive OCR processing done on them) for Colossus
249 and Luminary 131 are so bad that the "efficient"
proofing tool cannot be applied at all, while Artemis 72 is
highly questionable. Thus, a different and more
time-consuming proofing process was required.
I have just completed proofing Colossus 249, and the results are available in GitHub now. What has been done with it is to note that Colossus 237 (which preceded it chronologically by a short time), and Comanche 55 (which followed it chronologically) had already been proofed using the "efficient tool". A 3-way side-by-side "diff" between the transcribed source code from these three AGC program versions was done. This highlighted places where errors (many, many errors) might exist. An extremely-large number of errors was corrected in Colossus 249 in this way, along with a (much smaller) number of errors that lingered in the already-proofed Colossus 237 and Comanche 55.
This proofing process also benefited from the availability of an alternate scan of Colossus 249, not available originally, but available nowadays from the collection of AGC developer Fred Martin. Thus, many parts of the original scan that were garbled to the point of illegibility, could now be filled in with absolute certainty.
More than you wanted to know, probably, but having just finished it, I'm still excited about it! :-)
A similar 3-way proofing of Luminary 131's comment text awaits availability of comment-proofed source-code Luminary 116 and Zerlina (derived from Luminary 145), neither of which is available now, but both of which are expected to be available within a few months. Unfortunately, for Artemis 72, the last Colossus version, there is no prospect of a 3-way diff with predecessor and successor versions, but merely a 2-way diff against a predecessor version that may not be a closely-related as we would hope, so it will probably come last of all. But we'll see what we'll see.
||I've added a few "new" names to the list of AGC
developers, relayed to me by developer Henry Noble,
who also wasn't yet on the list. This reminds me that
the original list I made only took into account the names I
found within Luminary 131 and Colossus 249 ... whereas we
actually have lots and lots more AGC listings now, so I
should go through all of them and pull out more names!
And, I ought to add their affiliations, when they're known;
thus Henry worked at Raytheon. But I haven't yet
done those latter things.
The web-pages themselves have been internally cleaned-up in terms of their HTML coding. Hopefully, this has been done in a way that is 100% transparent to anybody viewing them, but it's always possible that problems might have been introduced in the process. Obviously, let me know if you see anything funkier than you expect!
The licensing on all of the pages has also changed, from what (in the U.S.) would have been an implicit copyright by me (Ron Burkey), with all rights reserved, to a Creative Commons No Rights Reserved license. This is equivalent to being in the Public Domain in the U.S., and is the closest equivalent to that in parts of the world where the concept of the public domain is not recognized. I learned this from something Nina Paley wrote in connection to her marvelous animated film, Sita Sings the Blues ... which, if you've not seen it, you should! She had originally released it for free under the Creative Commons Attribution Share Alike License, which already was unbelievably brave, but still had the effect of reserving some legal rights for herself. But she later concluded that since she knew she wasn't going to sue anybody for breaching the license anyway, what was the point of reserving any rights? So she simply changed the licensing in the same manner I am doing now. (Of course, I don't claim to have to have the guts she does, since I derived no financial benefit from this website anyway, so the licensing is irrelevant to my checkbook.)
Comparably gutsy to Nina's film is Kimiko Ishizaka's release of her piano renditions of Bach's Goldberg Variations under this same CC0 license. Highly recommended. I'm not sure of the licensing used for her later recordings of Book I the Well-Tempered Clavier or the Art of Fugue, though Wikipedia claims that the Well-Tempered Clavier has indeed been released to the public domain as well. Kimiko is a German-Japanese, former Olympic bronze medalist in powerlifting, and concert pianist, which is pretty interesting in itself.
||Colossus 237's source-code's comment text has
now been completely proofed, and
its proofing data published online, should you choose
to do a proofing pass on it yourself.
||The comment text for Solarium 55 has been
in the GitHub repository, so its colorized,
syntax-highlighted assembly listing has thus been
its proofing data published. It has also been removed
from the volunteering page's list of AGC versions requiring
This Retread 44 source code, unlike under source-code releases so far, as already been completely proofed in terms of its comment text, so I can proudly present it without a warning label.
Also, the Luminary 210 source code (Apollo 15-17 LM), announced a few weeks ago, has also had its comment text belatedly proofed, so it too is now gloriously warning-free!
The proofing data for both has been published online as well, for anybody interested in doing additional proofing passes on them.
The volunteering page has also been drastically reworked, as I realized that most the procedures and instructions given there were drastically out of date.
though, as almost-always for such initial announcements of rope availability, what this means is that:
||The comment-proofing data for Aurora 12 and
Sunburst 120, as well as the octal-proofing data for
Luminary 210 and Luminary 69, have now been posted online,
to join the Luminary 99 and Retread 44 proofing data
mentioned a couple of days ago.
The promised wiki article describing the usage of this
data has now also been written. That article
provides specific links to all of the available
Regarding the latter point, it is worth noting that the
Artemis 072 (Apollo 15-17 CM) code has been available for
a few years now, so that it is possible in theory to fly
an entire simulated Apollo 15-17 mission ... if the AGC
were the only issue involved in doing so.
||The Mac OS X build-instructions on the
download page are now functional (with the latest
source-code changes in the GitHub repo), and at least on my
primitive Mac (Mac OS X Lion), Virtual AGC can now be build
for Mac OS X.
(Though transcription of the Luminary 210 assembly-listing scans to source code is not yet completed, and transcription of Luminary 069 to source code has not really begun yet.)
In other words, not only is the Sunburst 120 source code
now available, but the assembler can assemble it without
error, and the executable rope will be word-for-word
identical to the known-good memory rope. Building
from source now assembles Sunburst 120 in addition to all
of the other available AGC versions, though it continues
to be the case that it is not integrated into the
VirtualAGC GUI program, and can only be assembled or run
in the simulator from the command line.
In other words, not only is the Aurora 12 source code now available, but the assembler can assemble it without error, and get the identical executable rope mentioned in the prior update.
Of course, I announced the AURORA 12 rope nearly a month ago, but for some curious reason failed to emphasize it as I normally do for new AGC versions, so I'm doing that now. In fact SUNBURST 120 has been available for a few days as well, though I forgot to update this change-log. In both cases, you still have to explicitly build the rope from the corresponding "binsource" file — "oct2bin <Sunburst120.binsource" or "oct2bin <Aurora12.binsource" — (with the rope being oct2bin.bin afterward), but you can do that and run either or both in yaAGC if you're of a mind to do so. In both cases, the source-code transcription is making progress, but isn't yet ready, so this is the only option if you want to run one of these programs right now rather than waiting for full availability.
||Lots of updates throughout the website, as I
review pages I haven't looked at in a while. Mostly
these are minor updates, though I marvel at some of the
oversights, such as: Not mentioning any of the Gemini
developers who helped me so much in the acknowledgements
section of the main page? Really? How dumb it
yaYUL page, in the discussion about the original YUL
program, pointed out that the original YUL was not
written in the Honeywell 800's ARGUS language, though it was
a Honeywell 800 program, and described the background for
||The various syntax-highlighted, hyperlinked
AGC program listings (Artemis072, Comanche055,
etc.) have all been updated with respect to the current
versions of their corresponding AGC source files, but the
principal change is that the symbol tables appearing at the
ends of the top-level files for these program listings are
now hyperlinked. In other words, if you click on a
link in one of these symbol tables, it takes you directly to
the point where that symbol is defined. This is a big
help, I think, because previously you actually had to know
which file the symbol was defined in, and now you do not.
||The main page now begins with a special help
offer — i.e., an offer for a way you can help us,
and that's about as special as things can get! — which is
explained fully on the
experimental pseudo-op, SECSIZ, has been added to the
yaYUL AGC assembler. This optional pseudo-op may be
useful during the process of transcribing hardcopies or
scans of AGC program listings into ASCII source-code form.
The program listing does have some issues, but nothing that we won't be able to work around. As usual lately, reduced-quality but faster-to-load images are hosted here, while the original-resolution but slow-to-load images are hosted at archive.org. Be aware that the archive.org images may not be stable for the next week or two, as their quality-control system works to fix whatever problems (that they can) with the scans. The imagery here will continue to be available regardless.
|| Some big news for today is that
But also, on a separate note, it has slowly dawned on me that I don't have AGC electrical schematics on our document-library page. I thought I did, but I don't! (No wonder I can never find them.) The Block II schematics, as contributed by Eldon Hall, have been on the klabs.org site for many years, but since NASA no longer funds it, that site is unfortunately now essentially a zombie and one wonders how much longer it will persist. So as of today, I'm now mirroring all relevant AGC material from that site here, in our document library. The highlights of the additions are:
It also seems that there may be a perception on the part of the AGC modeling community, if there is such a thing, that the available Block II AGC schematics are so incomplete that constructing a hardware Block II AGC sim is impossible. (That's why, I've been told, everyone continues to do Block I sims.) Well, Mike Stewart has certainly made a Block II sim that's good enough to help him track down and fix bugs in our own software sim, so while the Block II schematics may not be perfect, they are certainly not so incomplete as to prevent using them for this kind of project. And here are Mike's links to prove it:
As it happens, Mike has given me his evaluation of the completeness/incompleteness of the Block II AGC schematics, and I provide that assessment in the document library as well, for anyone interested in this kind of thing.
||The nav-bay version of the Block 1 DSKY
simulation is now available at GitHub, and the descriptions
on the Block 1 page have been altered accordingly, as well
as adding screenshots of the nav-bay DSKY to the Solarium
demo on that page.
Aurora what? Aurora is a very early version of the Luminary program, prior to any manned missions, prior to any unmanned ones ... though not quite the earliest one, which is called Retread. We will soon be engaged in the process of turning Aurora into source code, assembling it, running it on the simulator, etc., which is a process that takes a considerable amount of time. Read more about it on our Luminary page. Or contact us directly if you would like to help out in the process of converting Aurora page images to source code!
|| Well, this has been an interesting
day. I expected to have one significant announcement
today, and instead have two of them. First,
It is, unfortunately, unclear if the code can ever be run in the AGC simulator or not, but I'll think about it for a while before saying "no".
Second, and perhaps more importantly even though I haven't chosen to color it red, I was wrong in one very significant way about Francois Rautenbach's extractions of the rope-memory contents, and that is that it was not from Apollo 6 (Solarium 055) as I said, but rather is the Corona program from the AS-202 ("Apollo 3") mission, which we do not have already, and have no other prospects for acquiring. Moreover, it is simply in the form of stored electrical waveforms rather than a file of numbers representing the values stored at various memory locations. But perhaps it could be converted, and perhaps the Corona binary can be reverse-engineered back into the form of source code, which we will do if at all possible and present it here. So stay tuned.
||The discussion of CPU utilization in the Raspberry Pi build
instructions has been updated to include the Pi 3,
which has a much-lower utilization than the Pi B+, which was
the only model previously discussed.
||A number of goofy hyperlinks fixed.
||The download page now has Raspberry Pi
pre-built binaries on it, as well as installation
instructions and build instructions for Raspberry Pi,
contributed by Laszlo Morocz and Scott Sumner. Thanks,
Laszlo and Scott!
||The download page has been updated so that it
now provides not only the old Linux installer (which is
known not to work with some newer Linux versions like Linux
Mint 17.3 and Ubuntu 14.04), but also a newer
installer, specifically built for Linux Mint 17.3, and
therefore hopefully working for Ubuntu 14.04 or later as
well. Sadly, I'm not set up to test it as thoroughly
as I used to be on every platform under the sun! There
are also updated build-instructions. The code reflects
corresponding updates to the GitHub repository.
|| Well ... anyone who has looked at this will
notice that this website hasn't been updated in 4
years! The updates today are more to see if I still can
update the site after all this time, rather than anything
substantive. Perhaps more will follow. I
apologize to everyone who has sent me to-do's in the
meantime. They haven't been forgotten, merely
neglected, if that's of any consolation to anybody.
Today's changes are simply:
||Gemini: More bug fixes
to the OBC assembler program, yaASM. I think it's pretty close to
100% correct now. I've also created an OBC CPU
emulator called yaOBC,
which is also pretty close to 100% functional, except there
are presently no physical or emulated peripheral devices to
attach to the CPU yet, so it's purely an emulation of the
CPU in isolation. There is, however, a primitive
command-line based debugger interface included, from which
you can view or edit memory, run the OBC program, single
step, set breakpoints at instructions or data locations in
memory, etc. The source code for these is in
subversion, and executables
for the programs can be downloaded from here.
||Gemini assembler: I
realized somewhat belatedly that I hadn't accounted for
overlaying program modules in memory. this has been
fixed by changing the syntax of the CODE
and DATA directives in OBC
assembly language slightly. Both the yaASM program itself and
the write-ups on the Gemini page have been fixed.
|| All things Gemini:
|| I've been very lax about
updating this site, and so have a pretty large backlog of
stuff to deal with that people have sent me and that has
just been sitting on my to-do list. Sorry about
that! First, a status report:
||In the document library,
provided the multi-page fold-out flowcharts of the Gemini
catch-up and rendezvous simulation program as separate
single-page images. Also, added several documents
related to the IBM 704/7090/7094 systems that I found useful
in porting the program to make it buildable with gcc. (The porting
isn't yet complete, in that I'm still working on various of
the assembly-language subroutines.)
||On the Gemini page, corrected
"Ferney Hough" to "Dal G. Ferneyhough, Jr." Also,
added a photo of Gene Mertz et al., and some additional recollections
||Mike Jetzer pointed out that
all of the links to the Apollo press kits on the
document-library page were wrong. (Thanks,
Mike!) That has been fixed.
||Have made most of the PDFs in the Document Library searchable by adding a background OCR'd text layer. I say "most" because I tried to do all of them, but may have missed a few. If so, I'll catch them later. Have continued the process of adding bookmark panes and metadata (title, author, etc.) to them, but that's a much slower process since it's entirely manual.|
||Re-photographed and re-posted Fred Martin's Colossus 237 program listing. Not that I thought there was anything wrong with what I had, but because I still had the listing in hand and had acquired a better camera. The new photos have much better contrast (the background is lighter and the text is darker), so it's a good improvement.|
||Since there's now a site-search bar, I think it's appropriate to make sure that all of the PDFs in the Document Library have embedded metadata (such as title & author), sidebars with bookmarks to the various sections of the doc (where appropriate), and background OCR to make them searchable (where the document characteristics are compatible with Adobe Acrobat's OCR capability). Obviously it will take a good long while to fix up all of the PDFs, and even longer for Google to reindex them, but I'm making a start on it as of today.|
||Added a site-search bar to
the top of every page. It's swell!
||Added several "Apollo
Experience Reports" to the Document
Library, including reports on the "programers" (yes,
that's the real spelling) which were the automated stand-ins
for crewmen on the unmanned missions Apollo 4, Apollo 5, and
||Added a Gemini spacecraft computer page,
even though it's empty right now, and added documentation
(all scarfed from the Meadville
Space Center website) of the Gemini spacecraft
computer to our Document Library.
This is partly sheer compulsiveness, but also partially
because John Pultorak has pointed out that the LVDC must be descended from the
Gemini computer, simply because of some very deep
similarities between them.
||Added a "how to digitize" page to
||Integrated an LVDC page into the website.
It's a work in progress, but it has enough info on it now,
and enough corrections and improvements from the
corresponding wikipedia article, that it's starting to
||I no longer observe the
persistent FreeBSD problems I mentioned at the bottom of
yesterday's post, even though I haven't fixed them. I
wonder if perhaps FreeBSD doesn't have to be be rebooted
after building Virtual AGC or something wacky like
that. At any rate, today the FreeBSD native build
seems to be 100% functional and virtualy identical in
behavior to the other builds.
||Added scans of the Apollo 8
Flight Plan (sections
sections 3-5), contributed by Fred Martin.
||Added some new documents (memo and
addendum) describing the detailed method originally
used to find approximations for solar ephemerides data
suitable for use by the AGC. Thanks to Bill Robertson,
one of the original developers!
||Stephan Hotto has sent along
a bug-fix the LM-Simulator program. The bug was found
by Riley Rainey. Thanks to both!
||(SVN only at the moment,
since no development snapshot released yet.) Building
on Onno's syntax-highlighting ideas, yaYUL and yaLEMAP now have an
--html command-line switch which allows them to directly
create HTML of their assembly listings. These are not
only colorized, but also have hyperlinking from wherever
symbols (such as constants or line labels) are used back to
the points where they are defined. The HTML forms of
the listings are available from the yaAGS,
Luminary, Colossus, and links pages.
||On the download page, added a
section about networking problems, to cover problems which
have been observed with Fedora 11, as well as to summarize
potential problems I was already aware of on other
systems. Thanks to Onno Hommes for reporting the
Fedora 11 problem and fix.
||On the "volunteering" page,
I've added a lot of material about proofing tasks (octal
listings and program
comments) that I wouldn't mind accepting help
with. Those tasks were previously mentioned, I think,
but were basically left to the imagination.
I doubt that would justify a new download at this point, unless you're trying to do native Win32 builds and they're failing.
||I've reposted all of the
Comanche 055 (Apollo 11 CM) page images, having processed
them with reduced contrast from previously. The page
images are somewhat less pretty than before, in that the
backround color is darker and much less uniform, but the
text is more legible in the lower-left quadrants of many of
the pages. Although I've not updated the source-code
tarball, around half of the page images have been converted
to source-code files available in the subversion
repository. Work on conversion of Luminary 099
(Apollo LM) page images to source code has not yet begun.
The hardcopy from which these images were taken is from the Charles Stark Draper Historical Collection, MIT Museum, Cambridge, MA. The digital scans were produced by Paul Fjeld. Many thanks to Debbie Douglas of the MIT Museum for having the great foresight to arrange for these images to be made available to us, and to Paul Fjeld for performing the dreary work of creating the digital page images! More on this later.
||The FreeBSD native build is
now working again, to the extent that I'm able to check
it. The build instructions for it have changed a
||The VirtualAGC main screen
has been reworked to take up less space. This is
principally necessary on screens which are 1024×768 and have
a large dock or toolbar at the top or bottom of the
screen. However, I like the new layout better anyway
as it seems more logical to me. There is no functional
||I have had reports of the ACA
(hand-controller) simulation not working on some versions of
Mac OS X, so I have made a change. Instead of always
using the yaACA3
simulation program (which superceded the earlier yaACA simulation program
for snapshots 20090331 and later), the VirtualAGC GUI front-end
now allows for using yaACA
and yaACA3 somewhat
interchangeably. Basically, it will use yaACA3 unless it notices
that yaACA has been
configured, and then it will use yaACA instead. The yaACA program has also
been tricked up similarly to the yaACA3 program in that it now automatically
saves its joystick-related switches to a configuration file,
so that they become the defaults at the next run. Read about it in detail
if you have experienced a non-functional joystick.
(And don't send me any jokes about that, please!)
||I fixed the FreeBSD bugs
mentioned yesterday, and am now willing to say that Virtual
AGC works in FreeBSD. Instructions for building from
source on FreeBSD have been added to the download page. I'd
be lying, though, if I said it was thoroughly tested.
Unfortunately, I only have FreeBSD running in a virtual
machine, and the marriage of FreeBSD (PC-BSD) to VirtualBox
has not proved a happy one for me, so my ability to test the
the FreeBSD installation is very crude. When I say
Virtual AGC "works", I mean that I can run VirtualAGC, that I can
start the simulation, that I can put in verbs and nouns on
the DSKY and it does what I expect it to do, that I can see
telemetry downlinks, and that I can perform digital
uplinks. If anyone wants to send me more data, I'd be
happy to see it, but I've done all I expect to do on the
FreeBSD side in the absence of feedback.
As far as substantive changes are concerned, I fixed a couple of makefile bugs which prevented Virtual AGC from building on FreeBSD. It now builds—and works, as far as basic functionality is concerned—but fails after certain directory manipulations are made, so it still needs some tweaking. However, I've added some build instructions for it on the download page.
|| As far as the website itself
is concerned, various people have sent me interesting and
useful stuff which I've added. I won't detail those
things here, except to say "Thank you!" to Dimitris Vitoris,
Mirko Mattioli, and Onno Hommes. Some important corrections have been
made to material on the the website itself, thanks to
||yaDSKY and yaDEDA
have been superceded by rewritten replacements yaDSKY2 and yaDEDA2 to improve
portability and distributability. Moreover, there is a
completely new yaTelemetry
program to replace the Digital-Downlink-monitoring
functionality previously kludged into yaDSKY (but missing from
||There's now a GUI front-end
that conveniently ties all of the Virtual AGC bits and
pieces together that were previously provided only
incompletely and relatively unsatisfactorily through a few
very simplified command-line scripts. I call this
front-end program VirtualAGC.
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 LM_Simulator
module didn't have its various very-useful help screens.
||The current development
snapshot fixes a bug which has existed since 2007-03-16 in
the development snapshots, but not in any of the binary
downloads (since I've not posted new versions of the binary
downloads in that time period). The bug, very simply,
is that the LM_Simulator
module would abort if used in a CM simulation, even though
it would work in an LM simulation. The upshot of this
is that if you tried to start a CM simulation using any of
the provided scripts (SimColossus249,
SimArtemis072, or SimArtemis072_lite) then
the simulation would abort with an error message. I
suspect that some folks have complained to me about this and
that I blew them off with an explanation that there was
something misconfigured about their computers. If you
complained and I ignored it, I apologize.
Development of Virtual AGC has been on hold for a while, but I expect it to pick up again soon, with a vengeance. (For everyone who has sent me stuff with which to update the website and it has seemingly fallen into a black hole, I'll finally be adding your updates!) So watch this space.
||Added a nifty photo
Alessandro Cinquemani has sent in of the Pultorak-style
AGC/DSKY he is constructing.
I've completed all the subassemblies, which are now in their final form except for the DSKY. I plan to make it a 3 PCB unit; 1 PCB for the mainboard/keyboard, 1 for the LED display/caution & status lights and 1 for the interface daughterboard.That's necessary because the keys I'll use (RS 336-191) are a little tall and I'll have to elevate the displays. Also I plan to design my DSKY in such a way that it can be used in any revision I plan to make by just exchanging it's I/O daughterboard. You'll find that there are 5 new elements in this revision:
The MCAs are the separated monitoring busses and control switches from each A0 module. The MC is the main power distribution hub,
panel illumination controller and using it you can power down any or all the monitoring panels at will.
I have attached together with the A1 schematics the following:
As before these schematics should NOT be considered final and may contain errors. Looking forward for your comments and suggestions!
|| Stephan Hotto has sent
version 1.0 of LM_Simulator,
both in source code and in the Windows "stand-alone"
executable version, with the following notes:
||I have found a backdoor into
"archived" HRST website, and modified the links page
accordingly. However, I'll still continue to host the
documents, because it gives me a chance to improve them.
||As mentioned earlier, MIT's
Dibner Institute, whose website (HRST) formerly hosted most
of the scans of historical AGC documents on which Virtual
AGC is based, has closed and its website is gone. I have decided to begin
hosting the documents formerly available from HRST, with
improvements to some of them, here at Virtual AGC.
Some of the documents---particularly the assembly
listings---have been improved from the versions formerly at
HRST; others will be improved in the future. It may
take a while to find and fix all of the now-broken links, so
if you find any of them let me know.
|| Okay ... I haven't updated
the development snapshot or website since dev snapshot
20060110, mostly from laziness. Agood thing, too,
because since then a very nasty bug had been introduced into
yaAGC, but I
couldn't find it or fix it because I was falsely blaming the
symptoms on the LM_Simulator
changes. Hooray for laziness! But yaAGC is now
If you're iffy about installing the new dev snapshot, here's the executive summary of changes since 20060110:
|| Busy Stephan has sent still
update, as follows:
|| Stephan has sent another LM_Simulator update,
which he describes as follows:
Now the FDAI shows the correct 8-ball angles - currently with a limitation to:
Yaw: 0Deg \B190Deg
Pitch: 0Deg \B190Deg
Roll: Anyway limited by the Gimbal Lock condition at 0Deg \B185Deg
The functionality of the DAP and the dynamic model as well as the displayed FDAI angles can be verified by using the "Crew Defined Maneuver Routine V49". By initiating this routine you must provide the desired destination IMU Gimbal Angles, subsequently the AGC presents you with the associated FDAI angles it steers the LM to (please refer to the Tutorial). Because of the above mentioned limitation those FDAI angles should be in the defined range. [By the "tutorial", Stephan means the Contributed/LM_Simulator/tutorial.txt, which you'll get by downloading the development snapshot of Virtual AGC.]
The CPU load maximum lies around 20% on an Intel Core Duo 2.13GHz processor.
|| Here's a sort of omnibus
update that takes into account stuff people have been
sending me over the last year or so. I apologize to
anybody who sent me something I've forgotten about!
Additionally, Stephan tells us:
The DAP is now stable around all axes and even the "DAP V49 Crew Defined Maneuver" routine steers the LM exactly into the right orientation.
There was a major bug in the IMU coordination transformation that caused the DAP instabilities.
Furthermore, to handle single RCS jet events it was necessary to transform the U,V jet system into the P,Q,R pilot axes.
The whole dynamical model of the LM is now based on the equations used for the DAP state estimator. This approach makes the model very precise and comparable to the real thing.
To assure the right AGC initialization it is necessary to stick to the following pre-conditions and steps:
|| Have added the
SimArtemis072_lite startup script, have tried out Artemis072
in Win32, and have hopefully updated all of the web-pages to
properly reference Artemis072.
Unfortunately, it may be quite a long time before the source code for Artemis072 is available, so we'll just have to live with having only the executable for a while.
||All data entry and proofing
for the Artemis 072 (Colossus 3) executable has been
completed, and some startup scripts have been added for
it. I haven't yet made the necessary mods to the
webpages yet to explain how to use it, nor have I gotten the
chance yet to try it in Windows. Tomorrow,
hopefully. In the meantime: Start the simulation
using the script "SimArtemis072". (I'm really only
posting it today just in case I happen to die overnight,
which I presume is unlikely.)
||I now have in hand the
complete listing of the Colossus 3 (Artemis 072) executable
used in the CM of Apollo 15-17. Thanks to D. Thrust
for providing the scans! It will take me some time to
convert it into machine-readable form so that it can be
executed by the AGC simulator, but I will proceed with it as
quickly as possible. I don't yet have much of the
Colossus 3 assembly-language source code, but hopefully it
will make an appearance as well, in due time.
||Well, I seem to have hit the
jackpot this week, in terms of getting into contact with
some of the original AGC programmers. Eileen Hughes
has sent me the first names of several
programmers---including her own---while Jonathan Addelston
has written to tell me that I was spelling his name
wrong. Sorry about that! The acknowledgement
list on the home page has been corrected.
|| I've been holding onto some
changes for a while, so let's hope I manage to remember them
all. The reason I was holding on is that I have seen
some segfaults in yaAGC
when manipulating the RHC. However, now that I am
trying to fix them, they've magically disappeared. (If
you experience such problems, please send me the files
called "core" and "LM.core". Thanks!)
The downside is that you can no longer use any command-line parameters with the batch files. I've tried to make intelligent choices as to which command-line switches you might want, but if I'm wrong you need to edit one or another of the files SimLuminary131.xeq, SimLuminary131_lite.xeq, SimColossus249.xeq, or SimColossus249_lite.xeq. (These ".xeq" files contain the lists of files, along with their command-line parameters, that are run by WinAGC.exe.) Even then, there are some things you can't accomplish, such as running yaAGC or yaAGC in --debug mode. If you want to do that, I'd suggest setting the environment variable NOWINAGC=yes before running the startup scripts, as this will restore the batch files to their pre-WinAGC glory.
Another downside is that that Allegro and Tcl/Tk are now really requirements rather than options, although I've not had a chance to update the instructions yet. The reason is that the startup scripts will abort if yaACA and LM_Simulator cannot be run, rather than ignoring it. (I must say, though, that you really want to run both of these things, although admittedly yaACA isn't of much use without a "3D game controller" --- i.e., a joystick. Therefore, buy a joystick.) If you absolutely don't want to run these programs, or cannot for some reason, edit the appropriate ".xeq" file and prefix the yaACA and/or LM_Simulator lines by the character '#' (without quotes, of course).
The simulation reaches the correct Delta Velocity of about 2400m/s (about 8000ft/s) after using the complete fuel. The start values I'm using are obtained from the Lunar Module Wikipidia page and the pad load file.
||Well, I now like yaDSKY's ability to
display downlink lists so much that I've split off that
ability from the "--test-uplink" command-line switch, and
added it to a new "--test-downlink" command-line
switch. In fact, "--test-downlink" is used by default
in the SimLuminary131
startup scripts. Of course, the ability to completely
display all downlink lists isn't quite available.
However, the erasable dump downlist is still available, and
the AGS initialization/update downlist is complete.
||yaAGS: Finally have a sensible DVP instruction, I
think. (A rational person could still disagree with
this assessment, I suppose, so you're still invited to
examine the DVP
code in aea_engine.c to offer your opinion.) However,
I've noticed some anomalous behavior that I didn't notice
before, in that the DEDA will freeze up, or readouts will
occur that I can't figure out any way to stop, but it
doesn't seem to have anything particularly to do with the DVP
instruction. Typically, this will be readout of
address 555, which begins spontaneously, and which I can't
||Have now worked out the
details needed for the digital uplink, and have described
them in a new "Fictitious I/O Channel" section on the
developer page. However, I haven't yet implemented it
in yaAGC. (No
new new yaAGC
features are needed for the digital downlink, though I admit
I'm unclear yet on the mechanism used to transfer state
vectors between the CMC and LGC.)
||yaAGC: 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.)
|| In yaAGS, I've implemented
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 DVP instruction in
the function aea_engine
of the source file aea_engine.c, and give me your insights
on the matter. Otherwise, though, yaAGS 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.
||Lots of work on yaAGS, but mainly in the
form of improving debugging (fixing i/o-channel addresses,
editing of memory locations, backtraces, etc.).
executes an undefined instruction in displaying to the DEDA,
but I haven't figured out yet how that happens.
||"Finished" coding yaAGS. It doesn't
work, of course. I'll start figuring out why tomorrow.
||On the links page, updated the status of the integration of Virtual AGC with the Orbiter simulator again, after receiving some additional info from Markus Joachim.|
||Allan Klumpp has told me that
there is a descrepancy between the the software version
quoted on the Luminary page for
Apollo 15-17 vs. his personal recollections and
in-hand documentation. I've added notes to that
effect, along with disclaimers on the Colossus and Luminary pages to
indicate that I'm not certain how accurate the software
configuration information is.
||On the yaAGS 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.
||Minor corrections on
developer and language-manual pages. And a few
additions to the faq page.
||Finished up the API
documentation. Probably still needs a little work,
such as verifying the sample programs listed, but looks
|2005-05-18||Finally began filling in some
of the Virtual AGC Library API stuff on the developer's page
since, I was surprised to find, some people are actually
interested in it. Still needs a lot of work, but does
actually contain some useful information.
||The developer page
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.
||PR #30 (socket interface to
"unprogrammed" counter sequences completely inoperative) has
been fixed in yaAGC,
and a special mode (--debug-counter-mode) has been added to
yaDSKY so that
there's a way for debugging purposes of sending known
counter-commands to yaAGC
and observing the effect.
||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.
||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.
||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.
||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 yaAGC source code for
the Orbiter spacecraft simulator.
|| Added the AGS Performance
and Interface Specifications document to the AGS page. (Thanks to John
Pultorak and Davis Peticolas.) We've decided not to
provide one of the docs that was originally listed, so
||In yaAGC, managed to get rid of the annoying
effect (which appeared only in Linux) whereby stopping yaAGC before stopping yaDSKY resulted in an
operating-system timeout of a couple of minutes before the
port could be reused (and hence before the simulation could
||The AGS Flight Equations
document scan has been added to the AGS page.
|2005-01-27||The Mac OS X build
instructions have been simplified a little, and completely
tested on a pristine Mac OS X 10.2.8 system.
||On the links page, there are
now some scans of
tables relating to spacecraft interior and exterior
lighting, thanks to Paul Fjeld.
||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
download page. My only
problem, it turns out, was finding the right version of X11.
||The scan of the AGS FP6 Operating Manual has
been added, as usual thanks to John Pultorak and Davis
||Data entry for AGS Flight
Program 8 source code is complete, but no debugging has been
done on it yet.
||yaLEMAP, 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.
||Continued refinement of AGS
page text. The yaLEMAP
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.
||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, yaLEMAP,
but it's not much yet.
||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 binLEMAP 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
cross-assembler, which doesn't yet exist.
||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 "yaAGS et
al." 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.
||Changed from Pultorak link (see item below) to a complete page. 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.|
|2004-12-19||Added a link to John Pultorak's site
on the links page. (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
||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 Colossus page. 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.
||Fixed a website link on the Luminary page.
(Thanks to Christian Bucher for pointing out the error.)
||Added some additional hints
to the Mac OS X build instructions, thanks to Greg Dunn.
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 Luminary or Colossus for me to work with. :-)
||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.)
||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 Apollo LM System Handbook for Apollo 17
have been added also, Contributed by Fabrizio Bernardini.
||The G&C section of the Apollo CSM System Handbook
for CSM-112 through CSM-114 has been added to the links
page. (Contributed by Fabrizio Bernardini.)
||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.)
||yaUniverse: 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.
manual: Updated/added descriptions of various
||yaACA: The proof-of-concept now builds
(and hence works) in Win32. It still does not
communicate with yaAGC.
||yaACA: 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 yaAGC
yet, and have only gotten it to work in Linux.
||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.)
||Colossus249 source code: Source code through page 1037 (out of 1505) of the scan 1701.pdf is now available.|
||Colossus249 source code: Source code through page 1011 (out of 1505) of the scan 1701.pdf is now available.|
||Colossus249 source code: Source code through page 951 (out of 1505) of the scan 1701.pdf is now available.|
||Colossus249 source code: Source code through page 746 (out of 1505) of the scan 1701.pdf is now available.|
||Colossus249 source code: Source code through page 289 (out of 1505) of the scan 1701.pdf is now available.|
||Colossus249 source code: Source code through page 167 (out of 1505) of the scan 1701.pdf is now available.|
||Colossus249 source code: Source
code through page 128 (out of 1505) of the scan 1701.pdf is
||Colossus249 source code: Resumed data
entry. Source code through page 36 (out of 1505) of
the scan 1701.pdf is now available.
||yaAGC: Apparently I had forgotten to
--port=N command-line switch, so it wasn't possible to run
two instances of yaAGC
simultaneouly --- or at least not to run them and expect
both to connect to peripherals. (After daily snapshot
|| Found complementary errors
in bank 02 of Colossus249
binary. (Lest anybody be suspicious as to how
complementary errors could have been found in both Colossus249 and in Luminary131 --- 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
||Website changes: Lots
of screenshots added on the home page. Also, added
Frank O'Brien's amusing correction to the FAQ page.
||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 yaAGC
on one computer, either Linux or Win32, and yaDSKY on another
computer, either Linux or Win32). Minor cleanups of
the website have also been made.
||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 webb2burkey-rope,
in the Luminary131 directory, which converts the core-rope
files between Julian's format and mine.
||There was major code rework
done in yaAGC, 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.
Also, the LOG command was added to --debug mode.
||Added a new utility program
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 "CA L" and "CS L" don't presently work properly
when overflow is involved.
... 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 ....
||yaAGC --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.
||yaAGC --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
||In yaAGC --debug mode, fixed the sign of an
octal value displayed by GETOCT.
||The Win32 version compiles
again (at least on Windows 98), but the Win32 version of yaAGC is broken.
||yaAGC: Fixed a couple of problems with
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.
||yaAGC: Added primitive watchpoint
capability to the --debug mode.
|| Assembly-language manual
documentation tweaks (de-inhibiting of interrupts for GOJ or EDRUPT). yaAGC: Fixed TCAA, ZL, and ZQ
instructions. Closed up some conditions previously
resulting in the zero register (7) being overwritten with a
non-zero value. yaDSKY: Digit ND2 wasn't being
displayed --- instead, it was overwriting ND1.
||yaAGC: In --debug mode, now continues
to try to service client (yaDSKY)
connects or disconnects while waiting for keyboard input at
||yaAGC: 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.
||yaAGC: Fixed indexed instructions for
negative indices. Also, the instruction executing
had been taken from the BBRUPT register, whereas it should
have been taken from BRUPT.
||Instruction set in yaAGC now essentially
rewritten against v0.50. Still not fully working, but
seems more convincing than before.
||Finished drafting everything
I want to say in the assembly-language manual about how
machine code is processed. This is v0.50.
||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.
||Continued documenting the AGC
instruction set. So far I have CCS, DAS, EXTEND, INHINT,
RELINT, RESUME, RETURN, TC, TCF, XLQ, XXALQ, but DAS still needs a
few loose ends tied up.
||Continued updating counter
descriptions in the assembly-language manual.
||Added quite a lot of text to
the assembly-language manual, under the CPU
architecture 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 send/recv 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
||yaAGC: Now update the Z register to
c(Z)+1 prior to decoding the instruction.
||yaAGC: Made major fixes to the AD and
TS instructions, but there's still a lot more to do along
the same lines, I think.
||yaAGC: 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
||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.
||yaAGC: 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.
||yaAGC: 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.
||yaAGC: 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.
||The 'configure' script now
allows the command-line switches "--help" and "--prefix", so
that installation can be done to any directory.
||yaAGC: 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.
ability added to yaAGC
snapshot.) Fixed synchronization of BB, FB, and EB
registers in --debug editing. Also fixed faulty
display in --debug of addresses in superbanks.
||Various issues related to the
virtual i/o channels were fixed: yaAGC'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 yaAGC
read the virtual input port, it never actually wrote to the
virtual output port (except in --debug-dsky mode). As
a separate issue, both yaAGC'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 yaDSKY 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 yaAGC itself
||yaAGC's --debug mode now has a command
("getoct") for converting numeric values to/from the AGC's
|| Made various changes to make
the --debug mode of yaAGC
||'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).
and yaDSKY 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, yaAGC
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.
||Continued working on yaAGC. 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
||Continued working on yaAGC. Fixed some
bugs in AD, DCA, and CS.
||Fixed problem reports 3, 4,
and 5. Thanks to Christian Bucher for pointing
out the problems.
||Lot of links broken.
Thanks to Christian Bucher for pointing this out.
Hopefully I got them all.
NARA-Southwest finding-aids links.
||Added a bunch of CDROM-only
links for NARA-Southwest finding-aids I've created.
||Added scans of Skylab and
Apollo-Soyuz training "data cards", and the report The Apollo 11 Adventure,
to the links page. Various corrections to the web
pages as well.
||The Luminary 1C (Rev. 131)
GSOP document is now complete and online---about 2300 pages,
45M. Merry Christmas!
||The Colossus 1A (Rev. 249)
"guidance system operation plan" (GSOP) document is now
complete---and about 1840 pages, 43M in size.
||Changed the documents
mentioned in the item below to PDFs (rather than TIFFs), and
added section 3 and half of section 4 to the Colossus "operations
||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 AGC4 Basic Training Manual, the Preliminary MOD 3C Programmers Manual, and sections 1 and 2 of the Guidance System Operations Plan for Manned CM Earth Orbital and Lunar Missions Using Program Colossus 1 (Rev. 237) and Program Colossus 1A (Rev. 249).|
||Mr. Gary Neff has provided
some scans of a page in Luminary
131 and two pages in Colossus
249 which had previously provided obstacles to validating
the Luminary source
code and the Colossus
core-rope image. The small amount of
source code has been added to the file P20-P25.s.
||For yaAGC 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.
||yaAGC 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
||Lots and lots of improvements
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 yaAGC page.
||Resumed work on yaAGC. 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,
||The Colossus 249 binary is
now completely reconstructed, and presumably ready for
use! (I.e., whenever yaAGC
is actually ready.)
||Colossus249 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.
||Colossus249 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 may be possible to make
bank 36 error-free, which has previously been thought
impossible without additional scans (see bug report #1).
||Colossus249 binary: Bank 34 (octal) now proofed.|
||Colossus249 binary: Bank 32,33 (octal) now proofed.|
||Colossus249 binary: Bank 27,30,31 (octal) now proofed.|
||Colossus249 binary: Banks 23,24,25,26 (octal) now proofed.|
||Colossus249 binary: Bank 22 (octal) now proofed.|
||Colossus249 binary: Banks 20,21 (octal) now proofed.|
||Colossus249 binary: Banks 16,17 (octal) now proofed.|
||Colossus249 binary: Bank 15 (octal) now proofed.|
||Colossus249 binary: Bank 14 (octal) now proofed.|
||Added an Acknowledgements section to the home page. Colossus249 binary: Bank 13 (octal) now proofed.|
||Colossus249 binary: Bank 12 (octal) now proofed.|
||Colossus249 binary: Banks 10,11 (octal) now proofed.|
||Colossus249 binary: Bank 7 now
||Colossus249 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.
||Colossus249 binary: Banks 0,1 now
||Fixed a bunch of web links.
||Colossus249 binary: Bank 3 now
||Colossus249 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
||Colossus249 binary: Banks 7-32 (octal) are now in place, but not proofed.|
||Colossus249 binary: Banks 0-6 are now
in place, but only bank 2 has been proofed.
||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.
||yaDSKY and yaAGC
now actually work the same in Win32 as in Linux (and,
indeed, can be mixed-and-matched).
||yaDSKY and yaAGC
now build in Win32, and run. (However, the socket
communications don't work well enough for them to be fully
||yaDSKY 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 glade/gtk+
programs under Windows, with the idea of eventually having
Win32 versions of yaDSKY
and possibly Mac OS X versions at some point.
||Oct2Bin has been changed to make it a lot
clearer whether messages are errors or just information.
||Luminary131 binary (Luminary131.bin and/or
Luminary131.binsource) now completely proofed and
(presumably) ready for action! Of course, until yaAGC (or yaYUL) is ready, it's
not good for much.
||29 (of 36) memory banks of the Luminary131 binary now proofed.|
||26 (of 36) memory banks of the Luminary131 binary now proofed.|
|09/02/2003||21 (of 36) memory banks of
binary now proofed.
||Now have the complete Luminary131 binary, but
only the first 15 banks (out of a total of 36) are
proofed. The other banks are known to contain errors.
||Now have some (small) chunks
of Luminary131 and
binary. Download page completely rewritten, so that
now there are some sensible downloads.
||To the best of my knowledge,
yaDSKY 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 yaDSKY itself. The "--debug-dsky" mode
has been added to yaAGC
to allow testing of yaDSKY.
||The web pages are now
up-to-date with all of the info I've systematized from the
original Apollo docs.
|| 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
||Got the idea for this project, whilst watching the movie Apollo 13.|