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
