Larger animations get everything but the last 4 frames corrupted.

Beware: freeing static, unallocated memory will cause very strange
behavior!

Also incremented version number.

Removed buggy idle animations. Killed idle frames alltogether.

Finally, the moment you all long awaited :)

Also better filtering for audio data in AudioFirmware.

Poti is now a multiplication, from 1 to 3,5. Also added basic noise
filtering. UploadTest can now send a specific byte as frame data.

Audio CPU now resets MSGEQ7 properly. Bufferhelper clears memory after
allocation. Z Axis now goes into the correct direction. Removed
FillRect. Enabled Watchdog for Debug Build, too. Removed unneeded
strings. Built-In Framedata in own file. Makefile cleans object files
after every build, because it doesn't matter. Simple Visualization
works correctly. Most recent Hex-Files now included.

Wrote new audio visualizer. Created help functions to operate on a 3D
image buffer.

Changed some more faulty transistors. cubeInit now displays short test
animation. Moved header files in own folder.

Audio Firmware now with Watchdog. Removed unused code. Fixed compiler
warnings. Fixed cube coordinate system problems. Fixed audio display
rotation. Nicer Idle Display with SAP Logo. Increased Firmware Version
Number. Debug Build even more talky.

Code never was rewritten for new Hardware.

The display now gets updated with 48fps or 384 layers per second, while
the animations still play with 24fps.

Interrupt execution time does not change, strangely?

Yes, I'm bored. But thats only for you to do the real work *wink wink*…

No longer using one- and two-dimensional arrays combined.

Also changed nitrate to highest one possible with our clock speed,
38400bps.

Now talks to FRAM most of the time…

Auto select animations and frames, consistent order for frame and
animation buttons.

Setting the DDR of the serial pins before initializing the serial
hardware caused some logic '1' spikes on the tx line.

This was done because I was suspecting an error to be there. This is
not the case, so we probably have a Hardware Problem with our USB
Serial Stuff… If we send data too fast it sends garbage. It also always
sends two additional bytes (0xC2 at the beginning, 0xFF at the end),
which both come at the beginning if we don't delay between sending the
chars…