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 > EDIT: Self-answered Noob Question About Shared Memory

#146252 - natxcross - Sat Dec 01, 2007 1:13 pm

Hello! I've had a look around, but haven't found the answer to this one anywhere. How much shared memory does the DS have, and where is it?

For those wondering why I'm not figuring out FIFO, it's because I'm trying to merge some MP3 code with PALib while doing the least work possible.

EDIT: And what do you know, no sooner do I post this then I find somewhere with the answer. It's 037F:8000-037F:FFFF according to http://www.neimod.com/dstek/. Well, I did say it was a noob question.
_________________
YS3 - Occasional Entertainment.

#146381 - wintermute - Mon Dec 03, 2007 8:27 am

You didn't find the answer at all.

The switchable iwram banks are dedicated to the arm7 processor in a standard devkitARM nds project, generally you shouldn't change that without a very, very good reason.

As it happens, the entirety of the 4meg ewram region is accessible to both processors but some care is needed to maintain cache coherency & ensure that data written by the arm9 is actually available in the memory for the arm7 to read.

The ewram area is at 0x02000000 to 0x023FFFFF but the upper 4k of that is reserved for system and libnds internal variables.

To avoid problems with the cache there are a couple of methods you can use. Firstly, when writing to memory that you intend the arm7 to read later you should flush the cache for the area you're working with using DC_FlushRange( address, size).

For reading data that the arm7 has written you should ensure that the cache is invalidated for the area you're working with - DC_InvalidateRange( address, size).

To make things slightly easier there is also an uncached mirror of main memory from 0x02400000 to 0x027FFFFF. Reads and writes in this region do not go through the cache and will not require flushing or invalidating.

I'm also going to have to advise that you start learning to code with libnds rather than relying on PAlib. Given that the PAlib installer deliberately breaks devkitARM in order to compensate for their poor design choices I am now removing all pretence of diplomacy regarding that library. Future updates to libnds and devkitARM are extremely unlikely to be compatible with PAlib and several upcoming features will obsolete large parts of their code. As far as I'm concerned the PAlib installer should be considered malware since it overwrites devkitPro supplied libraries with unsupported versions supplied from unknown sources.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog