How did early computers handle mice?

Question

Early computer mice worked by sending a series of pulses; the more rapid the movement, the higher the frequency. How was this handled at the computer end?

At one level, it sounds easy: just run a loop, counting pulses. I did find a description of how this worked in a simpler system, the Apple II with its paddles: http://www.1000bit.it/support/manuali/apple/technotes/aiie/tn.aiie.06.html

The value of the Apple paddles (or joystick) is determined by a software timing loop reading a change of state in a timing circuit. The paddles consist of a variable resistor (from 0-150k ohms) which makes up part of the timing circuit. There is a routine in the monitor ROM, called PREAD, which counts the time until a state change occurs in the paddle circuit. This time is translated into a value between 0 and 255.

Okay, paddles are not the same as mice, but they are basically equivalent in this context.

But the games are not equivalent.

Wozniak designed the paddles for the Apple to be able to run Breakout. That's a simple game in which the game logic and animation only require a small, bounded amount of CPU time each frame. It's easy to see how this could be interleaved with calling PREAD.

Later machines used mice in the middle of much more involved games and other tasks. A game like SimCity or Lemmings is very demanding of CPU time in its own right. It's not at all clear to me how you could reasonably interleave that with spending a lot of CPU cycles in a software timing loop watching the mouse port for state changes. And if you 'go away and come back again', so to speak, you might miss one. A state change could trigger an interrupt, but then, if you move the mouse around rapidly, does that have the potential to slow or disrupt time-critical tasks?

How exactly did early computers like the Amiga, Atari ST and Macintosh handle the mouse while also carrying out demanding tasks?

Answer 1

How exactly did early computers like the Amiga, Atari ST and Macintosh handle the mouse while also carrying out demanding tasks?

In case of Amiga and Atari ST it was achieved by not low level handling the mouse:

The Atari ST had the 6301 based keyboard controller handling keyboard and mouse (or joystick). The mouse is a simple bus mouse type sending a pair of phase encoded signals (quadrature encoding) for X and Y. The controller counted these pulses to keep track of mouse movements.

The main CPU could read the added up values at any time (*1). Since all low level bookkeeping was handled by the 6301, no movement was lost, while keeping all timing quite relaxed.

The main CPU could focus at higher level mouse handling by applying scaling factors, turning relative movement into absolute positions and these again into update messages to any application handling mouse input.

The Amiga worked quite similarly, except that here the movement counters were not updated by software of a microcontroller, but kept in a pair of hardware counters within the chipset.

The first Mac (*2) used as well a phase encoded interface, but unlike the Amiga, Apple used standard interface devices, a 6522 VIA and a 8530 SCC, letting the main CPU do the counting during interrupt routines (*3). It shows that the task wasn't as demanding as one may assume (*4).

Whenever the mouse gets moved, the SCC will issue an interrupt, the 68k reads the SCC to determine if it's about X and/or Y and then read the VIA to see if it's one step up/left or down/right.

The mouse button again is not interrupt driven, but simply checked 60 times a second - with debouncing done by delaying any button press by one check.

So yes, for the Mac, moving the mouse results in a quick cascade of interrupts keeping the 68k quite busy(*5). Including a chance to lose movement when moving 'too' fast.

---

The mentioned Apple II had as well a mouse interface. THe mouse was quite like the Mac mouse (and all above), but the interface board included dedicated 6502 to do all counting, much like the Atari, but also higher level functions to simplify handling. After all, there was no driver on the Apple Ii side, so handling scaling and absolute mouse position had to be done in 'hardware'.

---

*1 - Well, it should happen not too slow, as these counters had only a limited range, thus overflowing rather soon. Good practice was to read them 60 times a second, for example during a screen interrupt.

*2 - That is the original 128k, the 512k and the Mac Plus.

*3 - The full description ready somewhat complicated, but in reality it comes down to a very fast interrupt handling as either.

*4 - While pushing a mouse around does seem quick, it's still "slow motion" from the viewpoint of a CPU.

*5 - Adding to the fact that the Mac wasn't really fast to begin with.

Answer 2

It's rather simple, the earliest mice were just outputting digital pulses from a quadrature encoder, and these pulses were not counted in software but hardware. How it basically works is that for each of the X and Y axes, there are two wires, which are basically digital sine and cosine waves of movement.

So nothing like the paddle interfaces, which did not have hardware counters, so the digital pulse length of waiting a capacitor to charge via the varying resistance was typically counted with software loops. That's how PC analogue joysticks also worked.

In real life, a simplified usage for the quadrature encoder wires is that one wire of an axis is used to detect when the mouse is moves on that axis, and when movement is detected, the other wire is used to determine in which direction the movement is on that axis. In practice a counter could be more sophisticated and use all edges from both wires of an axis to increase the counting resolution.

So for example in Amiga, there were two 8-bit counters in the chipset to track movement and direction of the two axes. PC bus mice worked similarly, the mouse adapter had the counters. The counter values can then be read at any rate the OS, mouse driver or game wants the info.

One advancement for later mice was to move the counters into the mouse. A typical ASIC or microcontroller can keep track of the counters and button presses in the mouse, and when there are changes, report them to the computer. For example typical mice had serial port connectivity using the "Microsoft" protocol at 1200 BPS using 7N2 framing. This meant that even if the mouse is constantly sending bytes, they are only sent at a rate of 120 bytes per second, and the protocol having three bytes per full movement packet, the computer receives at most 40 updates per second, which can easily be handled by a serial port driver.

Answer 3

Here's a concrete example of Amiga low-level mouse reading from a programmer's perspective:

As mentioned in other answers, the Amiga board handles counting X/Y mouse movement on its two joystick/mouse ports in hardware, not software. A cumulative 8-bit X and Y position is stored for each port and is updated as the quadrature pairs change for each axis due to the motion of the ball turning the wheels and interrupting the sensors. (This also means an Amiga interprets a rapidly spun joystick as mouse movement.)

There is a high-level event interface that handles the mouse (e.g. page 105 Amiga ROM Kernel Reference Manual - reading events, simulating events, etc.), but (I believe) most games would simply read the counters directly. You've picked a good pair of games for this question as Amiga Sim City works within Workbench and its OS wrappers and so probably responds to proper events, whereas Amiga Lemmings doesn't (I think?) and probably reads the counters directly.

The counters are exposed as a pair of 16-bit wide memory mapped registers, one for each port, at $DFF00A and $DFF00C. Each register has the X value in bits 0-7 and Y value in bits 8-15. As the mouse is moved, regardless of whatever other action the Amiga is taking, these values are updated and wrap in the range of 0-255. They're available at all times, no set-up required. To read the mouse 'position' on an Amiga, you do:

move.w $DFF00A,d0

Done. :)

It's up to the programmer to determine the movement deltas by reading and subtracting each axis' values every frame, and adjust the game's own mouse state appropriately, but there's no further hardware access needed. Mouse buttons work like joystick buttons and can be read from another register (though the right mouse button needs to be 'activated' first by setting another register as it's wired to a potentiometer input rather than a pull-up).

The relevant pages in the Amiga Hardware Manual are here and here.

Answer 4

If you want to look into early computers handling mice, you really need to take a peek at the Xerox Alto, developed in the early 1970s. It was the first computer designed with a mouse from the very beginning, and the first system to be built around the GUI. The mouse, as a device, had been invented earlier, and added onto existing equipment as a peripheral.

Wikipedia article

Other answers have outlined how the early mice transferred hand motion to a rolling ball, and frome there to two wheels with light passing holes, and then to IR sensors producing a quadrature signal. That signal then gets translated to an X Y number pair by simple hardware built for that purpose. You can read a separate article on the history of the mouse.

Mouse History

You can get some of Apple's history here

Answer 5

On MS-DOS, the system would be configured to generate an interrupt request (IRQ) whenever the mouse port had any input to report. In the case of a serial, rather than a bus, mouse, the bits of input would be combined into bytes by the serial port’s UART. The exact format would vary from mouse to mouse, but many used the same protocol as the Microsoft mouse from 1983.

You can read the open-source assembly code for a DOS mouse driver, CuteMouse, which supports many mice from the ’80s and ’90s.

Answer 6

Early computer mice worked by sending a series of pulses

At one level, it sounds easy: just run a loop, counting pulses. I did find a description of how this worked in a simpler system, the Apple II with its paddles [...]

The Apple paddles and joystick don't work by sending pulses (it's just variable resistors, no additional logic), and you cannot connect a mouse to those inputs. You needed an additional card for the Apple mouse (which was based on the Apple Lisa mouse) if you wanted to connect it to an Apple II.

This card worked by generating interrupts. Which means

It's not at all clear to me how you could reasonably interleave that with spending a lot of CPU cycles in a software timing loop watching the mouse port for state changes.

that you don't have to "watch state changes" (poll the mouse port), the CPU only spends the cycles during the interrupt when the mouse moves.

Answer 7

There was a mouse for the BBC Micro (and Acorn Electron) that was analogue use ten-turn potentiometers. It was very bad but, unusually for the time, it had a wheel (horizontal for use by thumb). The BBC Micro had a four-channel Analogue to Digital Converter (ADC) because the BBC wanted the machine to be a more general introduction to computers.

More usual on the BBC Micro was the AMX quadrature mouse which connected to a 6522 VIA through the User port.

The Acorn Archimedes used a quadrature mouse connected through the keyboard's 8051 microcontroller. So the mouse convenient plugged into the keyboard not the main box (except later all-in-one models where the socket was awkwardly under the machine).

Answer 8

Commodore 64/128, MSX and Roland treated its mouse as a joystick. In fact these mouses are connected in the DE9 joystick port of those systems.

Answer 9

They handled the mouse by copying pixels to a backing store before drawing the cursor, then writing back modified pixels when the pointer was moved. Trying to handle, not always very well, when the underlying image changed. To be responsive, the mouse was handled through interruptions and high priority tasks in the OS.

Some computers could use a sprite (Amiga for example) or even had a custom chip just for overlaying a cursor (some VAX), before accelerated video controllers on PCs, Macs, could offer a proper hardware cursor.