News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

wait_key.asm

Started by rkhb, April 27, 2012, 06:57:19 PM

Previous topic - Next topic

dedndave

yah - did some reading
you have to install your own INT 28h handler - something like sinsi did - it is initially just an IRET
the multiplex interrupt might be the way to go - provided the OS is recent enough to support it

FORTRANS

Quote from: dedndave on April 29, 2012, 06:24:00 PM
yah - did some reading
you have to install your own INT 28h handler - something like sinsi did - it is initially just an IRET
the multiplex interrupt might be the way to go - provided the OS is recent enough to support it

Hi,

   Int 28H and Int 2FH were introduced in MS-DOS 2.0 to support
the PRINT command.  That was to allow PRINT to operate in the
background.  To limit CPU usage in some of my code I use something
similar to what sinsi posted.  I just put a HLT in the test for a key
loop.  That was done to reduce power usage on the HP 200LX
palmtop.

Regards,

Steve N.

MichaelW

Running on a P3, HLT in a loop had no apprent effect under NTVDM.
eschew obfuscation

dedndave

yah - that's what i was afraid of   :P
NTVDM probably ignores HLT instructions altogether

FORTRANS

Hi,

   Well a quick test of HLT shows no effect with a Win2k NTVDM
or an OS/2 VDM on my P-III.  Using the graphical CPU meters
of each.  Got a way to measure CPU usage under plain DOS?

   With the MS-DOS 5.0 on the 200LX I used an amp meter.
But I can't find what the actual numbers were anymore...

Regards,

Steve N.

hutch--

Illuminate me here, with a non-re-entrant OS like MS-DOS, what is the point of looking for a wait instruction/sequence/interrupt when only one task is running ? Surely you just shove a test in the polling loop for something like a keystroke or mouse event (if I vagely remember int 33h correctly) and let the processor ping its heart out ?
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

sinsi

From the Intel docs
QuoteThe HLT instruction is a privileged instruction. When the processor is running in
protected or virtual-8086 mode, the privilege level of a program or procedure must
be 0 to execute the HLT instruction.
Makes sense I suppose. You don't want a DOS program to halt everything, especially in a single CPU case...
Light travels faster than sound, that's why some people seem bright until you hear them.

dedndave

as i remember, it didn't actually halt anything under DOS, either - lol
the first hardware interrupt that came along caused execution to continue
when you issued a HLT instruction on a 4004 or 8008, the world stopped spinning   :P

sinsi

>the first hardware interrupt that came along caused execution to continue
That's the point. This is how you nowadays stop a core that's not needed.
The BSP will send an interrupt to the AP when needed and off it goes.
Light travels faster than sound, that's why some people seem bright until you hear them.

FORTRANS

Quote from: hutch-- on April 30, 2012, 01:19:07 PM
Illuminate me here, with a non-re-entrant OS like MS-DOS, what is the point of looking for a wait instruction/sequence/interrupt when only one task is running ? Surely you just shove a test in the polling loop for something like a keystroke or mouse event (if I vagely remember int 33h correctly) and let the processor ping its heart out ?

Hi,

   Well in this case, the HP 200LX is a palmtop that can be running
on 2 AA batteries.  So reducing CPU usage prolongs the time between
chargings.

   Thanks for the Intel quote sinsi.  Makes some sense.  Though the
PM OS should process the exception.  But it could possibly wait before
returning to the RM/V86 program.  Seems that these don't.

Regards,

Steve N.

sinsi

>Though the PM OS should process the exception.
"Processes it" as in "ignores it" I guess. It does throw an exception.
Light travels faster than sound, that's why some people seem bright until you hear them.

MichaelW

For those running heavily overclocked Pentiums under DOS, it might be useful to keep the CPU from frying, while waiting at maximum speed :toothy

Come to think of it, when I used to routinely run DOS apps I sometimes had problems with the NTVDM CPU usage being so high that everything else slowed to a crawl. Periodic calls to the MS-DOS Idle Call function could have solved this problem, and done right, with no perceptible effect on the speed of the DOS app.
eschew obfuscation