Frequently asked questions
The first step is to build one of the examples included with BlocksDS. If you
have installed the thirdparty-blocksds-docs package with wf-pacman, the
examples are located in /opt/wonderful/thirdparty/blocksds/core/examples/.
From there, for example, go to graphics_3d/volumetric_shadow and type make.
This will generate a NDS ROM that you can try with an emulator or a flashcart.
You can also try one of the open source projects made with BlocksDS that are listed here.
Unfortunately, there isn’t any tutorial on how to develop NDS applications or games from scratch. Your best bet is to take a look at the examples and to ask other developers if you get stuck. Check the “getting support” section of the documentation here.
You can also check the online mirror of the documentation of all libraries included in BlocksDS here.
If libnds is too low-level for you, you can check high-level libraries like
Nitro Engine or
NightFox’s Lib. They don’t have
official tutorials either, but they also come with lots of examples you can use
as reference, and it may be easier to get started with NDS development with
them.
The main resource is GBATEK; some additional details are documented in the GBATEK addendum:
The recommended emulators are melonDS, DeSmuMe and no$gba. There is more information about debugging NDS programs here.
For NitroFS to work, the NDS ROM needs to know where the ROM itself is located. On emulators, this can be done by using the official cartridge access protocol; however, flash cartridges tend to not implement those commands.
Flashcarts traditionally provide a DLDI driver, which allows access to its SD/CF
card or built-in flash storage, including the .nds file on said storage. It is
common for modern flashcart software to automatically patch homebrew with the
correct driver. However, this by itself doesn’t give the homebrew program
information on where the right .nds file is.
On DSi consoles, we have a similar issue: while the driver for the DSi’s SD card slot is included in homebrew software, we don’t always know where the file is located.
To solve this problem, the argv protocol was defined as a way to pass arguments
to the homebrew program. Unfortunately, many old loaders don’t support this
protocol; first, make sure you’re running on the newest firmware for your
flashcart.
A good way to avoid this problem altogether is to use the NDS Homebrew Menu, which is capable of correctly launching modern homebrew.
Download the .zip archive and copy BOOT.NDS to your SD card/storage. You can
rename this file to a name that you can remember. Once you have it on the cartridge,
launch the Homebrew Menu, then launch your homebrew program with it. NDS Homebrew
Menu will make sure that the loaded ROM receives the information it needs.
Wi-Fi support in BlocksDS is currently limited. It comes with DSWiFi, a
library that provides Wi-Fi support. However, it doesn’t support DS-to-DS
direct communications or the new DSi-only features.
It supports connecting to an access point with your DS, even using the access points configured in the firmware of the DS.
Adding support for this involves a lot of effort, which is the main reason why there is no support for it at the moment.
Related issues:
The DSi comes with an additional general-purpose CPU apart from the ARM9 and ARM7. This CPU has an unusual architecture (TeakLite II) which isn’t supported in any open source or freely available toolchain.
There is an experimental LLVM port, but it’s stuck on an old version of LLVM
and it requires extensive LLVM patches to support an environment where
CHAR_BIT != 8 (chars are 16-bit on the Teak).
For more information, check this link:
https://www.embecosm.com/2017/04/18/non-8-bit-char-support-in-clang-and-llvm/
Related issues:
Initial support exists for the DSi’s built-in cameras. However, the Aptina chip features many configuration features, for which no high-level functions are currently provided.
Related issues:
BlocksDS provides built-in libraries for a variety of external peripherals:
-
- Memory Expansion Pak
- Most other cartridges
-
- GBA WarioWare
-
- GBA WarioWare, Drill Dozer
- DS Rumble Pak
- Many other cartridges
-
- GBA Boktai 1, 2, 3
-
- GBA Yoshi, Koro Koro Puzzle
-
- DS Motion Card
- DS Motion Pak
- Motion Pack (bundled with Tony Hawk Motion)
- Other cartridges
Additional peripheral support is provided by third-party libraries:
-
dserial: Slot-1 serial card
-
nrio-usb: Slot-2 USB interface
ELF files are a standard format used by open source toolchains for applications.
They are very flexible. With them it’s possible to define parts of the code that
are only loaded in DSi mode, and ignored in DS mode, for example. They are also
supported by debuggers, so it is possible to use gdb with emulators like
melonDS and DeSmuMe to debug your games.
There is more information here.
The initialization code of both CPUs requires functions that are present in
libnds. Some of them are too complicated to be kept in the initialization code
in the crt0 file, like the MPU setup code.
The license of libnds is Zlib, which means that you don’t need to give any
kind of attribution to its authors, and it doesn’t impose any restriction on how
you distribute your binaries and source code.
There is more information here.
BlocksDS uses picolibc as a C library. libnds and picolibc are very
tightly coupled so that it’s possible to use standard POSIX functions like
fopen() or time() from NDS programs. While it is possible to replace the C
library or libnds, it requires a lot of effort to make them work together.
There is more information here.
The .specs files’ role is to provide configuration flags for GCC. Many
compiler arguments have been moved here in order to allow changing them with GCC
and BlocksDS updates without causing downstream breakage to Makefiles provided
by end-user projects.