nanogui: Frame buffer Interface
Subject:
Re: Frame buffer Interface
From:
Erwin Rol ####@####.####
Date:
8 Feb 2000 21:37:25 -0000
Message-Id: <38A099DC.C71A963E@muffin.org>
####@####.#### wrote:
>
> Erwin Rol wrote:
>
> > Hello All,
> >
> > Went without mail from like a few hours so here one to keep
> > yer inbozx busy :-)
> >
> > 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.
> >
> > Create a RAM frame buffer and write to it.
> > There is running a update thread (or one cals the flush() function
> > manualy)
> > that compares the ram buffer with a second ram buffer , the bytes that
> > are different
>
> One idea on the update. Instead of having the update thread run from a timer or have to be
> called manually, one could from the kernel revoke write privilages and trap the access
> fault on the buffer as a trigger to know when the app is changing the contents. Then after
> a delay the update thread would perform its comparison/copyforward.
>
Yes this is the same principle Linux uses to shift the VGA window to
emulate a
linear framebuffer for cards that don't support it. But i am having
RTEMS in the back of my head amd that at the moment doesn't support
pagelevel
protection. But yes it would work, and could be implemented on CPU's
that
do support pagelevel protection. thanks for the hint :-)
- Erwin
