Posting this here, as it is about code i want to run inside dosbox, if I misunderstood the scopes of the forums, please move ...

I developed a little curses game recently and made it to compile for DOS (using djgpp) today. It depends on having a source of constant "timing ticks" -- the main loop waits for the next tick when work for the current tick is finished. The implementation for DOS initially looked like that:

1void
2ticker_wait(void)
3{
4    while (uclock() < nextTick);
5    nextTick += tickTime;
6}

giving the following assembly:

1L10:
2        call    _uclock
3        movl    _nextTick+4, %ebx
4        movl    _nextTick, %ecx
5        cmpl    %ebx, %edx
6        jle     L14
7L8:
8        addl    _tickTime, %ecx
9        adcl    _tickTime+4, %ebx
10        movl    %ecx, _nextTick
11        movl    %ebx, _nextTick+4
12        ret
13L14:
14        jl      L10
15        cmpl    %ecx, %eax
16        jb      L10
17        jmp     L8

(I stripped all pseudo opcodes and stack manipulation for readability)

This worked flawlessly in dosbox, but then I wanted to do something more "smart" than just a busy wait, so I changed it to the following:

1void
2ticker_wait(void)
3{
4    if (haveYield)
5    {
6        while (uclock() < nextTick) __dpmi_yield();
7    }
8    else
9    {
10        while (uclock() < nextTick) __asm__ volatile ("hlt");
11    }
12    nextTick += tickTime;
13}

The __dpmi_yield() should give up a time slice when running in a multitasking environment. in dosbox, the "else" branch is taken, so showing only the relevant assembly here:

1L8:
2        call    _uclock
3        movl    _nextTick+4, %ebx
4        movl    _nextTick, %ecx
5        cmpl    %ebx, %edx
6        jl      L9
7        jle     L14
8L11:
9        addl    _tickTime, %ecx
10        adcl    _tickTime+4, %ebx
11        movl    %ecx, _nextTick
12        movl    %ebx, _nextTick+4
13        ret
14L14:
15        cmpl    %ecx, %eax
16        jnb     L11
17L9:
18        hlt
19        jmp     L8

This looks all good, but my game has situations where the ticker is not used and curses (in that case PDcurses) is asked to do a blocking `getch()` (wait for keyboard input) -- e.g. while showing a dialog. As soon as this hlt instruction is there, a subsequent PDcurses blocking getch() will eventually succeed, but slow execution down ridiculously (like, waiting 10 to 20 seconds for ANYTHING to happen).

So I first thought this might somehow interfere with PDcurses' code to implement blocking. To verify, I ran my program in virtualbox, using a real MS-DOS 6.22 installation. It worked perfectly.

Therefore my question: Is this expected behaviour in dosbox?

For reference, the whole code is on github