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.
Description EWRAM IWRAM ITCM DTCM REGISTER MAP VRAM Location 0x2000000 0x37F8000 N/A 0x0080000 0x4000000 0x6000000 Size 4MB 32KB 16KB 16KB (registers seem to be found as high as 0x4010000 and higher) ~700KB
the memory gets mapped to more familiar locations.arm.com. nearly every aspect of the DS operation is controlled via these mapped registers. IWRAM: Internal working ram. REGISTER MAP: Like the GBA. It is this memory in which the arm9 and 7 binaries are normally executed from. The arm 7 has read-write access for the entire memory space. is seen only by the arm7. ITCM and DTCM: These are the arm9 caches. VRAM: V-ram is quite different than that of the GBA. 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
. The approach normally taken is to enable the instruction catch and map the data catch as fast ram. by default. Much of the register space is directly mapable to the GBA registers making them fairly easy to figure out. 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. It may be required to keep the data catch as a memory region since the arm9 IRQ vector is located inside. The bus appears to 16-bits wide and operate at 12MHz. It is actually two adjacent banks of memory that can be assigned to either CPU via a memory control register. Much is still unknown about the operation of these registers but the rest of this tutorial will be for the purpose of exploring them.GBA CART
Depends on your flash cart but 32MB max
EWRAM: This memory is the only shared memory between the two processors. It is a 32 Bit bus and its operating speed is unknown at this time but likely 16 or 33MHz. The cache and the memory unit work in tandem and are vital due to the slow external memory bus. the operation of which is explained in detail in the arm docs on www. The CPUs cannot have access to the same bank at the same time.
The sub screen is nearly identical if somewhat more limited. 5 of them use tile based rendering while the 6th is a bitmap mode similar to mode 4 on GBA. It would appear that any of the first four memory banks can be mapped in as memory for the tile and sprite graphics. Only the second two banks seem to be mapable to the sub engine. 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. suggesting that these memory regions are not mapped into vram banks. 3D engine: Preliminary works shows the 3D engine to be register driven with some elements of FIFO type input for vertex. are the palette and OAM tables mapped at 0x500:0000 and 0x700:0000 respectively and always seem available. Also present in vram. -Color format appears to be standard 16-bit BGR.Sub 2D OBJ`
0x660:0000 to 0x66??????
I have yet to test access to the actual vram banks when those banks are mapped onto lower vram. texture. The main and sub rendering engines can be assigned to output to either LCD.
. and color data. The first 6 are similar to modes found on the GBA. This means that frame buffer graphics on both displays does not appear possible…this seems odd to me and bares further review. 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. 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
The DS has two 256 x 192 pixel displays 2D engine: The DS has two rendering engines for 2D backgrounds. Fixed point vertex and texture format. The first 5 modes appear to operate the same as the main display while the 6th and 7th appear to be missing. Extensive testing still needs to be done. The main render engine appears to have 7 different operating modes. The operation of these modes will be explored in more detail in the next chapter.
The touch pad operates via a serial interface only accessible from the ARM7.-Vertex format has more than one form.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. But. 8 of those bytes happen to be the starting location for the arm7 and arm9 executable binaries. 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. Likely just a few direct sound channels relying on the arm7 to control the sound engine in software.
The 12-button controller operates identically to the GBA with the addition of two more buttons. No texture filtering. This register set spans a range of nearly 100 addresses which seems somewhat non-standard when compared to controlling other wifi chips.
Currently there are only two ways to run code on the Nintendo DS. 3D on both screens is possible at ½ frame rate although the mechanism for this is currently unknown. One of the things transferred during this time is the header for the cartridge. The new X and Y keys have been moved to an IO register only accessible from the arm7. 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).
Very little is known about the DS side of the wifi chipset (hence forth referred to as NIFI). because of this there is a brief period at the beginning of comms during which the data is not encrypted. The second is to use some sort of logic circuit to intercept the information coming from the Metroid cartridge. The encryption is different every time the cartridge is ran meaning the data is being encrypted by the cart in real time. The header contains 512 bytes of data. Anti-aliasing looks possible. Sound: No idea. The first is being a licensed developer and having a hardware kit that takes code. Hardware toon shading (have not seen this in action yet). When the DS boots it reads the cartridge and sets up encryption between the cart and the DS. By intercepting the header as it is transferred from the cart to DS and altering those bytes Darkfader was able to cause the
.bottlelight. -texture formats are varied and include paletted and 16bit BGR. Joat (www. Check out the wiki for more info on the touchpad.
darkfader.devkit. 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. Several people have duplicated this process. Since changing the start address changes the 16-bit CRC it too must be modified.net has a tool which will calculate the CRC of a header and let you view the details contained in the header.
First thing that must be done is tool setup. Setting up the software is quite simple. There is also effort in understanding the DS’s ability to multiboot over the nifi interface. Next you will need the library. Once control is attained for the ARM7 you can load code into the address space for the ARM9 executable and intercept it.
. Get ndslib from here: http://sourceforge. 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). 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. www. These dongles should be in the 30$ range. Google should tell you what you need to know. If you do not already have devkitARM installed for GBA dev you will need to do this now. 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.net/projects/devkitpro Follow the guide for setting up the compiler under the setup section of www.tk.arm7 to start from the GBA cart slot. If you are interested in such a pass through email me at passthrough@drunkencoders. 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. Currently people are attempting to understand the boot processes enough to remove the need for an original DS cart in the pass through.com . The other two bytes of data are the CRC at the end of the header. all of which have used an FPGA (field programmable gate array greatest geek toy ever created). of course to use this tool you will need some way to dump the header.net/projects/ndslib or from the tools section in zip format if you are uncomfortable with CVS. Installing devkitARM: Grab the zip file from: http://sourceforge. 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. 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.
export NDSLIBPATH := /c/projects/dsdemo/ndslib
. 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. again NO SPACES in any path name. 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. Also you can go to the command prompt and type 'make'. What you will end up with is three directories. Compiling your first demo: You will want to get the DS template from www.Again it must be unzipped into a directory with no spaces in the name. Tomorrow we will actually write our own code and explore the similarities and differences between GBA and DS 2D hardware. ARM9. 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. 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 have not read the original GBA tutorials now would be an ideal time as the following will assume you have. That is all for day 1. Assuming the library built you are ready to go.com/ds It provides a setup and makefiles for compiling a NDS demo. The other two are pretty self explanatory.bottledlight. Assuming everything went well you should see the demo build. and BOOT. You should unzip the template and then copy it to someplace convenient to edit. Open CommonMakefile. If you are experienced with GBA you will find it familiar code. ARM7. You are welcome to play with the source code in the main. You will notice that they both have some example code built in. Boot contains the code that actually takes over the DS and loads the arm7 and arm9 binaries into ram.in in a text editor and edit the following line: 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. If it did not go back an read the installation steps and ensure you did not miss any steps.cpp files for either cpu.