DOSBox would need a big rewrite for that kind of thing.

PCem can allow you to emulate a 40MHz 386 and perhaps a 25MHz 486-SX. Pentium 60s are a bit far up though...

Alright, perhaps it would. What about getting an approximate slower speed, but having it remain absolutely rock solid?

Cool, but PCemu needs a lot of refinement. For now dosbox is the way to go.

Configuring the cycles, has a similar effect.

E.g. 6000 is a good setting for most games from the early 90s. Wing Commander runs a little bit too fast though, so I would suggest 4500.

Most newer DOS games don't care about the speed. E.g. games such as Duke Dukem 3D or Doom run on a real Phenom II with 3+ GHz.

I always have set cycles, never Auto or Full speed...

PS: PM sent

It would be interesting to try in a custom build. I doubt that they'll put it into the main build though. 🤣

Is there a formula to determine how many cycles = emulated cpu mhz?
I assume it would also need to take into consideration the host cpu speed.

I know that modern cpu's don't always have a fixed time-to-execute an instruction, and with the multiple levels of cache it gets even more confusing.

But is there an approximate formula?

BTW: I also came to the conclusion that 3000 cycles seems to work best with Stellar-7 and 11,000 for Nova-9. At least on my system. By trial an error, not that it was hard to begin with.

Either way, I'm just slapp'n happy that I can get these old games up and running!

No, there is no such formula. If there was, it would be easy adding such an option.
The primary reason why an option to select exact MHz does not exist is because in dosbox every instruction takes one cycle. On a real CPU, instructions take anywhere from 1 to a few hundred cycles. There are differences between processor families (that's why 486 is faster than a 386 at the same clock), dosbox would also have to take into account memory speed, pipeline stalls, bus speeds, ..., to emulate accurate speed.

Yes, I figured as much. What about some sort of timing monitor or something to do with vsync?? Could that be used to get a steady and reliable reference for speeds..?

Just guessing..

Already used in real DOS.

Cycles measures how much instructions does the simulated CPU over time, so it may be easy to get a "reference" between CPU power and cycles... but it may be not a exact reference.

You could try to get an old benchmark, and try some values of cycles until you get a value near the target computer (i.e.: an equivalent to a 8086@4.77 MHz). Because the differences between emulated CPU (1 instruction per cycle) and real CPUs (every instruction is executed in different number of cycles), you won't get exactly the same speed but don't worry... 4.77 MHz was not a exact value when there were 8086, 8088, Nec V20 and Nec V30 processors in the market.

Keep in mind that cycles works as a hard limit of CPU power, so it doesn't alwasy work as expected. There were at least three methods of speed control in games:

- Fixed delays: It is not a throttle control... the game has some fixed delays to make it playable. Some games worked only as expected in 4.77 MHz, other games let you choose your CPU type and adjust delays (a 80286@6 Mhz had bigger delays than a 8086@4.77 Mhz) to get a constant speed between systems. It this context, a fixed value of cycles may will work as expected.

- Benchmarking the CPU: Some other games benchmarked your CPU (first executed some instructions in a loop, timed it, and then get a fixed value for the delays). If the emulated CPU is too fast, the time of the benchmark will drop to zero and the game won't work. Lowering the cycles will make the game work again, but keep in mind that there won't be any differences between playing at 3000 or 4000 cycles (for example) because the game can throttle the speed (There are other methods of benchmarking the speed, that actully may work at full cycles).

- External timing: The game used some external events to synchronize the game. The most popular it vertical retrace... so you won't need to touch cycles (those events are not related to CPU, so raising/lowering cycles won't affect them).

Synchronizing DOSBox with vertical retrace won't affect game speed, because the game may not be aware of vertical retrace. To get a fixed speed will need to get a cycle-perfect emulated CPU, but I doubt it would worth the effort. I don't know any game that relies on exact cycle emulation (in other systems, like ZX Spectrum and Amstrad CPC there are games that need exact cycles, but that's another story).