PTC would keep it in the same place. I tried it here, and it just reset it everytime. Even if I used SPCHR to "change" the sprite to what it already was (eg, I start with the orange, and use SPCHR to pick the orange again) it would still reset.
Maybe I'm doing something wrong here.
So apparently I have to use SPDEF.
When I was fiddling around with SPDEF, I noticed that SPHOME was still a thing. I decided to try it, and it worked as before...except...
When I used SPCHR to change the sprite in my control loop, it reset the coordinates of the control point to 0,0. In PTC, SPHOME set the origin of the sprite via the control #. Even if you changed the sprite with SPCHR,
*Goes to do some spriting*
*Realizes that the file has been overwriten with the blank graphic screen*
Remind me to move the load button over. Now if you'll excuse me, I need to go to a corner and cry.
(Luckily, I posted a picture of my first sprite for reference)
I was stuck on this as well, but I learned how it works with the ATTR command, which messes with text on the display console. It was helpful because it used less bits.
Like so:
Alternatively, I could've simply typed in the numerical equivalent of (0)10001, which is 17, at the end to get the same result.
However, I find it easier to manage when actually looking at the bits.
Hope this helps somewhat. If not, then I tried. :p
In the pic, I used SPDEF, but the same principle applies.
Notice what I typed at the end:
" &B010001 "
With the aide of the binary format, each individual number represents a bit:
0 1 0 0 0 1
Bits: 05 04 03 02 01 00
With this, you can apply a 1 to whatever you want to be true. In this case, I told it to show the sprite and invert it vertically.