Path: utzoo!attcan!uunet!lll-winken!sun-barr!newstop!sun!amdcad!weitek!practic!vlsisj!davidc
From: davidc@vlsisj.VLSI.COM (David Chapman)
Newsgroups: sci.electronics
Subject: Re: Frame Buffers
Message-ID: <15614@vlsisj.VLSI.COM>
Date: 27 Jun 90 02:07:12 GMT
References: <2229@mindlink.UUCP>
Reply-To: davidc@vlsisj.UUCP (David Chapman)
Organization: VLSI Technology Inc., San Jose, CA
Lines: 59

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.
>graphics board, in terms of the memory arrangement.  I understand how VRAMS
>work, but I'm having trouble figuring out how one would build the frame buffer
>out of DRAMS (or even SRAMS, for that matter).  Let's consider SRAMS, to avoid
>having to worry about refresh; for a 1024x1024x8 screen, with 60 Hz

Actually DRAMs work just fine.  Use the memory access as the refresh!  You
just have to get the address bits connected in the right order.  It's been
too long since I've designed with DRAMs (16 Kbit DRAMs were new), so I may
get RAS and CAS confused in the following discussion.  As I recall, selecting
a row with RAS automatically refreshes all of the bits in it, even if you
then read or write one bit in it with CAS.

As a result, if you make your low-order address bits (in the scan line, not 
the scan line number) be the RAS bits (vs. CAS), then your memory will be 
refreshed at much more than the minimum rate!

>non-interlaced raster update, we need a new pixel every 15.9 ns, neglecting
>blanking intervals.  Let's say it's 14 ns.
>
> Now, the obvious (and, I suspect, wrong) way to do this is to use x8 RAM, with
>each address representing one pixel.  This means 14 ns. access intervals.  Less
>obvious (but maybe more likely) is to use x8 RAM, with each address
>representing one bit of 8 pixels.  This means you access 8 chips in parallel,
>with a 112 ns access interval.  So far, so good; this sounds like it might
>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.

The best way is to read n bits at once into a shift register, then use your
dot clock to shift out the bits.  This is the way that video DRAMs work.
For example, if you had two x8 RAMs (DRAM or SRAM), then you would have a
16-bit shift register and would need to access memory at 1/16 the dot clock
rate (14 ns x 16 is 224 ns - no problem with today's DRAMs).  If this is 
faster than your memory cycle time (*not* access time), then simply make the 
shift register and memory bank wider.  You *never* access the RAM bit-by-bit 
"at speed", only word-by-word.  In fact, your graphics controller is probably 
going to have to manage reads and writes to video RAM for you, to get 
individual bits and to schedule your access in between display refresh 
accesses.

The key is that you never use the addressing bits at the bottom - the ones
that change the fastest.  With 16 bits read at once, the lowest 4 bits of
the dot address in the row are discarded.  You gain access to them implicitly
during display via the shift register and explicitly during processor read/
write using masking or special hardware.  You lose the ability to access
dots directly (at least without special hardware), but as you can see you
gain the ability to display your data.  How you get the 16 (or 32) bits is
up to you:  16 x1, 4 x4, 2 x8, etc.  It makes no difference.

By the way, 70 MHz dot clock rates (the 14 ns you quote above) are not
unheard of.
-- 
		David Chapman

{known world}!decwrl!vlsisj!fndry!davidc
vlsisj!fndry!davidc@decwrl.dec.com