Virtual AGC Change-Log Page

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:

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).
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]
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!

2008-01-13

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

2008-01-03

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!

2007-12-28

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.

2007-04-25

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.

2007-04-22

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.

2007-04-17

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!

2007-04-16

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.

2007-04-15

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.

2007-04-13

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.

Enjoy!

2007-03-17

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.

2007-03-16

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.

2007-03-05

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:

yaAGC has to be compiled with: "make CFLAGS=-DALLOW_BSUB". (This is now the default.)
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
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)
V61E (DISPLAY DAP FOLLOWING ATTITUDE ERRORS)

Now the DAP should enable you to steer the LM. !!!Please steer slowly to avoid that the simulation gets overloaded!!!
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.

2006-02-26

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.

2006-01-10

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.

2006-01-09

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

2005-12-24

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.

2005-11-06

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.

2005-10-29

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.

2005-10-17

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.

2005-10-05

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.

2005-10-04

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.

2005-10-03

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.

2005-09-25

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.

2005-09-20

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

2005-09-14

yaACA and LM_Simulator: The sign of yaw has been reversed, thanks to Stephan's feedback.

2005-09-09

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.

2005-08-28

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.

2005-08-23

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

2005-08-22

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

2005-08-21

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.

2005-08-20

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.

2005-08-17

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.

2005-08-15

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.

2005-08-14

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.

2005-08-13

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

2005-08-06

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.

2005-08-04

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.

2005-08-02

yaAGS: Courtesy of Jordan Slott, yaAGS again has a working --debug mode, and the command-history support in it seems to work perfectly.

2005-08-01

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.

With readline support enabled, hitting ENTER no longer interrupted execution of the AGC program. This has been fixed.
Repaired some spurious printing of prompts during AGC program execution.
"Break" was no longer working. This is now fixed. [That was my fault, not Jordan's --- RSB.]
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.)
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.)

2005-07-31

yaAGC: Jordan has added some further frills to the --debug mode. Here are the notes on the changes:

Added the "files <regex>" debugging command. This lists the source files matching the given regular expression.
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.
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.
Fixed a small bug in "list from,to" where the line numbers were not being displayed.
Cleaned up some of my old code in symbol_table.c
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.

2005-07-30

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.

2005-07-28

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

2005-07-19

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

2005-07-17

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

2005-07-16

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.

2005-07-13

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.

2005-07-11

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.

2005-07-10

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!*

2005-07-09

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.

2005-07-07

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.

2005-07-06

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.

2005-07-05

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.

2005-07-04

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.

2005-07-03

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

2005-07-02

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

2005-07-01

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.

2005-06-30

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.

2005-06-29

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.

2005-06-28

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

2005-06-27

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

2005-06-26

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.

2005-06-25

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.

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

2005-06-24

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.

2005-06-23

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

2005-06-19

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

2005-06-17

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

2005-06-16

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

2005-06-15

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)

2005-06-14

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.

2005-06-12

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.

2005-06-11

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

2005-06-09

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.

2005-06-08

"Finished" coding yaAGS. It doesn't work, of course. I'll start figuring out why tomorrow.

2005-06-07

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:

Fixes:

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.

2005-06-06

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.

2005-06-05

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.

2005-06-04

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.

2005-06-03

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.

2005-06-02

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.

2005-05-31

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.

2005-05-30

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.

2005-05-29

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.

2005-05-28

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!

2005-05-26

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.

2005-05-24

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.

2005-05-23

Minor corrections on developer and language-manual pages. And a few additions to the faq page.

2005-05-21

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