If you're only moving a few bytes, it's best to just move them with individual load/store commands, like:

{L₃}ʳ→X

The reason that's giving you an error, though, is because the degree modifier needs to precede variables.

Yep:

°VAR

Returns the pointer to the variable.

* Freyaday feels sheepish.

Yeah.
But, um, why'd Axe accept it as valid code and then not see the following argument? What was º, returning?

Maybe it caught the error only at the parenthesis?

Haha you know what the problem is? The ° "command" isn't checking whether or not the next token is actually a valid variable that can be dereferenced. So in your code, it's parsing X°, as loading the value of X and then loading the pointer to , even though the latter makes no sense. So there's a bug for you to fix after all, Quigibo.

Oops!  Forgot to check for that.  Looking at the code, if you're not using a letter, it subtracts the value of the token from the value of the "A" token to figure out where in memory it should be.  So if for instance, the token is value 200 and the A token is 32, then its looking at memory location (^oA+(200-32)*2) wherever that is.  I'll have that fixed next version.

getkeyr is unfinished, it seems. after you run a prog, you still have to 2nd+Quit to turn off the calc. Also, sometimes it force quits the progs, probably related.

So handy for menus though do interrupts still work while it pauses?

Edit: NVM about the 2nd bug, it's because I made a bad assumption regarding pointers in progs. First one still happens, where you need to do a QUIT to get stuff back to normal. Reminiscent of some Fix problems I've had

I have a bug for 0.5.1: I made a sprite routine and sometimes there are random lines appearing. I'll post the thing where it happens later.

Hmm... I'm going to call this 50% my fault, 50% Quigibo's fault. I provided Quigibo with an optimized portion for the Pt-Mask() routine for Axe 0.5.1. But because I was only providing a small portion of it, I didn't worry about its context. But it just so happens that the portion I provided for him was the very last part of the routine, so we managed to lose the final return for the routine somewhere along the way.


So here's why you're seeing the artifacts in your program. When aligned masked sprites are drawn (x mod 8 = 0), instead of the masked sprite routine returning at the end, code execution proceeds to whatever happens to be after it. And in the case of your program, the next routine is the Pt-On() routine. But because it just has garbage inputs that are whatever carried over from the end of the Pt-Mask(), you get garbage sprites drawn to the screen.

As for a fix, you have two options. The first is to downgrade to Axe 0.5.0, but I have a better idea. The second option is to add the final return onto the end of the masked sprite routine yourself! What you'll want to do is open RPGSPRIT and add the return manually like this:

Pt-Mask((A*8)+r₁,(B*8)+r₂,Pic1MB+(32*A)+(16*B)+(64*r₃)+(256*r₄)
[C9]
Pt-On((A*8)+r₁,(B*8)+r₂,Pic1SG+(16*A)+(8*B)+(32*r₃)+(128*r₄))ʳ


What?

Do you have the code? Maybe it's a different bug. Jumping all over the program works for me.