Contents

• Introduction
• Downloading, Running, or Updating Virtual AGC in VirtualBox
• Characteristics of the Virtual AGC VM
• Installation of the Virtual AGC VM
• Updating the Virtual AGC VM
• Platforms Directly Supported by Virtual AGC Installers
• Virtual AGC Installer for Raspberry Pi (Raspbian)
• Installer for Ubuntu 14.04 32-bit 'x86 Linux
  
• Installer for Windows
  
• Downloading and Building Virtual AGC from Source
• Limitation
• Getting the Source Code
• CMake-Based Builds
  
• Linux
• Raspberry Pi (Raspbian)
• FreeBSD
• Solaris
• Mac OS X
• Older Macs: Xcode with gcc
• Newer Macs: Xcode with clang
  
• Windows
• WebAssembly
  
• iPhone
• Running the Validation Suite of the Simulated AGC
• Some Resource Issues on Slower Computers, Such as Raspberry Pi
  

Introduction

This page covers various ways to download and/or install Virtual AGC project software.  Three methods are currently recommended, and a fourth is possible if not really recommended:

1. If you simply wish to run one of the provided AGC or AEA simulations, examine the AGC or AEA program code, and/or do visual debugging of (Block II) AGC code, then the easiest thing to do is to download and run the provided VirtualBox virtual machine.  The VM is guaranteed to work properly on any 32-bit or 64-bit 'x86 platform for which VirtualBox is available, namely Windows, Mac, Linux, and Solaris, and (according to this page) FreeBSD as well even though the latter is not obvious from the VirtualBox website.
   
2. If you just happen to have a computer system which is currently supported by an installation package, then you can simply download and install the proper installation package.  At present, however, these platforms are only the following:
1. Raspberry Pi
2. Ubuntu 14.04 32-bit 'x86.
3. Windows.
   
3. If you wish to do not only the above, but also wish to delve more deeply into the Virtual AGC project code (as opposed to just the AGC/AEA code), then you should instead download the Virtual AGC source code, and perhaps build it yourself.  This works on many more platforms, though is more-involved to set up, and visual AGC debugging may not be possible easily on platforms other than 'x86 Windows, Mac, or Linux.
   
4. If you are satisfied with older versions of Virtual AGC, many additional computer platforms were once directly supported with installer programs, which you can still find here or here.  Ideally, we would like to directly support all major platforms with Virtual AGC installer programs, but in practice it is far too hard to do so with the resources available at present, so this is no longer being done currently.

Note that a lot of detail about known quirks on different platforms, and about trouble-shooting, can be found at the older links listed in approach #4 above, but isn't found on the present page.  That's because the information hasn't been updated in so long that its reliability is dubious, and because many of the platforms mentioned there are long-obsolete.  It should also be noted that the build-instructions for some platforms presented here are similarly out-of-date and may need corrections.

Downloading, Running, or Updating Virtual AGC in VirtualBox

Characteristics of the Virtual AGC VM

My descriptions in this section relate to the 2017-04-20 version of both the VM and the VirtualAGC software, so other versions may be slightly different ... but this still gives the general idea.

The virtual-machine approach should work with any host system supported by VirtualBox:  namely, any 32-bit or 64-bit 'x86 version of Windows, Mac, Linux, Solaris, or FreeBSD.  The VM is nice because it lets you work with the most-commonly-desired elements of Virtual AGC, while skipping past the most-annoying and tricky setup steps, such as compiling Virtual AGC's source code.  It provides you with a "virtual machine", with Virtual AGC and other things you need in order to be able to work with Virtual AGC already pre-installed and pre-configured.  Though like anything else done to make our lives "simpler", it brings its own (hopefully smaller!) set of problems with it.

When the VM is run, the first thing you see is the VirtualAGC GUI, from which you can run an AGC simulation using various selectable options.  There are actually two different versions, and which you'll see depends on how large your (virtual) display screen is:  For screens smaller than 1200×1024 you'll get the interface below left, whereas for larger screens you'll get the one below right.  Unfortunately, they don't resize if you resize your virtual display screen, in which case you may simply need to exit from the program and restart it.  The two interfaces have exactly the same capabilities, except the smaller, left-hand one doesn't allow you to run "custom" AGC-software versions:

You can do a number of things from this VirtualAGC GUI, such as run the simulation (below left) or browse nicely syntax-highlighted AGC source code (below right):

If you exit from the VirtualAGC GUI, you'll see the VM's bare desktop, on which a number of other useful options appear:

• "AGC Simulator" lets you rerun the VirtualAGC GUI if you've exited from it.
• "GitHub Repo" lets you browse our GitHub source-code repository.
• "Internet Archive" lets you browse our Internet Archive document collection.
• "Website" lets you browse our main website.
• (2017-04-20 or later.)  "Update VirtualAGC" lets you download and install the latest version of the VirtualAGC GUI program, and all of the associated simulation software, AGC code, AGS code, and so on.  Just double-click it, and then answer the prompt with either YES or NO.
  
• "AGC Visual Debugging" allows you to work with the AGC source code, and or run the AGC simulation, within a program called Code::Blocks.  The desktop icon is actually a folder containing separate launcher icons for most of the AGC software versions available to us.
  

Okay, enough of the sales pitch already!  What's do you actually have to do to install the thing?

Installation of the Virtual AGC VM

It's hard to pin down exactly what computer resources you'll need to run the VM.  The minimum is probably around 2 GB of RAM and 30GB of free disk space, but the more of everything you have, the better.  In particular, you will have a far more satisfactory experience if your CPU has VT-x (Intel) or AMD-V (AMD) extensions.  The VM itself requires only about 10GB of disk space, but in the process of decompressing the downloaded VM, you'll temporarily need a lot more (hence the 30GB mentioned).

Before doing anything with Virtual AGC as such, you should take care of the following:

• If VirtualBox is not already installed, download and install VirtualBox, using whatever version is suitable for your computer system.  The Virtual AGC virtual machine (VM) you will download was created with VirtualBox 4.3.40, but it should work with later versions as well.  If you have a different version, you may find yourself wanting to reinstall VirtualBox's "guest additions"; if you do, remember that the username and password are both "virtualagc".
  
• The VM is compressed in tar.xz form for downloading, so if your operating system doesn't already have software support for tar.xz archives, you need to install extra software that provides it.  In Linux, you're probably okay without doing anything, or at worst just using your distribution's software repository.  For other platforms, a little googling reveals that the program 7zip provides these formats for Windows, and there are "unofficial" installers for 7zip for Mac, Solaris, and FreeBSD.  However, various other programs work as well, I think, such as WinZip.

Then to actually install the VirtualAGC VM, you do the following.

1. Download the current compressed VM, as listed at the top of this page.
   
2. Uncompress it, resulting in a folder called "VirtualAGC-runtime".  (This may or may not be a 2-step process, in which a tar file is first created, which in turn would need to be expanded to get the mentioned folder.)  The tar.xz/tar file(s) are no longer used after that and may be deleted ... though obviously we'd prefer you retained it for a while to make sure you don't need to download it again if some mishap occurs.  VirtualBox tends to store all of its virtual machines in the same folder (on Linux, for example, that folder is "~/VirtualBox VMs"), so although it's not necessary to do so, you might want to move the VirtualAGC-runtime folder into the corresponding "VirtualBox VMs" folder on your computer.
3. In whatever file-system browser your computer has, descend into the VirtualAGC-runtime folder, and double-click the mouse on the file VirtualAGC-runtime.vbox.  This makes VirtualBox aware of your VM, and may or may not actually immediately run it.  At any rate, the VM will be visible in VirtualBox's manager program, and you can run it from there.

In its as-downloaded form, the VM is typically configured to use 1GB of RAM and 2 CPU cores.  You may be able dial these settings down in VirtualBox, but you may need to scale your expectations at the same time.

As I mentioned above, the username and password for the VM are both "virtualagc".  Since you are automatically logged in whenever you run the VM, you don't normally need this information, but it's good to know just in case (for example) you ever need to install some new, non-Virtual-AGC software on it, or perform some other administrative action.

Finally, technically, for any Linux pros, the VM does not have any swap space.  If that makes you uncomfortable, versions the VM from 2017-04-20 or later actually have an uncommitted 1GB partition on the virtual disk which you can assign as swap space if you want.  I normally don't to this because I don't think it's necessary, but mainly because filling that partition with a lot of random garbage just causes more hassle in trying to create a "small" downloadable image.

Updating the Virtual AGC VM

Because the VM is such a large download, you don't want to have to download it every time there's updated Virtual AGC software, and usually just want to update the VirtualAGC software within the VM.

For VM versions 2017-04-20 or later, this update process is really easy:  There's simply a desktop icon called "Update VirtualAGC" that you can double-click.  It will tell you what the latest VirtualAGC version is, and you can tell it either YES or NO.

For earlier VM versions, you can download a script that does the same thing.  Just put it somewhere (say in the "home" directory, /home/virtualagc/), and then from a command-line run the following command:

bash ./UpdateVirtualAGC

Platforms Directly Supported by Virtual AGC Installers

Virtual AGC Installer for Raspberry Pi (Raspbian)

1. Download the current Raspberry Pi installation tarball, as listed at the top of this page.
2. Unpack the installation tarball somewhere:  either "tar -xJvf VirtualAGC-Raspbian-VERSION.tar.xz" or "tar -xjvf VirtualAGC-Raspbian-VERSION.tar.bz2", depending on which type of installer is downloaded.  (Notice that these two commands are not the same, in that one has a 'j' where the other has a 'J'.)
   

sudo apt-get install libwxgtk2.8-0 libsdl libncurses5 liballegro4 tk

cd VirtualAGC/Resources
../bin/VirtualAGC

Installer for Ubuntu 14.04 32-bit 'x86 Linux

1. For a first-time installation only, you may have to install the following system libraries from the Ubuntu repository:  tk, libsdl1.2, libncurses5, liballegro4.4, libgtk2.0, libwxgtk2.8.
2. Another one-time step is downloading the update script, UpdateVirtualAGC.
3. Run the command "bash UpdateVirtualAGC".
4. If you try to use the ACA simulation (joystick) and it doesn't work, read about configuring it.
   

Installer for Windows

Installation is as follows:

1. Download the current Windows installation tarball, as listed at the top of this page.
2. Unpack the installation tarball somewhere:  I did this by using 7zip, but I believe there are a lot of other possibilities as well.  With 7zip, the unpacking was a two-step process, first to turn VirtualAGC-Windows-VERSION.tar.xz into VirtualAGC-Windows-VERSION.tar, and then to turn the latter file into the uncompressed folder VirtualAGC.  (At which point the tar.xz and tar files are no longer needed and can be deleted.)

1. Right-click on the desktop, and choose New/Shortcut in the pop-up menu that appears.
2. The popup window that appears will ask you for the location of the program you want to run.  It is C:\Users\YourNameHere\VirtualAGC\bin\VirtualAGC.exe.
3. After the shortcut has been created on the desktop, right-click it and select Properties.  Change the "Start in" or "Working directory" to be C:\Users\YourNameHere\VirtualAGC\Resources.
4. If you're really very keen on getting everything just so, that same Properties window from step 3 above also lets you change the icon displayed on the desktop.  It's entirely optional, but I'd suggest using C:\Users\YourNameHere\VirtualAGC\Resources\ApolloPatch2-transparent.ico.

1. C:   
2. cd C:\Users\YourNameHere\VirtualAGC\Resources
3. ..\bin\VirtualAGC

Downloading and Building Virtual AGC from Source

Limitation

Building Virtual AGC from source actually has a limitation compared to running the VM as described above, which is that while the VM is already set up for visual debugging of AGC code using Code::Blocks, this capability is not a part of Virtual AGC proper.  That is, Code::Blocks based AGC debugging has its own set of installations, requirements, and setups, distinct from those of building Virtual AGC proper ... which is what's discussed below.  If (once Virtual AGC is built and working satisfactorily) you want to do visual debugging, you need to install Code::Blocks and should consult the instructions for development using Code::Blocks on our GitHub wiki, as well as the instructions for visual debugging.

Of course, it also has the limitation that we can't actually deal with every platform people might try to use.  So I make a pretty strong effort to make sure it works on Ubuntu- and Debian-based 64-bit 'x86 Linux, which I use every day, and occasionally (rarely) try to check that the process still works on whatever versions of Raspberry Pi, Windows, Mac OS X, FreeBSD, and Solaris it happens to be convenient for me to run personally.

Getting the Source Code

The complete up-to-the-moment source code is available from GitHub.  There are several ways which one might choose to download it, such as in a zipfile or using the 'git' program, which in Linux (for example) would look like this:

git clone --depth 1 https://github.com/virtualagc/virtualagc

CMake-Based Builds

Because I am lazy, I prefer to develop software only with the tools I already know and understand.  Usually, roughly speaking, those end up being the minimalist tools that there's a fighting chance the majority of developers can also work with somewhat easily.  For better or worse, that's why all of the "official" build instructions for Virtual AGC on various target platforms in the following sections are based simply on 'make' (specifically, GNU 'make'), without the fancier kind of build environments that may be easier for the user but have a steeper learning curve for the developer.  For example, among the "fancy" build environments I'm referring to are those based on autoconf/automake or CMake, which many would prefer.  I myself might prefer them ... as a user rather than a maintainer!

However, not everyone is as lazy as I or philosophically inclined in quite the same way, so sometimes others step up to fill in the gaps I've left.  This is the case with CMake-based builds of Virtual AGC.  Michael Hirsch has stepped up to do so (thanks, Michael!), and if the "official" instructions below don't appeal to you, or if you simply like the idea of using CMake, Michael's documentation for the CMake-based build process can be found in our GitHub repository's wiki.

Since Michael maintains both that wiki page and the CMake process itself, please don't attempt to get any sensible response from me (RSB) if you encounter problems them or have questions.  You'll want to use our GitHub repository's issue system to report problems, or direct inquiries via the GitHub communication system to Michael's tag (@scivision).

Linux

This works! Last verified (Mint 21 Mate 64-bit): 2022-08-07 Last verified (Mint 20.1 Mate 64-bit): 2022-08-07 Last verified (Mint 19 Mate 64-bit): 2022-08-07 Last verified (Mint 17.3 Mate 64-bit): 2022-08-07 Last verified (Mint 17.3 Mate 64-bit, clang 3.9): 2022-08-07 Last verified (Mint 32-bit): 2019-09-22 Last verified (Fedora 26 64-bit): 2017-08-31 Last verified (Slackware 14.2): 2021-03-21 Last verified (Chromebook): 2021-03-21

• Linux Mint 17 ⟺ Ubuntu 14.04
• Linux Mint 18 ⟺ Ubuntu 16.04
• Linux Mint 19 ⟺ Ubuntu 18.04
• Linux Mint 20 ⟺ Ubuntu 20.04
• Linux Mint 21 ⟺ Ubuntu 22.04

One-Time Setup

Unfortunately, I cannot give you an exact list of package names even for my own distribution of choice.  They change over time!  So you'll have to take the following information only as suggestions.  If you find things you need to do differently, let me know and perhaps I can incorporate that info here.

• Ubuntu/Debian/Mint:  "sudo apt-get install libsdl1.2-dev libncurses5-dev liballegro4.4-dev g++ libgtk2.0-dev libwxgtk2.8-dev tcl tk".  But sometimes the package names needed are a little different:
• Could be liballegro4-dev
• Could be libwxgtk3.0-dev or libwxgtk3.0-gtk3-dev
  
• Note that using wxWidgets 3.2 should also be possible.  At the present writing, that would entail building wxWidgets from source.  You will definitely need the latest Virtual AGC source code.
  
• Versions of Linux I don't personally support, but about which I have learned possibly-helpful info:
• Chromebook:  mkdir ~/Desktop, and use the instructions above.  I'm not actually sure what range of Chromebooks can support a VirtualAGC installation, but some have Linux terminals built in and can do so.  Thanks to Nick Warne for pointing this out.
• Slackware 14.2:  Do library builds for wxGTK and allegro4; I am told that the default allegro (allegro5) does not set up directory links as expected by VirtualAGC, which is why allegro4 has to be chosen specifically.  (Thanks to Nick Warne for all Slackware info.)
  
• Fedora 26 64-bit Intel/AMD: "sudo yum install SDL-devel ncurses-devel allegro-devel gcc-c++ wxGTK3-devel redhat-rpm-config".  (Note that this uses wxGTK 3 rather than wxGTK 2.8 as I normally advise.  To instead use wxGTK 2.8, the makefiles for all of the graphical programs, such as yaDSKY2, yaDEDA2, VirtualAGC, and so on, have to be modified manually to add -fPIC to the compiler command lines.)

Building Virtual AGC Once the One-Time Setup Is Complete

By the way, it's preferable to build Virtual AGC on a clean Linux installation.  If (like me) you have a system that's used extensively for software development, you may have lots of stuff installed beyond what's mentioned above.  That extra stuff may cause you problems.  Hopefully that won't happen to most people, but I suspect that a higher percentage of folks interested in Virtual AGC would have this kind of problem than those picked at random from the general population.  For example, I have this problem myself on one system of the several I use.  This particular offending development system is a 64-bit Linux Mint 17.3 system, but with multiple versions of gcc, libstdc++, and wxGTK installed.  The resulting (unclean) system can build the Virtual AGC software fine, but not run it once built, because of a mismatch between the default versions of the compiler and the share libraries installed.  This isn't a problem with Virtual AGC as such, but is simply the result of not having a clean Linux installation in which everything is guaranteed to work with everything else.

One potential fix is to have a virtual machine with a clean Linux installation on which you can build Virtual AGC; i.e., simply bypass your "dirty" build setup completely.  This is usually quite a hassle. 

A better solution, when feasible, would be to use extra command-line switches for 'make', to eliminate conflicts by overriding the default compiler choices.  There are two such switches, FORCE_cc and FORCE_CC, which respectively override the C compiler and the C++ compiler.  For example, on my offending Linux Mint 17.3 system, I can get around the goofed-up system libraries with the following dodge, which forces the use of an older compiler (gcc 4.8) vs the latest version I've installed (gcc 8.3):

    make FORCE_cc=/usr/bin/gcc FORCE_CC=/usr/bin/g++ clean install

See the comments in the Makefile itself for more explanation.  The switches can override not merely the filesystem paths for locating the compiler (when you have multiple versions of gcc or g++ installed), but can be used to specify completely different C/C++ compilers, such as clang (which might be installed using a command such as "sudo apt-get install clang-3.9 libclang-3.9-dev").  As an example, the command I use to build Virtual AGC using clang rather than gcc/g++ is:

make FORCE_clang=yes FORCE_cc=/usr/bin/clang-3.9 FORCE_CC=/usr/bin/clang++-3.9 clean install

Running VirtualAGC Once It Has Been Built

cd ~/VirtualAGC/Resources
../bin/VirtualAGC

Raspberry Pi (Raspbian)

This works! Last verified (Raspbian Jessie): 2017-11-20 Last verified (Raspbian Stretch): 2018-05-11 See notes below for Raspbian Buster

One-time setup:

sudo apt-get install wx2.8-headers libwxgtk2.8-0 libwxgtk2.8-dev libsdl-dev libncurses5-dev liballegro4-dev git
git clone --depth 1 https://github.com/virtualagc/virtualagc

• If libsdl1.2debian is pre-installed on your system, it may conflict with the installation of libsdl-dev described above.  Simply omit libsdl-dev.  If there is a libsdl1.2debian-dev package, you may need to install it.
• Raspbian Buster (as opposed to Jessie and Stretch).  I've not yet tried Raspbian Buster myself, but I'm told the following mods are necessary:
  
• Compilation:  There may be a problem with the wxWidgets 2.8 library that allows applications apparently to be built properly, but not to be runnable afterward, with a complaint about mismatched "ABI" versions.  The workaround is to install wxWidgets 3.0 instead of 2.8, in which case use the following command rather than the one given above:  "sudo apt-get install wx3.0-headers libwxgtk3.0-dev libsdl-dev libncurses5-dev liballegro4-dev git".
• Running:  It may be that Tcl/Tk isn't installed, and while that those aren't needed for the most common configuration of VirtualAGC (AGC+DSKY+Telemetry), it is needed for certain advanced features.  Install with "sudo apt-get install tcl tk".
  

Building Virtual AGC:

cd virtualagc
make install

FreeBSD

This works! Last verified: 2017-08-31

1. Install 'cmake' and GNU 'make' (gmake) using the "package" system, with the command "sudo pkg install cmake gmake".
2. Install the "ports" system, if you haven't already.
   
3. Install wxWidgets 2.8.12, or as close to that 2.8.x version as you can get, using the "ports" system:  "cd /usr/ports/x11-toolkits/wxgtk28" and "sudo make install".
4. For whatever reason, the 'wx-config' program is installed with a different name.  Make a symbolic link with the proper name for it somewhere in your path:  "mkdir $HOME/bin" and "ln -s /usr/local/bin/wxgtk2u-2.8-config $HOME/bin/wx-config".  If you test this with the command "wx-config --list", you should see that the default wxWidgets configuration is "gtk2-unicode-release-2.8".
   
5. Download Allegro 4.4.2, or as close to that 4.4.x version as you can get.  Prior to building Allegro, I had to do this: "sudo ln -s /usr/local/lib/libasound* /usr/lib"; I'm sure there's a much cleaner way to handle that problem (namely, that Allegro couldn't find libasound), but I don't know what it is.  To build and install, do this:
• "cd allegro-4.4.2"
• "mkdir Build"
• "cd Build"
• "cmake .."
• "make"
• "sudo make install"

Building Virtual AGC:

• In the Virtual AGC source directory, run "gmake FREEBSD=yes install" or "gmake FREEBSD=yes clean install".  (Note that 'sudo' is neither necessary nor desirable.)  Note the use of 'gmake' rather than just 'make'
  

Solaris

This works! Last verified: 2017-08-31

1. Install Oracle Developer Studio tools.  I used version 12.5, and only installed the tools rather than the complete IDE.  This is to give you the C and C++ compilers ('cc' and 'CC'), which have command-line options required by wxWidgets but not supported by 'gcc'.
2. Install the Open CSW system, add /opt/csw/bin to your PATH, and /opt/csw/lib to LD_LIBRARY_PATH.
3. Install wxWidgets via the Open CSW system.
4. Install gtk2, tcl-8, tk-8, ncurses, freeglut, cmake, and gnu-grep using the Package Manager.

Build Virtual AGC:

• In the Virtual AGC source directory (which for me was ~/git/virtualagc), run "gmake SOLARIS=yes install" or "gmake SOLARIS=yes clean install".  (Note that 'sudo' is neither necessary nor desirable.)  Note the use of 'gmake' (rather than just 'make').
  

Mac OS X

This works! Last verified: 2021-11-12

Older Macs: Xcode with gcc

1. Install most-current version of Xcode for your version of Mac OS X ... of course!  I use Xcode 4.6.3.
   
2. Install MacPorts.
3. Use MacPorts to install wxWidgets 2.8.12:  "sudo port install wxgtk-2.8" or "sudo port install wxWidgets-2.8", depending on your Xcode version.
4. Use MacPorts to install cmake:  "sudo port install cmake".
   
5. Install Allegro 4.4.2:
• Use MacPorts:  "sudo port install allegro".  That doesn't work on some versions of Xcode, in which case instead use the next step.  Be aware that Allegro version 5.x does not work for our purposes, so alternate installations like "sudo port install allegro5" aren't helpful.
  
• Install from source:
• Download and unpack the source code for version 4.4.2.
• "cd allegro-4.4.2"
• "mkdir Build"
• "cd Build"
• "cmake .."
• "make"
• "sudo make install"
• If both of the approaches to installing Allegro fail, as they did on my Mac, it's not a disaster, and you can still proceed.
  

Building Virtual AGC:

1. 'cd' into Virtual AGC source directory, as obtained from GitHub.
2. Determine where wxWidgets was installed by using the command "port contents wxgtk-2.8 | grep /bin/" (or "port contents wxWidgets-2.8 | grep /bin/").  What you're actually trying to find out is the directory in which the program 'wx-config' is installed.  In my case, I found that the location was /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/2.8/bin.  You have to add that to your PATH, so that the 'wx-config' program can be found during the build.  The command is "export PATH=$PATH:/opt/local/.../bin".  You can test that it worked with a command like "wx-config --list", from which we would like to see that the default configuration is "gtk2-unicode-release-2.8".  By the way, unless you make this change to the PATH permanent (which is done in ~/.profile), the PATH will be reset back to the default one as soon as you close the command-line terminal you're using for this.
3. Do "make MACOSX=yes install" or "make MACOSX=yes clean install".

However, not all features of the VirtualAGC GUI program necessarily work.  For example, while you can run simulated AGCs (which is the main thing!), you may not be able to browse the AGC source code from within VirtualAGC.  What is supposed to happen when you use VirtualAGC's source-browsing feature is that it simply launches whatever default web-browser you have set up on your system, and shows you the AGC/AEA source code within that browser ... and indeed, this approach used to work in Mac OS X.  But what happens for me is that there's simply an error message complaining that "There is no default application configured for HTML files".  However, I can certainly configure the default browser, and have changed it back and forth between Safari and Chrome, so I'm not sure what this message is complaining about.  Perhaps it's an X11 error.  At any rate, I have not been able to solve it.  You can still browse the source, of course:  simply right-click on the VirtualAGC app icon on the desktop, and select "show package contents"; navigate down to Contents/Resources/source/, select the mission you're interested in, and double-click on the MAIN.agc.html file you find in that directory.  It will open up in your default browser, just as it should have done in the VirtualAGC program.

Another quirk that may be of interest on the Mac is how to run individual GUI applications like yaDSKY2 or yaTelemetry, without having to run the VirtualAGC application.  Again, right-click on the VirtualAGC desktop icon and select "show package contents".  Navigate down to Contents/MacOS/, and you'll find the various individual GUI applications there, where you can simply run them by double-clicking on them.

Newer Macs: Xcode with clang

Ludo Visser has sent me instructions for building Virtual AGC on a clean installation of MacOS 12.0.1 (Monterey).  Virtual AGC itself required no changes.  He does mention that he didn't try it out with a joystick, but other than that indicates that Virtual AGC does work "out of the box" after he builds it.   

So here are his instructions, verbatim:

1. Install Xcode command line tools

          xcode-select --install

2. Install Macports per the instructions.
3. In a shell session:

          sudo port install git +credential_osxkeychain
          sudo port install wxWidgets-3.2
          port contents wxWidgets-3.2  | grep bin  # note path
          export PATH=/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.1/bin:$PATH # path from command above
          export cc=clang
          export CC=clang
          git clone https://github.com/virtualagc/virtualagc.git
          cd virtualagc
          make MACOSX=yes FORCE_clang=yes clean install

Windows

This works! Last verified (Andy Smith): 2021-05-24 Last verified (RSB): 2017-08-31

1. Install the MinGW compiler and the Msys Linux-like command-line development environment, using the downloadable "MinGW Installation Manager".  This installation program changes over time, so I cannot tell you precisely how to use it, and can only give you a general idea.  Use the default choices for installation directory (c:\mingw) and other settings, if any are offered.  Note that by default, the batch file c:\mingw\msys\1.0\msys.bat is what's used to start the Msys command shell as in the next step below, and you might want to manually create a desktop icon or a Windows start-menu entry for running that batch file.  If you are unlucky enough to have a Windows user name containing spaces, you will encounter difficulties.  The instructions at the www.mingw.org website explain what to do in that situation.  Specific packages which you need to install using the MinGW Installation Manager, at least at this writing, which may not be among the defaults are:
• All of the packages in the "Basic Setup", except Ada, FORTRAN, and Objective-C compilers.
• Among the packages in "All Packages":
  
• "msys-libregex" (dev+dll)
• "msys-libncurses" (dev+dll)
• "msys-wget"
• "msys-unzip"
2. Run Msys, to bring up a command shell.  All of the following steps occur within this command shell and not at a "DOS" command line.  Some of the "DOS" commands you probably are familiar with (such as "dir") don't work in this shell, while Linux-type replacements ("ls -l") are used instead.  Some commands, like "cd", work almost the same way, though there are subtle differences. Also, '/' is the separator for folders in path-names, rather than '\'.  Google for "bash" if you're interested in these kinds of differences. 
   
3. Install the SDL library, version 1.2.  You should find that there is a download file specifically labeled as a Win32 development library for MinGW.  Within your Msys home directory, unpack the download file, 'cd' into the directory it creates.  Do "mkdir /usr/local", and run the command "make install-sdl prefix=/usr/local".  (The /usr directory within Msys will probably correspond to something like c:\mingw\msys\1.0\ in your Windows filesystem.)   Note:  All software needed to build Virtual AGC will be installed under /usr/local, so eventually it will be populated with sub-directories such as /usr/local/bin, /usr/local/include, /usr/local/lib, and so on.  The Virtual AGC makefiles are hard-coded to assume these installation locations.  Note, however, that the Virtual AGC binaries you are going to create are not installed under /usr/local, because while the Virtual AGC apps are being created using Msys, Msys is not needed to run them ... they are simply Windows programs like any other.
   
4. Obtain a source zipfile of wxWidgets, version 2.8.12, or as close to this 2.8.x version as is available.  Of the several varieties offered for download (wxAll, wxMSW, wxGTK, ...) chose wxMSW, and make sure you get the source code rather than an installer program.  Unzip the downloaded file in your home directory, 'cd' into the directory this creates, and then do "./configure --enable-unicode", "make", and "make install".
5. Though it has nothing to do with building Virtual AGC, if you want to have access to Stephen Hotto's contributed Lunar Module accessories when you run Virtual AGC, you'll also have to install Tcl/Tk. 
   

1. Get the Virtual AGC source code from GitHub (from the link at the top of this page), either by using 'git', if installed on your computer, or by downloading a zipfile and unzipping it.  For the sake of discussion, I'm going to suppose that the folder you get from doing this is called "virtualagc" and is in your home directory.
   
2. Do "cd virtualagc".
   
3. Build it: "make WIN32=yes install" or "make WIN32=yes clean install". 
   

WebAssembly

This works! Last verified (RSB, Linux Mint 21): 2022-09-25

I probably don't need to describe what WebAssembly (Wasm) is, since anybody interested enough in reading about how to build Virtual AGC for it almost certainly would know much more about it than I do anyway.  Nevertheless, here's what little I do know.  While WebAssembly apparently has a number of potential use cases, the main use case for it at present seems to be as a way to port applications so that they can run within a web browser ... but to run somewhat faster than if they were instead ported to JavaScript.  Pragmatically, WebAssembly requires a browser which actually supports the WebAssembly virtual machine, though as of this writing (2021-05-26) such support is pretty widespread and includes Firefox, Chrome, Edge, and Safari. 

• A DSKY model
• Live views of AGC i/o ports
• Live view of erasable memory

Of course, for some years there has already been a JavaScript port of Virtual AGC: moonjs by Shahriar Iravanian (live demo), which runs the Colossus 249 AGC program (Apollo 9 CM).  Moonjs is based on a subset of JavaScript called asm.js, which is optimized to allow faster-execution than arbitrarily-coded full-featured JavaScript programs would.  It would be interesting some day to have a head-to-head speed competition between webAGC and moonjs, though of course if both could achieve speed parity with a physical AGC, then anything beyond that is gravy.  Shahriar's build instructions for moonjs are pretty straightforward, and I won't repeat them here.  I should note that moonjs relies on emscripten to port yaAGC.c to asm.js, but that emscripten now seems to target WebAssembly rather than asm.js, so that train may have left the station!

But as far as the WebAssembly port is concerned, here's my interpretation of Michael's build instructions for Linux Mint 19 or later, 64-bit.  The instructions won't work in Mint 17 or earlier because of library-versioning problems.  First, here is the one-time setup:

• Installation of wasi-sdk. For the sake of argument let's suppose the installation directory will be ~/wasi-sdk.  You can simply download the prebuilt release 16 tarball:
  

cd ~/wasi-sdk
wget https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-16/wasi-sdk-16.0-linux.tar.gz
tar xvf wasi-sdk-16.0-linux.tar.gz
export WASI_SDK_PATH=~/wasi-sdk/wasi-sdk-16.0

cd yaAGC
WASI=yes make [clean] yaAGC.wasm

• Clone Michael's webAGC code base onto your local computer.  For example, use the command "git clone --depth=1 https://github.com/michaelfranzl/webAGC".  The subdirectory webAGC/demo/ is the top-level code for the web-page, webAGC/demo/agc/ contains the AGC core ropes, and the subdirectory webAGC/src/ contains the WebAssembly material.  Specifically, the latter contains yaAGC.wasm, and that's where you need to copy any new yaAGC.wasm you create by compiling Virtual AGC.
• Install node.js if you don't have it installed already.  I don't know the version requirements, but version 8 definitely does not work.
• You now have to serve the webAGC/demo directory via HTTP. Follow the instructions in the README file of the demo subdirectory.

Browsers can read files even from hard disk and display static websites (html, js, css) just like, say, a word processor displays a word document. Strictly speaking, no HTTP servers are required in that scenario. However, when using more modern browser features, like JavaScript modules, WebAssembly, WebRTC etc., the browser insists that content be served over the network. This doesn't mean that servers need to have any 'business logic' implemented; they can just be static content delivery pipes. In this sense, the webAGC demo is indeed a pure browser/client solution; it is completely unaware of a server.

iPhone

Still okay?

Running the Validation Suite of the simulated AGC

1. Run the VirtualAGC program, select "Validation suite" as the simulation type, and hit the "Run" button.
2. A code of "00" will appear in the PROG area of the DSKY, and the OPR ERR lamp will flash.  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. There is no indication that the test is running.  The test takes about 77 seconds.
5. If all tests are passed, then the PROG area on the DSKY will show the code "77", and the OPR ERR lamp will flash.  (The return code is 77 because 77 is the largest 2-digit octal number.  It is just a coincidence that the test duration is also 77 seconds.)
   
6. If some tests fail, an error code other than "00" or "77" will be displayed in the PROG area on the DSKY, and the OPR ERR lamp will flash.
7. 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.agc.

Some Resource Issues on Slower Computers, Such as Raspberry Pi

• Pi B+:  80% CPU utilization. 
  
• Pi 3: 40% CPU utilization.
  

If that's too much for you, there are some things you may be able to do to make it more efficient.  First, note that the VirtualAGC program — which isn't a component of the simulation, but merely a convenient graphical interface so that you don't have to memorize command-line options for the actual components — actually takes 25-30% of the CPU (for either of the two Pi models mentioned above) all by itself.  You don't really need to run it if you don't want to.  But how do you run a simulation easily without VirtualAGC?  Well, if you run the simulation just once from VirtualAGC, and exit the simulation immediately after starting it, you'll find that it has automatically created a script called "simulate" which can be used to start that exact configuration of the simulation without running VirtualAGC itself.  As a result, you get CPU utilizations closer to 50% or 10%, respectively, on the two Pi models mentioned above.  To just run that script, you do this:

cd VirtualAGC/temp/lVirtualAGC/Resources
./simulate

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2022-09-25.