Hi Zbigniew,

>> Actually you can use FDAPM for that: While the APMDOS
>> function is active, FDAPM keeps MSDOS POWER compatible
>> statistics of which percentage of the timer tick...

You do not have to explicitly program anything for this:
Just run FDAPM APMDOS at some time, e.g. in your autoexec
and then run FDAPM STATS to see how much of the time the
CPU was idle - to be exact, which percentage of the time
slices contained any idle time, so "idle-ness" is always
over-estimated. Example:

C:\>fdapm stats
Performing action: STATS
Found resident FDAPM / POWER driver version 1.0
Savings mode: BIOS APM plus interrupt hooks (MAX setting)
 CPU was idle 99% of the time

So just getting the answer to "how much of the time was
the CPU idle since I loaded FDAPM" by typing a command
at the prompt is very easy. But you say that you wanted
to display real-time information about how busy you are
inside your program. For that, you can add some queries
to FDAPM to your app. A good example would be a game as
Chess or Go: Sometimes you do heavy calculations, while
at other times, your software just sits there and waits
for the player to make the next move. You could display
information about this as part of the game...


If you want, you can also query the stats in your apps:

1. set ax=5400h, bx=0, call int 2f, check if bx is 504dh
on return. If yet, FDAPM, POWER or similar are running.

2. set ax=5401h, bh=0, call int 2f, check if (ax&3) > 0
to see if ... is in a state where idle stats do matter.


3. now that you know that FDAPM or similar is active and
updating statistics, you can start polling them for some
sort of display inside your program - although I do not
know what type of program you are planning to write, it
is possible that it will be idle so often on modern CPU
that displaying the load is not even worth the effort.

In the example of the Chess or Go game, your game could
easily display a RED OR GREEN BOX for "is busy thinking
about the next move" versus "is bored - waiting for the
next human move" because CPU load is always either NONE
or FULL 100%. In this situation, FDAPM statistics would
be only interesting to show how much of the time since
the start of the current ROUND the CPU was busy, versus
how much of the time the CPU waited for the player, not
which percentage the last SECOND the game was busy :-)


Set ax=5481h, bx=0, cx=1ch, dx:si=pointer to a buffer of
seven 32bit "long" ints size, call int 2f, now if ax is
returned as 0 (okay) your buffer array will contain the
values, in this order:

- total number of timer ticks (time slices) counted
- number of timer ticks containing idleness
- (number of idle calls)
- (int 2f idle ticks: triggered by command.com waiting)
- (int 28 idle ticks: official DOS idle state call...)
- (int 16 idle ticks: idle while waiting for keypress)
- (int 2a idle ticks: "network related keypress idle")


The easiest idea is probably to make a snapshot of the
first two array items, wait until "total number of timer
ticks" ("FDAPM uptime", you could say) grew by, say, 100
(which takes a bit more than 5 seconds) and then display
an indication of how much "number of ticks ... idleness"
has grown in the same time (in my example, it would grow
by at most 100 because you waited 100 ticks of uptime).

If you want to update your load info display more often
you can of course only reach smaller counts of idleness
in the same time and your display would jump in steps of
multiple percent as smallest measurable load difference.

The other way round, in the Chess or Go game, you might
want to display thinking TIME per game, not percentage,
so you only snapshot once when a game starts, then show
total times after each turn, instead of per second load.

I hope this gives you an idea to get you started. Maybe
you could tell more about your project :-)

Eric


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to