Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!princeton!phoenix!kadickey
From: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey)
Newsgroups: comp.sys.apple2
Subject: Re: ProTERM vs. Sys 5.0.3
Message-ID: <4979@idunno.Princeton.EDU>
Date: 31 Dec 90 01:43:46 GMT
References: <20207.netnews.info.apple@pro-novapple> <5570@sage.cc.purdue.edu>
Sender: news@idunno.Princeton.EDU
Organization: Princeton University, Princeton, New Jersey
Lines: 22

In article <5570@sage.cc.purdue.edu> ericm@sage.cc.purdue.edu (Eric Mulholland) writes:
>ProTerm is one great program with one big flaw (in my option).  The authors
>decided to POLL the serial port instead of using INTERUPTS to grab the data.
>As you have pointed out, as long as there is no interupt driven routines
>running in memory, ProTerm is able to recieve all the data.  With interupts
>going off all over, this spreads the time between ProTerm's polling, causing
>it to miss data.  If the authors of kermit can do it (thanks!) then why
>can't ProTerm; it's obvious that they have the talent.

ProTerm does not poll the serial port on the //gs.  I've looked at the
code. It definitely uses interrupts.

What it does do, however, it replace the entire interrupt code of the
//gs with its own.  That is, it bypasses the short routine in ROM that
tries to deal with AppleTalk quickly, and inserts some of its own code
in front of it.  This will cause AppleTalk to lose data.  I believe they
insert their routine here for BETTER interrupt performance, but instead
it seems to get worse if it has to share interrupts with other devices.
I haven't quite tracked down why.

Kent Dickey
kadickey@phoenix.Princeton.EDU