Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!ubc-cs!alberta!calgary!enme3!deraadt From: deraadt@enme3.ucalgary.ca (Theo Deraadt) Newsgroups: comp.sys.amiga.tech Subject: Re: Denise/Paula/Agnus/Gary/Portia Keywords: Puff the majik dragon Message-ID: <1706@cs-spool.calgary.UUCP> Date: 13 Aug 89 06:10:05 GMT References: <1388@bnr-fos.UUCP> <1671@cs-spool.calgary.UUCP> <19145@usc.edu> Sender: news@calgary.UUCP Reply-To: deraadt@enme3.UUCP (Theo Deraadt) Organization: U. of Calgary, Calgary, Alberta, Canada Lines: 71 In article <19145@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >In articleI wrote: >>...display twice as much 16bit bitplane solution. Greater pipelining or >>extensive fifo usage could make it even better. >Of course, VRAMs would be nice as well since they have the fifos built in. You mean shift registers, not fifos. A video ram, like a dram, has rows of columns of bits. It also has an extra column which happens to be a shift register. Based on some timing signals that the VRAM has coming in, such as DOTCLOCK, VBLANK, HBLANK, etc.. it will grab a column out of the memory, into the shift register and shift these bits out, straight to your CLUT (Color LookUp Table). This shifting happens automatically, you don't have to make it shift, it just shifts out pits. This is very convenient for pixel packing. It can also be used for bitmapping I think. >>On the 340x0, it's a little different. If you have one bit/pixel it works >>the same. If you have two bits/pixel, then two consecutive bits in memory >>generate a pixel. If you have 16 colors, you have 4 consecutive bits >>to a pixel. Because the shifting gets icky, you don't get non power-of-two >>bits/pixel. Shifting 3 bits at a time out of a 16bit word gets messy >>when you get to the end of the word :-) It is easier to build video >>shifting circuitry for pixel packing. >The bitplane method gives the Amiga much more flexibility in memory >consumption. Sorta true. For any resolution with a power of two bits/pixel, bitplaned and pixel packed memory architectures use the same amount of memory. If you only needed 5 bit video, you would waste 3 bits/pixel of ram. >Building video shifting circuitry for bitplane method is not so ugly because >of the consistency between working with various numbers of bits per pixel. >Video shifting a pixel packed architecture with variable bits per pixel is, >on the other hand, rather ugly since it has to unpack in different ways. Shifting pixel packed video out is easier. You have one DMA circuit, with one complicated shift register. With bitplaning, you need multiple DMA circuits, with simple shift registers. I would not call either ugly, just better for certain things. >>There is a National graphics chip set [not sure about availability] that >>has a super blitter/display chip for each bitplane, the entire architecture >>is 32bit, and has a full graphics processor. I looked at a 10 or so page >>pamphlet on it, and it certainly was impressive. THIS THING HAD EVERYTHING, >>but it probably takes up a ton of board space.. the main processor had >>50ns cycles for some stuff... >Could you summarize the pamphlet? I will get it off the friend that has it, send me mail if you want info on it.. >Everytime I think about image processing with a bitplane approach I get >discouraged. In that case, I'd prefer 8 bits per color component available >in one byte. (Yes, and an 8 bit alpha channel, too! How about 12 bits per >channel so I can handle overflow? And enough memory for, say, 32 million >pixels?) Furthermore, it's a bit easier to do anti-aliased fonts. Of >course, you'd want some sort of convolver on it. Yes, but it is worth in a small system of losing the capability to do 5 bit video? We are designing a board that does 800 pixels across at 8bit each. The memory is arranged 64 bit wide, and it's 100ns ram. To be able to interleave our main processor and our drawing processor, we needed to do that. Not many a home system has that much memory bandwidth. Oh sorry, when we run in 800x8bit mode, the drawing processor gets not memory slices except during vblank and hblank... In 800x4 mode it does though.. >Would the National chip be better suited? To attempt to clone the functionality that the Amiga offers, I guess yes. The National has no sprites, but it's probably fast enough to fake them with blits. Copper lists are out, screens can be faked by memory copies, you get the idea.. actually it might do screens..