Details

Preliminary patch to explore the concept of plugins that consist of a single function ("pebbles", small rocks) to avoid the need for relocation.

These plugins are loaded into the skin buffer, and are called during WPS redraw. Add a %P token to the wps to try the included test_pebble

Still to do:
- actually parse the token to allow specifying the pebble to load
- call the pebble for init/exit
- implement bookkeeping and clearing of the pebble table on wps reload
- work out how the pebble-allocated memory should work
- test on non-ARM
- check the plugin API version on load
- allocate the correct buffer size

some random thoughts:
the/a pebble api needs to give the pebble some internal function pointers. get_*_token_value() and just get_token() so it can easily get the value from any other token
likewise it should be able to act like a simple token so it can just return the string to display
also access to the skin_buffer_alloc() function, and the entry point should be called for the parse line and updates
it should keep track of the update requirements for the token (WPS_REFRESH_DYNAMIC|STATIC|etc)

Also, it would be good to be able to reuse the same pebble more than once, either between skins, or even in the same skin (look at skin fonts and backdrops)

This one gets slightly closer to the standard plugins in the way things are organised. Multiple functions work (most of the time anyway), and the pebbles get a viewport.
Use with %P|name_of_pebble| (e.g. "%P|test_pebble|"), the pebble will get the entire enclosing viewport.

I've added a starfield pebble, but that one doesn't work properly. It suffers from illegal instructions, data aborts and the like. Help in figuring out why is welcome.

Changes since v6:
- partly works on m68k (test_pebble works for me, starfield does not). Linker scripts and compilers are evil!
- passes the viewport using a global (similar to rb) named pebble_vp
- calls lcd_set_viewport before calling the pebble paint function to ensure that the correct viewport is active