Because they contain fast routines so you don't have to write you own (most of the time slower) ones, for in example accessing archive etc

lol, that was a retorical question stating that we could use axioms then for such stuff

Well, I figure that if we use an app, we can have more code space (16KB and an 8KB program). We can still use axioms and use an app

I started working on scrolling in the up/down direction, and it is a pain o.o I have to keep track of how far up/down it is scrolled and left/right so that I can shift in new content appropriately .__. I rewrote the right/left shifting, too and I believe it is faster, but I'm not suree (I had a better idea last night, so I don't need the IX register). Also, I have a bug somewhere in the code, apparently, because the program is doing weird stuff to my calculator every so often. On the plus side, I fixed the scrolling bug for left/right >.>

On another note, if we decided to do text compression, I have a nice algorithm for that. I was thinking this morning that I could make a Python program to read a .txt file and spit out the compressed data in assembly format.

EDIT: It is still about 60FPS at 6MHz, a few extra frames per second for shifting up/down.

I'll describe it here, since I don;t think I ever released the idea, just the code. Basically, it works like this (there are two methods)

I first designed this algorithm using Celtic3+BASIC, using the idea of how common certain letters were in the English alphabet. I arranged them in order and threw in some numbers and punctuation, so I could compress my most common messages:
ETAOINSHRDLCUMFGYPBVKWXJQZ,?!.0123456789/-:'
Note that the first character is a space. Now, in the actual message, any time one of the first 14 characters appear, it will be assigned a nibble 0~D. If anything after that is used, (say the 23 character in the list), it will be a two-nibble value, starting with E or F. You can subtract 14 and add $E0 to it (essentially, add $D2 to the original value). In this way, text will take at the worst 100% the original size and at the best 50%. However, because the first 14 characters are the most common to appear in an English message, it averages around 60% compression. For example, here is the message, "HELLO!" (this works best with larger messages):
NOTE: We start counting at zero.
H is the 9th character, so it is one nibble, $8
E is the 2nd character, so it is one nibble, $1
L is the 12th character, so it is one nibble, $B
O is the 5th character, so it is one nibble, $4
! is 30th character, so it is two nibbles: $EF
Combining the nibbles, we get 81BB4EF, but we need to store bytes, and this is an odd number of nibbles, so we pad it with a 0. This is why a space is the first character, because decompressed, it would put a space at the end in cases like this.

Anyways, that is 4 bytes, compared to 6, so compression was about 67% In BatLib, to make sure the extra space at the end wasn't in the output for decompression, I compress data and store the original size as a two byte value in the beginning.

Now, why did we use 46 chars? The first 14 are used as 1-nibble values. A nibble can be 16 different values, so this leaves two extra nibbles for our "extended" chars. So 2*16=32, which means we can have 32 two-nibble values and 14 nibble values, totaling 46. Indexing at 0, we have chars numbered 0 to 45, which in hex is 00h~2Dh. If you look at what we add to find the value of 2-nibble chars ($D2), it is actually not a coincidence that it is the value 2D with its nibbles swapped

So what if we want to compress something other than text? What if it is arbitrary data? Basically, you need to scan the data to figure out which byte values are used, then you need to arrange them in descending popularity (I call this a "compression key"). Find your cut-off value (the number you add to get the two -nibble values) and this will also tell you your cut-off for one-nibble/two-nibble values. Because this will use a unique set of chars in some order, you will also need to include the "compression key" so that you can decompress. If the data isn't large enough, the compression key plus the compressed data will take up more space than the original.

I used this in BatLib to compress some internal data, like the main menu (the bitmap was compressed a few hundred bytes, including the compression key). You can also apply this algorithm several times in some cases to further compress the data. I got one tilemap to compress down to 12% of its original size, with each of the compression keys included!

EDIT: This is the relevant code in BatLib for most of the compression/decompression functions:

So if i get it right, the '.' would be $F0 ? or $F1 ?

Just try in Axe: text(0,,241)

Oh nevermind in that case :p

Well I can imagine a lot of things that I could already do. Just not sure if they're really needed since it's still in planning stages.