Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!towson@brl-bmd From: towson@brl-bmd@sri-unix.UUCP Newsgroups: net.micro.cpm Subject: Re: zcpr2 and unsqueezing Message-ID: <3544@sri-arpa.UUCP> Date: Wed, 27-Jul-83 11:09:33 EDT Article-I.D.: sri-arpa.3544 Posted: Wed Jul 27 11:09:33 1983 Date-Received: Sun, 31-Jul-83 20:49:32 EDT Lines: 49 From: Dave Towson (AMSAA)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 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 , 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