From: Jean Boullier <jean.boullier_at_wanadoo.fr>
Date: Sun, 25 May 2003 06:58:09 +0200

Hi Garrett!

You wrote:

>AFAIK I cannot use much more RAM for the time being. We do not do
>malloc/free; any buffer increases the size of the binaries. We are already
>up very close against the 200k limit for a boot image. That will change one
>day with Rockbox 2.3 and loadable applications. (At that time also I would
>guess the developers might choose to implement a buffered fread().)
>
>Of course I agree that even a small buffer increase would help, so maybe
>that will be possible.
>
As far as I am concerned, if you limited your text viewer storage only
to not make the resulting code exceed the allowed maxmum (i.e. if there
is no other technical constraint) I am more than ready to trade the full
set of games for a good clever text viewer and a few other things,
probably. Considering the general agreement that keys are weak and that
saving power is important for most, using the Jukebox as a (very poor)
Game Boy leaves me puzzled...

>Like you, I have noticed the frequent spin-ups when reading a lengthy text.
>I would like to be able to do something about it.
>
>One thing that puzzles me: doesn't a hard drive have its own built-in cache?
>Why does it need to spin up every time I read a couple sectors? The built-in
>cache is for write only?
>
In general the first purpose of disk caches is to avoid as much as
possible that the CPU waits for the disk, not for saving power. And for
that purpose, as soon as one has pulled some bytes from the cache the
logic therein is supposed to read the disk to supply an equivalent
number of bytes "at the end" of the cache, for the next time(s)...

I do not know if that works exactly like that in the Jukebox, but if
there is some disk caching in it, that should not be too far from this
scheme.

Cheers. Jean B.
Received on 2003-05-25