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
Bugfix0ring streak
So many things to do and so few coders. Poor melonDS company :P

Regardless, a bugfixing streak started happening. So, while I'm busy brainstorming about the current issue (which I'll talk about), have a post with juicy technical details about the process. It's oh so fun, you'll see.



First bug to go down is this weird 3D glitch that shows up in Mario Kart DS and probably others. The issue post shows what it's about: random glitch lines showing up in 3D graphics.

First attempts are some tests to determine the nature of the glitchy pixels. Disabling polygon edges, disabling translucent polygons, disabling antialiasing, whatever, you name it.

Eventually, we find out that those pixels are edge pixels.

Then, I suspected a depth test related issue. Stencil test can be excluded, shadow polygons are always translucent, and if you've read the previous post about the GPU innards, you know that translucent pixels don't set edge flags.

Enter depth buffer debugging. AKA Mario Kart LSD edition.

The purpose of this isn't to have an epic trip racing crapo AI players in a trippy setting, but to have a visual reading of the depth buffer. Not very readable to the bare eye, but the 24-bit Z values are mapped to 24-bit RGB, and this is a gross hack that bypasses the whole rendering pipeline (which is 18-bit).

... read more
The DS GPU and its fun quirks
Oh hey, another 'technical shito' post. Kind of a preamble to what will be the flagship feature of 0.8.

(would be nice to add actual tags/categories to this blog, btw. heh)



Anyway, I want to talk about how the DS GPU works, how it's different from modern GPUs, and why I don't think that using Vulkan over OpenGL would be any benefit.

I don't know Vulkan a lot, so don't quote me on that, but from what I get, Vulkan stands out by working on a lower level than OpenGL, letting you manage the GPU memory and similar things. This may be good for emulating more modern consoles, where sometimes proprietary graphics APIs are used that allow levels of control that aren't possible with OpenGL.

For example, the blargSNES hardware renderer -- one of the tricks it pulls is that during some of the operations, the same depth/stencil buffer is used with different color buffers. This isn't possible with OpenGL.

Also, there's less cruft between the application and the GPU, meaning better performance, provided you're doing things right. While OpenGL drivers are full of optimizations for common use cases and even for specific games, with Vulkan it's all up to the application to be, you know, well programmed.

So basically, with more power comes more responsibility.



... read more
Quick bugfix update for Windows
If you have downloaded melonDS until now, and it crashes when you try to launch it, try redownloading it.

I pushed a quick bugfix update for the Windows build. Fixed the code that was responsible for loading INI/BIOS/firmware from AppData. So now, it shouldn't crash randomly anymore, and it should actually work as intended.

The bug went unnoticed because a) it strikes on a fresh melonDS install, and b) it's a heisenbug! It tried to access memory that was uninitialized and potentially freed, depending on a lot of things internal to the OS. You guess how it goes.
melonDS 0.7 -- Granting popular wishes
Or atleast starting to do so. There isn't a lot in this release, but hey, we have to start somewhere.

Atleast, The Spark is back, somewhat. So I guess we can take melonDS somewhere.


Not a lot of novelty visually speaking, so there will only be one screenshot:



Nothing changed! :D

Except, if you look closely, the bottom border of the blue platform thing.

Couldn't resist.

Fixed a small bug regarding shadows and antialiasing, that caused that.


What else? Miscellaneous fixes. melonDS shouldn't crash randomly when closing it anymore. And other things.

... read more
Coming soooooooon!
The savestates feature is finished! Not saying much more though, the details are a surprise ;)

Other than there were other bugs like mentioned in the previous post that bit me, but eh, that's all over now.

There are a few issues to iron out regarding menus under GTK, though, so it'll take a little while.

But it's coming soon!
When your innocuous little code goes kaboom
So until we get something amazing to release, we're going to post some technical shito again.


As said in the previous post, I've been coding savestates. The base idea seems simple enough, just throw all the emulator's state into a file (or read it from that file if you were loading a state), make extra sure that you're not missing anything important, regenerating things that need it when loading, etc...


So I first designed the bases of the implementation:

• A savestate file is divided in several sections. Those can be ordered arbitrarily. The file format itself is very simple.

• To reduce complexity, we only handle loading/saving between frames.

• Some questions are still not clear, and I still need a way to avoid loading a savestate over the wrong ROM. (or I could allow it as a fun Easter egg, even if it generally results in a crash)


Then, the gruelling work, storing all the emulator state.


Including, you guess, the event scheduler, which is an array of event structures with an entry per possible event source. Just write that to the savestate file, right?

Think again.

... read more
gettin' there
Apologies for not keeping this up to date lately.

Anyway, savestates are being coded, and we need your help to test them out. More about this in this reddit post.

Other than that, I tried some hax on my new green DSi. Was able to install unlaunch. I'm not yet able to run DSi homebrew though-- ndstool builds oldschool DS ROM headers, which causes unlaunch to load these ROMs in DS mode. I have yet to figure out how to make ndstool build DSi ROM headers.

On the real life side... I'm getting there. Depression is a bitch tho. And capitalism too. I would feel a lot better if that didn't exist.
the plaaaaaans: getting staaaaaarted
this is spaaaaaarta





Meet Green.

It's a big DSi. Pretty cool, eh?

Quick inspection reveals that everything is alright. It was factory-reset, tho, so it might not have Flipnote on it. But whatever, we'll find a way. actually it does still have Flipnote. All good!


Still no news of the other order. If you happen to remember, it was returned to sender, and the sender notified me about it and asked me what they should do. I gave them another address to ship to, and even offered to pay for the reship, but since then, silence.

I guess I'll have to give the seller a reminder. Or ask for a refund.


Regardless, I think we can get started with the interesting things... once I'm a bit more settled.
The 'timing' branch
In the meantime, I figured I'd give this a try.

Basic idea is that emulating timings with reasonable accuracy will require emulating the ARM9 caches.

I want to see if I can emulate those without completely killing performance. If I pull it off, there'll be several benefits:

* much more accurate timings, fixing games that do weird things
* homebrew developers using melonDS wouldn't fall into the typical 'forgot to flush/invalidate cache' pitfall that reveals itself when testing on hardware
* if we take it even further, we can emulate the MPU (memory protection unit), which means emulating crashes

I guess that if I manage to get it going, there will be a sorta beta release so I can get feedback about this, whether it's killing performance, etc...
Updates on the plaaaaaaans
The package was, surprise, returned to sender, because some idiot can't find a mailbox that is street-facing and not hidden or anything fancy. Hell, it's right next to the building's front gate.

Whatever.

I'm trying to see if I can have it shipped at another address which I know should work.

I ordered another one, too (that was before the seller for the first one contacted me about the package), but it won't be shipped until a week.


I guess it can't be a bad idea to get two consoles either way. Like, if one turns out to be less/not haxable, or if I need to do hardmods...