Background
Video games for early 1980s home computers (such as Apple II family, Commodore 64, ZX Spectrum, IBM PC, etc) often based their timing on CPU loops of the form
for(i = 10000; i > 0; i--) { }
This turned out not to respond correctly when newer computers came out with faster CPUs. The game would run too fast to be playable, or the disk driver would not synchronize with the rotating media. Some computers such as early 286 based PCs and Apple IIGS computers solved this with a "turbo button" on the front panel or in the BIOS to select the machine's speed.
The following video games are notorious for not using a proper frame limiter and requiring a software CPU limiter such as Mo'Slo:
True frame limiters
A well-designed real-time application will synchronize itself to some clock signal with a constant period. This could be the signal from the operating system's scheduler, the tick of a real-time clock, or (most commonly in video games) the 50Hz, 60Hz, or 70Hz vblank signal from the video circuitry. Thus, software will run at the proper speed even on future machines with faster CPUs.
CPU-based frame limiters
Some programs run on platforms with a very coarse scheduler, such as the 18.2 Hz default timer setting of PCs or (worse yet) the 1.00 Hz timer of some real-time clocks. They make do by calibrating a CPU loop against the scheduler at the start of the program. Programs using this technique include the Linux kernel's BogoMIPS delay code. However, once CPU speeds become fast enough, some of these programs will crash with a division by zero error or overflow because a program written to adapt to a 10-100 MHz machine might not function once the speed gets up to 1000 MHz.
The following video games' CPU-based limiters don't work on modern hardware: