melonDS RSS The latest news on melonDS. melonDS 0.9 is out! -- by Arisotura Fri, 04 Sep 2020 12:14:06 +0000
And it's big.

So, what are the highlights of this release?

- JIT recompiler

Brought to you by Generic (aka RSDuck), the new JIT recompiler enables melonDS to run much faster, and quite often reach fullspeed even when emulating DSi titles!

There are a few settings you can try out to get the most out of this JIT. While it has been heavily tested and worked on, it's still imperfect.

- DSi emulation

This is the other flagship feature of this release: melonDS now emulates the DSi!

You will need a NAND and firmware dump from your DSi, as well as augmented BIOS dumps (such as those that NO$GBA requires). The following BIOS dumper can dump the required BIOS files from a homebrew-enabled DSi.

Do note that this is still experimental. For one, direct boot will not work under DSi mode. Not everything is running yet, either, but we're getting there. melonDS does not yet emulate some hardware like the DSi cameras (but on the other hand, emulates DSi wifi).

melonDS has a small hack to bypass the region check. However, DSiware titles can't be run standalone yet, they will need to be installed to the NAND.

- GBA slot support

melonDS now supports loading a GBA ROM to simulate having a cartridge in the GBA slot. This is done by selecting a .gba file while your game is running. Note that we don't support emulating the GBA in any way.

We also support the Boktai solar sensor addon. Support for more addons is planned.

- New Qt UI

This means we get to do more without needing to work around the limitations that libui had. For the end user, this also means a bigger binary, but on the other hand, on Windows, all the dependencies are linked statically, so melonDS does not come with external DLLs anymore.

The new interface adds features that were long requested: for example, you can open the emu settings dialog to point melonDS at your desired BIOS/firmware/etc files, without needing to move/rename them around.

- Cheats

This is another popular request, and here it is. melonDS lets you enter Action Replay codes to mess with your games in whatever ways you want.


melonDS now supports letting homebrew access files and directories on a SD card image. Note that for now, you will need to provide an image file, melonDS does not yet build such images on the fly like DeSmuME can do.

Similarly, you can also use a SD card image to emulate the console's SD card in DSi mode.

- and the rest!

As usual, there are plenty of little improvements with this melonDS release, that are too many to list here, but you may discover them on your own! Or find them in the changelog (which we are still busy compiling - it's a big release).


melonDS 0.9, Windows 64-bit
melonDS 0.9, Linux 64-bit

If you're feeling generous: here's our Patreon]]>
Getting there... -- by Arisotura Thu, 03 Sep 2020 13:12:53 +0000

I'll let you guess ;)]]>
Messin' around with the GL renderer -- by Arisotura Wed, 19 Aug 2020 13:52:17 +0000
Also, if you ever wondered why progress is slow: an emulator project is like a tree in that once you're done with the trunk, it branches off in a billion different directions. At this point, melonDS is too big to be a one-man show. There are a few people working on it now, but there's only so much we can do with our time and motivation.

Anyway, while Generic is busy polishing the JIT, I figured I'd go around and try fixing some of the issues on the issue tracker.

This one, Deformed floor textures in the Celestial Tower (Pokemon Black/White) (OpenGL only), is an interesting problem. The base issue is that, if you happen to remember, the DS can draw quads natively, while modern GPUs can't. Actually, it's even worse: clipping on the DS cuts through polygons but doesn't create more polygons, which means that you can end up with a maximum of 10 vertices per polygon. For example, a triangle that sticks out of the view volume can become a quad, a pentagon, or more.

The base issue here is faulty rendering of these polygons that have more than 3 vertices. The DS employs a scanline-based convex polygon renderer, so it doesn't care how many vertices your polygon has. Software renderers used in DS emulators use similar filling algorithms, so no problem there either. However, when you use OpenGL, it's another deal entirely -- modern OpenGL-compatible GPUs are very good at drawing triangles, but... that's about it.

So, what do you do when you need to render a quad? Easy, split it into two triangles!

Suppose the quad below.

All fine and dandy. Now we split this, like this:

You can notice that, compared to the original quad, it looks distorted now. Maybe if we try splitting it in the other direction?

... well, yeah. There's only so much we can do with this.

Enter Arisotura. I've always found this to be an interesting problem, and had a few ideas to alleviate it. There isn't going to be a perfect fix, short of implementing custom interpolation somehow, but we can try to reduce the distortion by dividing these polygons more. We can't overdo it either, lest it kill performance.

A simple way to do it is the following:

It's still not perfect, but somewhat better. Keep in mind that this is an extreme example to show the issue at hand. In real-world cases, polygons are going to be smaller, and the distortion generally more subtle.

Speaking of which:

The polygon right under the bridge is a quad and exhibits the issue we're talking about. For reference, here's how it looks with the software renderer:

So I tried implementing the polygon splitting algorithm shown above. The idea is simple: find the center of the polygon, calculate the color/texcoord/depth attributes at that point, and create triangles around it. In practice, it isn't always easy to get these things working.

Once the bugs were fixed, it started looking more promising.

Not perfect, but it looks much better this way.

Still got some testing to do, and considering whether I should add an option for this, but I'm confident this will make it in 0.9. We have been neglecting the OpenGL renderer since the day it was created, it's more than time to give it some love.]]>
maxmod fixes -- by Arisotura Thu, 23 Jul 2020 11:33:35 +0000
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.

Thing is, at this point, for each channel, SOUNDxCNT is initialized with the start bit set, and before the other channel registers are set (because SOUNDxCNT comes first). This messed with the way melonDS initialized its channels, because it expected everything to be ready by the time the SOUNDxCNT start bit is set. But, obviously, here, it wasn't the case, and most things being zero fucked everything up.

So I quickly revised melonDS to only perform channel initialization as soon as the channel can actually run. And, hey, that did the trick -- maxmod's interpolated mode sounds fine now.

That being said, I still want to check for any tests that use the unimplemented capture/output modes.]]>
hi -- by Arisotura Thu, 25 Jun 2020 04:22:05 +0000 The new wifi adventure -- by Arisotura Sun, 21 Jun 2020 16:19:18 +0000

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.

The DSi uses this new wifi device when connecting to the internet (local-multiplayer type connections use the old DS wifi device).

Alas, due to being a few years late to the party, there isn't much to do anymore. You can try using the DSi browser, but it won't be able to load a lot of websites successfully due to how limited and outdated it is. This site works fine... somewhat.

I was also able to update my emulated DSi to the latest firmware version, 1.4.5E. It doesn't do much, but it's working without issues, so there's atleast that.

Connecting to the DSi Shop gave me some weird undocumented error code. The logs showed that it was trying to use AES-CCM encryption, which was unimplemented. As I had already taken care of CCM decryption and verification, I could implement encryption quickly. Then I was able to access the Shop, from which you can download the 3DS transfer utility, and, well, nothing else.

Atleast these features are emulated, in case this can help spark new initiatives in the field, akin to AltWFC. Although things like custom DSi Shop servers would pose obvious copyright problems, unless they only distributed homebrew...

Regarding the old libpcap-powered direct mode, I'm thinking of retiring it. Perhaps not for 0.9, but later for sure. It might stick around for debugging purposes, but it has little advantage for the average joe if libslirp works just as well and is more flexible and easier to setup.

Regarding directions to take now, I have several ideas.

An interface for editing firmware settings. We could atleast make it work for DS mode. It would also allow you to change the console's MAC address, mostly to make up for the fact we're removing MAC randomization.

We also need some FAT library that can access files inside a FAT image. One of the purposes would be accessing the config files inside the NAND (which, below the encryption layer, is mostly a FAT filesystem), so we could edit the DSi-mode firmware settings too. We could also patch the touchscreen calibration data, like we do for DS mode (might also make that feature optional?).

Being able to generate a FAT image from a given folder, and maybe reflect changes to the actual files, would be perfect for things like the DSi's SD card, or DLDI. Not sure what is possible there, but we'll see.

I also need to finish the cheats feature. Dammit, considering all these things you see are popping up because I'm procrastinating on that.

Either way, this has been a fun ride.]]>
BAAHAHAHAHAHAHHHH -- by Arisotura Sat, 20 Jun 2020 23:18:46 +0000

melonDSi has been merged -- by Arisotura Tue, 02 Jun 2020 02:15:44 +0000 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.

* Direct boot is not supported yet under DSi mode.

* The current DSi emulation is more or less a base. Cameras, DSP, new wifi, etc... aren't supported yet.

* There is a hack in place to bypass region locking.

* DS games loaded via the DSi menu run in more-or-less-DS mode. Right now, some details like clock switching or RAM size aren't supported. Most games seen to run fine under these conditions, but some may run into issues.

* If you want to try out DSi support, I recommend that you keep a backup of your NAND dump.

* Savestates are not yet supported.

Next up is the JIT merger, Generic will keep you informed about that!]]>
#BlackLivesMatter -- by Arisotura Sat, 30 May 2020 13:30:34 +0000

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 -- by Arisotura Thu, 21 May 2020 19:20:04 +0000

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


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.

We thought about this for a long while, and in the end, went with Qt for the new UI. I have concerns about this, but I'm hoping for the best.

So how is the Qt adventure going so far?

Pretty good. Qt is fairly nice to work with. The new UI is almost on par with the old one, and in some ways it's better. You can see the progress in our git, in the qt branch.

At the time of writing this, the big things that still need to be taken care of are OpenGL support and the wifi interfaces. And, of course, building an UI for the cheat engine I wrote in February.

There will also be the whole issue of packaging this all up, especially on Windows. The current Qt builds require no less than 25 DLLs. Compare that to the measly 4 DLLs the libui versions came with... We'll need to look into static linking to avoid this madness.

I also want to look into providing Mac builds. Will probably involve installing an OSX VM, sounds like a lot of fun.

As for the rest, I'm keeping some surprise on the upcoming 0.9 features :)]]>