Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

polling (Announce)

posted by Ninho E-mail, 18.07.2011, 17:28

> Ninho - I appreciate the back and forth of the discussion - this is an area
> I am not very familiar with.

It's alright; In order to be brief and not too boring I not repeat the same things over and over, just try to make'm clearer if I can.

> Lets consider the case of 2F/1680 first. I think that the only concern
> with 2F is ensuring that it is installed first. On a bare system with no
> TSRs the interrupt vector might not be in use; at best if you invoke it
> there is an IRET there and nothing happens. At worse the interrupt vector
> is zero, and the machine blows up.

The vector won't be null on a bare DOS system, no more than say, int 21. It won't be null, and should be a valid callable software int on any system (DOS internally calls int 2F all the time). This is not meant to say you don't want to check, just in case... nuff said 'bout 2F.

> INT 28h is much more interesting ...

> I think you misread me earlier. I don't want to install an INT28 handler.
> I just want to invoke INT28 from my idle loop and if there is an INT28
> handler installed it can do whatever it needs to do.

No I think I understood what you meant to do, and I think it was the bad (TM) idea.

> Everything that I can find says that DOS issues it while waiting for
> keyboard input, and as you pointed out this is something that TSRs might
> want to monitor. Applications normally have no use for this.


> My applications are ill-behaved in that they are constantly polling for I/O
> outside of DOS so this interrupt will never be called. That gives the
> illusion of never having any idle time because I never called DOS functions
> to read the keyboard. This clearly is not the case - I'm just not using
> DOS when my application is in its idle loop.

I think you want to call int 2F/1680 in your polling loop. Windows and other multi taskers will notice the fact that your VM is calling the int repeatedly and adjust their scheduling strategies accordingly. It won't do anything under bare, monotasking, DOS, but there you have no use for those CPU cyles anyway, they aren't wasted; also see next point.

And, load/advise your users load DOSIDLE and SLEEPVM from your/their config or autoexec files. You might be suprised how efficient they are: in VMware and similar boxes, CPU usage will suddenly stay near zero; in real machines running Windows etc, multitasking will be eased; last but not least in stand alone DOS configurations this reduces processor power and heat by halting it (DOSIDLE can optionally make use of Advance Power Management functions of BIOS, not recommended for in virtual machines though).

...
> Clearly if 2F/1680 is working that is the better way to indicate that the
> application is idle. But in the absence of 2F/1680 I know that 28 is still
> available, and it has been in place since DOS 2.x. (It still might not do
> anything useful - that depends on if there is something monitoring it.)

Not that it is not useful, it's use is not that which you imagine. It is one of several "callouts" made by DOS to give TSRs a chance to do their thing.

---
Ninho

 

Complete thread:

Back to the forum
Board view  Mix view
22778 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum