Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!sun!amdcad!pepsi!phil
From: phil@pepsi.amd.com (Phil Ngai)
Newsgroups: sci.electronics
Subject: Re: Frame Buffers
Message-ID: <1990Jun26.200549.792@amd.com>
Date: 26 Jun 90 20:05:49 GMT
References: <2229@mindlink.UUCP> <1990Jun26.154640.26941@utzoo.uucp>
Sender: usenet@amd.com (NNTP Posting)
Organization: Advanced Micro Devices; Sunnyvale, CA
Lines: 23

In article <1990Jun26.154640.26941@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
|Nobody in his
|right mind uses anything but VRAMs for frame buffers unless there is some
|compelling reason why they won't work for the particular application.

I wouldn't be quite so strong about that. VRAMs are a lot more expensive
than regular DRAMs, and since you can run 50 ns page mode cycles on
ordinary DRAMs, you can easily get 20 Mhz * 32 = 640 million bits/sec
or 80 million 8-bit pixels/sec out of 1 megabyte of memory (8 x 256K x 4).
That's 1.3 million pixels/frame at 60 Hz.

The shift register on 64Kx4 VRAMs typically has a minimum access time
of 40 ns. The newer 256Kx4 VRAMs push that to 30 or 25 ns.

By the way, you can probably get away without refreshing such memories.

VRAMs do have an update advantage which may or may not outweigh their
cost disadvantage. It depends to a large degree on whether you live in
a PC or a workstation world.

--
Phil Ngai, phil@amd.com		{uunet,decwrl,ucbvax}!amdcad!phil
Separate but equal: Bad for blacks, good for women.