Recently a minor mystery resurfaced. When IBM’s OS/2 1.2 SE is installed on any “normal” system (either physical or virtual) and the PS/2 mouse driver is installed (the typical choice), the mouse won’t work:
The MSPS201.SYS driver is intended for Microsoft (‘MS’) PS/2 (‘PS2′) mice for so-called Type 1 (’01’) aka AT-compatible systems. It should work, and it indeed does work in IBM’s as well as Microsoft’s OS/2 1.3.
The reason why two error messages are displayed is caused by the mouse driver design in OS/2 1.x (as well as initial 2.x releases): There wa a generic mouse driver, MOUSE.SYS, which was responsible for providing mouse services to the rest of the system. This driver cooperated with a device-specific driver, such as MSPS201.SYS. Other device-specific drivers supported serial mice, MS bus mice, etc. The device-specific driver was relatively simple and used a straightforward interface to communicate with the generic driver.
But back to the original problem. Why won’t the IBM OS/2 1.2 MSPS201.SYS load? The answer turns out to be slightly unexpected. The driver doesn’t even get as far as trying to communicate with a mouse. During initialization, it calls the DosDevConfig API (twice) to query the system’s model and submodel ID bytes.
The driver only continues to load when the model is FCh (AT and compatibles) and submodel is 9. This would be true on IBM PS/2 Model 25 and 30 machines, the ISA bus based not-really-PS/2 systems. It’s not the case on any AT clone systems.
The obvious question is, would the driver load if the submodel ID were changed to 9 on a clone? The answer is as follows:
For PS/2 Model 25/30 machines, OS/2 1.2 and 1.3 loads a separate set of drivers that is neither ‘AT style’ (BASEDD01.SYS) nor ‘PS/2 style’ (BASEDD02.SYS). Not too surprisingly, the BASEDD03.SYS driver does not work on AT compatibles. Presumably if it did, there would be no need for separate drivers.
Is there any other way to convince the MSPS201.SYS driver to work? If changing the environment does not bring the desired results, perhaps patching the driver will. This method indeed works. For the driver distributed as MSPS201.SY@ (1796 bytes, dated 08/31/1989), all it takes is changing the byte at offset 6B0h from 74h (JE instruction) to 75h (JNE). Note that this modification must be applied to the unpacked driver!
With this tweak, the driver no longer fails the model/submodel check and happily loads and works on an AT clone equipped with a PS/2 mouse.
The MSPS201.SYS driver distributed with OS/2 1.3 does not include this overly strict model check. Because the internal mouse driver interface was not changed, the OS/2 1.3 PS/2 mouse driver for AT compatibles can also be used with OS/2 1.2.
…why patch from JE to JNE?
if the aim is to take the jump, why not patch to JMP? if the aim is to not take the jump, why not nop it all out? this would make it work in all circumstances..
Because… why change more than a single bit?
The difference is between making the patched driver work on all systems or all systems minus PS/2 Model 25/30, where the unpatched driver already works just fine. I did not consider that a difference worth bothering with. But if you are concerned about the case where someone needs to patch the existing driver and then move the patched driver to PS/2 Model 25 or 30… go for it 🙂
I always figured it was something along those lines. The PS/2 model 30 was such a weird machine, part IBM AT, part PS/2… I guess looking at what counts as a ‘modern’ computer it was the way to the future.
In a twisted way I still want a PS/2 model 60 with 16MB of ram, because it’d be the coolest OS/2 1.21 machine ever.
Hey… how about a Model 80 with 16MB? And some kind of 8514/A? 🙂
“I always figured it was something along those lines. The PS/2 model 30 was such a weird machine, part IBM AT, part PS/2… I guess looking at what counts as a ‘modern’ computer it was the way to the future.”
Yea, I knew that modern PCs were more similar to PS/2 model 30-286 than PC/AT for a while now.
Here’s a question — the Model 25 and Model 30 were 8086, with (at least in the case of the 25) a 640k RAM limit. So I assume the OS/2 support was limited to the Model 25SX, Model 25 286, Model 30 286, etc…?
Yes, a 286+ processor was required, so the 8086-based Model 25 and 30 machines were not supported.