Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!csd4.csd.uwm.edu!leah!rpi!pawl!shadow
From: shadow@pawl.rpi.edu (Deven T. Corzine)
Newsgroups: comp.sys.amiga
Subject: Re: Denise/Paula/Agnus/Gary/Portia
Message-ID: 
Date: 18 Aug 89 10:02:53 GMT
References: <1388@bnr-fos.UUCP> <713@neptune.UUCP>
	<8566@batcomputer.tn.cornell.edu> <3036@bucsb.UUCP>
	<15769@watdragon.waterloo.edu> <506@tardis.Tymnet.COM>
	<13167@well.UUCP>
Sender: usenet@rpi.edu
Distribution: comp.sys.amiga
Organization: Rensselaer Polytechnic Institute, Troy, NY
Lines: 73
In-reply-to: farren@well.UUCP's message of 16 Aug 89 18:09:26 GMT


On 16 Aug 89 18:09:26 GMT, farren@well.UUCP (Mike Farren) said:

Mike> The problem with the proposed scheme is that it wins you little
Mike> over the current scheme.  Blitting images is not done on a line
Mike> by line basis - if it were, the blit might be a little cleaner,
Mike> but would be one hell of a lot slower, as the overhead involved
Mike> in setting up the blitter for each line transfer would be
Mike> immense.  Making CHIP RAM out of 60ns chips and doubling the
Mike> blitter's transfer rate would help a lot more...  at a price.

Huh?  The proposed scheme sounds like it would work beautifully.  The
whole point of the matter was that the problem was multiple bitplanes
being disjoint with respect to specific lines...  One bitplane the
text of a line is on the new line while the other(s) are on the old
line...

The proposed scheme was to make one large bitplane (as far as the
blitter is concerned) and manipulating the Copper to display the
bitplanes, resetting the address for each line.  This way you get this
sort of layout:

         <---------- layout in memory --------->

        +---------+---------+---------+---------+
        |         |         |         |         |
        |         |         |         |         |
        |         |         |         |         |
        +---------+---------+---------+---------+

         <--bp0--> <--bp1--> <--bp2--> <--bp3-->

At the beginning of each scan line, the display address would be reset
by a Copper interrupt to the next scanline in the bitplane.  Given a
screen, resolution x by y, number of bitplanes n=3, length of a
scanline in bytes len, and starting address addr, organized as in the
above figure.  Starting scanline addresses would look as follows:

        Bitplane        Scanline        Address
        --------        --------        -------
        0               0               addr
        1               0               addr+len
        2               0               addr+2*len
        0               1               addr+3*len
        1               1               addr+4*len
        2               1               addr+5*len
        .               .               .
        .               .               .
        bp              line            addr+(bp+line*n)*len
                  number of bitplanes=3 --------------^

The copper would interrept the processor at every scanline to reload
the address registers, as the address of the next scanline would
otherwise point to what is actually the same scanline in the next
bitplane.

Now, to scroll, the blitter is told to scroll a region starting at addr,
len*3 bytes wide and y lines long vertically by the height of a line
of text.  It doesn't matter to the blitter that the region is not
displayed as a single bitplane.  If the size of that region is too
large for the blitter to handle at once, split it into several
requests.  Regardless, the blitter will scroll the region(s) smoothly,
without disjoint text.  Which was the idea behind the whole thing in
the first place...

I hope this makes things clearer for someone.

Deven
--
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2214 12th Street, Troy, NY 12180       Phone:  (518) 271-0750
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.