The Allegro Wiki is migrating to github at

NintendoDS architecture

From Allegro Wiki
Jump to: navigation, search
This article is incomplete and needs some revision or has some pending TODOs. Please help Allegro by editing and finishing it. When the article becomes complete, you may remove this tag.

Architecture of the NintendoDS port

The NintendoDS is a wonderfully simple platform to play lots of cool games. Using devkitpro and libnds it is now possible to port allegro over to the platform. Still in development, the port is now showing some progress.

The Port of Allegro to the DS is available via Subversion at

The DS itself is run by two ARM processors, an ARM7 which runs the touchscreen, WiFi, and sound and an ARM9 which runs everything else. Code can be offloaded to the ARM7 with no real downside, but this isn't Nintendo's way of doing things. The two processors communicate with a FIFO queue and some shared RAM. The ARM9 is a 32 bit processor runing at 66MHz while the ARM7 runs at 33MHz. There is 4MB of main RAM on the DS with 656KB of VRAM.

TODO: Add more details on architecture and porting Juvinious 11:38, February 7, 2007 (MST)




Input consists of a joystick and a touch screen.


Joystick has 4 directional pad and 8 buttons.

Driver is complete


Mouse input is driven my the touchpad.

Driver is complete


No keyboard available on the DS so for the time being there is no support, however in the future it might be possible using a touchscreen keyboard to use for input.


Dual 256x192 pixel screens for video output. Currently, one screen can be used for display with the other for text output. The bug preventing both screens from being used is still to be sorted out. One minor note is the screens should not be thought of as top and bottom, but rather main and sub. This corresponds to the video cores which both can be mapped to either screen.



16/15bit currently works, but doesn't support the alpha channel, and 8bit is likely broken (The ARM platform doesn't allow unaligned memory access).


The hardware video driver currently supports video bitmaps with buffering and scrolling in at least 16 bit (8 bit is yet to be tested). There seems to be a problem with makecol or clear_to_color (likely the former). Sprites (non-static bitmaps) are still to be thoroughly tested and implemented.

Initiating a hardware graphics mode is a bit touchy. As opposed to how Allegro usually does things, width and height of set_gfx_mode are completely ignored with focus being instead put upon the virtual width and height. Accepted values for the virtual width and height are 256x256, 512x256, and 512x512. Any values that are not one of these will be changed so they are. It is very important to be very aware of sizes and color depths as VRAM on the DS is quite limiting compared to other platforms. There is a total of 656kb of VRAM to be allocated to to video and system bitmaps of both the main and the sub screen. This already limited amount of VRAM also cannot be spread out as you like, but rather along strict parameters. In fact, the only options you have are the virtual width and height, as well as two special parameters (set by al_nds_set(NDS_MORE_SUB_SPRITE_VRAM, 1) which is on by default and al_nds_set(USE_SUB_SCREEN, 1) also on by default). VRAM allocated to video bitmaps can be calculated by multiplying the virtual width by the virtual hieght and multiplying by two if in 16 bit mode. The sprite VRAM is a bit more complicated and spelled out below.

For the main screen if the sub screen is not being used and the VRAM allocated to video bitmaps is 512kb there will be 96kb for sprites, if less VRAM is given to video bitmaps, there will be 256kb for sprites. For the main screen if the sub screen is being used and 128kb or less VRAM is given to video bitmaps and NDS_MORE_SUB_SPRITE_VRAM is set there will be 224kb for sprites, if it is not set, there will be 256kb. For the main screen if the sub screen is being used and 256kb or VRAM is given to video bitmaps (try to give any more and the sub screen will not have enough to work) and NDS_MORE_SUB_SPRITE_VRAM is set 96kb will be left for sprites, if it is not set there will be 128kb. For the sub screen if NDS_MORE_SUB_SPRITE_VRAM is set there will be 128kb for sprites, otherwise 16kb. Only 128kb of VRAM could be given to video bitmaps for the sub screen (lest the developers make the initialization code more intelligent).

Hardware Planning

The DS hardware supports Allegro's page flipping, scrolling and triple buffering, whether or not they should all be implemented or all implemented to work at the same time is another story. The DS also supports video "objects" like tiles and sprites, allegro lost the notion of sprites being separate from BITMAPs a long long time ago, so the only way to fit it into the current api is to use system bitmaps for that purpose, allocating and using a system bitmap will actually modify sprite data associated to that system bitmap. Or, instead, just provide a DS only set of api functions that make handling sprite and tile modes easier.

The developers (mainly Tomasu and relpats_eht) are currently undecided on which way to go for this port, and how flexible the port itself should be (should you be able to tell allegro that you're reserving some VRAM memory bank for yourself, and tell allegro not to touch it at all? Should you be able to enable pageflipping, scrolling AND triple buffering at the same time? Sounds stupid, and it likely is, as it'll really cut down on the usable vram per screen+page). The current pseudo-plan is, motivated by laziness, to have the port support as much of Allegro as is possible while leaving out DS specific features.

Please comment in Talk.


Allegro supports playing raw mono or stereo 8 or 16 bit PCM on the DS, but it may not be perfect yet. Streaming is yet to work, something which is rather important with only 4mb of RAM and uncompressed sound.


Implemented but likely buggy. There seems to be a slight distortion in the background, though this may be due to the low bit rate which the DS uses. There are 16 audio channels on the DS, but the sound driver cuts this down to 8 to make working with stereo audio files a bit easier. Ramping the volume currently works with a bug that maxes out volume on the very last sample played (about one tenth of a second). Sweeping pan currently works without bug. Frequency sweeping fails for unknown reason.


Not implemented at the current time.