What is the dev situation for Pyra?

[darkcpc]

Hi,

I have got a new job and guess what I want to buy? A Pyra of course! and it's great that is getting closer to release

I have been mainly lurking since the GP2X days. It's been a great community and so much has happened. I did preorder a Pandora but cancelled as I decided to keep my GP2X and Wiz.

But I am a bit worried about the emus and homebrew for the Pyra. I have seen great devs like Notaz, Exo, Skeezix, Senorquack, Slaanesh and others make big contributions to the scene but for the Pandora, these devs have slowly faded away or left the scene and we only have ptitseb doing a wonderful job in porting and improving emus.

My main use of Pyra will be computer and mame emulation with great controls and don't want to spend a lot of money on a device with a lack of great emus and development. What is the future? Do we have confirmed devs working on projects?

I personally would like Slaanesh to get a unit so we can have a special dedicated mame for Pyra like what he did for the gcw zero

 

[levi]

aTc has ported picodrive to his prototype, and it runs well (albeit not fullscreen or scaled yet, so it's in a tiny window until those working on those issues fix them). But yeah, that's another developer who's ported emus already. And, if I recall, Wally submitted some dbps to the store, but he didn't specialise in emulators yet as far as I can remember.

 

[ptitSeb]

Most emulators, like most games, need some Hardware acceleration to be fun. Once the SGX driver get stabilized and cooperating fully with TILER, developpement will start. There are a lot of "standard" emulator that can be easily ported to Pyra without much to do.

 

[undexsym]

If you like snake I've got you covered.

 

[Swordfish II]

Also keep in mind it will run debian. So the repo there can fill in too

 

[ToastBucket]

Also keep in mind it will run debian. So the repo there can fill in too

For this reason, what is the point of the DBP system? Why not just package everything as Debian packages. We have a dedicated Debian package repository for the Pyra.

 

[NutNut]

For this reason, what is the point of the DBP system? Why not just package everything as Debian packages. We have a dedicated Debian package repository for the Pyra.

I'm guessing it does Special Things.

 

[EvilDragon]

For this reason, what is the point of the DBP system? Why not just package everything as Debian packages. We have a dedicated Debian package repository for the Pyra.

Debian packages are being installed into a system and handled with a database.
The internal storage is 32GB. More than enough for an OS and everything around it, but not for games.

So games should be installed onto an external storage (SD Card).

However, Debian doesn't expect that this storage can be removed (for example, if the SD Card breaks or the user simply removes it). This could quickly lead to a broken Debian system - and you'd need to reinstall it completely.

The DBP system is similar to the PND system.
Each game comes in a single DBP. You delete the DBP, the game is gone.
You copy the DBP onto the SD Card and put the SD Card into the Pyra: The game can be played. Without any installing, etc. It just works.

So you can also easily manage and install your games and emulators on any PC, you don't need to do it directly on the Pyra.

Additionally, it's a lot easier creating DBPs than Debian files

 

[Swordfish II]

For this reason, what is the point of the DBP system? Why not just package everything as Debian packages. We have a dedicated Debian package repository for the Pyra.

I believe the reason is this:

Debian installs will install to default pathways throughout the system and are not self contained. DBP are self contained and can install to whatever you put them on AND function with overlayfs

Edit: ED beat me to it With a much longer explanation.

 

[ToastBucket]

Makes sense, thanks guys

 

[matzesu]

So whe need this SGX Driver for games, and it will take some time to make this work,
Whitout this SGX Driver, would at least "Low Level" Emulators work?? A bit Tetris coudnt be that hard..

Like on the Pandora: The Early Week, bevor everything works perfektly where the most fun.. ^^

 

[Grench]

Debian packages are being installed into a system and handled with a database.
The internal storage is 32GB. More than enough for an OS and everything around it, but not for games.

So games should be installed onto an external storage (SD Card).

However, Debian doesn't expect that this storage can be removed (for example, if the SD Card breaks or the user simply removes it). This could quickly lead to a broken Debian system - and you'd need to reinstall it completely.

I see a potential solution in the internal uSD slot. The uSD card doesn't get removed at random after all. A small interface in the Pyra setup menu to 'initialize microSD' could establish the handles - and allow the uSD to be re-initialized if it is removed/reinserted. Normal shutdown should disconnect the handles or at least close out the filesystem. Normal startup should re-initialize the handles if a condition on the uSD card is present. If it is absent or a different/new/uninitialized card is present on startup, the user should be prompted to initialize it.

Initialization would create a folder in the uSD file system to be used as the extension/addition to the primary file system - so the OS knows where to find it.

Nobody should be shocked at needing to source a memory card to get the most out of the device.

That is how I plan to use my Pyra anyway. The internal eMMC for the OS, the uSD slot for additional programs, the faster SD slot for media (music & movies) and the other SD slot for ease of getting data on/off the Pyra.

I don't see any conflict with making the internal uSD effectively 'non-removable' during normal operation in either the above scenario or if the user decides to use it as the boot device. Maybe I'm missing something?

 

[levi]

I see a potential solution in the internal uSD slot. The uSD card doesn't get removed at random after all. A small interface in the Pyra setup menu to 'initialize microSD' could establish the handles - and allow the uSD to be re-initialized if it is removed/reinserted. Normal shutdown should disconnect the handles or at least close out the filesystem. Normal startup should re-initialize the handles if a condition on the uSD card is present. If it is absent or a different/new/uninitialized card is present on startup, the user should be prompted to initialize it.

You can do stuff like that on any linux system. After all the uSD slot can't be removed without taking the battery out, so the unit will necessarily be power off at that point. On my current system I only have 4GB remaining of my internal storage for use, and a 128GB SD card inserted then taped over. The latter contains my /home folder, my /var and my /usr, while the 4GB internal eMMC contains /boot and everything else (actually just 61MB of stuff, about half of which is a older lib I had to unpack to work around a libreoffice build failure.

For me, my /home folder is the biggie, containing all my development stuff as well as my media. The biggest chunk is a few video files I have on this machine, amounting to 22GB, and 21GB for audio, while my source code repos only amount to 15GB, 8.5GB of photos and everything else adds up to 92GB used, so just under 32GB of config files and general cruft. If most of your media is going to be on a different SD card and have less general cruft, that could probably conveniently fit on the 32GB of Pyra eMMC.

I did have to modify my boot config and build it into my initcpio to ensure my /usr gets mounted earlier in the boot process, because with it being on a SD slot that's connected over USB internally, it's usually mounted relatively late during boot.

Edit: Of course, splitting things between the 32GB of eMMC and the uSD slot depends on both being accessible at least after the system has booted fully, which isn't planned to be supported when the system is released unless it turns out to be super-easy to do. I did collect 21GB worth of applications and games on my Pandora though, but the PND system meant these could be conveniently stored on removable media.