Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hpcc01!hpcuhb!hpcuha!nicholso From: nicholso@hpcuha.HP.COM (Ron Nicholson) Newsgroups: comp.sys.amiga.hardware Subject: Re: Cost of color (was: Bitplanes - good or bad) Message-ID: <13700001@hpcuha.HP.COM> Date: 10 Apr 90 19:53:05 GMT References: <5917@tekig5.PEN.TEK.COM> Organization: Hewlett Packard, Cupertino Lines: 35 In <13580@spudge.UUCP> johnm@spudge.UUCP (John Munsch) writes: >It's small consolation, but when Jay Miner came to talk to the Mid Cities >Commodore Club a while back he said that if he had it all to do over again he >would have made the whole thing pixel oriented rather than bitplane oriented. >Sigh... Alas. Designing in retrospect is so much easier... But lets look at some of the constraints that went into the design. The people who funded the venture were interested in a video game, not a personal computer. So they wanted a competitive price in the consumer marketplace. The original date of introduction was to be Christmas of 1984. Only 64k DRAMS were commodities at that time. This meant the base system was limited to 128k RAM. (and no keyboard, no disk!!!) A 640x400 16 color image would have taken all of memory. So being able to use 3 bits per pixels was seen as important. 6 bitplanes saturated the memory bus. 8 wasn't possible. Would you really want to design a video memory map with packed 3, 5 and 6 bit pixels? And with only 128k could you afford to waste memory by using unpacked pixels? The processor memory timing was so tight that an MMU had to be left out. (Also a fourth custom chip would've taken the design over budget.) The lack of any memory mapping precluded using a sparse memory map or multiple ways of addressing the same pixels. Chunky pixels? No way. But if I could design it over again today... --- Ronald H. Nicholson, Jr. Hewlett Packard uucp: nicholso@hpda.HP.COM Cupertino, CA (408) 447-6603 #include Oh goodie, a new one: 4,874,164 issued Oct. 1989 ---