What software/emulators are in development for the Pyra?


Wrath Of Khan

Soul soother...
Joined
Dec 29, 2009
Messages
5,223
Age
47
Location
Ireland
What software/emulators are in development or will be ported for the Pyra?

Emulators:
1) Dreamcast(It's a given)
2) Drastic(Exophase has mentioned a possible port for pyra) (Source: https://www.pyra-handheld.com/boards/threads/drastic-nintendo-ds-emulator.73431/page-81#post-1370605)
3) Psp emu?
4) Saturn? (Pitseb is porting this?)
5) 3DO (Ekianjo)

GUI: Proper setting dialogs for everything Pyra-specific.(Elvissteinjr)


Browsers:

Easy- most should work. (Pyra specific optimizations?)

Games?


Software-General:

Edge00x (Currently working on Pebble Classic support for Pandora, and hope newer Bluez and Bluetooth module on the Pyra will allow for Pebble Time support as well.)

Tournament Hub. Online interactive Hub. (PMprog)


I'm curious and want to gauge what we might expect to see on the pyra, initially and sometime after release.
I can update this list if others who are working on stuff post about it here.
 
Last edited:
Proper setting dialogs for everything Pyra-specific.
Although I gotta admit that the current state is just some kind of proof of concept. My plan is to wait and see what the Pyra will even give me to work with, since a lot of things may still change and I don't want to pin the OS-devs down to finalize anything yet (ED mentioned that the whole Nub configuration concept may change, so there's that).

So that's to expected after release. I'll try to hurry though when the time has come.
 
Exo has mentioned a forthcoming Pyra release of DraStic, though I'm not sure he's committed any code for it yet.

I haven't done anything except for a super hacked version that badly uses fbdev (which is very limited on Pyra currently), which was enough for notaz to run benchmarks. I don't have any kind of Pyra-like dev environment.
 
What software/emulators are in development for the Pyra?

What do you mean, development ? for emulators most of them are open source and can be ported.
[doublepost=1459320210,1459320146][/doublepost]
5) 3DO (Ekianjo?)

The Pyra should be at least much more capable in that regard so I dont think full speed emulation of 3DO would be a problem anymore.
 
Why have you got browsers as a section with a question mark?

sudo apt-get update && sudo apt-get install [name of browser] should suffice, I can't imagine anyone would need to port a browser.
 
s this a thread about what is going to be released with the Pyra or what we wish to be released with the Pyra? The first question is very obvious: It will be available everything that the devs/preorder want to port.

For the second, well, I hope we got a good Saturn port ASAP. I want to see it performance on the Pyra with 2D games.
 
s this a thread about what is going to be released with the Pyra or what we wish to be released with the Pyra? The first question is very obvious: It will be available everything that the devs/preorder want to port.

For the second, well, I hope we got a good Saturn port ASAP. I want to see it performance on the Pyra with 2D games.
I guess I'm just gauging what the devs intend to port and what we might have available at launch.
 
There are merits in doing specific optimization flags compared to a generic compilation for all ARM devices, for example. Not sure it's REALLY worth it, but it could make things a little faster.

Debian hardfloat is already targetting ARMv7 with vfp and NEON, I don't think you'll gain much from just adding some compiler flags.
 
Debian hardfloat is already targetting ARMv7 with vfp and NEON, I don't think you'll gain much from just adding some compiler flags.
True for most things, but I did see some significant differences in for example DOSBOX, the one on the Debian repository had poorer performance than even the Pandora version, when compiled on platform with optimized flags it had significantly better performance and put the Pandora DOSBOX to shame. But I have a feeling that may have been some specific dynarec flags set at compile time that were not implemented in the generic port.

And this is likely just a rare example, I think most of everything on the repository should behave well.
 
Debian hardfloat is already targetting ARMv7 with vfp and NEON, I don't think you'll gain much from just adding some compiler flags.

Well it's also a matter of how it was compiled. COmpiling with GCC 5+ gives some additional speed-ups compared to GCC 4.8 (which may be used currently for ARM repositories).
 
so with the Pandora, a command line software update and then upgrade broke the system, right? (or still does?)

but with Pyra, an apt-get update && apt-get upgrade should be fine, right?

(just thinking of things to put on the wiki re: software.)
 
Afaik, the Debian armhf distribution doesn't use all possible optimisation flags and especially not mfpu=neon due to compatibility reasons
 
so with the Pandora, a command line software update and then upgrade broke the system, right? (or still does?)

but with Pyra, an apt-get update && apt-get upgrade should be fine, right?

(just thinking of things to put on the wiki re: software.)

I would prefer dist-upgrade instead as the dependancies are normally handled better. But generally, as the Pyra would use debian stable, I'd expect upgrading the Pyra should work just fine (in the most cases. As with every OS,update regressions are always a possibility)
 
so with the Pandora, a command line software update and then upgrade broke the system, right? (or still does?)
Doesn't, Notaz worked the issues out with that.
but with Pyra, an apt-get update && apt-get upgrade should be fine, right?
That is currently the method for updating.
 
Back
Top