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

Downloading
and building the software
(This page is now obsolete)
FAQ
yaAGC
yaYUL
yaDSKY
yaOtherStuff
Luminary
Colossus
Language Manual
Physical Implementations

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

This is an unmaintained, obsoleted page, archived for legacy purposes only to provide information on some older Virtual AGC releases.  For information pertinent to current releases, please look on the current download page.

Contents


What's In a Full Download?

Directory
 Contents
 Status
yaAGC/Colossus249/
 Source code (*.s) for Build 249 of the Colossus (AGC Command Module) program.
 100% complete, and debugged.  (The comments in the source-code still need proofing, but the program assembles correctly with the yaYUL assembler.)
Binary (*.bin and *.binsource) image of the core-rope for Build 249 of Colossus. 100% complete, proofed, and known to be valid.
yaAGC/Luminary131/
 Source code (*.s) for Build 131 of the Luminary (AGC Lunar Module) program.
 100% complete, and debugged.  (The comments in the source-code still need proofing, but the program assembles correctly with the yaYUL assembler.)
Binary (*.bin and *.binsource) image of the core-rope for Build 131 of Luminary. 100% complete, proofed, and known to be valid. 
Some utilities.
  • Oct2Bin --- converts a set of Luminary/Colossus binaries given in the form of an ASCII file to a core-rope binary.  This is 100% working.  Needed only for validating data entry for programs like Luminary or Colossus.
  • CheckDec --- allows interactive entry of decimal numbers (suitable for DEC/2DEC pseudo-ops), and immediate viewing of their binary forms.  This is 100% working.  Needed only for experimenting with the binary formats the AGC uses for storing numbers.
  • webb2burkey-rope --- converts the core-rope files used in Virtual AGC to the format used by Julian Webb's AGC simulator, and vice-versa.  This is 100% working, but since few of you have Webb's simulator, the point is moot.
yaAGC/Artemis072/
 Source code (*.s) for Build 072 of the Artemis or Colossus 3 (AGC Command Module) program. About 6 pages (out of >1500) available.
Binary (*.bin and *.binsource) image  for Build 072 of  Artemis or Colossus 3. 100% complete and proofed.  I assume it's correct, but we won't really know until there's source code to cross-check it against.
yaAGC/yaAGC/
 Source code for the yaAGC (AGC emulator) program.
 99% complete.  At present, you can expect to see do the stuff described in the Quick Start section of my home page.  Both the LM and CM sims should work quite well.
yaAGC/ControlPulseSim
 An emulator for the AGC at the "control-pulse" (microcode) level rather than the instruction level.
 Allows interactive simulation of some (but not all) control-pulse sequences (microcode) for the AGC.  This program is only for the very brave, and very little of it works.  I'll probably never complete much more of it.
yaAGC/yaDSKY/
 Source code for the yaDSKY (DSKY emulator) program.
 99% complete (both Linux and Win32).  (The STBY and RESTART indicator lamps are inoperable.)  In addition to being a DSKY simulation, this program can print out downlinked telemetry data.
yaAGC/yaUniverse/
 Source code for the yaUniverse (spacecraft motion emulator) program.
Is now capable of modeling the motion of heavenly bodies and spacecraft under gravitational influences.  This, perhaps, 25% of what's required in the full program.
yaAGC/yaIMU/
 Source code for the yaIMU (inertial measurement unit emulator) program. This program has not yet been started.  (Because of Stephan Hotto's contributed LM_Simulator program, the yaIMU program is no longer needed, and therefore is no longer being planned.)
yaAGC/yaAOT/
 Source code for the yaAOT (alignment optical telescope emulator) program. This program has not yet been started.
yaAGC/yaACA/
 Source code for the yaACA (attitude controller assembly emulator) program. This program is 100% complete and seems fine on a standalone basis, but the complete system environment for it has not yet been demonstrated to work.
yaAGC/yaTelemetry/
 Source code for the yaTelemetry (telemetry-downlink console) program.
 This program has not yet been started.  (In its absence, yaDSKY is capable of printing out digital-downlink data, though not in a particularly attractive manner, with the "--test-downlink" command-line switch.)
yaAGC/yaYUL/
 Source code for the yaYUL (AGC cross-assembler) program.
 100% complete, and capable of assembling Luminary131, Colossus249, or Validation source code without error.
yaAGC/Validation/
 Source code for a (newly-written) program in AGC assembly-langauge that is used to test the emulator's instruction set.
 About as complete as it's going to get!
yaAGC/yaAGS/
 Source code for the yaAGS (Abort Guidance System emulator) program.
 Now working.  Probably there are a number of bugs and unimplemented features, but at least it can pass the built-in self-test, and can perform the few operations I personally know how to activate.  :-)
yaAGC/yaDEDA/
 Source code for the yaDEDA (emulator for the Data Entry and Display  Assembly -- i.e., the AGS user interface) program
 I think this program is 100% working, though I've only tested it with yaAGC (since yaAGS isn't available yet), so I can't be perfectly sure.
yaAGC/yaLEMAP/
 Source code for the yaLEMAP (AGS cross-assembler) program.
 I think this program is 100% working, though there could be bugs I'm not aware of.
Sample AGS source code.
 100% complete and correct.
Utilities
 binLEMAP --- like Oct2Bin, but for the AGS instead of the AGC.  100% working.  Needed only for validating source-code data entry for programs like AGS FP6 or FP8.
yaAGC/FP6/
 Source code (*.s) and binary (*.bin and *.binsource) for AGS FP6 (Flight Program 6)
 It is believed that the source code is 100% complete and correct, and that the binary produced by assembling the source with yaLEMAP is 100% complete and correct.
yaAGC/FP8/
 Source code (*.s) and binary for AGS FP8 (Flight Program 8)
 It is believed that the source code is 100% complete and correct, and that the binary produced by assembling the source with yaLEMAP is 100% complete and correct.
yaAGC/Contributed/LM_Simulator
 Tcl/Tk source code, contributed by Stephan Hotto.
 Continually evolving in its conception, and I'm not the author, so I can't give a percentage of completion.  At present, the program has the following features:
  • An operational IMU.
  • An operational FDA ball.
  • An operational "DSKY Lite" (an alternate DSKY simulation), for use on target computer platforms where yaDSKY cannot be built.
  • An operational i/o-channel monitor

Downloads

Download file
 What is it?
 Who needs it?
yaAGC-dev-20090301.tar.bz2

Note:  To take full advantage of pad loads provided by LM_Simulator, I'd suggest copying the file yaAGC / Contributed / LM_Simulator / LM.core to the directory from which you invoke the simulator.

Full development snapshot, containing all of the stuff mentioned above, to the extent described above.  Refer also to the change log.

Note:  If you already have Virtual AGC working on your computer and simply wish to install the Artemis 072 (Colossus 3) program, expand the tarball and copy the SimArtemis* and Artemis072/Artemis072.bin files to your installation directory.  (You might also need to change the file attributes of SimArtemis072 and SimArtemis072_lite to make them executable.)
  • Everybody who wants the Virtual AGC source code, AGC Colossus source code, AGC Luminary source code, or AGS flight-program source code not included in the Linux, Windows, and Mac OS X binary packages.
  • Everybody who needs to build Virtual AGC from source because binary packages for them aren't provided here, such as *BSD users, PPC Linux users, Solaris users, ....
  • Linux users who need to build from source because the binary package doesn't work for them.
  • Windows users who need to build from source because the binary package doesn't work for them.
  • Mac OS X users who need to build from source because the binary package doesn't work for them.
  • ... Oh, heck!  Just everybody!
yaAGC-linux-20050720.tar.bz2 Pre-built Virtual AGC executables for x86 Linux.
  • x86 Linux users who don't want to build Virtual AGC from source, and thus want to just install the binaries.
LM_StandAlone_210407a.zip
 Pre-built Virtual AGC executables for MS Windows, packaged by Stephan Hotto.
  • Windows users who don't want to build Virtual AGC from source, and thus want to just install the binaries.  (But see the next item.)
yaAGC-Win32-20050720.zip Pre-built Virtual AGC executables for MS Windows, packaged by Ron Burkey.
  • Windows users who don't want to build Virtual AGC from source, and thus want to just install the binaries.  Hey!  Isn't this just like the line above?!!!  Sort of ....  There are two different packagings of the Windows binaries.  My packaging (this line!) gives you everything and may run a little more efficiently, but may be a little harder to install; it's targeted at enthusiasts.  Stephan's (the line above) is more selective about what it provides, and may be a little easier to install; it's probably the better choice if you just want to quickly try out the simulation without getting too involved in it.  Also, you may want to see which one is more current.
runtime-package zipfile Runtime package needed for running the Ron's pre-built Windows executables.  Not needed for Stephan's executables.
yaAGC-macosx-20050720.tar.bz2
 Pre-built Virtual AGC executables for Mac OS X.
  • Mac OS X users who don't want to build Virtual AGC from source.  Note that this will be nothing like any Mac OS X package you've ever seen, so you will have to follow the instructions.
Archive Earlier versions of the downloadable files.
  • ... Probably nobody.


Extras!

Onno Hommes has sent us some configuration files for adding AGC-specific syntax-highlighting for the following source-code editors:  Kate, KWrite, Kdevelop, Eclipse, vim, TextPad, and (maybe) emacs.  Onno's zipfile contains all of the configuration files, along with instructions (in PDF form) for using them.

Here's a nice screenshot (click to enlarge) of what source highlighting looks like in Kdevelop.  As you can see, it's a lot more pleasant to read the AGC source code with the highlighting than without it.
Screenshot of source highlighting in KDevelop

Installing the Windows Binaries, the Stephan Way

(This is the installation procedure for LM_StandAlone_version.zip.)

Choose some folder on your Windows computer, and unzip LM_StandAlone_version.zip into it.  Now you're finished with the installation!

Inside the installtion directory, you'll find a program called "lm_simulator.exe".   (You might want to create an icon on your desktop for it.)  Run and enjoy!

Installing the Windows Binaries, the Ron Way

(This is the installation procedure for yaAGC-Win32-date.zip and the runtime-package zipfile.)

For Win32 users, it's much more work to get your computer set up to build Virtual AGC than it is in Linux, and the steps needed will be less familiar.  Therefore, most of you will feel inclined to simply install the Virtual AGC programs rather than compiling them from scratch.  On the other hand, if you are already a software developer using MinGW, you will probably want to build the software rather than installing the binaries, to avoid gumming up your \mingw directory.

Note:  Since it's inconvenient for me to build the Win32 packages, they may not be as current as the development snapshot.
  1. Download the runtime package (see above).  Extract its contents into your c:\ directory.  You only need to download and install this once.
  2. Download the  latest zipfile of Virtual AGC Win32 executables.  Extract its contents into your c:\ directory.
  3. Add the directory c:\mingw\bin (created by steps 1 & 2 above) to your PATH.  Note that yaDSKY will not work if you copy the files to a directory other than c:\mingw\bin.
  4. Optional:  The steps above give you Luminary and Colossus core-rope images, needed to run the simulation, but do not include source code for Luminary or Colossus, nor source code for yaAGC, yaDSKY, or yaYUL.  If you want those things, you'll have to download the full development snapshot also.  (To extract the contents of the downloaded archive, you'll need the programs tar and bzip2, which most Win32 users will not have pre-installed.   You can download versions of these programs for Win32 from the following links:  bzip2 or tar.)  The contents of the archive can then be extracted by the command-line steps, which will create a directory called yaAGC.
bunzip2 yaAGC-dev-RevisionDate.tar.bz2
tar -xf yaAGC-dev-RevisionDate.tar
  1. Optional:  If you want to run Stephan Hotto's contributed LM_Simulator software (and you probably do!), you'll have to install Tcl/Tk for it to work.

Installing the Linux Binaries

Disclaimer:  I don't really know how to package programs for installation on Linux, so these binaries may not work on your system.  (I think they work on SuSE 9.0 & 9.1, Ubuntu 5.04, RedHat 7.3, and Fedora Core 1.)  Hopefully they will work for you; if not, you may still need to end up building Virtual AGC yourself, as described below.

Prerequisites:  libgtk 2.0 or higher; also, Tcl/Tk if you want to run the LM_Simulator program.  I am not sure what version of Tcl/Tk is needed, but I've noticed that v8.4.4 works fine, whereas v8.3.3 (RedHat 7.3) aborts on trying to open the FDAI ball window.

Installation:
  tar --directory=/ --bzip2 -xf yaAGC-linux-RevisionCode.tar.bz2
tar --bzip2 -xf yaAGC-dev-RevisionCode.tar.bz2
Uninstallation:  Just remove the /usr/local/yaAGC directory containing the binaries, and the yaAGC directory containing the sources.

Building the Virtual AGC software, in Linux

Disclaimer:  On a number of Linux platforms, I've had no problem at all building the Virtual AGC suite.  (These include SuSE 9.0-10.0, RedHat 7.3, and Ubuntu 5.04.)  But on some, it's much trickier.  In cases like that, I'd suggest trying to install the binaries (see above) rather than building from source.

Prerequisites:  gcc, pkg-config, autoconf, automake, glib-dev, libgtk, libgtk-dev 2.0 or higher, readline-devel, either curses or ncurses, and the Allegro cross-platform GUI kit.

To unpack the tarball, you work from a command-line prompt.  The development-snapshot tarball, for example, is unpacked as follows:

tar --bzip2 -xf yaAGC-dev-RevisionCode.tar.bz2

After unpacking there will be a new directory called "yaAGC", with the contents listed in the preceding section.   To build the programs,

cd yaAGC
./configure
make clean
make
sudo make install

As shown above, installation will be made to the /usr/local directory, and the executables will go into /usr/local/bin.  If you would prefer to  do an installation to some other directory, perhaps to avoid needing root access, then  instead of using the command "./configure", use the command "./configure --prefix=InstallDirectory".  (This option is present only in software versions 05/14/04 and later.)  If you use this option, you will also want to add the directory InstallDirectory/bin to your PATH environment variable.

Important Note
Do not run the uninstallation script mentioned in the struck-out section following this note, since if you have installed into /usr/local (or worse, /usr) it will delete /usr/local/bin (or /usr/bin)! Thanks to Onno Hommes for catching this error.


For versions 2006-02-26 and later, 'make install' builds a script called VirtualAgcUninstall, which you can use to uninstall Virtual AGC later, if you so choose:

sudo VirtualAgcUninstall

This is principally useful, I expect, if you decide to change the installation directory after already having installed the program.  I guess I should point out that VirtualAgcUninstall is slightly dangerous on a true multi-user system, because it will uninstall not only Virtual AGC, but also any other programs that happened to be placed in the installation directory at the exact moment 'make install' occurred.  But if your system is a true multi-user system, I expect you'd not want to install Virtual AGC into /usr/local anyway.

Some trouble-shooting notes ...

  • If you get a message to the effect libcurses.a is not found, it points to a naming discrepancy between the curses library (which is what we'd like to have installed) and the ncurses library (which is probably what is actually installed).  In that case, locate the file libncurses.a (usually, in /usr/lib) and do this before running make again:
sudo ln --symbolic /usr/lib/libncurses.a /usr/lib/libcurses.a
  • As mentioned above, you will need to have gtk+ (plus the gtk+ development package) installed on your computer for this to work.  (Presently, I'm using gtk+ version 2.2.x.)  Unfortunately, the names of the packages you need to install will differ by Linux distribution, unless you choose to install gtk+ from source (in which case no separate "dev" package is needed).  They may be something like "gtk2" and "gtk2-dev", or "gtk+2" and "gtk+2-dev", or even (I'm told) something as obscure as "libgtk+2.0_0-devel".  For some reason, on my computer, the environment variable PKG_CONFIG_PATH needed for the "configure" step is not set properly by the  installation of gtk+.  If you encounter this problem, the "configure" step will display instructions as to how it may be easily fixed.  If you don't get a message, you probably don't need to worry about it. 
  • It may be that you just can't build the software, no matter how hard you try.  In almost all cases, the reason for this will be a problem in configuration of gtk+, and that all of the programs will build fine except for yaDSKY and yaDEDA.  In this case, as a last resort, you can use the following alternate build instructions:
cd yaAGC
make NOGUI=yes autogen
[or  make NOGUI=yes PREFIX=InstallDirectory autogen]
make NOGUI=yes clean
make NOGUI=yes
sudo make NUGUI=yes install

Instead of running "SimLuminary131", "SimColossus249", or "SimArtemis072", run "SimLuminary131_lite", "SimColossus249_lite", or "SimArtemis072_lite".  What these steps will do for you is to bypass building yaDSKY and yaDEDA, and to use instead the "DSKY Lite" module of the LM_Simulator program (which doesn't need to be compiled).
  • Other trouble-shooting info may be found in the FAQ.

Running the Validation Suite

Having built the software as above, you can test the emulated CPU using the "validation suite":
  1. Run SimValidation.
  2. A code of "00" will appear in the MODE area of the DSKY, and the OPR ERR lamp will light.  This means that the validation program is ready to start.
  3. Press the PRO key on the DSKY.  The OPR ERR light will go off and the validation program will begin.
  4. If all tests are passed, then the MODE area on the DSKY will show the code "77", and the OPR ERR lamp will light.  This will take about 50 seconds.
  5. If some tests fail, an error code other than "00" or "77" will be displayed in the MODE area on the DSKY, and the OPR ERR lamp will light.
  6. In the latter case, you can proceed from one test to the next by pressing the PRO key.  The meanings of the error codes are determined by reading the file Validation/Validation.s.
If this doesn't work for some reason, refer to the trouble-shooting info in the FAQ.

Building the Virtual AGC software, in Windows

Note:  I don't use Windows myself, if I can help it, and so will have no great enthusiasm for helping you if you have trouble with the Windows version of the simulation.  With that said, I am at this instant (07/17/04, 09:43 am.) watching four separate LM simulations, including a Win32 DSKY attached to a Win32 AGC, a Win32 DSKY attached to a Linux AGC, a Linux DSKY attached to a Win32 AGC, and a Linux DSKY attached to a Linux AGC.  They all seem to be working properly.

Before doing anything else, install the MinGW C-language compiler and the gtk+ toolkit on your computer.  The makefiles provided in the tarball assume that you have done this in exactly the way I prescribe, though possibly with different versions of some software packages, and may not work if MinGW and/or gtk+ have been installed slightly differently.  Those of you who know about such things may wonder if it wouldn't be easier to build Virtual AGC using Cygwin.  The answer is that I think it would be preferable, but I haven't been able to get it to work.  (Anybody who figures it out should let me know how you did it.)

If you want to build yaACA, you'll need the Allegro cross-platform GUI kit.  If you don't want to bother with yaACA, you don't have to.  The build-process (below) will display warnings, but won't abort.  However, yaACA gives you the ability to use the rotational hand controller (RHC) in the LM, and that substantially adds to the fun-factor of using the simulation.

One result of following the installation instructions is that an icon for Msys should now appear on your desktop.  Msys is a command-line environment which is similar to the command-line environment found in Linux.  It is not needed for running any of the Virtual AGC programs you'll be creating, but you will work within the Msys enviroment when building the programs.  Therefore, the first step is to click the Msys icon and enter the Msys command-line environment.

For versions 20040810 or later, you will also need to install POSIX Threads for Win32.  While I can't guarantee that the folks who develop that software won't change their installation procedure, as of 20040814 this is what worked for me:
cd pthreads
make
cp -a pthreadGC*.dll c:/mingw/bin
cp -a *.h c:/mingw/include
cp -a *.a c:/mingw/lib
Next, you need a way of getting the source-code tarball into the Msys environment.  The MinGW/gtk+ installation instructions give some hints as to how to do that.  Once you've done that, perform the following steps:

tar --bzip2 -xf yaAGC-dev-RevisionCode.tar.bz2
cd yaAGC
make install

(If you are using Virtual AGC versions prior to 20040810, you'll need "make -f Makefile.Win32 clean install" instead.)  Assuming the steps above were successful, you are now done with the Msys environment, and may exit it simply by using the command "exit".

The net result of this is that the Virtual AGC executable programs will now appear in the c:\mingw\bin directory, which you should add to your PATH.

Finally, if you want to run Stephan Hotto's contributed LM_Simulator software (and you probably do!), you'll have to install Tcl/Tk for it to work.  I'd strongly suggest doing this.

It may be that you just can't build the software, no matter how hard you try.  In almost all cases, the reason for this will be a problem in configuration of gtk+ (with which I'll probably be unable to help), and that all of the programs will build fine except for yaDSKY and yaDEDA.  In this case, as a last resort, you can do the following:
  1. Instead of "make install", do "make NOGUI=yes install".
  2. Instead of running "SimLuminary131", "SimColossus249", or "SimArtemis072", run "SimLuminary131_lite", "SimColossus249_lite", or "SimArtemis072_lite".
What these steps will do for you is to bypass building yaDSKY and yaDEDA, and to use instead the "DSKY Lite" module of the LM_Simulator program (which doesn't need to be compiled).

What about building Virtual AGC in FreeBSD, NetBSD, or OpenBSD?

In FreeBSD, NetBSD, or OpenBSD, I expect compilation to be pretty much as in Linux, but perhaps with various cleanups.  For example, I expect that the makefiles will have to be modified to use gmake rather than make.  I have not tried it, however, and if anyone wants to send me info on doing it, I'd be happy to make any required changes or to post the results on this page.

Installing and/or building Virtual AGC in Mac OS X (10.2)

Disclaimer:  Mac OS X is not my bag.  If this works, you'll be lucky.  (But it does work for me.)  My system is an iMac with Mac OS X 10.2.8.  The instructions below are relatively new; if you want to see the old instructions, look here.

Prerequisites:
  1. Please install Apple's "developer tools", from the CD that came with MacOS X.  If your version of the gcc program is 3.1 or prior, there is an upgrade to gcc 3.3 which you'll want to download from Apple and install.  (You can tell by running the command "gcc -v" from the command line interface to view the version number.)  Unfortunately, you'll have to sign up as an Apple developer (which is free) in order to download it.  What you're looking for is a "gcc updater", of which there are several (depending on your version of MacOS X), so I can't really advise you as to which of them needs to be downloaded.
  2. Please install fink, which is a program that is used to install other programs.  Make sure that you choose the version of fink that works with your version of Mac OS X, and follow the instructions on the fink webpage.  There is a graphical front end for fink called Fink Commander, which you'll have to manually drag onto your desktop, as it is not automatically installed by the installer program. 
  3. Run Fink Commander.  From the main menu, do FinkCommander/Preferences, and click the tab that says Fink.  Activate "Use unstable packages".
  4. Running Virtual AGC will require the X-window system (also known as "xdarwin", "xfree86", "xorg", or "X11").  If you already have this installed and are satisfied with it, you probably should ignore this step.  However, what I did to install the X-window system is this:  with Fink Commander, install the binary packages (rather than the source packages) for "xfree86" and "icewm-basic".  After Fink Commander finishes its business, create a text file called ".xinitrc" in your home directory which contains a single line reading "exec /sw/bin/icewm".
  5. With Fink Commander, install the binary packages (rather than the source packages) for the following programs:  "automake", "tcltk", "cvs", "readline", and "readline-shlibs".
  6. With Fink Commander, install the source package "gtk+2-dev".  This will probably take quite a long time, but (as of this writing) the much-quicker-installing binary package for gtk+2-dev provided by fink is not up-to-date enough to build Virtual AGC.   You may be presented with the choice between "pango1-xft1" and "pango1-xft2"; choose "pango1-xft2".
  7. Install the Allegro cross-platform GUI kit.  This can't be done at present from fink.  If you're only going to try installing the Virtual AGC binary package, you might try simply downloading the Allegro runtime library dmg file and installing it.  (But I should tell you I haven't tried it, and have no way at present to try it.  Let me know if it works for you.)  What I do instead is build Allegro from source.   Building Allegro is a tricky proposition, since the current version (as of 4.2.0 beta, when I'm writing this) does not seem to work correctly on Mac OS X ... or at least not on my version of Mac OS X.  So here's what I did, and hopefully it will work for you.  From a command line, use the following commands (just hitting ENTER when prompted for a password):
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alleg login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alleg co -r v4-1-18 allegro
cd allegro
mkdir obj/macosx/alleg/macosx
sh fix.sh macosx
make
sudo make install

For me, 'make' ends up with what appears to be an error message "no macro name given in #define directive", but 'sudo make install' is still able to install it, and it seems to work well enough for my purposes.

Try to install the Virtual AGC binary package:

(Note that I personally have no way to test this, but I've had some reports that it works.)

From a command-line, do the following, assuming that you've downloaded both the Virtual AGC binary package (yaAGC-macosx-RevisionCode.tar.bz2) and developer snapshot.

cd Desktop
sudo tar --directory=/ --bzip2 -xf yaAGC-macosx-RevisionCode.tar.bz2
tar --bzip2 -xf yaAGC-dev-RevisionCode.tar.bz2

Running the program is a little more complex than you're used to:
set path = ($path /usr/local/yaAGC/bin)
SimLuminary131 --half-size
If this didn't work properly, you may need to build Virtual AGC from source.

Trying to build Virtual AGC from source:

If you are unable to get the binary package to work, but have followed the steps above, you can try to build Virtual AGC from source.  Just do this from a command-line:

cd yaAGC
./configure --prefix=/sw
make
sudo make install

When you try to run the simulation, you do the same thing as instructed above (for the binary installation), but you don't need the "set path ..." command.

Bypassing compilation of yaDSKY:

One of the main difficulties that people seem to have in building Virtual AGC is the yaDSKY and yaDEDA applications.  It's possible to do without yaDSKY by using the "DSKY Lite" built into the LM_Simulator program.  (Sadly, there's no substitute at present for yaDEDA, but yaDEDA isn't as important to most people as yaDSKY.)  So modify the steps listed above as follows:
  1. Instead of "./configure --prefix=/sw", do "make NOGUI=yes PREFIX=/sw autogen".
  2. Instead of "make", do "make NOGUI=yes".
  3. Instead of "sudo make install", do "sudo make NOGUI=yes install".
  4. Instead of running SimLuminary131, SimColossus249, or SimArtemis072, run SimLuminary131_lite, SimColossus249_lite, or SimArtemis072_lite.
If all else fails:

Look here for the way I used to advise doing all this.

Uninstalling:

If you installed the binary package, you can uninstall just removing the directories that were created:

sudo rm -rf /usr/local/yaAGC
rm -rf yaAGC
Use Fink Commander to uninstall the prerequisites I asked you to install.

If you built from source, there's no good way to uninstall, aside from just figuring out all the files that were created, and deleting them.  I don't have a comprehensive list of files in Virtual AGC at the moment.  However, you're only talking a few megabytes, so it usually won't be a problem just to let the files alone.

Installing Virtual AGC Binaries in Mac OS X (10.4)

Disclaimer:   I used to explain how to install Virtual AGC binaries in Mac OS X, as well as how to build from source (see above).  However, it was almost as hard as building from source, so I eventually removed the instructions.  I'm told that it has become relatively easy in Mac OS X 10.4, so we have some new instructions thanks to Fabrizio Bernardini.  I haven't any way to try them myself, but Fabrizio knows what he's doing.  I've cut-and-pasted directly from his email.

Thanks to the availability of a brand new PowerBook I had to reload yaAGC and its stuff once more.

And thanks to the outstanding quality of the overall system provided by Apple (sorry for the ad, but it changes your life) installing the binaries is now simpler than currently cited in the download page.

Here are the steps I performed:

Initial conditions: MacOS Tiger 10.4.3 installed and configured as it is out of the box.

1. Run the Dev Tools installer situated in /Applications/Installers (if you are reading these you probably already performed that).

2. Install X11 from the Options package available in the MacOS Tiger Installation Disc. When you double-click the installer a selection window will open: everything should already been installed but X11, check it and go ahead.

3. Check that X11 works by double-clicking on the X11 icon now available in /Applications/Utilities.

4. Download from //fink.sourceforge.net/ the lates stable relase of fink. I got version 0.8.0 released on 09 June 2005.

5. Install fink double-clicking its installer package from the disk image (.dmg) file downlaoded. Let it create the /sw directory. Installing FinkCommander is an option, not required if you need fink for yaAGC only, or install it later.

6. Open a terminal shell and run the following fink request:

	$ fink install gtk+2

Running this command requires the computer to be connected to the Internet. Let it run and say Yes to requests.

7. Install yaAGC binaries in /usr/local

8. Upon successful completion of the above steps, starts X11 and:

	a. Open a term shell
	b. $ cd /usr/local/yaAGC/bin
	c. $ ./yaAGC --core=Luminary131.bin --port=19797 --cfg=LM.ini
	d. Open another term shell
	e. $ cd /usr/local/yaAGC/bin
	f. $ ./yadsky --half-size --cfg=LM.ini --port=19797

   and everything runs !

9. Bonus step: now the TCL/TK toolkit is included in the developer tools so it is already installed and if you wish you can open another term shell and run also LM_Simulator with no troubles !

Conclusions: MacOS is demonstrating itself as one of the best developing platforms ever conceived out of a box. Please note that only the gtk libraries where required in addition to the dev tools add ons.

I will perform the same procedures also on a iMac and will report the results soon.

Now is anybody so lucky to be able to try the same on an Intel iMac with Tiger 10.4.4 ?

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

Virtual AGC is hosted by ibiblio.org