melonDS just passed 4,884 GitHub stars and shipped its first major release in nearly a year — v1.1, out November 18, 2025, with DSi Speak-to-Text Processor (DSP) high-level emulation, cheat importing, and BSD support. It is, by a wide margin, the most-searched Nintendo DS emulator of 2026. But the single most important thing to know before you install it contradicts what a lot of setup guides — and even AI-generated search summaries — currently claim: melonDS has never supported BIOS-free play. There is no shortcut. This tutorial walks through all 13 steps to get melonDS running correctly, from picking the right download to dumping your own BIOS and firmware, configuring DSi mode, and fixing the errors that trip up almost every first-time setup.
What Is melonDS, and Why Does It Require Real BIOS Files?
melonDS is a free, open-source Nintendo DS and DSi emulator distributed under the GPL-3.0 license, maintained at github.com/melonDS-emu/melonDS. As of this writing the repository sits at 4,884 stars and 788 forks, with a commit pushed as recently as July 19, 2026 — a sign of an actively developed project nearly a decade after its first commit. It’s part of a broader wave of handheld emulation projects that have matured rapidly over the past two years, alongside Nintendo-platform siblings like Azahar (3DS) and Cemu (Wii U).
Unlike some other emulators covered on this site, melonDS does not offer a bios-free “high-level emulation” fallback. Its own FAQ states this in plain terms: melonDS requires BIOS and firmware dumps from a real DS for DS-mode play, and BIOS, firmware, and a NAND image for DSi-mode play. That’s worth repeating because it directly contradicts a claim currently circulating in AI-generated search summaries — that “since melonDS 0.9.4, DS mode can function without the user supplying BIOS or firmware files.” That claim is false. It does not appear anywhere in melonDS’s official documentation, and this guide will show you the legal, correct way to obtain the files melonDS actually needs.
That distinction matters because search volume for this emulator is unusually high for a niche retro-gaming tool: the bare term “melonds” pulls roughly 18,100 monthly searches in the US alone, according to DataForSEO, with “melonds android” adding another 2,400/month. A lot of that traffic is people hitting the BIOS-requirement wall for the first time and searching for a way around it. There isn’t one, and pretending otherwise just wastes an evening — the steps below get you to a working setup faster than chasing a shortcut that doesn’t exist.
A Brief History: From a Solo Project to v1.1
melonDS’s first commit under its original repository dates to May 2016, started by developer Arisotura (StapleButter) as a from-scratch DS emulator focused on accuracy rather than speed. The project has since moved to the melonDS-emu GitHub organization and shipped a steady release cadence: v1.0 RC in November 2024, the first stable v1.0 in July 2025, and v1.1 in November 2025 — the version this tutorial covers. Each release has closed the gap with DeSmuME, the older DS emulator most associated with tool-assisted speedruns, while adding features DeSmuME never prioritized, like full DSi hardware emulation.
What’s New in melonDS v1.1
v1.1, released November 18, 2025, is the release this entire tutorial is written against, and it’s worth knowing what changed versus the v1.0 line before you start. The headline addition is DSP high-level emulation for DSi titles — the DSi’s Nintendo-designed Teak audio coprocessor can now be emulated at a high level instead of requiring the project to fully low-level-emulate its instruction set, which improves compatibility for DSi games that lean on audio processing without changing any of the file requirements from Step 8. Alongside it, v1.1 added cheat-code importing, so you can bring in an existing cheat database rather than typing codes in by hand, and formal BSD compatibility, with the project now shipping dedicated FreeBSD, NetBSD, and OpenBSD builds rather than requiring a from-source build on those platforms.
None of this changes the core BIOS/firmware requirement covered throughout this guide — v1.1 is a compatibility and convenience release, not a rearchitecting of how melonDS boots a game.
melonDS vs DeSmuME: Which Nintendo DS Emulator Should You Use?
melonDS and DeSmuME are the two actively maintained Nintendo DS emulators in 2026, and they serve different audiences. DeSmuME (TASEmulators/desmume on GitHub, 3,599 stars, GPL-2.0, last pushed July 23, 2026) is not abandoned — a claim that circulates occasionally — but it is primarily built around tool-assisted-speedrun (TAS) workflows: frame-by-frame stepping, Lua scripting, and movie recording. melonDS, by contrast, targets accuracy and general play, and it’s the only one of the two with working DSi emulation.
The practical difference shows up the moment you try to load a DSi-exclusive game or a piece of DSiWare: DeSmuME simply has no code path for it, full stop, regardless of settings. If your library is entirely DS-mode cartridge games and you specifically want frame-stepping or movie/replay tooling for speedrun practice, DeSmuME’s feature set is still unmatched. For everyone else — including anyone who owns even a handful of DSi or DSiWare titles — melonDS is the more complete option in 2026.
| Category | melonDS | DeSmuME |
|---|---|---|
| License | GPL-3.0 | GPL-2.0 |
| GitHub stars | 4,884 | 3,599 |
| Latest stable release | v1.1 (Nov 18, 2025) | Rolling releases, actively maintained |
| DSi support | Yes — BIOS, firmware, NAND dump | No |
| Renderer options | Software, OpenGL | Software, OpenGL |
| Primary strength | Accuracy, general play, DSi | TAS tooling, Lua scripting, frame-stepping |
| Best for | Most players in 2026 | Speedrunners and researchers |
If you just want to play your DS and DSi library with the best available accuracy and hardware support, melonDS is the current default choice — it’s also the pick with by far the higher search interest, at roughly 18,100 monthly US searches for the bare term “melonds” against a fraction of that for DeSmuME-specific queries. If you need frame-perfect input tooling for TAS work, DeSmuME’s dedicated feature set still has no real equivalent in melonDS.
Prerequisites: What You Need Before You Start
melonDS is lightweight by modern emulation standards — it doesn’t demand a powerful GPU the way PS3 or PS4 emulation does — but a handful of things need to be in place before Step 1. Most importantly, none of the BIOS, firmware, or NAND files below can be legally downloaded from the internet: they must come from hardware you own. Step 5 covers this in detail. Budget somewhere between 20 and 40 minutes for a first-time setup that includes dumping your own files; if you already have BIOS/firmware dumps from a previous emulator setup, the software installation itself takes closer to five minutes.
| Requirement | Detail |
|---|---|
| melonDS version | v1.1 (November 18, 2025) — latest stable |
| Operating system | Windows 10/11 (x64 or ARM64), macOS (Universal), Linux, or BSD |
| Disk space | Under 50 MB for the emulator itself; budget separately for your ROM/BIOS library |
| DS BIOS files | bios9.bin, bios7.bin, firmware.bin — dumped from your own DS or DS Lite |
| DSi files (optional) | DSi BIOS9/BIOS7, DSi firmware, and a ~240 MB NAND dump from your own DSi |
| A DS/DSi you own | Required to legally dump BIOS, firmware, and (for DSi) NAND — see the Legal section below |
You do not need administrator privileges to run melonDS on Windows, macOS, or Linux — it ships as a portable archive rather than an installer, which is part of Step 1 below.
Step 1 — Download the Right melonDS Build
Get melonDS only from its official downloads page (melonds.kuribo64.net/downloads.php) or directly from GitHub Releases — never from a third-party “melonDS emulator” site promising a bundled ROM pack or a bios-free build. Several such sites rank well in search results specifically because official open-source projects rarely spend money on SEO; treat any site making unusual claims (bundled ROMs, guaranteed BIOS-free operation, a “premium” build) as a red flag, similar to unofficial SEO farms already documented for other emulators like Flycast.
As of v1.1, the official builds are: Windows x64 (18.58 MB) and ARM64 (11.97 MB), a macOS Universal build (23.25 MB), Linux AppImage and Ubuntu builds for both x64 and ARM64, and dedicated FreeBSD, NetBSD, and OpenBSD x64 builds. Pick the one matching your OS and CPU architecture. If you want to confirm you’re grabbing the current release rather than a stale mirror, query the GitHub API directly:
curl -s https://api.github.com/repos/melonDS-emu/melonDS/releases/latest | grep -E '"tag_name"|"published_at"|"name"'That should return tag_name “1.1” and a published_at date of 2025-11-18. If it doesn’t match what a download mirror is offering you, you’re not looking at the current release.
Step 2 — Verify and Extract Your Download
melonDS has no installer on Windows or macOS — it’s a self-contained portable archive. Extract it to a folder you fully control; avoid paths like Program Files on Windows, where restricted permissions can block the emulator from creating its own config file or writing save data. A folder under your user directory (for example, Documents\Emulation\melonDS) is the safer choice.
Before extracting, it’s good hygiene — especially on a security-focused site like this one — to verify the archive wasn’t corrupted or tampered with in transit. Generate a checksum and compare it against what you can see listed on the GitHub release page for that exact build:
# Windows (PowerShell)
Get-FileHash .\melonDS-1.1-win-x64.zip -Algorithm SHA256
# Linux/macOS
sha256sum melonDS-1.1-linux-x64.AppImageOnce verified, extract the archive and launch the executable directly — no separate install step is needed on these three platforms.
Step 3 — Install melonDS on Linux via Flathub or AUR
Linux users have two better-integrated options than the raw AppImage. The official Flathub listing is net.kuribo64.melonDS — note that the app ID’s domain (kuribo64.net) matches the official melonDS website, which is a useful legitimacy signal when you’re installing any Flatpak, since anyone can publish a Flathub app under an arbitrary reverse-domain name. Install and run it with:
flatpak install flathub net.kuribo64.melonDS
flatpak run net.kuribo64.melonDSArch-based distributions can instead use one of three AUR packages: melonds (stable release), melonds-git (rolling/nightly), or melonds-bin (precompiled). All three are community-maintained rather than published by the melonDS developers themselves, which is normal for AUR but worth knowing if you ever need to report a packaging-specific bug versus an emulator bug. Using an AUR helper:
# with an AUR helper (yay)
yay -S melonds
# or manually
git clone https://aur.archlinux.org/melonds.git
cd melonds && makepkg -siOne config-path detail catches people out on the Flatpak build specifically: its sandbox stores settings and can restrict file access to paths outside your home directory (like an external drive holding your BIOS/ROM library). We cover the fix — auditing and adjusting Flatpak filesystem permissions — in the Advanced Tips section below.
Step 4 — Install the Unofficial Android Port
There is no official melonDS build for Android or iOS. The project’s own FAQ is explicit about this: “We do not develop or support unofficial melonDS ports such as Android. Contact the developers of those ports for help.” That’s not a knock on the port’s quality — the Android build, developed independently by Rafael V. Caetano under the package name me.magnum.melonds, has been on Google Play since 2021 and has accumulated more than 2.6 million downloads according to AppBrain’s aggregated store data. It’s simply a separate codebase maintained by a different developer, which matters if you hit an Android-specific bug: the melonDS-emu GitHub issue tracker is the wrong place to report it, and the response you get will likely be a polite redirect rather than an actual fix.
Install it from the Google Play Store listing above, then configure BIOS/firmware paths through its in-app settings menu — the underlying file requirements (Step 5 below) are identical to the desktop build. There is currently no equivalent iOS build widely available through the App Store, given Apple’s historically stricter policies on emulator apps, so iPhone/iPad users are generally limited to the standalone desktop build running on a separate machine, or a browser-based option outside the scope of this guide.
Step 5 — Dump Your Own DS BIOS and Firmware
This is the step every other setup guide either skips or gets wrong. melonDS needs three files for standard DS-mode play: bios9.bin (the 4 KB ARM9 bootROM), bios7.bin (the 16 KB ARM7 bootROM), and firmware.bin (128, 256, or 512 KB depending on which DS model you dump it from). There is no built-in substitute for any of them — no “HLE mode,” no bundled replacement, regardless of what a search-engine AI summary might tell you.
The legally clean way to get these files is to dump them yourself from a DS or DS Lite console you own, using one of the BIOS/firmware dumping tools linked from melonDS’s own downloads page. Downloading pre-made BIOS or firmware files from a ROM site is a copyright violation — that’s true even though the act of reverse-engineering a BIOS to build the emulator itself is separately protected as fair use in the US (more on that distinction in the Legal section below). The two are not the same thing: writing emulator code that reads a BIOS is fair use; distributing or downloading a copy of Nintendo’s copyrighted BIOS/firmware is not.
One detail that trips people up: firmware dumped from a DSi or 3DS console (rather than an original DS/DS Lite) is only 128 KB and is explicitly non-bootable for “Firmware Boot” — it only works with “Direct Boot,” which is covered in Step 7. If your firmware.bin came from the wrong source device, you’ll hit a black screen the moment you try to boot into the DS system menu rather than straight into a game.
Step 6 — Point melonDS to Your BIOS and Firmware Files
With your files dumped, open melonDS and go to the Config menu, then Emu Settings, then the DS-mode tab. Set the three file path fields — BIOS9, BIOS7, and Firmware — to wherever you stored your dumps. There’s no required folder name or location; melonDS just needs valid, readable paths. A simple, organized layout looks like this:
melonDS/
├── melonDS.exe
├── melonDS.ini
└── bios/
├── bios9.bin
├── bios7.bin
├── firmware.bin
├── bios9i.bin (DSi, optional — Step 8)
├── bios7i.bin (DSi, optional — Step 8)
├── firmwarei.bin (DSi, optional — Step 8)
└── nand.bin (DSi, optional — Step 8)melonDS stores these path settings in melonDS.ini, which — depending on whether you’re running the portable Windows/macOS build, an installed Linux package, or the Flatpak — can live next to the executable, in ~/.config/melonDS/, or inside the Flatpak’s sandboxed config directory. If your paths seem to reset after an update, check that you’re editing the config file the running instance is actually reading from.
Step 7 — Choose Direct Boot or Firmware Boot
melonDS offers two ways to start a game. Direct Boot skips the actual DS system menu and firmware boot animation, loading straight into the game — it’s the more forgiving option and the one most first-time setups should use. Firmware Boot instead boots into the real DS system menu first, exactly as original hardware does, before you manually launch a game from there; it requires a fully bootable firmware.bin; a 128 KB DSi/3DS-sourced dump won’t work here (see Step 5).
Toggle this under Config → Emu Settings → General. Unless you specifically want the authentic system-menu experience or you’re testing firmware-dependent behavior, Direct Boot is the simpler, more reliable default.
Step 8 — Enable DSi Mode
DSi-exclusive games and DSiWare require switching melonDS’s console type from DS to DSi and supplying four additional files, on top of the three from Step 5.
| File | Size | Notes |
|---|---|---|
| bios9.bin / bios7.bin | 4 KB / 16 KB | Same DS-mode files from Step 5, still required |
| firmware.bin | 128–512 KB | DS-mode firmware, still required |
| DSi BIOS9 / BIOS7 | 64 KB each | DSi-specific bootROMs, separate from the DS ones |
| DSi firmware | 128 KB | Separate from DS-mode firmware.bin |
| NAND dump | ≈240 MB | Must come from your own DSi unit — cryptographically tied to it, a shared or downloaded NAND will not boot |
The NAND dump is the file most people get stuck on. It is not a generic file you can source once and share — it’s cryptographically paired to the specific DSi console it was dumped from, using keys unique to that unit. A NAND image dumped from someone else’s DSi (including one found online) will not boot on your setup. If you don’t own a DSi and can’t dump your own NAND, DSi-mode games simply aren’t accessible in melonDS — regular DS-mode games are unaffected by this and only need the three files from Step 5.
Step 9 — Configure the Renderer and Performance Settings
Under Config → Video Settings, melonDS offers two renderers: Software and OpenGL. Software is the most accurate option but the most CPU-intensive, since it emulates the DS’s rendering pipeline in software rather than offloading to your GPU. OpenGL shifts work to the GPU and runs faster on most modern hardware, at a small cost to rendering accuracy in a handful of edge cases. Note that melonDS does not currently offer a Vulkan renderer, despite that being claimed in some outdated or unofficial write-ups — if speed is your priority, OpenGL is the fastest option actually available, not Vulkan.
Two other settings matter for performance: the JIT recompiler (enabled by default on supported architectures, and generally worth leaving on — it dramatically speeds up CPU emulation versus the interpreter fallback) and internal resolution scaling, which lets you render above the DS’s native 256×192-per-screen resolution for a sharper image at some performance cost.
Step 10 — Set Up Dual-Screen Layout and Touch Input
The DS’s defining hardware feature — two screens, one touch-sensitive — needs a deliberate layout choice on a single-screen PC or phone. melonDS’s Screen settings (Config → Screen Layout) offer stacked (vertical, the closest to how the console looks), side-by-side (horizontal, better for widescreen monitors), and single-screen-with-swap (shows one screen at a time, toggled with a hotkey) — plus adjustable screen gap and sizing between the two.
For touch input, desktop users can click/drag with a mouse directly on the rendered touch screen. If you’re using a gamepad instead of mouse and keyboard, map touch input to the right analog stick under Input settings — this is the most common setup for games that need light stylus precision (drawing, menu navigation) without reaching for a mouse.
Step 11 — Map Controls for Keyboard and Gamepad
Open Config → Input to set bindings. Gamepads are auto-detected and generally work with sane defaults out of the box; keyboard users will want to explicitly assign the D-Pad, A/B/X/Y, L/R shoulder buttons, and Start/Select before your first session. melonDS also supports per-game control profiles, useful if one title benefits from a different touch-mapping scheme (a rhythm or puzzle game, for instance) than your general-purpose default.
Step 12 — Manage Save Data: In-Game Saves vs. Save States
melonDS supports two distinct save mechanisms, and mixing them up is a common source of “lost progress” complaints. In-game saves (.sav files) are written by the game itself, exactly as they would be to a real DS cartridge’s save chip — they’re tied to that specific ROM, portable across emulators and even to other melonDS installs, and the safest option for anything you care about long-term. Save states are an emulator-level feature: melonDS supports eight save-state slots per game, and per its own documentation, savestates are placed alongside the ROM file itself rather than in a separate central folder.
The practical rule: use in-game saves for anything you’d be upset to lose, and treat save states as a convenience layer for mid-session checkpoints, not a replacement for actually saving in-game before you close melonDS. It’s also worth backing up your .sav files separately from time to time — since they live alongside your ROM files rather than in a database managed by melonDS itself, a ROM library reorganization or a botched folder move can take your save progress down with it if you’re not keeping a copy elsewhere.
Step 13 — Set Up Local Wireless Play with melonAP
melonDS can emulate the DS’s local wireless features through melonAP, a virtual access point that lets two melonDS instances (or a melonDS instance and real DS hardware, in some configurations) discover each other. Set expectations accordingly, though: melonDS’s own FAQ describes this feature as still work-in-progress and “not guaranteed to work,” and separately states that “local multiplayer is currently unstable due to the timing requirements.” If a Pokémon trade or a multiplayer minigame refuses to connect, that’s a known, currently-unresolved limitation — not necessarily something wrong with your setup.
Using melonDS Inside RetroArch: The libretro Core Alternative
If you already run RetroArch as your main frontend, a melonDS libretro core is available and documented at docs.libretro.com. It’s worth knowing upfront that the libretro core meaningfully lags the standalone build covered in this tutorial: it has more limited DSi support and less flexible BIOS path configuration than the standalone app, since RetroArch cores generally trail their upstream project’s main-line development. If DSi games or fine-grained BIOS control matter to you, install the standalone build from Steps 1–3 above rather than relying solely on the RetroArch core. If you mainly want melonDS folded into a unified multi-system library alongside dozens of other consoles, the RetroArch core is still a reasonable choice for DS-only titles.
This mirrors a pattern across most modern emulators covered on this site: a full-featured standalone app maintained by the original developers, and a separate, slower-moving libretro port maintained by the wider RetroArch community. The practical takeaway for anyone building a multi-system retro setup is to treat the RetroArch core as a convenience layer for casual DS play alongside dozens of other consoles in one interface, and to keep a standalone melonDS install around specifically for DSi games, BIOS troubleshooting, or anything covered in Steps 6 through 8 above — trying to debug a DSi NAND issue through RetroArch’s more generic core-options menu is considerably more frustrating than doing it in melonDS’s own purpose-built settings screens.
Common Pitfalls When Setting Up melonDS
Most melonDS setup failures trace back to one of a small number of repeat mistakes, nearly all of them related to the BIOS/firmware/NAND file requirements this guide has walked through step by step. The list below is ordered roughly by how often each one actually shows up in setup-support threads and comment sections, starting with the single most common error.
- Believing melonDS can run without BIOS files. This is the single most common mistake, actively reinforced by AI search summaries repeating a false “BIOS-free since 0.9.4” claim. melonDS’s own FAQ says otherwise — budget time for Step 5 before you do anything else.
- Using DSi/3DS-sourced firmware for Firmware Boot. A 128 KB firmware.bin dumped from a DSi or 3DS is only valid for Direct Boot (Step 7) — it will not work for a full Firmware Boot into the DS system menu.
- Assuming any NAND dump will work for DSi mode. NAND images are cryptographically tied to the specific DSi unit they came from (Step 8). A downloaded or borrowed NAND simply won’t boot on your setup.
- Expecting Vulkan rendering. melonDS offers Software and OpenGL renderers only — there’s no Vulkan backend to switch to, regardless of what some third-party guides imply (Step 9).
- Treating the unofficial Android port as officially supported. melonDS’s own developers explicitly disclaim support for it (Step 4) — bug reports belong with the Android port’s own maintainer, not the main GitHub repo.
- Relying on melonAP for stable online multiplayer. Local wireless emulation is documented as unstable and work-in-progress (Step 13) — don’t build an online-only session around it.
- Losing BIOS/ROM access after a Flatpak install. The Flatpak sandbox can silently restrict file access to locations outside your home folder — covered in Advanced Tips below.
Troubleshooting: 10 melonDS Problems and Fixes
The table below covers the problems most likely to come up after you’ve finished the 13 setup steps above and started actually playing — as distinct from the pitfalls list, which focuses on setup-time mistakes. Each row links back to the step in this guide with the fuller explanation, so you’re not stuck guessing at a one-line fix.
| Symptom | Likely Cause | Fix |
|---|---|---|
| “BIOS/Firmware not found” on launch | File paths not set | Set all three paths under Config → Emu Settings → DS-mode (Step 6) |
| Black screen after Firmware Boot | 128 KB DSi/3DS-sourced firmware.bin in use | Switch to Direct Boot, or dump firmware from an original DS/DS Lite (Step 7) |
| DSi game won’t boot past a black/error screen | Missing or non-matching NAND dump | Dump NAND from your own DSi — a shared dump will never boot (Step 8) |
| Game freezes at the title screen | Corrupt or incomplete ROM dump | Re-dump the cartridge and check the file size against known-good dumps |
| No audio or crackling sound | Audio sync/interpolation misconfigured | Toggle audio sync under Config → Audio and adjust interpolation |
| Severe slowdown on older hardware | Software renderer under-resourced | Switch to OpenGL under Config → Video, lower internal resolution (Step 9) |
| Touch input registers in the wrong place | Screen layout doesn’t match touch mapping | Re-check layout under Config → Screen Layout against your input mapping (Step 10) |
| Local wireless won’t connect between two instances | melonAP is officially WIP | Retry, or treat as currently unreliable (Step 13) |
| Save appears to vanish after quitting | Game closed before writing the .sav, or wrong save type detected | Save in-game before closing melonDS; verify save-type detection (Step 12) |
| Flatpak build can’t see BIOS files on another drive | Flatpak sandbox restricts filesystem access by default | Grant access via Flatseal or flatpak override –filesystem (Advanced Tips) |
Advanced Tips for Power Users
v1.1’s new DSP high-level emulation is worth turning on if you’re running DSi titles that lean on the console’s Teak DSP audio coprocessor — it improves compatibility for DSi-specific audio processing without requiring anything beyond the standard DSi file set from Step 8. The same release also added cheat import support, letting you bring in existing cheat databases instead of entering codes by hand.
If you installed the Flatpak build in Step 3 and Step 6’s BIOS paths aren’t sticking, audit its sandbox permissions directly rather than guessing:
# See what the Flatpak sandbox currently allows
flatpak info --show-permissions net.kuribo64.melonDS
# Grant read-only access to a BIOS/ROM folder outside your home directory
flatpak override --user --filesystem=/path/to/your/bios:ro net.kuribo64.melonDSThis is the same class of fix documented for other Flatpak-distributed emulators and frontends on this site — treating each app’s sandbox as an actual security boundary worth inspecting, not just an installation detail to work around.
On Apple Silicon Macs, Windows-on-ARM devices, and modern Android phones, make sure the JIT recompiler (Step 9) is active — it’s the difference between near-native DS/DSi performance and a noticeably sluggish interpreter fallback, and it’s enabled by default on supported architectures but worth double-checking after any update.
If you’re setting up more than one machine, don’t copy your entire melonDS folder wholesale between them without checking melonDS.ini first — a config file carried over from a very different display setup (a 4K monitor’s window-size settings, for instance) can leave the emulator opening off-screen or oddly scaled on the new machine. It’s a quick fix (delete the offending window-geometry lines and let melonDS regenerate them), but it’s a confusing one to hit cold, since the emulator otherwise looks like it isn’t launching at all.
Is Emulating Nintendo DS Games Legal?
In the US, the core legal question around console emulators was settled over two decades ago in Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). The Ninth Circuit found that reverse-engineering a copyrighted PlayStation BIOS in order to build an interoperable emulator was protected fair use, not infringement — the same legal logic that lets projects like melonDS exist and study how the original DS BIOS behaves in order to emulate it. That’s the emulator side of the equation, and it’s well established.
The file-sourcing side is a separate question, and it’s where most legal risk actually sits for an individual user. Writing code that emulates a BIOS is fair use; downloading a copy of Nintendo’s copyrighted BIOS, firmware, or NAND image from a website is not — it’s ordinary copyright infringement, regardless of whether you also happen to own the original hardware. The same logic applies to game ROMs. Dumping BIOS, firmware, and ROMs from a DS or DSi console you personally own — using the tools referenced in Step 5 — is the only approach this guide recommends, and it’s consistent with how courts have actually drawn the line: the emulator itself is legal to write and run; downloading someone else’s copy of Nintendo’s copyrighted files is not, no matter how you access it.
Worth noting for context: melonDS itself has never been the target of legal action from Nintendo, unlike some Switch-emulation projects that reached settlements over tools found to facilitate piracy rather than over the act of emulation itself. The Connectix case remains the reference point US courts and commentators return to precisely because it separates two questions that are easy to conflate: whether writing emulator software is legal (yes, per the Ninth Circuit), and whether acquiring the copyrighted files that software needs is legal (only if you dump them yourself).
Frequently Asked Questions
Does melonDS require BIOS files to work? Yes, always, for both DS and DSi modes — there is no built-in bios-free fallback, despite claims to the contrary circulating in some search summaries.
Is melonDS free? Yes. It’s open source under the GPL-3.0 license, with no cost and no premium tier.
Can I run melonDS on Android? Only through an unofficial third-party port (me.magnum.melonds on Google Play) — the official melonDS project explicitly does not develop or support an Android build.
melonDS or DeSmuME — which should I install? melonDS for general play and any DSi game, since DeSmuME has no DSi support. DeSmuME remains the better choice specifically for tool-assisted speedrunning and frame-by-frame debugging.
Do I need a NAND dump to play any DS game? No — a NAND dump is only required for DSi-exclusive games and DSiWare. Standard DS-mode games need only the three files covered in Step 5.
Is it legal to download BIOS or firmware files instead of dumping my own? No. Emulator development itself is protected as fair use under US law, but downloading a copy of Nintendo’s copyrighted BIOS, firmware, or NAND file is ordinary copyright infringement. Dump these files from hardware you personally own.
Does melonDS support Vulkan? No. As of v1.1, melonDS offers Software and OpenGL renderers only.
Can I play DS games online with melonDS? Only through melonAP’s local wireless emulation, which melonDS’s own documentation describes as unstable and work-in-progress — don’t rely on it for anything time-sensitive.
