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 > Using eeprom to save game and settings.

#110721 - sirpoonga - Thu Nov 30, 2006 11:19 pm

I have been researching this and there is little documentation on this.

With rise of slot 1 devices sram will not be possible. Yes, one could still use fat. However, we all know the issues with using fat and needing to have compiles specific to devices. That might carry over to slot 1 as I see the Acekard doesn't handle regular fat.

So would think the most universal way of saving small amounts of data like game saves or settings would be to use eeprom.

So, here's the questions I have so far.

Is eeprom worth it? I would think so because in order to run commercial games a device needs to implement eeprom.

How big is eeprom? I think this varies from device to device, but is there minimum amount that you will know is there?

From what I can tell eeprom is serial. I see the card.h and .c files in libnds. Doing a search on various forums I don't see anyone talking about how to use that. Is it incomplete? Is there not enough information on how use eeprom?

#110736 - josath - Fri Dec 01, 2006 2:16 am

The smalles eeprom in a commercial game is 512bytes (4kbit). Of course there are a couple games with no eeprom at all. I think the biggest is 256KB (2mbit), though there might be 1 or 2 games with more than that.

The problem with eeprom, is that it's not supported directly on slot-2 devices. So make sure you have some backup method of saving as well (SRAM or FAT), otherwise you'll be leaving out the majority of homebrew devices.

Also, I do not know much how the slot-1 devices work. They may not actually be emulating real eeprom/flash, but instead patching the save game routines in commercial games. If this is the case, you'll have to run your homebrew thru the patcher, and there's a good chance it will NOT work (if their patcher is poorly written, which I highly suspect most of them are).

#110791 - sirpoonga - Fri Dec 01, 2006 4:14 pm

That's what i thought. I will be making a generic save class then with inherited sram and fat classes. Will have to make the build batch file build two versions.

Man, that sucks for slot 1 device owners. I have the dsx which does not use a patcher. It's drag and drop, no patching needed. When you restart the system it will write eeprom to the sav file of the last app that ran.

#110818 - josath - Fri Dec 01, 2006 10:47 pm

sirpoonga wrote:
That's what i thought. I will be making a generic save class then with inherited sram and fat classes. Will have to make the build batch file build two versions.

Man, that sucks for slot 1 device owners. I have the dsx which does not use a patcher. It's drag and drop, no patching needed. When you restart the system it will write eeprom to the sav file of the last app that ran.


Not sure how ds-x works either. it's possible it is patching the NDS games on-the-fly, once they get loaded to RAM or something. Only way to know is to try some homebrew app to write to eeprom and see if it works.

#110824 - sirpoonga - Fri Dec 01, 2006 11:49 pm

josath wrote:

Not sure how ds-x works either. it's possible it is patching the NDS games on-the-fly, once they get loaded to RAM or something. Only way to know is to try some homebrew app to write to eeprom and see if it works.

I wouldn't mind trying that. However that leaves me back at my original questions as I see little to no documentation on how to do it.