Simtel MSDOS - Coast to Coast/simteldosarchivecoasttocoast2.iso/packet/kmtrm120.zip/KAMTERM.DOC

Text File | 1993-03-12 | 94KB | 2,042 lines

KAMterm:  Copyright 1992,1993 by Jim Graham, N5IAL (All Rights Reserved)

PREFACE

As part of their more recent firmware in their TNCs, Kantronics offers
a special mode of operation known as Host Mode.  Host Mode differs from
the ``normal'' operating mode in many respects, and offers a great
deal of additional capabilities when using Host Mode terminal software.

This section is a general introduction to what Host Mode is and how it
operates, what it buys you, and some special considerations for using
Host Mode as opposed to the normal command mode.

What Is Host Mode?

Before going into any detail on the benefits of using Host Mode, it
is important to first have a general idea of what Host Mode actually
is, and how it operates, as opposed to the normal command mode you are
probably more accustomed to using.  It is not necessary that you fully
understand the details behind this, but you should have somewhat of a
feel for what's going on behind the scenes.  The detailed description of
the data format is in the Kantronics documentation, and only a general
summary will be listed here.

In normal command mode on TNCs, the text you type is transmitted
directly to the TNC exactly as you typed it.  This does not require any
special software on your computer other than a simple dumb terminal
emulator.  In fact, in normal command mode, you can attach a plain
terminal (as opposed to a computer running terminal emulation software)
to the TNC.

In Host Mode, however, the text you type is not transferred to the TNC
directly.  It is first enclosed in blocks of data, which include a
header indicating the type of data being transmitted (commands, data to
be transmitted, etc.) and the port and stream to which the data is
addressed, and a flag marking the end of the data block.

WHEN THE TNC IS IN HOST MODE, A SIMPLE TERMINAL EMULATOR WILL NOT
BE ABLE TO COMMUNICATE WITH THE TNC DIRECTLY, AS IT WILL NOT PUT THE
DATA IN THE REQUIRED DATA BLOCKS.  Likewise, when the TNC is in normal
command mode, software attempting to run Host Mode communications to
the TNC will also fail to function.

The data format used within Host Mode is actually very simple when
compared to that used in other data communications protocols (such as
X.25, AX.25, TCP/IP, etc.).  The blocks of data are delimited by a
flag, called a FEND (C0H, or decimal 192).  In most types of data
blocks, the first FEND is followed by 3 characters, indicating the
type of block, the port, and the stream, respectively.  This is
followed by the actual data, and finally another FEND which signals
the end of the block.

What Does Host Mode Buy You?

First, you can (assuming you have the KAM, as opposed to the KPC, etc.)
operate in a non-packet mode on HF, while operating packet on VHF.
(Without Host Mode, attempting to operate non-packet modes on HF while
connected on VHF packet will get you a ``NOT WHILE CONNECTED'' response
from the KAM.)

In addition, regardless of the type of Kantronics TNC, the special block
format of Host Mode allows you to do many things in Host Mode that can
not be done in normal command mode.

For example, in normal command mode, all data, regardless of the
port/stream it is from, is simply dumped to your screen, and each time
you wish to change streams, you must issue a command to the TNC to
change it to the new stream.

In Host Mode, however, the data block identifies the stream from which
incoming data is arriving, which provides for the design of a windowed
environment, such as KAMterm.  In such an environment, the data for
each stream can be given its own window, thus keeping things cleaner on
the screen.  In KAMterm, you need not keep telling the TNC which stream
you wish to work with---the Host Mode data format takes care of this
for you.  Outgoing data is automatically set to the port/stream
associated with the window you are currently viewing.

A related feature is the ability to have an entirely separate screen
for command entry (same as you would have with the TNC at the cmd:
prompt) and for monitor output, once again keeping the screen much more
organized.

All of this boils down to being able to have multiple connections open,
with a different screen for everything.  To change from one conversation
to another, you simply move to the next screen and the software takes
care of the rest for you automatically.

There are other features derived from this in KAMterm, such as the
ability to keep an eye on one stream while in another stream's window,
the AMTOR XMITECHO window (which displays the text as it is transmitted
without interfering with other operations).  These and other features
will be described in more detail later.

Special Considerations When Using Host Mode

In general, Host Mode can make things much simpler for you, but there
are a few things you need to keep in mind, or you may find yourself in
some confusing situations.

First, and most important, if the TNC is set to use normal command mode,
and the software is trying to use Host Mode (or vice-versa), neither one
will recognize the other.  While you are in KAMterm, if you change
between Host Mode and normal command mode, KAMterm will take care of
changing the TNC's setting for you.  If you also run other terminal
software, however, it is important to keep this in mind when configuring
and using KAMterm.

In general, if you expect to use any other terminal program, possibly
including other Host Mode software, you should configure KAMterm *NOT*
to automatically start and exit in Host Mode.  This is, therefore,
the default configuration.

For example, if you exit from KAMterm and leave the TNC in Host Mode,
and then try to use a plain terminal program, it simply will not work,
because the TNC is expecting Host Mode data blocks, and the terminal
program is not providing them.  To prevent this situation, do not leave
the TNC in Host Mode if you expect to use a regular terminal program.

Similarly, if you have instructed KAMterm to immediately start off in
Host Mode (see the section on the configuration file for details), and
the TNC is in normal command mode, KAMterm will be presenting Host
Mode data to the TNC, and the TNC will not recognize the data format.
You can re-establish communications with the TNC by telling KAMterm to
return to normal mode.

NOTE:  It has come to my attention that the HostMaster software from
Kantronics automatically returns the TNC to normal command mode when
it exits, so if you use KAMterm after using HostMaster, do not
assume that the TNC is in Host Mode---it probably isn't.

A second thing to keep in mind is the fact that the command screen is
always associated with some port/stream combination.  If you are
connected on streams A, B, and C on the VHF port, and you wish to
disconnect stream C (using the DISCONNECT command), you would return to
the command screen and enter that command.  You must, however, make sure
that the command screen is pointing to VHF Stream C, or you might end
up disconnecting the wrong stream!  The status bar will always indicate
the port/stream associated with each window.

A third thing to keep in mind is the fact that when you make a
connection from the command screen, you will see a status message
informing you of the connect, but from that point on, all data from
that connection will be displayed on a different screen.  This differs
from what you would expect when using normal command mode, where the
data from the connect is dumped straight to the same screen (the only
screen).


1.0)  INTRODUCTION

KAMterm is the result of my not being able to find a terminal program
that take advantage of the KAM's host mode functionality and maintain a
friendly user interface, without sinking large amounts of cash to get
it.  So, after getting tired of being told (by the KAM) that I can't do
this or that while connected, I decided it was time to do something
about it.  So here it is!

KAMterm is my answer to this problem.  I've included a lot of the standard
bits that you see in most terminal programs (i.e., split-screen, scrollback
buffers, logging to a file, etc.).  I've also added a lot of things that,
in my opinion, have been seriously lacking in everything I've tried for
packet terminal programs.

KAMterm is designed around several basic concepts:

*) Each active stream has its own window.

*) There is a separate screen for command mode and for monitor mode.

*) You can switch between screens with a single keystroke.

*) There is a ``priority window'' that you can use to display any
   incoming data on a given stream while working with another stream.

*) KAMterm is designed to be extremely simple to operate.

*) KAMterm will NOT modify your TNC's parameters unless you ask it to.

*) If you choose to do so, you have the ability to create startup and/or
   exit command files that will configure the KAM for you.

*) When logging to a file, KAMterm will try to keep things organized by
   adding a line above any text it logs indicating who said what.

*) In some menus, if you have a mouse, the mouse can be used for those
   menus.

*) Normally, host mode does not have some of the things normal command
   mode does---these are ``faked'' in KAMterm, and the appropriate
   action is taken.  These include:

  *) fake command prompt (hcmd:)
  *) |n to switch to VHF stream n for command window i/o commands
  *) ~n---same idea, except for HF
  *) a simple [CR] will result in new hcmd prompt (for aesthetics only)

*) Scrollback buffers are setup for each window if memory permits. Size
   is adjustable via configuration file (kamterm.cfg).

*) KAMterm will notify you of incoming connects no matter where you
   happen to be at the time.

*) Programmable function keys---[F1] is reserved for HELP, but
   otherwise, any of the function keys ([F1] through [F10]) can be used
   alone or in combination with [SHIFT], [ALT], and/or [CTRL] for your
   own macros, etc.  The limitation here is that the string is limited
   to 80 chars.

*) Macro command files---just as you can have setup files for start
   and exit, you can send macro command files to the KAM at any time
   while running KAMterm.

*) ``Brag'' files are supported, too.  You will be asked for the name of
   the file you wish to transmit.


2.0)  DISCLAIMER

KAMterm is provided AS IS with no warranty, expressed, written, or
implied.  While every effort has been made to keep KAMterm free of bugs,
individual systems do vary, and it is beyond the author's ability to
test KAMterm in all possible system configurations.  Under no
circumstances shall KAMterm's author be liable for incidental or
consequential damages that may be incurred by the performance or use of
this product.

3.0)  DISTRIBUTION

You are free to distribute UNMODIFIED copies of KAMterm, providing
that all documentation, sample files, and other related files are
also distributed unmodified.  This applies ONLY to the shareware
distribution---registered versions of KAMterm, as well as the
typeset documentation, are not to be distributed, period.

KAMterm may, if needed, be re-packaged by another archiving program
(e.g., ZIP, ZOO, ARJ, etc.) for distribution.  This represents the only
acceptable ``modification'' for its distribution.

Under *NO* circumstances is the Copyright notice within the program
or its documentation to be altered in any way or removed.


4.0)  NS16550AN/AFN  SUPPORT

KAMterm provides full support for the NS16550AN and NS16550AFN UARTs.
These UARTs (made by National Semiconductor), provide a much greater
degree of reliability at higher speeds (the definition of which depends
on the speed of the computer, and ranges from 4800 bps in severe cases
to 38,400 bps or higher on faster computers).

The 16550 does this in two ways.  First, it provides a 16 character FIFO
buffer, as opposed to the 1 character FIFO in older UARTs such as the
8250.  This provides some breathing room for your program. The second
thing the 16550 does is to allow a single interrupt for multiple
characters.  In other words, with only one interrupt, a communications
program can read several characters from the port at a time.  This
substantially reduces the interrupt loading on the computer, and thus
improves performance of serial I/O.

KAMterm automatically detects either the NS16550AN or NS16550AFN if it
exists, and takes advantage of the FIFO and the modified interrupt
structure described above.

Note, however, that while KAMterm does support speeds up to (and
including) 115,200 bps, most TNCs currently only support speeds up to
9600 bps.

If you do not have 16550 UART (you would know if you did---they are
more expensive, and are not standard stock in most serial cards), and
particularly if you have a slower computer, you may run into problems
running at 9600 bps.  If you're seeing dropped characters (normally only
a problem when there is a continuous stream of incoming data), try
dropping the speed down to, say, 4800 bps or lower.  Remember to change
the speed on the TNC (this requires a reset) before changing KAMterm.

5.0)  KAMterm  OPERATIONS

This section will describe some operational aspects of KAMterm.  These
include startup options, screen layout, and what happens internally when
new connects become active in Host Mode.

One thing worth mentioning, even though this is not a function of
KAMterm, is the TNC's handling of the LEDs in Host Mode.

In version 4.x of the firmware, some LEDs function differently in Host
Mode than they do in normal command mode.  The CON LED on the VHF side
indicates that data is being transmitted from the TNC to the computer,
and the STA LED on the VHF side indicates that data is being received
from the computer.  The normal command mode functions of these LEDs does
not apply in Host Mode.  This includes the usage of the STA LED to
indicate the status of the PBBS.

It is my understanding that in version 5 of the firmware, PBBS status,
and possibly even connect status and outstanding packet status are
available from the LEDs even under Host Mode.  More information on this,
and if needed, updates to KAMterm, will be added once I get the new
firmware.

5.1)  STARTUP  OPTIONS

There is only one startup option:  -h   (start immediately in Host Mode).

This assumes that the TNC is already in Host Mode, and does not send the
commands to the TNC to initialize Host Mode.  This overrides the
STARTHOST parameter in the kamterm.cfg configuration file (described
later), and starts in Host Mode regardless of its setting.  This is
primarily intended for times where you have left the TNC in Host Mode,
but normally do not do so.

5.2)  SCREEN  LAYOUT

The physical screen is divided into 2 regions.  The first is the main
output window.  This takes the majority of the screen.  The second is
the local window, which is the first place where the text you type will
be echoed. The format shouldn't be new to anyone who has used popular
terminal programs for packet radio.  The status bar in between these
which indicates the stream, who (if anyone) that stream is connected to,
etc.

5.2.1)  THE  SCREEN  ITSELF

When you first start KAMterm (assuming you start in non-Host Mode), you
will see a screen which looks something like the following:

╔════════════════════════════════ TOP OF SCREEN ══════════════════════════════╗
║                                                                             ║
║ This is the MAIN WINDOW.  All text coming FROM the TNC is placed in this    ║
║ window, as is the local echo (if it is turned on).                          ║
║                                                                             ║
║ This window uses lines 0 through 19 on the screen.                          ║
║                                                                             ║
║                                                                             ║
║                                                                             ║
║                                                                             ║
║                                                                             ║
║                                                                             ║
║ The line below (it is only one line in the program) is line 20, which is    ║
║ the STATUS LINE.                                                            ║
───────────────────────────────────────────────────────────────────────────────
F1=HELP COM1 9600 8N1             NORMAL MODE             09 May 1992  12:33:37
───────────────────────────────────────────────────────────────────────────────
║                                                                             ║
║ This is the LOCAL WINDOW.  Text you type goes here.  This window uses       ║
║ lines 21 through 24 on the screen.                                          ║
║                                                                             ║
╚══════════════════════════════ BOTTOM OF SCREEN ═════════════════════════════╝

So, with that picture in mind, let's take a look at what we've got.

First, the main window contains all text coming in from the TNC for the
stream assigned to the current window.  Because the TNC is not yet in
Host Mode, this means all data coming in from the TNC, period.

The last window on the screen is the local window.  This is where text
you type is first echoed.  In here, you can edit a line of text to send
to the TNC before actually sending the data.  If the line exceeds 78
characters, everything that has been typed to that point will be
transmitted to the TNC.  Word wrap is not currently implemented.

5.2.2)  THE  STATUS  BAR

The status window provides some information as to where you are, how
things are configured, etc.  Reading from left to right, we first see a
reminder that F1 can be used for HELP.  Next, we see that the serial
port is configured for COM1, 9600 bps, 8 data bits, No parity, and 1
stop bit.

Off to the right a bit in the status bar, we see an indication that we
are in normal mode, as opposed to Host Mode.  Note that this does not
indicate the TNC's configuration, i.e., the TNC may really be in Host
Mode.  If there is a mis-match between KAMterm and the TNC, things won't
work.

At the far right of the status bar we have the current date and time,
according to your computer's clock.

When you enter Host Mode, the status bar will be modified, and you will
see the following:

───────────────────────────────────────────────────────────────────────────────
F1=HELP COM1 9600 8N1          HOST CMD:  VHF/A           09 May 1992  12:33:37
───────────────────────────────────────────────────────────────────────────────

This is now telling us that we are in Host Mode.  Furthermore, this is
the HOST COMMAND WINDOW, which is where we issue actual commands to the
TNC (e.g., CONNECT FOO-BBS).  It then tells us that commands typed here
are currently affecting VHF stream A.  For many commands, this is not
important (e.g., DAYTIME, MYCALL, MONITOR, etc.), but for others (e.g.,
CONNECT, DISCONNECT, etc.), this does matter.  In addition, if you
intend to set the KAM's HF port to a non-packet mode (RTTY, CW, etc.),
the port needs to be HF, not VHF.  See the section on Host Mode commands
for more information about changing the current stream, etc.

If you have told KAMterm that you are using a Kantronics TNC other than
the KAM, your status bar will differ slightly, depending on the type of
TNC you have.  Basically, instead of using VHF and HF, it will refer to
Port 1 (and Port 2, where applicable) just as your TNC does.

From here, if you hit [PgDn], you will see the following:

───────────────────────────────────────────────────────────────────────────────
F1=HELP COM1 9600 8N1            HOST MONITOR             09 May 1992  12:33:37
───────────────────────────────────────────────────────────────────────────────

This window is the HOST MONITOR WINDOW, and all monitor output will be
placed in this window.

From here, if you hit [PgDn] again (assuming there are no other windows
opened), you will go back to the HOST COMMAND WINDOW.  If, on the other
hand, you have a connection open (let's say your connected to my PBBS,
N5IAL-1, on VHF stream A), you would see the following:

───────────────────────────────────────────────────────────────────────────────
F1=HELP COM1 9600 8N1           VHF/A (N5IAL-1)           09 May 1992  12:33:37
───────────────────────────────────────────────────────────────────────────────

The TNC is indicating here that the current stream is VHF stream A, and
that it is connected to N5IAL-1 (or at least, KAMterm thinks it is).  If
you were to then disconnect from N5IAL-1, the status bar would change to
the following:

───────────────────────────────────────────────────────────────────────────────
F1=HELP COM1 9600 8N1                VHF/A                09 May 1992  12:33:37
───────────────────────────────────────────────────────────────────────────────

This indicates that the current stream is VHF stream A, and as far as
KAMterm knows, this stream is not connected to anyone.

KAMterm attempts to keep track of who you are really connected to at all
times.  So, for example, if you connect to a local digipeater node (we'll
call it FOO-DIGI), and then from there, you connect to a local BBS (we'll
call it FOO-BBS), you would see the status bar change to indicate the new
callsign you're connected to.  This assumes, however, that the format of
the status message from FOO-DIGI is along the lines of:

FOO-DIGI:callsign} Connected to FOO-BBS

The only thing that is really important is that the FOO-DIGI string
appear in the first string on the line, and that the next bits are the
``Connected to'' message, followed by the new callsign/alias.  This is
NOT case sensitive.

It is possible, however, that KAMterm will miss one of these status
messages and not correctly track who you are connected to.  If this is
the case, you can use the [ALT][Z] command to correct it.  This command
is described later.

When you change screens, the main window and the status bar will be
updated, but the local window will remain the same.  This way, you can
type the connect command, etc., while still looking at the information
on the screen.

5.2.3)  LOCAL  ECHO  vs.  INCOMING  TEXT

KAMterm allows you to use a different color for locally echoed text than
that used for incoming text from the TNC.  This is defined in the
configuration file, kamterm.cfg, which is discussed later. The default
is to use YELLOW for locally echoed text, and LIGHTBLUE, RED, OR GREEN
for incoming text in the COMMAND WINDOW, MONITOR WINDOW, and STREAM
WINDOWS, respectively.  These are also configured in the configuration
file.

5.3)  NEW  CONNECTS  (Host  Mode  ONLY)

In Host Mode, a new connect will cause a new window to be created if the
stream connected is not currently allocated to an active window.  So,
for example, if the only windows open are the COMMAND WINDOW and the
MONITOR WINDOW, and you connect to someone, a new window will
automatically be created to handle that stream.  If, on the other hand,
you made the connect on, say, VHF stream A, and a window was already
active on VHF stream A, no window would need to be created.  This
applies for incoming connects as well.

In addition to this, KAMterm will notify you of incoming connects.  This
requires that the TNC parameter RING be set to ON (the ^G characters
sent from the TNC on incoming connects are used as the indicator that
the connect was not originated by you).

6.0)  KAMterm  COMMANDS

6.1)  GENERAL  COMMANDS


In KAMterm, some commands are available all of the time, and others are
available only while in Host Mode operation.  In this section, those
commands which are available at all times will be discussed.  They are
covered in order by the key that calls them (i.e., [ALT][B] will be
covered before [ALT][F], etc.).

6.1.1)  [ALT][B]

This command is used to transmit a ``brag file'' to the connected
station. A window will popup and ask you for the name of the file you
wish to transmit.  If this file is found, it will be transmitted just as
if you had typed the information.  If, on the other hand, it is not
found, KAMterm will complain about not finding the file, and return to
normal operation.

During each phase of the file transmission, KAMterm will check to see
that the transmit buffers have been cleared before proceeding to the
next part of the file.  This is to help insure that the buffers in the
KAM are not overrun by trying to send information faster than it can
transmit it to the remote station.  If the KAM's buffers fill up, and it
tells your computer to stop sending data, the buffers within KAMterm
will not empty, and KAMterm will wait until it can move on.

This function is not really intended for use to upload large text files
to a BBS, etc., though it could probably be used for such applications.
It is intended for short files describing your station, and does not
implement any error control with the remote station, and assumes that if
the KAM is happy, the remote end is happy.

Functionality for uploading actual files will be added when I get the
protocol specifications for file transfer programs used on packet BBS
systems.

6.1.2)  [ALT][C]

This command clears the screen in the current window.

6.1.3)  [ALT][E]

This command toggles the local echo of characters to the screen (from
KAMterm, not from the KAM).  Local echo from KAMterm is normally used
when the KAM is not echoing characters you type.  In its normal
operating mode, the KAM uses the ECHO command to determine whether or
not you want input echoed back.  In Host Mode, the KAM does not echo
characters back to you.  Therefore, KAMterm's default action is to echo
characters back only in Host Mode operations.

It is important to note that this command affects the current operating
mode only.  That is, the setting of the local echo parameter for normal
mode and for Host Mode are two different settings.  [ALT][E] toggles the
setting for the mode you are in when you use this command, without
changing the other mode's value for this parameter.

The default values for echo in both normal and Host Mode operations can
be set from the configuration file, as well.  This is discussed later.

6.1.4)  [ALT][F]

This command is used to send a macro command file to the KAM.  You will
be asked for the name of the file you wish to send to the KAM (the
default will be the name of the startup command file, if one is
defined).  This command can be used to change the KAM's configuration
while running KAMterm, if desired.

The format of the macro file is the same as that for the startup and/or
exit command files, which will be discussed later.

6.1.5)  [ALT][G]

This command is used to call KAMterm's internal QSO logger (or,
alternatively, an external logging program).  In the log function, you
will be asked for the normal items you would enter in a logbook, such as
the person's callsign, the start/end times for the QSO, the frequency,
and so on.  If you are in Host Mode, KAMterm will maintain a different
set of log information for each window.

The internal log function for KAMterm is far from elegant.  It is
primarily intended as a quick and easy way to document the QSO
information without having to switch between a note pad, a logbook, and
the keyboard.

When entering QSO log information in the internal logger, do not save
it to a file until the entry is complete.  Once you save an entry to
disk, KAMterm assumes that you have completed that entry, and the next
time you access the log in that window, it will be blank.

If you wish to set a default filename for the logfile, you can do so via
the configuration file, kamterm.cfg.  This is also where you can
instruct KAMterm to use an alternate logging program.  See the section
on the configuration file for more details.

6.1.6)  [ALT][H]

This command toggles between normal mode and Host Mode.  This command
DOES change the KAM's configuration, as this is REQUIRED to change
to/from Host Mode.

IMPORTANT NOTE:  Changing the KAM's state to/from Host Mode requires a
reset, which will DROP ANY ACTIVE CONNECTS!!!

While in Host Mode, KAMterm keeps track of which windows' streams are
connected, and will warn you if it knows you have connects active.  In
normal mode, KAMterm doesn't know you're connected, and will NOT WARN
YOU.  Also, if you have entered the program in Host Mode, you may have
connects active that KAMterm hasn't detected, and it will not warn you
if this is the case.  It is also quite probable that the reset will drop
any connection to your PBBS that is active.

YOU ARE THEREFORE ADVISED to use the STATUS command to check to see if
there are any connects active before using this command.  STATUS will
tell you if any connects are active, including connects to your PBBS.

6.1.7)  [ALT][I]

This command provides some general information about KAMterm,
registration, etc.

6.1.8)  [ALT][K]

This command brings up a menu which allows you to change the function
key definitions.  The menu will appear in the upper left corner of the
screen, and its exact nature will vary, depending on whether or not a
mouse was detected on the system.  The items in the menu are as follows:

                ┌────────────────────────────┐
                │ F2 through F10             │
                ├────────────────────────────┤
                │ ALT F1 through ALT F10     │
                ├────────────────────────────┤
                │ CTRL F1 through CTRL F10   │
                ├────────────────────────────┤
                │ SHIFT F1 through SHIFT F10 │
                ├────────────────────────────┤
                │ Load new function key file │
                ├────────────────────────────┤
                │ Save function keys to file │
                ├────────────────────────────┤
                │ Exit                       │
                └────────────────────────────┘

The first four options allow you to change the characters that will be
sent to the KAM for the function keys themselves.  Note that plain [F1]
is not included in this list---[F1] itself is reserved for HELP.

The fifth option, ``Load new function key file'', allows you to load a
new set of function key definitions from a file.  You will be asked for
the name of the file, and if it exists, it will be loaded.  Function key
macro files can either be created through the program, or manually.

The sixth option, ``Save function keys to file'', allows you to save the
function key definitions you have defined to a file.  You will be asked
for the name of the file.   The results will then be stored to that
file.

The last option simply exits the menu.  Pressing [ESC] will do the same
thing.

The format for the function key file will be discussed in the section
entitled FUNCTION KEY DEFINITION FORMAT.

6.1.9)  [ALT][L]

This command toggles logging of the current window to a file.  If
logging on the current window is not active, you will be asked for the
name of the file to log to.

If the current window is being logged to a file, the far-left section of
the status bar, which normally indicates the communications port
parameters, will now show the filename that all data is being recorded
into, and will be reverse-video relative to the remainder of the status
bar.

In Host Mode, KAMterm will attempt to keep things organized in the log
file by indicating who said what.  It will use the callsign it last
detected as the current connected call for the remote end, and the
callsign you defined (if any) in the configuration file.  If you have
not defined a callsign, it will simply use ``YOU'' to refer to you.  If
KAMterm doesn't know who you are connected to, this will not happen.
You can manually define the callsign of the station you are connected to
(if you need to) by using the [ALT][Z] command (discussed in the Host
Mode Commands section).

6.1.10) [ALT][M]

This gives a quick snapshot of the amount of memory available to KAMterm
on your system.

6.1.11)  [ALT][P]

This command allows you to change the communications parameters from
within KAMterm.  You will be given the following list of options:

         ┌─────────────────────────────────────────────────┐
         │         Port [1-4]:                             │
         │         Port Speed:                             │
         │ The KAM's Host Mode *REQUIRES a port setting    │
         │ of N81 and bidirectional hardware flow control. │
         └─────────────────────────────────────────────────┘

The port option selects the communications port, and valid inputs are
[1], [2], [3], and [4], for COM1, COM2, COM3, and COM4, respectively.

The port speed option is just that---port speed.  The KAM does not
support port speeds greater than 9600 bps.  KAMterm will, however, allow
speed settings up to (and including) 115,200 bps.

Parity, data bits, and stop bits are automatically set at No Parity, 8
bits per character, and 1 stop bit.  These settings are required for the
KAM's Host Mode.

In addition, the KAM's Host Mode requires that flow control be in the
form of bidirectional hardware flow control.

In this mode of flow control, the CTS (Clear To Send) control line is
used to inform the computer that the KAM is ready to receive data, if
the computer has any to transmit, and the RTS (Request To Send) control
line is used by the computer to inform the KAM that it is ready to
receive data, if any is available.  These operate independently of each
other.  This mode of flow control is the preferred mode for use with
high-speed modems, etc., as it adds the ability for the computer to stop
data flow from the connected device when it is not ready.

6.1.12)  [ALT][R]

This command allows you to execute an external DOS command.  You will
be asked for the name of the command you wish to execute.  If you simply
press [CR], you will simply shell out to DOS.  If you decide not to do
anything here, simply press [ESC] to abort.

6.1.12.A)  [ALT][V]

This command puts KAMterm in a mode in which characters you type are
immediately transmitted to the TNC, instead of allowing you to enter an
entire line, editing it as needed, and then sending the line only after
you press [CR].

The primary use for this command is expected to be sending a '*' to the
TNC for autobaud purposes.  An alternate application of this mode would
be the non-packet HF modes (AMTOR, RTTY, CW, etc.) on the KAM.

There are, however, some substantial side-effects of this command under
Host Mode operations.  When operating packet in Host Mode, using this
mode would result in an AX.25 packet for each individual character you
type!  This, obviously, would make throughput on the frequency virtually
nil, exactly the same as if you had set PACLEN=1.

As a result of the above potential side-effects, this mode is only
available under certain conditions.  Under normal mode, this command can
be used at any time, and does not interfere with packet operations.
Under Host Mode, however, this can only be used for HF Stream 0 with a
KAM (i.e., for non-packet modes).

When this mode is in effect, the center portion of the status bar (which
identifies the current window) will go into reverse-video, relative to
the remainder of the status bar.  In Host Mode, this will only have any
effect on HF Stream 0's window---all other streams' windows will
function normally.

Note that when using this mode under Host Mode, special macro functions
such as @amtor, @lamtor, @fec, etc., will not function---each
character typed will be transmitted to the remote station as if it were
any other data.  Also, you will not be able to edit any typos, etc., in
this mode.  Once you type it, it's gone.

6.1.13)  [ALT][X]

Exit KAMterm.  If you are in Host Mode, and have connects active (and if
KAMterm knows about them) you will be asked if you REALLY want to exit.
If you are in Host Mode, regardless of whether or not you have connects
active, you will be given the option of leaving the KAM in Host Mode
(press [h]).

6.1.14)  [ALT][Y]

This command is used to set the date/time on the KAM.  It uses the
current date and time setting on your computer.

6.1.15)  [F1]

View HELP SCREEN.

6.1.16)  [UP-ARROW]

If scrollback is enabled, and if scrollback buffers could be allocated
to the current window, this will pull up the scrollback buffer for the
current window.  Within scrollback, [PgUp], [PgDn], [HOME], [END], [UP],
and [DOWN] will move you around in the scrollback buffer. [ESC] exits
back to KAMterm's normal operation.

In addition, if you wish to save the entire scrollback buffer to a file,
press [S].  KAMterm will then ask you for the filename that you wish to
save the buffer to.  Press [ESC] instead of entering a filename to abort
this operation.



6.2)  HOST  MODE  COMMANDS

In KAMterm, some commands are available only while in Host Mode
operation. In this section, those commands which are available only
while in Host Mode be discussed.

6.2.1)  [ALT][A]

This command loads a primative protocol analyzer.  This function was
originally built for testing purposes within the program, but users may
find it interesting, and as a result, it has remained in the program
code.

6.2.2)  [ALT][D]

This command will delete the current window.  It cannot be used on
either the COMMAND WINDOW or the MONITOR WINDOW.  If KAMterm is under
the impression that the stream associated with window you wish to remove
is connected, it will ask you if you are really sure you want to delete
it. Doing so will not affect the connect itself, but as soon as
information is received for that stream, the window will be created once
again (except that it will no longer have the connected callsign
associated with it, and will not even show up as being connected in the
STATUS BAR).

6.2.3)  [ALT][N]

This command allows you to change the stream associated with the current
window.  If the stream associated with that window is connected (or at
least, if KAMterm believes it is), you will be warned that a connect is
active, and asked if you really want to do this.

This command can be used under the COMMAND WINDOW, but you will probably
find it easier to use the ``faked'' TNC stream switch commands (see the
information on faked commands later in this section).

6.2.4)  [ALT][S]

This command is used to send special non-packet HF port commands to the
KAM.  This is needed due to the fact that in Host Mode, the KAM does not
use the normal CTRL-C,n directives.  This will bring up a menu of the
directives you can send.  All non-packet HF port directives documented
for Host Mode (currently, Kantronics firmware versions 4.0 through 6.0)
are implemented.

6.2.5)  [ALT][T]

In Host Mode, the KAM does not use the PACLEN parameter as it would in
normal command mode.  Instead, the length of transmitted packets is
determined by the block size of Host Mode data blocks.

KAMterm uses two parameters (defined in the configuration file, and
discussed in the section on setting up the configuration file) called
VHFPACLEN and HFPACLEN to determine the default packet length to be
transmitted.  This option allows you to override the default values you
select for a given window.

You will be asked for the new value to be used within this window when
you use this command.  The current maximum is 78, as this is the maximum
number of characters you can type on one line in KAMterm.  If you ask
for a higher number, KAMterm will currently back it off to 78. When the
ability to transmit entire files using the various protocols used on
packet BBS systems is added, this will be modified accordingly to avoid
artificially limiting the efficiency of such transfers.

6.2.6)  [ALT][W]

This command is used to create a new STREAM WINDOW. If you already have
too many windows open, KAMterm will complain if you (or an incoming
connect) try to open another window.  Also, if a STREAM WINDOW is
already open for the port/stream combination you request, the window
will not be created. Otherwise, the window will be created with the
information you give it.

BE ADVISED, however, that as you open more windows, things slow down a
bit when switching from one window to another.  On the system where this
was developed (20 MHz 386 w/ 2 Meg RAM, running Digital Research Dos
6.0), this did not become noticeable until about 8 to 10 windows were
open (this includes the COMMAND WINDOW and the MONITOR WINDOW).  If
things get too slow, and you have inactive windows, you may wish to
close them.

6.2.7)  [ALT][Z]

This command is used to manually override KAMterm's concept of who you
are connected to on a given stream, or even whether or not you are
connected at all.  You will first be asked if the window's stream is
connected.  If you respond NO ([N]), all connect information for that
window will be cleared.  If, on the other hand, you respond YES ([Y]),
you will then be asked for the correct callsign of the person/bbs you
are connected to.

This command is primarily intended for either of two purposes.  First,
if you start KAMterm in Host Mode, and there is already a connect
active, KAMterm will not see the incoming status message, and will not
register the connect---this allows you to manually correct for this
problem. Second, if (and I have never seen this happen, but it is
possible) KAMterm should miss an incoming connect message from a
digipeater, you can insert the correct information yourself.

6.2.8)  [ALT][=]

This command is used to tell KAMterm that the window you are currently
in is the PRIORITY stream, and that you want to keep tabs on what is
going on in that window.  Using this command will create a PRIORITY
WINDOW, which uses the top four lines of the screen when any other
window is displayed on the screen to display incoming text that is being
displayed on the window you have defined to be your PRIORITY stream.

This could be used, for example, for sitting on a DX cluster while
working packet, RTTY, etc., over in another window.  With the PRIORITY
WINDOW, you don't have to check the other window every few minutes to
see if anything interesting has come in---you can have a smaller
version of that window at the top of your screen to keep an eye on.

This command can also be used when the PRIORITY WINDOW is active to
CHANGE the stream that it monitors (i.e., you don't have to delete an
existing PRIORITY WINDOW just to change the stream you wish to keep tabs
on).

6.2.9)  [ALT][-]

This command is used when you want to temporarily hide the PRIORITY
WINDOW, but you still want to keep it active.  This simply toggles
whether or not the priority window is actually displayed on the screen.

6.2.10)  [ALT][0]

This command completely deletes the PRIORITY WINDOW.

6.2.11)  [ALT][1]

This command creates the AMTOR XMITECHO WINDOW.  This window also
applies for PacTOR, under Kantronics firmware at version 6 and above.

This is the result of another addition in version 5 of the KAM's
firmware, the ability to use the XMITECHO parameter on the KAM when
running AMTOR under Host Mode. If this window is active, it will display
the KAM's status on transmitting the text you type.  Unlike normal mode
operations, this does not impact the normal echoing of characters to the
screen as you type them.  Instead, this will take the form of a small
window in the upper portion of the screen (just like the PRIORITY WINDOW
described earlier).

This option requires that the KAM's XMITECHO parameter be turned on to
operate.

This option is not documented in the version 4 documentation, but may
work there as well.  It is, therefore, not restricted within
KAMterm to version 5 firmware or above.

To create this window, you press [ALT][1].  The port/stream of the
current window must be HF/0 (HF PORT 0).  This small window will not be
displayed in other streams' windows.  If the PRIORITY WINDOW is also
active, this will override that window.

If the AMTOR XMITECHO WINDOW does not exist, and XMITECHO is turned on,
incoming data blocks identified as XMITECHO data will be treated as any
other data coming from the KAM, and displayed in the appropriate window
along with other incoming text.

6.2.12)  [ALT][2]

This command is used when you want to temporarily hide the AMTOR
XMITECHO WINDOW, but you still want to keep it active.  This simply
toggles whether or not the AMTOR XMITECHO window is actually displayed
on the screen.

6.2.13)  [ALT][3]

> This command completely deletes the AMTOR XMITECHO WINDOW.

6.2.14)  [HOME]

This command takes you immediately to the COMMAND WINDOW.  It will also
set the stream and port associated with the COMMAND WINDOW to that which
is associated with the window you were in when you used the HOME key.
(This last bit does not, however, apply to the MONITOR WINDOW, or the
PROTOCOL ANALYZER window if it is open, as these have no actual
stream/port association.  In this case, the stream/port associated with
the COMMAND WINDOW is left as it was.)

6.2.15)  [PgDn]

This takes you to the next window active in KAMterm.  If you are at the
last window, it will wrap you around to the COMMAND WINDOW.

6.2.16)  [PgUp]

This takes you to the previous window active in KAMterm.  If you are at
the COMMAND WINDOW, it will wrap you around to the last active window.

6.2.17)  ``Faked''  Commands

Normally, Host Mode doesn't have some of the things normal command mode
does, and this can be rather annoying at times.  To make things easier,
KAMterm ``fakes'' some of these things, and takes the appropriate action
for you.  These pseudo-commands are only effective in the COMMAND
WINDOW.

Fake command prompt (hcmd:)

Normally, the TNC gives you a cmd: prompt telling you it is ready to
accept commands.  When you are used to this, it can be distracting to
simply get a blank screen staring at you in Host Mode.  To eliminate
this problem, KAMterm generates its own prompt, hcmd: (the 'h' is added
to avoid confusion with the real cmd: prompt). A simple [CR] will result
in new hcmd prompt.  This is done for aesthetics only, and has no impact
or interaction with the TNC.

|n and ~n

In Host Mode, the KAM does not respond to the stream switch commands as
it does in normal command mode, because each block of data transmitted
to and from the KAM contains its own stream/port information, and
setting the KAM to a stream/port would have no meaning.

KAMterm will, however, allow you to use the stream switch commands as if
you were in normal command mode.  The difference here is the result.  In
normal command mode, using these changes all I/O with the KAM over to
another stream, which will be affected by what you type.  In Host Mode,
KAMterm uses these commands internally to change the stream/port
combination associated with the COMMAND WINDOW.  This will have
basically the same effect, since your commands will now impact the new
stream you have selected---it is simply handled within KAMterm instead
of by the TNC.

6.2.18)  AMTOR  SPECIAL  COMMANDS

To make working AMTOR a bit simpler, three special commands have been
created in KAMterm.  These are @AMTOR, @FEC, and @LAMTOR.  These special
commands are entered directly as if they were text to be transmitted
(i.e., in the LOCAL WINDOW---similar to the faked commands '|n' and
'~n'), and will only work under the following conditions:

   *) You must be in Host Mode
   *) The current port/stream must be HF/0
   *) You are assumed to be planning to work AMTOR

Note that these commands are not implemented as function key macros at
this time, nor are they in effect when transmitting macro files. This
may be added in the future, if there are requests to do so.

Normally, when working AMTOR, you might listen for a CQ using the KAM's
LAMTOR command, and then call the remote station using either Mode A
(ARQ) or Mode B (FEC).  To do this, however, you must first put the KAM
back into packet mode (to remove it from LAMTOR mode), and then go to
the COMMAND window and enter either ``AMTOR selcal'' or ``FEC selcal''
to connect to the remote station.

These special commands allow you to switch from whatever mode you might
be in to the appropriate AMTOR mode, unless you are already connected on
an HF packet stream (in which case, the KAM will probably not allow you
to do this).

@AMTOR is used to immediately enter ARQ mode.  If it is followed by the
SELCAL of the remote station you wish to connect with, it will cause the
KAM to attempt to connect to that station.  If it is not followed by any
additional arguments, it will simply place the KAM in ARQ mode.

Likewise, @FEC can either be used to connect with another station in
AMTOR FEC mode, or simply to enter that mode.

@LAMTOR takes no arguments---it simply puts you into the LAMTOR mode,
where you can monitor both ARQ and FEC transmissions, but cannot enter
transmit mode.

6.2.19)  PacTOR  SPECIAL  COMMANDS

To make working PacTOR (version 6 or higher firmware required) a bit
simpler, two special commands have been created in KAMterm.  These
are @PACTOR and @PTLISTEN.  These special commands are similar to the
AMTOR special commands, @amtor, @fec, and @lamtor, and work as
described below.

@PACTOR is used to immediately enter PacTOR mode.  If it is followed by
the callsign of the remote station you wish to connect with, it will
cause the KAM to attempt to connect to that station.  If it is not
followed by any additional arguments, it will simply place the KAM in
PacTOR standby mode.

@PTLISTEN takes no arguments---it simply puts you into the PacTOR
LISTEN (PTLISTEN) mode, where you can monitor PacTOR transmissions, but
cannot enter transmit mode.


7.0)  THE  CONFIGURATION  FILE

KAMterm uses a configuration file called kamterm.cfg, which allows you
to change most aspects of its configuration.  This file must exist,
however, it need not have all configuration options in it (or any of
them, for that matter).  Any options which are not set within this file
simply revert to their default values.  If the file is not found at all,
the system will create one for you with only the communications
parameters.

Within the configuration file, anything following a '#' character is
treated as a comment, blank lines will be ignored, and commands within
the file are not case-sensitive.  Only one command is allowed per line
in the file.  In the examples shown below (and in the sample
configuration file), a colon follows the field name---this is
optional, and is included for readability only.  KAMterm ignores this
completely.

Throughout this section, example commands will be represented as:

        INITFILE:  startup.kam

There may be several commands grouped together, but the groups of
commands (or the command) will have a blank space above and below it,
and will be indented.  If KAMterm does not understand the input in any
line, it will advise you of this, and tell you the offending line number
within the configuration file.

7.1)  GENERAL  OPTIONS

There are several types of options which may be set from the
configuration file.  This section will cover those which are general in
nature, and don't apply to any specific grouping.

7.1.1)  EXPERTMODE

Define EXPERTMODE (uncomment it) if you are familiar with KAMterm and
pretty much know your way around.  If this isn't defined, you will get
the odd pointer here and there telling you what's going on, and how to
deal with it.  This functionality is very new right now, but it will no
doubt grow in the future.  YOU TELL ME.

7.1.2)  CAPBUFF

CAPBUFF is the size of the scrollback buffer for EACH WINDOW.  Take care
when increasing this number---remember that each stream will have this
allocated to it, and that eats memory.  I suggest you start with the
default (100 lines) and gradually increase.  If a window is opened, and
there isn't room to allocate this number of lines, that window will not
have a scrollback buffer, but will be opened (provided there is enough
memory left to do so).

Here are some sizes for 100 line increments of the scrollback buffer
(note that there is clearly a pattern here):

      0 lines:  scrollback disabled
    100 lines:  18,400 bytes per active window
    200 lines:  28,400 bytes
    300 lines:  38,400 bytes
     ......      .......
    800 lines:  88,400 bytes

The example below sets the scrollback buffer size to 200 lines.

        CAPBUFF: 200

7.1.3)  INITFILE  and  EXITFILE

These options set the filenames for the optional command (macro) files
to be sent to the KAM when starting and exiting KAMterm.  In the
following example, when KAMterm is loaded, it will transmit all commands
in the file called startup.kam to the TNC, and right before exiting,
will do the same for the file finish.kam.

        INITFILE:  startup.kam
        EXITFILE:  finish.kam

The filenames can be anything you choose, provided of course that it is
a legal dos filename, and that the total length of the path/filename
does not exceed 80 characters.  The format for these files will be
covered in the section called FORMAT FOR INIT/EXIT COMMAND FILES.

7.1.4)  QSO LOG OPTIONS

There are several options which can be used to customize the operation
of the QSO logging functionality in KAMterm.  These include setting a
default file to log information to, setting up an external logging
program, asking KAMterm to automatically (and silently) record the times
for connects and disconnects, etc.

The first option is LOGFILE.  This sets the default filename that
KAMterm will use when logging QSOs to a file.  You will still be asked
for a filename, and can choose an alternate file if you so desire. This
is optional, and if this is not found in your configuration file,
KAMterm will simply present a blank field when asking for the filename.

The next option is AUTOLOGFILE, which tells KAMterm the name of the file
to which connect/disconnect times will be (silently) recorded. If this
option is not included, this information simply will not be recorded.

In the following example, the default filename to use for manually
entered logs is kamterm.log, and the filename for the automatic
recording of start/end times is autolog.kam.

         LOGFILE: kamterm.log
         AUTOLOGFILE: autolog.kam

In addition to these options, if you wish to use an external logging
program, you would identify it to KAMterm by using the LOGGER option.
With this option, when you press [ALT][G], you will execute the external
logging program, and when you exit from it, you will return to KAMterm.
If you want KAMterm to check with you before calling the external
logging program (e.g., if you sometimes use the internal logger), you
can use the ASKLOGGER option.  If ASKLOGGER is not used in your
configuration file, KAMterm will run the external logging program every
time you press [ALT][G].

In the following example, the external logging program is called by the
command ``mylogger logfile.txt'' and we do want KAMterm to ask before
calling the external logger.

         LOGGER: mylogger logfile.txt
         ASKLOGGER: YES

7.1.5)  MORSESPEED

KAMterm uses Morse code for a few minor status messages and error
messages. This option allows you to determine the code speed at which
Morse code messages will be sent from within KAMterm.  The default is 20
WPM. If this parameter is set to 0 (zero) words per minute, Morse
messages will be disabled.

The example below shows the default setting of 20 WPM:

        MORSESPEED: 20

NOTE:  According to the documentation for Turbo C++, the functions used
for determining the delays used in generating the Morse code messages do
not vary with the CPU speed of the computer the program is run on. Tests
run on multiple computers have verified this, however, if you should
happen to find this to be in error, you may need to experiment a bit.

7.1.6)  MORSETONE

This option allows you to change the frequency of the tones used for
Morse code messages.  The default is 600 Hz, as represented in the
example below:

        MORSETONE: 600

7.1.7)  MYCALL

MYCALL is the callsign that will be used for logging to a file. This
does not affect the value in the TNC in any way.  The example below sets
MYCALL to N5IAL.

        MYCALL: N5IAL

7.1.8)  NORMALECHO  and  HOSTECHO

NORMALECHO and HOSTECHO are used to determine if KAMterm should default
to echoing text locally in normal command mode and Host Mode,
respectively.  The values selected for these must be either 1 for on or
0 (zero) for off.

The default for normal mode is NOT to echo text locally, and the default
for Host Mode is to echo text.  The examples shown below illustrate how
those parameters would be set if they were included in the startup file.

        NORMALECHO: 0
        HOSTECHO: 1

7.1.9)  P1PACLEN  and  P2PACLEN

These options are exactly the same as VHFPACLEN and HFPACLEN,
respectively, but are provided for the non-KAM multi-port TNCs, who do
not refer to ports as VHF and HF, but rather, as PORT 1 and PORT 2.

Internally, KAMterm will not know the difference between P1PACLEN or
VHFPACLEN, and P2PACLEN or HFPACLEN, regardless of the type of TNC you
are using.  These new options are for basically for aesthetic purposes
and to avoid confusion for non-KAM users.

7.1.10)  VHFPACLEN  and  HFPACLEN

In Host Mode, the KAM does not use the settings defined by its PACLEN
setting.  This is left up to the Host Mode software.  Therefore, KAMterm
provides two parameters, VHFPACLEN and HFPACLEN, which correspond to the
VHF and HF portions of the PACLEN setting, respectively.

In KAMterm, a line of text is limited to 78 characters (limited by the
screen size), and the maximum setting for each of these options is,
therefore, 78 (a higher value would have no meaning).  When the various
file transfer protocols used on packet BBS systems is added, this will
be changed to avoid artificially limiting the throughput on file
transfers. Currently, the default for each of these settings is 78
characters, as shown in the examples below.

        HFPACLEN:  78
        VHFPACLEN:  78

7.1.11)  MARGINBELL

If you choose to do so, you can activate a margin bell that will sound
when you reach the specified number of characters from the left margin
(similar to the margin bell on actual mechanical typewriters).  The
default option is for this to be turned off, and if nothing is setup
in the configuration file, there will be no bell.  If, however, you wish
to set the margin bell to sound at a given column, you would setup
something like the example below, which assumes you want the bell to
sound 5 spaces from the right margin (the right margin is at column 78,
therefore, you would want it to sound when you hit column 73):

        MARGINBELL:  73

7.1.12)  TNCTYPE

This parameter tells KAMterm what type of TNC you are using, and
allows it to taylor its operation to fit your needs.  Valid options
are as follows:

*) KAM---tells KAMterm you are using the Kantronics All Mode (KAM).
   All features of KAMterm will be available to you (within the
   limits of your firmware revision---see KAMVERSION).
*) MPORT---tells KAMterm you are using a multi-port Kantronics
   TNC other than the KAM (e.g., the KPC-4).  All KAMterm features
   will be enabled except those dealing with non-packet HF modes.
   Port names will refer to PORT 1 and PORT 2, instead of VHF and HF.
*) SPORT---tells KAMterm you are using a single-port Kantronics
   TNC (e.g., the KPC-2, KPC-2400, and KPC-1).  With this option, there
   are no references to ports at all---only the stream is identified.
*) OTHER---tells KAMterm that you are not using a Kantronics TNC
   at all.  At the present time, only the Kantronics Host Mode
   interface protocol is supported.  When this option is in effect,
   KAMterm will not allow you to use any Host Mode operations.

NOTE:  If your TNC does support Host Mode, and you would like to see it
supported under KAMterm, please contact me---I would like to expand
KAMterm to support other Host Mode interface protocols for a future
revision.  You might also want to take a look at KTterm, which is geared
toward non-Host operations specifically.

If nothing is listed under this parameter, the default is to assume that
you have a KAM attached.

7.1.13)  STARTHOST and ENDHOST

These options control whether or not KAMterm assumes it is supposed
to startup and/or exit in Host Mode.

If you have STARTHOST defined in the configuration file, KAMterm will
assume that your TNC is already in Host Mode when it starts up, and
will immediately initialize itself in Host Mode.  If, in fact, the TNC
is not already in Host Mode, KAMterm and your TNC will not be able
to communicate.  You can solve this problem by using [ALT][h] to leave
Host Mode (within KAMterm), and then use it again to go right back into
Host Mode (taking the TNC with you).

If you have ENDHOST defined in the configuration file, and if you are
in Host Mode when you exit (i.e., you haven't dropped into normal mode
first), KAMterm will leave your TNC in Host Mode when it exits.  If
you try to use a plain (i.e., dumb) terminal program after that, it will
not be able to communicate with your TNC, because the TNC is still
expecting Host Mode data blocks.

These parameters are generally used if you only use Host Mode with your
TNC.  They are important in this case, because changing in and out of
Host Mode requires a soft reset on the TNC, which will drop any active
connections (including connects to your PBBS).  However, if you plan to
use other terminal programs with your TNC, use them with care (i.e.,
make sure you know what you're doing)!

7.1.14   KAMVERSION

In order to prevent problems with TNCs running older versions of the
firmware, KAMterm requires that you specifically tell it if you are
running revisions above 4.x.  To do this, use the following in the
configuration file:

        KAMVERSION: 5

The above tells KAMterm that you are running under version 5 of the
firmware.  This number must be an integer number (i.e., do not use 5.1,
etc.).  If you are not running version 5 of the firmware (or higher),
this need not be included, as the default is to assume that you are
running firmware prior to version 5.

One of the nice things that version 5.0 of the KAM firmware added is
the ability of the LEDs on the front panel to act as they would in
normal command mode.  So, for instance, CON now indicates that the
currently active stream is connected.  KAMterm will send an update
command to the KAM when you change windows to cause it to show the
current status for the stream associated with the window you change
to.  This does not, however, apply to the MONITOR window or to the
PROTOCOL ANALYZER windows, as these have no stream associated with
them.  When changing to these windows, the KAM will remain on the
last active stream.

Version 6, of course, adds PacTOR to the KAM, and KAMterm has some
internal macros for PacTOR (like AMTOR), that can reduce the time
required to change modes, etc., if you have told KAMterm that you
have version 6 firmware (otherwise, these macros are disabled).

7.2)  COMMUNICATIONS  PARAMETERS

This section discusses the communications parameters that can be set
from the configuration file.

7.2.1)  COMMPORT

COMMPORT sets the default serial port which KAMterm will use, and must
be one of 1, 2, 3, or 4, for COM1 through COM4, respectively.  In the
example below, COM1 (the default) is selected.

        COMMPORT: 1

7.2.2)  PORTSPEED

PORTSPEED sets the default serial port speed which KAMterm will use.  As
this is being written, the KAM does not allow port speeds higher than
9600 bps (KAMterm will support anything up to and including 115,200 bps).
The example below shows the default setting, 9600 bps, and how it would
be set in the file.

        PORTSPEED: 9600

7.2.3)  NONSTDPORT (for non-standard serial ports)

This command is used for serial ports that are not using the
``standard'' base address and interrupt (IRQ) combinations shown
in the following table:

          ╔══════════╤═════════════╤══════════════╗
          ║ COM PORT │ IRQ CHANNEL │ BASE ADDRESS ║
          ╠══════════╪═════════════╪══════════════╣
          ║     1    │      4      │ 0x3f8 (3F8H) ║
          ╟──────────┼─────────────┼──────────────╢
          ║     2    │      3      │ 0x2f8 (2F8H) ║
          ╟──────────┼─────────────┼──────────────╢
          ║     3    │      4      │ 0x3e8 (3E8H) ║
          ╟──────────┼─────────────┼──────────────╢
          ║     4    │      3      │ 0x2e8 (2E8H) ║
          ╚══════════╧═════════════╧══════════════╝

If your serial port uses an IRQ channel and/or base address other than
those listed in the table above, you must use this parameter to tell
KAMterm where your port actually is.

While this does provide a great deal more flexibility, there are still
limitations on what can be supported (for now, at least---I hope to
change this).  Only COM1--COM4 are supported, and the interrupt (IRQ)
line must be between IRQ3 and IRQ7, inclusive.  Anything outside of
this range will fail.  If you give KAMterm an incorrect base address,
it may think it's correctly initialized the port, but it will never see
CTS go high, and you won't get beyond a warning telling you that CTS is
low.  Use this command with care, and make sure you know what you're
doing.

The following example shows how this command would be used to specify
a serial port that is COM1 (first argument is '1'), uses IRQ6 (the
second argument is '6'), and has a base address of 0x3f8 (the third
argument).

        NONSTDPORT 1 6 0x3f8

If all three arguments are not present, this command will fail.  Note
that a ``-1'' (negative one) may be used in cases where the argument
is, in fact, the default.  So, for the above, we see that the default
base address for COM1 is 0x3f8, and that's what our example serial
port uses, so this could have also been written as shown below.

        NONSTDPORT 1 6 -1

Again, make sure you know what you are doing here.  This is one area
where a simple error could easily lock up your machine.  If you use
anything other than the standard configurations (as in the table above),
I suggest that you keep a table showing your system's configuration
(both interrupt line and base address) for every serial port, mouse,
soundboard, etc., that you have installed.  This helps prevent not only
software errors, but errors when installing new hardware, as well.[1]

---------
[1]  Actually, this is a good idea, period, even if your hardware uses
     only standard configurations.  I have saved myself a lot of time
     that would have been spent digging in manuals for boards that
     aren't properly labelled, etc., by using a simple table containing
     this information, and always keeping it up-to-date (which, of
     course, is obviously required).


7.3)  COLOR  SETTINGS

COLOR commands take exactly 2 arguments, and they must be in the right
order.  The first argument is the parameter which we wish to associate
the color with, and the second is the color itself.

A setup program is included which will allow you to easily configure
the colors to be used by KAMterm, as well as the other configuration
options.  It is recommended that you use this configuration program,
as it will let you change color definitions with one keystroke and
immediately see the result on the screen.

Monochrome users will only see different shades of gray with these
colors, but they can still gain a lot by going through this
configuration process.

Monochrome VGA users (e.g., those with laptop LCD screens) may need to
use the {mode bw80} command to specifically force monochrome mode in
order to get the window manager to use gray-scale instead of actual
colors.

Choices for colors are as follows:

         BLACK         DARKGRAY
         BLUE          LIGHTBLUE
         GREEN         LIGHTGREEN
         CYAN          LIGHTCYAN
         RED           LIGHTRED
         MAGENTA       LIGHTMAGENTA
         BROWN         YELLOW
         LIGHTGRAY     WHITE


The first set of color parameters deal with the colors assigned to the 3
key areas of the screen in normal operations (i.e., not in a menu,
etc.). The second set of color parameters deal with the colors used for
popup windows, menus, text entry (e.g., when you are asked for a
filename), and so on.  These are shown in the following tables.

    ╔═════════════════════════════════════════════════════════════════╗
    ║          Screen Colors for Normal Operations                    ║
    ╠══════════════════════╤══════════════════════════════════════════╣
    ║  STATFG              │  STATUS LINE foreground                  ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  STATBG              │  STATUS LINE background                  ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  PRIFG               │  PRIORITY WINDOW foreground              ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  PRIBG               │  PRIORITY WINDOW background              ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  LOCALFG             │  LOCAL WINDOW foreground                 ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  LOCALBG             │  LOCAL WINDOW background                 ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  MAINFG              │  MAIN COMMAND WINDOW foreground          ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  MAINBG              │  MAIN COMMAND WINDOW background          ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  MONFG               │  MONITOR WINDOW foreground               ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  MONBG               │  MONITOR WINDOW background               ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  STREAMFG            │  STREAM WINDOW(s) foreground             ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  STREAMBG            │  STREAM WINDOW(s) background             ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  ECHOFG              │  local echo foreground (any window)      ║
    ╟──────────────────────┼──────────────────────────────────────────╢
    ║  ECHOBG              │  local echo background (any window)      ║
    ╚══════════════════════╧══════════════════════════════════════════╝

╔════════════════════════════════════════════════════════════════════════════╗
║                     Popup Menu/Window Colors                               ║
╠═══════════════════════════╤════════════════════════════════════════════════╣
║  POPUPFG                  │ popup window foreground                        ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  POPUPBG                  │ popup window background                        ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  HELPFG                   │ help screen foreground                         ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  HELPBG                   │ help screen background                         ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  SBFG                     │ scrollback screen foreground                   ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  SBBG                     │ scrollback screen background                   ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUFG                   │ menu foreground                                ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUBG                   │ menu background                                ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUBDRFG                │ menu border foreground                         ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUBDRBG                │ menu border background                         ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUSELFG                │ menu selected item foreground                  ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUSELBG                │ menu selected item background                  ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUFIRSTFG              │ foreground for highlighted single key in menu  ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  MENUFIRSTBG              │ background for highlighted single key in menu  ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  ENTRYFG                  │ text entry foreground                          ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  ENTRYBG                  │ text entry background                          ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  ENTRYKEY                 │ text entry key text (labels)                   ║
╟───────────────────────────┼────────────────────────────────────────────────╢
║  ENTRYMSG                 │ text entry message text (messages to user)     ║
╚═══════════════════════════╧════════════════════════════════════════════════╝


The examples below show the default assignments for each of these items.

        COLOR: STATBG LIGHTGRAY
        COLOR: PRIFG BLUE
        COLOR: PRIBG LIGHTGRAY
        COLOR: LOCALFG GREEN
        COLOR: LOCALBG BLACK
        COLOR: MAINFG LIGHTBLUE
        COLOR: MAINBG BLACK
        COLOR: MONFG LIGHTRED
        COLOR: MONBG BLACK
        COLOR: STREAMFG LIGHTGREEN
        COLOR: STREAMBG BLACK
        COLOR: ECHOFG YELLOW
        COLOR: ECHOBG BLACK
        COLOR: POPUPFG YELLOW
        COLOR: POPUPBG BLUE
        COLOR: HELPFG LIGHTGREEN
        COLOR: HELPBG DARKGRAY
        COLOR: SBFG YELLOW
        COLOR: SBBG BLACK
        COLOR: MENUFG BLACK
        COLOR: MENUBG LIGHTGRAY
        COLOR: MENUBDRFG RED
        COLOR: MENUBDRBG LIGHTGRAY
        COLOR: MENUSELFG YELLOW
        COLOR: MENUSELBG CYAN
        COLOR: MENUFIRSTFG RED
        COLOR: MENUFIRSTBG LIGHTGRAY
        COLOR: ENTRYFG YELLOW
        COLOR: ENTRYBG LIGHTGRAY
        COLOR: ENTRYKEY BLUE
        COLOR: ENTRYMSG RED

If the color selected or the parameter to assign that color to are not
valid, KAMterm will advise you that it did not recognize what you were
trying to do, and the line number in the configuration file where the
mistake was found.

8.0)  FUNCTION  KEY  DEFINITION  FORMAT

If you are creating a file containing function key definitions by hand,
it must follow a specific format.  First, in most cases, anything
following a '#' character is treated as a comment, and ignored by the
program.  The only exception to this is the line of text associated with
the function key, where the '#' character is treated as any other
character would be.

8.1)  GENERAL  FILE  FORMAT

When definining text to be transmitted, the ']' character is used for a
carriage return.  This is not required at the end of the line, as a [CR]
will automatically be sent at the end of the macro key.  It is primarily
used for multiple commands being placed within one macro key. At this
time, the notation '^n' to send a CTRL-n key sequence is not supported.

To define the text to be sent to the KAM when a function key is pressed,
you first need to tell KAMterm what key you are defining.  To do this,
simply enter one of the following on a line by itself:

        {KEY Fn}
        {KEY ALT Fn}
        {KEY CTRL Fn}
        {KEY SHIFT Fn}

where 'n' is a number from 2 to 10 for the function keys by themselves,
or from 1 to 10 for [ALT], [CTRL], or [SHIFT] and the function key.
Again, [F1] is reserved for the HELP command within KAMterm.

The next line of text is the text that will be sent to the KAM when you
press that function key.  If the next line of text is blank, it will be
ignored.  Function key definitions cannot extend beyond one line, and
are limited to 80 characters.  In this line, the '#' character is NOT
treated as a comment.

So, for example, if we want to define [F2] to connect to FOO-BBS via
FOO-DIGI, we would enter something like the following:

                  ┌──────────────────────┐
                  │ KEY F2               │
                  │ C FOO-BBS v FOO-DIGI │
                  └──────────────────────┘

As for comments within the above, take a look at the following example:

          ┌──────────────────────────────────────────────────┐
          │ # This is a valid comment, and is ignored        │
          │ KEY F2     # This is also a valid comment        │
          │ C FOO-BBS v FOO-DIGI    # This is NOT a comment! │
          └──────────────────────────────────────────────────┘

In the above example, pressing [F2] would result in the following
being transmitted to the KAM:

     ``C FOO-BBS v FOO-DIGI    # This is NOT a comment!<CR>''

Note that the <CR> is automatically added at the end of the line.  If
the connect string itself had been followed by a ']' character, (i.e.,
``C FOO-BBS v FOO-DIGI]''), an additional <CR> would have been inserted
there, as well, thus sending TWO commands to the TNC (the second of
which would be ``# This is NOT a comment!'').

8.2)  INTERNAL  COMMAND  MACROS

Function key definitions within KAMterm can, to some degree, call
internal functions within KAMterm and thus provide single-key access
to some commands.  These are primarily intended to simplify operations
used while in a QSO, where you may often use the same command with the
same parameters (e.g., sending a ``brag'' file), or where using the
menu structure may be considered inconvenient or overly time-consuming.

As with any other command in the configuration files, these options are
not case-sensitive.  Only one internal command macro is allowed for a
function key---if more exist on the line, they will not be recognized
by KAMterm.

Some of these macros are available only in Host Mode.  If you attempt
to use them in normal command mode, KAMterm will respond with an 'H'
in Morse Code, reminding you of this (assuming you have not disabled
Morse messages).

8.2.1)  @BRAG

This macro is used to transmit a ``brag'' file, as if you had entered
the [ALT][B] command.  This command takes one optional argument, the
filename for the ``brag'' file to be transmitted.  If the filename is
not given, you will be asked to provide the filename.

8.2.2)  @MACRO

This macro is used to transmit a macro command file to the KAM, as if
you had entered the [ALT][M] command.  This command takes one optional
argument, the filename for the macro file.  If the filename is not
given, you will be asked to provide the filename.

8.2.3)  @DAYTIME

This macro is used to set the time and date on the KAM, as if you had
entered the [ALT][Y] command.  It accepts no arguments.

8.2.4)  @EXEC

This macro is similar to the [ALT][R] command.  The difference here,
is that you specify the command you wish to execute directly in the
function key macro line.  Like the [ALT][R] command, if you do not
provide a command to execute, you will simply shell out to dos.

8.2.5)  @SHELL

This macro is used to immediately shell out to DOS.  It takes no
arguments.

8.2.6)  @SET_PRIWIN

This macro is the equivalent of the [ALT][=] command, which sets the
PRIORITY WINDOW to the current stream.  It accepts no arguments. This
internal macro is only available in Host Mode.

8.2.7)  @TOGGLE_PRIWIN

This macro is the equivalent of the [ALT][-] command, which toggles the
display of the PRIORITY WINDOW.  It accepts no arguments. This internal
macro is only available in Host Mode.

8.2.8)  @DELETE_PRIWIN

This macro is the equivalent of the [ALT][0] command, which deletes
the PRIORITY WINDOW.  It accepts no arguments. This internal macro is
only available in Host Mode.

8.2.9)  @SET_AMTORWIN

This macro is the equivalent of the [ALT][1] command, which sets the
AMTOR XMITECHO WINDOW to the current stream.  It accepts no arguments.
This internal macro is only available in Host Mode.

8.2.10)  @TOGGLE_AMTORWIN

This macro is the equivalent of the [ALT][2] command, which toggles the
display of the AMTOR XMITECHO WINDOW.  It accepts no arguments. This
internal macro is only available in Host Mode.

8.2.11)  @DELETE_AMTORWIN

This macro is the equivalent of the [ALT][3] command, which deletes the
AMTOR XMITECHO WINDOW.  It accepts no arguments. This internal macro is
only available in Host Mode.


8.2.9)  @HFSPECIALS  Macros

These internal macros duplicate the functionality of selections under
the [ALT][S] menu, which transmits non-packet HF port directives to the
KAM in Host Mode.  These macros are, therefore, only available in Host
Mode.  There are five parameters which can be used with @HFSPECIALS.
These are XMIT, RCVE, RCVI, PACKET, and CLRXMIT.  If you use any other
parameter with this macro, KAMterm will respond with a '?' in Morse
Code, indicating that it doesn't understand what you want it to do
(assuming you have not disabled Morse messages).

@HFSPECIALS XMIT

This command causes the KAM to enter transmit mode.

@HFSPECIALS RCVE

This command causes the KAM to enter receive mode when the transmit
buffer is empty.

@HFSPECIALS RCVI

This command causes the KAM to enter receive mode immediately.

@HFSPECIALS PACKET

This command causes the HF port on the KAM to return to packet mode.

@HFSPECIALS CLRXMIT

This command clears the transmit buffer for the KAM's HF port.

@HFSPECIALS PTABORT

This command, which requires firmware revision 6 or higher, immediately
aborts a PacTOR connection.

@HFSPECIALS PTDISCONNECT

This command, which requires firmware revision 6 or higher, causes a
controlled disconnect of a PacTOR connection.

@HFSPECIALS PTAUTOBAUD

This command, which requires firmware revision 6 or higher, sets the
PacTOR link to the autobaud mode (recommended).

@HFSPECIALS PT100BAUD

This command, which requires firmware revision 6 or higher, attempts to
force the PacTOR link to use 100 baud.  This may not work with some
non-KAM PacTOR controllers on the other end of the link.

@HFSPECIALS PT200BAUD

This command, which requires firmware revision 6 or higher, attempts to
force the PacTOR link to use 200 baud.  This may not work with some
non-KAM PacTOR controllers on the other end of the link.


9.0)  FORMAT  FOR  INIT/EXIT  COMMAND  FILES

When using the startup and exit command files, there are only two key
things you must remember.  First, comments MUST have the '#' in the
first column on the line. This is done here in order to allow you to use
this character in TNC commands, if you so desire.

Second, if you wish to continue a command on to the next line (e.g., for
CTEXT), all you have to do is make sure the last character on the line
is a '\'.  This character is ignored anywhere else on the line, but in
this position, it will result in sending the ^V^M sequence to the KAM to
tell it to continue the command on the next line.

The following is a sample of what you might wish to place in the startup
file:

    ┌──────────────────────────────────────────────────────────┐
    │ CTEXT Howdy!  if I don't show, pse lv a msg on n5ial-1.\ │
    │ 73, de n5ial, Jim in Chicago.                            │
    │                                                          │
    │ CMSG ON                                                  │
    └──────────────────────────────────────────────────────────┘

This sets the connect text (CTEXT) to send the message shown, with the
``73, de n5ial'' part starting on a new line, and then sets the TNC up
to send CTEXT on a new connect in the normal manner.

The following is a sample of what you might wish to place in the exit
file:

   ┌─────────────────────────────────────────────────────────────────────┐
   │ ctext Hmmm.....I don't seem to be around. pse lv a msg on n5ial-1.\ │
   │ 73, de n5ial, Jim in Chicago.                                       │
   │                                                                     │
   │ cmsg pbbs                                                           │
   └─────────────────────────────────────────────────────────────────────┘

This sets the connect text (CTEXT) to send the message shown, with the
``73, de n5ial'' part starting on a new line, and then sets the TNC up
to send CTEXT on a new connect, and then transfer the user to the PBBS
if it is available.

10.0)  DEVELOPMENT  ENVIRONMENT

For those who may be interested, the following is the environment under
which KAMterm was developed, and initially tested:

   *) COMPUTER / SOFTWARE

      *) 20 MHz 386 running Linux 0.99 and Digital Research Dos
         version 6.0
      *) Serial port uses National Semiconductor NS16550AFN UART
      *) Turbo C++ Version 1.0 and Turbo Assembler Version 2.0
      *) Windowing library is UltraWin Version 2.50, which is
         available from EnQue Software (BBS:  816-353-0991).[1]
      *) Communications library is Encom Version 1.50, which is
         also available from EnQue Software.
   *) Kantronics All Mode (KAM) with firmware version 6.00.
   *) Printed documentation formatted using emTeX version 3.0 [3A]
      and printed on Panasonic KX-P1124 24-pin impact dot matrix printer
      at 360 dpi (typical desktop laser printer is 300 dpi).

[1] This may seem strange to some, but I'd like to include a small advert
    for another shareware product, the UltraWin library.  For those who
    wish to use windowing type functions in any C code, check this library
    out!  It is very nicely done, and is very powerful.  Support from EnQue
    has been very good WITHOUT EXCEPTION, and has been very helpful here.

11.0)  SUPPORT

I will provide support for problems, bug reports (what bugs?), and
suggestions to registered users via several modes:

11.1)  ELECTRONIC  MAIL

The best and FASTEST way to reach me is via electronic mail.  My addresses
are as follows:

   *) INTERNET
      *) [e-mail]
      *) [e-mail]
   *) UUCP: uunet!valinor!n5ial!jim

The last Internet address, [e-mail], is an alias provided by the
Institute of Eletrical and Electronics Engineers (IEEE)---this will
follow me even if I move---if all else fails, use this.

NOTE:  support will NOT be available via Amateur Radio---the FCC would
probably have some very bad things to say about that.

11.2)  LANDLINE

Another way to reach me is via landline.  This will probably be a bit more
difficult, as I'm not always around the phone, and don't currently have
an answering machine.  I now have an AT&T EasyReach number, which will
always point to my actual phone number, even if I move.  This number is
0-700-JGRAHAM (0-700-547-2426).  Please note that this is *NOT* a
toll-free 800 number.

When you dial this, you will get an AT&T menu that will ask you to press
the # sign and then ask if you want to charge to call to the number
you're calling from or your AT&T calling card (if you have one).  If you
don't have a touch-tone phone, just wait a few seconds, and the system
will just charge the call to the number you're calling from.

When using this EasyReach number, there are a couple of things to keep
in mind.  First, you must dial 0-700, and not 1-700.  Second, if you
are not an AT&T subscriber, you must dial 10-288-0-700 (10-ATT-0-700)
to get an AT&T line.  Admittedly, this is a hassle, but at least you
will be able to reach me via telephone even if I move and change
phone numbers.

If you have questions or problems with the EasyReach number, you may
contact the AT&T EasyReach customer service department 24 hours/day
at 1-800-982-8480.

The number this points to is currently also my data number.  If you get
a busy signal, or if a modem answers, you'll want to try back later.

At times, the modem may be setup to receive incoming UUCP connects to
support e-mail and Usenet News.  If you have the ability to use UUCP or
UUPC, we can set you up there, too.

11.3)  SNAIL  MAIL

If all else fails, send your questions to the snail mail address shown
in the REGISTRATION section.  This will take longer, as there will be a
delay involved.  I won't get it until my dad forwards it to me, but I
WILL get it.

I will keep registered users aware of my current mailing address, too.

12.0)  REGISTRATION

If you received this documentation with your registration, this section
does not apply to you, and can be skipped.

KAMterm is the result of a large investment of time and money spent in the
development process, and is NOT freeware.  If you have not registered
this program, please send $ 25 (US) to:

Jim Graham
C/O James A. Graham (my Dad---this address is more stable than mine)
519 Benning Dr.
Destin, FL 32541

US users, add $ 4 (US) shipping/handling.  International users, add
$ 9 (US) shipping/handling.

A few important things to remember:

*) Make check/money order payable to ``James D. Graham'' or to
   ``Jim Graham''.

*) Checks and money orders must be in US currency, and if at all
   possible, drawn on a US bank (my bank has serious problems
   otherwise, and yes, I am in the market for a new bank!).

If you would like a copy of the printed, bound documentation, please add
an additional $ 10 to your registration.  This is primarily to cover the
cost incurred at the printshop (would be much worse if I was giving them
anything less than camera-ready art) and the additional cost of mailing.

With your registration, you will receive the latest release of KAMterm,
as well as a registration program which can be used to automatically
register any new releases of KAMterm that you receive.  (Registered
users will also receive announcements of new releases in the mail.)
This registration program requires a set of ``keys'' which will be
provided with the program.

The copy of KAMterm that will be shipped with your registration will
not yet be registered---this is to allow you to distribute the most
current version as shipped to you if you care to do so.  You will,
therefore, need to register it upon its arrival.

By default, this will be shipped on a 360 k 5.25" disk.  If you prefer,
you can have the program shipped on a 1.44 Meg 3.5" disk.

In addition, you will be eligible for full support from me, and will get
priority for any enhancement requests you may have.

Please fill in the following form for my records---this will help me to
support you better.

═════════════════════════════════════════════════════════════════════════════

        NAME: ___________________________  CALL: ____________
     ADDRESS: ___________________________
              ___________________________  PHONE (day):   (___) ___-____
              ___________________________  PHONE (eve.):  (___) ___-____


INTERNET E-Mail Address (if any):




OTHER E-Mail Addresses (specify type, e.g., UUCP, Compuserve, BITNET, etc.):





═════════════════════════════════════════════════════════════════════════════

E-mail addresses will currently only work if I can get to them via
INTERNET, but try anyways. You never know---I might even have access
to them right now. I am including a list of other networks which can
exchange e-mail with INTERNET sites.  This list is available for
anonymous FTP from ftp.msstate.edu (130.18.80.11), and is found in
ftp/pub/docs/internetwork-mail-guide.  Other methods of distribution
are described within the file as well.  In this distribution, the file
is named mail.gui.

Enjoy, folks!
   --jim

--
#include <std_disclaimer.h>                                 73 DE N5IAL (/4)
------------------------------------------------------------------------------
INTERNET: [e-mail]  |  [e-mail]     ICBM: 30.23N 86.32W
AMATEUR RADIO: n5ial@w4zbb (Ft. Walton Beach, FL)          AMTOR SELCAL: NIAL
------------------------------------------------------------------------------