DSonPSP beta 3 - Nintendo DS Emulator for PSP

[Exophase]

I made a post on gp32x about areas in which DesMuME is lacking, and a faster DS emulator would need to correct:

http://www.gp32x.com/board/index.php...ost__p__749781

None of these things would be straightforward modifications to DesMuME but would involve massive overhauling.

Another thing I'd like to add to that list is better geometry processing. DesMuME processes geometry in separate function calls called from external memory interfaces, which at first glance is fine but really has a lot of overhead for trapping and loading state. It's essential that a DS emulator processes DMA to the geometry processor in batch and keeps state like current vertex and global matrices in local variables for a while, otherwise there's going to be constant state swapping for something that can happen hundreds of thousands of times a second.

There are also some PSP specific improvements that can be done. In general DesMuME could offer OpenGL support for vertex transformation and lighting, which the PSP can then do in hardware. Global matrix manipulation can be accelerated with on the PSP's VFPU. Several of DS's texture formats can be used natively w/o caching, with some others converting to more condensed forms than the 16bpp formats converted to by DesMuME's texture cache.

At the extreme end of things, 2D processing can be batched and moved to the media engine, along with ARM7. This would be very far from trivial to do while maintaining the same level of accuracy. But my guess is that DS games at least suffer fewer 2D VRAM writes per frame than GBA ones sometimes do, especially 3D games.

However, I firmly believe that all of the optimizations in the world will not make this good enough for PSP. It'd need to be a good 10x faster to really be feasible... and I think there are things that the DS can do in 3D that the PSP never will be able to do with its accelerator, since it's fixed function.

gpSP's recompiler can be adapted to this in some sense, but it's far from a direct fit. All of the ARM9 features would have to be added and the memory subsystem code would have to be pretty dramatically changed. Updates would have to be changed too, and there'd have to be some task switching magic to support both cores (unless the other really was on the Media Engine). It'd take someone who very seriously knows what they're doing and has the time to dedicate to something like this.

BTW, although developers aren't allowed to put their own code on the ARM7, they're still linking against libraries that have several revisions. So it's not a matter of having functionality on ROM. Emulating this at a high level might be problematic. Also, you need the ARM7 to access the X/Y buttons (stupid Nintendo..)