ajbrouw@ecl001.UUCP (Albert-Jan Brouwer) (05/18/91)
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. 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. 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; 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. 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. Sounds too good to be true eh? Probably is. Hope = Pain. Will someone torpedo this please.... -- 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
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (05/19/91)
In article <ajbrouw.3618@ecl001.UUCP> ajbrouw@ecl001.UUCP (Albert-Jan Brouwer) writes: >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. Surely possible but it is much easier to use VRAMs for that. Instead of generating chip bus cycles to fetch display data one uses the shift registers. Of course this has the problem that one can't interleave the cycles for the bitplanes. One would need an extra scanline buffer to gather all bits for a line before sending them to the palette. This is a bit similar to one of the Intel graphics processors (82768 ?) although this one didn't use dual-ported RAMs. This technique would have a second consequence: the cycle time would be independant of the video shift frequency. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
svante@kberg.se (Svante Gellerstam) (05/21/91)
In article <ajbrouw.3618@ecl001.UUCP> 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
andreww@uniwa.uwa.oz (Andrew John Williams) (05/23/91)
svante@kberg.se (Svante Gellerstam) writes: >I would like to say that the highest hurdle to come over is the >bitplane concept. Why bother? Bitplanes generally gives higher video bandwidth (just look at Nat Semi's graphics chipset) and more importantly more processor - memory bandwidth (If its done right - the processor sees 1 bit/pixel and the hardware sorts out the rest) John West (stealing Andrew's account) ten green fish sitting on a wall (or was that pink fish?)
markv@kuhub.cc.ukans.edu (05/24/91)
In article <1991May23.045536.1208@uniwa.uwa.oz>, andreww@uniwa.uwa.oz (Andrew John Williams) writes: > svante@kberg.se (Svante Gellerstam) writes: > >>I would like to say that the highest hurdle to come over is the >>bitplane concept. > > Why bother? Bitplanes generally gives higher video bandwidth (just look > at Nat Semi's graphics chipset) and more importantly more processor - > memory bandwidth (If its done right - the processor sees 1 bit/pixel and > the hardware sorts out the rest) I disagree to some extent. The relative merits of "chunky pixel" versus bitplanes depends on the kind of work being done. For area drawing, filling, raster bitmaps being moved in whole, etc. the bitplane system is better because you can optimize things and only change certain bitplanes. However, for line drawing (esp non vertical/hoizontal), object graphics, and other mostly single pixel manipulations the chunky pixel is better from the CPUs point of view. Take for instance a WritePixel() function. It might have to access one bitplane, or it might have to access all. Plus, since there are several bits per byte, it must read and write each plane. With Chunky pixel mode, it only writes one byte and its done. (Assuming an even byte bit count per pixel). If you do some simple profiling and best/worse/average case scenarios, you'll see that the more bitplanes you have (ie: 12,18,24 bit systems), the worse bitplanes are versus chunky pixels. Finally, Commodore themselves have "endorsed" chunky pixels since that's what the 2610 uses (assuming it ships before computers become sentient and dont need it anymore :-)). As for the discussion on CHIP architechures, simply modifing CHIP RAM to use VRAMs and Denise to take her DMA from the serial shift lines would drastically speed up drawing, since the CPU and Blitter would get massivlely increased available bandwidth (esp in higer res/color modes). > John West (stealing Andrew's account) > ten green fish sitting on a wall (or was that pink fish?) > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/24/91)
In article <1991May23.121032.31010@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: > > [Some well balanced arguments of bitplanes vs "chunky pixels" deleted] > >As for the discussion on CHIP architechures, simply modifing CHIP RAM >to use VRAMs and Denise to take her DMA from the serial shift lines >would drastically speed up drawing, since the CPU and Blitter would >get massivlely increased available bandwidth (esp in higer res/color modes). But I fear VRAMs are not possible, because Denise not only fetches the normal video data from Chip-RAM (this could indeed also be taken from VRAMs), but it also must display sprites and fetch their data from quite different places, so the VRAM mechanism is impossible for this. Also all the copper actions (copper list fetched from Chip-RAM!) are certainly at least difficult to implement on VRAM/Denise combinations. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
andreww@uniwa.uwa.oz (Andrew John Williams) (05/27/91)
>But I fear VRAMs are not possible, because Denise not only fetches the >normal video data from Chip-RAM (this could indeed also be taken from >VRAMs), but it also must display sprites and fetch their data from quite >different places, so the VRAM mechanism is impossible for this. Also all >the copper actions (copper list fetched from Chip-RAM!) are certainly >at least difficult to implement on VRAM/Denise combinations. Surely sprites could be read out as normal (how much bandwidth could they possibly use) and mixed in with the signal after it leaves the VRAMs. Copper operations could get interesting - I'll agree with you there. John West (stealing Andrew's account) where have all the fish gone?
daveh@cbmvax.commodore.com (Dave Haynie) (05/29/91)
In article <1991May23.121032.31010@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >In article <1991May23.045536.1208@uniwa.uwa.oz>, andreww@uniwa.uwa.oz (Andrew John Williams) writes: >> svante@kberg.se (Svante Gellerstam) writes: >>>I would like to say that the highest hurdle to come over is the >>>bitplane concept. >> Why bother? Bitplanes generally gives higher video bandwidth (just look >> at Nat Semi's graphics chipset) and more importantly more processor - >> memory bandwidth (If its done right - the processor sees 1 bit/pixel and >> the hardware sorts out the rest) >I disagree to some extent. The relative merits of "chunky pixel" >versus bitplanes depends on the kind of work being done. >If you do some simple profiling and best/worse/average case scenarios, >you'll see that the more bitplanes you have (ie: 12,18,24 bit systems), >the worse bitplanes are versus chunky pixels. Again, it depends on the job and the hardware. In the aforementioned NS RGP8500 architecture, you have a separate blitter subsystem per bitplane. So the time it takes to draw a pixel, do a blit, draw a line, etc. is independent of the number of bitplanes; 10, 24, 100, it doesn't matter. Certainly, a few operations in this architecture, namely single pixel modification, are more expensive than an evenly packed pixel system. For example, an simple pixel write operation in a packed pixel system could be done with a single write, assuming the pixel depth is less than or equal to the size of the machine word. Doing the same write operation requires a read modify write cycle for the bitplane machine, one per bitplane. If these are all done in parallel, that's only twice as long as for the packed pixel machine. Logical operations on each system still require a read modify write cycle. This isn't, in any case, what's currently being done in the Amiga system. But a bitplane architecture does lend itself to obvious parallelism, while a packed pixel architecture does not. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.