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
Pages:12345678910···21
The netplay saga, ep 3.5
Apr 17th 2023, by Arisotura
Just a quick post...

I'm having a mold problem in my apartment, so there won't be a lot of progress on netplay (or melonDS in general) while this is being dealt with. To give you an idea, I'm typing this from another place.

Regarding netplay: I'm not going to go with the idea of sending ROMs over. The other solutions suck from an end user perspective, but I don't want to deal with the legal grey area.

For the rest, we're waiting for JesseTG's pull request for in-memory savestates.
14 comments (last by N taisu) | Post a comment
The netplay saga, ep 3
Apr 7th 2023, by Arisotura
In the previous episode, I had basic input forwarding working, but we had problems due to the initial state being different on each side. So in this episode, I've been working on tackling this.


The first problem is the ROMs themselves. The first iteration of netplay required that each side have the same ROM, but this has the problem that there can be multiple revisions of the same game, and some games (hi Pokémon) even support multiplayer interaction with different games. Requiring every player to have the exact same ROM feels really restrictive, especially compared to a real-life DS multiplayer session, where each player has their own game cart (or doesn't, and uses download play).

Yet, we do need to ensure that every mirror client is using the exact same ROM as their mirror host. Two solutions: either having mirror hosts send their ROM to their mirror clients, or requiring all ROMs to already be present on all sides.

From an end user perspective, I don't like the second solution. It may require users to deal with complex multi-ROM setups, making sure they load everything in the right place; there's quite the potential for things to go wrong, or just for users to be confused.

So I went and experimented with the first solution. While it keeps things simple, it has the downside that transferring DS ROMs takes a while, due to their average size of 64MB. But there are ways to alleviate this: compressing the transferred data, but also skipping the transfer entirely if all sides already have the exact same ROM (which we can verify with a simple CRC).

Keep in mind that none of this is set in stone, and I'm largely experimenting here. We are still pretty far from a finished product.

Next step is ensuring that the emulator state on boot is the same on each side. For this, I had the idea of using the savestate system: basically, have the mirror host take a savestate after the ROM is loaded, send that state over to mirror clients, have them apply it, and it's guaranteed that all sides start with the exact same state.

I ran into a few issues with this. First, the savestate system doesn't save the BIOS and firmware, because it wasn't deemed necessary at the time I designed it. But right now, it's a requirement if we want our mirror clients to have the same user settings, MAC address, etc... as their mirror host. I also ran into a bug in the savestate system itself, which isn't a problem in most cases but turned out to be problematic in this current situation. After addressing all this, I was finally able to have all sides start from the exact same state. And it does fix the issues I had observed: games stay in perfect sync, items in Mario Kart will always pull the same item on each side, the AI players will stay in sync, etc...

This does have a bit of the same problem as sending ROMs around, though: melonDS savestates tend to be ~18MB in size. So, definitely, compression will come in handy here. I also want to look into other ways to optimize this: enet (the network library we use for this) isn't well suited for transferring large amounts of data like that, so it's slow.

... read more
22 comments (last by Agente9) | Post a comment
The netplay saga, ep 2
Mar 27th 2023, by Arisotura
I've been building the basic network infrastructure for netplay lately. Oh, the fun that is dealing with synchronization.

If you remember the graph from the previous post:



Implementing this proves to be tricky, because since each individual instance there is its own process, there's a lot of moving parts. So first, we're going to name them.

Assuming player 1 is the player who initiated the game: player 1's instance 1 acts as the game host, while player 2's instance 2 and player 3's instance 3 act as game clients. The game host transmits useful information to the game clients, tells them when to start running, ...

Then player 1's instance 1 acts as a mirror host: players 2 and 3's instance 1, the mirror clients, connect to it, and receive their input from it, thus mirroring player 1's input on players 2 and 3's machines. Similarly, player 2's instance 2 and player 3's instance 3 are also mirror hosts.

As is typical with netplay implementations, inputs are delayed by a fixed amount, which is hardcoded to 4 frames in the current test branch, but will be configurable in the final product. The basic idea is to delay inputs a bit on all sides to counter network lag.

Each input frame sent by a mirror host is given a frame count, which lets mirror clients make sure to apply that frame at the exact same time as their host, thus ensuring all sides are given the exact same inputs. If a mirror client runs out of input frames (because the mirror host is running slower), it will need to block until it receives input frames -- missing an input frame would cause a desync.

During a local multiplayer game, this has shown to be enough to form a somewhat viable netplay implementation: this crude synchronization mechanism, combined with local multiplayer sync, do a good job at keeping all instances in sync. But when the players aren't engaging in a local multiplayer game yet, there is the possibility that mirror clients run too slow and end up lagging behind an awful lot.

... read more
13 comments (last by Jawlshy) | Post a comment
The local multiplayer saga, season 2: Netplay
Mar 24th 2023, by Arisotura
As the apartment shito is beginning to settle down, I have been able to start working on this.


My first goal was to fix the two annoying issues I described in the previous post. In this situation, I was trying to get the pause command to simultaneously pause all local melonDS instances, instead of just the one that received the command. There is more to be done in the way of cross-instance sync, but this seemed an obvious starting point to me.

The first issue was due to the way the interface works. Originally, the only way to pause melonDS was through the interface (System->Pause). Later on, the pause hotkey was added. Hotkeys are checked and handled in the emu thread (separate from the UI thread), so to keep things simple, the pause hotkey would just send a signal to the main window which would behave like using the System->Pause menu command. It's a bit of a roundabout way to handle this, but it has the advantages that it avoids duplicating code too much, and keeps the UI state (the Pause checkmark) in sync without having to worry about it.

When I started adding cross-instance pause, I made the pause command handler send a message to other melonDS instances through IPC. Then the other instances would receive that message and treat it the same as pressing the pause hotkey. Easy peasy.

Yeah, except doing so would cause these instances to send more pause messages, essentially entering a feedback loop.

So I had to add a separate handler for the IPC pause command to avoid this. Not the best solution, but it works.

Next problem was that during a local multiplayer game, cross-instance pause would interfere with the local multiplayer sync system, and could essentially cause some instances to get stuck. To deal with this, I had to add some more intelligence to the IPC comm layer to avoid waiting on instances that are paused. And it does the trick. Pausing a local multiplayer game may cause minor packet loss, due to the way this works, but I haven't seen any problems in my testing -- Nintendo's local multiplayer protocol is resilient, so this should be mostly fine.

There is more state that should be shared across melonDS instances, like the recent ROM menu. We'll get there. Now that the system is in place for cross-instance comm, it shouldn't be very difficult.


But for now, I want to build the base for netplay. So let's talk about this.

... read more
8 comments (last by Este) | Post a comment
Status update
Mar 8th 2023, by Arisotura
Not a lot to report melonDS wise. I'm running into problems with my cross-instance sync design, the kind of issues that are very annoying to solve, so... yeah.

Real life wise, I have finished the diagnosis process, so I'm now diagnosed with ADHD. I'm also able to get medicated for this; we'll have to see how this goes, but so far it's been a night and day difference for me. It's much easier for me to get myself to start tasks and stick to them. I'm impressed at how productive I have been at work these days. And so far I'm not seeing any adverse effects.

I hope this improvement can also help me getting things done for melonDS or my other personal projects, but right now it's a tad complicated. I'm moving to a new, better apartment, and while this is a great thing, it also means that there are a lot of things to take care of still, and that tends to be energy consuming for me.

But hopefully, by the end of March this should all settle down and allow me to take a big sigh of relief. In the meantime I'm trying to think of how to address the problems I'm facing regarding melonDS. Netplay is really something I want to get going.
12 comments (last by Brandon) | Post a comment
Slow days
Jan 30th 2023, by Arisotura
Yeah, we haven't been doing a whole lot for melonDS these days. General winter laziness, I guess.

On my side, that certainly didn't help. I've been taking a new antidepressant, and the first month has been rough. Generally, feeling tired and lethargic, but also having to deal with insomnia, side effects from sleeping pills... you get the picture.

The side effects have largely subsided now, I'm able to sleep without having to take anything, I'm more energetic in general, and feeling good. I have had bad experiences with antidepressants in the past, so I'm glad that this one is working.

Now I'm looking forward to my ADHD diagnosis appointment, which will be next week. Hopefully they can help me there, it sure would be nice if I didn't take forever to motivate myself to do things (including, but not limited to, working on melonDS).

In the meantime, what I'm currently laying out is a base for proper communication between melonDS instances. For example, pausing all instances simultaneously, starting new instances with the right game pre-loaded, and so on. This is going to be a must for netplay.
22 comments (last by Retropie) | Post a comment
Lil' site updates
Dec 13th 2022, by Arisotura
Not much to say these times... after the big 0.9.5 release, I've mostly been taking a big break, and thinking of how to properly lay the base for netplay. I've also had a pretty rough time in November, but I feel much better and hopeful now.

Anyway, little update to this site. I changed the way IP bans work: they no longer block you from the entire site, instead they will just restrict your ability to post comments.

I will likely also do some other updates and cleanup related to this, too. So let me know if anything is broken or if you're erroneously banned from somewhere.
17 comments (last by Jason Mansker) | Post a comment
melonDS 0.9.5 is out!
Nov 3rd 2022, by Arisotura
First of all, a bit of a special announcement.

As of today, the melonDS project is 6 years old. For this occasion, we present you this special version of the melonDS logo, recolored to the same pretty sky-blue color as 6 itself:



We wanted to have Peach bake a cake shaped like this, but Bowser kidnapped her again. We aren't great bakers at the melonDS HQ, so... yeah.

Regardless, these 6 years are a great success. Back in 2016, when I started working on melonDS, I was mostly just making it to have fun and pass time until my job started. I had absolutely no idea the project would go on for so long, and be as much of a success as it has been. So, first of all, I want to thank all the comrades who have helped make this possible. The melonDS team and other contributors. nocash and his great documentation. Everybody else who has been involved in reverse-engineering the DS/DSi hardware, cracking the DSi security, etc... And of course, everybody who has been using melonDS, testing games in it, reporting issues, suggesting improvements, etc...

Thank you all. melonDS is a team effort, and you deserve your part of the birthday cake.

And, of course, the birthday present. There's only one, but it's a big one. We bring you melonDS 0.9.5, and if you've been following the blog lately, you know it's going to be big.


melonDS 0.9.5



... read more
70 comments (last by Erdemkhishig) | Post a comment
Having 'fun' with the DSP
Oct 14th 2022, by Arisotura
DSi support in melonDS has been getting to a pretty good state lately. Basically, the only remaining 'big' thing to deal with is DSP support. The rest is mostly bugfixes, implementing misc features (hi, power button), etc, you get the idea. Plus, an aging cart for the DSi has been discovered, which will help implement and test the DSi features more thoroughly than commercial games do. And then there are the various quality-of-life improvements that come to mind, like not requiring BIOS/firmware/NAND dumps...


Anyway, the DSP.

The thing I have always kept pushing back, and for two good reasons. First, the DSP instruction set and encoding is a mess, and the documentation on it is lackluster. Second, there's hardly anything on the DSi that uses the DSP. The DSi sound app, and a few other DSi titles, and that's it. Everything else sticks to the old DS sound mixer.

But what we have going for us is that the 3DS uses the same DSP, and it is much more popular there with every game using it, so the 3DS scene has already been dealing with it. Namely, we have teakra, which is a fairly reliable DSP interpreter and disassembler.

PoroCYon had integrated teakra into melonDS in an attempt at bringing DSP emulation. It didn't work, but it was atleast a pretty good base. I had tried quickly fixing a couple bugs in it, with no real success. I wasn't really looking forward to having to debug DSP code, either, to be honest.


Lately, I felt like looking into it again.

I launched the DSi sound app, and was sidetracked by another, unrelated bug: the sound app crashes when starting due to a bad memory access. It went unnoticed before because we didn't emulate data aborts, but now, we do, and we can't go back on that.

So I researched that bug. It's a timing issue.

The crash happens when trying to dereference a particular pointer, because it is NULL. During startup, the main thread will allocate some memory, then run a bunch of initialization, then initialize that pointer. During the initialization, it sends an IPC request to the ARM7 to determine whether headphones are connected. While it waits for the ARM7 to respond, another thread runs, which does some other initialization, sends other IPC requests to the ARM7 (to get the date/time and battery status), then tries to do things with the aforementioned pointer, which is expected to have been initialized by now.

... read more
13 comments (last by hoangson2007) | Post a comment
Merge party
Oct 2nd 2022, by Arisotura
We're in the process of getting melonDS ready for a 0.9.5 release. That means, while Generic is working on fixing up OpenGL rendering on desktop, I'm free to go and finish some other fun things.


First, local_wifi has been deemed close enough to completion, and has been merged.

I added some tidbits of wifi emulation (for example, the Inazuma Eleven games use WEP during local multiplayer, so I had to implement enough of that to make them work), but most notably, I worked on the UI side of this feature. No more opening melonDS instances from different folders, MAC randomization, and other awkward workarounds. Now melonDS is able to detect when coexisting with other melonDS instances, and makes sure to save things like user settings, save file, etc, to separate files. For example, that makes it possible to configure each instance to use its own joystick.

It is probably still not perfect, but it's certainly a start. I also want to hear some user feedback on all this.

Regarding local multiplayer, the BSD socket interface is going byebye. This means it's no longer possible to play over LAN (not that it has ever really worked). But we plan to implement netplay for melonDS 1.0, so that will make up for it. It should even work better, in that the connection will be more reliable, but due to having to emulate all the participating consoles on every user's computer, it will be more demanding (although testing has shown that any decent computer can handle atleast two melonDS instances at fullspeed).


Next, I finished the work on camera_betterer, and merged it too.

Basically it was only matter of finishing up the UI side of things, adapting the Qt camera code for Qt6, and fixing up some tidbits (like camera image formats -- most cameras should be able to provide YUYV image data, but Mac cameras can only provide NV12).

Basically:



... read more
41 comments (last by a.nak) | Post a comment
Pages:12345678910···21