nanogui: Frame buffer Interface
Subject:
Re: Frame buffer Interface
From:
Erwin Rol ####@####.####
Date:
9 Feb 2000 21:24:37 -0000
Message-Id: <38A1E89F.52C4CECD@muffin.org>
####@####.#### wrote:
>
> Hi.
>
> > ----------
> > Von: Erwin ####@####.####
> > 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: ####@####.####
> For additional commands, e-mail: ####@####.####
