melonDS einrichten: 4.876 Stars, 12 Schritte [2026]

Wer alte Nintendo-DS- oder DSi-Spiele wieder spielen will, kommt an einem Namen kaum vorbei: melonDS. Der quelloffene Emulator hat sich seit seinem Start als das inzwischen genaueste und schnellste Projekt seiner Art etabliert und wird auf GitHub aktiv weiterentwickelt. Diese Anleitung zeigt in 12 Schritten, wie die Einrichtung unter Windows, Linux, macOS und Android gelingt, welche BIOS-Dateien wirklich nötig sind und warum ein verbreiteter Mythos über eine angeblich optionale BIOS-Nutzung schlicht falsch ist.

Anders als bei neueren Konsolen ist die Technik hinter dem Nintendo DS gut dokumentiert, trotzdem stolpern viele Einsteiger an denselben Stellen: falsch abgelegte BIOS-Dateien, verwechselte Firmware-Formate oder ein DSi-Modus, der partout nicht starten will. Dieser Leitfaden arbeitet sich von den Voraussetzungen über die Installation bis zu Fehlerbehebung und Profi-Tipps durch – inklusive eines fertigen Setup-Skripts zum Nachbauen und einer nüchternen Einordnung, was rechtlich zulässig ist und was nicht.

Was ist melonDS? Der offene Nintendo-DS-Emulator im Überblick

Dahinter steht ein Open-Source-Emulator für Nintendo DS und DSi, der unter der GPL-3.0-Lizenz im Repository melonDS-emu/melonDS auf GitHub entwickelt wird. Hauptautor ist Arisotura (bekannt unter dem Pseudonym StapleButter), unterstützt von einer aktiven Community aus Mitwirkenden. Ein aktueller Blick auf die GitHub-API zeigt den Entwicklungsstand: 4.876 Sterne, 779 Forks und 1.022 offene Issues, mit einem letzten Commit vom 19. Juli 2026 – das Projekt ist also keineswegs eingeschlafen.

Die aktuelle stabile Version ist 1.1, veröffentlicht am 18. November 2025, als Nachfolger von Version 1.0 (Juli 2025). Im Gegensatz zu vielen Nachfolgeprojekten für neuere Konsolen zielt das Projekt speziell auf Genauigkeit: Der Emulator simuliert die Zwei-Bildschirm-Architektur der Nintendo DS inklusive Touchscreen-Eingabe, Mikrofon-Unterstützung und den Eigenheiten des DSi-Betriebssystems. Offizielle Anlaufstelle ist melonds.kuribo64.net, wo auch das offizielle FAQ gepflegt wird.

Wichtig für die Einordnung: Es handelt sich um reine Emulations-Software. Sie enthält keine Nintendo-Spiele, keine Nintendo-Firmware und keine Nintendo-BIOS-Dateien. Nach aktuellem Kenntnisstand ist auch keine rechtliche Auseinandersetzung zwischen Nintendo und dem Projekt bekannt – anders als etwa beim Switch-Emulator Yuzu, der 2024 nach einer Klage und einem Vergleich in Höhe von 2,4 Millionen US-Dollar eingestellt wurde.

Technisch bildet der Emulator zwei getrennte Prozessoren der Original-Hardware nach: einen ARM9-Hauptprozessor mit 67 MHz sowie einen langsameren ARM7-Co-Prozessor mit rund 33 MHz, der unter anderem für Ton und Teile der Wireless-Kommunikation zuständig ist. Beide Kerne müssen exakt synchron und zyklusgenau emuliert werden, da viele Spiele zeitkritisch zwischen beiden Prozessoren kommunizieren – ein wesentlicher Grund, warum ältere Emulationsversuche häufig an Timing-Fehlern scheiterten, während der hier vorgestellte, auf Genauigkeit ausgelegte Ansatz genau an dieser Stelle ansetzt.

Warum BIOS-Dateien überhaupt nötig sind

Wer bereits andere Konsolen-Emulatoren kennt, hat möglicherweise schon von High-Level-Emulation (HLE) gehört: Dabei bildet der Emulator die Funktionen des originalen BIOS in eigenem, neu geschriebenem Code nach, sodass keine Dateien der echten Konsole benötigt werden. PPSSPP etwa emuliert die PSP-Systemsoftware auf genau diese Weise komplett ohne fremde Dateien.

Für die Nintendo DS hat sich das Projekt bewusst gegen diesen Weg entschieden und setzt stattdessen konsequent auf Low-Level-Emulation (LLE): Das echte BIOS und die echte Firmware werden byteweise ausgeführt, nicht nachgebildet. Der Vorteil ist höhere Kompatibilität und Genauigkeit, insbesondere bei Spielen, die sich auf Timing-Eigenheiten des originalen BIOS verlassen. Der Nachteil: Ohne die passenden Dateien aus einer echten Konsole bootet gar nichts. Diese bewusste Design-Entscheidung erklärt, warum ein “eingebautes Ersatz-BIOS” – anders als bei manchen anderen Emulatoren – hier schlicht nicht existiert und laut offiziellem FAQ auch nicht geplant ist.

Im Vergleich: DeSmuME und die RetroArch-Core-Version

Vor dem hier beschriebenen Projekt war DeSmuME (Repository TASEmulators/desmume) über Jahre der Standard für DS-Emulation. DeSmuME ist mit 3.595 GitHub-Sternen und einem Commit vom heutigen Tag weiterhin leicht aktiv gepflegt – die Behauptung, das Projekt sei “seit 2017 tot”, stimmt schlicht nicht, auch wenn die Entwicklungsgeschwindigkeit deutlich zurückliegt. DeSmuME bleibt vor allem für Tool-Assisted-Speedruns (TAS) und Debugging-Funktionen relevant, während der jüngere Emulator in aktuellen Vergleichen regelmäßig als genauer und durch einen JIT-Recompiler auch spürbar performanter beschrieben wird, mit sichtlich besserer DSi-Unterstützung.

Eine dritte Option ist der melonDS-Core für RetroArch, gepflegt im Repository JesseTG/melonds-ds (317 Sterne, GPL-3.0, letzter Commit Ende Juni 2026). Er integriert sich in RetroArch und dessen einheitliche Bedienoberfläche, hinkt der Hauptentwicklung aber bei DSi-Funktionen und WLAN-Features hinterher. Wer ausschließlich DS-Spiele emulieren will und ohnehin schon RetroArch nutzt, ist mit dem Core gut bedient; wer die volle DSi-Funktionalität will, sollte zur eigenständigen Version greifen.

Emulator	GitHub-Sterne	Lizenz	Letzter Commit	DSi-Unterstützung
melonDS (Standalone)	4.876	GPL-3.0	19.07.2026	Vollständig
melonDS-Core (RetroArch)	317	GPL-3.0	26.06.2026	Eingeschränkt
DeSmuME	3.595	GPL-2.0	23.07.2026	Nicht vorhanden
melonDS Android (Port)	336	GPL-3.0	23.07.2026	Teilweise

Kompatibilität und bekannte Einschränkungen

Eine seriöse, offiziell veröffentlichte Kompatibilitäts-Prozentzahl für die gesamte Nintendo-DS-Bibliothek gibt es nicht – anders als etwa bei RPCS3 oder Vita3K, die eigene, laufend aktualisierte Kompatibilitäts-Datenbanken pflegen. Seriöse Anleitungen sollten daher keine erfundene Zahl nennen, auch wenn sie noch so plausibel klingt. Was sich stattdessen belegen lässt: Der Fokus des Projekts auf Genauigkeit und Timing-Treue sorgt dafür, dass die meisten kommerziell erfolgreichen Titel zuverlässig laufen, sofern BIOS und Firmware korrekt eingerichtet sind.

Die größte praktische Einschränkung betrifft nicht einzelne Spiele, sondern die Online-Funktionen: Nintendos ursprüngliches WFC-Netzwerk (Wi-Fi Connection) für Online-Matches wurde bereits 2014 von Nintendo selbst abgeschaltet und lässt sich naturgemäß auch hier nicht wiederbeleben. Lokaler Mehrspieler-Betrieb über die melonAP-Funktion (mehr dazu in Schritt 12) funktioniert dagegen grundsätzlich, gilt laut Projekt-Dokumentation aber weiterhin als instabil. Wer vor allem Singleplayer-Titel oder lokale Tauschfunktionen (Pokémon, Mario Kart DS) im Blick hat, wird selten auf grundlegende Probleme stoßen.

Voraussetzungen: Was du vor der Installation brauchst

Bevor der Emulator installiert wird, sollten folgende Punkte geklärt sein. Die Hardware-Anforderungen sind für ein Nintendo-DS-System erwartungsgemäß niedrig, da selbst ältere Rechner und viele Handhelds die nötige Rechenleistung locker aufbringen.

Ein 64-Bit-Betriebssystem (Windows, Linux oder macOS) oder ein Android-Gerät mit Version 8.0 oder neuer.
Die aktuelle Version 1.1 des Emulators, heruntergeladen ausschließlich von GitHub, Flathub oder dem Google Play Store.
Eine echte Nintendo-DS- oder DS-Lite-Konsole zum einmaligen Dumpen der BIOS- und Firmware-Dateien.
Für den DSi-Modus zusätzlich eine echte DSi-Konsole samt Werkzeugen zum Erstellen eines eigenen NAND-Dumps.
Mindestens 2 GB RAM sowie eine OpenGL-3.2-fähige Grafikeinheit für den beschleunigten Renderer.

Komponente	Mindestanforderung	Empfehlung
Betriebssystem	Windows 10 (64-Bit), Ubuntu 22.04, macOS 12	Windows 11, aktuelles Fedora/Arch, macOS 14+
Version	1.1 (18.11.2025)	Aktuellster GitHub-Release
Arbeitsspeicher	2 GB RAM	4 GB RAM oder mehr
Grafik	OpenGL-3.2-fähige GPU	Dedizierte GPU für Upscaling
Speicherplatz	50 MB für den Emulator	Zusätzlich Platz für ROMs und Save-States
Eigene Konsole	Eine echte DS/DSi-Konsole zum Dumpen	DSi zusätzlich für den DSi-Modus

Der wichtigste Punkt steht in der letzten Zeile: Der Emulator benötigt zwingend BIOS- und Firmware-Dateien, die aus einer echten Konsole stammen. Für den reinen DS-Modus reicht eine originale DS- oder DS-Lite-Konsole, für den DSi-Modus wird zusätzlich eine DSi-Konsole benötigt, da deren NAND-Speicher kryptografisch an genau dieses Gerät gebunden ist.

Ist die Nutzung von melonDS in Deutschland legal?

Der Emulator selbst ist als Software rechtlich unproblematisch: Es handelt sich um ein eigenständiges, quelloffenes Programm ohne Nintendo-Code. Rechtlich heikel wird es erst bei BIOS-Dateien, Firmware und Spiele-ROMs, denn Computerprogramme genießen nach § 69a UrhG einen eigenständigen urheberrechtlichen Schutz.

Entscheidend ist eine oft übersehene Besonderheit des deutschen Urheberrechts: Die allgemeine Privatkopie-Schranke nach § 53 UrhG gilt ausdrücklich nicht für Computerprogramme. Für Software gibt es stattdessen die speziellere Regelung in § 69d UrhG, die dem “rechtmäßigen Erwerber” einer Software erlaubt, eine notwendige Sicherungskopie anzufertigen. Praktisch bedeutet das:

Das Auslesen der BIOS- und Firmware-Dateien aus der eigenen DS- oder DSi-Konsole ist als Sicherungskopie im Sinne von § 69d UrhG rechtlich vertretbar.
Das Herunterladen von BIOS-Dumps, die von fremden Personen im Internet bereitgestellt werden, ist von dieser Ausnahme nicht gedeckt – hier verbreitet jemand anderes ein fremdes Computerprogramm ohne Erlaubnis.
Für Spiele-ROMs gilt dieselbe Logik: Nur das eigene, physisch vorhandene Modul selbst auszulesen (etwa über einen entsprechenden Flashcart-Dumper), bewegt sich auf rechtlich vertretbarem Boden.
ROM-Download-Portale berufen sich häufig auf eine “Ich besitze das Original”-Ausnahme, die es für Software im deutschen Recht in dieser Form nicht gibt.

Dieser letzte Punkt ist der am häufigsten übersehene: Selbst wer das Originalmodul eines Spiels nachweislich im Regal stehen hat, erwirbt dadurch nicht automatisch das Recht, eine online kursierende Kopie herunterzuladen. Rechtlich zählt allein, WER die konkrete Kopie erstellt hat und WOMIT – nicht, ob der Nutzer das Original ebenfalls besitzt. Wer ROMs aus dem eigenen Modul selbst zieht, bewegt sich im Rahmen des § 69d UrhG; wer stattdessen eine fremde Datei herunterlädt, begeht unabhängig vom eigenen Spielebesitz eine Urheberrechtsverletzung, die im Ernstfall auch abmahnfähig ist. Für Privatpersonen bleibt das Risiko einer tatsächlichen Abmahnung beim reinen Download zwar gering, verschwindet dadurch aber rechtlich nicht.

Verbraucherzentralen und Fachmedien wie heise.de vertreten in ihrer Berichterstattung zu Emulatoren durchgehend diese Linie: Der Emulator ist legal, der Umgang mit BIOS und ROMs entscheidet über die rechtliche Bewertung im Einzelfall. Wer nur eigene Dumps aus eigener Hardware verwendet, bewegt sich auf der sicheren Seite.

Schritt 1: Herunterladen

Alle offiziellen Builds stehen auf der GitHub-Releases-Seite von melonDS-emu/melonDS bereit. Für Windows und macOS lädst du dort direkt das passende ZIP-Archiv der Version 1.1 herunter – der Emulator wird portabel ausgeliefert, es gibt bewusst keinen klassischen Installationsassistenten. Für Linux ist Flathub der offizielle Kanal (Schritt 4).

# Beispiel: aktuelle Release-Metadaten direkt über die GitHub-API abrufen
curl -s https://api.github.com/repos/melonDS-emu/melonDS/releases/latest \
  | grep -E '"tag_name"|"published_at"|"browser_download_url"'

Der Befehl zeigt Versionsnummer, Veröffentlichungsdatum und die direkten Download-Links der aktuellen Version – praktisch, um vor der Installation zu prüfen, ob eine neuere Version als die lokal vorhandene erschienen ist. Lade Archive ausschließlich von der offiziellen Releases-Seite oder Flathub – Drittanbieter-Downloadportale, die den Emulator “gebündelt” mit angeblichen BIOS-Dateien anbieten, sind ein verbreiteter Weg, um Nutzern zusätzlich unerwünschte oder manipulierte Software unterzuschieben.

Schritt 2: BIOS- und Firmware-Dateien legal beschaffen

Hier entscheidet sich, ob der Emulator überhaupt startet. Ein weit verbreiteter, aber falscher Tipp behauptet, es gebe ein quelloffenes Ersatz-BIOS und BIOS-Dateien seien “optional”. Das offizielle FAQ widerspricht dem wörtlich: “melonDS requires BIOS and firmware dumps from a DS or if you want to emulate the DSi, melonDS requires the BIOS, firmware and NAND image. We haven’t gotten around to making alternate BIOS/firmware yet.” Es gibt also keine Ersatzdateien (HLE) – nur echte, selbst gedumpte Dateien funktionieren zuverlässig.

Datei	Größe	Benötigt für
bios9.bin	4 KB (ARM9)	DS-Modus (Pflicht)
bios7.bin	16 KB (ARM7)	DS-Modus (Pflicht)
firmware.bin	128 / 256 / 512 KB, je nach Quelle	DS-Modus – 128-KB-Dumps von DSi/3DS erlauben nur Direct Boot
bios9i.bin	64 KB (ARM9 DSi)	DSi-Modus (zusätzlich)
bios7i.bin	64 KB (ARM7 DSi)	DSi-Modus (zusätzlich)
firmware DSi	128 KB	DSi-Modus (zusätzlich)
NAND-Dump	≈ 240 MB	DSi-Modus – untrennbar an die eigene Konsole gebunden

Die Dateien lassen sich mit gängigen, dafür vorgesehenen Homebrew- und Dumping-Werkzeugen direkt aus der eigenen Konsole extrahieren. Wichtig: Ein NAND-Dump aus einer fremden DSi funktioniert grundsätzlich nicht auf einer anderen Konsole, da er individuelle Verschlüsselungsschlüssel des jeweiligen Geräts enthält – ein häufiger Grund, warum online kursierende NAND-Dumps in der Praxis schlicht nicht booten, unabhängig von der rechtlichen Bewertung. Bewahre die einmal erstellten Dumps zusätzlich als Backup außerhalb des Emulator-Ordners auf: Geht die eigene Konsole später kaputt oder verloren, lassen sich BIOS und Firmware aus dieser Sicherungskopie nicht neu erzeugen.

Schritt 3: Installation unter Windows

Das heruntergeladene ZIP-Archiv wird per Rechtsklick und “Alle extrahieren” in einen Ordner deiner Wahl entpackt, etwa C:\Emulatoren\melonDS. Da die Anwendung portabel ist, reicht ein Doppelklick auf melonDS.exe, um sie zu starten – es wird nichts in die Windows-Registrierung geschrieben, ein Deinstallieren bedeutet lediglich, den Ordner zu löschen. Beim allerersten Start wird nach BIOS- und Firmware-Pfaden gefragt; dieser Dialog lässt sich überspringen und später jederzeit unter Config → Emu Settings → DS-Modus nachholen.

Schritt 4: Installation unter Linux (Flatpak und AUR)

Der offizielle Linux-Kanal ist Flathub mit der App-ID net.kuribo64.melonDS. Auf Arch-basierten Distributionen stehen zusätzlich die AUR-Pakete melonds, melonds-git und melonds-bin zur Auswahl.

# Installation über Flathub (empfohlen, distributionsunabhängig)
flatpak install -y flathub net.kuribo64.melonDS
flatpak run net.kuribo64.melonDS

# Alternative auf Arch/Manjaro über einen AUR-Helper
yay -S melonds

Wer bereits EmuDeck oder Batocera nutzt, findet den Emulator dort in der Regel schon als Bestandteil der mitgelieferten Sammlung – ein manuelles Flatpak-Setup ist dann nicht nötig, lediglich die BIOS-Pfade müssen weiterhin manuell befüllt werden.

Schritt 5: Installation unter macOS

Für macOS liefert GitHub ein universelles ZIP-Archiv, das sowohl auf Intel- als auch auf Apple-Silicon-Macs läuft. Nach dem Entpacken kann macOS Gatekeeper die App zunächst blockieren, da sie nicht von Apple notariell bestätigt wurde. In diesem Fall über Systemeinstellungen → Datenschutz & Sicherheit den Start der App ausdrücklich erlauben, statt die Sicherheitsfunktion dauerhaft zu deaktivieren.

Schritt 6: Installation unter Android

Für Android existiert kein offizieller Port aus dem Hauptrepository, sondern ein eigenständiges, seit Jahren gepflegtes Community-Projekt. Es ist im Google Play Store unter dem Paketnamen me.magnum.melonds verfügbar und wird parallel im Quellcode-Repository SapphireRhodonite/melonDS-android weiterentwickelt (336 Sterne, Commits noch am heutigen Tag). Die App bringt seit einem Update im März 2025 einen OpenGL-Renderer mit Auflösungs-Skalierung bis zum 8-Fachen sowie manuelle Cheat-Eingabe mit.

Installation: App aus dem Play Store laden, beim ersten Start den Ordner mit den BIOS-Dateien und anschließend den ROM-Ordner auswählen. Wer die App direkt von GitHub statt aus dem Play Store bezieht, erhält teils neuere Funktionen etwas früher, muss dafür aber “Installation aus unbekannten Quellen” aktivieren.

Schritt 7: Erste Einrichtung – BIOS-Pfade konfigurieren

Nach der Installation öffnest du Config → Emu Settings → DS-Modus (bzw. DSi-Modus für den erweiterten Modus) und aktivierst dort die Option “Use external BIOS/firmware files”. Anschließend verweist du auf den Ordner, in dem die zuvor gedumpten Dateien liegen. Eine bewährte Ordnerstruktur sieht so aus:

~/Emulation/melonDS/
├── bios/
│   ├── bios9.bin
│   ├── bios7.bin
│   ├── firmware.bin
│   ├── bios9i.bin      (nur für DSi-Modus)
│   ├── bios7i.bin       (nur für DSi-Modus)
│   └── nand.bin           (nur für DSi-Modus, eigene Konsole)
├── roms/
│   └── nds/
└── saves/

Alle BIOS-Dateien müssen direkt im BIOS-Hauptordner liegen, nicht in Unterordnern – andernfalls werden sie nicht erkannt, und insbesondere der DSi-Modus startet gar nicht erst.

Schritt 8: ROMs laden und das erste Spiel starten

Über Datei → ROM öffnen navigierst du zu deinem ROMs-Ordner und wählst eine .nds-Datei aus. Startet alles korrekt, erscheint zunächst kurz das Nintendo-DS-Logo, gefolgt vom simulierten Startmenü der Konsole (bei aktivierter Firmware-Boot-Option) oder direkt dem Spiel (bei Direct Boot). Eine typische Konsolenausgabe beim Start über das Terminal sieht so aus:

$ ./melonDS ~/Emulation/melonDS/roms/nds/beispielspiel.nds
[melonDS] BIOS9 geladen (4096 Bytes)
[melonDS] BIOS7 geladen (16384 Bytes)
[melonDS] Firmware geladen (262144 Bytes)
[melonDS] ROM geladen: beispielspiel.nds (Speichertyp: erkannt)
[melonDS] Bereit – Fenster geöffnet (256x384, Dual-Screen)

Läuft das Spiel flüssig und reagiert der Touchscreen-Bildschirm auf Mausklicks, war die Einrichtung erfolgreich. Bleibt der Bildschirm dagegen schwarz oder friert die Anwendung direkt nach dem Logo ein, liegt die Ursache in praktisch allen Fällen bei einer fehlenden oder falsch abgelegten BIOS-Datei – der Abschnitt zur Fehlerbehebung weiter unten geht das systematisch durch.

Schritt 9: Grafik, Auflösung und Bildschirmlayout optimieren

Unter Config → Video Settings lässt sich zwischen Software- und OpenGL-Renderer wechseln. Der OpenGL-Renderer erlaubt eine interne Auflösungs-Skalierung weit über die native DS-Auflösung von 256×192 Pixel pro Bildschirm hinaus und sorgt für spürbar schärfere Kanten, besonders auf großen Monitoren. Ein Vulkan-Renderer ist entgegen gelegentlicher Behauptungen in Foren nicht Teil des offiziellen Funktionsumfangs; laut Projekt-FAQ bleibt die OpenGL-Unterstützung weiterhin “work in progress”. Der Software-Renderer wiederum ist zwar am langsamsten, dafür aber auf praktisch jeder Hardware ohne Treiberprobleme lauffähig und eignet sich gut, um technische Fehlerquellen einzugrenzen.

Für das Bildschirmlayout stehen unter Config → Display Settings mehrere Anordnungen bereit, die sich je nach Spielgenre unterschiedlich gut eignen:

Layout	Beschreibung	Gut geeignet für
Übereinander (Standard)	Beide Bildschirme klassisch vertikal gestapelt, wie am Original-Gerät	Rollenspiele, Jump’n’Runs, Standard-Gameplay
Nebeneinander	Beide Bildschirme horizontal angeordnet	Breite Monitore, Vergleich beider Bildschirminhalte
Hybrid	Ein Bildschirm groß, der andere klein daneben	Spiele mit seltener Touchscreen-Nutzung
Nur ein Bildschirm	Nur der aktuell relevante Bildschirm wird angezeigt	Maximale Auflösung auf kleinen Displays

Schritt 10: Spielstände und Save-States verwalten

Der Emulator unterscheidet zwischen zwei Arten von Spielständen: den regulären In-Game-Speicherständen, die in .sav-Dateien neben der ROM abgelegt werden und dem Speichersystem des jeweiligen Spiels entsprechen, sowie Save-States, die über F1 bis F8 den kompletten Emulator-Zustand inklusive Bildschirminhalt sichern. Save-States sind praktisch für schnelles Zwischenspeichern, ersetzen aber keine regulären Spielstände – bei einem größeren Versionswechsel sind ältere Save-States nicht immer kompatibel, während .sav-Dateien deutlich stabiler über Versionsgrenzen hinweg funktionieren.

Schritt 11: DSi-Modus aktivieren – NAND-Dump und zusätzliche BIOS-Dateien

Der DSi-Modus emuliert das erweiterte Betriebssystem der Nintendo DSi inklusive integriertem Speicher, DSiWare-Anwendungen und Kamera-Funktionen. Dafür wechselst du in den Einstellungen von DS-Modus zu DSi-Modus und hinterlegst zusätzlich zu den DS-Dateien die DSi-spezifische BIOS (jeweils 64 KB für ARM9 und ARM7), eine 128-KB-DSi-Firmware sowie den rund 240 MB großen NAND-Dump.

Der NAND-Dump ist der aufwendigste Teil: Er muss zwingend aus der eigenen DSi-Konsole stammen, da darin gerätespezifische Verschlüsselungsschlüssel gespeichert sind. Ein aus dem Internet bezogener NAND-Dump einer fremden Konsole lässt sich grundsätzlich nicht nutzen – unabhängig von jeder rechtlichen Frage scheitert das schon rein technisch. Plane für den DSi-Modus insgesamt spürbar mehr Einrichtungszeit ein als für den reinen DS-Modus, allein schon wegen der zusätzlichen Dumping-Schritte auf der echten Konsole.

Schritt 12: Lokalen Multiplayer und WLAN einrichten

Der Emulator unterstützt über die integrierte virtuelle Zugangspunkt-Funktion (melonAP) lokalen Mehrspieler-Betrieb zwischen mehreren Instanzen auf demselben Rechner oder Netzwerk – praktisch für Reihen wie Mario Kart DS, Pokémon oder Animal Crossing, deren Tauschfunktionen auf lokalem WLAN basieren. Laut offizieller Dokumentation gilt diese Funktion weiterhin als instabil beziehungsweise in aktiver Entwicklung; eine vollwertige Internet-Multiplayer-Infrastruktur über das ursprüngliche Nintendo-WFC-Netzwerk hinaus steht weiterhin auf der Projekt-Aufgabenliste und sollte nicht als ausgereiftes Feature vorausgesetzt werden.

Auf Steam Deck, Bazzite und Handhelds nutzen

Auf Linux-basierten Handhelds wie dem Steam Deck lässt sich der Emulator über Flathub genauso installieren wie auf einem klassischen Linux-Desktop. Wer Bazzite als Betriebssystem einsetzt oder eine Emulation-Sammlung wie Batocera beziehungsweise EmuDeck nutzt, bekommt der Emulator in aller Regel bereits vorkonfiguriert mitgeliefert. Der native Gamepad-Support des Steam-Decks lässt sich zusätzlich über Steam-Input-Profile auf die eigene Tastenbelegung des Emulators mappen, was insbesondere den Touchscreen-Bildschirm über den rechten Trackpad-Bereich steuerbar macht.

Performance ist auf modernen Handhelds kein Thema: Die für Nintendo-DS-Emulation nötige Rechenleistung ist im Vergleich zu PS3- oder PSP-Emulation minimal, selbst ältere Akku-schonende Taktraten reichen für konstante Bildraten meist locker aus. Wer parallel bereits Cemu für Wii-U- oder DuckStation für PS1-Titel eingerichtet hat, kann denselben Handheld problemlos für alle drei Systeme gleichzeitig nutzen, da jedes Projekt seine eigenen, getrennten Konfigurationsordner verwendet.

Datenschutz: Läuft alles vollständig offline?

Für sicherheits- und datenschutzbewusste Nutzer relevant: Der Emulator benötigt für den eigentlichen Betrieb kein Nutzerkonto, keine Registrierung und keine dauerhafte Internetverbindung. BIOS-Dateien, Firmware und ROMs werden ausschließlich lokal auf der eigenen Festplatte verarbeitet, eine Internetverbindung ist lediglich für den einmaligen Download des Programms sowie optional für lokalen WLAN-Mehrspielerbetrieb nötig. Das unterscheidet die lokale Emulation grundlegend von Cloud-Gaming-Diensten, bei denen Spielstand und Nutzungsdaten grundsätzlich über fremde Server laufen.

Standalone oder RetroArch-Core? Die richtige Version wählen

Beide Varianten basieren auf demselben Grundprojekt, unterscheiden sich aber in der Praxis spürbar. Die folgende Übersicht hilft bei der Entscheidung:

Wann sich die eigenständige Version lohnt

Wer den vollen DSi-Modus, die aktuellste WLAN-Multiplayer-Implementierung und die schnellste Feature-Auslieferung will, ist mit der Standalone-Version besser bedient, da neue Funktionen zuerst im Hauptrepository landen und der Core sie oft erst mit Verzögerung nachzieht.

Wer dagegen bereits eine große RetroArch-Bibliothek mit einheitlichen Shadern, Save-State-Verwaltung und Playlists über mehrere Systeme hinweg pflegt, profitiert von der nahtlosen Integration des Cores in genau diesen Workflow, auch wenn DSi-Spiele dabei aktuell eingeschränkter unterstützt werden.

Die häufigsten Fehler bei der Einrichtung

BIOS-Dateien in einem Unterordner ablegen. Der Emulator sucht die Dateien nur direkt im konfigurierten BIOS-Ordner, nicht rekursiv in Unterverzeichnissen.
DS-BIOS-Dateien für den DSi-Modus wiederverwenden. Der DSi-Modus benötigt eigene, zusätzliche BIOS- und Firmware-Dateien – die regulären DS-Dateien reichen dafür nicht aus.
Einen NAND-Dump aus dem Internet verwenden. NAND-Dumps sind an die jeweilige Konsole kryptografisch gebunden und funktionieren auf keiner anderen Konsole – unabhängig von der Quelle.
Firmware-Dateigröße verwechseln. Eine 128-KB-Firmware, die ursprünglich aus einer DSi oder einem 3DS stammt, erlaubt nur Direct Boot und keinen vollständigen Firmware-Start.
“Use external BIOS/firmware files” nicht aktivieren. Ohne diesen Haken in den Einstellungen werden die hinterlegten Dateien komplett ignoriert.
Unvollständige oder beschädigte ROM-Dumps verwenden. Abgebrochene Downloads oder fehlerhafte Cartridge-Dumps führen zu Abstürzen, die oft fälschlich der BIOS-Konfiguration zugeschrieben werden.
Save-States über Versionswechsel hinweg erwarten. Nach einem größeren Versionsupdate sind alte Save-States nicht immer kompatibel – reguläre .sav-Spielstände vor einem Update sichern.
Drittanbieter-Bundles mit “vorinstalliertem BIOS” nutzen. Solche Pakete stammen nie von der offiziellen Quelle und bergen sowohl rechtliche als auch technische Risiken, etwa manipulierte Programmdateien.

Fehlerbehebung: Lösungen für die häufigsten Probleme

Der Emulator zeigt nur einen schwarzen Bildschirm.
Meist fehlt eine BIOS- oder Firmware-Datei, oder der OpenGL-Renderer verträgt sich nicht mit dem Grafiktreiber. Zunächst unter Video Settings auf den Software-Renderer wechseln, um die Ursache einzugrenzen.

Fehlermeldung “BIOS not found” beim Start.
Der BIOS-Pfad in den Einstellungen zeigt nicht auf den richtigen Ordner, oder die Dateinamen weichen von bios9.bin/bios7.bin/firmware.bin ab. Groß- und Kleinschreibung unter Linux beachten.

Das Spiel startet, aber ohne Ton.
Unter Config → Audio Settings prüfen, ob das richtige Ausgabegerät ausgewählt ist. Bei manchen Linux-Distributionen hilft ein Wechsel zwischen PulseAudio- und PipeWire-Backend.

Spielstände verschwinden nach einem Neustart.
Der Speichertyp wurde beim ersten Laden der ROM falsch erkannt. Über Datei → ROM-Informationen lässt sich der Speichertyp manuell setzen, bevor das Spiel zum ersten Mal gespeichert wird.

Ruckelnde Bildrate trotz einfacher DS-Grafik.
Meist liegt es nicht an der Rechenleistung, sondern an einer zu hoch gewählten internen Auflösung im OpenGL-Renderer in Kombination mit aktivierter Bildschirmaufzeichnungs-Software. Auflösung schrittweise reduzieren.

Lokaler WLAN-Multiplayer verbindet sich nicht.
Beide Instanzen müssen dieselbe melonAP-Konfiguration nutzen und im selben lokalen Netzwerk laufen. Firewalls blockieren die Funktion häufig standardmäßig – testweise kurz deaktivieren, um die Ursache einzugrenzen.

Die Android-App stürzt beim Laden bestimmter Spiele ab.
Meist hilft ein Wechsel des Renderers in den App-Einstellungen von OpenGL zurück auf Software, insbesondere auf älteren oder speicherschwachen Geräten.

Bildschirmlayout wirkt gestreckt oder falsch proportioniert.
Unter Display Settings das Seitenverhältnis explizit auf “eingepasst” statt “gestreckt” stellen; insbesondere im Nebeneinander-Layout wird sonst leicht falsch skaliert.

DSi-Modus startet trotz korrekter Dateien nicht.
Häufigste Ursache ist ein NAND-Dump, der nicht zur eingesetzten DSi-BIOS/Firmware-Kombination passt, weil Dateien aus zwei unterschiedlichen Konsolen gemischt wurden. Alle DSi-Dateien müssen von derselben Konsole stammen.

Nach einem Update lassen sich alte Save-States nicht mehr laden.
Save-States sind eng an die interne Emulator-Version gebunden und können bei größeren Updates inkompatibel werden. Regulären .sav-Spielstand vor jedem größeren Update sichern, um nicht auf Save-States angewiesen zu sein.

Erweiterte Tipps für Fortgeschrittene

Wer den Emulator aus Skripten oder Frontends heraus steuert, kann ROMs direkt per Kommandozeile übergeben, was sich etwa für eigene Startmenüs oder Automatisierungen eignet:

melonDS --fullscreen ~/Emulation/melonDS/roms/nds/spiel.nds

Für portable Installationen – etwa auf einem USB-Stick – legt eine leere Datei namens portable.ini im Programmordner fest, dass sämtliche Konfigurationen und Save-States relativ zum Installationsort statt im Benutzerprofil gespeichert werden. Das erleichtert den Wechsel zwischen mehreren Rechnern erheblich, da keine Pfade manuell nachgezogen werden müssen.

Für sehr alte oder leistungsschwache Systeme lohnt sich ein Blick auf den JIT-Recompiler-Schalter unter Config → Emu Settings: Er ist standardmäßig aktiv und sollte es auch bleiben, da die Performance ohne JIT spürbar einbricht. Nur auf Architekturen, auf denen JIT nicht unterstützt wird, greift automatisch der klassische Interpreter-Modus.

Für Sammler mehrerer Konfigurationen (zum Beispiel getrennte Profile für DS- und DSi-Modus) empfiehlt sich, komplette Kopien des Programmordners mit jeweils eigener melonDS.ini anzulegen, statt ständig zwischen Einstellungen im selben Profil hin- und herzuschalten. Wer zusätzlich mehrere ROM-Bibliotheken (etwa eigene Dumps und Homebrew-Anwendungen) sauber trennen möchte, sollte separate Unterordner innerhalb von roms/nds/ anlegen, statt alles in einem einzigen Ordner zu sammeln – der Emulator selbst durchsucht Unterordner beim ROM-Öffnen-Dialog automatisch mit.

Vollständiges Setup-Skript: Automatisierte Einrichtung

Das folgende Bash-Skript fasst die wichtigsten Schritte für Linux zusammen: Es legt die empfohlene Ordnerstruktur an, prüft, ob die drei zwingend benötigten DS-BIOS-Dateien bereits vorhanden sind, und installiert den Emulator über Flathub, falls Flatpak verfügbar ist. Die BIOS-Dateien selbst müssen weiterhin manuell und legal aus der eigenen Konsole eingefügt werden – das Skript ersetzt diesen Schritt bewusst nicht.

#!/usr/bin/env bash
set -euo pipefail

EMU_DIR="$HOME/Emulation/melonDS"
BIOS_DIR="$EMU_DIR/bios"
ROMS_DIR="$EMU_DIR/roms/nds"
SAVES_DIR="$EMU_DIR/saves"

echo "Erstelle Ordnerstruktur unter $EMU_DIR ..."
mkdir -p "$BIOS_DIR" "$ROMS_DIR" "$SAVES_DIR"

REQUIRED_BIOS=("bios9.bin" "bios7.bin" "firmware.bin")
echo ""
echo "Pruefe auf vorhandene BIOS-Dateien:"
missing=0
for file in "${REQUIRED_BIOS[@]}"; do
  if [ -f "$BIOS_DIR/$file" ]; then
    size=$(stat -c%s "$BIOS_DIR/$file" 2>/dev/null || stat -f%z "$BIOS_DIR/$file")
    echo "  [OK] $file gefunden (${size} Bytes)"
  else
    echo "  [FEHLT] $file -- eigenen Dump hier ablegen: $BIOS_DIR/$file"
    missing=1
  fi
done

if command -v flatpak >/dev/null 2>&1; then
  echo ""
  echo "Installiere melonDS ueber Flathub ..."
  flatpak install -y flathub net.kuribo64.melonDS
else
  echo ""
  echo "Flatpak nicht gefunden. Anleitung: https://flathub.org/apps/net.kuribo64.melonDS"
fi

if [ "$missing" -eq 1 ]; then
  echo ""
  echo "Hinweis: Ohne vollstaendige BIOS-Dateien startet der Emulator nicht korrekt."
  echo "Nur selbst gedumpte Dateien aus der eigenen Konsole verwenden."
fi

echo ""
echo "Fertig. Unter Config -> Emu Settings den BIOS-Pfad setzen auf:"
echo "$BIOS_DIR"

Zur Ergänzung ein kleines Node.js-Beispiel, das sich in eigene Update-Checker oder Frontends einbauen lässt und die aktuellste verfügbare Version direkt über die GitHub-API abfragt:

const https = require('https');

const options = {
  hostname: 'api.github.com',
  path: '/repos/melonDS-emu/melonDS/releases/latest',
  headers: { 'User-Agent': 'melonds-version-check' }
};

https.get(options, (res) => {
  let data = '';
  res.on('data', (chunk) => (data += chunk));
  res.on('end', () => {
    const release = JSON.parse(data);
    console.log(`Aktuellste Version: ${release.tag_name}`);
    console.log(`Veroeffentlicht am: ${release.published_at}`);
    console.log(`Download: ${release.html_url}`);
  });
}).on('error', (err) => console.error('Fehler:', err.message));

Fazit: Lohnt sich der Aufwand?

Die Einrichtung ist in rund 20 bis 30 Minuten erledigt, sofern BIOS und Firmware bereits als eigene Dumps vorliegen – der eigentliche Zeitaufwand steckt fast immer im einmaligen Beschaffen dieser Dateien aus der eigenen Konsole, nicht in der Software-Installation selbst. Angesichts eines aktiv gepflegten Projekts mit wöchentlichen Commits, einer im Vergleich zu DeSmuME spürbar höheren Genauigkeit und einem klar dokumentierten, wenn auch strengen Umgang mit BIOS-Dateien bleibt dieser Emulator 2026 die erste Wahl für alles rund um Nintendo DS und DSi.

Wer die zwölf Schritte dieser Anleitung einmal durchlaufen hat, besitzt eine wiederholbare, dokumentierte Routine, die sich jederzeit auf einem neuen Rechner reproduzieren lässt – insbesondere im Portable-Modus. Angesichts der aktiven Weiterentwicklung und bislang fehlender rechtlicher Auseinandersetzung mit Nintendo spricht wenig dagegen, mit der Einrichtung von melonDS bereits heute zu beginnen, sofern die eigenen BIOS-Dateien aus rechtmäßigem Besitz stammen.

Häufig gestellte Fragen zu melonDS

Ist melonDS kostenlos?
Ja. Der Emulator steht unter der GPL-3.0-Lizenz und ist komplett kostenlos, ohne Werbung oder versteckte Kosten.

Brauche ich zwingend eine echte Nintendo-DS-Konsole?
Ja, zumindest einmalig zum Dumpen der BIOS- und Firmware-Dateien. Ohne diese Dateien startet der Emulator nicht korrekt, ein integriertes Ersatz-BIOS gibt es laut offiziellem FAQ nicht.

Funktioniert der Emulator wirklich nicht ohne BIOS-Dateien?
Korrekt, und das ist ein häufiges Missverständnis. Einige ältere Anleitungen behaupten das Gegenteil, das offizielle Projekt-FAQ stellt aber ausdrücklich klar, dass keine alternativen BIOS-Dateien mitgeliefert werden.

Ist die Nutzung von melonDS in Deutschland legal?
Der Emulator selbst ja. Rechtlich unproblematisch ist zudem das Auslesen von BIOS-Dateien und ROMs aus der eigenen Konsole als Sicherungskopie nach § 69d UrhG. Aus dem Internet heruntergeladene BIOS-Dumps oder ROMs fremder Herkunft fallen nicht unter diese Ausnahme.

Kann ich damit auch Nintendo-DSi-Spiele spielen?
Ja, im DSi-Modus, der zusätzlich zu den DS-Dateien eigene DSi-BIOS-Dateien und einen NAND-Dump aus einer eigenen DSi-Konsole benötigt.

Läuft der Emulator auf dem Steam Deck oder anderen Handhelds?
Ja, über Flathub direkt oder vorkonfiguriert als Teil von Sammlungen wie Batocera oder EmuDeck. Die für DS-Emulation nötige Rechenleistung ist auf jedem aktuellen Handheld unproblematisch.

Was ist der Unterschied zwischen der eigenständigen Version und dem RetroArch-Core?
Die Standalone-Version erhält neue Funktionen zuerst und unterstützt den DSi-Modus vollständig, der RetroArch-Core integriert sich dafür nahtlos in eine bestehende RetroArch-Bibliothek, hinkt bei DSi- und WLAN-Funktionen aber etwas hinterher.

Unterstützt melonDS Online-Multiplayer über das Internet?
Nur eingeschränkt. Lokaler Mehrspieler-Betrieb zwischen mehreren Instanzen funktioniert über die melonAP-Funktion, eine vollwertige Internet-Infrastruktur gilt laut Projekt-Dokumentation weiterhin als instabil beziehungsweise in Entwicklung.

Wie hoch ist die tatsächliche Spielkompatibilität?
Eine offizielle, verlässliche Prozentzahl für die komplette Spielebibliothek existiert nicht. Belegt ist lediglich, dass das Projekt gezielt auf Genauigkeit setzt und dadurch die meisten kommerziell erfolgreichen Titel zuverlässig laufen, sofern BIOS und Firmware korrekt eingerichtet sind.