No announcement yet.

TSR Programming in PB Dos 3.5

  • Filter
  • Time
  • Show
Clear All
new posts

  • TSR Programming in PB Dos 3.5

    This message is more of a "How does it Work" question than a
    support question. I am trying to learn more about how the TSR
    functions work in PB DOS 3.5. I have looked through the source
    code examples on this forum and the example that came with PB 3.5.
    My question is, Can a TSR be built that actually runs more as a
    background program than a popup program? In other words, I am
    looking to have a program run in the background continuously while
    my foreground application runs as the main application. I don't
    need any screen access for this background program.
    The reason for this request is, I am thinking of writing a background
    application that will collect counts from an external sersor and
    store them to a memory location for the forground application to
    access when needed. But timing is critical and that is why I need
    to understand more about the way TSR's work. Any help in this matter
    would be greatly appreciated.

    mailto:[email protected][email protected]</A>

  • #2
    DOS isn't designed for multitasking. However, it is possible for one application to be paused while another one's running, which is the basic idea of a TSR. If your sensor generates an interrupt, or is accessed through a device (like a serial port) that can generate interrupts, you might do well with POPUP INTERRUPT. If not, perhaps POPUP TIMER would get you there. Check your manual for more details.

    Tom Hanlin
    PowerBASIC Staff


    • #3
      To have the background program pause while the forground program
      ran would probably not work for me because of the critical timing
      I am dealing with. If it were to pause too long counts would be
      missed. My current application has one main loop that services all
      of the keyboard input plus checks the state of the switch. This so
      far has been usable but I was looking for a better way. I guess I
      pretty much knew your answer before I asked the question. Multi-
      tasking and DOS just don't go together. I guess there is always
      the old approach to multitasking... Does anyone remember Deskview!!
      It was a nice approach to enhancing DOS.



      mailto:[email protected][email protected]</A>


      • #4
        Rick ..

        An associate of mine who specialized for a while with TSR's that
        ran in the background once told me his answer for this.

        To assure timing sequencing between the TSR running in the background
        and the main application, the trick is to CHAIN the TIMER TICK,
        not to steal it!

        The TSR has to operate on the basis of the timer tick, but pass it
        on to the main application as well. That done, you have to remember
        that for all purposes, DOS doesn't know a darned thing about what
        is really going on with that running TSR in the background. It is
        in the position where it has to do its work when the foreground can
        be idled in step-sequence with it. That also means that, for example,
        disk I/O has to be carefully considered such that the TSR can't do
        that while the foreground application is doing such things as well.

        What you are doing is actually time slicing the CPU so that a part
        of the time is given to the TSR and a part to the main application
        and the two both get access to the timer tick for syncronization
        between them ..

        So he said ... All his work was in C and Assembler. I pose nothing
        as an expert in the art, simply explaining how it can be done, as
        it was taught to me...

        Instead of learning TSR's ...

        I bought OS/2 . threw DesqView away and never looked back. Once
        exposed to what OS/2 could do even nearly ten years ago, I got so
        spoiled, at what could be done with even ten or twenty DOS apps
        all running at once .. I stumbled and fell and never went to WIN at
        all! Was totally un-necessary for what I needed .. sigh ..

        I suspect that if WIN-2000 is even close to what OS/2 has been for
        all these years, a great many folks with dedicated needs that do
        not need WIN at all ... could get totally blissfully away with
        no TSR's .. just by doing what I do and passing the needed interface
        work silently to the disk for a tone of stuff more than a TSR could
        ever be expected to do in VERY complex work ...

        Of course, with WIN-NT and OS/2 native, you can go to threading and
        put it all in one giant master program as well, but that't the rest
        of the story ...

        Mike Luther
        [email protected]
        Mike Luther
        [email protected]


        • #5
          I wouldn't just assume that it won't work. Unless your data is coming in at extreme speed, it might be perfectly reasonable to have the TSR capturing the data via POPUP INTERRUPT, without causing trouble with the operation of your main program.

          Tom Hanlin
          PowerBASIC Staff


          • #6
            Tom ..

            I've enough interest in what POPUP INTERRUPT to test it, even
            though I'm so spoiled by the ability to run a gaggle of PB 3.5
            apps all at once. Assuming things gets one in trouble; I'm just
            as quilty about that as anyone else..

            Lance's suggestion to solve the CPU trashing in WIN:

            10  WHILE ISFALSE INSTAT
                   IF ISTRUE BIT(pbvHost,8%) THEN
                      ! push DS
                      ! mov AX, &H1680
                      ! int &H2F
                      ! pop DS
                   END IF
                A$ = INKEY$
                PRINT A$;
                   IF A$ <> CHR$(13) THEN
                      GOTO 10
                   END IF
            Works *FINE* in DOS-VDM sessions in OS/2 as far as I can see! It
            had been suggested here before, by Dave Navarro, I think. It was
            cast, as I recall, as a WIN-only solution .. so I assumed!

            Now, if it also works on a plain DOS box that has no networking
            and so on as well ... then ... WONDERFUL!

            Much like this one, if the POPUP INTERRUPT deal would work in
            ODS-VDM sessions as well, I can see a number of uses for it that
            would enhance some things...

            Thank you for your thoughts and work. ..

            Mike Luther
            [email protected]
            Mike Luther
            [email protected]


            • #7
              I haven't given up on it yet. I think I will try to develop the TSR
              and test it for it's theoretical top speed. I am looking at a maximum
              count speed of 50,000 pieces per hour. This is the reason for the
              critical timing questions.


              mailto:[email protected][email protected]</A>


              • #8
                Glad I could help. On the mux function &H1680, Ralf Brown's interrupt list has this to say:

                Notes: programs can use this function in idle loops to enhance performance
                under multitaskers; this call is supported by MS Windows 3.0, DOS 5+,
                DPMI 1.0+, and in OS/2 2.0+ for multitasking DOS applications
                does not block the program; it just gives up the remainder of the time
                should not be used by Windows-specific programs
                when called very often without intermediate screen output under WIN 3+,
                the VM will go into an idle-state and will not receive the next slice
                before 8 seconds. This time can be changed in SYSTEM.INI through
                "IdleVMWakeUpTime=<seconds>". Setting to zero results in a long wait.

                So, it apparently works on a great number of platforms. If your program may be run on DOS 2.x machines, it would pay you to make sure that INT 2Fh has been initialized...

                Without knowing more about it, I can't say for sure but, at an average of 14 items/second, it seems unlikely that you'll strain the processor. Depends on how much data there is per item and what the maximum burst rate is.

                Tom Hanlin
                PowerBASIC Staff