FYI: Writing code for the Nintendo DS.

It is still kind of hard for someone who is okay at writing code, but has no idea about the Nintendo DS, to get started writing DS code. As you might or might not know, I’ve written a demo and other small things for the NDS before, so here is a bunch of random things that are really useful when writing DS code, and enough to get you started, as compressed as I can manage, somewhat geared towards wanting to write demos. (Yes, bullet points. So sue me.)

• http://nocash.emubase.de/gbatek.htm <- This is gbatek. gbatek is the most complete inofficial reference of the NDSs hardware (Yes, even though it’s called “GBAtek”) and reading it or at least skimming it, and having it open for reference, is probably a good idea. Other than the official docs, this is the best documentation about the NDS you can get. It is mostly accurate, the only thing I’ve discovered to be wrong is the documentation of the MASTER_BRIGHT register, but eh. See below for that.
• http://dev-scene.com/images/3/3d/Dov_DS_MemoryMap.png Also, here is a picture of the NDSs memory layout, which can be very useful when you’re playing with the VRAM banks. It is kind of fancy.
• FYI: The DS has TWO CPUs. Two different CPUs. One ARM9 (Main CPU at 66mhz) and one ARM7 (Usually used for sound and/or wifi). It also has a fixed point math coprocessor and sine tables. Also, on the DS, a circle is made out of 512 degrees, for obvious reasons. You’ll get used to it.
• The DS has dedicated 2D hardware for sprite display that can display 128 rotated, scaled sprites (This is a whole fuckton) on up to four layers. You have two engines, one “main” engine and one “sub” engine, which you can map to one screen each. The engines run at 60fps. You get an vblank interrupt, which is neat for timing (Wait for it after each frame => 60fps) and an hblank interrupt which is neat for stupid tricks. The limit here is mostly the available VRAM. You need to map VRAM to the engines. See the memory map and libnds docs, and http://dev-scene.com/NDS/DOCgraphicmodes#VRAM here for what you can map where.
• The DS has dedicated 3D hardware. It works like you would expect 3D hardware to work. You can render to a transparent background if you turn antialiasing off.
• There is a library for doing NDS homebrew things, “libnds”. It’s okay. Documentation is at http://www.devkitpro.org/libnds/ (Kind of terrible to navigate, fuck yeah doxygen). The 3D functions are a little terrible. WAHa wrote a replacement for that, which is IMO nicer to use: DS3D.c / DS3D.h
• There is a higher-level library building on libnds, called “PALib”. I don’t particularily like it, and it’s IMO a little too high level to do cool things. That said, it does allow for making small things real fast (I used PALib to make this little game in like 2 hours). I just don’t think it’s worth it.
• There is a library for playing module audio on the DS, called maxmod. It works okay. It works best with modules in .mod format made in modplug. You need to preconvert modules using an app that comes with the library. It supports the sync effect. Documentation: http://www.maxmod.org/ref/
• To access more data than one can fit into RAM, it is probably a good idea to use nitroFS. It’s probably a good idea to use it for most data, really. http://blea.ch/wiki/index.php/Nitrofs (Also, it is a good idea to convert data such as images to NDS native formats before use. There are tools for this which come with the toolchain.)
• The toolchain you’ll want to use is devkitARM, which you can get http://www.devkitpro.org/ here for windows, lunix and OS X. Their makefiles are kind of a mess, but it’s not hard to write your own, slimmed down one. To test shit without having to get out the actual hardware, which is annoying and takes time, you might want to download an NDS emulator. The best emulator to use for this is no$gba. A working version is here: http://halcy.de/share-p/nocash.zip. (I am linking that here because the author is impossible to contact these days. If you are the author, talk to me, I’ll take it down. Also, I’ll buy a debug copy of no$gba off you.) It is not 100% accurate. It is good with timings, but the 2D emulation could need work. Mostly, it sometimes lets you map VRAM that you do not have, or acts strange with VRAM mapping in other fun ways. You’ll need it a lot probably, so a make rule to start it is a good idea, like so: “/usr/bin/wine /home/halcyon/Desktop/src/DS/devkitpro/nocash/NOCASH.EXE $(NAME).nds” (You get the idea.)
• Another emulator that is nice to have is the official Nintendo emulator “Ensata” (Sadly not supported by Nintendo anymore). It’s a little more accurate sometimes, but also much, much slower. Generally, use no$gba over this.
• If you can get a debug version of no$gba then things would be a lot easier. This is probably impossible since the developer is MIA. If you find one: I want that, badly. What the official devs use to debug (As far as I know) is CodeWarrior attached to the official emulator. This is most likely a pain to set up though. (They use that, or Nintendos in-hardware debugger, but I reckon no one reading this is an official licensed Nintendo dev… edit: except DFYX, but for the purpose of the previous sentence, he doesn’t count. >:T)
• To run code on the actual hardware, you’ll need a flash cart. They are available for cheap from sites like http://dealextreme.com/. There’s no soldering required, you just copy your ROM onto one of these via your computers card reader, put it in the DS and run things. Even though it is cheaper, the best one for development is probably the CycloDS. The “rerun last ROM by holding shoulder buttons during boot” function and generally very usable design (No spring loader that fires your microSD card to the stratosphere) make it very useful. You might want to make a rule in your makefile that compiles a ROM, mounts the microSD, copies the rom over and unmounts / ejects the microSD again to make it easier to play around.
• If you happen to have a copy of the official Nintendo DS technical manual, that is super useful. It really is a lot nicer than gbatek, but not readily available, for obvious reasons.
• If you know other interesting things or links or think/know I am wrong about stuff, tell me. Comment or mail to lorenzd@gmail.com.

PS: About the master bright register: Here is everything you should need to know.

// LOVE COLORED MASTER BRIGHT <3 mode flags:
// 0 0000 fail, nothing
// 1 0001 fail, nothing
// 2 0010 fail, nothing
// 3 0011 fail, nothing
// 4 0100 brightens
// 5 0101 fail, all white
// 6 0110 brightens
// 7 0111 fail, all white
// 8 1000 darkens
// 9 1001 fail, all black
// A 1010 darkens
// B 1011 fail, all black
// C 1100 darkens
// D 1101 fail, all black
// E 1110 darkens
// F 1111 fail, all black

u16* master_bright = (u16*)(0x400006C);
u16* master_bright_sub = (u16*)(0x400106C);
void fade( s16 fade_val ) {
   memset( master_bright, (1<<7) | fade_val, 2 );
   memset( master_bright_sub, (1<<7) | fade_val, 2 );
}
void fadew( s16 fade_val ) {
   memset( master_bright, (1<<6) | fade_val, 2 );
   memset( master_bright_sub, (1<<6) | fade_val, 2 );
}

PPS: Excuse the conversational tone, this was originally written for a private forum. I’ve cleaned it a little, but not much. The DS is a fun plattform to write stuff for. Go have fun and make a kickass demo. :3