Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!rochester!kodak!uupsi!sunic!lth.se!kberg!svante From: svante@kberg.se (Svante Gellerstam) Newsgroups: comp.sys.amiga.hardware Subject: Re: Breaking through the chip-bus barrier? Message-ID: <1991May21.081806.2668@kberg.se> Date: 21 May 91 08:18:06 GMT References: Organization: Karlberg & Karlberg AB, Lund, Sweden Lines: 92 In article ajbrouw@ecl001.UUCP (Albert-Jan Brouwer) writes: > There are two more or less fundamental limitations that are holding back >our beloved Amiga platform from entering the the 12/24 bit graphics era. > >First of all the system software is "hard-wired" to the custom chip set. >Making the graphics.library device independant will take atleast another >couple of years, if at all possible. Ofcourse in due time there will be >libraries that support the various add-in graphics boards, but this >implies that applications will have to be customized to make use of >these. I expect that the graphics.library could be rewritten to use most any graphics card. But, as you say, most system software is 'hard-wired' into the 'custom chip set' architecture. I would like to say that the highest hurdle to come over is the bitplane concept. It is a fact that most cheap gfx cards uses the 'chunky' concept (one or three byte/bytes per pixel). These will have a hard time working with all sorts of images todays apps uses which are in bit plane format (ie struct BitMap images). The ideal solution would be to have the generic graphics.library call on a display device.driver to get the work done. This would mean solving the plane vs chunky problem and the problem to add a board into the system (as we add hard disks today). There is also the problem of colors - color table vs direct and the desirable handling of gamma correction etc. The first step to make this possible would be to add ONE flag to the system BitMap structure to tell if it was pointing to a plane or chunky image. Then the world of cheap graphic architectures would open up to the Amiga. The next problem would be to rework the graphics.library into device dependance. >So if upgraded graphics are going to be transparent to applications, and >arrive somewhere in the foreseeable future, there HAS to be backwards >compatibity with the old chipset. My discussion above shows (to me :-) that the worst thing that could happen is the creation of a standard that is many years old compared to todays competition. This would mean that the card manufacturers would have to spend much time on the special interface. And the Amiga would be limited to 12 bit colormapped color. >That's were the second problem comes into play; limited chip bus bandwidth. >What I want to propose here is a possible way around this problem; You're absolutely right! The only way out of this is to let the graphics card do its work in its own optimized memory, using whatever accelerator available. It simply is not professionally possible to produce 24-bit real time color graphics of any resolution out of the current chip ram architecture. >Imagine a new Denise (graphics chip) that would snoop the chip bus and >maintain a mirror copy of the entire chip memory range. F.e. a small >board that plugs into the Denise socket and sport the new Denise and >2MB DRAM. All writes to chip memory would get copied into the mirror >chip memory. The new Denise could then fetch all bitplane data from this >mirror memory without taxing the chip bus. Urrrp! (Sorry.) >So this Denise could theoretically display upto 12 bitplanes in hires. >More wouldn't do any good because we'd still be stuck with the 4 bit >RGB DACs. > >So here we have a backwards compatible graphics engine. It works with the >old custom chips, blitter, agnus..., it can be added to any Amiga, it >is supported by the system software with only minor extensions meeded >to make use of the additional bitplanes/colours. And it is highly specialized and very limited. Picture quality would be like HAM+ in highrez and too slow. What you have is really a graphics subsystem with its own memory working like a slave to be compatible. I don't like it. It's too specialized. >Sounds too good to be true eh? Probably is. Hope = Pain. Will someone >torpedo this please.... All ideas leading out of the current hole in the ground (graphics wise) are good. We need this discussion. Anyone willing to comment on the feasibility of my concept (I haven't seen anyone advocating for a similar approach yet)? >Albert-Jan Brouwer "Pro is to con as progress is to Congress." >Pelt Computers OudeDelft 121, 2611 BE Delft, The Netherlands >Tel: +31 15 143824 FAX +31 15 146916 >UUCP hp4nl!cbmnlux!ecl001!ajbrouw -- Svante Gellerstam svante@kberg.se, d87sg@efd.lth.se