So I'm ThatTreeOverThere, new only in posting to the forums  , and I've been playing with Axe for a little while. I've run into an issue, though...
I'm making a top-down zombie shooter, and i'm having trouble drawing sprites exactly where I want them to go. I want to be able to store the positions of each zombie in 2 bytes per value (so, 4 bytes for X and Y together), but when I go to draw them on the screen, I suspect that Pt-On( converts my beautiful 16-bit numbers into 8-bit numbers and causes sprites to draw modulo 256, which is annoying! 

The specific part in source looks like:

For(I,0,S
Pt-On({I*2*2+B}[sup]r[/sup]+X,{I*2*2+B+2}[sup]r[/sup]+Y,Pic1
End
Where S is the number of sprites-1, Pic1 is the sprite image pointer, B is a pointer to a list consisting of 2byte X and Y values (and I'll optimize out that last duplicate expression later )

So can anyone help me?

The sprite drawing routines (and for that matter, pretty much all drawing routines) in Axe have always treated the position inputs as 8-bit numbers. Probably the main reason is that it makes the underlying assembly code simpler, smaller, and faster, while still doing enough for almost all uses of the commands. I always wondered in the back of my head if this would ever be a problem for anybody, but I think you're actually the first one to ever come forward with this issue.

Unfortunately, I shouldn't/can't really change it from 8-bit clipping as it is now. There is the issue of increased code complexity, size, and execution time as I mentioned before, but those alone probably wouldn't stop me from thinking about making the change. What would stop me is that, although you use 16-bit positions, I know a lot of other coders and their projects are fine with, and use, 8-bit positions for objects/entities. The issue arises if these 8-bit positions are negative, because the sign information is really lost with Axe's standard, unsigned 8-bit memory read (the value is actually converted to a 16-bit value, it's just a value from 0-255 so the high 8 bits are always 0). And having negative positions is important in some cases, like having sprites that are partly off-screen on the top or left side of the screen.

Anyways, tl;dr: sprite commands use, and must keep using, 8-bit positions. So I think your possible solutions are either to find a way to downgrade to 8-bit positions or to perform initial major clipping with your own code. The first option is definitely easier and more efficient, so I'd be interested to know a bit more about your project and entities to determine whether or not it's possible.

To post source code, you can use SourceCoder or TokenIDE, which are on-computer TI-Basic/Axe editors (they're respectively web and app based).
And for your problem, you can simply check whether or not the sprite is on screen, and then draw it at the proper position if it is. That's what Runer meant by "initial major clipping" I think.

Hmm, might I ask why you need 16-bit coordinates? And will they be signed or unsigned? If they are unsigned, you will not be able to use the negative coordinates Runer112 mentioned.

You wouldn't need 16-bit coordinates if you just want the screen to be the area to walk around or whatever, but that''s not what you want, right?

If I understood you correctly, you have also 2 16-bit coordinates of the camera. To get the right coordinates for your sprite on the screen, simply subtract the camera coordinates from the sprite coordinates. You might need to check whether the sprite is on the screen or not, you can achieve that by testing X+8 > 103 and Y+8 > 71, that will handle negative coordinates as well.