Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!beartrk!ceilidh!dnichols From: dnichols@ceilidh.beartrack.com (DoN Nichols) Newsgroups: comp.sys.3b1 Subject: Re: XMODEM file padding (was Re: UMODEM on local connections) Keywords: UMODEM XMODEM local Message-ID: <1991Apr14.053403.15598@ceilidh.beartrack.com> Date: 14 Apr 91 05:34:03 GMT References: <1991Apr8.221615.1195@cbnewsj.att.com> <1991Apr9.161637.12059@oswego.oswego.edu> <1991Apr13.014747.7144@netcom.COM> Distribution: na Organization: D and D Data, Vienna, VA. Lines: 29 In article <1991Apr13.014747.7144@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: >In article <1991Apr9.161637.12059@oswego.oswego.edu> ostroff@oswego.Oswego.EDU (Boyd Ostroff) writes: >> >>The only problem I've noticed is that there are often a bunch of NULLs [ ... ] >If the file size doesn't match up to an exact multiple of 128 bytes, the >last packet will be only partly full of file data. The protocol has to >put SOMEthing into the packet to fill it out, and nulls are often used. Also VERY frequently used is the '^Z' character, since it is interpreted as 'EOT' by text-mangling utilities under CP/M (where the xmodem protocol originated), and, by extension, MS-DOS. The packet size was chosen to be a single sector on then-popular implementations of CP/M. (I don't know whether CP/M ever had any other size sectors, alghough probably CP/M-86 which ran on IBM-PC hardware probably used larger sectors, at least as an option. At least there are never more than 127 of them, so I can get rid of them using JOVE, and not have to resort to emacs. :-) Kermit is a MUCH nicer protocol, it's a pity that it has so much overhead :-) (Although two of the newer ones talking to each other are not bad at all. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: --- Black Holes are where God is dividing by zero ---