Weirdness and wetness!

Spent some more time with the code and got dual animations on a single SD-card up and running!
It's an unlimited number really, but limited to two for performance. The theory is simple, since I'm not using a file system I simply load raw sectors and can grab any frame at will.

For simplicity and synchronicity's sake, I've decided to load SD-card animations with a blocking approach (as opposed to interrupt driven). This greatly simplifies things as I can keep the main loop/scene rendering to a single function instead of spreading out across several frames and wait for various inputs to complete etc. Since switch inputs and all I/O in general is moved outside the main loop, it doesn't matter really. I've locked the main loop to 40Hz which should be plenty for updating animated text, verifying animations and other non critical reasons. 

1) Basic render "geometry" examples with background animation, textlayer and front animation (layered above the text-layer).
The lower left are status flags for SD card, MCP, ULN etc. All 8 should be lit for a 100% functional machine.

The extra FX-layer really spice up the DMD, since I can overlay smoke, sparks and what not at will. I could also use two background layers, or two front etc.

I've also found a way to successfully detect if ULN and MCPs are functioning correctly, and can alert and disable features accordingly. I've completely lacked this troubleshooting feature previously, so this is a major leap forward.

I've also had the "joy" of realizing that the flash-burning sometimes fails, and that verification fails. It has been like that for a while, and I never knew why and it has "always" worked. But this weekend some simple code started to fail seemingly randomly and it basically boiled down to 'if verification fails, the upload isn't correct' after all. Usually a reboot or reselecting the toolkit in UECIDE allow me to upload successfully. As long as I know about the issue I can work around it. It wasn't exactly a straight path trouble shooting it though, since I both suspected that the DMD was broken. I took a rewrite of the routine in a new sketch to see that it was indeed working correctly. A new screen is _not_ something I want to buy at this stage...

But on the plus side the 13h+ troubleshooting made me rewrite SD card and DMD rendering routines, further optimizing them and avoiding unnecessary variable writes and operations. The downside is tough-to-read code, but once in place they won't change often (at all?).

So - three steps forward, one temporary step back.