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
melonDS 1.0 RC, there it is!
melonDS 1.0 RC, there it is!


We have finally released a brand new version of melonDS: 1.0 RC.

A bit of a disclaimer about this unusual version number: due to the large number of changes since 0.9.5, this version is a Release Candidate. We have done a thorough round of testing and bugfixing, but there is always the chance that further issues went unnoticed. This release will be the occasion to catch them and fix them for the actual, proper 1.0 release.

Now, the biggest changes this release brings:


Core refactor

This is the biggest change by far. We have undertaken a large and ambitious refactor of the melonDS core, in order to make it possible to run multiple instances of the emulator within one single process.

What does this change mean for end users? It means that local multiplayer is easier to deal with, since we no longer have to deal with inter-process communication. It also means that depending on your platform, local multiplayer may be more performant now.

However, much like in 0.9.5, this multiplayer mode only works when running multiple instances on the same computer. But we have another ace up our sleeve, which we'll see next.

It's also worth noting that this refactor was partly motivated by the idea of adding netplay support. While I haven't been able to get netplay working yet, the refactor has laid a very important foundation for it. We'll get there, eventually!

... read more
Happy birthday melonDS
melonDS is 8 years old now. Thus, here's the appropriately colored logo for this event:



We have to a point where, well... You guess it, it's been two years since the last proper release.

melonDS has become quite a large and complex project, with many moving parts. I compare an emulator project to a tree: when you're done with the trunk, it branches off in a billion directions. That's pretty much it.

We have been through a pretty big refactor of the codebase, and that comes with its lot of issues, doubts, and so on. Was the refactor a mistake? What could we do better?

One of the major selling points was the development of netplay. Unfortunately, that's not the first time I have big ideas, big ambitions, but fail to concretize them. That's ADHD for you.

In a way, I'm also afraid of netplay. It feels like a bit of a Pandora box. I mean, it has potential for being a very cool feature, but also for being an endless source of issues. Dealing with the wifi connection issues for so long has given me a glimpse of it already. As a matter of fact, solving interesting problems is something I'm good at, but user support is not. I've had a bit of a similar experience at my last job, too.

Regardless, I still consider melonDS to be a great success.

I might try netplay later if I feel like it, but for now, I'm burnt out on that stuff.

... read more
Public service announcement
Lately, we have seen more and more people asking us about the site at melonds.org, so I feel compelled to write a post to clarify the situation.

That site is a fake site.

It is part of a larger network of fake emulator sites (like desmume.com) that only exist to leech SEO traffic and confuse users.

The only real melonDS website is the one you are currently looking at: melonds.kuribo64.net.


What can we do?

I intend to add a splashscreen to melonDS with the URL to this site, to make things clear. The URL is also printed in the console, but since melonDS release builds don't really come with a console window anymore, well...

Other than that, spread the word, so people don't get confused.

Also: it appears that Bing (and by extension DuckDuckGo) has decided that melonds.org is the legitimate site, and has removed our site from their search listings.

So, if you can, help us fix that. Report the fake site to Bing or DuckDuckGo.

... read more
Future of melonDS
Hello there. There hasn't been a whole lot of melonDS related activity lately.

I've been completely caught in a different, but fun project. If you have seen my Github lately, you might have an idea what it's all about. It's actually an idea I've had since 2016: hacking the WiiU gamepad to run custom code on it, and trying to figure out what kind of cool things are possible. I made attempts back in 2016 and 2022, but never really got anywhere. However, 3 months ago I felt like making a more serious attempt (namely involving a FPGA board) and actually managed to get things done. I kinda want to make a non-melonDS blog to talk about that kind of projects, too -- there would be a lot to say. This project is really challenging and intellectually stimulating, which is all I love!

Anyway, I digress.

melonDS.

I still need to finish fixing the bugs before we can release 1.0. I hope I'll manage to get myself to get there, given the way my focus and motivation works.

First, thank you all for your kind comments! It means a lot.

Next, the plans. As I mentioned before, I want to take a big break from melonDS after releasing 1.0. melonDS will be 8 years old, and that's a lot, especially for a project of mine. It has been a very good project and I've had a lot of fun, but I think I need to do other things for a while.

However, melonDS isn't going to go dead.

You might have noticed that Jakly has been contributing a lot of accuracy improvements to melonDS. The amount of research she has been putting into things like the 3D rasterizer, or lately the ARM CPUs themselves, researching all the weirdest quirks and trying to emulate them, has been astounding. Better than even I have done years ago.

... read more
Some news...
Uninspired title huh.

Anyway, thank you all for your kind comments, it means a lot!

I haven't been working much on melonDS lately, mostly been relaxing by working on another personal project.

As far as melonDS is concerned, my plan is to release version 1.0 by November, ideally around the project's birthday. It is going to be 8 years old, by the way. I am amazed that it has been going this far.


So here's a quick list of the things that need to be done until then:

Implementing the multi-window feature. It shouldn't be very difficult, I had already coded the required support a while ago. It's mostly matter of integrating it into the UI and ensuring everything works correctly.

Fixing up the JIT to work with multiple instances. Generic is the JIT expert over here, so that'll be for him to deal with.

Maybe fixing up LAN, if I ever manage (and if I feel more motivated to work on it).

Fixing all the issues that have cropped up during the big refactor. There's also still a bunch of code cleanup to do. We will also need a bunch of testing and QA to make sure the 1.0 release works as intended.

... read more
Netplay will be postponed
It will not be part of melonDS 1.0.

The scope of this feature means it requires more development and testing time than I would be able to do before November.

You can tell I was in a really active period. I'm trying ADHD meds, again. They work, but I overestimated things, and I burnt out.

The recent wifi stuff was the straw that broke the camel's back, I guess. I mean, why did I spend so long implementing the powersaving stuff, channels, etc, in the first place? That's right, I was trying to fix games that had trouble connecting. I thought I had figured it out, I had a fix that worked well for me, but then I kept getting reports that it wasn't working. I did more of the same a few days ago, once again thinking I had a decent fix, and nope. Only makes things slightly better, or doesn't make any change. This feels utterly defeating. Like nothing I do will ever fix it.

It's kinda like when I make posts about my difficulties and all I get in the comments is "can you add feature X" "can you fix Y". I'm not a programming robot, you know.

I'm burnt out, I guess. I want to put out melonDS 1.0, but I need a big break from melonDS.
Wifi: when better emulation makes things worse
After LAN was merged, I was informed that it wasn't working as smoothly as the old season2 branch. In particular, it was harder to get a connection going in a game.

I didn't quite know where to look. The LAN interface itself functions the same way as its season2 counterpart. The only thing I could think of was the improvements that we'd done to wifi emulation since season2.

I fired up my other computer and gave LAN a test. I had to do a bit of setup to get both computers connected over ethernet, since wifi has too much latency. But then I observed the same thing that had been reported to me: I could sometimes get a connection going, but it had a high failure rate.

To further confirm it, I even happened to get a connection failure over local multiplayer. It was just a lot less likely there.

When logging the wifi traffic, I observed something peculiar: the client would send a 802.11 authentication frame and receive another authentication frame from the host, then it would send an association frame, but at that point the host had entered power saving mode. It would only leave power saving mode a lot later, and that was too late.

The LAN interface does something a bit particular: due to how it functions, it may receive frames at any time, and these are added to a receive queue to be consumed where needed. To avoid clogging up that queue, frames that are more than 16 milliseconds old are considered stale and are deleted. This should normally be more than enough: when the wifi system is active, it checks for incoming frames fairly often, that is atleast every 0.5 milliseconds.

I could see how this was a problem in the aforementioned case, but raising the 'stale frame' threshold as far as 500ms did not fix the problem. So I had to approach it differently, namely, by considering how things work in wifi land.

The host sends beacon frames every ~200 milliseconds, to advertise its presence to potential clients. A client that wants to connect will then initiate the process by sending the host an authentication frame after receiving a beacon, and so on. The authentication+association exchange is aligned to beacon frames, and that is important.

The host uses power saving mode between beacons. The basic process is as follows: send beacon frame, wait for a while to see if any clients want to connect, then enter power saving mode until next beacon. There is a timer (W_POST_BEACON) that determines how long to wait before entering power saving mode. It is typically set to 10 milliseconds or so, which is more than enough for an authentication+association exchange.

... read more
LAN: finally merged!
As promised, LAN multiplayer is mostly finished, and a first version of it has been merged. This feature was already largely functional, so all that was needed was to backport it to the modern melonDS codebase and fix up the UI side of it. We can also thank Nadia who provided great help fixing up the ENet integration.

You may now grab it over at Github, in the Actions tab (you will need a Github account).

The way this works is the same, so I will simply copy-paste from that old post:


How to get a LAN game going:

1. On the host machine: open melonDS, then System -> Multiplayer -> Host LAN game. You enter a player name and you're good to go.

2. On client machines: open melonDS, then System -> Multiplayer -> Join LAN game. Enter your player name there, then it should list any existing LAN games. If not, you can always try using the direct connect button.

3. Once all sides are connected to the LAN game, you can open a ROM on each machine and try getting a game going. Do note that you will need a good local network for this to work. Ethernet should work, but anything else may fail if the latency can get too high. In my experience, wifi has too much latency.


This marks the end of season 3, and the beginning of season 4: netplay. Ironically, netplay was the original goal of season 2 -- LAN happened more or less as an experimental side project, and it happened to work out rather well, so it stuck around.

So, stay tuned for the netplay adventures!


Also, we are working out how to properly label melonDS builds from the CI, releases and nightlies alike. When we figure it out, I will probably add the download section for nightlies.
Updates to the downloads section
I have been making updates to the site lately. About time.

Namely, the downloads page didn't do our project justice. It was just a very plain listing of all the melonDS releases since 0.1. Technically, it was a static page that I manually updated after each release.

But this is no more! Go check out the new downloads page.

Now it shows just the last melonDS release. However, if you go down, there is an extra page that will list all the older releases, just like the old download page. Except it's not a static page, so new releases can be added without having to modify everything by hand. I am even thinking of adding a Github hook to post releases automatically when they are posted there, but one thing at a time.

There is also another section named 'Misc. tools'. For now, there's nothing in it, but I plan to add all sorts of tools that are relevant to melonDS or DS emulation in general. For example the DSi dumper comes to mind -- there would be a stable place to get it rather than having to dig into the blog. I will probably add that in real quick.

(edit- I did; after 3 years, about time)

And there's a last section, that isn't finished yet: nightly builds.

The idea was to provide access to builds from the Github CI without requiring users to have a Github account. I coded a Github hook and a backend for it, which downloads the builds from Github onto the server, and keeps the last 100 commits. However, this raises a few questions.

We need to make sure nightly builds don't spread and cause confusion. Right now, any melonDS build just uses the same version number as the last release, which isn't ideal. We would need a way to properly identify builds to avoid confusion.

... read more
LAN: almost done!
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