Been silent lately...
Winter depression and covid shito don't help, gladly we'll soon be getting more sunlight, so there's atleast that.

Anyway, you may have observed I haven't been doing a lot for melonDS lately... there are a couple reasons to that, besides that side project of fixing up vintage Macs and other shit.

I don't want to abandon melonDS, it's my project, but it's true that I have less interest into it at this point. Things like emulating new hardware features and hunting emulation bugs interest me much more than, say, UI shenanigans. As far as these things go, I tend to just accept work from other contributors, sometimes to the point of them becoming fulltime members of the 'melonDS team'. It's better this way, after all; as I say, an emulator project is like a tree: once you're done with the trunk, it branches off in a billion directions.

So, what can we attempt doing now?

I've been idly trying to figure out why DSiware will only load when installed on the NAND. So far, haven't gone very far with this, mostly because, well, my motivation tends to be an all-or-nothing thing. Either get the spark and find yourself coding until 5:00, or have a hard time doing anything at all. Also, working with the DSi firmware is a real pleasure: it's a huge spaghetti network of threads and callbacks and shit, making it a massive pain to track anything, even moreso when all you have is a bunch of ARM ASM.

From there, there would be two possibilities: a quick hack to bypass whatever check the DSi firmware uses, like we do for the region check, or actually installing the provided DSiware into the NAND. The latter implies dealing with an encryption layer and a FAT filesystem, which I can't wrap my head around. We'd need to get a good lil' FAT library, but then this would open more possibilities regarding DSi emulation.

Then there are the remaining popular-request items, and the big pile of issues.

For example, a looooot of the issues are with the OpenGL renderer. This is why I stand for emulating things accurately: you are far less likely to run into constant issues and get yourself caught into a game of whack-a-mole perpetually hacking around issues. While things like the OpenGL renderer are creative and cool, we have seen countless times that the DS GPU is a pile of quirks, and that emulating it correctly is only possible with somethings like our software renderer. We can keep coming up with creative solutions to try and fix OpenGL issues, but at some point there is only so much we can do when using a fundamentally inadequate tool.

An alternative may be unearthing my old 'shaderzorz' experiment: that was an attempt at a compute-shader rasterizer that worked similarly to that of the DS. Such a renderer, implemented either in compute shaders or in fragment shaders, may be able to get around the shortcomings of the current OpenGL renderer, and maybe also support higher-resolution rendering without too much of a performance penalty. Back then, I ended up ditching it in favor of a classical polygon-based renderer because I wasn't positive about the performance. However, the current renderer is far from optimal too, due to how rendering has to be done.

So, we might offer such a renderer for platforms that support it, and keep the classical renderer for the remaining users, but we would have to accept that the latter will remain imperfect.

There are also the timing issues. The holy grail of DS emulation, I guess. This, like several of the other things I have in mind (hi pixel-perfection), is pretty much a high-effort low-reward item.

No hacking around timings will get us really far if we don't have the logic down. Thus, we would need to work out the CPU timings, how memory waitstates for code and data regions interact for each instruction, and so on. Only once we have the general logic down, could we try implementing a model efficiently, and then seeing whether such a model can work with estimated cache timings, or whether we need actual cache emulation. Until then, no real point attempting to emulate the ARM9 caches if our base timing logic is off.

Another thing that would definitely be good for user-friendliness, would be making melonDS plug-and-play: basically, not requiring original BIOS and firmware.

As far as DS mode is concerned, it's possible to use DraStic's alternate BIOS (even though I would like to make my own eventually). Building a basic firmware image would also be doable, obviously it wouldn't come with the DS menu, but it would be enough to run games. We would just need to provide an interface for changing the firmware config.

DSi mode would definitely be trickier. It requires a NAND dump, and I haven't looked into how feasible it would be to craft a working basic NAND. We haven't even looked into DSi-mode direct boot yet, and that would definitely be a requirement.

Then there is the good ol' wifi quest. Not sure how far we can get there...


I want to be there for melonDS 1.0. That's going to be one big release :)

Maybe I originally wanted to write about more things? My brain is running out of fuel. Oh well.
space says:
Mar 17th 2021
just seeing this. you've done good work. if you abandon this project, consider making it open source for us. maybe someone'll pick it up while you move on to better things
Rayyan says:
Mar 18th 2021
space: melonDS always has been open-source. The sources are up on GitHub.
Speechless says:
Mar 20th 2021
Hi i'm having trouble downloading a mod. The guy told me to download the mod through this website on youtube. But I needed to put in the download through a melon ds folder then put it in an sd card then put in in to the dsi. I was wondering if you can help me?
edit: I don't really know anything about mobs soooo...
TT says:
Mar 22nd 2021
Just wanted to let you know the extent of my excitement when I saw recently that melonDS was updated as a retroarch core for android, and now allowed for close to full speed and stable emulation on the platform. Been enjoying some of my favorite classics since then, and I want to thank you and the 'melonDS team' for that.
Xnonymous says:
Mar 22nd 2021
You and the team have done outstanding work with the emulator and can't wait for more content to come out for it, if debugging features come to the emulator then that would be something im certainly ill be super hyped towards for ^-^
aNON says:
Mar 22nd 2021
It never fails to amaze me how many people seem to think melonds isn't open source. It's licensed under the GPL, always has been, it is a glittering example of libre software. The only non-free DS emu I'm aware of is Drastic. What people don't seem to understand is that open source isn't a magic word that makes software eternal and awesome, that even in FOSS, only *very few* people ever contribute, specially in relation to amount of users. In the off chance that the project is aimed at a highly technical audience also capable and willing to contribute, and a dev team to match, does an open source program get the ideal "FOSS"ness. Like Linux in the early days. Unfortunately, not that many people are that interested in DS emulation, though the scene is rising from the dead. I expect a sort of Renaissance by late 2021, but I'm being optimistic. (Btw highly recommend The Cathedral and the Bazaar by Eric Raymond, it's available for free and it's kinda fun to read now :p. It was written before Firefox was even a thing, and it boggles me how spot on he was.)
aNON says:
Mar 24th 2021
Edit: Eric S Raymond is a piece of festering garbage when it comes to his political views. The essay is kinda good though.
Post a comment