No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.

Mmm i dont see how this would work.  I think you might be mixing up characters and tokens.  Tokens are what the editor uses, characters are only what the tokens are made out of.  Are you suggesting overriding 26 tokens with new character sets?

Its not speed im worried about, its getting the physics to work.  I think you might be underestimating how difficult this would be to get this to work.  Not only would i have to implement something like Zedd, but it would have to be able to transfer an arbitrary amount of force through portals.  Which means i would have to rewrite so much stuff, including the player movement.  Crazy situations would arise like the ones i detailed in my screenshot:


Green Portals:
Boxes stacked and going through 2 horizontal portals
Forces have to travel through portals, and the boxes would have to eventually find the balance point, with boxes colliding with ghost boxes and gravity acting different ways on a single box.

Red Portals:
Player pushing boxes through a portal into a vertical stack.  Eventualy the force from the stack makes it impossible for the player to push.  And what happens when the player goes through the portal?

Blue Portals:
Portals in a corner, so that a box that is going through a portal collides with itself.  To crazy to even try

In short: Its not happening

How would it know the difference between lowercase and uppercase then?  Since they would be using the same token o.O

Nope, for reasons stated before.  Having collisions between boxes through portals would be a nightmare with all the converting of forces and such.

The physics im talking about is because then every block would both have to continually check its position against the players position, and all other blocks.  If you pushed a block into a portal, and it was halfway on one side, you would still have to push the side thats on your side.  If you are pushing two blocks in a row, and you push them into a Portal, then weird things can happen.  Like if you push blocks horrozontaly into a portal, and they come out vertically from another.  They would have to start stacking upwards, while delivering the force of their weight back down through the portal to you.

And im not even considering the fact that when you move into a portal, you orientation doesn't change (as it should) you always remain vertical.  The physics of pushing blocks is not tooo bad, although too slow for my liking.  The physics of pushing blocks through portals?  A nightmare.  The way i have it right now, blocks dont collide with each other, and they dont collide with the player.  They do through Portals normally :]

I had to generalize the portal code though, so it would work for not just the player but for all objects

Hurm maybe thats how it used to be, but its not doing that for me anymore on version 1.26

The syntax is something like this

Baseconvert("Number",Base1,Base2)

i wonder if it was glitchy back then o.O I sometimes forget to put the number in quotes though

As far as i know, no.  Since whenever you store to a variable, it updates all 16 bits, clearing out any data you would want to store elsewhere.  If you really really really wanted to you could write your own routine to store and retrieve from the variable locations, but thats only if you really want those 27 extra bytes