Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pucc-i
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!CS-Mordred!Pucc-H:Pucc-I:ags
From: ags@pucc-i (Dave Seaman)
Newsgroups: net.micro.apple
Subject: Re: IIe Termcap; Bug in the 80 Col Monitor.
Message-ID: <828@pucc-i>
Date: Tue, 22-Jan-85 10:10:47 EST
Article-I.D.: pucc-i.828
Posted: Tue Jan 22 10:10:47 1985
Date-Received: Thu, 24-Jan-85 07:04:14 EST
References: <287@boulder.UUCP>
Distribution: net
Organization: Purdue University Computing Center
Lines: 29

>  II:  (FLAME) I have been using my IIe to communicate with our local system at
>  1200 baud for a year now, and have had real frustrations with
>  the slowness of the Apple Monitor. I need to pad linefeeds with
>  three nulls to keep the monitor from dropping one to three characters
>  at the beginning of lines. 

The "slowness of the Apple Monitor" is not the problem.  It's the Apple
hardware.

Scrolling the screen on an Apple involves moving 23x80 characters in memory.
This requires about 3700 memory references.  There isn't time to do this
in the 8.3 milliseconds that you have between characters arriving on a
1200 baud line, even if you don't bother with such things as branching
and incrementing.
  
>  What is most irritating about this is an attitude on the part of
>  the customer service people that if there is no currently available
>  fix to the problem, that the problem isn't a problem, it is an
>  undocumented feature.

It's more like a documented non-feature.  The Apple monitor does not
actively support interrupts, which are the only solution to the problem.
On the other hand, the hooks are available so that user programs can do
their own interrupt processing.  One of the reasons most terminal programs
do not do this is that most communications cards do not adhere to the
Apple standards for interrupt handling, which were established rather
late in the game.  See the Apple //e Reference Manual.
-- 
Dave Seaman			 ..!pur-ee!pucc-i:ags