Newsgroups: comp.sys.amiga.datacomm
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lethe!compus!cccan!entity
From: entity@cccan.uucp (Cybernetworx)
Subject: Re: Jr-Comm
Message-ID: <1991Jun20.135112.2753@cccan.uucp>
Organization: CCCAN
References: <231b3678.676527511@fergvax> <1991Jun16.020152.2331@cccan.uucp> <1472@faatcrl.UUCP>
Date: Thu, 20 Jun 91 13:51:12 GMT

In article <1472@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes:
>entity@cccan.uucp (Cybernetworx) writes:
>>An optimal solution might be to avoid the blitter altogether for moving
>>the screen, and just use a wraparound bitmap by using the copper to do
>>all the work.  The blitter/68000 could be used simply for putting the
>>characters on the bitmap.  This would definitely be the fastest solution.
>
>  A Copper list is probably the best way to go, performance-wise, since the
>major thing here is to keep chip DMA contention down to a bare minumim because
>the cpu needs some chip time in order to access the serial port which is in
>chip address space.  
>
>  An interleaved bitmap is also viable, but less so, since I have to be able
>to do a quick de-dice of the screen before I can allow Intuition to put up its
>menus.  I'd think that a Copper list that is oriented to text lines would be
>easier to do than an interleaved bitmap.
>
>  Also, the text routines would need to be customized with an interleaved
>bitmap, right?  Since WB2.0 speeds things up a good bit already, I think that
>this is less of a demand than it would have been under 1.3.
>
> Additional comments welcome...
>
 
Yep, the copperlist would present the fastest solution.  The main problem
with interleaved bitmap being the one that you pointed out regarding the
blits.  The OS doesn't support interleaved blits so you'd have to write your
own routines probably.  This is not necessarily a bad thing, since if you
went the hardware route, you could do a much faster job than the system,
*BUT* the most important thing is in the font support.  It would be
difficult for you to be able to write something so generic as to handle
all fonts etc.  Simpler to go through the system.  
 
The copperlist solution would also be relatively easy to implement I think.
You could use the OS to write the text into the bitmap, scroll using the
copper and have a moving splitscan. This way you could have the entire
thing continously wrap-around, thereby saving tons of memory.  (instead
of stepping through memory for a bit, and then jumping back to the top
since you'd have to perform a clear at the top then...) 
 
Well, I have no problems with JR-COMM since I'm only at 2400, but it 
might be something you might consider for those with 14.4k.  BTW, are your
screens double buffered at the moment?  If not, you might consider having
that as an option in one of the menus for those who have the RAM available.
 
>  -jack-


-- 
          __
    __   ///
    \\\ ///               UUCP:   ...uunet!utai!lsuc!becker!cccan!entity
 CYBERNETWORX             INET:   entity@cccan.UUCP