Here's some math, you're off by about 4 vertical, for 40 horizontal. 10% error. For something that you will have visual feedback for, this is not a big problem I would think. Just leave it. I refer you to the acronym, KISS. Keep It Simple, Stupid.
Yes after thinking about this overnight, I would have to agree with your KISS acronym. Thanks Joey.
How much input do you get from the mouse? On a granular level, you will always (almost always) move in a diagonal direction, even if it is just a couple of steps from being on the X or Y axis. It is very difficult to move exactly on axis, right?
You have a counter that tells you where you are in each 'cell', underflow moves you either DOWN or LEFT and overflow moves you UP or RIGHT? Then reset the counter to the middle of the cell.
I would think that the visual feedback you get from the cursor movement will correct for any skew in the X/Y coordinates.
The two most useful applications for the mouse (for me, anyway) are editing, where you are taking advantage of the live screen data, and menu navigation, where you 'hit' a series of drop-downs. In either case, the cursor movement needs to be somewhat accurate, but not perfect.
Lots of good questions. Basically I've come to the conclusion to do anything but single steps, as in character positions with the cursor for most of the normal mouse movement creates a problem of accurately getting to where you actually wish to be. However this is not to say that with a fast movement, that some acceleration can be achieved and be desirable by double stepping. But ultimately its got to revert back to single steps, otherwise you'll miss your target. So if I start seeing a large difference in newX and/or newY readings vs oldX and/or oldY, then I can add in an extra step, since these are essentially more like acceleration registers when handled this way.
"How much input do you get from the mouse?"
As by how much input, I'm assuming you are referring to how big a number is sent vs distance traveled. If I were streaming the mouse, some of this could be adjusted by a couple of registers it has for scaling and sample rate. When polling (as I am doing), then there is a resolution register that has 4 possible settings: 1 count/mm, 2 count/mm, 4 count/mm, 8 count/mm. Of course my polling isn't perfect, and is kind of dependent on what else is asking for attention in the main program loop. But with that said, even the 8 count/mm tends to work ok, since it would take a bit over an inch of travel to cause the 8-bit axis counters to overflow. So long as I can service the mouse before it travels an inch, the X &Y data stays intact. Of course if I were to sample that slow, it would be a pretty horrible mouse implementation. (Note: each time I request a data packet from the mouse, the axis counters get reset automatically)
"It is very difficult to move exactly on axis, right?"
If you keep to single steps, it is fairly easy to maintain a path up or down the Y axis, or left or right on the X axis. Diagonal is a bit less accurate, but not overly so. So in other words imagine that you are traveling horizontally with the mouse, then think of the height of a character on screen as being a window of multiple pixel resolution, so long as you are staying within that window while moving across the screen no up or down change in the cursor position will occur. This is the advantage to a low resolution. If you were to do the same on your Mac, Windows, or Linux machine, you would find it extremely difficult to maintain a single horizontal line of travel due to the higher resolution available (the window is essentially a pixel or two in size, with far more pixels than the Atari screen, hence much smaller as well).
"I would think that the visual feedback you get from the cursor movement will correct for any skew in the X/Y coordinates."
Yes I agree.
Thanks for the link Fuji, I'll check it out
Here's a quote from another source talking about the idea of scaling the mouse movement...
When a user is trying to point at something on a screen, they will quickly move the mouse in the general direction of the target, and then slow down to accurately point at it. The deltaX/Y values from the mouse packets can be used directly, but doing that will force the user to move the mouse very far to get the cursor from one area of the screen to another.
A better answer may be to scale the mouse movement by additional multiples, based on how fast the mouse is moving. If the mouse is moving slowly, the scale factor can be 1 -- to allow the highest possible sensitivity. When the mouse is (or has been) moving fast, the scale factor could be 5 or 10, to allow the cursor to move across large distances on the screen quickly.
There are many ways to do such scaling, obviously. If you are coding the driver in assembler, one suggestion might be to use the BSR command to generate an approximate log base2 of deltaX plus deltaY, and use that as your scaling factor.