5

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.

9

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.

| improve this answer | |
  • 3
  • 1
    @JdeBP thanks, I've worked it into my answer! – Tommy Jan 13 at 2:59
  • +1 Brill thank you @Tommy - +1 upvote and accepted answer. And thanks to Justme and JdePD for the great link. Just think if we had a time machine and knew all of this, how different (even better) the BBC micro might have been if more devs of the time knew this stuff. It did pretty well, but we can wonder, what if. Thank you again! – therobyouknow Jan 13 at 11:06
  • +1 upvote @JdeBP for the great link! That's an excellent site too in general - not heard of that. – therobyouknow Jan 13 at 11:07
4

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.

| improve this answer | |
  • +1 thanks! On that basis, looks like all those years ago, I had only found one of the pin values. I'll see if anyone else wants to contribute, but so far - thank you. – therobyouknow Jan 12 at 12:10
  • 1
    This is basically correct but the description of the two pins is not quite right. If you move the mouse in one direction the two pins output 00, 01, 11, 10, and repeat. In the other direction 00, 10, 11, 01, etc. So both pins show "a movement" and the pattern of adjacent pairs of shows the direction. If you only use one pin to delect "movement" you will halve the resolution of the mouse. – alephzero Jan 12 at 14:47
  • 1
    Like I said, mouse outputs quadrature just like you said, but that's how the hardware uses the pins, only rising edge of strobe pin is used to latch in the data pins (the direction) and generating an interrupt. Even today a simplest microcontroller without a specfic quadrature decoder peripheral (like Arduino) could handle it like this with background interrupts. – Justme Jan 12 at 16:17
  • If it’s possible, I’d be curious to know how this scheme is wired up for the BBC’s user port VIA. Presumably interrupts on one quadrature channel per axis, and the other exposed for polling? This guess is based on the 6522’s ability, I’m aware it’d provide less precise motion than if you had interrupts on all four quadrature inputs, though it would provide the same precision as the original Macintosh. – Tommy Jan 12 at 17:49
  • Yes the schematics are available on the net. One pin of each axis go to a PIO strobe pin, so I believe you can get interrupts from both axes. – Justme Jan 12 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.