TIP: Click on subject to list as thread! ANSI
echo: 80xxx
to: SYLVAIN LAUZON
from: GLEN MCNABB
date: 1997-03-23 19:33:00
subject: Re: Unknown function

Hi Sylvain,
SL>  > and switches to the next... and so on....  Task priorities
SL>  So, a pure multitasking OS like OS/2 isn't a real one (?). If all it 
oes
SL>  is switches from a task to another.
SL>  Having 2 CPU in one motherboard is real a multitasking system?
Not exactly.... Having two cpu's in a motherboard is equal to having
two computers in a single circut board. Each is doing one task at a
time....
Having a computer that has "true multitasking" microprocessor and
the operating system for it, is usually beyond the cost and needs
of an average "single" person.
What your describing is a called a multibus computer. It can have up
to any number of CPU's in it. It is likely to have a BAU or
Bus Arbitration Unit. It's purpose is to sorta "oversee" the sharing
of drives, memory, and other devices. It's one of many different
co-processors besides the ???87 numeric co-processor. Intel themselves
have a whole variety of co-processors for that chipset that doesn't
come on a dos machine.
SL>  > called the "indos flag". This is one byte that is examined by
SL>  When just writing to the console(TSR clock), might this indos flag be
SL> checked?
If your gonna use dos function calls, it is important to check this
flag.... I gonna assume that you need to know how to get to this
flag...
You need to call DOS function 34h, int 21h to get the address of the
"indos_flag". (also refered to as the "dos activity flag".
mov ah, 034                     ;set function value
int 021                         ;call dos
this returns the address of the "byte" that you need to examine
in the ES:BX......When this byte value equals zero, it is safe
to use a dos function.
Also, your operations during a TSR are not too "stack safe". The
reasons for this are simple. You don't know how much stack is
available for calling functions yourself. The best method is to
set aside memory in your TSR for your own stack operations.
(just to play it safe)
SL>  I've read somewhere about INT 21h/0C and above only might check for this
SL>  flag.
SL>  Print at console is INT 21h/09
SL>  What is your thought?
To be honest.... Don't make assumptions about DOS.... it varies too much
from version to version, and from OEM to OEM. Dos is designed to be a
"single task" operating system. By writing a TSR, you are circumventing
around DOS. To make the TSR reliably work, don't push your luck....
SL>  Print at console is INT 21h/09
I almost never use that function... Mainly because of the '$' terminator.
I end up writing too much code (for businesses) that need to print a '$'
Here's a snippet you can use....
; used to print ascii string to "standard output", string is pointed
; by dx register on call and must be nul terminated
print:                                  ;label called
        push ax
        push bx
        push cx
        push dx
        push di                         ;preserving registers
        push dx                         ;save for fastload di
        pop di                          ;load di
        mov cx, 0ffff                   ;set to loop, or -1 value
        mov al, 00                      ;set cmp value
        cld                             ;set direction flag to up
        repne scasb                     ;scan for 00
        not cx                          ;invert bits, to get count
        mov ah, 040                     ;set to write function
        mov bx, 0001                    ;set to std out
                                        ;cx value already set
                                        ;dx value already set
        int 021                         ;call dos to do it
        pop di                          ;restoring registers
        pop dx
        pop cx
        pop bx
        pop ax
        ret                             ;return to calling function
Nice trick with this one, is that ansi, and control charactors are
acted upon. (it can be redirected though) Load bx with 0002 for
"standard error" which is almost always the screen....
Glen
--- ProBoard v2.15 [Reg]
---------------
* Origin: Bucolic Fair, Pasco WA 1-509-545-5031 (1:3407/25)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.