smith@nrl-aic@sri-unix.UUCP (07/27/83)
From: Russ Smith <smith@nrl-aic>
I tried to retrieve and unsqueeze "AR80:CPM;ZCPR2 23AQM" using
an unsqueezer program written for UNIX ("AR43:CPM;XUSQ 107C").
Apparently this unsqueezer and the program used to squeeze ZCPR2
use different formats for the data encoding. What could I use on
our VAX UNIX system to do the task (i.e., is there one on mit-mc
which I can ftp over to unix ala XUSQ?)?
Russ (smith@nrl-aic)GZ@mit-mc@sri-unix.UUCP (07/27/83)
From: Gail Zacharias <GZ@mit-mc> Neither the ITS nor TOPS-20 USQ's have any trouble with that file, so it's not corrupted. Did you remember to strip the four header bytes from the file before handing it to the program?
towson@brl-bmd@sri-unix.UUCP (07/27/83)
From: Dave Towson (AMSAA) <towson@brl-bmd> 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
goldfarb.ucf-cs@rand-relay@sri-unix.UUCP (07/28/83)
I don't think the problem is with xusq107. I am the one who hacked that for
the Vax and 4.1bsd, I haven't ever had any problems since I got it going on
this machine. Here are some places where you might be going astray:
1) Not compiling xusq107.c with -DVAX
2) Not using the -b option of umodem to transfer the file (if you
are using umodem).
3) Not stripping the ITS "stuff" off of the squeezed file after
you get it from MIT-MC.
4) Not setting "Tenex" mode for the FTP transfer.
If these seem elementary, I am trying to cover all bases. Let me know if
I can help you further.
Ben Goldfarb
University of Central Florida
uucp: {duke,decvax}!ucf-cs!goldfarb
ARPA: goldfarb.ucf-cs@Rand-RelayW8SDZ%mit-mc@sri-unix.UUCP (07/28/83)
From: Keith Petersen <W8SDZ@mit-mc> Dave, you can get away from the binary zero padding problem on FTPing binary files from MIT-MC if you simply tell FTP (on BRL or BMD) that you want the 8-bit byte mode. The command at BRL and BMD that does this is "tenex". If you do this before transferring binary files from MC, the only thing you'll have to do to make them CP/M compatible is to strip off the first four bytes. These first four bytes are added to COM files by our Christensen-compatible MMODEM program so that it and other programs can later tell the difference between ASCII and BINARY files. I have written a program, ITSCVT, which runs on your CP/M machine, which removes the first four bytes of ITS-style "COM" (binary) files. It's available in AR13:CPM;ITSCVT HEX --Keith
GZ@mit-mc@sri-unix.UUCP (08/03/83)
From: Gail Zacharias <GZ@mit-mc> If you are getting all your bits and bytes shifted around, you are using the wrong mode in ftp! In addition to specifying image mode, you should also specify "8-bit bytes". ITS will then take care of extracting the bytes from PDP-10 words in the correct way. I gather different unix ftp programs have different commands, but I'm told at least one of them does it this way: ftp mit-mc type i quote type "l 8" You will still need to strip the 4 header bytes (which I'm told you can do with a general-purpose utility called 'dd'), but you certainly shouldn't have to shift anything around!
dave@rocksvax.UUCP (08/05/83)
You may be able to get things right if you can tell your ftp program that
you want "text" mode. I think that will give you 8 bit bytes back without
padding, maybe. We usually have that trouble ftping from those TENEX machines
to MAXC and getting both sides to say "text" 8 bits usually does the trick..
Dave
-----
Arpa: Sewhuk.HENR@PARC-MAXC.ARPA
uucp: {allegra, rochester, amd70}!rocksvax!dave