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
The new wifi adventure
I'm doing this while waiting for my surgery, which will be in 3 days. So, a bit more about yesterday's screenshot.


Basically, it all started with a new branch called slirp. What's that, you ask, another of Arisotura's oddball noises?

Nah. If you followed the melonDS history, you know that a while back, support for internet connectivity was added. It was pretty similar to how DeSmuME did it back then: providing a basic emulated access point to connect to, then forwarding outgoing traffic via libpcap.

While it was straightforward, it had its lot of issues: it required installing libpcap (or any Windows equivalent), required admin/root privileges, and, more annoyingly, did not work over wifi connections, as explained here.

Eventually indirect mode (aka LANMAGIC) was developed to get around this. The basic idea was to emulate a local network and use simple BSD sockets to forward outgoing traffic to the host network. The idea was good, but the actual implementation was more or less a pile of hacks that never really worked right.

Enter the slirp branch. Basically, QEMU's libslirp does exactly what LANMAGIC clumsily tried to do.

So I reimplemented indirect mode using that. Took a while to figure out how to use libslirp, as it isn't really documented, but we got there, and it works beautifully.

More notably, this is how we like it. Unlike direct mode, it requires no setup, it Just Works™. Over any sort of connection, without any special privileges, ...


Then I got carried away and began implementing features of the DSi's new wifi device. From there, you can see how this ended.

... read more
BAAHAHAHAHAHAHHHH


:)
melonDSi has been merged
melonDSi started last year as that clunky DSi experiment branch. Over time, it became more capable, but it still felt really crusty. It was basically stuck in DSi mode, hardcoded all around, didn't work that well, and was based off what became an increasingly obsolete version of melonDS as it was put on the backburner in favor of other fronts.

But that is past now.

I wanted to get it ready for the JIT merge, so I set to work. First off was merging recent melonDS into it, which went smoothly. It was a great sight to see the DSi menu come to life inside the new Qt UI.

Then, in a couple days, the SD/MMC issues were fixed, such that for example Flipnote can now save without softlocking. I then decided that would be a good base, and cleaned it up. Basically, I de-hardcoded it, allowing it to switch between DS and DSi modes, changing how DSi-mode assets are loaded, all that.

And now, there it is, DSi support is part of the master branch.

Couple notes on this:

* It was reworked to require less files. Namely, aeskeys.bin, initmem7/9.bin and boot2_7/9.bin are no longer required. However, it now requires 'augmented' BIOS dumps, the same ones that NO$GBA requires. I intend to provide an appropriate dumper.

* The location of the BIOS/firmware/NAND files can be configured.

* It is able to run both DSi and DS games from the menu. For some reason, some will fail to load, giving that error screen.

... read more
#BlackLivesMatter
You may be aware of what's going on in USA. I'm not going to go in detail over this, but I'm going to state that I stand with the protesters. For the end of racist policing, for the end of capitalism.


Other than that, little status update on melonDS. We're going to merge the JIT branch for 0.9. I figured that it would be easier to merge the DSi branch first, so I've been updating it. I'm going to clean it up some and fix a few things to make it good for a release.

The Qt UI is also nearly complete. All that remains to be done is the cheat interface and taking care of VSync. The other issues have been solved, including the one where the final executable required 25 DLLs -- by using the qt5-static package for MSYS2, I managed to get it down to a standalone executable that is about 21MB in size.
Sneak peek of melonDS 0.9
There's not going to be any fancy screenshot here, simply because there isn't much that is worth a screenshot. However, I figured I'd give a little status update, because it's been a while. There's been a lot of work done so far, and we're not done yet.


So, first of all, the whole 'new UI' adventure.

Again.

At this point, it's been what, four total UIs melonDS has had, counting the one being made.

The very first one didn't even see an actual release. Can't even really call it an UI, it was nothing more than a bare window using the Win32 API directly, along with some hardcoded input mappings, that just served to help me get the emulator core going.

Obviously, it was specific to Windows, and I wanted melonDS to be cross-platform, so it was thrown away. I didn't want to have to maintain separate frontends for each OS, so using a cross-platform UI toolkit was a must. I wanted something that was relatively lightweight, and if possible, used native widgets instead of reimplementing them.

Thus, the 0.1 release came with a wxWidgets UI. Due to not being able to make wxWidgets and SDL interoperate smoothly, the UI was a clunky mess that came in separate windows. But atleast it was more user-friendly, and worked under Linux.

The wxWidgets UI was eventually retired with the 0.5 release. I went with libui, which was small enough that I was able to modify it to meet my needs. The new UI even had several improvements over the previous one. libui's design was not optimal, but it was good enough for what we wanted, so we built upon it for the next releases.

Fast forward to now. As you might have read in the previous posts, we've been wanting to add new features to melonDS, but found that libui lacks support for what we need. We didn't want to spend forever building upon libui, so we decided it was time, after more than two years of service, to retire the good ol' libui UI.

... read more
We're alive!
I know things are slow lately, but there's still some shit getting done! Mostly taking care of low hanging fruit.


For example, I felt like dealing with issue #598. Which was the same problem as the older #379, by the way.

The base issue was that some polygons ended up sliiiightly offscreen (getting a lower Y coordinate of -0x1001 when the view volume bound is at -0x1000, for example). Not an issue with how coordinates are calculated, mind you. On the DS, polygons can be slightly offscreen like that and be clipped without any issues. But in the case of melonDS, due to how clipping was done, the texture coordinates of the vertices that stuck out would end up altered, resulting in a misaligned texture.

Ironically, using OpenGL appeared to fix the issue, but only because the way OpenGL applies textures is inaccurate to the DS hardware (which in itself causes a bunch of other texture alignment issues). So in the end, the two issues compensated eachother for a visually perfect result.

The software renderer, on the other hand, aims at replicating the original DS renderer as closely as possible, which in the end makes it more sensitive to little details like this.

Regardless, looking at the formula melonDS uses to clip polygons that are partly offscreen, it appeared that swapping the inner and outer vertices gave results closer to what the DS produced, so I did exactly that, and it ended up fixing the aforementioned issues.




So, one step closer to pixel perfection, I guess. Even though we aren't quite there yet; you might notice that the screenshot from Brain Puzzles are exhibiting another glitch that wasn't fixed.


Also, I finally took care of properly handling ROMs with encrypted secure areas (which is the case of the Virtual Console dumps, for example). Before, those could only be run by doing a full firmware boot, now they can be run via direct boot without issues.

... read more
Chaos ahead
Well.

I guess that within the current situation, I owe you a post to keep you informed on things.


We're envisioning FLTK for a new UI, but I have yet to give it a try and see whether it would be a good fit for melonDS given how it works.

Motivation is at a low here though.

But, to give you an idea what to expect: given the scope of what we are developing, we're aiming straight for a 0.9 release.


The IRL situation isn't helping things. You might be aware of the coronavirus. We at the Melon Factory of Kuribo64 are fine for now, but the pandemic is growing, and with it, a set of heavy consequences.

After underestimating the virus for a while, France is finally taking confinment measures.

That may slow things down regarding the plans I have IRL, like, my attempts at getting a decent job.

What worries me more than the coronavirus, though, is the ongoing economical crisis. Markets are crashing and I guess it's not a good thing. It all seems abstract for now, but sure enough, in a while we will begin seeing concrete effects to this. Like, I don't think this is the best time for getting a job, but it's also going to be a mediocre time in general for the smallest and most vulnerable.

So, I'm keeping a close eye on all that. Worst case would mean I'd have to take immediate action to avoid going bankrupt and ending up homeless. Probably ending up in some squat.
well, shit
As I decided to continue working on the new cheat system for melonDS, I devised a simple binary file format that melonDS will use to store cheat codes and associated metadata. Nothing terribly difficult.

Except then I need to properly design my basic blocks (AR code list parser thing, AR engine, etc) so that they can be interconnected nicely.

Which is where I began thinking about the kind of interface I would need for entering cheat codes.

And...

Uh oh.

libui doesn't support the kind of controls I want to use.

Generic has been thinking of a kickass debugger UI and running into the same issue.

So... it's time to take a decision here.

We haven't taken a decision yet. Basically we need a good UI toolkit, that, ideally, is lightweight yet well-featured, modular (so you don't need to embed a complete behemoth if you aren't using everything), uses native UI controls, supports drawing areas and OpenGL...

... read more
By popular request


You guess.


I'm not forgetting about the OpenGL work that was started, either, but I really needed to work on something new to get some motivation back and not let melonDS die.

Also, our comrades RSDuck/Generic and Chagall have been working on some pretty rad shit too. We're coordinating to unite all that nicely for an epic release eventually.
New melonDS feature: GBA connectivity
Hi everyone, I'm a new contributor to melonDS, Chagall on IRC and rzumer on GitHub. Being a fan of the melonDS project, I wanted to contribute something to it, and my most wanted missing feature being GBA connectivity, I spent a few weeks on and off implementing it.

This feature is mostly used in DS games to grant bonuses to players who own specific GBA titles. For example, inserting a GBA Ace Attorney game and launching the DS version will unlock all cases in the remake. Some games go further and read/write save data from/to the GBA cartridge (as in Pokémon games), or in one case polls its I/O port (Lunar Knights/Boktai DS).

All these features are now integrated in the master branch of the melonDS git repository. As far as I'm aware, this makes melonDS the first emulator to support solar sensor emulation in Lunar Knights. The video below demonstrates using the Solar Sensor item in Boktai DS with Bokura no Taiyou in the GBA slot.



Of course, you can also send your pocket monsters from GBA to DS, as demonstrated in this video:



As on real hardware, the GBA save file is modified during migration as the Pokémon are moved to the DS game:



Thanks to endrift of mGBA for the solar sensor emulation code that I used as a primary reference, and to DeSmuME authors for the GBA cartridge Flash save read/write logic that helped a lot with supporting the Pokémon games. Martin Korth's GBATEK document was also a great general reference.

... read more