If yous've ever tried to go a vintage calculator game up and running on a modern system, you've likely been shocked at howfast the game ran. Why do old games run out of control on modernistic hardware?

Earlier today nosotros showed you how to run older software on modernistic computers; today'south question and reply session is a dainty compliment that digs into why some older software (specifically games) never seem to work right when you try to run them on modernistic hardware.

Today's Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Substitution, a customs-driven group of Q&A spider web sites.

The Question

SuperUser reader TreyK wants to know why old computer games run crazy fast on new hardware:

I've got a few old programs I pulled off an early 90s-era Windows computer and tried to run them on a relatively mod computer. Interestingly enough, they ran at a blazing fast speed – no, not the 60 frames per second kind of fast, rather the oh-my-god-the-character-is-walking-at-the-speed-of-audio kind of fast. I would press an pointer fundamental and the grapheme's sprite would zip across the screen much faster than normal. Time progression in the game was happening much faster than it should. There are even programs made to ho-hum downwardly your CPU and then that these games are actually playable.

I've heard that this is related to the game depending on CPU cycles, or something like that. My questions are:

  • Why practice older games do this, and how did they get abroad with it?
  • How do newer gamesnot exercise this and run independently of the CPU frequency?

And then what's the story? Why exactly do the sprites in quondam games bonfire beyond the screen so fast the game becomes unplayable?

The Respond

SuperUser contributor JourneymanGeek breaks information technology down:

I believe they assumed the system clock would run at a specific charge per unit, and tied in their internal timers to that clock rate. Near of these games probably ran on DOS, and were real fashion (with complete, directly hardware access) and causeless y'all were running aiirc iv.77 MHz system for PCs and any standard processor that model ran for other systems like the Amiga.

They also took clever shortcuts based on those assumptions including saving a tiny fleck of resources by not writing internal timing loops inside the program. They also took up as much processor power as they could – which was a decent idea in the days of slow, oftentimes passively cooled chips!

Initially one way to get around differing processor speed was the good former Turbo button (which slowed your system down). Mod applications are in protected manner and the OS tends to manage resources – they wouldn'tlet a DOS application (which is running in NTVDM on a 32-bit organisation anyway) to utilize upward all of the processor in many cases. In short, OSes have gotten smarter, every bit have APIs.

Heavily based off this guide on Oldskool PC where logic and memory failed me – it's a great read, and probably goes more than in depth into the "why".

Stuff like CPUkiller apply up as many resources as possible to "slow" downwards your system, which is inefficient. Y'all'd be better off using DOSBox to manage the clock speed your application sees.

If you're curious about how the actual code was implemented in early on computer games (and why they adapt and so poorly to modern systems without beingness sandboxed in some sort of emulation program), nosotros'd also propose checking out this lengthy but interesting breakdown of procedure in another SuperUser answer.

Have something to add to the explanation? Sound off in the the comments. Want to read more answers from other tech-savvy Stack Commutation users? Check out the total discussion thread here.