This reverts commit b6b00a6bcd.

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?

Honestly: What is this kind of shit? Do you even care the slightest bit?

Conflicts:
	CubeControl/Led3D.java

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

Take a look at this to understand the protocol between hard- and
software.

Runs on Unix and creates a virtual serial port that can be opened by
CubeControl. Only responds to OK, (h)elp and (v)ersion right now.

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

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

What the....? Well it works THIS way...

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…

Unfortunately, the Class.equals() seems to compare something that
differs between our stored LED Spheres and the Clicked Primitive… Need
to find another way to compare…

All the code that we need to select a LED with the mouse is there…
Unfortunately, we have a "CapabilityNotSetException" and i don't know
where to set that capability… See Led3D.java Line 198!

Removing a dead IC (Atmega32) unfortunately killed some of it's pads…
I've marked the pads that need a flying wire added…

Finally! It's working… The DLL did not follow the _stdcall naming
convention!