LWELCH@COLGATEU.BITNET (02/13/89)
Would someone please post Kermit 3.85 to Apple2-l? Chip Welch LWELCH@COLGATEU.BITNET
JDA@NIHCU.BITNET (Doug Ashbrook) (02/15/89)
> Would someone please post Kermit 3.85 to Apple2-l?
I recall reading that since Kermit was available from Columbia, the
files were being deleted from the APPLE2-L list.
The source and hex files for several versions of Apple II Kermit are
available from listserver KERMSRV@CUVMA. To get a directory listing
of all of the Apple II files, try the command:
DIR APP*.*
The file APPAAA.HLP is a description of what most of the other files
are. To get this file, try the command:
PRINT APPAAA.HLP
-------------------------------------------------------------------
J. Douglas Ashbrook (301) 496-5181
BITNET: JDA@NIHCU ARPA: jda%nihcu.bitnet@cunyvm.cuny.edu
National Institutes of Health, Computer Center, Bethesda, MD 20892ALBRO@NIEHS.BITNET (02/16/89)
I'm surprised no one caught me on this. In recent postings I've described
experiments "proving" that Kermits 3.80, 3.84 and 3.85 strip linefeeds
automatically under DOS 3.3 but not under ProDOS. Others have stated that
they got stripping under ProDOS. Well, the answer seems to be pretty
simple now that I've bothered to read what was being shown on my screen.
The default ("as received") setup on v.3.84 is to have TRANSLATE CR<->CR,LF
On for send and Off for receive. When I made a test file containing line
feeds after carriage returns and sent it to the Vax with Kermit 3.84, it
woulund up with DOUBLE line feeds. When I brought it back, one of them was
stripped off, leaving the other still there. So a few more experiments
are in order.SEWALL@UCONNVM.BITNET (Murph Sewall) (02/16/89)
>Would someone please post Kermit 3.85 to Apple2-l?
NO! It's not there because we haven't the disk space to waste on
redundant storage. The proper place to retrieve APP385.1 and APP385.2
is KERMSRV@CUVMA (on BITNET, which is where the request came from)
or cunixc.cc.columbia.edu (by 'ftp') on the Internet.
(note the spelling of KERMSRV -- there only one 'E')
Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90]
Prof. of Marketing Sewall@UConnVM.BITNET
Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET]
U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP]
-+- I don't speak for my employer, though I frequently wish that I could
(subject to change without notice; void where prohibited)
According to the American Facsimile Association, more than half the calls
from Japan to the U.S. are fax calls. FAX it to me at: 1-203-486-5246c08_d103@jhunix.HCF.JHU.EDU (Ex-God) (02/27/89)
I have a slight problem with Kermit385 -- namely, it doesn't support
the AppleCat. Supposedly, the AppleCat will work with the "Apple
Serial Card" setting. Doubtful, and besides, there's not a chance in
hell that the AppleCat will be able to dial with Hayes commands --
even dialing by hand won't work, because there's no way to get the
modem to autosearch.... I would write my own driver, but the driver
support in the instructions doesn't mention anything about a dial
routine, and I don't want to break the Micromodem // driver down
looking for how it dials....
Anyway, the program looks like a great program -- I'd love to have
Kermit support, vt100 emualtion, and all the other features -- but
it's worthless to me without AppleCat support.
-- Andrew Barnert // ex-God // Smilin' Jack // Andy Matter // etc.
ins_balb@jhunix // ins_balb@jhuvms // c08_d103@jhunix
The opinions expressed in this message are yours. So there.
"If you can't stand the Big Chill, burn down the freezer." -- Jello BiafraDick@cup.portal.com (dick a wotiz) (02/28/89)
Andrew Barnert writes: > I have a slight problem with Kermit385 -- namely, it doesn't support > the AppleCat. Supposedly, the AppleCat will work with the "Apple > Serial Card" setting. I have the same problem.... and didn't expect it to work either. > Anyway, the program looks like a great program -- I'd love to have > Kermit support, vt100 emualtion, and all the other features Since this is the very first PD program I've seen with VT100, kermit and xmodem support, I figured it was worth it to write an Apple-cat driver. It uses some of the routines in the Cat's firmware ROM for dialing, so you need to have that installed. Since I only have an unenhanced IIe, I can't guarantee it works on anything else, but you don't know 'till you've tried :-) The driver supports interrupts for received characters, dialing, carrier detect, and xmit/receive buffering. If anyone's interested in getting a copy, I can mail it to you; if there's enough interest, I can post it to comp.binaries.apple2. Dick Wotiz dick@portal.com {uunet|sun}!portal!dick
paul@athertn.Atherton.COM (Paul Sander) (03/01/89)
I downloaded Kermit 3.85 for the first time last night, and I ran across
the same problem Scott Hutinger had last week. The problem is this: after
using the scripts posted by Lazlo Nibble to convert Unix newlines to Apple
CRs, I downloaded the APP385.1 and APP385.2 using my favorite communication
program ("favorite," because I don't have Kermit yet). After backing up
the disk, I followed the installation instructions, entering
"EXEC APP385.1,R25". The disk sat and spun for a while, eventually stopping
with an END OF DATA message.
The rest of this posting discusses why this happened, and how I repaired it.
If you have been having problems with Kermit which are not described above,
this article is not for you.
The problem arises from incompatible ASCII formats, among other things. Yes,
ASCII is a standard, but so is RS-232, so the word "standard," like the word
"should," is undefined in this industry. :-) :-) :-)
Unix stores characters in 7-bit ASCII. On machines that store characters in
8-bit bytes (do I dare say most?) the character is usually stored in the
least significant bits of the byte, and set the most significant bit to a
zero. Furthermore, lines of text are separated by an LF (linefeed) character.
Apple's DOS 3.3, on the other hand, stores characters in the least significant
7 bits of a byte, and then sets the most significant bit to a ONE, and it
separates lines of text with a CR (carriage return) character.
Using the shell scripts posted by Lazlo Nibble or Sean Kamath, the LF -> CR
translation can be done painlessly.
Transferring the file can be painful. In my case (using ASCII Express
XMODEM protocol transfers), the files came into my machine with the most
significant bits of the ASCII characters set to zero.
When I EXEC'ed APP385.1, DOS didn't recognize the text for what it was, and
read all the way to the end of the file and then gave an error, without
performing the installation.
Following is a quick Applesoft hack that I used to copy the files while
setting the MSBs correctly:
5 INPUT "ENTER INPUT DRIVE: ";D1
10 INPUT "ENTER INPUT FILE: ";F1$
15 INPUT "ENTER OUTPUT DRIVE: ";D2
20 INPUT "ENTER OUTPUT FILE: ";F2$
30 D$ = CHR$(4)
40 ONERR GOTO 1000
50 PRINT D$;"OPEN ";F1$;",D";D1
60 PRINT D$;"OPEN ";F2$;",D";D2
70 REM
75 S$ = ""
80 PRINT D$;"READ ";F1$
90 GET C$
91 IF C$ = CHR$(13) THEN 100
92 S$ = S$ + C$
93 GOTO 90
100 PRINT
105 PRINT D$;"WRITE ";F2$
110 PRINT S$
120 GOTO 70
1000 REM
1010 E = PEEK(222)
1020 IF E = 5 THEN 1040
1030 PRINT "ERROR ";E;" HAS OCCURED"
1040 REM
1050 PRINT D$;"CLOSE ";F1$
1060 PRINT D$;"CLOSE ";F2$
1070 END
This program is a simple sequential file copy, but it relies on a side-effect
of DOS' I/O: That it sets the MSB of any character it writes to a file. By
simply reading and writing the file, it becomes EXEC'able!
Note that this does not work when using COPY or COPYA, as they copy disks on
a track-by-track basis, and it doesn't work with FID, because it copies on
a sector-by-sector basis. This works because it copies on a character-by-
character basis.
To get Kermit to install, download its files, then copy the files to a new
disk using this program. IMPORTANT: Give the copied files names different
from APP385.1 and APP385.2, as this will confuse DOS. After the files have
been copied, rename the copies back to APP385.1 and APP385.2 and
EXEC APP385.1,R25 .
Note that this is a quick hack to solve a problem. There is no error checking
to speak of, and no guards against pilot error.
Good luck!
Paul
paul@Atherton.COM
--
Paul Sander (408) 734-9822 | Do YOU get nervous when a
paul@Atherton.COM | sys{op,adm,prg,engr} says
{decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ?krb20699@UXA.CSO.UIUC.EDU ("Ad finem...") (06/05/89)
Make sure your files are APP385.1 and APP385.2 You said they were, bu I wanted to make sure. This is important. Also, the EXEC APP385.1,R25 is not reliable. What you should do is take off the lines before the REM statements (up to and including the CUT line) and just EXEC APP385.1 WITHOUT the record spec. If this doesn't work for you, E-mail me. Ken. krb20699@uxa.cso.uiuc.edu