Nintendo DS Day 1

An introduction.

Hardware.
Memory.
Graphics.
Input.
Wifi.
Running code, hacking hardware, tunneling.

So how close is the DS to the GBA? Well, close enough that the transition will be simple
on the 2D side of the house with the background and sprite engines almost identical in
operation to the GBA. But, the DS differs greatly in other areas.

DS System hardware:

Processors:
The DS has two processors. One is the same as found in the GBA, an ARM7TDMI, but
clocked at about 33MHz. It has access to most of the memory map by default. It has no
special features and the same maskable IRQs that are present on the GBA (just a few
more of them). Its main purpose is as a slave to the arm 9 performing things such as wifi,
sound engine processing, and touch pad control. Its access to memory mapped registers
is limited, such that the registers it sees appear to be the same register map presented
when in GBA mode with the addition of sound registers, SIO registers and a bank of wifi
registers. It seems to have no access to video hardware (memory or registers) but it may
be possible to give it access via some memory control register.

The second processor is an ARM9426E clocked at 66 MHz. It has two 16KB caches, one
for data and one for instruction memory. These are either 4-way set-associative or
directly mapped. Interrupts work similar to the arm7 but the IRQ vector is less rigidly
defined and resides in the data catch. It has a limited memory protection unit controllable
by a special purpose register: CP15. It allows 8 regions of memory to be specified as
read/write and cacheable and accesses outside the range generate data abort exceptions.

Memory:
Description Location Size
EWRAM 0x2000000 4MB
IWRAM 0x37F8000 32KB
ITCM N/A 16KB
DTCM 0x0080000 16KB
REGISTER MAP 0x4000000 (registers seem to be found
as high as 0x4010000 and
higher)
VRAM 0x6000000 ~700KB
GBA CART 0x8000000 Depends on your flash cart
but 32MB max

EWRAM:
This memory is the only shared memory between the two processors. The arm 7
has read-write access for the entire memory space. The bus appears to 16-bits wide and
operate at 12MHz. It is this memory in which the arm9 and 7 binaries are normally
executed from.

IWRAM:
Internal working ram, by default, is seen only by the arm7. It is actually two
adjacent banks of memory that can be assigned to either CPU via a memory control
register. The CPUs cannot have access to the same bank at the same time. It is a 32 Bit
bus and its operating speed is unknown at this time but likely 16 or 33MHz.

ITCM and DTCM:

These are the arm9 caches, the operation of which is explained in detail in the arm
docs on www.arm.com. The cache and the memory unit work in tandem and are vital due
to the slow external memory bus. The approach normally taken is to enable the
instruction catch and map the data catch as fast ram. It may be required to keep the data
catch as a memory region since the arm9 IRQ vector is located inside.

REGISTER MAP:
Like the GBA, nearly every aspect of the DS operation is controlled via these
mapped registers. Much is still unknown about the operation of these registers but the
rest of this tutorial will be for the purpose of exploring them. Much of the register space
is directly mapable to the GBA registers making them fairly easy to figure out.

VRAM:
V-ram is quite different than that of the GBA. It consists of 9 banks of memory
located as follows:
Bank Location Size Use
Bank A 0x680:0000 0x20000 2D and Textures
Bank B 0x682:0000 0x20000 2D and Textures
Bank C 0x684:0000 0x20000 2D and Textures
Bank D 0x686:0000 0x20000 2D and Textures
Bank E 0x688:0000 0x10000 Texture Palette
Bank F 0x689:0000 ?? ??
Bank G ?? ?? ??
Bank H ?? ?? ??
Bank I ?? ?? ??

When using vram for 2D, the memory gets mapped to more familiar locations.
Memory Accessible at Banks map-able
Main 2D BG 0x600:0000 to 0x608:0000 0-3
Main 2D OBJ 0x640:0000 to 0x644:0000 0-3
Sub 2D BG 0x620:0000 to 0x62?????? 2
Sub 2D OBJ` 0x660:0000 to 0x66?????? 3

I have yet to test access to the actual vram banks when those banks are mapped
onto lower vram. Extensive testing still needs to be done.

Also present in vram, are the palette and OAM tables mapped at 0x500:0000 and
0x700:0000 respectively and always seem available, suggesting that these memory
regions are not mapped into vram banks.
Purpose Location Size
Main BG Palette 0x500:0000 0x200
Sub BG Palette 0x500:0200 0x200
Main OAM Table 0x700:0000 0x400
Sub OAM Table 0x700:0400 0x400

Graphics Engine:
The DS has two 256 x 192 pixel displays

2D engine:
The DS has two rendering engines for 2D backgrounds. The main render engine
appears to have 7 different operating modes. The first 6 are similar to modes found on
the GBA. 5 of them use tile based rendering while the 6th is a bitmap mode similar to
mode 4 on GBA. The 7th mode is strait frame buffer access in which any of the first four
vram banks can be rendered directly on screen. The frame buffers are all 16 bit BGR
graphics. It would appear that any of the first four memory banks can be mapped in as
memory for the tile and sprite graphics.
The sub screen is nearly identical if somewhat more limited. The first 5 modes
appear to operate the same as the main display while the 6th and 7th appear to be missing.
This means that frame buffer graphics on both displays does not appear possible…this
seems odd to me and bares further review. Only the second two banks seem to be
mapable to the sub engine.
The main and sub rendering engines can be assigned to output to either LCD. The
operation of these modes will be explored in more detail in the next chapter.

3D engine:
Preliminary works shows the 3D engine to be register driven with some elements
of FIFO type input for vertex, texture, and color data. The fifo appears to span many
registers hinting either many separate fifos or perhaps just a convenient means of sending
a command and data at the same time (ie a write to the vertex fifo is like sending a load
vertex data fifo command and then sending vertex data…this is just personal speculation
but seems logical due to the slow DS memory being a major bottleneck) No idea yet what
performance will be attainable but the following features seem to be possible based on
observation of the games and statements from Nintendo:
Fill rate comparable to N64 with improved texture memory.
Fixed point vertex and texture format.
-Color format appears to be standard 16-bit BGR.
 -Vertex format has more than one form, but the only one currently known
is 16 bit signed fixed point with 3 bits integer 12 bits fraction and 1 bit
sign (twos complement negative numbers).
-texture formats are varied and include paletted and 16bit BGR.
No texture filtering.
Anti-aliasing looks possible.
Hardware toon shading (have not seen this in action yet).
3D on both screens is possible at ½ frame rate although the mechanism for this is
currently unknown.

Sound:
No idea. Likely just a few direct sound channels relying on the arm7 to control
the sound engine in software.

Input:
The 12-button controller operates identically to the GBA with the addition of two
more buttons. Oddly the arm 9 and arm 7 can only read the original 10 buttons that
would be found on the GBA in the KEYS register. The new X and Y keys have been
moved to an IO register only accessible from the arm7.
The touch pad operates via a serial interface only accessible from the ARM7.
Check out the wiki for more info on the touchpad.

WIFI:
Very little is known about the DS side of the wifi chipset (hence forth referred to
as NIFI). Joat (www.bottlelight.com) has done a bit of poking in the Metroid code and
found an extensive set of register operations that appear to be the means of
communicating with the nifi chip. This register set spans a range of nearly 100 addresses
which seems somewhat non-standard when compared to controlling other wifi chips.

Running Code:
Currently there are only two ways to run code on the Nintendo DS. The first is
being a licensed developer and having a hardware kit that takes code. The second is to
use some sort of logic circuit to intercept the information coming from the Metroid
cartridge.
When the DS boots it reads the cartridge and sets up encryption between the cart
and the DS. The encryption is different every time the cartridge is ran meaning the data is
being encrypted by the cart in real time. But, because of this there is a brief period at the
beginning of comms during which the data is not encrypted. One of the things transferred
during this time is the header for the cartridge.

The header contains 512 bytes of data, 8 of those bytes happen to be the starting
location for the arm7 and arm9 executable binaries. By intercepting the header as it is
transferred from the cart to DS and altering those bytes Darkfader was able to cause the
arm7 to start from the GBA cart slot. In total only four bytes need to be changed: The
original start address for the ARM7 binary is 0x238:0000 so the high two bytes are over
ridden to be 0x800:0000. The other two bytes of data are the CRC at the end of the
header. Since changing the start address changes the 16-bit CRC it too must be modified.

This method should work fine on any cartridge but the CRC will need to be
calculated for each one (or some means to calculate the CRC real time in logic).
www.darkfader.net has a tool which will calculate the CRC of a header and let you view
the details contained in the header; of course to use this tool you will need some way to
dump the header.

Once control is attained for the ARM7 you can load code into the address space
for the ARM9 executable and intercept it.

Several people have duplicated this process, all of which have used an FPGA
(field programmable gate array greatest geek toy ever created). Currently people are
attempting to understand the boot processes enough to remove the need for an original
DS cart in the pass through. Once this is figured out (or found to be impossible) dongles
will likely be available that will allow you to use your GBA flash cart as a dev platform.
These dongles should be in the 30$ range. As it stands I have ordered a few PCBs to
make some simple pass through prototypes. If these work out I will be willing to make
more but at the moment this will require you to send me your Metroid demo cart which
will be soldered directly to the pass through. If you are interested in such a pass through
email me at passthrough@drunkencoders.com .

There is also effort in understanding the DS’s ability to multiboot over the nifi
interface. This method if ever successful will likely only be possible with very specific
hardware as the drivers need to be hacked to allow broadcasting of the nifi packets. It
appears that many cards handle wifi at too high a level and do not allow the level of
control necessary to broadcast the custom nifi packets.

Getting Started:
First thing that must be done is tool setup. Setting up the software is quite simple.
If you do not already have devkitARM installed for GBA dev you will need to do this
now.

Installing devkitARM:
Grab the zip file from: http://sourceforge.net/projects/devkitpro
Follow the guide for setting up the compiler under the setup section of
www.devkit.tk.
Next you will need the library. Keep in mind this library is in the very early
stages of development and will be updated frequently. Because of this you may want to
learn how to access the source forge CVS to keep your library as up to date as possible.
Google should tell you what you need to know.
Get ndslib from here: http://sourceforge.net/projects/ndslib
or from the tools section in zip format if you are uncomfortable with CVS.
 Again it must be unzipped into a directory with no spaces in the name.
Run the install batch file to build the library and the start up code as well as add
the needed files to your compiler so it can produce valid DS code. If you installed devkit
arm to anywhere other than c:\devkitarm then you will need to edit the first line of the
batch file to reflect that.
Assuming the library built you are ready to go. If it did not go back an read the
installation steps and ensure you did not miss any steps.

Compiling your first demo:

You will want to get the DS template from www.bottledlight.com/ds It provides
a setup and makefiles for compiling a NDS demo. If this looks complicated remember
that we are creating a demo for a dual processor system so binaries need to be build for
both processors and then combined in some way that can be loaded onto the DS.
You should unzip the template and then copy it to someplace convenient to edit,
again NO SPACES in any path name.
What you will end up with is three directories. ARM7, ARM9, and BOOT. Boot
contains the code that actually takes over the DS and loads the arm7 and arm9 binaries
into ram. The other two are pretty self explanatory. You will notice that they both have
some example code built in.
Open CommonMakefile.in in a text editor and edit the following line:
export NDSLIBPATH := /c/projects/dsdemo/ndslib
so that it points to the directory you installed ndslib.
The template includes a visual studio template file so you can easily build from visual
studio by hitting compile. Also you can go to the command prompt and type 'make'.
Assuming everything went well you should see the demo build.
Now when you look in the arm9 directory you will have an emu friendly binary
and if you look in the main directory you will have a demo you can write to your flash
cart.
You are welcome to play with the source code in the main.cpp files for either cpu.
If you are experienced with GBA you will find it familiar code.
That is all for day 1. Tomorrow we will actually write our own code and explore
the similarities and differences between GBA and DS 2D hardware. If you have not read
the original GBA tutorials now would be an ideal time as the following will assume you
have.