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:zmodem [2020/11/28 16:32] – [ZMODEM Frame] Clarify HEX frames digital manref:zmodem [2021/06/29 15:34] (current) – [ZFILE FRAME FILE INFORMATION SUBPACKET] footnote about path/file names with spaces (they are in fact supported in most ZMODEM implemenations) digital man
Line 67: Line 67:
  
 ==== ZMODEM Frame ==== ==== ZMODEM Frame ====
-There 2 classes of ZMODEM Frames: +There are 2 classes of ZMODEM Frames: 
-  Hexadecimal (HEX) frames, contain only US-ASCII characters +  Hexadecimal (HEX) frames, containing only US-ASCII characters 
-  Binary (BIN16 or BIN32) frames, contain //almost// all possible 8-bit octet values+  Binary (BIN16 or BIN32) frames, containing //almost// all possible octet values
  
 === HEX Frame === === HEX Frame ===
   <frame header> [CR] LF [XON]   <frame header> [CR] LF [XON]
  
-HEX frames are terminated with an ASCII linefeed character.+HEX frames are terminated with an ASCII linefeed character. Some ZMODEM implementations send the HEX frame terminating linefeed character with the high bit set (0x8A, that's ASCII-LF with an even-parity bit set). Also, for some HEX frame types, the frame terminator may be followed by an XON (0x11) character ("transmit on" in so-called "software flow control").
  
 === Binary Frame === === Binary Frame ===
Line 82: Line 82:
  
 ==== Frame Header ==== ==== Frame Header ====
-  <frame encoding> <frame type> <frame info> <crc>+  <frame encoding> <frame type> <frame info> <checksum>
  
-**Frame Encoding** (single byte): HEX ('''B'''), BIN16 ('''A'''), or BIN32 ('''C''').\\ +**Frame Encoding** (single byte):
-All frames sent by the "receiver" must use HEX encoding.+
  
-**Frame Type** (single byte): ZDATA, ZRPOS, ZACK, ZEOF, etc.+The //Frame Encoding// is also sometimes called the "Frame Style".
  
-**Frame Info**: Up to 15 bytes (but typically 4) of frame type-specific information. Note that later claims of //16// bytes of possible frame header data include the //Frame Type// byte.+^ Style  ^  AKA   ^ Value          ^ Frame Contents                       ^ Checksum   ^ 
 +| HEX    | ZHEX   | ASCII '''B'''  | Hexadecimal/US-ASCII characters only | 16-bit CRC | 
 +| BIN16  | ZBIN   | ASCII '''A'''  | Binary                               | 16-bit CRC | 
 +| BIN32  | ZBIN32 | ASCII '''C'''  | Binary                               | 32-bit CRC | 
 + 
 +Notes: 
 +  * All frames sent by the "receiver" must use HEX encoding.  
 + 
 +**Frame Type** (single byte): 
 + 
 +^ Type     ^ Value ^ TX((from sender))^ RX((from receiver)) ^ Info    ^ Data Subpkt    ^ Notes ^ 
 +| ZRQINIT  | 0x00  |  Y                -                  | caps    | -              | Request ZRINIT from the receiver | 
 +| ZRINIT   | 0x01  |  -                Y                  | caps    | -              | Receiver Initialized | 
 +| ZSINIT   | 0x02  |  Y                -                  | flags   | Attn sequence  | Sender Initialized | 
 +| ZACK     | 0x03  |  Y                Y                  | offset  | -              | Positive Acknowledgment | 
 +| ZFILE    | 0x04  |  Y                -                  | options | File metadata  | File information (name/len/date) | 
 +| ZSKIP    | 0x05  |  -                Y                  |         | -              | Skip (don't send) this file | 
 +| ZNAK     | 0x06  |  Y                Y                  |         | -              | Negative Acknowledgment | 
 +| ZABORT   | 0x07  |  -                Y                  |         | -              | Terminate batch file transfer | 
 +| ZFIN     | 0x08  |  Y                -                  |         | -              | Terminate transfer session | 
 +| ZRPOS    | 0x09  |  -                Y                  | offset  | -              | Reposition the send offset | 
 +| ZDATA    | 0x0A  |  Y                -                  | offset  | File contents  | One or more data subpackets follow | 
 +| ZEOF     | 0x0B  |  Y                -                  | offset  | -              | End of file reached | 
 +| ZFERROR  | 0x0C  |  -                Y                  |         | -              | File I/O error | 
 +| ZCRC     | 0x0D  |  Y                Y                  | CRC-32  | -              | File CRC request/response | 
 +| ZFREECNT | 0x11  |  Y                -                  | f-space | -              | Request free disk space | 
 + 
 +**Frame Info**: Up to 15 bytes (but typically 4) of frame type-specific information.\\ 
 +Note that later claims of //16// bytes of possible frame header data include the //Frame Type// byte.
  
 **Frame Header Integrity**: The //Frame Type// and //Frame Info// are integrity-protected with either a 16-bit or 32-bit CRC (determined by the frame encoding). **Frame Header Integrity**: The //Frame Type// and //Frame Info// are integrity-protected with either a 16-bit or 32-bit CRC (determined by the frame encoding).
Line 95: Line 122:
 ==== Data Subpacket ==== ==== Data Subpacket ====
   <data> ZDLE <subpacket type> <crc>   <data> ZDLE <subpacket type> <crc>
- 
-Data Subpackets may contain up to 1024 bytes of //data// (special octet values are transposed and escaped with //ZLDE//). 
  
 **ZDLE** is the ZMODEM Data-link-escape character (''^X'', ASCII 24). **ZDLE** is the ZMODEM Data-link-escape character (''^X'', ASCII 24).
 +
 +=== Data Subpacket Length ===
 +
 +  * Data Subpackets may contain up to **1024** bytes of //data// (special octet values are transposed and escaped with //ZDLE//)
 +  * The Data Subpacket Length is also sometimes referred to as the transmit "block size"
 +  * The Data Subpacket Length can be dynamically adjusted by the sender during the transfer of a file, e.g. in response to errors reported by the receiver
 +  * Some ZMODEM implementations (e.g. "ZedZap") support a Data Subpacket Length of up to 8K (8192 bytes)
  
 === Data Subpacket Types === === Data Subpacket Types ===
 The Data Subpacket Type is encoded in a single byte. The Data Subpacket Type is encoded in a single byte.
  
-^ Type  ^ ZACK/ZRPOS expected ^ End-of-Frame ^ Meaning ^ +^ Type  ^ ZACK/ZRPOS expected ^ End-of-Frame ^ Meaning    ^ Notes 
-| ZCRCW | Yes (synchronous)   | Yes          | Wait    +| ZCRCW | Yes (synchronous)   | Yes          | Wait or Write | "ZCRCW data subpackets expect a response before the next frame is sent ... to allow the receiver to write its buffer before sending more data"      
-| ZCRCE | Only errors         | Yes          | End     | +| ZCRCE | Only errors         | Yes          | End        | "If the end of file is encountered within a frame, the frame is closed with a ZCRCE data subpacket which does not elicit a response except in case of error"     | 
-| ZCRCQ | Yes (asynchronous)  | No           | Query   +| ZCRCQ | Yes (asynchronous)  | No           | Query      | "ZCRCQ subpackets are not used if the receiver does not indicate full duplex ability with the [ZRINIT] CANFDX bit" 
-| ZCRCG | Only errors         | No           | Go      |+| ZCRCG | Only errors         | No           | Go         | "ZCRCG subpackets do not elicit a response unless an error is detected"      |
  
 === Data Subpacket Integrity ===   === Data Subpacket Integrity ===  
Line 649: Line 681:
 The pathname (conventionally, the file name) is sent as a The pathname (conventionally, the file name) is sent as a
 null terminated ASCII string.  null terminated ASCII string. 
-No spaces are included in the pathname. +No spaces are included in the pathname. ((some ZMODEM implementations support path/file names that include spaces))
  
 Filename Considerations Filename Considerations
ref/zmodem.1606609947.txt · Last modified: 2020/11/28 16:32 by digital man
Back to top
CC Attribution 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0