World of Ham Radio 1997/WOHR97_AmSoft_(1997-02-01).iso/packet/intrflex/amsoft.iii

Text File | 1997-02-01 | 39KB | 889 lines

__________________________________________________________________________

THE VERSION 9 SOFTWARE NOW INCLUDES SUPPORT FOR THE AMSOFT CALLSIGN CD-ROM
__________________________________________________________________________

                     VERSION 9 NEW FEATURES

      Excerpt from "Performance Software" -- GOLD Software User Manual
      Copyright (C)1993,94 by InterFlex Systems Design Corporation
      All Rights Reserved

  Quick Summary:

  ALL   For all users, GOLD (Pk, Ka, dsp, etc) adds the ability
        for you to setup your station as a callbook server,
        conference bridge, general file/information server, as
        well as support for ANSI pics, restartable file
        transfers, and more.

  AEA   Ver 9 supports AEA's version 7 ROM additions, GUSERS,
        MYGATE and ARXTOR. AEA's rom for the PK-900 and dsp-2232
        has a number of other changes that have fixed the pactor
        changeover bug.

  KAM   Ver 9 supports G-TOR, the new mode from Kantronics that
        is about 4 times faster than Pactor, and about twice
        that of Clover, based on may on-the-air tests. The KAM
        version 7 rom also allows more NUMNODES (KaNode
        connects) -- well beyond the original 4 max. Lower the
        PBBS size, and raise NUMNODES.  Ver 9 also displays ARQ
        link status information including Huffman compressed
        frame, link speed, error condition, etc.

        G-TOR tests were conducted by W0XI, WK5M (Phil Anderson,
        Karl Medcalf, both of Kantronics) and WA4EGT (Jeff
        Towle, InterFlex systems), transferring a 9718 byte file
        using G-TOR and Pactor. The file was transferred in each
        mode, under the same band conditions. The test was
        repeated over 100 times during the next two months.

        G-TOR was faster than Pactor in EVERY case, and averaged
        about 3-times faster. InterFlex Systems program, KaGOLD
        w/Pactor fully supports G-TOR mode, as well as Pactor,
        Amtor, RTTY, Morse, split screen, multi-connect, ANSI
        graphics, command files, conference mode, and much more.


           VERSION NUMBERS -- ALL PROGRAMS NOW VERSION 9

  Starting with the 1994 release of PkGOLD and KaGOLD, version
  numbers are now consistent across different GOLD programs. This
  is a result of bringing all versions up to the same set of
  features.

  Version 9 represents a significant departure from the earlier
  versions of GOLD software.  Commands from remote stations are
  now allowed, two screen modes are supported for every session- -
  the normal text character screen and a new ANSI graphic screen
  -- direct interface to callsign databases (SAM, Buckmaster, QRZ)
  is supported, restartable file transfers, and improved operation
  in Windows and other multi- tasking environments, and support
  for CW announcements through ad-lib type sound cards.

  As you read the rest of this description, look for more about
  each of the following subjects:

      o   Callbook Support for four (4) CD based systems, and the
          SAM disk-based callbook. Users can lookup callsign data,
          the program does lookups automatically, and remote users
          can request callsign data making the station a callbook
          server (if remote commands are enabled and the
          appropriate callbook cmd file exists). Callbooks
          supported include Amsoft CD, Buckmaster CD, QRZ CD, SAM
          CD, and SAM Disk based callbook.

      o   ANSI Graphics supported on all sessions simultaneously.
          Pics are saved automatically if desired, and the program
          can "flip" to graphics mode automatically. No other
          program offers simultaneous, multiple ANSI picture
          receiving.

      o   Restartable YAPP and GOLD transfers. YAPP-C is
          supported, and restartable transfers are done
          automatically, as the program determines if the remote
          station supports these features. Partially complete
          files have a text header that makes it easy to determine
          which files are only partially received.

      o   Conferences can be started remotely, allowing your
          station to be a conference server. Users can switch
          conferences, start new conferences, and leave the
          conference and remain connected if desired. They can
          also send messages directly to other stations in the
          same or different conference.

      o   Remote commands, including user defined commands in CMD
          files.  This allows you to create a file server, ANSI
          pic server, radio mods server and more. The ability to
          create commands that remote users can issue opens a
          whole new set of outlets for for your programming
          creativity.

      o   Morse messages can be directed to an Ad-Lib compatible
          sound card. Also, CW pitch can be set by the user, both
          user options are in the SETUP area.

      o   Network View lines now show headers in low-video, and
          text in high-video, making it easier to distinguish
          headers from text. This is done automatically.

  Callbook Support

  If you have AmSoft, BuckMaster, QRZ, or SAM (disk or CD-based)
  callbook, the program will access these automatically, as well
  as allow other users to lookup callsign data through your
  system. To activate the support, use [Alt-S], then Setup, then
  Callbook.

  SAM Callbook

  First, find and load the SAMAPI (SAM Application Programmers
  Interface). The SAM callbook access requires this SAMAPI
  program. It is included with SAM, possibly in a subdirectory of
  one of the SAM disks.  To load SAMAPI from the GOLD directory
  you might type:

   C:\SAM\SAMAPI  C:\SAM                   For Disk based Version
   C:\SAM\SAMAPICD S:\SAMCDDAT C:\SAM      For CD ROM version


  If this does not load SAMAPI, check your SAM disks for SAMAPI
  and copy it to the SAM subdirectory. The second parameter in
  this command is the "Path" to the actual dataset. If you wish,
  make up a batch file to run GOLD and put this command before the
  KAGOLD or PKGOLD command. To unload SAMAPI from memory:

     C:\SAM\SAMAPI /R   (or /UNLOAD depending on version of SAM)

  While in SETUP (see above) select SAM as your callbook type if
  this is the only callbook you plan to use. If you also have CD
  ROM callbooks, indicate that you have both SAM and CD callbooks.
  The program will search for callbook data in the following
  order:

     CD based calldata first, then the
     SAMAPI or SAMAPICD.

  CD Callbook -- Buckmaster, AmSoft and QRZ In Setup, select CD
  ROM callbook data. If you also have SAM, select CD ROM and SAM.
  The search for callbooks is described above. The reason we don't
  choose the and by default is to save the time required to check
  for the SAMAPI if it will never be on your system. We use the
  index files directly from the QRZ disk, but on the Buckmaster
  disk, we create a unique index file for each version of
  Buckmaster. This may take up to 10 minutes the first time you
  use the Buckmaster option.

  Local use of the Callbook

  You can access the callbook using [Alt-I] then enter a callsign.
  You can also send callbook data to a session using:

       SENDCALL <callsign> [more callsigns] [F10]

  This causes the program to access the callbook for each callsign
  in the list (one or more) and produce a "mailing label" format
  for each callsign, sending it to the current session (packet,
  amtor, pactor, etc).

  Last, if you are using [Alt-E] to edit the logbook entry for the
  callsign showing in the banner (a connected station), you can
  then use [F9] to look up the callsign in your on-line callbook.

  Callbook Server -- Remote Access

  If you have enabled remote commands on the [Alt-Z] menu, a
  remote user can type //CALL WA4EGT or even a log list of
  callsigns separated by spaces or commas, to request callbook
  information from your station.

  How does this work? The answer is simple (we think it is
  anyway). CALL is the name of a CMD file. Here is what CALL.CMD
  contains:

       * Contents of CALL.CMD (this is a comment)
       CALLBOOK @0
       * Use zero not the letter O

  The command SENDCALL <callsign list> is a command in GOLD just
  like other TNC commands, and can be entered in a CMD file as
  above. The @0 (commercial "AT" sign followed by zero) is filled
  in with the string of characters supplied by the user who issued
  the CALL command.

  This means you can change the //CALL command to some other
  command, like //LOOKUP <callsign> if you wish. All you need to
  do is change the name of the file call.cmd to lookup.cmd and
  inform users that the new command name is lookup.

  Changing the names of this and other CMD files may introduce a
  lot of confusion.

    Conference Bridge Server

  If you have enabled remote commands in the [Alt-Z] menu, another
  station can connect to your station and join a conference
  without your assistance. This means that your station can be an
  unattended conference bridge or conference server. A remote user
  can connect and issue the following commands:

    //WHO          To list stations & conferences
    //JOIN A       To Join or create conference A
    //OFF          Exit conference, remain connected
    //BYE          Exit conference and disconnect
    //[call] text  Send text msg to [call]

  The last command allows a conferenced station to send a message
  to another conferenced station directly. If N6WIK and WA4EGT are
  both connected, the following:

   //N6WIK Let's start Conf C, type //JOIN C

  would send the message to N6WIK only.

  Users can log //OFF a conference, ask //WHO else is connected,
  and create a new conference with //JOIN C or any letter up to J.

  Remote CMD files

  Users who connect to your station can issue 1 to 8 letter
  commands that you create through the use of command files. A
  command file is a file in the directory cmdfiles off the GOLD
  directory. It must have a cmd extension, and can contain any of
  the following kinds of lines:

    Comments:   A line beginning with an asterisk (*) is a
                comment and is ignored.

    Message:    A line beginning with a quote (") is sent
                to the station who issued the command

    Commands:   TNC commands, or other "pseudo" commands that
                can also be run from command line with [F10]

  Most of the pseudo commands would not be issued directly by you,
  but would be put into CMD files for use in developing commands
  that remote users will find helpful.

  CMD file layout

  In the CMDFILES directory (which must be a subdirectory of the
  GOLD directory) you will create one or more files with .CMD
  extensions. A simple collection of 4 files might be as follows:

   CMD File #1
   * Help.cmd file contents (used to list
     other commands)
   " ?NAME, you may use any of the following commands
   " note: some may provide additional help
   "
   " //WHO           To list who else is connected
   " //CALL ?MYCALL  Information about ?MYCALL
   " //CALL ?CALL    Callbook information about yourself
   " //HFPARMS       Help about HF-Packet Parameters
   " //LISTMODS      List of Radio Modification files
   " << END OF HELP >>

   CMD File #2
   * LISTMODS.CMD file
   " ?NAME, here is a list of MOD files
   SENDDIR S:\MODS\*.MOD
   " Note: Use //GETMOD <filename> to get a mod file
   " << END OF LISTMODS >>

   CMD File #3
   * GETMOD.CMD file
   SENDTEXT S:\MODS\(@0)
   " << END OF RADIO MOD >>

   CMD File #4
   * Call.CMD file -- returns callsign data
   SENDCALL @0

  These examples show a number of features built into the CMD file
  processing. First, the use of the comment line to show the file
  name.  You can document your CMD files using the asterisk (*)
  comment line, and it is a good idea to make liberal use of
  comments.

  The use of the Quoted text line, the (") quote mark signals GOLD
  to send the text to the remote user. A good way to tell them
  what is coming, and notice at the end of each file, we've put a
  line to clearly indicate to the user that the command file is
  finished.

  The senddir command (described below) sends a directory, and can
  use "wildcards" for the directory mask, just like DOS. This
  usage gives a directory of all files in the S: drive MODS
  directory.

  The sendtext command is used to send a prepared text file, in
  this case a radio modification file that resides on drive S:
  (the QRZ CD ROM for example). The (@0) is a special case of the
  user supplied substitution string. It removes any path
  information from the user parameter, leaving only a file name
  (if any).

  The last file is the CALL command file, and contains only the
  pseudo command SENDCALL followed by the user parameter string.
  It will perform the Callsign lookup function on the string (one
  or more callsigns) supplied by the remote user.

  Remote user parameters

  When a user sends a // command, the program looks after the //
  for a valid CMD file name. If a match is found, the line is
  processed as a command. The remote user can include a parameter,
  like a file name or directory name, or both. In the CALL.CMD
  file example, the parameter @0 is used.

  If multiple parameters (words separated by spaces) are passed to
  the CMD file processor, you can use @1 @2 @3 etc. to identify
  each word separately, which is useful for DOS batch file
  processing.

  A CMD file can use the EXECDOS command to pass user parameters
  to a batch file as follows:

       EXECDOS DOSPROG @0

  When the CMD file processor sees this, the DOS shell is invoked,
  the program or batch file called DOSPROG is run, and the
  parameter @0 is passed to the spawned process as a single
  parameter string, as though typed at the DOS command prompt.

    Note:  The "at" sign (@) is similar to the percent (%) sign
    used in DOS Batch files.  The @0 is the entire user string,
    and the @1 through @9 are the individual words (parsed out of
    the string) in the @0 string.

  CMD file functions

    Senddir [path] [filespec]

  This cmd file function will send the directory of the default
  upload path if no parameters are passed to it. If you include a
  path, the directory of the files in that path are sent to the
  user connected that issued a CMD filename with a SENDDIR.

       Examples: Senddir S:\MODS\*.MOD
                 Senddir S:\@1

  The first example simply sends a directory of all files matching
  the *.MOD filespec. Similar to the DOS directory command and how
  it proc esses this kind of filespec (file specification).

  The second Senddir takes the first parameter (or the only one)
  provided by the remote user and substitutes it for the @1. A
  remote user typing a command followed by mods\IC*.*  will get
  all files that match S:\mods\IC*.*  due to the substitution that
  follows the S:\ in the above example.

    Sendyapp [path] [filename]

  This command sends a filename using YAPP protocol. The file name
  can be provided as "hard coded" or it can use the substituted
  parameter approach, similar to the SENDDIR above.

       Examples: Sendyapp S:\mods\ft990.mod
                 Sendyapp s:\@1

  The first example sends one file, that's it! No options. The
  second example allows the remote user to contribute a path and
  filename to request.

    Sendgold [path] [filename]

  This is a variant of binary file transfer using YAPP, only in
  this example, the transfer protocol is the GOLD protocol, which
  allows you and the remote station to continue conversing on the
  session/stream.  This is only honored if the remote station is
  identified as a GOLD user by the automatic exchange process.

    Sendbin [path] [filename]

  This method is like SENDYAPP and SENDGOLD with another layer of
  automation -- it figures out whether to use YAPP or GOLD
  protocol depending on whether the remote station is a GOLD user
  or not. If you want to send using GOLD protocol to any GOLD
  user, and to use YAPP with all other stations, then sendbin is
  the right command.

    Sendtext [path] [filename]

  This sends a file as plain ascii, no special protocol (like yapp
  or gold) and cannot be used to send binary files, like programs
  that have .COM or .EXE, or .ZIP extensions (to name a few). Use
  this method to send a MOD (radio modification) or some other
  file of text data.

    SendRaw [path] [filename]

  Some files, in particular ANSI graphic or "pic" files, and
  specially formatted text files such as M.A.R.S. messages created
  with programs that produce multiple Linefeeds rather than
  multiple CRLF sequences, must be sent with the Raw send
  capability of PK and KAGOLD. This command can be used in CMD
  files that need to use this raw send capability. It is this
  command, coupled with SendText and SendDir that can make your
  station into an ANSI Picture "Server" and allow remote users to
  receive ANSI graphics in an unattended mode.

    Recvyapp

  This command puts the current session into a YAPP receive mode.
  It will be ready for a yapp transfer from the other station. It
  does not require any parameters, and the files will be put into
  the default download directory that is specified as the
  "download path" in the setup area (under file transfers).

  There is no need for a "recvgold" because this is handled
  automatically when GOLD gets a "here comes a file" type packet.

    SENDCALL [callsign or list of callsigns or @0]

  This was described above in the example for the //call
  <callsign> command file. It will access whatever callbook it can
  find and produce the callbook information, sending it to the
  remote station. The use of @0 means the entire line of text
  (several callsigns) will be passed to the SENDCALL routine, with
  several callsign lookups.  You can use this command to send
  calldata to a friend: try SENDCALL W1AW [F10].

    Conference Commands

  The following commands are specific to the conference only, and
  are built-in, internal commands read directly by the software
  and processed immediately. While they look like the other
  commands, using the //cmdname format, they are unique to the
  conference processing.

    //who

       Display a list of Who is connected, and what conferences
       are in progress, if any, with letter identifiers. You can
       JOIN any conference. Outside of the conference, a user
       typing //who can access a WHO.CMD file to perform a similar
       function.  The file might look as follows:

         *who.cmd contents (or name it USERS.CMD)
         "At ?Time SENDWHO

       Understand that the //who command issued by a  station in
       conference will be processed by the internal "who" command
       parser, and will list only the connected stations. Outside
       of the conference, the same //who command is processed by
       the CMD file processor, using the SENDWHO tnc pseudo
       command.  You can issue SENDWHO locally, as you can with
       any TNC or Pseudo-TNC command, type it and push [F10].

    //name [yourname]

       A conference member may fill in his/her name, or change
       his/her name that is associated with the callsign.

    //Join <conference letter>

       This causes the station to be "joined" into a conference,
       or to create a conference with the letter chosen.

    //<callsign> <text to send to callsign>

       Send a string of text directory to the callsign typed out.
       Callsign must include the station's SSID if that is how it
       appears in the conference.

    //Off

       Exit from the conference, but remain connected to the
       station.  Useful to issue other remote commands, get files,
       etc. Here is another conference command that can have a
       counterpart outside of the conference.  You could create an
       OFF.CMD file, or LOGOFF.CMD file with the following format:

         * OFF or LOGOFF.CMD file layout
         "73 from ?MYCALL -- OFF at ?DATE ?TIME
         DISC

    //Bye

       Exit from conference, and disconnect. Again, you could
       create a BYD.CMD with a DISC command in it (like the OFF
       command) for use outside the conference.

    Advanced CMD file examples

  You can create some interesting CMD files, and with some
  planning, make your station into a resource for radio mods,
  information files, propagation forecasts, just about any
  collection of information you wish.

  Here are a few CMD files with a brief explanation of what each
  does.  Use them as a prototype for making your own CMD files.

   * This sends a list of my brg files (first line -- a comment)
   "Here is a list of my BRG files:
   execdos dir/w brgfiles\*.brg > upload\brgfiles.lst
   sendtext brgfiles.lst
   "<< END OF LIST >>
   "Use //GETBRG filename  to have a file sent back to you

  The second line uses the Quote command to send the text Here is
  a list of my BRG files to the remote user. The next line is more
  interesting.  It shells to DOS with EXECDOS, does a DOS
  directory (with /W meaning wide) of all files in the BRGFILES
  subdirectory with the BRG extension, redirecting the output of
  the DIR command to the upload directory, to a file called
  BRGFILES.LST. Finally, the SENDTEXT command is used to send the
  list of files.

  A couple of things to note: First, all directory references
  begin with the GOLD directory as the default directory. The DIR
  command, if issued from the GOLD directory, need only refer to
  BRGFILES subdirectory to cause the output to be redirected
  there. It is not necessary to fully specify the directory name.
  That means, for example, you can write these relatively benign,
  generic CMD files that will work on ANY drive letter, and can be
  used no matter what name was given to the main GOLD directory.
  Second, this example demonstrates the power of CMD files coupled
  with the EXECDOS command.

  Here is what the GETBRG.CMD file might look like, to allow users
  to request one of your BRG files.

   * GETBRG CMD file, used to get a BRG file
   "Here is a copy of "@0"
   sendtext  brgfiles\(@0)

  Radio Modifications "server" example Here is group of files that
  provides radio modifications lists.

   *Helpmod.cmd file -- explains how to use MODS list
   "To get a list of MODS, or a partial listing type
   "//LISTMODS        for all MODS
   "//LISTMODS FT     all mods starting with FT
   "//LISTMODS TS4    TS430, TS440, TS450, etc

  This first HELPMOD.CMD file is straightforward.  It uses the
  quote character to send help information to the remote station
  that typed the command //HELPMOD.

  This next file does the LISTMODS command from a remote user.

   * listmods.CMD, shows mods from QRZ dir
   senddir s:\mods\@0*.mod
   "Use //GETMOD <Modfilename> to get file

  Line 1 is a comment line, it begins with an asterisk (*). Line 2
  sends a directory from the S:\MODS directory using the remote
  request, and adding the asterisk followed by .MOD. If the user
  were to type //GETMOD FT the @0*.MOD would become FT*.MOD which
  will give a directory of all files beginning with FT and having
  a .MOD extension.

  The last line tells the user how to actually retrieve one of the
  mod files. The getmod.cmd file might look like this:

   * Getmod.cmd file, sends the mod requested
   //sendtext s:\mods\@0
   "<<end of mod file>>

  In this example, the user would have to type the exact filename,
  including the .mod extension.

  Calling a batch file example

  This last CMD file example shows how to call a batch file using
  EXECDOS and how to refer to the GOLD directory itself. The
  objective here is to call the Buckmaster ICALL program and
  request the extra station information that comes along when you
  use the /S option (supported in the BuckMaster Callbook CD).

  The user will be told to type //LOCATE <callsign>, and
  LOCATE.CMD is the file we need to create. In addition, a batch
  file is needed that does the actual work of calling ICALL once
  the program shells to DOS and gives control to the batch file.

  Here is the listing of LOCATE.CMD:

   * LOCATE.CMD  for locating (Lat/Lon) by Callsign
   * Usage:
   *   //LOCATE <callsign list>
   "Processing call(s)....
   execdos ic_loc @0
   * This next line is tricky, the only way to send from the GOLD
   * directory itself. This is a DOS issue, where dot (.) is the
   * current directory. The backslash is needed to separate the
   * dot from the filename.
   sendtext .\location.dat
   "<< END OF LIST >>

  This file has a lot of comments in it, a good idea when writing
  your own CMD files that others may use, or that you will
  maintain. The two highlighted lines do the work. First, the
  execdos command calls ic_loc.bat, a file located in the main
  GOLD directory. It passes the parameter(s) that were typed by
  the user by referring to the @0. The IC_LOC.BAT file will be
  shown in a moment.

  The next highlighted command uses the DOS syntax ".\" which is
  way to refer to the default directory. Without a directory
  specified like this, GOLD reverts to the default directory for
  sending files, namely the upload directory. We want to perform
  the callsign and station information lookup in the GOLD
  directory. Here is what IC_LOC.BAT has in it:

   @echo off
   rem  Put this BAT file into the GOLD directory
   IF %1x==x goto Nocall
   S:\ICALL S: %1 /S > location.dat
   edlin location.dat < fixdata.cmd > nul
   GOTO ENDBAT
   :NOCALL
   ECHO Need a callsign to lookup! > location.dat
   :ENDBAT

  This batch file takes the commands from the execdos command in
  the locate.cmd file that were typed by the remote user. The
  callsigns requested have traveled through the network, to GOLD,
  to the CMD file in the  @0, to the batch file and DOS sees the
  parameter as %1.

  The only twists here the redirection of the output of ICALL to
  location.dat, and the editing of location.dat using the DOS line
  editing program EDLIN. We pass EDLIN a filename to edit, and
  tell it what to do in the file FIXDATA.CMD.  The confusion about
  CMD files here is evident, but this CMD file has commands to the
  EDLIN editor.

  Here is what is in FIXDATA.CMD:

       1,3d
       e

  These EDLIN commands simply delete lines 1 to 3 of the resulting
  buckmaster icall output, and then exit the editor. You can learn
  more about using the EDLIN editor, and passing commands to it by
  referring to your DOS manuals. The idea of presenting these
  examples is to give you an idea of the power of the the new GOLD
  command file processing, especially when combined with batch
  files.

  ANSI Pics

  KaGOLD and PkGOLD are the only programs available that can
  capture and display multiple ANSI sequences simultaneously,
  capture them automatically, and on dual port units, capture ANSI
  graphics on both ports simultaneously. The only HF mode that is
  capable of supporting ANSI, without causing errors, is PACTOR.

  American National Standards Institute defines several "escape
  sequences" that involve cursor positioning, color setting,
  screen clearing, etc., and with the GOLD ANSI capabilities, you
  can view these ANSI "Picture" or "Graphic" files.

  An ANSI sequence is easily recognized by its use of the [ESC]
  character, which prints as a left arrow, and the opening square
  bracket. If you see  in some text, this is very likely the
  beginning of an "escape sequence" that contains cursor position,
  color, or other information for an ANSI interpreter.

  When an ANSI "picture" is received

  Every "session" has its own memory buffer, allocated and
  deallocated automatically. When an ANSI picture is detected, a
  second buffer is created for the session, and it becomes the
  scratch-pad or canvass to draw the resulting ANSI picture. This
  buffer is only created when the software detects the need for
  it. Therefore, as you read the next few sections about ANSI
  pictures, realize that [Alt-G] the keystroke used to "flip" to
  and from the graphic will only work if there is or was a graphic
  for this session. The purpose here is to save computer memory,
  another aspect of dynamic memory management that is built into
  GOLD software. If you use [Alt-G] and nothing happens, then no
  ANSI picture is available for display on the active session.

  Manual Display [Alt-G]

  As explained above, the ANSI screen is not always available. You
  can use [Alt-G] to see the ANSI graphic only if one exists.
  [Alt-G] is a toggle, switching between the graphic (if any) and
  the "normal" text screen.

  Auto-Capture

  By default, ANSI "pictures" are captured into the ANSFILES
  directory.  Automatically captured "pictures" are given file
  names as follows:

       GOLDnnnn.ANS

  where nnnn is a number from 0001 to 9999. If you collect more
  than 9999 pictures, the file will be named GOLnnnnn.ANS,
  dropping the "D" in GOLD and using 5 digits to express the
  picture number. Hopefully, you will review the files
  occasionally, and rename them to something more reasonable, like
  BART.ANS, or TRAIN.ANS.  You can turn this feature OFF if you
  wish, in the Setup area under Screen Settings.

  Auto-Flip

  The program defaults to "flipping" to the graphics screen when
  incoming ANSI sequences are detected. You can change this to OFF
  in the Screen Settings area under Setup (as above).  When the
  screen flips to graphics, you can always use [Alt-G] to return
  to the regular session screen and see the ANSI sequences in
  their raw, uninterpreted form. If you turn Auto- Flip OFF, you
  will always have to use [Alt-G] to see ANSI pics.  The ON
  setting is probably the most useful, but some users may want to
  avoid flipping to ansi graphics and do everything manually.

  Reviewing ANSI pics

  A program called SHOW.EXE may be in the ANSFILES subdirectory.
  It is also available on the InterFlex Systems BBS. Use this
  program to review ANSI graphics by typing the following command:

   SHOW sample.ans (or whatever the filename is)

  A second method is to have ANSI.SYS loaded from your CONFIG.SYS
  file.  If ANSI.SYS is active, all you need to do is TYPE the
  file and let the ANSI interpreter display the graphic. ANSI
  graphics with animation do not show very well, if at all, using
  this approach, but it is a quick way to review pictures. The
  command would be:

   TYPE sample.ans (assuming this file exists)

  Other programs can be used to edit and create your own ANSI
  pics.

  Creating ANSI Pics

  There is at least one program available on the InterFlex Systems
  BBS that can be used to create ANSI "graphics" files. It is
  TheDraw. You can download the zip file called TDRAW450.ZIP,
  extract the files, and take a shot at creating your own ANSI
  files.

  Here is the most important caveat: when you write your files, or
  save them, set the right margin, or maximum line length to 75,
  or some length below 80 characters. Using 75 allows others to
  copy/paste the ANSI sequences.

  Restartable File Transfers

  In Version 9, file transfers using a "protocol" like YAPP-C or
  GOLD are restartable. Text files and raw send (for ANSI pics)
  are "one way" type transfers and have no "protocol" and do not
  always result in creating a file on the other user's system.
  GOLD and YAPP do create files on the receiving station's
  computer. If the transfer is stopped, or aborted, the partially
  received file is saved with a special header that allows the
  transfer to resume, or restart rather than start from the
  beginning. This saves time.

  GOLD protocol

  On the [F6] transfer menu, sending or receiving files
  automatically supports restartable transfers (see above). With
  earlier versions of PkGOLD and KaGOLD, the restartable transfer
  is not supported, but you will still be able to send and receive
  files while connected to some earlier versions of PkGOLD and
  KaGOLD.

  YAPP-C protocol

  The YAPP (yet another packet program) system for sending and
  receiving files has been extended to YAPP-C, with and without
  restarting. With PkGOLD and KaGOLD, this is entirely
  transparent. If the remote station supports restarting, your
  station will handle it automatically. If not, again the software
  "knows" and handles things automatically. Just transfer files
  with YAPP to a local BBS or other user, and if YAPP-C or
  restartable YAPP is supported, your station will automatically
  comply with the newer protocol.

  Setting Alt-Messages

  You can use the Setup menu, Alt-n message selection to alter
  your one-line Alt-n messages (alt-0 through alt-9) or use a new
  feature in this latest version, the setalt <n|p><0..9> text...
  pseudo tnc commands. The syntax of this new command is the
  setalt command, the alt-n message you want to change, and the
  text string.  The <n|p> means "Non-packet OR packet" and the
  number 0 through 9 must be included to identify which Alt-n
  message to change.

  In any of your TNC or CMD files, you can put one or more of
  these new commands. You can also type the command from the
  command line to change an alt-n message. For example:

   setalt p5 My QTH is Laguna Niguel, CA [F10]
   setalt n1 ?call de ?mycall [F10]

  You can include any number of setalt pseudo commands in your tnc
  or command (cmd) files. Be sure the strings do not exceed about
  100 characters. Even better, do not exceed about 65 characters
  so that you can read the entire line when you hit the Alt-n.

  Hints for usage: Some users have suggested that we have a set of
  Alt-n messages for each mode, not just packet and non-packet.
  This new feature allows you to create a set for each of the non-
  packet modes, and put them into a tnc file that also calls up
  the mode. For example, an AMTOR.TNC file might contain several
  setalt messages for usage in amtor. It might be good as well to
  create a tnc file with a collection of default alt-n messages.
  RESETALT.TNC would be a good name.

  Special Connect BRG files

  You can do some new things with connect files.  If you have
  enabled the sending of "connect.brg" when a station connects (do
  this in the Setup menu, under Alt-n messages) you will have a
  few new options for naming the files.

  The program will look for any one of three files. First, a file
  with the same name as the callsign of the connecting station.
  Second, a file with the name "CO-xxx.brg" where "xxx" is the
  name of the port (the name you give the port on dual-port tncs).
  For example, create a short file called CO-HF.BRG and a larger
  CO-VHF.BRG file. Then, when a station connects on HF, the HF
  connect text file will be sent. This allows you to send short
  files on HF, and longer files on VHF. Third, the program looks
  for CONNECT.BRG, and sends it if it cannot find another file to
  use.

  If you create CO-HF.BRG, and K8TNK.BRG, and have the standard
  CONNECT.BRG in the BRGFILES directory, here is what would be
  sent under each condition:

   K8TNK connects on either HF or VHF, send K8TNK.BRG
   WA2VSM connects on HF, send CO-HF.BRG
   WB8TKE connects on VHF, send CONNECT.BRG

  Hints for usage: You can use the callsign.brg approach to leave
  a message for another station.  It will be sent every time the
  station connects until you delete that file, but you may have a
  message that is intended as a reminder for another station.

  Changes from Prior Versions

  In addition to the major changes explained in this chapter,
  there are several minor adjustments that will improve the
  operation of the program. For example, the logging system uses a
  B-tree index rather than a hashing index.  This is a technical
  matter, but the new system is faster, and has much larger
  capacity and is much faster. The monitor screen has been
  modified to show information frames with a bright color
  attribute, with headers in a dim or normal brightness. The
  on-screen clock uses a different technology that improves
  reliability of the program when operating in a multitasking
  environment.

  The technology for determining when to unkey the transmitter in
  the non-packet modes has been beefed up, to assure that unkeying
  occurs as quickly as possible when the buffer empties. The way
  the program does overlays is improved, to be faster and more
  reliable on systems that are slow to switch between real and
  protected mode.  The program handles more types of nodes,
  including TEXNET which uses the commercial at sign (@) in
  certain parts of the connect commands.  Other changes to version
  9 are the result of the months of beta testing that this program
  has been through.

  When other users ask what is new about Version 9, tell them the
  major new additions, which are (1) Callbook support for 3 CD ROM
  based systems, and SAM; (2) Support for ANSI graphics, on all
  sessions, simultaneously; (3) Conference server mode, with
  remote started, and changed conferences; (4) Remote command
  files that are user defined and able to send textfiles,
  directories, and start binary file transfers; and (5) File
  transfers are now restartable with both YAPP-C, and GOLD
  protocols supported. Some changes may be more useful than others
  to certain users, but we hope that you find these additions fun
  and easy to use.

                          <<END>>