I've wanted to figure something like this out for a while. Perhaps someday...😉

Basically what is needed is a program that will run and report the "speed" of the processor that it sees from within DOSBox. I'm sure one exists, I just don't know what it is. Then, once we run that, we get a list of cycle #s from people with different proessors relating to three or four specific emulated clock speeds (like 33MHz, 66MHz, 100MHz, 133MHz) and derive a formula from that data.

Well there are some problems with that since cycles take a big impact if you run a game that uses the mode-x features of the VGA. You can see that with DOOM 😀

Yeah... It would be a great program...

I thought I had the whole cycles thing down before, when DOSBox 0.58 was released. I was given a list of CPU cycles in relation to the Mhz of the CPU, and setting the cycles to 9200 seemed to accurately emulate a 486 at 100 Mhz. Well, at least it ran "like" my old 486... 😁

Trying the new CVS release of DOSBox with the same settings didn't work however. I was back to the sound stuttering and slow video. So all my *accurate* settings (or at least the illusion of accuracy) are out the window. 🤣 😉

Anyways, some people should really get on that program, or that formula, or whatever is used to determine the damn number.
😀

Regards,
·Criftus
math@gta.igs.net

I regret to disagree but it seems that every program/game out there may have different cycles requirements. Just use a median value where your cpu usage is at about 50% and keep using CTRL-F11 or CTRL-F12 until sound & video are properly synchronized.

Alrighty. I must admit I have absolutely no knowledge what-so-ever about clock speeds and CPU cycles. I thought CPU cycles was a fixed number that a certain CPU could run at in relation to the Mhz of that particular CPU. so... like 50Mhz is around 5000 CPS, 100Mhz at 10000 CPS, and so on...

Am I like way off the mark here? 😀 Someone explain! ^_~'

Well dosbox's cycles aren't the same as normal cpu's cycles, since normal cpu's can take different cycle counts for different operations, whereas dosbox takes only 1 for each operation.
But since there are loads of different operations the cpu can do, one can take longer to emulate than the other. So if you have a game that uses a lot of the heavy operations you can reach a lower maximum speed than some game using light instructions.

I... See... 😁

So people are going to have to continue adjusting the amount of cycles depending on the particular game or application being run? That sucks. 🙁 I was hoping I could just set it to a certain value ("486@100Mhz=XXXX") and leave it at that... *sigh*

Harekiet wrote:

Well dosbox's cycles aren't the same as normal cpu's cycles, since normal cpu's can take different cycle counts for different operations, whereas dosbox takes only 1 for each operation.

Could dosbox's CPU core be made "Cycle-accurate"?
"Cycle accurate emulation means modeling the system (or some of its parts) in such a way that instructions complete in the same relative amount of time compared to each other and to other components in the system."

Would that not help?

----------

Anyhow, haxoring the cycles is my biggest beef with DOSBox. All I really want to have to deal with is frameskip as far as speed settings. Please make a solution to this a priority in development.

Cycle accurate isn't possible anyway since each newer cpu has different cycle counts for instructions and there's also the triggering of other hardware like writing to vga memory which would make certain instructions take a lot longer. Or a trigger to start a soundblaster dma transfer, which would first generate the old piece in the buffer.

But still i don't see why anyone would want it to run exactly at the speed of say a dx/2 66 since that is just nonsense. There aren't any games that need exactly a dx/2 66 for the correct speed. That was only the case with certain older games requiring XT/AT speeds. Would be kind of brainless of a developer to make a dx/2 66 only game when at the time of the release people's machines range from 486-25 to 486-120.

Most games do all their timing through timer interrupts and only need you to setup dosbox with the minimum amount of cycles to run good and if you go above that minimum they still run fine.

Originally posted by Criftus So people are going to have to continue adjusting the amount of cycles depending on the particular game or application being run? That sucks.

That's reality. How about this...people should feel free to refer to their processor and it's speed and the # of cycles you use. Odds are, someone with a similar setup will get similar performance. Consider it a "loose guide" instead of a collection of definitive settings.

While I agree that no measure measurement method is going to be an exact science, I was also curious how cycle settings might roughly correspond to performance of the simulated processor. For anyone who is interested, I found an old utility at Simtel and put it up on my site for download. Feel free to give it a run, and remember to take it for what it's worth!

http://www.slor.net/cputest.zip

Slor

Also, I found an old utility called CheckIt 3.0 that does a whole slew of system benchmarks and system info and runs quite well on DOSBox. Only problem is - I don't know if it's legally redistributable or not (even though it's as old as it is), so I won't post it publicly until I'm sure. Feel free to send me a private message if you're interested in more info.

Originally posted by Slor Also, I found an old utility called CheckIt 3.0 that does a whole slew of system benchmarks and system info and runs quite well on DOSBox. Only problem is - I don't know if it's legally redistributable or not

It's not. The DOS version is still a part of CheckIt Pro.

NSSI does a similar job and is freely distributable, but it kills my CVS, and seems to lock in 0.58 (haven't tried every possible startup parameter).

There should be other, similar programs out there...

As it stands, the cputest program previously mentioned reports that at 9283 cycles (the max amount I can run before the CPU starts to choke) my DosBox 0.58 is the equivalent of a 25 MHz 386 CPU.

I'm slightly suspicious of using this as a standard however, since it reports the same results for the 0584 Beta (which eats more CPU and has worse performance).

Why not adding a speed factor for timers?
This would enable easy speed changing for almost every game.

Srecko, I don't understand you fully. Could you elaborate on that?

It's simple. If timer interrupt is set to run every x seconds, you could
adjust it to run every k*x seconds where k < 1 or k > 1.
So, (interrupt based) game runs slower or faster.

But to fully implement this, you should also do same modification to
all emulated parts of dosbox that have internal timers. (sound, vga, ...)

Sounds difficult to implement and lenghty.

eL_PuSHeR wrote:

I regret to disagree but it seems that every program/game out there may have different cycles requirements. Just use a median value where your cpu usage is at about 50% and keep using CTRL-F11 or CTRL-F12 until sound & video are properly synchronized.

I agree. I play Alone in the Dark at 7727 cycles, but I don't need to change the cycles at all to play Wolfenstein smoothly.

If we accept that we're unlikely to get CPU-accurate timings any time soon, how about the next best thing: have DOSBox remember what the timings (an possibly any other settings) were set to on an application by application basis.

Have DOSBox start as normal reading its config as normal, then whenever an application is started, DOSBox checks against a list in another config file (called, say, apps.cfg) to see if settings for that app have been recorded.

e.g. apps.cfg looks like this:

[C:\MOM\MAGIC.EXE]
cycles 6372
frameskip 1

[C:\MOO\ORION.EXE]
cycles 5690
frameskip 2

During normal operation, DOSBox would have to keep track of what app it was running, and if settings are changed using F11, F12 etc it updates the apps.cfg file with an entry for that application.

This way users will only have to fanny about once per application. Once they get an app balanced for their machine it will run correctly every time in the future.