




                            
            ۱۱۱  ۱۱  ۱   ۱  ۱   ۱
            ۱۱ ۱  ۱  ۱  ۱ ۱ ۱  ۱    ۱
              ۱    ۱    ۱ ۱ ۱       ۱
               ۱     ۱    ۱ ۱         ۱
               ۱     ۱۱    ۱  ۱        
               ۱     ۱     ۱     ۱      ۱
               ۱     ۱      ۱        ۱ ۱  
                              ۱ ۱   ۱
                                      

                       The Firmware PC Extended
|                    Version 2.73 (21 March 1999)

                   Resident AX.25-Controller for PC
              and BayCom-Modem, SCC-Boards, PAR96, YAM96
                     PA0HZP-OptoPcScc Board, KISS
                    with WA8DED-Hostmode-Interface
|                    and DRSI cards, BPQ ethernet

                       by Henk de Groot, PE1DNN

              Based on TFPCX 2.21 by Ren Stange, DG0FT
                    Based on TF2.7b by NORD><LINK


              English translation and update by PE1DNN
                  Editorial corrections by PE1MHO


                            Contents
                            --------

  1.      Foreword
  2.      A word about the documentation
  3.      Introductions since version 2.0
  4.      Quick-start tips
  5.      Installation

  6.      Invocation and configuration
  6.1.    General options
  6.2.    Options for resident loading
  6.2.1.  Port and baudrate configuration
  6.2.2.  TFPC and DRSI-interface
  6.2.3.  Other options
  6.3.    Clearing TFPCX from the RAM
  6.4.    Terminal-mode

  7.      Installation
  7.1.    SP (DL1MEN)
  7.2.    GP (DH1DAE)
  7.3.    THP (DL1BHO)
  7.4.    TERM (DL5FBD)
  7.5.    CT (K1EA)
  7.6.    DIEBOX (DF3AV)
  7.7.    WINPR (DG6BI)
  7.8.    TOP (DF8MT)
  7.9.    FBB (F6FBB)
  7.10.   MS-Windows, OS/2 and others

  8.      Operation
  8.1.    Multi-Port expansion
  8.2.    Individual commands
  8.3.    KISS
  8.4     DAMA

                                  APPENDICES

  1.      Overview of commands

  2.      Error-correction (Modem Operation)
  2.1.    Send and receive problems
  2.2.    Problems with other programs
  2.3.    Hardware problems

  3.      Hardware connections
  3.1.    Serial modems
  3.2.    BayCom USCC-card
  3.3.    BayCom PAR96 and PICPAR modem
  3.4.    YAM96 modem
| 3.5.    BPQ Ethernet

  4.      Information for software developers
  4.1.    Program-interface
  4.1.1.  TFPC-interface
  4.1.2.  DRSI-interface
  4.1.3.  Special functions
  4.2.    Format of reports
  4.3.    Extended hostmode
  4.4.    Previous versions


1. Foreword

  In  1997  DG0FT  published  his  work  under  the  GNU  General Public
| License, and stopped maintaining the code. Although this TFPCX  worked
  reasonably well, it was not suitable for use with DAMA stations.  This
  release used an old version  of TheFirmware by NORD><LINK. During  the
  next  few  years  the  Dutch  packet  network will be converted to use
  DAMA.  There are  still a lot of  users using TFPCX, and  therefore it
  seems to be a good idea  to exchange the TheFirmware version in  TFPCX
  for the latest version, which is TF2.7b.

  There is an alternative to TFPCX, which is TFX by DB7KG. But they  are
  not quite the same.   The main advantage of  TFPCX is the  possibility
| to  use  different  modems  at  the  same  time (different independent
  ports). Some of the modem  implementations in TFX are better,  but for
  others  the  TFPCX  implementation  is  preferable.  Replacing the old
  version of TFPCX with this  one will ease the change-over  to software
  supporting the DAMA protocol.

  Legal rambling

  The legal status of this product  is a bit strange. Both the  ALAS and
  the GNU  General Public  License are  applicable. This  work shall  be
| seen  as  an  aggregate  work  as  defined  in  the GNU General Public
  License.  The source code is  distributed in such way that both  parts
  are clearly distinguishable - therefore we don't confirm or deny  any-
  body's  right.   Both  parts  can  be  treated  according to their own
  license.  The resulting executable  has to follow ALAS since  that one
  poses the most restrictions.   Since the source code is  independently
  available in un-merged form:   this does not deny  anybody the use  of
  the  part  which  was  under  GNU  GPL  control.  Before you burn your
  fingers  to  put  me  right  -  it  is  highly questionable if the GNU
  General Public License  is applicable to  TFPCX anyway; it  contains a
  big portion of NORD><LINK's TheFirmware and violates the ALAS  license
  which was applicable for it. Anyway this is the current situation  and
  if  you  want  to  know  more,  read both LICENCE.DOC and ALAS.TXT and
  contact your lawyer.

  Now  I  want  to  give  the  word  to  Rene,  DG0FT,  who  made  TFPCX
  possible.....

  ----------------------------------------------------------------------
  "The additions in this version are  listed in chapter 3. In chapter  4
  some  advice  is  given  for  those  who are upgrading from an earlier
  version.

  Note that I can not guarantee that TFPCX will run without any  problem
  on every PC  when using a  serial modem:   especially when using  a PC
  with  a  slow  CPU  you  may  encounter problems during reception. XTs
  running with  a clock  frequency below  8MHZ are  not usable  (or with
  limitations). Some  TSR's (Terminate  and Stay  Resident) programs are
  known  to  cause  problems  (See  Appendix  2.1.). Since this is not a
| commercial product I take this  for granted. I think this program will
  work for most users with some compromises .

| I would  like to  thank Peter  (DB2OS), Also  (DG2BRS), Denis (G0KIU),
| Henk (PA0HZP),  Rob (PE1CHL),  the BayCom-Team,  all contributors  and
  all the users who have helped me with advice and recommendations."

  73 De Ren, DG0FT                      Strausberg, 20th. November 1993
  ----------------------------------------------------------------------

  And I like to  thank Ren (DG0FT) and  the NORD><LINK team for  making
  all this  software and  making it  available so  I could  extend it. I
  also want to thank the Beta testers for their valuable feedback.  Note
  that although  I updated  the document,  the major  part is written by
  Ren DG0FT,  so 'I'  in this  document will  refer to  him, not to me!
| Give the credit to Ren.  Thanks to PE1MHO for editorial correction of
| this document.  Thanks to  Nico IV3NWV for  the information  about the
| YAM96 modem and supplying a modem for testing  (works great!).  Thanks
| to PE1MEW and PA3AES for  testing the  BPQ ethernet  addition  (it was
| also their idea...).  Thanks  to VK1CAE  for fixing DAMA  for use with
| KISS (as far as possible of course), finding a DAMA violation flaw and
| review of the changes in the code.  Thanks to  D.D.S. Electronics  for
| providing a PA0HZP compatible SCC card and 1k2 modem.
|
| 73s Henk, PE1DNN                              Apeldoorn, 21 March 1999


2. A word about the documentation.

  I assume you have  a suitable Modem or  TNC. This can be  any modem or
  TNC which  is supported  by TFPCX.   Furthermore, you  need a suitable
  Terminal Program (capable of handling  TFPCX).  Finally you also  need
  some knowledge  about the  TNC-Software, which  is TheFirmware version
  2.7b by  NORD><LINK.   As reference  I enclosed  the documentation  of
  TheFirmware  2.7b  which  is  built  into  this version of TFPCX. This
  document  is  however  only  available  in  German,  so polish up your
  foreign languages  (and if  you happen  to be  German the same applies
  since this document  is written in  English).  You  can also wait  and
  hope that somebody  will translate it  for you.   Only the differences
  compared to TNC-Firmware will be considered here.

  If  you  get   TFPCX  running  without   reading  this   documentation
  completely you may save some time,  but you may have overlooked a  few
  tricks  which  will  come  in  handy.   If  you  have any questions or
  problems,  please  find  a  solution  by  reading this document first.
  Practice has shown  that the same  questions are raised  over and over
  again. I have kept the frequently  asked questions in mind when I  was
  writing this document  but this document  will never be  complete.  Of
  course this documentation  is not a  basic course in  MS-DOS or packet
  radio. A little  hint:  you  can quickly find  a keyword by  using the
  search function of a Text Editor.

  This document mentions certain  hardware and  software  which has been
  designed by other Radio Amateurs:   most of the time their call  signs
  are enclosed between brackets.

  At some  places (especially  appendix 1)  10 is  mentioned as  default
  value for the number of  channels. This value is however  configurable
  and is only used as indicator.  When using the '-CH' option the  value
  '10' has to be replaced by the value parameter.

  Concepts and Abbreviations:

  Port       a packet radio interface consisting of a port ( COM, LPT
             or SCC-Port), modem and a tranceiver. When using more
|            ports it is called multiport-operation. For BPQ ethernet
|            the interrupt number of the FTP software packet driver is
|            used as 'port'.

  Channel    one of the maximum 10 simultaneous Connects. When using
             a BayCom modem the meaning of Port and Channel is exactly
             reversed. Confused?

  Frame      one complete data unit transmitted by packet radio
             (packet), consists of an address field, a control field,
             data and a checksum.

  Interrupt  interruption of the currently running program due to a
             hardware-event (e.g. a key press, elapse of a defined
             time-interval).  Software-interrupts are not caused by
             hardware but created by executing a particular program
             instruction.

  KISS       (KA9Q and others) stands for 'Keep It Simple Stupid' and
             defines a simple Data Format for the transfer of Frames
             and TNC-Parameters over an asynchronous Serial Port. The
             original goal was to move the protocol processing from the
             TNC to the Terminal-CPU in order to run protocols which
             were not supported by the TNC. KISS is implemented in many
             TNCs: it also enables direct connection to the computer.

  SMACK      (DL5UE and DK5SG) is the abbreviation of 'Stuttgarts
             Modified Amateur radio-CRC-Kiss' and extends the on error
             free transmission based KISS with a checksum (CRC) so
             transmission errors can be recognised.

  0x         Prefix of Hexadecimal Number (e.g. 0x300 = 300H)


3. Changes since 2.0

| - TFPCX 2.72 was used to test all the changes from version 2.71. TFPCX
|   2.73 consolidates all the changes and is a stable release version.
|
| - Removed the Poll/Final bit from the last infoframe transmission,
|   causes "bumper-QSO's" and did not help much otherwise.
|   Retained '-SB' switch
|
| - Updated the documentation. Changes with respect to version 2.71
|   (last stable release) are annotated by a | in the first column.
|
| - Added -SB switch. To be used on bad links. It adds an RR+ after the
|   last I frame transmission. This increases the probability that the
|   link-partner will notice the poll since RR frames are smaller than I
|   frames and therefore more likely to be received okay.
|
| - Added Poll/Final bit to the last I frame transmission before expecting
|   a response from the link-partner.
|
| - When using DAMA slottime is fixed to 10 (100 ms) on KISS ports.
|
| - Corrected error which caused DAMA violations.
|
| - Corrected an error when using DAMA with KISS. The KISS TNC's Persist
|   value and Slottime were not being set to appropriate values for DAMA
|   operation. Fixed this.
|
| - New "modem": BPQ. Now you can establish a link over Ethernet using a
|   FTP software packet-driver.
|
| - Added a  switch for  frame-sammler. The  framesammler in  TF27b (and
|   thus TFPCX) is not safe when you link-partner uses a Maxframe of  7.
|   Default the  frame-sammler is  now off.  To switch  it on supply the
|   -SR flag. Note that  if your link-partner uses  a Maxframe of 7  you
|   might  loose  data  without  noticing  it. For lower Maxframe values
|   this is safe.
|
| - Updated the documentation. Changes are annotated by a | in the first
|   column.
|
  - The YAM 9k6 modem is supported now.

    Option -PYAMn:<Base>:<IRQ>  n = 1-4 (Number of the COM-Port)

    The  default  <Base>  address  is  the  address  known  by the BIOS.
    default <IRQ>  4 (COM1  or COM3)  or 3  (COM2 or  COM4) will be used
    when not otherwise specified.

    The  YAM  modem  does  not  support  Soft-DCD.  The  @C will have no
    effect. The parameter @D (Duplex) will be ignored.

  - Added -SA option. For transmission the  'frame-sammler' function  is
    off by default. By using -SA you can switch it on again.

| - At link-setup  time timer T1  (frame-acknowledge timer) did not run,
    this resulted in an  unusable link if at  startup the first I  frame
|   was  missed  (T1  regulates  retransmission).  This problem occurred
|   frequently when the UA response to  SABM at setup was missed and the
    CTEXT (U command) was send  directly following the UA (occurs  often
    when using SP or GP).

  - Before generating a  RR response a check  is done if DCD  is active.
|   If so  the generation  of the  response is  postponed.  This  allows
    the use of much smaller @T2  values then those needed for KISS  use.
    This will  make the  link faster  and should  be compatible now with
|   TFPCX221 and earlier.

  - Changed TF2.3b to TF2.7b - corrects the usage for DAMA

  - Due to the use of TF2.7b, the "Framesammler" is supported

  - When connected to a DAMA master the DCD is now ignored like in
|   TFX and TheFirmware 2.7b based TNCs (with the latest TF2.7b) (except
|   for a KISS port).

  - When using the -ST option on the commandline the DOS-Time will be
    used to set the clock in the TNC. This will give the real
    time to the timestamps (K command)

  - When you wanted to start Windows95 after TFPCX has been loaded and
    unloaded, Windows95 would complain about a non-conformant TSRs and
    use a so-called 'compatibility mode', in effect using 16-bit DOS
    drivers instead of 32-bit Windows95 drivers. This has now been
    solved.

  - The BayCom PAR96 and PICPAR modems are supported

    Option -PPARn:<Base>:<IRQ>  n = 1-4 (Number of the LPT-Port)

    The default <Base> address is the address known by the BIOS.
    <IRQ> 7 will be used when not otherwise specified.

    The Soft-DCD can be activated by the @C command. All values other
    than 0 have the same effect. The value only has influence on the
    DCD-indicator (more stable with larger values). The parameter @D
    (Duplex) will be ignored.

  - RMNC-CRC-KISS is supported when using -PKISS and automatically
    activated. The command @ST shows for both SMACK and RMNC-CRC-KISS
    a "+" symbol.

  - The BayCom Digi SCC-card is supported (only Ports 0 to 3).

    Option -PDSCC:<Base>:<IRQ>:<Modems> (Default -PDSCC:300:7:2222)

  - The TheFirmware K command (Timestamp) can be used. The flag -ST
    should be given on the command line to enable it.

  - FlexNet frames with header-compression are shown in the monitor.
    The command M +/- is used here.

    Format of the monitor-header:

    fm #<Qso> to <Call> ctl ...
    fm <Call> to <Call> ctl SABM+ #<Qso>
    fm <Call> to <Call> ctl UA- #<Qso>

    <Qso> = FlexNet QSO Number

  - For KISS, BayCom PAR96-Modem and PA0HZP OptoPcScc-card, the
    real-time clock will be used as timebase for internal timers so the
    time measurement will be more precise (not under Windows).

  - The option -ND has been removed.

  - KISS-Mode (including SMACK support) for up to 4 Ports and 57600
    baud is supported (Option -PKISS). Frame errors (e.g. through
    character loss) will be ignored and counted (See Section 6.2.1 and
    8.3.). By means of TFPCX and KISS the program GP (DH1DAE) can now
    control more TNCs simultaneously.

  - The PA0HZP OptoPcScc-card is supported (option -POSCC, see section
    6.2.1).

  - The BayCom 9K6 USCC-card now functions with TFPCX (Option -PUSCC,
    see section 6.2.1.). When using some BayCom USCC-cards, meaningless
    data was transmitted because of timing problems. This problem has
    been avoided by using another way of driving the SCC-controller, .

  - For SCC-Cards and COM-Ports (with KISS) AT-IRQs (9, 10, 11, 12, 14,
    15) can be used.

  - The number of free buffers (Option -BU) and the number of channels
    (Option -CH), and therefore the required RAM-Space, can now be
    configured. (Default values: 600 Buffers/10 Channels, see section
    6.2.3.)

  - The initialisation file (option -F) may now contain empty lines
    and comments. ESC-Characters will be recognised automatically and
    no longer require defining with  '^' (See section 6.2.3).

  - When using the DRSI-interface (Option  -DR), the incompatibilities
    with respect to the DRSI TNCTSR-driver have been removed. These
    incompatibilities previously lead to  problems with the monitor and
    heard-list in combination with FBB  (F6FBB). In cases where these
    modifications now give problems with other programs (e.g. with
    TOP), using the option -DX  will  enable the previous (modified)
    DRSI-Interface again (See section 6.2.2.1).

  - The new @PO command enables selective allocation of a channel to
    a port, so the channel can only be connected from this port. This
    is useful when using the Program TOP (DF8MT) or TstHost (IK1GKJ).
    (See section 7.8 and 8.2.).

  - By means of a Transparent-Mode during reception (Command @M) and
    switchable character echoing (Command @E). #BIN#-Reception in is
    possible in Terminal-mode (e.g. with TERM (DL5FBD)). (See section
    7.4 and 8.2)

  - Internal connects (Loopback) can be switched off when needed
    (Option -NL, see Section 6.2.3.).

  - TXTAIL (Command @TA) in combination with the serial modem and
    SCC-Card will be optimally installed according to the baud-rate and
    timer inaccuracy. Previously it gave some problems with operation
    at 300 Baud.

  - If the Option -P is not specified, it will not longer default to
    a serial modem on COM1 as before , but to no port at all, which is
    only meant for test purposes with internal connects. Therefore -P
    should always be specified in normal cases.

  - From now on, the option -D (Debug) is on only applicable to the
    most recently specified option -P (Port). This will enable
    monitoring of a specific port, even during multiport operation (See
    section 6.2.3.).

  - Disconnecting in the background mode or terminal mode is possible
    by means of the remote command '//Q' (Command U, see section 8.2.)

  - Because of a DAMA-change (since TF 2.6) the known "complaint-
    messages" from of TheNetNode-Digis during multiconnect should now
    be eliminated.

  - The Extended Host-Mode (DG3DBI) is now supported and enables
    faster communication with a terminal program.

  - The default-values for the Parameters F, N, P, R, T, U, @I, @T2,
    @T3, AND @TA have been changed.


4. Quick Start

  Because  of  the  many   different  configuration  settings  and   the
  existence  of  many  different  terminal-programs no general 'recipes'
  can  be  given.   In  most  cases  it  will  be sufficient if you read
  sections 6.2.1  and 7  (depending on  the program  used).   In case of
  trouble read appendix 2.   For multiport operations, the sections  8.1
  and 8.2 are  important.  In  section 8.3 important  tips for operation
  using KISS are given.

  If you used a previous version without the '-P' option and were  using
  the default COM-1 port you now have to include the option '-PCOM1'.

  If you  previously used  version 2.0  with more  than 10 channels, you
  now have to supply the  option '-CHnn' during startup of  TFPCX, where
  nn is the number of channels required.

  If you  used the  option 'DR',  and this  version introduces  problems
| with your monitor  or heard  list, you should supply the  option '-DX'
  instead of '-DR'(e.g. with TOP)

  If you worked with version 1.1x up  till now and only want to use  one
  modem you can additionally specify the option '-C' when loading  TFPCX
  if you want  the send-/receive indicator  - it is  not switched on  by
  default anymore. If you used the  option 'NC' up 'til now you  have to
  delete that.

  Command 'TFPCX -H' will show all allowed options in a shorthand  form.
  Command 'TFPCX -U' removes TFPCX from RAM.


5. Introduction

  A few years ago packet  radio was mainly operated using  Terminal-Node
  Controllers  (TNCs)  which   took  care  of   the  execution  of   the
  PR-specific protocol (AX.25), and used the computer as a tool to  look
  at the data in a convenient  way. The TNC itself is nothing  more than
  a small  computer with  a serial  port and  a modem.   Due to the wide
  distribution  of  software  for  the  TNC2  (WA8DED-Firmware  or   the
  compatible  TheFirmware  from  NORD><LINK)  many  popular  PC programs
  support the software-interface of this firmware (WA8DED-Hostmode).

  Since powerful PCs are not longer expensive (in fact they are easy  to
  get second-hand),  it becomes  feasible to  let the  PC take  over the
  work  of  the  TNC  and  save  the  investment in a TNC. Additionally,
  portable operation using a laptop  or a notebook is much  more elegant
| if you do  not have to  carry  an additional  'black box' around.  For
  this purpose the BayCom  system (Terminal, Modem or  USCC-Card) offers
  a quick, cheap and easy to understand solution. But the BayCom  system
  is a closed system without the support for TNC terminal programs.

  At  this  point  TFPCX  comes  into  the  picture,  since TFPCX is the
  connection  between  the  existing  hardware  (serial modem, SCC-card,
  Par96 or PicPar)  and the terminal  programs. TFPCX is  a kind of  RAM
  resident TNC which is loaded into  the PC once.  It will  conveniently
  sit in memory  and will perform  actions in the  background, driven by
  the constantly occurring  interrupts in the  PC.  It  will receive and
  transmit data and will react to  commands from the user. The data  and
  command interface  with the  terminal program  (software interrupt) is
  provided in a  similar way as  to that used  by TNCs and  is also (and
  this is important) clearly documented.  It is therefore easy to  adapt
  an existing program  to get it  running with TFPCX.   This is  already
  done in most popular programs.

  When  TFPCX  is  loaded  the  system  behaves  as  if  a  real  TNC is
  connected,  so  you  can  be  connected  from outside and all incoming
  messages will be  stored.  Since  TFPCX runs in  the background, other
  programs can  be used  (for exceptions  see appendix  2.2). A blinking
  rectangle in the upper right corner will draw your attention if  there
  is unread information pending.  The unread information will appear  on
  the screen as soon as a  terminal program is started. You can  compare
  TFPCX with L2 (DL8MBT) of the BayCom system.

  TFPCX  does  not  support  TCP/IP  operation  and  runs  only  on IBM-
  compatible PCs.  TCP/IP can be operated with BayCom-compatible  modems
| using the AX25DRV packet driver from Pawel Jalocha (SP9VRC).


6. Invoking and Configuration of TFPCX

  TFPCX will be activated by the following Command Line:

  TFPCX [ -N ] [ <load options> | -T | -U ]

| All  options  start  with  a  '-'  sign  and  are separated by a space
  character.   The  space  character  shall  not  appear  as part of the
  option. Options are case-insensitive (no difference between upper  and
  lower  case.   Certain  options   (e.g.  '-P')  have  more  than   one
  parameter,  separated  by  a  ':'.  For  those  values  which  are not
  explicitly specified default values will be used.

  Example:

  Option '-PUSCC::5' will be interpreted as '-PUSCC:300:5:1103', since
  the omitted values default to 300 and 1103.

  It makes sense to start TFPCX  from a batch-file so you won't  have to
  type in the same options over  and over again. All options are  listed
  in short-hand form, which will  also be presented as help-text  if you
  enter 'TFPCX -H', The <load  options> are only relevant while  loading
  TFPCX as a TSR, and remain valid until TFPCX is unloaded from memory.

| Usage: TFPCX [ -N ] [ <load options> | -T | -U ]
|
| <general options>              <legend>
|   -N no messages                 [] optional
|   -T terminal mode               |  alternative
|   -U unload                      x  hex digit
|                                  n  dec digit
  <load options>
    -P<port>[:xxx:nn:nnnn]  packet port [addr:IRQ:<clock>]
    -Bnnnn[:nnnn ...]       baud rate (1 number/port)

    -F[file]  read init file      -D  debug mode
    -C[xx]    show DCD [color]    -DM use DRSI messages
    -Ixx      TFPCX interrupt     -DR emulate DRSI driver
    -BU[nnnn] number of buffers   -DX modified DRSI interface
    -CHnn     number of channels  -NB no blinking rectangle
    -ST       time stamp          -NL no loopback
|   -SA       sammler on for TX   -SR sammler on for RX
|   -SB       send extra RR+ after I frame transmission
| <port>  COMn | LPTn | PARn | YAMn | BPQnn | KISSn | DSCC | OSCC | USCC
|         (n = 1-4, for BPQ n=  60-80)
  <clock> 0 = disable    2 = hardclock    4 = PA0HZP port  (1 digit/
          1 = softclock  3 = DF9IC modem  5 = PA0HZP timer  channel)

6.1. General Options

  These options can be used together with every other option.  Currently
  there is only one:

-N  Suppress Messages

| In  case  messages   from  the  program   are  not  wanted   (e.g.  in
  batch-files),  they  can  be  suppressed  by  using this option. Error
| messages are not suppressed.


6.2. Options for loading as TSR

  TFPCX  will  always  load  as  a  resident program in RAM, except when
  either option  '-T' or  '-U' are  specified, or  when TFPCX,  TFPCR or
  DRSI-TNCTSR are  already running  resident in  memory. If  you want to
  use multiple drivers simultaneously, TFPCX has to be the first TSR  to
  be loaded. I  cannot guarantee that  it will work  without problems in
  this case.

  The TFPCX program can also be loaded high in upper-memory (UMB)  using
  the LOADHIGH command  if there is  sufficient room. Keep  in mind that
  there  are  some  problems  when  using  EMM386-drivers  however  (see
  appendix 2.1.).

| In order  to adapt  TFPCX to different hardware,  transmission speeds,
  terminal programs  and user  preferences there  are a  lot of options,
| which will be described here.

  After loading, the following report will appear (example)

  Ŀ
|      TFPCX v2.73  (Mar 21 1999)       
|         by PE1DNN and friends         
    Based on TF2.7b/TNC2 07Jun95 code   
        TheFirmware by NORD><LINK       
  Ĵ
   Contains portions of TFPCX by DG0FT  
   published under GNU GPL License.     
   All other portions Copyright         
   (C) by NORD><LINK e.V. 1988-1995.    
   Es gilt die allgemeine Lizenz fr    
   Amateurfunk Software (ALAS).         
   ONLY for non-commercial usage.       
  Ĵ
   5 Port(s), 10 Channels, TFPC-Int FD  
  Ĵ
   0: COM1 (3F8/00),  1200 Bd, MODEM    
   1: SCC0 (300/07),  1200 Bd, SOFTCLK  
   2: SCC1 (301/07),  1200 Bd, SOFTCLK  
   3: SCC3 (303/07),  9600 Bd, DF9IC    
   4: COM2 (2F8/03),  9600 Bd, KISS     
  

  followed by the DOS  prompt. TFPCX is now  loaded and occupies a  part
  of memory.  In  the lower box the  number, the interface, the  address
  and when applicable the IRQ, the baud rate and types of the  connected
  modems are displayed.


6.2.1. Port- and Baud Rate-Configuration

-P  Specification of the used ports

| This option can be specified multiple times: twice for serial  modems,
| once for -SCC cards,   once for BayCom PAR96  or  PICPAR modems,  once
| for the  YAM96 modem,  once for  a BPQ  ethernet link  and 4 times for
| KISS   ports,   but  not  more   than  8  times   in  total.  Do   not
| underestimate processing load on  the PC when using serial modems.

  The allocation of  port numbers will  follow the same  sequence as the
  order in  which the  ports are  defined on  the commandline, where the
  order of SCC-ports  is fixed. The  report given above  as example will
  appear when starting TFPCX with:

  TFPCX -PCOM1 -PUSCC -PKISS2

  If the option '-P'  is not specified not  any port is used,  this only
  makes sense using internal connects.

| The optional port addresses should be  in the range 0x100 to 0x3F8 and
  be divisible by  8. With SCC  and KISS, use  of the IRQs  2-5, 7, 9-12
  and 14-15 are possible (When using XTs only IRQs below 8). ATs do  not
  actually have  an IRQ  2. Instead  of this  IRQ 9  is used.  Each port
  must have an unique IRQ.

-PCOMn or -PLPTn modem connected to COMn or LPTn (n = 1-4)

  The base address of the port will be read from the BIOS-data area  and
  has  to  be  present  there.   Most  BIOS-versions  don't  keep   this
  information for COM3 and  COM4. In that case  the address can also  be
  specified explicitly using '-P<Port>:xxx'.

  Example:

  TFPCX -PCOM3:338

| Using this command a modem connected to COM3 will be used, using  base
| address 0x338.  This address should  be  looked  up in  the  manual or
| description of the interface. The  number of the port (in this example
| 3) will be ignored if the base address is explicitly specified but has
  to be present and between 1 and  4. The IRQ of the interface is  of no
  interest to TFPCX since it is not used.

  When using 2 modems, the first modem specified shall be the one  which
  is  most  frequently  used  because  the  first  modem  has  a  higher
  priority. It is evident that  other programs can't use the  same ports
  as used by TFPCX.

-PUSCC:<Base>:<IRQ>:<Modems>  use BayCom USCC-card
-POSCC:<Base>:<IRQ>:<Modems>  use PA0HZPcOptoPcScc-card
-PDSCC:<Base>:<IRQ>:<Modems>  use BayCom Digi SCC-card

  The base address of the SCC card, the IRQ and a 4 digit number can  be
  specified as parameters. The 4 digit number specifies the type of  the
  SCC ports (up to  4).  The following  settings are possible (see  also
  appendix 3.2.):

  0  Disable      Port disabled (Switched Off)

  1  Softclock    The transmit and receive clocks are created internally
                  for use with AFSK-Modems (duplex mode not possible)

  2  Hardclock    The transmit clock will be generated by the modem,
                  the receive clock is created internally (e.g. G3RUH)

  3  DF9IC-Modem  The transmit and receive clock will be generated by
                  the modem, NRZ-Mode

  4  PA0HZP-Port  The receive clock will be created internally,
                  divided externally by 32 and passed back to
                  the SCC-Controller as transmit clock. (for
                  OptoPcSCC-card)

  5 PA0HZP-Timer  This port generates a timing reference for timing
                  purposes (Only for OptoPcSCC-card).

  The modem types 1-3 are reserved  for the USCC- and DSCC card,  type 4
  only functions with the OptoPcScc-Card.

  Number 5 has a special  meaning.  TFPCX requires a  regular timer-tick
| for internal timing. This timer-tick can be delivered by the OptoPcScc
  card, but  not when  running under  Windows. In  this case  the system
  timer of  the PC  will be  used, which  is, however,  not so accurate.
  This  can  cause  a  problem  for  some  parameters  (e.g. TXDELAY and
  TXTAIL).  TFPCX  offers  the  possibility  to  use an otherwise unused
  SCC-Port  for  generation   of  an  accurate   timer-tick,  which   is
  recommended when not all ports are in use.

  Examples:

  TFPCX -PUSCC:300:7:1103

  Base address  is 0x300  and IRQ  is 7.   USCC-ports 0  and 1 are using
  Softclock for use with normal  AFSK-modems (the two '1' digits),  port
  2 is disabled and port 3  is used with a DF9IC-modem (the  '3' digit).
  This is also the default setting when only '-PUSCC' is supplied.

  TFPCX -PUSCC:300:7:31

  USCC-Port 0 is now setup for a DF9IC modem. Port 1 uses the  Softclock
  and ports 2 and 3 are  switched off. This setting is required  for the
  9K6-USCC  Card,  which   offers  only  2   SCC-ports.   If  no   clock
  specification is supplied  '1103' is used  by default (as  above), but
  then a setting is  given using less than  4 digits the missing  digits
  will interpreted as '0'.

  TFPCX -POSCC:150:3:4445

  OptoPcScc-Card with base address  0x150, IRQ 3. Port  0, 1 and 2  will
| be  used  as modem  ports with  an external  clock. Port  3 delivers a
  timer-tick.   This is  also the  default setting  when using  '-POSCC'
  without additional parameters.

  TFPCX -PDSCC:300:7:2222

  BayCom-Digi-SCC-Card with  base address  0x300, IRQ  7. All  ports are
  used with  G3RUH modems,  which will  also deliver  the clock. This is
  also  the  default  setting  when  using  '-PDSCC'  without additional
  parameters.

-PKISSn:<Base>:<IRQ> KISS-Port on COMn (n = 1-4)

| The  base   address  will   be  determined   automatically,  but   can
| be overridden  if   a base-address   is specified.    IRQ  4   will be
| used as the default  interrupt for COM1   and  COM3, and  IRQ  3   for
| COM2  and  COM4.  If  the  default  is  not  correct  for   your  port
| hardware,  you will have to explicitly specify the correct IRQ.

  Examples:

  TFPCX -PKISS1

  KISS-Port on COM1, base  address determined automatically and  default
  IRQ for COM1 used. For COM1  and COM2 this setting will be  sufficient
  in most cases.

  TFPCX -PKISS3:338:5

  KISS-Port on COM3, base address 0x338 and IRQ set to 5

-PPARn<Base>:<IRQ>

  BayCom PAR96 and BayCom PICPAR-Modem  connected to LPT 'n', where  'n'
  is the number  of the LPT  port. The base  address will be  determined
  automatically, but  can be  overridden by  specifying a  base-address.
  The default  IRQ is  set to  7.   When this  is not in accordance with
  your installation, you have to specify the correct IRQ.

  Examples:

  TFPCX -PPAR1

  BayCom  PAR96  or  PICPAR  modem  on  LPT1,  base  address  determined
  automatically and default IRQ 7 used.

  TFPCX -PPAR2::5

  BayCom  PAR96  or  PICPAR  modem  on  LPT2,  base  address  determined
  automatically and IRQ set to 5.

-PYAMn<Base>:<IRQ>

  YAM96-Modem connected to COM 'n', where  'n' is the number of the  COM
  port. The base  address will be  determined automatically, but  can be
| overridden  if   a  base-address   is specified.     IRQ  4    will be
| used as  the default   interrupt for  COM1    and   COM3, and   IRQ  3
| for COM2  and  COM4.  If  the   default  is  not  correct  for    your
| port hardware,  you will have to explicitly specify the correct IRQ.

  Examples:

  TFPCX -PYAM1

  YAM96  modem  on  COM1,  base  address  determined  automatically  and
  default IRQ 4 used.

  TFPCX -PYAM2::5

  YAM96 modem on  COM2, base   address determined automatically  and IRQ
  set to 5.

-PBPQnn
|
| FTP  software packet driver installed at software interrupt 'nn'. 'nn'
| is  in  hexadecimal, between 60 and 80. If 'nn' is not specified TFPCX
| will  search for an FTP software packet driver. The first driver found
| will be used.
|
| Examples:
|
| TFPCX -PBPQ6F
|
| FTP software packet driver at software-interrupt 0x6F.
|
-Bnnnn[:nnnn ...] specification of the baudrate for each port

  When using multiple ports the  values separated by a ':'  are assigned
  to  each  port  in  order  (first  value  for port-0, second value for
  port-1 and so on). The following values can be specified:

                                                       Default

  Serial Modem   300, 1200, 2400 or 4800 Baud            1200

   SCC Softclock    50-38400 Baud                        1200
       PA0HZP-Port  50-38400 Baud                        1200
       Hardclock    50-38400 Baud                        9600
       DF9IC-Modem   1-65535 Baud (without significance) 9600

  KISS              2400, 4800, 9600, 19200,             9600
                    38400 or 57600 Baud

  PAR96/PICPAR      9600, 19200 Baud                     9600

  YAM               45-19200 Baud (without significance) 9600

| BPQ               meaningless, not used
|
  When  using  serial  modems,  only  the  above  specified  values  are
  possible; when using SCC cards intermediate values are also  possible.
  When using Hardclock  the delivered transmit-clock  shall be equal  to
  the  specified  value.   When  using  a  DF9IC  modem  the  value   is
  meaningless because  the clocks  are generated  externally, but  it is
| advisable to  specify the  correct  value  anyway, because  that value
  will be  displayed when  using the  'P' command.  When using the YAM96
  modem the given  baudrate is cosmetic  too (just like  for DF9IC), the
  communication speed to the  YAM96 modem is fixed  at 19200 Baud.   The
  initialisation of the modem (using YAMINIT - supplied with the  modem)
  determines the actual speed on the air interface.

  Example:

  TFPCX -PCOM1 -PUSCC:::1003 -B300::19200

  Modem on COM1  at 300 baud,  USCC-Port 0 with  Softclock at 1200  baud
  (Default, '::') and USCC-Port 3 with DF9IC-modem at 19200 baud.

  Which  baudrates  are  possible  on  a  particular  PC, depends on its
| computing power  (see  table in appendix  2.1.).  When using  a serial
  modem at  300 baud  the system  clock will  lose half  a minute  every
  hour.

-ST

  This option will enable the  use of timestamps on status  messages and
  monitor messages by  means of the  'K' command. This  option will also
  cause setting of  the TNC time  according to the  DOS time on  the PC.
| The default date  style is European  style. This can  be changed using
  the 'K' command but  you have to supply  the current date yourself  in
  that case.

-SB
|
| This option will  change the way the linkpartner is informed about the
| end of a data transmission. Normally the link partner's @T2 timer will
| timeout when the last info-frame of a transmission was send. With this
| option set, the  last info frame will be followed by an  RR frame with
| the Poll bit  set (RR+).  This will  in some  cases increase  the link
| performance. The extra  RR frame is of course  an overhead, so on good
| links you should not use the -SB option.  Your millage may vary.  This
| will most likely help you when  you link-partner uses KISS modems (for
| which they need a large  @T2 value).  This option is in  conflict with
| DAMA polling, so  while the  port has an active  DAMA connection, this
| option will have no effect.

-SA

  This  option   will  enable   the  so   called  'frame-sammler'    for
| transmission  (for TFPCX's reception use the -SR option).  If  enabled
  TFPCX will only re-transmit the I frame for which a REJ was  received.
  If the receiver also has a 'frame-sammler' build in the receiver  will
| 'remember' subsequent  I frames and will acknowledge those immediately
  after the 'lost' I frame has been received.

  If the receiver does not have this feature you should not specify  -SA
  at  the  command-line  since  re-transmission  takes much more time in
  that  case.  When  not  specified  TFPCX  will  (re)transmit as much I
  frames as possible.

-SR
|
| This option will  enable the  so called  'frame-sammler' for reception
| (for TFPCX's transmission  use the -SA option).  If enabled TFPCX will
| collect correctly  received I frames even when one frame in the middle
| of a number of transmitted I frames is missed. The sender  only has to
| send  the one  missing I frame and TFPCX will acknowledge this I frame
| and the  collected  I  frames. It saves retransmissions. If the sender
| uses a Maxframe value of 7 this mechanism fails. Therefore the default
| is to disable this feature. You can safely use this option if you link
| partner uses  a Maxframe  of 6 or  less.  Note that  this problem also
| exists in  the TF27b  firmware.  A  Maxframe  of 7  is  therefore  not
| recommended, even on a reliable link. In previous versions of TFPCX27x
| the  'frame-sammler' on reception  was always enabled which could lead
| to uncontrolled data loss when your link partner used a Maxframe of 7.
|
6.2.2. TFPC- and DRSI-Interface

  For communication  with a  terminal program  TFPCX offers  4 different
  variations from  which one  has to  chosen, depending  on the program.
| Appendix  4.1   describes  the  calling  and   parameter  parsing  for
  programmers.

  The TFPC-Interface was developed by Sigi (DL1MEN) for his  KISS-driver
  TFPCR and is widely supported by many programs (e.g. SP, GP,  TSTHOST,
  THP, TERM,  DIEBOX). Therefore  this method  is also  selected as  the
  default interface for  TFPCX.  The  disadvantage of this  variation is
  the  limited  Multi-port  capability,  because  the  transfer  of port
  numbers (e.g.  of the  Port on  which one  has been  connected) is not
  possible.   Because  of  this,  connections  and  monitor  frames  are
  displayed as if they were  originating from one frequency. If  you are
  using only one port this variant is recommended.

-DR  DRSI-Interface usage.

  This  interface  uses   the  TNCTSR  driver   which  belongs  to   the
  DRSI-PCPA-Addapter.   Since  TFPCX  now  supports  multiport  usage, a
  method had to be  found for the terminal  program to be able  separate
  the different ports. This variant was a suitable alternative since  it
  was already fully supported  by SP and FBB.   The difference with  the
  TFPC  interface  is  mainly  the  parsing  of the port numbers in link
  status reports  and monitor  information.   This option  does not  use
  hardware support of a DRSI-PCPA-Adapter.

-DX Modifies DRSI-Interface operation

  This  option  corresponds  to  the  'DR'  option  of TFPCX v2.0x. That
| version  introduced  an  incompatibility  with  the TNCTSR-Driver when
  using  DRSI-Interfaces,  which  has  been  corrected  later.   If that
  correction leads to problems in other programs (e.g. TOP), the  option
  '-DX' should be used instead of '-DR'.

-DM  Modifies TFPC-Interface operation

| This  variant  is  specifically designed  for multiport operation with
  programs  which  so  far  only  support  the  TFPC  interface. It will
  deliver the same type  of messages as the  DRSI interface (so it  will
  include port numbers) but uses the already known TFPC interrupt.   The
  usage of this variant is a compromise. With many programs (e.g.  TERM)
  it does not lead  to any problem but  there are some side-effects  and
  some programs (e.g. THP) can not handle the port numbers at all.   The
  best solution is to try your program with or without the '-DM'  option
  and hope for an update of the program to support multiport  operation.
| The program GP for instance was changed to support this.

  WARNING!

  Please do not overload the developer of your terminal program (or  me)
  with messages, if, while using the '-DM' option, something screws  up.
  This  option  is  a  compromise  and  has  caused strange effects with
  certain programs in the past. Hopefully is has been corrected by now.


6.2.3. Other Options

-BU[nnnn] Size of the TFPCX-Buffer

  TFPCX  saves  most  data  in  64  byte  buffers. The number of buffers
  needed may be totally different from one application to the other.  If
  TFPCX has a small number of buffers  only a few frames can be kept  in
  intermediate buffers and every now  and then 'TNC BUSY' messages  will
  be reported, which  leads to a  disconnect by the  terminal program in
  most cases. Too many buffers waste memory.

  The  buffer  size  changed  from  32  bytes  in  TF2.3b to 64 bytes in
  TF2.7b. The designers  of TF2.7b decided  to keep the  reported number
  of buffers  compatible with  earlier versions,  so when  the number of
  buffers is defined it is divided by  2, and when it is reported it  is
  multiplied  by  two.   The  same  is  applied  to TFPCX. The number of
  buffers is still defined as if  the buffers are still 32 bytes.   With
  this option  the number  of buffers  set between  400 and approx. 1400
  which will result in 200 to 700 buffers of 64 bytes internally.   When
  reporting the  number of  free buffers  the internally  kept number of
  free buffers is multiplied by  2, the reported number will  never have
  an odd  value. The  maximum value  depends on  the number  of channels
  specified and will  be allocated when  the option -BU  is used without
  an actual number.

  The  default  value  of  600  buffers  (300  real  buffers) is usually
  adequate. If many channels are  in use, Gateway-Functions are used,  a
  Mailbox is serviced or large  Files transferred on fast Digi-links  it
  makes sense to increase the value.   When using SP (except for  V7.50)
  you should  not specify  more than  999 buffers  (see Section 7.1). If
  there is  very little  RAM available,  then also  a smaller  number of
  buffers can be used.

-CHnn Number of Connect-Channels

  With this option,  the required number  of channels can  be specified.
  The number of channels  should be the same  as the number of  channels
| selected in the  Terminal Program, if defined more it  will just waste
| valuable  RAM  space.   Selection  of  4  to  40 channels are possible
  (Default 10).

-C[xx] Transmit-/Receive indicator switch

  When using this option  an indication of the  transmit-/receive status
  will be  displayed while  in Host  mode. The  indicator appears at the
  top right hand corner of the screen ('S' for transmit (Send), 'R'  for
  receive).   When more  ports are  to be  used, each  port will  have a
| separate  indicator,  the left  indicator  will be  the indicator  for
  port 0. When using KISS mode the indicator will display the status  of
  the  connection  between  PC  and  TNC.  The  indication only works in
| text mode. The additional parameter specifies a color attribute.

  Example:

  TFPCX -C17
           ^ Foreground (here White)
          ^  Background (here Blue)

  Numbers of the Colour Attributes:

  0 Black    4 Red      8 Dark-Grey   C Light-Red     Monochrome:
  1 Blue     5 Magenta  9 Light-Blue  D Light-Magenta
  2 Green    6 Brown    A Light-Green E Yellow        07 Normal
  3 Cyan     7 White    B Light-Cyan  F Light-White   70 Inverse
                        ^             ^
                        only foreground

-F<File> File for the setup parameters (default TFPCX.INI)

  When using this  option (and only  then!) the specified  file (or when
| no file name  is given TFPCX.INI) will be read  during the startup  of
  TFPCX and send character by  character to the TheFirmware core  inside
  TFPCX.   This makes  it possible  to give  a pre-defined  value to the
  parameters.   Normally  this  option  can  be  omitted,  because  most
| terminal programs will initialise the TNC themselves. The file will be
  looked for in the current directory if no pathname is given.

  The  file  can  be  created  using  normal text editor and may contain
  comments (preceded by '#' or ';')  and empty lines.  For each  command
  found  an  escape-character  will  be  sent first automatically. Older
  versions required a  '^' first. This  is not longer  required and will
  be ignored when found,  so old files can  still be used. Tabs  will be
  handled as spaces and  will be ignored at  the beginning and end  of a
| Line.   An  example-file  is  included  in the distribution package of
  TFPCX.

-Ixx  Software-Interrupt for TFPCX-Interface (40-FF)

  The  communication  between  TFPCX  and  the terminal-program uses the
| specified software-interrupt.  Default  value  is interrupt 0xFD.  You
  only need to change this if the specified interrupt is already in  use
  by another  program or  when the  terminal program  only works  with a
  specific setting (e.g. '-IFF' with CT (K1EA) and FBB (F6FBB)).

-NB  Switch off Status Flash

  When TFPCX  has unread  information or  status changes  in its buffers
  and  is  not  running  in  hostmode  (so  it  is running background) a
  rectangle will start  flashing in the  upper right hand  corner of the
| screen.   This will  alert  the  user that  for example  a connect  is
  pending. The user can now start  his terminal program to react to  the
  connect. This will not work if a DOS-Shell is started from a  terminal
  program  which  will  keep  TFPCX  in  hostmode (as e.g. with SP). The
  flashing can suppressed using this option.

-NL Internal Connects (Loopback) Switch Off

  In normal  cases all  transmitted frames  are handled  as if they were
  also received: this enables internal  connects for test purposes.   In
  some cases  this is  not wanted  (e.g. during  tests with  an external
  loopback)  and  therefore  this  option  can  be used to prevent this.
  Under high load the use of  this option will also reduce the  CPU load
  a  little  because  the  transmitted  frames  don't have to be handled
  twice.

-D  Test Mode (Debug)

  This  option  is  valid  for  the  most  recently supplied '-P' option
  issued before the '-D' option on the command-line. It will activate  a
  test-mode for this port or  these ports. Each interrupt for  this port
  will  lead  to  a  voltage  change  on  the  internal PC speaker which
  results in a ticks (cracks) or a tone.

  The  test  mode  is  mainly  used  for  fault-finding  when  there are
  transmit or  receive problems  during modem  operation. (see  Appendix
  2.1.). When using 1200 baud  you should hear a 1800  Hz-Tone (baudrate
  *  1.5).   This  tone  should  be  clear and without interruptions. An
| unclear tone  is caused by  delayed interrupts. If the quality  of the
  tone sounds disturbed or interrupted then the CPU is overloaded.  What
  is  and  what  is  not  acceptable  is hard to define: some background
| noise is most likely still acceptable.

  When using this  option with a  KISS, SCC-Card, PAR96/PICPAR  or YAM96
  modem  you  can  check  if  interrupts  are  generated  at  all. These
  interrupts  can  occur  constantly  or  only  during  transmission and
  reception.

  When the option '-D' is specified  in before any '-P' option then  you
  will hear ticks in time with the system clock.


6.3. Removal of TFPCX from RAM

  By using  the command  'TFPCX -U'  you can  remove the  resident TFPCX
  from the memory.


6.4. Terminal Mode

  The command 'TFPCX  -T' will start  a simple terminal  so you can  use
| TFPCX without additional terminal  software. TFPCX should already have
  been loaded  (as described  previously). This  means that  the program
  should be invoked  twice with different  parameter settings (first  to
  load it resident and the second  time using this -T option), in  order
  to get into the terminal mode.

  The  key  combination  ALT-X  will  stop this terminal program. Before
  doing that you should switch off the monitor (if activated) using  ESC
  'MN', because otherwise the  internal buffers will be  exhausted quite
  quickly, and it may cause  problems when starting a host-mode  program
  afterwards.


7. Installation

  In this section  some advice is  given for the  installation with some
  programs using  TFPCX. In  all cases  TFPCX has  to be loaded resident
  before the  terminal program  is started.  Additionally, some settings
  in configuration files  or menus are  needed.  On  the other hand  the
  specified baudrates  in these  files or  menus are  irrelevant most of
  the time: the option '-B' at the start of TFPCX takes care of this.

  Some  programs  have  problems  with  multiport use (option '-DM'). In
  these cases you  should skip this  option and with  it the display  of
  port  numbers.  The  use  of  port  numbers  is  still possible in the
  commands so  you can  still use  multiport operation  anyway. You just
  don't  see  on  which  port  somebody  connects or on which port which
  monitor-frame is received. When using these kind op programs it  makes
  sense to use the '@PO' command (see chapter 8.2).

| You should be  aware that TFPCX  occupies a part  of memory, so  it is
  not free  for use  by the  terminal program  anymore. This may require
  you  to  decrease  the  number  of  buffers  and the number of connect
  channels to get both TFPCX and the terminal program in memory.


7.1. SP (DL1MEN)

  Depending on the number of ports, two variants are available:

  When only  one port  is required  you can  opt for the TFPC-Interface,
  which is supported since SP v5.0.  In this case you should install  SP
  according to  the SP-manual  or using  the INSTALL  program install SP
  for TFPCX  (or TFPCR)  usage. The  file CONFIG.SP  (previously SP.CFG)
  shall include  the line  'CFG=PORT0:5H'. In  practice there  is hardly
  any difference between TFPCX and TFPCR.

  For  multiport  use  you  should  use  the  DRSI-Interface.   The file
  CONFIG.SP shall include  the line 'CFG=PORT0:DH'  and TFPCX has  to be
  started using  the '-DR'  option. Apart  from that  you should keep in
  mind  that  everything  said  about  the  DRSI-PCPA-Addapter in the SP
  manual is also applicable to TFPCX, with the following exceptions:

  - SP-Commands 'DR' and 'HB' do work, the parameter will be set using
    the normal TNC-Commands with and additional port designation (see
    Section 8.1).

| - The port selection mechanism (described in chapter 8.1) without an
    explicit specification of the port does not work for some commands.
    SP will send those to the monitor channel 0 instead of to the
    actually selected channel. When you are not sure, always specify
    the port number explicitly.

  - Commands 'TP' and '//par' will show the correct baud rate (and not
    a number)

  When using the DRSI variant with  SP, the SP program will allocate  an
  extra QRG for each  of the 8 ports  , except for the  monitor channel.
  Switching  off  ports  can  be  accomplished  through  'C  1:', on the
  monitor  channel  this  will  select  the  unproto  port. The selected
  default port will be selected automatically when a connect command  is
  given, but can also be specified directly.

  TFPCX can also be  used in parallel using  TNCs in hostmode. How  well
  this will function depends on the computing power of the PC.

  When using SP6.0  (or earlier), the  QRG indication is  a bit unstable
  in some cases and the connect bell doesn't sound the same compared  to
  the sound you hear when using a  normal TNC.  This is normal and  does
  not cause problems.

  With early versions of SP v7.00 a bug may cause problems when using  a
  modem. Another  problem arises  if, while  using this  SP version, you
  use 2 modems and a TNC  in parallel (which I'm sure somebody  will do)
| and are  using the  DRSI  interface.   At the  startup of  SP you will
  immediately  get  a  Resync  message  and  it will refuse to run. This
  problem can be solve with a patch for SP.EXE.

  When using  SP v7.00  (or earlier)  you should  not allocate more than
  999 TFPCX buffers (option '-BU') because these versions have  problems
  displaying  more  than  4  digits,  and  the transmission will be very
  slow. In SP version 7.50 this problem is solved.


7.2. GP (DH1DAE)

  GP  will  use  TFPCX  automatically  if  it  is  loaded,  therefore no
  additional configuration settings are  required in normal cases.   For
  multiport use you have keep the following in mind:

  - GP version 1.50 or better is required. Earlier versions can only
    cope with one port, and they also have problems with higher
    baudrates.

  - You have to start TFPCX using the option '-DM'.

  - You must specify at least one PORT command in the file NAMES.GP,
|   because without this command all connect attempts are terminated
    with an error message.

   Example:

   PORT0 = DB0BLN,438.450
   PORT1 = DB0BLO,438,300

  With the  use of  TFPCX,   GP is  able to  control more  than one  TNC
  simultaneously. For  this to  work, these  TNCs have  to support  KISS
  mode operation (see section 8.3.).


7.3. THP (DL1BHO)

  THP supports the  TFPC-Interface (that is,  version 3.03 did).  In the
  configuration file CONFIG.PR  you have to  specify port number  '5' in
  the 'TNC-Configuration'  section. In  the file  CMD.PR a  few commands
  are normally  executed which  lead to  an error  message in TFPCX (for
  example 'A' and 'Z'). The best solution is to comment these lines  out
  by putting a '#' a the beginning of the offending lines.

  Multiport-operation using  the option  '-DM' gains  nothing since  the
  port numbers are not correctly displayed.


7.4. TERM (DL5FBD)

  This  TFPCX-version  works  best  with  TERM  version  9.71  or later.
  Earlier  versions   of  TERM   used  another   method  for   transmit-
  handshaking. This method is not supported by TFPCX anymore.

  When you want to use more ports you should load TFPCX using the  '-DM'
  option. Since  TERM does  not process  the TFPCX  messages itself,  it
  does not exhibit problems with the port numbers.

  After starting TERM, press the  key combination ALT-P: this will  open
  the parameter-menu. The following settings will work for TFPCX:

  V24-COMx:     5
  Handshake:    S
  Protect Time: 0 (without BREAK)

  It is  possible to  receive #BIN#  files with  this version  of TFPCX.
  Proceed as follows (tested with TERM v9.98):

  - Switch off character echoing by using the 'E0' command. This
    version off TFPCX will always run in 8 bit mode (transparent) so
    the command '@M' is not longer supported.

  - start the BIN reception using key combination ALT-U and answer the
    questions (read command as last).

  - restore character echoing at the end of the transfer by means of
    the 'E1' command.

  For more information read the TERM documentation.


7.5. CT (K1EA)

  The  contest  program  by  K1EA  also  supports  TFPCX (tested with CT
  v6.26).   During  CW-Contests  you  can  only  use  KISS or a SCC Card
  because CT will  otherwise have problems  with the correct  generation
| of Morse code.

  The options  '-DR' and  '-IFF' are  required when  starting TFPCX.  It
  also makes  sense to  set up  the parameters  in TFPCX  using the '-F'
  option.

  In the first dialogue box, the item 'TNC' shall be set to 'Local'  and
  when using a modem the 'Mode'  should be set to 'SSB'. No  adjustments
| are required  in the   communications setup  (CT will  not access  the
  modem-port  itself).  The  command  'DRSI'  should  be  entered in the
  QSO-screen, and then by using key combination ALT-T the TALK mode  has
  to be selected, and ENTER has to be pressed once. Now you can  connect
  to the  DX-Cluster and  using key  combination ALT-A  will display the
  DX-Information in the  opened ANNOUNCE-Window. You  will have to  find
  out the rest  for yourself.   It is advisable  to set CT  up as Single
  Unlimited  since  the  Single  Operator  setting  will  prohibit  some
  options.


7.6. DIEBOX (DF3AV)

  You can use DIEBOX with TFPCX by using the TFPC-Interface.  Of  course
  you  can  hardly  run  a  Box  with  only  one  simple modem, but this
  operation makes sense  with a SCC-Card  .  You  can also use  the KISS
  mode to  establish a  direct connection  to a  digipeater (e.g. RMNC),
  this setup will save a TNC.

  TFPCX  should  be  started  without  the  '-DR'  option.  I don't know
  whether or not the '-DM' option will work: you have to check this  out
  yourself.   It  makes  sense  to  increase  the number of the channels
  (option '-CH')  and the  number of  buffers (Option  '-BU'). I can not
  give more information about  the configuration of the  DIEBOX software
  because I have not tested this myself.


7.7. WINPR (DG6BI)

  WINPR version 2.0 supports TFPCX via the TFPC- Interface. Since  WINPR
  runs under Microsoft Windows it only works on a fast computer using  a
  KISS  TNC  or  a  SCC-Card  (see  Section 7.10.). Multiport use is not
  supported by WINPR. The option '-DM' should not be used with WINPR.

  TFPCX should be loaded before  Windows starts up, or started  from the
  WINSTART.BAT file. Windows has to  run in 386 Enhanced Mode.  The File
  WINPR.INI requires the settings:

  Port = Com5
  TfpcrInq = 253


7.8 TOP (DF8MT)

  The TOP documentation describes  how to use TFPCX  so I will stick  to
  the items which  are new.   For multiport operation,  TFPCX has to  be
  started with the '-DX' option instead of '-DR' option/

  Under TOP,  the different  TFPCX-ports are  handled as  separate TNCs,
  and each channel is directly  allocated to a single port  in sequence.
  That is why a  connect command does not  need a port-number. This  may
  seem  fine  but  up  'til  now  it  did not work consistently, connect
| requests from outside just used  the lowest available channel with the
  correct MYCALL, regardless of the channels-to-port allocation in  TOP.
  Using the command '@PO' (see section 8.2.) will fix this problem.

  Example:

  You want to use  TFPCX with 2 ports  and 20 channels with  10 channels
  on each  port.   In addition  to the  setup of  TNC Configuration, you
  should enter the following INI-Command in TOPSET:

  @PO 00000000001111111111

  In this case you should   load TFPCX using the '-CH20' option  because
  the default number of channels is only 10.


7.9  FBB (F6FBB)

  The  F6FBB-BBS-Software  supports  both  TFPC-  (from v5.15) and DRSI-
  Interfaces. Since  the DRSI  multiport interface will be used  in most
  cases, I  will elaborate  on that.   For modem  operation you  need at
  least FBB v5.15 or better.

  TFPCX should be loaded with the '-DR' and '-IFF' options. If you  need
  to support more  than 10 channels,  the '-CH' option  is also required
  (see  section  6.2.3.).  When  using  2  ports, the configuration file
  PORT.SYS will look as follows:

  # PORT.SYS for FBB 5.15
  #
  #Ports TNCs
   1     2
  #
  #Com Interface Address (Hex0) Baud
   7   4         0              4800
  #
  #TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M/P-Fwd Mode Freq
   1   5    7   0      230   2     1     10     00/60   UDYW 144.650
   2   5    7   1      230   2     1     10     00/60   UDYW 438.458

  TFPCX simulates  2 TNCs  via a  virtual COM-Port  (COM7). Interface  4
  means DRSI: the address and  baudrate will be ignored, but  these have
  to appear in  the file. The  sum of the  number of ports  allocated to
  the channels  (NbCh) shall  not be  greater than  the total  number of
  available  TFPCX  channels  (given  with  option -CH or otherwise 10).
  There  is  however  only  one  INITTNC1.SYS  or MAINT1.SYS file needed
  which  will  set  all  the  needed  parameters  and port settings (see
  Section 8.1) for all ports.   The 'P'-command in TFPCX cannot be  used
| to set  all parameters  of a port simultaneously  like the DRSI-TNCTRS
  driver can. For more information refer to the FBB-Documentation.


7.10. MS-Windows 3.1x, OS/2 and others.

  When using a  modem TFPCX requires  a very low  interrupt latency (see
| appendix 2) which  can not be accomplished when running  under Windows
  3.x or IBM OS/2  2.0 (although there are  a lot of people  who find it
  hard not accept this fact). That  is why TFPCX will generate an  error
  message if  an attempt  is made  to start  TFPCX for  modem use  while
  running one of these systems.

| Operating an SCC-Card using these systems is possible.  Actually, this
  works  quite  well  when  using  1200  baud  under Windows. When using
| higher baud-rates running SCC cards will also cause problems.  Running
  OS/2 will  not work  as well  as running  under Windows,  but this was
  only tested  during a  short test.  I have  no idea  how well a PAR96,
  PICPAR or YAM96 modem will work under these systems.

  KISS mode works in my setup on both systems up to at least 38400  baud
  without any problem. The COM ports are fully supported by Windows  and
| OS/2 drivers,  which is  unfortunately not  the case for the SCC cards
  (which is of course reasonable).

  When  using  other  multitasking  systems  you  may  find  a   similar
  behaviour.


8. Operation

  In  this  section  the  most  important  differences and extensions in
  TFPCX compared to the TNC-Firmware TF 2.7b. will be explained.


8.1. Multiport extensions.

  The most  significant extension  is without  any doubt  the option  of
  using  more  than  one  port  simultaneously, which enables control of
| multiple modems and  transceivers.  If  you only use  one port you can
  skip this section and move ahead to next section.

  TFPCX-Firmware can manage up to 8 ports. I think that using them all
  will only occur in exceptional cases. The unused ports can be used
  for internal connects. This will enable you to check your CTEXT
  message without disturbing the Digi uplink (which seems to be a
| popular pastime with some people)

  A unique  number (0-7)  is assigned  to each  port. The  assignment of
  those numbers follows the exact  same order as the '-P'  options which
  are given at the start of  TFPCX. These port numbers are displayed  by
  TFPCX in  conjunction with  link status  reports, in  the Monitor, and
  when using certain commands ('C',  'L' and 'S'), so you  can associate
  the  message  with   a  specific  port.   This  portnumber  is    only
  displayed if one  of the options  '-DR', '-DX' or  '-DM' is used  when
  starting TFPCX.

  Example:

  1:fm DG0FT to DB0BLN ctl SABM+
  1:fm DB0BLN o DG0FT ctl UA-

  CONNECTED to 1:DB0BLN

  The exact format of the messages  can be found in appendix 4.2.  Where
  the  portnumber  is  displayed  on  the  screen depends on the type of
  message, and on the terminal program.

  Some  firmware-commands  (see  section  8.2.  and  appendix  1.)   are
  extended to accept a  port number so you  can set some parameters  for
  one specific port or connect a station on one specific port.

  Command Format:

  <Command> <Port>:[Parameter]

| <Port> is a  digit between 0  and 7, no  space is allowed  between the
  digit and the ':'.

  Example:

  C 1:DB0BLN
  T 2:15

  If  the  port  number  is  not  specified for a command which normally
  needs a port number,  either the port on  which a channel just  became
  active is used, or the port  which is specified on monitor channel  as
  unproto port is used.  There are, however, hostmode terminal  programs
  which do not send  a command to the  same channel as the  channel from
  which  the  command  was  originated,  and this will undermine correct
  port  selection.  Therefore,  always  specify  the port number when in
  doubt.

  Most  of  the  times  the  parameter  settings  are  defined  in   the
  configuration files  of the  terminal program  and have  to be defined
  individually for each port. The  file TFPCX.INI is an example  of this
  and can,  once the  personal data  has been  set, be  used directly to
  initialise the ports (Option '- F', Section 6.2.3.).

  Incoming  connects  are  normally  assigned  to the first free channel
  which has an matching MYCALL setting, regardless of the port on  which
  the connect  was recieved.   By using  the command  '@PO' (see Section
  8.2.) a port can be assigned to use only specific channels.


8.2. Some special command characteristics.

  There are a number of commands - which all start by using the  ESC-Key
  and which  are executed  by pressing  <ENTER> (see  Appendix 1.).  The
  TF27b commands  'A', 'H',  'K', 'Z',  '@F' and  '@K' do  not exist  in
  TFPCX.

  The Parameters  'B', 'O',  'P', 'T',  'W', 'X',  '@C', '@D', '@T2' and
  '@TA' are used separately for each port.

  The internal timer works  with an accuracy of  +/- 20 ms or  +/- 60 ms
  if KISS or the OptoPcScc-Card  without timer port is used.  This could
  be important  for some  parameters .  For TXTAIL  (Command '@TA') this
  inaccuracy is automatically taken into account.

  The individual commands:

C  Connect

  When using  multiple connects  to the  same station  with the selected
  SSID already in  use, the SSID  will be incremented  automatically (up
  to a maximum  of 15). The  terminal program may  not be aware  of this
  and may show the wrong SSID.

  You  can  specify  a  port  number  when  using  the C command. If not
  specified, the number  will be sought  in the Link-List  (see '@L') or
  the  Unproto  port  is  used  if  the  search fails. If the channel is
  allocated to a port by means of the '@PO' command, that port will  act
  as default  port for  that channel.   On the  monitor channel  you can
  select the  Unproto port  by specifying  a port  number, the UI frames
  will be transmitted (Default port 0) on this port.

  Examples:

  C 1:DB0BLN                  Connect DB0BLN on Port 1
  C 2:TEST \ Monitor-Channel  Set Unproto-Port to 2 and set Unproto-ID
  C 2:     /                  Set only Unproto-Port to 2

F  Frack

  The  FRACK-parameter  can  set  in  seconds  or  alternatively in 10ms
  units. Values 0 to  15 are considered to  be given in seconds  and are
  converted internally to the new 10 ms units.

O  MAXFRAME

  MAXFRAME be  set individually  for each  Port and  each connection. At
  connect  time,  the  value  specified  for  the port will used for the
  connection and can be changed independently from other connections  on
  the same port.

P  P-Persistence

  Under  DAMA-operation  the  non-DAMA-Value  will  be  displayed,   but
  actually P=255 will be used .

  If the indicated  parameter has a  value between 0  and 7 (Portnumber)
  the  P-Value  will  not  be  set  but  instead  some parameters of the
  indicated port will be displayed using the following format:

  <Port> R P W F O N @T2 @T3 T <Baud> @D

  This had to be built-in to keep TFPCX compatible with the  DRSI-TNCTSR
  driver when it is  used by SP.   <Baud> is the configured  baudrate in
  readable text formal, not like TNCTSR which uses a designated number.

  The DRSI-driver also  uses this command  to set the  P-parameter, this
  will  not  in  work  TFPCX.  TFPCX  will  ignore the entire command if
  additional values are given following the port number.

QRES  Reset

  QRES simply resets  TFPCX back into  Terminalmode (like 'JHOST0')  and
  does not RESET  the computer. This  command is needed  because SP uses
  it when the DRSI-Command 'HB' is executed.

U  Unattended Mode (CTEXT)

| This command is  mainly important when  using TFPCX in  terminal mode.
  With setting 'U0' link-status messages are sent out immediately,  even
  if another channel is active  at that moment. With setting  'U1' these
  messages kept and only displayed when the appropriate channel  becomes
  active by means  of the 'S'  command. This setting  will also cause  a
  readable text to be send back when someone connects from outside.

  The default setting 'U2' behaves almost the same as setting 'U1',  but
  additionally it allows disconnection  of a connected station  by means
  of the remote command '//Q' (or '//q'). This command has to appear  at
  the start of a frame (otherwise it will not be handled).

  You can also switch unattended mode  on if no CTEXT has been  defined.
  The only effect of this command in host mode this the handling of  the
  connect text (CTEXT).

@C  DCD-Working

| TFPCX has a Soft-DCD  (software squelch). When using slow transceivers
| (slow meaning  a slow  squelch circuit)  you can  leave the squelch of
  the receiver fully  open. TFPCX will  determine for itself  whether or
  not a packet signal is being received.

  The  Soft-DCD  can  be  controlled  by  means of the '@C' command, the
| given parameter  controls the noise-cancelling level.  This  parameter
  can be a  number between 0  and 63. When  using '@C0' the  Soft-DCD is
  switched off (default)- all other  values activate the Soft-DCD.   The
  lower the  value the  more unstable  and faster  the Soft-DCD becomes,
  the  higher  the  value,  the  more  stable and slower it becomes. The
  ideal DCD should be both  stable and fast. Therefore the  best setting
  will good compromise between the two extremes. To simplify the job  of
  finding the  right value  you can  use the  DCD indicator  (see option
  '-C').   When  using  a  small  value  you  will  see the unstable DCD
  indication, when using a large value you will see slow and  inaccurate
  recognition of  signals.   The best  way to  set this  correctly is to
  slowly increase the parameter value while listening to the signals  on
  the PR QRG,  until the indication  is correct. A  good start value  is
  '@C25'.

  When using  SCC, PAR96  or PICPAR  ports an  adjustment is  not really
  needed, all  values above  0 will  activate the  Soft-DCD and they all
  have the same meaning for  the operational software.  I  was, however,
  annoyed by the constant flickering of the indicator, so you can  still
  adjust the value  to reduce the  flicker. For the  YAM96 modem the  @C
  command will not work at all since it always uses a hardware DCD.

  IMPORTANT!

  The soft-DCD  only recognises  PR-Signals at  the same  baud rate. You
  can _not_ use the  soft-DCD on packet QRGs  which carry PR signals  at
  different baud-rates.

  When  using  KISS,  the  TNC  handles  the  DCD, and this command only
  defines the time  (in 10ms-Units) after  which the RX  indication will
  be removed from the  screen if no further  data was received from  the
  TNC.

  When you are connected to a  DAMA station the DCD will be  ignored for
  the used  port. The  DAMA station  will regulate  the traffic and will
  ensure a free QRG when it  sends a DAMA-poll to you, so  TFPCX doesn't
  need to double-check this. The advantage is a very fast response  from
  TFPCX, which makes the DAMA handling better. This was introduced  with
  TheFirmware TF2.7b, and is also used in TF2.7b based TNCs.

@L  Link List

  Using this command an internal  link-list is managed which is  used to
  allocate up to  8 calls (with  SSID) to a  specific port. The  list is
  used for the digipeating function ('R' command) to select the port  on
  which the  recieved frame  should be  re-transmitted. If  there is  no
  appropriate entry in the  link-list, the frame will  be re-transmitted
  to the same port as where it was recieved from.

  Syntax:

  @L <Port>:<Call> <Port>:<Call> ...

  Example:

  @L 0:DB0BLN 1:DB0BLO

  Using '@L-' will clear  the link list. The  contents of the list  will
  be displayed using '@L' without any parameters.

  For crossband-digipeating  both source  and destination  calls have to
  be present in the link  list, otherwise the connection will  only work
  correctly in one direction.

@PO

  By using this  command you can  define for each  channel if it  can be
  used for all ports, only for a  specific port or if it cannot be  used
  by any port.   If a channel is  set-up to use one  specific port, this
  port will also be used as the  default port if a 'C' command is  given
  on this channel.

  As  parameter  a  string  is  passed.   The first character belongs to
  channel 1, the second to channel  2 and so on. When using  10 channels
  the  string  will  normally  consist  of  10  characters. When a lower
  number of characters  are given the  allocation of remaining  channels
  are not changed. When more  characters are given the extra  characters
  are ignored.   The following  character can  appear in  the  parameter
  string:

  '0' to '7' Connect only possible from one port (Port Number)
  '*'        Connect possible from all ports
  '-'        No connect from outside possible

  Examples:

  @PO 0000011111*****-----

  Channels 1  to 5  can only  be accessed  from outside  though port  0,
  channels  6  to  18  only  through  port  1.  Channels  11  to  15 are
  accessible  by  every  port  when  someone  connects  from outside and
  channels 16 to 20 are not accessible from outside at all and can  only
  be used for outgoing connections.

  @PO **********

| All  channels  can  be  accessed from  all  ports: this is the default
  setting and is compatible with earlier TFPCX versions.

| Incoming connects are  assigned  to the  lowest free channel  to which
  the port is allowed to  connect (the channel either has  been assigned
  to this port or can be connected  by all ports ('*')) and on which  an
  appropriate MYCALL  is present.   If there  is no  appropriate channel
  available the connection will be refused (BUSY).

@ST  Statistics

  By using 'ST  <Port>:' some statistical  values will be  displayed for
  the given  port. These  values are  gathered for  all connects on this
  port. Be aware that the counters will wrap to 0 after reaching 65535.

  Example:

  0 SCC0 TX 87 11 10 RX 547 201 201 ERR 1
  ^ ^       ^  ^  ^     ^   ^   ^       ^
  1)2)      3) 4) 5)    6)  7)  8)      9)

  1) portnumber
  2) interface port ('NULL', for internal Port)
  3) total number of transmitted frames
  4) number of I-frames sent
  5) number of acknowledged I-frames ( 4)-5) are lost )
  6) total number of received frames
  7) number of received I-frames
| 8) number of effectively received I-frames ( 7)-8) REJects )
  9) number of errors occurred (will be shown for SCC and KISS and
     only if it isn't 0)

  It  is  possible  to  do  some  statistical calculations and draw some
  conclusions by using  these values .  The interface port  name 2) will
  have  a  '+'  appended  to  the  name  if  KISS  is  used and SMACK or
  RMNC-CRC-KISS is active.

  When using SCC cards value #9 shows the number of over- and  underruns
  of the  SCC controller,  which will  occur if  the interrupts  are not
  serviced fast enough. When using KISS the counter will be  incremented
  each time  a byte  is lost  or when  a KISS  frame or CRC error occurs
  (with SMACK  or RMNC-CRC-KISS).  When you  notice a  rapid increase of
  the number of errors your PC  might be too slow for the  used baudrate
  or, when using KISS, the connection to the TNC is not okay.

  You can clear  the statistics by  means of the  '@ST <Port>:-' command
  (for the indicated port).

@TA  TXTAIL

  You  can  specify  the  TXTAIL  value  in 10ms units (0-6000) but this
  value  is  in  normal  cases  (for  the  selected  baudrate  and timer
  inaccuracy)  already  set  to  the  most  optimal value (@TA=4 for 300
  baud, @TA=1 otherwise). When using  KISS the correct value depends  on
| the used TNC, therefor it is not set automatically in this case.

@U  Unproto-Poll

  By using  this command  you can  specify if  unproto-frames should  be
  sent with (Default) or without a set poll-bit.


8.3. KISS

  When using KISS there are some special things you'll need to know.  We
  will elaborate on this in this section .

  Before you start TFPCX the TNC has to be switched on should have  been
  set to KISS mode. TFPCX does  not offer the option of putting  the TNC
  into KISS mode. The TFPCR command  @K does not exist in TFPCX.  To set
| the TNC to KISS mode you  can use the program SETKISS (which should be
  in the package from which included TFPCX).

  TFPCX  supports   the  KISS-enhancements   SMACK  (Version   1.0)  and
  RMNC-CRC-KISS,  which  both  improve  the  reliability  of   transfers
  between the TNC and the  PC. SMACK or RMNC-CRC-KISS will  be activated
  automatically if the connected TNC  supports it. By using the  command
  @ST (see section 8.2)  you can check if  one of these enhancements  is
  activated (a  '+' sign  is shown  if SMACK  or RMNC-CRC-KISS is active
  e.g. 'COM1+'). SMACK or RMNC-CRC-KISS  is only activated when least  1
  Frame has been sent and received.

  With KISS, the Send-/Receive indicator does not show the  send/receive
  status  on  the  radio  channel,  but  the  send/receive status on the
  serial port to the TNC or to a connected other PC.

  To couple two PCs together (e.g. one running a digipeater and  another
  running a mailbox) you need a null-Modem-Cable. When using this  setup
  TFPCX always  works in  duplex mode  (the command  @D is meaningless).
| The parameters should be setup accordingly. The following descriptions
  are  mainly  important  for  normal  use  with  a TNC (no direct cable
  connection).

  In KISS-Mode,  TFPCX has  no direct  control over  the radio  channel,
  because the  TNC is  in between.  TFPCX has  no possibility  to detect
  whether or not the  frequency is free and  when the frames to  be sent
  are actually  transferred, which  may lead  to unwanted transmissions.
  Two situations are especially interesting.

  - Assume TFPCX has transferred  one frame to the TNC  for transmission
|   and waits for an acknowledgement  from the other station. If at that
    moment the radio link is  occupied for some time by  another station
    (for instance  a Digi)  the TNC  will not  be able  to transmit  the
    frame. After some time however TFPCX assumes the frame was lost  and
    starts a retransmission, but in  reality the original frame was  not
    transmitted at all at that time.  The result of this is an  unwanted
    duplicate transmission of a frame.

|   The  time   between  sending   a   frame   and  reception   of   the
|   acknowledgement is measured  by TFPCX and  it will 'learn'  how long
|   on  average  TFPCX  has  to  wait  before receiving a response. This
|   mechanism will adapt itself to the traffic on the radio channel  and
|   avoids the double transmissions. In TheFirmware 2.7b, the  parameter
|   @A3  (with  which  you  could  manipulate  the  delay  in earlier TF
|   versions) is fixed and cannot be adjusted anymore.

  - When  more  frames  are  received  in  a  row, all these frames  can
|   normally be acknowledged with  a single response frame. The question
    is, when can TFPCX assume no  further frames will be sent so  it can
    generate the  single response  frame? When  using a  serial modem or
    SCC Card, TFPCX can wait until the other station stops  transmitting
    and the radio channel is free again.

    This  method  is  not  usable  anymore  when using KISS. The correct
|   setting of  parameter @T2  is very  important when  using KISS.  @T2
    specifies  the  time  the  receiver  of  the  frame is going to wait
    before a response  is generated. If  a new frame  is received during
    this time,  the wait-time  is starts  all over  again. The wait-time
    should only expire if no further  frame is going to be received,  so
    all received frames  can be acknowledged  using one response  frame.
    If  the  wait-time  specified  with  @T2  is too short then unneeded
    response frames will be send (wasting time and channel occupation).

    Which value should @T2 have?  The wait-time should be just  a little
    longer with respect to the transmit-time of one frame from the  peer
    station. The following times are derived from the used baudrate  and
    can be used a guideline:

      Baud    @T2

      1200    250
      2400    150 (Default)
      4800    100
      9600     50

    These times are valid when using  256 data-bytes in a frame and  are
    a bit on the  high side. If you  want to experiment with  this value
    you should watch the monitor to see if sequentially recieved  frames
    are acknowledged with only  one RR-frame. It is  probably acceptable
    if  more RR-frames are sent occasionally.

    IMPORTANT

    The default-value  @T2=150 is  too short  to use  for 1200 baud. You
    should certainly use a larger delay setting for @T2 if you use  1200
    baud.

    The value @T4,  to be used  as @T2 with  DAMA, which was  present in
    previous versions of TFPCX, does not exist anymore. For DAMA @T2  is
    not  needed at  all since the response  can be generated as  soon as
    the DAMA  station polls  for a  response (result  of the  new TF2.7b
    firmware used in TFPCX).


8.4. DAMA

  As soon as a connection  is established to a DAMA-master  (digipeater,
| box or BBS), TFPCX will only transmit if it receives a frame from  the
  master  with  the  request  to  respond.  TFPCX  will send all pending
  transmit-frames for all channels which are using the same port as  the
  port on which de DAMA  connection exists. The DAMA-slave mode  is only
  activated on the port which carries the connection to the master.  The
  connections using other ports will  run normally without DAMA. When  a
  connection to another  DAMA master exists  using another port  it will
  handle  the  channels  using  that  port  independently  from the DAMA
  connection  on  the  other  port  (i.e.  for  DAMA  all  the ports are
  independent of each other).

  You don't  need to  change any  parameter setting  for DAMA. This will
  enable you  to use  the same  port also  for non-DAMA  connections. By
  looking at  the monitor  you can  see '[DAMA]'  appended to the frames
  from the DAMA master. If the  frames are sent to you, TFPCX  will also
  have  switched  to  DAMA.  The  'B'  command which existed in previous
  versions of  TFPCX does  not exist  anymore (TF2.7b  uses this command
  for another purpose).

  This version  of TFPCX  changed to  the DAMA  handling of TF2.7b. This
  means TFPCX now supports the latest version of the DAMA protocol.  All
  previous versions of TFPCX did not. In fact this was one of the  major
  reasons to upgrade TFPCX to the latest TheFirmware version. This  also
  means the layer 1 DCD is ignored when connected to a DAMA master.  The
  DAMA master ensures  a free QRG  so there is  no need to  double-check
  it. This will ensure a fast response on a DAMA request. This  solution
  may lead to  problems for KISS  however, since TFPCX  does not control
  the DCD in  the KISS TNC.  If the KISS  TNC has a  good DCD it  should
  work  anyway  because  the  QRG  is  clear  after  being polled by the
  DAMA-master.




                             Appendices


1. Overview of Commands

  Command        Parameter       Description
  ------        ---------       ------------

  * C            Call ...       Connect-route
                                Connect on channel 0 sets port and name
                                and name for unproto messages

    D                           Disconnect

    E(1)          0             No echo of input characters
                  1             Echo input characters

    F (250)      1-15           Start value for T1 (in seconds)
                16-65535        Start value for SRTT (10ms)

    G            [0]            Obtain information in hostmode
                 [1]            Obtain status in hostmode

    I            Call           Set own call sign

    JHOST (0)     0             Change to terminal-mode
                  1             Change to hostmode

    K             0             No timestamp
                  1             Timestamp on status messages
                  2             Timestamp on status and monitor messages
               hh:mm:ss         Set TNC time
|              dd.mm.yy         Set TNC date (European style)
|              mm/dd/yy         Set TNC date (American style)

    L           [0-10]          Status display of a channel, if no
                                channel given, displays all channels

    M (N)       NIUSC+-         Monitor-Operation Type

    N (20)       0-127          Number of Tries (0 = unlimited)

  * O (2)        1-7            Maximum number of unacknowledged
                                packets allowed

  * P (32)       0-7            Parameter request for a port
                 8-255          P-Persistence value for non-DAMA

    QRES                        Reset into terminal-mode

    R (1)         0             Digipeater function off
                  1             Digipeater function on

    S (0)        0-10           Select channel (number, 0 = unproto)

  * T (25)       0-127          Time between PTT on and frame start
                                (10ms)

    U (2)        0              Suppress connect text
                 1 [Text]       Connect text active
                 2 [Text]       Connect text and remote-//Quit active

    V                           Display TF version string

  * W (10)       0-127          Time slot for P-Persistence (10ms)
                                Ignored for DAMA

  * X (1)         0             PTT switching off, TX suppressed
                  1             PTT switching on, TX allowed

    Y (10)       0-10           Maximum number of connections

    @B                          Shows number of free buffers

  * @C (0)        0             Software-DCD off
                 1-63           Threshold value for software-DCD

  * @D (0)        0             Full duplex off
                  1             Full duplex on

    @I (80)       0             IPOLL off
                 1-256          maximum Length of an IPOLL-Frame

    @L           Port:Call ...  Linklist setup (max. 8 Entries)
                 '-'            Linklist clear

    @PO ('*')    cccccccccc     Port assignment (each channel one
                                character)
                 c = '0'-'7'    Connect only possible from port c
                     '*'        Connect from all ports possible
|                    '-'        No connect from external stations
|                               possible

    @S                          Current link state

  * @ST                         Status indicator per Port
                 '-'            Reset status counters

  * @T2 (150)    0-65535        Timer T2 (10ms)

    @T3 (30000)  0-65535        Timer T3 (10ms)

  * @TA (1/4)    0-65535        Time between frame end until PTT off
                                (10ms)

    @U  (1)       0             Unproto-frames without Poll
                  1             Unproto-frames with Poll

    @V  (0)       0             Call sign check switched off
                  1             Call sign check switched on

  *   Parameter <Port>: possible
  []  optional Parameter
  ()  Standard installation
  ... additional Parameters possible

A lot of these  commands can be used  without parameters to display  the
current setting for the command.


2. Error Remedies (Modem Operation)

  When you  have a  problem you  should first  find out  what could have
  caused it. Besides TFPCX, it could be caused by the Terminal  program,
  the modem,  the SCC  Card, DRSI,  PAR96/PICPAR or  YAM96 modem, or the
  tranceiver.

  This section focuses mainly on use with a modem.

  TFPCX demands more from your PC  compared to the use of a  normal TNC.
  When your PC cannot live up to this demand you will be in trouble.  To
  understand  this  I  will  explain  how  TFPCX  works when sending and
  receiving.

  When  using  packet  radio  the  information  is  transmitted  using a
  synchronous serial link.  The PC's serial  port can, when  used in the
  normal way, only transmit asynchronous serial information using  start
  and stop-bits which  do not exist  with packet radio.  The serial port
  can therefore not be used in  the normal way. This means TFPCX  has to
  handle each and every  bit itself: the serial  port is only used  as a
  simple latch which can store only one bit.

  To enable  TFPCX to  handle the  data in  a predefined  speed of,  for
  example, 1200 bits/s it needs a accurate clock. To transmit the  clock
| has to deliver 1200 ticks/s. The  method used to receive data needs  a
  clock  which  can  deliver  3600  ticks/s  which  makes it possible to
  constantly synchronise on the  recieved signal. TFPCX uses  a software
  PLL. The modem RX line is sampled 3 times per bit to detect if the  RX
  line changed from a logical 1 to  0 or 0 to 1. In the  ideal situation
  such  a  change  should  only  occur  on  every  third  sample. Due to
  inaccuracies the timing drifts away with respect to the sender.  Since
  three samples  are taken  per bit  the direction  of the  drift can be
  detected and compensated.

  As accurate clock I used the  PC's internal timer which is present  in
  any  PC  and  is  normally  used  for  the  date/time  in  DOS.  TFPCX
  re-programs  the  timer  to  supply  an timer-interrupt 3600 times per
  second.  The  interrupt  handler  (the  so  called  Interrupt  Service
  Routine, ISR)  will take  control over  the CPU  and suspend what ever
  was executing at  that moment and  will call the  functions which take
| care of  sending and  receiving. It  is inevitable  this can only work
  correctly if  all the  interrupts are  handled in  a steady repetition
  and  without  too  much  delay.  This  will  be a problem when running
  Windows or OS/2,  that's the reason  why it does  not work right  when
  using these systems.

  If you compare the load on the  PC caused by TFPCX compared to a  TNC,
  TFPCX will cause a 30 times higher load when using the same  baudrate,
  using 1200 baud it can be compared  with a 36000 baud TNC on your  PC,
  which gives problems on a lot  of slow PCs. Luckily enough for  us,PCs
  are  getting  faster  and  faster,  so  this  has  become  a less of a
  problem  over  the  years.  The  timing  inaccuracies are causing most
  problems nowadays  when TFPCX  doesn't run  under plain  DOS. This  is
  still a big difference between using TFPCX or using a TNC.


  2.1. Send- and Receive Problems

  The used  PC should  in the  first place  be capable  of handling  the
  large number of interrupts.  When your PC is  not able to handle  this
  it  will  run  very  slowly,  or  your  PC will lock-up or crash. From
  experience  the  following  table  may  used  as  a guideline (without
  guarantee):

  PC    XT   XT   286  386
  MHz   5    8    12   20

  Baud
   300  *    *    *    *
  1200  ?    ?    *    *
  2400  -    ?    *    *
  4800  -    -    ?    *

  *  Operation possible
  ?  Operation probably possible (with Limitations)
  -  Operation impossible

  As you  see, a  modern PC  with at  least a  486 or  Pentium processor
  should not cause any problems with processing speed any more.

  There are,  however, also  problems with  PCs which  are in  principle
  fast enough. Most of the  time the installation suffers from  unstable
  reception, which leads to many  REJects, which in turn will  result in
  many retransmissions.   This is in  most of the  cases caused by  some
  residential program,  driver or  additional hardware  which delay  the
  interrupts handling  too long.  When the  timer interrupt  handling is
  delayed for more than 200s during the reception of a frame the  whole
  frame will be lost (even if it occurs only once). When you  experience
  these kind of  problems you could  start TFPCX using  the '-D' option.
  When you hear interruptions of the tone you hear from the PC  speaker,
  you experience this problem.

  Common sources of problems:

  - Usage  of Extended  (XMS) or  Expanded   Memory (EMS)  as buffer for
    the terminal program  (e.g. SP, GP)  and disk-caches (especially  on
    a 286 PC)

    To avoid this you should prevent usage of this RAM as long as  TFPCX
    is used. When using SP  you should not use SPO.EXE  and XMS-Swapping
    ('SWP=1'  in  CONFIG.SP).  GP  should  be  started  with  the option
    '/NOXMS'.

  - A   driver, which  enables resident  programs to  be loaded  in high
    memory (e.g. EMM386)

    If the  previous solution  did not  work for  you, you could disable
    the whole EMM386 driver while using TFPCX.

  - Slow Keyboard-Driver (KEYB)

    If  frames  are  always  lost  when  a  key is pressed you could try
    another keyboard driver (like CKEYGR.COM from the SP-Disk).

  - VGA-cards and HD-controllers

    Many  VGA-Card  disable  interrupts  for  some  time when running in
    graphic mode. I also heard  there are HD controllers which  give the
|   same  kind  of problem.  When  the controller was removed everything
    worked again. It is a problem for me to give a general solution  for
    this. You could try a program which does not run in graphic mode.

  - Running under Windows

    Although you can not start TFPCX in a DOS session under Windows  for
    use with a serial modem, you can start TFPCX in DOS before  starting
    windows. Some  people have  reported this  works for  them, but most
    users will get  nothing but trouble  using this setup.  Windows will
    delay the timer  interrupts to much  to make a  reliable connection.
    The only solution is to quit using TFPCX this way.

  Sometimes you have to live with a compromise to use TFPCX. If you  are
  not willing to accept this then TFPCX  is not the right way to go.  If
  you wonder  why TFPCX  stopped working  all of  a sudden  you have  to
  question if you loaded  a new driver or  changed anything else in  the
  setup of your PC. Something I  do NOT want is somebody using  TFPCX on
  a Digi QRG with a setup which only receives a frame correctly after  3
  retries each time.


2.2. Problems with other Programs

  While TFPCX is  active you should  not run programs  which use the  PC
  timer which is in use by TFPCX.  If you do your system may crash,  run
| extremely slowly,  or the  DOS clock  will not  run correctly anymore.
  Among these programs are:

  - MS-Word 5.0 and 5.5
  - EDIT in MS-DOS 5.0
  - MS-Windows
  - many Mouse Drivers

  Using the following  programs also gave  problems, the exact  cause is
  unknown:

  - Keyboard  driver  from  DR-DOS  6.0  (keyboard hangup), use  another
    drivers (e.g. CKEYGR.COM, which was distributed with SP).

  - Microsoft mouse driver (MOUSE.COM). Cure: use another driver

  - IBM VCPI.SYS-Driver (used in notebooks), removal of the driver might
    solve the problem


2.3. Hardware Problems

  There are PCs (especially Laptops), which do not have 100%  compatible
  serial ports. The demands on the ports are not so high as for  BayCom,
  when the deviations are too big  it can also cause problem with  TFPCX
  on these  computers. In  many cases  receiving works  buy sending does
  not. Up till  now I received  some reports of  this for the  following
  computers:

  - Toshiba 1000XE
  - NEC Multispeed
  - Olivetti M24

| TFPCX offers the possibility  to use the modem  on the LPT port, which
  might be an option to bypass the problem.

  Most  laptops  and  notebooks  have  build-in Power Management to save
  (battery) power. When the keyboard is not pressed for some time  Power
  Management  may  reduce  de  processor  speed,  which  may  reduce the
  processing power for TFPCX below a usable level. When using this  kind
  of PCs (e.g.  Olivetti Quaderndo) it  is often required  to deactivate
  the  Power  Management  (especially  the  reduction  of  the processor
  speed). If your PC has enough power even with reduced processor  speed
  you can try to leave it enabled.


3. Hardware Connections


3.1. Serial Modems

  BayCom-compatible modems can  be used without  changes. In rare  cases
  there could be problems which are caused by the more stable supply  of
  power to the  modem in TFPCX  compared BayCom. In  TFPCX the TXD  line
  remains steady at approximately +12V, the BayCom solution has a  pulse
  signal on  this control  line. Therefore  the supplied  voltage to the
  modem is a little higher, the voltage on pin 7 of the TCM3105 may  not
  have the ideal  voltage anymore. In  this case a  re-adjustment of the
  voltage on  pin 7  is required  (see modem  documentation). Tip:  this
  voltage is  also very  important for  the correct  functioning of  the
  software  DCD,  you  can  use  the  Soft  DCD  indicator to adjust the
  voltage.

  Additionally there  is a  option of  connecting the  modem (e.g.  from
  DigiCom)  to  a  LPT-Port.  When  using  this, 6 data output lines are
  switched to a stable 5V which  could be used as voltage supply  to the
  modem (Use at your own risk)

  Here are the connections for the Modem-Ports

  COM-Port

  Signal   25pol.  9pol.  Meaning

  DTR      20      4      Transmit data +/- 12V
  RTS      4       7      PTT, High active, -12V=RX, +12V=TX
  CTS      5       8      Receive data
  GND      7       5      Signal ground
  TXD      2       3      +12V for BayCom-Modem

  LPT-Port

  Signal   25pol.         Meaning

  DATA1-6  2-7            constant 5V approx. for Modem
  DATA7    8              Transmit data, TTL-Level
  DATA8    9              PTT, High active, 0V=RX, 5V=TX
  BUSY     11             Receive data
  GND      18-25          Signal ground

  Modems using the  AM7911 can also  be used. You  may have to  increase
  the TXTAIL-parameter (command @TA) a little for this. At this point  I
  like to point out you need different modems for higher baudrates.


3.2. BayCom-USCC-Card

  The  connections  needed  for  the  USCC  card  can  be  found  in its
  documentation. Here  I will  only supply  the numbering  given to  the
  ports  and  the  default  setting  of  the  modem  clock  supply   and
  baudrate:

  Port  SCC  Modem-Clock    Baud  Modem

  SCC0  1A   Softclock      1200  AFSK (TCM3105)
  SCC1  1B   Softclock      1200  AFSK (AM7911)
  SCC2  2A   Disable        9600  External
  SCC3  2B   DF9IC-Modem    9600  FSK  (DF9IC)

  The second  SCC controller  (Z8530) does  not have  to be present when
  the  appropriate  channels  are  not  used,  the  first  controller is
  mandatory.  Therefore  you  can  also  use  the  9k6 USCC card (option
  -PUSCC:<Base>:<IRQ>:31).

  The following  table shows  the exact  clock source  for receive (RxC)
  and  transmit  (TxC)  and  also  the  used  encoding  mode. The column
  contains the number  to be supplied  with the -PUSCC  option, the last
  column shows the equivalent  values for the BayCom  parameters CARRIER
  and  HENNING.  Soft-DCD  and  Duplex-Operation  can  be switched on by
  means of the commands @C and @D.

  -P              RxC  TxC  Mode CARRIER HENNING

   1 Softclock    DPLL BRG  NRZI   0/1      0
   2 Hardclock    DPLL RTxC NRZI   2-4      0
   3 DF9IC-Modem  TRxC RTxC NRZ    1-4      1

  BRG   Baud rate generator \ embedded inside the
  DPLL  Digital PLL         / SCC-Controller
  RTxC                      \ Connections of the
  TRxC                      / SCC-Controller


  It looks like  some USCC cards  have timing problems  in accessing the
  data port  of the  SCC-controller. In  TFPCX v2.00  sometimes nonsense
  was  transmitted  because  of  this.  After lowering the bus-clock and
| exchange of the  SCC controllers by  original ZILOG types this problem
  could be partly eliminated. TFPCX does not send the transmit data  via
  the data port anymore, just like  BayCom does it. I hope this  problem
  is now of something of the past.


3.3.  BayCom PAR96 and PICPAR modem

  You  can  use  the  PAR96  and  PICPAR modem with TFPCX (since version
  2.21). There are some things to note:

  The PAR96  and PICPAR  modem are  connected to  one of  the LPT ports.
  TFPCX assumes a normal  LPT port is present.  On modern PC's this  can
  be an  EPP port  (Enhanced Printer  Port). TFPCX  assumes this port is
  set as if it is a normal LPT port at startup. If not TFPCX might  fail
  to communicate with the modem (I do not have information how to  setup
  the EPP port as normal printer port so I can't do it).

| There is  a particular  problem with  the PICPAR  modem.  The power to
  the PICPAR  modem is  supplied by  the LPT  port. If  the modem is not
  powered  at  the  start  of  TFPCX,  the  initialisation  by  TFPCX is
  finished before the power on  the PICPAR is stable. The  communication
  to the modem completely  fails in that case.  A way to solve  it seems
  to be lowering  the value of  the capacitors on  the power line  or to
  switch over to an external power supply.

  You must specify the correct IRQ at startup: the default IRQ is 7.  If
  you attempt to use the wrong IRQ, the communication to the modem  will
  also fail.


3.4.  YAM96 modem

  You can  use the  YAM96 modem  with TFPCX  (since version 2.71). There
  are some things to note:

  Before you can use the YAM96  modem you have to download the  software
  into the FPGA by means of the YAMINIT program you got with the  modem.
  If this  is not  done before  TFPCX starts,  TFPCX will  give an error
  message.

  The YAM96 modem is connected to one of the COM ports. TFPCX assumes  a
  normal COM port is present. When no port address is given TFPCX  tries
  to retrieve this address  from the BIOS area.  When using COM ports  3
  or  4  this  port  address  maybe  invalid.  In  that case you have to
  specify these values yourself.

  You must specify  the correct IRQ  at startup:   the default IRQ  is 4
  when using COM1 or COM3, 3 when using COM2 or COM4. If you attempt  to
  use the wrong IRQ, the communication to the modem will fail.

  Also be aware not to  use COM1 and COM3 or  COM2 and COM4 at the  same
  time. If your mouse is connected  to COM1 you should not use  COM3 for
  example.  You can use this combination however if COM3 is assigned  to
  another  IRQ  (so  in  fact  there  should be only one active COM-port
  using the IRQ at the same time).


3.5.  BPQ Ethernet
|
| You can  use BPQ ethernet  with TFPCX  (since version 2.72). There are
| some things to note:
|
| You must  load an  FTP software  packet-driver  for your ethernet card
| before loading  TFPCX. This kind of driver is usually supplied with an
| ethernet card.  Also on the Internet a lot of FTP software drivers can
| be found for a large  number of cards.  The most famous are the Crynwr
| Software packet drivers by Russell Nelson.  These drivers are  free to
| use, also the source code can be found on the Internet.
|
| TFPCX will  try to  program  the  FTP software  packet  driver  to use
| multicast ethernet  packets.  If that  fails TFPCX  will fall  back to
| use broadcast  ethernet packets.  In that  case TFPCX will print out a
| message to inform the  user about this. This BPQ driver will run at an
| equivalent speed  of approximately 19200 baud. The reason for this low
| speed is to minimise the load on the CPU, the speed can be much higher
| in theory but we  also want  CPU time for  the application and for the
| other modems that are connected. The transmitter is using the internal
| timer to start transmissions.
|
|
4. Information for Software Developers


4.1. Program-Interface

  The  communication  with  TFPCX  is  done  using a software-interrupt.
  There are  several sub-functions  which are  selected by  the value in
  register AH. Parameters are passed in the AL register when needed.  On
  return register  AX will  hold the  result or  0xFFFF when  an unknown
  sub-function  was  selected.  All  input  characters  have  to be read
  before  the  output  can  be  send  again.  TFPCX supports 2 different
  interfaces which only differ slightly.


4.1.1. TFPC-Interface

  Sub functions:

  AH = 1  Check, whether a character is available on the input

          Returns :   AX = 0  No character available on the input
                      AX = 1  Character available on the input

  AH = 2  Character input (call only if sub function 1 reported
          the availability of a character on the input)

          Returns:    AL      Character code

  AH = 3  Output a character

         Parameter:  AL      Character to output

  Three  bytes  behind  the  entry  of  the  TFPCX  interrupt  routine a
  recognition string 'N5NX' is available, which can be used to find  out
  which interrupt is used by TFPCX.


4.1.2. DRSI-Interface

| The implementation in  TFPCX is derived from SP because I didn't  have
  a description or a TNCTSR  driver myself. Therefore I could  only find
  out the  functions used  in conjunction  with SP.  It is possible that
| this interface deviates from the original TNCTSR deliver.

  Sub functions:

  AH = 0  Input of a character

          Returns :   AH = 0  No character available on input
                      AH = 1  Character available on input
                      AL      Character code (only if AH = 1)

  AH = 1  Output a character

          Parameter:  AL      Character to output

  The Interrupt-Routine starts with the following Bytes:

  0x53 0x1E 0xBB 0x?? 0x?? 0x8E 0xDB 0x84 0xE4 0x74 0x20

  You can find  out which interrupt  is used by  TFPCX by comparing  the
  start of the  interrupt routines for  vectors 0x40 till  0xff with the
  byte sequence above. The byes noted as 0x?? can have value and  should
  be  skipped  in  the  comparison.  This  method  also  works  with the
  DRSI-TNCTSR driver and is also used by SP.


4.1.3. Special Functions

  The following sub functions are extensions which only exist in  TFPCX.
  They are available for both interface methods mentions above.

  AH = 0xFB  Request number of Ports and Channels (from v2.00)

             Returns:   AL       Number of used ports (0 to 8)
|                       AH       Number of available Channels (4 to 40)

             The number of channel is defined by the option '-CH'

  AH = 0xFC  Request the send-/receive status (from v2.00)

             Returns:   AL       Receive status (Bit-Nr. = Port)
                        AH       Send status

             By using  this functions  a send/recieve  indicator can  be
             build in the terminal  program. The option '-C'  only works
             in text-mode and  the location is  fixed (which may  not be
             the  optimal  place  for  it  in the terminal program). For
             every port uses one bit of  AL and AH. Bit 0 (LSB)  belongs
             to  Port  0,  Bit  1  to  Port  1  and  so on. Something is
             recieved (DCD) or  send on the  port if the  respective bit
             is set.  During duplex-operation  both bits  can be  set at
             the  same  time.  The  Function  0xFB returns the number of
             ports, which should be indicated.

  AH = 0xFD  Request TFPCX busy status (from v1.11b)

             Returns:   AX = 0   Busy (free Buffer < 88)
                        AX = 1   not Busy

             This  sub  function  enables  the  implementation of a send
             handshake in the terminal mode.

  AH = 0xFE  Request for the TFPCX-Version (from v1.01)

             Returns:   AH = 2   Main Version Number
                        AL = 0   Lower Version Number (no BCD)

|            This sub function makes  it possible to make  a distinction
             between  TFPCX  and  TFPCR   (delivers  AX  =  0xFFFF)   or
             DRSI-TNCTSR (delivered in a test  AX = 0). You should  test
             whether 1<=AH<=20 is  true and only  in that case  conclude
             it is TFPCX. In addition  you can use this sub  function to
             check  if  an  old  TFPCX  version  is  used which does not
             support a certain function.


4.2. Format of Reports

  In this  section the  messages of  TFPCX are  presented which  deviate
  from the  TNC-Firmware. Most  deviations are  just the  addition of  a
  port  number  to  the  message.  Another  deviation has to do with the
  display of  FlexNet frames.  <Port> is  a digit  between 0  and 7. The
  <Port>: part  is only  displayed if  TFPCX is  started with the option
  '-DR',  '-DX'  or  '-DM'.  The  monitor  messages  with '-DR' are kept
  compatible to the DRSI-TNCTSR driver.

  - Link-Status

    BUSY fm <Port>:<Call> via <Digis>
    CONNECTED to <Port>:<Call> via <Digis>
    LINK RESET fm <Port>:<Call> via <Digis>
    LINK RESET to <Port>:<Call> via <Digis>
    DISCONNECTED fm <Port>:<Call> via <Digis>
    LINK FAILURE with <Port>:<Call> via <Digis>
    FRAME REJECT fm <Port>:<Call> via <Digis> (x y z)
    FRAME REJECT to <Port>:<Call> via <Digis> (x y z)

  - Monitor (with options '-DX' and '-DM')

    <Port>:CONNECT REQUEST fm <Call> via <Digis>
    <Port>:fm <Call> to <Call> via <Digis> ctl <Name> pid <Hex>

  - Monitor (with options '-DR' and TNCTSR)

    <Port>:CONNECT REQUEST fm <Call> via <Digis>
    <Port>: fm <Call> to <Call> via <Digis> ctl <Name> pid <Hex>
           ^
      extra space character

  - Response of the 'C' command if used without a parameter

    <Port>:<Call> via <Digis>

  - Monitor output when receiving FlexNet frames with header
    compression

    Format of the Monitor-header:

    <Port>:fm #<Qso> to <Call> ctl ...
    <Port>:fm <Call> to <Call> ctl SABM+ #<Qso>
    <Port>:fm <Call> to <Call> ctl UA- #<Qso>

    <Qso> = FlexNet QSO number


4.3. Extended Host-Mode

  The extended hostmode (DG3DBI) is  a compatible extension to the  'G'-
  command, which  it enables,  using a  global query-command,  to gather
  information  about  all  channels  of  the  firmware  on which data is
  pending to  be read  next. The  use of  the extended  host mode  is an
| improvement,  especially  if  you  are  using  many channels with very
  different data traffic loads: the  exchange of data between TFPCX  and
  the terminal program will be improved.

  The global  query uses  the 'G'  command on  virtual channel 255 (byte
  sequence: 0xFF 0x01 0x00  'G'). Parameters supplied with  this command
  are  ignored.  TFPCX  will  respond  with  a  0 terminated list of all
  channels,  which  have  buffered   data  (byte  sequence:  0xFF   0x01
  channel+1 ... 0x00). Channel+1 ...  is a row of channel  numbers which
  are increased by 1.

  Example:

  The channels  0 (monitor  channel), 1  and 5  have data pending. TFPCX
  responds with:

  0xFF 0x01 0x01 0x02 0x86 0x00

  The terminal program  should use this  response to read  the data from
  the indicated channels until all  data is read. When all  channels are
  empty  the  response  0xFF  0x01  0x00  will  be given on the extended
  hostmode command. On the first  global query you should check,  if the
  error  message  "INVALID  CHANNEL  NUMBER"  is  generated,  which will
  always be the case  if the extended hostmode  is not yet supported  by
  the used firmware.


4.4. Previous Versions

  Since v1.00 the following alterations have been implemented.

  v1.01

  - Pointer about unread information by means of the flashing
    square if not in hostmode (can be switched off by -NB)
  - Baseaddress of the modem-ports can set explicitly now
  - TxD-line on the modem-port (power supply to modem) kept fixed
    to +12V and switched off when unloading
  - Default TFPCX interrupt now 0xFD (previously 0xFE)
  - Version information via TFPCX interrupt (AH = 0xFE)

  v1.10

  - Transition to TheFirmware v2.3b DAMA (previously TF v2.1c)
  - Soft-DCD (Configure with command @C)
  - Send-/receive indicator in hostmode (can be switched off by -NC)
  - Delay of disk-access during send/receive as intermediate
    solution in case of problems (-ND) build in
  - Automatic increase of the SSID with connect if the same station
    is already connected
  - Internal connects possible
  - Setting of Frack in 1s- or 10ms-units (command F)
  - Unattended mode can be switched on without CTEXT,
    Error report 'NO MESSAGE AVAILABLE' removed (Command U)
  - 600 Buffer (previously 400)
  - Bug cleared, which makes unloading impossible with 486's

  v1.11

  - Command Z available again (XON/XOFF for TERM)
  - LPT-Pins DATA1-6 switched to 5V for modem powersupply

  v1.11b (unofficial)

  - Function for Send-handshake in the terminal mode via TFPCX-
    interrupt for TERM (AH = 0xFD)

  v2.00

  - Support for BayCom-USCC card and a maximum of 2 modems (maximum
    6 ports, internal 8 ports)
  - Options -PUSCC and -B extended for USCC-cards and more ports
  - Option -NC removed, the DCD-Indicator can be switched on by
    -C[xx] (optional screen attribute xx)
  - Now 20 channels (previously 10)
  - Emulation of the DRSI-TNCTSR-driver, additional software-
    interface (-DR)
  - With option -DM DRSI-compatible reports, but via old software-
    interface
  - Output of port numbers in reports
  - Parameter B, O, P, T, W, X, @C, @D, @T2, @T4 and @TA are
    separated for each port (specification <Port>:)
  - Command QRES resets TFPCX to terminal mode
  - Linklist for crossband-digipeating (command @L)
  - Statistic-Framecounter (command @ST)
  - Adjustable TXTAIL-parameter (Command @TA)
  - Command P with parameter 0-7 compatible with DRSI parameter
    request (no parameter setting)
  - Command Z removed again
  - 'dynamic' MAXFRAME removed (command O)
  - Error report during modem-operation under Microsoft-Windows (386
    Enhanced Mode)
| - Functions for the retrieval of the number of ports/channels (AH =
    0xFB) and of the send-/receive status (AH = 0xFC) via the
    software-interrupt
  - Bugs solved, which lead to buffer overflows during background
|   use and from time to time to redundant transmissions.

  v2.01

  - USCC-Sendproblems solved, through output of the transmit data via
    control-port (timing-problems on the data port on a few USCC-Cards)
  - Option -BU[nnnn] for the setting of the buffer size (minimum 400,
    default 600), -BU without parameters will allocate the maximum
    number of buffers.
  - The number of connect-channels selectable with option -CHnn (4-40
    channels, default 10)
  - Command E (Echo) back again (default 1, echo on)
  - Command @M for #BIN#-Receive, @M=0 Conversion of control-characters
    (Standard), @M=1 transport-mode (for TERM)
  - Init-File (Option -F) may contain empty lines and comments
    (by using '#' or ';'), ESC automatically created ('^' will be
    ignored), conversion of TABs to a space character.
  - Remote-Command '//Q' (when U=1 and JHOST=0)
  - Frames will be monitored, if more than 256 Buffers are Free
    (previously 64 Buffers)
  - Error reports on an attempt to operate a modem under OS/2 2.0
  - DRSI-Function 1 (character output) returns AH=0 (for compatibility
    with the TNCTSR-Driver, which reports in AH, whether characters
    are pending for input)

  v2.10

  - KISS-Mode (incl. SMACK) supported (option -PKISS, max. 4 ports)
  - Support for PA0HZP-OptoPcScc-Card (option -POSCC), clock Type 4
    (PA0HZP-Port with external Clock) and 5 (PA0HZP-Timer for 75 Hz
    timing-reference)
| - BayCom-9K6-USCC-card support (2nd SCC-Controller not activated,
    if not equipped)
  - IRQs for SCC and KISS: 2-5/7, for AT additionally: 9-12/14-15 (2=9)
  - Reports (monitor and CONNECT REQUEST) changed for the
    DRSI-Interface (Option -DR) (incompatibilities with the
    TNCTSR-driver eliminated), new option -DX for previous modified
    reports.
  - Command @PO for selective port allocation (channel can be
    connected only from the allocated port, default-port for outgoing
    connects).
  - Internal connects (loopback) can be switched off (option -NL)
  - TXTAIL (@TA) for modem and SCC set to optimal value depending on
    the baud rate and timer-accuracy (@TA=4 with 300 Baud, @TA=1
    otherwise), max. value for @TA is 6000 (255 for KISS)
  - 0 Ports, if -P not specified (No default-port anymore)
  - Option -D is applicable to the previous supplied option -P

  - With DAMA before polling also wait for expire of T1 (as TF 2.6)
  - Extended Host-Mode (DG3DBI) supported
  - Remote-Command '//Q' only with U=2 (Default)
  - @ST also clears the ERR-Counter
  - NET/ROM-Monitor removed
  - Default-Parameters F, N, P, R, T, U, @A3, @I, @T2, @T3, @T4 and @TA
    changed.

  v2.21

  - BayCom-PAR96 modem support added
  - KISS now also supports RMNC-CRC-KISS
  - BayCom-Digi-SCC card support added (only ports 0 to 3).
  - The firmware-command K (Timestamp) can be used now. You have to
    supply the -ST option at startup to use it
  - The monitor will now show FlexNet frames with header compression.
    Command M +/- can be used.
  - When using KISS, BayCom-PAR96 and PA0HZP-OptoPcScc card the
|   internal real-time clock is used for internal timers, this will
    result in a more exact time measurement (not under Windows)
  - The option -ND is removed.

  v2.70

  - Other author of the software, taken over from Rene.
  - Replacement of TF23b with TF27b. This will give:
    - Improved DAMA handling: TFPCX can now be used on DAMA connections
      again.
    - Framesammler support.
  - TNC commands in line with TF27b, some commands are not available
    anymore like '@A3', 'B' and '@M' for example.
  - When connected to a DAMA master the DCD is now ignored like in
    TFX and TheFirmware 2.7b based TNCs (with the latest TF2.7b).
  - When using the -ST option on the commandline the DOS-Time will be
|   used to initially set the clock in the TNC. This will give the real
    time to the timestamps (K command)
  - Everything I broke. This TFPCX just contains a small portion of the
    original TFPCX, I had to put all the enhancements into the TF27b
    code and may have overlooked something.
  - Changed licence condition. Due to use of TF27b code from NORD><LINK
    the ALAS is applicable again.
  - Windows95 will no longer use 'compatibility mode' after TFPCX
    has been in memory.

  v2.71

  - Added support for YAM96 modem, new -PYAMx command.
  - Added -SA option.
| - At link-setup time timer T1 (frame-acknowledge timer) did  not run,
    this is fixed now.
  - Before generating a RR response a check is done if DCD is active.
    This allows the use of much  smaller @T2 values.

| v2.72
|
| - Added -SB switch. To be used on bad links. It adds an RR+ after the
|   last I frame transmission. This increases the probability that the
|   link-partner will notice the poll since RR frames are smaller than I
|   frames and therefore more likely to be received okay.
| - Added Poll/Final bit to the last I frame transmission before
|   expecting a response from the link-partner.
| - When using DAMA slottime is fixed to 10 (100 ms) on KISS ports.
| - Corrected error which caused DAMA violations.
| - Corrected an error when using DAMA with KISS. The KISS TNC's Persist
|   value and Slottime were not being set to appropriate values for DAMA
|   operation. Fixed this.
| - New "modem": BPQ. Now you can establish a link over Ethernet using a
|   FTP software packet-driver.
| - Added a switch for frame-sammler. The framesammler in TF27b (and
|   thus TFPCX) is not safe when you link-partner uses a Maxframe of 7.
|   Default the frame-sammler is now off. To switch it on supply the -SR
|   flag. Note that if your link-partner uses a Maxframe of 7 you might
|   loose data without noticing it. For lower Maxframe values this is
|   safe.
| - Updated the documentation. Changes are annotated by a | in the first
|   column.
|
| v2.73
|
| - TFPCX 2.72 was used to test all the changes from version 2.71. TFPCX
|   2.73 consolidates all the changes and is a stable release version.
| - Removed the Poll/Final bit from the last infoframe transmission,
|   causes "bumper-QSO's" and did not help much otherwise.
|   Retained '-SB' switch
| - Updated the documentation. Changes with respect to version 2.71
|   (last stable release) are annotated by a | in the first column.
