Short answer: Yes.
Before launching into the long answer, let’s recap what it even is. FasterModeSwitch is a SYSTEM.INI setting in Windows 3.1 which applies only to Standard (286) mode and can therefore be found in the [standard] section of the INI file. KB article Q83387 describes the setting accurately and explains everything… except what it actually does.
Here’s what Microsoft had to say on the subject: Enabling this setting causes Windows running in standard mode to use a faster method of switching from protected to real mode on many 80286-based computers. When this setting is enabled, Windows responds quicker to hardware interrupts, allowing better throughput for interrupt-intensive applications, such as communications applications. In addition, you should enable this setting if you are using a Zenith Z-248 system and are losing characters while typing, or if you are using an Olivetti M-250-E and lose control of the mouse.
Note: This setting has no affect [sic] on 80386-based computers. Some early IBM-AT and compatible computers do not have the BIOS support necessary to use this setting. Enabling this setting on these computers may cause them to hang when starting Windows.
The upshot then is that enabling FasterModeSwitch either speeds up Windows 3.1 or hangs it, depending on the machine’s BIOS implementation. Now, what does the setting really do, and why is the behavior system specific? Here’s the long answer…
Windows 3.1, like other 286-based protected-mode systems with DOS compatibility, must switch from protected to real mode by resetting the CPU, a capability which IBM designed into the PC/AT. The mode switch behavior described below was experimentally determined by running Standard mode Windows 3.1 under emulation.
Windows resets the CPU by causing a triple fault, which is a faster method than using the PC/AT keyboard controller to trigger a reset (the PC/AT BIOS uses the latter, slower method). After reset, it needs to regain control rather than letting the system go through POST.
Shutdown Code 09h
The default Windows 3.1 behavior is setting up CMOS shutdown status 09h (written into CMOS byte 0Fh). Status 09h was designed to handle the INT 15h/87h service (extended memory move) which also first enables protected mode and subsequently resets the CPU.
The downside of the shutdown code 09h “return path” (i.e. code executed very early in the BIOS POST sequence when shutdown code 09h is detected) is that it does more than Windows needs. Shutdown code 09h skips re-initializing interrupt controllers, which is a necessary pre-requisite. But it does other things that Windows really does not need.
Shutdown code 09h forcibly disables the A20h gate, which is a) slow, and b) undesirable. If Windows actually needs the A20 gate enabled (likely), it means the BIOS first disables it and Windows has to immediately re-enable the A20 gate again. That’s a problem because the A20 gate is controlled through the keyboard controller, which is not fast.
A minor annoyance is that shutdown code 09h enables interrupts, which the OS may need to immediately disable again. The POST code also accesses the manufacturing status port 80h more than Windows really cares about.
Shutdown Code 0Ah
With FasterModeSwitch enabled, Windows uses shutdown code 0Ah to come back from reset. The code path is considerably shorter, does not touch the A20 gate, and relatively quickly jumps to a far address stored in the BDA.
For the purposes of Windows 3.1, shutdown code 0Ah has clear benefits over code 09h and no drawbacks.
When it works. The trouble with shutdown code 0Ah is that it behaved differently in the first PC/AT BIOS (dated 01/10/84). The difference was that in the original PC/AT BIOS, only shutdown code 09h skipped the interrupt controller reset. Shutdown code 0Ah reset both interrupt controllers, which would mean lost interrupts. That is why Windows cannot use shutdown code 0Ah on early IBM PC/ATs and early AT compatibles which emulate the behavior of the original PC/AT BIOS.
Starting with the second PC/AT BIOS (dated 06/10/85), shutdown codes 09h and 0Ah both skip interrupt controller initialization. On such machines, shutdown code 0Ah is usable by Windows and preferable to shutdown code 09h.
Real World Usage
The FasterModeSwitch setting was recommended for communications software, even by Microsoft. It was recommended for at least one spectroscopy software package, especially on slower systems.
There are also reports that enabling FasterModeSwitch is necessary for Sound Blaster audio playback, at least on slower systems.
All of the above mentioned usages affect software which is to some extent real-time and must operate with relatively low latencies. Reprogramming the A20 gate at least once and likely twice might take many milliseconds, and it is thus not surprising that it would seriously interfere with software requiring fast interrupt response.
It is unfortunate that FasterModeSwitch could not be enabled by default, and detecting whether it is usable (or even available) on a given system would be difficult, likely causing a hang or uncontrolled reboot if not supported.
Notes
The reconstructed source code for all three PC/AT BIOS code can be found at pcdosretro. The relevant files are TEST1.ASM (the START_1 POST entry, early initialization and shutdown code handling) and BIOS1.ASM (SHUT9 label, return from INT 15h/87h).
It should be noted that the CMOS shutdown codes were never an official BIOS interface; a PC/AT compatible BIOS needed some mechanism to come back from reset in a controlled fashion, but the details were in theory implementation specific. However, several of the shutdown codes were used by software (HIMEM.SYS, OS/2, Windows) and thus clone BIOSes were forced to support at least some of them in a manner compatible with IBM’s BIOS.
This reminds me of the code to fix the CMOS clock in DOS 3.3 and later that checks for the model/submodel.
Brian Livingston in Windows 3.1 Secrets was very forceful in asserting that FasterModeSwitch slowed the system down*. Amusing how different results can be perceived from the same data points.
* Not impossible. While the switching between modes is faster, if there are more frequent mode switches, the net performance for protected mode applications would be reduced. I no longer have my 286 system to test the overall performance effects and I have no idea how I had it set up. It was fast enough to reliably capture Compuserve and GEnie even in Windows when the more modern computer was busy with activity that precluded using it for fun.
Though in this case DOSX is mostly just a DPMI server.
There wouldn’t be more frequent switches. But it is entirely plausible that there existed a clone PC where FasterModeSwitch really was slower. No one ever formally defined what the various shutdown codes do precisely (obviously even IBM changed their mind on that), and not everyone cloned the PC/AT BIOS behavior in exquisite detail.
There is empirical evidence that FasterModeSwitch does help on a “typical” 286. I’m entirely prepared to believe that on specific 286 systems it did not. On 12-16 MHz and faster 286s it may not have made enough difference either way for users to notice.
Livingston was unusually vehement in the included disclaimer on FasterModeSwitch. I list the one for the Zenith keyboard; a similar disclaimer was included for the Olivetti mouse.
“This line slows down processing so the keyboard can handle it. Do not use
this line on other computers, thinking it will make them “faster.” This line
does not have that purpose and may hang IBM AT-type computers when
Windows 3.1 starts.”
Clearly, there was a bit of confusion as to what FasterModeSwitch did.
Curious. The part about possibly hanging IBM PC/ATs is right, with the first-gen ATs that would happen. But on a 2nd gen AT, FasterModeSwitch will speed things up, there is no question about that.
What exactly FasterModeSwitch might do on the Zenith or Olivetti machines is a another question. I really doubt it slows things down, but without examining the BIOS I can only guess. I’m prepared to believe that some machines existed where FasterModeSwitch was slower. The IBM PC/AT (2nd/3rd BIOS release) was definitely not one of them.
This is fascinating. It’s been over a decade since I’ve last used a 286 & I’ve been meaning to put together one to play around with. So many clever* things were done to mask the deficiencies the 80386 solved just a few years later.
*some might argue “dirty and klunky” but to each their own ;).
Engineers solve existing problems and the solutions aren’t always pretty. But they get the job done.
The 386 was lovely but when were there as many 386s as 286? Sometime around 1991?
I wonder if the toggling of the A20 gate by the BIOS or Windows relying on the keyboard controller were the problem. Windows reset the CPU using a triple fault, but…
(remembering that the PS/2 mouse use the same keyboard controller of course)