From: TP Diffenbach <rockbox_at_diffenbach.org>
Date: Tue, 29 Jul 2003 12:02:37 -0400

Quoting idc-dragon_at_gmx.de:

> Yes, I am interested, but what secret magic did you do? May I humbly ask for
> a little explaination?

No, the battery extension technology is proprietary intellectual property of The SCO Group.

You may license binary copies of the Battery Extesion Technology ("BET") but only if you sign an End User License Agreement ("EULA") to not reverse engineer, transer or even question the 1337ness of the technology. Also, you agree that I may access and alter the contents of your Archos, to replace your MP3s, at my sole discretion, with Wagner overtures.


Just kidding folks.

The magic is pretty simple: the wps thread does more mork than we want. The first cut battery extension just suspends scolling (without destroying the scroll infomation already calculated) and blocks the wps thread by waiting for keyboard input, after the backlight timeout has elapsed.

I'm fortunate that so much of the rockbox code is well-written, so in fact I had only to do a little work to get the savings. But there are some issues that with the code that I think bear examination:

The second cut will restore scrolling and screen updates, but defer settings savings. I suspect settings saving is the real hog, as I have previously experimented with optimizing (for size, not speed) the settings. Basically, wps only changes two settings, volume and resume position, but calling save_settings causes /every/ setting to be written to config_block, which is several hundred lines of bit masking and the like. This can happen up to about once a second, and is mostly pointless.

A good compromise might be to save only that information that really can change, and save it (or as much as possible) to the RTC memory, if in fact saving to the RTC memory is faster. Another compromise would be to defer saving settings (perhaps in another thread for code cleanliness) to something like once a minute. Another would be to save changes on power down.

Each possibility has tradeoffs in terms of work done versus loss of settings changes in the case of power down. I'm willing to lose the last minute of volume changes and track offset for 50% more battery. Obviously, if this is to be made part of the official build, we want to allow the user to select what strategy he's prefer to employ.

A related problem is that the wps thread is responsible for polling the mpeg thread for track changes, and updating directory information. I'd rather have the mpeg thread take care of this, as it's not really related to /display/ issues, and the mpeg thread, I think, wouldn't have to poll.

A more drastic change would be to make the GUI input and wps display completely seperate threads; this might in addition address my issues with occasionally delayed reaction to key-presses.

Thought and comments on the above are of course invited.

--Tom

-- 
Archos FM has a Rockbox!

Received on 2003-07-29