Home | Downloads | Screenshots | Forums | Source code | RSS | Donate

Register | Log in

< New demo: Emulator ExaminationExpect slowdown >

A bit of a status update Apr 26th 2026, by Arisotura

I've been taking a bit of a break from melonDS lately... mental health reasons, a silly side project, the usual stuff. Regardless, I've been rethinking my plans for melonDS. I think I might postpone the timing work to melonDS 1.3. It's bigger than anticipated. I want to address some other issues, most notably finishing the new OpenGL renderer, and release melonDS 1.2. There's also some codebase cleanup I want to do. Regarding the timing work, it's going to take some planning, and possibly a larger rework. As I've said, the ARM7 is simple enough. Things are pretty much sequential, and the only extra complexity comes from main RAM burst termination delays. The ARM9 is where it gets hard. We deal with mechanics like cache streaming, write buffering, ability to keep running code while the bus is in use... All sorts of mechanics which highlight the limits in melonDS's current model. For example, take the LDM and STM instructions. They do multiple consecutive memory accesses in a row. They're commonly used to push registers to the stack and pop them back, or to quickly clear or copy large blocks of memory. There are several issues arising from this. Depending on the base address, a LDM/STM instruction might cross the boundary between two memory regions, or two MPU regions on the ARM9. STM, when accessing I/O registers, might also cause a bus stall between two memory writes (for example, if it starts a DMA transfer...). melonDS was built on top of a plain old interpreter. We read one instruction word from memory, we use a lookup table to figure out what we should do, we do it, then we move on to the next instruction, and so on. This model treats individual instructions as atomic: there is no way to account for all possibilities with LDM and STM, for example. Or atleast, not easily. So an idea I have in mind is to try a different model for CPU emulation. A sort of cached interpreter. The idea is to turn DS code into an intermediate representation which not only enables faster execution, but also gives us more freedom. For example, the aforementioned LDM/STM could be turned into discrete memory accesses, or optimized into larger accesses if possible. Another reason would be timing calculations. Some of them, like interlocks, can be annoying to resolve, but only really need to be resolved once, so a cached interpreter could have them precalculated. At this stage, this is only a basic idea, but it's something I want to experiment with.

11 comments have been posted.

< New demo: Emulator ExaminationExpect slowdown >

Post a comment
Name:

DO NOT TOUCH