2QZNHONE@UKANVAX.BITNET (09/15/87)
I JUST BOUGHT AN APPLE //GS AND MY LATEST VERSION OF KERMIT, VERSION (3.75)
DOESN'T WORK ON MY //GS. DOES ANYONE KNOW OF A NEWER VERSION OR MAYBE
SOMETHING NEEDS TO BE CHANGED IN ORDER FOR IT WORK CORRECTLY. DOES ANYONE
HAVE A //GS AND KERMIT WORKING OKAY? IF SO, I WOULD APPRECIATE SOME INFO.
SOMEONE TOLD ME ABOUT A VERSION 3.78 (DOES THIS EXIST AND WORK ON THE //GS?)
IF YOU KNOW ABOUT IT, ALSO PLEASE TRY TO INFORM ME ON WHERE AND/OR HOW I
MIGHT OBTAIN IT. THANKS IN ADVANCE
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2QZNHONE@UKANVAX.BITNET
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++plate@dicome.UUCP (Douglas B. Plate ) (08/16/88)
A few days ago I posted an article descibing a "problem" I was having with my kermit ver. 3.73. Over the weekend, I discovered the answer to this. The first four bytes of a binary file are the loading address and the length of the file. Kermit expects these to be there already when it receives a file and saves it to a DOS 3.3 binary file. It also sends these bytes out with the data. It does make sense, since most of the binary data transferred to an Apple/kermit will be binary data from another Apple/kermit and will have these bytes. The stuff I was downloading, however, was YAMAHA DX7 system exclusive data and could have originated from any variety of PC that has MIDI. The way I got around this problem was to prepend the file with 4 "dummy" bytes on the vax side, download and then use a sector editor to change these bytes to the correct values. It was a lot to go through, but I did learn a few things. Thanks to those of you who took the time to reply, I would have mailed to you directly, but our mailer doesn't seem to be able to find you (old map). Doug Plate