                                                                   8/8/89
                         Santa Fe Institute's
         D O U B L E   A U C T I O N   T O U R N A M E N T


                       CHAPTER 2 -- THE SOFTWARE
                       -------------------------

This chapter describes the software available.  It also explains how to
obtain the software and documentation that you need, and how to start
setting it up on your own machine.  There are many details in this chapter,
but probably only part of it will apply to you.


                         2.1 Communication Methods
                         -------------------------
The first key to understanding the software is a knowledge of the
communication methods that can be used between the monitor and the
players.

Note that in all games there is one monitor and at least two separate
players.  The monitor and each of the players is a complete program in
itself; the players are NOT "subroutines" of the monitor.  The monitor
program and the player programs may run simultaneously (either on the same
computer or on different ones connected by the Internet), or one at a time.
The players each communicate only with the monitor, not directly with each
other.

The different communication methods are described below.  In each case we
show only one player communicating with the monitor, but in a real game
there would be more.  The monitor can support any mixture of communication
methods that are available on the computer concerned.

Certain facilities are only available to player programs based on the
skeleton programs written in C.  Such programs are referred to as "C players"
below, and include the human interface.

FILE-BASED COMMUNICATION

This is the slowest communication scheme but is available on all supported
systems.  It is the ONLY communication method available on an IBM-PC, or on
any other machine that can only run one program at a time.

Suppose the the player program is called PLAYER.  Then the following
sequence occurs for each step of the game:

     ---------
    | MONITOR |  ------------>   PLAYER.IN
     ---------                       |
                                     |
                                     |
                                    \|/
                                  --------
                                 | PLAYER | <----> PLAYER.SAV
                                  --------
                                     |
                                     |
                                     |
     ---------                      \|/
    | MONITOR |  <------------   PLAYER.OUT
     ---------

The monitor writes file PLAYER.IN and then starts up the PLAYER, which reads
it.  The player writes file PLAYER.OUT, which is then read by the monitor.
The monitor itself is suspended while the PLAYER is running.  The PLAYER
is started up separately for each step of the game, and exits after writing
PLAYER.OUT.  Because the PLAYER is not running continuously it must save
its working variables, either in a file called PLAYER.SAV as shown, or
(C players only) in PLAYER.OUT following the output messages.

This communication method is obviously very disk intensive, and also involves
many program launches.  It is not recommended when other methods are available.
On an IBM-PC it can actually be made fairly fast by placing the player programs
(and thus their .IN, .OUT, and .SAV files) on a RAM disk.  See the instructions
below.  On a Vax/VMS system it is extremely slow.

PIPE-BASED COMMUNICATION

This is the recommended communication method for use between the monitor and
each player when on the same multiprocessing machine.  The monitor and players
all run simultaneously, and communicate via "pipes" (or their equivalent, e.g.
"mailboxes" in VMS):

     ---------   -----------> (stdin)   --------
    | MONITOR |                        | PLAYER |
     ---------   <----------- (stdout)  --------

There is one pipe for each direction.  At the player's end these pipes are
arranged to look like the standard input and output channels, which would
normally be attached to the terminal.  Thus the player program can use simple
read and write operations without any special knowledge of pipes.

The monitor program is started up first and then starts up all the pipe-based
player programs.  They are technically "child processes" (Unix) or
"sub-processes" (VMS) of the monitor's own process.  The players keep
running until the end of the game or an error; for most errors detected by
the monitor the offending player will be "killed".

There is a modified form of pipe-based communication available only for the
C players and the human player. The player uses special channels
("descriptors") for the pipes, leaving its standard input and output free
for terminal communication.  This is essential for the human player.
This form of communication is called "arg-based communication" because the
descriptor numbers are passed via command-line arguments from the monitor to
the player when the player is started.

INTERNET-BASED COMMUNICATION -- DIRECT

Direct Internet communication is available only for the C players and the
human player.  It allows such players to connect to the monitor over a TCP/IP
Internet communication link:

     ---------                          --------
    | MONITOR |  <---- Internet ---->  | PLAYER |
     ---------                          --------
                                           |
                                          \|/
                                        display

The monitor and player programs are usually on different machines at different
locations.  The monitor is normally the one at sfi.santafe.edu, called the
Santa Fe Token Exchange (SFTE).  The monitor runs at a pre-arranged time
(every hour on the hour for the SFTE) and users start up their players at
the appropriate time at the remote sites.  The player program itself
establishes the connection to the monitor.  The player program can display
the progress of the game to the screen (or to a file) during the game.

INTERNET-BASED COMMUNICATION -- VIA DANI

The direct Internet-based method described above is only available for the
C players and human player.  For other languages the Double Auction Network
Interface (DANI) must be used:

     ---------                          ------             --------
    | MONITOR |  <---- Internet ---->  | DANI |  <----->  | PLAYER |
     ---------                          ------             --------
                                          |
                                         \|/
                                       display

DANI acts as a relay for messages between the player and the Internet.  It
can also display the progress of the game as it runs.  DANI and the player
can communicate by any of the non-Internet methods described above (file-
based, pipe-based, or arg-based).  The monitor is started first (at a
prearranged time), and then DANI is started at the remote site.  DANI
then starts the local player.  DANI can only support one player at a time.

DANI can also communicate with the player by some additional methods not
discussed here.  Please contact the organizers if you have a special need
not covered by the cases presented here.

Using DANI may sometimes be preferred over the direct Internet method even
for C players, because DANI's display format is more compact than the
C player's (which is designed primarily for the human player).


                     2.2 Outline of the Software Available
                     -------------------------------------
The software available for the Double Auction Tournament consists of the
following major parts:

  1. The monitor.  This is needed if you want to run double auction games
     on your local machine or network.  Without it you can only play games
     on the Santa Fe Token Exchange (SFTE), via the Internet.  This is
     available both in C source form and in IBM-PC executable form.

  2. The skeleton players.  You will certainly need one of these, in source
     form, if you plan to develop your own strategy (without it you can only
     play via the human interface on the SFTE, and cannot enter the
     tournament).  They are available in the following languages:

      C        for Unix, Vax/VMS, Unicos, Turbo-C, Quick-C
      Fortran  for Unix, Vax/VMS, Unicos, MS-Fortran, RyanMcFarland, Lahey
      Pascal   for Unix, Vax/VMS, Turbo-Pascal

     Using another language (e.g. Lisp, Ada, Basic) is possible for games on
     the SFTE (via DANI), but is not acceptable for tournament entries
     except by prior arrangement with the organizers.

     Using one of the above languages on a different system or compiler
     will not be difficult in most cases, though some features may be
     lacking.  Contact the organizers for advice.

  3. The human interface.  This allows you to play against computer
     strategies, either with your local monitor or on the SFTE.  The human
     player is available in C source form and in IBM-PC executable form.
     The C source actually shares much of the code of the C skeleton player
     and is packaged with it.

  4. DANI: the Double Auction Network Interface.  This is needed if you
     want to play on the SFTE using a player program based on the Fortran
     or Pascal skeleton players (or anything else but C).  It may also be
     useful even with the C players because its output display is compact.
     DANI is available in C source form only.

  5. PP: the simple pre-processor.  This is a program that processes another
     program performing file inclusion, parameter substitution, and conditional
     compilation (it recognizes a subset of the C preprocessor directives).
     It is needed if you want to use the Fortran skeleton player on a
     non-Unix machine.  It may also be useful for Pascal; see the README
     file for Pascal.  PP is available in C source form and in IBM-PC
     executable form.

  6. Networking software.  The programs described above have only partial
     networking ability.  The C players and DANI can contact the Santa Fe
     Token Exchange only, and the monitor supports only local players
     (on the same CPU).  Only one human player at a time can play in a
     local game, because it needs the login terminal.  To relax these
     restrictions, either to set up a networking monitor (your own token
     exchange), or to connect to a token exchange other than the SFTE, you
     need the full networking software.  THIS IS NOT NORMALLY DISTRIBUTED
     FREE TO PARTICIPANTS.  Contact the organizers for further information.

Note that while the skeleton players are available in several languages,
the rest of the software is only available in C or in IBM-PC executable
form.  However you should not need to understand or modify any of this C-only
software -- you will just need to compile it once on your system.  If you
don't have a C compiler please contact the organizers; we will attempt to
supply you with a binary executable for your machine.


                 2.3 Obtaining the Software and Documentation
                 --------------------------------------------
There are three basic ways to obtain the double auction software:

  1. Copy it electronically from the public directories of the
     sfi.santafe.edu computer at Santa Fe, using 'ftp'.

  2. Request floppy disks from Santa Fe.  This is most appropriate if
     you intend to run the software on an IBM-PC or compatible.

  3. Request that the software (and optionally the documentation) be sent
     to you by electronic mail from Santa Fe.

The documentation is all available in electronic form (as simple ascii
files), and can be included with any of the above methods.  Alternatively
you can request printed documentation from Santa Fe.

These methods are described in more detail in the following subsections.

OBTAINING THE SOFTWARE AND DOCUMENTATION WITH FTP

To obtain files from Santa Fe via ftp, follow the following steps:

  1. Connect to sfi.santafe.edu with ftp.  On most computers the command
     "ftp sfi.santafe.edu" will do this.

  2. Specify the user name "anonymous".

  3. Specify your own last name (up to 8 characters) as the password.  You
     should then get ftp's prompt (usually "ftp> ").

  4. cd pub

  5. cd dat

  6. If you plan to get the .tar.Z files or dos files (see below):  binary

  7. Use a combination of the following commands to get the files you need:

     a.  cd <directory>  to change to <directory> on the remote machine.

     b.  get <filename>  to copy <filename> to your machine.

     c.  mget <wildname> to copy all files matching <wildname> to your
                         machine.  E.g.  *.c matches all .c files.

     d.  prompt          to turn off prompting for each file; use
                         before mget if you want all matches.

     e.  ls              to list the files in the current directory.

     f.  lcd <directory> to change your local directory.

  8. quit

The organization of the directories and files in the pub/dat directory is
as follows (names with lines descending beneath them are directories):

     pub/dat
    |
    |--- README    (contains this chart and Notes)
    |--- directory (list of participants)
    |--- entries   (list of tournament entries)
    |--- mail      (correspondence sent to dat-list mailing list)
    |--- monitor.tar.Z
    |--- monitor
    |   |
    |   |--- *.c and *.h source files for monitor
    |   |--- Makefile, dmon.mak, dmon.prj
    |   |--- game, players
    |   |--- README
    |
    |--- players
    |   |
    |   |------ C.tar.Z
    |   |------ C
    |   |   |
    |   |   |--- *.c and *.h files for C players and human player
    |   |   |--- Makefile, *.com, *.mak, *.prj
    |   |   |--- helpfile (for human player)
    |   |   |--- README
    |   |
    |   |--- fortran.tar.Z
    |   |--- fortran
    |   |   |
    |   |   |--- *.F and *.h files for Fortran players (needs pp)
    |   |   |--- Makefile, Makefile.cray, make.com
    |   |   |--- README
    |   |
    |   |---- pascal
    |       |
    |       |--- skeleton.pas for Turbo Pascal
    |       |--- skeleton.p for Unix Pascal (pc)
    |       |--- skeleton.vms for Vax/VMS Pascal
    |       |--- skeleton.generic for any Pascal (needs pp)
    |       |--- Makefile
    |       |--- README
    |
    |---- misc
    |   |
    |   |---- dani.tar.Z
    |   |---- dani
    |   |   |
    |   |   |--- dani.c, inet.c (source files for dani)
    |   |   |--- Makefile, make.com
    |   |   |--- README
    |   |
    |   |----- pp.tar.Z
    |   |----- pp
    |       |
    |       |--- *.c, *.h source files for pp
    |       |--- Makefile, make.com
    |       |--- README
    |
    |----- doc.tar.Z
    |----- doc
    |   |
    |   |---- individual chapters of the documentation
    |
    |----- dos
        |
        |---- dmon.exe
        |---- gdmon.exe
        |---- human.exe
        |---- player.exe
        |---- pp.exe
        |---- *.bgi and *.chr files for gdmon (PC graphics)

Notes on the above:

  1. The .tar.Z files are compressed files that contain the whole directory
     listed immediately below them.  These are only useful if you have a
     Unix system with 'uncompress' and 'tar'.  If you have these you can
     do the following:

     a. Get the .tar.Z files you need USING THE BINARY MODE of ftp.

     b. Uncompress each file (e.g. "uncompress monitor.tar.Z").

     c. Unpack each file with tar (e.g. "tar xvpf monitor.tar").  This
        will make the directory concerned (e.g. monitor) within your
        current directory, and fill it with the files.

     d. Delete the .tar file.

  2. Most directories contain a README file.  Read this before attempting
     to compile.

  3. Many directories contain files with scripts for compiling and linking.
     'Makefile' is for Unix.  A .prj file is for Turbo-C.  A .mak file is
     for Quick-C.  A .com file is for Vax/VMS.  Read these files before
     using them; there may be things to customize.

  4. The dos directory contains executable binaries and graphics files for
     an IBM-PC.  See the following section for more details on these files.
     Be sure to use the binary mode of ftp to copy such files.  They can
     then be transferred to a PC in several ways (e.g. PC-NFS).  If your
     interest is just in the PC version, you'll probably find it more
     convenient to get floppies than to try this.



OBTAINING THE SOFTWARE AND DOCUMENTATION ON FLOPPY DISKS

If you use an IBM-PC or compatible, it is best to obtain the software on
floppy disks.  You may alternatively be able to use the ftp method, but
will then have to compile everything rather than receiving executables.

Ask for floppy disks by writing to:

    Double Auction Tournament
    Santa Fe Institute
    1120 Canyon Road
    Santa Fe,  NM 87501

Include media/shipping fee of $3 for floppy disks only, or $10 for floppy
disks plus complete printed documentation ($7.50 for documentation only).
The full documentation is included on the floppy disks (as simple ascii
text files) and is also available via ftp.

Unless you make a special request, you will receive two floppy disks
containing the following:

Disk 1:
    DMON.EXE    monitor without graphics
    GDMON.EXE   monitor with graphics
    *.BGI, *.CHR    graphics files used by GDMON.EXE (not needed if you
                have Turbo-C on your hard disk)
    HUMAN.EXE   interface to a human player
    HELPFILE    file of help information used by HUMAN.EXE
    PLAYER.EXE  sample player program (based on the C skeleton)
    GAME        sample gamefile, specifying game parameters
    PLAYERS     sample playerfile, specifying players in a game
    PP.EXE      simple preprocessor
    README.PP   instructions for PP.EXE

    PASCAL.DIR  directory containing the source for the pascal
                skeleton player:
                README           information about the Pascal versions
                SKELETON.PAS     Pascal source for the PC

Disk 2:
    C.DIR   directory containing the source for the C skeleton
            players, and the human player:
            README      instructions for compilation etc.
            SKELETON.C  skeleton player
            HUMAN.C     human player
            CONTROL.C   control routines for skeleton & human
            DEFINE.H    header file for skeleton & human
            *.MAK       Quick-C makefiles
            *.PRJ       Turbo-C makefiles
            TCCONFIG.TC Turbo-C configuration file

    FORTRAN.DIR directory containing the source for the Fortran
            skeleton player:
            README      instructions for compilation etc.
            SKELETON.F  skeleton player
            CONTROL.F   control routines for skeleton
            GLOBAL.H    header file
            SIXCHAR.H   file to reduce variables to six
                        characters, if necessary
            F77L.FIG    configuration file for Lahey Fortran

    DOC.DIR             directory containing  all  the  documentation  (except
                        that for DANI) in simple ascii text files.

Note that this does not include:

1. The source files for the monitor.
2. The source files for PP.
3. The source files and documentation for DANI.
4. Certain files not needed on a PC, but which may be needed or useful if you
   are merely using PC-floppies to transfer the software to another machine.

You should not need any of these for use solely on a PC.  If you request it
specially, we will send you "Disk 3" containing all the above files, including
a README file that explains its contents.  Please add $1 for this.

All floppy disks will be 5.25 inch, double-sided, double-density, 362K.

OBTAINING THE SOFTWARE AND DOCUMENTATION BY ELECTRONIC MAIL

This method should only be used if neither of the other two is available.
Send your request to:

    dat@sfi.santafe.edu

specifying:

1. Your name and institution.
2. Your e-mail address.
3. The type of machine(s) on which you want to run the Double Auction
   Tournament software.  Specify the operating system (e.g. Unix, VMS) too.
4. The language(s) you want to use for your players (C, Fortran, Pascal).
5. Whether you want the source for the monitor.  If you don't get this
   you can only play with the Santa Fe Token Exchange.
6. Whether you want to be able to play games with the Santa Fe Token
   Exchange.  This is only possible if your site has the appropriate TCP/IP
   software and hardware capability.

We will then send you the files we think you need.  No individual file
will exceed 50K.  Files will be bundled together into .shar files on a
Unix system; instructions will be included.  Note that binary files cannot
be sent via ordinary e-mail.


                              2.4 Getting Started
                              -------------------
There is a lot of software available, and a lot of documentation.  You will
not master it all at once.  We suggest the following approach:

FOR UNIX, VMS, ETC. USERS (MULTIPROCESSING MACHINES) -- SFTE USAGE

Before you do anything, try to determine if your machine has Internet TCP/IP
access using BSD 4.2 or 4.3 calls.  If it doesn't you cannot use the Santa
Fe Token Exchange; go to the next subsection.  If you can use "telnet" and
"ftp" on your machine you probably have the necessary access.  To find out for
sure, determine whether the following routines are available in your C run-time
library:

    socket()    connect()   inet_ntoa()
    htonl()     htons()     bcopy()     bzero()

The ones on the first line are the truly essential ones.  They may be in
a special library.  First try to find them via 'help' ('man' on a Unix
system).  Then, if that fails, ask an expert.  Note that for Vax/VMS there
are several implementations of TCP/IP; the Double Auction software currently
only supports the Wollongong WIN/TCP one.  If you have a different TCP/IP
implementation and want to use the SFTE, please contact the organizers.

If you do have the appropriate TCP/IP access, you can follow the following
suggestions to play a trial game with the SFTE.  Otherwise, or if the TCP/IP
access is dubious or needs work, proceed to the next subsection instead.

1. If you don't have printed documentation, print the appropriate files
   from the 'doc' directory.  To start with you'll want at least "intro",
   "software", and "players".

2. Get the source files for the C players (even if you ultimately want to
   use Fortran or Pascal).

3. Read the README file for the C players and follow the directions therein
   to compile and link the players using INETBASED; compile at least
   "inquire" and the human player (called "hi" or "human" depending on your
   system).  If you have difficulty just try to compile "inquire".  If that
   doesn't succeed please check that you followed the instructions (e.g. did
   you customize define.h?) and then contact the organizers (see "Getting
   Help" below).

4. Try running "inquire".  If it succeeds in connecting to the SFTE, you
   should get a message telling you about the schedule of games at Santa Fe,
   or a message that says a game is about to begin.  If instead it says
   (possibly after up to a minute or so of trying) that it couldn't connect
   to sfi.santafe.edu, the problem may either be with the network or with your
   machine's access to it.  Try again later, and keep on trying for a day or
   more before concluding that there's a real problem.  If you have the "ping"
   command, try "ping sfi.santafe.edu" -- if this responds with
   "sfi.santafe.edu is alive" then inquire should work too.  Asking a network
   expert may also help.

5. If "inquire" works, try running the human player.  Unless you use it at the
   right time (just before any hour), it should give the same message as
   inquire.  Using it just before the hour should allow you to play a game
   with the SFTE.  Study the "intro" and (at least briefly) "players" chapters
   of the documentation before attempting to play, but don't be afraid to
   experiment.  Use the "quit" command when you tire of playing.  As long as
   you completed at least the first period, you should receive a listing of
   the whole game by electronic mail after it is over.  Study this in
   conjunction with the "monitor" chapter of the documentation.  Please tell
   the organizers if you don't receive a game listing by electronic mail within
   a few hours of playing a game.

6. You can also try compiling and running a skeleton player (called "di" or
   "skeleton" depending on your system).  This is actually simpler than the
   human player.  When you run it at the right time it should play a game
   with the SFTE, displaying it as it goes.

7. You now have three directions in which to proceed:

   a. If you want to write in C, and only want to use the SFTE (not a local
      monitor), study the skeleton.c source file in conjunction with the
      "skeleton" chapter of the documentation.

   b. If you want to write in Fortran or Pascal, and want to use the SFTE,
      now is the time to compile and test DANI and the skeleton player in
      your chosen language.  See the appropriate README files and the "dani"
      chapter of the documentation.

   c. If you want to set up a local double auction monitor on your machine,
      follow the suggestions in the next subsection.

FOR UNIX, VMS, ETC. USERS (MULTIPROCESSING MACHINES) -- LOCAL MONITOR

In some ways this is the most complicated case because you must compile
both the monitor and at least one player before you can get anything going.

1. If you don't have printed documentation, print the appropriate files
   from the 'doc' directory.  To start with you'll want at least "intro",
   "software", "monitor", and "players".

2. Get the source files for the monitor and for the players in the language of
   your choice.  We recommend that you put the player files in a subdirectory
   of the directory containing the monitor files.

   If your language is not C, also get the C source for the human player.
   If your language is Fortran, also get the source files for 'pp' if you
   don't have a standard Unix system (see the Fortran README file).
   Make sure you also have any associated README files and makefiles.  Also
   make sure you have 'game' and 'players' for the monitor and 'helpfile' for
   the human player.

3. Compile the monitor.  See the README file for directions.  Try running it
   without any command-line arguments: it should read and list the parameters
   in the 'game' file, and then stop with a 'no active buyers or sellers'
   message.  If anything else happens, investigate before proceeding; first
   check that 'game' and 'players' are in the monitor's own directory and
   contain sensible parameters ('players' should not yet define any players).

4. Compile the skeleton player in the language of your choice.  See the
   appropriate README file for directions.  If you choose Fortran you may
   first need to compile 'pp'.  You will have to decide on your communication
   method, either FILEBASED or PIPEBASED; we recommend PIPEBASED for all Unix
   and VMS systems.  For other systems if you are the first person to try
   this software, it may be easier to start with FILEBASED.

5. Make a second copy of the compiled skeleton program with a different name
   (e.g. player2 or player2.exe as appropriate).  Simply copying it will work
   unless you are using FILEBASED communication and the program name has to
   be built into the program, in which case you'll have to recompile with the
   new name; see the appropriate README and source files for details.

6. Edit the 'players' file (in the monitor's directory) to specify your two
   players.  See the comments in the 'players' file and in the "monitor"
   chapter of the documentation.

7. Run the monitor.  Now a game between your two players should commence.
   Note though that games with only one buyer or one seller are not
   representative of the full game; many strategy issues do not arise.

8. Play with the following to familiarize yourself with the system:

   a. Adding more players.  Note that on many systems you can get away with
      using the same executable binary player program more than once in a
      game (simply specify it multiple times in the 'players' file).  This
      will never work for FILEBASED players though; these must always have
      unique names because the *.in and *.out message files must be unique.

   b. Changing the game parameters in the 'game' file.

   c. Controlling the monitor with single letter runtime commands (see the
      "monitor" chapter of the documentation.

   d. Sending the monitor listfile output to a file (this gives a different
      screen display); see the "monitor" chapter of the documentation.

9. Compile the human player.  See the directions in the README file from the
   C source.  Note that you need to customize 'define.h' differently for the
   human player and C skeleton players.  Define the human player in the
   'players' file, being sure to include the -h flag, as well as one or more
   skeleton players.  Run the monitor, sending the listfile output to a file.
   You should then find yourself playing a game against the skeleton player(s).

10. To start developing your own strategy, study the "skeleton" chapter of
   the documentation, and then look at the appropriate skeleton.* source
   file and the README file in the source directory.


FOR PC USERS WITH THE SOFTWARE ON FLOPPY DISKS

1. If you don't have printed documentation, print the appropriate files
   from the DOC directory on Disk-2.  To start with you'll want at least
   "intro" and "software".

2. Copy the root level files on Disk-1 (i.e. all but PASCAL.DIR) to a
   suitable directory on your hard disk.  Make a subdirectory of that
   directory for the skeleton programs in the language of your choice
   (C, FORTRAN, or PASCAL), and copy the contents of the appropriate
   directory on Disk-1 or Disk-2 into it.

3. As a trial, you can play a simple game, pitting yourself (via the human
   player interface) against PLAYER.EXE.  Get into the directory with
   DMON.EXE in it, and type:

        DMON OUTFILE

   A game should begin with you randomly either a buyer or seller.  It
   will be VERY SLOW, and NOT REPRESENTATIVE of the full game with many
   players; games with only a single buyer or a single seller (or both)
   do not raise most of the strategy issues of a full game.  But it may
   help to introduce you to the game and the software.  Here are some
   things to try:

   a. Type a ? at any prompt.

   b. Type 'help' at any prompt.  Try some of the commands/options listed
      there, especially u, w, and h.

   c. Type 'quit' when you are tired of playing.

   d. After playing, display or print the file OUTFILE, to which the
      monitor sent its output.

   For more information about the human player and its commands and display,
   look in the 'players' chapter of the documentation.  For more information
   about the monitor and its output (as in OUTFILE) look in the 'monitor'
   chapter of the documentation.

4. To make things reasonably fast on a PC, we highly recommend creating a
   RAM disk for the players.  If you do not currently have a RAM disk running
   on your machine, one can easily be installed using the VDISK program
   supplied with later versions of DOS.  In your CONFIG.SYS file (found in
   the root directory) insert the following line:

   DEVICE=C:\DOS\VDISK.SYS 128

   This assumes that your vdisk.sys file is in the C:\DOS directory; modify
   if necessary.  The 128 gives you a 128K RAM disk, which should be sufficient
   for several players and their message files; increase or decrease as needed.
   If you have extended memory (beyond 640K) you can install your RAM disk
   there by adding /E to the end of the above line.

   Reboot your machine after changing CONFIG.SYS; you should now have a RAM
   disk as drive D.  You can use it just like any other drive except that its
   contents are lost when you turn your machine off or reboot.

   Copy your players (.EXE files) to your RAM disk, and change your PLAYERS
   file to reflect their new location; the directory column should just
   contain 'D:' (or other appropriate drive letter) unless you make
   subdirectories on your RAM disk.

   You can also copy the monitor and its associated files to the RAM disk if
   you make it large enough, but this will not convey much advantage.

   Once you have mastered using a RAM disk for your players, the process of
   copying the appropriate files to it can be automated with batch file.

5. To try a game with more players, make copies of PLAYER.EXE with different
   names (e.g. PLAYER1.EXE etc.), and modify the PLAYERS file appropriately
   to define the players in each game.  You can try games with or without
   a human player.  If you include a human player you must direct the
   monitor's output to a file (e.g. 'DMON OUTFILE'); without a human player
   you can let the output go to the screen (e.g. 'DMON').  If you don't
   have a human player the monitor will respond to several single-letter
   commands from the terminal; see the "monitor" chapter of the documentation.

6. To try a game with graphical display of the supply and demand curves and
   transaction prices, use GDMON instead of DMON.  See also the discussion of
   the -g and -p options in the "monitor" chapter of the documentation.

7. You can also try changing the game parameters in the file GAME.

8. To start developing your own strategy, study the "skeleton" chapter of
   the documentation, and then look at the appropriate SKELETON.* source
   file and the README file in the source directory.  You should try
   compiling the skeleton without any changes (besides the customization
   required -- see the README) before developing any new strategies.  The
   resulting player program should behave essentially like the PLAYER.EXE
   provided.

9. There is a considerable advantage to having a small executable player
   file, since it must be loaded frequently.  You may want to explore ways
   provided by your compiler to minimize the .EXE size, including inhibiting
   some forms of debugging.  Some hints are provided in the README files
   and makefiles.  In general we find that Fortran executables are larger
   than C executables, which are larger than Pascal executables.


                               2.5 Getting Help
                               ----------------
We will try to assist you in getting our software to run on your system if
necessary.  We request, however, that you make an effort to thoroughly
understand this documentation before requesting individual help from us, since
many standard questions are already answered in the documentation. Additional
questions have also already been answered by the organizers in the "mail" file
available by FTP from pub/dat (see section 1.5 and section 2.3 for details). The
organizers are available to answer questions on the operations of the monitor
(pipe-based and file-based only), the skeleton players in C, Fortran, or
Pascal, DANI, and PP.  You can contact us by mail, phone, fax, or e-mail.
E-mail is recommended, particularly because the expert you need may not be
physically at Santa Fe, but will receive your message elsewhere.  In all
cases, please make it clear that you are referring to the Double Auction
Tournament. Please realize that the organizers have full-time positions
elsewhere, and so one shouldn't expect our technical help to have as rapid a
turn-around time as for commercial software.

Address:    Double Auction Tournament
            Santa Fe Institute
            1120 Canyon Road
            Santa Fe,  NM 87501

Phone:      (505) 984-8800      (office hours 8:30 am-5:00 pm MST)

Fax:        (505) 982-0565      (24 hours)

E-mail:     dat@sfi.santafe.edu     (for all general inquiries. Do NOT send
                                     initial inquiries to "dat-list"
                                     since this is a mailing list that goes out
                                     to hundreds of people. Send mail to
                                     "dat-list" only after reading section 1.5)

            palmer@sfi.santafe.edu  (for C, Fortran, monitor, DANI, PP)
            miller@sfi.santafe.edu  (for Pascal)
               jpr@sfi.santafe.edu  (for questions on DA rules, strategy, etc)


