🚀 go-pugleaf

pas@lcs.mit.edu (Paul A. Selkirk) writes:
>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>2.x or 3.x) is idling in the command interpreter, or executing a program?

not off hand...
 
>For the record, I am writing a screen-saver TSR that will only trigger when DOS
>is idling.  There are dozens of screen-savers, but I need one that won't kill
>a lengthy graphics program.  (Ever try generating the Mandelbrot set on a 4.77 
>MHz XT with no FPU?  I thought so.)

How about this, run the screen saver off of the timer interrupt.  If
the correct amount of time has passed, then change the pallette to all
black (if EGA or VGA) or do a memory copy of the screen and blank it 
(if < EGA).  While the screen is blank, the screen saver won't stop
any program that's currently running, but will latch on to the
keyboard or mouse interrupt.  And, of course, when the keyboard/mouse
interrupt is caught, you simply restore the screen by restoring the
palette (if >= EGA), or copy the screen back into video memory (if
< EGA).

This sounds like it might be a more elegant solution and you won't
have to worry about losing that Mandlebrot you've been generating for
the last xx hours...and probably just as important, it won't stop that
Mandlebrot while it's generating.  The only thing that could hurt this
is that if a program decides to modify the palette while the screen is
blanked.  I don't know EGA very well, but I bet there's probably a way
to intercept incoming commands to change the palette, and what you'd
do is intercept that and change what you've saved the palette as
appropiately.

TrevorB


-- 
 _____   _____   _____   _   _    ___    _____                       _____
(_   _) |  _  \ | ____) | | | |  / _ \  |  _  \      InterNet:      |  _  )
  | |   |  _  / | __)_  | |_| | ( (_) ) |  _  /  tbechtel@polyslo.  |  _ (
  |_|   |_| \_\ |_____)  \___/   \___/  |_| \_\     calpoly.edu     |_____)

I have a screen-blanker that will not destroy graphics screens, and can be
restored by simply pressing a Shift key, or Ctrl or Alt.  If anyone would
like a copy, send me email, and I'll ship it out next week (when I can get
to it).

BTW:  It also automatically parks hard disks.


Virtually,
- Charles Martin Hannum II       "Klein bottle for sale ... inquire within."
    (That's Charles to you!)     "To life immortal!"
  cmh117@psuvm.{bitnet,psu.edu}  "No noozzzz izzz netzzzsnoozzzzz..."
  c9h@psuecl.{bitnet,psu.edu}    "Mem'ry, all alone in the moonlight ..."

Uh, to elaborate ...  The program I referred to in my last article *will*
allow whatever you're running to continue.

In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu (Paul A. Selkirk) writes:
>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>2.x or 3.x) is idling in the command interpreter, or executing a program?

>I have determined, through much pain and disassembly, that DOS uses service
>0A (buffered string input) to get the next command, but other programs use that
>as well.  I can get by on this knowledge, but I would prefer something a little
>more certain.

>For the record, I am writing a screen-saver TSR that will only trigger when DOS
>is idling.  There are dozens of screen-savers, but I need one that won't kill
>a lengthy graphics program.  (Ever try generating the Mandelbrot set on a 4.77 
>MHz XT with no FPU?  I thought so.)

>Any leads will be duly appreciated.

Quoting from chapter 16 of a preliminary version of "A Textbook on the
8086 Family" by William B. Giles, Copyright 1989, to be published by
MacMillan Publishing Company in October, 1990:  (I reviewed it for
MacMillan and am using it in a class!  Any typo's are probably mine.)

  "DOS keeps a one-byte flag, which is usually called the InDOS flag
   or the DOS Active byte.  The value of this flag at any instant
   equals the number of calls to INT 21h functions which are currently
   in process of execution.  In particular, if the value is zero no
   DOS function is presently active and so DOS functions can be safely
   called.  Finding the value of the InDOS Flag is easy: a call to
   function 34h of INT 21h returns the address of the flag in es:bx."

Furthermore (a paragraph or two later):

  "... But even when DOS is busy, it may not be executing a non-
   interruptible section of code; during such "safe" periods, DOS
   makes regular calls to INT 28H."
   
  "The sole reason for the existence of INT 21h is to provide
   programmers with another method of determining whether it is safe
   to execute DOS functions.  If INT 28h is active, DOS is in a safe
   condition."
   
  "A number of the traditional DOS functions (01h through 0Ch) must
   wait for user input and, during such waiting periods, they call
   INT 28h repeatedly.  In particular, while the DOS prompt is being
   displayed and DOS is calling function 01h, the INT 28h method can
   be used to determine when it is safe to execute DOS function calls."

To actually use the above requires a "trick" almost like that of
writing device drivers.  When your TSR determines it needs to do
something, usually it should just set an internal flag to remind
itself of that fact.  Then it can make periodic tests (by taking
over the timer interrupt) and/or take-over INT 28h to determine
when it is safe to actually do the desired work.

Hope this helps.
--Myron.
--
#-------------------------------------------------------------------------
# Myron A. Calhoun, Ph.D. E.E.; Associate Professor   (913) 539-4448 home
# INTERNET: mac@harris.cis.ksu.edu   (129.130.10.2)         532-6350 work
# UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac             532-7004 fax

In article <PAS.90Mar1120125@saffron.lcs.mit.edu> Paul A. Selkirk writes:
>
>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>2.x or 3.x) is idling in the command interpreter, or executing a program?
>
>       .... rest omitted ....

I think you can accomplish what you want by using three undocumented
DOS functions:

	1)	int 21h function 34h -- Get DOS Busy Flag.
		on return, ES:BX will point to DOS Busy Flag; if this
		byte is nonzero, a DOS function is in progress.
	2)	int 28h -- DOS Safe Interrupt.
		this interrupt is called by DOS whenever it's sitting
		idle, waiting for keystrokes.
	3)	int 21h function 62h -- Get Current PSP.
		on return, BX will contain the current PSP segment.
		Prior to DOS 3.00, use function 51h.

When your TSR first executes, get the address of the DOS Busy Flag & store it
for future use (you don't want to have to call function 34h each time).
Also latch onto interrupt 28h, so you'll be called when DOS is idle.

Then, each time your TSR is activated later, check the DOS Busy Flag byte.
If it's zero, call Get Current PSP and peek around in its address space
to see if it's COMMAND.COM.

I haven't tried any of this, but it seems to me that it should work.
Let me know how it goes.

There are two ways to find out, and you really need to do both.  The first
way, which is the most reliable, is to hook into interrupt 28h, sometimes
known as the "DOS-Idle" interrupt.  MS-DOS calls this whenever it is waiting
for some event, like a keystroke.  *Almost* all the MS-DOS functions are
safe to use at this point.  (I'm not sure which ones aren't.)  This interrupt
is used by the print.com print spooler.  I also used it for my Printscreen
TSR I'm working on; it buffers the screen in memory until DOS-Idle tells it
that it's safe to write to the disk.  Be sure to pass on the interrupt by
calling whoever had to vector before you, or else a lot of other TSR's will
die when yours is installed.

The other flag to check is the "DOS-Busy" flag.  You can find out its
location by calling int 21h, function 34h.  The flag address will be returned
in the ES:BX pair.  This flag is 1 if MS-DOS is active, and 0 if it isn't.
Watch out though, since according to the flag, MS-DOS is active when it's
at the command prompt!  That's why you may need to use both techniques.

            <=> Stephen Trier    sct%seldon@skybridge.SCL.CWRU.Edu
                                 {sun,att,decvax}!cwjcc!skybridge!seldon!sct
                                 sct@po.CWRU.Edu

In the quoted article Myron A. Calhoun writes:

>In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu \
>(Paul A. Selk:
>>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>>2.x or 3.x) is idling in the command interpreter, or executing a program?
[text deleted]
>>a lengthy graphics program.  (Ever try generating the Mandelbrot set on a \
>>4.77 
>>MHz XT with no FPU?  I thought so.)
>>
>>Any leads will be duly appreciated.
>
>Quoting from chapter 16 of a preliminary version of "A Textbook on the
>8086 Family" by William B. Giles, Copyright 1989, to be published by
[text deleted]
>
>  "DOS keeps a one-byte flag, which is usually called the InDOS flag
>   or the DOS Active byte.  The value of this flag at any instant
>   equals the number of calls to INT 21h functions which are currently
>   in process of execution.  In particular, if the value is zero no
>   DOS function is presently active and so DOS functions can be safely
>   called.  Finding the value of the InDOS Flag is easy: a call to
>   function 34h of INT 21h returns the address of the flag in es:bx."
>             
>Furthermore (a paragraph or two later):
>
>  "... But even when DOS is busy, it may not be executing a non-
>   interruptible section of code; during such "safe" periods, DOS
>   makes regular calls to INT 28H."
>   
>  "The sole reason for the existence of INT 21h is to provide
>   programmers with another method of determining whether it is safe
>   to execute DOS functions.  If INT 28h is active, DOS is in a safe
>   condition."
>   
>  "A number of the traditional DOS functions (01h through 0Ch) must
>   wait for user input and, during such waiting periods, they call
>   INT 28h repeatedly.  In particular, while the DOS prompt is being
>   displayed and DOS is calling function 01h, the INT 28h method can
>   be used to determine when it is safe to execute DOS function calls."
>
>To actually use the above requires a "trick" almost like that of
>writing device drivers.  When your TSR determines it needs to do
>something, usually it should just set an internal flag to remind
>itself of that fact.  Then it can make periodic tests (by taking
>over the timer interrupt) and/or take-over INT 28h to determine
>when it is safe to actually do the desired work.

While the above information is essentially correct,  it requires some
elaboration.  The int 21h dispatcher works with three different stacks.
The way in which the dispatcher manipulates these stacks severely
hampers re-entrency.

(1) One must record the critical section flag address (int 21h ah=34h)
    when a tsr starts up.  It is potentially disasterous to issue
    this request at random times because its processing can cause a
    stack switch.

(2) The address of the critical error flag must also be recorded.  In
    dos 3.x it is adjacent to the critical section flag.  Before processing
    a critical error,  dos decrements the critical section flag and
    increments the critical error flag.

(3) When DOS issues an int 28h,  it is safe to make int 21h requests
    with ah > 0ch.  Requests in the ah=1h to 0ch are "character" i/o reqests
    and are serviced on one stack;  those ah>0ch are "disk" i/o requests
    and are serviced on a different stack.  Any attempt to issue int 21h
    ah=1 to 0ch could result in trashing a dos stack.

(4) Some of the "character" i/o functions are output functions.  Int 28h
    gets called periodically when dos is writing characters (every fourth
    character if memory serves me correctly).  This may be an inopportune
    time for a screen saver to kick in.

(5) Doing I/O behind DOS's back (in an isr) requires some careful preparation
    even if it is safe to carry out.  One must establish critical error and
    break handlers and change the current PSP.

Walt Dixon		{arpa:		dixon@crd.ge.com	}
			{us mail:	ge crd			}
			{		po box 8		}
			{		schenectady, ny 12301	}
			{phone:		518-387-5798		}

Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc.programmer
Subject: Re: idling in the interpreter
Summary: 
Expires: 
References: <PAS.90Mar1120125@saffron.lcs.mit.edu> <25EDB1B8.4B34@deimos.cis.ksu.edu>
Sender: 
Reply-To: dixon@sagittarius.crd.ge.com (walt dixon)
Followup-To: 
Distribution: usa
Organization: General Electric Corp. R&D, Schenectady, NY
Keywords: 



Walt Dixon dixon@crd.ge.com

In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu (Paul A. Selkirk) writes:
>
>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>2.x or 3.x) is idling in the command interpreter, or executing a program?
>
>I have determined, through much pain and disassembly, that DOS uses service
>0A (buffered string input) to get the next command, but other programs use that
>as well.  I can get by on this knowledge, but I would prefer something a little
>more certain.
>
>For the record, I am writing a screen-saver TSR that will only trigger when DOS
>is idling.  There are dozens of screen-savers, but I need one that won't kill
>a lengthy graphics program.  (Ever try generating the Mandelbrot set on a 4.77 
>MHz XT with no FPU?  I thought so.)
>
>Any leads will be duly appreciated.
>
>				paul

How about a way of turning screen saver on and off instead.  You can have
an interupt which turns screen saver on and off then write a utility which
calls the interupt which you can run before your program.  You can also
have a keyboard hook to turn it on and off asynchronous to the system state.
In cases where you have access to source code you can turn off the saver
within a program just for the parts where this is important.  I'd suggest
something like the following

    AH = 0    Turns off screen saver
    AH = 1    Turns on screen saver
    AH = FF   Returns 1234H or something unique to determine presence.

I would have it also return the current active state so that programs
could restore the system when necessary.

-- 
D'Arcy J.M. Cain (darcy@druid)     |   Thank goodness we don't get all 
D'Arcy Cain Consulting             |   the government we pay for.
West Hill, Ontario, Canada         |
(416) 281-6094                     |

In article <25ed7a61.29c1@polyslo.CalPoly.EDU> tbechtel@polyslo.CalPoly.EDU (TrevorB) writes:
>
>pas@lcs.mit.edu (Paul A. Selkirk) writes:
>>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>>2.x or 3.x) is idling in the command interpreter, or executing a program?
[...]
>>is idling.  There are dozens of screen-savers, but I need one that won't kill
>>a lengthy graphics program.
[...]
>How about this, run the screen saver off of the timer interrupt.  If
>the correct amount of time has passed, then change the pallette to all
>black (if EGA or VGA) or do a memory copy of the screen and blank it 
>(if < EGA).  While the screen is blank, the screen saver won't stop
>any program that's currently running, but will latch on to the
>keyboard or mouse interrupt.  And, of course, when the keyboard/mouse
>interrupt is caught, you simply restore the screen by restoring the
>palette (if >= EGA), or copy the screen back into video memory (if
>< EGA).

You don't need to mess with screen copying and pallette saving and restoring.

The following code will do the trick for VGA by setting a bit in the
sequencer that indicates that video access to the memory should be dissabled.
The result of this is that the screen blanks.

        mov     dx,3c4h                 ; Sequencer index
        mov     al,1                    ; Clock register
        out     dx,al
        inc     dx                      ; Point to data
        in      al,dx                   ; Get it
        or      al,20h                  ; Set video disable bit
        out     dx,al                   ; And set it

On the other cards (CGA, MDA etc.) you clear the screen enable bit in the
mode select register.  The following code illustrates it:

data            segment at      40h
                org     49h
crt_mode        db      ?
crt_cols        dw      ?
crt_len         dw      ?
crt_start       dw      ?
cursor_pos      dw      8 dup(?)
cursor_mode     dw      ?
active_page     db      ?
addr_6845       dw      ?
data            ends

        mov      ax,40h                 ; Address of data area
        assume   cs:code,ds:data,es:nothing
        mov      ds,ax                  ; Establish addressability
        mov      dx,addr_6845           ; Primary card address
        add      dx,4                   ; Address of 3X8 register (mode select)
        mov      al,crt_mode_set        ; See old value
        and      al,not 1000b           ; Make the display enable 0
        mov      crt_mode_set,al        ; Save it
        out      dx,al                  ; Out it

Diomidis
--
Diomidis Spinellis                  Internet:                 dds@cc.ic.ac.uk
Department of Computing             UUCP:                    ...!ukc!iccc!dds
Imperial College                    JANET:                    dds@uk.ac.ic.cc
London SW7 2BZ                      #include "/dev/tty"

In article <25EDB1B8.4B34@deimos.cis.ksu.edu> mac@harris.cis.ksu.edu (Myron A. Calhoun) writes:
>In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu (Paul A. Selkirk) writes:
>>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>>2.x or 3.x) is idling in the command interpreter, or executing a program?
>
>  "DOS keeps a one-byte flag, which is usually called the InDOS flag
>   or the DOS Active byte.  The value of this flag at any instant
>   equals the number of calls to INT 21h functions which are currently
>   in process of execution.  In particular, if the value is zero no
>   DOS function is presently active and so DOS functions can be safely
>   called.  Finding the value of the InDOS Flag is easy: a call to
>   function 34h of INT 21h returns the address of the flag in es:bx."
>

[lots of interesting stuff deleted]

The Waite Group's MS-DOS Developer's Guide, second edition, goes into
the area of using the above function and int 28h.  Neither of these
functions is documented, so you pay your money and take your risks...
Anyway, according to the Waite Group there are 'some peculiarities
regarding the DOS busy flag in various versions of MS-DOS.  Under
MS-DOS 2.10, the byte immediately after the DOS busy flag must be set
to 00 to permit the PRINT.COM interrupt to be called.  For MS-DOS 3.0
and 3.1 (except COMPAQ DOS 3.0), the byte before the DOS busy flag
must be zero;  for COMPAQ DOS 3.0 the byte 01AAh before it must be
zero.'  (pp744-745).  Any typos in the above are probably mine, also,
I should note that I haven't actually tried to use the features
described here, but I have found the MS-DOS Developer's guide to be
quite reliable...  Hope this isn't too misleading,

-tom

-- 
===============================================================================
webb@uhccux.uhcc.Hawaii.edu  "The first duty in life is to assume a pose.
                              What the second is, no one has yet
					discovered."            -Oscar Wilde

In article <25ed7a61.29c1@polyslo.CalPoly.EDU> tbechtel@polyslo.CalPoly.EDU (TrevorB) writes:
>(if < EGA).  While the screen is blank, the screen saver won't stop
>any program that's currently running, but will latch on to the
>keyboard or mouse interrupt.  And, of course, when the keyboard/mouse
>interrupt is caught, you simply restore the screen by restoring the
>palette (if >= EGA), or copy the screen back into video memory (if
>< EGA).

Ok.. I'll bite.

Does anyone know of a screen saver that REALLY succeeds in this endeavor?

EVERY one I have tried (10+) has flunked the graphics + mouse test.
Ie.. there I am, working away with a graphics program + mouse (FRACTINT),
and .. kapooeee.. the screen goes blank, regardless of mouse activity!
-- 
 ______Mark S. Lord______________________ ______________________________
|    ..uunet!bnrgate!carrsc!mlord        | These are only MY opinions.  |
| or:  bnr-rsc!mlord@bnrgate             | I charge for official views. |
|________________________________________|______________________________|