info-kermit@ucbvax.ARPA (12/18/84)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Tue, 18 Dec 1984 Volume 1 : Number 44
Departments:
ANNOUNCEMENTS -
Kermit for the Commodore 64 Written in Assembler
Kermit for the Commodore 64 in FORTH
Corrected Copies of MS-DOS Kermit 2.27 for Z100 and NEC APC
CP/M-80 KERMIT -
CP/M Kermit v4: CP/M 3 Support and H89
CP/M Apple Kermit v4.03
Kaypro Version of Kermit 4.03
Kermit-80 Status
MISCELLANY -
Columbia Kermit with Port 3?
Multics Kermit and X.25 Connections
Additional Heuristics for Kermit
Kermit vs 4705?
----------------------------------------------------------------------
Date: 14 Dec 84 00:41:50 EST
From: Eric <LAVITSKY@RUTGERS.ARPA>
Subject: Kermit for the Commodore 64 Written in Assembler
To: sy.fdc@CU20B.ARPA
Here is Kermit for the Commodore 64, written in CROSS (almost exactly like
the Apple version). I have bootstrap programs, but the BASIC version for
the C64 end doesn't yet do what it's supposed to. The bootstrap is supposed
to work just like the Apple version; since it isn't quite working yet, one
must have Kermit or Modem to get Kermit over to his/her machine. I hope
to have this problem corrected soon. The files are on CU20B, available
via anonymous FTP:
KER:C64DXL.BAS ; A BASIC version of C64DXL
KER:C64DXL.HEX ; The hex file for C64DXL (nulls removed!)
KER:C64DXL.M65 ; The source for the disk hex loader
KER:C64KER.DOC ; Incomplete Documentation
KER:C64KER.HEX ; The Hex file for C64KER (with nulls removed!)
KER:C64KER.INS ; One page installation instructions
KER:C64KER.M65 ; The source, however mixed up it may be
KER:C64KER.MSG ; Proposals for improvements (like an RFC)
KER:C64KER.MSS ; The Scribe source for C64KER.DOC
I am calling this release of Kermit a Beta-Test for several reasons.
This version was slapped together from the sources I received from
Dave Dermott and my improvements, updates from the latest Apple
version. I wanted to get this out ASAP. As a result, there are
several untested features, unimplemented features or some features
which may be better if implemented in a different way. See C64KER.MSG
for a list of these.
ARPA: Lavitsky@RUTGERS
UUCP: ...harpo!whuxlb!ru-blue!lavitsky
or ...allegra!ru-green!ru-topaz!eric
SNAIL: CPO 2765, CN 700
New Brunswick, NJ 08903
or 14 Rock Ave.
Swampscott, MA 01902
Phone: (201) 932 - 2443 (RUTGERS: Operators' Cubbyhole: leave a message)
(617) 593 - 4841 (Real Home: leave a message)
(201) 745 - 8143 (Campus Home during school semesters only)
[Ed. - CROSS is a cross assembler that runs only on the DEC-10 and DEC-20.
For bootstrapping, I'd suggest that the MS-DOS method be adapted -- run
MSMKBOO on the binary to produce a 4-for-3 encoded .BOO file (with
zero-compression), use MSBOOT.FOR to send the .BOO file, and adapt
MSPCBOOT.BAS to run on the C64 to receive the file. These days, every
Kermit seems to come with its own unique bootstrapping procedure; since
most of them do the same thing, let's start standardizing. Meanwhile,
send comments and suggestions about this new Kermit implementation to Eric
and to Info-Kermit.]
------------------------------
Date: Wed 12 Dec 84 15:46:38-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for the Commodore-64 in FORTH
To: Info-Kermit@CU20B.ARPA
Announcing Kermit for the Commodore 64 with Commodore 1541 disk drive,
from Robert W. Detenbeck, University of Vermont. The program was written
to be used with version A of C64-FORTH, sold by Performance Micro
Products, 770 Dedham Street-S2, Canton, MA 02021. Slight modifications
would be required to use the screens with the newer version B, a pure
FORTH-79 standard.
The files (slightly modified for distribution, as indicated) are available
on CU20B via anonymous FTP:
KB:C644TH.PRG -- core-image 8-bit binary "PRG" file.
KER:C644TH.HEX -- hex (nibble) encoding of C644TH.PRG, with CRLF inserted
after every 78 characters.
KER:C644TH.DOC -- brief explanation of the program
KER:C64495.SCR -- help screen SCR95, with CRLF inserted after every 40 chars.
KER:C64496.SCR -- help screen SCR96, ditto
KER:C64497.SCR -- help screen SCR97, ditto
KER:C64498.SCR -- help screen SCR98, ditto
Source not included. The author says "I would be glad to provide the
FORTH source screens to anyone who could use them, but it is awkward to
transmit 90 Kbytes on a 300-baud Kermit, so a mailed disk might be a
better answer to the probably small number of requests." Send a
self-addressed mailer to the author, Prof. Robert W. Detenbeck, Department
of Physics, University of Vermont, Burlington, VT 05405.
We'll also try to scare up the source ourselves.
------------------------------
Date: Tue 18 Dec 84 10:13:56-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Corrected Copies of MS-DOS Kermit 2.27 for Z100 and NEC APC
To: Info-Kermit@CU20B.ARPA
A forthcoming issue will be devoted to the reaction to MS-DOS Kermit v2.27.
In the meantime, it should be noted that serious problems were discovered
with the Heath/Zenith-100 version, and it has been replaced. Minor problems
were also discovered with the NEC APC version and it too has been replaced.
The new files are in
KB:MSZ100.EXE, KER:MSZ100.BOO, KER:MSXZ100.ASM -- Z100
KB:MSAPC.EXE, KER:MSAPC.BOO, KER:MSXAPC.ASM -- NEC APC
on CU20B, available via anonymous FTP.
------------------------------
Date: Tue, 11 Dec 84 23:51:18 CST
From: Paul Milazzo <milazzo@rice.ARPA>
Subject: CP/M Kermit v4: CP/M 3 support and H89
To: Charles Carvalho <CHARLES@ACC.ARPA>, INFO-KERMIT@CU20B.ARPA
One of the many nice things about the beta-test version of CP/M Kermit
is that it contains code that correctly calculates disk free space
under CP/M 3. Unfortunately, this code is only assembled in when you
select the "cpm3" flag, which results in a generic (pronounced "slow")
CP/M 3 Kermit, as if CP/M 3 were mutually exclusive with the supported
system types. Since I have an H89 running CP/M 3, I wanted to take
advantage of the H89-specific support and still be able to tell how
much free space there is on my disks.
Rather than double the number of supported system configuration flags
just for this one function, I chose to save the BDOS file system
version (from BDOS function 12) at startup, check it whenever sysspc is
called, and branch to the correct algorithm. That way, a configuration
for hardware which supports both CP/M 2 and 3 will work in either case.
If this approach is seen as a Good Thing, I'll be happy to contribute
it to the distribution. If not, what should I have done instead?
I've also added some additional H89 support (speed selection, sending
breaks, etc.), and fixed a minor bug in the delay subroutine used by
"kpii", "bbII", and "cpt85xx". It ignores its argument.
Paul G. Milazzo
Dept. of Computer Science
Rice University, Houston, TX
ARPA: milazzo@rice.ARPA
UUCP: {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo
[Ed. - When any of this finds its way into the distributed version, a
notice will be posted.]
------------------------------
Date: 13-Dec-84 03:13:51-EST
From: decvax!ncoast!stuart@Berkeley (Stuart Freedman,C.W.R.U.,368-8860)
To: .include.fdc@Berkeley
Subject: CP/M Apple Kermit v4.03
I just put together this version (snarfed it over and ddt-ed it) and find
it great (esp. the greater time between disk accesses). The only problem
I have discovered so far is that when I do a ctrl-] D to disconnect (I am
using the Micromodem II version), the system just hangs. Also, is there
any chance of making the logging feature better (i.e. enlarging the buffer
size and allowing more time for ^S-^Q so that no characters would be
lost)?
Thank you very much for putting Kermit together and coordinating the
ongoing efforts to improve it.
Stuart Freedman decvax!cwruecmp!ncoast!stuart
Case Western Reserve University or ccc%Case.CSNET@CSNet-Relay.ARPA
------------------------------
Date: 14 Dec 84 13:38:49 EST
From: Dave Zubrow <DZ05@CMU-CC-TD>
To: info-kermit@CU20B
Subject: Kaypro Version of Kermit 4.03
Dear Kermit:
I have been trying to use version 4.03 and can't get it to work with files
larger than the 16K buffer. After it writes the buffer to disk I get the
message "?unable to receive data". I've tried various settings for the
send and receive timeout parms on the Dec-20 but they were not successful
in eliminating the problem. Could it be that the 16K buffer is not being
flushed after the disk write? Do you have any remedies or suggestions?
Thanks,
Dave Zubrow
------------------------------
Date: 17 Dec 1984 12:59 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: Kermit-80 status
To: SY.FDC@CU20B
Frank and Bernie -
I've got the new H89 stuff here, and will merge it with the FILCOM for
the Northstar CP/M version. I'm curious about the bug Hal found in the
receive packet routine (but not surprized). I thunk about the disk
buffering problems this weekend, and am puzzled why increasing the
send/receive timeouts at the other end didn't fix the problem. (It worked
here, between a Kaypro and VMS Kermit; the Kaypro takes about 15 seconds
to transfer 16Kbytes to disk, so 20 seconds ought to be adequate. I used
30 seconds). Anyway, a possible solution is to check the line for more
data after receiving the packet terminator, and if a control-A is seen,
forget the received packet and accumulate the next one. (Doesn't the
MSDOS Kermit do something like this?) This should work for any number of
complete buffered messages, as well as the final partial message, if any,
for a micro such as the Robin that flow-controls if nobody is taking the
received data. What I'm not sure about is what happens if the middle of a
message is dropped (for instance, a SIO chip will keep the first two and
the last byte of a message that comes in while nobody is looking). I
guess we'd usually recover after a timeout. The problem with the Apple
Micromodem configuration is that control-] D no longer terminates connect
mode, it just hangs up the phone (oops...) For now, following control-] D
with control-] C should do the right thing.
/Charles
------------------------------
Date: 14 Dec 1984 12:34:56-EST
From: augeri%rpi.csnet@csnet-relay.arpa
To: info-kermit@cu20b.ARPA, csnet-relay%rpi.csnet@csnet-relay.arpa
Subject: Columbia Kermit with Port 3?
Does anybody has a version of kermit that runs on the Columbia using COM3
instead of COM1 or COM2? It seems to me that all that needs changing are
the port addresses in MSXIBM.ASM.
-- Ivan Auger -- (augeri@rpi for csnet)
(augeri%rpi@csnet-relay for arpanet)
[Ed. -- Look at MSXTIPRO.ASM for an example of how to increase the number
of ports.]
------------------------------
Date: Tue, 11 Dec 84 02:20 CST
From: Jerry Bakin <Bakin@HI-MULTICS.ARPA>
Subject: Multics Kermit and X.25 connections
To: info-kermit@COLUMBIA-20.ARPA
I have noticed some peculiar behavior in Multics Kermit; I was hoping to
pass this on to the maintainers of Multics Kermit (I know of at least
four versions!) and through Info-Kermit.
I have been connecting to Multics through a VAX using the DEC PSI
program which creates an X.29 virtual terminal over an X.25 circuit.
I notice that if the first thing I try to do in Kermit is "receive" a
file, I get an error complaining about setting "improper modes" for this
device. If I first try a "send" then things work ok. Indeed, if I
first send, and then try to receive, the receive works as well.
Could it be that you are setting modes differently for send then
receive, and trying to set modes for receive that do not really need
setting?
Jerry Bakin. <Bakin at HI-Multics> (818) 915-9874
[Ed. - This message was passed along to the author of MULTICS Kermit.]
------------------------------
Date: Sun 9 Dec 84 07:59:30-PST
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Re: Additional Heuristics for kermit
To: info-kermit@CU20B.ARPA
This is in response to Frank da Cruz's response to my message of Oct 17,
both of which are published in info-kermit V1 #33. Since we agreed on
idea #2, I have omitted it.
1. Any control character received in a packet terminates that packet.
What I meant by this was any control character not agreed
on as going through unharmed. If the sending kermit won't
send a control character, the receiving kermit should NAK
a packet containing one.
3. A nak should be sent as early as possible.
I should have been more explicit here too. This thought
was mainly important for kermits that send multiple packets
at a time. (Not yet part of the kermit protocol.) Many systems
have output buffers, so the amount of time they spend not
waiting for input is trivial. (I'm more used to large systems
where this is true, and I like micro's to imitate this. I
hate systems without typeahead.)
Bob Larson <Blarson@Usc-Ecl.Arpa>
[Ed. - No problem with any of these. But note in (3) that because of
the layered nature of the protocol, the program does not (or should not)
know the packet type or number until the packet reader has read the entire
packet and returned it to the entity awaiting the packet; thus it would not
fail and send a NAK as soon as a bad header was read.]
------------------------------
Date: Tue, 4 Dec 84 19:55:19 pst
Subject: Kermit vs 4705?
From: Steve Reynolds <reynolds%uofm-uts.cdn%ubc.csnet@csnet-relay.arpa>
To: info-kermit@COLUMBIA.ARPA
After implementing a Kermit on my NCR Tower (version III with Berkley
enhancements) and successfully communicating with a VAX Kermit I decided to
widen my horizons and try to communicate with an Amdahl 470. This is the
general configuration of the machines:
TOWER PAD AMDAHL 4705 VM UTS
x.28 pp04
After some attempts I decided to ask the 'cloud' about this. Does the 4705
eat any control characters??? Does anyone else have this type of config???
If so, how did they get it working. If anyone has any ideas and/or ways
of attacking the problem I would surely like to here from them.
steve reynolds
[Ed. - Note that Unix Kermit, as distributed, operates correctly on 370-
series mainframes running UTS, with 3705-style front ends.]
------------------------------
End of Info-Kermit Digest
*************************
-------