Synchronet v3.21e-Win32 (install) has been released (Mar-2026).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
ref:xmodem [2011/07/13 22:28] – Initial import of xmodem.doc digitalmanref:xmodem [2011/07/13 23:49] (current) – digitalman
Line 1: Line 1:
-====== Xmodem, CRC Xmodem, Wxmodem File Transfer Protocols ======+====== XMODEM, CRC XMODEM, WXMODEM File Transfer Protocols ======
  
 <code> <code>
-               Please circulate this document anyway that you see +    Please circulate this document anyway that you see 
-               fit without alteration except on the page at the +    fit without alteration except on the page at the 
-               end titled: "Notes and Comments".  It is requested +    end titled: "Notes and Comments".  It is requested 
-               that anyone using these protocols within a commer- +    that anyone using these protocols within a commer- 
-               cial product not charge for them as an option or +    cial product not charge for them as an option or 
-               surcharge, but include XMODEM and its derivations +    surcharge, but include XMODEM and its derivations 
-               as part of the basic product.+    as part of the basic product.
  
  
-                                             Peter Boswell +                                     Peter Boswell 
-                                             June 20, 1986 +                                     June 20, 1986 
-                                             People/Link email: TOPPER+                                     People/Link email: TOPPER
 </code> </code>
   
 +This document was converted to Wiki syntax by [[person:digital man|Rob Swindell]] on July-13-2011.
  
 ===== Preface ===== ===== Preface =====
Line 35: Line 35:
 Here are a few people that all of us should thank and I would especially like to recognize: Here are a few people that all of us should thank and I would especially like to recognize:
  
-=== Ward Christensen ===+  * Ward Christensen
 Ward, a true pioneer in the microcomputer Ward, a true pioneer in the microcomputer
 communications area, is the author of the original Checksum communications area, is the author of the original Checksum
 Xmodem protocol.  Thanks for reminding me to "keep it simple Xmodem protocol.  Thanks for reminding me to "keep it simple
 stupid". stupid".
- +---- 
-=== Chuck Forsberg ===+  * Chuck Forsberg
 Chuck has edited perhaps the best work on Chuck has edited perhaps the best work on
 Xmodem and has provided both YMODEM (1K Xmodem) and ZMODEM Xmodem and has provided both YMODEM (1K Xmodem) and ZMODEM
Line 47: Line 47:
 me a protocol which would deal with the X-On/X-Off problem me a protocol which would deal with the X-On/X-Off problem
 and reminding me that there is such a thing as a DLE character. and reminding me that there is such a thing as a DLE character.
- +---- 
-=== Richard (Scott) McGinnis ===+  * Richard (Scott) McGinnis
 Scott is the architect, the moving Scott is the architect, the moving
 force, for the People/Link software system.  His ideas, force, for the People/Link software system.  His ideas,
Line 54: Line 54:
 you see his visual conference program for the IBM PC! you see his visual conference program for the IBM PC!
 Thanks for showing me how to use a DLE. Thanks for showing me how to use a DLE.
- +---- 
-=== Gene Plantz ===+  * Gene Plantz
 Gene operates a major IBM PC bulletin board in Gene operates a major IBM PC bulletin board in
 the Chicago area and has been active in the National SYSOP the Chicago area and has been active in the National SYSOP
 Association.  Thanks for pushing me to do something about Association.  Thanks for pushing me to do something about
 performance. performance.
 +
 +----
  
 In a historical perspective, there seems to be a common pattern in all In a historical perspective, there seems to be a common pattern in all
Line 128: Line 130:
 this paper: this paper:
 <code> <code>
-          Name      Decimal        Hexadecimal    Description+      Name      Decimal        Hexadecimal    Description
  
-          SOH          01           H001          Start Of Header +      SOH          01           H001          Start Of Header 
-          EOT          04           H004          End Of Transmission +      EOT          04           H004          End Of Transmission 
-          ACK          06           H006          Acknowledge (positive) +      ACK          06           H006          Acknowledge (positive) 
-          DLE          16           H010          Data Link Escape +      DLE          16           H010          Data Link Escape 
-          X-On (DC1)   17           H011          Transmit On +      X-On (DC1)   17           H011          Transmit On 
-          X-Off(DC3)   19           H013          Transmit Off +      X-Off(DC3)   19           H013          Transmit Off 
-          NAK          21           H015          Negative Acknowledge +      NAK          21           H015          Negative Acknowledge 
-          SYN          22           H016          Synchronous idle +      SYN          22           H016          Synchronous idle 
-          CAN          24           H018          Cancel+      CAN          24           H018          Cancel
 </code> </code>
  
Line 148: Line 150:
 to say: to say:
  
-          "It was a quick hack I threw together, very unplanned (like +      "It was a quick hack I threw together, very unplanned (like 
-          everything I do), to satisfy a personal need to communicate +      everything I do), to satisfy a personal need to communicate 
-          with some other people.  ONLY the fact that it was done in +      with some other people.  ONLY the fact that it was done in 
-          8/77, and that I put it in the public domain immediately, +      8/77, and that I put it in the public domain immediately, 
-          made it become the standard that it is"....."People who +      made it become the standard that it is"....."People who 
-          suggest I make SIGNIFICANT changes to the protocol, such as +      suggest I make SIGNIFICANT changes to the protocol, such as 
-          'full duplex', 'multiple outstanding blocks', 'multiple +      'full duplex', 'multiple outstanding blocks', 'multiple 
-          destinations', etc etc don't understand that the incredible +      destinations', etc etc don't understand that the incredible 
-          simplicity of the protocol is one of the reasons it survived +      simplicity of the protocol is one of the reasons it survived 
-          to this day in as many machines and programs as it may be +      to this day in as many machines and programs as it may be 
-          found in!"((Ward Christensen, quoted from a message posted on CompuServe                     in 1985.  Edited by Chuck Forsberg, "X/Ymodem Protocol                         Reference", unpublished, 10/20/1985.))+      found in!" 
 +        
  
 ==== Xmodem Hardware Level Protocol ==== ==== Xmodem Hardware Level Protocol ====
Line 201: Line 204:
  
 <code> <code>
-          Transmitter                        Receiver+      Transmitter                        Receiver
  
-          [wait for one minute]         <    [NAK]+      [wait for one minute]         <    [NAK]
  
-          [begin block transmission]    >+      [begin block transmission]    >
 </code> </code>
  
Line 215: Line 218:
  
 The Xmodem Packet looks like this: The Xmodem Packet looks like this:
 +<code>
 +       [SOH] [seq] [cmpl [seq] [128 data bytes] [csum]
  
-               [SOH] [seq] [cmpl [seq] [128 data bytes] [csum]+       SOH       Start of header character (decimal 1).
  
-               SOH       Start of header character (decimal 1).+       seq       one byte sequence number which starts at 1, and 
 +                 increments by one until it reaches 255 and then 
 +                 wraps around to zero.
  
-               seq       one byte sequence number which starts at 1, and +       cmpl seq  one byte 1's complement of seq.  This can be 
-                         increments by one until it reaches 255 and then +                 calculated as cmpl = 255 - (255 and seq) or using 
-                         wraps around to zero.+                 xor as cmpl = (255 and seq) xor 255.
  
-               cmpl seq  one byte 1's complement of seq.  This can be +       data      128, 8 bit bytes of data.  Note than when sending 
-                         calculated as cmpl = 255 - (255 and seq) or using +                 CP/M and MS/DOS files a ^Z (decimal 26) must be 
-                         xor as cmpl = (255 and seq) xor 255. +                 added to then end of the file.  If the last block 
- +                 of data is less than 128 bytes, the Xmodem packet 
-               data      128, 8 bit bytes of data.  Note than when sending +                 must be padded with characters, usually ^Z's.
-                         CP/M and MS/DOS files a ^Z (decimal 26) must be +
-                         added to then end of the file.  If the last block +
-                         of data is less than 128 bytes, the Xmodem packet +
-                         must be padded with characters, usually ^Z's. +
- +
-               csum      one byte sum of all of the data bytes where any +
-                         overflow or carry is discarded immediately.  For +
-                         example, if the first 3 bytes are 255, 5 and 6 the +
-                         checksum after the first 3 bytes will be 10.+
  
 +       csum      one byte sum of all of the data bytes where any
 +                 overflow or carry is discarded immediately.  For
 +                 example, if the first 3 bytes are 255, 5 and 6 the
 +                 checksum after the first 3 bytes will be 10.
 +</code>
   
 Once Xmodem Initiation has completed, the transmitter sends the Once Xmodem Initiation has completed, the transmitter sends the
Line 260: Line 263:
 Let's look at a three block file transfer: Let's look at a three block file transfer:
 <code> <code>
-               Transmitter                                  Receiver+       Transmitter                                  Receiver
  
-                                             <<<<<          [NAK] +                                     <<<<<          [NAK] 
-               [SOH][001][255][...][csum]    >>>>> +       [SOH][001][255][...][csum]    >>>>> 
-                                             <<<<<          [ACK] +                                     <<<<<          [ACK] 
-               [SOH][002][254][...][csum]    >>>>> +       [SOH][002][254][...][csum]    >>>>> 
-                                             <<<<<          [ACK] +                                     <<<<<          [ACK] 
-               [SOH][003][253][...][csum]    >>>>> +       [SOH][003][253][...][csum]    >>>>> 
-                                             <<<<<          [ACK] +                                     <<<<<          [ACK] 
-               [EOT]                         >>>>> +       [EOT]                         >>>>> 
-                                             <<<<<          [ACK]+                                     <<<<<          [ACK]
 </code> </code>
 Seems easy, right?  And it is, until something goes wrong. Seems easy, right?  And it is, until something goes wrong.
Line 347: Line 350:
   * Once a SOH is found, assume that the next two characters                    will be a valid sequence number and complement.  If they                    are complements then assume that the packet has begun.                    If they are not complements, continue to search for a                    SOH.   * Once a SOH is found, assume that the next two characters                    will be a valid sequence number and complement.  If they                    are complements then assume that the packet has begun.                    If they are not complements, continue to search for a                    SOH.
  
-  * Send a NAK if a timeout occurs while attempting to                    re-synchronize (e.g. continue to process timeouts as +  * Send a NAK if a timeout occurs while attempting to  re-synchronize (e.g. continue to process timeouts as described above). 
-                    described above). +  * If no re-synchronization occurs within 135 characters  then send a NAK character and retry receiving the packet.
-                     +
-  * If no re-synchronization occurs within 135 characters                    then send a NAK character and retry receiving the                    packet.+
  
 === False EOT condition === === False EOT condition ===
Line 364: Line 365:
 return a NAK for the first EOT received and only assume true return a NAK for the first EOT received and only assume true
 end of transmission after receiving two EOT's. end of transmission after receiving two EOT's.
 +<code>
 +        Transmitter                   Receiver
  
-                    Transmitter                   Receiver +        [last block .. ]    >>>>> 
- +                            <<<<<     [ACK] 
-                    [last block .. ]    >>>>> +        [EOT]               >>>>> 
-                                        <<<<<     [ACK] +                            <<<<<     [NAK] 
-                    [EOT]               >>>>> +        [EOT]               >>>>> 
-                                        <<<<<     [NAK] +                            <<<<<     [ACK] 
-                    [EOT]               >>>>> +</code>
-                                        <<<<<     [ACK] +
 Just in case the transmitter was not prepared to resend the Just in case the transmitter was not prepared to resend the
 EOT, it might be wise to set the timeout to about 3 seconds EOT, it might be wise to set the timeout to about 3 seconds
Line 459: Line 460:
  
  
-===== WINDOWED XMODEM (WXMODEM) =====+===== Windowed XMODEM (WXMODEM) =====
  
 This section assumes that the reader is already familiar with Xmodem and CRC Xmodem presented above. This section assumes that the reader is already familiar with Xmodem and CRC Xmodem presented above.
Line 472: Line 473:
 A few people began discussing improvements to Xmodem with me in A few people began discussing improvements to Xmodem with me in
 late 1985, over time we developed the following criteria: late 1985, over time we developed the following criteria:
 +  - The protocol must be as similar as possible to the XMODEM originally developed by Ward Christensen. The popularity of XMODEM, I believe, is based on its conceptual simplicity.  More software writers are familiar with this protocol than any other. More files are transferred everyday by this protocol than any other asynchronous protocol. Simplicity here implies a limited number of rules for timing, error recovery and initiation.
 +  - The protocol must overcome the propagation delay that is characteristic of the public data networks.  While the cost of long distance communication is 50 to 90% less via the public data networks than via the public voice networks, the propagation delays inherent in public data networks both reduces the cost savings and increases the aggravation that occurs while watching a computer slowly perform a file transfer.
 +  - The protocol must overcome the flow control problems which are characteristic in many public data network situations.  Basically, in most situations, the X-On and X-Off characters must always be used for flow control and only for flow control when using public data networks.
 +  - The protocol should improve error recovery by simplifying the manner in which a programmer can determine the beginning of an XMODEM block.  Since the Start of Header character (SOH) can appear in the data or CRC, the programmer must use a relatively sophisticated method to determine if a SOH actually represents the beginning of a XMODEM block.
  
-  - The protocol must be as similar as possible to the +==== Transparency and Flow Control Rules (Byte Level Rules) ====
-XMODEM originally developed by Ward Christensen. +
-The popularity of XMODEM, I believe, is based on +
-its conceptual simplicity.  More software writers +
-are familiar with this protocol than any other. +
-More files are transferred everyday by this +
-protocol than any other asynchronous protocol. +
-Simplicity here implies a limited number of rules +
-for timing, error recovery and initiation.+
  
-  - The protocol must overcome the propagation delay 
-that is characteristic of the public data networks.  While the cost of long distance communication is 50 to 90% less via the public data 
-networks than via the public voice networks, the 
-propagation delays inherent in public data networks 
-both reduces the cost savings and increases the 
-aggravation that occurs while watching a computer 
-slowly perform a file transfer. 
  
-  - The protocol must overcome the flow control +This protocol provides special public data network support for 
-problems which are characteristic in many public +non-X.25 hosts and PC-Pursuit access to bulletin boards.  In order 
-data network situations.  Basically, in most +to accomplish this, the transmitter is not permitted to transmit 
-situations, the X-On and X-Off characters must +the X-On and X-Off characters in the Xmodem packets.  The reason 
-always be used for flow control and only for flow +for this restriction is simple:
-control when using public data networks.+
  
-  - The protocol should improve error recovery by +  * By the very nature of X.25 public data networks, without flow control, buffer overruns and lost data are inevitable from time to time at any baud rate.
-simplifying the manner in which a programmer can +
-determine the beginning of an XMODEM block.  Since +
-the Start of Header character (SOH) can appear in +
-the data or CRC, the programmer must use a relatively sophisticated method to determine if a SOH +
-actually represents the beginning of a XMODEM +
-block.+
  
-===== Transparency and Flow Control Rules (Byte Level Rules) =====+  * To avoid data loss public data networks must always assume that any X-Off and X-On character is a flow control character when supporting PC-Pursuit for bulletin boards and when supporting non-X.25 host systems.
  
 +Since many non-X.25 hosts, bulletin boards and communications
 +programs use X-On and X-Off as flow control characters, public
 +data networks must support those X-Off and X-On requests at the
 +point of connection where the X-Off is received by the public data
 +network.  Otherwise, as many as several hundred characters backed
 +up in the network would be transmitted by the public data network
 +before the X-Off used for flow control reached the transmitter.
 +The public data network has no way to know whether an X-On/X-Off
 +protocol or Xmodem is operational at any point in time.  Therefore
 +a Xmodem packet which contains an X-Off character and no succeeding X-On character will cause the public data network to stop
 +forwarding the ACK or NAK.
  
-          This protocol provides special public data network support for +In addition, error recovery requires sophisticated programming for 
-          non-X.25 hosts and PC-Pursuit access to bulletin boards.  In order +the receiver to determine the start of an XMODEM packet.  This 
-          to accomplish this, the transmitter is not permitted to transmit +protocol simplifies this task by dedicating a special character as 
-          the X-On and X-Off characters in the Xmodem packets.  The reason +an indicator that an XMODEM packet is about to begin.  The 
-          for this restriction is simple:+SYN (synch, decimal 22) character is used for this purpose. 
 +The presence of one or more SYN characters in a data stream always 
 +indicates that the next non SYN character is the beginning of an 
 +XMODEM packet (e.g. SOH).
  
-               By the very nature of X.25 public data networks, without +The method used here to handle these situations is through the 
-               flow control, buffer overruns and lost data are inevit- +insertion of the DLE character (H010, decimal 16, data link escape 
-               able from time to time at any baud rate.+character) as an indicator that the character following the DLE is 
 +in fact a modified DLE, SYN, X-On, or X-Off character.
  
-               To avoid data loss public data networks must always +=== Rules ===
-               assume that any X-Off and X-On character is a flow +
-               control character when supporting PC-Pursuit for +
-               bulletin boards and when supporting non-X.25 host +
-               systems.+
  
-          Since many non-X.25 hosts, bulletin boards and communications +  - Whenever an X-On, X-Off, SYN or DLE character is  about to be transmitted as any part of an actual                      XMODEM packet including the CRC, the transmitter                         will transmit instead a DLE character followed by                         the original character which has been modified by                         exclusive or'ing it with 64 to its value. 1 
-          programs use X-On and X-Off as flow control characters, public +  - The inserted DLE characters are not counted in the                         128 byte data length of the data portion of the                          XMODEM packet.  Indeed, it would be possible to                          have a packet which is physically 264 bytes in                          length because the Xmodem block sequence number                          (or its complement), all of the 128 data characters                          and two CRC characters are all either X-On, X-Off,                          SYN or DLE characters. 
-          data networks must support those X-Off and X-On requests at the +  - Neither the DLE nor the adjusted characters are                         used in the CRC calculation, rather the original                         character is always used in the CRC calculation. 
-          point of connection where the X-Off is received by the public data +  - When the receiver sees a DLE character, it does not                         count it in the XMODEM block length calculation,                         nor compute it in the CRC calculation but discards                          it and then remembers to exclusive or the next                         character with 64 and to verify that the result                         character is either a DLE, SYN, X-On or X-Off (the                         receiver will reject the packet unconditionally, if                         not one of those four characters) and then include                         the character as part of the packet. 
-          network.  Otherwise, as many as several hundred characters backed +   - Prior to transmission of a XMODEM packet, the                         transmitter will send one or more SYN characters                         (recommend two) as a positive indicator to the                          receiver of the beginning of a Xmodem packet.2 
-          up in the network would be transmitted by the public data network +  - Except for the character received after a DLE, the                         receiver will test each incoming character to see                         if it is a SYN character.  If it is, it will                         discard the character and assume that the next                         character will be another SYN or SOH.  If a SYN                          character is received in the middle of a packet,                          the receiver will NAK that packet.  The purpose of                          the SYN character is to simplify recognition of the                          beginning of a XMODEM packet by the receiver.  Once                          an out of synch condition occurs on incoming                          data, the receiver can just ignore every incoming                          character until it sees a SYN.  Existing XMODEM                          code which already properly deals with this                          situation could just always discard any SYN                          character at time of receipt with no further                          action. 
-          before the X-Off used for flow control reached the transmitter. +  - The transmitter must support flow control characters (X-On, and X-Off) during transmission of                         packets.  Upon receipt of an X-Off it will wait 10                          seconds for an X-On and will start transmission                          again after 10 seconds or an X-On is received,                          whichever occurs first.  Any extraneous X-On                          characters received by the transmitter will be                          ignored and discarded.  (Note that this does NOT                          apply to X.25 host computers which use X.25 L2 and                          L3 windows for flow control.)
-          The public data network has no way to know whether an X-On/X-Off +
-          protocol or Xmodem is operational at any point in time.  Therefore +
-          a Xmodem packet which contains an X-Off character and no succeed- +
-          ing X-On character will cause the public data network to stop +
-          forwarding the ACK or NAK.+
  
-          In addition, error recovery requires sophisticated programming for +==== Initial Handshake Rules ====
-          the receiver to determine the start of an XMODEM packet.  This +
-          protocol simplifies this task by dedicating a special character as +
-          an indicator that an XMODEM packet is about to begin.  The +
-          SYN (synch, decimal 22) character is used for this purpose. +
-          The presence of one or more SYN characters in a data stream always +
-          indicates that the next non SYN character is the beginning of an +
-          XMODEM packet (e.g. SOH).+
  
-          The method used here to handle these situations is through the 
-          insertion of the DLE character (H010, decimal 16, data link escape 
-          character) as an indicator that the character following the DLE is 
-          in fact a modified DLE, SYN, X-On, or X-Off character. 
  
-          Rules: +An initial handshake is provided to permit the receiver to 
- +indicate to the transmitter whether it can support checksum 
-               6.2.1.    Whenever an X-On, X-Off, SYN or DLE character is +Xmodem, CRC Xmodem, or Windowed Xmodem:
-                         about to be transmitted as any part of an actual +
-  +
- +
- +
- +
- +
- +
-          Xmodem, CRC Xmodem, WXmodem +
-     June 20, 1986                                                 Page 17 +
-     ---------------------------------------------------------------------- +
- +
-                         XMODEM packet including the CRC, the transmitter +
-                         will transmit instead a DLE character followed by +
-                         the original character which has been modified by +
-                         exclusive or'ing it with 64 to its value. 1 +
- +
-               6.2.2.    The inserted DLE characters are not counted in the +
-                         128 byte data length of the data portion of the +
-                         XMODEM packet.  Indeed, it would be possible to +
-                         have a packet which is physically 264 bytes in +
-                         length because the Xmodem block sequence number +
-                         (or its complement), all of the 128 data characters +
-                         and two CRC characters are all either X-On, X-Off, +
-                         SYN or DLE characters. +
- +
-               6.2.3.    Neither the DLE nor the adjusted characters are +
-                         used in the CRC calculation, rather the original +
-                         character is always used in the CRC calculation.+
  
 +  - WXMODEM - The receiver will send a character W                         (decimal 87) and wait 3 seconds for the beginning                          of a Xmodem packet.  This will be repeated 3 times                          and then the receiver will  drop down to CRC Xmodem.
 +  - CRC XMODEM - The receiver will send a character C                         (decimal 67) and wait 3 seconds for the beginning                          of a Xmodem packet.  This will be repeated 3 times                          and then the receiver will drop down to Checksum                          Xmodem.
 +  - Checksum XMODEM -  The receivers will send a NAK                         and wait up to 3 seconds for the beginning of a                          Xmodem packet.  This will be repeated 4 times and                          if no valid SOH is received, the receiver will                          abort the file transfer request.
  
-               6.2.4.    When the receiver sees a DLE character, it does not +==== Window Packet Transmission Rules ====
-                         count it in the XMODEM block length calculation, +
-                         nor compute it in the CRC calculation but discards +
-                         it and then remembers to exclusive or the next +
-                         character with 64 and to verify that the result +
-                         character is either a DLE, SYN, X-On or X-Off (the +
-                         receiver will reject the packet unconditionally, if +
-                         not one of those four characters) and then include +
-                         the character as part of the packet.+
  
-               6.2.5.    Prior to transmission of a XMODEM packet, the 
-                         transmitter will send one or more SYN characters 
-                         (recommend two) as a positive indicator to the 
-                         receiver of the beginning of a Xmodem packet.2 
  
-               6.2.6.    Except for the character received after a DLE, the +In order to overcome the propagation delays inherent with public 
-                         receiver will test each incoming character to see +data networks such as Tymnet, Telenet, Datapac, IPSS, Transpac and 
-                         if it is a SYN character.  If it is, it will +dozens more, the protocol must permit the transmitter to send more 
-                         discard the character and assume that the next +than one packet before receiving an acknowledgement from the 
-                         character will be another SYN or SOH.  If a SYN +receiver.  The number of packets that the transmitter will send 
-                         character is received in the middle of a packet, +before stopping transmission if an acknowledgement has not been 
-                         the receiver will NAK that packet.  The purpose of +received is called the "window".  WXmodem uses a window of 4 
-                         the SYN character is to simplify recognition of the +packets for several reasons.  Most importantly, it uses a single 
-                         beginning of a XMODEM packet by the receiver.  Once +set of timing rules which would deal reasonably well with a wide 
-                         an out of synch condition occurs on incoming +range of baud rates (that implied keeping the window fairly 
-                         data, the receiver can just ignore every incoming +small).  Secondly, the window sequence number is directly related 
-                         character until it sees a SYN.  Existing XMODEM +to the Xmodem packet sequence number which, hopefully, will 
-                         code which already properly deals with this +simplify implementation of windowing.
-                         situation could just always discard any SYN +
-                         character at time of receipt with no further +
-                         action.+
   
  
  
 +=== Rules ===
  
 +1. The window is always 4 Xmodem packets.  That is, the transmitter will send 4 unacknowledged packets.  Transmission will not cease and the time out                         interval will not begin until 4 unacknowledged                         packets have been transmitted.  Note that the                         window may be less than 4   Xmodem packets for short                         files or at end-of-file.
 +                         
 +2. The receiver will transmit acknowledgements in the form:
  
 +   ACK[sequence]
  
-          Xmodem, CRC Xmodem, WXmodem +The [sequence] field is an 8 bit number where the 
-     June 20, 1986                                                 Page 18 +high order or most significant 6 bits are always 
-     ----------------------------------------------------------------------+zero and the low order or least significant 2 bits 
 +are always the same as the low order 2 bits of the 
 +XMODEM block sequence number of the XMODEM packet 
 +being acknowledged (value in decimal may range 
 +from 0 to 3).
  
 +3. The receiver does not have to acknowledge every
 +packet, but must acknowledge at minimum every
 +fourth packet.  The transmitter will accept one
 +ACK[sequence] for multiple XMODEM packets.  For
 +example, after an unknown number of packets:
 +<code>
 +         Transmitter                             Receiver
  
-               6.2.7.    The transmitter must support flow control char- +         .... 
-                         acters (X-On, and X-Off) during transmission of +         .... 
-                         packets.  Upon receipt of an X-Off it will wait 10 +         .... 
-                         seconds for an X-On and will start transmission +         [Block Sequence Number H0FE] 
-                         again after 10 seconds or an X-On is received, +         [Block Sequence Number H0FF]            ACK[H002] 
-                         whichever occurs first.  Any extraneous X-On +         [Block Sequence Number H000]            ACK[H003] 
-                         characters received by the transmitter will be +         [Block Sequence Number H001] 
-                         ignored and discarded.  (Note that this does NOT +         [Block Sequence Number H002]            ACK[H001] 
-                         apply to X.25 host computers which use X.25 L2 and +         ..... 
-                         L3 windows for flow control.)+</code> 
 +Since some transmitters must close the window and 
 +cease all communications before doing disk I/O to 
 +read more data, it is suggested that acknowledgements be sent for every packet (except when the 
 +receiver can easily determine that another packet 
 +is already being received at the point in time that 
 +the ACK[sequence] is about to be sent).3
  
-          6.3. Initial Handshake Rules 
- 
-          An initial handshake is provided to permit the receiver to 
-          indicate to the transmitter whether it can support checksum 
-     Xmodem, CRC Xmodem, or Windowed Xmodem: 
- 
-               6.3.1.    WXMODEM - The receiver will send a character W 
-                         (decimal 87) and wait 3 seconds for the beginning 
-                         of a Xmodem packet.  This will be repeated 3 times 
-                         and then the receiver will drop down to CRC Xmodem. 
- 
-               6.3.2.    CRC XMODEM - The receiver will send a character C 
-                         (decimal 67) and wait 3 seconds for the beginning 
-                         of a Xmodem packet.  This will be repeated 3 times 
-                         and then the receiver will drop down to Checksum 
-                         Xmodem. 
- 
-               6.3.3.    Checksum XMODEM -  The receivers will send a NAK 
-                         and wait up to 3 seconds for the beginning of a 
-                         Xmodem packet.  This will be repeated 4 times and 
-                         if no valid SOH is received, the receiver will 
-                         abort the file transfer request. 
- 
-          6.4. Window Packet Transmission Rules 
- 
-          In order to overcome the propagation delays inherent with public 
-          data networks such as Tymnet, Telenet, Datapac, IPSS, Transpac and 
-          dozens more, the protocol must permit the transmitter to send more 
-          than one packet before receiving an acknowledgement from the 
-          receiver.  The number of packets that the transmitter will send 
-          before stopping transmission if an acknowledgement has not been 
-          received is called the "window".  WXmodem uses a window of 4 
-          packets for several reasons.  Most importantly, it uses a single 
-          set of timing rules which would deal reasonably well with a wide 
-          range of baud rates (that implied keeping the window fairly 
-          small).  Secondly, the window sequence number is directly related 
-          to the Xmodem packet sequence number which, hopefully, will 
-          simplify implementation of windowing. 
   
  
 +4. The receiver will reject a packet (request retransmission) by sending:
  
 +    NAK[sequence]
  
 +Where [sequence] is then next window sequence
 +number (between H000 and H003) after the [sequence]
 +of the last good block.  The receiver will discard
 +up to 3 Xmodem packets received after the NAK is
 +transmitted until it receives the packet with the
 +sequence number that had previously been nak'ed by
 +the receiver.  The receiver will not send a second
 +NAK until another packet with the same sequence
 +number is received which is also invalid or a
 +timeout has occurred.
  
 +5. When the transmitter receives a NAK[sequence], it
 +will complete transmission of any XMODEM block
 +currently being transmitted and then begin re-
 +transmission starting with the block which was
 +nak'ed.
  
-          Xmodem, CRC Xmodem, WXmodem +6. The receiver will discard duplicate packets but 
-     June 20, 1986                                                 Page 19 +count them in the window for purposes of deter- 
-     ----------------------------------------------------------------------+mining the maximum receive window without an ACK in 
 +response.  For example, if the receiver gets packet 
 +sequence number 127 four times in a row, it must 
 +send an ACK H003 even if the receiver has previously acked that block.
  
 +7. The timeout intervals at various points in processing are:
  
-          Rules:+  * Waiting for a character on receive, start of packet  not yet recognized:   15 seconds 
 +  * Waiting for a character on receive, start of packet has been recognized:   15 seconds 
 +  * Waiting for an Ack or Nak on transmit side after the window has closed:    15 seconds4 
 +  * Waiting for an X-On after receipt of an X-Off by the transmitter:          10 seconds
  
-               6.4.1.    The window is always 4 Xmodem packets.  That is, +8. When the transmitter times out waiting for an ACK                         or NAK when the window is closed (e.g. four blocks                         have been transmitted), the transmitter will                         retransmit the last block transmitted and wait                         again.  Only after 10 consecutive timeouts have                         occurred will the transmitter cancel the transmission.
-                         the transmitter will send 4 unacknowledged pack- +
-                         ets.  Transmission will not cease and the time out +
-                         interval will not begin until 4 unacknowledged +
-                         packets have been transmitted.  Note that the +
-                         window may be less than 4 Xmodem packets for short +
-                         files or at end-of-file.+
  
-               6.4.2.    The receiver will transmit acknowledgements in the +9. Where possible, it is recommended that the receiver                         return an ACK[sequence] for every packet or at                         least 50% of the Xmodem packets.  When the receiver                         must wait for the window to close (e.g. receive 4                         Xmodem packets without an acknowledgement),                         some performance benefit will be lost.
-                         form:+
  
-                              ACK[sequence]+If the receiver cannot overlap disk I/O and communications 
 +I/O, the receiver can temporarily stop transmission by either:
  
-                         The [sequence] field is an 8 bit number where the +  - "Closing the window" (e.g. receiving 4 blocks without sending               an ACK[sequence]) performing the disk I/O and then sending an                ACK[sequence]. 
-                         high order or most significant 6 bits are always +  - Transmitting an X-Off followed by an X-On when the receiver               is ready to resume accepting data.  Note that the receiver               should be prepared to accept data for about a 1/4 of a second               after the X-Off is sent to cover situations where satellite               propagation delay may occur.  One possible implementation               would let the computer user set the "X-Off delay time" so               that in the normal case the X-Off delay could be set to 25               milleseconds.  A sophisticated implementation might set the               initial X-Off delay at 250 milleseconds and then reduce it               based on experience during the file transfer. 
-                         zero and the low order or least significant 2 bits +  - Each approach has its advantages, but the X-Off approach will               provide the best performance in most cases especially when               using a public data network.  Note, however, that some               computers, notably the Commodore 64 and the IBM PC Jr cannot               receive communications data while writing to disk.
-                         are always the same as the low order 2 bits of the +
-                         XMODEM block sequence number of the XMODEM packet +
-                         being acknowledged (value in decimal may range +
-                         from 0 to 3). +
- +
-               6.4.3.    The receiver does not have to acknowledge every +
-                         packet, but must acknowledge at minimum every +
-                         fourth packet.  The transmitter will accept one +
-                         ACK[sequence] for multiple XMODEM packets.  For +
-                         example, after an unknown number of packets: +
- +
-                         Transmitter                             Receiver +
- +
-                         .... +
-                         .... +
-                         .... +
-                         [Block Sequence Number H0FE] +
-                         [Block Sequence Number H0FF]            ACK[H002] +
-                         [Block Sequence Number H000]            ACK[H003] +
-                         [Block Sequence Number H001] +
-                         [Block Sequence Number H002]            ACK[H001] +
-                         ..... +
- +
-                         Since some transmitters must close the window and +
-                         cease all communications before doing disk I/O to +
-                         read more data, it is suggested that acknowledge- +
-                         ments be sent for every packet (except when the +
-                         receiver can easily determine that another packet +
-                         is already being received at the point in time that +
-                         the ACK[sequence] is about to be sent).3+
  
   
 +==== Notes for X.25 Hosts ====
  
  
 +Host computer systems which utilize the X.25 protocol
 +(examples: People/Link, Delphi, CompuServe, The Source) to
 +interface with the various public data networks may send special
 +control packets which change the manner in which the network will
 +communicate with the remote personal computer, bulletin board or
 +terminal.  For the purposes of this paper, it is assumed that the
 +X.25 host can already support CRC and/or Checksum Xmodem and
 +present only the changes for WXMODEM.
  
 +  - When an X.25 Host is the transmitter, it must be                         sure to set the distant X.3 PAD parameters to                         assure that the receiver can use X-Off/X-On for                         flow control.  This is accomplished by sending a                         Q-Bit command packet to set X.3 parameter 12 to a 1                         prior to the initial handshake.  Note that if the                         receiver cannot support WXMODEM, the X.25 Host must                         send the appropriate Q-Bit packet to reset parameter 12 to a 0 before transmitting the first CRC                         or Checksum Xmodem packet.
 +  - When an X.25 Host is the receiver and in WXMODEM                         mode, it must be sure to set the distant X.3 PAD                         parameters to assure that the network will use                         X-Off/X-On for flow control between the network and                         the transmitter to prevent its buffers from                         overflowing.  This is accomplished by sending a                         Q-Bit command packet to set X.3 parameter 5 to a 1                         prior to the initial handshake.
  
- 
-          Xmodem, CRC Xmodem, WXmodem 
-     June 20, 1986                                                 Page 20 
-     ---------------------------------------------------------------------- 
- 
-               6.4.4.    The receiver will reject a packet (request re- 
-                         transmission) by sending: 
- 
-                              NAK[sequence] 
- 
-                         Where [sequence] is then next window sequence 
-                         number (between H000 and H003) after the [sequence] 
-                         of the last good block.  The receiver will discard 
-                         up to 3 Xmodem packets received after the NAK is 
-                         transmitted until it receives the packet with the 
-                         sequence number that had previously been nak'ed by 
-                         the receiver.  The receiver will not send a second 
-                         NAK until another packet with the same sequence 
-                         number is received which is also invalid or a 
-                         timeout has occurred. 
- 
-               6.4.5.    When the transmitter receives a NAK[sequence], it 
-                         will complete transmission of any XMODEM block 
-                         currently being transmitted and then begin re- 
-                         transmission starting with the block which was 
-                         nak'ed. 
- 
-               6.4.6.    The receiver will discard duplicate packets but 
-                         count them in the window for purposes of deter- 
-                         mining the maximum receive window without an ACK in 
-                         response.  For example, if the receiver gets packet 
-                         sequence number 127 four times in a row, it must 
-                         send an ACK H003 even if the receiver has previous- 
-                         ly acked that block. 
- 
-               6.4.7.    The timeout intervals at various points in process- 
-                         ing are: 
- 
-                         Waiting for a character on receive, start of packet 
-                         not yet recognized:      15 seconds 
- 
-                         Waiting for a character on receive, start of packet 
-                         has been recognized:     15 seconds 
- 
-                         Waiting for an Ack or Nak on transmit side after 
-                         the window has closed:   15 seconds4 
- 
-                         Waiting for an X-On after receipt of an X-Off by 
-                         the transmitter:         10 seconds 
- 
-               6.4.8.    When the transmitter times out waiting for an ACK 
-                         or NAK when the window is closed (e.g. four blocks 
-                         have been transmitted), the transmitter will 
-                         retransmit the last block transmitted and wait 
-                         again.  Only after 10 consecutive timeouts have 
   
  
 +===== Appendix A - CRC Calculation Rules =====
  
  
 +The purpose of this appendix is to give non-technical and non mathematical software writers a cook book approach to calculating the CRC-16
 +used in Xmodem.  We have half accomplished that goal.  The BASIC code
 +in the examples below has been tested on an IBM PC and found to work
 +effectively even at 9600 with compiled Basic.  Some BASIC languages do
 +not offer an XOR function and others do not have MKI$ and CVI functions
 +which simplified the movement of data between data types.  Someday we
 +hope to provide a Commodore C-64/C-128 implementation which simulates
 +XOR, but not today!
  
 +My thanks go to Chuck Forsberg, Joe Noonan, John Byrns and Stephen
 +Satchell.  Without their help and public domain documents, this would
 +have never been possible.
  
-          Xmodem, CRC Xmodem, WXmodem +==== IBM PC - 8088/8086 Data Structure ====
-     June 20, 1986                                                 Page 21 +
-     ----------------------------------------------------------------------+
  
-                         occurred will the transmitter cancel the trans- 
-                         mission. 
  
-               6.4.9.    Where possible, it is recommended that the receiver +The Intel 8080 and upward has a feature, convenient only to some 
-                         return an ACK[sequence] for every packet or at +electrical engineer somewhere, which places 2 byte (16) bit 
-                         least 50% of the Xmodem packets.  When the receiver +integers in BYTE REVERSE order in memory.  That is, the least 
-                         must wait for the window to close (e.g. receive 4 +significant byte is placed in memory before the most significant 
-                         Xmodem packets without an acknowledgement), +byte for integer operations.  If A$ is one byte containing the 
-                         some performance benefit will be lost.+number 52 and it is assigned to I% using the ASC function, the 
 +binary value (52) ends up in the first byte of I% and the second 
 +byte is zero. 
 +<code> 
 +                          Result
  
-          If the receiver cannot overlap disk I/O and communications +      I%=0                [x'0000'] 
-          I/O, the receiver can temporarily stop transmission by either:+      I%=1                [x'0100'] 
 +      A$="A"              [x'41'] 
 +      I%=ASC(A$)          [x'4100'] 
 +      B$=MKI$(I%)         [x'4100']  letter "A" then binary zero 
 +      I%=CVI(CHR$(0)+A$)  [x'0041'] 
 +      A$=CHR$(65)         [x'41'] 
 +</code> 
 +Once this is understood, many problems with these algorithms goes    away.
  
-               "Closing the window" (e.g. receiving 4 blocks without sending +==== BASIC Implementation of Bit Shift Method ====
-               an ACK[sequence]) performing the disk I/O and then sending an +
-               ACK[sequence].+
  
-               Transmitting an X-Off followed by an X-On when the receiver 
-               is ready to resume accepting data.  Note that the receiver 
-               should be prepared to accept data for about a 1/4 of a second 
-               after the X-Off is sent to cover situations where satellite 
-               propagation delay may occur.  One possible implementation 
-               would let the computer user set the "X-Off delay time" so 
-               that in the normal case the X-Off delay could be set to 25 
-               milleseconds.  A sophisticated implementation might set the 
-               initial X-Off delay at 250 milleseconds and then reduce it 
-               based on experience during the file transfer. 
  
-               Each approach has its advantages, but the X-Off approach will +The bit shift method here was converted from the "C" logic 
-               provide the best performance in most cases especially when +presented in Chuck Forsberg's "Xmodem/Ymodem" protocol reference 
-               using a public data network.  Note, however, that some +and from an old IBM two page reference guide that Joe Noonan 
-               computers, notably the Commodore 64 and the IBM PC Jr cannot +carries with him in his appointment calendar!
-               receive communications data while writing to disk.+
  
-  +=== Chucks' "C" code: === 
- +<code>
- +
- +
- +
- +
-          Xmodem, CRC Xmodem, WXmodem +
-     June 20, 1986                                                 Page 22 +
-     ---------------------------------------------------------------------- +
- +
-          6.5. Notes for X.25 Hosts +
- +
-          Host computer systems which utilize the X.25 protocol +
-          (examples: People/Link, Delphi, CompuServe, The Source) to +
-          interface with the various public data networks may send special +
-          control packets which change the manner in which the network will +
-          communicate with the remote personal computer, bulletin board or +
-          terminal.  For the purposes of this paper, it is assumed that the +
-          X.25 host can already support CRC and/or Checksum Xmodem and +
-          present only the changes for WXMODEM. +
- +
-               6.5.1.    When an X.25 Host is the transmitter, it must be +
-                         sure to set the distant X.3 PAD parameters to +
-                         assure that the receiver can use X-Off/X-On for +
-                         flow control.  This is accomplished by sending a +
-                         Q-Bit command packet to set X.3 parameter 12 to a 1 +
-                         prior to the initial handshake.  Note that if the +
-                         receiver cannot support WXMODEM, the X.25 Host must +
-                         send the appropriate Q-Bit packet to reset para- +
-                         meter 12 to a 0 before transmitting the first CRC +
-                         or Checksum Xmodem packet. +
- +
-               6.5.2.    When an X.25 Host is the receiver and in WXMODEM +
-                         mode, it must be sure to set the distant X.3 PAD +
-                         parameters to assure that the network will use +
-                         X-Off/X-On for flow control between the network and +
-                         the transmitter to prevent its buffers from +
-                         overflowing.  This is accomplished by sending a +
-                         Q-Bit command packet to set X.3 parameter 5 to a 1 +
-                         prior to the initial handshake. +
- +
-  +
- +
- +
- +
- +
- +
-          Xmodem, CRC Xmodem, WXmodem +
-     June 20, 1986                                                 Page 23 +
-     ---------------------------------------------------------------------- +
- +
-     7.   APPENDIX A - CRC CALCULATION RULES +
- +
-     The purpose of this appendix is to give non-technical and non mathema- +
-     tical software writers a cook book approach to calculating the CRC-16 +
-     used in Xmodem.  We have half accomplished that goal.  The BASIC code +
-     in the examples below has been tested on an IBM PC and found to work +
-     effectively even at 9600 with compiled Basic.  Some BASIC languages do +
-     not offer an XOR function and others do not have MKI$ and CVI functions +
-     which simplified the movement of data between data types.  Someday we +
-     hope to provide a Commodore C-64/C-128 implementation which simulates +
-     XOR, but not today! +
- +
-     My thanks go to Chuck Forsberg, Joe Noonan, John Byrns and Stephen +
-     Satchell.  Without their help and public domain documents, this would +
-     have never been possible. +
- +
-          7.1. IBM PC - 8088/8086 Data Structure +
- +
-          The Intel 8080 and upward has a feature, convenient only to some +
-          electrical engineer somewhere, which places 2 byte (16) bit +
-          integers in BYTE REVERSE order in memory.  That is, the least +
-          significant byte is placed in memory before the most significant +
-          byte for integer operations.  If A$ is one byte containing the +
-          number 52 and it is assigned to I% using the ASC function, the +
-          binary value (52) ends up in the first byte of I% and the second +
-          byte is zero. +
-                                   Result +
- +
-               I%=0                [x'0000'] +
-               I%=1                [x'0100'] +
-               A$="A"              [x'41'] +
-               I%=ASC(A$)          [x'4100'] +
-               B$=MKI$(I%)         [x'4100']  letter "A" then binary zero +
-               I%=CVI(CHR$(0)+A$)  [x'0041'] +
-               A$=CHR$(65)         [x'41'] +
- +
-          Once this is understood, many problems with these algorithms goes +
-          away. +
- +
-          7.2. BASIC Implementation of Bit Shift Method +
- +
-          The bit shift method here was converted from the "C" logic +
-          presented in Chuck Forsberg's "Xmodem/Ymodem" protocol reference +
-          and from an old IBM two page reference guide that Joe Noonan +
-          carries with him in his appointment calendar! +
- +
-  +
- +
- +
- +
- +
- +
-          Xmodem, CRC Xmodem, WXmodem +
-     June 20, 1986                                                 Page 24 +
-     ---------------------------------------------------------------------- +
- +
- +
-          Chucks' "C" code:+
  
      /*      /*
Line 974: Line 739:
          return (crc & 0xFFFF);          return (crc & 0xFFFF);
      }      }
 +</code>
  
-  
- 
- 
- 
- 
- 
-          Xmodem, CRC Xmodem, WXmodem 
-     June 20, 1986                                                 Page 25 
-     ---------------------------------------------------------------------- 
- 
- 
-          But in IBM PC BASIC, our implementation looks like: 
  
 +But in IBM PC BASIC, our implementation looks like:
 +<code>
      100 DEFINT A-Z 'DEFAULT IS TWO BYTE INTEGERS      100 DEFINT A-Z 'DEFAULT IS TWO BYTE INTEGERS
      2000 REM * V$ CONTAINS 133 CHARACTER COMPLETE XMODEM PACKET      2000 REM * V$ CONTAINS 133 CHARACTER COMPLETE XMODEM PACKET
Line 1014: Line 770:
      4130 CRC$=CHR$(CRCH1)+CHR$(CRCL1)      4130 CRC$=CHR$(CRCH1)+CHR$(CRCL1)
      4140 RETURN 'WHEW      4140 RETURN 'WHEW
 +</code>
  
 +That routine will execute 128 * 7 + 128 * 9 * 8 BASIC statements
 +for each Xmodem packet or 10112 statements per Xmodem packet!  It
 +will work for low baud rates in compiled BASIC, but just is too
 +much for interpretive BASIC.
  
-          That routine will execute 128 * 7 + 128 * 9 * 8 BASIC statements +==== BASIC Implementation of the Table Method ====
-          for each Xmodem packet or 10112 statements per Xmodem packet!  It +
-          will work for low baud rates in compiled BASIC, but just is too +
-          much for interpretive BASIC.+
  
-  
- 
- 
- 
- 
- 
-          Xmodem, CRC Xmodem, WXmodem 
-     June 20, 1986                                                 Page 26 
-     ---------------------------------------------------------------------- 
- 
-          7.3. BASIC Implementation of the Table Method 
- 
-          This method is based on routine M4 in Steven Satchell's paper, 
-          "Test of CRC Routines for CRC-CCITT", but has some very signifi- 
-          cant differences.  A table of 256 CRC's, originally calculated 
-          with the bit shift method is used to avoid performing the bit 
-          shift during communications.  The table contains the CRC's for 
-          each byte value from 0 to 255 when the original CRC is zero.  The 
-          result of this calculation is included in the DATA statements in 
-          the code. 
- 
-          The comments are intended to show what is logically happening 
-          rather than physically.  Because of the "byte reverse" nature of 
-          integers in the 8088, a logical shift of 8 bits to the left is a 
-          physical shift of eight bits to the right! 
  
 +This method is based on routine M4 in Steven Satchell's paper,
 +"Test of CRC Routines for CRC-CCITT", but has some very signifi-
 +cant differences.  A table of 256 CRC's, originally calculated
 +with the bit shift method is used to avoid performing the bit
 +shift during communications.  The table contains the CRC's for
 +each byte value from 0 to 255 when the original CRC is zero.  The
 +result of this calculation is included in the DATA statements in
 +the code.
  
 +The comments are intended to show what is logically happening
 +rather than physically.  Because of the "byte reverse" nature of
 +integers in the 8088, a logical shift of 8 bits to the left is a
 +physical shift of eight bits to the right!
 +<code>
      200 DEFINT A-Z  'ALL INTEGERS      200 DEFINT A-Z  'ALL INTEGERS
      210 DIM CRCTB(256)      210 DIM CRCTB(256)
Line 1081: Line 827:
      9140 DATA -9219,-13348,-1089,-5218,-25735,-29864,-17605,-21734      9140 DATA -9219,-13348,-1089,-5218,-25735,-29864,-17605,-21734
      9150 DATA 27814, 31879, 19684, 23749, 11298, 15363, 3168, 7233      9150 DATA 27814, 31879, 19684, 23749, 11298, 15363, 3168, 7233
-  
- 
- 
- 
- 
- 
-          Xmodem, CRC Xmodem, WXmodem 
-     June 20, 1986                                                 Page 27 
-     ---------------------------------------------------------------------- 
- 
      9160 DATA -4690,-625,-12820,-8755,-21206,-17141,-29336,-25271      9160 DATA -4690,-625,-12820,-8755,-21206,-17141,-29336,-25271
      9170 DATA 32407, 28342, 24277, 20212, 15891, 11826, 7761, 3696      9170 DATA 32407, 28342, 24277, 20212, 15891, 11826, 7761, 3696
Line 1110: Line 846:
      9410 DATA -4321,-194,-12451,-8324,-20581,-16454,-28711,-24584      9410 DATA -4321,-194,-12451,-8324,-20581,-16454,-28711,-24584
      9420 DATA 28183, 32310, 20053, 24180, 11923, 16050, 3793, 7920      9420 DATA 28183, 32310, 20053, 24180, 11923, 16050, 3793, 7920
 +</code>
 +This method uses 128 * 6 BASIC statements per Xmodem packet or a
 +miserly 768 BASIC statements per packet.  And, if you want, the
 +code can be tightened still more.  Unfortunately, any further
 +tightening that we could see would eliminate most of the already
 +limited readability of the code.
 +
 +===== Notes and Comments =====
  
 +Please add your notes and comments here or send them to me and I'll get
 +them added to the current copy on People/Link.
  
-          This method uses 128 * 6 BASIC statements per Xmodem packet or a +  - This was originally set up to ADD 32 to the character on transmit                    and SUBTRACT 32 on receive.  By using exclusive or with 64, the                    logic is the same on transmit and receive. 
-          miserly 768 BASIC statements per packet.  And, if you want, the +  - The use of the SYN character was added at the request of several                    people who have coded Xmodem routines and have struggled valiantly                    to improve their error recovery routines.  Peter Boswell 6/10/86 
-          code can be tightened still more.  Unfortunately, any further +  - The suggestion that ACK[sequence] be sent for every block received                    was added.          Peter Boswell       6/10/86 
-          tightening that we could see would eliminate most of the already +  - The original value for the ACK/NAK timeout was 10 seconds.  This                    was changed to 15 seconds the situation where the receiver is                    operating at 300 baud and using X-Off to stop receipt of characters                    during disk I/O.  Peter Boswell, 6/10/86
-          limited readability of the code.+
   
-     Xmodem, CRC Xmodem, WXmodem +XMODEM and its derivatives have become the primary method for file 
-     June 20, 1986                                                 Page 28 +transfer for personal computers and is a popular error recovery type 
-     ----------------------------------------------------------------------+protocol. Before learning more about Xmodem, it is important to hear 
 +what its author has to say:
  
-     8.   NOTES AND COMMENTS+      "It was a quick hack I threw together, very unplanned (like 
 +      everything I do), to satisfy a personal need to communicate 
 +      with some other people.  ONLY the fact that it was done in 
 +      8/77, and that I put it in the public domain immediately, 
 +      made it become the standard that it is"....."People who 
 +      suggest I make SIGNIFICANT changes to the protocol, such as 
 +      'full duplex', 'multiple outstanding blocks', 'multiple 
 +      destinations', etc etc don't understand that the incredible 
 +      simplicity of the protocol is one of the reasons it survived 
 +      to this day in as many machines and programs as it may be 
 +      found in!"
  
-     Please add your notes and comments here or send them to me and I'll get +Ward Christensen, quoted from a message posted on CompuServe 
-     them added to the current copy on People/Link.+in 1985.  Edited by Chuck Forsberg, "X/Ymodem Protocol 
 +Reference", unpublished, 10/20/1985.
  
-               1.   This was originally set up to ADD 32 to the character on transmit +The protocol is Asynchronous, 8 data bits, no parity bit, one stop bit. 
-                    and SUBTRACT 32 on receive.  By using exclusive or with 64, the +
-                    logic is the same on transmit and receive. +
-               2.   The use of the SYN character was added at the request of several +
-                    people who have coded Xmodem routines and have struggled valiantly +
-                    to improve their error recovery routines.  Peter Boswell 6/10/86 +
-               3.   The suggestion that ACK[sequence] be sent for every block received +
-                    was added.          Peter Boswell       6/10/86 +
-               4.   The original value for the ACK/NAK timeout was 10 seconds.  This +
-                    was changed to 15 seconds the situation where the receiver is +
-                    operating at 300 baud and using X-Off to stop receipt of characters +
-                    during disk I/O.  Peter Boswell, 6/10/86 +
-  +
-     XMODEM and its derivatives have become the primary method for file +
-     transfer for personal computers and is a popular error recovery type +
-     protocol. Before learning more about Xmodem, it is important to hear +
-     what its author has to say:+
  
-          "It was a quick hack I threw together, very unplanned (like +===== See Also ===== 
-          everything I do), to satisfy a personal need to communicate +  * [[:ref:|Reference Library]]
-          with some other people.  ONLY the fact that it was done in +
-          8/77, and that I put it in the public domain immediately, +
-          made it become the standard that it is"....."People who +
-          suggest I make SIGNIFICANT changes to the protocol, such as +
-          'full duplex', 'multiple outstanding blocks', 'multiple +
-          destinations', etc etc don't understand that the incredible +
-          simplicity of the protocol is one of the reasons it survived +
-          to this day in as many machines and programs as it may be +
-          found in!"+
  
-    Ward Christensen, quoted from a message posted on CompuServe +{{tag>xmodem}}
-    in 1985.  Edited by Chuck Forsberg, "X/Ymodem Protocol +
-    Reference", unpublished, 10/20/1985.+
  
-          The protocol is Asynchronous, 8 data bits, no parity bit, one stop 
-          bit.  
  
  
  
-===== See Also ===== 
-  * [[:ref:|Reference Library]] 
  
-{{tag>xmodem}} 
  
  

Trace: