How did the BBC sideways ROM software for the AMX mouse process the user port input data to determine x and y movement?

Question

This mouse plugged into the user port on the underside of the BBC micro models. The mouse came with software in the form of a sideways ROM which provided APIs, CLI commands for own programs as well as a mac-Like Desktop environment. There was AMX Super Art software as well as Pagemaker - a Desktop Publishing (DTP) software package (up to 4 ROMs). For BBC models such as the BBC Master, with Sideways RAM, ROM images of the software could be loaded into those.

The product was made by Advanced Memory Systems.

My question is: how did the code in that software ROM process the values that the mouse generated on the user port, for x and y movement (both up and down, left and right, and a mix, as well as variable speed and the 3 buttons).

Many, many years ago, I did try to develop equivalent clean-room software, but only got as far as reading the buttons (bit on and off) and reading a pattern of 0s and 1s for x and y movement but only being able to detect this and not whether it was negative or positive movement. I did this by peeking some values in PAGE 0000 of the memory map.

I also recall that Superior Software, a 3rd-party software house, provided stand-alone (not dependent on AMX ROM) support for the AMX mouse in their game editor for the Repton series.

Answer 1

Trying to get more into the specifics of the BBC connection, there is a substantial hint in the user guide:

However only 5 bits of the [user] port, and CB1, CB2 are used: This leaves bits 1,3 and 4 available for other uses.

Which is backed up by the schematic provided by Simon Inns in the doco for SmallyMouse2; comparing that to the user port's pinout the mouse provides inputs:

• X1 on the VIA's CB1;
• Y1 on the VIA's CB2;
• X2 on bit 0 of the VIA's port B;
• Y2 on bit 2 of the VIA's port B; and
• the three buttons, left, middle, right on bits 5–7 of the VIA's port B respectively.

So the value you found in page 0 was that of the input to port B: three bits corresponded to the buttons, and two of the others related to motion in X and Y as you suspected.

As per Justme's answer, mice of the era were quadrature encoded, producing two outputs per axis. On the x axis they are conventionally called X1 and X2. Both carry the output of a square wave that has a frequency proportional to the mouse velocity. They differ in that they're ninety degrees out of phase.

So during a fast movement then they might output a signal like:

X1 = 00110011
X2 = 01100110

Now imagine the user changed direction partway through, so that the pattern reversed itself:

X1 = 00110011 | 11001100
X2 = 01100110 | 01100110

If they had halved their speed when they reversed direction:

X1 = 00110011 | 11110000
X2 = 01100110 | 00111100

So a cheap way to track such a mouse is:

1. Set up an interrupt for each time X1 transitions from 0 to 1.
2. When X1 transitions, note a pixel's movement and sample X2.
3. If X2 is 1, move to the right. Otherwise move to the left.

(And for greater precision, also interrupt on X1 transitions in the other direction, but for those reverse your X2 test, and also interrupt on X2 transitions, doing the direction test on X1)

The 6522 in the BBC is capable of raising an interrupt upon transitions in CB1 and CB2, so that is how software is alerted to mouse movements without constantly polling.

You can ask the 6522 to interrupt on either an upward transition or a downward one, but not both, so I would imagine the implementation is the simplest that I've described: transitions on X1 trigger a cursor movement, and sampling of the other signal picks between a left or right movement.

It'll likely be transitions in one direction only (e.g. low to high, ignoring high to low) as although you could reprogram the 6522 on every transition I'll wager that they didn't out of a preference for lower interrupt processing time, and because the BBC Micro screen is already low resolution enough that input can be relatively low precision.

So the only thing you didn't spot in your investigation was the interrupts.

Answer 2

I don't know the specific details, but in general the mouse uses standard quadrature encoders so for each axis you get two data pins that output movement data. While several ways to decode the quadrature data for each edge to achieve maximum resolution, the hardware uses a simplest possible approach with the PIO chip. Basically a pulse on one pin can be used to detect movement and other pin can tell the direction. These pins are connected to a PIO chip which seems to have some strobe inputs, connected to detect movement, and the direction pins are connected to normal PIO inputs. Either the strobe pins triggers a flag in PIO status so CPU can poll for happened movement events and then read direction, or the PIO chip may even latch the direction pin on strobe event and perhaps signal movement with interrupts to CPU.