 ┌───────────────────────────────────────────────────────────────────────────┐ 
 │  Quick Reference         File Transfer Methods                 Protocols  │ 
 └───────────────────────────────────────────────────────────────────────────┘ 

   WILDCAT! offers a wide selection of available file transfer protocols
   internal to the software.  These protocols are what's used to allow files
   to be transmitted from the BBS to your PC.

      XMODEM/CRC  - 128 byte block size, medium efficiency
      1K-XMODEM   - 1,024 byte block size, medium efficiency
      YMODEM      - 1,024 byte block size, batch transfer capability
      YMODEM/G    - 1,024 byte block size, reliable connect required
      1K-XMODEM/G - 1,024 byte block size, reliable connect required
      ZMODEM      - Variable byte block size, crash recovery capability
      KERMIT      - 8 bit data can be transferred in 7 bit form
      ASCII       - Continuous data stream, no error checking

   Additional protocols can be added to the system and are referred to as
   EXTERNAL protocols.

┌─────────────── For Detailed Descriptions, select [C]ontinue ────────────────┐
╘═════════════════════════════════════════════════════════════════════════════╛
 ┌───────────────────────────────────────────────────────────────────────────┐ 
 │  Detailed Description    File Transfer Methods                 Protocols  │ 
 └───────────────────────────────────────────────────────────────────────────┘ 

   The file area allows movement of files between the host BBS system and
   the caller'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 preferable 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 or the most recently
   introduced correction method, V.42/V.42bis.  If a MNP connection is
   detected, WILDCAT! will add this protocol choice (as well as 1K-XMODEM/G)
   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,400 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 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 normally 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.


┌────────────────────────── End of Help Information ──────────────────────────┐
╘═════════════════════════════════════════════════════════════════════════════╛
