• Please review our updated Terms and Rules here

Windows 3.x and the Tandy 1000 "PS/2" Mouse Port

Cloudschatze

Veteran Member
Joined
Apr 17, 2007
Messages
691
Location
Western United States
The Tandy 1000 RL, RLX, and TL/3 systems feature a "PS/2" mouse port that, while protocol-compatible, isn't accessed in standard PS/2 fashion. Given a lack of documentation, it's also something of a mystery.

Support-wise, either CuteMouse or a specific version of Logitech's mouse driver can be used in DOS. Regrettably, Windows 3.0 and 3.1 support for this mouse port is entirely lacking, generally resulting in the use of a serial port/mouse combination instead. Where I'd like to put the single serial port of the RL and RLX to greater use, this is problematic.

Question is, what needs to be modified in Windows' standard mouse driver to provide compatibility?

As concerns the Tandy implementation, and per the RLX service manual:

  • IRQ 1 is shared by both the keyboard and mouse.
  • Port 0060h is used for keyboard I/O, and port 0067h is used for mouse I/O.

Where the keyboard/mouse IRQ sharing isn't unheard of, and may even be accounted for in Windows' MOUSE.DRV besides, is the non-standard I/O port the key?
 
Do those Tandy 1000s support the PS/2 INT 15h mouse BIOS calls or the INT 11h mouse present bit? If not, the Windows 3.x PS/2 mouse driver won't even get a chance to look for the PS/2 port on the Tandys.
 
So, INT 11h appears to be supported, with bit 2 appropriately reflecting the "Installed / Not Installed" state of the mouse port, as set in the system setup.

I'm not sure how to directly check for INT 15h, C2h support. CuteMouse purportedly uses it though, and since that driver works, I imagine the C2h support must also be present to some extent.
 
It was the first thing that jumped out at me looking at the PS2.ASM file within the DDK's mouse driver. I didn't see any code relying on port address and the code referencing IRQs seems to be commented out.

The Tandy specific part of the driver is a very long rant about the 2500 which while entertaining does not address the issues for this topic.
 
I looked into this little annoyance again the other day, and discovered that the primary issue lies with the system detection portion of the affected PS/2 drivers. As such, I've come-up with a couple of hacks (myself being a talentless hack):


Windows 3.0 with the Tandy 1000 RL or TL/3:
  • Configure Windows to use the "Microsoft, or IBM PS/2" mouse driver (MOUSE.DRV)
  • Hex-edit MOUSE.DRV, search-for and replace "3C FA" with "3C FF"

Windows 3.1 with the Tandy 1000 RLX:
  • Configure Windows to use the "Logitech" mouse driver (LMOUSE.DRV)
  • Hex-edit LMOUSE.DRV, search-for and replace "3C FA" with "3C FF"

I'm basically telling the driver to use the same detection and operational routine for the relevant Tandy system (machine ID: FF) that it would for an IBM PS/2 Model 25/30 (machine ID: FA). This modification works great, as applies to the listed combinations. Other combinations partially work, in conjunction with a change to the interrupt vector, but consequently introduce other non-desirable behaviors. Let's never speak of them.

So, yeah, a one-byte change resolves a nearly 30-year-old problem. Hooray.
 
Last edited:
Do those Tandy 1000s support the PS/2 INT 15h mouse BIOS calls or the INT 11h mouse present bit? If not, the Windows 3.x PS/2 mouse driver won't even get a chance to look for the PS/2 port on the Tandys.

I have a 1000SX and as you probably know, there are no 'built in' serial ports. I've always used a Logitech bus mouse which eats up one of the 5 precious slots. I don't believe I've ever encountered a 8-bit PS/2 mouse card, but I'd be willing to give it go if I had one such animal.
 
Thanks for the fixes. Another related problem I encountered was that I couldn't get the keyboard to work in Windows 3.0 on my 1000RLX, with any of the drivers it provides: 101-key Enhanced, 84-key AT, AT compatible, or 83-key PC/XT. Regardless of which one I choose, Windows 3.0 doesn't respond to my keypresses, although the BIOS still is, because eventually when the keyboard buffer fills up, it starts beeping at me.

Windows 3.1 works fine with the standard 101-key driver on the 1000RLX, but it's painfully slow.
 
Thanks for the fixes. Another related problem I encountered was that I couldn't get the keyboard to work in Windows 3.0 on my 1000RLX, with any of the drivers it provides: 101-key Enhanced, 84-key AT, AT compatible, or 83-key PC/XT. Regardless of which one I choose, Windows 3.0 doesn't respond to my keypresses, although the BIOS still is, because eventually when the keyboard buffer fills up, it starts beeping at me.
I don't run generally Windows 3.0 on the RLX, but I am familiar with that particular keyboard behavior. It seems to have something to do with running in Standard mode, as the keyboard operates normally in Real mode. I'll have to look into this.

Windows 3.1 works fine with the standard 101-key driver on the 1000RLX, but it's painfully slow.
With some tweaks, I actually find Windows 3.1 to be faster/more-responsive than Windows 3.0.
 
Well, I was sort-of hoping that upgrading Windows 3.00 to 3.00a would resolve the keyboard issue, as it includes some relevant-sounding fixes to Standard mode operation. Alas, no. Still looking...

That said, about the only advantage I can think of to a Windows 3.0 instance over a comparable 3.1 setup on the RLX is a memory savings of ~50KB. That savings comes with a considerable loss of functionality though, including the ability to use the Tandy DAC for wave playback within Windows, and that's just sad. ;)

 
What other tweaks did you use on 3.1?
I'd have to put together some sort of complete list, or just post the relevant configuration files. Here are a couple of of immediate recommendations though:

  • Disable TrueType fonts. (Control Panel -> Fonts -> TrueType)
  • Add "FasterModeSwitch=1" to the [standard] section of the SYSTEM.INI file. This must be done if you want to use the Tandy DAC driver.
  • Configure the system for zero wait-state operation. I wrote a little COM utility that can be called from AUTOEXEC.BAT to do this. (View attachment RLX_0WS.zip)
 
Last edited:
Back
Top