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:1···8910111213141516171819
Timing renovation, ep 4: world of shit
Dec 6th 2018, by Arisotura
Took a while, but I have finally implemented the new memory timings, atleast CPU-side. DMA is not done yet, but will be quick to do.

Noting that these timings, atleast ARM9-side, would still be faster than the real thing, mostly due to not emulating cache misses and a lot of other little things. But it should be a lot closer.


And, how does that fare?

So much for that.

For now it's a total fucking trainwreck. Everything is running too slow and there are quite a few issues with it. For example, Rayman DS is slow as shit.

And even worse, the Millionaire FMV bug.

As it still happened, I extracted the FMV decoder code to run it within a test app. So it runs within the same conditions: code in ITCM, data it accesses in mainRAM, cache enabled over similar regions, etc.

What's the result? On hardware, the decoder is taking ~724 scanlines to run. Which means it actually spans over several frames, and, since it's set to start upon VCount=20, by the time it would be done, VCount would be 218. Which is past scanline 214, so under these conditions, we would be getting glitches on hardware too. And yet, the thing runs fine on hardware.


I don't fucking understand it.

... read more
2 comments (last by Arisotura) | Post a comment
Timing renovation, ep 3: the new GX timings
Nov 24th 2018, by Arisotura
So, this is it. GX timings are covered.

After days of feeding specific command lists to the geometry engine, measuring how long they take to run, and trying to figure out the logic behind it, we finally did it. And implemented it in melonDS.

Have yet to write a post to get into that in detail, but that will go on the board.

I believe it was definitely worth it.


Looking at history, it is apparent that first-gen DS emulators have run into issues caused by display lists taking too long to execute, despite following the timings given by GBAtek. When measuring their timings, we can guess that they went for the easier solution and lowered their per-command timings. Nothing bad with that, if it gets games running, and gets them running at better speeds on lower-end platforms, but that ain't accurate.

In a less "accuracy horseman" note, we'll quote byuu's article on accuracy, again:

If you do not get the timing perfect, you will end up playing a perpetual game of whack-a-mole. Fixing one game to break two others, fixing them to break yet two more. Fixing them to break the initial game once again. You need only look at the changelogs over the past fifteen years to verify this.

You might not end up needing absolute perfection there, but history has shown that, if you don't have the basic logic down, hacking around timing issues can only get you so far.

A prime example may well be Burnout Legends, which JMC47 mentioned in his blog post The next generation of DS emulators. The game seems to have built-in frameskipping or slowdown compensation, but it's not working correctly on emulators, resulting in random slowdowns or speedups.

I haven't looked into this game in detail, though, so I don't know for sure what it's doing.

... read more
4 comments (last by poudink) | Post a comment
Happy birthday, albeit late
Nov 23rd 2018, by Arisotura
It turns out that melonDS is two years and 20 days old, counting from the first serious commit. So:



Too many candles there? Nah! That's just the melonDS company being generous.


So, the usual bit of retrospective. We're not going to repeat the whole history, you can read that on the one-year post.

Anyway, reading the DeSmuME commit log shows that they're trying to play catch-up.

Ironically enough, they finally took their wifi system out from behind its EXPERIMENTAL_WIFI wall, and exposed the settings to their users. They even went as far as fusioning the old 'adhoc'/'infrastructure' modes (basically selecting between nifi/local and internet/WFC), akin to melonDS where the setting just doesn't exist-- it's always running both modes at the same time.

A few notes on that, for those who are interested into DeSmuME altWFC:

* You need a recent DeSmuME build, such as those produced by their buildbot. Not the 0.9.11 release from 2015.
* It functions the same way as melonDS, you need libpcap and an Ethernet connection.
* They haven't yet been fixing the underlying issues in their wifi stack or maybe even emulator core. For example, Mario Kart DS races don't work, while they do on melonDS. (I do not know what causes the issue in DeSmuME though, haven't faced it at all in melonDS, so I can't help there)

However it is nice that they're finally reconsidering their stance on what was largely my work, and giving it some spotlight.

... read more
10 comments (last by Arisotura) | Post a comment
Fun with custom WFC servers
Nov 18th 2018, by Arisotura
PeeJay Bonobo and his friends have been having some fun with melonDS and custom WFC servers. For example:



So, what do we learn from this?

• This is some pretty cool shit!
• Graphically, melonDS is hardly distinguishable from the real thing
• The wifi stack is also fairly robust! There are no stability issues. Although this is less demanding than local multiplayer (nifi).
• They managed to get this experimental, undocumented feature working.

So yeah, that last point.

Local multiplayer was celebrated and widely advertised, despite suffering from data loss every now and then. But internet connectivity was later implemented but never mentioned in any changelogs. There was only this thread mentioning it.

Reason is that this feature is unfinished. Most of it is actually coded, and it works, but it's nowhere near where it ought to be in terms of user-friendliness. It was more or less a quick hack, and was hardcoded to use the second network adapter (whichever that is), because that was what worked for me at the time. It also only works if your computer is connected via ethernet.

The first part just requires building up the UI for selecting a network adapter. As well as some extra code for naming them, atleast under Windows: winpcap provides a 'name' and a 'description' for each adapter, the former is some GUID-like identifier string and the latter seems to always be 'Microsoft', so, not too user-friendly. I will have to dig into the Windows API to look for a better method. Haven't checked under Linux but you probably get names like your typical /dev/eth0, which would be good enough.

Second issue is due to the way this works.

... read more
8 comments (last by whattheheckman) | Post a comment
Bugfix0ring streak
Nov 7th 2018, by Arisotura
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
3 comments (last by Arisotura) | Post a comment
The DS GPU and its fun quirks
Oct 27th 2018, by Arisotura
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
16 comments (last by HELLO) | Post a comment
Quick bugfix update for Windows
Oct 27th 2018, by Arisotura
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.
3 comments (last by Arisotura) | Post a comment
melonDS 0.7 -- Granting popular wishes
Oct 26th 2018, by Arisotura
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
7 comments (last by AsPika2219) | Post a comment
Coming soooooooon!
Oct 24th 2018, by Arisotura
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!
4 comments (last by swagmaster) | Post a comment
When your innocuous little code goes kaboom
Oct 18th 2018, by Arisotura
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
2 comments (last by Anonymous) | Post a comment
Pages:1···8910111213141516171819