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:12345678···21
LAN: almost done!
Aug 7th 2024, by Arisotura
Those of you who pay attention to our git repo may have noticed the recent activity in the season3 branch.

The plan was to backport the LAN and netplay features to a recent branch, since the old season2 branch was way outdated. It is over one year old, and a lot of refactoring has happened since then. I figured that backporting them would be easier than trying to get season2 up to date, so that was why season3 was started.

I didn't even realize season2 was that old before I checked. Shows how good my perception of time is, really.


Anyway, the backporting is going smoothly so far. The LAN feature is fully ported, and it seems to be functioning. Also, JesseTG helpfully moved the network interfaces to their own module, so different frontends can reuse them. I based my work on that, and added an interface to switch between multiplayer modes (local, LAN, netplay).

All that is missing is some polish on the UI side. I will take care of the biggest problems, make sure it all works smoothly, and we will merge season3 very quickly.

This will enable you to test LAN multiplayer by simply grabbing our nightly builds (from Github's Actions tab; you need a Github account).


After that, I will tackle netplay in what will be season4. For now, I brought in the netplay related code, but I just commented out a lot of it so melonDS would build. It is nowhere near functional for now, and there is more work with it.

But on the other hand, several of the issues I had encountered during the original implementation are now solved.

For example, my original idea to get multiple instances started with the exact same state was to use the savestate system. Take a snapshot of one instance's state, send it over the network to other instances, which can just apply it and be all set (or so I hope). Sounds easy enough. Except the savestate system was coded to deal with files directly. I had worked around it in a very ugly way, but the issue has since been fixed, the savestate system operates on memory chunks now.

... read more
6 comments (last by Unknown Messenger) | Post a comment
Sorry for the downtime
Jul 24th 2024, by Arisotura
For some reason we had DNS trouble affecting our kuribo64.net subdomains. Things should progressively go back to normal now.
10 comments (last by melonJYC) | Post a comment
Backporting LAN and netplay: we're getting started!
Jul 18th 2024, by Arisotura
Progress on this will happen in the season3 branch. For now, this branch doesn't even build, so don't get all excited about it yet :P

LAN should not be too difficult to backport, as it was largely functional.

Netplay will be another story. It was built around the old multi-process IPC system, and is generally obsolete, so a lot of reworking will be needed to get it functional again.

I'm hoping to be able to get all that to a functional state by November. We'll see how this goes.

There's also work needed to properly integrate this to the UI. I'm thinking of enforcing one melonDS instance only when using LAN or netplay, to keep things simpler. For netplay, it would pretty much be required anyway, as we will need to have instances set up in a specific way.

You can tell things aren't super fast on my side, I've pretty much taken a one-month break after getting doublemelon done. I need a big break from melonDS, which I will hopefully take after 1.0 is released.
10 comments (last by kikilxve) | Post a comment
News of the refactor: doublemelon is merged
Jun 15th 2024, by Arisotura
Finally, time has come to merge the doublemelon branch.

This was the second big step of the refactor (after refactoring the core). It is now done, so we have a good base upon which to build the features we want for melonDS 1.0.

There is still a lot of work to do. Many areas of the codebase are less than ideal, there are some old bugs that linger and that we need to address, but we will get there in due time. melonDS 1.0 will be big, and we can't afford to let any stupid bugs slide.

But for now, a quick list of the changes the doublemelon merger is bringing in:

Some base work is laid for multi-window support. There will be more work to get it working correctly, but we do have a good base going now. This was the original intention behind the doublemelon branch, it just became a step in the refactor because it was pretty much required.

The configuration system has been remade to be much more flexible. There is code in place to translate legacy config files to the new format, so you won't lose your settings.

The frontend components have been properly encapsulated, which allows for proper multi-instance support. As of now, we still need to deal with a workaround in the JIT, so multi-instance will only work with the interpreter.


Thank you all for your support, and stay tuned for more!
19 comments (last by Luxion) | Post a comment
News of the refactor: almost there!
Jun 10th 2024, by Arisotura
Basically what it says on the tin. I am working on the last big part of this refactor: the network interfaces. You might already know melonDS employs two different network interfaces: one for local multiplayer (between multiple melonDS instances) and one for outer network, which lets melonDS connect to external servers (like WFC) through libslirp or PCap.

These need to be adapted to the refactor, too.

Adapting the local multiplayer interface wasn't that hard. What I did was simply change the shared memory buffer to a regular memory buffer guarded by a mutex, and change the interprocess semaphores to regular semaphores. This makes the code simpler and easier to deal with.

From a performance perspective, I haven't observed a huge improvement from this change, atleast under Linux. However, the gains will be apparent when we will be reimplementing netplay: managing multiple emulator instances is going to be a whole lot easier and more reliable when they are all contained within the same process.

Then I moved on to the outer network interfaces. I had a bit of a debate as to whether to make them instance-specific. Because it could make sense to have them be shared across instances: these instances could be networked together rather than being isolated. It's a bit of a hypothetical scenario, but I like the possibility.

It requires, among other things, sharing around data frames. So this is what I'm working on: designing a packet queue system that can broadcast packets across all emulator instances in a reliable and efficient way.

Once I've tackled the network part of melonDS, the refactor will be mostly done. There will be a few bugs and misc things to iron out, and we will be good to finally merge it.

There will still be a lot of stuff to fix and rework, but we will atleast be in a somewhat workable state.
13 comments (last by Isabella) | Post a comment
Refactor still underway...
May 27th 2024, by Arisotura
There has been pretty good progress done, though. We have decided against merging my branch until it's a bit more complete, but it's getting pretty close at this point.

I finished porting everything to use the new configuration system, and thus the old system (really just a pile of global variables) is no more.

Most of the frontend is also properly encapsulated. What remains at this point is the core-frontend glue (Platform.cpp) and the networking code.

There will still be a bunch of cleanup and fixes to do, but we're getting there! The first goal is to get everything encapsulated so it becomes possible to run multiple DS instances within the same melonDS process. The code may not be the best or the prettiest, but we can always go back and fix up things later, when the bulk of the work is done.

Quite the audacious refactor, given the sheer scale of it, but it's definitely worth it. Even if it can feel paralyzing at times.

Stay tuned!
17 comments (last by AlexHalley) | Post a comment
Refactor underway
May 15th 2024, by Arisotura
Due to the scope of the refactor, keeping it all in a separate branch will not be feasible. I will have to merge my branch soon (hopefully by the end of the week).

This means that while the refactor is in progress, CI builds will be more or less rather broken and unstable, so don't rely on them.

We also plan on putting up 'beta' builds with certain features of interest, namely the compute shader renderer that has been merged recently, or season2 (the experimental LAN/netplay branch).


Also, side note: the comment section is not for posting your brainfarts. Pointless comments will be deleted. Repeated pointless comments will get you banned.

Thank you.
12 comments (last by IdkWhatItIs) | Post a comment
A couple notes about the Delta release
Apr 24th 2024, by Arisotura
It appears that the recent release of Delta on the Apple app store is giving us extra attention. While this is nice, I would like to state a few things.


First, we the melonDS team are not responsible for third-party ports (with the exception of Generic supporting the Switch port, since he made it). Our scope is limited to the melonDS core and the desktop frontend (ie. the Windows, Linux and macOS versions).

If you are running into issues with Delta, or with any port of melonDS: you should contact the authors of that port. Members of our community may also be able to help you, but contacting the port authors directly may be quicker.

It is also worth noting that port authors are responsible for keeping their port up-to-date.

At the time of writing this, Delta is using melonDS 0.9.1 as its core, which is quite outdated by now. If you're running into emulation issues with Delta, chances are that the bugs have long been fixed, but you will need to bug the Delta authors to update their port. We have tried to contact them about this, but haven't received a response yet.


tl;dr: if you are running into any issue with Delta, or any melonDS port, please ask the authors of that port first.


Second point, emulation frontends like Delta, RetroArch or BizHawk (to name a few) are definitely impressive pieces of work, but it is worth keeping in mind that they wouldn't be possible without the work from the emulator authors who provide the cores these frontends use. So if you're considering donating towards these frontend projects, try to keep the underlying emulator core projects in mind too.

That being said, we have already seen an influx of new patrons, so thank you folks!


Third point, not related to Delta per se, but this is prompted by the situation: I'm planning a bunch of updates to the site.

... read more
20 comments (last by Matthew) | Post a comment
News of the great refactoring
Apr 19th 2024, by Arisotura
In this post I showed an attempt at running two melonDS windows at the same time. Just a silly test, but groundwork for more.

What became apparent during this is the fact that our current configuration system won't do.

The current config system was born out of simple needs: at the time we just needed to store a few configuration values. The keyboard and joystick input mappings, and misc settings like direct boot or 3D renderer threading. For this, a simple pseudo-INI format was deemed enough. The config file is named melonDS.ini, but it is just a simple key-value pair format with a custom parser, not an actual INI format.

The configuration data in melonDS is just a bunch of global variables in the Config namespace exposed to the entire program. The parser simply goes through all the lines in melonDS.ini, checks the key against a list of possible keys, and when a match is found, the corresponding variable is filled with the value that was read. The same list also serves to initialize the config data with default values (for example, if melonDS.ini wasn't created yet). All fine and dandy.

This system, however, doesn't shine in its flexibility. This started becoming apparent in 0.9.5 when the new local multiplayer system was added. I realized we needed a way to allow each melonDS instance to have different settings for things like input mappings. Prior, the only way to do that was to run the different instances from different folders.

The solution I had come up with, was to create other melonDS.ini files: melonDS.2.ini for instance 2, melonDS.3.ini for instance 3, and so on. melonDS.ini would contain the bulk of the settings: the settings that are common across all instances, and the settings for instance 0. Then, when opening a new instance, it will get the global settings from the main melonDS.ini, and its instance-specific settings from its specific config file. If said specific file doesn't exist, it is initialized from the main melonDS.ini.

It's nice and colorful, but a bit unwieldy...

When I started working on that proof-of-concept multiple window thing, I had a realization in the same vein. Basically, the config file also serves to store settings related to the window: size, layout settings, etc. For a multi-window feature to be useful, we want each window to have its own settings (say, having one window display the top screen, and another the bottom screen). Clearly, the current config system won't do here.

So what can we do? Find other creative ways to get around the lack of flexibility of the pseudo-INI system?

... read more
4 comments (last by it is) | Post a comment
Wifi fixes: channels and power
Apr 10th 2024, by Arisotura
Long time no update. Sorry about that. I'm getting better, though.

Anyway, I recently felt like getting back into melonDS dev. I figured that trying to fix some wifi bugs could help me build up momentum and motivation I'll need to finish the big refactor.

The point of the big refactor is to lay groundwork for turning netplay from a clunky proof of concept into an actual finished product. But netplay or LAN won't be very useful if the underlying wifi implementation is malfunctioning...


The first bug I looked at was that weird bug in Meteos: when starting a download play game, if you're using a DSPhat firmware, you will instantly get a connection error, but everything will work fine if you're using a DSLite firmware.

So I researched the bug, but the outcome was a bit disappointing. Long story short, it's a timing issue. The ARM9 starts wifi initialization and allows it about 44 milliseconds before deciding it has failed. The wifi initialization doesn't actually take this long, but on a DSPhat (or any console equipped with a type 2 RF module) the RF initialization includes an extra delay of 40 milliseconds. Changing the ARM9 cache timings fixes the bug.

Cache emulation is something we're looking at for the next release, as it may fix quite a bunch of these timing issues -- there have been preliminary tests and it's looking promising. But in the meantime, that particular bug goes beyond my scope.


No biggie, we have a plethora of other problematic games. In particular, I had gen4 Pokémon games in mind. In these games, players can meet into the Union room where they can decide to chat, battle, etc... but the Union room was said to be malfunctioning in melonDS if more than two players were in it.

I first ran into some 'easy' bugs. For example, melonDS would not generate different MAC addresses for extra instances when using an external firmware. I also had to obtain different savefiles -- the game will get confused if multiple players using the same save file try to connect.

Past that, I figured that the issue might be caused by the lack of wifi channel support in melonDS. You probably know about wifi channels: the 802.11 standard specifies a set of 14 channels, which correspond to specific frequencies.

... read more
12 comments (last by shmi) | Post a comment
Pages:12345678···21