Newsgroups: comp.sys.laptops
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!quimby
From: quimby@madoka.its.rpi.edu (Quimby Pipple)
Subject: Re: kermit at 9600 baud
Message-ID: <cqsh6_f@rpi.edu>
Nntp-Posting-Host: madoka.its.rpi.edu
Reply-To: quimby@mts.rpi.edu
References: <1991May31.163425.13075@jade.uucp>
Date: 4 Jun 91 00:51:36 GMT
Lines: 28

Well, today I spent some time playing around with our new toy.  It's
an Everex Tempo LX, 386SX/20, 1 Meg, 60 Meg -- pretty similar to the
machine that was dropping characters.

I don't think the problem is with the Everex's ability to receive at
9600, as ours doesn't seem to have any trouble with receiving/displaying
text or file transfers at 38.4k with MSKermit.  (At 38.4k a file listing
scrolls by as a very fast blur.  No retries while transfering.)  It also 
works interactively at 38.4k as a terminal into PCAnywhere with most DOS 
applications.  I was able, however, to coax it into receive overuns
by running "split window" Word Perfect, through PCAnywhere, at 38.4.
Here's what happens:  MSKermit uses the BIOS to read the keyboard.  While
the keyboard interrupt is being serviced, and the display written to, the
buffer can overflow if the remote device sends several characters at once,
and the user types very quickly.  The work around seems to be to enable the 
shadow RAM for BIOS and video RAM in setup.  (Note that you have to disable
the mapping of the 384k 'missing' memory, too.)  Most desktop 386's
has shadow RAM enabled as default, but in a notebook most people would
probably rather have the extra 384k instead of shadow RAM.

Hope this solves your connection problem, please let us know how it
works out.
  
Quimby
 
-- 
quimby@mts.rpi.edu, quimby@rpitsmts.bitnet

