I wouldn't stop playing this game if possible on a handheld.
But interresting Idea to test it.
I buy a Pyra too when it start
What could we hope to emulate?
- Thread starter Kian
- Start date
But interresting Idea to test it.
I buy a Pyra too when it start
Don't you think if the Wine/Qemu project with OpenGL might be revived it might me possible to play Rome?
If Pentium 3 at 1GHz is too much, what might me more realistic?
At least we have a multi-core processor and one core could be used to do the qemu stuff and the other for the game.
If Pentium 3 at 1GHz is too much, what might me more realistic?
At least we have a multi-core processor and one core could be used to do the qemu stuff and the other for the game.
Is there any hope, for Rigs of Rods (a opensource driving simulator whit a cool physik, and a lot of mods, and Openmorrowind on the Pyra??
The situation is a little more complicated then that. Of the 6th Generation only the GameCube and Dreamcast could be argued to have relatively mature and applicable emulators. The XBox emulators aren't exactly mature, and Playstation 2 emulation has only started to reach maturity on the x86 platform.
At this point PCSX2's recommended system is a Core 2 Duo at 3.2GHz or an i3 at 2.8GHz. It's designed to only utilize two cores, and of those cores only one core is for the actual emulation process with the other being for offloading plug-ins and other things that would interrupt the main emulation process thread. The required specs is just a processor with SSE2 and alludes to a base level Pentium 4.
However it should be noted that PCSX2 is primarily designed for Windows and built off of x86 recompilers, and thus work would need to be done to move it's codebase to working better on Linux and with ARM recompilers to even begin to contemplate such things. It'll take a while for their project to get around to that, not to mention increasing the sophistication of their emulator to improve multicore utilization.
At this point the software isn't really there. It wouldn't surprise me if the Pyra's successor wasn't in the works by the time the software would be there to really test the hardware with. Maybe there's a similar project already working with ARM tools and getting their codebase to really multithread, but I'm not aware of it.
In the context of emulation I wouldn't be so fast.
The Nintendo DS involved the combination of an ARM9 at 67 MHz and an ARM7 at 33MHz with the DSi only modifying things in terms of cranking the ARM9 up to 133MHz. The ARM7, ARM9, and ARM11 are all single issue in order designs, while the Cortex A8 used in the Pandora is dual issue in order design. So in term of theoretical throughput a 1GHz Pandora could handle roughly 20x the number or ARM instructions a DS can.
As far as I'm aware there are no official stats on the 3DS, but the Internet seems to believe it's a pair of ARM11's at 400MHz, in addition to the PICA 200 GPU was intentionally designed to be programmable. In terms of CPU you're talking roughly 8x the power of the DSi, and 8x the power of the DS. In terms of straight up on a single core, it wouldn't appear to be viable with current techniques.
On the other hand the Dreamcast's SuperH4 CPU ran at 200MHz and was a superscalar dual issue design. So improvements in techniques for handling the multicore processor the Pyra might allow it. Although again such a project would be liable to be reaching maturity in a few years time, even ignoring the issues raised by the increasingly sophisticated operating systems used by 7th and 8th generation consoles.
I'm pretty sure that doesn't work given what Qemu does, in this context, is translate the binary instructions. Even if you had one core translating instructions and then writing a que to memory for the other core to read, the I/O of going from die to off die and back through the memory bus would result in you effectively losing a ridiculous amount of your potential cycles while the thread is locked and waiting on memory meaning that the processor is effectively stalled in the mean time.
What you could do would involve trying to find some way to split off process threads so they could be split off to multiple cores, but that not exactly a simple thing to implement.
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
Emulation is a very nuanced sort of thing, it's hard to tell what you need to emulate something efficiently before you're deep into emulating games. For example: DraStic will often only spend 10-20% of its runtime executing recompiled code, plus a few more percent for some functions commonly called from the recompiled code. The rest of the time is spent emulating 2D, 3D, geometry, SPU, other memory mapped peripherals, glue logic in timing and task switching, and so on. If you tried to deduce this sort of thing by comparing the theoretical throughput of the CPUs you wouldn't get this far. Even just for core CPU emulation comparing peak throughput doesn't tell you much - Cortex-A8 is dual issue but compared to the ARM9 it has a lot more interlock points and a big branch misprediction penalty (while ARM9 has a more constant branch taken penalty). And in terms of cycles an L1 cache miss that hits L2 on Pandora might be similar to an L1 miss on DS, but an L2 miss on Pandora costs many times those cycles. And with all the code bloat a recompiler adds, even going ARM to ARM, the L1 icache pressure is a lot worse... plus DS games use 32KB ITCM + 16KB DTCM heavily which Pandora doesn't have.
3DS is 268MHz ARM11 x2, 134MHz DSP for audio, and 268MHz PICA200 GPU. Without knowing how much overhead there is in mapping that GPU to OpenGL ES 2 or 3 or whatever it's impossible to say what emulating it is like. And this will invariably have a lot to do with how the OS, libraries and games are actually written. Allegedly, one core was originally dedicated to system software and was at some point opened up for user applications. Maybe extensive HLE could work well like it does with PSP emulation. Or maybe not. Until emulators are written in some form we won't really know.
With Dreamcast emulation they really can spend a lot of its runtime just emulating SH4 instructions, without having to very frequently switch out and emulate other stuff. So the dynamics are very different vs a system like DS, hence why the emulation can work so well despite Dreamcast being a lot more powerful. But you'll never be able to emulate a single core using multiple cores. Threading out the recompiler doesn't really make sense, usually you're recompiling code because that code needs to be executed. And you're not supposed to be spending a bunch of time recompiling stuff, and you usually aren't.
Last edited by a moderator:
God Ginrai
Godmaster
I'll just leave these here:
http://www.racketboy.com/retro/games-that-defined-sega-saturn
http://www.racketboy.com/retro/best-undiscovered-sega-saturn-games
It must suck to be one of you people who get headaches when they use the 3D mode on the 3DS.
Actually, that's not the case. We voted for the OMAP over the Freescale chip that Craigix, EvilDragon, and co. were looking at because it opened up the possibility of N64 emulation. We always thought we could get one, we just didn't expect it to be ready before the device released thanks to the awesome efforts of Ari64.
DS Emulation, yea, people probably weren't expecting that. I was always of the opinion that we would only get one if Exophase decided to tackle it. I was pleasantly surprised when he went and did just that.
-God Ginrai
Exophase:
Good to know, but given the Cube doesn't seem to be the OP's focus we're not really talking about a single CPU core. So in theory you could do something like for the PS2:
CPU0:
-Host OS
-Emulation Manager, which would need to regulate dispatch, timing, and pulling things together
-Misc Emotion Engine bits
CPU1:
-PS2 CPU0 & VPU0 thread offload
CPU2:
-PS2 VPU1 & OpenGL/OpenCL translation of PS2 graphics offload
CPU3:
-Plug-ins etc.
Or for the 3DS:
CPU0:
-Emulation Manager & Misc bits
CPU1:
-3ds core0 thread offload
CPU2:
-3DS core1 thread offload
CPU3:
-GPU translation to OpenGL/OpenCL offload
[-]
I'm not sure if that'd work given multicore adds extra complexities with pulling things together, but I imagine you'd need to do something like that to handle PS2 emulation on the Shield. In addition to all the core infrastructure stuff like ARM recompilers instead of x86 ones. I wouldn't expect full speed, but with that kind of offload/multithreading I could see some definition of playable being possible. I however wouldn't expect PCSX2 be there for years yet.
Good to know, but given the Cube doesn't seem to be the OP's focus we're not really talking about a single CPU core. So in theory you could do something like for the PS2:
CPU0:
-Host OS
-Emulation Manager, which would need to regulate dispatch, timing, and pulling things together
-Misc Emotion Engine bits
CPU1:
-PS2 CPU0 & VPU0 thread offload
CPU2:
-PS2 VPU1 & OpenGL/OpenCL translation of PS2 graphics offload
CPU3:
-Plug-ins etc.
Or for the 3DS:
CPU0:
-Emulation Manager & Misc bits
CPU1:
-3ds core0 thread offload
CPU2:
-3DS core1 thread offload
CPU3:
-GPU translation to OpenGL/OpenCL offload
[-]
I'm not sure if that'd work given multicore adds extra complexities with pulling things together, but I imagine you'd need to do something like that to handle PS2 emulation on the Shield. In addition to all the core infrastructure stuff like ARM recompilers instead of x86 ones. I wouldn't expect full speed, but with that kind of offload/multithreading I could see some definition of playable being possible. I however wouldn't expect PCSX2 be there for years yet.
Last edited by a moderator:
knightron
Member
I hate to nitpick, but i had to bring this up.
DraStic works fantastically for me, i think you're doing something wrong.
Super Mario 64 Ds runs perfect, Dragon Quest IX and Final Fantasy IV run pretty close to perfect at 1100ghz. Mario Kart runs perfectly in races, and if clocked at 1100, battles are pretty close too. With the latest release, even Golden Sun III has become runable at full speed with minor sound glitches, (i say runnable because i haven't tested it much).
I think it's inaccurate to say 3d emulation of the DS is slow.
To keep things on topic, if the Pyra got Gamecube emulation and could run Pikmin, i would be so happy. Overall though, retaining equivalent or better compatibility with what we already have for the Pandora, would be good.
That's great news, I haven't updated since its initial release!
But how could you get past the Super Mario 64 DS loading screen? Wasn't it 'touch to start', or have they implemented stylus support? Must go check it out!
*I'd love Game-cube emulation too, Super Mario sunshineeeeee!
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
It always had touchscreen emulation.
Last edited by a moderator:
God Ginrai
Godmaster
This made me laugh so hard. I just imagined you as the tsukkomi and Kian as the boke. XD
-God Ginrai
bodies26
Still Fresh
I would love GameCube emuation too, I'd be so awesome! I could play my old games like animal crossing or Mario sunshine again. But I know its hard too emulate GameCube, even the latest tegra 4/snapdragon 800 devices cant handle it.
Gesendet von meinem Nexus 7 mit Tapatalk
Gesendet von meinem Nexus 7 mit Tapatalk
EssoAir
Well-Known Member
To answer the original question, if the correct chipset is chosen (not the OMAP 5) then Gamecube is absolutely within the realm of possibly. Its near playable on some android phones today. give it another year and I expect it to be full speed on the latest hardware.
the biggest thing that is needed is FULL Open GL ES 3.0 support. If thats added and the specs are good enough, then Super Mario Sunshine (my favprote childhood game) could run! That would be awesome!
the biggest thing that is needed is FULL Open GL ES 3.0 support. If thats added and the specs are good enough, then Super Mario Sunshine (my favprote childhood game) could run! That would be awesome!
Last edited by a moderator:
bzar
A Commando
Why is that the biggest thing that is needed?
commander-beef
Very Active Member
I would love to see: GeePee32 emu. Its Win soft, but who knows, maybe it will be released as OpenSource some day..
And more obscure emus.. maybe vmac
And more obscure emus.. maybe vmac
If the Pyra will get backward compatible, whe have Ginge for the good old GPH Handhelds
The Pandora has a lot Emus, so it will be hard for the pyra, to beat it on this competition..
The Pandora has a lot Emus, so it will be hard for the pyra, to beat it on this competition..
EssoAir
Well-Known Member
do some reading on forums.dolphin-emu.org/forum-android
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Or you can just summarize
olphin used to require full OpenGL, but was updated a few months ago to also support OpenGL ES3.0 for mobile platforms.Some other details in there, but that's the gist of it: to run Dolphin we need ES3.0 support at least.
Last edited by a moderator:
- Joined
- Sep 18, 2011
- Messages
- 742
ES 3.0 doesn't add *that* much over 2.0. You can output similar (but less pretty) graphics with just 2.0.
I can't guarantee more than 150-200MHz CPU in WINE, but I'll offload more stuff in the future.
I can't guarantee more than 150-200MHz CPU in WINE, but I'll offload more stuff in the future.
Similar threads
