Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!iuvax!maytag!focsys!jack
From: jack@focsys.uucp (Jack Houde)
Newsgroups: sci.electronics
Subject: Re: Frame Buffers
Message-ID: <1990Jun26.125723.18996@focsys.uucp>
Date: 26 Jun 90 12:57:23 GMT
References: <2229@mindlink.UUCP>
Reply-To: jack@focsys.UUCP (Jack Houde)
Organization: Focus Automation Systems, Waterloo, Ontario.
Lines: 25

In article <2229@mindlink.UUCP> a575@mindlink.UUCP (Michael G. Henders) writes:
>I'm curious about how one goes about building a frame buffer for a high-res.

>actually work.  :)  BUT, how does it work with the more common x1 RAM chips??
>In this case, you access 8 chips in parallel, but you only get one pixel out of
>it, so the access interval is 14 ns; pretty quick for SRAM, and right out for
>DRAM.
>
> I guess one could bank-interleave, but, using 1 Mb chips, this means you end
>up with N times the amount of RAM you actually need, where N is the interleave
>factor; I can't see anyone actually doing this. Clearly, I'm missing something
>fundamental here; can someone tell me what it is??  Thanks much...
>
>          Mike Henders        a575@mindlink.UUCP 

You might want to look at a 256k by 32 organization. On every clock
you latch the output data and then increment to the next address. The
data is sent out at the full clock rate (somewhere near 19.69 MHz)
in chunks of 8 bits, whereas the address counter is 1/4 of that (5 MHz)
which allows for the use of standard 120 nsec DRAMS.

Anything faster than 80 nsec DRAMS would probably warrent the use
of VRAMS. The great thing about these is that they allow for the
simultaneous reading and writing of data (almost! given the horizontal
retrace time).