Contents

• Prerequisites for Binary-Package Installation
  
• Downloads (source code package; Windows and Mac OS X binary packages)
• Installing binary packages
• Linux
• Windows
• Mac OS X
• Raspberry Pi (Raspbian)
  
• Contents of the development snapshot
• Extras! (Optional stuff requiring manual setup)
• AGC/AEA Source-Code Syntax Highlighting
• gdb-compatible AGC/AEA debugging
• One-time setup procedure for Code::Blocks
• Project-creation procedure for Code::Blocks
  
• Building the Virtual AGC software
  
• Linux
• Raspberry Pi (Raspbian)
  
• FreeBSD
• Solaris
• Mac OS X
  
• Windows
• iPhone
  
• Cross-compiling
  
• Running the Validation Suite of the simulated AGC
  
• Some platform-specific odditities
  

Prerequisites for Binary-Package Installation

• All platforms:  Install Tcl/Tk if not already installed.  I don't know how pervasive a problem it is—i.e., which operating systems or versions of Tck/Tk it affects—but in recently trying to install Tcl/Tk on Microsoft Vista, I found that the installation program does not create a file called "wish.exe", but instead creates a file called "wish85.exe".  This prevents certain features of Virtual AGC from working.  In the case of Windows Vista, I fixed it by duplicating the file "c:\tcl\bin\wish85.exe" and calling the duplicate "c:\tcl\bin\wish.exe".  Sorry about this, but I don't honestly see what I can do about it.
  
• Linux:  The X-Window system, xterm, and gtk+ libraries must be installed.
  
• Operating systems:
• Mac OS X: 
  
• 10.4 and later, Intel and PowerPC, are believed to work.
  
• 10.2 or prior is known not to work.
• Windows:
• XP is known to work.
• Vista and Windows 7 are known to work but various workarounds need to be applied and some patience may be needed.
  
• Windows 98 or prior is known not to work.
• Only 32-bit systems were tried; the behavior on 64-bit systems is unknown.
  
• Others (2000) are untried and unknown.
  
• Linux 'x86:
• Fedora Core 4 and later versions are believed to work; Fedora Core 1 is known not to work.
  
• Ubuntu 7.04 and later versions are believed to work.
• SuSE 10.1 and later versions are believed to work.
• Both 32-bit and 64-bit systems seem okay.
  
• Other distributions and earlier versions of those listed above: untried and unknown.
• FreeBSD:
• Currently, I am working only with PC-BSD 7.1, which is based on FreeBSD 7.2.  In the past it worked also with PC-BSD 7.02, which is based on FreeBSD 7.1.  There is no binary package for this platform, but if built from source it seems to work.
  
• OpenSolaris:
• Currently, I am working only with OpenSolaris 0811.  There is no binary package for this platform, but if built from source it partially works.  I'm not satisfied with it at this point.
  

Downloads

• Installation is faster and better-behaved if some auxiliary requirements like Tcl/Tk aren't installed.
• Better compliance to Linux standards, such as installation under /opt.
• Better permissions settings for some files.
• Easier upgrade.
  

Installing binary packages

Linux

Windows

Mac OS X

Raspberry Pi (Raspbian)

Contents of the development snapshot

Extras!  (Optional stuff requiring manual setup)

AGC/AEA Source-Code Syntax Highlighting

gdb-compatible AGC/AEA debugging

One-time setup procedure for Code::Blocks

• For a default Linux binary installation:  "~/VirtualAGC".
• For a default Win32 binary installation:  "c:\Program Files\Virtual AGC".
• For a default Mac OS X binary installation:  "~/VirtualAGC.app/Contents".
• For a native build from source code, it's more complex, but could be:  "yaAGC/VirtualAGC/temp/lVirtualAGC".

1. Install Code::Blocks for your desired development platform.  (If you are developing/debugging your AGC/AEA code in Linux, Code::Blocks may be in your Linux distribution's packaging system.)
2. Installation of AGC/AEA syntax-highlighting enhancement for Code::Blocks:
1. Copy the contents of InstallDir/Resources/SyntaxHighlight/CodeBlocks/lexers/ to the lexers/ folder of your Code::Blocks installation:
1. For a default Linux installation:  "/usr/share/codeblocks/lexers".
2. For a default Win32 installation:  TBD.
3. For a default Mac OS X installation:  TBD.
2. Run Code::Blocks.
   
3. Verify installation of syntax-highlighting by selecting Settings/Editor/Syntax-highlighting from the main menu.  If "AGC Assembly" and "AEA assembly" are among the choices in the language-selection drop-down list, then the syntax-highlighting enhancement has been installed properly.
3. Configuration of AGC toolchain:
1. From the main menu, select Settings/Compiler-and-debugger.
2. In the Global-compiler-settings section:
1. Make sure that "GNU gcc Compiler" is the "Selected compiler".
2. Click the "Copy" button and in the "Add new compiler" pop-up window that appears, choose the name "AGC yaYUL Assembler".
3. In the "Compiler Flags" tab, make sure that no flags are enabled.
4. In the "Toolchain executables" tab (which you may need to scroll rightward to find):
• For Mac OS X only, in the "Additional Paths" tab next to the "Program Files" tab, add the path "InstallDir/MacOS".  (All of the other settings below are in the "Program Files" tab and apply to all platforms unless stated otherwise.)
  
• For the "Compiler's installation directory" choose InstallDir.
• For the "C compiler", "C++ compiler", "Linker for dynamic libs", and "Linker for static libs" choose either "yaYUL" or "yaYUL.exe" depending on your platform.
• For the "Debugger", set "yaAGC" or "yaAGC.exe" depending on your platform.
• Leave the "Resource compiler" setting blank.
• For Win32, you may will probably need to change the "Make program" setting whatever 'make' you're actually using, and to add the path in which it is located to the "Additional Paths" tab.
  
• For FreeBSD only, if you are using GNU make rather than the default 'make' provided by the operating system, change the "Make program" setting to "gmake".
  
4. Configuration of AEA toolchain:  Not implemented yet.

Project-creation procedure in Code::Blocks

Building the Virtual AGC software

Linux

I would recommend reading the instructions at the GitHub repository, which (of course) cover building from a Git clone of the code base.  However, the following are some older (though extremely-similar) instructions related specifically to building from the development snapshot tarballs.

Raspberry Pi (Raspbian)

• Tested with the 2016-05-27 version of Raspbian-Jessie.
  
• The build goes a lot faster if you do it on (say) a physical hard disk on the USB port, rather than on the standard SD card.

You can then do the following, from a command line:

sudo apt-get install wx2.8-headers libwxgtk2.8-0 libwxgtk2.8-dev libsdl-dev libncurses5-dev liballegro4-dev git
git clone https://www.github.com/rburkey2005/virtualagc
cd virtualagc
make

cd VirtualAGC/temp/lVirtualAGC/Resources
../bin/VirtualAGC

• 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 — takes 25-30% of the CPU (for either of the two Pi models mentioned above) by itself.  Tou don't really need to run it if you don't want to.  So:

• 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

• If you're more-adventurous, and more programming-savvy, there may be a way to get various programs, but specifically yaAGC and yaAGS, to use less CPU cycles, at the cost of less accuracy time-wise.  At various places in the program suite, individual programs are put to sleep using the nanosleep() function, specifically to avoid using CPU cycles.  So if you search for "nanosleep", you'll often find nanosleeps with of req.tv_nsec=10000000 nanoseconds, or 10 milliseconds.  Selectively changing some of those to (say) 100 milliseconds (100000000) or even 250 milliseconds (250000000) might reduce the CPU utilization of those particular programs.  If you do try it and it works better for you, let me know!

FreeBSD

• I installed wxWidgets 2.8.9 from source into /usr/local.  You have to do something beyond my understanding to get the system to find libwx*.so* at runtime.  I managed to monkey it into working, but I'm not sure what I did, and you FreeBSD users are unlikely to care about my wrong methods anyhow.  Please let me know the answer if you find one.
  
• I installed GNU readline 6.0 from source into /usr/local.  (As a BSD kind of person, you may be tempted to install the BSD-licensed editline library instead, but it is not fully feature-compatible and cannot be used.)
• I found that libSDL was already installed.
• I installed Tcl/Tk ("pkg_add -r tk-wrapper").
  
• I unpacked the Virtual AGC snapshot tarball ("tar --bzip2 -xf yaAGC-dev-YYYYMMDD.tar.bz2").
• I cd'd into the yaAGC/ directory and built ("gmake FREEBSD=yes").  Do not "configure" and do not "gmake install".

Solaris

• I installed (or happily accepted the pre-installation, as the case may be) the following packages, using the package system:
• SUNWgnome-common-devel
• SUNWGtk
• SUNWxorg-headers
• FSWxorg-headers
• SUNWncurses
• SUNWtcl
• SUNWtk
• SUNWlibsdl
  
• Installed GNU readline 6.0 from source into /usr/local.
• I installed wxWidgets 2.8.9 from source into /usr/local, configuring with "configure --disable-shared".  (While there is a package called SUNWwxwidgets which can be installed from the package system, in the version I tried the switches produced by `wx-config --cxxflags` are incompatible with gcc, so I eliminated it.  Your luck might be better.)  The Virtual AGC makefiles are simply going to take the first wx-config found in the PATH, so the present makefiles may be too simple for you if you have more than one version of wxWidgets installed.
• I installed Allegro 4.2.2 from source into /usr/local, configuring as "configure --enable-shared=no --enable-static=yes".
  
• I put /usr/local/bin into my PATH, or otherwise somehow get /usr/local/bin/wx-config linked into your PATH.
  

• Unpack the Virtual AGC snapshot tarball ("tar --bzip2 -xf yaAGC-dev-YYYYMMDD.tar.bz2").
• Then 'cd' into the yaAGC/ directory and build ("make SOLARIS=yes").  Do not "configure" and do not "gmake install".

Mac OS X

1. Mac OS X 10.5 includes wxWidgets 2.8.4, which in theory is too early a version.  Nevertheless, it appears to work and I won't quibble about it.  Mac OS X 10.4 includes wxWidgets 2.5, which is definitely (I think) not going to work, so you'll want to install wxWidgets 2.8.9 or later; probably you'll need to do this from source.
2. SDL, which is needed for the joystick handler program (yaACA3) is also pre-installed, but I haven't figured out how to use it.  (Hint: if from a command line a program called "sdl-config" is in your PATH, you don't need to install SDL; if it isn't, then you do.)  So what I did was to download the source tarball, unpack it, configure it ("./configure"), build it ("make"), and install it ("sudo make install").  This puts SDL into /usr/local, where it won't conflict with your already-installed version.
3. From a command-line, cd to some (preferably empty) working directory and unpack the Virtual AGC development-snapshot tarball ("tar -xjf yaAGC-dev-YYYYMMDD.tar.bz2"), thus creating a sub-folder called yaAGC/ containing the Virtual AGC source tree.
4. Browse to the web to download the Terminator application's dmg file.
5. Double-click the Terminator dmg file, and once it's open find the Terminator application ().
6. Drag the Terminator application from the open dmg file to the working directory in which you created yaAGC/ in step 3 above.
   
7. From a command line in that working directory, make a tarball from Terminator.app ("tar -cjvf Terminator.app.tar.bz2 Terminator.app").  Once you have the tarball, you can eliminate the Terminator app itself, along with its dmg file.
   
8. From the working directory (not from within the yaAGC/ directory) you would build Virtual AGC using the command "make -C yaAGC MACOSX=yes".  In the  folder yaAGC/VirtualAGC/temp/, you should now find the VirtualAGC application ().
   
9. If you like, drag the VirtualAGC application from yaAGC/VirtualAGC/temp/ to the desktop.  (It's better to drag rather than to use a 'cp' command, to make sure that Mac OS X admits that the folder is actually an application.)
   
10. You're ready to go!

Windows

1. Install the MinGW compiler, using the downloadable setup.exe file.  Use the default choices for installation directory, etc.  Among the options you should choose (if given the choice) are installation of the g++ compiler and of make.
2. Install the Msys (Linux-like command shell) environment using the downloadable setup.exe file.
   
3. Run Msys, to bring up a command shell.  If you are unlucky enough to have a Windows user name containing spaces, you will encounter difficulties.  For example, my home directory in Msys is "/home/Ron Burkey", and this messes up some of the build steps that need to be performed.  My solution to this was to create a directory called "/home/rburkey" and to 'cd' to that directory whenever starting up Msys.  It would also be wise to change the value of the HOME environment variable to reflect this change.  When I refer below to your "home directory", I mean whatever your equivalent of "/home/rburkey" is.
   
4. Install the SDL library.  You should find that there is a download file specifically labeled as a Win32 development package for MinGW.  Within your Msys home directory, unpack the download file, 'cd' into the directory it creates, and run the command "make install-sdl prefix=/usr/local".  The /usr directory withing Msys will probably correspond to something like c:\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.
5. Obtain a source tarball of wxWidgets.  At present, Virtual AGC binary packages are always built with wxWidgets 2.8.9, so 2.8.9 is a safe choice though it is not the only choice which works.  Unpack the tarball in your home directory, 'cd' into the directory this creates, and then do "./configure", "make", and "make install".  The "configure" step will accept various command-line options that select unicode vs. ansi, static linking vs. dynamic linking, etc., but the default options seem to work fine.
6. Install POSIX Threads for Windows ("pthreads").  There may be a number of methods that work, but here is what I did:  Unpack the source tarball, 'cd' into the directory it creates, then run the command "make clean GC-inlined".  This creates various files that you should copy into /usr/local as follows:  copy *.dll into /usr/local/bin; copy *.h into /usr/local/include; copy the single libpthread*.a file created into /usr/local/lib and rename it libpthread.a.
7. Install GNU readline for Windows.  You should find zipfiles of both "binaries" and "developer files" are available for download.  They should both be downloaded and unpacked into /usr/local.  (I.e., each zipfile contains directories like bin/, include/, lib/, and so on, and we want these to be merged into /usr/local/bin/, usr/local/include/, etc.)
8. Install a regular-expression library.  The MinGW project has a "contributed" regex library ("libgnurx") that you can use.  Download both the "bin" and "dev" tarballs and unpack them into /usr/local.
   

1. Unpack the development tarball in your home directory: "tar -xjvf yaAGC-dev-YYYYMMDD.tar.bz2".
2. Build it: "make -C yaAGC WIN32=yes".
3. On Windows 7  (but not on XP) I found it necessary additionally to copy c:\MinGW\bin\mingwm10.dll to yaAGC/VirtualAGC/temp/lVirtualAGC/Resources/.  Whether this is a difference between Windows 7 and XP, or whether it's some ghastly improvement to MinGW since the time I installed it last on XP, I can't say at the present time (and am not too motivated to figure out).
   

iPhone

Cross-Compiling

1. The oldest Linux on which I've made this work is Fedora Core 5, so presumably any newer Linux would be okay.  You will need the normal gcc C/C++ compilier toolchain, as well as developer packages ("dev" or "devel") for wxWidgets (2.8.9 or later), SDL, and Allegro.  These are all available in the package repositories of the recent common Linux distributions, though figuring out what the package names are can be an adventure.  Or, you can install them from source .
   
2. Download the installation tarball for the Windows/Mac cross-compiling environment called I'm Cross!  Please use version 20090426 or later.
   
3. In an empty directory (which for the sake of argument I'll call ~/Projects), unpack the I'm Cross tarball.  This will give you a directory called ~/Projects/IMCROSS/.
4. Within ~/Projects/IMCROSS/ create a text file called Makefile.override-settings containing the following line:  "NO_SDL=".
   
5. Install I'm Cross! using the instructions on the I'm Cross! website, noting in particular that you may have to install some additional software to insure that the Mac OS X tools and libraries are installed.  However, do not customize the I'm Cross! installation, since Virtual AGC is designed to accept the I'm Cross! defaults.  This is the part that takes a long time, and a lot of bandwidth and disk space.  The good news is that you can walk away from it and let it do its job unattended.
   
6. Unpack the Virtual AGC development snapshot (yaAGC-dev-YYYYMMDD.tar.bz2) someplace.
7. Browse to the web to download the Terminator dmg file.  In theory you may be able to 'mount' this in Linux, but I simply opened it in Mac OS X.  Inside, you'll find an application called "Terminator", which (considering the way Mac OS X works) is actually a folder called "Terminator.app".  Make a tarball from this ("tar -cjvf Terminator.app.tar.bz2 Terminator.app"), and copy Terminator.app.bz2 to the parent directory on your Linux box where you unpacked the Virtual AGC development snapshot.  (In other words, Terminator.app.tar.bz2 and yaAGC/ should be in the same directory.)
   
8. Back on Linux again, 'cd' into the yaAGC/ directory created by unpacking the tarball.
9. Do "make all-archs".
10. In the directory yaAGC/VirtualAGC/, you'll find the binary-installation packages for Linux (VirtualAGC-installer), Windows (VirtualAGC-setup.exe), and Mac OS X (VirtualAGC.app.tar.gz).

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 platform-specific oddities

• Very slow machines.
• You may find that the simulation uses >100% of the available CPU, particularly if the Tcl/Tk-based LM-Simulator component is being used.  I fear that the only workaround for this at present is to turn off the interfaces of the simulation which you don't need.
• You may find that the simulation (and particularly LM-Simulator) aborts at startup, possibly with a pop-up box indicating that there is a failure to connect to yaAGC.  This problem is caused by the time needed to start the various program components.  You can introduce extra delay before these checks are performed by editing a pair of files in the installation directory (by default, ~/VirtualAGC/Resources in Linux, c:\Program Files\Virtual AGC\Resources in Windows, or ~/Desktop/VirtualAGC.app/Contents/Resources in Mac OS X).  In the file SimStop, change "sleep 5" to "sleep 30".  In the file VirtualAGC.tcl, change "after 5000" to "after 30000".  These change some 5-second delays to 30 seconds.
• Networking must be properly configured, even though Virtual AGC does not by default communicate with other computers, because Virtual AGC uses TCP ports which Virtual AGC uses to interconnect the various bits and pieces of the simulation.  So if you don't have a network card or wireless, it may be difficult to get Virtual AGC to work.  Specifically:
  
• If you have SE Linux (or I guess, the equivalent security features in Windows/Mac OS X) enabled, it may block Virtual AGC from using networking as being an untrusted application.  (I believe that most modern Linux distributions, such as Fedora, enable SE Linux functionality by default.)  Personally, I have no need for SE Linux , so I always just completely disable it, and hence I can't give you much additional insight into details about reconfiguring it, but I presume there's some way to identify the bits and pieces of Virtual AGC (namely VirtualAGC, yaAGC, yaAGS, yaDSKY2, yaDEDA2, yaTelemetry, and Tcl/Tk) as being trusted applications.
• If you have a personal firewall software enabled, it may block the TCP ports which Virtual AGC uses.  The ports in question are (by default) 19697-19706, 19797-19806, and 19897-19906.  I generally just disable personal firewalls on my computers since I'm always behind a physical firewall anyway, but usually there's some sort of a GUI configuration program you can run to open holes in the firewall for specific TCP ports.
• By default, it is generally possible when making network connection to refer to a computer either by the host name you assign it when you install the operating system, or by the default name "localhost".  Virtual AGC uses the latter.  I am told that there are some conditions, possibly having to do with the use of wireless (though the problem has been reported to me as a problem with the Network Manager on Fedora 11 Linux), in which the computer cannot be accessed using the default name "localhost".  Hence Virtual AGC fails.  In Linux, this can be gotten around by adding the line "127.0.0.1 localhost" in the file /etc/hosts.  (If the line "127.0.0.1 something" already exists, then just add "localhost" to the end of it.)  I presume that you can diagnose both the problem and verify the fix by trying "ping localhost" from a command line.  Thanks to Onno Hommes for pointing out this problem and the fix for it.
  
• Linux, installed from binary package
  
• Fedora Core 1—the VirtualAGC binary distribution is unusable on Fedora Core 1.  I believe that a build from source does work.
• Fedora Core 4, 32-bit—no oddities noted.
• Fedora Core 5, 32-bit—no oddities noted.
• Fedora 10, 32-bit—some odd fonts and odd positioning of text was noted, but nothing that would make Virtual AGC unusable.  Fedora 10 is extremely odd in that it does not install xterm by default, and if you don't install it yourself you'll find that a number of VirtualAGC features don't work.  (Thanks to Onno Hommes for noticing this!)  I also have a report that the joystick configurator does not work properly even when xterm is added, but it worked for me.
  
• Ubuntu 7.04, 32-bit—no odditites noted.
• Ubuntu 8.04, 64-bit—no oddities noted.
• Ubuntu 8.10, 32-bit—no oddities noted.
• OpenSUSE 10.1, 32-bit—no oddities noted.
• OpenSUSE 11.1, 32-bit—the KDE 4 desktop system refused to admit that the installer program (VirtualAGC-installer) was an executable program, so it was necessary to run the installer from the command-line rather than by clicking on its desktop icon.  Moreover, the installer could not be run unless a software package called "itcl" (which is present on the OpenSUSE distribution disk) was installed.  Fortunately, the installer ran normally, and the KDE 4 desktop did recognize VirtualAGC itself as an executable program after installation.  Positioning of text in some of the VirtualAGC screens was somewhat unusual, but not unusable.
  
• Windows, installed from binary package
• Windows 95, 98—VirtualAGC is unusable on Windows 95 or 98, even if it could be built from source there.  The reason is that none of the batch files created by Virtual AGC are compatible with the command shell in Windows 95 or 98.  It is possible that individual programs like yaAGC or yaDSKY2 may be usable there if controlled from the command line rather than from the VirtualAGC GUI, but I no longer have any means of verifying or denying this.
• Windows 2000—unknown.
• Windows XP—
• Windows will sometimes (but not always) pop up a warning window asking whether it should "block" or "unblock" yaAGC or yaAGS—presumably because they are servers and therefore might do Very Bad Things to your computer.  I think the only thing the "block" does is to prevent network access via a firewall, and since usually all of your Virtual AGC servers and clients are running on the same computer anyway, it doesn't really matter whether you block or unblock: it seems to work fine either way.
  
• Some of the programs (such as the telemetry monitor) may not always be closable from the operating-system-supplied controls around the border of the windows.  However, they will close down normally if (for example) you close the DSKY.
• The yaACA program is unusable, because if its window loses focus it is unable to access the joystick thereafter.
• Windows always displays a message when yaACA2 shuts down that it has experienced "a problem" and asks whether or not you want Microsoft informed.  Well, I don't know why the message appears, but yaACA2 seems to work well enough for our purposes.  Neverthless, if the message annoys you, you should use the default yaACA3 anyway (assuming that it works for you).
  
• The main GUI programs (yaDSKY2, yaDEDA2, yaTelemetry) don't seem to produce any console output, so if you run them from a command line—say, "yaDSKY2 --help"—you won't see any messages.  I believe that you may still be able to see something if you pipe the output into a file—as, for example, "yaDSKY2 --help >temp.txt".
• The "debug" mode for the yaAGS program displays no prompt, but otherwise seems to work properly.
• The "debug" mode for the yaAGC program sometimes displays garbage characters upon pressing keys at startup.  However, the commands being entered by the keystrokes are interpreted correctly and after executing a command or two it settles down and works properly.
  
• If using the command-line debug modes for yaAGS or yaAGC, their terminal windows will not close automatically when the other windows close, nor will yaAGC or yaAGS be halted.  You'll have to close those windows manually.
  
• Windows Vista and Windows 7—I do not have dedicated Windows Vista or Windows 7 machines on which to perform testing.  However, because of the continued complaints I've received about Vista, I have been able to do some limited testing with Windows Vista Home Basic and with the Windows 7 Release Candidate.  Additionally, I have received some notes on this subject from users of my Project Gutenberg Prettifier, GutenMark, whose programs are constructed using techniques similar to Virtual AGC.  So here are some things that may or may not be useful to note:
•  Jim Adcock (thanks, Jim!) sent word that it was necessary to change the properties of all of  the .exe files in the bin/ sub-directory of the installation directory (by default, "c:\Program files\VirtualAGC\bin') to "Run as Administrator".  I personally did not find it necessary to do this for Virtual AGC.
  
• A user identified only as "Wendl" (thanks, Wendl!) sent word that it was additionally necessary to change the properties of the .exe files to select compatibility with XP Service Pack 2.  I personally did not find it necessary to do this for Virtual AGC.
• Brendan O'Rourke (thanks Brendan!) has pointed out that an error "Cannot create file simulation.bat" occurs when trying to run the simulation.  I have found that this may  not happen at first, but may begin happening after Windows is shut down and then restarted again later.  The problem appears to be that Windows is not consistent in the permissions you are given, so you are fooled into thinking that Virtual AGC works, but only later find that you don't have the proper permissions to run it.  Here is the fix:
1. 
2. 
3. 
   

• File dialogs may not open to the proper folders.  For example, in trying to select a source-code file to assemble, I've found that the file dialog opens at Resources\scenarios, whereas it is supposed to open at Resources\source.
• The command-line debug modes for yaAGCandyaAGSmay sometimes display garbage at first when you type at the keyboard, though eventually starts properly displaying keystrokes.  Unfortunately, unlike other versions of Windows in which this is merely an annoyance, in Vista/Win 7 it may instead cause the simulation to abort.  I've had pretty good luck working around this by hitting a few carriage returns before typing in the first actual debugging command.
  

• Windows, natively built from source
• The yaACA3 joystick-handler program cannot display the joystick readings, and therefore is hard to configure using the "Handler" functionality.  (Also, after trying to configure it with "Handler", it remains running rather then being closed down, and you have to manually terminate it by using ctrl-alt-delete to bring up a process list.)  In spite of these quirks, it does actually work properly when running a simulation.
• AGC/AGS program listings may or may not align at the proper tab-stop positions when viewed in a browser.
  
• Mac OS X, installed from binary package
  
• All—Mac OS X insists on opening all of the windows (DSKY, DEDA, telemetry monitor, etc.) exactly atop each other, so that on each run you have to manally move the windows around in order to see them.
• 10.2 and prior—the VirtualAGC binary distribution is unusable on these platforms.
  
• 10.3.9 and 10.4.11 (PowerPC)—
• The IMU (LM-Simulator) does not seem to respond to the hand-controller (yaACA3), even though both of them appear to work individually.  This may have something to do with the fact that the iMac I'm running it on is old and very slow.  (The simulation takes >100% of the CPU time.)
• The AGS/DEDA pair of programs seems to intermittently freeze up and require rebooting.  I suspect that this is because on the old 400 MHz G3 I'm using the CPU loading is at 300%, and there are some timing requirements on AGS/DEDA communications that aren't being met.  But I'm not sure, and it could be a different bug.
• 10.3.9 (PowerPC)—
• The file-save and file-open dialogs for core-dump saves and opens, and for Digital Uplink, refuse to navigate to the proper directory (by default, ~/Desktop/VirtualAGC.app/Contents/Resources/scenarios/); it may be advisable to copy or link this directory to the Desktop or some other accessible location if you wish to use these features. 
• Can't run yaAGC or yaAGS in --debug mode from VirtualAGC.
  
• 10.5.6 (Intel)—In spite of my best efforts, I've seen instances in which the LM-Simulator portion of the simulation suite does not shut down when the remainder of the simulation shuts down, and needs to be terminated manually from its menu.
• Even on my fastest box (which is a Core Duo Mac Mini), LM-Simulator runs at fractional speed, and is therefore useless (whilst the remainder of Virtual AGC proper is running fine at full speed).  I suspect an incompatibility in Tcl/Tk.
• The "debug" mode for the yaAGS program displays no prompt, but otherwise seems to work properly.
• The "debug" mode for the yaAGC program sometimes displays garbage characters upon pressing keys at startup.  However, the commands being entered by the keystrokes are interpreted correctly and after executing a command or two it settles down and works properly.
• Mac OS X, built natively from source
• The "Retro" display mode of the yaTelemetry program may not work.
  
• FreeBSD, natively built from source.
• For joystick handling, yaACA3 works, but yaACA2 and yaACA do not.
• There is some unusual horizontal positioning in some text which is supposed to be centered.
• The crossed-out sub-items are observations of problems which I no longer observe.
  
• When running yaAGS in command-line debug mode, there is no command-line prompt, except that one appears sometimes after hitting the carriage-return.  Nevertheless, it seems to work properly otherwise.
• Source browsing does not seem to work from VirtualAGC, because the paths to the html files (which exist!) aren't constructed properly.
• Nor does assembly of source code from VirtualAGCwork, presumably for the same reason (badly-constructed paths).
  
• What success I had was with PC-BSD 7.1.  I was previously able to build on PC-BSD 7.02, but have not had a working setup for a while to see if it still works in 7.02.
• Solaris.
• Only OpenSolaris 0811 has been tried.
• There is some unusual horizontal positioning in some text which is supposed to be centered.
• No joystick-handler program is available.  (yaACA2 doesn't build, while yaACA and yaACA3 build but don't work ... at least for me.)
• Redrawing of graphical objects seems intermittent.  For example, some digits on the DSKY might get updated, and others might not.
• The telemetry-display program never displays any telemetry.
• In command-line debug mode, yaAGC and yaAGS spontaneously abort and end the simulation.
• Sometimes there is a spurious i/o command; for example, when running the "validation" program on the AGC, the it often seems as if it starts out with the PRO key pressed.
  
• It appears to me that several of these phenomena may be due to data being lost or otherwise corrupted in the socket system; perhaps some of the socket uptions I'm using aren't as portable as I imagined.
• Assembly doesn't work from within the VirtualAGC environment.  I suspect that the file-open dialogs in Solaris may cause the current working directory to change in ways I haven't been anticipating.

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2017-01-11.