Let me explain what cycles are and how max cycles work (in simple terms).
Why it doesn't work for a particular game... I don't know.

1) Cycles: cycles are the number of emulated instructions per millisecond
2) max cycles: DOSBox keeps track of the emulated/internal time (time spend on emulating instructions) and the "outside time" and adjusts the cycles value so that the ratio between the two times is 0.9. It does this at regular intervals.

That suggests that Daggerfall would have problems on a modern fast machine running dos - which I think I've heard before. The game is doing some math assuming that the computer isn't too fast, and the math breaks down as the number of game loops per second increases past some boundary.

But all that means is you find a good speed and set your dosbox cycles to that level. That's exactly that's why we can control the cycles count, and why the default cycles setting is around 3000 instead of "max". As I understand it, happy to be corrected, 3000 cycles is performance roughly in the 286/386 range of computers. That's assuming Cycles / 1000 = Dhrystone MIPS, which isn't exactly correct but I think is a reasonable estimate:

http://en.wikipedia.org/wiki/Instructions_per_second

And real chips couldn't always perform 1 instruction per cycle, but dosbox assumes/estimates based on that simplification. That speed increase might move the default emulation speed higher into late 386 or 486 era speeds, rough calculation. I didn't look, but I assume someone somewhere has done some DOSBox performance comparisons to real hardware?

Why its not possible to setup dosbox to work like pc with, for example, Pentium 166? And forget about clocking cycles every time for different games on different PCs?

vorob wrote:

Why its not possible to setup dosbox to work like pc with, for example, Pentium 166? And forget about clocking cycles every time for different games on different PCs?

That would require big changes to the emulation core of DOSBox.
Currently it counts all instructions as 'one cycle'. In reality, different instructions take different amounts of cycles, and then there are extra complications such as main memory being slower than cache, and memory mapped to an external device such as videomemory may be even slower still, have wait states etc...

DOSBox isn't designed at all to be an accurate emulator of actual hardware. It just does everything 'as fast as possible'.
You could try PCem, it's not super-accurate, but at least it tries to emulate the actual cost of instructions and accesses to video memory and such, where you can select different CPUs, video interfaces etc to control the overall performance.

vorob wrote:

Why its not possible to setup dosbox to work like pc with, for example, Pentium 166?

You may roughly do so by DOS benchmarks like Doom's demo and than use a chart for different CPUs. Or to use other benchmarks, like Speed Test.

🙄

.....or you could just use TOPBENCH

leileilol wrote:

TOPBENCH

TOPBENCH is less correct for this. For example, with 3000 cycles it shows speed of 386 33 MHz.
Also a system with 286 16 MHz it says faster than 386 33 MHz. It needs a possibility for sorting by CPU related params to be useful for DOSBox.

Tertz wrote:

leileilol wrote:

TOPBENCH

TOPBENCH is less correct for this. For example, with 3000 cycles it shows speed of 386 33 MHz.

TOPBENCH is probably right.
The problem is the inaccuracy in DOSBox, as explained above.

Scali wrote:

The problem is the inaccuracy in DOSBox, as explained above.

As explained above, we need something to decide about emulation speed in DOSBox and set it. Topbench shows wrong emulation speed and hence is less accurate for this, as explained above.

Tertz wrote:

Scali wrote:

The problem is the inaccuracy in DOSBox, as explained above.

As explained above, we need something to decide about emulation speed in DOSBox and set it. Topbench shows wrong emulation speed and hence is less accurate for this, as explained above.

As explained above, there's no way to do that, because DOSBox doesn't try to do any kind of realistic emulation speed.
All instructions are equally fast, while on a real machine one instruction can take 1 cycle, and another can take 100 cycles.
So how DOSBox performs compared to a real machine depends a lot on what instruction mix you are feeding it exactly. I have been very VERY annoyed by this, because it means it's impossible to use DOSBox for any reasonable benchmarking during development. Eg, if I optimize some code on a real machine, I may replace a routine of 5 instructions with another routine that takes 10 instructions, where those 10 instructions take less time than the 5 instructions.
On DOSBox however, it will get twice as slow.

vorob wrote:

Why it is so?

Daggerfall have some wonky behavior when the CPU is too fast. This happens if you play Daggerfall on a, say, 600MHz computer in DOS too.

Quadko wrote:

But all that means is you find a good speed and set your dosbox cycles to that level. That's exactly that's why we can control the cycles count, and why the default cycles setting is around 3000 instead of "max".

Yeah, with Daggerfall I usually play cycles=auto limit 30000 in the config file.

EDIT: Oops, just realised this thread is old 😵

leileilol wrote:

Ignore "DOSBox benchmark" requests

Thanks for your interest and advertising of my DOSBox benchmarking theme. 😀

We see another leileilol's useless captiousness 😀 wich sometimes writes a bullshit and even lie to bark louder.
As there is some correlation (in DOSBox too) between speed in different benchmarks, apps and games - so evidently there is use to know the speed in them. 😀 This correlation is not ideal, but it's useful anyway. A lot of tasks have similar code and hence get similar speed results. For example, Speed Test and Doom generally have good speed correlation (inside DOSBox too). I suppose Speed Test results are useful to understand the rough level of DOSBox performance in many DOS games. While Quake should be good to predict DOSBox speed in late 3D DOS games wich load FPU and in 3D Win9x games.
Some benchmarks for DOSBox are worse than other to predict games' performance in DOSBox, for example the one you've suggested previously was relatively bad for this.