开发者

How can I create a sleep function in 16bit MASM Assembly x86?

I am trying to create a sleep/delay procedure in 16bit MASM Assembly x86 that will, say, print a character on the screen every 500ms. From the research I have done, it seems that there are three methods to achieve this - I would like to use the one that uses CPU clock ticks.

Please note I am running Windows XP through VMWare Fusion on Mac OS X Snow Leopard - I am not sure if that affects anything.

Could someone please point me in the right direction, or provide a working piece of code I can tweak? Thank you!

The code I have found is supposed to print 'A' on the screen every second, but does not work (I'd like to use milliseconds anyways).

TOP:
MOV AH,2C
INT 21
MOV BH,DH  ; DH has current second
GETSEC:      ; Loops until the current second is not equal to the last, in BH
MOV AH,2C
INT 21
CMP BH,DH  ; Here is the comparison to exit the loop and print 'A'
JNE PRINTA
JMP GETSEC
PRINTA:
MOV AH,02
MOV DL,41
INT 21
JMP TOP

EDIT: Following GJ's advice, here's a working procedure. Just call it

开发者_如何学编程
DELAY PROC
 TIMER:
 MOV     AH, 00H
 INT     1AH
 CMP     DX,WAIT_TIME
 JB      TIMER
 ADD     DX,3         ;1-18, where smaller is faster and 18 is close to 1 second
 MOV     WAIT_TIME,DX
 RET
DELAY ENDP


This cannot be done in pure MASM. All the old tricks for setting a fixed delay operate on the assumption that you have total control of the machine and are the only thread running on a CPU, so that if you wait 500 million cycles, exactly 500,000,000/f seconds will have elapsed (for a CPU at frequency f); that'd be 500ms for a 1GHz processor.

Because you are running on a modern operating system, you are sharing the CPU with many other threads (among them, the kernel -- no matter what you do, you cannot take priority over the kernel!), so waiting 500 million cycles in only your thread will mean that more than 500 million cycles elapse in the real world. This problem cannot be solved by userspace code alone; you are going to need the cooperation of the kernel.

The proper way to solve this is to look up what Win32 API function will suspend your thread for a specified number of milliseconds, then just call that function. You should be able to do this directly from assembly, possibly with additional arguments to your linker. Or, there might be an NT kernel system call to perform this function (I have very little experience with NT system calls, and honestly have no idea what the NT system call table looks like, but a sleep function is the sort of thing I might expect to see). If a system call is available, then issuing a direct system call from assembly is probably the quickest way to do what you want; it's also the least portable (but then, you're writing assembly!).

Edit: Looking at the NT kernel system call table, there don't appear to be any calls related to sleeping or getting the date and time (like your original code uses), but there are several system calls to set up and query timers. Spinning while you wait for a timer to reach the desired delay is one effective, if inelegant, solution.


use INT 15h, function 86h:

Call With: AH = 86h CX:DX = interval in uS


Actually you can use ROM BIOS interrupt 1Ah function 00h, 'Read Current Clock Count'. Or you can read dword at address $40:$6C but you must ensure atomic read. It is incremented by MS-DOS at about 18.2 Hz.

For more information read: The DOS Clock


Well, then. An old style, non constant, power consuming delay loop which will make other threads running slow down would look like:

       delay equ 5000

top:   mov ax, delay
loopa: mov bx, delay
loopb: dec bx
       jnc loopb
       dec ax
       jnc loopa

       mov ah,2
       mov dl,'A'
       int 21
       jmp top

The delay is quadratic to the constant. But if you use this delay loop, somewhere in the world a young innocent kitten will die.


I didn't test this code but concept must work... Save/restore es register is optional! Check code carefully!

DelayProcedure:
    push  es                      //Save es and load new es
    mov   ax, 0040h
    mov   es, ax
//Pseudo atomic read of 32 bit DOS time tick variable
PseudoAtomicRead1:
    mov   ax, es:[006ch]
    mov   dx, es:[006eh]
    cmp   ax, es:[006ch]
    jne   PseudoAtomicRead1
//Add time delay to dx,ax where smaller is faster and 18 is close to 1 second
    add   ax, 3
    adc   dx, 0
//1800AFh is last DOS time tick value so check day overflow
    mov   cx, ax
    mov   bx, dx
//Do 32 bit subtract/compare
    sub   cx, 00AFh
    sbb   dx, 0018h
    jbe   DayOverflow
//Pseudo atomic read of 32 bit DOS time tick variable
PseudoAtomicRead2:
    mov   cx, es:[006ch]
    mov   bx, es:[006eh]
    cmp   cx, es:[006ch]
    jne   PseudoAtomicRead2
NotZero:
//At last do 32 bit compare
    sub   cx, ax
    sbb   bx, dx
    jae   Exit
//Check again day overflow because task scheduler can overjumps last time ticks
    inc   bx                //If no Day Overflow then bx = 0FFh
    jz    PseudoAtomicRead2
    jmp   Exit
DayOverflow:
//Pseudo atomic read of 32 bit DOS time tick variable
PseudoAtomicRead3:
    mov   ax, es:[006ch]
    mov   dx, es:[006eh]
    cmp   dx, es:[006ch]
    jne   PseudoAtomicRead3
//At last do 32 bit compare
    sub   ax, cx
    sbb   dx, bx
    jb    PseudoAtomicRead3
Exit:
    pop   es                      //Restore es
    ret


Here's a fairly simple example that should work if a long, not highly precise delay is needed.

To use, specify the delay in AX in 125ms increments.

;----------------------------------------------------------------------------;
; Simple delay based on PIT timer ticks
;----------------------------------------------------------------------------;
; Input: AX = delay_time in 1/8th of a second (~125ms) increments
;----------------------------------------------------------------------------;
DELAY_TIMER PROC
    STI                             ; ensure interrupts are on
    PUSH    CX                      ; call-preserve CX and DS (if needed)
    PUSH    DS
    MOV     CX, 40H                 ; set DS to BIOS Data Area
    MOV     DS, CX
    MOV     CX, 583                 ; delay_factor = 1/8 * 18.2 * 256
    MUL     CX                      ; AH (ticks) = delay_time * delay_factor
    XOR     CX, CX                  ; CX = 0
    MOV     CL, AH                  ; CX = # of ticks to wait
    MOV     AH, BYTE PTR DS:[6CH]   ; get starting tick counter
TICK_DELAY:
    HLT                             ; wait for any interrupt
    MOV     AL, BYTE PTR DS:[6CH]   ; get current tick counter
    CMP     AL, AH                  ; still the same?
    JZ      TICK_DELAY              ; loop if the same
    MOV     AH, AL                  ; otherwise, save new tick value to AH
    LOOP    TICK_DELAY              ; loop until # of ticks (CX) has elapsed
    POP     DS
    POP     CX
    RET
DELAY_TIMER ENDP

Here is an example to "sleep" for 1/2 second:

MOV     AX, 4                       ; delay for 1/2 seconds (4 * 1/8 seconds)
CALL    IO_DELAY_TIMER

This is somewhat "non-blocking" as it will halt the CPU between ticks. It would of course be a non-issue on real hardware running on single-user DOS, but in a VM/Windows environment it might make it a better neighbor.


..The problem with all of the above code examples is that they use non-blocking operations. If you examine the CPU usage during a relatively long wait period, you will see it running around 50%. What we want is to use some DOS or BIOS function that blocks execution so that CPU usage is near 0%.

..Offhand, the BIOS INT 16h, AH=1 function comes to mind. You may be able to devise a routine that calls that function, then inserts a keystroke into the keyboard buffer when the time has expired. There are numerous problems with that idea ;), but it may be food for thought. It is likely that you will be writing some sort of interrupt handler.

..In the 32-bit windows API, there is a "Sleep" function. I suppose you could thunk to that.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜