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.
Generic aka RSDuck says:
Feb 4th 2021
with compute OpenGL the difference in API overhead is really small as there are very few state changes, feature wise there is pretty much no difference either. In the end it will be bottlenecked by the GPU's shading performance either way.

Also we're dealing with 2048 polygons at max. We could use a single draw call for every single one and it would still be ok. But on that topic someone's trying to write a Vulkan renderer for melonDS.
zedfireblast333 says:
Feb 6th 2021
They Are a Great Team Working In This Emulator. Melon DS 1.0 Is Great And Will Amaze You
Anon says:
Feb 7th 2021
Honestly, I'm a little delirious from travel, but I think you should take a loooooong break.You sound desperately tired.

I check back on this emu almost every time when I'm free, and it keeps fascinating me. I truly believe that the golden era of DS emulation is dawning on us. Gone will be the days of lagging black screens. And you've truly made that possible.

I think you should ditch the OpenGL renderer if better ones are available. It keeps glitching on all of the games I play, and the software renderer is nearly perfect, so I never bother with OpenGL. It doesn't really make much of a difference upscaling the games I play, even on "mature" emus like DeSMuMe. Scanline filters would be really cool, and same with better BIOs and upscaling options.Also custom hotkeys.


Chill. Literally no one has a goddamn grip on themselves, least of all in the past year. You almost always have an update like "Sorry for not updating" like come on, we can wait.

Take care of yourself out there.

Peace
extherian says:
Feb 8th 2021
The lack of texture upscaling (e.g. xBRZ) is the only remaining shortcoming of melonDS compared to DeSmuME. The OpenGL renderer may have its issues, but for the first time ever it's possible to render Nintendo DS games at 1080P without requiring a CPU clocked at 6GHz or something crazy like that. You've done a great job, and the arrival of so many DeSmuME contributors to your project says a lot about how good it is.
poudink says:
Feb 8th 2021
The only remaining shortcoming? Not quite. DeSmuME has TASing tools, debugging tools, lua scripting support, video/audio dumping and more. Those are more than enough reason to still keep it around. Also the only DeSmuME contributors I can think of that became melonDS contributors are Arisotura herself and SuuperW.
kevincrans says:
Feb 12th 2021
@Arisotura, for shaderzorz, here is an old post from me recalling quadrilateral patches/meshes:
Opengl 4.0: https://www.nvidia.com/content/GTC-2010/pdfs/2127_GTC2010.pdf
Directx11 Tesselation: https://developer.nvidia.com/sites/default/files/akamai/gameworks/CN/CGDC2010_TessellationTutorial_en.pdf

Furthermore, I suspect nintendo used Nec/Renesas ARM since the GBA and DS (and Wii), the graphics sounds like the old ancestor of PowerVR (AMD only has stakes in home consoles).

I've got adhd, depression (in treatment) and no motivation at all, I only wanna help, since it's never easy.

I think we should all thank you ppl for everything!
Kevin says:
Feb 14th 2021
Lo podrían hacer para Android plis
AsPika2219 says:
Feb 15th 2021
Don't worry! Be happy! 😊 Thanks for making nice emulator! I hope more better than Desmume, No$gba etc... Stay safe from covid attacks. Vaccine will comes soon. 💉 Have a break, have a Kit Kat! 🍫
EFGHIJK says:
Feb 17th 2021
Maybe you can figure out by checking how the TWiLightMenu did it, though this one runs on actual dsi but it can load dsiware from SD Card.
happygreenfairy says:
Feb 23rd 2021
Hey, take things at your own pace. I'm pretty dang excited this can even boot DSi stuff at all honestly, if it's another few years or so before that's all figured out, I feel it'll still be worth that kind of wait in my opinion. Motivation can be hard, I should know, so if you need a few weeks or however long to yourself until you can get that kind of creative spark again, well, we'll still be here to cheer you on.
anonymoose says:
Feb 26th 2021
Have you tried talking to the Twilight Menu++ devs about DSiWare? You can run DSiWare off of the SD card using their CFW and Twilight Menu, maybe they might be able to shed some light on DSiWare running on something that isn't the NAND.
CoolDog420 says:
Feb 27th 2021
Hey dude, idk about ds emu stuff but I just wanted to let you know that you've done an awesome thing for this community and for people who are nostalgic for these wonderful little games. If you're feeling burnt out and depressed, it's more than okay to take the phone off the hook and disappear for a while.

Peace~*~*~*~*~
Post a comment
Name:
DO NOT TOUCH