Thanks for the informative post hlide, indeed I think PSP w/HLE is a very interesting and unconventional emulation choice.
hlide said:
In fact, it is very difficult to answer. If a PSP game just uses only MIPS instructions (CPU+FPU), it would probably be okay with the appropriate HLE and a good GE emulator through OpenGL. But if this game really uses VFPU (as I would expect it for recent 3D games), I fear that would be very difficult as VFPU is quite a beast to emulate (http://forums.ps2dev.org/viewtopic.php?t=10471).
Some details about PSP :
The only fear is that the games heavily use the Allegrex's FPU in a way such that it does not map well to NEON. And you'd want to throw NEON at VFPU emulation as much as possible, so would not want to tie up resources in register caching FPU for it, etc.
hlide said:
- So only two types of RAM to emulate : main RAM and VRAM for GE. We can use a check and patch memory selector (before reading or writing a register in memory, we check whether the address is in the expected memory - if not, we patch the faulty code with the right code for the right memory; for most time, this patch would be done only once as this part of code is only accessing either main memory or VRAM)
Although there are only two types of RAM, there are more than one region for each because of cached vs. uncached. However, because none of these read/writes have any side effects this is a perfect opportunity to use mmap to emulate it directly. You just need to make sure that the address space the emulator needs is placed somewhere where user mode on PSP cannot access, and this can most likely be guaranteed with a proper linker script.
With both memory and I/O out of the way you're free to make a very efficient recompiler. Having direct memory accesses means that you can do complex conversions say from series of loads/stores to ldm/stm. I would love to see constant, move, and shift propagation employed to better take advantage of the strengths of the ARM architecture over MIPS32 (and help fight some of the disadvantages). This would work well for addressing especially, IE converting "shl r1, r3, 2; add r2, r2, r1; ld r1, (r2)" into "ldr r1, [r2, r3, lsl #2]" at least. Also some kind of efficient global register allocation.. it could all get very complex, be sure to write a dissertation on it when you're done. But you've already been doing MIPS->ARM recompilation anyway.
hlide said:
- Official game developers cannot program the second Allegrex processor in ME as it is used for codecs. So no need to emulate this second processor. Great.
But, you still need to emulate the codecs, and as far as I'm aware there is dedicated hardware in PSP for this. The OMAP3530's C64x+ DSP would most likely be put to heavy work, but I think it should all be doable.
hlide said:
What else ?
In fact, my very first fear is about VFPU : would it be possible to turn them into fast NEON instructions ?
Clock for clock NEON can't match VFPU, so the only hope you have is that the great clock difference (cross fingers for 900MHz) would outweigh that.
However, there is another major fear IMO, and that is whether or not the SGX 530 can really catch up. You said to use OpenGL, however as you know there are many subtle features in PSP's GU that do not map to OGL and would have to be emulated with shaders. SGX 530 doesn't look like it'll have extremely strong shaders, and there isn't really a clock advantage here (maybe even a disadvantage). There are also different texture formats, including swizzling, so you'd need caching (and I think some PSP games load textures constantly), and there are the same problems for PS1 emulation with full access to VRAM, this time for the CPU as well. PSP claims to be able to handle far more triangles than SGX 530 to begin with. I don't know how this will work out in the real world, for games, especially those that are using the GU at 111MHz, but it seems like you're bound to find something that doesn't map well enough fast enough.
Maybe aiming for 2D games would be the most realistic bet.
andora1:
