Hi Alain, > 1) You say something about restoring the dos time.
This only applies to SUSPEND, for which many APM BIOSes stop the CPU. > Am I safe if I use only APMDOS? APMDOS - which is the only TSR mode of FDAPM - uses both HLT and the int 15.5305 CPU idle call (you can configure which to use, but default is to use both) in the following situations: "wait for key" (not: check for key), int 2a.84, int 28 (DOS idle). It could happen that HLT (which causes Stop Grant on some modern CPUs to save more energy) stops the time stamp counter (-> RDTSC). Would be nice if somebody could tell me if that happens. However, IRQs are still handled, so the DOS time is not slowed down by APMDOS, and no other problems should happen. > 2) Aparently STATS apply to all the time interval from going TSR. How > can I reset them to fine tune my main program? You would have to reset onTicks and idleTicks... which are hopefully counted properly enough by handlers.asm... The non-idle ticks are counted when int 16 "check for key" or int 2f.ae are called. If those are not called for a long time, you end up in a situation where the measured uptime is too small and you have more than 100% idle time according to FDAPM. If you think this is a problem, then please suggest some other hooks which should also trigger uptime update (preferrably not simply hooking int 1c, or would that be the best option?). When FDAPM displays the stats, it copies them from the TSR to the non-TSR instance. Nothing resets the counts in the TSR yet, but I can add such a function if you like. I can also add the mentioned int 1c hook when I am updating FDAPM anyway... Comments please. > 3) I intend to use it with a program in OpenWatcom-3 in PM. The problem > is that it is not allowing any saving :( Same for DJGPP-compiled SSH2DOS (sshdos.sourceforge.net) :-(. > The main program loop is: check keyboard via bios, check mouse movement > (cursor is in sw not the driver), check timers (3 events/s) and when the > the event queue is empty that is it. As explained above, CHECK keyboard does not count as being idle. However, you can just use the HLT assembly language command in your main loop yourself - this stops the CPU until the next hardware interrupt. WAIT for keyboard would count as being idle, but it would slow down your loop (freeze whenever no key pressed!). I see no way how FDAPM could decide that your main loop involves being idle - for FDAPM, your program looks as if it is checking keyboard and mouse as often as possible, and it cannot decide when your program is bored, even though FDAPM could be made clever enough to know when keyboard / mouse has "no news to report". In Linux, your task would yield / wait for "event on any file handle" (using select(), sleep(), or using signal handlers together with "wait for data" instead of "select to check for data"), Linux would switch to the next task, and if no tasks are left waiting for CPU time, then the last task - the kernel "idle task" - would do just that: invoke HLT. For Win9x, you have tools like RAIN or WATERFALL (freeware) to call HLT... > Is USB mouse in DOS handled via bios OK? If your BIOS supports USB mouse, then it will simulate a PS/2 mouse from it. Mouse drivers which do NOT use direct hardware access should work with that, e.g. CuteMouse 1.9 will work, 2.0 will not. If you load own drivers for OTHER USB devices, the BIOS will usually loose all control over USB, and you would have to load DOS drivers for ALL USB devices (or for NONE, and use only those USB things for which you have BIOS drivers). However, you can conceivably use DOS drivers for some of your USB controllers if BIOS only grabs those USB controllers which have supported devices like mice plugged in... Modern PCs often have 2-4 independent USB controllers. You can also spin down disks (IDE: FDAPM, using hardware access, SCSI: using ASPI SCSIMGR$ device drivers and http://home.arcor.de/g.s/ ???) to save 5-10 Watts per disk, and throttle the whole CPU speed (to N*12.5%) with http://www.oldskool.org/pc/throttle/ ... If throttling turns out to be effective, I could try to add that to FDAPM. CPUs which support SpeedStep or Cool'n'Quiet allow you to reduce power consumption a lot: For example Athlon64 at 40% of max speed, with lowered core voltage, takes only 24% of the top power consumption, and Sempron takes 32% power at 55% speed. Other CPUs take 89/66/35 Watts at 2/1.8/0.8 GHz ... Even for K6-2 333 MHz you have a big difference between worst case (19 Watts), normal load (not keeping all CPU components busy all the time) (11 Watts) and HLT (4 Watts). For Pentium M and Celeron M, you have 22/25 Watts (2 GHz?) normally and 7/10 Watts in HLT - those also support deep and (not Celeron M) also deeper sleep, which makes more components of the CPU sleep (5/6 Watts, deeper sleep of Pentium M even less than 1 Watt). You can compare HLT / StopGrant with S1 idle state (CPU C1 idle state). To support C2/C3 sleep states, you often need extra (ACPI) drivers, which is probably not too useful in DOS (HLT is not much worse than deepsleep, and you can keep the CPU throttled all the time to save even more energy). The next useful state would be S2 standby, which is not supported by all BIOSes and systems: For S2, you need extra ACPI drivers, and have to save ALL (including configuration and protected mode stuff and all floating point, MMX, whatever) CPU state and call WBINVD (flush cache) before you enter that mode: S2 turns off the CPU (!) and reboots to wake up. The wake up jumps to a handler (which you have to provide) which copies all state information back to your CPU. I guess "deepersleep" on Centrino works without that complex step, by allowing a state-preserving minimum power mode for the CPU. Talking about Sn states: S3 is suspend to RAM - some APM BIOSes support that (very few (?) even do suspend to DISK S4 for you) - which can be triggered by FDAPM SUSPEND, but only if your BIOS supports APM. S1 is STANDBY, and PCISLEEP S should get close to that even without APM BIOS (PCISLEEP just HLTs the CPU and tells all devices for which no extra drivers are needed to do that to enter a sleep state). Finally, S5 is soft-off, and it would be interesting to make FDAPM able to power off the system without APM BIOS help. You can try my PNPOFF tool on systems where newest FDAPM fails, and if that STILL fails, I would have to make FDAPM or PCISLEEP understand a bit of ACPI (full ACPI support would require a binary of 70k or more uncompressed size, containing complex parsers and a virtual machine, see www.acpi.info). However, you have to tell me if not having to press the power button with your fingers is worth the effort of improving FDAPM POWEROFF. Something between S1 and S3 can be reached by spinning down disks with FDAPM or SCSISPDN and then using PCISLEEP V, which disables the screen and then suspends the VGA. For the wake-up after that, the VGA BIOS is "rebooted", which can crash for modern VGAs, in particular when you have EMM386 loaded. But it is a very interesting experiment to try it! In particular: How much energy does it save? Suspending other devices is not supported - 1. because I do not know how to re-init them and 2. because they only use little energy as far as I can tell. Feedback welcome! PCISLEEP V also odoes the same SLEEP step as PCISLEEP S and of course also HLTs the CPU. URLs: http://www.coli.uni-sb.de/~eric/pnpoff.zip http://www.coli.uni-sb.de/~eric/pcisleep.zip http://www.coli.uni-sb.de/~eric/stuff/soft/fdapm-21jan2005.zip http://www.oldskool.org/pc/throttle/ http://home.arcor.de/g.s/ (SCSISPDN) PCISLEEP also has the L option to show a PCI device list including information about power management capabilities. To find names for the displayed device codes, try http://pciids.sourceforge.net/ or http://members.datafast.net.au/dft0802/ Eric ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
