melonDS RSS The latest news on melonDS. hi -- by Arisotura Thu, 25 Jun 2020 04:22:05 +0000 The new wifi adventure -- by Arisotura Sun, 21 Jun 2020 16:19:18 +0000

Basically, it all started with a new branch called slirp. What's that, you ask, another of Arisotura's oddball noises?

Nah. If you followed the melonDS history, you know that a while back, support for internet connectivity was added. It was pretty similar to how DeSmuME did it back then: providing a basic emulated access point to connect to, then forwarding outgoing traffic via libpcap.

While it was straightforward, it had its lot of issues: it required installing libpcap (or any Windows equivalent), required admin/root privileges, and, more annoyingly, did not work over wifi connections, as explained here.

Eventually indirect mode (aka LANMAGIC) was developed to get around this. The basic idea was to emulate a local network and use simple BSD sockets to forward outgoing traffic to the host network. The idea was good, but the actual implementation was more or less a pile of hacks that never really worked right.

Enter the slirp branch. Basically, QEMU's libslirp does exactly what LANMAGIC clumsily tried to do.

So I reimplemented indirect mode using that. Took a while to figure out how to use libslirp, as it isn't really documented, but we got there, and it works beautifully.

More notably, this is how we like it. Unlike direct mode, it requires no setup, it Just Works™. Over any sort of connection, without any special privileges, ...

Then I got carried away and began implementing features of the DSi's new wifi device. From there, you can see how this ended.

The DSi uses this new wifi device when connecting to the internet (local-multiplayer type connections use the old DS wifi device).

Alas, due to being a few years late to the party, there isn't much to do anymore. You can try using the DSi browser, but it won't be able to load a lot of websites successfully due to how limited and outdated it is. This site works fine... somewhat.

I was also able to update my emulated DSi to the latest firmware version, 1.4.5E. It doesn't do much, but it's working without issues, so there's atleast that.

Connecting to the DSi Shop gave me some weird undocumented error code. The logs showed that it was trying to use AES-CCM encryption, which was unimplemented. As I had already taken care of CCM decryption and verification, I could implement encryption quickly. Then I was able to access the Shop, from which you can download the 3DS transfer utility, and, well, nothing else.

Atleast these features are emulated, in case this can help spark new initiatives in the field, akin to AltWFC. Although things like custom DSi Shop servers would pose obvious copyright problems, unless they only distributed homebrew...

Regarding the old libpcap-powered direct mode, I'm thinking of retiring it. Perhaps not for 0.9, but later for sure. It might stick around for debugging purposes, but it has little advantage for the average joe if libslirp works just as well and is more flexible and easier to setup.

Regarding directions to take now, I have several ideas.

An interface for editing firmware settings. We could atleast make it work for DS mode. It would also allow you to change the console's MAC address, mostly to make up for the fact we're removing MAC randomization.

We also need some FAT library that can access files inside a FAT image. One of the purposes would be accessing the config files inside the NAND (which, below the encryption layer, is mostly a FAT filesystem), so we could edit the DSi-mode firmware settings too. We could also patch the touchscreen calibration data, like we do for DS mode (might also make that feature optional?).

Being able to generate a FAT image from a given folder, and maybe reflect changes to the actual files, would be perfect for things like the DSi's SD card, or DLDI. Not sure what is possible there, but we'll see.

I also need to finish the cheats feature. Dammit, considering all these things you see are popping up because I'm procrastinating on that.

Either way, this has been a fun ride.]]>
BAAHAHAHAHAHAHHHH -- by Arisotura Sat, 20 Jun 2020 23:18:46 +0000

melonDSi has been merged -- by Arisotura Tue, 02 Jun 2020 02:15:44 +0000 clunky DSi experiment branch. Over time, it became more capable, but it still felt really crusty. It was basically stuck in DSi mode, hardcoded all around, didn't work that well, and was based off what became an increasingly obsolete version of melonDS as it was put on the backburner in favor of other fronts.

But that is past now.

I wanted to get it ready for the JIT merge, so I set to work. First off was merging recent melonDS into it, which went smoothly. It was a great sight to see the DSi menu come to life inside the new Qt UI.

Then, in a couple days, the SD/MMC issues were fixed, such that for example Flipnote can now save without softlocking. I then decided that would be a good base, and cleaned it up. Basically, I de-hardcoded it, allowing it to switch between DS and DSi modes, changing how DSi-mode assets are loaded, all that.

And now, there it is, DSi support is part of the master branch.

Couple notes on this:

* It was reworked to require less files. Namely, aeskeys.bin, initmem7/9.bin and boot2_7/9.bin are no longer required. However, it now requires 'augmented' BIOS dumps, the same ones that NO$GBA requires. I intend to provide an appropriate dumper.

* The location of the BIOS/firmware/NAND files can be configured.

* It is able to run both DSi and DS games from the menu. For some reason, some will fail to load, giving that error screen.

* Direct boot is not supported yet under DSi mode.

* The current DSi emulation is more or less a base. Cameras, DSP, new wifi, etc... aren't supported yet.

* There is a hack in place to bypass region locking.

* DS games loaded via the DSi menu run in more-or-less-DS mode. Right now, some details like clock switching or RAM size aren't supported. Most games seen to run fine under these conditions, but some may run into issues.

* If you want to try out DSi support, I recommend that you keep a backup of your NAND dump.

* Savestates are not yet supported.

Next up is the JIT merger, Generic will keep you informed about that!]]>
#BlackLivesMatter -- by Arisotura Sat, 30 May 2020 13:30:34 +0000

Other than that, little status update on melonDS. We're going to merge the JIT branch for 0.9. I figured that it would be easier to merge the DSi branch first, so I've been updating it. I'm going to clean it up some and fix a few things to make it good for a release.

The Qt UI is also nearly complete. All that remains to be done is the cheat interface and taking care of VSync. The other issues have been solved, including the one where the final executable required 25 DLLs -- by using the qt5-static package for MSYS2, I managed to get it down to a standalone executable that is about 21MB in size.]]>
Sneak peek of melonDS 0.9 -- by Arisotura Thu, 21 May 2020 19:20:04 +0000

So, first of all, the whole 'new UI' adventure.


At this point, it's been what, four total UIs melonDS has had, counting the one being made.

The very first one didn't even see an actual release. Can't even really call it an UI, it was nothing more than a bare window using the Win32 API directly, along with some hardcoded input mappings, that just served to help me get the emulator core going.

Obviously, it was specific to Windows, and I wanted melonDS to be cross-platform, so it was thrown away. I didn't want to have to maintain separate frontends for each OS, so using a cross-platform UI toolkit was a must. I wanted something that was relatively lightweight, and if possible, used native widgets instead of reimplementing them.

Thus, the 0.1 release came with a wxWidgets UI. Due to not being able to make wxWidgets and SDL interoperate smoothly, the UI was a clunky mess that came in separate windows. But atleast it was more user-friendly, and worked under Linux.

The wxWidgets UI was eventually retired with the 0.5 release. I went with libui, which was small enough that I was able to modify it to meet my needs. The new UI even had several improvements over the previous one. libui's design was not optimal, but it was good enough for what we wanted, so we built upon it for the next releases.

Fast forward to now. As you might have read in the previous posts, we've been wanting to add new features to melonDS, but found that libui lacks support for what we need. We didn't want to spend forever building upon libui, so we decided it was time, after more than two years of service, to retire the good ol' libui UI.

We thought about this for a long while, and in the end, went with Qt for the new UI. I have concerns about this, but I'm hoping for the best.

So how is the Qt adventure going so far?

Pretty good. Qt is fairly nice to work with. The new UI is almost on par with the old one, and in some ways it's better. You can see the progress in our git, in the qt branch.

At the time of writing this, the big things that still need to be taken care of are OpenGL support and the wifi interfaces. And, of course, building an UI for the cheat engine I wrote in February.

There will also be the whole issue of packaging this all up, especially on Windows. The current Qt builds require no less than 25 DLLs. Compare that to the measly 4 DLLs the libui versions came with... We'll need to look into static linking to avoid this madness.

I also want to look into providing Mac builds. Will probably involve installing an OSX VM, sounds like a lot of fun.

As for the rest, I'm keeping some surprise on the upcoming 0.9 features :)]]>
We're alive! -- by Arisotura Sat, 11 Apr 2020 22:55:52 +0000

For example, I felt like dealing with issue #598. Which was the same problem as the older #379, by the way.

The base issue was that some polygons ended up sliiiightly offscreen (getting a lower Y coordinate of -0x1001 when the view volume bound is at -0x1000, for example). Not an issue with how coordinates are calculated, mind you. On the DS, polygons can be slightly offscreen like that and be clipped without any issues. But in the case of melonDS, due to how clipping was done, the texture coordinates of the vertices that stuck out would end up altered, resulting in a misaligned texture.

Ironically, using OpenGL appeared to fix the issue, but only because the way OpenGL applies textures is inaccurate to the DS hardware (which in itself causes a bunch of other texture alignment issues). So in the end, the two issues compensated eachother for a visually perfect result.

The software renderer, on the other hand, aims at replicating the original DS renderer as closely as possible, which in the end makes it more sensitive to little details like this.

Regardless, looking at the formula melonDS uses to clip polygons that are partly offscreen, it appeared that swapping the inner and outer vertices gave results closer to what the DS produced, so I did exactly that, and it ended up fixing the aforementioned issues.

So, one step closer to pixel perfection, I guess. Even though we aren't quite there yet; you might notice that the screenshot from Brain Puzzles are exhibiting another glitch that wasn't fixed.

Also, I finally took care of properly handling ROMs with encrypted secure areas (which is the case of the Virtual Console dumps, for example). Before, those could only be run by doing a full firmware boot, now they can be run via direct boot without issues.

On a bigger scale, well, we're still trying to find a good solution for the UI shit. I'm at a point where I'm envisioning the craziest options, like giving in and using Qt.

I dropped the FLTK option because FLTK uses raw pixel positions for everything, which isn't going to be too good for hiDPI support and such.

I also want to attempt things regarding local multiplayer, but it's going to be a bit of a gamble. The basic idea would be running the wifi subsystem on its own thread with a specific timing mechanism, as to ensure more reliable operation. But, not quite sure how well the emulated software is going to appreciate that.

As a side note, on the DS, the wifi system runs off its own 22MHz clock (and not the 33.51MHz system clock), so I guess that doing so wouldn't be too inaccurate. However, on the DS, things are running at more or less the same rate always.

On the other hand, in melonDS, the actual rate at which things run depends on how fast the host machine can run it, and it's impossible to reach perfectly homogeneous timing due to how the emulator works. You can use the throttling mechanisms, like the framerate limiter, audio sync, or vsync. But those kick in between entire frames, so essentially you're running an entire frame as fast as possible, then sitting around until it's time to begin the next frame. Finer throttling would reduce the gap, but would also be likely to slow things down, as the emulator isn't running homogeneously and some things take more time than others (and some things are performed all-at-once instead of being a cycle-per-cycle process like in the DS).

This is why local multiplayer doesn't work well in melonDS (and this is also why disabling throttling makes it work better). It's going to run too fast, then halt, then run too fast again, and so on. Meanwhile, in melonDS the wifi system is currently driven by the core scheduler (running one 'microsecond' every 33 cycles), so it's going to be affected by the whole on-and-off thing. You guess this doesn't bode well with the local multiplayer protocol, given how it works and the tight timings it requires.

Running the wifi system on its own thread would allow the local multiplayer exchages to function better, depending on how reliable the network is. However, it would do so at the expense of the timing between the emulator core and the wifi system. It's hard to predict how games will react to that, given we are emulating the wifi system at a low level (to give you an idea, we do emulate the transmission/reception delays for packets, not sure how much the software requires this).

Oh well, we'll see.

The Melon Factory of Kuribo64 hopes that you are well.]]>
Chaos ahead -- by Arisotura Mon, 16 Mar 2020 10:00:33 +0000
I guess that within the current situation, I owe you a post to keep you informed on things.

We're envisioning FLTK for a new UI, but I have yet to give it a try and see whether it would be a good fit for melonDS given how it works.

Motivation is at a low here though.

But, to give you an idea what to expect: given the scope of what we are developing, we're aiming straight for a 0.9 release.

The IRL situation isn't helping things. You might be aware of the coronavirus. We at the Melon Factory of Kuribo64 are fine for now, but the pandemic is growing, and with it, a set of heavy consequences.

After underestimating the virus for a while, France is finally taking confinment measures.

That may slow things down regarding the plans I have IRL, like, my attempts at getting a decent job.

What worries me more than the coronavirus, though, is the ongoing economical crisis. Markets are crashing and I guess it's not a good thing. It all seems abstract for now, but sure enough, in a while we will begin seeing concrete effects to this. Like, I don't think this is the best time for getting a job, but it's also going to be a mediocre time in general for the smallest and most vulnerable.

So, I'm keeping a close eye on all that. Worst case would mean I'd have to take immediate action to avoid going bankrupt and ending up homeless. Probably ending up in some squat.]]>
well, shit -- by Arisotura Tue, 25 Feb 2020 00:45:10 +0000
Except then I need to properly design my basic blocks (AR code list parser thing, AR engine, etc) so that they can be interconnected nicely.

Which is where I began thinking about the kind of interface I would need for entering cheat codes.


Uh oh.

libui doesn't support the kind of controls I want to use.

Generic has been thinking of a kickass debugger UI and running into the same issue.

So... it's time to take a decision here.

We haven't taken a decision yet. Basically we need a good UI toolkit, that, ideally, is lightweight yet well-featured, modular (so you don't need to embed a complete behemoth if you aren't using everything), uses native UI controls, supports drawing areas and OpenGL...

This is going to be another great moment of 'fuck technology'.

If you have any ideas that aren't Qt, your input is welcome.]]>
By popular request -- by Arisotura Sat, 15 Feb 2020 12:13:14 +0000

You guess.

I'm not forgetting about the OpenGL work that was started, either, but I really needed to work on something new to get some motivation back and not let melonDS die.

Also, our comrades RSDuck/Generic and Chagall have been working on some pretty rad shit too. We're coordinating to unite all that nicely for an epic release eventually.]]>