Exophase said:
Stephane Hockenhull said:
the cpu emulation speed isn't a problem (64Mhz ARM9 -> 600+Mhz ARM Cortex, you don't need to emulate the ARM7 just simulate the IPC), but the DS hardware is insanely complex.
Even though commercial games are only allowed to run Nintendo SDK code on the ARM7 it doesn't mean that it's trivial to HLE that. Since this is not code that's on the platform itself there's no guarantee that the different games will use even very similar versions, much less the exact same. Indeed, by my understanding many builds of Nitro exist. An attempt to do this would probably end up in the same dire situation CXBX has.
I wouldn't underestimate the overhead in emulating the ARM9 either. Virtualization has some serious emulation drawbacks and can break badly on some pretty likely cases because of lack of L1 cache coherency. You wouldn't get a full address space in Linux anyway, and some segmentation of the NDS's memory map are smaller than 4KB and would have to be trapped. And emulating aborts through Linux is very slow as well, which is not good for a 3D platform that does a lot of writes to hardware FIFOs and what have you. You'd really want to emulate the memory accesses in software, so I guess you can do the math from here. I'm not saying it's not possible but you make it sound easy.
Of course like you said, there are a lot of other components in the DS - I wouldn't call it insanely complex, but it takes a good amount of CPU just to emulate all of the 2D. The 3D could probably be done acceptably by the SGX, though (assuming we can access its framebuffer directly). The DSP could also be used to help a lot.
I was not counting on running under Linux for this, or you'd need a kernel module to have fast aborts processing,
nor using OpenGL ES drivers, direct hardware access to the GPU, textures, and framebuffer is needed for rendering 3D and 2D stuff efficiently.
(OpenGL is very bad at texture updates and waste so much ram bandwidth on embedded system)
the Jaguar or Saturn might be the only ones more complex than the DS, not many other consoles have that many circuits/modules, video modes, memory configurations, 2D layers and effects, etc.
I never accessed the 3D hardware FIFO on DS directly, and I doubt many games, if any, do: there's DMA for that.
the command stream is usually written to ram/cache, then cache-flushed, then DMA is started on the buffer, this provides a single point of capture for the 3D geometry side of things for virtualization.
texture memory can be translated on writes/uses and cached, texture memory is rarely accessed due to timing and exclusivity of gpu or cpu access (only approx. 20KB max transfer possible per frame) so that would not be a bottleneck.
there are many revisions of the OS, I don't know how complex the changes there are between revisions in the ARM 9->7 and 7->9 FIFO and interrupt protocol, but its not too hard to do on a case-by-case basis.
THE big problems and likely a show stoppers would be the very efficient video capture and blending on the DS (capture as it renders within the same buffer, SGX has delays)
as well as the hardware toon inking post-processing, 2D tile map+rotations, hblank dma-based (virtualizable) and cpu-based (not so much) video register modifications.
those prevents using only the SGX GPU to render.
if you want compatibility, perfect emulation, and under Linux while it plays nice with other programs that's another story
it would be a very broken emulator, but for the games that works, playable speed would be there.