19

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?

9
  • 2
    @Raffzahn I specified three machines, all of which existed at the same time, used the same CPU at approximately the same clock speed, ran generally similar operating systems and many of the same games, and I strongly suspect used very similar mouse interface technologies.
    – rwallace
    Nov 12 at 0:34
  • 4
    Nop. They didn't. While Atari and Amiga were similar, the Mac used complete different interfaces and protocols - in fact, the various Mac models of that time frame used three different mouse interfaces over time. Also, none of them is related to paddles or alike. Also, if it's exactly about this three machines, then it would be helpful to say so at the begining. Or just ask for one machine first and go on from there. Keep it simple, enable a clear straight answer. One that would also help others later one.
    – Raffzahn
    Nov 12 at 0:38
  • 9
    "How did early computers handle mice?" They didn't. The mouse wasn't invented until about 15 years after the first stored-program electronic computers. ;-) Nov 12 at 3:38
  • 5
    "How did early computers handle mice"? Mousetraps.
    – Sneftel
    Nov 12 at 11:21
  • 2
    @another-dave Trackballs, OTOH, were invented in 1946 and in use as early as 1952. Nov 13 at 9:09
32

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

This was achieved by simply not low level handling the mouse.

The Atari ST for example had a 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 simply 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, while letting the main CPU do the counting during interrupt routines (*3).

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, moving the mouse results in a cascade of interrupts keeping the 68k quite busy(*4). This includes 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 - Adding to the fact that the Mac wasn't really fast to begin with.

12
  • 7
    Isn't this supposed to be an answer, not a question? You're starting off the post with a question about the very subject they tried to ask about; they're not going to know the answer, since it's exactly the thing they're asking about. If you know what the answer is, just tell it. If you don't, then don't post an answer.
    – ilkkachu
    Nov 12 at 8:58
  • 13
    Taking it as a rhetoric question, it comes off as the passive-aggressive kind at best. It makes the post sound like you think the poster should already know the answer. But sure, that's a valid stylistic choice. I'm not sure what my native language has to do with anything (or yours, which I also don't know). The difference between a question and a statement is similar in at least the few languages I know.
    – ilkkachu
    Nov 12 at 10:47
  • 10
    When commenting on someone’s language skill it’s wise not to write your as you’re Nov 12 at 10:53
  • 5
    @SebastiaanvandenBroek Muphry's Law
    – Muzer
    Nov 12 at 12:00
  • 6
    As a native English speaker raised and living in English-speaking spaces, the first line of this question does not come across as an epistemic rhetorical question because it is simply not a question. It is a factual statement (By simply not low level handling the mouse) followed by a question mark. To most native English speakers this is almost exclusively a passive-aggressive construct, as though to question the very nature of the question being answered, or to imply the response of "why would you even ask that?".
    – Mayube
    Nov 12 at 20:39
14

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.

1
  • 1
    Petty on ‘read at any rate’: the Amiga’s display being larger than 256 pixels across that isn’t quite true. Actually, in emulation, with a trackpad calibrated for navigating a 4k display I find it pretty easy to wrap the counters more quickly than Workbench reads them. It’s really something the emulator should deal with, being a way in which my trackpad is dissimilar to a mouse, but there it is.
    – Tommy
    Nov 12 at 9:08
8

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.

7

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

4

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.

2
  • 1
    @Justme The second-to-last paragraph of the question asks how games such as SimCity could poll “later mice” without it taking excessive amounts of CPU time.
    – Davislor
    Nov 12 at 0:53
  • 4
    I wrote some mouse SW for IBM PC ~1985, graphics editor/drawing. I wanted to move mouse to a point, click any of several dozen keys, immediately to a second point, and so on. As quickly as possible, possibly quicker than the screen update. I.e. combined mouse and keyboard type-ahead. Had to be interrupt driven. I wished for HW buffering of mouse and keyboard events with timestamps if separate buffers to for correct interleaving. Even now in 2021 proper interleaving of independent devices is a challenge on MS Windows and Linux. I am told MIDI is better.
    – Krazy Glew
    Nov 12 at 21:59
4

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.

1
  • It would have been practical to use a 1970s-era microcontroller to interface a quadrature encoder to the Apple II joystick port in such a way as to be compatible with software written for joysticks, but also allow mouse movements to be precisely tracked by software that could poll at whatever interval was convenient, without requiring any interrupts. From a marketing perspective, having a dedicated mouse card may have been good, but sticking a microcontroller in a mouse could have been cheaper.
    – supercat
    Nov 24 at 19:12

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.