IDLE DR-DOS | OS/2 Museum

I’ve a laptop computer. Generally I run VMs on it, and a few of these VMs run DOS. When a DOS VM doesn’t have any energy administration, the laptop computer shortly lets me know by kicking up the fan velocity. It’s Very Annoying. So annoying that I actually need to keep away from the state of affairs.
In newer variations of PC DOS and MS-DOS, the included POWER.EXE utility takes care of it, for probably the most half. However DR-DOS doesn’t ship with any energy administration utility. That’s even supposing since model 5.0, DR-DOS has a really promising-sounding IDLE command in-built. Sadly, it does nothing:

The net assist in DR-DOS 5.0/6.0 or Novell DOS 7.0 doesn’t even point out the IDLE command. Scouring the depths of the Web revealed a doubtlessly useful doc titled Implementing Power Management (BatteryMAX) in DR-DOS.
In brief, stated doc explains that DR-DOS has hooks for energy administration, however requires a driver known as (internally) $IDLE$ to be put in as a way to truly do something. OEMs had been speculated to ship such a driver. DRI/Novell/Caldera had a growth package with pattern drivers that OEMs might use as a place to begin.
However alas, it seems that the event package didn’t survive, and I did not discover a single launch of DR-DOS that would come with an influence administration driver. So shut, and but thus far!
However wait! The documentation mentions that Digital Analysis patented BatteryMAX and was granted U.S. Patent No. 5,355,501. Solely… the actual patent is only a pile of patentese gobbledygook, practically not possible to decipher and never too helpful.
Besides… besides… the PDF version of the patent consists of about 80% supply code listings that nobody bothered to OCR!
These supply code listings begin with excerpts from DR-DOS itself, exhibiting how the facility administration hooks are carried out within the OS. But it surely will get higher. That is adopted by a supply code for a tool driver known as IDLE86.SYS, a rudimentary however maybe practical implementation of the $IDLE$ driver from 1990.
So… I typed the entire thing in, as a result of expertise taught me that it’s a lot sooner than correcting a horrible high quality OCR. Mounted a few typos, linked, and loaded in a Novell DOS 7.0 VM. Amazingly, it labored! The laptop computer fan instantly calmed down when DOS sat on the command immediate.
However not after I ran, say, the editor that comes with Novell DOS. After a little bit of debugging, I discovered one other typo that prevented idling from working when the idle examine wasn’t invoked from DOS itself. After fixing that, the VM idled additionally when operating random editors. Very promising!
How $IDLE$ Works
The $IDLE$ driver supply code offered in patent 5,355,501 is what one would possibly name a functioning pattern. It’s meant to be tailored to interface with hardware-specific energy administration, however merely executes the HLT instruction when it decides that the system ought to enter the idle state.
Not like POWER.EXE, which features independently of DOS, the $IDLE$ driver makes use of hooks offered by DR-DOS. Thus there’s for instance no must intercept INT 28h, as a result of DR-DOS will name into the $IDLE$ driver when INT 28h is invoked and sure circumstances are glad.
There’s a small information construction, known as the Idle State Knowledge Space, which is used for communication between the DR-DOS kernel and the $IDLE$ driver. The interface is documented in good detail and discussing it right here can be redundant.
The pattern IDLE86.SYS driver, along with utilizing the Idle State Knowledge Space, additionally intercepts INT 8h and INT 16h.
INT 16h is intercepted to allow idling of purposes which name the keyboard BIOS providers instantly, quite than going by means of DOS. Full-screen DOS purposes sometimes do this, particularly if in addition they help a mouse.
If INT 16h is invoked and the INDOS flag is about, indicating that DOS itself is looking INT 16h, IDLE86.SYS passes by means of the decision to the BIOS; DR-DOS will name the idling operate instantly.
In any other case, when INT 16h operate 00h or 10h is known as, the IDLE86.SYS driver goes to idle state instantly; on this state of affairs, the calling utility is blocked till a secret’s pressed.
Calling some other INT 16h features is taken into account polling and IDLE86.SYS could go to idle state. That is based mostly on a heuristic which tries to guess whether or not the applying is doing something a lot in addition to polling the keyboard.
To that finish, IDLE86.SYS makes use of the 8253/8254 Programmable Interval Timer (PIT) to measure what number of timer ticks it takes to ballot the keyboard state and question the Actual-Time Clock (RTC). If the keyboard is polled a sure variety of instances and little or no time elapsed, the system is taken into account idle and the IDLE86.SYS driver goes into idle state.
Comparable logic is used for INT 28h. If INT 28h is known as in speedy succession, the applying is taken into account idle. Be aware that calling INT 28h doesn’t robotically imply that an utility is idle. Invoking INT 28h is a option to let background packages execute now and again.
IDLE86.SYS additionally hooks INT 8h, the timer tick interrupt. The hook does little or no, solely resetting inner counters and persevering with to the beforehand put in handler. That is carried out to make sure that purposes should look like idle quickly, inside one timer tick, as a way to be thought-about actually idle.
When idling resulting from repeated invocations of INT 16h or INT 28h, IDLE86.SYS tries to evaluate whether or not the system is lively. With out entry to energy administration {hardware}, that is tough. For testing and demonstration functions, DRI had a separate driver known as IDLE386.SYS which ran DOS in V86 mode and used normal 386 {hardware} to intercept entry to video reminiscence and a few I/O ports. This was utilized in lieu of precise energy administration {hardware} to detect whether or not the system is performing some exercise despite the fact that it would seem idle. The supply code for IDLE386.SYS will not be offered within the patent, however it might be impractical in any case as a result of the driving force prevents reminiscence managers or different protected-mode software program from operating.
With out IDLE386.SYS, all that IDLE86.SYS does is examine whether or not the floppy motor is on. When it’s, IDLE86.SYS considers the system lively and received’t enter the idle state.
As talked about above, when the floppy motor is on, idling is prevented. That avoids a state of affairs the place the floppy motor is on and idle state is entered with the timer interrupt masked. That will forestall the floppy motor from being turned off after the conventional timeout.
Expertise exhibits that IDLE86.SYS could be very fast to detect idle state, a lot sooner than POWER.EXE. That’s as a result of POWER.EXE has a comparatively lengthy ramp-down interval, solely coming into idle state a while after idling is first detected. As a consequence, for instance typematic key repeat could fully forestall POWER.EXE from idling. IDLE86.SYS in distinction should detect idle state inside one timer tick (about 1/18 sec) to enter the idle state in any respect.
As a result of IDLE86.SYS plugs into DR-DOS, it’s managed by the DR-DOS IDLE command. IDLE OFF disables idle detection and IDLE ON turns it on once more. This may be used if the $IDLE$ driver incorrectly decides that the system is idle when it’s not (presumably as a result of some exercise it doesn’t or can’t detect is happening).
Sleeping More durable
The IDLE86.SYS driver introduced within the patent exhibits one attention-grabbing concept which isn’t absolutely realized within the pattern code. When the driving force detects that nobody else hooked the timer associated interrupt vectors (INT 8h, INT 1Ch, INT 28h), it could masks the timer interrupt whereas idling. The logic is sort of easy: If no TSR hooked something relying on timer ticks, it then the timer tick is just utilized by the BIOS to maintain time and probably flip off the floppy motor. When the system goes into idle state ready for keyboard enter, timer interrupts are masked, and the CPU is just woken up when some different interrupt arrives. At that time IDLE86.SYS reads the RTC and updates the BIOS tick rely.
Whereas the concept is sort of attention-grabbing, it has severe drawbacks in follow. One is that very often, some TSR does hook timer associated interrupts; one such instance is NWCACHE from Novell DOS 7.0. The sleep optimization due to this fact can’t kick in as a result of IDLE86.SYS can’t make sure that timer ticks aren’t required.
The opposite drawback is that the RTC solely has 1-second decision. Due to this fact, as soon as the system wakes up, it can’t restore the timer tick rely exactly and the BIOS timer tick rely will probably be inaccurate. This might not be a lot of an issue in follow, and the algorithm might maybe be improved. Nonetheless, since many frequent configuration forestall this optimization anyway, it’s not more likely to be price fixing.
DR-DOS 5.0/6.0 Caveat
Expertise with IDLE86.SYS and DR-DOS 5.0 and 6.0 clearly exhibits that DRI by no means shipped the driving force within the type that was revealed within the patent. As a result of when DR-DOS 5.0 or 6.0 runs with EMM386.SYS (aka MemoryMAX) loaded, the idle driver has no impact.
It’s not that the idle driver doesn’t work—it really works simply nice. The difficulty is that when it executes the HLT instruction, a #GP fault is triggered (which is regular—HLT is a privileged instruction), and EMM386.SYS “handles” it by merely persevering with execution.
In different phrases, the $IDLE$ driver tries to halt, however EMM386.SYS doesn’t play ball and successfully ignores HLT directions. That is the case even with the latest EMM386.SYS for DR-DOS 6.0 dated April 27, 1992.
Be aware that the issue will not be in any approach particular to the IDLE86.SYS driver. Any energy administration utility utilizing the HLT instruction has the identical drawback.
Novell DOS 7.0 doesn’t have this deficiency and idling utilizing the HLT instruction works with or with out EMM386 loaded.
Lacking Performance
There’s one helpful piece of performance that the IDLE86.SYS driver (as introduced within the patent) doesn’t implement. That’s the DPMI INT 2Fh/1680h idle service. The DPMI specification was revealed at about the identical time the patent was filed, so the dearth of this performance is hardly stunning.
Be aware that there’s a important distinction between INT 28h and INT 2Fh/1680h. INT 28h may be periodically known as from a busy utility with the expectation that INT 28h returns shortly and execution continues.
In distinction, INT 2Fh/1680h is supposed to be executed when an utility decides that it’s idle. It doesn’t require any heuristics within the energy administration driver and takes impact instantly. The IBM PC DOS 7 Technical Update clearly states: This API (purposes program interface) [INT 2Fh/1680h] must be utilized by all PC DOS 7 purposes to point when they’re idle.
Be aware that INT 2Fh/1680h was not initially supposed for energy administration. As an alternative, it was designed for multi-tasking environments operating DOS purposes (OS/2 2.0, Win386). Nonetheless, it seems to be the identical drawback: If an utility is idle and may let different purposes execute, additionally it is idle and may let the machine go right into a low-power state.
Idle Historical past
It’s obvious that when Digital Analysis patented BatteryMAX in 1990, the performance was not developed from scratch. Removed from it. As talked about above, the issue of detecting idle purposes for the needs of energy administration is in actual fact the identical drawback as detecting idle purposes for the needs of multi-tasking.
Digital Analysis developed Concurrent CP/M-86 and later Concurrent DOS all through the Nineteen Eighties. Expertise from detecting idle purposes within the Concurrent DOS atmosphere was instantly relevant to BatteryMAX.
That is in all probability additionally the explanation why DRI’s $IDLE$ driver is rather more tightly built-in with the OS than the IBM/MS POWER.EXE driver. In Concurrent DOS, the idle detection needed to be in-built and couldn’t rely on customized {hardware}.
Making an attempt It Out
I took IDLE86.SYS, very barely modified it, and renamed to DRIDLE.SYS (to point the DR-DOS connection). A check model of the driving force is obtainable here.
The motive force was evenly examined with DR-DOS 5.0, 6.0, and Novell DOS 7.0. It has a noticeable impact on CPU utilization, though it won’t work in all circumstances. Be aware additionally the restriction talked about above—EMM386.SYS shipped with DR-DOS 5.0/6.0 prevents the HLT instruction from truly halting the system.
The motive force doesn’t (but?) help INT 2Fh/1680h. It’s nonetheless more likely to work with typical purposes which ballot the keyboard in a loop.
The motive force may be loaded on PC DOS/MS-DOS. It is not going to do something helpful, however received’t hurt something both.
The motive force could also be improved sooner or later… or not.