• ZModem

    From deon@1:103/705 to Digital Man on Tue Oct 21 17:41:58 2025
    Hey DM,

    Hoping you can help clarify something for me. I'm playing with zmodem source code.

    In a ZFILE frame, there are 4 bytes used for "flags", and I thought they were used as bits?

    For ZF0, google AI certainly told me they were bits, but suggested that they are:
    Bit 0: LSZ_CONVBIN (Transfer in binary)
    Bit 1: LSZ_CONVCNL (convert new lines)
    BIt 2: LSZ_CONVRECOV (resume transfers).

    However, looking at some old code, I see that the header files had them recorded as 0x01, 0x02, and 0x03 respectively, and the code I was looking at was setting ZF0 with

    ls_txHdr[LSZ_F0] = LSZ_CONVBIN [pipe] LSZ_CONVRECOV when sending a file.

    which doesnt make sense having 0x01 [pipe] 0x03, which equals 3, and bit 0 and 1 are on (not bit 2).

    So I went to google AI to help me understand, and it infact came back a similiar explaination (indicating ZF0 CONVRECOV is 0x03).

    So I looked at your zmodem code, and I see that you just set ZF0 to just 0x01.

    So is this a bug in the code I'm referencing? ie: LSZ_CONVRECOV should actually be 0x04 do you know, or are the flags actually treated as values?

    Secondly, when looking at your code I was confused on how you are setting ZF1. It seems it could end up as either ZF1_ZMPROT 0x07, or ZM1_ZMCLOB 0x04 or ZF1_ZMNEW 0x05 or ZF1_ZMCRC 0x02. IE: also "values".

    The Google AI explanation for ZF1 is that it bit has a different purpose.
    0x1 - make new name (ok that lines up when used with 0x04 and you have 0x05), but
    0x2 - modify an existing file, and
    0x4 - protect and existing file
    0x8 - clobber a file.

    So your definitions for 0x02 and 0x04 differ, and makes no reference to a CRC bit.

    Any of this make sense? Is the difference due to implementation or version or something else I havent discovered yet?


    ...ëîåï

    ---
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Oct 21 00:38:23 2025
    Re: ZModem
    By: deon to Digital Man on Tue Oct 21 2025 05:41 pm

    Hey DM,

    Hoping you can help clarify something for me. I'm playing with zmodem source code.

    In a ZFILE frame, there are 4 bytes used for "flags", and I thought they were used as bits?

    Flags (aka bit-flags) and bits are the same thing really. Those bits are used to specify options. Chuck could've defined any special combination of those bits to mean whatever you liked. :-)

    For ZF0, google AI certainly told me they were bits, but suggested that they are:
    Bit 0: LSZ_CONVBIN (Transfer in binary)
    Bit 1: LSZ_CONVCNL (convert new lines)
    BIt 2: LSZ_CONVRECOV (resume transfers).

    Chuck's zmodem.h has these definitions for ZFILE's ZF0:

    /* Parameters for ZFILE frame */
    /* Conversion options one of these in ZF0 */
    #define ZCBIN 1 /* Binary transfer - inhibit conversion */
    #define ZCNL 2 /* Convert NL to local end of line convention */ #define ZCRESUM 3 /* Resume interrupted file transfer */

    So that'd be:
    Bit 0: Binary transfer
    Bit 1: Convert news lines
    Bit 0 and 1: Resume interrupted file transfer

    Which I guess in that case means it's an 8-bit enumeration/integer, not a set of bit-flags.

    However, looking at some old code, I see that the header files had them recorded as 0x01, 0x02, and 0x03 respectively,

    and the code I was looking at was setting ZF0 with

    ls_txHdr[LSZ_F0] = LSZ_CONVBIN [pipe] LSZ_CONVRECOV when sending a file.

    which doesnt make sense having 0x01 [pipe] 0x03, which equals 3, and bit 0 and 1 are on (not bit 2).

    I agree: probably just want to set it to LSZ_CONVBIN.

    So I went to google AI to help me understand, and it infact came back a similiar explaination (indicating ZF0 CONVRECOV is 0x03).

    So I looked at your zmodem code, and I see that you just set ZF0 to just 0x01.

    So is this a bug in the code I'm referencing? ie: LSZ_CONVRECOV should actually be 0x04 do you know, or are the flags actually treated as values?

    It depends on the frame and (probably) which flag byte.

    Secondly, when looking at your code I was confused on how you are setting ZF1. It seems it could end up as either ZF1_ZMPROT 0x07, or ZM1_ZMCLOB 0x04 or ZF1_ZMNEW 0x05 or ZF1_ZMCRC 0x02. IE: also "values".

    Yeah, the low 7-bits of ZFILE's ZF1 appear to be an enum as well. The high bit (bit 7) of ZF1 does appear to be a bit-flag however.

    The Google AI explanation for ZF1 is that it bit has a different purpose. 0x1 - make new name (ok that lines up when used with 0x04 and you have 0x05), but
    0x2 - modify an existing file, and
    0x4 - protect and existing file
    0x8 - clobber a file.

    So your definitions for 0x02 and 0x04 differ, and makes no reference to a CRC bit.

    My (zmtx's) definitions of those ZF1 values appears to match Chuck's zmodem.h, so I trust those over any AI slop. :-)

    Any of this make sense? Is the difference due to implementation or version or something else I havent discovered yet?

    I think a lot of these options/flags aren't checked on receive and you likely can set or not set and have no ill effect. Experimentation is good, but also look at Chuck's source code and the various ZMODEM docs (e.g. https://wiki.synchro.net/ref:zmodem) to try and make sense of it. AI probably isn't going to give you accurate answers 100% of the time.
    --
    digital man (rob)

    Breaking Bad quote #48:
    I am not in danger, Skyler. I am the danger. - Walter White
    Norco, CA WX: 65.2øF, 57.0% humidity, 0 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.30-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)