melonDS RSS The latest news on melonDS. welp. -- by Arisotura Sat, 06 Jul 2019 14:31:06 +0000
It will require some amount of wifi support to be able to launch titles. The amount required makes the 0.2 wifi stub look tiny in comparison. Basically the DSi menu tries to communicate with the wifi CPU thing and upload firmware to it.

We can either HLE it given sufficient documentation (and have to deal with ass-shitting high-level wifi concepts) or LLE the damn thing.

We'll see.]]>
the heat -- by Arisotura Mon, 01 Jul 2019 16:49:00 +0000

Let's just say it's a bit hard to be productive when your outside temperature is a scorching, capitalism-induced 43°C.

It's back to more reasonable temperatures now, but regardless, we don't do much besides bathing at the beach or at the nearby river.

I kind of need to take a break at this point though. Like, there are many things I want to do with melonDS, but I have too much ideas, and there's only so much I can do at once.

I will need to release a quick-fix 0.8.3 though. Atleast to fix the bug I introduced when adding support for 'Ctrl+M' type keys'. Basically you can't press any key while keeping R pressed if you keep the default mapping (right Shift).

I also want to try and fix the framerate limiter, which, askskfdksgsf.

On the DSi side, there will be some alpha builds of melonDSi once I finish the DSi dumper. Right now, the dumper is able to extract AES keys from the AES engine. The rest will be a breeze: dumping the BIOSes, the memory holding RSA/Blowfish keys, the NAND, the eMMC CID and console ID. It's mostly just matter of copying memory to a file, except the NAND is going to be a bit more involved, but nothing insurmontable.

I gave melonDSi a small pause, because I got stuck on AES-CCM (needs hardware tests) and also didn't want to let the master branch rot. Right now, it's not in a very interesting state -- all it does is boot the DSi menu, but it's still not getting further. And also because I keep fixating on the lack of full DSi bootroms. I'm even considering getting in touch with someone who is doing the hardware haxing required to dump them, or attempting to do it myself.

melonDSi will eventually be merged into regular melonDS when it's ready. You can think of it like medusa vs mgba.

I'm also trying to optimize melonDS. I have several targets in mind, but we'll see. The plan is to get it to run on less powerful platforms, like the Switch, or Android.

Speaking of this, user RSDuck is working on a JIT. The first iteration will be for x64, but he said it will be easy to port it to other architectures. If we can get this going without sacrificing too much accuracy, it will be a great help on the performance front.]]>
melonDS 0.8.2 -- by Arisotura Tue, 25 Jun 2019 18:17:40 +0000

Namely, there have been some fixes to the OpenGL renderer. If you were one of those for whom it did not work, we hope that now it will work. There are still issues with it, but we will eventually find them and fix them all.

I also undid a quick hack I did in 0.8.1 to try fixing texture alignment problems, that in the end caused more issues than it fixed. This problem will need a cleverer solution. It basically stems from the fact that the DS rasterizer works differently from OpenGL: it has no subpixel precision, and calculates color/texcoord for exact pixel positions, where OpenGL calculates them for a position that is +(0.5,0.5) inside the pixel.

I also hope to improve the GL renderer some more. In mind are: texture cache, texture upscaling/filtering, applying filtering to the 2D layer, doing something for dual-screen 3D...

We fixed a bug with the 'map joystick button and axis' feature of 0.8.1, where, if you mapped an axis control alone, it would also map 'button 1' alongside it.

melonDS now explicitly disables VSync when using OpenGL, atleast under Windows.

We also fixed a bunch of issues, potential crashes, etc...

... and changed kMaxIterationCycles from 16 to 64. That constant controls how many maximum cycles the ARM9 can run before control is given to the ARM7 and other system components. This change might affect accuracy negatively (it is worth noting that melonDS has several provisions for on-demand sync, bypassing kMaxIterationCycles) but has been found to give a small speed boost.

We're also using Github releases now. I'll add the builds to the Github page (and to the downloads page on this site) soon :)


melonDS 0.8.2, Windows 64-bit
melonDS 0.8.2, Linux 64-bit

If you're feeling generous, if you want to help us take this OpenGL renderer further: here's our Patreon]]>
melonDSi??? -- by Arisotura Thu, 20 Jun 2019 01:59:33 +0000
[DSi shito]

It doesn't get further than this though, but, considering the amount of work this required, between implementing the newfangled DSi hardware and fixing stupid bugs, this isn't a bad start. We can also thank Martin Korth and all the other comrades who have been paving the way and making this possible at all.

This is nowhere near ready for a release tho. It's an experimental branch in which I felt like playing around with things, attempting to boot a DSi firmware, and, well, this happened.

This also requires a bunch of data that have to be dumped from a DSi:

* NAND dump
* console ID
* RSA/Blowfish/AES keys

Those can be dumped from a DSi with unlaunch, but we will need a user-friendly way to do so.


There is also the issue that, well, this isn't completely clean and perfect.

When booting the DS firmware, we just load the ARM9 and ARM7 BIOSes, point the emulated CPUs to the reset vectors, and let it do all the work, just like how an actual DS would do. That way, we avoid any issues caused by incomplete memory/register setup when running a game, because the original boot ROM and firmware are taking care of everything. We also have a good reference for perfecting our direct boot implementation.

However, with the DSi, there's an issue: so far, we have only been able to dump the lower 32K of the 64K BIOSes. This is problematic as the first thing the reset vector does is jump to the upper half of the ROM. Then, said upper half is permanently locked right before jumping to the next bootloader stage (boot2), meaning that even if you somehow ran a completely custom boot2, you couldn't dump the upper halves of the BIOSes by software. The only way would be via hardware glitching attacks, or maybe by haxing a 3DS if it happens to have the full DSi BIOSes (noting that, ironically, the 3DS BIOSes were able to be dumped by software).

This means we run into issues like "decryption of X failed because the key is missing". We can work around them, but it's not as clean as starting from square one.

Oh well.]]>
melonDS 0.8.1 -- by Arisotura Wed, 12 Jun 2019 13:06:03 +0000
Edit- If fast forward doesn't work for you, it means one of two things: you're using OpenGL and your video driver is forcing vsync, or melonDS is just not running fast enough for fast-forward.

Input upgrade

The input code has been reworked to be more pleasant to deal with, especially with regards to adding hotkeys. In less nerdy terms, what does this mean?

It is now possible to map keys with modifiers, like Ctrl+Z or Shift+R or even combinations like Ctrl+Alt+Q. It is worth noting that during mapping, you should use left-hand Ctrl/Alt/Shift keys for these mappings. However, ingame, both sets of keys should work. This feature may not be too useful for DS input, but it should be more handy for hotkeys. It is also possible to delete a key mapping by pressing the Backspace key during the mapping process.

I have also been upgrading joystick support. You can now choose which joystick to use, and can map axes to buttons/hotkeys.

The twist to this is that I liked the old "axis maps to DS dpad" feature, and how it could be used alongside regular button/hat controls. I didn't want to lose the ability to use both, but I also wanted to make it, well, not a hardcoded mapping. So instead, you can map both a button/hat direction and an axis to each control. When mapping a joystick control, pressing a button/hat direction keeps the axis mapping intact, and vice-versa. You can delete both mappings by pressing Backspace during the mapping process.

The aforementioned axis support should also be able to support analog triggers, which are typically exposed as axis controls.

I also added support for multiple hat controls.


This new, optional feature shows some short, temporary status messages onscreen. For example, when loading or saving savestates, pausing, resuming...

The idea is to give some visual feedback about these operations, rather than, say, have savestate loads just appear to do nothing because the slot is empty.

You can disable the OSD if you find it to get in the way.

New hotkeys

You might remember that some early melonDS versions had a secret hardcoded fast-forward hotkey. This seems to have appeared in version 0.3, but eventually disappeared with the UI revamp in version 0.5.

Well, now, with Ace4896's contribution, this feature is back with a proper hotkey mapping. There is also a 'toggle' hotkey that enables or disables the framerate limiter.

I also added hotkeys for pausing and resetting emulation.

OpenGL fixes

Several of the crashes and rendering errors that appeared in 0.8, stemming from the new OpenGL support, have been fixed in this version.

I also added a little hack to support line triangles in OpenGL, and a preliminary implementation of edge marking, which you can see demonstrated in one of the screenshots above.

There's also a bunch of little fixes and optimizations, as usual. Enjoy!

melonDS 0.8.1, Windows 64-bit
melonDS 0.8.1, Linux 64-bit

If you're feeling generous, if you want to help us take this OpenGL renderer further: here's our Patreon]]>
Defying all expectations -- by Arisotura Mon, 10 Jun 2019 01:45:16 +0000
In particular, this issue: graphical glitches in iCarly - Groovy Foodie.

When it was posted, I didn't look much into it, thinking that was my topnotch software renderer acting up, and hastily giving it the '3D accuracy' label to put it on the backburner.

So I thought, hey, let's see if this is any different with the OpenGL renderer?

Which is where this bug started defying my expectations. Software or OpenGL, it didn't matter, the graphics looked the same. But, when I tested the game under DeSmuME and NO$GBA, they both exhibited the same bug.

Which is where I knew that we were in for an interesting ride. Typically, emulation bugs in melonDS are either specific to melonDS, meaning it's a flaw in my implementation, or they're shared with NO$GBA but not DeSmuME, which means that is some hardware behavior that was discovered by the DeSmuME team but did not yet make it into GBAtek. But with a bug that happens in every of these emulators, we know that we're stepping in uncharted territory.

So, as usual, we start by investigating how the game renders its graphics. The issue has nothing to do with 3D graphics at all, as it's not using the 3D engine. In particular, the glitched intro logo on the top screen is made of sprites, but looking at NO$GBA's sprite viewer shows there's something fishy behind this.

We only have a handful of the 16x16 sprites that make up the logo. Where's the rest?

Some logging confirms my suspicion that the game is updating OAM midframe. This is probably the last game where I'd have expected to see this kind of trickery, but hey, why not.

For example, as far as the glitched part of the logo is concerned, the OAM for the sprites is updated during the HBlank period right before scanline 30. However, the new sprite data gives them a Y coordinate of 31. Hence the glitch.

At this point, one can easily speculate that the OAM data copied right before scanline 30 is meant to be used at scanlines 31 and up. But hey, we can't just go and implement something based on an assumption. So, a few hardware tests later, we can confirm that sprites are rendered one scanline in advance. After implementing this behavior, and a few checks to ensure we aren't breaking anything, tada:

Hotfix release -- by Arisotura Sat, 01 Jun 2019 00:43:23 +0000
This should fix broken 3D rendering with OpenGL, namely for AMD/Intel GPU users.

Seems hotfix releases are a common theme with melonDS :P]]>
melonDS 0.8 -- by Arisotura Fri, 31 May 2019 22:11:23 +0000

So, without further ado, let's discover all the details of this.

The OpenGL renderer

This renderer is an attempt at targeting a sweet spot of, say, 90% compatibility while being fast. If you have read the previous posts about the DS GPU and how quirky that thing is compared to your average GPU, you guess that perfect rendering with OpenGL isn't going to be possible, but we can do our best.

The current renderer supports most of the DS GPU features, but not all of them. There is room for improvement, but certain features will just not be implemented. For the games that happen to require those, we still have our old trusty, nearly pixel-perfect software renderer.

But, the OpenGL renderer opens the door to all sorts of graphical improvements. I have plans in mind for more features (namely, some form of texture filtering), but I will draw a line as to keep the codebase not too complex.


The OpenGL renderer is enabled by default, but you can go to the video settings dialog to configure it. Namely, this renderer supports increasing the internal resolution to up to 8x the native resolution.

Note that changing the internal resolution does not change the window size, you will need to take care of that. However, changes from the video settings dialog apply instantly, so you can compare the various settings and select the one you like best.

OpenGL display

The 'OpenGL display' setting uses OpenGL to display the DS screens in the melonDS window. This has nothing to do with the OpenGL renderer directly. However, it is forcibly enabled when using the OpenGL renderer, as the two work fastest when they are together.

OpenGL display can be used with the software renderer. You don't get upscaling, but you can, for example, enforce vsync via driver settings this way. Also, for now, screen filtering doesn't work with OpenGL display, but there are plans for filtering methods that would work with both renderers and provide amazing results. We'll see how far we can get on that front.

The alternative to OpenGL display is the old method that has been used by previous melonDS releases. Direct2D under Windows, cairo under Linux.

Take note that the 0.8 release is a bit of an experiment. Basically, we tested it before release to ensure the OpenGL renderer will work, but we can't cover every setup that exists, so it is likely that there will be issues arising either from crummy programming on our part, or from crummy OpenGL drivers. So, if you have any issue with this, let us know!

melonDS 0.8, Windows 64-bit
melonDS 0.8, Linux 64-bit

If you're feeling generous, if you want to help us take this OpenGL renderer further: here's our Patreon]]>
Getting there! -- by Arisotura Fri, 31 May 2019 02:56:34 +0000

OpenGL output under Linux! About fucking time.

Was it a ride to get there, though.

As I explained in a previous post, the first attempts with a GtkGLArea were a trainwreck. GtkGLArea is nice and all, but it's really limited in how much control you have over rendering, compared to, say, the Windows equivalent (get a GL context for any HWND and do whatever you want).

For one, GtkGLArea provides no control over its GL context, other than "make context current now". No way to unset the current GL context, which is important in melonDS. Even though all the rendering is done in the emu thread, we do need to unset the GL context at times, because when changing video settings we do reconfiguration from the UI thread, and said reconfiguration involves GL calls.

But, well. You may already know that GTK isn't thread-safe. As such, GtkGLArea really isn't designed to be used outside of the UI thread, or outside of one particular way. So, unless we rewrote melonDS's rendering system, this would have never worked. Besides, the emu thread is distinct from the UI thread for a reason -- I'm reluctant to having any work that may affect emulation done on something as uncertain as the UI thread.

So, I began researching.

And, now, the melonDS company proudly presents the result of all that research: the DIY GL area.

Basically, I decided to directly use GDK's GL context API to get the level of control I needed. With this, you don't need a specific widget type, you can create a GL context from any GdkWindow (which you obtain from any realized GTK widget). You can then use the function gdk_cairo_draw_from_gl() to draw your OpenGL output to the widget.

So I'd basically replicated the GtkGLArea, which in itself simply wraps around the aforementioned API. It's a simple framebuffer that you point OpenGL to, and that you resize as your widget gets resized.

There is still one issue: when using GL contexts, GTK will issue GL calls when rendering the area widget, and will do so internally, before calling the widget's draw handler. This is a problem if these calls are issued while melonDS's emu thread is also issuing GL calls. To avoid this, I had to resort to some trickery: melonDS's GL calls are wrapped in a critical section, and I used a custom GDK event handler to wrap any GTK draw events in that same critical section, before GTK starts issuing GL calls. This way, only one thread can be doing its GL work at the same time, and we avoid potential shitshows.

In reality, this took a while to get working, but, here we are. OpenGL output under GTK, stable and fast, and without needing to rewrite melonDS's rendering system.

Oh also, this supports hi-DPI! Provided you have a good GPU and not too shitty drivers, you get hi-DPI OpenGL graphics, and that sure does look nice.

There are still some tidbits to fix (like, some bugs in fog that appeared after I had to made a fix for Intel drivers), but we're way close to a finished product here.

I will also try to see if I can make hi-DPI work under Windows, too.]]>
BLARGRARAAAAAAA -- by Arisotura Mon, 27 May 2019 21:45:35 +0000 ]]>