gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Simple app that would measure battery life

#178508 - zoranc - Mon Oct 19, 2015 12:45 am

Not sure if this is the right part of the forum for this request.

I would like to have some app for GBA that would measure the battery life. Something like save a number on each minute when started and obv. stop when the battery is out. Would the saving be corrupted if it coincides with battery going down? Alternatively can one detect the red low-battery?

Do you know of such app? My google skills didn't show anything so far.

#178509 - gauauu - Mon Oct 19, 2015 5:17 pm

I don't know of any mechanism to read the battery level from software on the GBA, and searching through gbatek didn't turn up anything. So if there's a way to do it, I'd have no idea how.

(Beyond a hardware hack, and feeding encoded battery voltage levels back to the gba, possibly through the linker port)

#178511 - sverx - Wed Oct 21, 2015 10:24 am

zoranc wrote:
I would like to have some app for GBA that would measure the battery life


You mean to estimate how much is left in there? I guess this is impossible.
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary

#178512 - zoranc - Wed Oct 21, 2015 12:52 pm

sverx wrote:
zoranc wrote:
I would like to have some app for GBA that would measure the battery life


You mean to estimate how much is left in there? I guess this is impossible.


I guess my explanation was not very clear. Probably my alternative request was confusing. What I want is the following:
1. I fully charge the GBA (SP or micro). Plug it out from charger and turn it on.
2. Start the app.
3. App would continuously store it's running time.
4. Once the battery is out, last saved running time would be the the battery life of the current GBA battery.
5. After a new charge and restart, the app would give me the previous running time.

I got replacement batteries for my GBA SP and micro, and would like to know how good those fare against a GBA that is used for some time. Also against a new one. My guess was that such tool already exists. If not what environment would be the easiest one, for building such app?

#178513 - gauauu - Wed Oct 21, 2015 3:28 pm

Ah, that sounds much more realistic.

You'd need to write a simple program that just continually increments a counter in sram every frame. And since you want it to also report the previous results to you once you recharge, you'd need to it to display the previous value on the screen before it starts counting.

A 32-bit integer maxes out at 2,147,483,647, which is to 10,000 hours if you do that correctly, (If I did my math right?), so you wouldn't have to worry about it overflowing.

Do you have any experience with C programming? If you install the DevkitPro sdk, and take a look at the "template" example in the gba examples, it gives you a simple outline of a program that does nothing but display some text and wait forever. It should be a fairly simple manner to add a counter to that, and change the text output.

Writing to save ram in only slightly trickier (mainly because it's hard to find reliable documentation about it nowadays). You basically just write to a particular location in memory, but have to make sure you only write 8 bits at a time. Oh, and if compile with full optimizations on, GCC sometimes tries to be smarter than you, and optimize your writes to something bigger than 8 bits. Below is a sample function from my game Anguna that writes to save data. Yours can be simpler, if you are only writing a single number (although 8 bits won't be big enough to store the whole counter you are using)


Code:

#define SAVE_RAM ((u8*)0x0E000000)

void writeSaveGameToCart(SaveGameData * data, int saveSlot)
{
   u8 * save = SAVE_RAM;
   int slotSize = sizeof(SaveGameData);
   save += saveSlot * slotSize;

   u8 * saveData = (u8*)data;

   //use a u8 loop because save data can only be written 8 bits at a time
   int i = 0;
   for (i = 0; i < slotSize; i++)
   {
      *save++ = *saveData++;
   }
   
}

#178514 - zoranc - Thu Oct 22, 2015 11:00 pm

Save RAM - I guess that was the thing I was looking for. Thanks for the info!

To be frank I wanted to avoid devKitPro because is just too much effort to build a working C/C++ app, but in the end it seems I'll need to byte the bullet. Eventually I intended to develop for the platform anyway.

On the timing and counters I'd probably use an internal timer or even better a V-blank to get a real life reference of time. Probably in my flash cart Save RAM is implemented with a SRAM, not EEPROM so optimising for a few writings might be an overkill.

#178515 - gauauu - Fri Oct 23, 2015 2:48 pm

zoranc wrote:
To be frank I wanted to avoid devKitPro because is just too much effort to build a working C/C++ app, but in the end it seems I'll need to byte the bullet. Eventually I intended to develop for the platform anyway.


Yeah, there's not really any other good way of doing development.

Quote:

On the timing and counters I'd probably use an internal timer or even better a V-blank to get a real life reference of time.


If you use that template from the devkitpro examples, it waits for vblank every frame, so you are locked at a fixed fps (around 60). You can then not worry about any timing, and just increment your timer once per frame.

#178516 - sverx - Mon Oct 26, 2015 11:37 am

I'm really not sure that when your battery runs out your RAM will hold the contents. It should be static or battery-backed.
Also, you can write to SRAM every minute (3600 frames) instead of every frame. But I wouldn't use the same SRAM location over and over, as when your battery will run out your hardware could just trash the contents there (it happens often with the first byte on my hardware).
I would zero the whole SRAM and set each byte to an increasing value each minute, skipping the first few bytes too. Then check what's there at the next boot, reading the values as long as they're increasing.
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary

#178517 - zoranc - Tue Oct 27, 2015 9:29 am

sverx wrote:
I'm really not sure that when your battery runs out your RAM will hold the contents. It should be static or battery-backed.
Also, you can write to SRAM every minute (3600 frames) instead of every frame. But I wouldn't use the same SRAM location over and over, as when your battery will run out your hardware could just trash the contents there (it happens often with the first byte on my hardware).
I would zero the whole SRAM and set each byte to an increasing value each minute, skipping the first few bytes too. Then check what's there at the next boot, reading the values as long as they're increasing.


Ok another piece of important information. That's why most games beg you not to turn off the power while the saving is happening.

What I'll probably do, is have 8 (or so) locations (2-byte long, or so) in the save memory that would have the the counter stored. A 1 byte counter is also fine if I increment on 10 min. periods, but that's too unprecise. That way if one of them gets trashed probably would be substantially diferent then the rest and easy to recognizeby a human. A clustering of the 7 similar values is also not too difficult.

Thank you all for the input!