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:ymodem [2011/07/13 21:16] – digitalmanref:ymodem [2011/07/13 22:02] (current) – digitalman
Line 1: Line 1:
-====== YMODEM ====== +====== XMODEM/YMODEM Protocol Reference ======
-XMODEM/YMODEM Protocol Reference+
  
 A compendium of documents describing the XMODEM and YMODEM File Transfer Protocols. A compendium of documents describing the XMODEM and YMODEM File Transfer Protocols.
  
-This document was originally edited and formatted (by Chuck Forsberg) 10-27-87. +This document was originally edited and formatted (by [[http://omen.com|Chuck Forsberg]]) 10-27-87.
- +
-This document ported to Wiki syntax by Rob Swindell July-13-2011. +
- +
- +
- +
-Please distribute as widely as possible. +
-Questions to Chuck Forsberg +
- +
- +
- +
- +
- +
-                               Omen Technology Inc +
-                          The High Reliability Software +
-                            17505-V Sauvie Island Road +
-                              Portland Oregon 97231 +
-                            VOICE: 503-621-3406 :VOICE +
-    Modem (TeleGodzilla): 503-621-3746 Speed 19200(Telebit PEP),2400,1200,300 +
-                              CompuServe: 70007,2304 +
-                                    GEnie: CAF +
-                        UUCP: ...!tektronix!reed!omen!caf+
  
 +This document was formatted for Wiki syntax by [[person:digital man|Rob Swindell]] on July-13-2011.
  
 ===== Tower of Babel ===== ===== Tower of Babel =====
Line 45: Line 24:
 Jeff Garbers (Crosstalk package development director) said it all: "With Jeff Garbers (Crosstalk package development director) said it all: "With
 protocols in the public domain, anyone who wants to dink around with them protocols in the public domain, anyone who wants to dink around with them
-can go ahead." [1]+can go ahead." ((Page C/12, PC-WEEK July 12, 1987))
  
 Documents containing altered examples derived from YMODEM.DOC have added Documents containing altered examples derived from YMODEM.DOC have added
Line 62: Line 41:
 ==== Definitions ==== ==== Definitions ====
  
-    ARC     ARC is a program that compresses one or more files into an archive +=== ARC === 
-            and extracts files from such archives.+ARC is a program that compresses one or more files into an archive 
 +and extracts files from such archives. 
 + 
 +=== XMODEM ===
  
-    XMODEM  refers to the file transfer etiquette introduced by Ward +XMODEM refers to the file transfer etiquette introduced by Ward 
-            Christensen's 1977 MODEM.ASM program.  The name XMODEM comes from +Christensen's 1977 MODEM.ASM program.  The name XMODEM comes from 
-            Keith Petersen's XMODEM.ASM program, an adaptation of MODEM.ASM +Keith Petersen's XMODEM.ASM program, an adaptation of MODEM.ASM 
-            for Remote CP/M (RCPM) systems.  It's also called the MODEM or +for Remote CP/M (RCPM) systems.  It's also called the MODEM or 
-            MODEM2 protocol.  Some who are unaware of MODEM7's unusual batch +MODEM2 protocol.  Some who are unaware of MODEM7's unusual batch 
-            file mode call it MODEM7.  Other aliases include "CP/M Users' +file mode call it MODEM7.  Other aliases include "CP/M Users' 
-            Group" and "TERM II FTP 3".  The name XMODEM caught on partly +Group" and "TERM II FTP 3".  The name XMODEM caught on partly 
-            because it is distinctive and partly because of media interest in +because it is distinctive and partly because of media interest in 
-            bulletin board and RCPM systems where it was accessed with an +bulletin board and RCPM systems where it was accessed with an 
-            "XMODEM" command.  This protocol is supported by every serious +"XMODEM" command.  This protocol is supported by every serious 
-            communications program because of its universality, simplicity, +communications program because of its universality, simplicity, 
-            and reasonable performance.+and reasonable performance.
  
-    XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical +=== XMODEM/CRC === 
-            Redundancy Check (CRC-16), giving modern error detection +XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical 
-            protection.+Redundancy Check (CRC-16), giving modern error detection 
 +protection.
  
-    XMODEM-1k Refers to the XMODEM/CRC protocol with 1024 byte data blocks.+=== XMODEM-1k === 
 +XMODEM-1k refers to the XMODEM/CRC protocol with 1024 byte data blocks.
  
-    YMODEM  Refers to the XMODEM/CRC (optional 1k blocks) protocol with batch +=== YMODEM === 
-            transmission as described below.  In a nutshell, YMODEM means +YMODEM refers to the XMODEM/CRC (optional 1k blocks) protocol with batch 
-            BATCH.+transmission as described below.  In a nutshell, YMODEM means 
 +BATCH.
  
-    YMODEM-g Refers to the streaming YMODEM variation described below.+=== YMODEM-g === 
 +YMODEM-g refers to the streaming YMODEM variation described below.
  
-    True YMODEM(TM) In an attempt to sort out the YMODEM Tower of Babel, Omen +=== True YMODEM(TM)=== 
-            Technology has trademarked the term True YMODEM(TM) to represent +In an attempt to sort out the YMODEM Tower of Babel, Omen 
-            the complete YMODEM protocol described in this document, including +Technology has trademarked the term True YMODEM(TM) to represent 
-            pathname, length, and modification date transmitted in block 0. +the complete YMODEM protocol described in this document, including 
-            Please contact Omen Technology about certifying programs for True +pathname, length, and modification date transmitted in block 0. 
-            YMODEM(TM) compliance.+Please contact Omen Technology about certifying programs for True 
 +YMODEM(TM) compliance.
  
-    ZMODEM  uses familiar XMODEM/CRC and YMODEM technology in a new protocol +=== ZMODEM === 
-            that provides reliability, throughput, file management, and user +ZMODEM uses familiar XMODEM/CRC and YMODEM technology in a new protocol 
-            amenities appropriate to contemporary data communications.+that provides reliability, throughput, file management, and user 
 +amenities appropriate to contemporary data communications.
  
-    ZOO     Like ARC, ZOO is a program that compresses one or more files into +=== ZOO === 
-            a "zoo archive".  ZOO supports many different operating systems +Like ARC, ZOO is a program that compresses one or more files into 
-            including Unix and VMS.+a "zoo archive".  ZOO supports many different operating systems 
 +including Unix and VMS.
                          
 ===== YMODEM Minimum Requirements ===== ===== YMODEM Minimum Requirements =====
Line 368: Line 357:
 receiver commands CRC-16. receiver commands CRC-16.
  
-              Figure 1.  XMODEM-1k Blocks+=== Figure 1: XMODEM-1k Blocks ===
  
-              SENDER                                  RECEIVER +      SENDER                                  RECEIVER 
-                                                      "s -k foo.bar" +                                              "s -k foo.bar" 
-              "foo.bar open x.x minutes" +      "foo.bar open x.x minutes" 
-                                                      C +                                              C 
-              STX 01 FE Data[1024] CRC CRC +      STX 01 FE Data[1024] CRC CRC 
-                                                      ACK +                                              ACK 
-              STX 02 FD Data[1024] CRC CRC +      STX 02 FD Data[1024] CRC CRC 
-                                                      ACK +                                              ACK 
-              STX 03 FC Data[1000] CPMEOF[24] CRC CRC +      STX 03 FC Data[1000] CPMEOF[24] CRC CRC 
-                                                      ACK +                                              ACK 
-              EOT +      EOT 
-                                                      ACK+                                              ACK
  
-              Figure 2.  Mixed 1024 and 128 byte Blocks+=== Figure 3: Mixed 1024 and 128 byte Blocks ===
  
-              SENDER                                  RECEIVER +      SENDER                                  RECEIVER 
-                                                      "s -k foo.bar" +                                              "s -k foo.bar" 
-              "foo.bar open x.x minutes" +      "foo.bar open x.x minutes" 
-                                                      C +                                              C 
-              STX 01 FE Data[1024] CRC CRC +      STX 01 FE Data[1024] CRC CRC 
-                                                      ACK +                                              ACK 
-              STX 02 FD Data[1024] CRC CRC +      STX 02 FD Data[1024] CRC CRC 
-                                                      ACK +                                              ACK 
-              SOH 03 FC Data[128] CRC CRC +      SOH 03 FC Data[128] CRC CRC 
-                                                      ACK +                                              ACK 
-              SOH 04 FB Data[100] CPMEOF[28] CRC CRC +      SOH 04 FB Data[100] CPMEOF[28] CRC CRC 
-                                                      ACK +                                              ACK 
-              EOT +      EOT 
-                                                      ACK+                                              ACK
  
 ===== YMODEM Batch File Transmission ===== ===== YMODEM Batch File Transmission =====
Line 426: Line 415:
 Only the pathname (file name) part is required for batch transfers. Only the pathname (file name) part is required for batch transfers.
  
-    To maintain upwards compatibility, all unused bytes in block 0 must be set +To maintain upwards compatibility, all unused bytes in block 0 must be set to null.
-    to null.+
  
-    Pathname The pathname (conventionally, the file name) is sent as a null +=== Pathname === 
-         terminated ASCII string.  This is the filename format used by the +The pathname (conventionally, the file name) is sent as a null 
-         handle oriented MSDOS(TM) functions and C library fopen functions. +terminated ASCII string.  This is the filename format used by the 
-         An assembly language example follows: +handle oriented MSDOS(TM) functions and C library fopen functions. 
-                                  DB      'foo.bar',0 +An assembly language example follows: 
-         No spaces are included in the pathname.  Normally only the file name +    DB      'foo.bar',0 
-         stem (no directory prefix) is transmitted unless the sender has +No spaces are included in the pathname.  Normally only the file name 
-         selected YAM's f option to send the full pathname.  The source drive +stem (no directory prefix) is transmitted unless the sender has 
-         (A:, B:, etc.) is not sent. +selected YAM's f option to send the full pathname.  The source drive 
- +(A:, B:, etc.) is not sent.
-Filename Considerations:+
  
 +== Filename Considerations ==
  
   * File names are forced to lower case unless the sending system supports upper/lower case file names.  This is a convenience for       users of systems (such as Unix) which store filenames in upper and lower case.   * File names are forced to lower case unless the sending system supports upper/lower case file names.  This is a convenience for       users of systems (such as Unix) which store filenames in upper and lower case.
Line 449: Line 437:
   *  If directories are included, they are delimited by /; i.e., "subdir/foo" is acceptable, "subdir\foo" is not.   *  If directories are included, they are delimited by /; i.e., "subdir/foo" is acceptable, "subdir\foo" is not.
  
-==== Length ====+=== Length ===
 The file length and each of the succeeding fields are optional.((Fields may not be skipped.)) The file length and each of the succeeding fields are optional.((Fields may not be skipped.))
 The length field is stored in the block as a decimal string counting The length field is stored in the block as a decimal string counting
Line 463: Line 451:
 any padding added by the sender to fill up the last block. any padding added by the sender to fill up the last block.
  
-==== Modification Date ====+=== Modification Date ===
 The mod date is optional, and the filename and length The mod date is optional, and the filename and length
 may be sent without requiring the mod date to be sent. may be sent without requiring the mod date to be sent.
Line 480: Line 468:
  
  
-==== Mode ====+=== Mode ===
 If the file mode is sent, a single space separates the file mode If the file mode is sent, a single space separates the file mode
 from the modification date.  The file mode is stored as an octal from the modification date.  The file mode is stored as an octal
Line 491: Line 479:
  
  
-==== Serial Number ====+=== Serial Number ===
 If the serial number is sent, a single space separates the If the serial number is sent, a single space separates the
 serial number from the file mode.  The serial number of the serial number from the file mode.  The serial number of the
Line 499: Line 487:
  
  
-==== Other Fields ====+=== Other Fields ===
 YMODEM was designed to allow additional header fields to be YMODEM was designed to allow additional header fields to be
 added as above without creating compatibility problems with older added as above without creating compatibility problems with older
Line 530: Line 518:
 RZSZ.ZOO should answer other questions about YMODEM batch protocol. RZSZ.ZOO should answer other questions about YMODEM batch protocol.
  
-              Figure 3.  YMODEM Batch Transmission Session+=== Figure 3: YMODEM Batch Transmission Session ===
  
-              SENDER                                  RECEIVER +      SENDER                                  RECEIVER 
-                                                      "sb foo.*<CR>" +                                              "sb foo.*<CR>" 
-              "sending in batch mode etc." +      "sending in batch mode etc." 
-                                                      C (command:rb) +                                              C (command:rb) 
-              SOH 00 FF foo.c NUL[123] CRC CRC +      SOH 00 FF foo.c NUL[123] CRC CRC 
-                                                      ACK +                                              ACK 
-                                                      C +                                              C 
-              SOH 01 FE Data[128] CRC CRC +      SOH 01 FE Data[128] CRC CRC 
-                                                      ACK +                                              ACK 
-              SOH 03 FC Data[128] CRC CRC +      SOH 03 FC Data[128] CRC CRC 
-                                                      ACK +                                              ACK 
-              SOH 04 FB Data[100] CPMEOF[28] CRC CRC +      SOH 04 FB Data[100] CPMEOF[28] CRC CRC 
-                                                      ACK +                                              ACK 
-              EOT +      EOT 
-                                                      NAK +                                              NAK 
-              EOT +      EOT 
-                                                      ACK +                                              ACK 
-                                                      C +                                              C 
-              SOH 00 FF NUL[128] CRC CRC +      SOH 00 FF NUL[128] CRC CRC 
-                                                      ACK+                                              ACK
  
-            Figure 4.  YMODEM Batch Transmission Session-1k Blocks+=== Figure 4: YMODEM Batch Transmission Session-1k Blocks ===
  
-            SENDER                                  RECEIVER +      SENDER                                  RECEIVER 
-                                                    "sb -k foo.*<CR>" +                                              "sb -k foo.*<CR>" 
-            "sending in batch mode etc." +      "sending in batch mode etc." 
-                                                    C (command:rb) +                                              C (command:rb) 
-            SOH 00 FF foo.c NUL[123] CRC CRC +      SOH 00 FF foo.c NUL[123] CRC CRC 
-                                                    ACK +                                              ACK 
-                                                    C +                                              C 
-            STX 02 FD Data[1024] CRC CRC +      STX 02 FD Data[1024] CRC CRC 
-                                                    ACK +                                              ACK 
-            SOH 03 FC Data[128] CRC CRC +      SOH 03 FC Data[128] CRC CRC 
-                                                    ACK +                                              ACK 
-            SOH 04 FB Data[100] CPMEOF[28] CRC CRC +      SOH 04 FB Data[100] CPMEOF[28] CRC CRC 
-                                                    ACK +                                              ACK 
-            EOT +      EOT 
-                                                    NAK +                                              NAK 
-            EOT +      EOT 
-                                                    ACK +                                              ACK 
-                                                    C +                                              C 
-            SOH 00 FF NUL[128] CRC CRC +      SOH 00 FF NUL[128] CRC CRC 
-                                                    ACK+                                              ACK
  
  
  
-           Figure 5.  YMODEM Filename block transmitted by sz+=== Figure 5: YMODEM Filename block transmitted by sz === 
 +<code> 
 +      -rw-r--r--  6347 Jun 17 1984 20:34 bbcsched.txt
  
-           -rw-r--r--  6347 Jun 17 1984 20:34 bbcsched.txt +      00 0100FF62 62637363 6865642E 74787400   |...bbcsched.txt.| 
- +      10 36333437 20333331 34373432 35313320   |6347 3314742513 | 
-           00 0100FF62 62637363 6865642E 74787400   |...bbcsched.txt.| +      20 31303036 34340000 00000000 00000000   |100644..........| 
-           10 36333437 20333331 34373432 35313320   |6347 3314742513 | +      30 00000000 00000000 00000000 00000000 
-           20 31303036 34340000 00000000 00000000   |100644..........| +      40 00000000 00000000 00000000 00000000 
-           30 00000000 00000000 00000000 00000000 +      50 00000000 00000000 00000000 00000000 
-           40 00000000 00000000 00000000 00000000 +      60 00000000 00000000 00000000 00000000 
-           50 00000000 00000000 00000000 00000000 +      70 00000000 00000000 00000000 00000000 
-           60 00000000 00000000 00000000 00000000 +      80 000000CA 56 
-           70 00000000 00000000 00000000 00000000 +</code> 
-           80 000000CA 56 +=== Figure 6: YMODEM Header Information and Features ====
- +
-                Figure 6.  YMODEM Header Information and Features+
  
     _____________________________________________________________     _____________________________________________________________
Line 625: Line 613:
 ===== YMODEM-g File Transmission ===== ===== YMODEM-g File Transmission =====
  
-    Developing technology is providing phone line data transmission at ever +Developing technology is providing phone line data transmission at ever 
-    higher speeds using very specialized techniques.  These high speed modems, +higher speeds using very specialized techniques.  These high speed modems, 
-    as well as session protocols such as X.PC, provide high speed, nearly +as well as session protocols such as X.PC, provide high speed, nearly 
-    error free communications at the expense of considerably increased delay +error free communications at the expense of considerably increased delay 
-    time.+time.
  
-    This delay time is moderate compared to human interactions, but it +This delay time is moderate compared to human interactions, but it 
-    cripples the throughput of most error correcting protocols.+cripples the throughput of most error correcting protocols.
  
-    The g option to YMODEM has proven effective under these circumstances. +The g option to YMODEM has proven effective under these circumstances. 
-    The g option is driven by the receiver, which initiates the batch transfer +The g option is driven by the receiver, which initiates the batch transfer 
-    by transmitting a G instead of C.  When the sender recognizes the G, it +by transmitting a G instead of C.  When the sender recognizes the G, it 
-    bypasses the usual wait for an ACK to each transmitted block, sending +bypasses the usual wait for an ACK to each transmitted block, sending 
-    succeeding blocks at full speed, subject to XOFF/XON or other flow control +succeeding blocks at full speed, subject to XOFF/XON or other flow control 
-    exerted by the medium.+exerted by the medium.
  
-    The sender expects an inital G to initiate the transmission of a +The sender expects an inital G to initiate the transmission of a 
-    particular file, and also expects an ACK on the EOT sent at the end of +particular file, and also expects an ACK on the EOT sent at the end of 
-    each file.  This synchronization allows the receiver time to open and +each file.  This synchronization allows the receiver time to open and 
-    close files as necessary.+close files as necessary.
  
-    If an error is detected in a YMODEM-g transfer, the receiver aborts the +If an error is detected in a YMODEM-g transfer, the receiver aborts the 
-    transfer with the multiple CAN abort sequence.  The ZMODEM protocol should +transfer with the multiple CAN abort sequence.  The ZMODEM protocol should 
-    be used in applications that require both streaming throughput and error +be used in applications that require both streaming throughput and error 
-    recovery.+recovery.
  
-            Figure 7.  YMODEM-g Transmission Session+=== Figure 7: YMODEM-g Transmission Session ====
  
-            SENDER                                  RECEIVER +      SENDER                                  RECEIVER 
-                                                    "sb foo.*<CR>" +                                              "sb foo.*<CR>" 
-            "sending in batch mode etc..." +      "sending in batch mode etc..." 
-                                                    G (command:rb -g) +                                              G (command:rb -g) 
-            SOH 00 FF foo.c NUL[123] CRC CRC +      SOH 00 FF foo.c NUL[123] CRC CRC 
-                                                    G +                                              G 
-            SOH 01 FE Data[128] CRC CRC +      SOH 01 FE Data[128] CRC CRC 
-            STX 02 FD Data[1024] CRC CRC +      STX 02 FD Data[1024] CRC CRC 
-            SOH 03 FC Data[128] CRC CRC +      SOH 03 FC Data[128] CRC CRC 
-            SOH 04 FB Data[100] CPMEOF[28] CRC CRC +      SOH 04 FB Data[100] CPMEOF[28] CRC CRC 
-            EOT +      EOT 
-                                                    ACK +                                              ACK 
-                                                    G +                                              G 
-            SOH 00 FF NUL[128] CRC CRC+      SOH 00 FF NUL[128] CRC CRC
  
  
Line 679: Line 667:
 ==== Definitions ==== ==== Definitions ====
  
-      <soh> 01H +  <soh> 01H 
-      <eot> 04H +  <eot> 04H 
-      <ack> 06H +  <ack> 06H 
-      <nak> 15H +  <nak> 15H 
-      <can> 18H +  <can> 18H 
-      <C>   43H+  <C>   43H
  
  
Line 711: Line 699:
   * The last block sent is no different from others, i.e.  there is no "short block".   * The last block sent is no different from others, i.e.  there is no "short block".
    
-                  Figure 8.  XMODEM Message Block Level Protocol+=== Figure 8: XMODEM Message Block Level Protocol ===
  
     Each block of the transfer looks like:     Each block of the transfer looks like:
Line 781: Line 769:
 getting garbaged.  <xx> represents the checksum byte. getting garbaged.  <xx> represents the checksum byte.
  
-                  Figure 9.  Data flow including Error Recovery+=== Figure 9: Data flow including Error Recovery ===
  
     SENDER                                  RECEIVER     SENDER                                  RECEIVER
Line 803: Line 791:
 ==== Programming Tips ==== ==== Programming Tips ====
  
-  * The character-receive subroutine should be called with a parameter specifying the number of seconds to wait.  The receiver should first call it with a time of 10, then <nak> and try again, 10 times.+1. The character-receive subroutine should be called with a parameter specifying the number of seconds to wait.  The receiver should first call it with a time of 10, then <nak> and try again, 10 times.
  
 After receiving the <soh>, the receiver should call the character After receiving the <soh>, the receiver should call the character
Line 811: Line 799:
 127 characters to be seen instead of 128. 127 characters to be seen instead of 128.
  
- +2. When the receiver wishes to <nak>, it should call a "PURGE" subroutine, to wait for the line to clear.  Recall the sender tosses   any characters in its UART buffer immediately upon completing sending a block, to ensure no glitches were mis- interpreted.
-  *  When the receiver wishes to <nak>, it should call a "PURGE" subroutine, to wait for the line to clear.  Recall the sender tosses   any characters in its UART buffer immediately upon completing sending a block, to ensure no glitches were mis- interpreted.+
  
 The most common technique is for "PURGE" to call the character The most common technique is for "PURGE" to call the character
Line 820: Line 807:
 ensuring the other end will see it. ensuring the other end will see it.
  
-   * You may wish to add code recommended by John Mahr to your character receive routine - to set an error flag if the UART shows framing         error, or overrun.  This will help catch a few more glitches - the         most common of which is a hit in the high bits of the byte in two         consecutive bytes.  The <cksum> comes out OK since counting in 1-byte         produces the same result of adding 80H + 80H as with adding 00H + 00H.+3. You may wish to add code recommended by John Mahr to your character receive routine - to set an error flag if the UART shows framing         error, or overrun.  This will help catch a few more glitches - the         most common of which is a hit in the high bits of the byte in two         consecutive bytes.  The <cksum> comes out OK since counting in 1-byte         produces the same result of adding 80H + 80H as with adding 00H + 00H.
  
 ===== XMODEM/CRC Overview ===== ===== XMODEM/CRC Overview =====
Line 848: Line 835:
 protocol. A description of this handshake is presented in section 10. protocol. A description of this handshake is presented in section 10.
  
-                Figure 10.  Message Block Level Protocol, CRC mode+=== Figure 10: Message Block Level Protocol, CRC mode ===
  
     Each block of the transfer in CRC mode looks like:     Each block of the transfer in CRC mode looks like:
Line 873: Line 860:
 block is the coefficient of X^0 in the message polynomial. block is the coefficient of X^0 in the message polynomial.
  
-               Figure 11.  Example of CRC Calculation written in C+===Figure 11: Example of CRC Calculation written in C ===
  
-    The following XMODEM crc routine is taken from "rbsb.c".  Please refer to +The following XMODEM crc routine is taken from "rbsb.c".  Please refer to 
-    the source code for these programs (contained in RZSZ.ZOO) for usage.  A +the source code for these programs (contained in RZSZ.ZOO) for usage.  A 
-    fast table driven version is also included in this file.+fast table driven version is also included in this file.
  
 +<code>
     /* update CRC */     /* update CRC */
     unsigned short     unsigned short
Line 900: Line 888:
             return crc;             return crc;
     }     }
 +</code>
 ==== CRC File Level Protocol Changes ==== ==== CRC File Level Protocol Changes ====
  
Line 931: Line 919:
  
   -  the initial <C> can be garbled or lost.   -  the initial <C> can be garbled or lost.
- 
   -  the initial <soh> can be garbled.   -  the initial <soh> can be garbled.
- 
   -  the initial <C> can be changed to a <nak>.   -  the initial <C> can be changed to a <nak>.
- 
   -  the initial <nak> from a receiver which wants to receive in checksum      can be changed to a <C>.   -  the initial <nak> from a receiver which wants to receive in checksum      can be changed to a <C>.
  
Line 969: Line 954:
 represents the checksum byte. represents the checksum byte.
  
-          Figure 12.  Data Flow: Receiver has CRC Option, Sender Doesn't+=== Figure 12: Data Flow: Receiver has CRC Option, Sender Doesn't ===
  
     SENDER                                        RECEIVER     SENDER                                        RECEIVER
Line 1001: Line 986:
 2 CRC bytes. 2 CRC bytes.
  
-               Figure 13.  Receiver and Sender Both have CRC Option+=== Figure 13: Receiver and Sender Both have CRC Option ===
  
     SENDER                                       RECEIVER     SENDER                                       RECEIVER
Line 1063: Line 1048:
  
  
-==== REVISIONS ====+===== Revisions =====
  
-  * 10-27-87 Optional fields added for number of files remaining to be sent and total number of bytes remaining to be sent. +=== 10-27-87 === 
-  * 10-18-87 Flow control discussion added to 1024 byte block descritpion, minor revisions for clarity per user comments. +Optional fields added for number of files remaining to be sent and total number of bytes remaining to be sent. 
-  * 8-03-87 Revised for clarity. +=== 10-18-87 === 
-  * 5-31-1987 emphasizes minimum requirements for YMODEM, and updates information on accessing files. +Flow control discussion added to 1024 byte block descritpion, minor revisions for clarity per user comments. 
-  * 9-11-1986 clarifies nomenclature and some minor points. +=== 8-03-87 === 
-  * The April 15 1986 edition clarifies some points concerning CRC +Revised for clarity. 
-    calculations and spaces in the header.+=== 5-31-1987 === 
 +emphasizes minimum requirements for YMODEM, and updates information on accessing files. 
 +=== 9-11-1986 === 
 +clarifies nomenclature and some minor points. 
 +=== 4-15-1986 === 
 +clarifies some points concerning CRC calculations and spaces in the header.
  
  
Line 1111: Line 1101:
 implement XMODEM, YMODEM, and ZMODEM with state of the art features and implement XMODEM, YMODEM, and ZMODEM with state of the art features and
 reliability. reliability.
- 
- 
-                                 LIST OF FIGURES 
- 
- 
-     Figure 1.  XMODEM-1k Blocks..........................................  11 
- 
-     Figure 2.  Mixed 1024 and 128 byte Blocks............................  11 
- 
-     Figure 3.  YMODEM Batch Transmission Session.........................  15 
- 
-     Figure 4.  YMODEM Batch Transmission Session-1k Blocks...............  15 
- 
-     Figure 5.  YMODEM Filename block transmitted by sz...................  16 
- 
-     Figure 6.  YMODEM Header Information and Features....................  16 
- 
-     Figure 7.  YMODEM-g Transmission Session.............................  17 
- 
-     Figure 8.  XMODEM Message Block Level Protocol.......................  19 
- 
-     Figure 9.  Data flow including Error Recovery........................  20 
- 
-    Figure 10.  Message Block Level Protocol, CRC mode....................  22 
- 
-    Figure 11.  Example of CRC Calculation written in C...................  23 
- 
-    Figure 12.  Data Flow: Receiver has CRC Option, Sender Doesn't........  25 
- 
-    Figure 13.  Receiver and Sender Both have CRC Option..................  26 
- 
  
 ===== See Also ===== ===== See Also =====
Line 1147: Line 1106:
  
 {{tag>xmodem ymodem}} {{tag>xmodem ymodem}}
 +
 +
  
  

Trace: