TSR Programming in PB Dos 3.5

[Rick Holcomb]

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>

[Tom Hanlin]

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

[Rick Holcomb]

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.

Thanks

Rick


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

[Mike Luther]

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]

[Tom Hanlin]

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

[Mike Luther]

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
    WEND

    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]

[Rick Holcomb]

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.

Rick


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

[Tom Hanlin]

Mike--
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
slice
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...

Rick--
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