Submitted a patch for this just now :)

After testing his original idea and concluding just what you did :)

Brandon

On Wed, 12/28/05 at 22:28:31 +0100, Linus Nielsen Feltzing wrote:
> Matthias Larisch wrote:
> >So my idea is:
> >What about buffering the whole lcd_framebuffer in internal SRAM?
> >(64kbyte are not enough... so we have to put second 32kbyte directly
> >after the 64kbyte to connect these 2 together.
>
> The other targets have the framebuffer in SRAM, but the H300 framebuffer
> is too big. We just can't waste 72Kbytes for a framebuffer when the
> codecs and the main stack need that SRAM.
>
> >If so, on lcd_update move away the crap, store lcd_framebuffer in there,
> >write to gram and last but not least (else player would maybe hang ^^)
> >restore crap from the beginning.
>
> Now where would it move the "crap" to? Moving it would take longer than
> just updating the LCD from SDRAM.
>
> The problem is that the hardware won't let us do burst writes to the
> LCD, which makes it impossible for us to use the fast LCD transfer mode.
> If we could, we could use DMA with Line transfers.
>
> We could still optimize the LCD update, by using movem.l to burst read
> from SDRAM. We'll do this when we find the time.
>
> Linus
Received on Wed Dec 28 22:31:36 2005