Submitted-by: michaeli@stout.atd.ucar.edu Archive-name: xmodem/part05 #!/bin/sh # this is xmodem.05 (part 5 of xmodem) # do not concatenate these parts, unpack them in order with /bin/sh # file xmodem/ymodem.doc continued # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo 'WARNING: not restoring timestamps' fi rm -f 1231235999 $$.touch # if test ! -r _sharseq.tmp; then echo 'Please unpack part 1 first!' exit 1 fi shar_sequence=`cat _sharseq.tmp` if test "$shar_sequence" != 5; then echo "Please unpack part $shar_sequence next!" exit 1 fi if test ! -f _sharnew.tmp; then echo 'x - still skipping xmodem/ymodem.doc' else echo 'x - continuing file xmodem/ymodem.doc' sed 's/^X//' << 'SHAR_EOF' >> 'xmodem/ymodem.doc' && X upward compatibility.[4] X X If the filename block is received with a CRC or other error, a X retransmission is requested. After the filename block has been received, X it is ACK'ed if the write open is successful. If the file cannot be X opened for writing, the receiver cancels the transfer with CAN characters X as described above. X X The receiver then initiates transfer of the file contents with a "C" X character, according to the standard XMODEM/CRC protocol. X X After the file contents and XMODEM EOT have been transmitted and X acknowledged, the receiver again asks for the next pathname. X X Transmission of a null pathname terminates batch file transmission. X X Note that transmission of no files is not necessarily an error. This is X possible if none of the files requested of the sender could be opened for X reading. X X X X __________ X X 4. If, perchance, this information extends beyond 128 bytes (possible X with Unix 4.2 BSD extended file names), the block should be sent as a X 1k block as described above. X X X X X Chapter 5 XMODEM Protocol Enhancements X X X X X X X X X/YMODEM Protocol Reference June 18 1988 16 X X X X Most YMODEM receivers request CRC-16 by default. X X The Unix programs sz(1) and rz(1) included in the source code file X RZSZ.ZOO should answer other questions about YMODEM batch protocol. X X Figure 3. YMODEM Batch Transmission Session (1 file) X X SENDER RECEIVER X "sb foo.*" X "sending in batch mode etc." X C (command:rb) X SOH 00 FF foo.c NUL[123] CRC CRC X ACK X C X SOH 01 FE Data[128] CRC CRC X ACK X SOH 02 FC Data[128] CRC CRC X ACK X SOH 03 FB Data[100] CPMEOF[28] CRC CRC X ACK X EOT X NAK X EOT X ACK X C X SOH 00 FF NUL[128] CRC CRC X ACK X X Figure 7. YMODEM Header Information and Features X X _____________________________________________________________ X | Program | Length | Date | Mode | S/N | 1k-Blk | YMODEM-g | X |___________|________|______|______|_____|________|__________| X |Unix rz/sz | yes | yes | yes | no | yes | sb only | X |___________|________|______|______|_____|________|__________| X |VMS rb/sb | yes | no | no | no | yes | no | X |___________|________|______|______|_____|________|__________| X |Pro-YAM | yes | yes | no | yes | yes | yes | X |___________|________|______|______|_____|________|__________| X |CP/M YAM | no | no | no | no | yes | no | X |___________|________|______|______|_____|________|__________| X |KMD/IMP | ? | no | no | no | yes | no | X |___________|________|______|______|_____|________|__________| X X 5.1 KMD/IMP Exceptions to YMODEM X X KMD and IMP use a "CK" character sequence emitted by the receiver to X trigger the use of 1024 byte blocks as an alternative to specifying this X option to the sending program. This two character sequence generally X works well on single process micros in direct communication, provided the X programs rigorously adhere to all the XMODEM recommendations included X X X X Chapter 5 XMODEM Protocol Enhancements X X X X X X X X X/YMODEM Protocol Reference June 18 1988 17 X X X X Figure 4. YMODEM Batch Transmission Session (2 files) X X SENDER RECEIVER X "sb foo.c baz.c" X "sending in batch mode etc." X C (command:rb) X SOH 00 FF foo.c NUL[123] CRC CRC X ACK X C X SOH 01 FE Data[128] CRC CRC X ACK X SOH 02 FC Data[128] CRC CRC X ACK X SOH 03 FB Data[100] CPMEOF[28] CRC CRC X ACK X EOT X NAK X EOT X ACK X C X SOH 00 FF baz.c NUL[123] CRC CRC X ACK X C X SOH 01 FB Data[100] CPMEOF[28] CRC CRC X ACK X EOT X NAK X EOT X ACK X C X SOH 00 FF NUL[128] CRC CRC X ACK X X Figure 5. YMODEM Batch Transmission Session-1k Blocks X X SENDER RECEIVER X "sb -k foo.*" X "sending in batch mode etc." X C (command:rb) X SOH 00 FF foo.c NUL[123] CRC CRC X ACK X C X STX 01 FD Data[1024] CRC CRC X ACK X SOH 02 FC Data[128] CRC CRC X ACK X SOH 03 FB Data[100] CPMEOF[28] CRC CRC X ACK X EOT X NAK X EOT X X X X Chapter 5 XMODEM Protocol Enhancements X X X X X X X X X/YMODEM Protocol Reference June 18 1988 18 X X X X ACK X C X SOH 00 FF NUL[128] CRC CRC X ACK X X Figure 6. YMODEM Filename block transmitted by sz X X -rw-r--r-- 6347 Jun 17 1984 20:34 bbcsched.txt X X 00 0100FF62 62637363 6865642E 74787400 |...bbcsched.txt.| X 10 36333437 20333331 34373432 35313320 |6347 3314742513 | X 20 31303036 34340000 00000000 00000000 |100644..........| X 30 00000000 00000000 00000000 00000000 X 40 00000000 00000000 00000000 00000000 X 50 00000000 00000000 00000000 00000000 X 60 00000000 00000000 00000000 00000000 X 70 00000000 00000000 00000000 00000000 X 80 000000CA 56 X X herein. Programs with marginal XMODEM implementations do not fare so X well. Timesharing systems and packet switched networks can separate the X successive characters, rendering this method unreliable. X X Sending programs may detect the CK sequence if the operating enviornment X does not preclude reliable implementation. X X Instead of the standard YMODEM file length in decimal, KMD and IMP X transmit the CP/M record count in the last two bytes of the header block. X X X 6. YMODEM-g File Transmission X X Developing technology is providing phone line data transmission at ever X higher speeds using very specialized techniques. These high speed modems, X as well as session protocols such as X.PC, provide high speed, nearly X error free communications at the expense of considerably increased delay X time. X X This delay time is moderate compared to human interactions, but it X cripples the throughput of most error correcting protocols. X X The g option to YMODEM has proven effective under these circumstances. X The g option is driven by the receiver, which initiates the batch transfer X by transmitting a G instead of C. When the sender recognizes the G, it X bypasses the usual wait for an ACK to each transmitted block, sending X succeeding blocks at full speed, subject to XOFF/XON or other flow control X exerted by the medium. X X The sender expects an inital G to initiate the transmission of a X particular file, and also expects an ACK on the EOT sent at the end of X each file. This synchronization allows the receiver time to open and X X X X Chapter 6 XMODEM Protocol Enhancements X X X X X X X X X/YMODEM Protocol Reference June 18 1988 19 X X X X close files as necessary. X X If an error is detected in a YMODEM-g transfer, the receiver aborts the X transfer with the multiple CAN abort sequence. The ZMODEM protocol should X be used in applications that require both streaming throughput and error X recovery. X X Figure 8. YMODEM-g Transmission Session X X SENDER RECEIVER X "sb foo.*" X "sending in batch mode etc..." X G (command:rb -g) X SOH 00 FF foo.c NUL[123] CRC CRC X G X SOH 01 FE Data[128] CRC CRC X STX 02 FD Data[1024] CRC CRC X SOH 03 FC Data[128] CRC CRC X SOH 04 FB Data[100] CPMEOF[28] CRC CRC X EOT X ACK X G X SOH 00 FF NUL[128] CRC CRC X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Chapter 6 XMODEM Protocol Enhancements X X X X X X X X X/YMODEM Protocol Reference June 18 1988 20 X X X X 7. XMODEM PROTOCOL OVERVIEW X X 8/9/82 by Ward Christensen. X X I will maintain a master copy of this. Please pass on changes or X suggestions via CBBS/Chicago at (312) 545-8086, CBBS/CPMUG (312) 849-1132 X or by voice at (312) 849-6279. X X 7.1 Definitions X X 01H X 04H X 06H X 15H X 18H X 43H X X X 7.2 Transmission Medium Level Protocol X X Asynchronous, 8 data bits, no parity, one stop bit. X X The protocol imposes no restrictions on the contents of the data being X transmitted. No control characters are looked for in the 128-byte data X messages. Absolutely any kind of data may be sent - binary, ASCII, etc. X The protocol has not formally been adopted to a 7-bit environment for the X transmission of ASCII-only (or unpacked-hex) data , although it could be X simply by having both ends agree to AND the protocol-dependent data with X 7F hex before validating it. I specifically am referring to the checksum, X and the block numbers and their ones- complement. X X Those wishing to maintain compatibility of the CP/M file structure, i.e. X to allow modemming ASCII files to or from CP/M systems should follow this X data format: X X + ASCII tabs used (09H); tabs set every 8. X X + Lines terminated by CR/LF (0DH 0AH) X X + End-of-file indicated by ^Z, 1AH. (one or more) X X + Data is variable length, i.e. should be considered a continuous X stream of data bytes, broken into 128-byte chunks purely for the X purpose of transmission. X X + A CP/M "peculiarity": If the data ends exactly on a 128-byte X boundary, i.e. CR in 127, and LF in 128, a subsequent sector X containing the ^Z EOF character(s) is optional, but is preferred. X Some utilities or user programs still do not handle EOF without ^Zs. X X X X X X Chapter 7 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 21 X X X X + The last block sent is no different from others, i.e. there is no X "short block". X Figure 9. XMODEM Message Block Level Protocol X X Each block of the transfer looks like: X <255-blk #><--128 data bytes--> X in which: X = 01 hex X = binary number, starts at 01 increments by 1, and X wraps 0FFH to 00H (not to 01) X <255-blk #> = blk # after going thru 8080 "CMA" instr, i.e. X each bit complemented in the 8-bit block number. X Formally, this is the "ones complement". X = the sum of the data bytes only. Toss any carry. X X 7.3 File Level Protocol X X 7.3.1 Common_to_Both_Sender_and_Receiver X All errors are retried 10 times. For versions running with an operator X (i.e. NOT with XMODEM), a message is typed after 10 errors asking the X operator whether to "retry or quit". X X Some versions of the protocol use , ASCII ^X, to cancel transmission. X This was never adopted as a standard, as having a single "abort" character X makes the transmission susceptible to false termination due to an X or being corrupted into a and aborting transmission. X X The protocol may be considered "receiver driven", that is, the sender need X not automatically re-transmit, although it does in the current X implementations. X X X 7.3.2 Receive_Program_Considerations X The receiver has a 10-second timeout. It sends a every time it X times out. The receiver's first timeout, which sends a , signals the X transmitter to start. Optionally, the receiver could send a X immediately, in case the sender was ready. This would save the initial 10 X second timeout. However, the receiver MUST continue to timeout every 10 X seconds in case the sender wasn't ready. X X Once into a receiving a block, the receiver goes into a one-second timeout X for each character and the checksum. If the receiver wishes to a X block for any reason (invalid header, timeout receiving data), it must X wait for the line to clear. See "programming tips" for ideas X X Synchronizing: If a valid block number is received, it will be: 1) the X expected one, in which case everything is fine; or 2) a repeat of the X previously received block. This should be considered OK, and only X indicates that the receivers got glitched, and the sender re- X transmitted; 3) any other block number indicates a fatal loss of X synchronization, such as the rare case of the sender getting a line-glitch X X X X Chapter 7 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 22 X X X X that looked like an . Abort the transmission, sending a X X X 7.3.3 Sending_program_considerations X While waiting for transmission to begin, the sender has only a single very X long timeout, say one minute. In the current protocol, the sender has a X 10 second timeout before retrying. I suggest NOT doing this, and letting X the protocol be completely receiver-driven. This will be compatible with X existing programs. X X When the sender has no more data, it sends an , and awaits an , X resending the if it doesn't get one. Again, the protocol could be X receiver-driven, with the sender only having the high-level 1-minute X timeout to abort. X X X Here is a sample of the data flow, sending a 3-block message. It includes X the two most common line hits - a garbaged block, and an reply X getting garbaged. represents the checksum byte. X X Figure 10. Data flow including Error Recovery X X SENDER RECEIVER X times out after 10 seconds, X <--- X 01 FE -data- ---> X <--- X 02 FD -data- xx ---> (data gets line hit) X <--- X 02 FD -data- xx ---> X <--- X 03 FC -data- xx ---> X (ack gets garbaged) <--- X 03 FC -data- xx ---> X ---> X <--- X ---> X <--- X (finished) X X 7.4 Programming Tips X X + The character-receive subroutine should be called with a parameter X specifying the number of seconds to wait. The receiver should first X call it with a time of 10, then and try again, 10 times. X X After receiving the , the receiver should call the character X receive subroutine with a 1-second timeout, for the remainder of the X message and the . Since they are sent as a continuous stream, X timing out of this implies a serious like glitch that caused, say, X 127 characters to be seen instead of 128. X X X X Chapter 7 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 23 X X X X + When the receiver wishes to , it should call a "PURGE" X subroutine, to wait for the line to clear. Recall the sender tosses X any characters in its UART buffer immediately upon completing sending X a block, to ensure no glitches were mis- interpreted. X X The most common technique is for "PURGE" to call the character X receive subroutine, specifying a 1-second timeout,[1] and looping X back to PURGE until a timeout occurs. The is then sent, X ensuring the other end will see it. X X + You may wish to add code recommended by John Mahr to your character X receive routine - to set an error flag if the UART shows framing X error, or overrun. This will help catch a few more glitches - the X most common of which is a hit in the high bits of the byte in two X consecutive bytes. The comes out OK since counting in 1-byte X produces the same result of adding 80H + 80H as with adding 00H + X 00H. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X __________ X X 1. These times should be adjusted for use with timesharing systems. X X X X X Chapter 7 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 24 X X X X 8. XMODEM/CRC Overview X X Original 1/13/85 by John Byrns -- CRC option. X X Please pass on any reports of errors in this document or suggestions for X improvement to me via Ward's/CBBS at (312) 849-1132, or by voice at (312) X 885-1105. X X The CRC used in the Modem Protocol is an alternate form of block check X which provides more robust error detection than the original checksum. X Andrew S. Tanenbaum says in his book, Computer Networks, that the CRC- X CCITT used by the Modem Protocol will detect all single and double bit X errors, all errors with an odd number of bits, all burst errors of length X 16 or less, 99.997% of 17-bit error bursts, and 99.998% of 18-bit and X longer bursts.[1] X X The changes to the Modem Protocol to replace the checksum with the CRC are X straight forward. If that were all that we did we would not be able to X communicate between a program using the old checksum protocol and one X using the new CRC protocol. An initial handshake was added to solve this X problem. The handshake allows a receiving program with CRC capability to X determine whether the sending program supports the CRC option, and to X switch it to CRC mode if it does. This handshake is designed so that it X will work properly with programs which implement only the original X protocol. A description of this handshake is presented in section 10. X X Figure 11. Message Block Level Protocol, CRC mode X X Each block of the transfer in CRC mode looks like: X <255-blk #><--128 data bytes--> X in which: X = 01 hex X = binary number, starts at 01 increments by 1, and X wraps 0FFH to 00H (not to 01) X <255-blk #> = ones complement of blk #. X = byte containing the 8 hi order coefficients of the CRC. X = byte containing the 8 lo order coefficients of the CRC. X X 8.1 CRC Calculation X X 8.1.1 Formal_Definition X To calculate the 16 bit CRC the message bits are considered to be the X coefficients of a polynomial. This message polynomial is first multiplied X by X^16 and then divided by the generator polynomial (X^16 + X^12 + X^5 + X X X __________ X X 1. This reliability figure is misleading because XMODEM's critical X supervisory functions are not protected by this CRC. X X X X X Chapter 8 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 25 X X X X 1) using modulo two arithmetic. The remainder left after the division is X the desired CRC. Since a message block in the Modem Protocol is 128 bytes X or 1024 bits, the message polynomial will be of order X^1023. The hi order X bit of the first byte of the message block is the coefficient of X^1023 in X the message polynomial. The lo order bit of the last byte of the message X block is the coefficient of X^0 in the message polynomial. X X Figure 12. Example of CRC Calculation written in C X X The following XMODEM crc routine is taken from "rbsb.c". Please refer to X the source code for these programs (contained in RZSZ.ZOO) for usage. A X fast table driven version is also included in this file. X X /* update CRC */ X unsigned short X updcrc(c, crc) X register c; X register unsigned crc; X { X register count; X X for (count=8; --count>=0;) { X if (crc & 0x8000) { X crc <<= 1; X crc += (((c<<=1) & 0400) != 0); X crc ^= 0x1021; X } X else { X crc <<= 1; X crc += (((c<<=1) & 0400) != 0); X } X } X return crc; X } X X 8.2 CRC File Level Protocol Changes X X 8.2.1 Common_to_Both_Sender_and_Receiver X The only change to the File Level Protocol for the CRC option is the X initial handshake which is used to determine if both the sending and the X receiving programs support the CRC mode. All Modem Programs should support X the checksum mode for compatibility with older versions. A receiving X program that wishes to receive in CRC mode implements the mode setting X handshake by sending a in place of the initial . If the sending X program supports CRC mode it will recognize the and will set itself X into CRC mode, and respond by sending the first block as if a had X been received. If the sending program does not support CRC mode it will X not respond to the at all. After the receiver has sent the it will X wait up to 3 seconds for the that starts the first block. If it X receives a within 3 seconds it will assume the sender supports CRC X mode and will proceed with the file exchange in CRC mode. If no is X X X X Chapter 8 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 26 X X X X received within 3 seconds the receiver will switch to checksum mode, send X a , and proceed in checksum mode. If the receiver wishes to use X checksum mode it should send an initial and the sending program X should respond to the as defined in the original Modem Protocol. X After the mode has been set by the initial or the protocol X follows the original Modem Protocol and is identical whether the checksum X or CRC is being used. X X X 8.2.2 Receive_Program_Considerations X There are at least 4 things that can go wrong with the mode setting X handshake. X X 1. the initial can be garbled or lost. X X 2. the initial can be garbled. X X 3. the initial can be changed to a . X X 4. the initial from a receiver which wants to receive in checksum X can be changed to a . X X The first problem can be solved if the receiver sends a second after X it times out the first time. This process can be repeated several times. X It must not be repeated too many times before sending a and X switching to checksum mode or a sending program without CRC support may X time out and abort. Repeating the will also fix the second problem if X the sending program cooperates by responding as if a were received X instead of ignoring the extra . X X It is possible to fix problems 3 and 4 but probably not worth the trouble X since they will occur very infrequently. They could be fixed by switching X modes in either the sending or the receiving program after a large number X of successive s. This solution would risk other problems however. X X X 8.2.3 Sending_Program_Considerations X The sending program should start in the checksum mode. This will insure X compatibility with checksum only receiving programs. Anytime a is X received before the first or the sending program should set X itself into CRC mode and respond as if a were received. The sender X should respond to additional s as if they were s until the first X is received. This will assist the receiving program in determining X the correct mode when the is lost or garbled. After the first X is received the sending program should ignore s. X X X X X X X X X X Chapter 8 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 27 X X X X 8.3 Data Flow Examples with CRC Option X X Here is a data flow example for the case where the receiver requests X transmission in the CRC mode but the sender does not support the CRC X option. This example also includes various transmission errors. X represents the checksum byte. X X Figure 13. Data Flow: Receiver has CRC Option, Sender Doesn't X X SENDER RECEIVER X <--- X times out after 3 seconds, X <--- X times out after 3 seconds, X <--- X times out after 3 seconds, X <--- X times out after 3 seconds, X <--- X 01 FE -data- ---> X <--- X 02 FD -data- ---> (data gets line hit) X <--- X 02 FD -data- ---> X <--- X 03 FC -data- ---> X (ack gets garbaged) <--- X times out after 10 seconds, X <--- X 03 FC -data- ---> X <--- X ---> X <--- X X Here is a data flow example for the case where the receiver requests X transmission in the CRC mode and the sender supports the CRC option. This X example also includes various transmission errors. represents the X 2 CRC bytes. X X X X X X X X X X X X X X X X X Chapter 8 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 28 X X X X Figure 14. Receiver and Sender Both have CRC Option X X SENDER RECEIVER X <--- X 01 FE -data- ---> X <--- X 02 FD -data- ---> (data gets line hit) X <--- X 02 FD -data- ---> X <--- X 03 FC -data- ---> X (ack gets garbaged) <--- X times out after 10 seconds, X <--- X 03 FC -data- ---> X <--- X ---> X <--- X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Chapter 8 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 29 X X X X 9. MORE INFORMATION X X Please contact Omen Technology for troff source files and typeset copies X of this document. X X X 9.1 TeleGodzilla Bulletin Board X X More information may be obtained by calling TeleGodzilla at 503-621-3746. X Speed detection is automatic for 1200, 2400 and 19200(Telebit PEP) bps. X TrailBlazer modem users may issue the TeleGodzilla trailblazer command to X swith to 19200 bps once they have logged in. X X Interesting files include RZSZ.ZOO (C source code), YZMODEM.ZOO (Official X XMODEM, YMODEM, and ZMODEM protocol descriptions), ZCOMMEXE.ARC, X ZCOMMDOC.ARC, and ZCOMMHLP.ARC (PC-DOS shareware comm program with XMODEM, X True YMODEM(TM), ZMODEM, Kermit Sliding Windows, Telink, MODEM7 Batch, X script language, etc.). X X X 9.2 Unix UUCP Access X X UUCP sites can obtain the current version of this file with X uucp omen!/u/caf/public/ymodem.doc /tmp X A continually updated list of available files is stored in X /usr/spool/uucppublic/FILES. When retrieving these files with uucp, X remember that the destination directory on your system must be writeable X by anyone, or the UUCP transfer will fail. X X The following L.sys line calls TeleGodzilla (Pro-YAM in host operation). X TeleGodzilla determines the incoming speed automatically. X X In response to "Name Please:" uucico gives the Pro-YAM "link" command as a X user name. The password (Giznoid) controls access to the Xenix system X connected to the IBM PC's other serial port. Communications between X Pro-YAM and Xenix use 9600 bps; YAM converts this to the caller's speed. X X Finally, the calling uucico logs in as uucp. X X omen Any ACU 2400 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp X X X X 10. REVISIONS X X 6-18-88 Further revised for clarity. Corrected block numbering in two X examples. X 10-27-87 Optional fields added for number of files remaining to be sent X and total number of bytes remaining to be sent. X 10-18-87 Flow control discussion added to 1024 byte block descritpion, X minor revisions for clarity per user comments. X X X X Chapter 10 Xmodem Protocol Overview X X X X X X X X X/YMODEM Protocol Reference June 18 1988 30 X X X X 8-03-87 Revised for clarity. X 5-31-1987 emphasizes minimum requirements for YMODEM, and updates X information on accessing files. X 9-11-1986 clarifies nomenclature and some minor points. X The April 15 1986 edition clarifies some points concerning CRC X calculations and spaces in the header. X X X 11. YMODEM Programs X X ZCOMM, A shareware little brother to Professional-YAM, is available as X ZCOMMEXE.ARC on TeleGodzilla and other bulletin board systems. ZCOMM may X be used to test YMODEM amd ZMODEM implementations. X X Unix programs supporting YMODEM are available on TeleGodzilla in RZSZ.ZOO. X This ZOO archive includes a ZCOMM/Pro-YAM/PowerCom script ZUPL.T to upload X a bootstrap program MINIRB.C, compile it, and then upload the rest of the X files using the compiled MINIRB. Most Unix like systems are supported, X including V7, Xenix, Sys III, 4.2 BSD, SYS V, Idris, Coherent, and X Regulus. X X A version for VAX-VMS is available in VRBSB.SHQ. X X Irv Hoff has added 1k blocks and basic YMODEM batch transfers to the KMD X and IMP series programs, which replace the XMODEM and MODEM7/MDM7xx series X respectively. Overlays are available for a wide variety of CP/M systems. X X Questions about Professional-YAM communications software may be directed X to: X Chuck Forsberg X Omen Technology Inc X 17505-V Sauvie Island Road X Portland Oregon 97231 X VOICE: 503-621-3406 :VOICE X Modem: 503-621-3746 Speed: 19200(Telebit PEP),2400,1200,300 X Usenet: ...!tektronix!reed!omen!caf X CompuServe: 70007,2304 X GEnie: CAF X X Unlike ZMODEM and Kermit, XMODEM and YMODEM place obstacles in the path of X a reliable high performance implementation, evidenced by poor reliability X under stress of the industry leaders' XMODEM and YMODEM programs. Omen X Technology provides consulting and other services to those wishing to X implement XMODEM, YMODEM, and ZMODEM with state of the art features and X reliability. X X X X X X X X X X Chapter 11 Xmodem Protocol Overview X X X X X X X X X X X X CONTENTS X X X 1. TOWER OF BABEL................................................... 2 X 1.1 Definitions................................................. 2 X X 2. YMODEM MINIMUM REQUIREMENTS...................................... 4 X X 3. WHY YMODEM?...................................................... 6 X 3.1 Some Messages from the Pioneer.............................. 7 X X 4. XMODEM PROTOCOL ENHANCEMENTS..................................... 10 X 4.1 Graceful Abort.............................................. 10 X 4.2 CRC-16 Option............................................... 10 X 4.3 XMODEM-1k 1024 Byte Block................................... 11 X X 5. YMODEM Batch File Transmission................................... 13 X 5.1 KMD/IMP Exceptions to YMODEM................................ 16 X X 6. YMODEM-g File Transmission....................................... 18 X X 7. XMODEM PROTOCOL OVERVIEW......................................... 20 X 7.1 Definitions................................................. 20 X 7.2 Transmission Medium Level Protocol.......................... 20 X 7.3 File Level Protocol......................................... 21 X 7.4 Programming Tips............................................ 22 X X 8. XMODEM/CRC Overview.............................................. 24 X 8.1 CRC Calculation............................................. 24 X 8.2 CRC File Level Protocol Changes............................. 25 X 8.3 Data Flow Examples with CRC Option.......................... 27 X X 9. MORE INFORMATION................................................. 29 X 9.1 TeleGodzilla Bulletin Board................................. 29 X 9.2 Unix UUCP Access............................................ 29 X X 10. REVISIONS........................................................ 29 X X 11. YMODEM Programs.................................................. 30 X X X X X X X X X X X X X X X X - i - X X X X X X X X X X X X X X X LIST OF FIGURES X X X Figure 1. XMODEM-1k Blocks.......................................... 12 X X Figure 2. Mixed 1024 and 128 byte Blocks............................ 12 X X Figure 3. YMODEM Batch Transmission Session (1 file)................ 16 X X Figure 4. YMODEM Batch Transmission Session (2 files)............... 16 X X Figure 5. YMODEM Batch Transmission Session-1k Blocks............... 16 X X Figure 6. YMODEM Filename block transmitted by sz................... 16 X X Figure 7. YMODEM Header Information and Features.................... 16 X X Figure 8. YMODEM-g Transmission Session............................. 19 X X Figure 9. XMODEM Message Block Level Protocol....................... 21 X X Figure 10. Data flow including Error Recovery........................ 22 X X Figure 11. Message Block Level Protocol, CRC mode.................... 24 X X Figure 12. Example of CRC Calculation written in C................... 25 X X Figure 13. Data Flow: Receiver has CRC Option, Sender Doesn't........ 27 X X Figure 14. Receiver and Sender Both have CRC Option.................. 28 X X X X X X X X X X X X X X X X X X X X X X - ii - X X X X SHAR_EOF echo 'File xmodem/ymodem.doc is complete' && $shar_touch -am 0812084894 'xmodem/ymodem.doc' && chmod 0644 'xmodem/ymodem.doc' || echo 'restore of xmodem/ymodem.doc failed' shar_count="`wc -c < 'xmodem/ymodem.doc'`" test 67550 -eq "$shar_count" || echo "xmodem/ymodem.doc: original size 67550, current size $shar_count" rm -f _sharnew.tmp fi # ============= xmodem/README.vxWorks ============== if test -f 'xmodem/README.vxWorks' && test X"$1" != X"-c"; then echo 'x - skipping xmodem/README.vxWorks (File already exists)' rm -f _sharnew.tmp else > _sharnew.tmp echo 'x - extracting xmodem/README.vxWorks (Text)' sed 's/^X//' << 'SHAR_EOF' > 'xmodem/README.vxWorks' && This is version 3.10.vxW.02 Date: 8/12/94 SHAR_EOF : || echo 'restore of xmodem/README.vxWorks failed' fi echo 'End of xmodem part 5' echo 'File xmodem/README.vxWorks is continued in part 6' echo 6 > _sharseq.tmp exit 0