How can I delay smth on screen? 2

[Joshhhhh]

for example if i have the following lines:
mov ah,09h
mov al,':'
mov bh,0
mov bl,7
mov cx,1
int 10h

mov ah,0
int 16h
in a tsr program. My program displays the character -- : -- until i press a key and then it comes back to the initial screen. That's what I did..

What i should have done is that the character to be displayed for a certain number of seconds and then the prog. to come back to the main screen.
i've tried to do this :
mov count,0
A:
inc count

mov ah,09h
mov al,':'
mov bh,0
mov bl,7
mov cx,1
int 10h
;this is where i restore the screen
cmp count,100
jne A
doesn't work
little help

 

[bluetongol]

i am not really sure what's your reason for making
such program but you could have done it without
using tsr:

mov ah,02
mov dl,":"
int 21h

mov cx,0
loophere1:
mov dx,0
loophere2
dec dx,1
jnz loophere2
loop loophere1

mov ax,4c00h
int 21h

 

[strettonman]

If you use int 10H in a TSR program there is a good chance it will crash. There are very few interrupts which can be called from within a TSR without taking elaborate precautions, and int 10H isn't one of them. The best thing to do would be to write directly to video buffer at 0B800:0000.

With processor speeds currently around 2GHz and more, it will certainly take more than 100 iterations around a loop to introduce any kind of noticable delay. You will have to try some extravagant experiments, and the more extravagant the better. Perhaps you could start with:

mov cx, 65535
L1:
push cx
mov cx, 65535
L2:
push cx
mov cx, 256
loop $
pop cx
loop L2
pop cx
loop L1

If that doesn't do it, try increasing the 256 until it does.

 

[Joshhhhh]

Well thank you,it works both ways.

bluetongol: It was a tsr program because I'm now learning assembly and I had to write a program that shows smth on screen for a couple of seconds and than give the control to the operating system.

 

[lionelhill]

Another convenient way to make a delay that doesn't depend greatly on processor speed is to wait for a certain amount of screen refreshes, relatively easily available from any standard VGA (which is something you're assuming already as soon as you write to screen memory directly).

The reason you cannot call most interrupts from most TSRs is that most interrupt handlers are not re-entrant. That is to say that they are not designed to be called from within themselves. Since TSRs are often designed to be triggered at any random time, you cannot be sure that the processor wasn't already half way through executing the interrupt when the TSR called the interrupt again. If the interrupt keeps certain information in a definite place (rather than a stack) then the second call to the interrupt will overwrite the information that the first call was using. On returning to the first call, the information will be wrong, and the interrupt will do the wrong thing, or crash.