Introduction to PNDs

For developers: Libpnd hub

A .pnd ("pandora") file is an application (game, word processor, emulator, whatever.) More accurately, it is a full application bundled up into a single file; think of it like a zip, with a relatively well defined internal structure.

The pnd-file system was designed so you could use an application without the hassle of installation or uninstallation, or even having to organize it yourself if you don't want to. You just download or obtain the pnd-file, and use it.

If you remember classic computers such as the Amiga - where you inserted a disk and then launched the applications read by Workbench (the Amiga's operating system) - then this is similar:
When you insert an SD card into one of the two slots, the (Linux-based) Pandora OS will scan it for your PND program files. Any program it finds will either turn up on the desktop or the application menu (just like in Windows).

How do I run a PND-application?

Put your pnd-files on your SD card and insert the SD card into either slot of your Pandora.

Using the file browser, you can double-click on the pnd-file to run it. However, more normally pnd files are put in special folders so they get picked up by the Pandora's OS and are made easier to find and run.

Where do .PNDs Go?

This is what the folder structure on your SD card should look like. The drive letter and card name will vary; they're not important.

Put .pnd-files into specific directories if you want them to show up in the Start menu or on your Pandora desktop, or in Minimenu.

You can put them anywhere you like in internal NAND or SD, if you wish to organize them yourself and launch them with taps.

Folder	Note
/pandora/desktop	pnd files show up on the desktop background
/pandora/menu	show up in the Applications menu or in minimenu(under the categories suggested by the developer)
/pandora/apps	show up in all places; the desktop, the apps menu and in Minimenu
/pandora/mmenu	show up only in minimenu, ignored by other GUIs

These locations are not written in stone. The libpnd config files are in /etc/pandora/conf in the NAND. Generally you will never need to alter these files, but you certainly can if you wish. In theory, obliterating the files will still leave the system working, and they are easily restored. One file, /etc/pandora/conf/desktop defines the "search paths" to look for .pnd files, and where to put ".desktop" files when they are found. The searchpaths says where to find them (such as /pandora/desktop), and where to put the application link - /usr/share/applications is where the menu items are pulled from. IF you wish to put pnd files somewhere not in the searchpath, just add the directory to the search-path and you're good to go.

NOTE: You can actually put subdirectories into those locations above, should you wish to organize your pnd-files somehow within those larger categories.

Where DON'T .PND files go?

• .pnd files are looked for in the directories mentioned above; that list can be tailored if you wish to edit config files.
• .pnd files are not looked for in the / (root) of the SD cards.. this is _on purpose_; consider, if your SD card is 32GB, or if you're using a 2TB USB drive even -- it could have tens of thousands of files on it; having the Pandora scan the entire device for pnd files would take forever. Instead, we made a well defined set of directories the system will use - /pandora for everything, with 'appdata' and 'menu' and 'desktop' and other special purpose directories.

Where does my data go? How do I make files visible to the applications?

An application normally will see what is contained within the pnd-file, or your personal data created with the tool; it can of course look anywhere on the SD or device internal memory. For example a Quake port might expect to see extra level files in /quake, or give you a way of selecting a path to put files in.. or it might just expect it to be in your personal data folders, or in the pnd-file itself. Its up to the application, with suggestions in the pnd-guidelines for developers.

The first time a pnd-application is run, an "app data" directory is created for it; anything that app data folder contains will be visible to the application as if it was in the pnd-file (and in fact, this lets you override files in the pnd-file without modifying the .pnd itself, which could be handy.) If your app creates a file "foo", it'll show up in /pandora/appdata/appname-id as "foo". The actual appdata folder name depends on the name used by the developer, but should generally look like application-name and some funny number afterwards. It should be easy to spot.

example: Quake 1 will probably put score or save data in /pandora/appdata/quake1-123/ or somesuch.

It will always be helpful to read the description or readme file included.

Example: Hatari

Hatari (Atari ST emulator) by default is set to look in "./disks" for the disk images (ROMs) to use. What this means is within the pnd-file (where no disks are supplied), and in the appdata directory. With Hatari, you can browse anywhere from the UI and pick a disk anywhere on your SD cards, but by default it'll look into the ./disks directory.

So you might put Hatari into the menu (/pandora/menu/Hatari131.pnd), or into the desktop (/pandora/desktop/Hatari131.pnd), or somewhere else. Regardless, the appdata will be (with the version I'm building now), /pandora/appdata/hatari.skeezix and thus you would put your .ST or .MSA disk images into /pandora/appdata/hatari.skeezix/disks to make them visible to the emulator. However, given it features its own UI, you can put them into /roms/atarist or /disks or whatever, and use them from there.

Using a start-up script

In an ideal world, your application will be completely self-contained and can be run directly without any kind of set-up. It is however often necessary to tweak settings or request input from the user before starting your application. This is easily achieved by having the PND specify a shell script as its executable, which then in turn runs the application. The general structure of such a script is:

#!/bin/sh

# Do stuff here...

./my_app

# Clean-up

The first line identifies the file as a shell script, run using "/bin/sh" as the shell. The other lines beginning with a "#" are comments. Before the application is started, parameters can be gathered and/or set. The application itself then gets run by the "./my_app" line, which means "execute the file my_app in the current directory". When the application exits, it may be necessary to restore previous settings, delete temporary files, or perform some other kinds of cleaning up.

Avoiding NAND writes by setting $HOME

Many applications write configuration data to the user's home directory by default. This is not desirable on the Pandora as this directory resides on the NAND filesystem. It is however often possible to fool an application into writing to a different directory by setting the $HOME environment variable.

export HOME=`pwd`
export HOME=$(pwd)

Providing a default configuration

If your application uses a configuration file, you'll usually want to include this in the PND. However, if you simply leave this file in the root of the PND, it will effectively be read-only, preventing the application or user from writing to it. A simple solution is to provide a default configuration file with a different name, and copy this the first time the application is run. The file will then be created under appdata, and can therefore easily be edited.

# Method 1: check if file exists, otherwise copy default.
if [ ! -f app.conf ] ; then
    cp default.conf app.conf
fi

# Method 2: Same as above, less typing.
[ -f app.conf ] || cp default.conf app.conf

# Method 3: using a non-destructive copy.
cp --no-clobber default.conf app.conf

Nub Configuration

This is a little (but not much!) lengthier - see the page on PND nub modes.

Making writable directories

If your application requires that directories be writable for the application, don't put them in the PND, but create them at run-time:

# Bad! This will cause an error after the first run, as the directory will already exist.
mkdir saved_data

# Better to use "-p" which won't complain about existing directories.
mkdir -p saved_data

# Added bonus: this allows you to create whole trees in one go.
mkdir -p saved_data/foo saved_data/bar/with/deep/sub/dirs

Loading shared libraries

If your application requires shared libraries which aren't part of the standard firmware, they can be included in the PND along with the executable. In order for the system to be able to find the libraries, it must be told which directories to search. This can be done by setting the LD_LIBRARY_PATH environment variable. For example:

export LD_LIBRARY_PATH=`pwd`       # Load libraries in the root directory of the PND.
export LD_LIBRARY_PATH=`pwd`/libs  # Load libraries in the "libs" subdirectory of the PND.

Getting a file/directory from the user

Its often necessary to ask the user for the location of a file or directory. This may be because your application requires files which aren't included in the PND itself, or simply because you application doesn't have a built in file picker. The commands below will prompt the user for a file, then run "my_app" with that file as an argument. Note the use of different sorts of quotes which is important for proper operation and handling spaces in file names.

FILE="`zenity --file-selection --title='Select a File'`"
./my_app "$FILE"

Saving a file/directory name

If your application always asks for a file at start-up, it's handy to remember the location for next time. This can be done by writing the name of the directory to a file in appdata, and reading it back next time the application is run.

SAVEDIR=./dir.saved    # Name of the file we'll save the directory name to

# Did we save a directory last time? If so, read it into a variable.
DIR=`cat $SAVEDIR 2> /dev/null`

# Remember where we are right now, as we'll need to come back later.
PNDDIR=`pwd`

# Does the directory still exist?
if [ -d "$DIR" ] ; then
    # Yes, go to that directory before Zenity is started.
    cd "$DIR"
else
    # No, try to go to /media (where the SD cards are mounted)
    # or if that fails, go to "/" as a last resort.
    cd /media 2> /dev/null || cd /
fi

# Get a file name form the user. Our current directory is now that which
# was saved, so that's where Zenity will start.
FILE=`zenity --file-selection --title="Select a file"`

# If the file selector failed, or the user hit cancel, exit now.
[ $? -eq 0 ] || exit 1;

# Go back to the PND's mount point.
cd $PNDDIR

# Save the file's directory for next time.
dirname "$FILE" > $SAVEDIR

# Run our app with the file as an argument.
./my_app "$FILE"

Checking a file's contents

Maybe your application requires some file which cannot be distributed with the PND, either for legal reasons or due to size limitations. A prime example of this is BIOS files used for emulators. Simply copying the file to the current directory will be enough to save it to your program's appdata, but it can also be useful to check the contents of the file are indeed what your application expects.

One way of doing this is to check the file's contents using a hash. A hash is a mathematical formula which can be used to create a "fingerprint" of a file. Two identical files will always generate the same hash value, so knowing this one value is enough to check if two files match. The MD5 hash is a popular choice, and can be easily generated for a given file like so:

$ md5sum bios.img
cfcfd01f1b0dfa97f07cb286b2942dc2  bios.img

Save this output to a text file named bios.md5 and put it in your PND root directory. The following commands can then be used in your start-up script to copy a file specified by the user, and check it's hash.

BIOS=bios.img       # The name of our BIOS file

# Check if the BIOS file already exists.
if [ ! -f ./$BIOS ] ; then
    # Not found, so get a file name from the user.
    cp "`zenity --file-selection --title="Select your $BIOS file"`" $BIOS
    if [ $? != 0 ] ; then
        # User hit cancel, bail out.
        zenity --error --text="Sorry, emulator cannot run without a BIOS file."
        exit 1
    fi

    # Check the MD5 hash of the given file against our known-good value.
    # If the match fails, ask the user if they'd like to try it anyway.
    md5sum -c bios.md5 || zenity --question \
        --text="BIOS does not appear to be the correct version. Use it anyway?"

    if [ $? != 0 ] ; then
        # File did not match hash, and the user opted not to try it anyway,
        # so remove the copied file and bail out.
        rm -f $BIOS
        exit 1
    fi
fi

# Run our emulator with the BIOS file as an argument.
./my_emu "$BIOS"

Advanced topics

I want to override the .PND icon, name, or other settings, how is this done?

The easiest way right now is via the "override" (or "overlay") system -- .ovr files.

An .ovr is just a text file you create, with the same name as the pnd-file and in the same location, but with a different file extension. Piece of cake.

If your pnd-file is Hatari.pnd, and you're putting it into /pandora/desktop, then you might create an ovr file for it as: /pandora/desktop/Hatari.ovr If you wish to provide your own icon, create it with the same location and filename, but as a .png file: /pandora/desktop/Hatari.png

.ovr files are automatically supported by the system so should work across all pnd-application aware applications and desktops. .png icon overrides have to be handled by the menus, but are already handled by minimenu and anything using the .desktop system (such as XFCE full desktop or other standard desktop environments.)

An ovr-file simply looks like this:

• The ovr file may (at this time) override the icon title, the CPU clock speed to set on launch, the main category, and the first subcategory for the main category. Additional fields will become overridable.
• The category list uses the existing desktop standard. See here for a list of categories and subcategories supported.
• Minimenu honors up to 3 lines of 'notes', pulled from the .ovr file. (Make sure they are in the right subapp group). note-1, note-2, note-3, see example below. The notes in minimenu are shown at the bottom of the detail text panel.

[Application-0]
title                   HatariHack0
maincategory            Audio
maincategorysub1        Emulator
[Application-1]
title                   HatariHack1
clockspeed              200
note-1                  My text for note line 1

Notice the Application-0 and Application-1 -- any given .pnd file may include multiple applications, so you need to assign your overrides to the correct "sub application". It can be tricky to figure out which subapp you wish to override, but there are some tricks. minimenu, for example, shows the subapp-number in the detail panel. When looking at a .desktop filename, you'll notice #0.desktop .. some number after the # is the subapp-number.

How Do I Make .PNDs?

The following is a work in progress, the instructions in here may or may not work for you. It was taken from PND quickstart.

The steps to produce a pnd file are as follows:

• create a directory to represent the application on SD card; i.e.: ./mame-app

• create a PXML.xml file and drop it into the dir (./mame-app/PXML.xml); genpxml script can be used, or do it by hand

• drop the executable and data files into this dir (say, ./mame-app/mame.bin, and ./mame-app/artwork/foo, etc.) <- note, with a PXML.xml and executable, your Pandora can now find and run your app without even bundling it into a .pnd!

• invoke /usr/pandora/scripts/pnd_make.sh (or on Windows, various commands in the command-line) to produce mame4all-pandora-1.0-arm.pnd or whatever you want to call it (foobearspanky.pnd, we don't care.)

• you're done, distribute it as you see fit

(alternate instructions)

For these instructions, you will first need to grab the example file, here.

• Edit ./pnds.sh. I use that script to handle multiple apps at once. Each line represents a command line for an app / game to turn the directory into a PND. If I change the app / game, I simply uncomment the line in pnds.sh so that I can easily create or update multiple PNDs by simply running one single script.
• Run ./pnds.sh
• Upload

Don't forget to check the license conditions for anything you re-distribute.

PXML.xml file?

The PXML.xml file is the pnd file's metadata file and specifies things like:

• A description of the software
• A link to the icon filename
• What version it is
• The author, and their website
• Whether it's a beta or release version
• The menu categories the pnd file should appear in
• The license the code is distributed under
• Preview pictures, for display in minimenu or on the [repo]

You can use genpxml.sh to generate a template PXML.xml file for you (in /usr/pandora/scripts/), but perhaps simplest way to make your first PXML.xml file is to look at an example one from a real pnd file, from the repo (where PXML.xml file are guaranteed to be valid). The PXML.xml file will be inside the pnd file's root folder, and you can look at it using a text editor.

How Do I Look Inside a .PND?

To open a PND, the easiest way is probably to use the PNDTools or PNDManager programs, which can browse and create PNDs. They're Windows-only, currently.

You could also install 7zip on your home PC, change the .pnd's file extension to .sfs, and 7zip should be able to open it. (This is a simple way to look into a .pnd on Ubuntu: unsquashfs FILE.pnd needs squashfs-tools installed) [1] On the Pandora, you can run a PND and look at what's inside /mnt/tmp. To do this in a terminal (on PC or Pandora), see this tutorial.

The PND Cookbook contains recipes for common PND tasks, like setting up your application's environment and configuration, locating and copying files, etc.

All these commands are hard. Give me a GUI tool to do it

Okay:

• PNDbuilder by freedomdown. Discussion. Download v1.1 for Pandora.

How do I make .PNDs on Windows?

Command-line

For this command-line tutorial, I will assume you have already created a PXML.xml file.

Preparations

Get yourself mkisofs tools; for example, grab from here: http://www.student.tugraz.at/thomas.plank/ -- get cdrtools-2.01-win32-bin.zip and DLL version 1.5.25, and extract to somewhere. That lets you run 'mkisofs' to spit out .iso files

If you want to make a compressed image, use squashfs tools here: ftp://ftp.slax.org/useful-binaries/win32/squashfs-tools/

Generate the actual PND-file

Make yourself the iso; this step produces the iso, but to turn the iso into a pnd you need a couple last steps. You could also use some fancy iso-building tool.

mkisofs -o foo.iso -R /path/to/folder/myapp

Append PXML.xml to the .iso (yes, the PXML.xml is included in the iso, but we also want to append it for performance reasons.)

copy foo.iso+PXML.xml foo.step2

Append the icon PNG file to the .iso (if you have an icon; if not, you can leave this step out.)

copy foo.step2+myicon.png foo.pnd

Clean up:

del foo.step2 foo.iso

Profit!

GUI

You have a few choices here:

• PNDTools by foxblock. Discussion: OP, GP32X. Can browse and create PNDs. Two (simple and advanced) editors for PXML creation.
• PNDBuilder by StreaK. Discussion (old). Can create PNDs and edit PXML files.
• PNDManager by Speaker Ender. Discussion.
• PNDbuilder by freedomdown. Discussion.

Mac OSX

TBD

This is a list of frequently asked questions about using the Pandora PND package format. For factual and other kinds of questions, use the search box. If your question is not answered on this page, do some research and include it!

The PND system

What is a PND file?

A PND file is a compact file that contains one or more runnable applications for the Pandora. The file is basically an archive (like a ZIP, RAR or ISO) that contains all the data that the provided set of applications require, along with some meta data about the applications themselves.

Why are PNDs useful?

Normally, on an ordinary computer, it is necessary to install an application in order to run it. This usually happens in one of many different ways; an installer might be run, or an archive might become extracted, etc.

PND files are used to allow for applications to be executed without them being installed first. They are supposed to work in a way similar to game cartridges, in that they contain all of the necessary information in one tight package that can be executed independently.

This system is inspired by similar systems such as the Apple OS 10 DMG file system, the Puppy Linux package format, or the Haiku Box package management system.

Can I modify a PND file?

You can, but you need easily obtained open source freeware special tools to do so. (These tools are included by most Linux distributions by default, but are downloads for Windows and Mac OSX users.) It is advised that only developers modify or create PND files.

Can a PND file modify itself?

No, not generally. A pnd-file, even after extended use may be copied anywhere and still be in its original state. Any changes the application has made will have been redirected to its appdata directory instead, so you have your self-contained directory of its changes.

How does a PND store application data?

Since the PND cannot modify itself, there has to be a way for it to store runtime data, such as configuration files and user-added level files. This is achieved in the PND system by creating an application data directory for each application that is inside a PND. Since a PND can contain many applications, there can, and will, be multiple application data folders per PND, and each application declares its own application data folder name.

The application data folders are located in "pandora/appdata/*" on the device that the PND is stored on.

What desktop environments do pnd files work with?

As described below, the pnd-files will cause the system to spit out standard ".desktop" files for each application contained. The Pandora firmware includes several desktop environments (ie: menus) that understand those files (or operate with pnd-files directly.) The ".desktop" files are a standard however, so you are free to install other desktop environments and they should work fine out of the box with pnd-files, without any alteration whatsoever,

Can a PND-file be unpacked and used?

A pnd-file may be unpacked into what is called a "PXML-application directory" if the packager of the pnd-file followed the specification. (ie: the icon and PXML.xml metadata are included in the contained filesystem and not just found at the end of the pnd-file.) An application directory may be auto-discovered and executed just like a pnd-file, but you can muck with the files in-place without a problem. When the application writes back to itself however, the changes will still be directed to the appdata directory as with a regular pnd-file.

This is an advanced topic, noted here for completeness.

Can the PND-file system be added to other Linux distributions?

It is very easy to add the PND system to other Linux distributions, be they Pandora oriented or not. As of 2010 the Pandora APIs are are a little Pandora-specific, but effort will be made to split off the PND-file support and Pandora-specific support into separate systems, so that non-Pandora Linux distributions can even more easily adopt the PND-file system should they wish to. Certainly however, if you're building a new distribution to run on the Pandora, it is absolutely trivial to include PND-file support (and other Pandora originated technologies), so please do, to help for a consistent user experience.

Usage

How do I use PND files?

Using PND files on your Pandora is easy: You simply get hold of a PND file, presumably via a web page of some kind, and store it in a special folder on one of your SD cards. See the folder listing below. By default, both SD slots (and other mountable media) on the Pandora will be monitored for PND-files, though everything is configurable for advanced users.

Once you've put your PND in a known location, the PND system will pick up the new PND, "activate" it, and create shortcut icons to the applications inside of the PND. You can then use these icons to launch the applications.

How do I launch a PND application without putting it in a special location?

If you open a PND file in your file manager, the first application in the PND will be launched without you having to move the PND file.

This guide describes how to mount a PND file, so you can browse the files within (to find documentation, or otherwise eat its brain and gain its knowledge.)

For now, the information is being compiled in [this thread] where I am fine tuning it with some expert help. When all the facts are straight, I will replicate the information here. -Gruso

How do I choose where the shortcut icons for a PND appear?

With the default configuration, there are four different folders you can put your PND files in to have their applications show up in different locations:

• "/media/*/pandora/menu" - These PND-files will only generate shortcut icons in the system's application menu. ("*.desktop" files will be written to "/usr/share/applications")
• "/media/*/pandora/desktop" - These PND files will only generate shortcut icons on the Desktop. ("*.desktop" files will be written to "~/Desktop")
• "/media/*/pandora/apps" - Deprecated to some extent, this directory is used to be _both_ menu and desktop, without having to copy the pnd-file into /menu and /desktop (avoiding duplication)
• "/usr/pandora/apps" This also extracts shortcut icons to the desktop. This path should not be touched, and is included to make an easy avenue for the Pandora firmware developers to include essential tools for the user, when bundled as pnd-files. (As of this writing early 2010, such tools are built into the firmware without being pnd-files, but the option exists still.)

Advanced Information

How is a PND file structured?

The PND file is simply an archive or file system image (currently, ISO and SquashFS are supported) with a "PXML.xml" appended at the end. There can also be an accompanying icon that is appended as well.

How does the PND discovery mechanism work?

There is an open source API for working with pnd-files and PXML-application directories (among other tasks); this API can be used by developers wishing to take advantage of the pnd auto-discovery system, such as when developing a new menu system say.

There is a special process called "pndnotifyd" that uses this API to watch the PND search paths for file changes. Once it finds a new PND file, it uses the PXML.xml file to generate one or more "*.desktop" files for the PND. (A .desktop file is a open standard way of describing an application and how to execute it, and is supported across most popular desktop environments.)

How do I change the search paths for PND files?

Simply edit the "/etc/pandora/conf/apps" file, and change the "searchpath" entry to include the paths you want to use. Paths are separated by colons (":") and may include wildcards (in the shape of "*") anywhere in the path.

How do I configure different locations for my PND shortcuts?

Edit the file "/etc/pandora/conf/desktop" (The "desktop" refers to "*.desktop files"). It will look like this:

# Open Pandora
# Desktop configuration

[desktop]
searchpath	/media/*/pandora/desktop:/media/*/pandora/apps:/usr/pandora/apps
dotdesktoppath	~/Desktop/
iconpath	/tmp

[menu]
searchpath	/media/*/pandora/menu
dotdesktoppath	/usr/share/applications
iconpath	/tmp

You should leave the "iconpath" variables be, but you can change which paths are searched through and where "*.desktop" files are extracted with the "searchpath" and "dotdesktoppath" variables, respectively.

How can I open a PND file to see what's inside?

The simplest way is probably to use PNDTools or PNDManager, which currently only work in Windows. You can also use them to edit PNDs and create them.

How do I set up a script to run before/after a specific PND runs?

^{(Using pnd_run.sh or as of Zaxxon HF6 Alpha 1)}
The pandora will look in the program's appdata folder for a bash script named PND_pre_script.sh to run before the PND is run, and PND_post_script.sh to run on the PND's closing.
^{All information pulled from [2] and may be subject to change due to updates.}