I'm having slight progress with the SD-card reading programming.
I'm currently reading a full frame of animation 13 times per second. Time for some sloppy math!
Old code: 1 Byte @ 3.5 ms
New code: 1 Byte @ 0.01 ms
Unfortunately, this is too slow to be useful - but it is still a 350x improvement over the previous speed! IF it's possible to break down the reading over several frames this is not an issue. But I'm not sure how the SD-library responds to changes in the SPI-slaveselects during reading.
I could load one color-layer at a time (512 Bytes) directly into the drawbuffer during animations, which hopefully translates to around 6 ms per layer. That way the screen would still refresh fast enough to be considered flickerfree. It would only allow for videos with around 10 frames per second if all 16 colors are being used. There might be a FAT restriction on the number of files on the SD-card that prevents me from using this method however.
Another option could be to simply load a lot more data and "pause" the game during loading. 1 second of loading would load 23 frames of animation, and if playback speed is 15 fps it roughly sums up to 1.5 seconds of animation. But it's not really practical to pause the display and lights every now and then, and usually when the game allows a pause you'd often want more than 1.5 seconds of animation.
Naturally I'd prefer to read an entire frame (4096 Bytes) in one go, since this allows me to easily add text and tweak the screen before displaying. I guess I'll have to experiment a little to find out how to solve this!
It may be time for me to fix the slow 'digitalWrite' of the Chipkit after all, something which I've sort of avoided until now... because it's boring!