Since I've seen "crash-proof", I've become very tempted to attempt a program that corrupts the archive beyond what yours can repair
Anyway, congratulations!

1895:Youitakeithatiasiaichallenge.

It's possible to create a program that ignores Ctrl-C, at least in Windows. Combine that with a fork bomb... (See the Win32 API version)
Frey, it stands for Anti-Riot Squad, a user group with op permissions in IRC and some mod powers created because of the need for increased moderation after the popularization of nDoom.

There's only one notation: decimal notation. Is the part that's throwing you off the fact that the number is bounded between two powers of two and not two powers of ten?
Edit: It doesn't seem very hard to understand a statement such as "The number must meet the condition that -128<=#<128."

That will screw with all your math. That would make 0.500**1.000>>1.000 true, for instance. And don't suggest changing the ** operator, either, because then all it would make it almost twice as slow because of the necessary extra multiply.

There's absolutely no way you could specify the integer part from 0-999 unless you did 10.6 fixed point instead of 8.8, which is what Axe uses
Also, given that Axe treats all fixed-point numbers as signed, the integer part can only be from -128 to 127, anyway.

Have you chosen yet yourself? None of those options are bad (except perhaps for the ones involving playing video games ); it'd be hard to make a wrong decision.

The degree sign is already used to use the address of a variable. If I could remember how Axe did fixed point, I'd give you a simple workaround for it.
As for the 2- or 3-digits issue:
First, note that the underlying format uses base 2, while the numbers are expressed in source as base 10.
8 binary digits (I'm not using 'bits' in hope that what I say will be slightly clearer) have more precision than 2 decimal digits. This can easily be seen by noting that 2⁸ = 256 > 10² = 100.
8 binary digits are also less precise than 3 decimal digits. Once again, 2⁸ = 256 < 10³ = 1000.
The reasons behind each preference for a certain length are, as I understand it, as follows:
2 digits: We want the underlying format to be more precise than the input format, so that nobody is confused by the loss of precision resulting from expressing the number in 3 digits.
3 digits: We want the input format to be more precise than the underlying format, so that everybody has full control over the contents of the resulting binary fixed-point number.

I do support 3 digits, though. A note in the README should suffice to alert about the loss of precision.
The main reason is that, if you only want to use 2 digits, then you only use 2, while you can't use 3 if there's only support for 2.