Okay then. Either way, this topic can be closed as we will never know how they actually achieved PS2 emulation
I wasn't sure if you and Milk were trolling me earlier so I just stopped responding, but I brought in both CPU and GPU numbers for a very real reason.
Let's go with your assumptions but I'll preface why you cannot vaguely use one situation and apply it to another. First off, emulation is not impossible, it can be emulated but all emulation comes with extremely high overhead.
There's quite a difference running virtualization and emulation and in this case with XBO you are going to run emulation if there is hardware missing.
Luckily as you pointed out everything else is the same so the emulation wrapper can be fairly light weight, we assume. But the wrapper will still have to exist as it will be looking for API calls that shuffle data into and out of and directly addressing memory addresses inside esram.
Once the Wrappers spots these calls it's going to have to tell the program to look for these specific memory addresses elsewhere and work from there.
So part 1. Increased CPU requirement, the system is now looking for additional API calls and searching to line up addresses and mapping it into a similar space. In this case we expect there to be a lot of esram calls as 90% of XBo bandwidth is there. It's also only 32MB large so we expect a lot of action since space is limited. There is also a small hurdle that the CPU doing this check and moving memory is going to be significantly slower than DMA engines moving memory from the larger pool to esram or etc. This time the CPU will move memory from one address and write it to another address (read and then a write, and we know this to be a heavily penalty on DDR bandwidth).
This is a large overhead but not as big as translating a completely different CPU.
Let's talk GPU. So the GPU is now going to be stalled up waiting for memory in large because the program normally relies on a much speedier response from esram. This time we have a CPU moving memory over the main bus and not over DMA bus. We don't get advantage of swizzling while the textures are being moved and so forth. But let's break down to what happens, the game shaders are written likely with the assumption that simultaneous read/write or just quick switching between the two without penalty. There's nothing the emulator can do about changing that so now we are going to have to suffer some delay of getting this information to proceed.
Okay no problem. So I've framed it and I'm sure you understand everything I've written. Now your response is well PS2/PS3.
Okay so this is where ratios of powers do matter. You only know the end result, which is that emulation works. You do NOT provide a breakdown of frame time data. As far as any of us know PS3 could be struggling with EDRAM emulation but it makes up much more with it once it comes to PROCESSING. The GPU is 30x faster than. PS2.
Without real world knowledge of which parts is slow and which parts is fast you have a vague argument. Emulation is a non issue but performance is.
So it's why I brought up both CPU and GPU requirements. This next Xbox will be iterative, it's not going to have such a massive performance delta to be able to make up the latency of waiting for data to work.