SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (12/24/85)
Info-Kermit Digest Tue, 24 Dec 1985 Volume 3 : Number 35
Departments:
MS-DOS KERMIT -
Kermit 2.28 jrd Bug Report
Fast Kermit for AT?
IBM-PC Kermit v2.28 Display Problems
Kermit for Victor
MISCELLANY -
Kermit for Apples with StarCard
Request for KERMIT binary for Radio Shack 6000 Xenix
Set File 8-Bit in Kermit-20
----------------------------------------------------------------------
Date: 23 DEC 85 13:15-MST
From: JRD@USU.BITNET
Subject: Kermit 2.28 jrd Bug Report
1. Thanks for the mail messages and nice words. Using Bitnet here is magic
of a rather dark hue, alas. Given that you seem to have a shortage of
MS-DOS folks perhaps I can get the mail via Bitnet and help solve the sundry
bugs as they arrive and then send responses to you for editing.
2. Bugs of various kinds in "MS Kermit 2.28 jrd" are discussed below.
3. Rare computer hangups when engaging IBM mode and then entering the
Connect state. Peering at the interrupt level code in file MSXIBM shows
several places of difficulty if the mainframe were to have sent a char
before Kermit was ready to accept one. Some changes were made to hopefully
avoid problems; all involve completing work before interrupts can interfere.
The hangup problem seems to be like a corrupted segment register (ds?),
which could happen I suppose if a char arrived during serial port
initialization. Actually, I or someone needs to have a hard look at the
code in SERINT to see if all UART conditions are properly serviced and if
the 8259 interrupt controller chip is attended to in an manner consistent
with both IBM PCs and ATs. ISRs are such fun! My quick changes are as
follows.
Procedure SERINI:
- flush UART received character BEFORE turning on interrupts,
- change allowable UART interrupting conditions to avoid interrupts on
TX Holding Buffer Empty (a nonsense interrupt for us) but allow them
on Data Available, RX Line Change, and Modem Change,
- move push/pop es to allow quicker procedure exit,
- replace call to proc Clrbuf with separate code since Clrbuf turns on
interrupts within the body of SERINI (a likely culprit).
Procedure SERRST:
- move push/pop es to allow quicker procedure exit.
Procedure SERINT:
- send 8259 chip End-of-Interrupt signal as almost last item in the proc,
- remove strange Enable Interrupts (sti) instruction within proc body;
after all, we got here via an interrupt.
4. Data overrun when turning around line between IBM mainframe and IBM
PC/AT. An obvious thing to do here is insert a small wait interval before
sending a packet (sending filler chars could still upset the host during
line turn around); this is usually called pacing. In terms of fast micros
and sluggish mainframe terminal handlers, pacing seems to be one of the
solutions. I added a 3 millisecond wait routine at the very beginning of
procedure OUTPKT in file MSCOMM; it may not be enough, but the delay is
easily adjusted. If it's too long then we will lose the time slice, if too
short then mainframe loses the first part of a packet.
5. Files sent while in server mode do not use repeat prefixing. My goof due
to misunderstanding the non-standard protocol of setting the prefix char. Two
lines of code were added in procedure SERVER (in file MSSERV) to force the
default prefix char into the active prefix after each server command.
6. Items not clearly explained in original read.me file for 2.28 jrd.
-- GET allows both file names to be on the same line; ex. GET theirs mine.
-- GET allows ? chars in filenames after the first char, but I forgot to
invoke the # --> ? translation. I think earlier versions omitted this
also. Similarly, I parse both file names on whitespace (can be fixed)
which is probably painful for IBM users.
7. All these changes affect three files: MSXIBM, MSCOMM, and MSSERV. Below is
the output of MSDOS utility FC on the new and original "2.28 jrd" files. The
complete files, with extension of .NEW, are being sent as well.
8. Happy holidays. Joe
[Ed. - Now that we have established network connection with Joe, we can send
files back and forth rather quickly. There may well be a few more
contributions from him in the coming weeks. I've put the new files in
PS:<KERMIT-MS> on CU20B, in case anybody wants to check them out -- feedback
solicited and appreciated!]
------------------------------
Date: Thu 19 Dec 85 16:51:47-PST
From: Ed Pattermann <PATTERMANN@sumex-aim.arpa>
Subject: Fast Kermit...
Does anyone have a patch for MS-KERMIT that allows it to work with IBM AT's
that have faster crystals installed, like a 18MHZ crystal? Kermit fails
to work after installing the new crystal.
[Ed. - Some of the changes mentioned in the previous message might go a long
way towards helping here.]
------------------------------
Date: 19 Dec 85 16:39:48 PST (Thu)
From: Mike Iglesias <iglesias@UCI.EDU>
Subject: IBM-PC Kermit v2.28 Display Problems
I've seen the display problems that Kathleen Connors has seen with the original
v2.28 Kermit on both a IBM PC-I and a Compaq. It appears to only happen on the
old motherboard PCs (we have only one of those here) and the Compaq (which must
do something the same way that the PC-I does). It does not happen on the newer
PCs (PC-II; 256k motherboard) or a Compaq 286, so I suspect it may have
something to do with the ROM BIOS.
Mike Iglesias
University of California, Irvine
------------------------------
Date: 20 Dec 85 02:13:23 +0100
From: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU (YD14@BR1.THDNET)
Subject: Kermit for Victor?
I'm using a Vicky with "BIOS Version 2.9 February 4,1984 for V9000" and
MSDOS 2.11. I've tried to run the SIRIUS ASM available from KERMSRV
at CUVMA but it doesn't work. The CONNECT corrupts a lot of keys
(I'm using a German keyboard) and the RECEIVE doesn't work at 2400 baud.
The generic MSDOS kermit is running up to 2400 baud.
Has anyone a special kermit version for the Vicky (Victor 9000) PC?
Thanks
Reinhard Goeth (Techn. Univ. of Darmstadt/Fed. Rep. of Germany)
P.S. I wish you a merry chrismas and a happy new year.
------------------------------
Date: Fri, 20-DEC-1985 08:53 MST
From: Eric Zurcher <REHABIV@USU.BITNET>
Subject: KERMIT for Apples with StarCard
I thought I'd pass along a few things that I've learned while trying
to implement KERMIT on an Apple ][+ with a StarCard CP/M board. All of this
may already be familiar to you, but I provide it to you on the chance that it
may keep someone else from having to reinvent the wheel.
"Official" versions of KERMIT exist for Apples using the SoftCard CP/M
board, but I could not locate any for the StarCard. The SoftCard versions do
not work, since the two CP/M boards use quite different approaches in gaining
access to the Apple's ports. I have found that the "generic" CP/M KERMIT can
be made to work quite well with the StarCard, but only after making a minor
alteration in the BIOS of the operating system provided with the card. In its
standard configuration, the BAT: device is identical to the CRT: device, both
refering to the Apple's monitor and keyboard. However, changing a single byte
in the BIOS will cause the BAT: device to refer to a serial card in slot 2 of
the Apple, which is of course the sort of arrangement that generic KERMIT
needs. The byte in question is located at an offset of 63H from the start of
the JMP tables of the BIOS (that is, it can be easily located by adding 60H to
the address pointed to by the JMP instruction at address 0). This address
normally contains the value CC - changing it to C8 will result in the
definition of the BAT: device being changed to slot 2 of the Apple. (I have
not seen this "feature" documented anywhere, though I have not requested
technical documentation from the manufacturers of the StarCard.) Once this
change is made, generic KERMIT works quite well.
I'm currently working (though not very hard) on the rather simple task
of developing a KERMIT that will handle the task of modifying this byte, if
necessary. At present, I get around the problem by booting the system with a
disk that contains a version of the BIOS in which I have already modified the
byte. I've also managed to combine a few features of the SoftCard KERMITs with
the generic KERMIT, to allow VT52 emulation to work and to "tidy up" the
display during file transfers. It works reasonably well. If you wish, I will
send a version to you once I get everything working the way I'd like.
There are a few caveats (aren't there always?): (1) an 80-column
display enhancer is almost a necessity for reasonable terminal usage; the
StarCard can try to produce a 70-column display using software, but this is too
slow to keep up at even 1200 baud. (2) I have not thoroughly tested this, but
I suspect that a DC Hayes MicroModem II will not work with this arrangement -
the problem is that you can't dial a number. It does appear to be possible to
first dial and establish the connection under Apple DOS, then reboot the
machine to run CP/M. In any case, whatever serial interface is used must be in
slot 2 of the Apple. (3) I have not tested this arrangement at speeds above
1200 baud, but I suspect that faster speeds will not work well. (4) Most of
the VT52 emulation features work as they should, but the "home and clear
screen" operation is a bit slow - at 1200 baud I usually lose the next dozen or
so characters received after this operation. (5) It appears that data is
restricted to 7-bit, and not 8-bit bytes. For transfer of non-ASCII files,
parity should be set to space.
I hope somebody, somewhere, finds some of this useful. In the long
run, it would be preferable to have a KERMIT for this system which accesses
the serial port a bit more directly, rather than through twiddling the IObyte,
but I will leave that task to someone else.
Regards, and Merry Christmas!
Eric Zurcher
Dept. of Biology
Utah State University
Logan, Utah 84322-5305
REHABIV@USU
[Ed. - Thanks for the information; I've added your message to the APPLE.BWR
file for the time being. USU seems to be a beehive of Kermit activity these
days...]
------------------------------
Date: Sun, 22 Dec 85 11:41:56 EST
From: Glenn Ricart <glenn@mimsy.umd.edu>
Subject: Request for KERMIT binary for Radio Shack 6000 Xenix
I'd like to run KERMIT under Xenix on a Radio Shack 6000 (previously
known as the 16B before some magic happened). Unfortunately, this
system does not have a C compiler so I can't start from the sources.
Could someone contribute the binary? . . . . Thanks!
------------------------------
Date: Sun, 22 Dec 1985 13:29 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Set File 8-Bit in Kermit-20
Request for change in next update of Kermit-20: Because I do a lot of
uploading to Simtel20 and frequently use SEND *.* to do it, I have my
KERMIT.INI do SET FILE BINARY. No problem so far, as I can use ASCIFY
later to fix the ascii files - meantime I can go away from the
computer and let things transfer automatically (of course my Kermit-80
is set to default to SET FILE BINARY).
Now the problem: When downloading from Simtel20, that INI is still in
effect and I get garbage on ascii files sent to me. I need to be
able to tell Kermit-20 to use SET FILE 8-BIT for sends from me to
Simtel20, and SET FILE AUTO for sends from Simtel20 to me.
Suggest it might be added as SET FILE SEND AUTO and SET FILE RECEIVE
8-BIT.
--Keith
[Ed. - Good idea, will probably be added to the next release.]
------------------------------
End of Info-Kermit Digest
*************************
-------