melonDS RSS The latest news on melonDS. Quick news -- by Arisotura Mon, 19 Feb 2024 23:39:17 +0000

This is just a quick attempt at supporting multiple windows. There's still a whole pile of issues to fix, but it's looking promising so far.

This is not only part of the ongoing refactor, but would also pave the way for separate windows, a feature that has long been requested.

I'm having a bit of a question there: if we got multiple windows, which one should have the OSD? The main window? The currently active one? All of them?

Other than that, sorry for the lack of updates lately. January has been rough for me, but things are getting better. I've also been caught in a fun side project that involves reverse-engineering (and emulating, heh) ancient FPGAs. Maybe I could have a sort of personal blog for non-melonDS projects of that kind, or just personal stuff in general.]]>
Merry belated Christmas -- by Arisotura Thu, 28 Dec 2023 14:51:23 +0000

As I have received and set up my new laptop, I've been able to work on melonDS some. The goal is still the same: to adapt melonDS for supporting multiple instances within one process.

The frontend is proving to be tricky, because it was largely built without many regards for code quality. Originally, the frontend was just quickly built around the program entry point in main.cpp, as it just needed to provide a means to use the emulator. We had a simple window, a dedicated thread to run the actual emulation, and that was it.

Obviously, over time we added various features to the emulator, rebuilt the frontend around different UI toolkits, piled on more features, and so on. Basically, the frontend code became a mess, and everything was more or less just dumped in the global namespace -- there are some modules which live in their own namespaces, but it's all not very modular, and doesn't lend itself to running multiple instances of melonDS.

I started by splitting main.cpp into separate files. We are far from done with the cleanup, so there's a lot of cruft around, but the basic idea is the following:

* main.cpp just holds the entry point (main()) and global application-related stuff.

* Window.cpp holds the MainWindow code, for managing the emulator window. We may also add support for multiple windows.

* Screen.cpp holds the ScreenPanel code, that is, the panel widget that goes inside the emulator window and handles display and touchscreen input. There are two kinds of ScreenPanel: one that relies on Qt's graphics API, and one that uses OpenGL.

* EmuThread.cpp holds the emulation thread.

From there, each EmuThread would hold its own instance of the emulator core (which we mostly finished porting), and optionally point to one or two windows to display to (or none, in the case of a headless instance).

After laying out this basic separation, I figured it would make sense to integrate the OSD feature into ScreenPanel. The OSD module was a bit of a mess, with having to maintain different code paths for Qt or OpenGL drawing. Now things are a lot cleaner.

There's still quite a bunch of global state and stuff that we need to adapt before the dream of emulating multiple DS's within the same process can come true. But we're getting there, slowly but steadily. This is the perfect occasion to finally clean up and improve our frontend code.]]>
Long-due status update -- by Arisotura Sun, 17 Dec 2023 13:33:22 +0000
What's new since the last post? I had started working on refactoring the melonDS codebase for the ambitious changes to come. JesseTG mostly finished the work on the core, so that's one big thing out of the way.

The frontend code is now going to need adequate refactoring too. That's, well, more work. We'll get there over the coming days.

On my side, I (finally) ordered a new laptop, so I'm waiting to receive it and set it up before I do more big work on melonDS.

I will need a while to adjust to the new changes that have been done to the melonDS core. It's also likely not perfect, we will likely have to do more work to clean up and harmonize the codebase. But atleast, the biggest part of the work is done.

On the frontend side, we need to add support for multiple different emulator windows. Historically, the frontend was structured around one emu thread and one emu window. The latter provides a means to display the emulator's video output and lets the user interact with the emulator, the former feeds the inputs into the melonDS core, runs it and manages it.

It wouldn't be difficult to spawn multiple emu threads, one per emulated DS. Window management is another deal. We thought we might want to support attaching multiple windows to one emu thread, for example to support displaying each DS screen on a separate window. For netplay purposes, we might also want to support headless instances, that is, running an emu thread with no window attached, no sound output, and inputs received from the network.

This also poses the question of OpenGL context management, all things we will need to look into.

We'll get there. It just... takes time.]]>
Happy birthday melonDS! -- by Arisotura Fri, 03 Nov 2023 23:31:32 +0000

(if you're wondering about these colors: I have synesthesia, that's all)

I'm sorry for the lack of new releases since 0.9.5. It's been one year. That being said, we have big plans for the next release. I'm not going to go in length about these, the previous posts detail the plans well enough.

Just bear in mind that we're currently refactoring the melonDS codebase, so things may get a tad unstable while this is ongoing.

Other than that, it is a bit of a miracle that melonDS has been going for so long, and that after so long we're still around and coming up with ambitious plans. I've had several other personal projects, and none of them made it far past the one-year mark (or I only still work on them in a much more sporadic manner, like blargSNES). So, long live melonDS.

On my side, I quit my antidepressant in September, which went much more smoothly than I imagined. I've had a few bouts of depression since then, but nothing really bad, it's completely incomparable to what it was last year, and it's progressively getting better. I'm hopeful.

I tried Ritalin again, but it seemed to make me depressed after a while, so that's a bummer. I have a few ideas for other possibilities, but in the meantime I'm back to being unmedicated. Since this is how it's been for most of my life, I have coping strategies already, but the low energy part of it kinda sucks.

May 2024 be filled with success.]]>
The RTC rework is done -- by Arisotura Tue, 31 Oct 2023 10:17:42 +0000

melonDS has got a fun little dialog for changing the date and time now.

Basically what it does is show you the current date and time of the emulated DS. You can change it to any date and time, or you can reset it back to your computer's date and time.

What you set is saved as an offset in seconds from your computer's time. Every time you launch a game, the computer's time is used as a reference to calculate the emulated DS's time, and then melonDS does its own time counting from this point.

This also means that, unlike the previous behavior, if melonDS runs too slow or too fast, it will affect the passage of time for the emulated game from your perspective. The point is to keep melonDS's time counting accurate from the perspective of the game.

This was also the occasion to rework the RTC emulation itself, because it was quite lacking.

For example, when returning the current time, it would simply return the current hour from 0 to 23, ignoring the AM/PM flag that is also encoded in the hour register. It gets a bit weird, because the way this register works depends on the 12/24-hour setting in status register 1. In 24-hour mode, the register goes from 0 to 23, and the AM/PM flag is automatically based on that. In 12-hour mode, the register goes from 0 to 11, and the AM/PM flag needs to be set properly for things to function.

I was also able to add support for writing to the date/time registers. This means that for example, you can boot the DS firmware and change the time from there, and melonDS's date and time setting will reflect that. Perhaps not very useful, but a nice touch regardless.

There is also the part where, in the DS, the RTC is powered by the battery. This means the RTC state isn't reset unless the battery runs out or is removed. I made melonDS save the RTC state between runs to mirror this: if you notice a new rtc.bin file, that's what it is.

Then there's the fun part: the RTC IRQ. Basically, the RTC has several alarm modes that will trigger an IRQ based on different conditions. The alarm interrupt mode will trigger the IRQ based on day of week, hour and/or minute, much like an alarm clock. Then there are other modes for simple per-minute interrupts or for firing at specific frequencies. All fine and dandy.

A prime example is libnds, or atleast the older versions of it, where they used the RTC IRQ to keep track of time. In more recent versions, they moved away from it, mainly because the RTC IRQ doesn't work on the 3DS in DS/DSi mode.

Regardless, this use case isn't difficult: they use the selected frequence steady interrupt mode to fire an IRQ every second. With support for this, these older libnds homebrews are no longer stuck in time.

I also looked into the DS firmware's alarm clock feature. The alarm clock screen does its own counting, the RTC IRQ is only really used when the DS is closed: while most of the DS hardware is turned off, the RTC still functions, and its interrupt can wake up the rest of the hardware (much like the 'lid open' interrupt that fires when you open your DS).

I had to rework melonDS's implementation of sleep mode to get this to work (and also, you know, to get the RTC to count while in sleep mode in general). Kind of a pointless detail, I doubt anybody out there will be using melonDS as their alarm clock, but still a nice touch. Also helps make for more accurate emulation in general, so hey, I'll take it.]]>
RTC and ambitious plans -- by Arisotura Thu, 26 Oct 2023 10:06:25 +0000

The RTC, aka Real-Time Clock. The DS uses a RTC chip to keep track of the current date and time. melonDS has had some RTC emulation since the early days, because it was a requirement to get the firmware to boot, but since then, that RTC emulation has been pretty much barebones. Basically, all it does is return the current system time from the host. While it's good enough for the most basic purposes, it comes with a number of downsides.

For example, we've had several requests from end users about changing the time inside melonDS. Currently, the only way to do that is to change your computer's time. melonDS offers no UI for setting its own time. It is possible to boot into the firmware and use the settings menu there, but melonDS ignores writes to the RTC date/time registers, so it just reverts back to the host system time. Less than ideal.

This is also a problem for netplay. The basic idea behind netplay is that all players run the same emulation, and inputs are synced across them. For this to work, you need to ensure that for all players the emulation starts from the exact same state, and that the inputs are the exact same for everybody. Since games use the RTC to initialize their random number generators, all sides need to start from the exact same time, or they will desync. So the basic, "let's just return the system time" RTC won't do here.

Then there's also the fact that this RTC emulation we have is incomplete. The RTC does more than just keep the current time: it features several 'alarm' settings that can trigger interrupts, for example. libnds uses that feature to do its time counting, so if you run any libnds homebrew in melonDS, it will seem stuck at the same time.

The DS firmware also has an alarm clock feature. While I doubt anybody out there is going to use melonDS as their alarm clock, emulating it would be a nice touch.

Regardless, I started working on the RTC yesterday. The first part is to have the RTC in melonDS do its own time counting. The RTC in the DS is likely controlled by a 32768 Hz clock, as is typical for these things, so I did something similar in melonDS, as it will be a requirement for emulating the alarm interrupt features.

I used the system event scheduler in melonDS for this purpose. It is technically inaccurate, because the scheduler runs on the DS system clock (33.51 MHz), but it provides a reliable way to keep the emulated RTC in sync with the rest of the system. I had to get a bit fancy to correct for the inaccuracy from using the system clock as a base, but nothing bad.

From there, I laid down the basic idea of a clock. Have a bunch of registers for the current date and time, count one second every 32768 RTC ticks, count one minute whenever the second register reaches 60, count one hour whenever the minute register reaches 60, etc... You get the idea. As there's currently no way to tell the melonDS core which time to use on startup, it starts at 01/01/2000 00:00:00, but it does count up properly so far.

Next step will be to do some hardware tests to figure out some details. For example, the date/time registers are BCD, which means that for example a value of 24 is represented as 0x24 (decimal 36, 2*16+4). Since they are writable, I need to determine what happens if invalid BCD values are written. For example, say the register's value is 0x29, when it will be incremented, the next value will be 0x30 and not 0x2A.

0x2A wouldn't be a valid BCD value, so what happens if I try to write that to the register? It could be rounded down to 0x29, or rounded up to 0x30, or the write could be ignored entirely, or it could actually accept a value of 0x2A and behave weirdly because of it, so I need to figure this out. This is an off-the-shelf RTC chip, so chances are it's well-behaved, but it's not exactly like there are no precedents of DS hardware accepting whatever garbage inputs and doing weird shit.

Then I will have to implement all the alarm interrupt features and all, and provide a way to set the time in melonDS, and this should be good.

Then the ambitious plans.

This was an idea that we put off before due to the amount of work required, but JesseTG is giving us a much welcome boost in ambition. Basically, he is making a Retroarch port of melonDS, and a lot of the work he's putting into it is going to be very useful for netplay.

For example: when starting a netplay game, we want each side to start from the exact same state. I figured that using the existing savestate system for this purpose would be adequate: just save the initial state on the host, then broadcast that to the clients and they just have to load it, and boom, most of the work is magically done.

The problem I originally ran into was that said savestate system was designed to interact with files directly, so getting around it was hacky. JesseTG modified it to work on memory buffers, which is exactly what we need here. This change will also be welcome for Generic's Switch port, where savestates turn out to be slow due to the sheer amount of file I/O calls.

Anyway. The plans.

In its current state, melonDS is designed to run exactly one DS per instance. This proved to be a bit of an issue for local multiplayer. In the early days, the strategy was to just run multiple melonDS instances, have them toss around packets over UDP, and pray that it would work. But we do things in a more refined way now.

The ideal way to do local multiplayer on one machine would be to run multiple DS's inside the same melonDS instance. Thus, there would be little to no losses in the multiplayer data exchange. But the main issue with this is that, well, the melonDS codebase doesn't lend itself well to this. At all.

So instead, we went for the technically easier way. We just run multiple instances of melonDS and sync them via IPC mechanisms. Essentially, they use shared memory buffers for data exchange and shared semaphores for synchronization.

There are multiple issues with this design, though. First, it is not ideal from a performance standpoint. Inter-thread communication from within the same process is easier and faster than inter-process communication. The shared semaphores we need to use are named semaphores, which are a special type of semaphore and aren't really optimal for performance.

Another issue is making this work in netplay. With having to deal with multiple processes across multiple machines and keep all of it in sync, there are many moving parts and many ways things can go wrong. If we only had to deal with one melonDS instance per machine, it would make things a lot simpler.

So you can see where this is headed.

Adapting melonDS to support multiple DS's per instance.

In the current state of things, the melonDS core is largely a collection of namespaces that roughly represent the DS hardware components. Certain of the components are already classes, because they need to be instanced multiple times: the ARM CPUs, the 2D GPUs, the SD/MMC controllers for the DSi... But for the rest, it can only be instanced once, because it's just a namespace.

For what we want, all of these components need to be converted to classes. Which you guess isn't going to be a walk in the park. This is the kind of change that will conflict with every existing branch, pull request, etc. Existing ports of melonDS will need to be updated accordingly. And so on.

We're going to plan this out and take it easy. I'm realizing that after nearly 7 years of ongoing development, melonDS has become quite a big and complex project.

Stay tuned!]]>
LAN multiplayer: getting there! -- by Arisotura Sat, 07 Oct 2023 15:17:51 +0000

LAN gameplay between the two computers I have at hand over here.

LAN is actually fairly close to a finished product, now. It's obviously still a bit rough around the edges, may be a tad unstable, but from my testing it has shown to be pretty smooth.

From this point, I encourage anybody who is interested to grab the experimental builds from our Github CI. It's the runs labelled 'season2 test PR'; note that you will need a Github account to download them.

But if you're motivated, please give them some deep testing, abuse them in whatever ways you can think of, and report anything that seems odd to you, in our IRC or Discord or in this thread. We'd like these features to be rock-solid for the 1.0 release.

How to get a LAN game going:

1. On the host machine: open melonDS, then System -> Multiplayer -> Host LAN game. You enter a player name and you're good to go.

2. On client machines: open melonDS, then System -> Multiplayer -> Join LAN game. Enter your player name there, then it should list any existing LAN games. If not, you can always try using the direct connect button.

3. Once all sides are connected to the LAN game, you can open a ROM on each machine and try getting a game going. Do note that you will need a good local network for this to work. Ethernet should work, but anything else may fail if the latency can get too high.

That should be about it. There are also options pertaining to netplay, but for now, it doesn't work. I had managed to get it working as a very crude proof of concept, but due to changes in the melonDS codebase since then, it's broken. I will let you know when I can get it working again.

Have fun!

EDIT- clarification on the terminology:

LAN is for playing local multiplayer games over a local network (ie. multiple computers in the same house for example).

Netplay is for playing local multiplayer games over the internet.

Neither of these apply to online multiplayer (aka WFC).]]>
LAN multiplayer: in the works -- by Arisotura Fri, 08 Sep 2023 10:33:14 +0000
Anyway, I've been throwing together a basic interface for LAN multiplayer. It's far from complete, but it's already showing promising results so far.

The issue is that it requires a low enough latency to work well. When connecting my two computers over a crosswired cable, yielding a latency of ~1ms, I had decent success connecting the two sides together. However, when using the regular network (my laptop connects over wifi, while the other computer uses a PLC adapter), latency was all over the place and it was impossible to get a local multiplayer connection going.

This isn't too different from the old socket-based network interface, really. Except that interface performed even worse, because it was really just tossing packets over the network with zero care.

This new LAN mode will function more like typical LAN games: you get a host starting a LAN game, then everyone else connects to the host using their local IP (or their computer's host name). Then you would launch your game and connect to other players like you would on an actual DS.

There's still some more work to be done before this can be called finished, mostly UI work but also other tidbits. I'll keep you informed.]]>
Sorry for the silence lately -- by Arisotura Sun, 27 Aug 2023 12:48:58 +0000
"Wow, has it really been one year?"

I'm sorry about this. It's not that we, melonDS team, don't care about user contributions. We do, and we're grateful for them. However it takes time to review them and make sure they're mergeable.

And while I can't speak for the rest of the team, the way I am doesn't help. I don't really notice the passage of time, anything in the past just feels like it happened ages ago, and it's very easy for me to let myself be carried into a comfortable routine for a long time. As you can imagine, it's a problem for certain daily life things. It also means that I end up postponing some things a lot, when I don't immediately feel like dealing with them and there's no urgency, I end up just thinking that "I'll do it later when I feel like it", let time pass, let routine carry me, and... "wow, has it really been one year?". Things like dealing with pull requests definitely fall into this pattern.

Lately, side effects from meds haven't been helping either. I take ritalin for ADHD, and venlafaxine for depression, and the two don't go together well for me. The latest dose increases (in July) led me to a situation where I had bad side effects: absurdly dry mouth, headaches and light sensitivity, bad sleep (waking up every hour or so), and intense fatigue, entirely negating ritalin's benefits.

I stopped taking ritalin and things quickly got a lot better. Although this also means I'm back to my usual ADHD self, in terms of focus and productivity: I don't really control what my brain focuses on, and it can take a long while to get myself to do things.

I won't try taking ritalin again until I'm off venlafaxine. I'm tapering down that; I get more tired some days but overall it's going well. I think venlafaxine has done its job, I also feel a lot better about myself and the world than even one year ago, so I'm pretty confident I can do this. I also want to go out, meet people, do things (all of which are very good ways to keep depression at bay), but it doesn't help when meds leave me too tired to do much at all. So yeah.

From a coding perspective: I want to attempt getting a proper LAN mode going for melonDS. Although lately my brain has been wanting me to focus on something else: a fun side project adventure that involves DSi DSP programming. It's not directly related to melonDS, but it may end up benefitting the DS/DSi scene either way, so hey. I'd want to talk more about it, if it does pan out, but that'd go on another blog.]]>
Optimizing wifi, take two -- by Arisotura Mon, 31 Jul 2023 08:41:43 +0000
The basic idea is that games send multiplayer data at a generally steady rate and the timings are predictable. When the host sends a CMD frame, generally there won't be anything else being sent (other than replies and ack) until the end of the CMD_COUNT window, unless some clients failed to reply. The only exception to this is when the host sends a beacon frame, but since these are sent at a fixed interval, it's not hard to take them into account.

I had to do a few tweaks to get it reliable in certain situations, but so far it gives quite a substantial speed boost and doesn't seem to impact reliability. We still have to see how this goes -- we might have to make it optional if it causes problems somewhere.

I'm also trying to fix some other problems, namely how in some games you can't connect more than two players. I have a bit of an idea what's going on, but I'll need to work on it more.

We're also thinking of bringing back LAN, but as a proper LAN mode instead of just tossing packets around the network. It may even possible to build something robust around enet. I'll have to give this a try.]]>