Delay for DOS

Hi,
I'd like to write a delay function for DOS (real DOS, not Win32 console). But the important thing is: The function shall not increase the processor load to 100 %. So anything like that:

Code:

---

void delay(int milliseconds)
{
    clock_t start = clock();

    while ((clock() - start) * 1000 / CLOCKS_PER_SEC < milliseconds)
    {
        // Do nothing.
    }
}

---

is completely out of the question. Because such a function would put the processor load to 100 % (50 % on a dual core, 25 % on a quad core etc.) for the duration of the loop. And I want to avoid this at all costs.
So, I basically need something that does the same as the Sleep function in Windows (which does not make the processor jump to 100 %), only that I need a DOS version.

Turbo C++ has a delay function, but it suffers from the mentioned drawback. And it has a sleep function that doesn't increase the processor load, but it can only wait whole seconds, not milliseconds. Also, I need the delay to work with all DOS C++ compilers and therefore cannot rely on a function that only comes with a specific compiler.

How do I solve my problem? Can this be done with normal C or C++ or do I have to use some assembler code in the function? I'd really appreciate if you could help me.

HLT
So instead of do nothing, you could do

Code:

---

    while ((clock() - start) * 1000 / CLOCKS_PER_SEC < milliseconds)
    {
        asm{"hlt"};
    }

---

It will be as accurate as the fastest external interrupt source on your hardware.

Also, the asm syntax might vary from one compiler to another, but IIRC the "traditional" old DOS compilers all had similar syntax.
SourceForge.net: Compilers - predef
if you need help writing #ifdef's for each compiler you have to work with.

At first, thanks for your help. But it still doesn't work. The processor load still goes up to maximum. Is there maybe a way to call the hlt command with a parameter that says how long the program is stopped, so that I only need to call it once per function call?

Did you test it on a real DOS machine as well, and not some emulator/VM ?

Because HLT is a privileged instruction, which means if you're running an emulator/VM, there will be a certain amount of trickery and fakery going on.
And just how are you measuring CPU load when all you have is a full-screen "C:\>" prompt?

I just let the program run in Windows XP, so no, I didn't test it on a real DOS machine. But the thing is: If the method only works in a real DOS environment, but not when I use the 16 bit DOS program in Windows, then it's not what I'm looking for anyway. Because the command should of course also work if the DOS program runs under Windows.

By the way, does anybody know why the sleep function in Turbo C++ (which, unlike delay, doesn't increase processor load) can only wait whole seconds instead of milliseconds?

If you want to use windows, then write a win32 console program and use Sleep(). But you'll need a new compiler (not that old fossil)

> Because the command should of course also work if the DOS program runs under Windows.
Why would you want such a thing?
The whole point of the emulation layer is to give you functional equivalence for well behaved programs (albeit at the expense of CPU time in some cases).
It wouldn't be much good if some badly behaved DOS program could still bring down the entire OS, because it had direct access to say the physical hardware.

If you don't like the native emulator, perhaps another one behaves better (not that I've tried it)
DOSBox, an x86 emulator with DOS or VirtualBox
Hey, it's even open source, so perhaps you can hack it do behave how you would want it to.

> By the way, does anybody know why the sleep function in Turbo C++ (which, unlike delay, doesn't increase processor load)
> can only wait whole seconds instead of milliseconds?
Because that's the historic specification for the sleep() call.

Unless you have a real reason for running real DOS code on a real DOS machine, then there is no reason I can see for sticking with 20+ year old compilers for an OS which most people regard as being dead. Certainly, there is no point stressing over the finer detail of why the emulation layer doesn't precisely match the real hardware (it never can).

Quote:

---

Originally Posted by Salem

It wouldn't be much good if some badly behaved DOS program could still bring down the entire OS, because it had direct access to say the physical hardware.

---

Of course I don't want my program to screw up Windows. I doubt that this is even possible in Windows XP. All I was saying is: If a solution only works on a real DOS machine while it still poses the same problem when the DOS program is run from Windows XP, then it's not the solution I'm looking for.
(By the way, in the moment we don't even know if the current problem, that using the hlt command still increases processor load, is just a Windows problem because of missing rights or if it wouldn't work in a real DOS as well.)

I know that the sleep function doesn't increase processor load, so the whole issue doesn't seem to have anything to do with missing privileges. Therefore, there's no need to look for another emulator or anything like that.

Quote:

---

Originally Posted by Salem

Unless you have a real reason for running real DOS code on a real DOS machine, then there is no reason I can see for sticking with 20+ year old compilers for an OS which most people regard as being dead.

---

Well, my idea is to program an old-school game that behaves exactly as it would have if it was programmed back then. Later, I will maybe write a Windows version, but in the moment, I'd like to program it as a native DOS application. And since a game loop does nothing in 99% of the time:

Code:

---

while (gameIsRunning)
{
    if (TimeToDrawTheNextFrame())
    {
        ReadInput();
        ProcessGameLogic();
        DrawNextFrame();
    }
    // else do nothing
}

---

I don't want a program that makes the processor run on full power just because it's waiting in an infinite loop. Thus, I want to do the following:

Code:

---

while (gameIsRunning)
{
    if (TimeToDrawTheNextFrame())
    {
        ReadInput();
        ProcessGameLogic();
        DrawNextFrame();
    }
    else
    {
        delay(1);
            // Unload the processor since
            // there's nothing to do.
    }
}

---

But since delay itself sets the processor to 100%, I need a function like sleep, only that it has to be able to wait milliseconds.

If you want to write a true native DOS game then why are you worried about the processor usage? DOS is inherently a single process operating system it does not multitask. So most of the functions did not worry about using "all" of the resources. If you don't want the peculiarities of the DOS delay() function then you should use the Windows API functions or setup a Virtual Machine with DOS installed and not worry about processor usage.


Jim

Like I said - DOSBOX
Performance - DOSBoxWiki
You can tune it to behave as a more (or less) capable processor.

> Well, my idea is to program an old-school game that behaves exactly as it would have if it was programmed back then
If a game isn't running at 100% CPU all the time, then it isn't going to be keeping the frame rate at the highest level for the best possible user experience.

Quote:

---

Originally Posted by jimblumberg

If you want to write a true native DOS game then why are you worried about the processor usage? DOS is inherently a single process operating system it does not multitask.

---

It's not about the multitasking stuff. It's about the simple fact that I don't want my program to run on full power in an infinity loop even though it doesn't need to. Did you ever own a PC with a loud fan? I guess you can imagine what a

Code:

---

while (true)
{
}

---

can do in this case in terms of noise.

Quote:

---

Originally Posted by Salem

Like I said - DOSBOX

---

No. My question was how to stop the program for a certain amount of time in milliseconds, how to implement a decent delay that's not just a simple loop. The solution to that problem is not "Use DOSBox."

Quote:

---

Originally Posted by Salem

If a game isn't running at 100% CPU all the time, then it isn't going to be keeping the frame rate at the highest level for the best possible user experience.

---

I guess I'll use a fixed frame rate anyway. You don't need a "Super Mario"-like game with 500 FPS.

I believe the problem you are having here is a communication issue. The "DOS" you speak of in windows is not actually dos, it is an emulator, hence Win32 console. In order to run actual DOS you need to do what Salem has suggested. If on the other hand you want to run your "dos" program from within windows you are actually running a console program which will have its behavior modified, under the hood of course, by windows.

If this is the case then just simply use the Win32 API Sleep() command for your console app. This will not raise CPU usage since windows will place your console thread to sleep. Trying to ignore the fact that your program is a console program does not make it go away. Thus if your thread demands that it be stalled but does not give control back to Windows you will see your CPU usage go to 100%.

EDIT: If you are worried about complexity, it is actually quite easy to implement a DOS style game using the Win32 API. In fact I would say it is easier to program a console BitBlt style game taking advantage of the API then it is to code an original DOS game. A lot of the complexity with memory management is taken out of the equation.

Quote:

---

Originally Posted by AndrewHunter

I believe the problem you are having here is a communication issue. The "DOS" you speak of in windows is not actually dos, it is an emulator, hence Win32 console.

---

No, there isn't a communication problem, at least not from my site. I know the difference between a Win32 console application and 16 bit DOS programs. And yes, my program is really a DOS program. It's a game that uses Mode13h and that is compiled with Turbo C++ 3.0 or Microsoft Visual C++ 1.52c. It's not a Win32 console application. The fact that I don't have a DOS computer right at hand and test the application under Windows XP (which is still able to run real 16 bit DOS programs) doesn't change the fact that my program is still a real DOS program. For example, my program includes lines like:

Code:

---

unsigned char far *screen = (unsigned char far *)MK_FP(0xA000, 0x0000);

---

or stuff like

Code:

---

REGS in, out;

in.h.ah = 0x00;
in.h.al = 0x13;
int86(intNumber, &in, &out);

---

or

Code:

---

void WaitForVBlank()
{
    while (inp(0x3DA) & 8)
        ;
               
    while (!(inp(0x3DA) & 8))
        ;
}

---

You see? It's really a DOS program.

Quote:

---

Originally Posted by AndrewHunter

In order to run actual DOS you need to do what Salem has suggested.

---

Not necessarily. Even though Windows XP is not based on DOS anymore, but on Windows NT, it's still capable of running actual DOS applications. And that's what I do: As long as I'm still working on the basic things, I just test the program under my usual operation system, Windows XP. Later, when it comes to performance and all that stuff, I can set up a DOS installation and test it there. But in the moment, I don't need that yet.
However, it is a DOS program, not a Win32 console application, otherwise I would have already used the Sleep function (since I mentioned it in my very first post). But this DOS program, due to a loop, pushes the processor load. And since I've seen that Turbo C++'s delay function has the same problem while Turbo C++'s sleep function hasn't, but can only wait full seconds, all I want to know is: How do I implement a delay that works like Turbo C++'s sleep function, but can wait milliseconds instead of seconds?

Quote:

---

Originally Posted by AndrewHunter

EDIT: If you are worried about complexity, it is actually quite easy to implement a DOS style game using the Win32 API. In fact I would say it is easier to program a console BitBlt style game taking advantage of the API then it is to code an original DOS game. A lot of the complexity with memory management is taken out of the equation.

---

Yes, I could write a Windows game. In fact, I'm writing the game in a way that all platform independent things are separated from the OS specific stuff, so that I can easily replace the graphics and input engine later and still have the game behave absolutely the same. But in the moment I want to program an original DOS game. And I don't have a problem with anything, except the fact that Turbo C++ has a sloppily implemented delay function and Visual C++ 1.52c doesn't have one at all.

P.S.: There's actually more memory management with Windows GDI with all their DeleteDC and ReleaseDC and DeleteBitmap and stuff. DirectX isn't much better with all their surfaces and clippers and palettes. In DOS, all I have to do is call a delete[] for each of my sprites and the back buffer when I don't need them anymore.

No one is trying to argue with you here, neither is anyone going to be impressed with Screen 13 access commands or the fact that you know where the legacy memory address for screen 13 is. This simple fact is regardless of how you compiled or wrote your code it's implementation on Windows is such that the behavior is modified so that it can run within the DOS emulator.

Quote:

---

Virtual DOS machines rely on the virtual 8086 mode of the Intel 80386 processor, which allows real mode 8086 software to run in a controlled environment by catching and forwarding to the normal operating system (as exceptions) all operations which involve accessing hardware. The operating system can then perform an emulation and resume the execution of the DOS software.

VDMs generally also implement support for running 16- and 32-bit protected mode software (DOS extenders), which has to conform to the DOS Protected Mode Interface.

When a DOS program running inside a VDM needs to access a peripheral, Windows will either allow this directly (rarely), or will present the DOS program with a Virtual Device Driver which emulates the hardware using operating system functions. A VDM will systematically have emulations for the Intel 8259A interrupt controllers, the 8254 timer chips, the 8237 DMA, etc.

---

Quote:

---

Originally Posted by AndrewHunter

No one is trying to argue with you here, neither is anyone going to be impressed with Screen 13 access commands or the fact that you know where the legacy memory address for screen 13 is.

---

Did you really think that I posted the code to "impress" anybody? I showed it so that you believe me that I'm really writing a DOS program and that I'm not just too stupid to confuse DOS with Win32 console. I didn't show you the code to "impress" you.

Quote:

---

Originally Posted by AndrewHunter

This simple fact is regardless of how you compiled or wrote your code it's implementation on Windows is such that the behavior is modified so that it can run within the DOS emulator.

---

O.k. And what does that and the quote you posted have to do with my problem? My original question was: "How do I implement a delay function that really halts the program and doesn't just go through a loop until the specified time has come?" Plain and simple. But your descriptions don't do anything to help me with my question. "When a DOS program running inside a VDM needs to access a peripheral, Windows will either allow this directly (rarely), or will present the DOS program with a Virtual Device Driver which emulates the hardware using operating system functions." Fine. And? How does that help me with my delay function problem? If a driver of a car wants to reduce mileage, he doesn't need a text about how the engine works from within. All he needs to know is what he can do to reduce mileage. And my question is the same: I'd like to know how the code looks like that implements a decent delay function. Nothing more, nothing less. If the DOS program runs under a DOS machine or under a Windows machine or under DOSBox and how those programs handle the EXE file has nothing to do with how my source code will look like. I just need to know how a delay that halts the program would have been implemented in a DOS application (or where I can find concrete information about that topic).

I think what everyone here is trying to tell you is:
It simply isn't possible to make a "sleep" function that works in both Windows and DOS.

The reason why "halt" isn't working is that Windows probably won't allow it (ie emulates it in a wrong way than you expect).
Hence their suggestion about DOSBox to "fix" that problem.

Quote:

---

Originally Posted by Elysia

I think what everyone here is trying to tell you is:
It simply isn't possible to make a "sleep" function that works in both Windows and DOS.

---

Well, we have the sleep function from Turbo C++ which works quite well, also when the DOS program is run in Windows. (The only drawback is the fact that it only waits seconds, not milliseconds).

Quote:

---

Originally Posted by Elysia

The reason why "halt" isn't working is that Windows probably won't allow it (ie emulates it in a wrong way than you expect).

---

Or maybe because the suggestion to use hlt in a loop was incorrect in the first place. (I mean, why shouldn't it work in Windows? The whole thing works in the native Windows Sleep function, so why should DOS emulation just skip it instead of emulating its behavior?) After all, can anybody confirm to me that this:

Code:

---

while ((clock() - start) * 1000 / CLOCKS_PER_SEC < milliseconds)
{
    asm{"hlt"};
}

---

indeed does work under DOS and wasn't just a quick first idea? But even if it would, it's obviously still not the way Turbo C++'s sleep is implemented because that one does work in Windows.

Windows Sleep function does not use a "halt" function. It does not need to.
It simply tells the scheduler not to schedule the program for execution for a while. Windows is natively multi-threaded as opposed to DOS.

But the DOS function sleep still works from within Windows.

The DOS sleep() call probably maps down to a DOS interrupt call, which can be trapped by the VM and thus "do the right thing".

You might be able to make your own around this DOS interrupt, if the VM emulates it correctly
Int 21/AH=89h

Only a tiny fraction of the DOS interrupt API is mapped to C function calls, and those that are are also constrained by the historic API requirements (like sleeping for integer seconds). The underlying DOS API might be better.

FWIW, some degree of familiarity with the "Ralph Brown Interrupt List" is a must if you want this level of control.

A busy wait is not necessarily bad for non multitasking operations. For a long wait it does make sense to make the CPU go into a low power mode, but for a small time period there isn't much benefit. I suspect the windows scheduler will do a busy wait, and not try to halt the cpu.

I find it quite unlikely the scheduler will do any busy wait of sorts, seeing as Windows has lots of work to do in the background and as all operating systems, works with timer interrupts.

Quote:

---

Originally Posted by Elysia

I find it quite unlikely the scheduler will do any busy wait of sorts, seeing as Windows has lots of work to do in the background and as all operating systems, works with timer interrupts.

---

A timer interrupt can interrupt a low priority busy wait. But yeah, it may just use halt.

Sure, but my point was that Windows has lots of things to do (and have better things to do than busy wait!).
There is also the question of how a busy wait would be implemented. Would it be spun off as a DPC/APC?
And if it was, would it interfere with other work, especially that of drivers? It seems just more certain that it would be easier and better if it simply scheduled it for running some timer interrupt later.

Necessarily for windows to run smoothly, most of the time it must be doing nothing. DPCs and APCs are things that are differed when there is high load, but at some point you must run out of those too, or else the queue of things to do will grown faster than it is consumed.

Researching this a little it does seem like a halt command is likely. However with a modern CPU, the command cannot just power down the CPU. A CPU has it's own instruction queue of active and pending instructions that it must empty.

Quote:

---

Originally Posted by Salem

The DOS sleep() call probably maps down to a DOS interrupt call

---

Alright, that might help me. Unfortunately, I know almost nothing about Assembler, therefore, what do I have to do to understand how to implement a timer without studying a huge reference of overall commands?

There's a generic API called int86 which allows you to easily call and DOS/BIOS interrupt without messing about with assembler.

OK, thanks. But how do I know what commands to use? As I said, I don't really know how to use that whole low level commands. Where can I get to know how to use the stuff relevant for the delay?

By the way, I downloaded Open Watcom and in this compiler, both functions, delay and sleep, rise the processor load to 100%, while with Turbo C++ and also Borland C++ 5.02, only the delay makes problems.

> But how do I know what commands to use?
Post #19 and lots of reading on your part.
The RBIL is a very comprehensive list of essential information for low level real-mode programmers.

Quote:

---

Originally Posted by Salem

Post #19 and lots of reading on your part.
The RBIL is a very comprehensive list of essential information for low level real-mode programmers.

---

Yeah, and that's exactly the problem: I don't want to become an advanced low level programmer, I only have one tiny bit in my program that needs such stuff. That's why I need tutorials that show me exactly and to the point how to do it, not whole lists and references about low level programming in general. If you want to clean your drain and need to know how to remove the pipe from the washbowl, you look for something that tells you how to do exactly that. You wouldn't study a whole handbook about plumbing in the hope that one day, you'll be able to achieve the task with your newfound craftsman knowledge.

Quote:

---

Originally Posted by Erde

That's why I need tutorials that show me exactly and to the point how to do it

---

Things don't always come in neat little packages. Suck it up or go find something else to do.

Quote:

---

Originally Posted by adeyblue

Things don't always come in neat little packages.

---

Yeah, but do you know what? I don't need a forum to tell me "Go and learn low level stuff." If that's the answer to my problem, I could have easily done without all of you. I'm here to get some help about a specific problem. Telling me that I should study a whole compendium is really not a help. That I could have told myself too. For such a generic answer, I don't need people like you.

I doubt that's going to guilt-trip any of us into doing the research for you. If one of us knew off the top of our heads, it would have appeared by now; and the question is (at least in our opinion) not worth our time to find out. We're sorry you had such an uninteresting question, but there it is.

You got help to your specific problem: You need to set up a timer interrupt and then halt.

Writing DOS programs isn't your every day problem, so don't be surprised that you can't find someone who can spoon feed you the answer. If you had asked how to pause the program on windows or Linux for a few ms, the answer would be easier.

OK, doesn't matter anymore. Instead of programming, from now on I will only play video games.

Video games ruined my life. Good thing I have two extra lives.

*thread closed*