Hi Bernd and Guti,
thanks for mentioning the topic :-) Actually FreeDOS EDIT VERSION 0.7d
does take care of idling in FDAPM compatible ways ;-)
/* ---- dispatch messages to the message proc function ---- */
BOOL dispatch_message(void)
{
WINDOW Mwnd, Kwnd;
/* -------- collect mouse and keyboard events ------- */
collect_events();
/* only message.c can fill the event queue, but all components */
/* can fill the message queue. Events come from user or clock. */
if ( (EventQueueCtr == 0) && (MsgQueueCtr == 0) &&
(handshaking == 0) ) { /* BORED - new 0.7c */
union REGS r;
#if 0 /* int 2f is often quite crowded */
r.x.ax = 0x1680; /* release multitasker timeslice */
int86(0x2f, &r, &r); /* multiplexer call */
#else
r.h.ah = 0x84; /* "network" idle call */
int86(0x2a, &r, &r); /* network interfaces */
#endif
}
/* --------- dequeue and process events -------- */
while (EventQueueCtr > 0) {
...
Of course this also leads to the question which calls are interpreted
as signs of being idle by FDAPM in which configurations. Those are,
as implemented in handlers.asm:
- waiting for keyboard input in a blocking way (int 16 func 0, 10, 20)
- polling the keyboard (int 16 func 1, 11, 21) counts as activity BUT
- polling in vain because no key got pressed counts as being idle ;-)
- calling int 2f func 1680 (win3 / DPMI release timeslice) is idle-ness
- calling int 2a func 84 means you are idle
- calling int 28 means you are idle BUT ONLY when ADV:MAX mode is used
FDAPM takes care to implement being idle in a suitable way. The most
basic action is indeed invoking HLT, but if the BIOS supports APM,
the BIOS calls for being idle are preferred. Note that HLT is one
of the things you cannot do while protected mode tasks etc. exist,
unless your host (possibly EMM386!) allows you to do it ;-)
Maybe you can take a look to this:
https://github.com/javiergutierrezchamorro/DRIDLE
https://github.com/javiergutierrezchamorro/DRIDLE/blob/main/dridle.asm
This hooks int 8 (or 1c and 28), 16 and 2f, but not int 2a.
Note that FDAPM does not hook int 8 or 1c (timer tick ints).
DRIDLE has the categories "idle condition", "int 28 idle loop"
and "idle because you are waiting for keyboard input".
- waiting for keyboard input counts as idle if no key is pressed
AND no "activity" is detected (see below for an explanation)
- polling the keyboard counts as being idle while done frequently
- int 16 keyboard functions int 20 and 21 are not processed here
- the timer tick is used to check whether things happen frequently
- calling int 2f func 1680 (see above) is idle-ness
- calling int 28 means you might be idle, UNLESS "activity" etc.
It seems DRIDLE stays in idle mode until a key is pressed when it
detects that keys are what you are waiting for. FDAPM would just
wake up at the next timer tick and go to sleep again at the next
sign of being idle - usually soon. Easier, but less energy saved.
DRIDLE tracks how quickly signs of being idle are coming in.
Checking for "activity" is done by using a protected mode driver
which can notify DRIDLE about text or VGA graphics RAM writes and
COM1 or COM2 I/O port activity using a simulated DRIDLE I/O port.
In addition, floppy motor status at 40:[3f] is checked: If this
value is non-zero, DRIDLE avoids sleeping as a floppy is turning.
If anything else is using the timer interrupts, then DRIDLE will
also avoid sleeping, because it assumes that the other users of
the timer interrupt will need to do something at regular intervals.
DRIDLE also cares for the indos flag, and checks whether somebody
else has modified the int 16 BIOS keyboard handler. Depending on
some "VBOX" related compile time option, it will either use HLT
or out 8003 to port 40f (idle signal to virtualbox??). It accesses
both the RTC and the timer, so it is quite time-aware as well :-)
Regards, Eric
Bernd wrote:
Is anyone into power management, specifically how to properly idle DOS
applications NOT using any of the DOS calls typically triggering DOS idle
handling?
FreeDOS EDIT does not use any DOS functions in its event handling loop, but
instead does its input polling through INT16 (keyboard) and INT33 (mouse).
First guess on saving some energy would be to issue HLT instructions as part of
the event loop, but I am not sure about the side effects on doing so from
within an application. May it safely be used?
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
