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 > why is SRAM not #defined as volatile

#120329 - KeithE - Fri Mar 02, 2007 11:10 pm

In memory.h from libnds, there is the following directive:

Code:
#define SRAM          ((uint8*)0x0A000000)


Why is SRAM not #defined as volatile, like this?

Code:
#define SRAM          ((vuint8*)0x0A000000)

#120339 - LiraNuna - Sat Mar 03, 2007 1:16 am

Cause it's not really volatile.
volatile means that the compiler will disable caching optimization options for that variable, like needed with registers. SRAM is a RAM and nothing external (from the source) will change it. so caching it will not do any harm.

... I know i'm wrong here somewhere
_________________
Private property.
Violators will be shot, survivors will be shot again.

#120341 - tepples - Sat Mar 03, 2007 1:27 am

LiraNuna wrote:
Cause it's not really volatile.
volatile means that the compiler will disable caching optimization options for that variable, like needed with registers. SRAM is a RAM and nothing external (from the source) will change it. so caching it will not do any harm.

GBA Game Pak flash memory (512 Kbit and 1 Mbit) consists of registers mapped into SRAM. People making Pok?mon cheat programs need to be able to rewrite the Game Pak's flash memory.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#120349 - HyperHacker - Sat Mar 03, 2007 3:02 am

Not to mention either CPU can access it.
_________________
I'm a PSP hacker now, but I still <3 DS.

#120422 - KeithE - Sat Mar 03, 2007 7:45 pm

I'm accessing the data from the slot-2 DS Motion Card via the SRAM bus, and I had to make a volatile version of the SRAM #define for it to work. I did this:

Code:

#define V_SRAM          ((vuint8*)0x0A000000)


after I figured out that just using SRAM was not working.