Pyra dev?


error

Very Active Member
Joined
Oct 22, 2012
Messages
106
Age
39
Location
Dallas, TX, USA
Sorry in advance if this is all spelled out somewhere already.

I have some spare time over the holiday and I thought maybe I'd try writing a game or something for the Pyra.

I guess first I would need some sort of emulated ARM machine with the Pyra OS running on it.

Then I need a compiler toolchain that either uses bytecode or can cross-compile to ARM. I actually have the most experience in C#, and I know .NET Core runs on ARM32, so that's my first preference. Otherwise, I know C/C++ and Java. I'm assuming I'd be using OpenGL for graphics.

My dev machine is Windows 10 and preferred IDE is Visual Studio (for .NET) or Visual Studio Code (for everything else).

Can anyone help me to get started?
 
Until you actually have the device I would recommand to just develop locally so you can code with the IDE you want.
I'm sure C# will run at some point on the pyra since there's C# games on the pandora repo. But since I dont know the language I cant tell you more than that. Just make sure it run well using mono.

There's has been no toolchain released for windows for the pandora as far as I know so I wouldnt expect any to be released for the pyra either.
But ARM do provide one which you could use as long as you're open to tinker with it enough so it accept to link with the libraries within the pyra rootfs.

Else there's still the option of a linux VM (preferably debian as it provide the toolchain and the libraries you need)
EDIT: in which case I can even recommand using this. (shameless plug xD)
 
Else there's still the option of a linux VM (preferably debian as it provide the toolchain and the libraries you need)
EDIT: in which case I can even recommand using this. (shameless plug xD)

There's the Linux Subsystem for Windows 10. It might work with that. I'll give it a try.

But I was really hoping I could try running things on the Pyra OS. To test but also as an early taste of what using the device would be like.
 
@error get yourself a debian vm started. since pyra will run debian, that is as close as you will get to running the actual pyra OS. Don't bother with the win10 linux subsystem, it will not prepare you for using an actual linux.
 
@xnopasaranx I've used Debian-based distros before (and RHEL and SLES and some BSDs), and I've used the Pandora a bit. I prefer to develop on Windows. I've never compiled before anything for ARM though.

I was able to compile and run some C++ code for Ubuntu on Windows from the Linux Subsystem (x86, though).

Honestly I was hoping to make something specifically targeting the Pyra rather than some generic Linux game. I thought surely there must be a docker image or something available.
[doublepost=1515126214,1515125803][/doublepost]The main reason I write Android apps instead of iOS apps is that Apple has a silly requirement that iOS apps must be compiled on a Mac, and Android can be developed from any OS at all.

I'd expect at least that level of openness from a Free and Open-Source Software platform.
 
Linux on ARM works rather much like Linux on Windows, at least in terms of compiling stuff. Download/create source, build using make, publish using make install.

If you wanted to try exactly what will be running on the Pyra then you'd need more than a docker image, you need an emulator. That'll slow things down a bit, but by how much I'll leave to you to find out. Also, it won't give you access to 3D acceleration and OpenGLES so it won't run games and things like the real device will. But you can get the latest files here I think: http://packages.pyra-handheld.com/rootfs/stretch/

The other thing that differs between the Pyra and Linux on your x86 computer (or SBC) it the DBP system, designed to let you have software on removable media like SD cards. I don't know the best place to start for that at present, but it'll almost certainly be somewhere either in this thread or linked to from it: https://pyra-handheld.com/boards/threads/a-possible-pnd-system-replacement.74709/

Edit: And in terms of cross compiling from another OS onto the Pyra, you probably want something like this: https://dev.pyra-handheld.com/sebt3/pyra-debian-cross

If that does run on window's posix layer that would be very interesting to know.
 
Last edited:
There are no security devices in place to limit where you develop from. You can develop for the pandora from anything you like, you just have to setup the compiler properly. If you want to build from a windows desktop x86 machine you need to set up the environment to allow you to cross compile to arm. You should be able to setup codeblocks to do this. The downside is that without a pyra you do not have a way to test your software. There is no pyra emulator and won't be until someone makes one.
 
Windows' Linux subsystem is apparently just a version of Ubuntu, so I'd expect most things to work. Even X11 apps work if you use Xming.
 
Windows' Linux subsystem is apparently just a version of Ubuntu

You can actually choose from a few available distros.
[doublepost=1515163693,1515163180][/doublepost]
Edit: And in terms of cross compiling from another OS onto the Pyra, you probably want something like this: https://dev.pyra-handheld.com/sebt3/pyra-debian-cross

If that does run on window's posix layer that would be very interesting to know.

It's installing dependencies; it looks like it will work. Thank you.

So I can hypothetically create an image that will run natively on Pyra, but I can't actually run it until I get mine.

Would emulating an ARM device such as a Raspberry Pi be similar enough?
 
IIRC the there's an ISEE IGEP v5 board that uses the same SoC at the Pyra so if you can emulate that you'd be able to test software.

In terms of Raspberry Pis, in terms of raw number crunching it's somewhere between the Pi 2 and Pi 3 I think, but I don't know how their GPUs compare. If you can run your stuff on a Pi 2 then I'd expect it'd run on a Pyra no problems though.
 
I can't extract the rootfs because Windows doesn't allow ':' in filenames.

I guess I can do this part with Docker at least.
 
I doubt it. Windows doesn't really do character escaping, especially in filenames. And it doesn't like colons because colon means the bit before it is the drive letter to use, even if that's more than one character and contains lots of forward slashes and stuff.

I don't know off the top of my head how Qemu contains the target filesystem to get around whatever special characters the target OS wants to use, but I'd look at that if this was my problem.
 
I can't extract the rootfs because Windows doesn't allow ':' in filenames.
The files containing ':' are man pages for perl modules (which you can easyly live without) and dpkg infos files.
Not having the later mean you wont be able update your rootfs nor be able to install other things in it (at least using dpkg).
Yet you would have all the libraries to link to availables. So you could still use it with the corresponding cross-compiler.

EDIT: did you try to extracts the files from the linux subsystem ? maybe tar will do something to cope with it. Because, if the linux subsystem is ubuntu, then it's using dpkg as package management system... and thus it should already have the files with these ':'
 
Last edited:
EDIT: did you try to extracts the files from the linux subsystem ? maybe tar will do something to cope with it. Because, if the linux subsystem is ubuntu, then it's using dpkg as package management system... and thus it should already have the files with these ':'

I was working in the Linux subsystem, and tar printed a ton of cryptic "invalid argument" messages, that I Googled were related to an invalid filename. I looked at the files it was printing errors for, and they all had : in their filenames. Finally, I tried several methods of creating such a file and all failed.

I'm not sure at what level this restriction is in place (NTFS, WinNT, or Win32). It seems like there is a hierarchy where some things are allowed by NTFS but not by WinNT, and similarly for WinNT but not Win32.
 
Mmm, I tried a simple test, and it work on my side, look
Code:
root@Seb-PC:~# nano \:
root@Seb-PC:~# ll
total 67
-rw-rw-rw- 1 root root     6 janv.  7 21:04 :
drwx------ 0 root root   512 janv.  7 21:04 ./
drwxr-xr-x 0 root root   512 janv.  1  1970 ../
-rw-rw-rw- 1 root root    35 août  13  2016 .bash_aliases
-rw------- 1 root root  5576 janv.  7 11:47 .bash_history
-rw-r--r-- 1 root root  3124 août  26  2016 .bashrc
drwx------ 0 root root   512 août  13  2016 .cache/
drwx------ 0 root root   512 août  13  2016 .config/
-rwxrwxrwx 1 root root 24316 août  13  2016 crosscompilemaker.sh*
drwxrwxrwx 0 root root   512 août  13  2016 cvs/
-rw------- 1 root root    57 août  13  2016 .cvspass
-rw-rw-rw- 1 root root  3261 août  14  2016 .gdbtkinit
drwxrwxrwx 0 root root   512 août  13  2016 .local/
-rw------- 1 root root    21 janv.  7 21:04 .nano_history
-rwxrwxrwx 1 root root  1136 août  13  2016 pandomount.sh*
-rw-r--r-- 1 root root   140 févr. 20  2014 .profile
-rwxrwxrwx 1 root root   502 août  13  2016 seb_gcc51_arm.sh*
-rwxrwxrwx 1 root root   518 août  13  2016 seb_gcc53_arm.sh*
-rwxrwxrwx 1 root root   518 août  13  2016 seb_gcc5_arm.sh*
-rwxrwxrwx 1 root root   494 août  13  2016 seb_gcc61_arm.sh*
-rwxrwxrwx 1 root root   519 août  13  2016 seb_pnd.sh*
-rwxrwxrwx 1 root root  9189 janv.  7 11:01 spectre*
-rw-rw-rw- 1 root root  4392 janv.  7 11:01 spectre.c
drwx------ 0 root root   512 août  13  2016 .ssh/
-rw------- 1 root root     0 août  13  2016 .Xauthority
root@Seb-PC:~#

This is from the home folder, in here the file system should be 100% linux compatible.
Doing the same from "/mnt/c" will not work...
 
True fact: Microsoft Works was changed to Microsoft Office because of truth in advertising laws. >_>

Edit: Darnit, little seb, you messed up my comedic timing.
 
Back
Top