As far as I know, not any longer.  The only mirror I knew of seems not to have been updated since 2010.

Mirroring, of course, entails downloading of our entire website onto your own server.  But realize that just mirroring the main website doesn't get you any of the material at our supplemental GitHub and Internet Archive sites mentioned earlier.  And even if you've separately made local copies of that material, none of the hyperlinks to GitHub or The Internet Archive in your local copy of our website will actually point to your local copies of the GitHub or Internet Archive material anyway. 

With that said, if you were to download our entire ibiblio site to (say) a thumb drive, you could still certainly get a lot of great offline use out of it, since other than the GitHub or Internet Archive links, it doesn't need an active server and is designed to be used entirely offline.  (In fact, you'd have access to almost anything you might need, except for our tens of thousands of electrical and mechanical engineering drawings.)  A tool such as 'wget' works well for this on Linux or Mac OS X.

Just for fun, here are some of the site statistics as of 2019-05-11:

• Our main (ibiblio.org) website:  27GB.
• Our GitHub repository:  276MB
  
• Our Internet Archive project:  144GB

Big!  Though to be fair, The Internet Archive creates a lot of extra files in alternate formats, so we probably really only uploaded about half of the amount quoted above.

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

If you have AGC/AGS information you'd like to contribute, you could do so by contacting me directly.  A wiki would be a more-straightforward approach, but in a practical sense there isn't one.  (Our only wiki is part of our GitHub repository, and frankly its not quite good enough to be used for our purposes.)

There is a mailing list, thanks for asking!  On the other hand, I'm told that mailing lists are old-fashioned, and that a newer approach would be something like the "Discussions" in our Virtual AGC GitHub repository.  At the moment I'm writing this, the Discussions are completely new, so there's admittedly no content there, and therefore if you're interested in older content you'd probably need to consult mailing list after all.  But new questions or topics would perhaps best be posted as a Discussion.

As far as the mailing list specifically is concerned, if you'd like to subscribe, changes the preferences of your existing subscription, or unsubscribe, go to

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 diminished and you'd be doing a public service.

If you would like some hints about where this kind of information lurks, click here.

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.

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.

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.

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 publicly information was available to do so.  As it quickly turned out, there was enough information publicly 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!

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.

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. 

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"):

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

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.

Well ... maybe just a couple more.

• The story of the 1201 and 1202 alarms on the descent by Armstrong and Aldrin to the lunar surface during Apollo 11 is well known.  (If you don't know it, the astronauts received repeated alarms from the AGC of type 1201 and 1202 -- 5 alarms in all, if I'm not mistaken.  On each alarm, the question was raised as to whether to continue or to abort.  Obviously, they continued.)  I'm informed that the representative from the MIT Instrumentation Lab who was present to be consulted by Mission Control was Russ Larson.  When consulted on the go/no-go question, Larson simply gave a "thumbs up" signal.  When asked years later why he had done this, he said simply that he was too scared to speak.  (Thanks to Allan Klumpp for this story.)
• And continuing on the topic of the 1201/1202 alarms in Apollo 11:  These alarms were caused by the fact that during the landing, both the landing radar and the rendezvous radar were turned on.  Only the landing radar actually needed to be active, but it was felt by some that having the rendezvous radar turned on would be useful in case of a sudden abort.  What wasn't known was that this extra load on the AGC CPU would cause it to run out of processing cycles.  The software would work all right at first, but eventually the loss of about 15% of the CPU cycles due to processing the excess radar data would cause some tasks to be spawned before earlier instances of those tasks had completed running.  Eventually, because of the duplication of tasks, the software would be unable to allocate the memory needed to spawn new tasks, and would need to restart.  Fortunately, the cunning design of the software allowed the software to basically continue executing at the same point where it had been before restarting, and so it could continue operating normally until it ran out of memory again.  Eldon Hall likes to point out that this is a success of the AGC rather than a failure (as some other people like to say).  At any rate, Allan Klumpp coded a workaround for this problem in time for the Apollo 13 mission, but the powers-that-be declined to use the new software.  Klumpp was upset enough about this to contact the mission commander, Jim Lovell, and describe why the new software (Luminary 131) would be so much better than the old.  The next morning, Dick Battin dropped by Klumpp's office and announced, "Allan Klumpp, your political savoire-faire has descended to a new low!"  That was his way of saying that Luminary 131 would be used on Apollo 13 after all, because Jim Lovell wanted it.
• The original source code for the AGC assembler program called "YUL" is available here.  Examine (say) pages 2 and 3 carefully.  I needn't comment further.
  
• Not an AGC story, but I like it:   I'm told that one of the perks of writing software at MSC (Manned Spacecraft Center, now Johnson Space Center) in the Apollo era was taking the coding sheets to the 'swamp' for the keypunch operators to build the card decks to be taken to the computer center.  The 'swamp' was a tiered auditorium with many young women at keypunch machines on the tiers.  Of course, the young engineers would enter the room at the front at what was the focus of the tiers, feeling a little like a bull at the rodeo auction.  Apparently, this was a good way to meet bored young women in need of stimulation.  This is a case, obviously, where progress has been in completely the wrong direction.  (Thanks to Paul Schlein for this story.)
• When the disks containing the Apollo 11 assembly listings arrived (May 2009) arrived at my office, the shipping clerk who handed the box to me asked if it contained a software update.  I informed him that it did.  That it was a very old software update ... in fact, perhaps the oldest software update in the history of the world.  And you know what?  I think it may actually be true.
• This one is not quite so amusing ... to me!  Perhaps bittersweet is the proper word.  As you have noticed from reading our Luminary or Colossus pages, or from various other comments, I (we) are rather fanatical about finding all of the versions of the AGC software we can, so as to fill in all of the blanks and be able to tell you the complete story of AGC software development from end to end.  Mostly this involves trying to find AGC developers and Museums/Archives that have such software listings in their possession, and then shamelessly begging.  However during the Apollo era, MIT Instrumentation Lab employees weren't the only people who routinely had these program listings.  Another group that had them was the Flight Procedures Branch of the flight Crew Support Division at the Manned Spacecraft Center (MSC) in Houston.  One member of that group, Clark Neily, had the following to say in response to my questioning on the matter:

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

• Regarding the "free data, take one" AGC story above, an LVDC developer told me a similar story upon hearing my complaints about a lack of LVDC documentation and software:

IBM-FSD [IBM Federal Systems Division, which developed the LVDC] happened to build a HUGE fancy building in 1987 (approximately).   In the early 1990’s, NASA had one of their periodic funding cutbacks and reorganizations.  Independently, IBM was downsizing and sold FSD to a corporation that began massive layouts.  Because of the double-whammy, the “new” building was effectively vacated.  I drove past it almost every day and observed massive amounts of documentation being discarded.  A temporary ramp was built from the upper floors to ground-level.  Documents were then shoveled from open window-areas to a lower-level dumpster.  That ramp stayed in place for several months.
 
That is likely one of the reasons why material is difficult to find.

Yikes!  (Or if you prefer, Yipes!)

• AGC developer Peter Volante has passed along some pictures of a cardboard-cutout toy that Gulf Oil gave out back in 1969.  It forms a model of a LM, which Peter (good for him!) still calls a LEM.  Surprisingly, at least in 2017, you can still get these through eBay, at a not-too-outrageous price.  I ordered mine right away!  (Unfortunately, now that it has arrived, pristine and unspoiled by human hands in its plastic wrapper, I'm uncertain whether I should actually build it or not.  Why does nothing ever turn out like we plan?)
  

• AGC developer Steve Copps tells this story about a Flight Software Readiness Review (FSRR):

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.

• AGC developer Peter Volante contributes this story about a different Flight Software Readiness Review (FSRR), slightly edited.  The story also happens to be about Steve Copps (see above), though Steve disavows any memory of the incident:

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.

• AGC developer Fred Martin contributes this story, though it perhaps needs a little explanation.  The software in the AGC was partitioned up into a series of "major modes" that were numbered with 2-digit numbers, such as P00, P01, P02, etc. In particular, P00 is the "fresh start" program, the entry point, and isn't something you would normally use whilst in the midst of normal operations.

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.

• And speaking of P00, a dirty little secret that you may be able to deduce from the story above if you are an extremely keen observer is that P00 (pee zero zero) was generally referred to in the AGC source code as POO (pee oh oh) or sometimes POOH (as in Winnie the Pooh).  Now, it's not documented whether POOH is actually an allusion to Winnie the Pooh, or perhaps to something else, but one of my favorite program comments in the AGC source code (appearing in many different versions of the code in one form or another) is the following:

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.

Tracking down these "Norton Documents" is a bit tricky.  There's a notion floating around that the "Programmed Guidance Equations" documents (like this one for LUMINARY 1B), are the Norton Documents, even though textually they purport to have been written entirely by MSC's Flight Software Branch, and barely mention TRW at all (let alone John Norton).  However, they do correspond vaguely to Garman's description of them.  The only hard support I'm aware of for this theory is the writing on the spine of this document in Don Eyles's collection:


Is it a Norton Document?  You decide.  We don't yet have a scan of it, unfortunately, for reasons which escape me.

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

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.

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:

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

A non-AGC, non-Apollo, non-NASA site you might enjoy (hint: it's about Vostok and Soyuz) is the Vostok Supersite. 

Here are some folks who have done wacky stuff with the AGC (including, of course, our AGC simulation), generating lots and lots of media coverage in the process:

• An anonymous programmer has modified the AGC Comanche 55 software — i.e., the Command Module's AGC software for Apollo — to solve the "Dodge the Lasers" problem for Google's Foo.Bar Coding Challenge ... which is not something I had previously heard of, apparently because the Foo.Bar Coding Challenge is secret and by invitation only.  But here's a write-up of it I found online.  At any rate, our anonymous benefactor has provided his/her modified Comanche code in a GitHub repository, from which you can compile it and run it; the repository includes instructions, as well as a bit of a write-up of the Dodge the Lasers problem itself.  Plus, there's an instructional video.
• Ken Shirriff, a member of the AGC restoration team, has written some bitcoin-mining code for the AGC, and provided his code for it as well (though you have to dig a bit to find his GitHub link to it).
• David Given has created an "Ada-inspired language for very small systems (6502, Z80, etc.) called Cowgol.  As a lark, he has chosen to port this language to the AGC, as well as writing a lunar lander game (Cowlark) for it.  In other words, you build the Cowlark game using a Cowgol "cross-compiler" on your PC, producing an AGC rope-image of the game software.  When you run this rope in our AGC simulation — or on a physical AGC if you happen to have one laying around — you have a lunar lander game that runs on the LM's own computer!
  

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:

Realistic full-feature LM and/or CM simulations:

Tools used in developing for Virtual AGC.  This list isn't really up-to-date, but I suppose it might be of value to somebody.  Maybe!  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.

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.

Email to Ron Burkey <info@sandroid.org>.