Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Reactions to IBM PC2 graphics
Message-ID: <1673@cbmvax.cbmvax.cbm.UUCP>
Date: Mon, 13-Apr-87 15:57:28 EST
Article-I.D.: cbmvax.1673
Posted: Mon Apr 13 15:57:28 1987
Date-Received: Wed, 15-Apr-87 03:40:28 EST
References: <10726@topaz.RUTGERS.EDU> <1964@hoptoad.uucp> <541@neoucom.UUCP> <739@sputnik.tc.fluke.COM> <662@batcomputer.tn.cornell.edu>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 32
Keywords: VGA Killer graphics

In article <662@batcomputer.tn.cornell.edu> kagle@tcgould.tn.cornell.edu.UUCP (Jonathan C. Kagle) writes:
>
>	Why would 256 colors require much greater bandwidth? Remember that the
>256 color mode is only available in low-res (320 horiz) mode. Hmmm.  Isn't
>that the same amount of data as a 640 horiz. 16 color screen? Sure, 8 bitplanes
>could cause problems, but two 4-bit high-res. pixels could be combined to yield
>an 8-bit result.  Of course, this would create ugly bitmaps, but it's better
>than being put down by PC owners (choke).  This hypothetical chip wouldn't 
>require more address lines than the current one, so it could be retrofitted on
>existing A1000, A2000, and A500 :-)  models.  

True, it would require the same bandwidth as 640/4 bitplane hi-res.  At this
point though, you've traded off many of your available CPU cycles for display
refresh.  The big problem is that it would require 8 times the size of the
color lookup table.  In addition to chewing up a lot of high-speed silicon
area on the chip, this would required some kind of paging kludge to address
the color table in the current register addressing scheme.

>	Although a similar chip has probably already been pondered by Commodore,
>perhaps the PS/2 might get it into production.

We're thinking about a lot of things.  Understand that when it comes to custom
IC's it takes many months to get from thought to working chips.

Anybody who has some neat ideas should suggest them now, but please be sure
to consider all the system implications, including memory bandwidth, hardware
compatibility, software compatibility and incremental cost.  At least that's
what we have to do at this end...
-- 
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)