The low-level XA/XB/YA/YB signal must be watched by software (the 300Hz interrupt is probably too slow to sense fast motions, so there's little chance to have the mouse driver running in background).
== Timings ==
The Atari/Amiga mice do output low-level signals. Ideally, software should check the signals ''more than 500 times per second''. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse if moved too fast.
Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.
== Motion Signals ==
The XA/XB indicate horizontal motion (and YA/YB vertical motion), like so:
One Direction Opposite Direction
XA _______----____ _____----______
XB _____----______ _______----____
The signal timings depend on how fast the mouse is moved (ie. if the mouse is not moved, then it may stop anywhere in the above diagram, eg. while XA and XB are both high, both low, or one high and one low).
The simpliest approach is to wait for raising edge on XA, and then to check XB (either XB is already high, or XB is still low) and increase/decrease the software's mickey counter accordingly. In situations where the direction changes, it may be also recommended to handle "half mickeys" on falling edges on XA, eg.:
One Direction Stop Opposite Direction
XA _______---------------------------______
XB _____-------------------------------____
In the above case, checking only raising XA would miss the direction change on falling XA (if that happens repeatedly, then the mouse would disappear towards the screen border, eg. if the mouse is in an unstable position, without actually being moved).
== CPC Plus Compatibility ==