Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!cbmvax!grr
From: grr@cbmvax.cbm.UUCP (George Robbins)
Newsgroups: comp.sys.amiga
Subject: Re: Reactions to IBM PC2 graphics
Message-ID: <1749@cbmvax.cbmvax.cbm.UUCP>
Date: Sat, 25-Apr-87 21:26:40 EDT
Article-I.D.: cbmvax.1749
Posted: Sat Apr 25 21:26:40 1987
Date-Received: Sun, 26-Apr-87 22:21:37 EDT
References: <10726@topaz.RUTGERS.EDU> <1964@hoptoad.uucp>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 22

In article <178@s.cc.purdue.edu> ain@s.cc.purdue.edu.UUCP (Patrick White) writes:
>   Since memory is getting cheaper all the time, how about a 12 bit plane
>mode that uses three groups of 4 bits as the RGB values themselves (no color
>registers used)?  With extra address pins on the chips, this could handle
>640x400 mode without eating serious percentages of chip ram.

	Well, 8 bit planes would chew up all the available memory bandwidth
except during screen retrace, so I think 12 would require major architectural
changes.  Note that the HAM mode gives you an approximation of 12 bitplanes
in that you can get all 4096 colors up one the same screen.  Of course your
horizontal color changes are subject to some restrictions, but map fairly
well to real-world, continuous tone images.

	The other direction is, of course, to combine bitplanes to get a
hi(er)-res monochrome or n-color image.  This is needed for windowing and
computer oriented stuff, but the sales trend on the ST monochrome vs.
color screen shows that most people buy color over higher resolution
monochrome, so you don't want to give up anything to acheive this...
-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)