what would sub-routine usage in expression do?

In my example:
91-(sub(CS))
I have:
Lbl CS
S=8*2
Return
This allows me to return a calculation I use in many places throughout the program without having to retype the expression everywhere it is needed, thereby reducing program size.

Right. That is exactly how I did it on the calculator. Token for token, hex for hex, and number for number

edit: Ok, I added the same [xxxxxxxxx]->pic1 right after pause 100, and it worked... I guess it forgot that pic1 was stored?  
edit: I put the diagnostic off after the sprite, and it worked. I think thats what did it

I don't think that retrieving and storing two-byte expressions work correctly. Both of the following examples would be affected:

{V+2}r→T
T→{L1+2}r
I believe this is because, although the r modifier is supposed to simply signify two bytes in this case, it signifies both two bytes and it swaps the bytes. Taking the first line as an example, if {V+2}=01 and {V+3}=F0, T becomes F001, although one would think that it should become 01F0. The second example acts even more oddly, the incorrect behavior of which I am spending a lot of time trying to counteract.


EDIT: This really needs looking into. I've spend the last hour just trying to get a few two-byte values to work correctly. And I haven't even been successful yet.

ANOTHER EDIT: I finally got it to work, but the code that makes it work took a lot of trial and error and doesn't logically make sense. This is still a problem that needs to be checked.

jk

So if i understand you correctly, you are saying that storing 2 byte numbers works incorrectly because it stores the bytes in backwards order?

I'm really not sure anymore. I just spent over an hour trying to get two-byte data manipulations to work in my program. What works in one case doesn't work in another case. I can't explain what is wrong anymore, it doesn't even seem to be a constant flaw.

jk again

Do you understand how if i store a 2 byte number into {L1+0}, the first byte gets stored into {L1+1} and the second byte into {L1+0}?  This is what is known as Little-Endian format (since the little end goes in first)

Ok wait, I'm confused now. If I stored 1025 (0401) into {L1+2}r, I would get {L1+2}=01 and {L1+3}=04? Then what would I get if I evaluated {L1+2}r?

EDIT: Shit fail, now it all makes sense... *facepalm, goes to strike out other posts*

Right. That is exactly how I did it on the calculator. Token for token, hex for hex, and number for number

edit: Ok, I added the same [xxxxxxxxx]->pic1 right after pause 100, and it worked... I guess it forgot that pic1 was stored? 
edit: I put the diagnostic off after the sprite, and it worked. I think thats what did it

That shouldn't be happening, I'll look into it.

I hate little endian!  It was so confusing when I was learning assembly and caused all sorts of errors.  But you kinda grow to like it eventually because it makes some things simpler.  Fortunately you never have to deal with that directly in Axe unless you actually go to look at the data you wrote in some non-conventional way.

I always wondered what was little-endian before. Glad people summed it up now, because the Wikipedia article seemed to be TL;DR