Dec 132017
 
Screen blank device driver.
File SCRNBLNK.ZIP from The Programmer’s Corner in
Category Display Utilities
Screen blank device driver.
File Name File Size Zip Size Zip Type
SCRNBLNK.8 6912 1847 deflated
SCRNBLNK.DOC 4224 1765 deflated
SCRNBLNK.SYS 326 285 deflated

Download File SCRNBLNK.ZIP Here

Contents of the SCRNBLNK.DOC file


SCRNBLNK.SYS by Bob Montgomery - a device driver for blanking the
CGA, EGA, or Monochrome (including Hercules) screen after five
minutes of no keypresses.

This device driver should be included in the CONFIG.SYS file (in the
root directory of the default drive) as 'device=scrnblnk.sys'
(without the quotes). The device driver must also reside in the root
directory. It should be placed in the CONFIG.SYS file after any ANSI
type driver, which changes some keypresses. It should be before any
devices which print messages, so it will blank the screen if not
responded to within 5 minutes. This program is a modification of
EGABLANK.COM described in PC Magazine, Sept. 30, 1986 by Charles
Petzold in his column PC Tutor. It was converted to a device driver
because my password program is also a device driver (so it can't be
avoided with Cntrl-Break), and was not blanked by EGABLANK.COM until
the user responds to the password and the AUTOEXEC.BAT file is run.
Sometimes someone would turn on the machine, and not knowing the
password, would walk away and leave the password prompt on the
screen. It would not be blanked because EGABLANK.COM would not be
installed until the AUTOEXEC.BAT file is run, and this wouldn't
happen until the password was given. While I was at it, I included
the code to blank the CGA and Monochrome screens by controlling the
video enable bit in the CGA and Monochrome mode control register.

The source code (in A86 assembler format) is included for those
interested in how it works, and is a good example of how to write a
character type device driver. It can be converted to MASM format by
adding the required ASSUMEs, SEGMENT, ENDS, END, etc. Basically, when
DOS sees a device in CONFIG.SYS, it loads it and then calls the
Strategy routine and passes the address of the Request Header (RH)
for that device in ES:BX. The Strategy routine must store the RH
address in the program data area, and do a far return to DOS. Next,
DOS calls the Interrupt routine to allow the device to initialize
itself; in this case, the vectors for Int 8, 9, and 16 are pointed to
the program, and the old vectors saved so the interrupt processing
chain is not broken. Then, the program writes the address of the
first byte not required for the resident portion of the program
(generally the Strategy and installation code) in the RH Data area
and sets the done bit in the RH Status byte (thats why we had to save
the address of the Request Header), and far returns to DOS. From then
on, all Int 8 (clock ticks), Int 9 (keyboard outputs), and Int 16
(video updates) are routed to the program and control when the screen
blanks and unblanks. Since this device has a very weird name, it is
unlikely to be typed (even inadvertantly), which would trigger DOS to

send info to or try to get info from the device, and cause strange
things to happen.

After initializing, the program starts with the count for 5 minutes
in a memory location. At each clock tick (18.2 times/sec), the count
is decremented by the Int 8 routine in the program. If it gets to
zero, the screen is blanked. Meanwhile, every time a key is pressed
(or released) or a video update occurs, the Int 9 or Int 16 routines
in the program reset the count to the 5 minute value. If the count
was zero when Int 9 or 16 occured, the screen is unblanked. The delay
value can be changed using DEBUG; see the formula in the Delay EQU
directive at the start of the source code. It appears in only one
place (the Setcount subroutine), and can be changed with the E
DEBUG command.

If you have any comments or suggestions, I can be contacted at the
Black Hole BBS in Orlando, Fl. (305) 260-6397, 1200/2400 baud.
Bob Montgomery


 December 13, 2017  Add comments

Leave a Reply