gbadev.org forum archive

I have just added a power saving SWI 2 instruction to Bookreader (V4.91), and to check how effective it was I took some battery current measurements this evening. if anyone has tried this you'll know what fun it is to insert a meter into the battery circuit on a GBA SP, when you don't want to ruin the battery or the contacts.

Anyway I thought that the results were instructive. I took a few readings in different software situations, all using an 256Mbyte F2A Ultra cartridge, and rounded to 1mA.

Pogoshell (Light On)...................72mA
Pogoshell (Light Off)...................46mA
Bookreader V4.9 (Light On)........71mA
Bookreader V4.9 (Light Off)........45mA
Midi plug-in playing on Pogoshell (Light On)......70mA
Zelda (start of game play) (Light On)....78mA
Bookreader V4.91 (Light On).........41mA
Bookreader V4.91 (Light Off).........17mA

Conclusions? Well first of all the light is taking 22mA. Turning off the light in an official game could extend battery life by 28%.

Secondly, in spite of criticism of Bookreader for not using SWI 2, it doesn't appear to use more current than other programs.

Thirdly though, with the light off, the new Bookreader will run for more than 2 1/2 times longer than the older one. With the light on (essential in my opinion) the new Bookreader will run for 73% longer than the older one.

[Pogoshell V1.2 was used, later versions may have been power reduced. Bookreader 4.91 has not yet been released.]
_________________
http://www.bookreader.co.uk/

Last edited by gb_feedback on Sat Aug 14, 2004 2:17 pm; edited 1 time in total

Really interesting, thanks for your efforts. :)

Did you allow any interrupts to occur ? If yes which interrupts ?

DKL

Bookreader does everything other than reacting to user input during the VBLANK interrupt. V4.9 looped in main() waiting for key input. V4.91 checks just once then calls swi 2. Obviously it gets woken up once per frame by the return from the VBLANK interrupt.

The other point is that when reading a book there are long periods with nothing happening!
_________________
http://www.bookreader.co.uk/

gb_feedback wrote:

The other point is that when reading a book there are long periods with nothing happening!

Sure.

There's another thing I'm wondering about. Do DMA transfers uses more current than CPU memory transfers ? If you could test it one of these days, it would be cool. :)

Also could you make some tests with some other interrupts enabled, like say HBLANK, serial, etc. I think battery consumption is really an important parameter when you are developing software. Don't you think ?

Thanks again for your efforts.

Regards,
DKL

I think it would be fun to do more measurements too.

However you can probably guess some of the answers. SWI 2 will turn off the CPU (but nothing else) until the next interrupt. The interrupt is just a process using the CPU. So the consumption of the GBA without light or CPU is about 17mA (or maybe a bit less) [with sound circuits enabled]. With CPU on continuously it's around 45mA. So regardless of which interrupt you're using the current would seem to be 17mA + (28mA times the proportion of time the CPU is on) + 22mA if the light is on.

I'm sure these figures could be refined - I only spent a few minutes taking the measurements, using programs which were to hand.
_________________
http://www.bookreader.co.uk/

Could you test a multiboot program? I have this hypothesis that ROM access is rather expensive in terms of current. I'd like to see how much current the GBA drains when running Tetanus On Drugs in the following states:

TOD at title screen (minimal CPU use)
TOD during gameplay (medium CPU use)
TOD during paused game (minimal CPU use)
TOD during 3D rotation effect (first used in level 3) (high CPU use)

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

gb_feedback wrote:

So the consumption of the GBA without light or CPU is about 17mA (or maybe a bit less) [with sound circuits enabled].

Yep, it should be less. Maybe could you just do some measurements while the cpu is completely halted (not even VBLANK irq to wake him up) ? And so you would have a correct base value.

Quote:

With CPU on continuously it's around 45mA. So regardless of which interrupt you're using the current would seem to be 17mA + (28mA times the proportion of time the CPU is on) + 22mA if the light is on.

Of course, you're right. :) I wonder how much dma and serial transfers do use current though... And what's the influence of sound, and the influence of display complexity, and...

I will keep notes of this values. :)

Regards,
DKL

Don't forget that flash cartridges use considerably more power than original game carts.
On the original GBA, a game played on a flash cart used 50% more power than the same game on a original cart.
The same should be true on the SP with the light turned off.

ampz wrote:

Don't forget that flash cartridges use considerably more power than original game carts.
On the original GBA, a game played on a flash cart used 50% more power than the same game on a original cart.
The same should be true on the SP with the light turned off.

True, and it even depends on the flash card type. But this values aren't interesting in absolute terms, at least for programming. They are because they indicate which 'proportion' of power is used.

DKL

tepples: allow for some experimental error owing to difficult of playing game while holding wires on! Most rounded to 1mA.

All with light OFF!

GBA SP no cart - just after N logo.......16mA
During download of TOD...................19-24mA

TOD at title screen (minimal CPU use) ...15mA
TOD during gameplay (medium CPU use)...18mA
TOD during paused game (minimal CPU use) ...16mA
TOD during 3D rotation effect (first used in level 3) (high CPU use)...around 19mA
(but with quite high variation)

Variation in current drain at low/high volume setting with NO sound..0.5mA
Variation in current drain at low/high volume setting with sound....3mA

Effect of Playing from F2A Ultra 256Mb cart (presumably just quiescent cart current - as it's still a multiboot program)...additional 0.8mA

Hope it makes sense. I noticed that I had left the multiboot cable in. That reduces the current by half a mA or so for some reason, so the real result maybe should be 1mA higher in some cases. Bear in mind that if the game is actually doing anything the reading goes up and down all the time.

EDIT - Later experiment. I dumped a commercial cartridge and put it (very temporarily) on the F2A Ultra 256Mb. At the same point in early gameplay (light off) the commercial cart took 31mA and the FLASH cart took 51mA. A 64% increase in battery consumption, or a 40% decrease in battery lifetime. I have now of course deleted the temporary backup.

It would perhaps be interesting if we tried a version of TOD which actually ran from the FLASH cart. I leave the idea in tepples court as I don't have time to compile his source right now. Tepples: PM me if you are able easily to send me a temporary version...
_________________
http://www.bookreader.co.uk/

gb_feedback wrote:

tepples: allow for some experimental error owing to difficult of playing game while holding wires on! Most rounded to 1mA.

Understandable.

Quote:

Zelda (start of game play) (Light On)....78mA
...
Well first of all the light is taking 22mA

So an official game uses an estimated 56mA without the light.

Quote:

TOD at title screen (minimal CPU use) ...15mA
TOD during gameplay (medium CPU use)...18mA
TOD during paused game (minimal CPU use) ...16mA
TOD during 3D rotation effect (first used in level 3) (high CPU use)...around 19mA

So that's why I make multiboot games: it really cuts down on power consumption. Thanks for testing my hypothesis.

Quote:

Effect of Playing from F2A Ultra 256Mb cart (presumably just quiescent cart current - as it's still a multiboot program)...additional 0.8mA

Minimal. I wonder what battery consumption would be like with a program that loads itself to RAM but keeps its assets such as audio samples in ROM, which is what happens when a DevKit Advance R5 program is loaded by a loader that relies on DKA crt0's dual .mb.gba capability.

Quote:

I noticed that I had left the multiboot cable in. That reduces the current by half a mA or so for some reason

Probably because the cable is feeding the GBA's serial port.

Quote:

It would perhaps be interesting if we tried a version of TOD which actually ran from the FLASH cart. I leave the idea in tepples court as I don't have time to compile his source right now. Tepples: PM me if you are able easily to send me a temporary version...

I'll try to find time to work on alternate versions today or tomorrow, as I'll have to set up long-call access for the audio mixer and reset.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

One thing that surprised me slightly.

Before I located my multiboot cable, I tried running TOD from a cart and then pulling the cart out, assuming that it would keep running as even on a cart it would be running from ram after being moved.

Well it ran with increasing visual and auditory errors. OK I know it wasn't a very correct thing to try but I really thought it would work. Maybe pulling the cart put rubbish on the data bus?...who knows.

EDIT

Quote:

Quote:

Zelda (start of game play) (Light On)....78mA
...
Well first of all the light is taking 22mA

So an official game uses an estimated 56mA without the light.

Quote:

TOD at title screen (minimal CPU use) ...15mA
TOD during gameplay (medium CPU use)...18mA
TOD during paused game (minimal CPU use) ...16mA
TOD during 3D rotation effect (first used in level 3) (high CPU use)...around 19mA

So that's why I make multiboot games: it really cuts down on power consumption. Thanks for testing my hypothesis.

We really need the data from TOD on FLASH to be able to claim this, I think. (Not saying that you're wrong - just that we have to compare the same game in the two different circumstances. After all Bookreader working from FLASH now takes the same current as TOD working from RAM - but of course nothing is going on in the CPU while you stare at a book page.

By the way, interestingly, we now have two active official games (measured on FLASH) 51mA and 56mA - quite similar figures.
_________________
http://www.bookreader.co.uk/

I have measured the current consumption of several official games on the original GBA. The consumption is almost constant, no matter the title of the game or if it is measured during gameplay or during something static, like a menu. The current consumption for official games on the original GBA is always 100mA, with only 10-20% or so deviation.

Yes, 100mA is higher than that of the GBA SP, this is because the original GBA runs on 2 NiMH batteries, so the voltage is only about 2.4V, while the GBA SP runs on a 3.8V LiIon battery.
Also, the original GBA uses a boost (step up) type power supply while the SP must use a buck (step down) type power supply. I don't think they can get as high efficiency from a boost PS as from a buck PS. Take theese two factors into account, and the power consumption becomes equal.

ampz: Interesting. For the record, were these original carts or flash copies?
_________________
http://www.bookreader.co.uk/

gb_feedback wrote:

Before I located my multiboot cable, I tried running TOD from a cart and then pulling the cart out, assuming that it would keep running as even on a cart it would be running from ram after being moved.

Well it ran with increasing visual and auditory errors. OK I know it wasn't a very correct thing to try but I really thought it would work. Maybe pulling the cart put rubbish on the data bus?...who knows.

GBFS + DevKit Advance R5 beta 3's changes to how appended assets are handled in multiboot programs + flash card running multiboot program as ROM = assets not copied from ROM to EWRAM.

Assets not copied from ROM to EWRAM + yank the cartridge = open bus when trying to read assets.

Workaround: Use PogoShell or Multiboot Menu, not your flash cart's writer program, in order to be able to pull the cart out mid-game.

Quote:

We really need the data from TOD on FLASH to be able to claim this, I think.

I'll make different versions of TOD post-M3 tonight or tomorrow.

Quote:

but of course nothing is going on in the CPU while you stare at a book page.

I expect similar behavior out of TOD's title screen. Perhaps TOD will use a bit more juice because 1. sound is still on (so that you don't get pops all the time) and 2. its audio mixer is still running but mixing silence.

ampz wrote:

the original GBA runs on 2 NiMH batteries, so the voltage is only about 2.4V, while the GBA SP runs on a 3.8V LiIon battery.

Does the use of alkaline cells (2x1.5V) change the boost vs. buck figures any? I know my GBA with alkaline cells will sometimes show a green power light on TOD but a red power light on some original commercial Game Paks, or a bouncing red/green light on GSM Player (which uses slightly less power for a frame 6 times a second).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

gb_feedback wrote:

ampz: Interesting. For the record, were these original carts or flash copies?

Originals, of course.
Same games running on a flash cart adds about 50% to the current.

tepples: Alkaline cells reduces the current since they have a higher voltage. I don't think they affect the efficiency of the boost type power supply.

Does having the sound at different levels affect the battery life significantly in any way?
_________________
Little kids and Playstation 2's don't mix. :(

dagamer34 wrote:

Does having the sound at different levels affect the battery life significantly in any way?

Not sure. I assume that louder music uses more power but I have never really tested it or anything. Specifically disabling the sound circuits is meant to save a little itty bit of power however.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

dagamer34 wrote:

Does having the sound at different levels affect the battery life significantly in any way?

No. The difference can hardly be measured.

The video hardware (including the LCD itself), the processor, the cart (especially if it is a flashcart), and the light (if GBA SP). Thoose are the big consumers.

If you wanna save power:
Turn the GBA SP light off.
Put the processor in a sleep mode whenever you don't need it.
Limit cart accesses.
Shut down the LCD (yeah, right...).

I find it weird that most commercial games don't appear to use the sleep modes very much. I would expect that to be a requirement from Nintendo.

ampz wrote:

dagamer34 wrote:

Does having the sound at different levels affect the battery life significantly in any way?

No. The difference can hardly be measured.

The video hardware (including the LCD itself), the processor, the cart (especially if it is a flashcart), and the light (if GBA SP). Thoose are the big consumers.

If you wanna save power:
Turn the GBA SP light off.
Put the processor in a sleep mode whenever you don't need it.
Limit cart accesses.
Shut down the LCD (yeah, right...).

I find it weird that most commercial games don't appear to use the sleep modes very much. I would expect that to be a requirement from Nintendo.

It's probably because most 3rd party games aren't played for very long periods of time. Nintendo makes most of the games that take a long time to complete and are most likely to be played for longer periods of time.
_________________
Little kids and Playstation 2's don't mix. :(

I previously made the following measurements on tepples TOD in multiboot, which I don't think I included.

Changing volume control from min to max with NO SOUND playing increases current consumption by 0.5mA

Changing volume control from min to max with loud music playing increases current consumption by 3mA

Compare thse with the overall consumption to gauge the significance.
_________________
http://www.bookreader.co.uk/

dagamer34 wrote:

ampz wrote:

I find it weird that most commercial games don't appear to use the sleep modes very much. I would expect that to be a requirement from Nintendo.

It's probably because most 3rd party games aren't played for very long periods of time. Nintendo makes most of the games that take a long time to complete and are most likely to be played for longer periods of time.

I don't think zelda use the sleep mode.

gbadev.org forum archive

Coding > Power Consumption Measurements

#24953 - gb_feedback - Fri Aug 13, 2004 8:47 pm

#24954 - DKL - Fri Aug 13, 2004 8:55 pm

#24955 - gb_feedback - Fri Aug 13, 2004 9:10 pm

#24959 - DKL - Fri Aug 13, 2004 9:27 pm

#24963 - gb_feedback - Fri Aug 13, 2004 10:19 pm

#24970 - tepples - Fri Aug 13, 2004 11:30 pm

#24971 - DKL - Fri Aug 13, 2004 11:33 pm

#24979 - ampz - Sat Aug 14, 2004 1:19 pm

#24980 - DKL - Sat Aug 14, 2004 1:59 pm

#24981 - gb_feedback - Sat Aug 14, 2004 2:03 pm

#24985 - tepples - Sat Aug 14, 2004 4:24 pm

#24986 - gb_feedback - Sat Aug 14, 2004 4:55 pm

#25001 - ampz - Sat Aug 14, 2004 8:10 pm

#25004 - gb_feedback - Sat Aug 14, 2004 9:44 pm

#25009 - tepples - Sun Aug 15, 2004 12:37 am

#25032 - ampz - Sun Aug 15, 2004 8:41 pm

#25099 - dagamer34 - Mon Aug 16, 2004 11:30 pm

#25104 - MumblyJoe - Tue Aug 17, 2004 12:16 am

#25112 - ampz - Tue Aug 17, 2004 1:19 am

#25125 - dagamer34 - Tue Aug 17, 2004 4:41 am

#25140 - gb_feedback - Tue Aug 17, 2004 8:25 am

#25154 - ampz - Tue Aug 17, 2004 2:03 pm