gbadev.org forum archive

Hey,

I just bought myself a nifty R4 (slot1) card today.

I copied the game I am working on and it worked fine.

I have been using my supercard lite (slot2) for dev up until now.

I now want to add some persistant data to the cart (i.e. sram stuff)

My question is:

How should I save data using the slot1?

When I start my rom a *.sav file is created by the OS but I can't seem to read or write to it.

All the examples I can find use the memory on slot2 for saving. I have tried simply using:

Code:

*(uint8*)(SRAM) = 69;

Has anyone else run into this? What is the solution? Can homebrew saves be done on an R4?

I'm thinking I should use eeprom for saving but I can't find any example code using this.

I'm not a n00b but really need some advice.

Thanks in advance for any info,
Zapf bandit

Last edited by Zapf_Bandit on Thu Jul 12, 2007 12:48 pm; edited 2 times in total

I have done a bit more research and have found a lib that should be able to read and write to eeprom.

It is called "cardme" and I found it in RAC (http://www.pineight.com/dx/RAC)

Anyhow I included the files and tried the following:

Code:

int cardType = cardmeGetType();
u8 test = 69;
cardmeWriteEeprom(0, &test, 1, cardType);
test = 0;
cardmeReadEeprom(0, &test, 1, cardType);
//test should now be 69 again...

On both my Supercard lite and the R4 "cardType" is -1 (i.e. not detected)

What am I doing wrong? I am even close to the right path?

Please help,
Zapf Bandit

Cardme is intended for reading and writing authentic DS Game Cards. Are you making sure to eject your NoPass or R4 and insert a Game Card before pressing a button that starts the cardme operation? If so, which Game Card are you using?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Would it not be easier to force a card type, rather than trying to detect it, I assume the R4 detects what type of save you are tying to do. I have an R4, so any progress in this would be useful to me also.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

Why not just use libfat + DLDI?
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Quote:

Would it not be easier to force a card type, rather than trying to detect it, I assume the R4 detects what type of save you are tying to do. I have an R4, so any progress in this would be useful to me also.

I had the same thought on the drive home from work. I hope it doesn't brick my R4, I only got it this morning :-P

I wonder which I should use? I think I'll try for the full 512Kb and see what happens...

I am going to try that now and see what happens... Wish me luck...

Zapf Bandit

Quote:

Why not just use libfat + DLDI?

I wanted to avoid having to patch after every build.

I guess it has the great advantage that it will work for all cards...

I guess I could add it into the makefile which I will do if this doesn't work.

Just testing now...

Zapf Bandit

Well, you're using an R4. The latest R4 firmware auto-patches DLDI, so you don't need to worry in that respect.

The SuperCard, not so much so :-(
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Well that's sealed it...

If I tried to pass in any card type to "cardmeWriteEeprom" the whole arm9 seized up.

Looks like it's libfat for me... Thanks for the advice OOPMan.

Great news about the auto patch on R4, really justifies my decision.

Zapf Bandit

Yay !!!

libfat is WAY cool...

I now have a config file that I can read and write from!

For completeness I am going to show all the changes I had to make in the hope that it will help someone else out.

This is using devKitArm r20 and assuming that you are using a varient of the template shell supplied.

1) In "arm9/Makefile" changed:

Code:

LIBS := -lnds9

to

Code:

LIBS := -lfat -lnds9

2) In "arm9/source/main.cpp" added:

Code:

#include <fat.h>
#include <stdio.h>

3) Added this before trying to read and write:

Code:

fatInitDefault();

4) To read:

Code:

FILE* test = fopen ("/game.settings", "r");
if (test)
{
fseek ( test , 0 , SEEK_END );
uint32 testSize = ftell (test);
rewind ( test );
fread ( testBuffer, 1, testSize, test );
fclose ( test );
}

where testBuffer is a allocated char*

4) To write:

Code:

FILE* test = fopen ("/game.settings", "w");
if (test)
{
fwrite( testBuffer, 1, sizeof(testBuffer), test );
fclose ( test );
}

where testBuffer is a allocated char*

In order for this to work correctly you need to patch with the DLDI for the card you use. You can easily add this to your Makefile by changing:

Code:

$(TARGET).nds : $(TARGET).arm7 $(TARGET).arm9
ndstool -c $(TARGET).nds -7 $(TARGET).arm7 -9 $(TARGET).arm9

to

Code:

$(TARGET).nds : $(TARGET).arm7 $(TARGET).arm9
ndstool -c $(TARGET).nds -7 $(TARGET).arm7 -9 $(TARGET).arm9
dlditool ***.dldi $(TARGET).nds

where "***.dldi" id the dldi for the card you use (e.g. r4tf.dldi). You can get these DLDIs from http://chishm.drunkencoders.com/DLDI/

I hope this info helps someone else out,
Zapf Bandit

How do loaders (such as the R4 one) know what type of save chip to emulate for commercial games? Is there info in the file header or something?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

spinal_cord wrote:

How do loaders (such as the R4 one) know what type of save chip to emulate for commercial games? Is there info in the file header or something?

Do they actually emulate a save chip? Or do they simply patch the rom on the fly in order to change eeprom-write commands to r4-fat-write commands?

josath wrote:

spinal_cord wrote:

How do loaders (such as the R4 one) know what type of save chip to emulate for commercial games? Is there info in the file header or something?

Do they actually emulate a save chip? Or do they simply patch the rom on the fly in order to change eeprom-write commands to r4-fat-write commands?

Is it possible, since it asks if you want to create a .sav file every time you run a new .nds file, that it appends that file to the .nds every time it's run?
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

josath wrote:

spinal_cord wrote:

How do loaders (such as the R4 one) know what type of save chip to emulate for commercial games? Is there info in the file header or something?

Do they actually emulate a save chip? Or do they simply patch the rom on the fly in order to change eeprom-write commands to r4-fat-write commands?

Even if the don't emulate the save chip and patch the rom, I assume the differnt save chips are written to differently, so wouldn't the loader still need to know what sort of chip it is supposed to be looking for?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

spinal_cord wrote:

josath wrote:

spinal_cord wrote:

How do loaders (such as the R4 one) know what type of save chip to emulate for commercial games? Is there info in the file header or something?

Do they actually emulate a save chip? Or do they simply patch the rom on the fly in order to change eeprom-write commands to r4-fat-write commands?

Even if the don't emulate the save chip and patch the rom, I assume the differnt save chips are written to differently, so wouldn't the loader still need to know what sort of chip it is supposed to be looking for?

(This is complete speculation) My guess is there is some NitroSDK function like:

Code:

writeEEPROM(u8 *data, int offset, int size);

and this function handles checking for the chip type. All the flashcart authors have to do, is replace that call with a:

Code:

writeToFAT(u8 *data, int offset, int size, char *filename);

They don't have to care what the writeEEPROM function does internally. The flashcarts i've seen, always use a save file that is as big as possible (ie even a game with 512-byte save will have a 256KB save file)

But if you write to the .sav manually, and it is named as the card names it, it will be overwritten by the card and you will lose your data.

I still think it is a good idea to be able to use the modern slot-1 cards virtual eeprom the way that commercial games do it.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

gbadev.org forum archive

DS development > Question of saving to SRAM for R4 cards

#134304 - Zapf_Bandit - Thu Jul 12, 2007 11:37 am

#134306 - Zapf_Bandit - Thu Jul 12, 2007 12:17 pm

#134319 - tepples - Thu Jul 12, 2007 1:20 pm

#134322 - spinal_cord - Thu Jul 12, 2007 1:42 pm

#134323 - OOPMan - Thu Jul 12, 2007 1:49 pm

#134324 - Zapf_Bandit - Thu Jul 12, 2007 1:49 pm

#134325 - Zapf_Bandit - Thu Jul 12, 2007 1:52 pm

#134326 - OOPMan - Thu Jul 12, 2007 2:01 pm

#134328 - Zapf_Bandit - Thu Jul 12, 2007 2:28 pm

#134415 - Zapf_Bandit - Fri Jul 13, 2007 1:30 am

#136025 - spinal_cord - Sat Jul 28, 2007 4:42 pm

#136109 - josath - Sun Jul 29, 2007 8:34 am

#136178 - Dood77 - Sun Jul 29, 2007 10:12 pm

#136663 - spinal_cord - Fri Aug 03, 2007 5:09 pm

#136664 - josath - Fri Aug 03, 2007 5:14 pm

#136709 - spinal_cord - Sat Aug 04, 2007 12:18 am