Thread: TSR to detect video mode

  1. #1
    Registered User
    Join Date
    Mar 2004

    TSR to detect video mode

    Hi!! I was exploring a few dos softwares , while doing so it clicked me to find out the video mode in which they were working. So i'm trying to write down a program to detect the video mode in which a aprticular program is running.
    I actually planned that i'll write a TSR which i'll load before running the target program,then run the target program and on pressing a key or a key combination the TSR will come into picture and display the video mode or wite it onto a file which can be read later.
    the problem is that to invoke the TSR an interrupt has to occur (for example keyboard interrupt here) and to detect the video mode i'll have to use int86 funtion which issues an interrupt BUT another interrupt cannot occur untill the TSR has executed. WHAT CAN I DO NOW
    please help
    i'm using Turbo C++ 3.0 compiler

  2. #2
    Been here, done that.
    Join Date
    May 2003
    Writing to a file is difficult. I never spent enough time to figure out exactly how it's done, but it takes triple checks to make sure it's safe to open a file.

    Writing to the screen is workable, as long as you can write the the proper screen memory.

    Simply have two hotkeys:
    1) save the screen data that's to be overwritten to a buffer and output the mode
    2) restore the buffer to the screen.

    Other interrupts should not affect your TSR since yours is only looking for the hotkeys specified. Other keys are passed thru to the keyboard interrupt.
    Definition: Politics -- Latin, from
    poly meaning many and
    tics meaning blood sucking parasites
    -- Tom Smothers

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    DON'T invoke a DOS interrupt from inside of a TSR unless you first check the INDOS flag via int 21h INDOSFLAG check. This check will not cause DOS to re-enter itself.

    If you do not do the check it is possible that DOS has invoked an interrupt which if you invoke another it will cause problems. It is also possible that DOS is inside of a DOS interrupt handler and invoking int 21h will cause DOS to re-enter itself. DOS is not re-entrant so this will cause a major crash - possible CPU triple fault which will reset the computer.

    Here are some guideline from the DOS 6 tech ref concerning TSRs:


    1. Make sure the TSR is not already loaded.
    2. Install the interrupt handler or handlers.
    3. Free unneeded resources
    4. Call Keep program (INT 21h Function 31h)

    You should use interrupt 2Fh or the multiplex interrupt as a check to whether or not your TSR is already loaded.

    You must install interrupt handlers via INT 21h function 25h. You should save the current handler via INT 21h function 35h and this should be restored when the TSR is removed from memory.

    Before calling Keep program:

    1. Close all unneeded files including standard devices.
    2. Free the environment block if it is not needed.
    3. Free all memory not needed to support the interrupt handler.

    If your handler uses MS-DOS functions:

    1. You MUST check the InDOS flag before calling a function and MUST check the ErrorMode flag before calling any character I/O functions (INT 21h functions 01h - 0Ch).

    2. If the InDOS flag is non-zero the interrupt handler can only call the character I/O functions - it MUST not call any other MS-DOS system functions. To retrieve the address of the InDOS flag through int21h function 34h.

    3. The ErrorMode flag indicates whether or not MS-DOS is currently processing a critical disk error. If it is, the flag is non-zero and the interrupt handler MUST NOT call any MS-DOS system function, including the character I/O functions. The ErrorMode flag is a one byte flag that is immediately before the InDOS flag. You can retrieve the InDOS flag address and subtract 1 from its address to point to the ErrorMode flag.

    4. The handler MUST check whether any ROM BIOS routine it calls directly has been interrupted and it MUST NOT call an interrupted ROM BIOS routine that is not re-entrant. MS-DOS provides no mechanism for checking whether a ROM-BIOS routine has been interrupted so the handler must intercept these interrupts and record when control enters and leaves these routines. The handler can check this record before making a call to the ROM-BIOS.

    5. The handler MUST NOT continue if another hardware interrupt is being processed. To determine whether and interrupt is active the TSR must query the system interrupt controller.
    EDIT: I believe checking the IF or interrupt flag will suffice for this, but I could be wrong.

    There are several more rules regarding TSRs and open files and/or file handles, PSP, DTA (disk transfer address), etc.
    Before attempting this you should read up on DOS TSR's either in the DOS tech ref or via the net.

    This is only valid for DOS 6.20. It is likely that under Windows much of this will not work correctly and to be sure under XP command will NOT support any of this.
    Best bet is to be in a pure DOS environment.

  4. #4
    Registered User
    Join Date
    Mar 2004

    thanx guys

    thanx guys for u support
    i finally got a solution in an old book lying with me

    thanx again

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Your handler must do all of what I posted if you plan on using DOS or ROM BIOS interrupts in it. If not your code will be unstable at best.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. console mode and service mode
    By George2 in forum C# Programming
    Replies: 0
    Last Post: 06-01-2008, 01:42 AM
  2. 6 measly errors
    By beene in forum Game Programming
    Replies: 11
    Last Post: 11-14-2006, 11:06 AM
  3. video mode
    By sunil21 in forum A Brief History of
    Replies: 4
    Last Post: 04-28-2004, 02:33 AM