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 > Saving/Loading

#133654 - yellowstar - Sat Jul 07, 2007 11:10 pm

I need some help with saving/loading data.

I am trying to save/load to DSX Virtual EEPROM, and SRAM
but neithier works.

EEPROM

Solved,
goto this
post for the solution.
http://forum.gbadev.org/viewtopic.php?p=144731#144731

Virtual EEPROM

I'm trying to use the Virtual EEPROM feature
on my DS-X.(firmware version 1.1.2)

The firmware I have supports ~1 MegaByte of Virtual EEP.

The size of my DS-X is 2GigaByte(16Gigabit).

The following is my problems:

Click here for my new problems.

Here's how Virtual EEPROM
is supposed to work on the DS-X:
(As I understand it)
The DS-X has no EEPROM.

It emulates it instead.

When Written to(EEPROM),
it is supposed to write to a section
in the FLASH memory(where the firmware is stored.)
This is where the emulated EEPROM is stored.

When Read from(EEPROM),
the emulated EEPROM is supposed to
be read.

When I reboot my DS-X,
It checks if the emulated EEPROM was written to.
If so, it writes to .sav file,
with the same filename as the last
nds file ran.
It writes all of the emulated
EEPROM to that file.
It also displays "Saving EEPROM".

When I boot homebrew,
it checks for a sav file for
that homebrew.
If it finds it,
the DS-X writes the contents of
that file into the emulated EEPROM.

Each homebrew
would have its
own sav file.
In this way,
all homebrew
on the DS-X can
have there own
slot of Virtual EEPROM.

SRAM


The following problem is old:(My new problem is below)<old>
I am still having problems though.
When I try writing to SRAM,
it won't work.
I'm not sure about reading,
but it probably dosen't work eithier.

When I write to SRAM,
and run the program again,
it dosen't detect the data it wrote to
it before.

When I write to SRAM,
it dosen't mess-up the
saved data on the GBA cart,
so it isn't even writing to SRAM.

It's probably the same way with reading,
not even reading the SRAM.I'm not sure about this one though.
</old>

Here's my new problem:

With Bomberman Tournment,
the new written data written by my
program stays!
So it works!
It also works with other homebrew.

But, when I use my original code(the source code which is below)
it won't do what I want.

When it detects the correct indentifier,
it is supposed to display a string
which is written earlier.

This string is after the identifier.(after the null-terminating byte
for that string.)

It is supposed to display a string which was written earlier,
with "Contents: " before it.(without quotes)

But it won't do that.

It won't even display a character in the SRAM_buffer array.

I also tried all the copy functions.(memcpy,bytecpy,dmaCopy)
Only bytecpy copied the data correctly.

Here's my source code:
Note that this is the whole thing.

main.cpp
Code:

//UPDATED
#include <nds.h>

#include <stdio.h>

#include <string.h>

#define SRAM_SIZE 32760

u8 SRAM_buff[SRAM_SIZE];

char sig[] = "SRAM";

char txt[] = "YAY, IT WORKS!!!";

__attribute__((section (".ewram"),long_call))
void bytecpy(void* in_dst, const void *in_src, unsigned int length)
{
  unsigned char *src = (unsigned char *)in_src;
  unsigned char *dst = (unsigned char *)in_dst;

  for(; length > 0; length--)
    *dst++ = *src++;
}

void InitSRAM()
{

   //REG_EXEMEMCNT &= ~BIT(7);
   sysSetCartOwner(1);

   memset(SRAM_buff,0,SRAM_SIZE);

   //Read SRAM into buffer.
   //memcpy(SRAM_buff,&SRAM[4],SRAM_SIZE);
   bytecpy(SRAM_buff,&SRAM[4],SRAM_SIZE);
   //dmaCopy(&SRAM[4],SRAM_buff,SRAM_SIZE);

}

void WriteSRAM()
{

//memcpy(&SRAM[4],SRAM_buff,SRAM_SIZE);
bytecpy(&SRAM[4],SRAM_buff,SRAM_SIZE);
//dmaCopy(SRAM_buff,&SRAM[4],SRAM_SIZE);

   /*if(SRAM[4]==125)
{
printf("Still there!\n");
}

SRAM[4] = 125;
if(SRAM[4]!=125)
{
printf("Failure\n");
}
else
{
printf("Sucess!\n");
}*/
}

bool IsHomebrew()
{

   for(int i=1; i<=5;i++)
   {

      printf("%c\n",(char)SRAM_buff[i-1]);

      if(SRAM_buff[i-1]!=(u8)sig[i-1])
         return 0;

   }

   return 1;

}

void WaitForKey(KEYPAD_BITS key)
{

swiWaitForVBlank();swiWaitForVBlank();swiWaitForVBlank();

   while(1)
   {

      scanKeys();

      if(keysDown() & key)
         break;

      swiWaitForVBlank();

   }

   consoleClear();


}

bool DoStuff(bool m)
{


   if(m)
   {

for(int i=0;i<=(int)strlen(sig);i++)
         SRAM_buff[i] = sig[i];

for(int i=0;i<=(int)strlen(txt);i++)
         SRAM_buff[strlen(sig)+1] = txt[i];


WriteSRAM();

      return 1;
   }
   else
   {
      printf("GOOD!\n");
      printf("%c %d\n",(char)SRAM_buff[10],(int)SRAM_buff[10]);//This won't even
      //do anything.
      //printf("Contents:\n%s\n",(char*)&SRAM_buff[9]);

      return 1;

   }

   return 1;

}

int main()
{
irqInit();
irqEnable(IRQ_VBLANK);

consoleDemoInit();

   printf("SRAM saving demo.\nInsert a GBA cart that you don't mind losing saved data on.\n\nInsert a GBA cart and press A to continue...\n\n");

   WaitForKey(KEY_A);

InitSRAM();
   
   //WriteSRAM();

   if(!IsHomebrew())
   {

      printf("Invalid Header!\nIf a Commercial game is inserted, the saved data will be lost.\n");
      printf("Do you want to save now?\nPress A to continue...\n");

      WaitForKey(KEY_A);

      DoStuff(1);

      printf("Please reset your DS and start this demo again to see if it worked.\n");

   }
   else
   {
      
      DoStuff(0);

   }

   
   while (1)
   {
      
      swiWaitForVBlank();
      
   }
   
   return 0;
}




NDS file

How do I save/load to a section
in a NDS file?

Tales Of Dagur does this.

This would be used for game saved data.

EDIT:
There was a mistake in the SRAM source code,
in the WriteSRAM function.
Instead of writing to the SRAM,
it would read it.
That is fixed now.

But it still won't work.

EDIT2:

I tried fixing the the size used for the SRAM.(32768)
I tried using dmaCopy for the the SRAM.
I tried using bytecpy for the SRAM.

But none of those fixed it.

EDIT3:

In the SRAM section,
I changed the offset in SRAM it reads/writes to
4.(0-based.)

That didn't fix it.

EDIT4:

SRAM
Tried Bomberman Tournment,
and it works.
It also works with other homebrew.

But with my original code it dosen't work.

See above for my new problems.
I have also updated the source code for the SRAM.

EDIT5:

Added DSX Virtual EEPROM and NDS file
saving/loading questions to this post.

Last edited by yellowstar on Fri Nov 09, 2007 12:07 am; edited 12 times in total

#133656 - tepples - Sat Jul 07, 2007 11:20 pm

yellowstar wrote:
I am trying to save/load to EEPROM and SRAM,
but neithier works.

EEPROM

I tried using the card functions in libnds,
but they don't work.

I switched to cardme,
and that works better than libnds.

With cardme, it will only return the identifier,(or whatever it is, at the very beginning of the EEPROM.)
when reading.
I haven't tried writing to EEPROM,
since reading won't work.

Which Game Card have you put into SLOT-1?

Quote:
SRAM

When I try writing to SRAM,
it won't work.
I'm not sure about reading,
but it probably dosen't work eithier.

When I write to SRAM,
and run the program again,
it dosen't detect the data it wrote to
it before.

Are you using a Game Pak or a SLOT-2 flash card? If a Game Pak, then which title(s) have you tested it with? If a SLOT-2 flash card, then which make and model?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133661 - olimar - Sat Jul 07, 2007 11:36 pm



Last edited by olimar on Wed Aug 20, 2008 10:45 pm; edited 2 times in total

#133663 - tepples - Sat Jul 07, 2007 11:44 pm

I would imagine that bytecpy() from the GBA era still works, even though the address of SRAM has changed. Just watch out for SLOT-2 adapters that lose the SRAM contents on a power cycle *cough*SuperCard*cough*. You may have to use libfat, or you may have to perform an especially quick power cycle to get the adapter to save your data.

Oh, and the SRAM in a GBA Game Pak is only 32768 bytes long.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133669 - olimar - Sat Jul 07, 2007 11:57 pm



Last edited by olimar on Wed Aug 20, 2008 10:45 pm; edited 2 times in total

#133672 - tepples - Sun Jul 08, 2007 12:00 am

olimar wrote:
As for EEPROM writing, after looking at the source, it appears that libnds's implementation of cardWriteEeprom is incorrect.

What would StoneCypher say to that?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133681 - Dood77 - Sun Jul 08, 2007 12:21 am

Alternatively, could a SC user use rebootlib, to reboot to the firmware and save the .sav to card?
_________________
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

#133690 - tepples - Sun Jul 08, 2007 12:34 am

Dood77 wrote:
Alternatively, could a SC user use rebootlib, to reboot to the firmware and save the .sav to card?

Rebootlib 1.1 has a few license terms that I disagree with.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133691 - olimar - Sun Jul 08, 2007 12:36 am



Last edited by olimar on Wed Aug 20, 2008 10:45 pm; edited 1 time in total

#133697 - yellowstar - Sun Jul 08, 2007 1:00 am

tepples:
When I try to read the
EEPROM/SRAM,
I use commerical games.

I only have NoPass devices.

SRAM

I tried fixing the the size used for the SRAM.(32768)
I tried using dmaCopy for the the SRAM.
I tried using bytecpy for the SRAM.

But none of those fixed it.

olimar:

I fixed that problem
in the WriteSRAM function.

I updated the SRAM source code
in my first post.

EEPROM

I am using cardme,
not libnds,
as in libnds it dosen't work.
At least for me it dosen't work.

#133701 - tepples - Sun Jul 08, 2007 1:05 am

yellowstar wrote:
When I try to read the
EEPROM/SRAM,
I use commerical games.

But what are the titles of these commercial games? It may turn out that the games you are trying don't have the save type that you expect. For instance, if you try to read 256 KiB (the size of a type 3 save) from a type 1 or 2 save, you will get a repeating pattern.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133712 - dantheman - Sun Jul 08, 2007 1:49 am

The problem I see with Supercard QPC saving is that with firmware versions 1.70 and up, many users find themselves unable to use said saving feature. Instead of seeing "do you save to SD?", the message turns into "do you load from SD?" and the save does not get written. The following solutions have been made to fix this:
1. Booting into GBA mode instead of DS mode makes it work correctly
2. For Rumble users, the DumpSRAM program acts as a homebrew alternative to the Saver menu. I believe that DumpSRAM is DLDI-capable, meaning that SCSD_moon.dldi can be used if needed, but I'm not entirely sure about that. If I'm wrong, then it will only work on Supercards that work with pre-DLDI libfat and the SCSD.dldi file.

#133721 - olimar - Sun Jul 08, 2007 2:28 am



Last edited by olimar on Wed Aug 20, 2008 10:46 pm; edited 1 time in total

#133722 - yellowstar - Sun Jul 08, 2007 2:32 am

For the EEPROM,
it gets the EEPROM type and size,
and it uses that data when reading/writing.
It does not use preset EEPROM types and sizes,
this is grabbed by functions before the EEPROM
is read, during the initialization.

#133725 - yellowstar - Sun Jul 08, 2007 3:08 am

I tried changing the offset in SRAM were it starts to read/write to,
but that didn't fix it.
I changed it to 4.(0-based)
I tried commenting out the attribute above the bytecpy function,
but that didn't work.

I am now using bytecpy instead of dmaCopy.
There wasn't any noticable difference in speed
between the copy functions.

I tried something similar to what olimar suggested.

It reads and writes it correctly.

But when I reboot my DS and run the program again,
that data in gone/erased.

When I copy the data to/from the SRAM,
it won't work.
But when I access it directly,
like SRAM[4],
it works.
Except the written data gets erased.

#133759 - tepples - Sun Jul 08, 2007 2:13 pm

yellowstar wrote:
But when I reboot my DS and run the program again,
that data in gone/erased.

This is likely to happen with a SLOT-2 adapter or with a Game Pak whose battery is dying. What is the title of this Game Pak?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133795 - yellowstar - Sun Jul 08, 2007 8:05 pm

SRAM

tepples wrote:
yellowstar wrote:
But when I reboot my DS and run the program again,
that data in gone/erased.

This is likely to happen with a SLOT-2 adapter or with a Game Pak whose battery is dying. What is the title of this Game Pak?


What do you mean tepples,
by a Game Pak whose battery is dying?

My DS battery wasn't dying,
when I was testing it.

I am using normal Game Paks.

I tested it with several Game Paks,
and it dosen't work.

Could the code I am using
for initializing the ARM9 for accessing the SRAM
be causing this?
I tried sysSetCartOwner,
but that didn't fix it.

Code:


REG_EXEMEMCNT &= ~BIT(7);
//sysSetCartOwner(1);



I tried to save on homebrew(which I have) DS games
that use SRAM.

EDIT:

Never mind about Tales Of Dagur's saving method,
it dosen't use SRAM.

All the homebrew(which I have) I tried,
won't work on the Game Paks
I tried with my program.

Last edited by yellowstar on Mon Jul 09, 2007 9:00 pm; edited 2 times in total

#133796 - bean_xp - Sun Jul 08, 2007 8:16 pm

I'm no expert but I can be fairly sure that by "battery is dying" he is refering to the system employed by many flashcards so save SRAM into the memory card.

This is basically how I understand it to work (please somebody correct me if I am wrong).

1. The save data is created in a game which in a normal card would write to the SRAM, however in flashcards this memory is often just a portion of normal RAM which is battery backed (to prevent data loss after power down).

2. The data is held in the battery backed memory until next time the DS (or GBA) is powered up.

3. At the next time the card boots up, the flashcard reads the battery backed memory, and saves the data into the filesystem of the memory card (or flash memory).

So what this would mean is that data would be read and written correctly whilst the application is running, however due to low power in the battery when the DS is reset the contents of the memory are lost.

#133804 - yellowstar - Sun Jul 08, 2007 9:55 pm

I am not using flashcarts or anything like that.

I m only using a Slot-1 NoPass device.

For testing the saving I am only using commercial games.

#133806 - tepples - Sun Jul 08, 2007 10:09 pm

yellowstar wrote:
What do you mean tepples,
by a Game Pak whose battery is dying?

The Game Pak itself contains a battery. When this battery no longer holds a charge, the SRAM can no longer keep its data refreshed.

Quote:
I am using normal Game Paks.

I tested it with several Game Paks,
and it dosen't work.

But what are the titles of some of the "several Game Paks" that you tested it with? I want to know these titles in order to figure out whether 1. they actually have SRAM and not something else, and 2. they are at least 5 years old and likely to have had their batteries run out.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#133923 - yellowstar - Mon Jul 09, 2007 8:59 pm

SRAM

A few of the Game Paks I tested is below:
(Note that this isn't the whole list.)
Yoshi Topsy-Turvy
Tetris Worlds
Brain Games/ Ultimate Brain Games

I have made some progress on the Yoshi game,
and saved.
Then I reset my DS and started it again.
It loaded correctly, with the same data it loaded.
So this Game Pak's battery shouldn't be the problem
for this Game Pak, since saving/loading works
correctly on the actual game.

As for the one of the other Game Pak's battery,
I'am not sure if saving on the actual game works.

On Tetris Worlds,
it won't save the options,
and the other stuff,
With this Game Pak.
But it did that the last time
I played it,
which was a long time ago.(atleast ~1 year)

I tested it with my program,
and wrote to SRAM,
and then checked if it worked.
That worked,
but that data got erased after I
turned off my DS.
Its the same way with
the other Game Paks I tested.
This is the same problem
I have with all the Game Paks
I have tested.

On Brain Games/ Ultimate Brain Games,
saving/loading on the actual game works,
so the battery shouldn't be the problem.

After I tried to view the Opponnet section in the Options
section on my DS, it crashed.(no white screens.)
It made noises like when you pull out a GBA Game Pak
on a DS, GBA SP, or GBA.
After that, my DS wouldn't detect that game anymore.
But it works(runs correctly) on a GBA SP.
It dosen't crash were my DS crashed, on
a GBA SP.


As I mentioned in my previous post,(after editing)
I tested all the homebrew(which I have) which uses SRAM.
I tested them with the Game Paks I have tested with my program.
They all don't work.
Except Tales Of Dagur,
which dosen't use SRAM.
Instead it saves to a section somewhere
inside its .nds file,
by using libfat.

Last edited by yellowstar on Mon Jul 09, 2007 10:45 pm; edited 1 time in total

#133944 - HyperHacker - Mon Jul 09, 2007 10:06 pm

You need to try to speak more clearly. If I understand what you're saying:

  1. Yoshi's Topsy-Turvy works just fine, but when you try to modify its save data yourself, the changes disappear after you turn the system off.
  2. Tetris Worlds doesn't save in-game.
  3. Brain Games was working, but it crashed when you tried to view a list of opponents, and now only works in your GBA SP.
  4. No homebrew games are able to save to the games you have inserted.


Is that correct? If so, here's my thoughts on the matter:
1) Yoshi is fine, but it's not using the type of save you think it is. Since the game has a tilt sensor, the memory map could be different than normal.
2) Tetris probably has a dead battery, if it won't even save in-game.
3) I'm not sure I understand this one. Is "Brain Games" a homebrew? What do you mean by opponent list?
4) Homebrew games might be checking to ensure they don't save over a commercial game's save data, or they might be assuming the cartridge has one save type when the ones you've tried have another.

According to a site I can't link to here, Yoshi's Topsy-Turvy's save type is "EEPROM_V124 (4Kbit)". Tetris Worlds has no save function. I don't see any game named Brain anything for GBA. I can't vouch for the accuracy of the site, though.
_________________
I'm a PSP hacker now, but I still <3 DS.

#133970 - yellowstar - Mon Jul 09, 2007 11:09 pm

HyperHacker wrote:

3) I'm not sure I understand this one. Is "Brain Games" a homebrew? What do you mean by opponent list?

According to a site I can't link to here, Yoshi's Topsy-Turvy's save type is "EEPROM_V124 (4Kbit)". Tetris Worlds has no save function. I don't see any game named Brain anything for GBA. I can't vouch for the accuracy of the site, though.



By Brain Games,
I mean Ultimate Brain Games,
from Telegames.

In Ultimate Brain Games,
the opponent option in the options
is where you can change which opponet
you play with.(computer)

It has games in which you must use your brain.
Like Chess, checkers, ect.

How do I use saved data on a Game Pak,
which isn't SRAM?(EEPROM, 4Kbit)

#134023 - tepples - Tue Jul 10, 2007 3:45 am

Fewer than half of GBA games use SRAM save, and none of these do:
  • Yoshi Topsy-Turvy has EEPROM, not SRAM.
  • Tetris Worlds has no save.
  • Ultimate Brain Games uses EEPROM.

Are you trying to write a save backup tool? Or what are you ultimately planning to store in this 4 Kbit (512 byte) EEPROM?

Do you have F-Zero Maximum Velocity?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#134100 - yellowstar - Tue Jul 10, 2007 4:19 pm

tepples wrote:

Are you trying to write a save backup tool? Or what are you ultimately planning to store in this 4 Kbit (512 byte) EEPROM?


I would mainly use saving/loading to SRAM/EEPROM
for games.

But I haven't started making any games for DS yet.

tepples wrote:

Do you have F-Zero Maximum Velocity?


No.

#134106 - yellowstar - Tue Jul 10, 2007 5:36 pm

SRAM

What year did
commercial GBA developers(or the offical GBA SDK)
stopped using SRAM,
and started using something else?(like EEPROM.)

I just found out,(by testing my program with it)
that Bomberman Tournment works!

Other homebrew
on that Game Pak works too!

The problem must have been the Game Paks
I was trying didn't use SRAM,
or didn't have save data.

But, when I use my original code,(with the copy functions for reading/writing)
it won't work.

I have only tried bytecpy.

I will post my new SRAM source code later,
in my first post.

#134109 - dantheman - Tue Jul 10, 2007 6:10 pm

It's not really a matter of which year it was. Some launch games used EEPROM (the ones that didn't need to store very much data) and some used SRAM for storing larger amounts of data. Newer carts may also use FLASH type saving. I believe later on the SRAM was actually replaced with a new save type that didn't require a battery, though we still label it as "SRAM" as it functions in a similar way.

If you could perhaps find a Gameboy Advance release list, you could find the saving data for specific games.

#134115 - yellowstar - Tue Jul 10, 2007 7:10 pm

I have posted the new source code for the SRAM section
in my first post.

I have also posted the my new problem in this post,
and my first post.




Here's my new problem:

With Bomberman Tournment,
the new written data written by my
program stays!
So it works!
It also works with other homebrew.

But, when I use my original code(the source code is in my first post)
it won't do what I want.

When it detects the correct indentifier,
it is supposed to display a string
which is written earlier.

This string is after the identifier.(after the null-terminating byte
for that string.)

It is supposed to display a string which was written earlier,
with "Contents: " before it.(without quotes)

But it won't do that.

It won't even display a character in the SRAM_buffer array.

I also tried all the copy functions.(memcpy,bytecpy,dmaCopy)
Only bytecpy copied the data correctly.

#134138 - yellowstar - Tue Jul 10, 2007 11:05 pm

Added sections in my first post
about questions for DSX Virtual EEPROM and NDS file.

EDIT:

In that post somebody linked to for the bytecpy function,
at the end it says:
tepples wrote:

Don't use the first or last byte of SRAM, as those locations can become corrupted in some cases during power-cycle or pak-swapping.


Is this still true for DS and commercial Game Paks?

#134143 - tepples - Tue Jul 10, 2007 11:27 pm

Corruption of first and last bytes shouldn't happen on GBA serial EEPROM, DS serial EEPROM, or DS serial flash, because those use a seek/read packet structure. But virtually all original DS homebrew games that save use libfat (or its functionally similar predecessor).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#144731 - yellowstar - Tue Nov 06, 2007 3:41 am

I have pretty much solved
my EEPROM problems.

This is thanks to the latest eeprom example.

One of the things I wasn't doing,
was this:
Checking if the card was encrypted.(and thus,
needing to be ejected and put back in.)
(For the Game Cards I tested,
since my card is a Slot-1 DSX, this wasn't a issue)

Reading and writing works great for DS Cards.

I have found something strange.(Unless my
previous problems were caused by buggy card code)
(Note: I switched backto libnds for eeprom)
The code I was using to print read data
wouldn't work. However, when I copy and pasted
the code for that from the example,
it worked.

However,
I am having problems with writing to my DS-X.(Virtual EEPROM)
Reading seems to work.(It seems to be bytes with value 0,
and hex ff)

Whenever I try writing,
it crashes.

Here's the code for writing:
Code:

pos=0;

memset(buffer,50,512);

if(strcmp(gameID,"D!S!XTREME")==0){//Check if Game Card is a DS-X(str is gameID)
size=1024;
type=2;
printf("DS-X detected!\n");
}

while(size>=(Size+pos))
{
                       
                       
                       cardWriteEeprom(pos,buffer,(u32)Size,type);
                       
                       pos+=Size;
}

pos=0;


The only thing I want to use
EEPROM for is for tools.
No HB save data.

I have figured out,(Once my DS-X V EEP problems are fixed)
that for creating EEPROM backups,
I could read EEP on a DS Card,
then write on DSX.
Then Reset,
write the data in EEP,
then repeat untill done.

EDIT:
That would only be used
to backup DS Card EEP,
before I fiddle with the EEP myself.(No savegames
and ect.)(That is, overwriting the EEP on the DS Card
with a savegame on the Inet.)
(For fiddling, that would mean
attempting to crack the save format,
and similar things)

(One thing is
to find out how to destroy all fruit
in ACWW, and put the bells from them in one player's pocket.)
(Harvesting that fruit takes a very long time)
(I don't even harvest that fruit anymore)

Last edited by yellowstar on Fri Nov 09, 2007 12:24 am; edited 1 time in total

#144896 - yellowstar - Fri Nov 09, 2007 12:12 am

Could somebody post some
SRAM writing/reading code?(with download optionally)

#150455 - nipil - Mon Feb 04, 2008 8:30 pm

tepples wrote:
But virtually all original DS homebrew games that save use libfat (or its functionally similar predecessor).

Sorry to bring this back to the surface, but i'm looking forward to save my application state (max 2K of data). And i was thinking "the eeprom is the best place to store this, because afaik official games do this." What you're saying actually means that i shouldn't do it, and save to the cart via libfat-like library. Did i get it wrong, or is it what you actually advice ?

I wonder, because conceptually, i find it far more logical to have our applications work in the same way as standard DS games... But of course, there might be some limitations/problems i'm unaware of.
_________________
NDS Lite Gold/Silver, MK5/R4DS, MSI PC54G2, D-Link DI-624

#150470 - yellowstar - Tue Feb 05, 2008 1:42 am

nipil wrote:
tepples wrote:
But virtually all original DS homebrew games that save use libfat (or its functionally similar predecessor).

i'm looking forward to save my application state (max 2K of data). And i was thinking "the eeprom is the best place to store this, because afaik official games do this." What you're saying actually means that i shouldn't do it, and save to the cart via libfat-like library. Did i get it wrong, or is it what you actually advice ?

I wonder, because conceptually, i find it far more logical to have our applications work in the same way as standard DS games... But of course, there might be some limitations/problems i'm unaware of.

You should always/mainly use fat, not eeprom. Every card in existence supports fat.(That is, they have a DLDI patch available)
You should not use EEPROM, because hardly any cards, as far as I know,
have that.(And only Slot-1 cards can have that, not Slot-2s.)

You could have EEPROM for a option for saving, but you should have fat as the primary saving method.But it is much better to only use fat.

#150479 - nipil - Tue Feb 05, 2008 8:40 am

yellowstar wrote:
But it is much better to only use fat.

Ok, thanks
_________________
NDS Lite Gold/Silver, MK5/R4DS, MSI PC54G2, D-Link DI-624

#150508 - tepples - Tue Feb 05, 2008 10:35 pm

yellowstar wrote:
EDIT:
That would only be used
to backup DS Card EEP,
before I fiddle with the EEP myself.(No savegames
and ect.)(That is, overwriting the EEP on the DS Card
with a savegame on the Inet.)
(For fiddling, that would mean
attempting to crack the save format,
and similar things)

The ACWW save format is already thoroughly cracked.

Quote:
(One thing is
to find out how to destroy all fruit
in ACWW, and put the bells from them in one player's pocket.)
(Harvesting that fruit takes a very long time)

Which fruits does your town have? If you have Wi-Fi, I know someone who lives in Picken who could come to your town, give you some pointers as to how to harvest more efficiently, and help you fix it up. PM me if you want Chester@Picken to pimp your town.

Quote:
(I don't even harvest that fruit anymore)

Some people on animalxing.com told me fishing is faster.


But especially with this case, the problem with only using FAT is that a lot of cards that use FAT can't fit in the slot at once with a DS Game Card. A DS-X inserted into a powered-on DS resets the DS in some cases (has this been fixed?), and R4/M3 Simply doesn't bring up the SD card interface properly.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#150515 - yellowstar - Wed Feb 06, 2008 12:53 am

tepples wrote:
yellowstar wrote:
EDIT:
That would only be used
to backup DS Card EEP,
before I fiddle with the EEP myself.(No savegames
and ect.)(That is, overwriting the EEP on the DS Card
with a savegame on the Inet.)
(For fiddling, that would mean
attempting to crack the save format,
and similar things)

The ACWW save format is already thoroughly cracked.

Yay. What I want to do is transfer some EEPROM save data to/and from a Game Card to my DS-X Virtual EEPROM basicly. A good while ago I wrote a liblobby EEPROM program which transfers EEP, but I never finished it.

Quote:

Quote:
(One thing is
to find out how to destroy all fruit
in ACWW, and put the bells from them in one player's pocket.)
(Harvesting that fruit takes a very long time)

Which fruits does your town have? If you have Wi-Fi, I know someone who lives in Picken who could come to your town, give you some pointers as to how to harvest more efficiently, and help you fix it up. PM me if you want Chester@Picken to pimp your town.

I don't have Wifi. I got a N Wifi dongle at XMas, but the homebrew drivers indirectly busted my XP. Now I'm not allowed to use those drivers. Now both of my computers aren't working right, and they need fixed. Once they are fixed, I'm going to hunt down a Wifi device.

But if I do decide to accept that help, whoever would be helping with this would need to be warned that I'm using Dial-Up.(Of course it should be noted that's only because I'm stuck with it)

Here's my method for harvesting:
I divide the work in half. First I work on the half of the town to the east of the river, and to the east of the shop.(And the shop is on the other side)
When I finish that side, I then attack the other side, which has the shop.
This side west gets done very quickly.
I also divide each side in half horizontally. I tackle each section one-at-a-time.
When starting on one half of the town, I always start at the beach.

Now, for the procedure:
1. Start at the beach on the right side of the river.

2. Dash to the nearest fruit tree, shake all the fruit out, and grab all the fallen fruit.

3. Repeat #2 until your pockets are full.

4. Run for the shop. Use the Y button to shoot the fruit over to the sell box. Move the cursor over every item, then press Y on each. Quickly do every as fast as possible.

5. Go back to where you were, and repeat the procedure.

Quote:

Quote:
(I don't even harvest that fruit anymore)

Some people on animalxing.com told me fishing is faster.

*Bookmarks that web site*(Firefox)
Lots of stuff to dig through on that site!(*Later discovers it's mostly GC*)

But anyway:
I have 100% foreign fruit. The long-ago local fruit was completely obliterated.(Not intended though... It was pears.)
It's FOREVER to make anything close to what I make.
It takes about an hour to finish harvesting.

Quote:

But especially with this case, the problem with only using FAT is that a lot of cards that use FAT can't fit in the slot at once with a DS Game Card. A DS-X inserted into a powered-on DS resets the DS in some cases (has this been fixed?), and R4/M3 Simply doesn't bring up the SD card interface properly.

That DSX reset issue was fixed.The idea with my app is to...
*Realizes this won't work as I thought...*
Looks like I need to finish the liblobby app I wrote...

#150712 - yellowstar - Mon Feb 11, 2008 2:24 am

I recently started playing ACWW again. I also thinned the trees.(All most all of them are oranges)

Previously, there were 200 orange trees, with a whopping profit of 300,000 bells.(To bad I only used to get 100,000... The rest goes to the owner of those trees. My brother hired me to do that work.)

Now I'm trying to get a perfect environment, but with troubles. I think the problem is the fact that most trees are fruit.

I think I figured out the bug in my Nifi EEP app. But I decided it would be best to rewrite the whole thing.