Any possibility of this running PS2 emulators?

[Zednark]

I'm talking from a hardware standpoint, as obviously it'd need programmers on the project. Just wondering if it'd be possible.

 

[notaz]

Not with currently available emulators, and making a new ARM optimized one would be a huge effort. Even then, as always, it depends on the game in question as the games use hardware in very different ways, but perhaps some would be playable.

 

[ZXDunny]

Is that playable as in "OMG! x86 emulation+WINE is playable on the Pandora!" or "Dreamcast is now playable on the Pandora!", or are we talking actually playable?

D.

 

[Haraldur]

I tempt correction from the more knowledgeable, but I shall speculate based on some Instructions Per Second (IPS) and FLoating-point Operations per Second (FLOPS) data I have found on the web.

Firstly, according to this table, the Pandora's Cortex-A8 has 2 IPS per Hz, so for a 1GHz Pandora there are 2000 MIPS (Mega IPS), while for the Pyra's Cortex-A15 the ratio is between 3.5 and 4.01 (let us assume 3.5), giving 5250 MIPS at 1.5GHz. That is, the Pyra's CPU should be about 2.5 more powerful than the Pandora's (I ignore the Wattage question). The Pyra's PowerVR SGX544 GPU allegedly gives 7200 MFLOPS (Mega FLOPS) at 200 MHz (which I shall accept, but I have no idea what clock speed the Pyra would use).

According to this table, the PS2 total power (including all processors like CPU an GPU) is 1997 MIPS and 6200 MFLOPS, while for the Dreamcast (already working on the Pyra, I believe) the values are 291 MIPS and 2800 MFLOPS, for the original XBOX (though I believe that is not sufficiently well documented for a serious emulator) there are 1203 MIPS and 7300 MFLOPS and for the GameCube 1596 MIPS an 11000 MFLOPS.

Assuming the Pyra's GPU is clocked at 200 MHz, the GameCube and XBOX are out of the question (but, again, I have no idea about the Pyra's GPU's clock speed), while the PS2's MFLOPS are barely less. If the GPU is somehow clocked at 400 MHz then they all become reasonable, except for the GameCube, perhaps (is there significant overhead for graphics?).

From the MIPS values, it is clear that the Pandora never had a hope of playably emulating a PS2, as the values were essentially the same for the two machines (there is some overhead from dynamic recompilation and so on, which I know little about). The Pyra would seem to be fine for PS2, GameCube and XBOX from MIPS alone; the question is then: what is the rule of thumb for the ratio between a emulating machine's minimum viable performance and the emulated machine's maximum possible performance? If the ratio is 2:1 for MIPS and and near 1:1 for MFLOPS, then the PS2 may well be possible to emulate well with the GPU at 200 MHz, but there would absolutely need to be hardware accelerated graphics, as software mode would not have a chance (assuming 1 IPS = 1 FLOPS, (1997 MIPS + 6200 FLOPS) > 5250 MIPS). The other consoles are easier for MIPS only, but have higher graphics requirements, it seems.

Does anyone know the intended clock rate of the Pyra's GPU? Is it hardwired in the OMAP5?

What is the approximate power ratio of emulator to emulated, assuming a competently made emulator?

 

[Klumpen]

Sure, you can run them via Qemu+WINE, I guess.
No, you won't be able to play Shadow of the Colossus.

 

[ZXDunny]

It depends on the hardware interactions between the emulated processors. If there's tight scheduling then parallelisation won't help much, most of the time cores would be hanging around waiting for other cores to finish what they're doing.

As an example, an accurate z80 emulation (of a CPU running at 3.5MHz) requires about.. 40Mhz to achieve without a dynarec. Add in a graphics processor that stalls the z80 and you're suddenly looking at at least 150MHz to get a usable emulation. If the interaction between graphics and CPU requires stalling at the T-State rather than scanline level then it's up to 200MHz+ and that's with a granularity of 4Ts. The more accuracy you add, the higher the requirements - currently to get an accurate emulation going in Windows of a Spectrum requires upwards of a 366MHz CPU. That's 100x the original CPU speed.

Of course, it varies depending on what the CPUs you're emulating actually do, and how and when they do it.

I'd be quite surprised if there's anything that the Pyra will be able to emulate that the Pandora cannot - I suspect it will be pretty much the same emulated systems but with better framerates. I'd be even more surprised if the Pyra emulates PS2, given the PC specs necessary to get a playable framerate.

D.

 

[Haraldur]

I'd be quite surprised if there's anything that the Pyra will be able to emulate that the Pandora cannot - I suspect it will be pretty much the same emulated systems but with better framerates. I'd be even more surprised if the Pyra emulates PS2, given the PC specs necessary to get a playable framerate.

I thought the Dreamcast (reicast) was effectively Pyra-ready and Pyra-only (at reasonable frame-rates)?

I have a slight hope, given a lot of programming effort by someone, that less demanding games like Disgaea may be playable (though in that particular case PPSSPP would likely be better).

It depends on the hardware interactions between the emulated processors. If there's tight scheduling then parallelisation won't help much, most of the time cores would be hanging around waiting for other cores to finish what they're doing.

Ah, yes. I forgot that the Pyra would have 2 Cortex-A15s, so the effective MIPS is 5250 worst case and 10500 best case.

As an example, an accurate z80 emulation (of a CPU running at 3.5MHz) requires about.. 40Mhz to achieve without a dynarec. Add in a graphics processor that stalls the z80 and you're suddenly looking at at least 150MHz to get a usable emulation. If the interaction between graphics and CPU requires stalling at the T-State rather than scanline level then it's up to 200MHz+ and that's with a granularity of 4Ts. The more accuracy you add, the higher the requirements - currently to get an accurate emulation going in Windows of a Spectrum requires upwards of a 366MHz CPU. That's 100x the original CPU speed.

Are these MHz values you give ALL for a Z80? This table states that the Z80 performs 0.145 instructions per clock (IPC), while for the Pyra the CPU can do 3.5 instructions per clock per core (under what conditions I know not). I assume that the types of computations required for emulation would be similar to the those used in the benchmark tests (to enable this conversation), so a multiple of 14x (Pandora, 2 IPC) or 24x (Pyra with only one core, 3.5 IPC) would make a big difference -- if you meant 200MHz+ on a Z80 then that would be about 10MHz on a Pyra. If all your figures are for a notional Z80, then the ratios are about 1:10:40:50+ without a dynarec -- how much better is a dynarec? Would a dynarec give a ratio of 1:2, 1:3, 1:4, what?

What is a T-state? The top result on Google suggested that it had something to do with temperature and throttling.

What about high-level emulation? What about if accuracy is sacrificed for speed, like in old SNES emulators (or so I have read)? What is the minimum reasonable ratio?

 

[ZXDunny]

Are these MHz values you give ALL for a Z80?

Go back and re-read. The initial figure is for a z80 - they're easy to emulate with only around 700 opcodes to take care of.

Add in a graphics processor (in this case a Ferranti ULA) which interrupts the z80 in order to take control of the memory bus for reading from shared display memory. You could always just read out the whole graphics ram at the end of each frame, but you'd not emulate accurately - the ULA interrupts the z80 based on a pattern of what's called "contention" which effectively freezes the z80 if they're both trying to read from the same 16kb block. This is used quite effectively by coders to create more colour blocks on the screen than the Spectrum is nominally capable of.

Adding in this second CPU adds more complexity and drives system requirements up. You can't use a dynarec with it as the interaction between the two chips would negate any possible speed gain - the ULA is throttled to the framerate.

What is a T-state? The top result on Google suggested that it had something to do with temperature and throttling.

A T-State is microcode in the z80's instructions, the building blocks that make up the opcodes. The z80 can be interrupted at any point during certain stages of an opcode execution (notably memory and port i/o access, including opcode fetch) For a long time it was thought that the granularity of the interaction between ULA and z80 was 4Ts, but that has been disproved recently with emulation of a video artefact called "ULA Snow" which happens when the IR register pair (which handles memory refresh) is corrupted resulting in display garbage - and that happens (Accurately) with a granularity of just 1TState. Emulating that pushes system requirements up to way more than 400MHz and with Windows overheads will only get higher. That said, the majority of games and apps on the Spectrum don't rely on this, but then there are one or two games that do need it...

What about high-level emulation? What about if accuracy is sacrificed for speed, like in old SNES emulators (or so I have read)? What is the minimum reasonable ratio?

...Which brings me to my final point -

Yes, you could reduce the interactions between CPUs/GPUs/PSGs etc to their bare minimum, run them on multiple cores with careful thread sync, dynarec them where you can, and even just do a "high level" emulation which works with a few games - but there will always be some games that people want to run which will bring the emulator to its knees.

Shadow of the Colossus? Hardly - that one is pretty hard to emulate at full speed on mid-range PCs, as are more popular titles such as Katamari.

Sure, we could get a working version for a small subset of games but that won't be enough for a great many people. Hell, they're still complaining at PC emulators even now.

D.

 

[Haraldur]

Go back and re-read. The initial figure is for a z80 - they're easy to emulate with only around 700 opcodes to take care of.

Pardon me, but when you just said "CPU" the pedant in me said that the Z80 is a CPU and that it could, in principle, emulate itself. If by "CPU" you meant "modern Intel CPU", then that is very different, as they are about 40x faster at a given clock speed (for one core, for a quad core 160x). Do I overestimate the importance of IPS vs clock speed?

Yes, you could reduce the interactions between CPUs/GPUs/PSGs etc to their bare minimum, run them on multiple cores with careful thread sync, dynarec them where you can, and even just do a "high level" emulation which works with a few games - but there will always be some games that people want to run which will bring the emulator to its knees.

Shadow of the Colossus? Hardly - that one is pretty hard to emulate at full speed on mid-range PCs, as are more popular titles such as Katamari.

Sure, we could get a working version for a small subset of games but that won't be enough for a great many people. Hell, they're still complaining at PC emulators even now.

On x86 GNU/Linux I have had great trouble getting PCSX2 to work speedily and functionally and prettily for most games (normally: pick two), which I have assumed to mostly be a result of the prioritization of Direct3D and other Windows interfaces. I assumed that PCSX2 was quite good on the M$ OS.

Yes, many games would not work, but I was thinking of a bare minimum emulator; my impression is that, early in a game console's existence, the games are programmed in a relatively straightforward way, resulting in less impressive visuals, until all the little tricks of the system are learned by the programmers (and that some may be ports from earlier systems, as they were not released early enough -- was Castlevania SOTN not meant to be a Sega 32X game originally?). This would mean that quite a few early PS2 games might work just about acceptably.

Of course, I recognise that that may not be good enough to motivate someone to make an emulator, and that certain people would see "PS2 emulator", get excited and then complain when a particular game does not work.

Thanks for your informative answers.

 

[Mr_Loon]

I'm talking from a hardware standpoint, as obviously it'd need programmers on the project. Just wondering if it'd be possible.

Guess we'll never know until it happens, I was just about to post that playable PS2 for any commercial game would be impossible on Pyra, then someone who actually knows what they are talking about (Notaz) suggests it would indeed be possible...

FWIW I'd have said it was impossible to get playable NDS emulation on a CC Pandora, based on using other NDS Emulators on vastly more powerful x86 & Arm systems, then along comes Exophase with Drastic...

There could be a good commercial incentive for an Arm Optimised PS2 emulator (For instance Drastic has had between 500,000 - 1,000,000 installs according to the play store) so you never know...

 

[Exophase]

I tempt correction from the more knowledgeable, but I shall speculate based on some Instructions Per Second (IPS) and FLoating-point Operations per Second (FLOPS) data I have found on the web.

Firstly, according to this table, the Pandora's Cortex-A8 has 2 IPS per Hz, so for a 1GHz Pandora there are 2000 MIPS (Mega IPS), while for the Pyra's Cortex-A15 the ratio is between 3.5 and 4.01 (let us assume 3.5), giving 5250 MIPS at 1.5GHz. That is, the Pyra's CPU should be about 2.5 more powerful than the Pandora's (I ignore the Wattage question). The Pyra's PowerVR SGX544 GPU allegedly gives 7200 MFLOPS (Mega FLOPS) at 200 MHz (which I shall accept, but I have no idea what clock speed the Pyra would use).

According to this table, the PS2 total power (including all processors like CPU an GPU) is 1997 MIPS and 6200 MFLOPS, while for the Dreamcast (already working on the Pyra, I believe) the values are 291 MIPS and 2800 MFLOPS, for the original XBOX (though I believe that is not sufficiently well documented for a serious emulator) there are 1203 MIPS and 7300 MFLOPS and for the GameCube 1596 MIPS an 11000 MFLOPS.

That number, "DMIPS", is not instructions per second but the result of an almost meaningless benchmark called Dhrystone.

That said, Pyra being 2.5x more powerful per core than Pandora is roughly in line with my expectations based on other tests.

The MFLOPS comparison isn't very useful either, because PS2 has 0 MFLOPS in its GPU. They come entirely from the Emotion Engine (vector units plus CPU) and it will probably not be viable to use the Pyra's GPU to help emulate it. I'm not totally sure about the XBox or GameCube numbers, I think those have actual floating point available for vertex shading/T&L.

There really isn't that much potential in looking at raw theoretical numbers like this and then applying a magic ratio of emulation overhead. It just doesn't really work that way. So much depends on the nuances of the system design and how the games work.

For example, PS2 is a big pain because the floating point operations don't follow the IEEE-754 standard. They don't support infinities or NaNs and have more effective dynamic range because of it, and shockingly games actually do rely on it. PCSX2 uses a bunch of clamping tricks and what have you to work around it and make games happy enough, but this adds overhead. A fully reliable solution would be slow, requiring calculations using doubles or ints to emulate their floats.

 

[Kev2442]

Very interesting thread. I might add that the Dreamcast is not a good example, as its PowerVR 2 may be quite similar to the SGX series. I don't know for sure, but I suppose there could be some sort of compatibility layer that helped in emulating the system.

Do you consider Gran Turismo 3/4 to be as optimized as a SotC is ? There are quite a few heavy graphical optimizations (480p and 720i on GT4) but the main game may not rely on such hardware specificities.

 

[ingoreis]

Playstation-2 is possible on the Pandora over Remote Play from another PC where the PS2 emu runs:


But an Playtation-2 Emulator for the Pandora would be realy nice.
I asked serveral Times for it..but its definly too Difficult to port PCSX2 because many Pure X86 Code on the Sourcecode.
We have no X86 on the Pandora...we have an ArmV7a+Neon CPU.


But there is a Project with an Opensource Arm Optimized Playstation2 Emulator named Play!
http://purei.org/

With this Play! Emulator i can see new Hope for a working PS2 Emulator.
Shure...it will be very slow but it can be possible and maybe we will find more Chances to optimize it then

 

[Askarus]

^
Nice info. Never heard of Play! before.
I see PtitSeb work ....

 

[God Ginrai]

Not with currently available emulators, and making a new ARM optimized one would be a huge effort. Even then, as always, it depends on the game in question as the games use hardware in very different ways, but perhaps some would be playable.

So not unless someone comes along doing something similar to what Ari64 did?

My answer was just going to be: "Not until we see a CPU board replacement with a more powerful SoC".

-God Ginrai

 

[ZXDunny]

So not unless someone comes along doing something similar to what Ari64 did?

My answer was just going to be: "Not until we see a CPU board replacement with a more powerful SoC".

-God Ginrai

I'd go with your answer to be honest. What happened with Ari64 and his N64 emulation was that N64 went from "nothing more than a very slow tech demo" to "Almost playable if you're not very picky about what you want to play, and even then it's Mario64". Even now, after all these years, N64 is generally unplayable on Pandora and the amount of faffing around needed with the various plugins is a joke.

That's probably about the best we can hope for using the initial CPU board in the Pyra for PS2, and even then I'm very doubtful. On Pandora we have one higher-end emulator that's up to the job and that's Notaz's PSX emu. N64, PSP, DC, Saturn, PC-DOS/Windows et al are proof of concept at best. Even Exophase's NDS emulator is borderline playable and I have yet to see a single video from Ingoreis that I would categorise a having an acceptable framerate for a Windows game, despite his enthusiasm.

D.

 

[levi]

I generally leave my N64 plugins set up to run F-zero X well. Many other games run well on my 1GHz unit with those settings (especially the earlier releases), but as long as I can play F-Zero X when I want, that's all that really matters to me

 

[RubisDrake]

The big problem with emulators like PCSX2 is that they, for some reason, use x86 32-bit assembly code, making it only able to run that code on that specific architecture. If only somebody could successfully translate that ASM code to C (or whatever the emulator uses) could it then finally become a multi-platform emulator.

In terms of the hardware, I'm not sure. The sad truth is that, for emulation specifically, faster cores perform better than more cores of lower speed. This is especially true with MAME and MESS emulators which focus on low-level emulation (LLE) versus high-level (HLE). Multithreading helps little with most types of emulation, especially when you are trying to translate heavy hardware instructions with software. And for 3D video games, a good GPU does matter!

I'd expect the Prya to perform almost flawlessly with PCSX, or Mednafen's PS1 emulation perhaps, since they can use OpenGL (not sure about OpenGLES), but intensive PS2 games are a bit of a stretch. I'd stick to playing them on the desktop, personally.

 

[God Ginrai]

What happened with Ari64 and his N64 emulation was that N64 went from "nothing more than a very slow tech demo" to "Almost playable if you're not very picky about what you want to play, and even then it's Mario64". Even now, after all these years, N64 is generally unplayable on Pandora and the amount of faffing around needed with the various plugins is a joke.

That's actually not true. There are plenty of N64 games that run fine even on the original Pandora with the current version of the emulator. For example, Bomberman 64: The Second Attack runs basically fullspeed, with only a couple of graphical glitches to worry about. Sure, Ocarina of Time never reached a good point, but there are plenty of games that run well on the N64 emulator on the Pandora.

-God Ginrai

 

[ZXDunny]

The big problem with emulators like PCSX2 is that they, for some reason, use x86 32-bit assembly code, making it only able to run that code on that specific architecture. If only somebody could successfully translate that ASM code to C (or whatever the emulator uses) could it then finally become a multi-platform emulator.

I'm fairly certain that there are two possible reasons for that - a) the coders are not good enough at C to write truly performant code, or b) it really is possible to write asm that cannot be expressed in standard C which will run rings around any compiler output in terms of speed.

So basically, the desire to translate from asm to C in order to gain portability is actually a desire to get a slower emulator on your platform of choice.

That's actually not true. There are plenty of N64 games that run fine even on the original Pandora with the current version of the emulator. For example, Bomberman 64: The Second Attack runs basically fullspeed, with only a couple of graphical glitches to worry about. Sure, Ocarina of Time never reached a good point, but there are plenty of games that run well on the N64 emulator on the Pandora.

And there are an enormous number (far outweighing the few that do run well) that do not. Unfortunately, they tend to all be the popular ones... So yes, it is true. Your definition of "playable" might not be the same as mine, however - I'm not a fan of frameskip, missing textures/polygons and sound stuttering.

But Pyra will almost certainly run N64 quite well indeed.