Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!gnh-starport.cts.com!scottg From: scottg@gnh-starport.cts.com (Scott Gentry) Newsgroups: comp.sys.apple2 Subject: Re: Stellar 7 re-release Message-ID: Date: 12 Jan 91 02:19:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 X-Unparsable-Date: Thu Jan 10 91 at 11:06:25 (EST) This isn't really to David, this is to Brian Willoughby (who is generally very correct in most of his posts)... In one that got by, he said... >I think that you are overlooking a detail in the design of the GS. >Multiple palettes are enabled by setting an interrupt bit for >individual scan lines. This interrupt does, in fact, take CPU time >to handle, as all 16 color registers must be loaded for the new >palette. Just because all of this is set up by the system and not by >your own code does not mean that it is totally free. There is a CPU >time price. Moving from 320X200 with 16 colors to 320X200 with 256 >colors takes CPU time. Brian, sorry, but I wasn't overlooking anything. Others have responded with correct answers, so I'll leave it at that. I do think you should read your hardware reference manual. The overhead is all taken care of by the hardware with the exception of the individual SCB setup. Once the SCB's have been set, display is transparent to the application -- in most cases. The only applications that have to worry about the actual color in the palette pointed to by the SCB are those that create graphics in the multiple palette environment. Anyrate, have a nice day! _______________________________________________________________________________ | Scott Gentry * ALPE AFL Scott * I never said that!| | 2051 Mercator Drive * GEnie W.GENTRY * But you never | | Reston, VA 22091 * UUCP: uunet!ingr!ne1300! * know! | | (703) 264-5652 * brnded!scott * Do You? | |_____________________________________________________________________________|