I've had a free while to test latest version of gpsp, and I must say that improvements are amazing. Thanks a lot, gdizzz, it won't be too bold to say that even desktops doesn't have so smooths GBA emulating experience, as your smoothly integrated GUI, (in pair with tweaked base gpsp), offers!

I have one maemo-specific feature request, that (I hope) shouldn't be hard nor time consuming to implement, yet would be *very* usefull to have:
It's about expanding a little (already present in gpsp) accelerometer support. I found that it works suprisingly well for many sim/arcade sim games (Wings, Tomcat F-14, Wing Commander, etc), allowing for even better control experience, than on native GBA - the thing is, that it assume "neutral" position at an angle that is *very* unpleasant to play, i.e. when N900 lies flat on table. So, to keep it without triggering directional keys, one need to "hang" above horizontaly positioned N900, tilting it to get input.

Now, there are two possible workarounds for this that I imagine - the best one is seen on most accelerometer-enabled Maemo games, already (including Open Source ones, like Alpha Strike, or "Accelemymote" tool, so approriate code could get "borrowed", if nothing else), and works in a way that device "calibrate" neutral point at accel. readings from when game is started.

In this variant, all the user have to do is to held N900 in comfortable position, while hitting "start" from gpspGUI. In case of accel. enabled globally/for that particular game, main gpsp application would set neutral point for accel. readout at startup.

Other, less comfortable, but absolutely acceptable solution, would be to set neutral point for accelerometer in gpsp config file (and/or from GUI "general settings"). There are many programs that give readouts for current gyro's position, so one would need to check them while holding N900 comfortably, then write it into config. Not as smooth as 1st solution, but would still work, nevertheless.
---

Last but not least, it would be nice to have control over what get mapped to acceleromete positions. Sure, anything else than directional pads are rarely required, but in some cases, it would help - from simple up<->down inversion (when game doesn't offer Y-axis inversion from its control), as basic example. And if we would be to give that control to the user, no reason to disallow assigning more weird things, like whatever button.

/Estel