you're right, dealing with it as a 16-bit isn't necessary, you can just do it with an 8-bit variable and an if-else statement, like you have in your pseudo-code, just don't forget that it is a 2's complemented number, so you do have to remember to convert it back to a positive number before you go subtracting it from 'distance', in the case that it's negative, but don't convert if it's positive... in other words, move your first line there (where you convert it) inside the if statement for the negative case.
oh, and isn't assigning a variable called "X" with the Y-axis movement a little confusing? are you going to call your variable for X-axis movement "Y"? :lol:
and as for your display routine, that's very inefficient because division and modulus are not fast routines on a PIC, and you have it calculating up to 4 of those per line. For example, with the CC5x compiler there is documentation of the time it takes for certain math operations. modulus and division both take, on average, nearly 300 instruction cycles to execute for two 16-bit numbers. I would assume your compiler produces comparable delays for these operations.
you can do away with a lot of the operations with intermediate variables.
like so:
Code:
b5=distance/10000;
temp=distance%10000;
b4=temp/1000;
temp2=temp%1000;
b3=temp2/100;
temp=temp2%100;
b2=temp/10;
b1=temp%10;
that only involves 8 modulus/division operations, whereas your original code used 14. Granted, in a perfect world the C compiler should be smart enough to realize that it could re-use a lot of its own internal intermediate variables to optimize all of that, however I wouldn't rely on it until I had actually tried writing it both ways, compiling them, and verifying the final code size in each case.