nanogui: Frame buffer Interface


Previous by date: 9 Feb 2000 11:35:31 -0000 Re: Running document -- RTEMS framebuffer interface specification, Rosimildo daSilva
Next by date: 9 Feb 2000 11:35:31 -0000 Re: Driver for Trident TGUI9680XGi -- where ??, Alan Cox
Previous in thread: 9 Feb 2000 11:35:31 -0000 Re: Frame buffer Interface, Chris Johns
Next in thread: 9 Feb 2000 11:35:31 -0000 Re: Frame buffer Interface, Erwin Rol

Subject: RE: Frame buffer Interface
From: ####@####.####
Date: 9 Feb 2000 11:35:31 -0000
Message-Id: <10468740C382D311A7D60000E850244E2EF288@mail.compugroup.de>

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.

cheers
     Erik


Previous by date: 9 Feb 2000 11:35:31 -0000 Re: Running document -- RTEMS framebuffer interface specification, Rosimildo daSilva
Next by date: 9 Feb 2000 11:35:31 -0000 Re: Driver for Trident TGUI9680XGi -- where ??, Alan Cox
Previous in thread: 9 Feb 2000 11:35:31 -0000 Re: Frame buffer Interface, Chris Johns
Next in thread: 9 Feb 2000 11:35:31 -0000 Re: Frame buffer Interface, Erwin Rol


Powered by ezmlm-browse 0.20.