Path: utzoo!attcan!uunet!steinmetz!glacier!elliott
From: elliott@glacier.steinmetz
Newsgroups: comp.sys.apple
Subject: Re: ][e enhancement
Message-ID: <11295@steinmetz.ge.com>
Date: 20 Jun 88 14:38:13 GMT
References: <steinmetz!glacier!elliott@itsgw.rpi.edu> <8806191034.aa04168@SMOKE.BRL.ARPA>
Sender: news@steinmetz.ge.com
Reply-To: elliott@glacier.steinmetz.ge.com ()
Organization: General Electric CRD, Schenectady, NY
Lines: 51

In article <8806191034.aa04168@SMOKE.BRL.ARPA> 22149853@WSUVM1.BITNET (Duane Wessels) writes:
>>>   I just got my old ][e updated to an enhanced ][e.  The reason was so
>>>that I wouldn't lose characters when the screen had to scroll.
>>
>>That seems a very strange reason to get enhanced... No decent terminal
>>program would lose characters while scrolling!
>
>   Thats what I thought!  Unfortunately, its not up to the termial program.
>I tried several and they all had that problem.  The problem was definately
>in the ROMS that I had.  As near as I can tell, whenever a the first character
>of a new line was sent to the screen, the ROMS said "geez, I have to scroll
>the screen now!"  While the CPU was busy doing that, any incoming data was
>simply lost.  I always managed to get the first character of a new line, and
>miss the next 4 or 5.

While it is true that the firmware (ROM) scroll routines are slow,
ugly and inefficient, and any program silly enough to use them for
Screen I/O while doing non-interrupt-driven I/O on a serial port will
lose characters during scrolling, my statement is still true: No
decent terminal program loses characters during scrolling.

There are two ways to solve the problem: The first is to include
better screen I/O code in the program, which is faster and also polls
the card frequently, so that even when scrolling, incoming characters
are buffered. Totally ignoring the ROM screen I/O code is actually a
good idea.

The second option is to write an interrupt handler and turn on
interrupts in the serial card. This way, whenever a character comes in
over the serial port, NO MATTER WHAT ELSE MAY BE HAPPENING, it will be
buffered by the interrupt handler, to be processed later. (Actually,
if you are going to be doing disk I/O you have to be even more
careful. But that is a whole other story).

Any responsible terminal program MUST do one of these two things if it
is to be useful at 2400 baud (probably even lower baud rates) on a
//e.

I've written two terminal programs which work perfectly fine at 19,200
baud on an unenhanced //e, so I feel qualified to make the above
statements. The second program is now documented, and as soon as I add
//gs support, I will be making it available as ShareWare (probably
later this week).

 .     .    .    .   .  . ... .  .   .    .    .     .    .   .   .  . ... . .

 Jim Elliott                       /    ...!seismo!uunet!steinmetz!crd!elliott
                                  /
 "Don't look, son, it's          /      Jim_Elliott%mts@itsgw.rpi.edu [school]
  a secular humanist!"          /  (or)     elliott@ge-crd.arpa	      [work]
 .     .    .    .   .  . ... .  .   .    .    .     .    .   .   .  . ... . .