Date   : Wed, 27 Jul 1983 11:09:33 EDT
From   : Dave Towson (AMSAA) <towson@brl-bmd>
Subject: Re: zcpr2 and unsqueezing

Russ - With regard to your file unsqueezing problem, it seems likely that
you are having the same problem we on the BRL UNIX machines have had in
transferring binary files from mit-mc.  MC is a 36-bit machine, and packs
binary files four-bytes-to-the-word.  The remaining four bits are filled
with zeros, and at least in our experience, those four-zeros-per-word are
delivered along with the desired binary information when files are FTP'ed.
Two people here have dealt with this problem:  One, Joel Kalb <jkalb@brl>
has written a CP/M program to remove the junk, but I guess that won't help
you since you want to correct the files while still in the UNIX domain.
The other person, Steve Segletes <steven@brl>, has written a C program
which works well, but is still being polished, and which runs under UNIX.  Both
of these programs also strip-off the first four bytes of the recieved binary
file.  These bytes are put there by mc as part of the file-transfer process,
and are not part of the desired file.  To see whether you are having the 
same problem we are having, I suggest you try the same experiment we did here:
FTP both the ASCII-hex file and the resulting COM file for some convenient
program (such as, AR13:CPM;CRCK 44HEX  and  AR12:CPM;CRCK 44COM) and then
use the UNIX utility OD with the hex-byte option to get a hex-dump of the
COM file (and maybe print the first ten lines or so).  Then compare what you
got with what it was supposed to be as read from the ASCII-hex file.  (If
you don't know how to read Intel hex format records, send me mail and I'll tell
you, or alternatively, transfer the hex file to your CPM system and LOAD it
to get a clean COM file which you can dump using DDT.)  If you are having "our"
problem, you will find that the first four bytes of the FTP'ed COM (binary)
file will be 93 3A D8 00 (in hex), and that from there on,  each four bytes of
desired data will be preceded by four junk-zeros.  This will cause the first
four program bytes to be shifted-right by four bits (for example, C3 34 12 F3
will be changed to 0C 33 41 2F 30), and then the next four junk-zeros will
bring the next four bytes back into proper registrtation.  This pattern will
repeat for the rest of the file, giving five bad bytes, four good ones. five
bad, four good, etc.  The programs written by Steve and Joel strip the first
four bytes and then throw-out the first four bits of each 36 bits thereafter.
They work like a champ.  If you are having this problem, your unsqueezer will
not be able to recognize the mess as a squeezed file, much less unsqueeze it.
As a final note, I guess I should say specifically that squeezed files must
be moved as BINARY files using the image-mode (i.e.,TYPE IMAGE) of FTP.  If
you haven't been doing that, you have probably gotten a lot of extra carriage
returns added to your binary data by the UNIX FTP server.  Use image-mode for
squeezed files.  We have had no trouble moving ASCII files from mc to our UNIX
machines (both PDP-11 and VAX), but until the two post-processors were written
binary files were 100% frustration.  If you would like copies of either of the
post-processors, send netmail to steven@brl for the C program, or jkalb@brl for
the CP/M version.  Both work.  Good luck!

Dave Towson
US Army Materiel Systems Analysis Activity
Aberdeen Proving Ground, Maryland