07/05/23 17:43:56 GSLlsCFn
横槍失礼します。
VRAMC/DはARM7からアクセスするときは8bit読み書きできて、普通にWRAMの増設に使えるので便利でした。
ARM7でmallocすると、WRAMのコード領域を除いたエリアから切り分けしてくれますが、普通の4MByteメモリをARM9でmallocしてIPCでARM7に渡してやれば、ARM7で自由に使えます。
malloc使わないで4MByteエリアを同時に使っても構わないのですが、メモリ管理が面倒なので普段はARM9からmallocするかな、くらいの感じです。
補足1。ARM9のデータキャッシュ（読み書き両方）さえ気を付けていれば、ARM7とARM9のデータ通信に4MByteエリアを使うことも出来ます。
補足2。4MByteエリアを同時にアクセスすると、どちらかのCPUがもう片方のCPUを待ちます。どちらのCPUが待つかはREG_WAIT_CR (*(vuint16*)0x04000204) で設定できます。
補足3。REG_WAIT_CRの設定はARM9側からしかできません。
補足4。DevKitProR20で正式採用されたARM7用WRAM96kbyte設定ですが、一部のファームウェアはこれを正しく扱えません。
問題があったときは（リンカスクリプトをいじるのは面倒なので）r17aかr19辺りを使うのが楽だと思います。SharedRAMを結合しないのでWRAMが64kbyteになります。
補足5。サウンドバッファを4MByteエリアに確保するときは、CPU優先設定をARM7優先にしておかないと、ARM9に負荷が掛かるたびにブツブツ切れます。
補足6。ARM7で大量のメモリをハンドリングするときは、VRAM_CとVRAM_Dを両方ともARM7に割り当てて（ついでに暇があればリンカスクリプトをいじってmallocをVRAM領域にして）256kbyte使うと便利です。
この場合はARM7優先設定する必要がありません。
補足7。libnds-20060719より前の基本ライブラリにはVRAM設定が不十分です。128kbyteまでしかdefineがありません。VRAMC/Dを256kbyte全部ARM7に割り当てるときは、libnds-20070127以降を使う必要があります。
defineを自分で定義すれば気にしなくても大丈夫だと思います。
長い上に箇条書きな補足ばかりですいませんです。
追記、C++を使うと（例外とか使わなくても）C++ライブラリが組み込まれるので、r18/r19b辺りを使うときは、ARM7でC++を使わない方がいいかも。