New demo: Emulator Examination

< The timings saga, ep 2A bit of a status update >

New demo: Emulator Examination
Apr 12th 2026, by Arisotura

Emulator Examination is a DS demo which has been released recently, and has been programmed by PoroCYon.

I figured this would be an opportunity to write about something other than CPU timings for once! But first, a video of this demo, comparing the hardware results against melonDS.

This demo bends the DS hardware in creative ways. You can read PoroCYon's writeup here, but I figured I would write about my perspective too.

First of all, this is a DSi demo, which limits the opportunities for emulator comparison. As of now, melonDS and NO$GBA are the only emulators with some degree of DSi support. The demo will still run on a DS, but you'll be limited to the first test, since this one isn't DSi-exclusive.

Now, let's see what we got here.

First, we have an eyesight test. At first, I had no real idea what was going on here. Basically, the PPU mode is changed in the middle of a scanline, which causes very specific glitches.

The interesting part is that this mirrors how hardware reverse-engineering works: doing unintended things with the hardware, observing the results and figuring out the logic behind them, can offer insight into how the hardware works beneath the surface. It can also confuse you to shit (hi, 3D GPU).

However, this effect is unlikely to ever work correctly in melonDS. Emulating it requires understanding and accurately modelling how the PPU works at a cycle level, while melonDS employs a scanline-based renderer. And since no games out there try to modify PPU registers during a scanline, there are no provisions for supporting that.

This would be right up Jakly's alley, with DualSOUP. fleroviux has done a lot of research on the GBA PPU's cycle-level operation, which will likely be helpful for this.

The second test displays an animated rainbow pattern on a monitor. What's causing melonDS to struggle so much with it?

My immediate observations were that: 1) it uses timer-driven NDMA transfers, and 2) it uses custom DSP code, hence the poor performance.

The first part wouldn't be very difficult to implement. I have never implemented this NDMA transfer mode because I haven't yet encountered a use case for them, and haven't yet gotten around to write test ROMs, but it's probably not very difficult - just not high priority.

The second part is where this stops. This is more racing-the-beam shenanigans: the DSP sets up a DMA transfer to the first entry of the BG palette, and that's how the rainbow effect is created. So even with proper support for timer-driven NDMA, it still wouldn't render properly on melonDS.

The third test simulates a basic hearing test: it produces beeps that match the little 3D animation. melonDS outputs nothing at all.

This one is cheeky. I had a feeling I knew what was going on there, and I was right.

I talked about the DSi audio hardware here. The DSi uses a TI audio amplifier slash touchscreen controller. This chip has quite a bunch of audio processing features, one of them being... making beeps. There's a bunch of registers for this: you set the desired length in samples, some values derived from the desired frequency, and it will output a sine wave.

When I looked at the console output in melonDS, I could see repeated accesses to unknown TSC registers, and sure enough, those are the beep registers.

It brings back memories: the Wii U gamepad uses a similar audio amplifier chip, and it also has those beep registers. When I started reverse-engineering the audio system there, I used those to validate that the audio amplifier was configured correctly.

Anyway, this is... interesting. On one hand, it would be interesting to try to emulate this. On the other hand, it wouldn't be terribly useful - nothing else ever uses the beep registers. But it's within the realm of what I consider feasible in melonDS.

In a similar vein, the current TSC support in melonDS is pretty lackluster, but once again, nothing ever changes the TSC configuration outside of specific situations (like entering DS mode). The TSC is configured once and everything else, like volume control, is done by other components. Even the audio frequency switch is implemented by changing the TSC input clock - none of the TSC configuration is affected.

The fourth and final test is a series of CPU tests. But wait, how could melonDS fail those so egregiously?

The DSi embeds a new wifi card based on the Atheros 6k chipset. Unlike the old DS wifi card, which is powered by a fixed-function chip, this Atheros wifi card is powered by an Xtensa CPU. Modern wifi cards work similarly: you have an embedded CPU functioning as the brain of the system, controlling the 802.11 radio, the power management systems, and the various other peripherals. This CPU runs firmware which exposes a high-level interface to the host driver, and handles all the complex low-level details.

In this case, our demo is running custom code on the wifi card's Xtensa CPU.

Hence why it's utterly and completely failing. It's interesting that they were able to even get past this test in the video-- when I tested the demo on melonDS 1.1, it would get stuck on the last subtest.

It's a bit of a shitty situation, here.

On one hand, it would be an interesting technical challenge to get this running.

On the other hand, I'm not looking forward to emulating the entire wifi card. And even if we ignore that, the DSP situation should tell you why the wifi card firmware is HLE'd.

Then we get to the credits screen, which uses more beam-racing to do a shimmer effect. Because of course.

All in all, I appreciate the display of creativity in how the hardware is used. It's always interesting to figure out how those things work.

At the same time, this shows the limits to emulation. It's a balancing act between what is fun and what is practical to do with a given approach.

For example, see the fourth test up there, the whole "running custom code on the wifi card" bit. If games were doing that on a regular basis, and with enough variety, it would make sense to emulate that entire CPU.

Compare to the DSP situation. We have low-level DSP emulation, but it's slow. Even if there could be room for optimization, there's only so much we can do when emulating an entire subsystem. On the flip side, all the games that use the DSP use a limited set of ucodes, which makes HLE feasible. The issue is that it fails to cover custom ucodes, like our demo here is using. For this, it would make sense to look into some sort of recompilation, JIT or AOT (ahead of time). While commercial games were constrained to a limited set of official ucodes, homebrew has no such limitation. HLE wouldn't be practical unless specific ucodes became common (for example, by becoming part of homebrew toolkits).

As far as the wifi card is concerned, it's a no-brainer: every game is going to use the same wifi firmware, which was already set up by the DSi firmware, so it just makes sense to HLE it.

So, basically, while there's room for improvement in melonDS, I doubt it will ever run this demo 100% correctly.

5 comments have been posted.

< The timings saga, ep 2A bit of a status update >

Alex Andru says:
Apr 16th 2026

This was such a cool read. I learnt a few things here

AsPika says:
Apr 17th 2026

Make timing stuff great again!

Tris says:
Apr 17th 2026

Thanks for the write up. I don't know much about all the jargon and actual programming stuff, but I love the insight into the philosophy and approaches to emulation as a whole.

Hrock says:
May 5th 2026

add 32 bit support, beacuse i use old windows

Celina says:
May 8th 2026

amazing
amazing