VOGONS


The Proper Speed

Topic actions

First post, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

I am concerned about the proper speed at which games should run. Later games are often good about this, having frame limiters built-in to throttle the game. Early games do not have it at all or high speeds can affect them in ways not immediately apparent.

The games of the first five years were developed or ported for a remarkably homogenous platform, the IBM PC, which only had a 4.77MHz 8088. Developers designed their games to be played at that speed for a rather long time and supported it for even longer. Also, it should be the base speed from which all things grow, no PC ever ran slower (although I once heard someone say that PC Jr.s and Tandy 1000s ran at a slightly slower 4.6MHz.)

Now while many games could run at the standard IBM PC speed, upgrades could lead to speed improvements, making the game run more smoothly but without impairing the gameplay by making the game run too fast. But what is the correct speed for a particular game? Some poor programmers let the CPU speed dictate their game's speed, finding the available CPUs created a tolerable array of speeds. Other poor programmers only tested their game on one model of processor and didn't feel it was necessary to do it on other CPUs. Can anyone claim that he played all the major or good DOS games back-in-the-day? Surely there must be some games which people are unfamiliar with. How can a person play a game that doesn't speed throttle (at all or in part) if they don't know what it should be run at?

One of the concerns that I have with DOS box is that it emulates all op codes in one cycle. The 8088 was especially inefficient in this regard, but even the 486 took an average of 6-7 cycles per instruction. I doubt even modern CPUs process any or all instructions in 1 clock cycle. Now suppose one part of a game is reliant on "low-cost" instructions that only require a few clock cycles. Another part of the same game is reliant on "high-cost" instructions that requires many clock cycles. In Dosbox the two parts of the game would run out of sync with each other, leading to distortion.

Now this is why you can't equate DOSbox clock cycles with CPUs. Its only a rough estimate that "500 cycles = 8088, 1250 cycles = 286, 2500 cycles = 386, 10000 cycles is a high speed 486."

Reply 1 of 3, by Guest

User metadata

It would be nice to have accurate timing emulation for the IBM PC, Tandy 1000, and PCjr, but I think it's also worth mentioning that these timing problems exist on real hardware when running those old PC/Tandy games on, say, a 486. Additionally, I'd say that DOSBox's ability to control emulation speed is arguably better than any slowdown utility that I used on my old 486DX4-120 to run the really old games at a playable speed.

Reply 2 of 3, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Crap, that was me again - my login keeps timing out

Reply 3 of 3, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Plus, a 286 did some instructions in less clock cycles than a 8086, and needed more for others. Which is true for all CPUs - you'd need individual timings for each model. A whole lot of work for what gain? There is nothing that could run out of sync, like you say - sometimes it would run faster, sometimes slower, nothing more, and that's ONLY IF a program had real bad luck. In reality, programs use a mix of instructions which makes this theoretical problem vanish. Remember that even a 8086 and an 8088 already had different timings due to different bus latencies (memory access duration, for example).