Hi, I updated my local FDAPM copy 2 weeks ago, fixing the "idle time" statistics and making the ACPI support more insisting (ignores im- plausible values from BIOS, for example).
However, I cannot get my plans settled for other possible updates, most of them inspired by PC-DOS documentation, so it would be really nice to have some feedback from users. Here we go... - POWER normally polls the APM BIOS for things like "standby upcoming" and broadcasts them to some POWER-specific programming interface, allowing DOS programs to show messages, flush caches, or - only for some events - reject the state transition (e.g. user presses the sleep / power button, BIOS gets the message, POWER forwards it, some DOS program rejects it, POWER tells the BIOS to ignore the button). FDAPM does *not* implement that yet. The feature would only be useful if there are actual DOS programs which use it. Laptop DOS users, can you remember any such program? Or maybe google one? Events are: standby request, suspend request, and notifications for resume, "crit. resume", battery low and status change. For APM 1.1, there are also events for USER resume/suspend/standby, crit. suspend and clock changes. I assume that laptops have some light that goes blinking when the battery is low, and there does not seem to be too much use for the other events in DOS either - as it is not normally used as server or with some DOS-APM-driver-using multitasking GUI(?). - POWER allows you (although there is no command line interface for it) to enable / disable each of 4 categories of idle detectors separately. I am planning to make FDAPM compatible to that (not much work), but would be interested to know of any nice user interface / configuration tool for the feature. The change also involves adding support for "int 2f.1680 yield time slice / multitasker idle call". No idea which programs will be happy about that / save more energy with it, though. - POWER has an "check for key"-flood detector. If a program looks for keyboard events more than N times per second, then some throttle mechanism kicks in which sleeps M of each 8 timer ticks. Values are documented for IBM PC DOS POWER. My problem with that: It would make FDAPM more *invasive* to timing if I add support for the function. In other words, programs which have a tight "check for keypresses" loop in their architecture would suddenly run much slower because they trigger the flood detector. With faster CPUs, chances to trigger the detector raise. I really have a bad feeling about this, although I am sure that it will improve energy saving with certain programs a lot. Comments please. Maybe it would be an idea to write a tool which controls ACPI throttle based on keyboard-check flood ratio in some way? I mean, instead of just halting the whole system for M of each 8 timer ticks (a timer tick is 0.054 seconds, relatively long, you WILL notice the stop-and- go behaviour), reduce the CPU clock to M times 1/8th of maximum in a smooth way. Or do you need support for pre-ACPI systems / noticed that FDAPM saves far less energy than POWER with certain programs on such systems? If I do implement the ACPI throttle, what would the algorithm be? Something like "if keyboard is checked more than 1000 times per timer tick, then the system is probably bored and can be slowed down, and if keyboard check frequency drops below 250 times per timer tick, more CPU power should be made available, system has to speed up again"? I hope you can help me with some feedback on this, even if it is just "nobody needs broadcasts, nobody has some user interface for the single detector on/off control, and I would like you to keep the flood check out of FDAPM because my games will run shaky". Then I do at least know that I can drop the priority of the above ideas and can instead publish the existing updates (timeslice yield, statistics fix, ACPI insisting). Thanks! Eric ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
