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.
friend says:
Jan 31st 2021
Hey friend, you seem a little tired. We all appreciate you, and not only your work Thanks for everything. This last year has been horrible for everyone, don't feel bad for feeling down. Good luck feeling better! Much love <3
ScaryCactus says:
Jan 31st 2021
I for one love your emulator and hold it above anything else. Yes the OpenGL is fucky with the Pokemon games I play. But damn that full screen mode keeps be playing. Thank you for all the work.
Nixel says:
Jan 31st 2021
I've been checking the github occasionally, and it always brings a smile to my face when there's been progress, no matter how small. Even when progress is slow, it still adds up. There's already a lot to look forward to in the next update, and I'm definitely excited!
ILoveBra says:
Feb 1st 2021
MelonDS was the one who saved my life during the long terrible time of covid19 pandemic.
Just want to drop by and post something to cheer you up.
I haven't got any request yet because right now MelonDS seems perfect to me even on a handheld PC that uses Core-M (Rockman Zero Collection, Dragon Quest V, Castlevania games on DS, etc)
I actually think further that MelonDS is the only one who pushes forward the DS emulation for this world to be honest. (Off course, Drastic too, for making DS emulation on Android possible)
pikkafan says:
Feb 1st 2021
I will always be thankful for this emulator. Thanks a lot.

You can always take a break. Progress is progress but you need to find a balance.
Good luck
IUnknown says:
Feb 1st 2021
Take it slow. Go step by step, like when you're debugging a random bug.

If you feel there's still much left to do, just stick to one thing.
Get bored with it for 8 hours? Get a refresh.

A solution came to your mind? Go for it again.
Else? Work on something else that interests you or that you think it could use more work.

Got bored/tired trying to figure timings?
"Screw it! I'm gonna watch a movie/play something worthwhile. Maybe I'll ask for help later."
Next day...
"Ah! I feel like working on the software GPU. Fixed a bug! Yay!
Now how would I do this other thing on the compute-shader renderer? Let's see..."

MelonDS has been progressing well and is promising, but do not over do it.
chainswordcs says:
Feb 1st 2021
You and your team have made incredible progress in this emulator and in DS emulation as a whole. Properly figuring out those little quirks does add up, and of course it's absolutely fascinating too. Keep it up, but it's okay to work at your own pace at least in my opinion.
Mew3 says:
Feb 2nd 2021
You have made the best DS emulator ever. Take the rest all you want.
It's not a compulsion you can work whenever you feel like.

Hey have you tried meditation? I have paid subscription(android) which I am willing to share.
MmM says:
Feb 2nd 2021
"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."

While all of this is true for pretty much any system with anything that you can call "real GPU", can't you try something like MAME did to improve performance while still making use of hardware acceleration? They're moving some parts of the software rendering to the GPU, so you'll still be running the software rendering but instead of bottlenecking the CPU you're actually using the GPU (that in some aspects will be faster anyway).
Generic aka RSDuck says:
Feb 2nd 2021
that's basically what Arisotura is describing in the paragraph following that. On that topic I've started working on something just like that. Though who knows how well (or for that matter whether at all) it will work.
MmM says:
Feb 2nd 2021
Would this be an "all or nothing" implementation? I remember that on MAME they could implement software rendering even for some specific effects running from the GPU, like a partial approach. Not sure how does this improves (or makes it worse, on the DS case) performance, maybe being partial here would make it even worse ;-;
Generic aka RSDuck says:
Feb 2nd 2021
ideally all the graphics work is done on the GPU. Otherwise you get something like desmume which doesn't really utilise the versatileness of modern GPUs and so it processes data coming from the GPU on the CPU. This is the desmume gets so much slower when rendering at higher resolutions.

In terms of performance melonDS's software renderer is fast enough. The only reason we want to use the GPU is for enhancements like higher resolutions rendering (and the exception, Switch which has the rare case where the graphics hw is relatively competent while the processor is pretty slow).
^.^ says:
Feb 3rd 2021
To me, this is already one of the best emulators I know, so don't beat yourself too hard ;)
For the DSi NAND: the Nintendo Update Servers (NUS) should still be online, so theoretically one can use those files to build a working system menu by only proving the keys and bios...
^.^ says:
Feb 3rd 2021
Or if that isn't online, maybe you can use the TWL firmware as a base...
nine says:
Feb 4th 2021
I think openGL even with compute may offer diminishing returns. It might be time to start a vulkan renderer and make one pipeline to be accurate AND fast. Dave Airlie has a software vulkan rasterizer called lavapipe that can both act as reference implementations of vulkan functions and a debugger.
Post a comment