Looks interesting. What all haven't you told me of this algorithm? Answer in pm if you'd like.  Also, it's likely not 19/750, but something else, and it just appears that way.  We shall see.

I'm curious about if you applied it to complex numbers.

Yo, welcome to omnimaga. If you make an introduction topic, we can give you peanuts. ;-)

Now then, I'm glad you choose axe for your development needs.  Pointers are both the most complex and yet the most beneficial part of any programming language.  First, let me explain pointers. A "pointer" is a variable that points to something else. See, that wasn't that hard.  In the example of pics, it is fairly easy. (Everything after ; is a comment)
[pic1]->Pic2 ; Absorb the 756 bytes that make up the pic1 variable on the calc into the program.  Pic2 is now the pointer to the first byte of the data for pic1 inside the program.  Pic2 does not mean Picture 2 as in the calculator.
det(12) ; Adds 12 more bytes (all zeros) in order to make the total length 768, as that is the byte-size of the calculator screen.
for(A,0,767) ; A goes from 0 to 767.
{Pic2+A}->{L6+A} ; Since Pic2 is pointing to the first byte of the picture, {Pic2} gets the actual first byte. So, {Pic2+A} gets the first byte, plus some offset. So, {Pic2+1} gets the second byte. This is why we went from 0 to 767 and not 1 to 768.
end ; End to the for loop
DispGraph ; Display the buffer on the screen.
If you had replaced L6 with L3 above, it would have been to the back buffer.  Now then, imagine 3 different things. A screen, and two buffers. One is what is being displayed. One is the buffer, and as soon as dispgraph is run, the buffer becomes the screen.  The backbuffer is essentially another buffer, just used in case you need two buffers.

Note that the above code should work, but isn't tested. Don't have a calc to really test it.

If you send it to another calculator, it will not expire.  What I'm calling the expiration count is a field on the certificate page; it's not stored within the app, but it's set by the OS at the time the app is installed.  For normal, non-limited-trial apps, it should be set to the value 80 00.  Since Axe circumvents the normal installation procedure, this doesn't happen, so the field is left at its default value (FF FF), which is interpreted to mean that the app should expire after being run 16 times.

So, if axe changed those two bytes, would it fix it? Wait, can we even write to the certificate that easily?

Try in different browser? (or maybe they got too many Casio Prizm e-mails and purposely broke their e-mail form to not receive anymore )

Also nice find Graph! One thing I hope, though, is that the loading bar won't appear everytime we store stuff to real vars, though. This would make BASIC programs ugly...

Which could mean that their memory is insanely slow.  Other than that, I can only assume it is a flag, and can be disabled software wise. I might just get one of these.

The quick modify button is actually just an image which calls the modify_msg() command on click.

for some reason it won't let me send ...

...can someone else try it too?

Nope! j/k. I don't think it's over the word count. Are you sending from a hotmail/gmail account? What error is it giving?