Document library
Change log
Bug and issues
Developer info
Virtual AGC — AGS — LVDC — Gemini

Software / Website / News

Language Manual
Physical Implementations

Please enable javascript in your browser to see a site-search form here.

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 from Gene.
  • Due to feedback from Gene Mertz, a number of changes were made to the reminiscences and homage sections of the Gemini page.
  • Some source code for the Gemini 7/6 catch-up and rendezvous simulation programs has now been extracted from the "wonderful report" mentioned in the last entry.  It is only in the Subversion repository at the moment, and isn't yet complete or proofed/debugged, and so cannot yet be compiled or executed.
  • Eugene Mertz, one of the original Gemini on-board computer software developers has contributed a wonderful "report" that is really the complete FORTRAN source code used to validate algorithms and to simulate flight computer behavior for the catch-up and rendezvous Gemini flight phases.  Thus while we have no actual Gemini flight software at the present time, this is the next closest thing!  Many thanks to Gene and to his son Dave for careful scanning of the document.  Although I have not yet had time to do so, I expect to convert this FORTRAN code into a compilable/runnable form in the near future.
  • Gene has also supplied various Gemini software reminiscences and factoids, of which I have provided an edited version on the Gemini page.
  • Zach Greene has sent along a nice, partial list of the current locations of the command modules, which I've added to the Colossus page.
  • Will Ault has complained :-) that I nowhere describe my own professional background.  Ah, silly boy!  I've added an appropriate link on the FAQ.
  • On the Gemini page, replaced the Apollo-patch logo with a Gemini-patch logo instead.
  • On the reading list of the FAQ page, added Frank O'Brien's new book, The Apollo Guidance Computer: Architecture and Operation.  Go buy it right now, if you know what's good for you.
Several other people have sent in material that has been sitting in the queue for far too long.  Hopefully, I'll soon update the website with that material as well.  My apologies for the delays!
These are the release notes for snapshot 20102020.

  • The Artemis 72 (Apollo 15-17 Command Module) program listing has now been converted completely to source-code files, and has been debugged so that the assembled binary agrees with the octal listing from the hardcopy.  The existing Artemis 72 binary that we have been providing since snapshot 20060110 was found to be in error, and was corrected in one place!  The conversion to source was done by Hartmuth Gutsche, Onno Hommes, Jim Lawton, and Sergio Navarro, but Jim took it upon himself to perform the complete debugging of the source after it was created and I can attest that this is a large job.  Kudos to all!
  • Jim Lawton also seems to have single-handedly converted all of the Solarium 55 (Apollo 4 Command Module) program listing to source-code files and octal.  (Thanks, Jim!)  We presently have no way to assemble the Block 1 source code in yaYUL, so we don't yet have any way to verify the conversion; nor can we run the Block 1 binary in yaAGC yet.  But first things first.
  • In a pathetic attempt to say "me too" in a soft, whimpering voice, I've begun creating a new assembler (yaASM) for Gemini OBC and Apollo LVDC source (if we had any).  But it does nothing useful yet, so it's sheer bravado on my part to even mention it.
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.
  • Paul Fjeld has managed to come up with the pad loads for the Apollo 11 LM, and those are now in the document library.  Thanks, Paul!
  • Christian Bucher has let me know that the duty cycle for flashing indicators and digits on the DSKY is 3:1 (high:low) rather than the 1:1 that I've been using.  I've corrected the current yaDSKY2 program to fix this, but haven't bothered with the obsolete yaDSKY program.  Thanks, Christian!
  • John Pultorak has sent me a game pack for the AGC.  :)  The pack includes a tic-tac-toe game (1 or 2 players) and a Simon game.  I've included the games in the "Contributed" source tree, but there's presently no way to actually use them.  There are two problems with trying to use it, and if anybody wants to fix them I'd be grateful:
    1. The code is written in the syntax of John's assembler rather than yaYUL.  There are several mods needed, the principal one being that John's assembler doesn't have the yaYUL limitation of 8-character upper-case labels.
    2. Rather than directly accessing the DSKY via i/o channels, the code assumes the presence of some Colossus code (including the executive) to manage this activity.  Figuring out just what portions of Colossus to prune away to get room for the games is quite tricky.  It was done this way because John envisaged the game pack as an add-on to Colossus ... a kind of in-flight entertainment system.  :)  However, for our purposes you could just as easily eliminate all of the Colossus code and directly access the DSKY.
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 Apollo 6.
  • Finished fleshing out the Gemini page.  I think it's pretty usable now, though I'm sure there's plenty to be done to make it better.  Any mistakes on it now are actual mistakes as opposed to mere work-in-progress mistakes.
  • Added some documents to the Document Library, such as mission reports, press kits, and some training materials.
  • Added some tweaks to the AGS page, based on a newly-added AGS Design Survey document.
  • Added some much better images (drawings, actually) of the Block I DSKYs, in which all of the labeling on indicator lamps and what-not are actually readable.
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 the website.
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 become useful.
  • Page images of the Colossus rev. 237 (Apollo 8) program listing are now available.  The program listing was provided by Fred Martin, and photographed by yours truly.  We're getting quite a backlog now, so I've no idea when this will become available as source code or will be usable in the simulator.
  • Various documents relevant to the LVDC (or more accurately, to the Saturn 1B/V guidance system) have been added to the Document Library.  Many thanks to Barry Silverman for directing me to these, and to other documents that I haven't had a chance yet to add.
  • Added the remainder of the SGA memos, again contributed by Fred Martin and scanned by Onno.
  • Did more reorganization of the Document Library, and added a bunch of scrounged docs from various sources on the web (flight plans, crew debriefings, chunks of GSOPs, etc.), including the first LVDC docs we've had here.  Of course, added appropriate cross-links to the new docs on the Luminary and Colossus pages.
  • Added a number of additional SGA memos, again contributed by Fred Martin and scanned by Onno.
  • And this time I really restructured the "links" page so that it is now a "Document Library" page instead.  Everything that wasn't a document was moved instead the FAQ page.  I have realized somewhat belatedly that it hasn't been about "links" for a long time now, and by pretending that it was I was just keeping people from easily finding the documents they needed.  Well, it should be a lot easier now.  Also, there are planned improvements (beyond just the continued accumulation) which should make it yet a better tool in the future.  But we'll have to think about that another day.  I suppose I should note just out of sheer compulsiveness that I haven't had time to do all of the processing I'd like to do on the documents now being uploaded, such as making the text searchable and putting in document metadata, but all that stuff will hopefully be added later.
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.
  • Various adjustments to account for problems people have been having using command-line debugging of AGC/AEA code.  (Thanks to John Pultorak for reporting problems.)  Command-line debugging made a lot less frustrating, but not perfect by any means.  Most of the problems had to do with an optional library called libreadline, which provides may nice features related to command-line editing and command histories, but (to put it nicely) was causing us terrible problems.
    • Inability to find source files in some cases:  Changed pathname generation for source-code files in symbol tables to account for the possibility of the current runtime directory being used also as the source-file directory.
    • Garbage on command line and/or (in Vista) yaAGC/yaAGS crashing:  Made some fixes in the usage of libreadline in yaAGC and yaAGS, and added various WIN32 checks for spurious returns from the libreadline functions.  However, none of it helps the problem I was trying to fix.  Therefore, I have disabled the libreadline support in production Win32 builds, and that seems to take care of it.  (I made no effort to disable libreadline in native Win32 builds. )
    • But then ... the libreadline-associated problems I see on Linux (inability to use the backspace key, right-arrow backspaces right over the prompt in yaAGC, missing prompt in yaAGS) have finally exasperated me too much.  I've disabled libreadline support on all platforms until these unprofessional irritations can be resolved.  On some platforms this causes loss of the ability to use the up/down arrows to navigate through the command history, but I can live with that.
    • Found and corrected an arbitrarily-short command line length in the WinAGC utility I created to run and monitor the simulation in Win32.  The upshot of this is that when running a very complex set of simulation options, such as command-line debugging, the commands to start the simulation might be truncated and fail, and so the simulation would abort at startup.  Hopefully this won't happen now.
  • The main GUI (VirtualAGC), when allowing the user to choose a custom AGC/AEA source or binary file to assemble and/or simulate, now starts from the user's home directory (or whatever the equivalent is on an operating-system by operating-system basis) when the custom name is blank.  It also doesn't allow directory-changes to bleed through between the different types of file-dialogs as it has been doing on some platforms.
  • Custom AGC/AEA code in the main GUI (VirtualAGC):  You were previously able to assemble source code and run from here, but you couldn't do symbolic debugging or browse the source-code listing.  In other words, the main GUI is now almost a one-stop shop for assembly and command-line debugging.  You still have to provide your own editor or, if you want GUI-based debugging in Code::Blocks (for instance), you still need to do some manual stuff outside the GUI.
  • Added Alberto Galdo's mods (thanks, Alberto!) for building yaAGC for an iPhone.  Now, yaAGC without a DSKY obviously doesn't do very much, though in theory you could still run and debug AGC code from a command line (if the iPhone has such a thing).  Since I don't have an iPhone and haven't bothered as of yet to download an iPhone development kit it's an open question if I've properly implemented Alberto's changes, but at least it's a start.  There are some instructions on the download page for building it.
  • Added some proofing for Luminary 99 done by Steve Case.  (Thanks, Steve!)
  • The volunteer team (who will all be acknowledged later when the Artemis072 source code is completely available) have added various Artemis072 source files, as well as making some corrections to existing Luminary099 and Comanche055 source files.
  • This dev snapshot (identical to svn 285) was checked by:
    • Installation and checkout of production builds on: Ubuntu 8.04 64-bit Linux, Windows Vista, and Mac OS X 10.5.7 Intel.
    • Native builds and checkout on: Mac OS X 10.5.7 Intel, Windows XP, FreeBSD 7.2 (PCBSD 7.1).  Note that the pathname problems previously reported for FreeBSD have not been fixed yet, so that problem persists.
Added scans of the Apollo 8 Flight Plan (sections 1-2 and sections 3-5), contributed by Fred Martin.
  • Corrected a typo on the assembly-language manual page, in which I left out the word "not" in saying that interrupt service routines do [not] save registers.  Thanks to Benjamin Stover for pointing out this bone-headed error.
  • Fred Martin, one of the original AGC developers has sent over a bunch of documents, of which I've had time to scan the following so far:
    • The Apollo 8 Technical Debriefing (first half and second half).
    • Section 5 ("Guidance Equations") of the Guidance System Operation Plan (GSOP) for Colossus 2 (Comanche 44, 45).  (Sections 5.1, 5.2, 5.3, 5.4, 5.5, and 5.6-5.9.) Though as usual I don't have enough configuration data to be sure, I am willing to provide a very strong guess that this is for Apollo 10, and I'm going to treat it as such.
    • A readable copy of the Colossus 249 assembly listing.  Of course, we've had a Colossus 249 assembly listing all along, but the legibility of this new copy is far superior.
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!
  • yaYUL
    • Corrected some syntax colorization in AGC code, where the 2nd interpretive instruction on a line could be mistaken for a symbol (if there was one of the same name, which happens pretty frequently).
    • Made a lot of provisions for Block 1 code, though nothing that's working yet.
    • Added a utility called SplitInterp for helping to reverse-engineer interpretive codes.
  • Comanche055:  Added some annotations (thanks to Marcus Joachim) related to lunar and solar ephemerides.
  • Artemis072 and Solarium055:  Various changes related to beginning conversion of page images to source files.
  • yaLEMAP was previously converting AEA source code comments to all upper-case.  It has been fixed so that case is now preserved in comments.  Thanks to Marcin Skoczylas for pointing out that this was causing a problem when following the URLs provided in the comments in assembly listings.
  • The story (provided by Don Eyles via Onno Hommes) about the naming of the BURN BABY BURN Luminary routine has been added to the annotations of the Luminary 099 source code.
  • VirtualAGC has been fixed so that Colossus 249 is identified with Apollo 9 rather than Apollo 8.  The good news here is that I am now expecting Colossus 237 (for Apollo 8) to actually be available soon, so we aren't really losing Apollo 8.
  • The naming of all AGC source files has been changed from *.s to *.agc; that of all AEA source files has been changed from *.s to *.aea; that of all HTML files created from source has been changed from *.html to *.agc.html or *.aea.html.  This has been done to play nicely with the AGA/AEA syntax highlighting which Google has been nice enough to add.  I hope that I have tracked down all associated links on this website and fixed them, but I may have missed a few.  Please let me know if you discover any wrong ones.
Note that the changes for yaLEMAP and VirtualAGC are available in subversion only at the moment, as I haven't released a new source tarball or binary installers.  However, I am updating the assembly code HTML listings on the website.
  • I believe that I have been mis-identifying Colossus 249 all these years as being for Apollo 8, but that it was really for Apollo 9.  This correction has been made on the Colossus page, but hasn't made it's way into any software yet.  Thanks to Onno Hommes and Fred Martin.
  • The home page has been modified to provide the solution to the Apollo 14 "final exam" problem.  Thanks to Onno Hommes, Don Eyles, and Paul Fjeld.
Stephan Hotto has sent along a bug-fix the LM-Simulator program.  The bug was found by Riley Rainey.  Thanks to both!
  • Building HTML from yaYUL/yaLEMAP now allows addition of annotations, with styling.
  • The volunteer page now has a new section, describing addition of modern annotations to the AGC/AGS source code.
  • I am finally able to provide some positive advice on using Virtual AGC on Windows Vista or Windows 7.  Thanks to Brendan O'Rourke for reporting the Vista problems that triggered the extreme step of my actually running a copy of Vista ... though I don't know that "thanks" is really what I want to say here.  :-)
  • Updated the FAQ page with some delightful sarcasm.  (Well, delightful to me anyway.)
  • Integrated the fancy new HTML assembly listings with VirtualAGC.  (In other words, they fancy new assembly listings appear when browing source from VirtualAGC.)  Incorporated them in the binary installers as well.
  • Added Onno's syntax-highlighting files to the binary installers, so that it is no longer necessary to download them separately if colorizing Vim, Code::Blocks, Kate, etc.
(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.
  • On the DSKY page, made some corrections as to which DSKY configurations were used with which missions, and added a little supporting evidence for my assertions.
  • On the Luminary page, added some supporting evidence for my Apollo 9 versioning assertions, thanks to James Kernan.
  • My addition of the "presentation" feature to the yaDSKY2 program apparently broke the Windows version of the program, in that if the optional configuration file the feature uses is absent, nasty pop-up warnings appear.  I've fixed this in the current development snapshot and Linux/Windows/Mac installers.  Thanks to Brendan O'Rourke for pointing this out!
  • James Kernan (thanks, Jim!), one of the original AGC developers, has sent us an answer about some of the uncertainties in the versioning of the Apollo 11 LM software.  I've added his comments to the Luminary page.
  • Alessandro Cinquemani (thanks, Alessandro!) has sent some new photos updating his progress on rebuilding John Pultorak's Block 1 replica, and I've updated the Physical Implementation page with those.
  • Unfortunately, info on the Block 1 DSKYs hasn't previously been available easily on this website, so I've begun the process of collecting it and adding Block 1 info to the yaDSKY page.  Of course, yaDSKY(2) does not as yet support Block 1, nor does yaAGC nor yaYUL, so the information is presently for interest only.
  • Apparently, my fix for the non-portability of the symbol tables (when debugging AGC code) was faulty in that it broke some aspects of symbolic debugging, as well as use with CODE::BLOCKS.  Onno Hommes has fixed the regressions I created.  Thanks, Onno!
  • At the request of Fabrizio Bernardini, I've added a feature to the yaDSKY2 program that may be of use in making presentations using Virtual AGC.
The Apollo 11 LM AGC code is now fully available in source and binary form, is provided by the development snapshot and installer programs, and can be run in the simulation using the VirtualAGC GUI.
It has been only partially proofed—less so than Comanche 055—and so I won't feel great confidence until another proofing step or two has been done.  Nevertheless, there's no reason (other than sad past experience) to think that it isn't okay as-is, as all of the memory-bank checksums are okay.
  • Fixed a little bug in yaYUL:  In the bugger-word table printed at the end of an assembly listing, the addresses of the bugger words were being printed as things like 33,01777 rather than 33,3777.
  • Fixed a page image (#1294) for Luminary 099 that had a few lines truncated at the bottom.
  • Luminary 099 is now complete in svn and assembles without errors, but I've not debugged it yet.  Undoubtedly it's still full of errors, so I haven't updated the development snapshot or installers to include it yet.
  • A wrong command-line switch was being passed in a Makefile, which would cause the native Win32 build to fail.  Thanks to Onno Hommes for noticing this.  I would have sworn I had tested this after the last relevant change, but apparently did not.  I promise you that with this snapshot I tried native builds in Linux, Win32 XP, Mac OS X 10.5, FreeBSD 7.2, and cross-platform builds as well.
  • There are also incremental changes for things like Luminary 99 and syntax highlighting.

I doubt that would justify a new download at this point, unless you're trying to do native Win32 builds and they're failing.
The Apollo 11 CM AGC code is now fully available in source and binary form, is provided by the development snapshot and installer programs, and can be run in the simulation using the VirtualAGC GUI.
  • Almost all of the Comanche 055 source code and a small amount of the Luminary 099 source code is available in the subversion repository, though I didn't feel it was worthwhile rebuilding the development-snapshot tarball until we're closer to having something that runs in the simulation.
  • The giant PDFs of Colossus 249 and Luminary 131 page images have been deleted, in favor of reduced-quality files of individual pages.  When I say "reduced quality", I'm making a statement that is technically true, but I doubt anyone would see the difference unless they did a side-by-side comparison and zoomed in by about 3:1 or 4:1.  The orginal giant PDFs  (without the improvements I made in them) are still available elsewhere online if you want them.  This change has been made to be more consistent with Comanche 055 and Luminary 099, to make it easier for anyone who might want to volunteer to proof the program comments, and simply to reduce the disk space taken up.  Not that ibiblio.org has complained or anything, but there's no value added in wasting the space!
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.
Page images for the Apollo 11 LM and CM AGC code are now in hand, but the processing necessary for use in the AGC simulator has not yet been performed.  If you would like to assist in conversion effort, please visit the volunteer page.

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.
  • Now able to do a native build on OpenSolaris.  However, anyone saying it was working on that platform would have to have a more charitable nature than I.
  • Added the "volunteer" web-page and linked it in with the other pages.
The FreeBSD native build is now working again, to the extent that I'm able to check it.  The build instructions for it have changed a little.
  • There is now a subversion repository, thanks to Onno Hommes.  Developer snapshot tarballs and binary installation packages will continue to be produced, but the repository may contain more-recent data than in the snapshots.  At some point in the future, once I become more comfortable with the repository, I may stop producing the source-code tarballs.
  • Onno Hommes forked the Virtual AGC source tree some time ago in order to make some extensive changes to the way debugging of AGC and AGS/AEA programs is done.  These changes relate to the ability to use gdb style commands rather than the command-set I had invented, and to integrate with GUI debugger front-ends such as Code::Blocks.  In other words, Onno made debugging AGC programs a lot nicer.  The source trees have now been re-merged.  yaAGC debugging has switched entirely to the new method, and the "classic" method previously described on the yaAGC page has been eliminated.  yaAGS debugging is still undergoing change in this direction.
  • When command-line debugging of AGC/AGS programs is being done, both yaAGC and yaAGS now use readline style command-editing and command-histories on all platforms.  I had been unable to provide this feature on several platforms previously.
  • There is now a native-Windows build procedure listed on the download page, again thanks to Onno.
  • The FreeBSD native build procedure may or may not be broken.  I can't tell, because I've broken my FreeBSD installation.
  • I've reduced some 30-second startup delays I introduced in the last snapshot to 5 seconds.  The delays were based on the worst-case characteristics of some very slow test machines I am using, but aren't necessary for more-normal computers.  I've instead added some configuration instructions to the download page if someone should need the longer delays.
  • The cross-build instructions given in previous snapshots were wrong, in that some aspects would work only if my username and directory setup were used.  Hopefully this is fixed now.
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 difference.
  • Can now build Virtual AGC natively in Mac OS X—at least in 10.5.6 Intel—and I have added the instructions for doing so on the download page.
  • Can now build yaAGC, yaAGS, yaYUL, and yaLEMAP in OpenSolaris.  But I haven't worked out any instructions for doing so.  Perhaps at the next OpenSolaris release I'll be able to get it fully working.
  • Finally got around to talking (on the downloads page) about Onno's debugger work, and giving a link to Onno's page.  It was a silly oversight not to do so earlier.
  • Dean Koska's YouTube demo of his Palm Centro port of yaAGC with his custom DSKY has been added to the homepage.
  • Configuration of the joystick for the ACA simulation, though simplified from previous times, was still annoyingly intricate.  I've added small GUI program called jWiz to hopefully simplify the configuration process and bring it a little closer to where it needs to be.  There's a button marked "Handler" next to the VirtualAGC checkbox that enables the ACA, and clicking the button calls up jWizjWiz usage is fully explained in the yaACA/yaACA3 documentation.  
  • I've also managed to fix the annoying characteristic of yaACA that it couldn't display console output in Windows, and thus you couldn't see the information you actually needed for the joystick calibration.  But it still doesn't work in Windows in spite of that, because after its window loses focus it never sees any more joystick events.
  • The yaACA2 program, which has a joystick driver based on wxWidgets, has been added.  So there are 3 separate ACA simulations to choose from, and hopefully at least one of them will work for you.  yaACA2 doesn't seem to work in Mac OS X (though I believe I recall that it did originally), so at least for now it's disabled there.
  • A lot of work has been done in yaTelemetry to display digital-downlink data in a format that would more closely correspond to the way ground control data was displayed in actual missions.  The associated display formats are designated by the names MSK-683, MSK-966, MSK-1123, and MSK-1137.  However, I don't have it actually working yet, so the extra controls which have been added to yaTelemetry for this purpose are disabled and grayed-out at present.
  • In the Mac OS X version, it hasn't previously been possible to run yaAGC or yaAGS in debugging mode—and wouldn't have been possible to configure the joystick using jWiz—because of the lack of any command-line switches in the native Terminal program and the practical inability to use xterm properly on the 10.4 and 10.3 platforms.  Therefore, on the Mac platform we automatically include an open-source terminal program called Terminator, which allows VirtualAGC and jWiz to add back all of the missing functionality. It still isn't possible to use the debugger in 10.3, but it seems to be fine now in 10.4 and 10.5.
  • Discovered (and fixed) that the endian conversions added previously to make symbol tables portable between Intel and PowerPC platforms weren't yet working.
  • On the links page I've added a new document, the "Saturn Ground Control System Mathematical Subroutine Manual".  Don't get too excited, because it's not what you think it is: the "mathematical subroutines" are algorithms for multiplication, division, trig functions, etc.  Thanks to Dimitri Marinakis for sending this!
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.
Big Fat Warning!  The Linux VirtualAgcUninstall script included in snapshots 20060226 through 20090317 will delete your /usr/local/bin directory if you installed Virtual AGC there (or worse, will delete /usr/bin if that was your installation directory).  Please do not run this script.

The latest releases have a different uninstaller, and don't have this problem.  I never noticed the problem, because I had been installing to ${HOME} for a long time before creating the original uninstaller.  Big thanks to Onno Hommes for pointing out the problem.

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 Fabrizio Bernardini:
  • We now know with a higher degree of certainty that Luminary 1E build 210 was flown in Apollo 17 (and probably Apollo 15-16), whereas before there was some dispute that it might have instead been Luminary 1D build 209.  This is significant in the sense that we're aware of a listing for 1D (and may even get a copy of it someday), but we're not aware of the existence of a copy of 1E.  As to what the differences between 1D and 1E are, that will await future revelations!  Perhaps there are none.
  • We are now aware that AGS Flight Program 8 was used in Apollo 15-17, rather than in Apollo 14 as previously supposed.  This is significant because we actually have a copy of Flight Program 8 included within the project, and it's good to know what we have!
Software-wise, lots of bugs have been fixed and auxiliary changes associated with those fixes have been made, so that I'm not even sure I remember them all.  Here are some of the ones that stand out in my mind as particularly significant:
  • There was an issue in sequencing key-releases with shifting of buffered keypad data in communications between yaDEDA/yaDEDA2 and yaAGS, which could basically break AGS communications, requiring a reboot of the simulation to fix it.  The effect was fairly repeatable if the HOLD key was hit and then the READ OUT key was hit.  I *hope* it's fixed now.  A new --debug-deda switch in yaAGS helped me find this one.
  • The yaAGC and yaAGS --debug modes were crippled using the as-distributed symbol tables for Luminary and Colossus, because they embedded path names to the source-code files that were set at compile time ... in other words, for the symtabs I've been distributing, they pointed to source files in directories on my computer.
  • Moreover, the symbol tables used the natural endianness of the CPU, meaning that symbol tables generated on an Intel architecture would not work if I distributed them to a PowerPC architecture.
  • There was a bug in the yaAGC core-dump and --resume, in which half the time resuming from a core-dump would cause the DSKY to become non-responsive.  My believe is that some state information (probably relating to interrupts) was not being saved in the core-dumps.
  • I think there was a bug in direction flags (displacement direction of the control stick from detent) sent to the AGC by yaACA when more than one axis was displaced.  The bug carried over into yaACA3 (see below) as well, but I fixed it in both places.
In terms of new features, again there are lots.  Some of the more significant ones are:
  • VirtualAGC has also been given a capability not present in any software existing previously to the GUI, in that it can perform scripted Digital Uplinks to the AGC.
  • VirtualAGC integrates AGC/AEA compilation and source-code browsing, in addition to merely managing the simulation.
  • yaAGC and yaAGS have been modified so that when in --debug mode they no longer output status messages like socket connections or disconnections of peripherals, thus giving an "easier" to understand debugging experience.
While it is basically a feature-neutral change, the ACA emulation program yaACA has been superceded by yaACA3, principally to allow the use SDL rather than Allegro for providing the joystick interface.  The initial motivation for this was that Paul Fjeld (thanks, Paul!) advised that SDL's joystick code was more stable than Allegro's on Mac OS X.  However, having made this replacement, I find some other significant advantages, the two principal being that there is far less configuration burden (and what configuration there is I've integrated in a way that won't be painful for VirtualAGC), and that I find I hadn't noticed before that yaACA provides absolutely no console feedback on Windows, making debugging that much more painful.  I've also taken the opportunity to use static linking for SDL, to avoid distributing Allegro's dll.  So hopefully it's a win-win-win-win kind of dealio.
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 yaDSKY2).
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, SimColossus249_lite, 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.
  • We've had word of another AGC physical implementation, by Philip Schmidt.  We're not hosting it here, though we'd be delighted to.  Check it out!
  • Dimitris Vitoris has sent us an update to his AGC physical implementation, which now includes most of the 'A1' phase of his Block I design.  (See here.)  Here is his own description, slightly edited for time and content, and to fit on your screen:

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:
  • DSKY
  • Monitoring and Control Assembly - Driver Module     (MCADM)
  • Monitoring and Control Assembly - Logic Module     (MCALM)
  • Monitoring and Control Assembly - Memory Module (MCAMM)
  • Master Controller
 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:
  1. My custom libraries for the PSA05-12GWA Kingbright alphanumeric display and for the RS 336-191 illuminated keys. You'll have to put those 2 in the 'lbr' directory of EAGLE before opening the DSKY schematic (only used there).
  2. The datasheets of PSA05-12GWA and HDSP-5601 plus dimensions and a pic of 336-191.  [Actually, I have held back these datasheets for copyright reasons.  I'll certainly maintain a private archive of them here, in case someone absolutely can't get their hands on them in a 'legal' way—Ron Burkey]
  3. A draft correction log of A1.
 As before these schematics should NOT be considered final and may contain errors. Looking forward for your comments and suggestions!
  • I've discovered a change in the status of the CircuitMaker2000 program needed to work with John Pultorak's Block I schematics, so I've added some textual comments related to that situation.
  • Meanwhile, Dimitris Vitoris has sent some minor corrections to his own Eagle-based Block I AGC schematics.  In his words:
    • I forgot to connect 1_CONTROL_BUS Net19 to U45D in the LOGIC MODULE ALU #5.
    • Also I named U135 as R135 by mistake which lead to the comment #4 situation (Logic
      Module section of my changelog). After that it's R135 again as the original and not R201.
    • That thing is so complex my head hurts...
  • Onno Hommes has updated the AGC source highlighting so that it includes vim (both Linux and Windows) and TextPad.  He also indicates that when all this stuff is installed, emacs also highlights correctly (but he isn't sure why).
  • Dimitris ("Jim") Vitoris has sent us some electrical CAD files using the Eagle schematic-capture program that provide an alternate editable form of the physical Block I AGC simulation pioneered by John Pultorak and available elsewhere on this site.  This is only the first step of what we're hoping ... keep fingers crossed! ... will be a physical Block II simulation.  Check it out!
  • Josef (Jeff) Sipek is now generously mirroring the Virtual AGC website, and a link to his mirror has been added on the links page.  Thanks, Jeff!  Actually, he has been doing so for some months.
  • Onno Hommes has sent us some configuration files (and a nice set of instructions) for adding AGC-specific syntax-highlighting for the following source-code editors:  Kate, KWrite, Kdevelop, and Eclipse.  You can now get these from the download page.
  • Fixed lots and lots of broken or workable but ill-formed links throughout the website.
  • Stephan tells us that v1.0 of his "stand-alone" Windows executable has some startup problems, and has sent a revised version of it.
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:
  • FDAI now fully functional! The attitude looks a bit confusing around ±90 degrees Yaw but that is for the reason that LM_Simulator does not uses a real 3-dimensional ball to show the attitude. Please keep in mind that the LM-IMU has its Gimbal Lock Condition on the Roll-Axis and not on the Yaw-Axis like the Command Module has.
  • A Checkbutton in the FDAI window now allows to switch off the 8-Ball for computers with low performance.  [LM_Simulator's CPU performance has been greatly improved from a month or two ago, but you still might like to reduce it some, and updating the 8-ball is the majority of the CPU time used by LM_Simulator.  Thus, the option for switching it off.]
  • FDAI angles are additionally presented as numerical values.
  • New lm_configuration.ini parameters:
    • Operationg_System "Windows/Linux" - To allow one source code for both operating systems.
    • FDAI_Update_Rate "updates per second" - Choose a lower value if you experience performance problems.
  • New HTML documentation as well as re-work of the existing documents.  [The HTML documentation is in the development snapshot under the directory Contributed/LM_Simulator/Documentation, whereas the ASCII documentation is in Contributed/LM_Simulator/doc.]
Please remember if you're using the development snapshot (rather than the Windows stand-alone executable) that to take complete advantage of the pad loads in the latter-day versions of LM_Simulator, you have to copy Contributed/LM_Simulator/LM.core into the directory from which you intend to run the simulation.
  • Stephan Hotto has sent over what he refers to as a "stand-alone" version of the simulation for Windows.  It is a lot easier to install than the full version of Virtual AGC --- not least because I don't update the Windows version very often --- but is very LM_Simulator-centric.  For example, it doesn't include the Abort Guidance System simulation.  Check it out on the download page!
  • I've improved several of the documents in the HRST archive.  Not much, but a little!
I have found a backdoor into the "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 fixed. 

If you're iffy about installing the new dev snapshot, here's the executive summary of changes since 20060110:
  • Builds again in Win32.  (Not a behavioral change.)
  • Incorporates patches used by the Orbiter integrators.  (Not a behavioral change.)
  • Handles the BRUPT register properly, eliminating some serious problems that occurred when using the digital autopilot.
  • LM_Simulator tremendously improved in terms of bugs, CPU utilization, and some features.
Busy Stephan has sent still another LM_Simulator update, as follows:
  • LM_Simulator now has its own RHC/ACA (Rotational Hand Controller) and THC (Translational Hand Controller). Both are implemented as simple GUI-Elements (Sliders and Buttons).  [In other words, if the joystick interface provided by the yaACA program doesn't work for your joystick, or you don't have a joystick, or you're just not very good at operating the joystick, you can now replace it with LM_Simulator.]
  • A minor change in the RCS calculation allows now the usage of translational commands without influencing the rotation of the vessel.
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 ±90Deg
Pitch: 0Deg ±90Deg
Roll: Anyway limited by the Gimbal Lock condition at 0Deg ±85Deg

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!
  • yaAGC:   The AGC architecture allows for a wacky feature using the BRUPT register, in which an interrupt-service routine can place in instruction into BRUPT to be executed upon return from interrupt.  In other words, the instruction executed upon return from an interrupt doesn't have to be the instruction that's at the location to which the program returns.  I had implemented this feature, but couldn't figure out why anyone would want to do anything so crazy, and so disabled it by default.  'x15' of the group which has integrated Virtual AGC into the Orbiter spacecraft simulator has discovered that this feature does need to be activated for proper operation, as the multi-tasking performed by the program executive makes use of it.  The effect of turning off this feature is that the digital autopilot will hit the dreaded EDRUPT instruction, and hence reset the AGC from time to time.  Hence, it is now activated by default.  (You can get this feature without a new download by compiling Virtual AGC with the command "make -DALLOW_BSUB".)
  • LM_Simulator:  Stephan Hotto has sent in a major update, v. 0.8, that he describes as follows:
  • Critical Bug Fixes!!!
  • Implementation of a precise RCS-Thruster simulation by using the transformation between the U,V and P,Q,R systems
  • Complete rework of the IMU/FDAI which had errors in the coordination transformation between Pilot axes and Stable Member axes.
  • CPU load now below 25% on an Intel Core Duo 2.13GHz processor
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:
  1. yaAGC has to be compiled with: "make CFLAGS=-DALLOW_BSUB".  (This is now the default.)
  2. The LM.core file delivered with the on hand LM_Simulator package has to be used because it is populated with the necessary pad load data
  3. After start of the simulation the following steps have to be executed (please use the Tutorial as a reference):
  • V36E to reset the AGC
  • V37E 00E to start the idle program. Probably there is a need to do this a couple of times until PROG shows 00
  • V48E (DAP Initialization) -> V21E to change the value to 21022 (ACA Fine Scaling 4Deg/Sec)
  • AGC Crew Inputs -> Set "Attitude Hold Mode" to ON
  • V77E (Rate Command and Attitude Hold Mode)
  1. Now the DAP should enable you to steer the LM. !!!Please steer slowly to avoid that the simulation gets overloaded!!!
  2. Use "V49 Crew Defined Maneuver" to let the DAP steer the LM to the selected attitude
  • hrst.mit.edu, the mother-lode of documentation for the AGC, has apparently given up the ghost.  Links at the former site imply that an archive site exists at caltech.edu, but that archive site is apparently "under construction", and has been for the past six months (as I write this).  I have archived the complete contents of hrst.mit.edu, so  if the caltech.edu site does not come up eventually, I'll host all of the old hrst.mit.edu docs myself.  If you have an opinion on this, let me know.  (Thanks, Geoff!)
  • Eugene Dorr has written with such a rave review of "Computer for Apollo", one documentary from a 2-DVD set of documentaries called "Mission to the Moon" (available from www.spacecraftfilms.com), that I feel obliged to mention it even though I have not yet seen it myself.  Apparently, it shows demonstrations of using the AGC, as well as covering the AGC's manufacture.
  • Onno Hommes has written with nice apologia for the interpreter language used in some AGC programming.  I've made a few changes to the assembly-language manual based on his comments.
  • Charles Chapman has pointed out that some of the links on the yaAGC page were pointing to my local disk, and weren't web-accessible.
  • Others have written to mention problems with the Windows scripts, which I hope to take care of soon.
  • Orbiter:  Various source-code changes have been made to make integrating new Virtual AGC versions with Orbiter more routine.  (Thanks to Mark Grant.)  In case you haven't been watching the efforts being made in Orbiter, the integration has been making great strides lately.  There is talk that flying a complete Apollo 8 mission in Orbiter may be possible in the near future.  Check it out!
  • Linux:  When building Virtual AGC, 'make install' now creates an uninstallation script called VirtualAgcUninstall.  I assume this will work on any *nix type system, but I admit I haven't made any effort to try it out except on Linux.
  • Win32:  Recent versions haven't being building on Win32.  (Thanks to Peter Joseph for pointing this out.)  This is now fixed.
  • Mac OS X:  Instructions by Fabrizio Bernardini have been added to the download page for installing the Virtual AGC binaries on Mac OS X 10.4.  Some time ago I removed the instructions for installing binaries on Mac OS X, because it just wasn't any easier than building from source.  However, it has apparently become much easier.
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.

Milestone:  The Artemis072 (Colossus 3) command-module software from Apollo 15-17 can now be run in the simulation!  Simply use the startup scripts SimArtemis072 or SimArtemis072_lite wherever the scripts SimColossus249 or SimColossus249_lite would have been used before.  I leave to those of you who are more expert than I the task of evaluating it.

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.
  • yaAGC:   If you use the VIEW command in --debug mode, the value of the variable will always print at least once now, even if it doesn't change.
  • General:  I had to make a couple of minor tweaks to get Virtual AGC to build in OpenSUSE 10.0.  Note that if you upgrade from SuSE 9.x to openSUSE 10.0, you'll probably need to rebuild Allegro.
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!)
  • yaAGC:
    • The PCDU and MCDU commands (used by the simulated IMU to update the CPU counter registers related to gimbal-angle measurements) have been split into two separate commands each, one of which is a "fast" count at 6400 counts per second, and the other of which is a "slow" count at 400 counts per second.  This replaces the 800 count-per-second buffering used in the 2005-10-05 snapshot.  (But there's some doubt as to whether it actually works yet!)
    • The WATCH command (used in --debug mode) has been fixed so that it accepts symbolic variable names in addition to numerical addresses.
    • A new command called VIEW has been added to --debug mode.  It works similarly to WATCH, except that it displays the values of variables in real time rather than interrupting execution upon change.
  • LM_Simulator:  Stephan Hotto has sent us v0.7.
    • The timing of the Jet Firing, the timing of the dynamic simulation, and the FDAI refresh rate have been decoupled.  This reduces the CPU time, as well as making the firing of the jets snappier.
    • Fast/Slow Increment/Decrement of the IMU AGC counter to pass the KALMAN-Filter.
    • Tutorial extended: "V49E Crew Defined Maneuver Routine"
    • Final Gimbal Lock of the FDAI now at >85 degrees
    • Moment of Inertia factor removed (ini-file and program)
    • There is an LM.core file --- i.e., a snapshot of erasable memory --- in which Stephan has performed a number of erasable pad loads related to things like the LM mass.  (This contrasts with the default LM.core, which is all zeroes, and in which nothing is initialized.)  If you want to use it, please copy it from yaAGC/Contributed/LM_Simulator into the directory from which you run SimLuminary131.  (Probably your home directory.)
  • yaDSKY web-page:  Some image links were broken.  Thanks to Anthony Rich for pointing them out.
  • yaAGC:  Provides a complementary feature to yesterday's LM_Simulator update, in that it internally buffers all PCDU or MCDU commands to the CDUX, CDUY, and CDUZ counter registers, and actually applies them to the counters at an 800 cps rate.  In other words, the simulated IMU can feed in new angle measurements as fast as it likes, but they are now applied to the simulated AGC's internal counters only at an 800 cps rate.  The reason for this is that the real IMU communicated with the real AGC using an 800 cps signal, and the digital autopilot (DAP) in the Luminary/Colossus software employs a digital filter based on this assumed counter update rate.  The filter was intended to eliminate electrical noise and or noisy angles due to the vibration of the spacecraft, but it also has been causing rejection of changes to the CDUX, CDUY, and CDUZ counters that don't conform to the assumed 800 cps timing.  Consequently, the simulated IMU has been feeding info on the spacecraft orientation to the simulated CPU, but the DAP has been rejecting this info.  I don't claim that this change has been extensively tested, though, and an erasable pad load is needed to set the DAP's "Kalman filter" characteristics, or else the CDU inputs will continue to be rejected anyhow.  (But I don't quite know what those pad loads are yet.)  Thanks, as usual, to Stephan for figuring this out.
  • LM_Simulator:  Another v0.6 (but this time really saying 0.6 in the window title).  This should work a little better with tomorrow's yaAGC update, as it is intended to be able to feed in IMU orientation changes at (at least) and 800 cps rate, so as to avoid falling behing the AGC software's expectations about update rates.
  • LM_Simulator:  Another update, v0.6, thanks to Stephan Hotto.  (The main window still says "v0.5", but don't worry about that.)  Here are the changes:
    • Documentation revised
    • Code clean up
    • Changed the switch handling of the DAP Mode Switch within the Crew Switch Window.
    • Rotational Model Moment of Inertia Calculation bases now on the same hyperbola equation as used by the AGC state estimator
    • Roll, Pitch and Yaw Rate-Indicators added. In the real LM the data for these indicators came from the fixed mounted gyro rate assembly unit.
    • Error Needles added. The data shown by the error needles can be switched between 3 modes:
      1. DSKY: V61E -> DISPLAY DAP FOLLOWING ATTITUDE ERRORS. This is the standard mode. The needles show how far the DAP is away from the wished axes positions.
      2. DSKY: V62E -> DISPLAY TOTAL ATTITUDE ERRORS WITH RESPECT TO NOUN 22.  Here the needles display the absolute difference between the entry shown by V16N22E and V16N20E. Normally used for automatic positioning.
      3. DSKY: V60E -> DISPLAY VEHICLE ATTITUDE RATES ON FDAI ERROR NEEDLES. These outputs should provide the same information as the FDAI rate indicators do. The Roll, Yaw and Pitch rate shown by the FDAI bases on a separate Rate Gyro Assembly fixed mounted to the LM body, whereas the Information on the needles shown by V60E is derived from the AGC measurement of the angular changes. This is also a backup mode in case of a Rate Gyro Assembly Fault.
  • LM_Simulator:  Stephan has sent us a new version, designated v0.5.  Here are the changes:
    • Stage Separation
    • Ascent Engine (Veryfication shows that the engine exactly reaches the defined delta V).
    • Extension of the config file by adding the ascent engine parameter
    • Elaboration of the Help text
  • yaAGC & yaAGS:  Several people have pointed out to me that Virtual AGC no longer builds properly on their *nix systems, because of new dependencies I've forgotten to document.  Namely, you now need "readline-devel" and "curses" (or else "ncurses" with a symbolic link making it appear to be "curses").  Now documented in the build instructions.
  • yaDSKY:  "Accelerator keys" have been added, thanks to Christian Bucher.  The hotkeys are: vne0123456789+-.  Note that the hotkeys for VERB, NOUN, and ENTR are lower-case.  There are no hotkeys for RSET, CLR, and PRO.
  • LM_Simulator:  A lot of changes, thanks to Stephan Hotto.  You should particularly note the changes to the tutorial (in the Contributed/LM_Simulator/doc directory).  Here's what Stephan has to say about it:
  • Used the new LM-Coordinates to re-code the whole IMU-Module
    • IMU Coarse Align
    • IMU Fine Align
    • PIPA Vectors
  • Gimbal Lock (Middle Gimbal) on LM-Z-Axis (Roll-Axis)
  • Complete re-work of the RCS Thruster handling:
    • 4 Thruster Mode along X, Y, Z axes
    • 2 Thruster Mode (Minimum Impulse Mode) along X, Y, Z, U, V axes
  • Remark: THC (Crew-Inputs) activates the correct thrusters to translate the LM along the X,Y,Z axes. This increase in speed is not jet reflected within the IMU PIPAs.
  • Update of the tutorial to reflect the DAP mode and data load routines.
The summary of these changes is that for some time we've been trying to correctly match all of the various thrust and rotational axes of the simulation with the axes assumed by the Luminary and Colossus, and hopefully have them all correct now. However,  the DAP is not yet stabilizing the LM even after loading the correct data (e.g. LM weight) as in the updated tutorial. It just bounces back and forth around the desired orientation, until it runs out of fuel.  Obviously, we're still working on figuring that out!
  • Web:  The fragments of Stephan's tutorial (see above) which had been on the yaOtherStuff page have been removed, and the reader is instead directed to Stephan's real tutorial in the development snapshot.  (It was too hard to keep the two in sync.)
  • yaACA and LM_Simulator:  The sign of yaw has been reversed, thanks to Stephan's feedback.
  • LM_Simulator:  (Thanks to Stephan Hotto.)  The mapping of pitch/yaw/roll axes to thruster/joystick axes has been modified.  The ATTITUDE HOLD mode thus now actually works (and attempts to hold the attitude) rather than merely allowing thrusters to fire.  However, there is an overcompensation, so that the attitude overshoots, resulting in continual corrections and eventual exhaustion of fuel.  This may be due to mismatch between the AGC's and IMU's assumptions about the LM's inertial characteristics.  At any rate, it's a big improvement, but we haven't crossed the finish line yet.
  • yaAGC:  The freeze-up problem in ATTITUDE HOLD mode has been fixed, I hope.  For anyone who has been holding off on downloading new development snapshots, I think it's okay to do so now.
  • yaAGC:  In "--debug" mode, a "WATCH A V" command has been added, to allow breaking upon the value stored at an address changing to a specific value.  (Whereas the already-existing "WATCH A" simply broke upon any change.)
  • In general:  All uses of unsigned long long now replaced by uint64_t, to make it easier to build Virtual AGC with MS Visual C++ (which is apparently being done for integration with Orbiter).
  • yaAGC:
    • Fixed the calculation of "patterns" in fixed memory in "--debug" mode.
    • Added detection of certain types of infinite loops, for debugging purposes.
    • The current version of yaAGC has a mysterious problem.  I'm not sure when this problem began.  (I suspect the underlying problem was always present, but that it was masked by other problems in versions 20050814 and prior, so that it was not noticeable.)  The problem can be observed as follows:  Suppose you run Luminary131, then you activate ATTITUDE HOLD mode, then you use the hand controller to fire the thrusters.  At some later time, you'll find that the AGC has become largely unresponsive, though it still responds in an automatic way to certain stimuli.  The only way of recovering from this is to restart the simulation.  Fixing this problem is my top priority at present.
  • LM_Simulator:  Stephan has sent over a new version, differing principally in that it supports combined pitch & roll control from the hand-controller. 
  • yaAGC
    • The DELETE command in debugging mode was not consistent in format with the BREAK command, and (in fact) was broken for numerical addresses; this is now fixed.
    • There had been a problem for some time, in which activating ATTITUDE HOLD mode caused a program alarm 32000.  I think this has now been fixed, with the advice from a number of people.  (Specifically, Julian Webb, Hugh Blair-Smith, and Mike Higgins.  I hope I haven't forgotten anybody; if so, my apologies!)
  • Assembly-language page:  Heavily modified the description of the EDRUPT instruction.  This change relates to the latter bullet point above.
  • FAQ:  Mark Grant has sent me a more exciting screenshot from the Orbiter integration project, showing the DSKY during liftoff.
  • yaAGC:  Christian Bucher has fixed an embarrassing bug for me.  (For arithmetic with a double-precision negative value in which the less-significant word was +0, the more-significant word would have been arbitrarily converted to -0.  Admittedly, I don't know if this situation ever occurred in practice, but it's great to have it fixed.)  Also, Markus Joachim has sent a fix for timing in some output pulses generated by the CPU; the timing error was not perceptible in a human sense, but caused some program alarms in the Orbiter integration.
  • Web-pages:  Stephan Hotto send me some nifty photos of the AGC and DSKY taken at the Computer Historic Museum in Palo Alto.  I've incorporated a few of these into the yaAGC and yaDSKY pages.  The ones on the yaAGC page show some of the inner construction of the AGC.  The one on the yaDSKY page is nice because it's almost head-on, and therefore shows the relative sizes (of buttons vs. indicator lamps vs. numerical display) with reasonable accuracy.
  • Building yaAGC and yaAGS in Win32:  "x15" points out that the Pthreads-w32 project, needed for building yaAGC and yaAGS in Win32, has changed its library-naming, so that you can't use newer versions of this library without manually editing a couple of Virtual AGC makefiles.  The stock Virtual AGC makefiles now auto-select a Pthreads-w32 library version in a way that's hopefully adequate to obviate the need for manual editing.  Note that I've not personally had the chance yet to try it out with the newer versions of Pthreads-w32, so your mileage may vary.
  • LM_Simulator:  Stephan has sent over a new version of LM_Simulator, with the following changes:
    • CPU Load reduction
    • Smaller font to reduce window sizes
  • Luminary page:  Some clarifications have been added, relating to discrepancies in the known versions of Luminary 099.
  • Interoperability with Orbiter integration project:  Applied several code fixes provided as feedback from the Orbiter integration.  (Thanks to Mark Grant.)  Specifically, header-file changes have been made that should allow you to link Virtual AGC libraries to C++ code, and some hooks have been added for use by the Orbiter integration but which could theoretically by used for other purposes as well.  (I refer to the agc_clientdata and ags_clientdata fields in the agc_t and ags_t structures.)
  •  yaAGC's or yaAGS's "--debug" mode apparently did not work on some versions of Windows, but some initialization changes have been made to fix this.  (Thanks to "x15".)
  • yaAGC:  Apparently, we had been concentrating so much on yaAGC's "--debug" mode, that we didn't notice that the regular (non-debug) mode had been broken for several days, and so the usual startup scripts like SimLuminary131 didn't work unless yaAGC was built without readline support.  Jordan has now fixed this for us.
  • yaAGC & yaAGS:  Took care of some build-platform-specific dependencies in finding the 'curses' library sometimes needed with the 'readline' library.
  • Win32 with Cygwin:  For those of you who think my Win32 build instructions seem too complex, Virtual AGC now seems to build with Cygwin.  (Warning:  I haven't yet gotten the Allegro library to install because I'm too lazy to follow the instructions, so I haven't yet tried yaACA.)   You have to install a huge number of Cygwin packages first, but fortunately that's really easy.  For now, I'll just note that you use the Linux build instructions, and you have to do 'make NOREADLINE=yes", because for some reason Jordan's command-history stuff doesn't build.  Also, the stuff for shutting down all of the components of the simulation gracefully doesn't work, so comment out the line reading "SimStop" in scripts like SimLuminary131.  Finally, the steps to running the simulation are to run "startx" from a Cygwin command line, and then to run SimLuminary131 or another startup script from the X-terminal.  I'll write up the instructions for this in detail as I perfect it.
  • Building, in general:  Now have a much better technique, I think, for detecting the build-platform, so there's more consistency among the build-instructions on different platforms.
  • Artemis072 docs:  Thanks to Shelly Kelly and UHCL, we now have the Colossus 3 Guidance System Operation Plan (GSOP) scans ... or at least as much of them as can be located at present.  (Sections 4 and 6 are missing, but we have sections 1-3, 5, and 7.)  Section 7 is particularly interesting, because it documents and contains AGC assembly listings of all programs loaded into AGC erasable core memory rather than fixed core memory.  In other words, these are the programs that were loaded into the "RAM" by the astronauts or via digital upload from a ground station.
  • yaAGS, yaLEMAP:  Thanks to Jordan Slott, symbolic debugging of AGS firmware (via the "--debug" command-line switch of yaAGS) is now implemented.  This also includes a few little flourishes I forgot to add myself, such as a HELP command.
  • yaAGS:  Courtesy of Jordan Slott, yaAGS again has a working --debug mode, and the command-history support in it seems to work perfectly.
  • yaAGC:  Jordan Slott has added a few fixes to the recent --debug mode features.  Because of the fixes, 'readline' support is now enabled by default in the Makefiles. 
    1. With readline support enabled, hitting ENTER no longer interrupted execution of the AGC program.  This has been fixed.
    2. Repaired some spurious printing of prompts during AGC program execution.
    3. "Break" was no longer working.  This is now fixed.  [That was my fault, not Jordan's --- RSB.]
    4. yaAGS now builds when readline support is enabled, and actually works in Win32.  In other words, you can get a command history.  Warning:  In Linux, yaAGS --debug mode no longer functions properly, regardless of whether you compile with or without readline support.  Hopefully that will be fixed Real Soon Now.  (If you need --debug mode in yaAGS under Linux or Mac OS X, please hold off on downloading the development snapshot, since there are no improvements in yaAGS anyhow.)
    5. There is also an issue with the prompt. When you hit a breakpoint it does not print a ">" prompt. You can just hit "enter" to get a prompt.  (Actually, it does work in Windows, but just not in Linux or presumably Mac OS X.)
  • yaAGC:  Jordan has added some further frills to the --debug mode.  Here are the notes on the changes:
  1. Added the "files <regex>" debugging command. This lists the source files matching the given regular expression. 
  2. Reworked the "break" command. Now "break *address" is used to add a breakpoint at a memory address, as in gdb.  The "break <line>" is used to break at a line number, whenever <line> can be parsed as an integer. Update "help break" to reflect this change.
  3. Improved the output from "breakpoints" a bit -- for those breakpoints specified using a symbol or a line number, it outputs the file:line from where it can be found. Note that I do not output file:line if you create a breakpoint using a memory address, although I don't think this would be difficult to do.
  4. Fixed a small bug in "list from,to" where the line numbers were not being displayed.
  5. Cleaned up some of my old code in symbol_table.c
  6. Added the ability to use libreadline to read in the debugger command line. The upshot is you get source file name completion, history, etc.  (Note:  Though apparently functional, this feature is currently disabled in the Makefile, because of some conflicts which prevent yaAGS from building.  Hopefully it can be fixed up soon.)
  • Startup scripts:  After performing some upgrades on my main Linux workstation, I found that the startup scripts (SimLuminary131, etc.) have become unreliable and may randomly shut down the simulation.  (It's a problem in the relatively-recently-added feature that shutting down any component of the simulation, such as yaDSKY, shuts down all of the other components, such as yaAGC and LM_Simulator.)  This should not affect Windows users, but potentially affect everyone else.  I don't know how to fix this problem with any satisfying degree of certainty, but workarounds have been added that should reduce the probability of such a random shutdown to a very low order of probability.
  • yaAGC & yaYUL:  Jordan has greatly improved the symbolic debugging, with the greatest improvement being that (where possible) the actual source code is displayed rather than disassembled source code.  This lets you see not only program labels and variable names, but even program comments.  Several versions of the LIST command have been implemented in the debugger, so that you can get various types of disassemblies.   Also, it's all related to the source files by filename and line number, so it's cross-referenced much more nicely.  I'd say this feature is now at a completely satisfying stage, from a user's point of view.  Note:  The symbol tables created for this functionality are now quite large.  (About 11 megabytes each for Luminary131 and Colossus249.)  Therefore, you'll now find that Virtual AGC is chewing a lot more disk space than before.
  • yaAGC & yaYUL:  Jordan Slott (thanks, Jordan!) has sent in a very cool mod that integrates symbol tables produced by yaYUL into the "--debug" mode of yaAGC.  The upshot of this is that in some cases you can use symbolic names when debugging, rather than being forced to use absolute numeric addresses all the time.  It's still not fully implemented, but it's pretty valuable nonetheless.  Refer to the yaAGC page to see how to use it.  Symbolic debugging was on my wish list, but I was too lazy to do anything about it.  Besides, it was very brave of Jordan to poke around in my source code.  (Hopefully there won't be too much emotional scarring.)  This builds and works on both Linux and Win32, but I haven't had a chance to try it in MacOS X.
  • Scans of the Colossus 3 GSOP document have begun filtering in.  (Thanks to Shelly Kelly and U. H. Clear Lake.)  I only have section 1 and a small chunk of section 2 right now, but more is coming.  (This is nicely coincident, of course, with the fact that the Colossus 3 source code is also dribbling in, and the GSOP document is basically the program documentation.)
  • yaDSKY:  Thanks to the availability of the docs mentioned above, all of the CM digital downlink lists have been implemented.  Therefore, all of the downlink lists are now implemented (if not necessarily correctly).
  • yaACA:  Fixed a bug in variable-declarations that caused compilation with gcc 2.9.x to fail (but which gcc 3.x hadn't minded).
  • yaYUL:  The inconsistency in SBANK bits between the octals produced by yaYUL on Linux vs. Windows platforms has been fixed.  (One octal word in Colossus249 was being assembled incorrectly in Win32; the incorrect octal word was being repaired by a workaround in the makefile, but would actually have executed properly even if it hadn't been repaired.  Now that yaYUL is fixed, the workaround in the Makefile has been removed.)  Also, some variable initializers which did not work properly Linux for PowerPC has been fixed; this error manifested itself in assembly-time error messages, but presumably could have caused incorrect octals as well.
  • Linux PPC:  Virtual AGC now builds and works on Linux for PowerPC (or at least, on Ubuntu 5.04 for PPC).
  • Mac OS X:  Now builts completely (including yaACA, which hadn't ever been built before on Mac OS X), and partakes of the automatic shutdowns recently put into the Win32 and Linux versions, and is so much more convenient to shut down.  Furthermore, the installation/build instructions have been completely revamped, so the simulation is much more convenient to run, and a little more convenient to build.
  • yaACA:  There had been a bug in which the raw joystick values as received from the driver were being used for yaAGC, without applying yaACA's --yaw, --pitch, and --roll adjustments, or even their default values; for me, this only affected the Win32 platform (with the symptom being that in ATTITUDE HOLD, the thrusters were continually firing to increase yaw), but it has been fixed for all platforms.  The program has been tweaked so that its timing is much more convenient in Mac OS X.  Also, if it does not find a joystick on start-up, it keeps trying until it finds one, so you can plug in the joystick after startup without having to restart the simulation.
  • MS Windows:  A few days ago I was able to modify the startup scripts (SimLuminary131, etc.) in Linux so that:  a) they don't open so many useless windows; and b) they shutdown all of the Virtual AGC apps and windows when you choose to exit from any one of them.  This is tremendously convenient, and is theoretically possible in Windows XP Pro, but not (apparently) in Windows XP Home, or any other version of Windows.  The facilities for doing process management simply aren't provided in Windows in a form usable by batch files.  So instead, I've written a program (WinAGC.exe) that accomplishes the same thing.  It's a program that simply runs groups of programs, and then shuts down all of those programs when any one of them shuts down.  I've revamped all of the Windows batch files (SimLuminary131.bat, etc.) so that they take advantage of WinAGC.exe.  This should work in any version of Windows, but I've only tried it in Windows 98 (first edition), Windows XP Home, and Windows XP Pro. 
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).
  • yaAGC, yaAGC, others:  Some fixes have been made that can prevent the CPU utililization from shooting up to very high levels under some circumstances.
  • MS Windows:  The startup scripts have some experimental improvements that may (in Windows XP Professional only!) allow automatic shutdown of the simulation when any of the apps closes.  I further hope that the scripts continue to work as before in non-XP-Pro versions of Windows.  To activate the new script feature, you need to set the environment variable XPPRO to anything non-blank.  Since I don't have a computer with XP Pro available, I haven't been able to try the new feature out.
  • LM_Simulator:  This is the last version for at least a month, so enjoy now!
    • Fixes a critical bug within DSKY Lite which causes a serious memory problem and therefore the slows down handling the socket data when "Attitude Hold" was activitated. Now LM_Simulator does not fall behind in reading socket data anymore.
    • The simulation of the joystick is very limited jet and just in an experimental status. The steering commands are only recognized when they are along the three axis (Roll, Pitch and Yaw). A combined steering command (e.g. u or v axis) is not yet implemented.  Also, the calculation of the RCS fire time is based on the setting within the "Attitude & Speed Control" window.  The simulation just takes the RCS thruster time and multiplies that time with the joystick amplitude divided by 57.  That means that a full stick deflection takes the selected time as RCS fire time.
  • LM_Simulator:  
    • Dynamic CPU Load handling.  (It's infinitely more responsive than in the last version, and you can ignore the workaround advice I gave on 2005-07-06.)
    • All RCS parameter and Moment of Inertia factors are configurable within the INI file.
    • The Moment of Inertia and therefore the rotational model are quite near the real thing.  (Data Source: CSM/LM Spacecraft Operational Data Book Volume III Mass Properties.)  Assumptions made:  Moment of Inertia along all three axes is identical (which is obviously not completely true for the real world).  MOI change is stable over the whole LM weight range (which is comparable with real world behavior).
    • It now interoperates with yaACA, so that when you turn on attitude-hold, you can see the digital auto-pilot (DAP) firing thrusters in response to displacement of the rotational hand-controller (RHS).  Of course, if you don't have a 3D joystick, this will be of little value to you.  Also, the connection has not yet been made between the thrust outputs of the CPU and the thrust inputs of the IMU.  In other words, while the IMU can respond to thrust inputs entered into it manually, it will not yet respond to the thrust commands generated by the CPU.  (By the way, turning on ATTITUDE HOLD causes a program alarm 32000---which is a CPU overload---but this is not LM_Simulator's fault.  We'll worry about this problem later.)
  • yaACA:  There were lots of bits in input channel 031 that yaACA was supposed to be setting but was not.  It is now, I hope.
  • yaAGC:  Was incorrectly saving the contents of CM erasables in LM.core rather than CM.core.  In other words, the Colossus simulation would always start up using the Luminary erasables.  This is now fixed.
  • In general:  Virtual AGC has been opening so many windows on your screen, that it's very difficult not only to manage them, but also to make sure you get all of the individual programs closed when you want to exit the simulation.  The startup scripts have now been modified to that in Linux, so that not only are less xterms open, but also closing any one of the applications (like yaDSKY) will also close all of the other applications and windows as well.  I only found out how to do this by accident, and it's awfully convenient!  I don't know how to do this in Windows, but I'm sure I'll figure it out one of these days.  (Of course, if anybody already knows, it would be ever so helpful ....)
  • Mac OS X:  I've noticed that (as usual) the Mac OS X version has become almost impossible to build, and almost intolerable to use.   *Sigh!*
  • Artemis072:  Banks 6-7 of the octal executable are now available, proofed, and have the correct checksums.
  • yaACA:  Development continued, because LM_Simulator is now at the point where it wants to have a rotational hand-controller (RHC).  I think yaACA is actually complete.
  • yaAGC:  Modified to accept data from yaACA, and to output RHC data for use by LM_Simulator, yaAGS, etc.  Note that LM_Simulator has not yet been modified to take advantage of this stuff.
  • Docs:  Various RHC-related stuff added or modified on the developer page and language-manual page.
  • yaAGC:  Tweaked a little to restore erasable 010 upward on startup (rather than 020 upward).  Also, most of the machinery has been put in place to allow structural coverage analysis of the executed flight software, but it is not actually working yet.
  • Artemis072:  Banks 4-5 of the octal executable are now available, proofed, and have the correct checksums.
  • LM_Simulator:  (Stephan continues to be a busy bee.)  This is the first version with a rotation model.  (In other words, rather than adding angular displacements around the pitch/yaw/roll axes, you can apply thrust around the pitch/yaw/roll axes.  Once you start playing with that, it's hard to stop!)  The calculation of the "moment of inertia" by using the LM mass distribution is not yet correctly implemented.  The values used are just experimental.  The calculation of the RCS propellant consumption depends on the RCS impulse length and should be correct within in the current simulation which uses 445N for each thruster and a specific impulse of 2840MS.  The Attitude control uses an impulse length between 0.05 - 1 second.  The CPU usage has popped up again to very high levels in this version, and if you're going to use it I'd suggest not turning on the "output log".  However, the rotational model is so neat to have that I'd be reluctant to recommend not using this version.
  • Artemis072:  Banks 0-3 of the octal executable are now entered, proofed, and have correct checksums.  Half of bank 043 is (and has been) in place and proofed, but there's no way to know if the checksum is okay with only half a bank.
  • yaAGC:  Now saves the contents of erasable memory when the AGC "powers down", and restores it when the AGC "powers up", to preserve things like pad loads.  I'm sure there are other things that need to be restored that I'm not restoring, or things I'm restoring that I shouldn't be, since it always starts with OPR ERR now.  But we'll work it all out eventually.  For a full explanation (along with available adjustments) see "--dump-time" on the yaAGC page.
  • Artemis072:  Bank 0 of the octal executable has been added and proofed, but there's still a 1-bit error in it somewhere.
  • LM_Simulator (thanks, Stephan):
    • Fuel Flow is calculated by using the specific impulse (3050m/s)
    • The CPU load has been heavily reduced.  (By about 50%.  It's now fast enough to run in Mac OS X 10.2, which before it was not fast enough for.)
    • The simulation initialization values (such as the LM mass) are configurable within the INI file
    • The degree character doesn't show up correctly on some target platforms, and has now been removed from the FDAI/IMU window.
    • Tcl "-smooth" option removed, to allow versions of Tcl/Tk prior to 8.4 to be used.
    • Now the simulation model for the Descent Engine is verified by using the Tsiolkovsky rocket equation:
      DeltaVelocity = Specific Impulse * ln(m0/m1), where m0 = Start Mass and m1 = End Mass
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.
  • yaAGC:    Although channel 033 is an input channel, the CPU writes to it from time to time.  Bits 11-15 of the channel are latched inputs, and the act of writing (presumably, independent of the value) resets the latches to 1.  What yaAGC had been doing is to treat the channel as an output channel, which obviously is very different.  This is now fixed.  (Thanks to Markus Joachim and Mark Grant for pointing out the problem.)
  • LM_Simulator:   Now simulates the LM Weight -> Thrust -> Acceleration -> Velocity relationship.  The model does not yet take in consideration the effect of thrust reduction by increased velocity (Rocket Equation).  (Thanks, as usual, to Stephan Hotto.)
  • Colossus 3:   I've had small bits and pieces of Colossus 3 ("Artemis" build 072) in hand for a while, but it was so little that there was no point in mentioning it before.  It looks like much more of it is rolling in now, so I'm adding it to the development snapshot as I convert it to machine-readable form.  Artemis072 is, of course, the AGC flight software for the CM in Apollo 15-17.  (Thanks to D. Thrust for making this available!)  We are adding the core-rope image first (before the source code, that is), so that it will be possible to run the program long before seeing or assembling the source code.  So far, memory banks 2 and 3 are present in the core-rope image and have correct checksums.
  • yaDSKY & libyaAGC:  Made the formatting of the downlink lists even more flexible, by providing the option of using user-defined functions.  Made use of these to correct a few fields in the downlink lists which have already been completed.  All LM downlink lists are now complete, if not necessarily error-free.  CM downlink lists are barely started.
  • LM_Simulator:
    • PIPA handling integrated. Display of Velocity data (Meter/Second or Feet/Second) within the FDAI.
      • By using the Attitude Simulation Window a velocity increase in Yaw direction (Main Thrust Axis) will be separated into the different PIPA (X,Y & Z) components (one pulse = 0.0585Meter/Second).
      • For example: If the IMU Z-Axis is parallel to the Yaw-Axis then the velocity increase goes directly into the Z-PIPA. To reduce the velocity the LM has to be rolled for 180° to bring the velocity vector in the oposite direction.
    • Some spelling corrected ("to -> too").
    • Socket timeout (from yesterday) removed.
    • A lot of algorithm optimization.
    • The FDAI recognizes now the GIMBAL LOCK.
      • Gimbal Lock reset is possible by "V36E" (AGC Reset) or the Crew Input "IMU Set to 0°"
  • yaAGC:  My changes yesterday to fix fine-alignment had the side-effect of causing the alignment changes to look very jumpy on the FDAI ball.  The (relative) smoothness has now been put back in.  Also, the coarse-alignment is much more smooth-looking than it had been previously.  More importantly, the optics trunnion & shaft drive is now supported, by means of new fictitious output channels.
  • Stephan has sent a new version of LM_Simulator.  Here are the changes:
    • Workarounds added when we believed the fine-alignment problems were on the LM_Simulator side rather than the yaAGC side have been removed.  (Specifically, the angle-increment value is corrected, and the coordinate transformation has been deactivated.)
    • Drives the IMU to Zero when the "Zero IMU CDU" signal is activated. Now the IMU zeros after V36E (AGC reset) but there are cases where the AGC lefts the signal active. After using the crew button "Zero IMU..." the signal goes back to zero.
    • Drive the IMU only when "Coarse Align Enable of IMU" is activated. This is really an important change, because in the "Attitude Hold Mode" the AGC uses the counters to drive the error needles and the autopilot misalignment. If the IMU was driven in such cases, then the FDAI would jump uncontrollably over a small angle area.
    • Socket Timeout added. If there is a period longer than 2 seconds when no data appears on the socket, then the LM Simulator assumes that the AGC has been terminated. After showing an error message: "Lost connection to yaAGC" the program terminates itself.  (This is a slight problem when yaAGC is run in --debug mode.  We are looking at fixes for that case now.)
    • Attitude & Speed Control has been changed.  (You don't have the same precise level of control over roll, pitch, and yaw as before, but it's much easier to use.)
If I'm not mistaken, this means we're at a nice milestone:  the IMU simulation in LM_Simulator can now be regarded as functional.  (The next level needed will be to feed spacecraft accelerations and rotation into the IMU automatically rather than manually.)

  • yaAGC:  Well, I was wrong, and there still were fixups that needed to be made in order to get fine-alignment to work.  That fix is made, but there is still a little fix that needs to be made in LM_Simulator to get it all finished.  (The  angles aren't scaled quite right yet.) 
  • yaDSKY & libyaAGC:  I've also done a lot more fixups related to the portability of the downlink-list parser.  The description of how to take advantage of the portability has been added to the developer page.  The LM Coast/Align downlink list is now parsed.
  • Well, we have a discussion group now.  Or at least, the software for a discussion group has been installed and appears to work.  I'll mess with it another day or two, and the let it loose on the world.  I hope that a lot of you---particularly software developers---will join and exchange ideas.
  • Stephan has sent over a new version of LM_Simulator.  The changes are:
    • FDAI finalized (Z-Axis added)
    • A bug fix for counting.  [To keep the simulated angles equal to those of the AGC there is a need for both an external counter which stores the IMU angles in high resolution and a counter which counts in angle increments of (0.01Deg).  Previously, only the latter was used, leading to large angle misalignments after several attitude changes. Now, there is a synchronization between the counters, which enables a sufficient precision in angle handling.]
  • yaAGC:  Previously, there was no use made of the GYROCMD counter register in gyro torquing during fine-alignment.  Since the GYROCMD register is the central entity in this operation, that pretty much ruined it.  The upshot of this fix is that IMU fine-alignment should now work properly.
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 and SimColossus249 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.
  • Rewrote a lot of the telemetry-downlink formatting code I added yesterday.  I realized that I could write it in a way that was much more flexible so that even though it is used in yaDSKY's "--test-uplink" mode, it could also be used without change in yaTelemetry or other apps, with mere replacement of a pointer to the function that does the actual output.  In other words, the code is now completely reusable, and independent of the output device.  Consequently, I feel much more enthusiastic about going ahead to do more work on it.
  • Stephan has sent over a new version of LM_Simulator.  Here's a summary of the changes, as I understand them:
    • There are now Roll, Pitch and Yaw commands in the attitude window, which translate into the associated IMU gimbal angle changes.  (Previously, there were X, Y, Z gimbal-angle commands that simply drove the gimbal angles without translation.)
    • There is a kind FDAI ball in the IMU window now, though Stephan points out that "with TCL/TK there is no chance to create a real FDAI ball." (Even so, in my humble opinion, it seems darned good.)
  • In yaDSKY's "--test-uplink" mode, I now print out a little of the downlink lists in more human-friendly form, but there's just so much data that the effort of making it human-friendly---i.e., printing it with descriptive headings and units, and scaled properly---is enormous.  There are a couple of thousand data values in the complete collection of downlink lists (though, admittedly, with some overlap among the lists).  I don't think I'll do much more of it right now.  I have, however, organized the hooks for doing it into libyaAGC, so the effort isn't entirely wasted, and is potentially reusable by anyone who wants to complete the work.  I'd be more excited about doing it myself, if I knew what the displays on the downlink-telemetry consoles in mission-control were supposed to look like.
  • I have added a couple of new commands (LMSIM and CMSIM) to the yaAGC/yaDSKY INI files.  These commands tell the simulation whether it is supposed to be for an LM or a CM.  (Odd that this hasn't been needed until now, isn't it?)  The downlink lists for the LM and CM aren't distinguishable in some cases without this additional info.  (They would have been distinguishable in real life, because the telemetry downlink hardware external to the CPU would have added this identfying info, I think.)
  • yaAGC:  The digital uplink has now been implemented.  I had to modify the description of it that I added to the developer page a few days ago, but not by much.
  • yaDSKY:  I've added a new command-line switch, "--test-uplink".  In this mode, yaDSKY emits uplink-data when keys are pressed instead of emitting keycodes to its usual CPU input channel 015.  This mode is very convenient for testing the digital uplink, since the uplink data consists of encoded DSKY keycodes anyhow.  I've noticed that yaAGC is very lazy in updating the DSKY display when receiving uplink data; indeed, it may or may not update the display.  However, in the absence of other data, I assume this is a normal property of the Luminary and Colossus flight software, rather than a bug in yaAGC.  This mode also prints messages when valid downlink data is detected, so I think it's fair to say that both the digital uplink and digital downlink are working properly now.  Note:  If you want to see something keen you can do with this, look at section 2.1.2 on p. 2-8 of the LM GSOP.  Enter V71E on the DSKY (in --test-uplink mode), and proceed from there.
  • yaAGC:  I now properly handle the DOWNRUPT interrupt request.  The practical upshot of this is that the CPU is now emitting downlink telemetry and/or AEA initialization packets, whereas it was not doing so before.  You can see the downlink in LM_Simulator, but it's just raw data on i/o channels 034 and 035, and so isn't very informative as of yet.
  • I rationalized the startup scripts somewhat.  In particular, an LM_Simulator script is created during installation, and the other scripts (like SimLuminary131) call that script.  This shouldn't matter much to anybody but me, I guess, but it allows yaAGC's --debug switch to be used again with the scripts.  Scripts like SimLuminary131 can have up to three command-line arguments, the first of which is passed (in common) to yaDEDA and yaDSKY, the second one of which is passed to yaAGC, and the third one of which is passed to yaAGS.  Scripts like SimLuminary131-lite have a single optional command-line argument, which is passed directly to yaAGC.   The table below is probably a complete list of the useful ways you can use the command-line options with the scripts.  (Though not shown, the SimColossus249[-lite] scripts work the same way, but obviously without yaAGS and the DEDA.)  If you want to do something trickier, you should probably run the various programs directly rather than relying on the startup scripts.
Just run the simulation without options.  yaDSKY will be the DSKY simulation and yaDEDA the DEDA simulation.
SimLuminary131 --half-size
Same, but yaDSKY and yaDEDA will be half-sized.
SimLuminary131 "" --debug
Run the simulation with yaAGC in debug mode.
SimLuminary131 "" "" --debug
Run the simulation with yaAGS in debug mode.
SimLuminary131 --half-size --debug
Run the simulation with yaAGC in debug mode, and yaDSKY/yaDEDA half-sized.
SimLuminary131 --half-size "" --debug
Run the simulation with yaAGS in debug mode, and yaDSKY/yaDEDA half-sized.
Just run yaAGC and LM_Simulator (without yaAGS and yaDEDA).  LM_Simulator provides the DSKY simulation.
SimLuminary131-lite --debug
Same, but with yaAGC in debug mode.

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 turn off.
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.)
  • Added the "lite" options and scripts, to allow building Virtual AGC without yaDSKY and yaDEDA, and running it instead with the DSKY Lite module from LM_Simulator.
  • More changes to LM_Simulator:
    • --port and --cfg command-line parameters added.
    • A fatal bug was fixed in the socket read routine which increases a counter until eternity in case of no input on the socket, leading to an array overflow for the data input array.
    • Furthermore, I've added the Alarm Codes out of the Luminary Listing because of the alarm simulation capabilities of LM Simulator .
    • FDAI / IMU color corrected
  • The development snapshot now builds and works in Windows again.  This is thus the first opportunity to really use yaAGS, yaDEDA, and LM_Simulator on that platform.  It does build on Mac OS X, but LM_Simulator seems to run at super-slow speed, and even to slow down yaAGC/yaDEDA to the point where those programs don't work, so I'm not sure what's going on there.
  • LM_Simulator:  Well, Stephan has been a busy little bee.  Here is a list of changes:
  • Blocking behavior of the simulator due to missing data on the socket has been fixed
  • CPU load reduced
  • LM System Input: "IMU Operate with no Malfunction" is now active by starting the program
  • To allow a free configuration (e.g. on/off) of windows or different IP-Addresses to connect to yaAGC an INI-File has been added (lm_system_simulator.ini)
  • The window arrangement and content has been optimized
  • The IMU Coarse Align and IMU Fine Align is implemented, although the last one does not work correctly. (The counter is merely for very small angles quite proportional to the given angle)
  • New FDAI/IMU window to monitor the gimbal angles
  • "Attitude & Speed Control" window to simulate gimbal angle changes has been added
  • Tutorial updated
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 the DVP 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.

In case it wasn't clear from the comments above, the complete basic suite of Abort Guidance System software is now available and (hopefully) working, in Linux:
  • CPU emulator (yaAGS)
  • Data-entry and display emulation (yaDEDA)
  • Flight software source code and executables (Flight Program 6 and Flight Program 8)
  • Assembler (yaLEMAP)

  • In yaAGS, fixed some problems with the LRS instruction, and continued fixing the DVP instruction.  The DVP instruction is better than it was before, but it's still not totally fixed.
  • The SimLuminary131 script now runs not only yaAGC, yaDSKY, and LM_Simulator, but now runs yaAGS and yaDEDA as well.  It's pretty impressive to see them all running at once.   I still haven't attempted to run LM_Simulator, yaAGS, or yaDEDA (or even to build them) in Windows or Mac OS X yet, so I'm referring only to Linux here.
  • Added a very small tutorial for yaAGS/yaDEDA to the "quick start" section of the home page.
  • In yaAGS, fixed problems forming double-precision operands in general, and sign-generation problems with the LRS instruction.  Fixed the handling of overflow in instructions "LLS 0" and "ALS 0".  The DVP instruction is really messed up with negative divisors, and I have no clue as to what's going on with it.  However, yaAGS can now communicate with yaDEDA, and the CPU emulation works well enough that you can do things like looking at the results of the self test.  (CLR 4 1 2 READOUT, for anyone who's interested.  The displayed code, +30000, means a "logic error", such as a bad DVP instruction.)
  • In yaAGC, fixed the handling of the DINC unprogrammed sequence, so that POUT, MOUT, and ZOUT signals are output.  (Thanks to Stephan Hotto for pointing out the problem.)
  • Also, Stephan has provided a new LM_Simulator, with gyro-tracing functionality.
  • In yaAGC, implemented a fictitious output channel 0177 (see the developer page) which can be used for simplifying implementation of emulated gyros.
  • In yaAGS, added the DISASSEMBLE, COUNTS, and PATTERN commands for debug-mode.  Fixed the TIX instruction, which was overwriting memory and causing the problem mentioned two days ago.  But now I find that there is a fundamental problem in the yaAGS/yaDEDA interaction through the socket interface; yaDEDA only transmits data to yaAGS upon a strobe from yaAGS, but there is not enough time between the strobe and the time the flight program checks the shift register for the data to be exchanged.  Resolving this will take some thought.
  • In the development snapshot, added a version of Stephan Hotto's LM_Simulator program which he has wrapped as a Windows executable (so that you don't have to install Tcl/Tk to make it work).
Lots of work on yaAGS, but mainly in the form of improving debugging (fixing i/o-channel addresses, editing of memory locations, backtraces, etc.).  Somehow yaAGS 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.
  • Various corrections to yaAGS.
  • Correction of DEDA shift-register bit-ordering in yaDEDA and yaAGC.
  • Stephan Hotto has sent us yet another update to LM_Simulator.  Here are the changes, as described by Stephan:
  • Unknown unprogrammed sequences as output of the AGC/AGS are now handled (hopefully ;-))
  • Improvement of the DSKY Lite by using real 7-Segment numbers
  • Remove of a trace (inserted for development) of an internal timer which would fill up the Log-Out-Window
  • Crew Button handling (AOT, Descent) corrected
  • DSKY PRO button is now working
  • Time printouts removed
  • DSKY Labeling and Number Size as well as separation lines corrected and added.
  • Most important, the program now merely recognizes AGC data packages with the following signature: 00... 01... 10... 11... So, the AGS packets shouldn't have a negative impact any longer.
RHC does not work yet because beside setting the associated input bit, a counter must be increased proportional to the stick angle.
  • Stephan Hotto has sent us a new version of LM_Simulator.  Here's what he has to say about it:
Bug Fixes:
  • AGC Output has been completely revised. Now I'm using text labels which will show the different state of the signals.
  • LM System Signals and Crew Buttons corrected. I'm still unsure in some cases.
New Features:
  • DSKY LITE is a very simple (awful graphics) but full functioning DSKY. Due to your extensive description of the interface it was quite simple to implement.
  • IMU Simulation has been corrected and accelerated. The angles are now running between 0° and 360° as noted by the AGC.
  • Simple RHC and THC as well as AOT buttons added
  • Noun & Verbs and first steps of the Tutorial added.
The "DSKY LITE" is, I think, remarkably good, in spite of Stephan's badmouthing of the graphics.
  • Corrected polarity and bit positioning of AGS "input discretes" on the developer page, in the yaDEDA program, and in "yaAGC --debug-deda".
  • yaAGS is coming along very well.  I'm now trying it in --debug mode, and fixing bugs in some of the instruction set.  Shouldn't be too much longer before it's ready to use with yaDEDA.
  • Lots more work on yaAGS.  Getting close to being ready to try out.
  • Fixed up the GUI in yaDEDA so that it is consistent in sizing with yaDSKY.  (Before, I had stupidly made it bigger.)  Should now work in Mac OS X, though I haven't tried it yet.
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.
  • Removed the CVS subdirectories and some symbolic links from future development snapshots.  (Thanks to Markus Joachim for pointing them out to me.)
  • On the links page, updated the status of the integration of Virtual AGC with the Orbiter simulator.  (Hint:  It's going great, and there is now a Sourceforge project for it, again thanks to Markus Joachim.)
  • There's now a skeleton of a yaAGS program.  It doesn't do much yet other than to allow yaDEDA to connect to it, load the selected flight program, and keep accurate time, and execute a few types of instructions.  Lots of instructions are implemented, but they're all of a rather simple nature.  (But who knows if they're implemented correctly?  I haven't quite figured out yet how I'll be testing these things.)
  • Stephan Hotto's LM_Simulator program is now included in the installation when doing 'make install' (i.e., building from source).  The SimLuminary131 script runs LM_Simulator in addition to yaAGC/yaDSKY.  You need to have Tcl/Tk installed to take advantage of this, but if you don't nothing bad will happen.  Incidentally, Stephan has given me a list of a few problems he's found so far.  I won't bother to put these in the buglist quite yet; the LM_Simulator program is so new that it's in rapid flux.  After it has settled down some, then I'll start recording bugs for it.
Note:  This big bunch of changes isn't without cost.  This stuff likely won't build (or won't build completely) on Windows and Mac OS X.  I'll fix this up soon, but probably not until I'm happy with yaAGS.  Therefore, Windows and Mac OS X users will probably want to stick with the binary packages, use an earlier source package, or else just take your chances.
  • On the developer page:  Added some yaAGS-specific functions to the API, and on a global basis made the applicability of the API's library functions (yaAGC vs. yaAGC, CPU vs. peripheral) much clearer.  Also, added a section on the yaAGS core-image file format.
  • On the yaOtherStuff page, corrected a couple of links (thanks to Fabrizio Bernardini).
  • On the download page, added some additional info about the Mac OS X binary tarball.
  • yaDEDA seems to be working, as near as I can understand its operation at present.  Of course, there's no yaAGS to operate it, but I added a command-line switch to yaAGC (--debug-deda) that seems to provide a pretty good test.
  • On the yaOtherStuff page, I've added a "contributed code" section because the development snapshot now contains a nifty i/o-channel monitor (on it's way to becoming an IMU simulation) contributed by Stephan Hotto, called LM_Simulator.  It's a work in progress, but is quite useful as it stands.
  • The AEA/DEDA interaction is now covered in much more detail on the developer page.  In fact, there is an entire section devoted to it.
  • Scans of Delco's quick-reference cards for Apollo 15 Luminary 1E are now available on the links page, thanks to Fabrizio Bernardini.
  • yaDEDA is now mostly working.  With luck I can finish it up tomorrow.  yaAGS doesn't exist yet, but because the DEDA is smarter than the DSKY, you can actually use it and see a lot of what it does even without yaAGS.  (Whereas yaDSKY is completely useless without yaAGC.)  Refer to the yaAGS page for more detail.
  • More noodling with the yaDEDA program ...
  • The yaAGS page has been pepped up with additional verbiage, such as:
    • More circumstantial evidence that the two missing pages of FP6 have been reconstructed correctly.  I thought the evidence was pretty good before, but it seems conclusive now.
    • A table of known versions of the AGS flight program.
    • ... and more.
  • There is now a skeleton form of the yaDEDA program.  So far it really just shows what the GUI will be like, but it does have a working socket interface (in the sense that it can connect to a server), though it doesn't know what to do with any of the information it receives on the socket interface.  I haven't made the mods yet that would allow it to build in Windows, nor have I checked that it still builds in Mac OS X.
  • Also, there's some great news.  Thanks to Allan Klumpp, it appears that Luminary 1A 099 (Apollo 11) and Luminary 1D 209 (Apollo 15-17 we think) will soon be available.  Now, I don't know whether "soon" will be two weeks, two months or two years, as I don't yet have access to these materials.  But it's still great.  Yay, Allan!  (There are other people to thank for this as well, but I'll save some of my praises for when the listings are actually available.)  Any of you folks out there who have Luminary or Colossus listings you've been hoarding had better step forward soon if you want to get any karma points out of this deal!
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 pretty good.
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. 
  • There's now a Mac OS X binary package.  It doesn't conform in any reasonable way to what a normal Mac OS user would expect, so probably it's nearly as unusable as the source package.  But at least it does avoid the necessity of building the program.
  • Website:  On the links page, corrected the link to José Portillo Lugo's paper (thanks to Jordan Slott for pointing out the bad link), and added a link to Don Eyle's "Tales from the Lunar Module Guidance Computer".  On the FAQ page added another email contact address, in case somebody has experience blockage of the normal Virtual AGC email address for some reason.
  • Source code (AGC and Virtual AGC):  Corrected a lot of out-of-date website references, from sandroid.org to ibiblio.org.  However, there are hundreds of files in this project and the website is referenced in each one, so I didn't fix them all.
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

AGS document entry is now complete.

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 be restarted).
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.
  • yaLEMAP:  The alignment of fields in the assembly listing is now better.  The format of the output binsource file has also changed to make audio proofing go a little faster (by removing leading zeroes).
  • AGS FP6 source code:  I've proofed the first two blocks of memory, and the checksums of all three blocks are correct.  I personally believe that the source code is now 100% complete and correct, although I haven't proofed the third memory block (4000-7777), because I believe this block did not change between FP6 and FP8.  Anyone who wants to proof it and make a liar of me, be my guest!  It may take a while for me to get to it.
  • On the AGS page, the link to the textual (vs. scanned) listing for AGS FP8 has been updated (because of the yaLEMAP formatting changes mentioned above).
  • A link for the textual (vs. scanned) listing for AGS FP6 has been added to the AGS page.
This is a nice little milestone:  The AGS cross-assembler and the source code for AGS Flight Programs 6 and 8 are now completely available and correct, along with scans of most documents needed to learn how to write AGS programs.

  • The AGS page has been fancied up with various illustrations and a lot more text (particularly in discussing the architecture).
  • The AGS FP6 source-code data-entry has been completed, but none of it is debugged.  There are no errors or warnings from the assembler, but only one of the three memory areas has a correct checksum, so it is known that errors are present in the source code.
  • A big, fancy AGS block diagram has been added, thanks to John Pultorak.
  • The AGS FP6 software-test document is now available, thanks to John Pultorak and Davis Peticolas.
The scan of the AGS FP6 Operating Manual has been added, as usual thanks to John Pultorak and Davis Peticolas.
  • The AGS FP8 source code is now debugged, and its binary proofed against the scanned listing.  Obviously it's always possible for me to have made mistakes, but I think it's 100% complete and correct now.
  • Minor changes were made to yaLEMAP and binLEMAP.
  • Addition of "CHECKSUM RANGE" to yaLEMAP for proper assembly of AGS FP8.s.  The OCT pseudo-op now conforms to the programmer's manual (though it actually worked well enough before).  Various minor formatting changes also to make the assembly listing look prettier.
  • The AGS FP8 source code has been through a lot of proofing/debugging.  It now assembles without errors and the symbol table is probably correct.  However, the binary still has some bugs, since the checksums are wrong.  Comparison with the binary from the scanned assembly listing has begun.
Data entry for AGS Flight Program 8 source code is complete, but no debugging has been done on it yet.
  • Yesterdays's scans have been cleaned up.  The PDF page numbers now match the numbers marked on the pages, and the many foldouts in the "programmed equations" have been processed so that each is a single page rather than 2-3 separate pages.
  • Approximately half of the AGS FP8 source code has been entered, but not proofed.
  • The scans of the AGS FP6 assembly listing and "programmed equations" document are now available.  Again, thanks to John Pultorak and Davis Peticolas.
  • Some (not much) FP8 source code has been entered.
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 yaLEMAP 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 better?)  
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.)
  • Documents:  A variety of significant new scanned documents, or excerts from documents, have been added to the links page.  These have been contributed by Fabrizio Bernardini and Paul Fjeld, but I have received more documents from them than I have yet been able to process.
    yaUniverse:  Has been cleaned up a lot, and has a lot more options.  After experimentation, it now has a lot more realistic default timestep for the numerical integration (6 hours rather than 1 minute).  Consequently, we can get realistic ephemeris data with a 1-hour rather than a 1-minute timestep, and can therefore tremendously reduce the ephemeris data in size.  For testing purposes, the Apollo8-epoch ephemeris data is very complete (including the Earth, Moon, Sun, Mercury, Venus, Mars, Jupiter, Saturn, Ganymede, Io, Europa, Callisto, Titan, Tethys, Dione, and Rhea), though ephemeris data for other missions (not yet created) will only initial data points.
  • Documents:  A variety of new scanned documents, or excerts from documents, have been added to the links page.  These have been contributed by Fabrizio Bernardini and Paul Fjeld, but I have received more documents from them than I have yet been able to process.
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.
2004-09-21 Assembly-language manual:  Updated/added descriptions of various pseudo-ops.
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.
  • Win32 zipfile on download page:  Well, I don't know what was behind my inability to create uncorrupted zipfiles, but it seems to be fixed now.  It affected only the 20040905 and 20040910 files.  The 20040912 zipfile should be okay, and contains exactly the same stuff that the 20040905 file was supposed to contain.  Sorry for the inconvenience.
  • yaDSKY:  Added the LM1.ini configuration.
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.)
  • yaYUL:  Various small tweaks needed for Colossus:  The CADR pseudo-op can now appear in the midst of interpretive operands.  (Thought this had been done yesterday, but it was messed up.)  Added processing for the "=MINUS", "MEMORY", and "SUBRO" pseudo-ops (the latter two of which actually do nothing for us).  No longer generates fatal errors for illegal EXTENDs, if preceded by INDEX (since there's no telling at assembly time whether the code executed after indexing needs an EXTEND or not.)  Also, the RESUME instruction no longer is treated as an EXTEND for the purpose of detecting fatal errors.  The latter two changes allow us to remove the "--force" command-line flag from the Makefiles used for assembling Colossus249 or Luminary131.
  • Colossus249 source code:  Now completely debugged and, with the yaYUL changes above, assembles correctly.  Yay!  I had to add a dozen or so extra SBANK= pseudo-ops --- because I am still unable to determine exactly how 2CADR et al. set the superbank bit --- but I'm willing to live with that.
In case it isn't obvious from what I've written above: 
  1.  yaYUL is now complete.
  2. The Colossus249 core-rope is verified to be 100% accurate.
  3. The Colossus249 source code is 100% complete and accurate (except possibly for the program comments).

  • Website:  Downloads of assembly listings created by yaYUL for Colossus249 and Luminary131, are now available on the links page, the Colossus page, and the Luminary page, to save the reader the effort of building them or of downloading the horrendously huge scans.
  • yaAGC:  One of the Mac OS X changes broke the Win32 build.  This has been fixed.
  • Colossus249 core-rope image:  Found a set of three mutually-offsetting (i.e., checksum-preserving) errors in bank 00.  And a complementary pair of errors in bank 12.  Yikes!
  • Colossus249 source code:   More debugging.   Banks 00-26 (octal) out of 43 now debugged, though there is an unsupported instruction used in bank 01 (so yaYUL needs a tweak to actually assemble the code).
  • yaYUL:  Various small tweaks needed for Colossus:  The DEC and 2DEC pseudo-ops previously did not treak -0 differently from +0.  The previous method of treating "ERASE start - end" was incorrect; it is now equivalent to "EQUALS start".
  • Website:  Numerous small corrections and rearrangements.  Most significantly, there is now a little more understanding of the EDRUPT instruction, there is more description of the various proposed peripheral components (yaIMU, etc.), and the former yaTelemetry page has been co-opted as a "yaOtherStuff" page to cover all of the peripherals (other than yaDSKY).
  • Colossus249 source code:   More debugging.  Down to about 243 fatal errors now.
  • Brought the ibiblio site online and automatically redirected references from sandroid.org/Apollo to ibiblio.org/apollo.  (Keep fingers crossed.)  An important consequence is that the NARA finding aids are now online rather than requiring a snail-mail CDROM.
  • Added a little more data about the original developers to the acknowledgements.  (Thanks, Willard Simmons and Rob Stengel.)
  • Colossus249 source code:   More debugging.  Down to about 345 fatal errors now.
  • Colossus249 source code:   Debugged a lot.  Right now, there are no undefined symbols and about 575 fatal errors.  (Sounds bad, but at the start of the evening there were, I think, about 700 undefined symbols and 3000 or 4000 fatal errors.)
  • Began the process of moving the website to ibiblio.  It's a slow upload, but perhaps it will finish tomorrow.
  • For downloads, I've eliminated ftp.sandroid.org/Apollo, in favor of www.sandroid.org/Apollo/Downloads, in preparation for an expected move of Virtual AGC to ibiblio.org.  Hopefully the links have all been changed properly, and so there should be no disruption unless somebody has bookmarks specifically to ftp.sandroid.org.  If so, I apologize.  The move will allow us much greater capacity in terms of providing document scans.
  • Main makefile:  Problem report #26 (spurious error messages from yaYUL) is now hopefully worked around, as far as builds of Virtual AGC are concerned.  (I knew about this bug before, but didn't know that it was occurring in the build and causing 'make' to fail.  Thanks to Craig Steffen for pointing this out.)
  • Colossus249 source code:   Now 100% complete, though the code is not yet debugged and the comments have not been proofed.
  • I should have noted also that yesterday's update fixed a problem in the Linux makefile, relating to installing non-existent ephemeris data.  (It existed on my machine, so I didn't notice.)
  • Some additional bad links were fixed.  (Thanks to Ed Thelen.)
  • Colossus249 source code:    Source code through page 1362 (out of 1505) of the scan 1701.pdf is now available.  (In a sense, all of the source code is now available, since all of the remaining stuff will be adapted from similar Luminary131 files rather than transcribed.  However, all that's happened so far is the copying and not the adapting.  And of course, not the slightest portion of it has yet been debugged.)
  • Mac OS X Panther:  Thanks to Matteo Giani, some slight changes have made Virtual AGC buildable on Mac OS X Panther.  I suspect, but don't know, that this will work on earlier versions of Mac OS X as well, if X11 is first installed.  The download page has been changed to show the build-instructions, along with a screenshot provided by Matteo.
  • Fixed a few bad links.  (Thanks to Melissa Reid for pointing them out.)
  • By the way, the existence of the Apollo 11 Luminary and Colossus source-code listings at MIT has now been independently confirmed, although I was pretty darned sure about it anyway.  (Thanks, Sandy Brown.)
  • Colossus249 source code:    Source code through page 1243 (out of 1505) of the scan 1701.pdf is now available.
  • Language manual:  Added Peter Adler's theory as to the history of the EDRUPT instruction.  Thanks, Peter; you made me laugh.
  • Colossus249 source code:    Source code through page 1064 (out of 1505) of the scan 1701.pdf is now available.
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.
  • yaIMU:  Well, it's not much yet, but it's something.  (Namely, Earth/Moon/Sun ephemeris data for the Apollo 8 mission epoch, and an untried program for loading that ephemeris data into memory.)
  • Colossus249 source code:    Source code through page 973 (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.
  • Website:  Added a list to the acknowledgements of as many of the Luminary/Colossus programmers as I could find reference to.
  • Colossus249 source code:    Source code through page 915 (out of 1505) of the scan 1701.pdf is now available.
  • yaDSKY:  Added the --delay command-line switch, in an attempt to address PR#23.
  • Colossus249 source code:    Source code through page 890 (out of 1505) of the scan 1701.pdf is now available.
  • yaDSKY:  Mr. Paul Fjeld has informed me that the digits in the DSKY simulation haven't been quite right.  (In his words:  "The digits on the [real] DSKY were unique and very cool.")  Since Mr. Fjeld is both an artist and the Spacecraft Manager for LM-13 at the Cradle of Aviation Museum, I'm inclined to believe him.  Besides, he prepared an all-new set of images of the digits and sent them to me, thus saving me most of the work in changing them.  So obviously, the appearances of the decimal digits have now changed in the software, and indeed, have changed pretty dramatically.  (For now, though, I'll let all of the screenshots on this website stay the way they are, so they're all a little inaccurate.)
  • Colossus249 source code:    Source code through page 801 (out of 1505) of the scan 1701.pdf is now available.
  • Developer changes (normal functionality not affected):  My original intention was that yaAGC would be developed in a way that was very independent of the peripheral devices (like the IMU and DSKY), and somewhat independent as well from the means of interfacing to the peripherals.  Unfortunately, over time this idea became corrupted to the point that it really became impossible for developers to use anything other than the default socket-based interface (which I still recommend!), unless the yaAGC source code itself was hacked quite a lot.  This has become unacceptable, since there are a number of groups adapting yaAGC to existing flight simulators, or other purposes, and all of this independent hacking will make it time-consuming to port improvements to yaAGC into all of these efforts.  Therefore:
    • I have  separated all socket-based code from the offending source-code file (agc_engine.c), and replaced it instead by a simple 3-function API that should be usable for developing memory-mapped i/o models, embedded AGC's, or other purposes, without further modification to agc_engine.c
    • I have created an embedded demonstration (i.e., of an AGC as embedded firmware) based on a Motorola Coldfire microcontroller, using an unmodified agc_engine.c.
    • These concepts will be explained in detail on the developer page, over the next week or so, though no details are available there yet.
  • yaAGC:  (And speaking of improvements that need to be back-ported ...)  I have noticed that although I provided all of the hooks for processing external triggers for counters (such as gimbal CDU counters), I did not actually implement them.  In other words, if yaAGC received a signal to increment a counter register, it would not actually do so.  Hopefully this has been fixed.
  • Colossus249 source code:    Source code through page 776 (out of 1505) of the scan 1701.pdf is now available.
  • Win32 compile:  This broke a couple of days ago without my noticing it.  Fixed now.
  • Today was a remarkable day for this project, for a variety of reasons, of which I'll mention only the following:  Up to now, I have feared that only the Luminary 131 (Apollo 13 LM) and Colossus 249 (Apollo 8/9 CM) software listings have survived, since no other versions have turned up.  However, Mr. Paul Fjeld has told me of the existence of 3 additional AGC software versions, including (apparently) both the Luminary and Colossus versions used for Apollo 11.  While I don't have any of these, so I can't make them available to you, there is now a much stronger basis for hope that they can be provided in the future.  (Any volunteers in the Boston area who would like to scan the Apollo 11 program listings?  Let me know.)
  • Colossus249 source code:    Source code through page 760 (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.
  • Miscellaneous:  The developer page now has a reasonably-detailed table of suggested port assignments for interconnection of AGCs and simulated peripherals.  The SimLuminary131 startup script has been changed in accordance with these suggestions, with the bonus side-effect of allowing you to use SimLuminary131 and SimColossus249 simultaneously without conflict.
  • Colossus249 source code:    Source code through page 682 (out of 1505) of the scan 1701.pdf is now available.
  • yaYUL and Luminary131:  When building the software, a regression test has been added in which the Luminary131 source code is assembled with yaYUL, and the resulting binary is checked byte-for-byte against the known-good binary.  This has the helpful side-effect of creating Luminary131.lst --- i.e., an assembly listing --- which is much more useful than having to use the scanned listing (650 Mbytes, 1729.pdf).
  • Colossus249 source code:    Source code through page 629 (out of 1505) of the scan 1701.pdf is now available.
  • yaAGC (and yaDSKY), Win32 version:  Some problems with socket-connections between yaAGC and yaDSKY have been cleared up, so that yaAGC can now be expected to detect that yaDSKY has been shut down.  This means that if yaDSKY is stopped but yaAGC is kept running, yaDSKY can be started up again later without problems.
  • Colossus249 source code:    Source code through page 544 (out of 1505) of the scan 1701.pdf is now available.
  • Miscellaneous: 
    • All of the Virtual AGC executables (or at any rate, all of the important ones), display a common version number separate from the build date, and controlled from the Makefile.   (Right now, the number happens to be 0.90.)  Undoubtedly, this will evolve further in the future. 
    • The process of creating the Win32 binary distribution has been made much easier, and so it should be easier to keep the binary distro more up-to-date with the development snapshot.
    • The FAQ page has been updated with hints on some of Virtual AGC's quirks.
  • The webb2burkey-rope utility is now part of the installation.
  • yaAGC:  Upon connection of a new peripheral (such as a DSKY), the peripheral is now updated with all current i/o-channel settings.  (Previously, the peripheral simply received changes to the i/o channels on an ongoing basis, but had no knowledge of channel outputs prior to connection.  This was bad on the Win32 platform where --- for some still-unidentified reason --- peripherals can only be started after yaAGC starts.)
  • Validation:  Because of the yaAGC change mentioned above, it has become possible to remove the artificial startup delay in the validation suite.
  • Colossus249 source code:    Source code through page 527 (out of 1505) of the scan 1701.pdf is now available.
  • Note to anybody who downloaded yesterday's dev snapshot:  somehow, the changes I made yesterday did not appear in the snapshot, though the Win32 binary download should be okay.  Oh, well!  Hopefully, today's snapshot will be okay.
  • Miscellaneous:  The default Win32 install directory hardcoded into yaAGC and yaDSKY has been changed (from /usr/local/bin) to c:/mingw/bin.  This should let command-line switches like --core and --cfg work properly, instead of forcing full pathnames to be used with them.
  • yaDSKY:  The default yaDSKY graphical interface is far too big for any graphics resolution less than 1024×768.  I've therefore now added another mode to yaDSKY, in which interface is only half as big.  Use yaDSKY's --half-size command-line switch to get the smaller interface.  The smaller interface doesn't really look very good, because it is simply blindly scaled down from the larger interface, rather than being optimized, but at least it's usable at 800×600 and 640×480 resolutions.
  • Colossus249 source code:    Source code through page 500 (out of 1505) of the scan 1701.pdf is now available.
  • Miscellaneous: 
    • I now take pity on you poor, deluded Win32 users, and provide executable binaries for you rather than forcing you to build Virtual AGC yourself.
    • I now provide shell scripts (or batch files for Win32) for running various common configurations of the simulator.  These shell scripts are called SimLuminary131, SimColossus249, and SimValidation.
    • Made sure that all executables show a copyright notice and reference this website.
    • In Win32, if the build environment is based on Msys as I recommend, you can now just use "make", "make clean", or "make install", rather than "make -f Makefile.Win32", "make -f Makefile.Win32 clean", and so on.
  • yaAGC
    • When typing HELP from the --debug command-line, the help-text was curiously truncated.  But the help-text was far too long to fit on the screen anyway, so I've now fixed it that the HELP-text is topic-specific (resulting in much shorter messages).
    • In Win32, you can now get a debug prompt by hitting the return while the program is running, just as you can in Linux.  To accomplish this, the program has become multi-threaded.  POSIX Threads for Win32 is now an additional requirement for being able to build Virtual AGC in Win32.
    • Now that running --debug mode in Win32 makes much more sense, I've cleaned up the Win32 version of the register display used in --debug mode.
  • Colossus249 source code:    Source code through page 417 (out of 1505) of the scan 1701.pdf is now available.
  • yaDSKY:  PR #21 fixed.  (yaDSKY can now be built in SuSE 9.1 again.)
  • Colossus249 source code:    Source code through page 384 (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 217 (out of 1505) of the scan 1701.pdf is now available.
  • Luminary131 source code:  A link to this website has been added to the header of each source file.
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 now available.
Colossus249 source code:  Resumed data entry.  Source code through page 36 (out of 1505) of the scan 1701.pdf is now available.
  • yaAGC:   The timing for polling has been changed, in order to reduce the PC's CPU utilization.  Also, backtrace references (as originally intended) are no longer created when not in --debug mode.  (In Linux on my 2.8GHz P4, the net effect of these changes is to reduce the CPU utilization from 90-98% to an immeasurably small percentage whilst waiting for --debug mode keystrokes, and to 0-2% whilst running the simulator.  In Windows XP, the CPU utilization is 0.)
  • yaYUL:   Fixed a segfault that caused the Win32 version of the assembler to crash.
  • yaYUL:   The method used of selecting the positive or negative branch in computing bugger words did not match the method used by YUL.   Assembly of the validation suite was broken by addition of the bugger words; this is fixed.  Numerous additional fixes, related to selecting coding schemes for interpretive operands, for avoiding conversion of constants to addresses until absolutely necessary, for correct ordering of inversion of interpretive operands vs. incrementing of interpretive operands, for using program labels that correspond to operator names like TC and VN, and so forth.
  • Luminary131 source code:  Numerous fixes. 
The yaYUL program now assembles Luminary131 source code to the correct core-rope image.  Therefore, yaYUL is now working and the source code for Luminary131 is now correct.  (However, Luminary's source-code comments still need proofing, and yaYUL still emits some confusing errors and warnings.)

  • yaYUL:  Fixes to formatting of the list-file output.  Banks are now terminated with their "bugger words".  Various assembly fixes, particularly to shift operative instructions.
  • Luminary131 source code:  Numerous fixes.  We're now down to about 35 fatal errors and 765 mis-assembled core-rope words.
  • Website:  Lots of earlier development snapshots have been removed in order to save megabytes.  I still have them, if anybody is interested.
  • Luminary131 source code:   A few minor fixes.
  • yaYUL:  Implemented the comma-suffix notation for the operands of interpretive opcodes.  We're now down to about 110 fatal assembly errors and about 1020 mis-assembled core-rope words.
  • Luminary131 source code and yaYUL:  Lots more fixes of a similar nature to yesterday.  The number of mis-assembled core-rope words is down to about 1430, though the number of fatal errors has increased to about 350.
  • The last few snapshots (I think) may have omitted the core-rope binaries and/or may have included zipfiles of some of them.  Of course, it's perfectly easy to build the core-ropes, but (on the grounds that people may not like doing that) the new snaps will include the core-ropes.
  • bdiffhead:  Added the --only-super and --lst-super switches.
  • Luminary131 source code and yaYUL:  Lots more fixes of a similar nature to yesterday.  The number of mis-assembled core-rope words is down to about 6040.
  • bdiffhead:  This is a new utility I've added for displaying the differences between core-rope files.  (It's only useful for debugging yaYUL, Luminary131 source, and Colossus249 source.)
  • yaYUL:  Added the --force command-line switch.  Lots more tweaks from working with Luminary.  There are only about 7700 core-rope words (out of about 39,000)  assembled with the wrong value now.   (Sounds bad, but a couple of days ago there were over 15,000 fatal errors, and the core-rope --- if I had bothered to create it --- would have been 100% wrong.  And  yaYUL still assembles the Validation program correctly, so we're not moving backward either.)
  • Luminary131 source code.  A lot more fixes.  There are only about 90 fatal errors now.
  • yaYUL:  The program is still incomplete, but at least it can generate the symbol table for Luminary.  (Since there are over 7000 symbols in the program, I don't claim to have performed an exhaustive check, but the symbols I have checked are correct.)
  • Luminary131 source code:  A huge number of fixes (100's, probably) discovered in the course of working on yaYUL.
  • Validation:  Added a few seconds delay at startup, to allow running the test without yaAGC's --debug switch.
  • yaYUL:  Continued developing the framework for assembling interpretive opcodes.
  • yaYUL:  Fixed PR #19, in which (somehow) I managed to break the ability to assemble the validation suite.  Put the framework in place for assembling a lot of the interpretive instructions --- though quite a bit of the interpretive instruction stuff doesn't actually assemble correctly yet (namely, the STCALL, STODL, STORE, and STOVL instructions, and the operands).
  • The size of the development snapshot has been creeping upward because of accidental inclusion of stuff like output from yaYUL and zipfiles of core-ropes.  Some of the worst offenders have been eliminated.
  • yaYUL:  Added various instructions-aliases and pseudo-ops:  CAE, CAF, COUNT, BBCON, 2CADR, 2BCADR, 1DNADR, -1DNADR, 2DNADR, -2DNADR, 3DNADR, -3DNADR, 4DNADR, -4DNADR, 5DNADR, -5DNADR, 6DNADR, -6DNADR, DNPTR, -DNPTR, DNCHAN, -DNCHAN.
  • Luminary131:  Various typos fixed in source code.
yaAGC:  Apparently I had forgotten to implement yaAGC's --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 posted.)
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 better.)

Goto-pooh (V37E00E) now works in the CM sim.  As far as I know, the CM sim is now working as well as the LM sim is.  Woo-hoo! 

  • A few additional fixes for Win32 builds that work on some systems (with some versions of make) but not on others.
  • Fixed some goofed-up instructions in the "quick start" section for running the sims.
  • yaAGC:  Now at v0.86; this is the version I intend for intial announcement on freshmeat, in time for 35th anniversary of the lunar landing, which is tomorrow.  Added the --interleave command-line switch (and associated internal goo) to work around the incredible sluggishness I've seen when running the simulation on slower PC's.  Reworked some of the data displays in --debug mode to fit into the width of crippled Win32 command lines.  The number of ports scanned for socket connections is now 10 rather than 5.
  • yaDSKY:  Reworked the  --help messages to fit into the width of crippled Win32 command lines.
  • The simulation is now known to work on Windows 98.
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.
  • Validation:  Added some delay loops in the validation suite to work around some quirks in the prototype of Julian's sim.   Fixed the polarity of the PRO key, which was inverted.
  • ControlPulseSim:  Added the BZF pulses, the extra control pulses needed to handle it, and handling for the br1,br2 flags (though I don't think the latter are correct).
  • yaDSKY and *.ini:  Added the control signals for the ALT and VEL indicators to LM.ini.  (Thanks to Julian Webb for this info.)  Also, finally got around to eliminating the PRIO DISP and NO DAP indicators from LM.ini; I've known they were bogus for about 8 months, so it's about time!  Fixed a bug in which bit 10 of channel 13 could be used to turn on all of the DSKY lights.  Fixed the polarity of the PRO key, which was inverted.
  • yaAGC:  Final contents of L register now explicitly overflow-corrected after DCA, DCS, and DXCH instructions.  The default values of input channels 30-33 (octal) have now been changed to reflect the fact that they contain low-polarity signals rather than high-polarity signals.
Most of the various super-annoyances I've been having, like the LM sim crashing 100 seconds after power-up, and not being able to change major modes in either the CM or LM sim have now suddenly disappeared.   yaAGC and yaDSKY now appear to be working for the LM with only minor caveats.

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 called ControlPulseSim, 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 ....
  • Validation:  Added error sub-codes and single exit points to all of the tests that were written before I thought of doing this.
  • Spec (language manual):  Extensive changes, due to the change of Q from 15 bits to 16 bits.
  • yaAGC:  All addition operations changed to work on full 16-bit (non-overflow-corrected) values when the data source is A or Q.
  • yaDSKY:  Fixed (I hope) the intermittent bogus display of +/- signs.
  • yaAGC:  Added 16th bit to Q register.   The correct 1-second delay now appears with "monitor" verbs (rather than the bogus 2 minute 43.85 second updates we were seeing earlier).
  • yaDSKY:  Fixed a bug in the OPR ERR indicator introduced yesterday, in which rather than a lit OPR ERR, we'd see a dark KEY REL indicator where the OPR ERR was supposed to be.
  • Validation:  Smally's COUNTCHK, D--LCHK, O-UFLOW added.
  • Website:  Rearranged text between the FAQ page and the home page.  Add a "Quick Start" section to the home page, illustrating some of the things you can do with the simulation.
  • yaDSKY and *.ini:  Added i/o-channel mappings mappings for the GIMBAL LOCK, PROG, NO ATT, TRACKER, and STBY indicators.  Fixed the DSKY's reaction to channel 13, which previously was clearing the display any time the DSKY-test bit was not set.  The OPR ERR and KEY REL indicators now flash.  When flashing VERB/NOUN is activated, we now flash the digits rather than the VERB/NOUN labels above the digits.  The flashing rate has been changed from 1 cycle per second to 1.5 cycles per second.
  • Website:  Fixed the links page so that it's easier to get to spaceborn.dk's (Ron Noteborn's) javascript DSKY simulation.
  • Validation:  More stuff from Smally:  MSUCHK.  Also, added error sub-codes to make it easier to track down which specific test caused the error.
  • Spec (language manual):  The MSU instruction now says that overflow is cleared rather than set as a result of the operation.  In DCA and DCS, the special cases of "DCA L" and "DCS L" are covered.
  • yaAGC:  The MSU instruction has been "fixed"; this fix is dubious since it is "to the test" rather than from the functional description.  The cases of "DCA L" and "DCS L" have been added.  And --- yikes! --- fixed a major problem, in that I forgot to inhibit interrupts while overflow is present; the result was intermittent loss of overflow/underflow.  By analogy with BZF and BZMF (see notes for 07/08/2004), "CCS A" has been changed so that +overflow is treated as a +non-zero and -overflow is treated as a -non-zero.
  • yaYUL:  Fixed INDEX for the case in which the operand is a constant rather than a program label.
The CPU's instruction set is still buggy, but at least there's a little more functionality than previously.  We can now run Luminary's or Colossus's show-banksum program.  (Luminary will freeze up about 100 seconds after power-up for some reason, so it's probably better to try this with Colossus.)  What the show-banksum program does is to successively display checksum information about the various banks of memory.
  • Validation:  Added Smally's DAS+INCR.  The validation program has become too large to fit into fixed-fixed memory, so I've now split it up to use both fixed-fixed and common-fixed.
  • Spec (language manual):  The DAS and DDOUBLE instructions have been changed so that the signs of the less-significant and more-significant words of the sum no longer need to match.  In DV with dividend and divisor equal in magnitude, the remainder is (and has been) the divisor; but we no longer say in this case that the sign of the remainder is adjusted to match the dividend.
  • yaAGC:  Changed to match the spec changes mentioned above.   Also, when the DV instruction had a remainder of 0, it was always being treated as zero without distinguishing between +0 and -0.
  • yaYUL:  Implemented the 2FCADR pseudo-op.
  • Validation:  Continued, with Smally's TC+TCF, CCSCHK, BZMFCHK, RESTORE1, RESTORE2, RESTORE3, BZFCHK, DXCH+DIM.
  • Spec (language manual):  Changed to indicate that positive or negative overflow block BZF and that positive overflow blocks BZMF.
  • yaAGC:  Fixed the instructions CA and CS so that they re-edit the editing registers.  The spec changes mentioned above were made in the CPU also.
  • Validation:  Continued, by adding stuff (particularly MPNMBRS and DVCHECK) from Smally (E-2065).
  • yaYUL:  Fixed the aliases for the ZL and ZQ instructions.
  • yaAGC:  The sign of the remainder for one weird case of the DV instruction has been fixed (and changed in the spec).  A bug in various types of DP arithmetic when the most-significant or least-significant word is -0 has been fixed.
  • Validation:  Continued by writing test code for the MASK, READ, WRITE, RAND, WAND, ROR, WOR, and RXOR instructions.
  • Added instructions for using the validation suite to the download page.
  • yaYUL:  Had not been retaining the extracode flag after an INDEX instruction.  Also, now add a notation in the output list-file that shows where include-files end.
  • Validation:  Continued.
  • yaAGCDXCH was deliberatedly not doing overflow-correction on the accumulator before; now it is.  Also, it was incorrectly detecting the case "DXCH L" (which permutes the A, L, and Q registers).
  • yaYUL:  Tweaked error messages so that they are formatted similarly to gcc error messages.  (Useful when working in an IDE that takes you directly to errors in the source code.)  For multi-word pseudo-ops like 2DEC, only the first word was being written to the binary; this is fixed.
  • Validation suite:  continued to improve.
  • yaAGC:  Handling of the 16th accumulator bit by the DCOM instruction has been fixed.  Fixed handling of signs in conversion of certain values from internal DP representation to AGC DP representation.  The DAS instruction was not leaving the correct values in the accumulator or L register.
  • Have begun writing a "validation suite" program in AGC assembly langauge, which I can use to test the implementation of the AGC instructions one by one rather than waiting to encounter them doing something flaky in Luminary.
  • yaYUL:  Now writes out the core-rope if there are no fatal errors.   Didn't do this earlier, since I was waiting for a complete version of yaYUL that could assemble the Luminary or Colossus binary perfectly.  We're not at that stage yet, but I needed a way to assemble the validation program mentioned above.  (In other words, yaYUL is capable of assembling the validation program.)  Also fixed a bug in which the INDEX instruction wasn't assembled properly with symbolic operands.
  • Luminary131 core-rope image:  PR #8 has been fixed.  (Note:  The core-rope image is now known to be correct not merely by the indirect evidence of correct checksums, but because it has been compared byte for byte with an image created independently by Julian Webb.  Thanks, Julian!)
  • yaAGC:  A serious bug in the SU instruction has been fixed, in that the wrong operand address was being used.
  • yaAGC --debug mode:  A bunch of new script files (for use with the FROMFILE command) have been prepared.  There is one for each instruction type, and what they do is to delete the "patterns" used to trap on those instruction types.
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 instructions.
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 the MP 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. 
Today is a pretty big milestone, since both Luminary and Colossus now (sometimes) accept input (such as nouns and verbs) from the DSKY, and display information on the DSKY.  Alas! there are still bugs in yaAGC that keep it from doing anything really useful yet.  But up until today the DSKY just sat there and did nothing, like a lump of virtual metal, so it's still exciting.
yaAGC:  In --debug mode, now continues to try to service client (yaDSKY) connects or disconnects while waiting for keyboard input at the debugger.
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 after RESUME 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 counter updates.
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 supposed to.)
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.
Primitive  backtracing ability added to yaAGC --debug mode.
(After 20040510 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 and yaDSKY'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 with gdb.
yaAGC's --debug mode now has a command ("getoct") for converting numeric values to/from the AGC's native format.
Made various changes to make the --debug mode of yaAGC easier:
  1. The disassembler now shows opcodes for the implied-address instructions, like "SQUARE" instead of "MP A" and "RETURN" instead of "TC Q".
  2. When INDEX is used with an instruction, the disassembler decodes and shows the instruction with the index added (along with a notation "w/i"), instead of leaving the user to deduce it.
  3. The timing used (i.e., the number of machine cycles in a given period of real-time) was messed up when --debug mode was used, since the time spent waiting at the debugger prompt was not accounted for.
  4. The timing also was not previously right with the --resume switch, since the time used prior to generating the core-dump wasn't accounted for.
  5. The construct sysconf(_SC_CLK_TCK) is now used in place of CLK_TCK.  This is required for new compiler versions.  I don't know if it will break under older compilers or not.  I think I've fixed it to work with Win32 also.
'make install' now copies *.ini, Luminary131.bin, and Colossus249.bin to the installation directory (which is hard-coded as /usr/local/bin, so it's not totally perfect).  Meanwhile, yaAGC 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 debugger.
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.
More CDROM-only 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 plan".
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 previously-missing Luminary 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 assembly-language manual.
Lots and lots of improvements to yaAGC:   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, etc.
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 proofed.
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 proofed.
Fixed a bunch of web links.
Colossus249 binary:  Bank 3 now proofed.
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 are unknown.
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 operational.)
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 yaTelemetry, 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 the Luminary131 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 Colossus249 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 following:
  • Complete Luminary131 source code (but still presumably with lots of typos), and no binaries.
  • A 90%-complete yaYUL assembler.
  • A 95%-complete yaDSKY simulation.
  • The framework of the yaAGC emulator.
  • Some rewritten documentation.
Got the idea for this project, whilst watching the movie Apollo 13.

Last modified by Ronald Burkey on 2009-08-30.

Virtual AGC is hosted by ibiblio.org