
                        F I L E    T R A N S F E R S

  The file area allows movement of files between @BBS@ and
  @USER@'s computer.
  Downloading is the process of moving files from the BBS to the caller,
  and uploading is moving files from the caller to the BBS.

  Data transfer can be done in a number of ways in on the BBS.  New error
  checking protocols are being added on a regular basis, and the following
  is a summary of many of those available.


  XMODEM FILE TRANSFER - The BBS supports two variations of the XMODEM
  protocol,originally developed by Ward Christensen, called XMODEM and
  XMODEM/CRC respectively.  XMODEM offers the advantage of error checking
  on a block by block basis to assure that the data sent contains no
  errors.  It does this by adding a checksum byte to the end of each 128
  byte block of data; the receiver calculates its own checksum and
  compares it to the one received.  If an error is detected in the
  transmission, XMODEM will request that WILDCAT! retransmit the block of
  data.  In addition to the above checksum comparison, XMODEM/CRC adds
  another level of error detection using a complex CYCLICAL REDUNDANCY
  CHECK algorithm.

  XMODEM and XMODEM/CRC are slow transfer protocols when compared to many
  others available.  They should only be used when your software supports
  no other protocol.  XMODEM/CRC is preferrable to XMODEM due to its
  greatly improved error checking.

  1K-XMODEM - This protocol performs exactly like regular XMODEM/CRC, but
  increases the block size to 1024 bytes, hence the name 1K.  It is
  slightly faster (on fairly clean phone lines) than regular XMODEM due to
  a smaller number of blocks being sent, and therefore fewer block checks
  being made.

  YMODEM - YMODEM is a protocol devised by Chuck Forsberg of Omen
  Technology which adds a number of enhancements to protocol based
  transfer. Block sizes are variable at 128/1024, but 1K is the usual
  size. Error checking makes use of CRC-16, accurate to 99.99%.  By
  definition, all YMODEM transfers are capable of sending multiple files
  at one request, with the file size and date included in the "header
  block" sent prior to each file.  YMODEM supports multiple file transfer
  (both down AND up) of up to 99 files with WILDCAT!.

        CAUTION: A number of communication programs incorrectly use
        the term YMODEM but actually send using 1K-XMODEM.  This
        practice is not proper and will result in a failure when
        used with a true YMODEM transfer as used by WILDCAT!.

  Use of YMODEM, if supported by a caller's software, is recommended over
  XMODEM and 1K-XMODEM for speed, reliability, and features.

  YMODEM/G - This variation of YMODEM is available only to callers making
  a "reliable" connection using a modem supporting MNP (Microcom
  Networking Protocol) or the U.S. Robotics ARQ hardware error checking.
  If a MNP connection is detected, WILDCAT! will add this protocol choice
  (as well as 1K-XMODEM/G - see below) to the available options.

  MNP is a hardware based system in which the modems perform the actual
  error checking and correction, if needed.  The software such as WILDCAT!
  and Qmodem simply send the information blindly from one system to the
  other using the protocol for block sorting information only.  For this
  reason, these two protocol choices ONLY appear if a MNP connection is
  detected at logon.

  YMODEM/G is among the fastest protocols with the exception of the newer
  versions of ZMODEM discussed below.  If you have a modem that supports
  MNP or ARQ, YMODEM/G should be your usual choice on the BBS. Connections
  using two U.S. Robotics HST modems, with ports locked at 19200 or 38400
  at both ends, results in throughput in excess of 1725 characters per
  second (equivalent of over 14,000 bps)!  YMODEM/G also supports multiple
  file transfer (both down AND up) of up to 99 files at on time.

  1K-XMODEM/G - This version of 1K-XMODEM makes use of MNP hardware error
  correction to do away with the block-by-block checking in the normal
  version.  The result is a very fast single file transfer protocol for
  use if YMODEM/G is not readily available.

  ZMODEM - This is another protocol developed by Chuck Forsberg.  It is a
  "streaming protocol", one which sends variable sized blocks of data with
  CRC-32 error checking for an accuracy of 99.9999%, but does not wait for
  an acknowledgment from the receiving computer.  The sending system
  assumes data received is OK unless a repeat request is sent for a
  specific block.  This streaming activity tends to make ZMODEM one of the
  fastest protocols available (but very slightly slower than Ymodem/G or
  1K-Xmodem/G).  ZMODEM also supports multiple file transfer capability,
  and should be considered in situations where MNP is not available, or
  another batch transfer protocol cannot be used.  Zmodem also has the
  unique capability to resume file transfers that have been aborted for
  some reason and thus only partially completed.  This is called crash
  recovery.

  KERMIT - This protocol's main claim is not speed, but rather its ability
  to interact with many types of computers from mainframes to micros.  It
  can cope with systems limited to seven-bit characters even when the data
  to be transmitted is in eight-bit form.  All characters to be sent are
  translated into standard printable characters and reconstructed on the
  receiving end.

  While not terribly efficient, it is sometimes an absolute necessity for
  data transfer involving different types of systems and terminal types.
  It is not recommended for PC to PC transfers.

  ASCII DATA CAPTURE - ASCII transfer is simply the sending of information
  as characters, and is limited to 7 bit information.  The transfer of
  files in ASCII mode can be done if your system is capable of any type of
  data capture.  ASCII transfer is limited, and some sort of error
  checking protocol is required if you intend to transfer files with
  extensions of EXE, OBJ, COM, ARC or ZIP, as well as tokenized BASIC
  programs and files containing the IBM PC special ASCII characters (ones
  with ASCII values above 128).  These files cannot be transferred in
  ASCII mode since ASCII transfer is only 7 bit and these types of files
  require the full 8 bit transfer of the data, with no translation of the
  contents of the file.

