|
| Home | Downloads | Screenshots | Forums | Source code | RSS | Donate |
| Register | Log in |
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:1234567···23 |
|
Display capture: oh, the fun! Nov 12th 2025, by Arisotura |
|
This is going to be a juicy technical post related to what I'm working on at the moment. Basically, if you've used 3D upscaling in melonDS, you know that there are games where it doesn't work. For example, games that display 3D graphics on both screens: they will flicker between the high-resolution picture and a low-resolution version. Or in other instances, it might just not work at all, and all you get is low-res graphics. It's linked to the way the DS video hardware works. There are two 2D tile engines, but there is only one 3D engine. The output from that 3D engine is sent to the main 2D engine, where it is treated as BG0. You can also change which screen each 2D engine is connected to. But you can only render 3D graphics on one screen. So how do those games render 3D graphics on both screens? This is where display capture comes in. The principle is as follows: you render a 3D scene to the top screen, all while capturing that frame to, say, VRAM bank B. On the next frame, you switch screens and render a 3D scene to the bottom screen. Meanwhile, the top screen will display the previously captured frame from VRAM bank B, and the frame you're rendering will get captured to VRAM bank C. On the next frame, you render 3D graphics to the top screen again, and the bottom screen displays the capture from VRAM bank C. And so on. This way, you're effectively rendering 3D graphics to both screens, albeit at 30 FPS. This is a typical use case for display capture, but not the only possiblity. Display capture can receive input from two sources: source A, which is either the main 2D engine output or the raw 3D engine output, and source B, which is either a VRAM bank or the main memory display FIFO. Then you can either select source A, or source B, or blend the two together. The result from this will be written to the selected output VRAM bank. You can also choose to capture the entire screen or a region of it (128x128, 256x64 or 256x128). All in all, quite an interesting feature. You can use it to do motion blur effects in hardware, or even to render graphics to a texture. Some games even do software processing on captured frames to apply custom effects. It is also used by the aging cart to verify the video hardware: it renders a scene and checksums the captured output. For example, here's a demo of render-to-texture I just put together, based on the libnds examples: ... read more |
| 3 comments (last by Anonymous) | Post a comment |
|
Happy birthday melonDS! Nov 3rd 2025, by Arisotura |
|
Those of you who know your melonDS lore know that today is a special day. melonDS is 9 years old! ...hey, I don't control this. 9 is brown. I don't make the rules. Anyway, yeah. 9 years of melonDS. That's quite the achievement. Sometimes I don't realize it has been so long... - As far as I'm concerned, there hasn't been a lot -- 2025 has had a real shitty start for me. A lot of stuff came forward that has been really rough. On the flip side, it has also been the occasion to get a fresh start. I was told about IFS therapy in March, and I was able to get started. It has been intense, but so far it has been way more effective than previous attempts at therapy. I'm hopeful for 2026 to be a better year. I'm also going to hopefully get started with a new job which is looking pretty cool, so that's nice too. - ... read more |
| 19 comments (last by dud) | Post a comment |
|
The joys of programming Nov 1st 2025, by Arisotura |
|
There have been reports of melonDS 1.0 crashing at random when running multiple instances. This is kind of a problem, especially when local multiplayer is one of melonDS's selling points. So I went and tried to reproduce it. I could get the 1.0 and 1.0RC builds to crash just by having two instances open, even if they weren't running anything. But I couldn't get my dev build to crash. I thought, great, one of those cursed bugs that don't manifest when you try to debug them. I think our team knows all about this. Not having too many choices, I took the 1.0 release build and started hacking away at it with a hex editor. Basic idea being, if it crashes with no ROM loaded, the emulator core isn't the culprit, and there aren't that many places to look. So I could nop out function calls until it stopped crashing. In the end, I ended up rediscovering a bug that I had already fixed. The SDL joystick API isn't thread-safe. When running multiple emulator instances in 1.0, this API will get called from several different threads, since each instance gets its own emulation thread. I had already addressed this 2.5 months ago, by adding adequate locking. I guess at the time of 1.0, it slipped through the cracks due to its random nature, as with many threading-related bugs. Regardless, if you know your melonDS lore, you know what is coming soon. There will be a new release which will include this fix, among other fun shit. In the meantime, you can use the nightly builds. |
| 5 comments (last by Deaddie999) | Post a comment |
|
Sneak peek Oct 27th 2025, by Arisotura |
|
Just showing off some of what I've been working on lately: This is adjacent to something else I want to work on, but it's also been in the popular request list, since having to manually enter cheat codes into melonDS isn't very convenient: would be much easier to just import them from an existing cheat code database, like the R4 cheat database (also known as usrcheat.dat). It's also something I've long thought of doing. I had looked at usrcheat.dat and figured the format wasn't very complicated. It was just, you know, actually making myself do it... typical ADHD stuff. But lately I felt like giving it a look. I first wrote a quick PHP parser to make sure I'd gotten the usrcheat.dat format right, then started implementing it into melonDS. For now, it's in a separate branch, because it's still quite buggy and unfinished, but it's getting there. The main goal is complete, which is, it parses usrcheat.dat, extracts the relevant entries, and imports them into your game's cheat file. By default, it only shows the game entry which matches your game by checksum, which is largely guaranteed to be the correct one. However, if none is found, it shows all the game entries that match by game code. It also shows a bunch of information about the codes and lets you choose which ones you want to import. By default, all of them will be imported. This part is mostly done, besides some minor UI/layout bugs. The rest is adding new functionality to the existing cheat code editor. I modified the melonDS cheat file format (the .mch files) to add support for the extra information usrcheat.dat provides, all while keeping it backwards compatible, so older .mch files will still load just fine. But, of course, I also need to expose that in the UI somehow. ... read more |
| 8 comments (last by Loreciao) | Post a comment |
|
Not much to say lately... Oct 15th 2025, by Arisotura |
|
Yeah... I guess real life matters don't really help. Atleast, my mental health is genuinely improving, so there's that. But as far as my projects are concerned, this seems to be one of those times where I just don't feel like coding. Well, not quite, I have been committing some stuff to melonDS... just not anything that would be worthy of a juicy blog post. I also had another project: porting my old SNES emulator to the WiiU gamepad. I got it to a point where it runs and displays some graphics, but for now I don't seem motivated to continue working on it... But I still have some ideas for melonDS. One idea I had a while ago: using the WFC connection presets to store settings for different altWFC servers. For example, using connection 1 for Wiimmfi, connection 2 for Kaeru, etc... and melonDS would provide some way of switching between them. I don't know how really useful it would be, or how feasible it would be wrt patching requirements, but it could be interesting. Another idea would be RTCom support. Basically RTCom is a protocol that is used on the 3DS in DS mode to add support for analog sticks and such. It involves game patches and ARM11-side patches to forward input data to RTC registers. The annoying aspect of this is that each game seems to have its own ARM11-side patch, and I don't really look forward to implementing a whole ARM11 interpreter just for this. But maybe input enhancements, be it RTCom stuff or niche GBA slot addons, would make a good use case for Lua scripting, or some kind of plugin system... I don't know. There are other big ideas, of course. The planned UI redesign, the netplay stuff, website changes, ... Oh well. |
| 16 comments (last by Zerando Jogos) | Post a comment |
|
Fix for macOS builds Sep 26th 2025, by Arisotura |
|
Not a lot to talk about these days, as far as melonDS is concerned. I have some ideas, some big, some less big, but I'm also being my usual ADHD self. Anyway, there have been complaints about the macOS builds we distribute: they're distributed as nested zip files. Apparently, those people aren't great fans of Russian dolls... The issue is caused by the way our macOS CI works. I'd have to ask Nadia, but I think there isn't really an easy fix for this. So the builds available on Github will have to stay nested. However, since I control this site's server, I can fix the issue here. So now, all the macOS builds on the melonDS site have been fixed, they're no longer nested. Similarly, new builds should also be fixed as they're uploaded. Let us know if anything goes wrong with this. |
| 7 comments (last by Spitfire) | Post a comment |
|
DSP HLE: reaching the finish line Aug 11th 2025, by Arisotura |
|
In the last post, the last things that needed to be added to DSP HLE were the G711 ucode, and the basic audio functions common to all ucodes. G711 was rather trivial to add. The rest was... more involved. Reason was that adding the new audio features required reworking some of melonDS's audio support. melonDS was originally built around the DS hardware. As far as sound is concerned, the DS has a simple 16-channel mixer, and the output from said mixer is degraded to 10-bit and PWM'd to the speakers. Microphone input is even simpler: the mic is connected to the touchscreen controller's AUX input. Reading said input gives you the current mic level, and you need to set up a timer to manually sample it at the frequency you want. So obviously, in the early days, melonDS was built around that design. The DSi, however, provides a less archaic system for producing and acquiring sound. Namely, it adds a TI audio amplifier, which is similar to the one found in the Wii U gamepad, for example. This audio amplifier also doubles as a touchscreen controller, for DS backwards compatibility. Instead of the old PWM stuff, output from the DS mixer is sent to the amplifier over an I2S interface. There is some extra hardware to support that interface. It is possible to set the sampling frequency to 32 KHz (like the DS) or 47 KHz. There is also a ratio for mixing outputs from the DS mixer and the DSP. Microphone input also goes through an I2S interface. The DSi provides hardware to automatically sample mic input at a preset frequency, and it's even possible to automate it entirely with a NDMA transfer. All in all, quite the upgrade compared to the DS. Oh, and mic input is also routed to the DSP, and the ucodes have basic functions for mic sampling too. All fine and dandy... ... read more |
| 17 comments (last by Arisotura) | Post a comment |
|
Having fun with DSP HLE Jul 31st 2025, by Arisotura |
|
If you pay attention to the melonDS repo, you might have noticed the new branch: dsp_hle. And this branch is starting to see some results... These screenshots might not look too impressive at first glance, but pay closer attention to the framerates. Those would be more like 4 FPS with DSP LLE. Also, we still haven't fixed the timing issue which affects the DSi sound app -- I had to hack the cache timings to get it to run, and I haven't committed that. We'll fix this in a better way, I promise. So, how does this all work? CasualPokePlayer has done research on the different DSP ucodes in existence. So far, three main classes have been identified: • AAC SDK: provides an AAC decoder. The DSi sound app uses an early version of this ucode. It is also found in a couple other titles. • Graphics SDK: provides functions for scaling bitmaps and converting YUV pictures to 15-bit RGB. ... read more |
| 8 comments (last by Arisotura) | Post a comment |
|
melonDS 1.0 is out Jul 8th 2025, by Arisotura |
|
Finally, the "proper" melonDS 1.0 release is here. Sorry that it took so long... Anyway, this is pretty much the same as the 1.0 RC, but we fixed a bunch of bugs that were found in said RC. Namely, you can now use multiple windows with OpenGL under Windows. However, depending on how good your OpenGL driver is, doing so may reduce performance. It's due to having multiple OpenGL contexts sharing data, but for now we don't really know what we can do about it. If you have ideas, let us know! Speaking of multiple windows, I also added a way to tell melonDS windows apart, because things could get pretty confusing. They now get a tag in their title, for example [p1:w2] means first multiplayer instance, second window. We also merged asie's add-on support PR, so this release includes support for the Motion Pak and the Guitar Grip. We merged some other PRs. Among which, lower audio latency. This release also includes the DSi camera fixes that were discussed in the previous posts. DSi titles that ran into issues while trying to use the camera should now work with no problems. However, since they tend to also use the DSP at the same time, the performance will be abysmal... ... read more |
| 40 comments (last by mrjfilippo) | Post a comment |
|
Let's Golf: the horseman of apocalypse that wasn't one Jul 7th 2025, by Arisotura |
|
I figure I need to resolve the dramatic tension from the previous post. So the issue we had was a screen-sized DMA3 transfer interfering with NDMA1, which is used to transfer camera data... Shortly after I made that post, I recalled that Jakly mentioned VRAM timings, and started to figure it out. I said that when I reproduced the setup in a homebrew, it would trigger a data overrun error and get stuck. But there was one thing I was missing: my homebrew was using a camera resolution of 256x192, with DMA set to run every 4 scanlines, the standard stuff. However, Let's Golf uses cropping to achieve a resolution of 144x144, and runs the DMA every 7 scanlines. This means more time between each NDMA1 transfer. Regarding VRAM, the DSi supports accessing it over the 32-bit bus, instead of the old 16-bit bus. One effect is that this makes it possible to write to VRAM in 8-bit units, which wasn't possible on the DS. Another effect is that it affects timings: for example, a 32-bit DMA transfer from main RAM to VRAM would take 2 cycles per word, instead of 3. I did the math, and with such timings, the screen-sized DMA3 transfer would have enough time that it could run between two NDMA1 transfers without disrupting the camera operation. But with the 16-bit bus timings, DMA3 would definitely take too long. I even modified my homebrew to use the same 144x144 resolution as Let's Golf, and added a key to toggle the 32-bit bus for VRAM (via SCFG_EXT9 bit 13). Suddenly, my homebrew was running just fine as long as the 32-bit bus was enabled, but when it was disabled, it would trigger the data overrun error and get stuck. So, basically, this is nothing fancy, just a case of "this works out of pure luck". I added support for the new VRAM timings in melonDS. But this wasn't enough, Let's Golf would still get stuck. ... read more |
| 3 comments (last by Arisotura) | Post a comment |
| Pages:1234567···23 |
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: