VOGONS

Common searches


First post, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

With this patch DOSBox will take only few host CPU when waiting for input i.e. at the command prompt or in a program that calls the idle function (Win 3.11). There might be some side effects but I haven't found any so far.

Attachments

  • Filename
    dosidle.diff
    File size
    2.48 KiB
    Downloads
    134 downloads
    File license
    Fair use/fair dealing exception

1+1=10

Reply 1 of 12, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

hmm, might have to try that, since Dosbox idles at 20% on OS X 🙁

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 3 of 12, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Last time I had a cpu issue with DOSBox @ idle (in the CLI with no programs running) it was due to an issue with the renderer. (Was fixed a long time ago). Before the fixed IIRC I had about 30% usage at idle.

Makes since since at idle rendering the video would be the most intensive I suppose.

How To Ask Questions The Smart Way
Make your games work offline

Reply 4 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Will the patch help cpuidle work better when DOSBox is running? IIRC, cpuidle uses special instructions to put the CPU into a low-power mode, and it would be nice if the low power and cooling effect of cpuidle was the same with DOSBox sitting at its prompt as Windows sitting at its desktop.

Reply 5 of 12, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

If the CPU usage decreases a lot (while at the command prompt) when increasing frameskip then your computer is indeed struggling with the video and CPU idling inside DOSBox won't help.

The patch uses DOSBox's HLT instruction (fixed/worked around to not lock up with max cycles). The CPU usage on the host drops with max/high fixed cycles that would otherwise start my CPU fan. I can't tell how this works with cpuidle. I think DOSBox still executes every millisecond but does almost nothing each time.

1+1=10

Reply 6 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

When waiting for input, DOSBox's INT 16h AH=00h and AH=10h functions have an idle loop that executes some NOP instructions with interrupts enabled. If the idle patch changed the NOPs to INT 28h, the loop added to the console device could be eliminated. This would have a couple of advantages: no additional use of CALLBACK_RunRealInt(), and anything that calls the INT 16h functions directly would also receive the idling benefit. I tried this slight modification to the patch, and it works just as well, with any improvement being more conceptual than perceived.

Reply 8 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I guess putting the HLT in INT 16, whether directly or through an INT 28 call, would be moving the idling into bios when it should be about DOS. 😉

The default INT 28 handler in real DOS is a bare IRET, so having HLT there is not entirely compatible.

Reply 9 of 12, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

It shouldn't matter how the BIOS wastes its time 😉

The side effects I could think of:
- HLT is a privileged instruction that might mess up implementations that use V86
- Programs might expect INT28 to return earlier

Anyway, I don't intend to add it to SVN. Maybe as option in some unofficial build.

1+1=10

Reply 10 of 12, by ovvldc

User metadata
Rank Newbie
Rank
Newbie

FWIW, I would appreciate any reductions in unneeded cycles.

It isn't that I need them desperately, but it just seems wasteful. Besides, (almost) anything to make computers less noisy is good.

Best wishes,
Oscar