Thanks. I'm not sure if this helps any, but running pci.exe 1060:886a 40, returns

100:12.0 - 40 is 05

and running pci.exe 1060:886a 45, returns

100:12.0 - 45 is 04

05h = 00000101 binary. I'm not sure which enabler bit would be 40.10.

04h = 00000100 binary. I'm not sure which enabler bit would be 45.01.

Whatever the case, pci.exe returns the same value when I run the PS/2 modded WINBIOS vs. the original un-modded WINBIOS. So the WINBIOS may have some enabler bits set incorrectly.

You could try pci 1060:886a 40=15 45=05 and then load ps2suppc to see if this really is the issue.

Thanks again.

I'm not sure if PS2SUPPC was designed to work with WINBIOSes. Nonetheless...

I added pci.exe 1060:886a 40=15 45=05 and ps2suppc.com to the autoexec.bat file on a bootable floppy disk, then:
ps2suppc.com
1)
When using the original 5/6/96 WINBIOS, ps2suppc states that a PS/2 mouse was found and to run a mouse driver. I separately tried, both, mouse.exe from Microsoft, and Cute Mouse v1.9. They both load their drivers without complaint. I then run Microsoft's DOS mouse test GUI, test.exe. The GUI loads. The mouse pointer will move for a few pixels, then the system hangs up hard. Feels like some progress was made.

Curiously, if I just run pci.exe 1060:886a 40=15 45=05 without adding ps2suppc.com to the autoexec.bat file, I cannot type anything at the C:\ prompt, that is, keyboard key presses do nothing. But if I load PS2SUPPC in autoexec.bat, I can still use the keyboard, whether or not I've loaded a mouse driver (e.g. CTMOUSE).

2)
When using the PS/2 modified 5/9/96 WINBIOS, ps2suppc states that a PS/2 mouse was not found and aborts. System hung up. Perhaps BCPW511's attempt to add mouse support is doing more harm than good?

The pointer moving a couple pixels before a hard lock is a classic symptom of IRQ12 not being connected properly, at least with the traditional interposer based mods. I wonder if it's related?

since hardware works with other bios the problem might be WINBIOS not initializing IVT offset 74 irq12 to a generic int ack iret routine. Enabling IRQ12 and actually triggering one before handler is ready will crash the computer.

can look it up using debug.exe. IVT offset 74 irq12 handler will be at 0x74 times 4 = 0x1D0 offset, 0x1D2 segment

1d 0000:01D0 L 4

then take the result and inverse it pair wise (little endian) so

10000:01D0  dd cc bb aa

means handler lives at aabb:ccdd, to disassemble do

1u aabb:ccdd

I can get the HOT-433 v4 out later and try and diff the PCI config space with a PS/2 mouse connected or unconnected.

rasz_pl wrote on 2026-08-25, 18:08:

since hardware works with other bios the problem might be WINBIOS not initializing IVT offset 74 irq12 to a generic int ack iret […]
Show full quote

since hardware works with other bios the problem might be WINBIOS not initializing IVT offset 74 irq12 to a generic int ack iret routine. Enabling IRQ12 and actually triggering one before handler is ready will crash the computer.

can look it up using debug.exe. IVT offset 74 irq12 handler will be at 0x74 times 4 = 0x1D0 offset, 0x1D2 segment

Copy code to clipboard

1d 0000:01D0 L 4

then take the result and inverse it pair wise (little endian) so

Copy code to clipboard

10000:01D0  dd cc bb aa

means handler lives at aabb:ccdd, to disassemble do

Copy code to clipboard

1u aabb:ccdd

To use debug, I placed the files on the IDE drive. I am using the original non-PS2 modified 05/06/1996 WINBIOS.
In autoexec.bat I have:
pci 1060:886a 40=15 45=05
ps2suppc
ctmouse /3

After following rasz's instruction, the result was:

Does this tell us anything? Or was I supposed to run the debug command without the PCI.EXE command and without ps2suppc?

handler at ~61 KB of conventional RAM, looks reasonable

1seg000:02D2 loc_102D2: 
2seg000:02D2                 push    ax
3seg000:02D3                 push    bx
4seg000:02D4                 push    ds
5seg000:02D5                 in      al, 60h
6seg000:02D7                 sti
7seg000:02D8                 mov     ah, al
8seg000:02DA                 mov     bx, 40h ; '@'
9seg000:02DD                 mov     ds, bx
10seg000:02DF                 assume ds:nothing
11seg000:02DF                 mov     bx, ds:0Eh
12seg000:02E3                 mov     ds, bx
13mov     al, ds:27h

thats ps2suppc code, and it ends with

1seg000:0353                 mov     al, 20h ; ' '
2seg000:0355                 out     0A0h, al
3seg000:0357                 out     20h, al
4seg000:0359                 pop     ds
5seg000:035A                 pop     bx
6seg000:035B                 pop     ax
7seg000:035C                 iret

so interrupt exit/ack is handled correctly. Problem is somewhere else.
ps2suppc installs two handlers, one for raw mouse interrupt, second one for Int15 C2 handler https://stanislavs.org/helppc/int_15-c2.html
Maybe there is something wrong with this handler. Can you try CuteMouse v2.0? afaik this version talks directly to PS2 hardware (ports 0x60/0x64) and bypasses BIOS int15.

Thanks for this analysis.

Indeed, loading CTMOUSE v2.0 and v2.1 following pci 1060:886a 40=15 45=05 and ps2suppc allow for a working mouse pointer in DOS. However, if I have already loaded CTMOUSE v2.0 or v2.1 and use the reset button, or a soft-reset, then load CTMOUSE v1.9, the mouse will function normally. With a cold startup, v1.9 will not work. Nor will Microsoft Mouse driver version 4.0 (1992).

I can confirm that Logitech mouse driver version 7.3 also functions correctly in MS-DOS with my Logitech MouseMan M-S38.

I have verified that, both, registers 40=15 and 45=05, along with ps2suppc are needed for this to work.

Does PS2SUPPC need to be edited to allow older mouse drivers to function on the M919?

Do we know how to edit the BIOS with the appropriate information to bypass PS2SUPPC?

Thats good and weird news at the same time 😀
I specifically asked about CTMOUSE v2.0 because its the separate branch using direct hardware interface bypassing BIOS. https://cutemouse.sourceforge.net

V1.9 branch uses BIOS to handle PS/2 mice.
V2.0 branch uses direct hardware access for PS/2 mice, and supports the wheel.
V2.1 branch uses BIOS to handle PS/2 mice but also supports the wheel, combining the best of V1.9 and V2.0. Wheel programming info is included in the v2.x packages.

But now you say v2.1 also works? 😮 That means its either a bug in v1.9, or v2.1 is just more robust and makes extra sure to initialize everything that should be initialized even if BIOS forgot.

v2.1 beta 1 has those in patch notes
-do not disablePS2 right before enablePS2 (IRQ/settings)
-removed PS/2 IRQ handler by BIOS callback handler.

one of them might be the magic that makes 2.1 work

>confirm that Logitech mouse driver version 7.3 also functions correctly in MS-DOS with my Logitech MouseMan M-S38.

might also use defensive programming and initialize more than strictly required.

>Do we know how to edit the BIOS with the appropriate information to bypass PS2SUPPC?

not so much bypass as add missing handlers for hardware irq12 (tiny) and int15 (bigger). While im pretty good at quickly disassembling and understanding BIOSes now, I never patched one. One has to first find free space, then fix checksums, then test extensively.
CTMOUSE v2.0 should work even without PS2SUPPC loaded.

Sounds like one of those so close, yet so far situations. Direct BIOS hacking is beyond me.

I'm not sure if it matters, but I was using CTMOUSE 2.1 beta4, rather than 2.1 beta1.