Using straight integers for velocity values limits your options somewhat.
Only gives you 10 or so useful unique values per direction - anything bigger just becomes too fast to be very useful.
You can fairly easily employ "fractional" values by using 2 bytes per sprite axis instead of 1.
Have the integer "velocity/direction" value in one byte, "fractional velocity" in the other and have the fractional part get added to an "accumulator" value, and if it overflows, it gets added to the position on that occasion.
Use the high bit of the velocity/direction value to determine if the sprite moves in a positive or negative direction.
The coding is somewhat more complex than just doing movement by integer only but you end up with exponentially more useful velocity possibilities.
Best method is probably to add the fractional to the accumulator values, store it.
Then get the velocity/direction byte. PHP to save the "N" flag.
AND with #$7F to leave velocity only, ADC #0 to add the accumulator overflow that would be left in the Carry.
Then PLP to get the previous "N" state back. Accumulator has the velocity in force for the current iteration. Then you BMI to the code that subtracts velocity from the XPos, otherwise it gets added to the XPos.
The other advantages of fractional movement is the ability to do nice smooth acceleration, and very slow movement - down to about 1 pixel every 5 seconds.