5

In the old days, it sometimes happened that a computer with a compatible but faster CPU, had problems running old games. For example, Sopwith was written for an 8088 PC; it was amusingly challenging on a 286, completely unplayable on a 386. For a while, it was not unusual for PCs to have switchable clock speed (typically via a button labelled 'Turbo') to deal with this.

The proper solution, of course, was for games to start locking frame rate to the display refresh. That solution focuses on the display. What about sound?

The ideal scenario is a sound chip with a decent amount of autonomy, so it gets handed some stuff to play, and goes ahead and plays it without further intervention from the CPU. That both offloads work and avoids speed dependency.

But early computers didn't have such sophisticated technology. For example, the Apple II and the CoCo had sound hardware consisting of little more than a DAC, so the CPU had to be continually involved; doubling the clock speed would presumably be expected to double the pitch of the sound.

Are there any known cases, on any platform, where games did lock to the display refresh rate, but still had problems on faster machines, specifically because of the sound playing too fast?

Edit: As Michael Kjörling observes, the really proper solution is to synchronize display with the CRT refresh, while simultaneously using a separate timer as a way to time stuff happening. I'm not aware of anyone doing this before the nineties, but maybe some developers did. One reason it wasn't done in the eighties is that you can't strictly adhere to that discipline with a 2-D game because you can't really move things non-integral numbers of pixels.

16
  • 2
    I'm assuming that "locked to the display rate, then got exported from a PAL country to an NTSC country so everything played too fast" doesn't count? Faster as in: same model, same (or similar) processing speed, different refresh rate, is probably stretching the question?
    – Tommy
    Jan 3, 2018 at 14:21
  • 2
    "The proper solution, of course, was for games to start locking frame rate to the display refresh." Citation needed for the claim that this was the proper solution. For example, you've got a perfectly good 18.2 Hz timer in any IBM PC compatible, which could easily be used to calibrate a delay loop. Doing so, and then tying both display refresh and sound to that same delay loop, seems a far more "proper" solution than to tie sound to the display refresh rate.
    – user
    Jan 3, 2018 at 14:55
  • 2
    I've talked myself out of it since there's no CPU speedup on the machines I'm thinking of, contrary to the question title. But the MSX is a good example — big in Japan and popular enough in Europe to acquire lazy Spectrum ports, which carry their audio over exactly. It's an AY + toggle so tone generation is mostly automated but they generally use the refresh interrupt for timing. So tempo is very obviously wrong, being sped up by the 20%, if you play them on an NTSC machine. The famous Robocop (of Ariston advert fame — youtube.com/watch?v=iqHkGX6VrUQ ) is very obviously wrong.
    – Tommy
    Jan 3, 2018 at 14:56
  • 1
    "but then you're going to get tearing because you aren't synchronized with the CRT refresh" Only if you use only a single delay loop value. You'd obviously need to adjust for however much work you've been doing in the interim. Lots of detail stuff, but such was life when programming that class of machines to do anything timing-sensitive...
    – user
    Jan 3, 2018 at 15:02
  • 1
    There were definitely machines where you could only poll for CRT refresh but which had separate timers (such as the Vic-20), but I think standard practice was just to set up your timer to match CRT refresh, to make it an interrupt event.
    – Tommy
    Jan 3, 2018 at 15:12

1 Answer 1

3

As @MichaelKjörling says "For example, you've got a perfectly good 18.2 Hz timer in any IBM PC compatible, which could easily be used to calibrate a delay loop. "

It could be done indeed, any program could program a counter in the the PIT 8253/8254 that any PC compatible has (or emulates). I however have no idea if any game used it for graphics/sound timing.

I used that chipset programming the TAPE2TAP util around 1995, that digitises sound from tapes from the Sinclair ZX Spectrum to DOS files, and the Warajevo emulator also used my routines also for independent CPU speed sound sampling (with my permission). see PIT.INC in my sources.

The Intel 8253 and 8254 are Programmable Interval Timers (PITs), which perform timing and counting functions using three 16-bit counters.[1] They were primarily designed for the Intel 8080/8085-processors, but later used in x86-systems. They (or an equivalent circuit embedded in a larger chip) are found in all IBM PC compatibles. In PC compatibles, timer channel 0 is assigned to IRQ-0 (the highest priority hardware interrupt), channel 1 is assigned to DRAM refresh (at least in early models), and channel 2 is assigned to the PC speaker.

TBH, I hardly believe my software would be the only example in that time period. The technology was there usable from DOS from the beginning (XT times) to achieve CPU speed independency in time sensitive routines/loops.

2
  • 1
    I recall one proof-of-concept — exactly one — from the 486 era of PCs that attempted to measure the refresh rate and set the timer for a mid-frame interrupt, to import mid-frame palette changes to the PC. Though even then it was unstable, and it's perceptively a lot less impressive to go from 256 colours to 512 than from, say, 16 to 32, as you still just remain generally aware that there obviously aren't unlimited options but that there are clearly a lot of them.
    – Tommy
    Jan 4, 2018 at 16:33
  • @Tommy The problem may stem exactly from having a lot of them. The 8253 is common to ALL machines. I do remember the boon that was having the X mode in all VGA compatibles for instance. Jan 4, 2018 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .