Hey, I'd like to thank you for the original work on Temper. I got your source from gameblabla's GitHub - he ported it to GCW0.
Yeah I thought as much based on the readme. GCW Zero isn't ARM based, so there would have been no intention of using ARM_ARCH there, but it should be used here.
As a rough gauge, in this current port, I use 2 CPUs of the Old 3DS. The first runs the main emulation + graphics, the second emulates the PSG and mixes it with the raw CD + ADPCM output (which comes from the main CPU).
Have you done benchmarking to see what the result is of doing PSG and mixing on the second CPU? These are pretty low overhead operations and you should make sure that you don't lose speed doing this. The one thing that I'd consider the best candidate for being done on another core is Vorbis decoding for CD games with OGGs. This should also be using libtremor, which is a fixed point ARM optimized library.
When running most games, the CPU + graphics (hardware-accelerated) takes up about 60% without idle loop patching. Raiden, in some areas in the first stage, gets rather busy and hits 110%-120%. I tried earlier to define the CPU_ARM_FAST_MODE before to use the cpu_arm_asm_fast.s, but for some reason, it ran a wee bit slower than the original C core. I didn't spend too much time to figure out why, and I just went back to the original C core.
Obviously when I went software, the total CPU time goes up to 150% or more for a bulk of the games. The Raiden one is probably much worse. I could do some timings for you if you want more details.
CPU_ARM_FAST_MODE isn't something you're supposed to define, it's a wrapper to allow switching between a compatible mode and a slightly faster mode for the ARM assembly interpreter. As far as I know this is only necessary to get one game working (Exile). I would recommend either making this an option that defaults on or make it always in compatible mode, I don't think the performance difference is especially large.
But if you don't have ARM_ARCH defined you'll never be using the ARM interpreter and anything you measured in performance degradation was probably just a coincidence.
While it's good that you have something that's usually full speed, it seems like it'd be more desirable if you could get there with a more compatible and more timing-deterministic software renderer. The best option there may be to write ARM assembly for the C code in the new renderer, something I never got around to. I suspect that this could be faster than the old one was, since part of the new rendering approach was intended for improved speed.
But I have to warn that this renderer also has some regressions that I haven't fixed or even identified, and I'm not sure which games they occur in, this is just based on some old reports from Pandora users. So all things considered it may be worthwhile to just use the old one anyway, unless SuperGrafx support is an important goal.
To know that the ARM9 can run this at 150Mhz at full speed is a great reference. And it does seem to me that we don't have full access to 100% of the 3DS's app core, or I am missing something in my codes.
It'd be good to have some idea of just how much CPU time you have available. Do you have any means of profiling, or using the benchmark mode built into the emulator?
