I've noticed with the latest update (the one that WabbitEmu prompted for an update) that having the skin on really eats up resources and causes lots of lag with keypresses. Turning the skin off, it works just fine.

Yep, that is correct. 5^k+1 mod 100 = 26, so  (5^k+1)/2 mod 10 = 3. Then (5^k+1)/2=5^m is never true, so the only way to take care of that is if (5^k+1)/2=(4n+1)2^r, but since it is odd, we know it must be that r=0, so (5^k+1)/2=(4n+1)

Also, sorry if I am wrong about anything, I haven't slept much.

You only need to worry about when n(2n-1) is not of the form 2ⁿ5^m.

2n-1 is always odd, so that must always be a power of 5.

2n-1=5^k ==> n=(5^k-1)/2

So then you need (5^k-1)/2 to be factored as powers of 2 and 5. 5 will never be a factor, so we need (5^k-1)/2=2^m ==> 5^k-1=2^m+1

This is true for k=1, which is n=2.

All other cases are when (4N+1) happens to cancel any non-2 and non-5 factors from the denominator, which happens at N=8. (2n-1 = 15, 4n+1=33, so the 3 cancels leaving 2^3*5 in the denominator).

Well, the Nspire is a whole different system than the Z80 calcs, so I have only done BASIC for the most part on it.

LZ compression followed by statistical compression would probably get the best results. LZ compression would compress any repeated words or phrases to 4 bytes (maybe 5 depending on how large the file actually is). This might not seem good, but the bytes are just a pointer to the existing phrase. For example, the following:

gird yourselves, and ye shall be broken in pieces; gird yourselves, and ye shall be broken in pieces.

Since it is less than 256 bytes would be compressed to something like the following:
[0+49]gird yourselves, and ye shall be broken in pieces[0+2]; [128+0][0+1].
Everything in [] is a single byte. So the original phrase would have been 101 bytes, but the encoded string would have been 1+49+1+2+1+1+1=56 bytes. However, in the much larger file of a book, words like "ye", "be", and "yourselves" might be encoded in a single byte (like BASIC tokenization as codebender described) so the compression would be significantly better.

If you have a compressed copy on your computer, chances are software can be easily written to decompress on your calc.

Do you know if Axe will ever be able to work in WabbitEmu and jsTIfied again? It always crashes for me.

Yup, I am in each category. I don't know Lua, but the worst that can happen is that I won't win

Question: The english documentation says to name the file MINDXX, but the French says TOMEKXX. Which one should we use?

I managed to optimize the first iteration. I thought to analyze it while in class, so I saved two bytes, 8 cycles.

EDIT: Here is some pseudocode for getting the full square (not just the lower bits):
A_sqrd:
;Input: A is an x-bit number (example, 8-bit, 16-bit, et-cetera)
;Output: A*A
A<<1→B ;Store A shifted once into B.
0→ACC ;Initialise the accumulator with 0
1<<(x-1)→MASK ;Set the last bit of MASK
For (x-1) Iterations:
ACC<<1→ACC ;shift ACC (same as *2 or ACC+ACC)
B<<1→B ;shift left once, keep carry
((SBC(0,0)^A)&MASK)+ACC→ACC ;SBC(0,0) is "subtract with carry" and will yield either -1 (carry flag set) or 0 (carry flag reset).
(MASK>>1)|MASK→MASK ;arithmetic right shift
Return (A<<x-A)-ACC
Implemented on the Z80, it kind of sucks taking twice as long as a traditional routine. However, it is novel, I think, taking 7 iterations:
L_sqrd:
;Input: L
;Output: L*L->HL
;It's really slow compared to a generic 8-bit multiplication
;It's also pretty big
;But it is a novel approach!
ld e,a            ;this just stays a constant for the algorithm
rlca
ld d,a            ;this will be rotated to get the bits of the input
ld l,0            ;the accumulator
ld bc,0780h      ;c is a mask
loop:
add hl,hl
rlc d
sbc a,a
xor e
and c
add a,l
ld l,a
jr nc,$+3
inc h
sra c
djnz loop
;HL is 255*input-input*input
;add input
ld c,e
add hl,bc
;HL is 256*input-input*input
;negate HL
xor a
sub l
ld l,a
sbc a,a
sub h
ld h,a
;HL is input*input-256*input
;add input*256
ld e,b
add hl,de
;HL is input*input
ret