Announcement

Collapse
No announcement yet.

TSR Programming in PB Dos 3.5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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>

    Leave a comment:


  • Mike Luther
    replied
    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:

    Code:
    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]

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Mike Luther
    replied
    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]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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>

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Guest's Avatar
    Guest started a topic TSR Programming in PB Dos 3.5

    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>
Working...
X