DosBox is buggy with int 15h ah = 86h

Question

I am currently working on an assembly program, but I need to make the program wait every once in a while.

So, I have been using int 15h/ah = 86h, but for some reason DosBox is giving me a hard time, and the program either gets confused with pixels (wierd colors) or in the worse case; crash.

Can someone please help me?

Answer 1

This is a bug in DOSBox through release 0.74.3. There is a missing break in the switch of their int 15h handler function, so the ah=86h handler falls through into ah=87h, Copy Extended Memory which copies memory around from some random addresses. See bios.cpp around line 663-681. (If they'd turned on -Wextra they'd have got a compiler warning!)

This seems to have been fixed in trunk back in 2011 but somehow never made it into releases, I guess.

I have filed bug #548 to report this.

The region to be copied by ah=87h is specified by a count in cx and addresses in a descriptor table pointed to by es:si. If those addresses are out of range, you should just get the Illegal read/write warnings and no other harmful behavior, but if they happen to point to actual memory, something important may be overwritten. I suspect in OP's test the destination happened to point into video memory, explaining the "weird colors"

By the same token, if cx = 0 then nothing is copied and the bug won't appear. That justifies the workaround in rkhb's deleted answer, of executing delays of less than 65 ms in a loop.

Answer 2

I had this issue as well. Based on the answer at Problems with BIOS delay function (INT 15h / AH = 86h), I was able to get it working by making sure to set AL to zero before calling the interrupt:

    mov     counter, 10
L1:

    mov     cx, 0007H
    mov     dx, 8480H
    mov     ah, 86h
    mov     al, 0
    int     15h

    mov     dl, '*'
    mov     ah, 02h
    int     21h

    dec     counter
    jnz     L1

(the program prints 10 *'s, pausing for 1 second between each.) With out the 'mov al, 0', the program would hang or give other undefined behavior while DOSBox spews illegal read/write messages. By setting al to zero, the program works correctly but, strangely, error messages still appear on the DOSBox log.

Answer 3

Replace int 15h by something else, for example a procedure that waits "n" seconds:

.stack 100h
.data.

text     db 'text$'
seconds  db 99
delay    db ?  ;HOW MANY SECONDS TO WAIT.

.code          
  mov  ax, @data
  mov  ds, ax     ;INITIALIZE DATA SEGMENT.

forever:                      
  mov  delay, 5  ;DELAY 5 SECONDS.
  call my_delay  ;◄■■ CALL PROCEDURE HERE.
;DISPLAY TEXT EVERY 5 SECONDS.
  mov  ah, 9
  mov  dx, offset text
  int  21h       
  jmp  forever

  mov  ax, 4c00h
  int  21h       ;FINISH PROGRAM.

;--------------------------------------------------------
;PROCEDURE TO WAIT "N" SECONDS.
;SECONDS ENTER IN VARIABLE "DELAY".
;VARIABLE "SECONDS" MUST EXIST. USED AS LOCAL COUNTER.

my_delay proc  
delaying:   
;GET SYSTEM TIME.
  mov  ah, 2ch
  int  21h ;RETURN SECONDS IN DH.
;CHECK IF ONE SECOND HAS PASSED. 
  cmp  dh, seconds
  je   delaying
;IF NO JUMP, ONE SECOND HAS PASSED. VERY IMPORTANT : PRESERVE
;SECONDS TO USE THEM TO COMPARE WITH NEXT SECONDS. THIS IS HOW
;WE KNOW ONE SECOND HAS PASSED.
  mov  seconds, dh
  dec  delay   
  jnz  delaying  ;IF DELAY IS NOT ZERO, REPEAT.

  ret 
my_delay endp