[sci.electronics] Questions about building a graphics system.......

naivar@hc.UUCP (06/05/87)

	Hi there. I'm thinking about designing a graphics system around
the "hot new" graphics processor from AMD: the Am95C60 Quad Pixel
Dataflow Manager (QPDM) and I have a few questions for all you graphics
"experts" out there. But first, let me explain the basic layout of the
system I have in mind. The system will consist of the QPDM, from 2-4
Megs of VRAM and a color palette. Not really sure just how many bit-planes
I'm gonna end up using: probably 8. Right now the plan is to connect the
whole thing to a SUN, but who knows? But anyway, here's what I need to
know (pardon my ignorance, but this is all new to me.):

		1. From what I've read so far, it seems that the
		   speed you run the graphics processor at is
		   independant of the resolution obtainable. Is
		   this true? Is the shift speed of the VRAMs
		   and/or the color palette the only things that
		   determine resolution?
		
		2. Is it fairly easy to make VRAMs out of "normal"
		   RAMs by adding data serializers? What are the pro's
		   and con's of doing this?

		3. Are there any good books or magazines out there that
		   would be helpful for this project? Especially the
		   nitty-gritty details of the proper signals required
		   to generate an image on a graphics screen, and maybe
		   even timing diagrams of vsync, hsync and blank.

		4. What are the things I really have to look out for
		   when designing a system of this sort? I'd really
		   not have to find all the pitfalls by experiencing
		   them myself.

		5. Eventually, I hope to add some sort of processor to
		   the system to allow animation. Is there some sort of
		   "standard" command set for animation processors?

		6. Any other stuff you think I may be overlooking or
		   that will give me problems later on.

	Right now I'm kinda being overwhelmed by all these new concepts.
Any references to books would be great if you don't want to spend the
time trying to get the concepts through my thick head.

	Any help would be greatly appreciated. Thanks in advance, as they
	say. I've posted to several news groups (hopefully all are at least
	somewhat appropriate..) so just e-mail to me. If there is enough
	interest, I will post a summary of what I've found out. By the way,
	would there be much interest out there for a board such as the one
	I described? Just curious........  :-)

							-Mark

	naivar@hc.dspo.gov
	{ucbvax!unmvax,ihnp4!lanl}!dspo!naivar

einstein@vmix.UUCP (Fredric J. Einstein) (06/09/87)

In article <4332@hc.DSPO.GOV>, naivar@hc.DSPO.GOV (Mark A. Naivar) writes:
> 
> 
> 	Hi there. I'm thinking about designing a graphics system around
> the "hot new" graphics processor from AMD: the Am95C60 Quad Pixel
> Dataflow Manager (QPDM) and I have a few questions for all you graphics
> "experts" out there. But first, let me explain the basic layout of the

	I am using a four plane board based on the AMD QPDM (I wrote an
MS-WINDOWS driver for it.  The current state of the QPDM involves some 
VERY serious software bugs that won't be fixed till AT LEAST November, 1987.
Among these bugs are the inability to write bitmap data from the host to
the graphics board and to read back bitmap data from the board due to bugs
in the chip's firmware.  Although the chip is incredibly fast and easy to
write software for (especially MS-WINDOWS and DRI GEM drivers -- I've written
them for INTEL '786, TI-34010, and the VMI PGL interfaces), these bugs really
throw a spanner into the works.  If you don't care about these SERIOUS bugs
having to do with bitmap data, the AMD is a great, fast and flexible (if not
cheap) graphics co-processor.  As far a speed is concerned, the biggest 
bottleneck in any PC-based graphics system is the board communication with 
the host.  Number of planes etc make little difference except for the 
number of bytes that must be transmitted between the host and the graphics
engine.  I don't know anything about the SUN, but on the IBM-AT bus, this
is what really slows everything down.

Fred Einstein