gbadev.org forum archive

I was looking through some of the PALib help files, and noticed that although there are functions for reading/writing sram, there does not seem to be a simple doesSRAMexist() (or similar) function. So I was wondering, is there a way to tell if the cart being used has sram or not? before trying to use it.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

By "SRAM", you're talking about GBA SRAM in 0xA0000000-0xA0007FFF, right? You could just read the SRAM and use a heuristic to see whether the data is valid. Try a GBA game known to use SRAM (e.g. F-Zero Maximum Velocity) and try open air.

What are you ultimately trying to do with the SRAM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Just use it fro saves etc. I'm wondering if it is save to attempt read/write if there is no sram, like in gbamp.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

spinal_cord wrote:

Just use it fro saves etc.

If you are not trying to have your program interact with commercial GBA Game Paks, then the preferred method of saving in DS homebrew is libfat, not GBA SRAM. At least the SuperCard will destroy the SRAM contents if the power stays off for a significant length of time.

Quote:

I'm wondering if it is save to attempt read/write if there is no sram, like in gbamp.

It should be safe to use the SRAM, as long as there is a homebrew card (GBA header signature == "PASS") in the GBA slot.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

At least the SuperCard will destroy the SRAM contents if the power stays off for a significant length of time.

what length of time (hours, days, months)?

It's a matter of seconds or minutes for the Supercard CF, SD, and Lite versions, while the Supercard miniSD does have a battery to back up the SRAM. Keep in mind however that even with the miniSD version, unless the user uses a method to save the SRAM to a *.sav file on the card, it will be overwritten the next time any program writes to it. Methods include a button combination (after running the file through the Supercard patcher) and the QPC method. The DS program DumpSRAM can also be used in place of the Saver tab when using the QPC method, which is useful for Rumble users that find the Saver tab to be broken in DS mode when using the latest few firmware versions.

Ideally, you should use libfat to save your game data, and only use SRAM if libfat fails to detect a compatible card.

well, sure. but on gba that might not be that easy, i believe on gba libfat only works when compiling as multiboot.

Ant6n wrote:

well, sure. but on gba that might not be that easy, i believe on gba libfat only works when compiling as multiboot.

Why would you believe that?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

josath wrote:

Ant6n wrote:

well, sure. but on gba that might not be that easy, i believe on gba libfat only works when compiling as multiboot.

Sorry, I assumed he meant for DS only, since he mentioned PAlib (a ds-only library) and this was posted in the DS Development forum.

And given that PAlib is a DS only library it should really be avoiding use of GBA specific things like GBA cart SRAM. It might have been useful back before we had slot 1 cards but these days slot 2 features should be avoided unless *absolutely necessary.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

Ant6n wrote:

well, sure. but on gba that might not be that easy, i believe on gba libfat only works when compiling as multiboot.

Why would you believe that?

well, since there is not much documentation, or an example to come along with devkitarm, i can't know for sure. But
http://forum.gbadev.org/viewtopic.php?t=13354&highlight=libfat+multiboot
seems to suggest it, also, nobody contradicted me on my help request http://forum.gbadev.org/viewtopic.php?t=13793&highlight=libfat+multiboot. After some hours of fiddling with it following exact instructions on chishm's page (which are sparse), it always gave random crashes. So i basicly arrived at the believe that one cannot use the gba-slot to run code from and read from a fat device at the same time.

Heh, I deleted that post within a second or two of making it :/

I realised after I posted that most slot 2 devices probably have their registers in the GBA rom area so it might be somewhat difficult to get this working. Maybe Chishm can shed some light later.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

If you have the disc IO routines in RAM, and those routines switch the cart between ROM and disc and back again, then you should be able to do it without running as a multiboot program. The rest of the FAT library can be in ROM, as can the rest of the program. It will be slower than normal, and you'll need to write your own drivers that do the switching, but it is possible. Why you would want to do it, I dunno. Since this is on DS (should've posted in a GBA forum otherwise), you have 4MiB for code and variables.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

gbadev.org forum archive

DS development > Detecting SRAM?

#136024 - spinal_cord - Sat Jul 28, 2007 4:20 pm

#136032 - tepples - Sat Jul 28, 2007 5:52 pm

#136048 - spinal_cord - Sat Jul 28, 2007 7:43 pm

#136055 - tepples - Sat Jul 28, 2007 8:02 pm

#136063 - Ant6n - Sat Jul 28, 2007 9:04 pm

#136068 - dantheman - Sat Jul 28, 2007 9:45 pm

#136108 - josath - Sun Jul 29, 2007 8:33 am

#136111 - Ant6n - Sun Jul 29, 2007 9:01 am

#136141 - wintermute - Sun Jul 29, 2007 5:40 pm

#136142 - wintermute - Sun Jul 29, 2007 5:41 pm

#136156 - Ant6n - Sun Jul 29, 2007 8:45 pm

#136169 - wintermute - Sun Jul 29, 2007 9:26 pm

#136214 - chishm - Mon Jul 30, 2007 5:43 am