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
