TWiLight Menu++: a DSi Menu replacement for DS, DSi, 3DS and 2DS

What TWiLight Menu++ replaces, and for whom

The README describes TWiLight Menu++ as an open-source DSi Menu upgrade and replacement for the Nintendo DSi, the Nintendo 3DS, and Nintendo DS flashcards. It launches games for the Nintendo DS, Nintendo DSi and GameBoy Advance, and it can load DSTWO plugins when a DSTWO card is present. That is the whole scope in one sentence, and it is worth reading literally: this is a menu and a launcher, not an emulator. The DS, DSi and GBA titles it starts are the ones the hardware can already run or that nds-bootstrap provides a path to.

The audience is narrow and specific. You need homebrew-capable hardware, which in practice means a DSi or 3DS with custom firmware or an exploited entry point, or a DS with a flashcard. On a stock console with no exploit, none of the entry points in this repository can be loaded. The project also assumes you are comfortable moving files onto an SD card and, in the flashcard case, overwriting kernel files such as _DS_MENU.dat and akmenu4.nds. If that sentence makes you uneasy, this is not the right starting point.

The payoff is a consistent interface across several generations of hardware, with multiple themes rather than one fixed look. The README lists Nintendo DSi, Nintendo 3DS, SEGA Saturn, Homebrew Launcher, R4 Original, Gameboy Color, Wood UI and a DS Lite quick menu as selectable interfaces. That range is the actual product: one launcher, several shells, one set of ROM folders.

How the sub-projects fit together at build time

The repository is not one program. It is a set of sub-projects that each compile to a .nds file, and most of those are copied into /_nds/TWiLightMenu/ with a .srldr extension inside the packaged archive. The README spells out the mapping, and it is the clearest documentation in the whole file.

booter is the main entry point, the first file loaded by the console when using an SD card or CFW. It produces /BOOT.nds and /title/00030004/53524c41/content/00000000.app, which the README notes are the same file. booter_fc is the flashcard counterpart and produces _DS_MENU.dat, dsedgei.dat, akmenu4.nds, _DSMENU.nds, SCFW.SC and others. Those two folders are the fork in the road: whichever one you build or install determines whether the console sees an SD-card boot or a flashcard kernel.

The menu shells come from romsel_dsimenutheme (dsimenu.srldr, covering the DSi, 3DS, SEGA Saturn and Homebrew Launcher UIs), romsel_aktheme (akmenu.srldr, the Wood UI), romsel_r4theme (r4menu.srldr, the R4 Original and Gameboy Color UIs) and quickmenu (mainmenu.srldr, the DS Lite menu). settings.srldr, title.srldr, slot1launch.srldr and manual.srldr round it out. imageview.srldr is the image viewer and the README marks it as part of the Multimedia add-on, which is the one place where a component is explicitly tied to an optional download.

The top-level Makefile ties this together. Its package target descends into booter, booter_fc, 3dssplash, gbapatcher, quickmenu, manual, imageview, resources, romsel_aktheme, romsel_dsimenutheme, romsel_r4theme, settings, slot1launch and title, running make dist in each, then deleting .gitkeep files from the 7zfile tree. Note that rungame is present in the Makefile but its dist line is commented out, so it is not part of a package build. The all target lists a similar set but omits imageview, which means make all and make package do not build the same things. That is a small inconsistency in the build system, and it is the kind of thing you notice only when a component is missing from your output.

Installing TWiLight Menu++ and running a first game

The README does not contain end-user installation steps. It links to the project wiki at wiki.ds-homebrew.com/twilightmenu/ for add-ons, and the manual pages live in a separate repository, DS-Homebrew/twilight-manual, downloaded from a release at build time. So the authoritative install path is the wiki, not this repository. What the repository does give you is the build path, which is what the instructions below cover.

Building requires devkitPro's devkitARM, libnds, grit and mmutil. The README says these come from devkitPro pacman:

sudo dkp-pacman -S nds-dev

The README notes the command varies by OS, that sudo may not be needed, and that on some systems the binary is just pacman. If dkp-pacman is not on your PATH, that is a devkitPro installation problem, not a TWiLight Menu++ one.

The repository has submodules, so a plain clone is not enough:

git clone --recursive https://github.com/DS-Homebrew/TWiLightMenu.git

If you already cloned without them, the README gives the recovery command:

git submodule update --init --recursive

With the toolchain in place, the full build is one command from the repository root:

make package

The README states the output lands in the 7zfile folder, following the same directory structure as the official TWiLightMenu.7z builds. That folder is where you look for the .srldr files and the booter artifacts. If you want only one component, cd into its folder and run make dist instead, for example into romsel_dsimenutheme for the DSi-style menu.

There is also a Docker path for people who do not want to pin devkitARM by hand. The included Dockerfile is short and pins the toolchain image:

FROM devkitpro/devkitarm:20241104
RUN \
  apt-get update && \
  apt-get install -y python && \
  rm -rf /var/lib/apt/lists/*
WORKDIR /data

The README says to drive it through the provided PowerShell scripts, and that the script forwards make arguments, so a clean and a full build look like this:

.\compile_docker.ps1 clean
.\compile_docker.ps1 package

One warning in the README is easy to miss and will cost you time: Docker compilation is not compatible with native compilation on Windows, so run .\compile_docker.ps1 clean before switching to Docker. On Windows, Docker may also prompt for drive sharing, which must be enabled.

Where the documentation runs out

The README is a developer document wearing a project badge. It tells you how to compile. It does not tell a console owner how to install, how to pick a theme, how to configure cheats, how to adjust widescreen settings, or how the camera viewer is enabled beyond the note that imageview belongs to the Multimedia add-on. Those are all things people search for, and the answers are not in this file. The README's own escape hatch is the wiki link and the separate twilight-manual repository, which is honest but means the repository alone cannot answer most user questions.

The build system has real sharp edges. The all and package targets do not cover the same sub-projects, as noted above. The Docker image pins devkitarm:20241104, so a build that works today can break when that tag is superseded and you rebuild from a modified Dockerfile. There is a commented-out ENV TWLNOPATCHSRLHEADER=1 line in the Dockerfile, which suggests a build-time switch exists but is not documented in the README.

Flashcard users carry the most risk. The booter_fc output overwrites kernel-named files including _DS_MENU.dat and akmenu4.nds. If the flashcard's original kernel is not backed up first, and the build or the card is wrong, you have replaced the card's own menu. The README does not document rollback. That is not a criticism of the code; it is a statement about what the documentation covers, and it is the single most important gap for anyone using a flashcard rather than CFW.

TWiLight Menu++ versus nds-bootstrap and YS Menu

The clearest comparison is inside the project's own credits. nds-bootstrap, credited to ahezard, shutterbug2000 and Rocket Robz, is described in the README as the component used for launching Nintendo DS(i) ROMs off the SD card. TWiLight Menu++ is the menu and the boot chain around it. They are not alternatives; nds-bootstrap is a dependency of the launcher path. If your question is why a particular ROM does not start, the answer lives in nds-bootstrap's compatibility, not in the menu you are looking at.

YS Menu is the comparison users actually search for, and the difference is structural. YS Menu is a flashcard kernel replacement built around a single menu and a single card family's expectations. TWiLight Menu++ ships several menu front ends (dsimenu, akmenu, r4menu, mainmenu) that share the same launcher, and it targets both flashcards and CFW consoles through two separate entry points. That breadth is the trade-off: more hardware covered, more entry-point combinations to get right, and a build tree with fourteen or so sub-projects instead of one.

If you only need a DS flashcard to boot ROMs with a familiar kernel, a card-specific kernel is less to maintain. If you want the DSi or 3DS to boot from SD card with a DSi-style interface, and you want the same launcher to also work on a flashcard, TWiLight Menu++ is the one that spans both.

Licence and the cost of staying current

TWiLight Menu++ is GPL-3.0. If you redistribute a modified build, the licence's source-availability terms apply to your changes; if you only build for your own console, that is a different situation. Nothing here is legal advice, and the LICENSE file at the repository root is the text that governs.

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and versioned by date: v27.24.1 on 2026-05-24, v27.24.0 on 2026-05-23, v27.23.0 on 2026-03-17. The v27.24.1 tag is labelled a hotfix, which is a useful signal: point releases do get corrected shortly after landing, so tracking the newest tag rather than the newest minor version is the safer habit.

Upgrade cost depends on how you consume the project. If you use official builds, you replace files on the SD card, and the main risk is the flashcard kernel files listed above. If you build from source, every upgrade means re-cloning submodules, re-running make package, and accepting whatever devkitARM the Dockerfile pins. The manual is pulled from a separate repository at build time, so a build can fail for reasons that have nothing to do with this codebase. Budget for that: a source build is not a one-command operation on a machine that has never had devkitPro installed.

Editorial conclusion

Adopt TWiLight Menu++ if you want a DSi-style menu on a DSi, 3DS or 2DS and you are willing to work from the wiki rather than the README. Skip it if you need the repository itself to explain installation, add-on setup or how a given console handles autobooting; the README only points at the wiki for add-ons and does not document those steps. Before flashing anything, verify which entry point your hardware uses (booter for SD card or CFW, booter_fc for flashcards), and confirm the devkitARM version matches the Dockerfile tag 20241104 if you intend to build from source.

Frequently asked questions

Official sources

1. DS-Homebrew/TWiLightMenu on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases