VOGONS


First post, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie

See also
http://www.z80.eu/blog/index.php?entry=entry210208-095857

I was wondering what happened because the tested DOSBOX 0.74-3 (not tested older versions) shows a strange behaviour while executing a small benchmarking program.
This small benchmarking program was a part of a MASM 5.10 sample series, written by myself.
I tested it with real PCs, with PCem, and with DOSBOX.
DOSBOX was slowing down significantly while displaying an increasing amount of single (colored) chars, using the INT 10 function 09h.
You can look into the program source code as well, see the link above.
I was curious what is the reason for that.... any hints ?

Reply 1 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

What cycles setting are you using? If you are using max cycles, that is not a specific amount; rather, DOSBox tries to guess the amount needed. Also keep in mind that DOSBox uses internal callback code for BIOS functions, not code that executes on the emulated CPU as on a real system, and that internal code appears to execute almost instantaneously according to any timekeeping within the emulation, which complicates benchmarking against real systems.

Reply 2 of 15, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote on 2021-02-08, 12:54:

What cycles setting are you using? If you are using max cycles, that is not a specific amount; rather, DOSBox tries to guess the amount needed. Also keep in mind that DOSBox uses internal callback code for BIOS functions, not code that executes on the emulated CPU as on a real system, and that internal code appears to execute almost instantaneously according to any timekeeping within the emulation, which complicates benchmarking against real systems.

No. That's not the point. I was testing it by using default settings (I guess it is 3000 cycles).
My point is the specific behaviour of DOSBOX .... it starts with high speed and is slowing down 2-3 secs later significantly.
I am using DOSBOX on a Ryzen 7 3700X system with NVMe SSDs...

Just test it by yourself and you will see what I mean.
The program behaves totally different in PCem for example. It runs continuosly with the same speed, not slowing down while running.

Reply 3 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Peter z80.eu wrote on 2021-02-08, 12:58:

it starts with high speed and is slowing down 2-3 secs later significantly.

If you're referring to the appearance of animation in the colored blocks, that remains consistent for me throughout the ~5 second running time of your program, there is no slowing down here.

Do you see the slowing down you refer to in SVN as well as 0.74-3?

I tested with default settings, which includes output=surface; and also with default settings except for output=opengl. Maybe try different output methods at your place.

Reply 4 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I want to emphasize my earlier point about the internal callback code. It is so fast within the emulation that it could, depending on host factors like the display and drivers, create apparent patterns that aren't really there. I see this using your program when using much more than 3000 cycles, where there appear to be shifting bands of the blocks, but that's just patterns evolving from the rapidly changing image and the way DOSBox renders.

BTW, loading a video BIOS in DOSBox will create a more level playing field against real systems. For example, loading the IBM VGA BIOS with 3000 cycles results in 36 loops in your program vs. 175 with the internal callbacks... no small difference. To load a video BIOS you need a debug version of 0.74(-3) or SVN.

Reply 5 of 15, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie

May be it's related with the sizing / the size of the DOSBOX Window - I'm using one almost twice sized (compared to the unscaled size). Or in other words, my DOSBOX window is resized to a bigger size than the default offers.

I guess these parameters may influence it, too (settings come from dosbox-0.74-3.conf):
fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=1280x960
output=ddraw

Reply 6 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I tried output=ddraw and see no difference. Different window sizes, scaler settings, and fullscreen also appear the same. Actually, I usually use windowresolution=1280x960 with output=opengl and aspect=true (scaler=normal2x in 0.74, but scaler=none and glshader=sharp in SVN).

You seem to be experiencing something that is not necessarily typical of DOSBox users. Maybe try capturing a video of your program with DOSBox and watching it in a media player to see the difference.

Reply 9 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Peter z80.eu wrote on 2021-02-08, 12:58:

No. That's not the point. I was testing it by using default settings (I guess it is 3000 cycles).

The video clearly shows you are using max cycles, and my point about that remains.

Reply 10 of 15, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie

That was correct, I looked into the .conf file, and there was indeed max, but set to 5000 shows still the mentioned slowing down effect. Set to 4000 makes it less visible, using 3000 it is almost invisible.
So what is the exact explanation if cycles > 4000 are used ? Why is this so "parameter cycle" dependant, but other emulators like PCem does not show this effect ?

Reply 11 of 15, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

1) Have you tried with output=opengl?
2) What refresh rate is your monitor running at?

If the emulated screen is being updated at 70Hz but your physical screen only refreshes at 60Hz, you'll get bad performance. Usually this is mitigated because DOSBox performs "lazy" screen updating, redrawing only when the content actually changes. OpenGL can also help because it attempts to disable vsync (not always successfully).

Reply 12 of 15, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie

I see no relationship between the Windows monitor refresh rate and the emulated screen, because even the captured screen (with only 30 frames/sec) shows the effect. But anyway, my monitor is set to 75Hz.
I can try OpenGL instead of DDraw, but I choosed DDraw, because in the past, I was not able to change the size of the DOSBOX window smoothly with the OpenGL setting.

Reply 13 of 15, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie

opengl looks a bit more blurry/blurred but shows the same effect. The only parameter which influences it drastically is "cycles", as mentioned before. Setting it below 4000-5000 will stop the slowdown, if set to max it has also the most slowing down effect. I will try to accept it, also because if I know that I should not set cycles to max, no unwanted effect will occur again.

Reply 14 of 15, by M-HT

User metadata
Rank Newbie
Rank
Newbie

I tried the benchmark and I noticed no slowdown. I tried various cycles and everything looked fine. I'm using Linux and also Ryzen 7 3700X.

What power plan are you using? Is there any difference if you use High Performance ?

Reply 15 of 15, by Peter z80.eu

User metadata
Rank Newbie
Rank
Newbie

No power plan, DOSBOX is running with Windows 10 Pro on a Desktop PC (always max. CPU performance). Although I appreciate Linux too, I didn't tried it here (but I will try it with a Life CD for sure).