dales@pro-novapple.cts.com (Dale Smith) (12/28/90)
In-Reply-To: message from whitewolf@gnh-starport.cts.com
Tae, I am puzzled as I run ProTERM out of System 5.0.3 ALL the time and never
have character loss EXCEPT when some DA or INIT comes along that I try only to
find that it's playing with the interrupts causing character loss -- BLAM!!
it's gone. I will not tolerate anything in my system that adversely affect
ProTERM. Anyway, when in ProTERM you're not running under GS/OS -- but I'm
sure you knew that.
I have found that Control Panel NDA, FontDA.Installer NDA, BRK Cursor INIT,
FasText INIT, GraphSpeed INIT, and Shadow INIT do not conflict with ProTERM.
But some of the RAM5 drivers (RAMdrive.Manager CDA and /RAM5.Driver) do
conflict, anything that does timing (Twilight, screen blankers, etc.) and such
all play with interrupts in ways that ProTERM can't handle. Even El Macro CDA
has a conflict - too bad it would be nice to have that to make up for the lack
of macros in the PT Editor, but I can't have it conflicting.
Later ...
- Dale -
proline: pro-novapple!dales
uucp: crash!pro-novapple!dales
arpa: crash!pro-novapple!dales@nosc.mil
Internet: dales@pro-novapple.cts.com
Northern Virginia Apple Users Group >pro-novapple< 703-671-0416/300-2400 baud ericm@sage.cc.purdue.edu (Eric Mulholland) (12/30/90)
In article <20207.netnews.info.apple@pro-novapple> dales@pro-novapple.cts.com (Dale Smith) writes: >In-Reply-To: message from whitewolf@gnh-starport.cts.com > >Tae, I am puzzled as I run ProTERM out of System 5.0.3 ALL the time and never >have character loss EXCEPT when some DA or INIT comes along that I try only to >find that it's playing with the interrupts causing character loss -- BLAM!! > >all play with interrupts in ways that ProTERM can't handle. Even El Macro CDA 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. -- ____ Y_,_|[]| Eric Mulholland {|_|_|__| ericm@sage.cc.purdue.edu //oo--OO ...!pur-ee!sage.cc!ericm
jb10320@uxa.cso.uiuc.edu (Desdinova) (12/31/90)
In article <20207.netnews.info.apple@pro-novapple> dales@pro-novapple.cts.com (Dale Smith) writes: >In-Reply-To: message from whitewolf@gnh-starport.cts.com > >Tae, I am puzzled as I run ProTERM out of System 5.0.3 ALL the time and never >have character loss EXCEPT when some DA or INIT comes along that I try only to >find that it's playing with the interrupts causing character loss -- BLAM!! >it's gone. I will not tolerate anything in my system that adversely affect >ProTERM. Anyway, when in ProTERM you're not running under GS/OS -- but I'm >sure you knew that. Gee, sounds like it's time for you to get a more modern term program, perhaps one that runs under GS/OS. >I have found that Control Panel NDA, FontDA.Installer NDA, BRK Cursor INIT, >FasText INIT, GraphSpeed INIT, and Shadow INIT do not conflict with ProTERM. >But some of the RAM5 drivers (RAMdrive.Manager CDA and /RAM5.Driver) do >conflict, anything that does timing (Twilight, screen blankers, etc.) and such >all play with interrupts in ways that ProTERM can't handle. Even El Macro CDA >has a conflict - too bad it would be nice to have that to make up for the lack >of macros in the PT Editor, but I can't have it conflicting. What speed is your modem running at? I ran 9600 baud with ZLink and never lost characters, even with about 20 NDAs, 20 CDAs, bunches of INITs, and CDEVs. Never had a problem. I would suspect ProTERM is the problem, no the other components of the system. > - Dale - >Internet: dales@pro-novapple.cts.com -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (12/31/90)
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