swh:1:snp:79c9132b4a8931e989e318225e00e088ef6f383d
Tip revision: a8fa8f03b50a72034009439908f1339f4ce94518 authored by Ron Burkey on 06 June 2021, 12:28:21 UTC
Fixed more hyperlinks.
Fixed more hyperlinks.
Tip revision: a8fa8f0
download.html
<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Virtual AGC Download Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Author" content="Ronald Burkey">
<link rel="icon" type="image/png" href="favicon.png">
<meta name="author" content="Ronald S. Burkey">
<script type="text/javascript" src="Header.js"></script>
</head>
<body style="background-image: url(gray3.jpg);">
<script type="text/javascript">
document.write(headerTemplate.replace("@TITLE@","Downloads").replace("@SUBTITLE@","Installation Instructions for<br>Linux/Windows/Mac OS X and others"))
</script>
<div align="center"> <br>
<br>
</div>
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td colspan="4" rowspan="1" valign="top">
<div align="center"> <big><b>Current Versions of Virtual
AGC Downloads</b></big><br>
</div>
</td>
</tr>
<tr>
<th valign="bottom" align="left">Target Platform<small><br>
</small></th>
<th valign="bottom" align="left"> Description<small><br>
</small></th>
<th valign="bottom" align="left">Download Version<small><br>
</small></th>
<th valign="bottom" align="left"> Instructions<small><br>
</small></th>
</tr>
<tr>
<td valign="middle">All platforms<br>
</td>
<td valign="middle">Complete source code (Apps, AGC, and AEA)<br>
</td>
<td valign="middle"><a
href="https://github.com/virtualagc/virtualagc">Current at
GitHub</a></td>
<td valign="middle"><a
href="#Downloading_and_Building_Virtual_AGC">Building from
source</a><br>
</td>
</tr>
<tr>
<td valign="middle">Windows, Mac OS X, Linux, Solaris, or
FreeBSD (32- or 64-bit 'x86)<br>
</td>
<td valign="middle">VirtualBox virtual machine (Apps, AGC
source code, and visual AGC debugging). <br>
<br>
<font size="-1">Since the VM is a rather substantial
download (~1GB), you normally wouldn't want to download it
very often, and instead would just update it with new
VirtualAGC software, as needed, after the initial
download. But sometimes the improvements to the VM
itself are substantial enough to justify re-downloading it
in its entirety, so here is a brief change history to let
you decide. Note that older versions of the VM are <i>not</i>
retained on this site, so only the latest one listed in
the change history is still available. </font><font
size="-1">Note also that a complete re-download of the VM
requires erasing the old VM, putting the downloaded one in
the same location as the old VM on your host machine.</font>
<ul>
<li><font size="-1">2017-04-20:</font></li>
<ul>
<li><font size="-1">[<b>Note:</b> I recommend
installing a later version of the Midori browser, by
executing the following command from a command-line
in the VM: </font><font size="-1">"</font><font
size="-1"><tt>sudo apt-add-repository ppa:midori/ppa
&& sudo apt-get update -qq && sudo
apt-get install midori</tt></font><font size="-1">".
You
will be prompted for a password, which is
"virtualagc".]</font></li>
</ul>
<ul>
<li><font size="-1">Virtual disk size increased from 5GB
to 9GB, therefore, more actual disk space on the
host-system is required as well.</font></li>
<li><font size="-1">Space reserved for a swap-partition,
though not enabled.<br>
</font></li>
<li><font size="-1">Cut-and-paste between VM and host
machine is now enabled by default.<br>
</font></li>
<li><font size="-1">Language support and keyboard-layout
for the VM added (beyond just U.S. English), with
desktop launcher icon for selecting among them.<br>
</font></li>
<li><font size="-1">"Update VirtualAGC" launcher icon
added to desktop, for easy updates to the VirtualAGC
software.</font></li>
<li><font size="-1">2017-04-17 version of VirtualAGC
software.<br>
</font></li>
</ul>
<li><font size="-1">2017-03-29: </font><br>
</li>
<ul>
<li><font size="-1">Added Code::Blocks visual-debugging
launchers for many more AGC versions.</font></li>
<li><font size="-1">Eliminated the password entry
associated with the screen-saver.</font></li>
<li><font size="-1">Default browser changed, for much
faster viewing of AGC program listings. [<b>N</b><b>ote:</b>
It turns out that there are oddities about the way
this browser, Midori, has been working, so I would
advise installing a newer version of it. From
within a command-line in the VM, execute the
following command: "</font><font size="-1"><tt>sudo
apt-add-repository ppa:midori/ppa && sudo
apt-get update -qq && sudo apt-get install
midori</tt></font><font size="-1">". You
will be prompted for a password, which is
"virtualagc".]<br>
</font></li>
<li><font size="-1">2017-03-29 version of VirtualAGC
software.<br>
</font></li>
</ul>
<li><font size="-1">2016-11-19: <br>
</font></li>
<ul>
<li><font size="-1">Initial version of VM.</font></li>
<li><font size="-1">2016-11-19 version of VirtualAGC
software.</font></li>
</ul>
</ul>
</td>
<td valign="middle"><a
href="Downloads/VirtualAGC-runtime.tar.xz"> 2017-03-29,
1.2GB</a><br>
(10GB uncompressed)<br>
</td>
<td valign="middle"><a href="#Downloading_Running_or_Updating">Using
the
VM</a><br>
<br>
or <br>
<br>
<a href="#Updating_the_Virtual_AGC_VM">Updating the VM to
latest version of VirtualAGC (see next item)</a><br>
</td>
</tr>
<tr>
<td valign="middle">Ubuntu 14.04 (32-bit 'x86)<br>
</td>
<td valign="middle">App-installation tarball<br>
</td>
<td valign="middle"><a
href="Downloads/VirtualAGC-Ubuntu-14.04-32-2017-08-31.tar.xz">2017-08-31,
26MB</a><br>
(418MB uncompressed)<br>
</td>
<td valign="middle"><font color="#999999"><a
href="#Installer_for_Ubuntu_14.04_32-bit_x86">Using
Ubuntu installer</a></font></td>
</tr>
<tr>
</tr>
<tr>
<td valign="middle">Raspberry Pi (Raspbian-Jessie)<br>
</td>
<td valign="middle">App-installation tarball<br>
</td>
<td valign="middle"><a
href="Downloads/VirtualAGC-Raspbian-2017-08-31.tar.xz">
2017-08-31, 26MB</a><br>
(418MB uncompressed)<br>
<a href="Downloads/VirtualAGC-Raspbian-2017-03-29.tar.xz"> </a></td>
<td valign="middle"><a href="#Raspberry_Pi_Raspbian_">Using
Raspbian tarball</a><br>
</td>
</tr>
<tr>
<td valign="middle">Windows<br>
</td>
<td valign="middle">App-installation tarball<br>
</td>
<td valign="middle"><a
href="Downloads/VirtualAGC-Windows-2017-08-31.tar.xz">2017-08-31,
27MB</a><br>
(418MB uncompressed)<br>
</td>
<td valign="middle"><a href="#Installer_for_Windows">Using
Windows tarball</a><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<table summary="" cellspacing="2" cellpadding="2" border="1"
align="center">
<tbody>
<tr>
<td colspan="4" rowspan="1" valign="top">
<div align="center"> <big><b>Older Versions</b></big><br>
</div>
</td>
</tr>
<tr>
<th valign="top" align="left">Target Platform<small><br>
</small></th>
<th valign="top" align="left"> Description<small><br>
</small></th>
<th valign="top" align="left">Download Version<small><br>
</small></th>
<th valign="top" align="left"> Instructions<small><br>
</small></th>
</tr>
<tr>
<td valign="top">Ubuntu 14.04 (32-bit 'x86)<br>
</td>
<td valign="top">App-installation tarball<br>
</td>
<td valign="top"><a
href="Downloads/VirtualAGC-Ubuntu-14.04-32-2017-04-17.tar.xz">2017-04-17,
21MB</a></td>
<td valign="top"><a
href="#Installer_for_Ubuntu_14.04_32-bit_x86">Using Ubuntu
installer</a></td>
</tr>
<tr>
<td valign="top">Ubuntu 14.04 (32-bit 'x86)<br>
</td>
<td valign="top">App-installation tarball<br>
</td>
<td valign="top"><a
href="Downloads/VirtualAGC-Ubuntu-14.04-32-2017-03-29.tar.xz">2017-03-29,
23MB</a><br>
</td>
<td valign="top"><a
href="download.html#Installer_for_Ubuntu_14.04_32-bit_x86">Using
Ubuntu
installer</a><br>
</td>
</tr>
<tr>
<td valign="top">Ubuntu 14.04 (32-bit 'x86)<br>
</td>
<td valign="top">App-installer program<br>
</td>
<td valign="top"><a
href="Downloads/VirtualAGC-installer-2017-03-27">2017-03-27,
42MB</a><br>
</td>
<td valign="top"><a
href="download.html#Installer_for_Ubuntu_14.04_32-bit_x86">Using
Ubuntu
installer</a><br>
</td>
</tr>
<tr>
<td valign="middle">Ubuntu 14.04 (32-bit 'x86)<br>
</td>
<td valign="top">App-installer program<br>
</td>
<td valign="middle"><font color="#999999"><a
href="Downloads/VirtualAGC-installer-2016-11-16">
2016-11-16, 27MB</a></font></td>
<td valign="middle"><font color="#999999"><a
href="download.html#Installer_for_Ubuntu_14.04_32-bit_x86">Using
Ubuntu
installer</a><br>
</font> </td>
</tr>
<tr>
<td valign="top">Raspberry Pi (Raspbian-Jessie)<br>
</td>
<td valign="top">App-installation tarball<br>
</td>
<td valign="top"><a
href="Downloads/VirtualAGC-Raspbian-2017-03-29.tar.xz">2017-03-29,
21MB</a></td>
<td valign="top"><a href="#Raspberry_Pi_Raspbian_">Using
Raspbian tarball</a></td>
</tr>
<tr>
<td valign="middle">Raspberry Pi (Raspbian-Jessie)<br>
</td>
<td valign="top">App-installation tarball<br>
</td>
<td valign="middle"><a
href="Downloads/VirtualAGC-Raspbian-2016-08-13.tar.bz2">
2016-08-13, 12MB<br>
</a></td>
<td valign="middle"><a
href="download.html#Raspberry_Pi_Raspbian_">Using Raspbian
tarball</a><br>
</td>
</tr>
<tr>
<td valign="top">Windows<br>
</td>
<td valign="top">App-installation tarball<br>
</td>
<td valign="top"><a
href="Downloads/VirtualAGC-Windows-2017-03-29.tar.xz">2017-03-29,
23MB</a></td>
<td valign="top"><a href="#Installer_for_Windows">Using
Windows tarball</a></td>
</tr>
<tr>
<td colspan="4" rowspan="1" valign="top"><a
href="download-less-old.html">Very old versions</a><br>
</td>
</tr>
<tr>
<td colspan="4" valign="top"><a href="download-old.html">Very,
very old versions</a><br>
</td>
</tr>
</tbody>
</table>
<br>
<h2>Contents</h2>
<ul>
<li><a href="#Introduction">Introduction</a></li>
<li><a href="#Downloading_Running_or_Updating">Downloading,
Running, or Updating Virtual AGC in VirtualBox</a></li>
<ul>
<li><a href="#Characteristics_of_the_Virtual_AGC_VM">Characteristics
of
the Virtual AGC VM</a></li>
<li><a href="#Installation_of_the_Virtual_AGC_VM_">Installation
of the Virtual AGC VM</a></li>
<li><a href="#Updating_the_Virtual_AGC_VM">Updating the Virtual
AGC VM</a></li>
</ul>
<li><a href="#Platforms_Directly_Supported_by">Platforms Directly
Supported by Virtual AGC Installers</a></li>
<ul>
<li><a href="#Virtual_AGC_Installer_for_Raspberry_Pi">Virtual
AGC Installer for Raspberry Pi (Raspbian)</a></li>
<li><a href="#Installer_for_Ubuntu_14.04_32-bit_x86">Installer
for Ubuntu 14.04 32-bit 'x86 Linux<br>
</a></li>
<li><a href="#Installer_for_Windows">Installer for Windows</a><br>
</li>
</ul>
<li><a href="#Downloading_and_Building_Virtual_AGC">Downloading
and Building Virtual AGC from Source</a></li>
<ul>
<li><a href="#Limitation">Limitation</a></li>
<li><a href="#Getting_the_Source_Code_">Getting the Source Code</a></li>
<li><a href="#CMake-Based_Builds">CMake-Based Builds</a><br>
</li>
<li><a href="#Linux_">Linux</a></li>
<li><a href="#Raspberry_Pi_Raspbian_">Raspberry Pi (Raspbian)</a></li>
<li><a href="#FreeBSD">FreeBSD</a></li>
<li><a href="#Solaris">Solaris</a></li>
<li><a href="#Mac_OS_X">Mac OS X</a></li>
<ul>
<li><a href="#Older_Macs:_Xcode_with_gcc">Older Macs: Xcode
with gcc</a></li>
<li><a href="#Newer_Macs:_Xcode_with_clang">Newer Macs: Xcode
with clang</a><br>
</li>
</ul>
<li><a href="#Windows">Windows</a></li>
<li><a href="#WebAssembly">WebAssembly</a><br>
</li>
<li><a href="#iPhone">iPhone</a></li>
</ul>
<li><a href="#Running_the_Validation_Suite">Running the Validation
Suite of the Simulated AGC</a></li>
<li><a href="#Some_Resource_Issues_on_Slower">Some Resource Issues
on Slower Computers, Such as Raspberry Pi</a><br>
</li>
</ul>
<h2><a name="Introduction" id="Introduction"></a>Introduction</h2>
<p>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:<br>
</p>
<ol>
<li>If you simply wish to <i>run</i> 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 <a href="#Downloading_Running_or_Updating">download
and run the provided VirtualBox virtual machine</a>. 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 (<a
href="https://www.freebsd.org/doc/handbook/virtualization-host-virtualbox.html">according
to
this page</a>) FreeBSD as well even though the latter is not
obvious from the VirtualBox website.<br>
</li>
<li>If you just happen to have a computer system which is
currently supported by an installation package, then you can <a
href="#Platforms_Directly_Supported_by">simply download and
install the proper installation package</a>. At present,
however, these platforms are only the following:</li>
<ol>
<li>Raspberry Pi</li>
<li>Ubuntu 14.04 32-bit 'x86.</li>
<li>Windows.<br>
</li>
</ol>
<li>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 <a
href="#Downloading_and_Building_Virtual_AGC">download the
Virtual AGC source code, and perhaps build it yourself</a>.
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.<br>
</li>
<li>If you are satisfied with <i>older</i> versions of Virtual
AGC, many additional computer platforms were once directly
supported with installer programs, which you can still find <a
href="download-less-old.html">here</a> or <a
href="download-old.html">here</a>. 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.</li>
</ol>
<p>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.<br>
</p>
<h2><a name="Downloading_Running_or_Updating"
id="Downloading_Running_or_Updating"></a>Downloading, Running,
or Updating Virtual AGC in VirtualBox</h2>
<h3><a name="Characteristics_of_the_Virtual_AGC_VM"
id="Characteristics_of_the_Virtual_AGC_VM"></a>Characteristics
of the Virtual AGC VM<br>
</h3>
<p>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.<br>
</p>
<p>The virtual-machine approach should work with any host system
supported by <a href="http://www.virtualbox.org">VirtualBox</a>:
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.<br>
</p>
<p>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:<br>
</p>
<table width="100%" cellspacing="2" cellpadding="2" border="0">
<tbody>
<tr>
<td valign="top" align="center"><a
href="VirtualAGC-runtime-gui.jpg"><img alt="" title="Click
to enlarge" src="small-VirtualAGC-runtime-gui.jpg"
width="360" height="265" border="2"></a></td>
<td valign="top" align="center"><a
href="VirtualAGC-runtime-gui-B.jpg"><img alt=""
title="Click to enlarge"
src="small-VirtualAGC-runtime-gui-B.jpg" width="360"
height="265" border="2"></a></td>
</tr>
</tbody>
</table>
<p>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):<br>
</p>
<table summary="" width="100%" cellspacing="2" cellpadding="2">
<tbody>
<tr>
<td valign="top" align="center"><br>
</td>
<td valign="top" align="center"><a
href="VirtualAGC-runtime-sim.jpg"><img alt="" title="Click
to enlarge" src="small-VirtualAGC-runtime-sim.jpg"
width="360" height="265" border="2"></a><br>
</td>
<td valign="top" align="center"><a
href="VirtualAGC-runtime-browse.jpg"><img alt=""
title="Click to enlarge"
src="small-VirtualAGC-runtime-browse.jpg" width="360"
height="265" border="2"></a><br>
</td>
</tr>
</tbody>
</table>
<p>If you exit from the VirtualAGC GUI, you'll see the VM's bare
desktop, on which a number of other useful options appear: <br>
</p>
<p align="center"><a href="VirtualAGC-runtime-kbd-select.jpg"><img
alt="" title="Click to enlarge"
src="VirtualAGC-runtime-kbd-select.jpg" width="360"
height="265" border="2"></a><br>
<br>
</p>
The VM actually runs Ubuntu Linux, and if you're not an American,
you might want to configure language options or keyboard-layout
options. (Or you might not care about those things, since the
language options only affect the VM and not VirtualAGC, and you have
very little need to use the keyboard ... but still.) For VM
versions 2017-04-20 or later, the overall language selection is in
the desktop icon called "Language Support"; all languages supported
by Ubuntu are already loaded, so you don't need to download any new
ones, but you do need to select the one you want (if it's not U.S.
English). By the way, that's <i>not</i> what's depicted
above; what you see in the screenshot above is the keyboard-layout
selection list, which you can get by clicking the icon that looks
like a keyboard near the desktop's bottom right. There are
actually a lot more layouts available than what's shown, but to get
more of them, such as Arabic or Chinese or whatever, you need to use
the "Keyboard Input Methods" icon first, to add the layout you need
to this pop-up menu.<br>
<br>
Some other very-useful icons you can see on this desktop are:<br>
<ul>
<li>"AGC Simulator" lets you rerun the VirtualAGC GUI if you've
exited from it.</li>
<li>"GitHub Repo" lets you browse our GitHub source-code
repository.</li>
<li>"Internet Archive" lets you browse our Internet Archive
document collection.</li>
<li>"Website" lets you browse our main website.</li>
<li>(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.<br>
</li>
<li>"AGC Visual Debugging" allows you to work with the AGC source
code, and or run the AGC simulation, within a program called <a
href="http://codeblocks.org/">Code::Blocks</a>. The
desktop icon is actually a folder containing separate launcher
icons for most of the AGC software versions available to us.<br>
</li>
</ul>
Code::Blocks is a popular Integrated Development Environment
(IDE). Within it, you can edit the AGC source code and
reassemble it ... but more importantly, you can <i>visually debug</i>
it: i.e., single-step through the AGC code, examine AGC variables,
and so forth, so that you can get a very intimate understanding of
how the AGC code works, if that's something that interests
you. For example, in the VM screenshot below, the Luminary 131
(Apollo 13 LM) code is being debugged, and the program is at line
379 (the <tt>EXTEND</tt> instruction) of the Fresh Start and
Restart section of the code.<br>
<p align="center"><br>
<a href="VirtualAGC-runtime-dbg.jpg"><img alt="" title="Click to
enlarge" src="small-VirtualAGC-runtime-dbg.jpg" width="720"
height="530" border="2"></a><br>
</p>
<p>Okay, enough of the sales pitch already! What's do you
actually have to do to install the thing?<br>
</p>
<h3><a name="Installation_of_the_Virtual_AGC_VM_"
id="Installation_of_the_Virtual_AGC_VM_"></a>Installation of the
Virtual AGC VM<br>
</h3>
<p>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 <a
href="https://en.wikipedia.org/wiki/X86_virtualization">VT-x
(Intel) or AMD-V (AMD) extensions</a>. 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).<br>
</p>
<p>Before doing anything with Virtual AGC as such, you should take
care of the following:<br>
</p>
<ul>
<li>If VirtualBox is not already installed, <a
href="https://www.virtualbox.org">download and install
VirtualBox</a>, using whatever version is suitable for your
computer system. The Virtual AGC virtual machine (VM) you
will download was created with <a
href="https://www.virtualbox.org/wiki/Download_Old_Builds_4_3">VirtualBox
4.3.40</a>, 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".<br>
</li>
<li>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 <a href="http://www.7-zip.org/download.html">7zip</a>
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 <a
href="http://www.winzip.com/win/en/index.htm">WinZip</a>.</li>
</ul>
<p>Then to actually install the VirtualAGC VM, you do the following.<br>
</p>
<ol>
<li>Download the current compressed VM, as listed at the top of
this page.<br>
</li>
<li>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 <i>we'd</i> 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.</li>
<li>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.</li>
</ol>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<h3><a name="Updating_the_Virtual_AGC_VM"
id="Updating_the_Virtual_AGC_VM"></a>Updating the Virtual AGC VM</h3>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>For earlier VM versions, you can <a href="UpdateVirtualAGC">download
a
script</a> 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:<br>
</p>
<blockquote>
<p><tt>bash ./UpdateVirtualAGC</tt><br>
</p>
</blockquote>
<h2><a name="Platforms_Directly_Supported_by"
id="Platforms_Directly_Supported_by"></a>Platforms Directly
Supported by Virtual AGC Installers</h2>
<h3><a name="Virtual_AGC_Installer_for_Raspberry_Pi"
id="Virtual_AGC_Installer_for_Raspberry_Pi"></a>Virtual AGC
Installer for Raspberry Pi (Raspbian)</h3>
Installation is trivial:<br>
<ol>
<li>Download the current Raspberry Pi installation tarball, as
listed at the top of this page.<a
href="Downloads/VirtualAGC-Raspbian-2016-08-13.tar.bz2"></a></li>
<li>Unpack the installation tarball somewhere: either "tar
-xJvf VirtualAGC-Raspbian-<i>VERSION</i>.tar.xz" or "tar -xjvf
VirtualAGC-Raspbian-<i>VERSION</i>.tar.bz2", depending on which
type of installer is downloaded. (Notice that these two
commands are <i>not</i> the same, in that one has a 'j' where
the other has a 'J'.)<br>
</li>
</ol>
This gives you a directory called VirtualAGC/ (or lVirtualAGC/ if
the older .bz2 form of the installer was used). Before running
the program for the first time, there's a one-time setup you may
have to do:<br>
<blockquote><tt>sudo apt-get install libwxgtk2.8-0 libsdl
libncurses5 liballegro4 tk</tt><br>
</blockquote>
To run the program, simply do the following from the command line,
or set up a desktop icon that does the equivalent:<br>
<blockquote> <tt>cd VirtualAGC/Resources</tt><tt><br>
</tt><tt> ../bin/VirtualAGC</tt><br>
</blockquote>
<h3><a name="Installer_for_Ubuntu_14.04_32-bit_x86"
id="Installer_for_Ubuntu_14.04_32-bit_x86"></a>Installer for
Ubuntu 14.04 32-bit 'x86 Linux<br>
</h3>
<ol>
<li> 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.</li>
<li>Another one-time step is downloading the <a
href="UpdateVirtualAGC">update script, UpdateVirtualAGC</a>.</li>
<li>Run the command "bash UpdateVirtualAGC".</li>
<li>If you try to use the ACA simulation (joystick) and it doesn't
work, <a
href="yaTelemetry.html#Joystick_configuration_for_use_with_the">read
about
configuring it</a>.<br>
</li>
</ol>
<h3><a name="Installer_for_Windows"></a>Installer for Windows</h3>
<p>Installation is as follows:<br>
</p>
<ol>
<li>Download the current Windows installation tarball, as listed
at the top of this page.</li>
<li>Unpack the installation tarball somewhere: I did this by
using <a href="http://www.7zip.org">7zip</a>, 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-<i>VERSION</i>.tar.xz into
VirtualAGC-Windows-<i>VERSION</i>.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.)</li>
</ol>
This gives you a folder called VirtualAGC. This folder can be
stored any place you like, though I usually copy it into the same
folder I find myself in when opening up a DOS command line.
Just for the sake of discussion, let's suppose you've done this too,
and so you now have a file called C:\Users\<i>YourNameHere</i>\VirtualAGC.<br>
<br>
To run the program, my suggestion would be to create a desktop
shortcut for it. I'm no Windows aficionado, but I think the
basic steps to do that are these:<br>
<ol>
<li> <i>Right</i>-click on the desktop, and choose New/Shortcut
in the pop-up menu that appears.</li>
<li> The popup window that appears will ask you for the location
of the program you want to run. It is C:\Users\<i>YourNameHere</i>\VirtualAGC\bin\VirtualAGC.exe.</li>
<li> After the shortcut has been created on the desktop, <i>right</i>-click
it and select Properties. Change the "Start in" or
"Working directory" to be C:\Users\<i>YourNameHere</i>\VirtualAGC\Resources.</li>
<li>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\<i>YourNameHere</i>\VirtualAGC\Resources\ApolloPatch2-transparent.ico.</li>
</ol>
You should now be able to run VirtualAGC simply by double-clicking
the desktop shortcut you've created.<br>
<br>
Another way to use the program is from a command line. In the
command line, do this:<br>
<ol>
<li>C: </li>
<li>cd C:\Users\<i>YourNameHere</i>\VirtualAGC\Resources</li>
<li>..\bin\VirtualAGC</li>
</ol>
<h2> </h2>
<h2><a name="Downloading_and_Building_Virtual_AGC"
id="Downloading_and_Building_Virtual_AGC"></a>Downloading and
Building Virtual AGC from Source</h2>
<h3><a name="Limitation" id="Limitation"></a>Limitation</h3>
<p>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 <a
href="https://github.com/virtualagc/virtualagc/wiki/DevelopmentWithCodeBlocks">the
instructions for development using Code::Blocks on our GitHub
wiki</a>, as well as <a
href="https://github.com/virtualagc/virtualagc/wiki/VisualDebugging">the
instructions
for visual debugging</a>.<br>
</p>
<p>Of course, it also has the limitation that we can't actually deal
with every platform people might <i>try</i> 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.<br>
</p>
<h3><a name="Getting_the_Source_Code_" id="Getting_the_Source_Code_"></a>Getting
the
Source Code<br>
</h3>
<p>The complete up-to-the-moment source code is available from <a
href="https://github.com/virtualagc/virtualagc">GitHub</a>.
There
are several ways which one might choose to download it, such as <a
href="https://github.com/virtualagc/virtualagc/archive/master.zip">in a
zipfile</a> or using the 'git' program, which in Linux (for
example) would look like this:<br>
</p>
<blockquote>
<p>git clone --depth 1 https://github.com/virtualagc/virtualagc<br>
</p>
</blockquote>
In either case, you end up with a folder called virtualagc. <br>
<br>
What you do with it after that depends on which platform you intend
to run Virtual AGC on, and that's the topic of the next few
sections. It's also possible that <a
href="https://github.com/rburkey2005/virtualagc/blob/master/README.md#linux-1">the
instructions at the GitHub repository</a> may (or may not) be more
up-to-date than those here.<br>
<h3><a name="CMake-Based_Builds"></a>CMake-Based Builds</h3>
<p>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!<br>
</p>
<p>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 <a
href="https://github.com/virtualagc/virtualagc/wiki/Building-Virtual-AGC-Using-CMake">documentation
for the CMake-based build process can be found in our GitHub
repository's wiki</a>.<br>
</p>
<p>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).<br>
</p>
<h3> </h3>
<h3><a name="Linux_" id="Linux_"></a>Linux</h3>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="middle" align="center"><img alt=""
src="greenCheckmark.png" width="72" height="75"><br>
</td>
<td valign="middle" align="center"><big><big><b>This works!<br>
</b> <small><small><small><i>Last verified (Mint
64-bit): 2020-12-06<br>
Last verified (Mint 32-bit): 2019-09-22<br>
Last verified (Mint 64-bit, clang 3.9):
2020-12-06<br>
Last verified (Fedora 26 64-bit): 2017-08-31<br>
Last verified (Slackware 14.2): 2021-03-21<br>
Last verified (Chromebook): 2021-03-21<br>
</i></small></small></small></big></big></td>
</tr>
</tbody>
</table>
<br>
These instructions apply to building Virtual AGC on <i>Ubuntu-like
systems</i>, but are probably directly applicable to most Ubuntu,
Debian, or Mint desktop systems. They are known to work on
64-bit Linux Mint 17.3 and 32-bit Ubuntu 14.04. Please realize
that while Linux is my own working environment of choice, I don't
have time to support every possible Linux variant, and don't intend
to even try to do so any longer. <br>
<br>
One-time setup:<br>
<ul>
<li>Ubuntu/Debian/Mint: "sudo apt-get install libsdl1.2-dev
libncurses5-dev liballegro4.4-dev g++ libgtk2.0-dev
libwxgtk2.8-dev". Sometimes the package names needed are a
little different:</li>
<ul>
<li>Could be liballegro4-dev</li>
<li>Could be libwxgtk3.0-dev</li>
<li>Note that using wxWidgets 3.1.<i>x</i> (developmental
version) or 3.2.<i>x</i> (stable version, when it is
eventually released) should also be possible. At the
present writing, that would entail building wxWidgets from
source. Moreover, it requires Virtual AGC source code
from 2021-03-22 or later which while it <i>appears</i> to
work, may not be entirely debugged.</li>
</ul>
<li>Versions of Linux I don't personally support, but about which
I have learned possibly-helpful info:</li>
<ul>
<li>Chromebook: <tt>mkdir ~/Desktop</tt>, and use the
instructions for Debian above. I'm not actually sure
what range of Chromebooks can support a VirtualAGC
installation, but <i>some</i> have Linux terminals built in
and can do so. Thanks to Nick Warne for pointing this
out.</li>
</ul>
<ul>
<li>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.)<br>
</li>
</ul>
<ul>
<li>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.)</li>
</ul>
</ul>
Here's how to build Virtual AGC:<br>
<ul>
<li>In the Virtual AGC source directory, run "make install" or
"make clean install". (This does not require a 'sudo', and
you shouldn't use one.)</li>
</ul>
<p>By the way, it's preferable to build Virtual AGC on a <i>clean</i>
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 <i>extra</i>
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 <i>multiple</i> 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. See the
comments in <a
href="https://github.com/virtualagc/virtualagc/blob/master/Makefile">the
Makefile</a> 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 ("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:<br>
</p>
<p align="center">make FORCE_clang=yes FORCE_cc=/usr/bin/clang-3.9
FORCE_CC=/usr/bin/clang++-3.9 install<br>
</p>
The switch FORCE_clang in this case provides some additional clang
tweaks beyond just the compiler locations. (Don't interpret
this as a claim that clang is supported. It's not! But
you may be able to get away with using it, if you're adventurous.)<br>
<br>
On supported Linux variants, the build process creates a desktop
icon from which you can run Virtual AGC. In some versions of
Linux, you will need to right-click the icon and indicate that it is
"trusted" before it will work properly. You can "uninstall" by
removing the icon, the ~/VirtualAGC folder, and the source-code
directory you downloaded from GitHub.<br>
<br>
On unsupported Linux variants, there may be no desktop icon, and you
may need to run the program from a command line, as follows:<br>
<blockquote><tt>cd ~/VirtualAGC/Resources<br>
../bin/VirtualAGC<br>
</tt></blockquote>
<h3><a name="Raspberry_Pi_Raspbian_" id="Raspberry_Pi_Raspbian_"></a>
Raspberry Pi (Raspbian)</h3>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="middle" align="center"><img alt=""
src="greenCheckmark.png" width="72" height="75"><br>
</td>
<td valign="middle" align="center"><big><big><b>This works!<br>
</b> <small><small><small><i>Last verified (Raspbian
Jessie): 2017-11-20<br>
Last verified (Raspbian Stretch): 2018-05-11<br>
See notes below for Raspbian Buster<br>
</i></small></small></small> </big></big></td>
</tr>
</tbody>
</table>
<br>
These instructions relate to building Virtual AGC on a Raspberry Pi
3 running Raspbian-Jessie, though they're not really specific to any
particular Pi model. For example, the instructions also work,
unchanged, on a Pi B+ and a Pi Zero (though I would not recommend
running VirtualAGC on them, unless you like to snooze). This
really isn't any different from building it on <a
href="#BuildLinux">any other Linux system</a>, but I'll go through
the steps separately anyway, using a completely clean Raspbian
installation. Laszlo Morocz provided the original idea. <br>
<p>One-time setup:<br>
</p>
<blockquote>
<p>sudo apt-get install wx2.8-headers libwxgtk2.8-0
libwxgtk2.8-dev libsdl-dev libncurses5-dev liballegro4-dev git<br>
git clone --depth 1 https://github.com/virtualagc/virtualagc</p>
</blockquote>
The "sudo apt-get install ..." step given above is inadequate in
some versions of Raspbian, and may need modifications:<br>
<ul>
<li>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. </li>
<li>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:<br>
</li>
<ul>
<li>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".</li>
<li>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".<br>
</li>
</ul>
</ul>
<p>Building Virtual AGC:<br>
</p>
<blockquote>
<p>cd virtualagc<br>
make install<br>
</p>
</blockquote>
or perhaps "make clean install" instead. (No 'sudo' should be
used with the 'make', nor is it a good idea to build from the root
account, since I gather there's no desktop for the root user.)
This process creates a desktop icon from which you can run Virtual
AGC. You can "uninstall" by removing the icon, the
~/VirtualAGC folder, and the source-code directory you downloaded
from GitHub.
<h3><a name="FreeBSD" id="FreeBSD"></a>FreeBSD</h3>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="middle" align="center"><img alt=""
src="greenCheckmark.png" width="72" height="75"><br>
</td>
<td valign="middle" align="center"><big><big><b>This works!<br>
</b> <i><small><small><small>Last verified: 2017-08-31</small></small></small></i><br>
</big></big></td>
</tr>
</tbody>
</table>
<br>
The instructions here relate to building Virtual AGC using <a
href="http://pcbsd.org/download/">PC-BSD 10.3, desktop version</a>.
That
isn't the latest version of FreeBSD (version 11), but it's much
easier to install than FreeBSD proper, and should be 100% equivalent
for the same version numbers. At any rate, I know nothing
about FreeBSD, so my instructions may not be the most-efficient
ones. The executive summary is that the build process works,
and VirtualAGC acts normally once built. <br>
<br>
Setup:<br>
<ol>
<li>Install 'cmake' and GNU 'make' (gmake) using the "package"
system, with the command "sudo pkg install cmake gmake".</li>
<li>Install the "ports" system, if you haven't already.<br>
</li>
<li>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".</li>
<li>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".<br>
</li>
<li><a href="http://liballeg.org/old.html">Download Allegro 4.4.2</a>,
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:</li>
<ul>
<li>"cd allegro-4.4.2"</li>
<li>"mkdir Build"</li>
<li>"cd Build"</li>
<li>"cmake .."</li>
<li>"make"</li>
<li>"sudo make install"</li>
</ul>
</ol>
<p>Building Virtual AGC:<br>
</p>
<ul>
<li>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'<br>
</li>
</ul>
This process creates a desktop icon from which you can run Virtual
AGC. You can "uninstall" by removing the icon, the
~/VirtualAGC folder, and the source-code directory you downloaded
from GitHub.<br>
<h3><a name="Solaris" id="Solaris"></a>Solaris</h3>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="middle" align="center"><img alt=""
src="greenCheckmark.png" width="72" height="75"><br>
</td>
<td valign="middle" align="center"><big><big><b>This works!<br>
</b> <small><small><small><i>Last verified: 2017-08-31</i></small></small></small><br>
</big></big></td>
</tr>
</tbody>
</table>
<br>
The instructions here relate to building Virtual AGC using Solaris
11.3. Note that my personal knowledge of Solaris is mid-way
between "completely ignorant" and "dangerously misinformed", so you
have to take what I say with a grain of salt. Nevertheless,
the executive summary is that the instructions do work.<br>
<br>
One-time setup:<br>
<ol>
<li><a
href="http://www.oracle.com/technetwork/server-storage/developerstudio/downloads/index.html">Install
Oracle Developer Studio tools</a>. 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'.</li>
<li>Install the <a href="https://www.opencsw.org/">Open CSW
system</a>, add /opt/csw/bin to your PATH, and /opt/csw/lib to
LD_LIBRARY_PATH.</li>
<li>Install wxWidgets via the Open CSW system.</li>
<li>Install gtk2, tcl-8, tk-8, ncurses, freeglut, cmake, and
gnu-grep using the Package Manager.</li>
</ol>
<p>Build Virtual AGC:<br>
</p>
<ol type="a">
</ol>
<ul>
<li>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').<br>
</li>
</ul>
This creates a Virtual AGC launcher (which is actually just a shell
script) on the Desktop, and you can run Virtual AGC from that.
If it asks you whether to "Run" or "Run in terminal", the proper
choice is "Run". Unfortunately, no icon gets associated with
the launcher, but you can optionally associate one by right-clicking
on the launcher, selecting Properties, and using
~/VirtualAGC/Resources/ApolloPatch2-transparent.png as the image.<br>
<br>
You can "uninstall" by the deleting the desktop launcher, the
~/VirtualAGC folder, and the source-code directory you downloaded
from GitHub.<br>
<h3><a name="Mac_OS_X" id="Mac_OS_X"></a>Mac OS X</h3>
<table summary="" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="middle" align="center"><img alt=""
src="yellowQuestion.png" width="70" height="75"><br>
</td>
<td valign="middle" align="center"><big><big><b>Yes ... maybe<br>
</b> <small><small><small><i>Last verified: 2017-08-31</i></small></small></small><br>
</big></big></td>
</tr>
</tbody>
</table>
<br>
There are aspects of Virtual AGC that I simply can't personally
check on Mac OS X, because Apple no longer supports my particular
Mac with newer versions of Mac OS X. I'm stuck at Mac OS X
Lion (10.7), and with whatever version of Xcode is compatible with
that. The Apple Way out of this situation is, of course,
simply to buy a new Mac and then loudly tell everyone how overjoyed
I am, because that's is a <i>good</i> thing that I should have done
anyway. I decline to take that approach, since my "old" Mac is
100% satisfactory in every other way for my purposes. I'd
rather make snide comments behind Apple's back than to give them any
more of my money.<br>
<br>
One particular drawback of this situation is that Xcode is now
apparently based on the clang compiler, rather than on the gcc
compiler that Virtual AGC was designed for. Now that I've
found this out, of course, Virtual AGC has been adapted for use with
clang, and seems to work well with clang on the Linux platforms I
use for development purposes. But I can't test it for you on
the Mac, since the Xcode on <i>my</i> older Mac uses gcc.<br>
<br>
Now that I've warned you, the subsections below cover what I know
and what I theorize about building Virtual AGC on Macs.<br>
<h4><a name="Older_Macs:_Xcode_with_gcc"></a>Older Macs: Xcode with
gcc<br>
</h4>
The executive summary is that this works (on <i>my</i> Mac, with
Mac OS X Lion 10.7.5 and Xcode 4.6.3) and the simulated AGC, DSKY,
etc., can be run. The only problem is that the pretty,
syntax-highlighted AGC source code may not be browsable from <i>within</i>
VirtualAGC.<br>
<br>
Setup:<br>
<ol>
<li>Install <a href="https://developer.apple.com/download/more">most-current
version
of Xcode for your version of Mac OS X</a> ... of course!
I use Xcode 4.6.3.<br>
</li>
<li><a href="https://www.macports.org/">Install MacPorts</a>.</li>
<li>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.</li>
<li>Use MacPorts to install cmake: "sudo port install
cmake".<br>
</li>
<li>Install Allegro 4.4.2:</li>
<ul>
<li>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.<br>
</li>
<li>Install from source:</li>
<ul>
<li><a href="http://liballeg.org/old.html">Download</a> and
unpack the source code for version 4.4.2.</li>
<li>"cd allegro-4.4.2"</li>
<li>"mkdir Build"</li>
<li>"cd Build"</li>
<li>"cmake .."</li>
<li>"make"</li>
<li>"sudo make install"</li>
</ul>
<li>If <i>both</i> of the approaches to installing Allegro
fail, as they did on my Mac, it's not a disaster, and you can
still proceed.<br>
</li>
</ul>
</ol>
<p>Building Virtual AGC:<br>
</p>
<ol type="a">
<li>'cd' into Virtual AGC source directory, as obtained from
GitHub.</li>
<li>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.</li>
<li>Do "make MACOSX=yes install" or "make MACOSX=yes clean
install".</li>
</ol>
The result is that a new app icon appears on the desktop, and you
can launch VirtualAGC from that.
<p>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 <i>supposed</i>
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 <i>used to work</i> 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 <i>should</i> have done in the VirtualAGC
program.<br>
</p>
<p>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.<br>
</p>
<h4><a name="Newer_Macs:_Xcode_with_clang"></a>Newer Macs: Xcode
with clang</h4>
<p>As I hope my earlier rant made clear, I have no such newer Mac,
and am unlikely ever to have a need to outlay funds for such a Mac
(unless you want to give me one for free), so I'm dependent upon
others for feedback on this topic. Of which there isn't a
lot.<br>
</p>
<p>But here's what I do know about how you might proceed to build
Virtual AGC on one of these Macs. Firstly, I should mention
that I'm told that the app produced by the build process in the
preceding section, for older Macs, does <i>not</i> run on newer
Macs, so I can't just build it for you.<br>
</p>
<p>Try these build instructions:<br>
</p>
<ol>
<li>Install Xcode as usual.</li>
<li>I am told (thanks to Ludo Visser) that (at least once you
reach MacOS X 11.2), wxWidgets 2.8 and 3.0 either can no longer
be used or else no longer work properly with Virtual AGC.
So in that case it is apparently necessary on the Mac to go to
the <i>next</i> version of wxWidgets ... which at the time I'm
writing this is the developmental version 3.1, which will
eventually be released as 3.2. Ludo advises installing it
via "<tt>port install wxWidgets-3.2</tt>" from macports; Virtual
AGC source code from 2021-03-22 or later is also needed.
Also, for that same vintage of MacOS X, I'm told that the yaACA3
and jWiz programs in Virtual AGC currently won't build. If
you have no joystick and don't want to simulate the LVDC, you
can eliminate these programs directly from the Makefile by
removing the lines reading "<tt>SUBDIRS += yaLVDC</tt>", "<tt>SUBDIRS
+= yaLVDC</tt>", and "<tt>SUBDIRS += yaLVDC</tt>". I
apologize for forcing you to do that yourself rather than
handling it transparently for you, but I don't want to eliminate
these programs without understanding more precisely why and
whether or not it really needs to be done on a permanent basis.
</li>
<li>Presumably, most of the instructions in <a
href="download.html#Older_Macs:_Xcode_with_gcc">the preceding
section (on older Macs)</a>, except possibly other than those
related to wxWidgets, have to be performed on newer Macs as
well. However, the 'make' command has to be run
differently to enable using clang in place of gcc, namely:<br>
</li>
</ol>
<blockquote>
<blockquote>
<pre wrap="">EXPORT cc=clang
EXPORT CC=clang
<tt>make MACOSX=yes FORCE_clang=yes clean install<br></tt></pre></blockquote></blockquote><p> </p><ol></ol>
(Thanks to Gavin Eadie for the two "EXPORT ..." lines.) <br><br>If that doesn't work, it's theoretically possible to install gcc
separately from Xcode, and to use gcc in spite of Xcode being
present. You may notice that there's a gcc command already
present, but I'm told that Xcode somehow internally aliases that to
clang. Thus don't assume that just because you can type the
command "gcc", and get a response, that gcc is actually
installed. The build process looks something like this:<br><ol><li>Install Xcode as usual.</li><li>Additionally, install gcc (C compiler) and g++ (C++
compiler). I have no personal knowledge of this, but a few
websites (<a href="https://solarianprogrammer.com/2017/05/21/compiling-gcc-macos/">such
as this one</a>) discuss how to do it.</li><li>Presumably, most of the instructions in <a href="#Older_Macs:_Xcode_with_gcc">the preceding section</a>
have to be performed. However, the 'make' command has to
be run differently, in such a way as to force it to use the gcc
and g++ you just installed, as opposed to the default clang
compiler. You need to know the actual paths to the true
gcc and g++ programs, and do this:</li></ol><blockquote><blockquote><tt>make MACOSX=yes FORCE_cc=<i>/path/to/gcc</i>
FORCE_CC=<i>/path/to/g++</i> clean install<br></tt></blockquote></blockquote>
As to whether either of these approaches does anything useful at
all, your mileage may vary. If you try it, feel free to let me know
what happens.<br><blockquote><blockquote> </blockquote></blockquote><h3><a name="Windows" id="Windows"></a>Windows</h3><table summary="" cellspacing="2" cellpadding="2" border="1"><tbody><tr><td valign="middle" align="center"><img alt="" src="greenCheckmark.png" width="72" height="75"><br></td><td valign="middle" align="center"><big><big><b>This works!<br></b> <small><small><small><i>Last verified (Andy Smith): 2021-05-24<br>Last verified (RSB): 2017-08-31</i></small></small></small><br></big></big></td></tr></tbody></table><br>
<i>Concerning the build verifications listed above: After my last personal (RSB) verification I had gotten various hints from correspondents that Windows 64-bit builds no longer worked properly. Also, I was told that in all MinGW builds the AGC program SUNBURST 37 no longer assembled correctly. Subsequent fixes have hopefully corrected those issues, but I have not personally verified the builds. Thanks to Andy Smith for that. Also, I'm told that Cygwin builds work as well, though I have not tried it within recent memory, nor can I provide any specific set of instructions for doing so.</i><br><br>This section relates to building Virtual AGC on 64-bit Windows 7,
though the procedure doesn't seem to have anything in it that's
specific to that version of Windows. (It's merely that I've
only <i>tried</i> it on Windows 7. On occasion, I've copied
the results into Windows XP and run VirtualAGC there as well, but I
don't always do that.) The building process uses MinGW/Msys
(as opposed to Visual Studio), and I don't know whether or not there
is a valid Visual Studio build process.<br><br>
First-time setup of the Windows box is somewhat time-consuming (but
building Virtual AGC is pretty easy after that):<br><ol><li>Install <a href="http://www.mingw.org">the <b>MinGW</b>
compiler and the <b>Msys</b> Linux-like command-line
development environment</a>, 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 <b>Msys</b>
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:</li><ul><li>All of the packages in the "Basic Setup", except Ada,
FORTRAN, and Objective-C compilers.</li><li>Among the packages in "All Packages":<br></li><ul><li>"msys-libregex" (dev+dll)</li><li>"msys-libncurses" (dev+dll)</li><li>"msys-wget"</li><li>"msys-unzip"</li></ul></ul><li>Run <span style="font-weight: bold;">Msys</span>, to bring up
a command shell. <i>All</i> 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. <br></li><li>Install the <a href="http://www.libsdl.org">SDL library,
version 1.2</a>. You should find that there is a
download file specifically labeled as a Win32 development
library for <span style="font-weight: bold;">MinGW</span>.
Within your <span style="font-weight: bold;">Msys</span> 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
<span style="font-weight: bold;">Msys</span> will probably
correspond to something like c:\mingw\msys\1.0\ in your Windows
filesystem.) <span style="font-weight: bold;">Note:</span>
<span style="font-style: italic;">All</span> 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 <span style="font-style: italic;">not</span> installed under
/usr/local, because while the Virtual AGC apps are being created
using <b>Msys</b>, <b>Msys</b> is not needed to run them ...
they are simply Windows programs like any other.<br></li><li>Obtain a source zipfile of <a href="http://www.wxwidgets.org/">wxWidgets, version 2.8.12</a>,
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".</li><li>Though it has nothing to do with <i>building</i> Virtual AGC,
if you want to have access to Stephen Hotto's contributed Lunar
Module accessories when you <i>run</i> Virtual AGC, you'll also
have to <a href="https://www.tcl.tk/software/tcltk/">install
Tcl/Tk</a>. <br></li></ol>
Once this one-time setup is complete, you should now be able to
build Virtual AGC as follows. As above, all of the following
steps take place in the <b>Msys</b> command shell, and <u>not</u>
from a "DOS" command line:<br><ol style="list-style-type: lower-alpha;"><li>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.<br></li><li>Do "cd virtualagc".<br></li><li>Build it: "make WIN32=yes install" or "make WIN32=yes clean
install". <br></li></ol>
This process may or may not create a desktop launcher for
VirtualAGC. (If not, you can create your own launcher on the
desktop. Just have it run the program C:\Users\<i>YourUserName</i>\VirtualAGC\bin\VirtualAGC.exe,
and have it use C:\Users\<i>YourUserName</i>\VirtualAGC\Resources as
the starting directory.)<br><br>
You can "uninstall" simply by removing the desktop icon and
%HOMEPATH%\VirtualAGC, and whatever source-folder you downloaded
from GitHub.<br><h3><a name="WebAssembly"></a>WebAssembly</h3><table summary="" cellspacing="2" cellpadding="2" border="1"><tbody><tr><td valign="middle" align="center"><img alt="" src="greenCheckmark.png" width="72" height="75"><br></td><td valign="middle" align="center"><big><big><b>This works!</b><small><small><small><i><br>
Last verified (RSB): 2021-05-26</i></small></small></small><br></big></big></td></tr></tbody></table><p>I probably don't need to describe what <a href="https://webassembly.org/">WebAssembly (Wasm)</a> 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. <br></p>WebAssembly builds of Virtual AGC don't provide the entire Virtual AGC suite of programs, but merely the AGC CPU emulation (<b>yaAGC</b>). So the idea is that you can load the WebAssembly build of <b>yaAGC</b> into an HTML web-page you create, along with a core-rope images of an AGC program, and then run the whole thing in a suporting browser of your choice. Of course, your web-page will also have to provide its own simulation of a DSKY or whatever other of the AGC's peripherals you desire. In principle, I suppose, you could build an entire CM or LM simulation within your browser.<br><p>Many thanks to Michael Franzl for creating this Virtual AGC port. Note that <a href="https://github.com/michaelfranzl/webAGC">Michael's code is provided in a separate repository (webAGC)</a>, rather than being integrated within the Virtual AGC software repository. Additionally, it includes <a href="https://github.com/michaelfranzl/webAGC/tree/dev/demo">demo code for integrating webAGC into your website</a> (including a DSKY model) as well as a <a href="https://michaelfranzl.github.io/webAGC/demo/">fun live demo</a>. Any description I would give of Michael's live demo would likely be obsolete by the time you read it, but it's worth noting that (at least at this writing) you have to use the live demo's "load program into fixed memory" option first, choosing between the Luminary099 program and the Validation program, and then you have to click the Run button to begin executing the AGC code. (Or the Step button instead, if you simply want to execute a single AGC instruction rather than to allow the AGC CPU to run freely.) Subsequently, you can use either the DSKY buttons or else the "DSKY key input" field to interact with the running AGC program. Luminary099 refers to the AGC program used in the Apollo 11 LM, while Validation is a "modern" AGC program originally written by me to test the simulated AGC CPU. Some very basic instructions for running <a href="index.html#Playing_with_Luminary_">Luminary099</a> or <a href="index.html#Running_the_Validation_Suite_">Validation</a> can be found on our website home page. <br></p><p>Of course, for some years there has already been a JavaScript port of Virtual AGC: <a href="https://github.com/siravan/moonjs">moonjs</a> by Shahriar Iravanian (<a href="http://svtsim.com/moonjs/agc.html">live demo</a>), which runs the Colossus 249 AGC program (Apollo 9 CM). Moonjs is based on <a href="http://asmjs.org/">a subset of JavaScript called asm.js</a>,
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 <a href="https://github.com/siravan/moonjs#compiling">build instructions for moonjs</a> are pretty straightforward, and I won't repeat them here. I should note that moonjs relies on <a href="https://emscripten.org/">emscripten</a> 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!<br></p><p>Here's my interpretation of <a href="https://github.com/virtualagc/virtualagc#webassembly">Michael's build instructions</a> for Linux Mint 19 or later, 64-bit. I personally normally use Linux Mint 17, but these instructions won't work in Mint 17 or earlier because of library-versioning problems. First, here are the one-time setups:<br>
</p>
<ul><li>Installation of cmake: "<tt>sudo apt-get install cmake</tt>" may work for you. However, if you end up needing to build wask-sdk from source (see below!) then you'll need cmake of at least 3.13. On Mint 19 you get only 3.10 from the official Mint repository, so you need to make some other provision for installing a later version of <a href="https://cmake.org/">cmake</a>. In the case of Mint 19, there are prebuilt installers you can download from the cmake website. For example, I installed a <a href="https://github.com/Kitware/CMake/releases/download/v3.20.2/cmake-3.20.2-linux-x86_64.sh">prebuilt cmake 3.20.2 from a script</a>.<br></li><li>Installation of wasi-sdk. Among other things this gets you the <b>clang</b> and <b>llvm</b> programs, each of which must be at least version 12. For the sake of argument let's suppose the installation directory will be ~/wasi-sdk. <i>Do not confuse the wasi-sdk version with the clang/llvm version!</i> Release 12 of wasi-sdk only contains clang/llvm 11 and you need clang/llvm 12.<br></li><ul><li>If wasi-sdk 13 has already been released at some point—which as of <i>this</i> writing it has not been—then you can simply download a prebuilt release 13 tarball:<br></li></ul></ul><blockquote><blockquote><blockquote><p><tt>cd ~/wasi-sdk<br>wget https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-13/wasi-sdk-13.0-linux.tar.gz<br>tar xvf wasi-sdk-13.0-linux.tar.gz<br></tt><tt>export WASI_SDK_PATH=~/wasi-sdk</tt></p></blockquote></blockquote></blockquote><ul><ul><li>But if wasi-sdk 13 has <i>not</i> yet been released, then you'll have to build wasi-sdk from source. Probably the latest version of code in the wasi-sdk repository would be fine, but to use the specific version we've tested, do as follows:</li></ul></ul><blockquote><blockquote><blockquote><p><tt>cd ~</tt><tt><br></tt><tt>git clone --recurse-submodules https://github.com/WebAssembly/wasi-sdk.git # about 1.5 GB download</tt><tt><br></tt><tt>cd wasi-sdk</tt><tt><br></tt><tt>git checkout a927856376271224d30c5d7732c00a0b359eaa45 # to use the specific version we've tested.</tt><tt><br></tt><tt>make<br></tt><tt>export WASI_SDK_PATH=~/wasi-sdk/build/install/opt/wasi-sdk</tt></p></blockquote></blockquote></blockquote><ul><li>Installation of <a href="https://github.com/WebAssembly/wabt">wabt</a>, <a href="https://github.com/WebAssembly/binaryen">binaryen</a>:<br></li></ul><blockquote><blockquote><p><tt>wget https://github.com/WebAssembly/wabt.git</tt><tt><br></tt><tt>cd wabt</tt><tt><br></tt><tt><i>... follow the instructions in the wabt README.md ...</i><br>sudo make install<br>cd ..</tt></p></blockquote></blockquote><ul><li>Installation of <a href="https://github.com/WebAssembly/binaryen">binaryen</a>.</li></ul><blockquote><blockquote><tt>wget https://github.com/WebAssembly/binaryen.git</tt><tt><br>cd binaryen</tt><tt><i><br>... follow the instructions in the binaryen README.md ...</i></tt><tt><br>sudo make install<br>cd ..<br></tt></blockquote></blockquote>In the instructions above, note that the executable program files for wabt and binaryen will end up in your /usr/local/bin directory, as opposed to /usr/bin, so you'll want to make sure that /usr/local/bin is in your <tt>PATH</tt>. Note also that although I called this a one-time setup, the environment variable <tt>WASI_SDK_PATH</tt> will remain set only in this particular
instance of the command line window, and will not persist if you open another
command line afterward. This lack of persistence only becomes a problem if you later need to compile the WebAssembly target for Virtual AGC again in a new command-line window, and hence need to set <tt>WASI_SDK_PATH</tt> again. But you may wish to permanently set this environment variable to avoid confusion later.<br><br>Actually building Virtual AGC's WebAssembly target is easy: Just '<tt>cd</tt>' into Virtual AGC source directory, as obtained from
GitHub, and then:<br><blockquote><tt>cd yaAGC</tt><tt><br></tt><tt>WASI=yes make [clean] yaAGC.wasm</tt><tt><br></tt></blockquote>The file yaAGC/yaAGC.wasm is what you actually need for your web page, so this is the end of the build process for Virtual AGC<br><br>Insofar as the details of how to run an actual web page using this yaAGC.wasm target are concerned, if you're a web expert you probably don't need any additional commentary from me. For someone with a lesser level of expertise, such as myself, perhaps a few more words need to be said. I'll confine my remarks to Michael's demo code, which is probably what you'd want to start with if you were creating your own web app. <br><ul><li>Clone Michael's webAGC code base onto your local computer. For example, use the command "<tt>git clone --depth=1 https://github.com/michaelfranzl/webAGC</tt>". 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.</li><li>Install <a href="https://nodejs.org">node.js</a> if you don't have it installed already. I don't know the version requirements, but Mint 19's repository provides version 8, which definitely does not work. I installed version 14 from the node.js website, and it works fine.</li><li>In the webAGC/demo/ directory, run "<tt>sudo npm i -g jspm@2.0.0-beta.7</tt>" (or presumably, any later version of <a href="https://jspm.org/">JSPM</a>). Then run "<tt>jspm install</tt>".</li><li>You now have to serve the webAGC/ directory via HTTP. There are apparently a number of ways to do this. Here are two:</li><ul><li>You could do a one-time install "<tt>sudo gem install webrick</tt>", and then run the server by "<tt>cd webAGC ; ruby -run -ehttpd . -p8000</tt>". I'm told that webrick must be at least v1.7, and if you have an older version of <a href="https://www.ruby-lang.org/en/">the ruby language</a> then by default it may have installed a version of webrick that's too old. However, explicitly installing webrick as I've shown here apparently upgrades webrick to the newest version. If you end up having problems running the simulation, you may simply have a version of ruby/webrick that's too old.<br></li><li>You could do a one-time install "<tt>sudo npm install --global light-server</tt>", and then run the server by "<tt>cd webAGC ; light-server --no-reload -p 8000 -s .</tt>". (Warning: Those familiar with node.js might think it's more natural to install http-server, and to use it in place of light-server. At least as of now, that does not work, so please do not do it.)<br></li></ul><li>Finally, you use a browser to browse to http://localhost:8000/demo/. Michael tells us that the browser must support "import maps", and tells us that Chrome 89 or later does so.<br></li></ul>Now, you may wonder why there's a need to run an HTTP server at all, when one could simply browse to "file:///<i>PathToWebAGC</i>/demo/index.html" rather than to "http://localhost:8000/demo/" and seemingly avoid HTTP entirely? In other words, why can't this demo, or presumably similar web apps, simply run entirely within the browser? I'll simply quote what Michael has told me:<br><meta http-equiv="content-type" content="text/html; charset=UTF-8"><blockquote><span style="color: rgb(106, 115, 125); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">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<span> </span></span><code style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, monospace; font-size: 11.9px; padding: 0.2em 0.4em; margin: 0px; background-color: var(--color-markdown-code-bg); border-radius: 6px; color: rgb(106, 115, 125); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">webAGC</code><span style="color: rgb(106, 115, 125); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;"><span> </span>demo is indeed a pure browser/client solution; it is completely unaware of a server.</span><br></blockquote>Which just reminds me of why I have always preferred <i>not</i> to become involved in web programming, and came away frustrated every time I was forced to do so.<br><blockquote><meta http-equiv="content-type" content="text/html; charset=UTF-8"></blockquote><h3><a name="iPhone" id="iPhone"></a>iPhone</h3><table summary="" cellspacing="2" cellpadding="2" border="1"><tbody><tr><td valign="middle" align="center"><img alt="" src="yellowQuestion.png" width="70" height="75"><br></td><td valign="middle" align="center"><big><big><b>Still okay?</b></big></big><br></td></tr></tbody></table><br>
For development snapshot 20090802 and later, it's possible to build
<span style="font-weight: bold;">yaAGC</span>—not the entire Virtual
AGC suite, just <b>yaAGC</b>—from (I guess) a Mac, if you've
downloaded an iPhone development kit. From the "I guess" in
the preceding sentence, you'll probably be able to deduce that I'm
just parrotting someone else's words and don't really know what I'm
talking about ... and you'd be right. The instructions and
mods necessary to do it came from Alberto Galdo (thanks,
Alberto!). If you try it and it doesn't work, blame me for not
implementing Alberto's instructions properly.<br><br>
To build, simply 'cd' into the yaAGC/yaAGC/ folder and do this:<br><br><div style="margin-left: 40px;"> make IPHONE=yes<br></div><br>
As for how useful <span style="font-weight: bold;">yaAGC</span> by
itself is, it's obviously only marginally useful until such time as
there's a DSKY. You should be able to do command-line
debugging, however, so you could in theory run and debug AGC code.<br><h2><a name="Running_the_Validation_Suite" id="Running_the_Validation_Suite"></a>Running the Validation
Suite of the simulated AGC<br></h2>
Having installed the software as above, you can test the emulated
CPU and DSKY using the "validation suite". <br><ol><li>Run the <span style="font-weight: bold;">VirtualAGC</span>
program, select "Validation suite" as the simulation type, and
hit the "Run" button.</li><li>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.<br></li><li>Press the PRO key on the DSKY. The OPR ERR light will go
off and the validation program will begin.<br></li><li>There is no indication that the test is running. The
test takes about 77 seconds.</li><li>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.)<br></li><li>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.</li><li>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.</li></ol>
If this doesn't work for some reason, refer to the trouble-shooting
info in the <a href="faq.html">FAQ</a>.<br><h2><a name="Some_Resource_Issues_on_Slower" id="Some_Resource_Issues_on_Slower"></a>Some Resource Issues on
Slower Computers, Such as Raspberry Pi<br></h2>
On new but slow computers like Raspberry Pi, or old computers such
as PowerPC-based Macs, the CPU utilization for Virtual AGC can be
rather high. Indeed if you ran every available option on an
early-model Pi, you could find yourself using close to 100% of the
CPU. For the default configuration of VirtualAGC (Lunar Module
AGC with DSKY and Telemetry but without abort system or IMU), I find
the following:<br><ul><li>Pi B+: 80% CPU utilization. <br></li><li>Pi 3: 40% CPU utilization.<br></li></ul><p>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 <i>once</i> 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:</p><blockquote> <tt>cd VirtualAGC/temp/lVirtualAGC/Resources</tt><tt><br></tt> <tt>./simulate</tt><br></blockquote><br><hr style="width: 100%; height: 2px;"><center> <br><span style="color: rgb(84, 89, 93); font-family: sans-serif;
font-size: 11.05px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
16.575px; orphans: auto; text-align: center; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display:
inline !important; float: none; background-color: rgb(255, 255,
255);"> This page is available under the <a href="https://creativecommons.org/publicdomain/zero/1.0/">Creative
Commons No Rights Reserved License</a></span><br><i><font size="-1">Last modified by <a href="mailto:info@sandroid.org">Ronald Burkey</a> on
2021-05-30.<br><br><a href="http://www.ibiblio.org"><img style="border: 0px solid
; width: 300px; height: 100px;" alt="Virtual AGC is hosted
by ibiblio.org" src="hosted.png" width="300" height="100"></a><br></font></i> </center><br>
</body></html>