It would be useful to have a "compatibility" directory in both the Pandora and Pyra firmware that can be used to make software that works well on both devices. Let's say the directory is called /usr/share/pandyra (the name of the directory is not important, make it /opt/dragonbox if that sounds better).
It could be used as an abstraction layer to abstract away the differences between the devices.
E.g. say the Pyra has action buttons labeled Δ Π Ω X and the Pandora has action buttons labeled Y A B X. From the point of view of a developer, they're just PgUp Home End PgDn, so the labeling does not really matter. But he may want to show the button mapping in a help screen or something. In /usr/share/pandyra there could be guihint images, e.g. /usr/share/pandyra/guihints/action_north.png could be an image of the Y button on a Pandora, and an image of the Δ button on the Pyra. That way, if you load the guihint images from that standard location, they "magically" become the right image. (Independently of what button labeling the Pyra will have, I think it's a good idea to have shared guihint image files in a standard location, even if they're the same for Pandora and Pyra).
We could use a similar idea to allow applications to use 4 shoulder buttons and 6 action buttons on the Pyra, while mapping the missing buttons to O P 1 backspace or something like that on the Pandora (and you could change the mapping easily and globally by tweaking some files).
Setting the CPU speed could be done by calling /usr/share/pandyra/set_cpu_speed.sh with as a parameter the number of classic Pandora MHz of performance the application needs. The script would check if the current cpu clockspeed is fast enough, automatically sets it higher if it's in range of what you allow to automatically change, or gives a warning and allows you to try anyway if the application wants to go higher. E.g. if you do set_cpu_speed 800 it may overclock a CC Pandora unit and do nothing on other devices, if you do set_cpu_speed 1000 it gives a warning on a CC/ReBirth unit but lets you try anyway at the max you can do (e.g. 900MHz), if you do set_cpu_speed 1400 it will overclock a 1GHz unit to the max you let it go to but may still do nothing on the Pyra. The formulation of the warning could depend on how much difference there is between the max you allow and the requested speed; e.g. if you try running a very demanding Pyra application that asks for 3000 "MHz" of performance (remember, these are Pandora-equivalent bogoMHz of performance, so 3000 "MHz" may correspond to only 1000MHz actual clock speed on the Pyra's A15) on a CC Pandora, the warning may say "This will not work. Do you really want to see this slideshow?". Anyway, you get the point, and by using a shared script, we can make it relatively intelligent.
And so on. There may be more things to put in /usr/share/pandyra. The point is: we should avoid having individual applications that try to do smart stuff so they work well on both Pandora and Pyra, the differences should be abstracted away somehow. Most of this abstraction will of course already happen with the standard libraries (like SDL etc), but there will be things that have to be made explicit and standardized, like the examples I gave above, and that require minor additions to the Pandora firmware. We can already start with that now and update our applications to become "Pyra-ready".
It could be used as an abstraction layer to abstract away the differences between the devices.
E.g. say the Pyra has action buttons labeled Δ Π Ω X and the Pandora has action buttons labeled Y A B X. From the point of view of a developer, they're just PgUp Home End PgDn, so the labeling does not really matter. But he may want to show the button mapping in a help screen or something. In /usr/share/pandyra there could be guihint images, e.g. /usr/share/pandyra/guihints/action_north.png could be an image of the Y button on a Pandora, and an image of the Δ button on the Pyra. That way, if you load the guihint images from that standard location, they "magically" become the right image. (Independently of what button labeling the Pyra will have, I think it's a good idea to have shared guihint image files in a standard location, even if they're the same for Pandora and Pyra).
We could use a similar idea to allow applications to use 4 shoulder buttons and 6 action buttons on the Pyra, while mapping the missing buttons to O P 1 backspace or something like that on the Pandora (and you could change the mapping easily and globally by tweaking some files).
Setting the CPU speed could be done by calling /usr/share/pandyra/set_cpu_speed.sh with as a parameter the number of classic Pandora MHz of performance the application needs. The script would check if the current cpu clockspeed is fast enough, automatically sets it higher if it's in range of what you allow to automatically change, or gives a warning and allows you to try anyway if the application wants to go higher. E.g. if you do set_cpu_speed 800 it may overclock a CC Pandora unit and do nothing on other devices, if you do set_cpu_speed 1000 it gives a warning on a CC/ReBirth unit but lets you try anyway at the max you can do (e.g. 900MHz), if you do set_cpu_speed 1400 it will overclock a 1GHz unit to the max you let it go to but may still do nothing on the Pyra. The formulation of the warning could depend on how much difference there is between the max you allow and the requested speed; e.g. if you try running a very demanding Pyra application that asks for 3000 "MHz" of performance (remember, these are Pandora-equivalent bogoMHz of performance, so 3000 "MHz" may correspond to only 1000MHz actual clock speed on the Pyra's A15) on a CC Pandora, the warning may say "This will not work. Do you really want to see this slideshow?". Anyway, you get the point, and by using a shared script, we can make it relatively intelligent.
And so on. There may be more things to put in /usr/share/pandyra. The point is: we should avoid having individual applications that try to do smart stuff so they work well on both Pandora and Pyra, the differences should be abstracted away somehow. Most of this abstraction will of course already happen with the standard libraries (like SDL etc), but there will be things that have to be made explicit and standardized, like the examples I gave above, and that require minor additions to the Pandora firmware. We can already start with that now and update our applications to become "Pyra-ready".
