Pandora-on-Pyra Emulator?

[Grench]

OK, so, I was thinking - which usually gets me in trouble.

The Pyra is going to have all sorts of system emulators available for it - eventually.
The Pyra is going to have the majority of the Pandora programs ported over to it - maybe quickly?

There are a few things that will 'get in the way' of just being able to grab a Pandora PND file and run it on a Pyra. People are going to have saved games, a few programs that don't migrate quickly, etc. And the PND system did a few very neat things with how it handled removable media.

So, here is the idea. Have a Pyra program that essentially plugs in the needed bits to allow it to run Pandora PND files. In theory this program would look/find the PND related folder structures on the most likely storage targets - so that it would recognize an SD card that was set up for the Pandora.

I understand that there are different compile flags needed for an application to run native on the Pyra Vs Pandora. Ideally this emulator would provide on-the-fly translations (this is the hard part and what makes this an emulator).

How difficult would it be to make? Would it be worth the effort?

 

[pmprog]

Not sure a fair few of the Pandora PNDs were open source, so it'll be easier to recompile... All you need to do is add code to look up the old Pandora storage locations.
That would be much easier than working am emulator

 

[Eight Bit]

Wouldn't it be easier and make the software run faster to just compile it straight on/for the pyra?
[doublepost=1565368905,1565368851][/doublepost]Missed pmprog's post

 

[TeDaDeS]

Some people don't know how to recompile applications themselves. So it would be easy to have a Pandora emulator, maybe even for PC.

 

[Grench]

I thought that a few of the Pandora programs, though, were independently done and no source code exists in the community?

Also, there is the matter of save games migration - might be trivial.

It feels odd that a device built for emulation isn't set up to effectively emulate it's own predecessor. Maybe that is just a pedantic point of view.

 

[lukey]

Creating an LXC Container with SuperZaxxon shouldn't be a Problem. The specific Pandora-Optimized parts are problematic: We'll need to emulate the Low-Level input-devices, scaled Framebuffers (that are compatible with the Optimized libsdl) and the DSP (as the one in the OMAP5 is weaker).

 

[Grench]

Creating an LXC Container with SuperZaxxon shouldn't be a Problem. The specific Pandora-Optimized parts are problematic: We'll need to emulate the Low-Level input-devices, scaled Framebuffers (that are compatible with the Optimized libsdl) and the DSP (as the one in the OMAP5 is weaker).

Might not be worth the effort then. I have just always sub-consciously equivocated a PND-Pandora as a CartridgeROM-emulator.

 

[Swordfish II]

Afaik the dbp system is very very similar to pnd and shouldn't be hard to recompile.

 

[levi]

Creating an LXC Container with SuperZaxxon shouldn't be a Problem. The specific Pandora-Optimized parts are problematic: We'll need to emulate the Low-Level input-devices, scaled Framebuffers (that are compatible with the Optimized libsdl) and the DSP (as the one in the OMAP5 is weaker).

As far as I know the dsp in the OMAP3 family of chips used in various Pandorae has never been used in anger. Some effort was expended in getting basic code running on the thing, but in the end trying to actually use it in anger turned out to be much harder than just rewriting frequently used code using NEON instructions.

There are differences in the NEON implementations between the OMAP3 and OMAP5 I've heard, but in reality, I'm most interested in rescuing early pandora exclusive releases with no source and a thus far lost authors such as Super Geometry Dust.

 

[elw3]

Ive actually did that already, pnds can start just fine if you chroot into a copy of the pandora OS, graphics work and no recompile is needed between hardfload/softfloat.
Hardware is a different question tho, you probably need to adjust the screen size setting rather than scaling the window for example, hardcoded buttons wont ever work i suppose.
But only idiots hardcode buttons in.
Also asciiman wont ever work due to hartcoded buttons so its just a waste of time to even try to build a pandora wrapper, only stupid games like mrs snake and hase will run..

 

[PowerGod]

@Elw3 : did you have a bad day ?

 

[Grench]

I'm most interested in rescuing early pandora exclusive releases with no source and a thus far lost authors such as Super Geometry Dust.

Yup. That one is top of my concern list. Great game - should be awesome on the Pyra - no source, just a PND. Essentially it is a Pandora only game ROM.

 

[elw3]

@PowerGod
ffs!
*flips table*
Its called humour!

 

[asimov-solensan]

Same question arised regarding Pandora and gp2x. The answer was ginge.

Can't know if a similar thing is possible in Pyra for Pandora packages.

 

[Hellfleck]

some kind of compatibility layer is probably doable as its "almost" the same hardware but anything too close to emulation is a definite no

although I am really looking forward to it the Pyra is not that much more powerful than the 1GHz Pandora was / is

 

[darkcpc]

Same question arised regarding Pandora and gp2x. The answer was ginge.

Can't know if a similar thing is possible in Pyra for Pandora packages.

I would much prefer native emus for pyra even if they are just straight pandora ports.

 

[FBnil]

Interesting idea about the chroot, @Elw3 so, the Pyra Linux kernel runs with the Pandora GNU uh.... tools.

*put's table back and quietly leaves room while softly closing door.*

 

[levi]

Same question arised regarding Pandora and gp2x. The answer was ginge.

Can't know if a similar thing is possible in Pyra for Pandora packages.

Indeed. I remember when I was mostly lurking on the old gp32x forums, people were discussing how to use both the main CPU and the secondary CPU on the gp2x, but I don't know how often that was used seriously in games. Maybe ginge emulates both CPUs, or maybe it doesn't actually support the secondary CPU as it was rarely used in anger.

It strikes me that the GP2x was a much simpler device that the Pandora turned out to be, and optimisation efforts seemed to go further, so there may be more corner cases for the Pandora where special care in a PandoraGinge for the Pyra would need to be taken.

 

[Wally]

Not sure why we'd want a Pandora emulator when we can just port everything (or kindly ask the people who have games with close source ports to port to the Pyra for us.

I'm sure they'd be happy to do that when we get hardware but we don't have the hardware yet right?

 

[Lightkey]

although I am really looking forward to it the Pyra is not that much more powerful than the 1GHz Pandora was / is

Welp, Wally chickened out (or platypussied out?). :-D
Anyway, as has been repeated a lot of times already, the OMAP5 is a lot faster than the OMAP3. Conservatively at least 3.5 times as fast per core, which makes it 7 times with both cores, that is plenty.
That is because the OMAP3 was before the smartphones boom and was supposed to work even without passive cooling, so it was optimised for low power while the OMAP5 was the opposite, to the point that nobody wanted to use it because it overheated without proper cooling, which ended Texas Instruments' development of the OMAP line.
The real trouble with the OMAP5 is not performance but lack of current features like 64-bit and OpenGL ES 3.