It turns out that the reason why my BASIC driver only returned 00 01 and FF in hex was not because BASIC couldn't keep up but because the light sensors had got bent out of place in the mouse casing!
That aside, the next task is to get some machine code going. The new program on this disk ("U.MOUSEY") may be *RUN having set up your Mouse Systems compatible mouse (NB, not Microsoft).
The packets of five bytes will be printed on the screen as and when there is mouse or button movement.
This software operates in the background as per a finished version would have to, so you can carry on doing other things at the same time.
I haven't tested it whilea accessing the disk - the DFS or ADFS hogs interrupts so its results are undetermined. Try it and report back to me how it responded.
If the screen is in scroll lock mode then the OS's IRQ handling becomes dodgy. Likewise during background printing or using SEI for prolonged periods in assembler.
My driver takes this into account, and if some of the mouse's bytes are lost while the BBC is doing long interrupts then it will resync itself to the start of the next five-byte packet. You are informed of this by RR appearing on screen.
Now all that remains (he says) is to get some sort of a pointer on the screen. I know what the five bytes received mean in terms of relative positions, but these will need scaling depending on which Mode is in use.
Pop the result in a ROM, package it up and we can all have mice attached to our machines. Simple.
1st October 1996