Contents

Why Does it Say "ibiblio" All Over these Pages, and Yet the Site URL is "github" ... Maybe?

Our official Virtual AGC website is at URL https://www.ibiblio.org/apollo (or http:).

However, we find it convenient to manage the coding for the website in our GitHub repository, and a side effect of this that there is another version of the website at URL https://virtualagc.github.io/virtualagc/index.html. This GitHub version website is a kind of "staging area" for testing changes, and depending on circumstances at any given moment, may be either more up-to-date or less up-to-date than the main site.  In general, though, it looks and feels exactly the same as the main site.  One important difference is that the GitHub site does not have access to the vast AGC-related documentation library (~10GB at this writing) that's available on the main site, so clicking on most links to documentation won't work properly.

Is this site mirrored anywhere?

The Virtual AGC website is mirrored at http://apollo.josefsipek.net/.  Thanks, Jeff!

Mirroring, of course, entails downloading of our entire website.  Using a program like 'wget' isn't recommended, since as of right now, it's roughly an 11GB download and changes fairly frequently.  A program like 'rsync' is much better, since it only downloads files that have changed.  According to my notes, the following command is supposed to work, though it doesn't seem to be working for me:
rsync -av ibiblio.org::virtual-agc/ YourLocalDirectory

What other websites is this website associated with?

Other than the "staging" and mirror sites mentioned above, these other sites are closely related to this site:

Privacy concerns?

This website collects no data about you of any kind.  It does not send data about you anywhere.  It uses no cookies.  It saves no data in your local browser's storage area.  It uses no analytics.  It serves you no ads.  It loads no 3rd-party libraries.  It is almost entirely pure HTML, but does use a small amount of javascript to make sure that the banners at the tops of the pages appear correctly, and that you can hide information that's too old (if you choose to do so) on the change-log page.  In short, we couldn't care less about you, either as an individual or a demographic, unless you want to contact us directly.

In fact, our main site is entirely stand-alone, and can operate perfectly well if you were to download the entire website onto (say) a USB flash drive and disconnect the internet entirely.  (Not that we'd recommend downloading the entire thing, since at the moment it would be an 11GB download.  But if you are interested in doing things like that, read the advice in the mirroring section above.)

Except ... with that said, there is a Google search bar at the top of every page, for your convenience in finding documents on this site, which admittedly can sometimes be rather difficult otherwise.  Nor (obviously) does that search work without the internet.  And it does to a lot of the junk I just said I don't do.  I'm afraid you'll have to interpret that factoid for yourself, applying whatever degree of paranoia you are personally feeling at the moment.

I will tell you, though, that we derive no revenue or other considerations from Google; the search bar is simply a free feature that they provide, and that I think is a great convenience for us.

How can I help?

If you want to participate directly (in the sense of contributing effort), there are indeed some areas in which assistance would be helpful.

Is there a Wiki for this project?

If you have AGC/AGS information you'd like to contribute, you could do so by contacting me directly.  However a more straightforward approach may be to contribute your knowledge to the wiki.  Examples of things that are useful are theoretical discussions, historical information or anecdotes, tutorials on how to perform certain tasks with the AGC or AGS, etc.  You may be required to register ... but I'm not sure exactly how it works.  Yes, this is a hassle, but it's a one-time thing and it helps to keep the wiki reliable.

Is there a mailing list for this project?

There is!  If you'd like to subscribe, changes the preferences of your existing subscription, or unsubscribe, go to

lists.ibiblio.org/mailman/listinfo/apollo

Important note:  For whatever reason, the mailing list subscription form rejects new subscribers with a message like "invalid capcha".  This may or may not be resolved now.  If this happens to you, email me directly (at the address at the bottom of this page), and I will manually subscribe you to the list.

I expect this to be a very low-traffic mailing list, devoted to very technical questions, if my own inbox is any indication.  :-)  However, as with any mailing list, you're taking your chances.  It's a members-only mailing list, so hopefully you'll be spammed by it only if spammers spoof the email address of existing members.  Also, there are various options you can set for your subscription, such as concealing your email address from the group.  (I think I'd still be able to find out your email address, since I administer the list, but you'd just have to live with that.)

You might also want to look at Orbiter NASSP's Virtual AGC mailing list, where they seem to be making great progress on the practical details of actually using the AGC for running simulated missions.  Highly recommended if you're more interested in running the AGC rather than understanding its guts!  Unfortunately, I never seem to be able to find it myself from one time to the next, so I don't have a handy link to give you; you'll have to google it yourself.

Wow, where did you get all this material, and how can I find some too?

If you want to collect AGC documentation and software in a secret shrine where you can admire it without sharing the content with anybody else, please don't.  Sometimes you can find this stuff on eBay.  There are also auctioneers who buy and sell this stuff.  Obviously, we (Virtual AGC) can't afford to buy it there or anywhere else, but if you find yourself doing so please consider sending us a digital copy.  The value of your collectable won't be dimished and you'd be doing a public service.

Sadly, a lot of information that would be very helpful for this project does not seem to be publically available on the Internet.  For example, where is a dimensioned drawing of the DSKY?  What connector types were used for feeding external signals to the AGC, what was the pinout of the connectors, and what were the electrical characteristics of those signals?  Where are additional source-code versions of Luminary or Colossus ... or of Sundance  (alternate CM software)?  (I could go on like this all day.)  Alas! I don't know the answers to these and many other questions.  One can only hope that the materials still exist somewhere and may become available someday.  If you would like some hints about where this kind of information may be lurking, click here.

Fortunately, just enough information has been readily available to allow development of Virtual AGC.  All of the materials we've collected are available from our document library page.

I have some of the documentation you need, but what can I do with it?

A pretty complete description of the available options can be found on our "how to digitize" page, but I think that rather than frustrate yourself by reading it, just contact me directly at the email address given at the bottom of the page.  I can advise better once I find out the nature and extent of what you have, as well as your personal preferences and resources.

Is this project affiliated somehow with NASA, or Draper Labs, or TRW Aerospace, or IBM, or ... are any former Apollo workers involved?

No, not in terms of running it or providing any of the simulation software.  We try to reach out, from time to time, with little luck.  However, in latter years it has been gratifying to see contributions of archived AGC documentation and program listings by various of the original AGC developers.

And who the heck are you, anyway?

Well, I'm not involved in the space program in any way.  Professionally, I write embedded software for airborne devices.  I have a number of other open-source projects, which you can read about (along with a more-extended write-up about me, Me, ME!) at my main website.  But all kidding aside, there's nothing interesting about me or my projects except Virtual AGC.

And yes, somebody really did ask this.

Why waste so much time on a project that may be of interest to 3 geeks somewhere?

Placing men on the moon is one of the greatest accomplishments of the United States of America.  It is arguable, indeed, that it is the greatest accomplishment (of any kind) in the history of the human race.  If so, perhaps it makes sense to preserve the relics of the Apollo project.  (Besides, I'm one of the 3. )

I got the idea while watching the movie Apollo 13.  The instant in the movie where the AGC is powered up on Earth approach is the instant when the viewer suddenly feels that survival of the astronauts has changed from "highly unlikely" to "very probable".  It gives me a chill whenever I see it.  Anyhow, on watching this one day, it struck me that it was a shame nobody knew any longer how to operate the AGC—let alone write the programs for it.  (As it happens, that thought was a bit premature:  only 35 years had passed since the AGC software was written, thus many of the original software developers were still reasonably young.  Nevertheless, the principle is correct, since very few people could use or program the AGC.) 

Anyway, it then occurred to me that it would be cool to bring the AGC back to life, and to allow anyone so inclined to use it or program it ... assuming, of course, that sufficient publically information was available to do so.  As it quickly turned out, there was enough information publically available, though just barely enough.  The project turns out to be an interesting experiment in digital archaeology.

News flash:  I found a couple more geeks, bringing the total to 5.  Here's their website, where they're doing almost the same thing as me, inspired (no less) by From the Earth to the Moon.

Later news flash:  I've found still more geeks.  Let's just assume that the total is around 100 and do away with these further news flashes!

Tom Hanks, Wherever You Are, Call Me!

I jest, of course.  But I suspect that if Tom Hanks (a well-known space buff) had an assistant make a few judicious telephone calls to people hoarding the AGC-related information we need to advance this project, it could accomplish more in a few hours than years of knocking on doors by me has accomplished.

If you know someone like Tom (or know someone who knows someone like Tom) who might be sympathetic, pass the word along to them.

What's with the "ya" stuff all over the place?

Computer programmers are aware—though Apollo enthusiasts may not be—that "ya" is often added to computer program names to mean "yet another".  Thus, yaYUL is "yet another YUL", yaDSKY is "yet another DSKY", and so on. 

What's the deal with "verbs" and "nouns"?

The following amusing (if not necessarily helpful) comment may be found in the source code of the keyboard and display program (otherwise known as "pinball"):

THE FOLLOWING QUOTATION IS PROVIDED THROUGH THE COURTESY OF THE AUTHORS.

"IT WILL BE PROVED TO THY FACE THAT THOU HAST MEN ABOUT THEE THAT
USUALLY TALK OF A NOUN AND A VERB, AND SUCH ABOMINABLE WORDS AS NO
CHRISTIAN EAR CAN ENDURE TO HEAR."
                                           HENRY 6, ACT 2, SCENE 4

It turns out, though, that the authors' literary skills didn't quite match their programming skills, as this quote is really from Henry VI, Part 2, Act IV, Scene VII.  (Thanks to Frank O'Brien of the Apollo Flight Journal and Apollo Lunar Surface Journal for this correction.)  By the way, if you take it upon yourself to actually read the play to figure out the context, you may find yourself reading about "a Nowne and a Verbe" rather than "a noun and a verb".

Original AGC hardware developer Ramón Alonso provides a little more insight:  Apparently, nobody had yet arrived at any kind of software requirements for the AGC's user interface when the desire arose within the Instrumentation Laboratory to set up a demo guidance-computer unit with which to impress visitors to the lab.  Of course, this demo would have to do something, if it was going to be at all impressive, and to do something it would need some software. In short order, some of the coders threw together a demo program, inventing and using the verb/noun user-interface concept (in the whimsical fashion seen in much of this code), but without any idea that the verb/noun concept would somehow survive into the flight software.  As time passed, and more and more people became familiar with the demo, nobody got around to inventing an improvement for the user interface, so the coders simply built it into the flight software without any specific requirements to do so.

However, that does not mean that the verb/noun interface was universally beloved.  Ramón says that many objections were received from naysayers, such as "it's not scientific", "it's not dignified", or even "astronauts won't understand it".  Even though the coders of the demo hadn't seriously intended the verb/noun interface to be used in any permanent way, it became a kind of devilish game to counter these objections with (perhaps) sophistic arguments as to why the interface was really a good one.  In the end, the coders won.  I don't know whether they were elated or dismayed by this victory.

The astronauts, of course, could understand the interface, but they did not like it.  Most of them really wanted an interface much more like that they had used in aircraft:  i.e., lots of dials and switches.  Dave Scott is the the only astronaut I'm aware of who had kind words for it (or for the AGC in general), though we are told that Jim McDivitt wasn't necessary completely hostile to it.

Why Isn't More Information Provided About Why the Guidance System User Interface Was Like it Was?

A lot of thought about usability went into the design of the guidance system, much more so than the story above about verbs and nouns would indicate.  Questions like what kinds of controls needed to be provided, or even where those controls would be physically located, were extremely important  (Thanks to George Silver for pointing this out.)  Sadly, I don't know anything about these topics, and that's why I don't cover them here.

Tell Us More Amusing Stories

Well ... maybe just a couple more.
At least some of them were subtitled with the following Latin motto:
Quod non videt oculus, cor non dolet.
Does anyone among you remember this charming grace note, and who was responsible?  Being the only New Englander in that part of MSC, and thus familiar with the native institutions here, I strongly suspected that the presence of this item in the listings was an unsubtle indication that at least one member of the IL development team had graduated from someplace like Amherst College (my dad's alma mater) rather than MIT.

To answer your question [about other MSC members having kept copies of AGC listings as souvenirs], just about all of our inventory went over the side at the end of Apollo. I remember in particular a huge stack of listings in the hallway with a sign above saying "Free data, take one''.




A group of MIT engineers attended the Apollo 7 FSRR and made presentations, myself included. Bell Labs and TRW along with the various NASA Branches involved also made presentations. The presentations went very well and everything pointed to a GO for flight. After the presentations were completed various members of the head table (there were probably 50 people in the room,) in turn expressed their opinion based on the presentations and other information. When it got to the crew, backup CSM pilot Dave Scott spoke for the prime crew as they were at the Cape doing simulations. He said that in effect the prime crew had asked him to report that they ”had no confidence in the flight software”. You could have heard a pin drop and of course the MIT contingent was in shock. The meeting chairman, Chris Kraft, asked what they meant and asked if they were ready to fly. Dave replied immediately that yes they were ready to go. Kraft said, in so many words, that if they were ready to fly then he didn’t understand what they were saying. He then said if they weren’t ready he would replace them that minute. He then declared the software ready for flight.

That was an unbelievable moment and it made clear the command of Chris Kraft.

There is another story involving Steve that I recall from the Apollo 11 Flight Software Readiness Review (FSRR) The FSRR was a big deal; all the contractors involved in producing and testing the AGC software (Grumman , TRW, the Lab and others) had to make presentations and vouch that the software was ready for the mission. It took place in a big auditorium at MSC. I was sitting with Joe Saponaro and Gene Muller. George Cherry was introducing the Lab's presentation of the test results that demonstrated that the LEM software was capable of performing the mission under various conditions that might be encountered. When George came to the Lunar Orbit Rendezvous phase, he presented a single slide showing the test results for Rendezvous Navigation. There were a number of test cases reflecting different possible mission scenarios; the only ones I remember are one sigma and three sigma IMU errors. For each test case, George's slide showed the miss distance at closest approach, which was the figure of merit used to evaluate system performance. Now the amount of effort to get those results was substantial. I had worked closely with Gene and Pete Kachmar, with Joe supervising and helping out, for many weeks to produce all the data. And George had taken the heart of Gene's presentation (each mission phase, Descent, Ascent, Rendezvous, etc. was presented by the responsible engineer). So Gene was cringing while Joe and I were trying not to laugh.

When George finished talking about the slide there was a momentary silence. Then a voice was heard asking a question. It was Steve. "George," he said, I notice that the three sigma IMU error case is better than the one sigma IMU error case"; that is, the miss distance with three sigma IMU errors was smaller than the miss with one sigma errors. George didn't know how to respond; he wasn't all that familiar with the testing. He could have said something about offsetting errors, but he didn't. "Well," Steve continued, "do you think that's the way we should go?" George didn't answer and the room was silent — Steve had just suggested that it might be better to fly the mission with an inertial system with three sigma errors. What could anyone say?

 George was bright and enthusiastic, and made an indelible impression on everyone who worked with him.

While we're reminiscing I thought I'd relate the P00 story. It was beautiful clear Sunday afternoon, Dec. 29, 1968, and the Apollo 8 was on its way home. I had just deposited my family at Logan for their visit to NJ and I then went to the lab to be "on duty." Dan [Lickly], Margaret [Hamilton] and I were in the 2nd floor conference room reading and listening to the astronaut/Houston chatter when Jim Lovell said "Oh oh, I think I just did something wrong." The voice from Houston was calm when asking what he did. "I selected P00 on the keyboard. Did I do something?" "We'll get back to you." A microsecond later the phone rang from Houston wanting to know what the hell he did and what effect it had. We didn't know and said we'd get back as soon as we could. Who ever tested selecting POO coasting home after TEI [Trans-Earth Injection]? Nobody! We discussed the problem and what the effects might be and Dan and Margaret tore in to the listing to follow the thread of events. The crew had been taking star sightings and building their navigation base. The phone again ...."Well what have you come up with? We've got to know quickly. If the computer is out and we lose communications we've lost the crew. We need an answer now." "We're doing the best we can, we'll get back to you." The 8 inch listing was on the table and we pored over it. It was taking time. Another phone call .... more time. Finally, after about 90 minutes the detective work yielded the result. Jim had wiped out, from erasable [memory], all the navigation data that he had been collecting via the sextant. While the astronauts had multi-communication channels to Mission Control, the fact is that they would be in trouble with a loss of communications and no navigational information. We conveyed our conclusion to a very impatient Houston and then we heard the calm Houston voice say, "Jim, on that P00 we'll just up-link some data to you. Everything is OK." After that it was just a beautiful restful Sunday afternoon. No problems.

DO NOT USE ENEMA WITHOUT CONSULTING POOH PEOPLE

which is not only good advice in the AGC, but for life in general.  It probably helps to know that ENEMA is the software function that flushes waiting programs from the system during a software restart.

A number of stories revolve around the remarkable technical exploits, and equally remarkable quirkiness, of the late John Norton of TRW.  Though not an AGC coder himself, he had an important effect on the AGC coding process.  Here's what the late Jack Garman had to say about him in an interview, in reference to the Apollo 14 mishap with the LM's intermittently-activating abort switch:
A fellow named John Norton, he’d be a good one to get hold of if you ever can, TRW in those days. I don’t know where he is now. He was a genius. Like many geniuses, he had trouble communicating with management, okay, but in the computer game, he was a genius. TRW had many roles in those days, but part of it was continuous independent assessment of what was going on. John’s task was to look at all the onboard software code and do what is today called code inspections. It’s a normal part of testing. It wasn’t done in those days, except that John Norton did it.

The way he’d do it is, he’d take this awful assembly language and translate it back into his own version of a readable higher order language. The Norton Document, as we called it, that he put out for every version of every program, all typed by hand—no word processing in those days—was our Bible. We actually used it the same way somebody might use a Fortran listing or higher order language listing of a program to analyze their program.

As soon as this happened, we opened up our Norton Documents and started looking for flag bits, remember, hard-coded stuff. The first thing we determined was that the minute the engine lit, the minute it lit, it would be shut down and it would abort, because that’s the way the computer was programmed and that’s hard code. It would assume that the crew just—first it cycles and reads it environment every two seconds, including all the switches, and it would read the switch and say, “Oh, time to abort. I’ll do exactly what I’m told,” and separate the descent part of the vehicle and ascent and fire right back into the command module. No, we don’t want to do that.

But sometimes one had to have a bit of fun with John.  Here's a story that AGC developer Steve Copps tells:
There seems to be some interest in this so I’ll do my best to remember back through the years. It occurred in 1967 I believe.

I was responsible for the crew interface to the CSM guidance system and strived to put together a perfect GSOP IV [Guidance System Operations Plan, section 4] for Apollo 7. After a thorough review and sign-off at the lab I sent the document to NASA Houston as a deliverable. I remember being proud of the product and more or less thought of it as my baby... I was young. Imagine the shock when within 24 hours after they received it we got a multipage memo written by John Norton (with the usual disclaimers) and delivered through John Williams, Jack Garman's boss. I couldn’t believe it. I must have seen it as a challenge or something because I decided that if John Norton could find all those faults in a day then I could fix them in a day. So I went at it, punching the IBM cards myself and submitting run after run.  Around 5 in the morning I was finished and had incorporated the comments which were pretty much valid but for the most part were not substantive.

After proofing it as best I could I decided that it would be fun to tease John a bit and insert a little comment which I assumed would take him days to find, and would make him laugh if he ever did find it. In the middle of P52 I wrote in tiny letters the words “Norton needs glasses”.

I quickly received the approvals I needed (without telling of the little bomb I had inserted) and sent it off to Houston early with someone who was flying down. So it was in John William’s office that day. Within hours after receiving it Norton found the entry and hit the ceiling, raising hell all over the Center. The phones were ringing off the hooks; it seems everyone weighed in. I was told that Norton wanted the one who wrote it fired and he wanted MIT removed from the program. I, of course, was called to task and got to speak to a lot of people during the next few days.

I was reprimanded by both my own management and by NASA management but in all cases with a wink and smile.
AGC developer Peter Volante confirms that he saw the phrase mentioned above, "Norton needs glasses" in a Guidance Systems Operations Plan (GSOP) document.  He went on to say that a copy of that GSOP should be placed in the Smithsonian or some other museum, because the story demonstrates that a sense of humor is a valuable asset when working on a large program under intense pressure.

And speaking of Peter, here's my transcription of a memo he sent me, which Norton had apparently fired off to Jack Garman in 1971, in response to some later hiccup:
Subject:  "Norton is Working With Us"

I received a call this morning from a John van Ecckel, whom Monroe identified as somebody in "crew coordination".  He said that he had been talking to C. Thomas about the Users' Guide Material.

He said that he had talked to R. Larson of MIT, and Larson had informed him that "Norton has been working with us the past couple of weeks on updating the Users' Guide."

With the millions of dollars that you give to MIT, it seems to me that they should be able to produce documents on their own, rather than having to drag my name into their excuses to NASA as to why the document is lousy.  As Mr. Larson craftily planned, the documents I was permitted to see had no page numbers and had to be returned, so I have absolutely no proof of whether or not some particular butch in the crew version was or was not in the version I saw.  I do have proof of the Rev. 1 comments that MSC ignored in Rev. 2, but MIT still has their millions and I still have the post-midnight hours.  As I told you yesterday, I've been working for 6 years on Apollo, and NASA doesn't have much to show for it.  I hope you sleep well.

Personally, I laughed and laughed when I read this, so I naturally raised the question as to whether John had, perhaps, been making a little joke when he wrote this.  I was told "I wouldn't say John had a sense of humor.  That message was not a joke."  I don't know, though; does anyone really say "craftily" unless they're trying to be funny?

And speakings of the millions of dollars NASA was giving to MIT (as opposed to John Norton, I suppose), here is an amusing aside about Norton from MSC's Clark Neily:
Norton was under contract to my group at MSC in Flight Procedures Branch of the Flight Crew Support Division. He was quite a phenomenon. He would have a detailed report in our office the day after the release. His reports and the flow charts were used to assure that the part-task procedures simulators were functionally identical to the LGC software, even though [the simulators were] programmed in FORTRAN IV (extended). Also I understand [he] drove TRW HR crazy because he didn't cash his pay checks for months at a time. I once stood behind him at the Clear Lake Savings and Trust and he had a sheaf of them in his hand...

I've Heard About the Block I and Block II Systems ... Is There a Block III Also?

No, never was, and never will be ... and you can read all about it at this link.

Wouldn't it be better to incorporate Virtual AGC into a flight simulation or lunar landing simulation?

Yes.  I would strongly encourage it.  But it's outside of my personal limits, workload-wise.  If you want to work on that, I may be able to connect you to other people who are also interested in doing so. 

If you do want to work on this, I'd strongly advise that you use (or adapt and improve) the socket-based interconnect model I've provided and described on the developer page (so that yaAGC can be used as a stand-alone program), rather than trying to cut-and-paste yaAGC code into the flight-simulator.  Remember that even though Virtual AGC is free of cost, you are still bound by the licensing provisions of the General Public License (GPL); in other words, there are consequences for misuse of the code.  If, for example, you insert yaAGC code into a flight simulator, then that flight simulator must also be open-sourced under the GPL, or else I would have to grant you a special exception to the license.  (For example, I have granted such an exception for the Orbiter program.  See below.)  On the other hand, if you use yaAGC as a stand-alone program that merely communicates with the flight simulator, then there is no such problem.  Remember also that Virtual AGC is a work-in-progress, and if you insist on customizing yaAGC itself, you will have to carefully consider what you intend to do when I improve it without consulting you, and you have no way to merge the changes.

Work to integrate Virtual AGC into the Orbiter spacecraft simulator has proceeded marvelously.  There is a Sourceforge project, complete with working code and documentation such as installation instructions.

I'm told that integration into FlightGear is proceeding well also, though I have not heard anything about it for several years.

How come the stuff the simulation can do is so trivial?

It takes more than just a computer to fly an Apollo LM or CM.  At the very least, you need simulations of the spacecraft's IMU, AOT, and of the physical spacecraft (i.e., acceleration, torque, fuel usage, etc.).  Maybe we'll have those things, one of these days.   The LM-Simulator module has made a good start towards providing some of these things.

It doesn't work!  How do I make it work?

It's Too Slow!

At the moment, Virtual AGC consists of two parts:  the core programs (like yaAGC, yaDSKY, etc.) and the contributed LM-Simulator program.  I separate them because very different techniques and tools were used for creating them, so they don't contribute to slowing down you computer in the same way.  Furthermore, the contributions of the various parts are different on different platforms.  Here are some approximate timings I've made using the 20050716 development snapshot:

CPU
Speed
Operating System
CPU Utilization
Core Programs
LM-Simulator Total
Without
Rotation
With
Rotation
Intel P4
2.8 GHz
Windows XP Home
0-3%
65-70%
>95%
65-100%
Intel P4
2.53 GHz
Linux
0-3%
35%
40-45%
35-45%
G3
450 MHz
Mac OS X
50%
60%
90%?
110-140%

While the benchmarks above are very far out of date technology-wise by now, they are still somewhat instructive.  What you'll notice, undoubtedly, is that the simulation is going to need a relatively modern system to run all of the bits and pieces.  If you don't have a fast enough CPU, it doesn't observably affect the core programs, but has the symptom that LM-Simulator slows to a crawl, and responds increasingly slowly as time goes on, because the backlog of unprocessed data increases.

So what is to be done about this?  Well, I'm sure that over time we'll be able to improve the speed of these programs, but that's not of any immediate help to you.  One thing you can do immediately, assuming you have the resources, is to take advantage of Virtual AGC's client-server architecture.  You can do things like running LM-Simulator on one computer, and the core programs on another computer.   Splitting up the bits and pieces this way has the additional advantage (if each computer has its own monitor) of making it easier to see all of the various controls without having them obscure each other.

Of course, if you're so inclined, you could also roll up your sleeves, pitch in, and help us figure out how to speed up the simulation programs.

Troubleshooting Running the Simulation

Various things to to look out for are found in the quirks list, but here's a separate, supplemental list just to make it even more confusing:

How do I Uninstall this Thing?

On Linux or Windows, an uninstaller program is provided when the installer program is run.  Alternately—if installed on Mac OS X or from source code—simply remove the installation directories which were created.  Unless you've renamed them, these will be folders with names like "yaAGC/" (dev snapshot), "VirtualAGC/" (Linux binaries), "Virtual AGC\" (Windows binaries), or "VirtualAGC.app/" (Mac OS X binaries. On very old versions, in Linux or Mac OS X, the installation directory might have been "~/.yaAGC".

I'm drowning in Alphabet Soup!  What does it all mean?

ACA
Attitude Controller Assembler---the LM's hand-controller for pitch/roll/yaw adjustments.
AEA
Abort Electronics Assembly.
AGC
Apollo Guidance Computer
AGS
Abort Guidance System---a separate computer aboard the Lunar Module
AOT
Alignment Optical Telescope.  Telescope used to make star sightings.  By monitoring the orientation of the telescope, the AGC could compute the orientation of the spacecraft and use this information to calibrate the IMU (see below).
CM
The Command Module---i.e., the capsule.
CMC
Command Module Computer---i.e., the AGC in the CM.
CSM
The combined Command and Service Modules.
G&N
Guidance and Navigation
GNCS
CM G&N Control System---i.e, the AGC plus G&N measurement and control devices.
IMU
Inertial Measurement Unit.  This a stable platform (i.e., retains its orientation with respect to the fixed stars rather than to the spacecraft) containing accelerometers.  By monitoring the accelerometers and the orientation of the platform with respect to the spacecraft, the AGC can compute the orientation of the spacecraft, as well as its position, velocity, and acceleration.
LGC
Lunar Guidance Computer---i.e., the AGC in the LM.
LM
The Lunar Module---i.e., the lunar lander.
LVDA
Launch Vehicle Data Adapter
LVDC
Launch Vehicle Digital Computer
PGNCS
("Pings".)  The LM Primary G&N Control System---i.e, the AGC plus G&N measurement and control devices.

What about GitHub Repositories?

Around mid-2016, Chris Garry's Apollo 11 source-code repository got a lot of press, and I ended up getting some mail from journalists and what-not in regard to it.  I wasn't involved with it, but it was a clone of the Apollo 11 AGC source-code files here at Virtual AGC.  There was a brief flurry of activity at his repository, in which various typos in the text of the program comments for that code were corrected more quickly than here at Virtual AGC, though I doubt that that's the case any longer, since we ended up correcting literally thousands of such errors in our own Apollo 11 source code.  Regardless, the attendant publicity worked out well in our favor, and I suspect that it indirectly resulted in us getting various material offered to us which we've been quite happy to get, from folks who might not have heard of us otherwise.  At any rate, if that sounds interesting to you, check it out!

As it happens, Chris is neither the first nor the last to clone some or all of Virtual AGC (all of which is allowed and perfectly fine, of course!), and you'll find a number of them at GitHub.  Though perhaps Chris was unique in discarding everything that wasn't directly related to Apollo 11.  I'm not certain what most of the other clones are for. 

Until early in 2016, our own subversion-based source-code repository had resided at Google Code for about 10 years.  However, that earlier repository at Google Code no longer exists other than in archival form, since Google Code ceased its normal operations, and was migrated to GitHub.  Just for clarification, our (Virtual AGC's) official GitHub repository is

Accept no substitutes!

Are there other websites I should look at?

There are lots of online sites with worthy Apollo-related resources, though not necessarily specializing in the AGC.  Some terrific ones are listed below, in no particular order.
Here are sites of some folks who are doing pretty much the same kind of stuff as I am:
Here are links to some apparently pretty realistic full-feature LM simulations, but (of course) without true AGC simulations except insofar as efforts have been made to integrate Virtual AGC with them.  (I've not tried any of them myself, except for briefly messing with Orbiter.)
I just want to inform you that I finally released my stuff "Virtual Apollo". It's available at SourceForge together with it's "parent Orbiter add-on" called "Project Apollo - NASSP". You can find it here: http://sourceforge.net/projects/nassp/. The Virtual Apollo documentation is also available online: Look here http://nassp.sourceforge.net/ and click the "Virtual Apollo - The Virtual AGC integration" link.

With "I finally released my stuff" I don't mean [that the integration of Virtual AGC] is finished or that this is the final release.... :-). My stuff isn't finished; the IMU is working fine, but optics, RCS, the DAP and so on are still missing....  [Later] I plan to do a tighter integration of the Virtual AGC in Project Apollo.... But I suppose it will be months (or years) until all this is finished. Perhaps Mark Grant will help with that; more help, any comments or suggestions are welcome.  ;-)
 
Project Apollo - NASSP is not only an Apollo CSM add-on but it contains the complete Apollo missions including a fully functional LM, mission specific textures, the Skylab, the Saturn 1b missions... A really huge add-on! But "Virtual Apollo" covers only the CSM and there only lift-off and earth orbit insertation.

Update:  I've also received the following comments from Mark to indicate that the integration effort continues to make great progress:

I now have the AGC functioning up to orbit and outputting something resembling the correct numbers on the DSKY.... Actually, we are [working on an LM simulation also]. The Virtual Apollo release only had the Saturn V, but we've also got the Saturn 1b and LEM. The LEM AGC is up and running the Luminary code, but currently doesn't do much other than P00.
Emulators for other spacecraft-borne computers, such as the Gemini flight computer, the Apollo LM Abort Guidance System (AGS), the Apollo launch vehicle inertial guidance system (LVDC), or the shuttle computer (4pi AP101). 
... And some folks who are doing nothing relevant, but cool and possibly interesting to anybody interested in Virtual AGC.
Tools used in developing for Virtual AGC.  Modern Linux distributions typically provide all of the tools needed, if not in a default installation at least in the distribution's package system for painless download.  Win32, in contrast, provides none of them.  (Hey, folks, they're free.  It wouldn't cost Microsoft anything to provide them.)  Mac OS X is somewhere in between.

Tool
Linux
Win32
Mac OS X
UNIX & BSD
GNU gcc, make, etc.
Provided automatically by almost all Linux distributions.
 www.mingw.org Apple developer CD, or download from www.apple.com.
Often provided automatically.  Note that although GNU tools are assumed (www.gnu.org), native tools may work also.
wxWidgets cross-platform GUI toolkit for building VirtualAGC, yaDSKY2, yaDEDA2, and yaACA2.
Provided automatically by many Linux distributions.  Otherwise, download from www.wxwidgets.org Download from www.wxwidgets.org Provided in Mac OS X 10.5, but you may need to update.  The version provided in Mac OS X 10.4 is too early, so download from www.wxwidgets.org If not provided, download from www.wxwidgets.org
gtk+ cross-platform GUI toolkit for building yaDSKY and yaDEDA.

No longer needed for the yaDSKY2 and yaDEDA2 programs that have superceded yaDSKY and yaDEDA!
Provided automatically by many Linux distributions.  Otherwise, download from www.gtk.org www.gtk.org Install using fink Sometimes provided automatically.  Otherwise, download from www.gtk.org
Optional glade GUI builder for gtk+.

No longer needed for the yaDSKY2 and yaDEDA2 programs that have superceded yaDSKY and yaDEDA!
Provided automatically by many Linux distributions.  Otherwise, download from glade.gnome.org glade.gnome.org (Don't know.)
Sometimes provided automatically.  Otherwise, download from glade.gnome.org
Thread library.
(Not needed.)
POSIX Threads for Win32 (Not needed.)
(Not needed.)
Allegro cross-platform GUI toolkit for building yaACA.

No longer needed for the yaACA2 program that has superceded yaACA!
Provided automatically by some Linux distributions.  Otherwise, download from alleg.sourceforge.net alleg.sourceforge.net alleg.sourceforge.net May be provided automatically.  Otherwise, download from alleg.sourceforge.net
bzip2 for unpacking development snapshots.
(Not needed.) sources.redhat.com/bzip2/ (Not needed.) (Not needed.)
tar for unpacking development snapshots.
(Not needed.) www.gnu.org/software/tar/tar.html (Not needed.) (Not needed.)
Tcl/Tk scripting language for LM_Simulator.
www.tcl.tk/

What books and movies do you recommend?

Magazine

Books

Video

Is the moon landing a hoax?

Yes, though I've removed all references to the hoax from the Luminary and Colossus source code.  (Joke!) 

But seriously, I've found the blog of some thinker who has used the existence of our Virtual AGC project itself as evidence that the moon landing was faked.  His reasoning goes as follows:  a) Virtual AGC simulates some Apollo hardware; b) therefore, it is possible to simulate Apollo missions; and c) therefore Apollo missions were fake 40 years ago.  Well, you hardly need Virtual AGC as a step in that reasoning, since lots of people already know that the astronauts trained extensively in simulated spacecraft.  The simulators being used in the 1960s and 70s were far better and more accurate than our 21st-century software-only simulations.

Amusingly to me, the Virtual AGC project has also been used as a counter-argument to those who believe in the hoax theory, so I guess the pluses and minuses of our project, hoax-wise, tend to balance out.  I quite like a YouTube video in which a Microsoft Windows based compilation of our AGC assembler (yaYUL) is performed, and then yaYUL is used to assemble one of the Luminary or Colossus programs.  Too bad the demonstration stops short of actually running the simulated system.  The video is well worth watching, but I'm merely giving the link for it rather than embedding the video itself within in this page, because there is an audio track that might startle those around you if you happened to be reading this page while on a break at your workplace.  Anyway, a claim had been made that Luminary and Colossus were not real programs, or something of that sort, and the demo video is supposed to debunk that by showing the the programs not only exist as scanned program listings, but can also be assembled.  Naturally, this was not very conclusive as far as the believer whose argument being debunked was concerned.

A case in point is the the extraordinarily detailed argument given at this link, which (at least at this moment) includes the totality of our own page describing the AGC programming language(s) in a nice, scrolling box, which is flattering in a way.   Good thing I recently removed the copyright of our site and placed the entire content in the public domain, so as to keep usage like that on the legal up-and-up!  What I take to be the first paragraph of the argument reads
"I am a professional computer engineer, I have known the microprocessor from its start.  I have had the curiosity of having a look at the Apollo guidance computer which has been made public.  I have read the operator's manual documentation, and it's really the weirdest I have ever seen, so weird that it makes my hair raise on my head when I read it (and I have read many technical documentations). The program of the CM is very weird too; I strongly doubt it piloted anything; it could not even be compiled, that is transformed into machine code to be executed."
I admit that I haven't read most of the rest of the argument — the fact that it says in the very first paragraph that the AGC software can't be assembled (even though our project provides an assembler that assembles it) and that it couldn't possibly pilot anything (even though the folks over at NASSP do so regularly) causes my suspension of disbelief about the argument to be crumble — but it is very, very detailed, and uses some resources I've never seen before, so you may be interested in taking a look.  Most of the argument seems to be that the AGC is "weird", a fact which I'm happy to grant, but has no bearing on anything else.  The weirdness might cause the hair on my head to stand up too, if I had any left.  But an aardvark or a kangaroo is weird too.  So what?  They still exist.

Nor, as it happens, are assemblers for AGC code all that uncommon, and mine (yaYUL) is not the only one, nor even necessarily the best, by any means.  I found out recently that quite a few of my collaborators on this project have also written AGC assemblers, such as one called JaYUL, for their own personal edification.  One of them told me something like, Ron, don't you know that eventually everyone writes an AGC assembler?  I didn't, but it's good to know!  Of course, at this site we now also provide the original YUL assembler used by the Instrumentation Lab until it was superceded by a replacement assembler called GAP.  Admittedly, we have no way to actually run YUL without having a Honeywell 800/1800 computer or a simulation thereof, so perhaps it doesn't really work; I suppose that pro-hoaxers can take comfort in that ... for the moment.

How can the Virtual AGC project be contacted?

Email to Ron Burkey <info@sandroid.org>



This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2017-04-28.

Virtual AGC is hosted
              by ibiblio.org