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···101112131415161718192021
melonDS 0.7.2
Dec 16th 2018, by Arisotura
The melonDS company celebrates Christmas! Albeit one week early. But this new release of melonDS is a neat little pile of presents.

You have already gotten a glimpse of it, but let's go over all the changes since 0.7.1, because it's been a fast week.


So first of all, the issues we have seen pop up in NSMB, Pokémon, or Etrian Odyssey after the timing renovation, have been fixed. Nicely, the new timings uncovered some stealth GX bugs that would surely have bitten us another day under other circumstances.

So the claim that was made for 0.7.1 ("now your games run better than ever") is finally more than a phony advert :P


Second big thing is, as you probably guessed by now, microphone support. If your machine has a microphone connected and if you are using SDL 2.0.5 or more recent, you can blow or blare bullshit into it and it just works! If that is not the case, you can also opt to feed a WAV file or white noise as microphone input.

Note that this feature is still experimental. Quality of microphone input may not be optimal, especially when using a physical microphone. WAV input works better.

WAV and white noise modes send input when pressing a microphone hotkey (default is the key right next to right Shift, '?' on QWERTY keyboards). WAV mode can take any reasonably small file, encoded as 8-bit or 16-bit PCM, signed or unsigned, any number of channels (it will read the first channel).

All this can be configured in the new audio settings dialog, where you can also set the volume for audio output.


Which brings us to the new hotkey system. For now, aside from the aforementioned mic hotkey, there is only another one: 'Close/open lid', which simulates closing/opening the DS. Default key is Backspace.

... read more
15 comments (last by Mauricio) | Post a comment
I am fucking relieved
Dec 15th 2018, by Arisotura
You might already know that 0.7.1 sports all new timings and that it also causes a few issues that were not present in 0.7. Ranging from NSMB's cannons putting on some weight to Pokémon characters getting magical growth to, less amusingly, dual-screen 3D shitting itself in Etrian Odyssey.

The NSMB and Etrian Odyssey issues also had the fun aspect that they didn't occur in the USA ROMs, for some reason.

Well, that's a thing of the past now.

I knew the issues appeared after the timing renovation, but that was about it. I figured that instead of blindly hodgepodging timings until the issues disappeared, and potentially getting into some whack-a-mole game, I would take the time to understand the issues.


So the first one was the NSMB cannon.

Technically, the cannon body is a billboard (3D sprite that always faces the camera). The 'big' version is just the same but with the cannon body scaled too big.

So I investigate how the cannon body is rendered. For that, we can use NO$GBA's debugger version, atleast until melonDS gets similar tools :P

Conveniently, the cannon body is the first polygon in the display list. Before it gets rendered, there are some transforms set up so it will face the camera. In this case, the second-to-last scale transform sometimes got wrong values that caused the billboard to appear too big, hence the bug.

So I look into the game's code to find out where and how that scale transform is calculated. Noting that debugging NSMB is made way easy by the awesome folks at the NSMB Hacking Domain who have a complete IDA database of the game.

... read more
5 comments (last by extherian) | Post a comment
Sneak peek
Dec 14th 2018, by Arisotura
New feature of melonDS 0.7.2, among a nice little pile of other features and fixes:



I'll let you guess ;)
7 comments (last by Arisotura) | Post a comment
melonDS on the Nintendo Switch
Dec 13th 2018, by Hydr8gon
What's this?

In case you didn't know, melonDS has a port for the Switch. And it's made by me!

It's actually been around for a while now, but just today I put out an update with a major UI overhaul. As in, it actually has a UI now.

For the longest time the port was just text-based, with few options and it ran like crap. I just did it for fun, and because melonDS was surprisingly easy to port. A couple weeks ago we gained the ability to overclock the Switch, and this let melonDS actually reach playable framerates for a few games!

Normally overclocking is scary, but not so much on the Switch. The Switch rocks an Nvidia Tegra X1, the same processor used in the Nvidia Shield TV. Maybe to save battery life, or maybe to prevent overheating, the Switch runs at about half the clock speed of the Shield by default. Since melonDS isn't GPU intensive at all, the cooling of the Switch is plenty good enough to handle the higher clock speed on its own for emulation.

So now that that's a thing, melonDS on Switch seems to be more than just a novelty. It seems like it could actually become a usable NDS emulator! Unfortunately the UI is still shit. So I built a UI with OpenGL that resembles the UI of the Switch itself.

It's not much, but it gets the job done. On top of that I added all of the screen layouts available in desktop melonDS for some extra fun. Aside from a few minor things, melonDS for Switch is now at feature-parity with core melonDS, and it doesn't look terrible, either.

So what's in store for this project?

Well, since the UI is more or less finished, the plan from here on is to keep the Switch version up-to-date with core melonDS. Once the hardware renderer comes along in 0.8, it'll likely be able to run most, if not all, games at full speed. I'd also love to help StapleButter out with the core project, although my expertise in writing actual emulation code is extremely limited.

... read more
13 comments (last by thewickest) | Post a comment
melonDS 0.7.1 -- here it is!
Dec 11th 2018, by Arisotura
As title says.

We're not showing screenshots because they wouldn't be a good medium for conveying the number of changes in this release.


The biggest change here is that the core timings were entirely renovated to try being closer to the hardware.

First of all, after several days of gruelling testing and guesswork, we were finally able to understand the GX timings, and emulate them properly for the first time. But, as we weren't gonna stop there, we also renovated the timings for DMA and memory accesses, so that both of them are closer to their hardware counterparts. DMA and ARM7 should be pretty close to perfection now, ARM9 less so but it's still more realistic.

We have also been fixing the emulator's main loop, so that the ARM9, ARM7 and system clocks shouldn't desync anymore.

All of this, with a few added optimizations, fixes a whole bunch of issues, from things flickering to audio crackling to games outright going haywire (hi RaymanDS). Your games are now running better than ever!

... or not. That's also the point of the 0.7.1 release, I want to hear about any issues caused by the timing renovation, so we can get them fixed for the epic 0.8.

We already have one such issue, all of this is causing sprite flickering in Pokémon Platinum. Quick attempts at fixing this went nowhere, so we will have to investigate this proper.


There's also a number of misc fixes. For example, the 3D glitches that showed up in Mario Kart DS were fixed, but there's already a lengthy post about this.

... read more
12 comments (last by Dante Seal) | Post a comment
Update
Dec 7th 2018, by Arisotura
I had a few bugs in my implementation. After fixing those, the timings I got were closer to what it should have been. Too fast, but way too fast.

Anyway, I had issues with my test app too. One of the memory buffers it accesses was in main RAM instead of DTCM; fixing that oversight gave me more realistic timings. In reality, the Millionaire issue was what I first thought-- on hardware, the FMV decoder completes in 146 scanlines, and I was being too slow.

So, obviously, fixing the timings made it fast enough that the glitch was entirely gone. But, aside from that, we were back to square one: running too fast and the issues it causes everywhere. Rayman DS is a good test for that, and it was shitting itself big time, so... yeah.

If we raise the cached memory timings to 2 cycles, as some sort of average between cache hits and cache misses, we get closer to the real thing. Still a bit too fast, but this time Rayman DS is running normally.


However...


The new timing logic, coupled with PU emulation, is a pretty noticeable speed hit.

We can keep the PU logic for a potential future 'homebrew developer' build, that would also have several features to warn against typical DS pitfalls. For example, some form of cache emulation and/or warning about things like DMA without flushing/invalidating caches, 8-bit accesses to VRAM, etc...

If there is demand for such a build, that is.

As far as regular gamers are concerned, we can go for a faster compromise that would run most of the shit (really most of it) well. It wouldn't run things like GBA emulators that make extensive use of the PU, but... eh.

... read more
2 comments (last by Arisotura) | Post a comment
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
Pages:1···101112131415161718192021