Hacking Acekard 2 w/AKAIO v1.2 keeps messing with my DS settings!

[Hachibei]

K, so this isn't a super huge problem, but whenever I try to change my nickname/screen name in the DS itself, the Acekard keeps changing it back to my old name! Is there some sort of fix for this? I tried looking through all the settings and files in the AKAIO firmware and there doesn't seem to be anything that could be making this happen. Should I just use a different firmware?

 

[cory1492]

Change it twice in a row (change it to something close the first time, then what you want it to be the second time), powering off the DS through the menu options each time.

 

[JLsoft]

Hachibei, thanks for confirming this...it's been driving me crazy that my firmware's brightness setting would change now and then and I couldn't track it down

 

[Hachibei]

Change it twice in a row (change it to something close the first time, then what you want it to be the second time), powering off the DS through the menu options each time.

Hahaha, that'd work.. but they should really fix the problem itself.
Thanks for the advice!

 

[cory1492]

Maybe they've not seen the problem in person, could be model/chip specific. For myself, if I change it only once it boot's to AIO with my change the first time only so changing the settings twice before inserting acekard again solves it as a workaround.

Which reminds me, never ask a mechanic to fix a problem you can't reproduce in front of them... xD

 

[Smiths]

never had a setting not work here. all changes in firmware, when properly shut down after changing them, work fine.

 

[cory1492]

Well, I never had a problem either -until I checked more thoroughly-... using the last public beta on my AK2 with my flashme'd DSLite:
1 - remove ak2 and go into the DS menu, change your name text (I added a 2 at the end of mine, so it became "cory2"), quit through the DS gui so it shuts off the DS for you
2 - put in ak2, boot to AIO menu - it say's "cory2"
3 - shut off DS, remove ak2 (or not) and check again, it say's "cory" (I assume it has either fallen back to the previous settings via corruption or is just using the first profile in the settings area)
4 - if it didn't show the problem this time, rinse and repeat with "cory3" to see it fall back to "cory2" - it definitely has something to do with the backup profile.

Now, from where it's at if I change it to "cory2" and exit out/power off through the menu, then start the DS menu again and change it to "cory3" the problem does not occur (hence my recommendation to change and save it twice as a workaround.) There is definitely a glitch in there somewhere, I assume AIO is writing the settings back at some point where it probably shouldn't touch the settings other than to read them.

Any which way, thanks JLSoft for initially mentioning it - I normally have my screen set to lvl2 brightness and had set that in the DS firmware as well, but I could not figure out why the bloody thing would blind me with a really bright white screen before it started AIO.

Smiths: out of curiosity, with the new FIFO stuff in the latest libnds - is AIO using the latest libnds now? I'm having no luck tracking down NDSX_ARM7_FirmwareAccessFifo()

 

[Smiths]

brightness has been reverted to our old code. a while back we ported gelu's code in (I wasn't a fan of it, sorry!) Norm and I are both on DS Phats, so we don't know if brightness stays or goes.

libnds? I think Norm thought about it but it was going to break so much crap.

 

[Smiths]

FYI - tried your whole method on a FlashME DSPhat and could never get it to not know the latest change I had made.

Nick always was what I set in the BIOS.

_userName = unicode_to_local_string( (u16 *)PersonalData->name, PersonalData->nameLen, NULL );


That's all it does

 

[cory1492]

I can agree as well, the problem does not exist on my flashme'd DS, just on the DSL; aka: "Maybe they've not seen the problem in person, could be model/chip specific." At least I'm 100% right on that point, anyway. That's always been my biggest frustration with libnds as well, they always seem to try to break *everything* on updates

I swear, I've spent 5x more time looking at libnds source updates than I have coding when it comes to the DS.

PersonalData's data it stored on a spi accessed firmware chip, it's read from there before you have access to the info (and it's just as much if not more of a pain to put that data back, it takes a clear chunk of code to do so), be it by the bios or otherwise. To change the brightness setting, well here (which was why I suggested it may be the brightness code, as that method tries to write it back to the user data - wasn't there a couple reports of losing the language setting as well?) I do recall there being problems surrounding PersonalData corruption before, back around DKPR17 or so, but I think it was only with that asian one with the larger firmware chip. Too bad they used CVS for so long, the commit logs are so much better in SVN.

Would it help any if I coded up something to dump both slots of PersonalData before and after the problem comes up? As far as I can tell that would only be proof rather than a fix - are you then (basically) using gelu's codebase right now for akmenu arm7? If so (and I assume not, more likely what is in AK-BBS) I'll check out what is current and see if I can replicate the bad result on an independent/small app. Anyway, if there is anything I can help with in isolating it, I'm still game.

BTW, I did find NDSX_ARM7_FirmwareAccessFifo, in google at any rate - in lick's DSLua stuff... which led me to look a little more closely at gelu's .h files - what a mess putting code in a header

 

[Normmatt]

I can agree as well, the problem does not exist on my flashme'd DS, just on the DSL; aka: "Maybe they've not seen the problem in person, could be model/chip specific." At least I'm 100% right on that point, anyway. That's always been my biggest frustration with libnds as well, they always seem to try to break *everything* on updates

I swear, I've spent 5x more time looking at libnds source updates than I have coding when it comes to the DS.

PersonalData's data it stored on a spi accessed firmware chip, it's read from there before you have access to the info (and it's just as much if not more of a pain to put that data back, it takes a clear chunk of code to do so), be it by the bios or otherwise. To change the brightness setting, well here (which was why I suggested it may be the brightness code, as that method tries to write it back to the user data - wasn't there a couple reports of losing the language setting as well?) I do recall there being problems surrounding PersonalData corruption before, back around DKPR17 or so, but I think it was only with that asian one with the larger firmware chip. Too bad they used CVS for so long, the commit logs are so much better in SVN.

Would it help any if I coded up something to dump both slots of PersonalData before and after the problem comes up? As far as I can tell that would only be proof rather than a fix - are you then (basically) using gelu's codebase right now for akmenu arm7? If so (and I assume not, more likely what is in AK-BBS) I'll check out what is current and see if I can replicate the bad result on an independent/small app. Anyway, if there is anything I can help with in isolating it, I'm still game.

BTW, I did find NDSX_ARM7_FirmwareAccessFifo, in google at any rate - in lick's DSLua stuff... which led me to look a little more closely at gelu's .h files - what a mess putting code in a header

We were using Gelu's akmenu4 arm7 code but i reverted to the older code based on official akmenu4, which never seemed to cause problems and is alot cleaner imho.

 

[cory1492]

Hear that noise? I think something just flew over my head...

(or maybe that was santa getting an early start?)

So then - is gelu's code in the latest public beta (1.3b2), and you've reverted it since? I do know gelu's code has firmware bytewise (nononono! not on a flash chip that has existing data! erase sector/block, write block!) writes in it( meaning that would be the most likely culprit if gelu used it at all.)