Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Idea: Speeding up LCD on Iriver H300

Idea: Speeding up LCD on Iriver H300

From: Matthias Larisch <tierchen_at_eow.ath.cx>
Date: Wed, 28 Dec 2005 01:49:55 +0100

Hey there!

FIRST: Sorry for crosspost! I didnt want to post this on GENERAL, just
on DEVEL. But I'm new to mailinglists.


I'm new to rockbox and used my last 24 hours to go through the whole
code. Myself owns an Iriver H300. I think rockbox is very great now, but
could be much better :) (Jpeg, Video)

So here is what I think about the lcd_update() Speed problem:
The LCD can handle one Pixel per 150ns (Datasheed->Writecycle). That
would be around 120frames per second. I think, the problem is in the
code. For every Pixel send to LCD, Chipselect selects SDRam, reads one
byte, selects LCD and writes byte there.

The whole procedure with switching Chipselects for every byte (aw sry, i
mean word, pixel) is consuming many time we dont have...
I wrote a very small speed-test, a few loops with just increasing colors
(nearly no calculations, just to have it look funny) with LCD_WIDTH
calls to lcd_update(). This loop dures around 28 seconds with CPU not
boosted and around 10 seconds with CPU boosted.
Just for fun with CPU Idle:
2 mins 24 -> 144 seconds.
Oh maybe a kind of bug: My plugin only has this for-loop, and standard
plugin api. HD doesnt stop spinning! (it seems like nothing else than
plugin code is executed)
And.. kind of mistake in my program: it just runs from 0 to
LCD_WIDTH-31, so 189 loops.
That is:
Idle 1,3125 fps
Normal 6,75fps
Boost 18,9fps

Code, just if someone wanna use it ^^ (verry crappy)
int i,j,c;
for(c=0;c<LCD_WIDTH-31;c++)
{
   for(j=0;j<LCD_HEIGHT;j++)
   {
     for(i=c;i<c+31;i++)
     {
       rb->lcd_framebuffer[j*LCD_WIDTH+i]=LCD_RGBPACK(c,j,i*8);
     }
   }
rb->lcd_update();
}

So only calculation done is LCD_RGBPACK with few bitshifting... Not to
forget the loops, with few clockcycles per run.


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.

I dont really know.. Does rockbox use sram for some stuff?
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.
This should be a little bit faster... But I cannot implement it because
of my low coding skills (PHP is more what i can do...)

What do you think of my idea?

bye,

Matthias Larisch
Received on 2005-12-28

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy