melonHLE?
While my situation is being sorted out, I will make a post about an idea I had a while ago: attempting HLE for DS emulation.

All the existing DS emulators, as far as I'm aware, are essentially LLE. DS games are mostly self-contained and run on the bare metal, relying on the small BIOSes for basic functions like interrupt waits, decompression, etc.

Some emulators, like DeSmuME, are able to HLE the BIOS calls, basically replicating them inside the emulator. The main advantage to this is that the emulator doesn't require a proper BIOS dump to run games, but there is no other real benefit from this. BIOS calls aren't critical enough that HLEing them might boost performance significantly.


What I've been experimenting with melonHLE goes further: HLEing the ARM7.

It may seem feasible if you consider that Nintendo never allowed game developers to write their own ARM7 binaries. This means that, in theory, all commercial games out there will have one of the few possible ARM7 binary versions. It also means that the ARM7 is limited to taking care of utility tasks, while all the game logic is running on the ARM9.

In practice, how does it work?

The ARM9 communicates with the ARM7 via the IPC hardware (IPCSYNC and the IPC FIFO), and some shared memory areas. When the game boots, there is a IPCSYNC handshake, then the ARM7 exposes a bunch of services that are accessed via the IPC FIFO. The services serve to provide access to the ARM7-side hardware: sound, wifi, touchscreen controller, PMIC, firmware memory, etc. Most of these services are fairly simple, with sound and wifi being by far the most complex ones.


So I've been experimenting with this in a private repo. So far, I've implemented enough of the utility services to get some games to boot, and observe a few things:

* There is a substantial speed gain from HLEing the ARM7. If this proves to be viable in the long run (despite the problems I will get to later), it may be an option for low-end platforms.

* Even if not, I still find it quite interesting to reverse-engineer the ARM7 binary and figure out how things work.

* Super Mario 64 DS has an earlier version of the sound engine, where some of the commands are different.

* Super Princess Peach has a completely different sound engine.

* Mario Kart DS's ARM7 binary has an extra service, which is used to assist loading code to ARM7 VRAM. Nothing we really need to worry about here.

* Aside from that, the smaller utility services seem to be pretty identical across games. However, I haven't started looking into wifi.


Now, the problems to this approach:

* Obviously, this only works for commercial games. It may be possible to support most homebrew by implementing libnds's default ARM7 binary, but anything with a custom ARM7 binary won't work.

* It is far less accurate than the current LLE approach. Given the ARM7's average workload, it may not matter to most games, but there's still the potential for timing issues (which stem from bad game programming).

* I have tried a few games, but I don't know how much variation there is across the entire DS library, and how I should go about identifying the different possible ARM7 binaries. This is going to be the main determining factor for whether ARM7 HLE is viable: how much code complexity is required to attain decent compatibility?


Also, I might want to avoid getting sidetracked too much. I want to finish implementing netplay, once my apartment is less of a mess.
JIIN says:
May 9th 2023

Thanks for the new post. And thank you again for working hard on the development of melond ds despite your busy schedule. I hope the day when I can play local network online with friends will come true!!
Link1448 says:
May 9th 2023
Looking forward to all of these very nice improvements !
Thanks for the hard work.
poudink says:
May 9th 2023
This is really cool. I've been thinking about how neat it'd be to see a DS emulator with HLE ARM7 since to my knowledge it's never really been tried before and it could push performance even further. It's not too useful for the hardware melonDS officially supports since any computer that isn't ancient should be able to handle melonDS fine, but it's going to be neat to see what this can do for unofficial ports, like on the Vita for example. Android too, this might allow melonDS to compete with Drastic's performance.
EL_T aka CV says:
May 9th 2023
appreciation from Brazil man, thx for all hard work, can you tell me if i can download the development version
A dragon says:
May 10th 2023
Given that Nintendo is going after a tool to get keys from the Switch for Switch emulation, it might be a good idea to reverse engineer the bios just to avoid any potential problems that could come out of this.
Generic aka RSDuck says:
May 10th 2023
the bios is that well understood. And for example we also already ship the Drastic's open source bios reimplementation with melonDS. Not that it matters much, because Nintendo doesn't seem to care that much about more niche stuff related to their older consoles.
Mr2Seconds says:
May 10th 2023
Cool! If the performance boost is that good, then it may allow local multiplayer to run way smoother than before. Can't wait to see what comes from this.
kevincrans says:
May 11th 2023
What about dsi mode arm7?
ThiccFurLizzy says:
May 13th 2023
This reminds me a bit of how Dolphin has HLE Audio, because practically all games use the same microcode for it, they can just use the HLE implementation (even Homebrew using the FOSS microcode), while keeping LLE for exotic configurations.
^.^ says:
May 14th 2023
I'm not a great fan of HLE, especially for a low spec console like this, it doesn't really have a powerful SoC or a single standard Arm7 binary acting as an universal interface.
Also I guess it wouldn't be able to emulate DownloadDS (it loads the Arm7 from wifi right????) or DSi mode (or even integrate GBA emulation if you ever get the chance).

It might be better to focus on the 1.0 features for now, maybe you could make that HLE branch public to let people test the various arm7 binary revisions.
hoangson says:
Jun 3rd 2023
One other feature I would like to see is improved DSi support. Right now, some games just show a "An error has occurred" screen when launched from the regular DSi menu, and a white screen when launched from TWiLightMenu.

And even getting TWiLightMenu on there is its own issue, because the Virtual SD Card Maker linked in the forum thread creates images that gives a "Invalid MBR Entry" message upon booting up Unlaunch, the TWiLightMenu boot.nds loader doesn't get loaded upon emulation bootup unless Unlaunch is installed, and Unlaunch... well, I already described my issue with it earlier.
Myownfriend says:
Jun 6th 2023
I've been thinking about HLEing the ARM7 for the last few months. It's crazy that you happen to have been working on it already lol
melonJYC says:
Jun 6th 2023
I have an idea, to prevent game slowdown, how about frameskip for melonDS. It would be cool.
txmutt says:
Jun 6th 2023
Did Nintendo ever allow DSiWare developers to write their own ARM7 binaries?
^.^ says:
Jun 7th 2023
@melonJYC isn't that already available?
Post a comment
Name:
DO NOT TOUCH