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.