melonDS aims at providing fast and accurate Nintendo DS emulation. While it is still a work in progress, it has a pretty solid set of features:

• Nearly complete core (CPU, video, audio, ...)
• JIT recompiler for fast emulation
• OpenGL renderer, 3D upscaling
• RTC, microphone, lid close/open
• Joystick support
• Savestates
• Various display position/sizing/rotation modes
• (WIP) Wifi: local multiplayer, online connectivity
• (WIP) DSi emulation
• DLDI
• (WIP) GBA slot add-ons
• and more are planned!







Download melonDS

If you're running into trouble: Howto/FAQ
Pages:1234567···23
Happy birthday melonDS!
Nov 3rd 2025, by Arisotura
Those of you who know your melonDS lore know that today is a special day. melonDS is 9 years old!



...hey, I don't control this. 9 is brown. I don't make the rules.

Anyway, yeah. 9 years of melonDS. That's quite the achievement. Sometimes I don't realize it has been so long...

-

As far as I'm concerned, there hasn't been a lot -- 2025 has had a real shitty start for me. A lot of stuff came forward that has been really rough.

On the flip side, it has also been the occasion to get a fresh start. I was told about IFS therapy in March, and I was able to get started. It has been intense, but so far it has been way more effective than previous attempts at therapy.

I'm hopeful for 2026 to be a better year. I'm also going to hopefully get started with a new job which is looking pretty cool, so that's nice too.

-

... read more
12 comments (last by Lockstar64) | Post a comment
The joys of programming
Nov 1st 2025, by Arisotura
There have been reports of melonDS 1.0 crashing at random when running multiple instances. This is kind of a problem, especially when local multiplayer is one of melonDS's selling points.

So I went and tried to reproduce it. I could get the 1.0 and 1.0RC builds to crash just by having two instances open, even if they weren't running anything. But I couldn't get my dev build to crash. I thought, great, one of those cursed bugs that don't manifest when you try to debug them. I think our team knows all about this.

Not having too many choices, I took the 1.0 release build and started hacking away at it with a hex editor. Basic idea being, if it crashes with no ROM loaded, the emulator core isn't the culprit, and there aren't that many places to look. So I could nop out function calls until it stopped crashing.

In the end, I ended up rediscovering a bug that I had already fixed.

The SDL joystick API isn't thread-safe. When running multiple emulator instances in 1.0, this API will get called from several different threads, since each instance gets its own emulation thread. I had already addressed this 2.5 months ago, by adding adequate locking.

I guess at the time of 1.0, it slipped through the cracks due to its random nature, as with many threading-related bugs.

Regardless, if you know your melonDS lore, you know what is coming soon. There will be a new release which will include this fix, among other fun shit. In the meantime, you can use the nightly builds.
5 comments (last by Deaddie999) | Post a comment
Sneak peek
Oct 27th 2025, by Arisotura
Just showing off some of what I've been working on lately:



This is adjacent to something else I want to work on, but it's also been in the popular request list, since having to manually enter cheat codes into melonDS isn't very convenient: would be much easier to just import them from an existing cheat code database, like the R4 cheat database (also known as usrcheat.dat).

It's also something I've long thought of doing. I had looked at usrcheat.dat and figured the format wasn't very complicated. It was just, you know, actually making myself do it... typical ADHD stuff. But lately I felt like giving it a look. I first wrote a quick PHP parser to make sure I'd gotten the usrcheat.dat format right, then started implementing it into melonDS.

For now, it's in a separate branch, because it's still quite buggy and unfinished, but it's getting there.

The main goal is complete, which is, it parses usrcheat.dat, extracts the relevant entries, and imports them into your game's cheat file. By default, it only shows the game entry which matches your game by checksum, which is largely guaranteed to be the correct one. However, if none is found, it shows all the game entries that match by game code.

It also shows a bunch of information about the codes and lets you choose which ones you want to import. By default, all of them will be imported.

This part is mostly done, besides some minor UI/layout bugs.

The rest is adding new functionality to the existing cheat code editor. I modified the melonDS cheat file format (the .mch files) to add support for the extra information usrcheat.dat provides, all while keeping it backwards compatible, so older .mch files will still load just fine. But, of course, I also need to expose that in the UI somehow.

... read more
8 comments (last by Loreciao) | Post a comment
Not much to say lately...
Oct 15th 2025, by Arisotura
Yeah...

I guess real life matters don't really help. Atleast, my mental health is genuinely improving, so there's that.

But as far as my projects are concerned, this seems to be one of those times where I just don't feel like coding. Well, not quite, I have been committing some stuff to melonDS... just not anything that would be worthy of a juicy blog post. I also had another project: porting my old SNES emulator to the WiiU gamepad. I got it to a point where it runs and displays some graphics, but for now I don't seem motivated to continue working on it...

But I still have some ideas for melonDS.

One idea I had a while ago: using the WFC connection presets to store settings for different altWFC servers. For example, using connection 1 for Wiimmfi, connection 2 for Kaeru, etc... and melonDS would provide some way of switching between them. I don't know how really useful it would be, or how feasible it would be wrt patching requirements, but it could be interesting.

Another idea would be RTCom support. Basically RTCom is a protocol that is used on the 3DS in DS mode to add support for analog sticks and such. It involves game patches and ARM11-side patches to forward input data to RTC registers. The annoying aspect of this is that each game seems to have its own ARM11-side patch, and I don't really look forward to implementing a whole ARM11 interpreter just for this.

But maybe input enhancements, be it RTCom stuff or niche GBA slot addons, would make a good use case for Lua scripting, or some kind of plugin system... I don't know.

There are other big ideas, of course. The planned UI redesign, the netplay stuff, website changes, ...

Oh well.
16 comments (last by Zerando Jogos) | Post a comment
Fix for macOS builds
Sep 26th 2025, by Arisotura
Not a lot to talk about these days, as far as melonDS is concerned. I have some ideas, some big, some less big, but I'm also being my usual ADHD self.

Anyway, there have been complaints about the macOS builds we distribute: they're distributed as nested zip files.

Apparently, those people aren't great fans of Russian dolls...

The issue is caused by the way our macOS CI works. I'd have to ask Nadia, but I think there isn't really an easy fix for this. So the builds available on Github will have to stay nested.

However, since I control this site's server, I can fix the issue here. So now, all the macOS builds on the melonDS site have been fixed, they're no longer nested. Similarly, new builds should also be fixed as they're uploaded. Let us know if anything goes wrong with this.
7 comments (last by Spitfire) | Post a comment
DSP HLE: reaching the finish line
Aug 11th 2025, by Arisotura
In the last post, the last things that needed to be added to DSP HLE were the G711 ucode, and the basic audio functions common to all ucodes.

G711 was rather trivial to add. The rest was... more involved. Reason was that adding the new audio features required reworking some of melonDS's audio support.


melonDS was originally built around the DS hardware. As far as sound is concerned, the DS has a simple 16-channel mixer, and the output from said mixer is degraded to 10-bit and PWM'd to the speakers. Microphone input is even simpler: the mic is connected to the touchscreen controller's AUX input. Reading said input gives you the current mic level, and you need to set up a timer to manually sample it at the frequency you want.

So obviously, in the early days, melonDS was built around that design.

The DSi, however, provides a less archaic system for producing and acquiring sound.

Namely, it adds a TI audio amplifier, which is similar to the one found in the Wii U gamepad, for example. This audio amplifier also doubles as a touchscreen controller, for DS backwards compatibility.

Instead of the old PWM stuff, output from the DS mixer is sent to the amplifier over an I2S interface. There is some extra hardware to support that interface. It is possible to set the sampling frequency to 32 KHz (like the DS) or 47 KHz. There is also a ratio for mixing outputs from the DS mixer and the DSP.

Microphone input also goes through an I2S interface. The DSi provides hardware to automatically sample mic input at a preset frequency, and it's even possible to automate it entirely with a NDMA transfer. All in all, quite the upgrade compared to the DS. Oh, and mic input is also routed to the DSP, and the ucodes have basic functions for mic sampling too.

All fine and dandy...

... read more
17 comments (last by Arisotura) | Post a comment
Having fun with DSP HLE
Jul 31st 2025, by Arisotura
If you pay attention to the melonDS repo, you might have noticed the new branch: dsp_hle.

And this branch is starting to see some results...



These screenshots might not look too impressive at first glance, but pay closer attention to the framerates. Those would be more like 4 FPS with DSP LLE.

Also, we still haven't fixed the timing issue which affects the DSi sound app -- I had to hack the cache timings to get it to run, and I haven't committed that. We'll fix this in a better way, I promise.


So, how does this all work?

CasualPokePlayer has done research on the different DSP ucodes in existence. So far, three main classes have been identified:

• AAC SDK: provides an AAC decoder. The DSi sound app uses an early version of this ucode. It is also found in a couple other titles.

• Graphics SDK: provides functions for scaling bitmaps and converting YUV pictures to 15-bit RGB.

... read more
8 comments (last by Arisotura) | Post a comment
melonDS 1.0 is out
Jul 8th 2025, by Arisotura
Finally, the "proper" melonDS 1.0 release is here. Sorry that it took so long...


Anyway, this is pretty much the same as the 1.0 RC, but we fixed a bunch of bugs that were found in said RC.


Namely, you can now use multiple windows with OpenGL under Windows.

However, depending on how good your OpenGL driver is, doing so may reduce performance. It's due to having multiple OpenGL contexts sharing data, but for now we don't really know what we can do about it. If you have ideas, let us know!

Speaking of multiple windows, I also added a way to tell melonDS windows apart, because things could get pretty confusing. They now get a tag in their title, for example [p1:w2] means first multiplayer instance, second window.


We also merged asie's add-on support PR, so this release includes support for the Motion Pak and the Guitar Grip.

We merged some other PRs. Among which, lower audio latency.


This release also includes the DSi camera fixes that were discussed in the previous posts. DSi titles that ran into issues while trying to use the camera should now work with no problems.

However, since they tend to also use the DSP at the same time, the performance will be abysmal...

... read more
40 comments (last by mrjfilippo) | Post a comment
Let's Golf: the horseman of apocalypse that wasn't one
Jul 7th 2025, by Arisotura
I figure I need to resolve the dramatic tension from the previous post.

So the issue we had was a screen-sized DMA3 transfer interfering with NDMA1, which is used to transfer camera data...


Shortly after I made that post, I recalled that Jakly mentioned VRAM timings, and started to figure it out.

I said that when I reproduced the setup in a homebrew, it would trigger a data overrun error and get stuck. But there was one thing I was missing: my homebrew was using a camera resolution of 256x192, with DMA set to run every 4 scanlines, the standard stuff. However, Let's Golf uses cropping to achieve a resolution of 144x144, and runs the DMA every 7 scanlines. This means more time between each NDMA1 transfer.

Regarding VRAM, the DSi supports accessing it over the 32-bit bus, instead of the old 16-bit bus. One effect is that this makes it possible to write to VRAM in 8-bit units, which wasn't possible on the DS. Another effect is that it affects timings: for example, a 32-bit DMA transfer from main RAM to VRAM would take 2 cycles per word, instead of 3.

I did the math, and with such timings, the screen-sized DMA3 transfer would have enough time that it could run between two NDMA1 transfers without disrupting the camera operation. But with the 16-bit bus timings, DMA3 would definitely take too long.

I even modified my homebrew to use the same 144x144 resolution as Let's Golf, and added a key to toggle the 32-bit bus for VRAM (via SCFG_EXT9 bit 13). Suddenly, my homebrew was running just fine as long as the 32-bit bus was enabled, but when it was disabled, it would trigger the data overrun error and get stuck.

So, basically, this is nothing fancy, just a case of "this works out of pure luck".


I added support for the new VRAM timings in melonDS. But this wasn't enough, Let's Golf would still get stuck.

... read more
3 comments (last by Arisotura) | Post a comment
More camera trouble...
Jul 6th 2025, by Arisotura
So I had made a nice post about Let's Golf and how it was fixed...

But, obviously, as far as DSi camera support is concerned, it wasn't all.


I looked at another game that was running into issues with the camera: Assassin's Creed II. The Wanted feature in the menu uses the camera, if you're playing the game on a DSi, but on melonDS, it just showed nothing at all.

Quick investigation showed why.

Normally, when using the camera, games will set up the DMA with a block length of N scanlines, and a total length matching the length of the full camera picture. The DMA channel will also be set to trigger an IRQ when it's done.

However, this game does things differently. The DMA channel has no total length setting, and is just set to repeat infinitely. It transfers picture data to a small temporary buffer, from which the game reads when needed. No idea why they did it this way, but regardless, shows why it's good to emulate things accurately. Anyway, a NDMA channel that is set to "repeat infinitely" will trigger an IRQ after each block, but due to an oversight, melonDS never triggered any IRQ.

After fixing this, I did have the camera feed showing up in the game's UI thing, but it was rolling. Heh. Couldn't have been so simple.

This turned out to be because of the timings for the camera transfer. The timings melonDS used were a big fat guess, and were way too fast for that game.

I dug up my old camera test homebrew and modified it to track camera timings from the DSi. Took some time to figure out the logic behind the numbers I was getting -- there was more time between camera DMA transfers when running in 256x192 mode, than in 640x480 mode. In fact, it makes sense: internally, the camera always runs at 640x480, and the HSync/VSync are the same, but when told to output a 256x192 picture, the camera simply skips some of the scanlines.

... read more
4 comments (last by jiink) | Post a comment
Pages:1234567···23