Why there is no 32-bit build of melonDS
The main reason is that I don't have an incentive to provide 32-bit builds. Most people already have 64-bit OSes.

That being said, melonDS can currently run on 32-bit platforms. It may be less performant, as the 3D renderer does a lot of 64-bit math, but it is still possible.

But if I ever decide to implement a JIT, for example, there will be no 32-bit version of it.

If you're stuck on a 32-bit OS for hardware reasons, your computer will not be fast enough to run melonDS at playable speeds.

melonDS will be optimized, it will run faster, but it will also tend towards more accuracy. So I can't tell how fast it will be in the end. But I highly doubt it will run well on a PC from 2004. Maybe it will, if a JIT is made, but that's not a high priority task.

If you are stuck on such hardware, NO$GBA is a better choice for you. Or NeonDS if you don't mind lacking sound. Or hell, the commonly mentioned method of running DraStic in an Android emulator -- those who bash DeSmuME at every turn claim it's fast.

Truth is, emulating the DS is not a walk in the park. People tend to assume it should be easy to emulate fast because the main CPU is clocked at a measly 66MHz. Let's see:

There are two CPUs. ARM9 and ARM7, 66MHz and 33MHz respectively. Which means you need to keep them more or less in sync. Each time you stop emulating one CPU to go emulate the other (or to emulate any other hardware) impacts performance negatively, but synchronizing too loosely (not enough) can cause games to break. So you need to find the right compromise.

The ARM7 generally handles tasks like audio playback, low-level wifi access, and accessing some other peripherals (power management, firmware FLASH...). All commercial games use the same ARM7 program, because Nintendo never provided another one or allowed game devs to write their own. This means that in theory the ARM7 could be emulated in HLE. In practice, this has never been attempted, unless DraStic happens to do it. It's also worth noting that it would be incompatible with homebrew, since they don't use Nintendo's ARM7 program.

If it is possible to get ARM7 timings reasonably accurate without too much effort, the ARM9 is another deal. It is clocked at 66MHz, but the bus speed is 33MHz, so the CPU needs to adjust to that when accessing external memory. Accesses to main RAM are slow, moreso than on the ARM7, due to what appears to be bad hardware design. But the ARM9 has caches which can attenuate the problem (provided the program is built right). When the caches are used, timings can vary dramatically between cache hits and cache misses.

So emulating ARM9 timings is a choice between two unappealing options: 1) emulating the whole memory protection unit and caches, or 2) staying grossly inaccurate. I went with the second option with melonDS, but I'm considering attempting MPU/cache emulation to see how much it would affect performance.

Noting that RaymanDS is an example of timing-sensitive game: when timings are bad enough, it will start doing weird things. Effects get worse as timings are worse, and can range from text letters occasionally jumping out of place to travellings going haywire. I have observed polygons jumping out in melonDS, so the timings aren't good enough for this game.

And then you have all sorts of hardware attached to the CPUs. Timers, DMA channels, or the video hardware-- oldschool 2D tile engines and a primitive, quirky custom 3D GPU. The 2D GPUs need to be emulated atleast once per scanline as games can do scanline effects by changing registers midframe (it is less common than on the SNES for example, but it's still a thing). The 3D GPU is another deal: geometry is submitted to it by feeding commands to a FIFO. You need to take care of running commands often enough to avoid the FIFO getting full, especially as games often use DMA to fill it.

Oh by the way, the 2D GPUs are actually pretty complex, supporting a variety of BG modes and sizes, multiple ways to access graphics for sprites, and so on. The 3D GPU isn't any better, I think we have already established that it's a pile of quirks.

So yeah, with the sheer amount of hardware that must be emulated, the DS isn't a piece of cake.
Yayaya says:
Jul 29th 2017
I only need 1 build for windows xp 32bit so i can trade my decades old pokemon.
This is the only standalone emu which has local link support and aint 32bit :D:D

such a shame really how desmume treated wifi and pokemon... i still remember my excitement when i saw your post in the ngemu forums about connecting to the servers a decade ago :D
and nogba still has no wifi the dev seems to work more on dsi.

pls tell me u have any plans to make a android port with wifi or atleast try to help drastic devs or nogba dev to implement wifi :D
Specially drastic since a ds android emu with wifi is probably most peoples wet dream haha.

can the retroarch melonds core have wifi btw? i tried to run a few ds games and all crashed the app (android retroarch)
desmume core runs them so idk what is wrong i used bios and firmware and it still crashes.
AsPika2219 says:
Jul 30th 2017
No 32 bit.... No Windows XP.... Never mind! Anyway, just only one is play any games on Desmume, then export save game (use RAW save) into MelonDS and then, play same games, plus trade them or battle them! After that, import back to Desmume and enjoy!
stan says:
Aug 10th 2017
Are you really positive that Nintendo never ever revised their ARM7 program? My understanding was always that they forced their own one, but I imagined that they changed it with changing dev kit versions, this is what happened with Wii equivalent after all.
Luigi442wii says:
Aug 11th 2017
Do people not understand that Windows XP is a dead operating system and it was released and revised in the times where 512 MB of RAM and a 30 GB HDD were acceptable... I mean, sure I like the OS myself but I wouldn't ever use it in a non-virtualised environment...
StapleButter says:
Aug 16th 2017
stan: Nintendo may very well have revised their ARM7 program, to fix bugs or add features, but the overall featureset will be the same, and the IPC protocol should be the same too.
Post a comment