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
• (WIP) GBA slot add-ons
• and more are planned!

Download melonDS

If you're running into trouble: Howto/FAQ
The local multiplayer saga, ep 7
At this point, we should have this published on Netflix or something :P

In the previous post, we saw that we had lag in some games because the client was sometimes not replying, so I had to deal with that issue.

I introduced the new local-multiplayer data exchange/sync mechanism in ep 2, and since then it has seen several iterations as I made it simpler and more efficient.

For one, I used special-purpose microsecond counters for this instead of relying on USCOUNT. The first issue there was with that was that USCOUNT can be disabled or modified at any time by software, which isn't ideal if we're going to rely on it for sync purposes. Second benefit is that now, when a client connects, I can just sync up its counter to the host's, and not have to deal with any offset between the two. So, all in all, it's more reliable this way, and a lot easier to deal with.

Next change was that I got rid of the specific 'sync point' messages and simply attached timestamps to packets. This reduces the amount of data being exchanged, and let me simplify the sync mechanism too. Now, when receiving a packet from the host, clients know when to actually start emulating reception of that packet, and how long they can keep running on their own before having to wait for another packet from the host. This way, clients can't run too far ahead of the host, and we also ensure the host doesn't run too far ahead by dropping any replies that are too old. All in all, this system is more efficient.

Lately, I also reworked how replies are dealt with, to make things more efficient and reliable, and to deal with the issue at hand in this post. Replies go through a separate FIFO, and instead of being broadcast to everybody, they're only received by the host, which mirrors the way local-multiplayer communication works in real life.

To deal with the problem of clients sometimes not being ready to reply, I simply made clients send a blank if they receive a CMD frame they can't reply to. The blank is a frame with no data, that the host ignores -- it's just there so that there is something to receive, so that we don't hit the timeout.

A problem with this system is that it won't function well if there are two or more concurrent local-multiplayer games running on the same computer, but I don't think that's a use case we need to worry about.

Anyway, this isn't perfect yet, but the results are encouraging. Tetris DS and Mario Kart DS connect with no hitch now, so that issue is dealt with. However, I'm noticing some regressions. For example, NSMB minigames won't connect: I immediately get a comm error screen on the client. I looked into it quickly, and found out that the client is doing weird things (like occasionally setting RXBUF_RDCSR to 0x05FE, which doesn't look right), but I need to look deeper into it. It's possible that the issue was always here but was less apparent due to the different way of doing things. I have also seen some occasional slowdown in NSMB and Mario Kart, so that may be related.

Oh well, we'll get there. It's getting close at this point.
The local multiplayer saga, ep 6
For melonDS, there are three horsemen of apocalypse. Over the years, we have been able to deal with nearly everything the DS has thrown at us, but there are three main categories of long-standing issues: timing issues, precision errors in the OpenGL renderer, and local multiplayer.

And I certainly did deal a blow to that horseman back in 2017 when a working local multiplayer connection was emulated for the first time, but of course it wasn't going to be all. While the connection worked, it was always finicky, and getting it to work was a bit like voodoo magic. After melonDS 0.4 was released, melonDS changed from being a mere curiosity to being 'the wifi emulator', and many people came in for that feature. And we just kept telling them to disable their framerate limiter, pray, sacrifice a goat or two to the wifi deities, and hope things will work.

It was certainly substandard for melonDS. One of the main reasons why it stayed that way for long was, besides having to work on other fronts, that it was a precarious position of equilibrium. Any attempts at improving wifi emulation resulted in a more unstable connection. I thought it would take an overhaul of how the connection is emulated to make it work reliably, but I always had that fear of putting much time and effort into it only to get terrible results, so the status quo was maintained. But you know how it is: when making your emulation more accurate gives worse results, it means you're missing something else. After 5 years of business, we're no stranger to this.

So what does it take to beat the horseman of wifi? Two things: a stable, reliable medium of communication, and reverse-engineering of the DS wifi hardware, which is full of fun little details that sometimes matter a lot.

But, of course, it's not going to go down without resistance. It's a horseman of apocalypse. It will put up a fight at every stage.

Lately, we got to a point where local multiplayer connections are pretty stable, and it's possible to reach decent speeds on good hardware. For reference, my 2014 laptop Crepe can run New Super Mario Bros. MvsL multiplayer at near-fullspeed with the JIT on. I'm confident that any decent computer will be up to the task when we're done.

But, of course, that's with well-behaving games, where everybody sends their packets as they should and everything is good. While we were testing other games, it appeared to us that there are... cursed games. Tetris DS and Mario Kart DS, for example, have exhibited intense lag while trying to get a multiplayer game going.

I looked at what was going on in Tetris DS. The lag is caused by the host hitting the timeout when waiting for incoming client replies, because sometimes the client isn't sending any reply at all. It was egregious because I set the timeout to a ridiculous value (500 milliseconds) to make sure everything would get through reliably. A lower timeout reduces the lag in this situation, but also increases the chance of missing incoming packets when we need them, so this is essentially a compromise (we might end up making the timeout user-configurable).

But, why are we not receiving replies from the client to begin with? In a previous post, I have mentioned that the DS, when it acts as a multiplayer client, always replies to CMD frames, even when no reply frame is configured, and melonDS emulates this behavior too.

... read more
The local multiplayer saga, ep 5
It keeps going!

Lately, I have been working on faster IPC, so I could get a more accurate idea of how much it would take to emulate local multiplayer at acceptable speeds, and whether my ideas were feasible at all. First order was getting rid of the old inefficient BSD sockets.

Instead, I built a data exchange system based on shared memory. The idea is simple: have a large block of memory shared between all melonDS instances, where you have a FIFO buffer for exchanging wifi packets, another FIFO buffer for exchanging sync points, and a small header containing some useful status bits. Then each instance has a set of semaphores that other instances can use to signal when new packets or sync points are sent. All fine and dandy.

I figured this would be easily taken care of, with QSharedMemory and QSystemSemaphore. And I ran into my first issue: QSystemSemaphore sucks. Basically, it isn't possible to wait on a QSystemSemaphore with a timeout, which means that waiting on it will block until it is signaled. What if, for whatever reason, the other side isn't signaling the semaphore? That's a deadlock. In our situation (and probably many others), this is unacceptable. The problem has been reported to the Qt team in 2008 and they don't seem very interested in fixing it. So this basically means I had to code my own thing, directly using the OS's named semaphores. Currently, I have only coded it for Windows, so it will have to be ported to Linux and macOS.

On the other hand, QSharedMemory works like a charm, so there's that.

I also reworked the sync system some. It's currently not perfect, but atleast now I know I'm not being held back by faulty emulation: as long as no frames are being dropped or delayed, the communication should work fine.

Overall, this gives much better performance than the previous iteration: NSMB multiplayer reaches near-fullspeed on my laptop Crepe, and that's with the interpreter. There are still issues to iron out, but this gives me hope that we can pull off fun multiplayer features in melonDS.

Also worth noting that there is another candidate for optimization, which I haven't talked much about yet: the wifi module itself.

The wifi module, you say? What's worth optimizing in there?

... read more
The local multiplayer saga, ep 4
If you happen to remember the previous episode, you'd know I'd ran into an issue caused by short CMD frames, as melonDS was erroneously replying to these with long replies. In that situation, the hardware skips the reply and sends a default empty reply, and I had yet to implement that feature properly.

So I did.

Except I still had data loss problems and random hangs in Pictochat.

I ran several hardware tests to make sure I wasn't missing any detail of this feature, and all seemed correct.

So I turned to debugging Pictochat. I noticed that when the client was getting stuck, it just stopped sending reply frames entirely. I backtracked and backtracked to find out why it was doing that, and finally found the cause. It was quite stupid.

Basically, when the DS sends a reply frame, it marks the previously sent frame by changing the first byte of its header to 0x01. All fine and dandy. melonDS of course does the same thing.

Except that when I added support for substituting a frame with a default-empty frame, I copypasted some code without paying enough attention to what it did. And that code was setting the internal reply frame address to zero, which caused the above frame header manipulation to fail unless the previous frame happened to be at address zero (basically, the beginning of the wifi RAM).


After fixing this oversight, I was rewarded with a perfectly stable and smooth connection. No hiccups, no data loss, no hanging. I didn't even see the host try to retransmit any frames.

... read more
The local multiplayer saga, ep 3
From the previous post:

However, there is still data loss in the client->host direction, which I need to investigate further.

So I've been doing exactly that. I'm not done yet, because the DS wifi is a rabbit hole, so many little details everywhere and especially in the local-multiplayer specific features.

If you have messed with wifi in melonDS before, you might have seen this message appear in the console:

wifi: !! unusual TXSLOT_CMD bits set C000

What is this about? The value for TXSLOT_CMD has two known parts. Bits 0-11 are the address of the CMD frame, and bit 15 tells whether the CMD slot is enabled. The rest is undocumented as of now.

In this situation, the game is setting bit 14, which prevents the hardware from automatically filling in the CMD frame's sequence number. This feature comes in handy if the host needs to retransmit a CMD frame for whatever reasons (for example, if some clients failed to respond). All in all, nothing too difficult to deal with.

Except implementing it in melonDS worsened the problem of client->host data loss in Pictochat. So I just ignored that feature, which made the transfers work nearly perfectly (albeit with some apparent lag). But you know our standards: that's not correct emulation, and also more likely to lead to other problems.

So I investigated the data flow. There are a few things of note in the Pictochat data flow:

* The host sends a CMD frame every 4 milliseconds. Each frame can be addressed to a maximum of 3 clients. Thus, the host needs 5 frames to poll every possible client. This is probably done to avoid monopolizing the wifi channel too much.

* The client, when receiving a CMD frame not addressed to it, will interact with the unknown hardware registers 0x244 and 0x228. Register 0x244, in this case, seems to be used to inhibit the transfer of a reply frame, which I'm not sure why they do it when no reply would be sent anyway. I don't know what register 0x228 does, I haven't observed any effects in my tests. Over all, this part doesn't seem very important.

... read more
The local multiplayer saga, ep 2
Slowly but steadily, I'm working on it. For now, I'm keeping my work private, so I'm not bothered by people wanting to try an unfinished branch, reporting issues with it, etc.

We assume here that you're familiar with local multiplayer terms. If you're not: read this.

I introduced a crude synchronization mechanism where the host of a local multiplayer game can instruct clients to stay in sync. When a client connects, the host sends its USCOUNTER (the wifi system's microsecond counter) value to that client, which can then compare that to its own USCOUNTER value: the point a connection is established is considered the reference point, and the client will then wait for the host to allow it to run, so it doesn't get too far ahead or behind.

Thus, the host can enforce sync (and also wait for clients to have caught up) before sending a CMD frame to its clients, thus ensuring that everybody is at the same point at that time. It can then send its CMD frame and allow clients to run ahead for a given amount of time that covers the entire MP exchange process.

The results aren't perfect, but they are somewhat promising.

For example, Pictochat doesn't seem to get stuck trying to send messages. I have only tested with two instances for now, but they seem to stay in sync fine.

However, there is still data loss in the client->host direction, which I need to investigate further.

I suspect there might be issues with ack frames being received too late. I intend to just fake them, to simplify things and reduce the amount of data being transferred. I made a quick attempt at that yesterday, but so far it's not working as intended.

It may also be caused by lacking emulation of the error handling processes in hardware (like automatically resending the CMD frame if some clients failed to respond, for example). I will have to do some more reverse-engineering to determine how that works in detail.

... read more
Plans for local multiplayer
I know I haven't been active a lot lately, the usual.

Well, I tried looking into the DSi sound app, and found that it crashes due to a NULL access. I tried debugging that, but it seems to be some weird timing problem and I don't know why that crash doesn't happen on hardware. This will need further investigation.

Anyway, local multiplayer.

It's one of the big things to take care of, now. We have been mostly putting it aside over time, favoring various popular requests, quality of life improvements, and fixes to DSi emulation. But we can't keep pushing it away like that. We have decided that improved local multiplayer is a must-have for melonDS 1.0, and we aren't going to keep making 0.9.247 type releases forever.

(besides, 0.9.x releases aren't very pleasant, for the same reason why I don't like $29.99 type prices: 9 is brown)

Anyway, I brainstormed some ideas for reliable local multiplayer. I have already explained before why local multiplayer is so finicky to implement, but the basic story is that we can't just run two melonDS instances and have them hurl packets at eachother and pray that things will work out. You might already know that we keep telling people to disable the framerate limiter if trying local multiplayer, and that's linked to this too.

We need a smarter mechanism for synchronizing melonDS instances taking part in local multiplayer. I have some ideas in mind for this, but I have to see how well they will translate to reality. I'm concerned about the performance implications this could have.

If this is successful, there are other possible quality of life improvements that relate to local multiplayer. For example, how to deal with user input when multiple melonDS instances are running on the same machine? You might want them to have different input mappings, but how do we deal with that without making things too complicated?

The craziest thing to achieve would be netplay, akin to Citra. Well, of course, there is no chance local multiplayer could work over the internet, but there are probably ways around this; we can look into how popular emulators handle netplay.

Oh well, we'll see how this goes, I guess.
Long time no news
I'm sorry, there just hasn't been a whole lot of fun new things to talk about these days.

On my side, it's a mix of the usual, ADHD, depression, ... I realize I have mostly been pushing these issues aside, but ignoring them only works for so long, so I'm in the process of getting professional help.

I also started a new job a few weeks ago, so it takes a while to get into it and all. I hope this will work out, especially as my ADHD is getting in the way there too, and the earliest appointment I could get for a diagnosis is in February 2023.

Oh well.
Opening your eyes to the world
I haven't been very active these days, mostly real life getting in the way, as usual. Anyway, I have been thinking of cool things I could work on for melonDS. I have some ideas in mind regarding input, like supporting multi-touch and other fun touchscreen-related features, but lately I felt like working on some actual emulation, especially in the DSi field. It's well known that DSi emulation in melonDS needs more love.

I was thinking of implementing things like SoundEx and microphone support, but Generic said he was going to implement that, so I'm letting him having fun there. Instead, I went for improving camera emulation. After all, cameras are the main thing DSi-exclusive games make use of, so DSi emulation with no camera support just feels incomplete.

melonDS 0.9.4 already has some very basic camera emulation, but it basically just does the bare minimum to pass the camera init sequence, and then returns a fixed stripe pattern (which is basically just the picture data register returning a fixed value). Nothing exciting.

For example, you can open the DSi camera app and get to the actual camera part of it, but trying to take a picture will result in a system error. Reason for this is that the camera can be set to output at multiple resolutions. It has two modes of operation, named 'preview' and 'capture', which makes sense in applications like digital cameras: preview mode would provide a low-res preview of what the camera sees, that can be displayed on a built-in screen, while capture mode would provide a full-res picture that can be saved. The DSi camera lets you configure two contexts, each with their output resolution, image format, and various other options (for example, flipping the picture...).

So I first had to add support for these modes of operation. I first implemented the registers necessary to handle the camera mode/context switch. But, of course this wasn't enough. The stub in place for picture transfer assumed a resolution of 256x192, but in this case, the resolution is changed to 640x480. This also means that the DSi camera app expects more picture data to come, and it will softlock if there isn't enough data incoming.

This is where my camera test homebrew came in handy. I modified it so that I could do things like switching between the front and back cameras, switch between preview and capture modes, and even use the picture cropping feature to view different areas of the picture in 640x480 mode (as obviously it wouldn't fit onscreen). Doing this let me get a good grasp on how these features were supposed to work.

Then I felt confident implementing all that into melonDS.

This is a preexisting still picture, not actual camera input. But regardless, we have working camera emulation now, and this is half the battle. The other half would be reading picture data from sources like an actual camera, feeding it into the emulator, and integrating all that into the UI.

... read more
melonDS has been acquired by Meta
EDIT - this post is an April Fools joke (in case that wasn't obvious)

A while ago we had an... unusual visit at the melonDS HQ: Mark Zuckerberg, no less. Zuck stated that he had always been a great fan of emulation, and that he loved our project greatly.

He offered us $324 million for the melonDS company, including both the HQ and the Melon Factory of Kuribo64.

An offer we could hardly refuse. Zuck is a very cool guy, and we greatly enjoyed the time spent in his company at the HQ. Plus, he's good at karaoke, so that will definitely make for some fun nights!

On more practical terms: this means lots of new exciting developments for melonDS.

For example, one of the new ideas is selling NFTs of the best melonDS screenshots. That is an obvious one, but not the only one at all.

There are also many possibilities opened by Metaverse integration: melonDS could be made compatible with game cartridges you would buy in the Metaverse, and you would then get to enjoy your favorite DS classics in VR. Who wouldn't love that?

melonDS will also become smarter, for an enhanced user experience. We are thinking about keeping a database of games, so melonDS can detect which game it is running, and offer ads related to that game. That is a start, but with AI we might be able to take this even further and offer the most relevant ads an emulator has ever offered.

Harnessing the power of a cloud could let us determine for you what the best emulator settings are, so you never ever have to mess with settings again.

... read more