DSVita runs Nintendo DS games on a PS Vita, with rendering caveats you have to plan around

The ARM7 emulation setting is the first dial to turn

DSVita is described as a fast NDS emulator for ARM32 and the PlayStation Vita, written in Rust. The status section says most games run, with a list of caveats that reads like a manual for a device with a very specific hardware profile.

The setting that decides whether a game works at all is Arm7 Emulation, with the values Hle, SoundHle and AccurateLle. The documentation says Hle does not work with some games, and that if a game does not boot, gets stuck or crashes, you should switch to SoundHle or AccurateLle, where each step is more compatible but slower. That is a straight speed versus compatibility trade, and it is the same dial the bug reporting guidance points at: before filing an issue, make sure the problem still occurs with the setting on AccurateLle.

The other caveat worth internalising is about the frame counter. Auto frameskip is always used, which means the FPS counter will often show 20 to 30 fps even when the game logic runs at full speed. So the number in the corner is not a performance readout, and treating it as one will send you looking for a problem that is not there.

Rendering splits into two tiers. 2D rendering is mostly complete. 3D rendering is mostly implemented, with Z fighting possible, games that use 3D on both screens having bad framerates and stutters, and some effects such as fog unimplemented. There is no scanline rendering, so games that update VRAM mid-frame will not render correctly, though the documentation notes that few games do this and that those that do mostly use it for scrolling text.

Vita installation depends on two homebrew plugins that must be in the right section

Installing DSVita on the Vita is not a single step, and two of the steps are failure-prone enough that the documentation calls out what goes wrong.

The first is the vpk itself, taken from the releases page. The second is libshacccg.suprx, a shader compiler, installed by following the linked troubleshooting guide or by installing and opening VitaDB. The third is kubridge.skprx version 0.3.1 or newer from the kubridge releases. The warning matters: make sure this plugin is in the *KERNEL section, otherwise the app might crash upon opening, and if the wrong version is installed the app will either crash or will not be able to launch any games at all.

The fourth step is a hardware recommendation rather than a command: it is strongly recommended to overclock the Vita to 500MHz. This is a Vita homebrew modification, and it is the kind of instruction that tells you a lot about who this project is for. The fifth is data layout: create the folder ux0:data/dsvita and put your roms there, where they must have the .nds file extension. The final pointer is to the compatibility list in the project wiki for popular games.

There is also an experimental feature for streaming the top screen over udcd-uvc, which needs a specific udcd-uvc release installed under the *KERNEL section of your config.txt, plus the second linked homebrew tool, plus the stream top screen setting enabled. If you only get a black screen, the documentation says to reboot the Vita, and that you might need multiple reboots.

The Rust build needs two LLVM versions, a sysroot and a pinned nightly

Building from source is where the real constraints of this project live, and they are substantial. The build requires both llvm-18 and llvm-21 to be installed, for two different reasons: llvm-18 is required for bindgen because newer versions struggle to parse class sizes correctly, and llvm-21 is used for building the C and C++ libraries.

The clone needs submodules, because the repository vendors several C and C++ projects, among them vitaGL, vixl, soundtouch and math-neon:

$ git clone --recurse-submodules https://github.com/Grarak/DSVita.git

On Linux the route goes through an armhf sysroot, and the final build command needs both the sysroot path and the llvm-18 library path in the environment:

$ LIBCLANG_PATH=<path to llvm-18 library> DSVITA_SYSROOT=<path to armhf sysroot> cargo build --target thumbv7neon-unknown-linux-gnueabihf --release

For Vita builds the documentation asks for Vitasdk and cargo vita, and the build command is:

$ LIBCLANG_PATH=<path to llvm-18 library> cargo vita build vpk -- --release

The paths in these commands are meant to come from a local environment file. The repository ships .env.example, and the documented way to set it up is:

$ cp .env.example .env   # then edit .env with your paths

The tools/ scripts source .env automatically, and for cargo builds the environment has to be loaded into the shell:

$ set -a; . ./.env; set +a
$ cargo build --target thumbv7neon-unknown-linux-gnueabihf --release

The .env file is gitignored because it is machine-specific, and the example file shows the shape of it: DSVITA_SYSROOT, LIBCLANG_PATH, DSVITA_ROMS_DIR, DSVITA_TEST_ROM, DSVITA_PI_HOST for a remote ARM test box, and ANDROID_NDK_HOME.

The optimized release build needs a patched rust compiler

The most interesting build requirement is the one that pushes ordinary contributors out. To obtain the most optimized build you need a patched rust compiler, linked from the author's own rust fork, because of LTO incompatibility. The reason given is specific: the upstream rust compiler does not set the target cpu and target features in the callsite attributes, which prevents the clang linker from inlining cross language functions.

The command for it is long and the flags are all specific:

$ RUSTC=<path to compiled rustc> LIBCLANG_PATH=<path to llvm-18 library> RUSTFLAGS="-Zlocation-detail=none -Zfmt-debug=none -Zub-checks=no -Zsaturating-float-casts=no -Ztrap-unreachable=no -Zmir-opt-level=4 -Clinker-plugin-lto -Clto=fat -Zunstable-options -Cpanic=immediate-abort" cargo vita build vpk -- --release

On top of that, the toolchain is pinned to an older rust nightly through rust-toolchain.toml, described as the last one built against llvm-21, because newer llvm versions cause performance regressions. So the supported build environment is deliberately narrow: an older nightly, a forked compiler for the release path, and a specific pair of LLVM installs. That is a maintenance fact with teeth, and it is the reason the plain cargo build is the more realistic entry point for a new contributor.

There is also an experimental Android port with no releases yet. It needs an Android NDK for the sysroot only, since the compiling is done by host clang-21:

$ cd android && ./gradlew assembleDebug   # builds libdsvita.so via cargo and packs the apk

The dependency tree tells you what the emulator is made of

The manifest describes a Cargo workspace with members named macros, vitabuild, vitaGL, vixl and rcheevos, and the package itself is dsvita at version 0.9.4 on edition 2021. The Vita build metadata gives the title id DSVITA000, sets build_std to std,core,panic_abort,alloc and points assets at ./static.

The dependency list reads like an inventory of an emulator's moving parts. vixl is the VIXL JIT compiler, inlined as a path dependency, which lines up with the jit topic tag on the repository. vitaGL is also a path member, and the credits say 2D and 3D hardware acceleration would not be possible without it, which is the Vita-specific rendering layer. rcheevos is another workspace member, the retro achievement system. bilge and enum_dispatch come from the same GitHub author, and bilge is a bit-level field manipulation library, which is what you would reach for when packing and unpacking hardware register bitfields for two emulated ARM processors.

Other entries are more ordinary: nalgebra for the maths that a 3D renderer needs, glyph_brush for text, a jpeg encoder and decoder plus the png crate, and miniz_oxide for savestate compression. The manifest even carries a comment noting that miniz_oxide is already in the tree transitively through png and flate2 but is used directly. There are patches applied to crates.io for simd-adler32 and openssl-sys, both pointing at the author's own forks, which is a signal that the project tracks fixes ahead of upstream.

Where DSVita is the wrong tool

The clearest wrong-tool case is a game that depends on accurate 3D rendering. The documentation states that 3D rendering is mostly implemented rather than complete, that Z fighting can occur, that some effects like fog are unimplemented, and that games using 3D on both screens will have bad framerates and stutters. A title built around those effects is not going to be a good experience.

The second case is any game that rewrites VRAM mid-frame, which will not render correctly because there is no scanline rendering support. The documentation is candid that few games do this and that those that do mostly use it for scrolling text, but a scrolling-text-heavy game is still a game that shows artefacts.

The third case is operational. If you want to build a Vita homebrew application from source, the toolchain requirements are the barrier: two LLVM versions, an older pinned nightly, and a forked rust compiler for the optimized path. A developer without a Vita and without a Linux armhf cross-compilation setup will spend most of their time on the build rather than on the emulator.

For the alternative question, the reference point is the original DS hardware and the emulators that target desktop platforms. The difference in approach is the JIT and the Vita-specific acceleration. DSVita uses vixl for JIT execution and takes the ARM7 HLE implementation and JIT optimisations from melonDS, and it borrows the ARM7 HLE approach from DesmumePSPExperimental and pokediamond, with NooDS as the general reference and a lot of code taken from there. So DSVita is not a from-scratch architecture; it is a port of an established emulator design onto Vita hardware with VitaGL doing the drawing, and the credits list makes that lineage explicit.

Release cadence, licensing and the state of the tree

The project ships versioned releases and the recent history is steady: 0.9.4 on 2026-07-21, 0.9.3 on 2026-06-28 and 0.9.2 on 2026-04-18, with the last push to the repository on 2026-07-21. The default branch is main.

The licence is GPL-3.0, and the repository ships a single LICENSE file at the top level. For a project that vendors and links against other emulator code, the GPL choice is a deliberate constraint on how derived versions are distributed, and anyone planning to reuse code from the tree should read the licence rather than assume the permissive alternatives common in the Rust ecosystem. That is a documentation point, not a legal opinion.

The repository itself is a good deal larger than a typical application. Alongside src and build.rs there are directories for imgui, with an imgui_impl_sdl_gl3.cpp and an imgui_wrapper.h, for vitaGL, vixl, kubridge, soundtouch, math-neon, rcheevos and builtins, plus a vita-gprof directory and a ldscript.ld linker script. The imgui presence points to an immediate-mode debug interface, and vita-gprof points to profiling support. There is also a DEVELOPMENT.md holding what the README calls development background, specifically JIT and interpreter invariants and a debugging playbook, and a tools/ directory with helper scripts for launching under qemu, remote test box runs, screenshots and instruction traces, documented in tools/README.md.

Together those two files are the most useful things in the repository for anyone extending the emulator, and they are the first place to look after the compatibility caveats.

Editorial conclusion

DSVita suits a Vita owner with homebrew set up who wants to run Nintendo DS roms on the handheld and who accepts a compatibility list rather than a guarantee. It does not suit someone looking for accurate 3D, for games that rewrite VRAM mid-frame, or for a build pipeline you expect to reproduce on a stock toolchain, since the optimized release path needs a patched rust compiler. Before adopting, put a test rom in ux0:data/dsvita, run the game with the Arm7 Emulation setting on AccurateLle, and check the compatibility list to see whether your target title is known to work.

Frequently asked questions

Official sources

1. Grarak/DSVita on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases