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, ...)
• OpenGL renderer, 3D upscaling
• RTC, microphone, lid close/open
• Joystick support
• Savestates
• Various display position/sizing/rotation modes
• (WIP) Wifi: local multiplayer, online connectivity
• and more are planned!









Download melonDS

If you're running into trouble: Howto/FAQ

If you're feeling generous: melonDS Patreon
maxmod fixes
Sorry for the silence lately -- these times are getting pretty busy. melonDS wise, we're trying to perfect the JIT and the few other things we want for the 0.9 release. Real life wise, on my side, I'm starting the procedure to get my gender marker updated, which is going to be the last big thing for my transition.

Anyway, just yesterday, asie told me that maxmod's interpolated mode was broken in melonDS, which piqued my curiosity.

What's maxmod, you ask? It's a real fancy audio library for the GBA and DS. I don't know much about the GBA side of it, but on the DS, it supports three modes: hardware mode, interpolated mode, and extended mode. Hardware mode is fairly straightforward. Interpolated mode resamples audio on the fly, applying interpolation to make up for the lack of hardware interpolation. Extended mode does its own mixing, adding support for more channels than the hardware can offer.

In our case, interpolated mode was broken, outputting pretty much short high-pitched beeps and nothing else. I was curious to see if maxmod used any of the fancy audio capture/output modes that melonDS doesn't support (because no commercial game uses them, and my policy is to avoid implementing things until I have test cases). melonDS is set to report if any such features are being used, but in this case, it didn't report anything out of the ordinary. So this meant I'd have to dig further.

Quick regression testing showed that interpolated mode worked okay-ish on melonDS versions prior to 0.6. Well, it didn't sound as it should, but it was atleast reasonably close, instead of just being high-pitched beeps.

So apparently it was completely broken when sound FIFOs were implemented. The FIFO logic was fine, but the addition of that feature worsened the consequences of a bug that had always been there.

I logged what was going on during playback, to try and figure out where it failed. It appeared that the data being fed to the audio channels was fine, but, for whatever reason, the channels themselves failed to actually pull the data from memory. More logging revealed some strange things, like how certain things started at zero when they shouldn't. Notably, the channel timers started at zero, when they're supposed to start at the SOUNDxTMR reload value. But also, the FIFO level started at zero, causing it to immediately go negative and break the FIFO filling logic.

For a while, I scratched my head at all that, until it finally clicked.

In interpolated mode, maxmod will first disable the mixer, then sequentially initialize the channel registers, then enable the mixer, letting all channels start in perfect sync.

... read more
hi
I got the surgery. I am alive and well. Thank y'all! :)
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