Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!slacvm!wglp09
From: WGLP09@SLACVM.SLAC.STANFORD.EDU
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Jr-Comm 1.02
Message-ID: <91157.112156WGLP09@SLACVM.SLAC.STANFORD.EDU>
Date: 6 Jun 91 19:21:56 GMT
References: <676066596.2@kcufgat.fidonet>
Organization: Stanford Linear Accelerator Center
Lines: 21

Jody -
         When you say "when it scrolls it flickers" you probably mean that
when you have it set to color mode (I don't know JrComm, so I have no idea
what its functions are) that when it scrolls, for a brief moment the
text turns a different color?
         If that is the case, there is no fix that can be made in JrComm,
or any other terminal package. The reason is that the scroll is done one
bitplane at a time, and if the text occupies two or more bitplanes (as in
colors 3, 5, 6 and 7) you see the effect of first one bitplane being scrolled
and then another.
         This may however be fixable by the following trick: there is a program
called CPUBlit, which replaces BltBitMap by a function that uses the CPU
instead. CPUBlit calculates if it is faster to do the blit with the processor
or the blitter, and if it decides to do it with the processor, then it does
the scroll from top to bottom, all bitplanes at the same time (well, more or
less). If JrComm doesn't do any funny stuff but uses the standard ScrollRaster,
and if CPUBlit is set to do blits by CPU, then the flicker is gone.
So you might want to try that. Alternatively, use only colors 1, 2 and 4,
since they only use one bitplane and therefore won't flicker.

        Willy.