Sorry, but I cannot totally verify the below. It's my best SWAG.
ps2mouse.zip IBM PS/2 Mouse Program Diskette Ver 1.00
Mouse Connector Pinouts
Mouse Connector Signals
Using Serial Mice on a PS/2?
IBM Mouse Types
PS/2 to Serial to PS/2 (Dumb KVM switches)
PS/2 Mouse Maker
Serial, Bus, and PS/2 Mice (PC Magazine)
Location of Mouse (pointing device) connector.
The mouse port is always the PS/2 port FARTHEST from the power supply.
The PS/2 mouse port is IRQ 12 and I/O Port Addresses 60h and 64h.
Bus Mouse Problem!
A bus mouse uses a mini-DIN connector just like the PS/2
mouse, although they are totally incompatible. You can damage your motherboard
by plugging a bus mouse into it.
Note: Microsoft calls it's
bus mouse an Inport mouse Be warned!
PS/2 Appears to Hang When Exiting Windows 3.1x
Some IBM PS/2 models may appear to stop responding (hang)
when you exit Windows version 3.1. The computer eventually restarts; however,
it remains frozen for up to a minute while the mouse port is reinitialized.
This problem is most severe on PS/2 models 56 and 57.
It also occurs on models 50z, 55sx, 70, 80, 90, and 95.
The problem can be corrected by adding the following line to the [386Enh]
section of SYSTEM.INI:
This prevents Windows from attempting to reinitialize the PS/2-style
mouse port prior to exiting to MS-DOS. This may cause problems when you
run some mouse-aware, MS-DOS-based applications after exiting Windows.
Mouse Connector Pinout
The keyboard connector is a 6-pin miniature DIN connectors.
The signals and voltages are the same for both connectors.
+ 5 V dc
The keyboard and auxiliary device signals are driven by open-collector
drivers pulled to 5Vdc through a pull-up resistor.
Sink current Max
Hi-level output V Min
5.0 Vdc minus pull-up
Low-level Output v Max
High-level input v Min
Low-level input v Max
Serial Mouse Conversion?
The "Serial Mouse" uses a RS-232 style interface with
-5 to -12 VDC as logical "1" and +5 to +12 VDC as logical "0". The PS/2
mouse interface is a TTL-style interface, which uses 0 - +2 VDC as logical
"0" and +3 - +5 VDC as logical "1".
In addition - and to make things worser - the RS-232 is
an asynchronous interface, the PS/2 interface is a synchronous, where the
data is sent along with a clock signal. It uses a simplified 4-wires serial
interface with +5VDC (for the transceiver), GND, keyboard / mouse clock
and keyboard / mouse data. The data and clock line can be used from the
keyboard / mouse controller and the attached device as well following a
particular handshake, which defines which is the active "sender" and which
is the "receiver". So: it is not *that* easy conversing serial mouse to
PS/2 and vice versa.
The "dual mode" mice have an automatic logic detection
and sort of adaptive interface electronic, which detects whether the mouse
is attached to a serial port or a PS/2 port and set the output drivers
As you can see from the above: it is not enough only *physically*
changing the plugs.
PS/2 Mouse Versions
From Fred Mau:
Best as I can tell, IBM had five distinct species of Rattus
Armonkus in the PS/2 world: (Not to mention all the clones).
- The original ugly wedge-shaped PS/2 mouse
- Early oval-shaped mouse. White body and white buttons.
- Later oval-shaped mouse. White body and brownish buttons.
- A smaller black mouse used with the CL57, N51, TP 700 and
720 laptops. Lower voltage than a regular mouse, not interchangeable.
- The current IBM mouse, OEM'ed by Logitech. A more ergonomic
Best as I can tell, all the PS/2 mice (except the minnie
mouse for early thinkpads) are interchangeable, with one notable exception:
If you have an 8516 Touchscreen monitor, the touchscreen cable plugs into
the mouse port and the mouse plugs into the monitor, but it will ONLY work
with the original ugly mouse or the early oval mouse with white buttons.
work with the later oval mouse with brown buttons or anything newer.
I have no idea why, but apparently something changed in the mice.
It's something to keep in mind if you ever happen across an 8516.
From Jim Shorney:
Side note: I seem to have an oval variation you didn't
mention: white top, white buttons, brownish bottom, 33G5430/33G5410/FRU33G5420.
BTW, have you seen the IBM memo on mouse ball replacement?
Ed. I think he means THIS
From Carroll Bloyd
And there's the track-ball/mouse combination (P/N 1397040)
sold for use with the L40 SX laptop. Big ugly thing--the mouse side
of the device looks like a larger version of the original PS/2 mouse.
And, you might want to add the three-button mouse OEM'ed
from Logitech and supplied with the 9595-PQx models. They seem to
be rare--I've only seen a few--I wonder if they were used on the RS6000
From David Doerr:
There was, indeed, a three-button mouse from Logitech
used on the RS6000. I have several, but they don't seem to work on
From Aron Eisenpress:
I'd like to point out one substantive change in the IBM
PS/2 mice, which happened around the time of the two-tone-topped ones:
the resolution increased from 200dpi to 400dpi (and noticeable if you swap
mice around as the speed of the cursor will change!)...
PS/2 mouse to serial cable and back to PS/2 port
From Tim Clarke:
PS/2 mouse to serial cable and back to PS/2 port Or Dumb KVM switches
I think your problem is in the PS/2->Serial and
Serial->PS/2 adapters. You *must* ensure that they *are* as described and
*not* 2 x PS/2->Serial or 2 x Serial->PS/2 used back-to-back. Otherwise,
the pinouts will not get 'passed' correctly.
The thing to be aware of is that, with a manual
switch, the keyboard and mouse 'lose' power during a switch and 'reinitialise'
when the switch closure to the 'to' computer is completed (i.e. 5V power
returns). Also, you can get spurious bytes sent during the transitions
(plaintive beeps from the BIOS).
As I said, DOS (due to BIOS) and the OS/2
(due to it's drivers) recover most of the time (OS/2 seems to recover the
mouse best if you use Desktop "Lockup" before switching away). Clones (AT-class
BIOS) and Windows O/Ses are generally horrible because they haven't implemented
the equivalent functionality and cause you to 'lose' the mouse and, sometimes
keyboard function (except for manic beeping for keypresses) after a 'switch-away,
switch-back' sequence. It's not so much the BIOS in Clones, that seems
to be comaptible. It's the usual crap programming by the MicroShaft "gurus".
It may be down to the O/S drivers. E.g. All
PS/2 BIOS/ABIOS seem to handle an 'unexpected keyboard reconnection' (i.e.
0xFF bytes and BAT-completion message) and reinitialise the 'Scan Code
Set' and 'Shift State' indicators. Mouse stuff seems to be much more sensitive
and OS/2 is the only server environment that I *know* can (usually) handle
this. Netware 3.1x and 4.1x don't. Windows and WfWg don't. I doubt whether
W9x does. NT *might* but I don't know. DOS is happy so long as you're at
the command prompt with no mouse-driven s/w actively using the mouse.
Current Mouse Maker
Unicomp lists the IBM Two Button mouse. It has the brown
buttons and the white body. I have a few of this specific model. Nice button
switches, tracks well. At $7 it's a damn good bargain. Mine has a long
cord (nice for use with 80/85/95 systems!)
IBM Two Button mouse Regular $15 Sale $7
Serial, Bus, and PS/2 Mice
PC Magazine May 28 1991 v10 n10 p413(4)
Author: Prosise, Jeff
Full Text COPYRIGHT Ziff-Davis Publishing Co. 1991
Thanks for the formatting advice, Rich!
How do they run?
Would you describe how the three common types of mice work (serial,
bus, and PS/2 mouse port), how the mouse driver communicates with the mouse,
and how programs in turn talk to the mouse driver?
Jacek Hejnar, St. Hubert, Quebec
At the software level, bus mice, serial mice, and PS/2 mice are all
the same. The mouse driver provides a common interface so that an application
program can communicate with a mouse using identical sets of function callsregardless
of its type.
At the hardware level, however, these mouse types are fundamentally
different. The serial mouse works just like a communications device:
It sends data to the serial port of your choice each time a mouse event
takes place. (A mouse event is when a button is pressed or released
or the mouse is moved.) A microprocessor inside the mouse transmits a packet
of data any time it detects a change in state.
Typically, the mouse driver programs the serial port to interrupt the
CPU when a byte of data is received at the port. It does this in
the same way a communications program such as ProComm would.
If the mouse is stationary and no buttons are being activated, no CPU
time is tied up tracking mouse actions.
Many serial mice use the 3-byte packet format standardized by Microsoft
to transmit information about mouse position and the state of the buttons
to the CPU. Figure I shows the format of the packet. Since
the Microsoft Serial Mouse transmits data at 1,200 bits per second using
I stop bit, 7 data bits, and no parity, bit 7 (the leftmost bit) in each
byte isn't used. Bit 6 is a clock bit that the mouse driver uses
to stay in sync with the mouse. In the first byte in the packet,
it's set to 1; in the second and third bytes, it's set to 0. Bits
4 and 5 indicate the current up/down states of the left and right mouse
buttons. A 0 indicates that the corresponding button is pressed,
while a I indicates that it's not. The remaining bits in the data
packet are combined to form two 8-bit numbers indicating the number of
mickeys the mouse has moved in the x (horizontal) and y (vertical) directions
since the last report. A mickey is the mouse unit of distance, equal
to approximately 0.005 inch. By recording mickeys, the mouse driver
can track the location of the mouse at all times.
Microsoft Serial Mouse Data Packet Format
Each time a serial mouse is moved, it transmits a packet of data containing
information about the mouse position and the state of the buttons to the
CPU. This figure illustrates the 3-byte data packet format that is used
by the Microsoft Serial Mouse and many other Microsoft-compatible Serial
0 = pressed
1 = not pressed
0 = pressed
1 = not pressed
||8-bit X-movement indicator (number of mickeys moved
in the horizontal direction since the last data transmission)
||8-bit Y-movement indicator (number of mickeys moved
in the vertical direction since the last data transmission)
The mouse driver can determine the direction of the movement-up or down,
right or left-from the sign of the mickey counts transmitted by the mouse,
which are encoded in two's complement form (a common method for representing
signed integers on computers). Using this representation, an 8-bit
value can store any number from -128 to 127, inclusive. Thus,
the mouse can move up to 127 units in either direction (about 0.62 inch)
in the time it takes a,packet to be transmitted (about 20 milliseconds
at 1,200 bps) without missing a beat. That provides enough latitude
for you to move the mouse across the table rather quickly, without losing
any information in the process. Some mice use higher data rates to
increase resolution. Logitech's Series 9 Mouse, for example, operates
at 2,400 bps, doubling the range that the mouse may travel between data
Not all serial mice use Microsoft's 3-byte packet format. The
three-button Mouse Systems Mouse, for example, transmits data in 5-byte
packets. The added bits are used to transmit information about the third
button (something that the Microsoft format does not support) and information
about the mouse's current and last positions, which, among other things,
can be used to determine mouse velocity.
How does the serial mouse get its power? It's not battery operated,
nor does it have to be plugged into an electrical outlet. Instead,
it draws power directly from the serial port through the RTS (request to
send) line. The Microsoft Serial Mouse uses five RS-232 lines: TD
(transmit data), RD (read data), DTR (data terminal ready), RTS ready
to send), and SG (signal ground). TD is used to transmit packets
of data. The driver asserts RTS when it is activated, to make sure
power is available to the mouse, and asserts DTR as a signal that it's
installed and ready to go. In current Microsoft Serial Mouse implementations,
RD is unused.
The bus mouse interfacing scheme takes an entirely different approach
to linking a mouse to a PC. Unlike the serial mouse, the bus mouse
does not contain its own microprocessor. Instead, logic on the bus
interface card is responsible for monitoring the mouse and notifying the
mouse driver when the mouse is moved or a button is activated. In
the most common implementation, the card is programmed to poll the mouse
at regular intervals (typically every 1/30 to 1/60 second) and interrupt
the CPU so that the mouse driver can read the current mouse status from
registers on the card. Why these interrupt rates? Because 30 to 60
Hz roughly corresponds to the refresh rates of most displays. When
the mouse pointer is being moved across the screen, there's usually no
need to poll the mouse more frequently, because the screen can't be updated
fast enough to show what's happening. difficult to paint a picture
of how a " typical " bus mouse operates. Versions of the Microsoft
Bus Mouse sold since 1986, for example, contain a custom chip called an
InPort on the bus interface card. This chip tracks mouse events and-like
the microprocessor in the serial mouse-interrupts the CPU only when the
mouse is moved or a mouse button is pressed or released. This way,
valuable CPU time isn't wasted reading registers on the interface card
when the mouse is idle. And thanks to the InPort chip, the Microsoft Bus
Mouse can be programmed for 30-, 50-, 100-, or 200-Hz operation.
It's also possible to have the InPort chip interrupt the CPU at regular
intervals regardless of whether there's anything new to report, or to forgo
interrupts altogether and allow software to drive the mouse strictly by
polling it. Using this scheme, the mouse driver (or a program driving
the mouse directly) can track mouse position more precisely than programmed
30-to-200-Hz interrupt rates allow. Alternatively, it can tap into the
vertical sync pulse generated by the video adapter each time a screen refresh
is completed and take time out to read the mouse status during the vertical
A bus mouse does not send packets of data the way the serial mouse does.
Instead, status is read directly from lines connecting the mouse to the
bus interface card. For example, the Microsoft Bus Mouse uses the
nine-pin Hosiden circular connector shown in Figure 2. Of the nine
pins, three-SWI, SW2, and SW3-reflect the state of up to three mouse buttons
in real time. XA, XB, YA, and YB carry quadrature signals that communicate
the amount and direction of motion in the x and y directions to counter
registers inside the InPort chip. In quadrature encoding, two lines
are provided to track motion in a given direction. A pulse on one
of the lines-for example, XA-indicates that the mouse has been moved.
A pulse on XB, which arrives slightly out of phase with the pulse on XA,
reveals the direction of the movement. If XA leads, then movement
is positive; if the pulse on XB comes first, movement is in the negative
direction. Values read from the InPort's counter registers are two's
complement 8-bit numbers, so they, like the values transmitted by the serial
mouse, may range from -128 to 127.
The remaining two pins on the connector serve equally important functions.
The bus mouse draws its power from the +5V pin, while the other pin goes
Microsoft Bus Mouse Pinout
The Microsoft Bus Mouse uses a nine-pin circular connector to interface
with the bus interface card. SW1, SW2 and SW3 are used to sense the state
of the mouse buttons. XA, XB, YA and YB carry quadrature signals indicating
mouse movement and direction. The mouse draws power from the +5V
pin, while the remaining pin goes to ground.
The PS/2 mouse is similar to the serial mouse in many respects.
This mouse contains its own microprocessor that transmits clocked serial
data to the keyboard controller inside the PS/2, just as the PS/2 keyboard
does. The controller decodes the information coming in and the PS/2
BIOS makes it available to the mouse driver. Through the BIOS programming
interface, the mouse sampling rate may be set to frequencies ranging from
10 to 200 Hz. Typically, the mouse driver will register itself with the
BIOS, and the BIOS will activate a handler inside the driver each time
a mouse-related event occurs.
One peculiarity of the PS/2 mouse is that the packet format it employs
does not include a clock bit as the Microsoft packet does. Furthermore,
because the same system board controller is used to decode data coming
from the mouse and the keyboard simultaneously, programs that use both
the mouse and keyboard on the PS/2 sometimes experience data-overman conditions
that cause the mouse driver to lose synchronicity with the mouse.
If there were a clock bit, timing could be reestablished and the overrun
condition could be defeated. Without the clock bit, application programmers
have been forced to resort to several ad hoc means of maintaining the integrity
information flowing to the mouse driver. Some of these methods
are more effective than others. If your mouse goes haywire or simply
stops working when you run certain application programs on a PS/2 (especially
older programs), it's probably for this reason.
It's no accident that you can replace the end adapter on a Microsoft
Serial Mouse and plug it into the mouse port of a PS/2. The PS/2
mouse port has six pins, one of which carries power to the mouse (see figure
2b). The Microsoft Serial Mouse looks at this line to determine what
type of port it's connected to and adjusts the format of the data it sends
out accordingly. If the line is asserted (carrying voltage), then
the mouse knows it's attached to a PS/2 port. If the line is not
asserted, the mouse concludes that it must be attached to a serial port.
Mouse Programming Interface
Fortunately,programs don't have to interface with the mouse at the packet
level; that's what mouse drivers are for. The mouse driver is the
program you install before running an application that uses the mouse.
The Microsoft mouse driver is called MOUSE.SYS or MOUSE.COM. (The only
difference between the two is that MOUSE.SYS is installed with a DEVICE
statement in CONFIG.SYS, while MOUSE.COM is installed from the command
line or your AUTOEXEC.BAT file.) Microsoft and Nbcrosoft-compatible mouse
drivers provide a set of 35 high-level function calls that applications
can use to communicate with the mouse.
Mouse Driver Function Calls
Microsoft and Microsoft-compatible mouse drivers provide 35 different
function calls (functions 17 & 18 are not assigned) that a program
can use to communicate with the mouse. Collectively, these function
calls make up the mouse programming interface.
|0||Mouse Reset and Status|
|3||Get Button Status and Mouse Position|
|4||Set Mouse Cursor Position|
|5||Get Button press Information|
|6||Get Button Release Information|
|7||Set Minimum and Maximum Horizontal Cursor Position|
|8||Set Minimum and Maximum Vertical Cursor Position|
|9||Set Graphics Cursor Block|
|10||Set Text Cursor|
|11||Read Mouse Motion Counters|
|12||Set Interrupt Subroutine Call Mask and Address|
|13||Light Pen Emulation Mode On|
|14||Light Pen Emulation Mode Off|
|15||Set Mickey/Pixel Ratio|
|19||Set Double Speed Threshold|
|20||Swap Interrupt Subroutines|
|21||Get Mouse Driver State Storage Requirements|
|22||Save Mouse Driver State|
|23||Restore Mouse Driver State|
|24||Set Alternate Subroutine Call Mask and Address|
|25||Get User Alternate Interrupt Address|
|26||Set Mouse Sensitivity|
|27||Get Mouse Sensitivity|
|28||Set Mouse Interrupt Rate|
|29||Set CRT Page Number|
|30||Get CRT Page Number|
|31||Disable Mouse Driver|
|32||Enable Mouse Driver|
|34||Set Language for Messages|
|35||Get Language Number|
|36||Get Driver Version, Mouse Type and IRQ Number|
For example, if a program wants to determine whether a mouse button
is currently held down, all it has to do is make a call to function number
5, Get Button Press Information. The driver, which fields the interrupt
generated when a mouse button is pressed or released, keeps track of the
state of the buttons. In response to the program's request, the driver
returns an integer whose value reflects the current button status.
If the left button is depressed, bit 0 is set to 1; if the right button
is depressed, bit 1 is set to 1. A value of 0 in either bit indicates
that the corresponding button is not depressed.
Mouse driver functions are accessed through interrupt 33h. The
following code sequence portrays what a typical call to the mouse driver
looks like in assembly language:
In general, function codes are passed in register AX, and other parameters
in BX, CX, and DX. This particular sequence calls function 5 to retrieve
the status of the right mouse button (BX=l for the right button, BX=O for
the left). On return, bit I of the BX register is tested and a branch
is made if it's set to 0, indicating the button is not currently depressed.
We don't have the space here to explore each of the function calls in
detail. For more information, refer to the Microsoft Mouse Programmer's
Reference (1989, Microsoft Press), or to PC Magazine's July 21, 1987, Lab
Notes column ("Mouse Software: See How They Run," page 41 1). However,
there is one function that is so useful and so widely used by programmers
that a discussion of the mouse programming interface couldn't be considered
complete without it: function 12, Set Interrupt Subroutine Call Mask and
Function 12 lets a program instruct the mouse driver to interrupt it
asynchronously when the mouse is moved or a button is pressed or released.
The program passes the mouse driver two objects: a call mask and a subroutine
address. The call mask acts as an event filter. If the program
isn't interested in mouse movements or button releases, the call mask can
be set up so that the driver interrupts the program only when a button
press occurs. The subroutine address is a 32-bit pointer to the subroutine
that the program will use to process calls from the mouse driver.
By registering itself with the mouse driver this way, a program doesn't
have to constantly poll the mouse driver to see what's going on.
When something happens, the program is automatically notified and given
a chance to act on the event.