added 220 characters in body
Source Link
Michael Karcher
  • 5.6k
  • 3
  • 15
  • 39

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software (not only games) that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 6.0): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, this time in version 7.0 resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.
  • Windows 95 on AMD K6 processors with 350 MHz or more, resulting in the patch called AMDK6UPD (mentioned by Eric Towers)

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 6.0): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, this time in version 7.0 resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software (not only games) that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 6.0): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, this time in version 7.0 resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.
  • Windows 95 on AMD K6 processors with 350 MHz or more, resulting in the patch called AMDK6UPD (mentioned by Eric Towers)
Fixed turbo pascal versions
Source Link
Michael Karcher
  • 5.6k
  • 3
  • 15
  • 39

Your premise that the point of the Turbo button was originally to slow down the computer to be timing compatible to an IBM PC/XT is correct. There was demand for that function, because a some of software, mostly games, were not synchronized to any timing source, but just scaled with the CPU frequency. some examples I encountered at that time are:

As you correctly identified, more modern computers are unable to enter a mode that has the same speed as the IBM PC/XT. This actually started as early as

  • 1984: the Compaq Deskpro, containing an 8086 processor that executed notably faster than the IBM PC/XT on software that was bound by main memory performance. The 8088 of the PC is known to be limited by the bandwidth of its 8-bit bus, whereas the Compaq Deskpro had 16-bit memory access.
  • Also 1984: the IBM AT, not only featuring a 16-bit memory bus, but also the 80286 processor that executes some instructions a lot faster than both the 8088 and the 8086.

Yet the Turbo button was still a useful feature. Even if the games did not run at the intended speed, they often were still playable at the slightly increased speed these machines had in de-turbo mode, while they were nearly unplayable in turbo mode. I remember quite well that I considered "Bugs" to be an unplayable game (on a 12MHz 80286 machine) until I had access to an old 8088 machine that had a 4,77MHz mode. On the other hand, digger was quite playable at the de-turbo mode of said 80286 machine (which happened to be 8 MHz).

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 56.50): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, this time in version 7.0 resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

So while the original purpose of the Turbo button, to be compatible to the IBM PC, was lost soon, the general concept of being able to slow down a machine to make a wider range of software run well on it was useful for a much longer time. As I observed it, the Turbo button started to disappear in the mid-90s, when multitasking got commonplace, and even games started to move to being Windows-95-based instead of DOS-based.

Your premise that the point of the Turbo button was originally to slow down the computer to be timing compatible to an IBM PC/XT is correct. There was demand for that function, because a some of software, mostly games, were not synchronized to any timing source, but just scaled with the CPU frequency. some examples I encountered at that time are:

As you correctly identified, more modern computers are unable to enter a mode that has the same speed as the IBM PC/XT. This actually started as early as

  • 1984: the Compaq Deskpro, containing an 8086 processor that executed notably faster than the IBM PC/XT on software that was bound by main memory performance. The 8088 of the PC is known to be limited by the bandwidth of its 8-bit bus, whereas the Compaq Deskpro had 16-bit memory access.
  • Also 1984: the IBM AT, not only featuring a 16-bit memory bus, but also the 80286 processor that executes some instructions a lot faster than both the 8088 and the 8086.

Yet the Turbo button was still a useful feature. Even if the games did not run at the intended speed, they often were still playable at the slightly increased speed these machines had in de-turbo mode, while they were nearly unplayable in turbo mode. I remember quite well that I considered "Bugs" to be an unplayable game (on a 12MHz 80286 machine) until I had access to an old 8088 machine that had a 4,77MHz mode. On the other hand, digger was quite playable at the de-turbo mode of said 80286 machine (which happened to be 8 MHz).

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 5.5): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

So while the original purpose of the Turbo button, to be compatible to the IBM PC, was lost soon, the general concept of being able to slow down a machine to make a wider range of software run well on it was useful for a much longer time. As I observed it, the Turbo button started to disappear in the mid-90s, when multitasking got commonplace, and even games started to move to being Windows-95-based instead of DOS-based.

Your premise that the point of the Turbo button was originally to slow down the computer to be timing compatible to an IBM PC/XT is correct. There was demand for that function, because a some of software, mostly games, were not synchronized to any timing source, but just scaled with the CPU frequency. some examples I encountered at that time are:

As you correctly identified, more modern computers are unable to enter a mode that has the same speed as the IBM PC/XT. This actually started as early as

  • 1984: the Compaq Deskpro, containing an 8086 processor that executed notably faster than the IBM PC/XT on software that was bound by main memory performance. The 8088 of the PC is known to be limited by the bandwidth of its 8-bit bus, whereas the Compaq Deskpro had 16-bit memory access.
  • Also 1984: the IBM AT, not only featuring a 16-bit memory bus, but also the 80286 processor that executes some instructions a lot faster than both the 8088 and the 8086.

Yet the Turbo button was still a useful feature. Even if the games did not run at the intended speed, they often were still playable at the slightly increased speed these machines had in de-turbo mode, while they were nearly unplayable in turbo mode. I remember quite well that I considered "Bugs" to be an unplayable game (on a 12MHz 80286 machine) until I had access to an old 8088 machine that had a 4,77MHz mode. On the other hand, digger was quite playable at the de-turbo mode of said 80286 machine (which happened to be 8 MHz).

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 6.0): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, this time in version 7.0 resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

So while the original purpose of the Turbo button, to be compatible to the IBM PC, was lost soon, the general concept of being able to slow down a machine to make a wider range of software run well on it was useful for a much longer time. As I observed it, the Turbo button started to disappear in the mid-90s, when multitasking got commonplace, and even games started to move to being Windows-95-based instead of DOS-based.

added 155 characters in body
Source Link
Michael Karcher
  • 5.6k
  • 3
  • 15
  • 39

Your premise that the point of the Turbo button was originally to slow down the computer to be timing compatible to an IBM PC/XT is correct. There was demand for that function, because a some of software, mostly games, were not synchronized to any timing source, but just scaled with the CPU frequency. some examples I encountered at that time are:

As you correctly identified, more modern computers are unable to enter a mode that has the same speed as the IBM PC/XT. This actually started as early as

  • 1984: the Compaq Deskpro, containing an 8086 processor that executed notably faster than the IBM PC/XT on software that was bound by main memory performance. The 8088 of the PC is known to be limited by the bandwidth of its 8-bit bus, whereas the Compaq Deskpro had 16-bit memory access.
  • Also 1984: the IBM AT, not only featuring a 16-bit memory bus, but also the 80286 processor that executes some instructions a lot faster than both the 8088 and the 8086.

Yet the Turbo button was still a useful feature. Even if the games did not run at the intended speed, they often were still playable at the slightly increased speed these machines had in de-turbo mode, while they were nearly unplayable in turbo mode. I remember quite well that I considered "Bugs" to be an unplayable game (on a 12MHz 80286 machine) until I had access to an old 8088 machine that had a 4,77MHz mode. On the other hand, digger was quite playable at the de-turbo mode of said 80286 machine (which happened to be 8 MHz).

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 5.5): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

So while the original purpose of the Turbo button, to be compatible to the IBM PC, was lost soon, the general concept of being able to slow down a machine to make a wider range of software run well on it was useful for a much longer time. As I observed it, the Turbo button started to disappear in the mid-90s, when multitasking got commonplace, and even games started to move to being Windows-95-based instead of DOS-based.

Your premise that the point of the Turbo button was originally to slow down the computer to be timing compatible to an IBM PC/XT is correct. There was demand for that function, because a some of software, mostly games, were not synchronized to any timing source, but just scaled with the CPU frequency. some examples I encountered at that time are:

As you correctly identified, more modern computers are unable to enter a mode that has the same speed as the IBM PC/XT. This actually started as early as

  • 1984: the Compaq Deskpro, containing an 8086 processor that executed notably faster than the IBM PC/XT on software that was bound by main memory performance. The 8088 of the PC is known to be limited by the bandwidth of its 8-bit bus, whereas the Compaq Deskpro had 16-bit memory access.
  • Also 1984: the IBM AT, not only featuring a 16-bit memory bus, but also the 80286 processor that executes some instructions a lot faster than both the 8088 and the 8086.

Yet the Turbo button was still a useful feature. Even if the games did not run at the intended speed, they often were still playable at the slightly increased speed these machines had in de-turbo mode, while they were nearly unplayable in turbo mode. I remember quite well that I considered "Bugs" to be an unplayable game (on a 12MHz 80286 machine) until I had access to an old 8088 machine that had a 4,77MHz mode. On the other hand, digger was quite playable at the de-turbo mode of said 80286 machine (which happened to be 8 MHz).

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 5.5): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

So while the original purpose of the Turbo button, to be compatible to the IBM PC, was lost soon, the general concept of being able to slow down a machine to make a wider range of software run well on it was useful for a much longer time. As I observed it, the Turbo button started to disappear in the mid-90s, when multitasking got commonplace, and even games started to move to being Windows-95-based instead of DOS-based.

Your premise that the point of the Turbo button was originally to slow down the computer to be timing compatible to an IBM PC/XT is correct. There was demand for that function, because a some of software, mostly games, were not synchronized to any timing source, but just scaled with the CPU frequency. some examples I encountered at that time are:

As you correctly identified, more modern computers are unable to enter a mode that has the same speed as the IBM PC/XT. This actually started as early as

  • 1984: the Compaq Deskpro, containing an 8086 processor that executed notably faster than the IBM PC/XT on software that was bound by main memory performance. The 8088 of the PC is known to be limited by the bandwidth of its 8-bit bus, whereas the Compaq Deskpro had 16-bit memory access.
  • Also 1984: the IBM AT, not only featuring a 16-bit memory bus, but also the 80286 processor that executes some instructions a lot faster than both the 8088 and the 8086.

Yet the Turbo button was still a useful feature. Even if the games did not run at the intended speed, they often were still playable at the slightly increased speed these machines had in de-turbo mode, while they were nearly unplayable in turbo mode. I remember quite well that I considered "Bugs" to be an unplayable game (on a 12MHz 80286 machine) until I had access to an old 8088 machine that had a 4,77MHz mode. On the other hand, digger was quite playable at the de-turbo mode of said 80286 machine (which happened to be 8 MHz).

While the relevance of IBM PC games that only were playable at 4.77MHz dropped significantly at the end of the eighties, the general concept of software that failed to perform correctly on machines that were faster than the developers of the software tested on was a recurring theme. Some examples are:

  • Turbo Pascal's delay loop (up to version Turbo Pascal 5.5): The machine speed counter overflowed and delays were to small. An example game that used this code is 20th Century Frog, 1988 Gameplay Video here. On a 486 machine with 33MHz CPU clock, the intro music (played via Timer interrupts) matched the intro animation (timed using Pascal's delay function) only in de-turbo mode.
  • Again Turbo Pascal's delay loop, resulting in Runtime Error 200 on startup.
  • A couple of games that synchronized their speed to video refresh, but actually expected to be at half the video refresh rate, because their game code took more than one frame to execute. On faster computers, these games suddenly ran at double speed, because they locked to every frame instead of every other frame. A notable example is the game Supaplex. There exists a wide-spread "speed fix" version that prevents running at 70fps instead of 35fps. Please note that the version at archive.org I linked does not seem to run at the intended speed in the javascript dosbox.

So while the original purpose of the Turbo button, to be compatible to the IBM PC, was lost soon, the general concept of being able to slow down a machine to make a wider range of software run well on it was useful for a much longer time. As I observed it, the Turbo button started to disappear in the mid-90s, when multitasking got commonplace, and even games started to move to being Windows-95-based instead of DOS-based.

Source Link
Michael Karcher
  • 5.6k
  • 3
  • 15
  • 39
Loading