nanogui@linuxhacker.org

EHE@CompuGROUP.COM wrote:
> 
> Hi.
> 
> > ----------
> > Von:  Erwin Rol[SMTP:erwin@muffin.org]
> > Gesendet:     Dienstag, 8. Februar 2000 22:21
> > An:   NanoGui List
> > Betreff:      Frame buffer Interface
> >
> > Hello All,
> >
> >
> > First i have been breaking my head to think of a way to update
> > slow LCD dot matrix displays. They have a 8 bit bus with some chip
> > selects,
> > you first write the address of the memory byte in "video" ram and than
> > the
> > actual byte for that place. This means updating the whole display from
> > CPU ram is to expencive when probably less than 10 % is changed after
> > some
> > dots drawwing. So a virtual RAM framebuffer (i first thought) would be
> > not possible. But now i came up with the following.
> >
> Some comments to T6963 based LCD's:
> I've found that bit/byte fiddling is much to slow.
> I'm updating the whole display ram with burst write from time to time.
> This is very fast, because you can strobe out byte after byte and the
> address
> pointer is increased automatically.

good point :-) i wonder where the treshold is. howlong does it take to
do
a full update and how long does it take to do a single random byte
update.
if i put my brain in "simple" mode i would think random byte write
takes two write , one address selection and the byte itself, and burst
only 
one write for the byte. 
so 2n = N   => N/2 = n  so when more than half the buffer needs to be
updated
one should use burst. So we might want to at a argument to the flush()
function 
to say it needs a full update or a bytewise update?

- ERwin
 

> 
> cheers
>      Erik
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org
> For additional commands, e-mail: nanogui-help@linuxhacker.org