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.

DS development > Personal data not updating

#162007 - Jeremysr - Sat Aug 23, 2008 2:11 am

I want to get the DS username, but when I set the username to something else (from the DS firmware) and then run my program, it still displays the username that I had before I changed it. The DS firmware displays my new one but my program still displays the old one. If I go to the options again and set it again, then it will work. Why does this happen and how can I fix it?

Here is the code:

Code:
void get_username(char *username) {
   struct tPERSONAL_DATA *user_info = PersonalData;

   for (u8 i = 0; i < user_info->nameLen; i++) {
      username[i] = (char)(user_info->name[i] & 0x00FF);
   }

   username[user_info->nameLen] = '\0';
}


My program isn't storing the username anywhere other than in memory so it can't be a problem with my program.
_________________
viewsourcecode

#162009 - chuckstudios - Sat Aug 23, 2008 3:44 am

GBATEK says:

Quote:
Note: There are two User Settings areas in the firmware chip, at offset 3FE00h and 3FF00h, if both areas have valid CRCs, then the current/newest area is that whose Update Counter is one bigger than in the other/older area.

IF count1=((count0+1) AND 7Fh) THEN area1=newer ELSE area0=newer

When changing settings, the older area is overwritten with new data (and incremented Update Counter). The two areas allow to recover previous settings in case of a write-error (eg. on a battery failure during write).



Off-topic:
This is immediately below that paragraph:
Quote:

Battery Removal
Even though the battery is required only for the RTC (not for the firmware flash memory), most of the firmware user settings are reset when removing the battery. This appears to be a strange bug-or-feature of the DS bios, at least, fortunately, it still keeps the rest of the firmware intact.

This is not true, as a flashcart with the autoboot bit set will prove. IIRC, Martin Korth is nowhere to be found. As cases like this are found, who will maintain the technical documents?

#162010 - Jeremysr - Sat Aug 23, 2008 4:46 am

Ok, so I have to check which one is the new one, or does the DS do that? I'm guessing when the DS starts up, it checks which one is new and loads it to 0x27FFC80... Except the DS firmware menu shows the new name but my program shows the old one.
_________________
viewsourcecode

#162030 - chuckstudios - Sat Aug 23, 2008 5:46 pm

Jeremysr wrote:
Ok, so I have to check which one is the new one, or does the DS do that? I'm guessing when the DS starts up, it checks which one is new and loads it to 0x27FFC80... Except the DS firmware menu shows the new name but my program shows the old one.


It's likely that libnds's getUserSettings() (or named similarly) that runs on the default ARM7 core does not evaluate for which is newer. I'll check the libnds source a bit later to see if that is the case...

Edit: I've checked userSettings.c, and it does check both CRC and modification time. :-/

#162231 - thoduv - Thu Aug 28, 2008 10:49 am

chuckstudios wrote:

Edit: I've checked userSettings.c, and it does check both CRC and modification time. :-/

Yeah, but there is obviously a bug in this check:
Code:
currentSettings = (slot2count == (( slot2count + 1 ) & 0x7f) ? &slot2 : &slot1);

should be
Code:
currentSettings = (slot2count == (( slot1count + 1 ) & 0x7f) ? &slot2 : &slot1);

(I currently don't have the tools needed to make a .diff patch and submit it, so if someone could report this to devkitPro...)