DosBox的int 15h是错误的ah = 86h [英] DosBox is buggy with int 15h ah = 86h

问题描述

我目前正在处理汇编程序，但是我需要使程序不时地等待.

因此，我一直使用int 15h/ah = 86h，但是由于某种原因，DosBox给了我很大的麻烦，并且该程序要么与像素(较偏颜色)混淆，要么在更坏的情况下出现；崩溃.

有人可以帮我吗?

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?

推荐答案

我也遇到了这个问题.根据有关BIOS延迟功能的问题(INT 15h/AH = 86h)，通过确保在调用中断之前将AL设置为零，我能够使其工作:

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

(程序打印10 *，每次之间暂停1秒钟.)如果没有'mov al，0'，则该程序将挂起或给出其他未定义的行为，而DOSBox会吐出非法的读/写消息.通过将al设置为零，程序可以正常运行，但是奇怪的是，错误消息仍然出现在DOSBox日志中.

(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.

这篇关于DosBox的int 15h是错误的ah = 86h的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！