5 ms·

Related but completely different: All MS-DOS programs built with Turbo/Borland Pascal stopped working on ~200+ MHz Pentium CPUs because of a sleep calibration l

by tpmx 4y ago

Related but completely different: All MS-DOS programs built with Turbo/Borland Pascal stopped working on ~200+ MHz Pentium CPUs because of a sleep calibration loop that ended up going too fast and causing a divide by zero in the runtime library: http://www.pcmicro.com/elebbs/faq/rte200.html http://www.pcmicro.com/elebbs/faq/rte200.html

TazeTSchnitzel 4y ago
I read somewhere that Windows 95 has several such loops that have to patched to get it to run on modern CPUs.
- benjaminpv 4y ago
  Yep, you still see it come up nowadays with people running it under virtualization. https://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/ https://www.os2museum.com/wp/those-win9x-crashes-on-fast-mac...
cf100clunk 4y ago
Another 68000 system time related bug but completely different problem (former Apollo/Domain sysadmin here, which I became at one company because I was already doing their Unix sysadmin job. We had to periodically reset the system clocks on those): ''The bug apparently results from the high 32 bits of the clock data type being declared as a 31 bit value instead of 32 bit in the pascal include files. The reason for this is lost to history, but early pascal compilers may have had problems with 32 bit unsigned numbers, possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations.'' https://jim.rees.org/apollo-archive/date-bug https://jim.rees.org/apollo-archive/date-bug
- tpmx 4y ago
  Do I understand this correctly - it was a 31-bit version of the 32-bit Y2K38 problem?
  - xxpor 4y ago
    The year 2038 problem is a 31 bit problem: time_t is signed (in POSIX).
    - tpmx 4y ago
      So, was it a 30-bit problem?
      - KMag 4y ago
        It looks like maybe Apollo/Domain systems use an epoch of 1929-10-14 instead of 1970-01-01. Maybe that's the birthday of one of the early developers (or their spouse). There's nothing particularly magical about the Unix epoch.
        toast0 4y ago
        > There's nothing particularly magical about the Unix epoch. It's the beginning of time, everything before is Omphalos; even the Omphalos conjecture itself; Unix is meta like that.
        owl57 4y ago
        > There's nothing particularly magical about the Unix epoch. When you have to debug the same event reported in five different timezones, and then see some ugly 13-digit numbers and immediately know that's milliseconds since a certain globally-coherent moment… That moment definitely starts to feel magic.
        cf100clunk 4y ago
        > 1929-10-14 Hmmm, about 2 weeks before the Wall Street Crash of 1929, so I doubt it refers specifically to that.
- mikepavone 4y ago
  > possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations. This doesn't really make sense as an explanation. For both signed and unsigned multiply, the 68000 has a 16x16 -> 32 multiply. This is indeed kind of inconvenient if you need to multiply 32-bit numbers, but 31-bit numbers are not any easier. If anything, the unsigned cases is easier to reason about than the signed one
  - lokedhs 4y ago
    Not only that, the M68k has the mulu.l instruction which is an unsigned 32-bit multiplication instruction. Go it has all the instructions you need.
    - mikepavone 4y ago
      The 68000 lacks that instruction. It was added in the 68020.
TonyTrapp 4y ago
Up to this day I find it fascinating that the runtime error number just so perfectly coincides with the approximate speed at which the error will happen.
nottorp 4y ago
Ohh I was there on my first programming job, still a student :) I think we recompiled the RTL and then distributed new binaries with the working RTL.
- tpmx 4y ago
  At Borland? Cool!
  - nottorp 4y ago
    Lol no. At a company selling products done in Turbo Pascal and then Delphi. As our customers for the Turbo Pascal product upgraded their machines, the application started to freeze on launch...
the_af 4y ago
One early videogame that got this right was Alley Cat... in '83! The x86 version, coded in assembly language, works at the right speed regardless of CPU speed. MobyGames has this to say [1]: > "Alley Cat was one of the few games of the 1980s that was programmed with full attention to different PC speeds. It's an early, old game--yet it runs perfectly on any machine. The reason it runs on any computer today is, upon loading, the first thing it performs is a mathematical routine to determine the speed of your processor, and as of 2003 we've yet to build an Intel PC too fast to play it." I had a lot of fun with this game back in the day, when I got my first PC, an XT clone (with Hercules graphics card and "amber" monochrome CRT!). ---- [1] https://www.mobygames.com/game/alley-cat https://www.mobygames.com/game/alley-cat
- tpmx 4y ago
  I had a lot of fun with Alley Cat, Sopwith Camel, digger (https://digger.org/ https://digger.org/), GW-Basic and Turbo Pascal 3.0 or so when my computer finally got upgraded from a ZX81 (I got it in 1984 as a handmedown from a relative) to an Amstrad PC1512 in 1988 (thanks, supportive parents). The British truly ruled the low-end computer market in Europe back then.
  - the_af 4y ago
    Lots of love for GW Basic here! It was my first "true" programming language. I started with C64 BASIC but it was too limited to do actual interesting things, at least while not resorting to the cheat of PEEK and POKE.
- astrange 4y ago
  That seems like it'd break if your CPU speed changed during runtime, which it could due to power saving, or being AMP instead of SMP, etc…
  - KerrAvon 4y ago
    Absolutely. None of that would have been a concern back in 1983, though. And it still won't be as badly broken as every other game released in 1983.
dylan604 4y ago
I was too young to know/understand the hows and whys, but I do remember having a couple of programs that you had to disable the turbo button on the front of the computer for them to run. I always thought it silly to have a button to intentionally slow down the computer, but yet it absolutely was required.

by tpmx 4y ago

TazeTSchnitzel 4y ago

I read somewhere that Windows 95 has several such loops that have to patched to get it to run on modern CPUs.

benjaminpv 4y ago
Yep, you still see it come up nowadays with people running it under virtualization. https://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/ https://www.os2museum.com/wp/those-win9x-crashes-on-fast-mac...

cf100clunk 4y ago

Another 68000 system time related bug but completely different problem (former Apollo/Domain sysadmin here, which I became at one company because I was already doing their Unix sysadmin job. We had to periodically reset the system clocks on those): ''The bug apparently results from the high 32 bits of the clock data type being declared as a 31 bit value instead of 32 bit in the pascal include files. The reason for this is lost to history, but early pascal compilers may have had problems with 32 bit unsigned numbers, possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations.'' https://jim.rees.org/apollo-archive/date-bug https://jim.rees.org/apollo-archive/date-bug

tpmx 4y ago
Do I understand this correctly - it was a 31-bit version of the 32-bit Y2K38 problem?
- xxpor 4y ago
  The year 2038 problem is a 31 bit problem: time_t is signed (in POSIX).
  - tpmx 4y ago
    So, was it a 30-bit problem?
    - KMag 4y ago
      It looks like maybe Apollo/Domain systems use an epoch of 1929-10-14 instead of 1970-01-01. Maybe that's the birthday of one of the early developers (or their spouse). There's nothing particularly magical about the Unix epoch.
      - toast0 4y ago
        > There's nothing particularly magical about the Unix epoch. It's the beginning of time, everything before is Omphalos; even the Omphalos conjecture itself; Unix is meta like that.
      - owl57 4y ago
        > There's nothing particularly magical about the Unix epoch. When you have to debug the same event reported in five different timezones, and then see some ugly 13-digit numbers and immediately know that's milliseconds since a certain globally-coherent moment… That moment definitely starts to feel magic.
      - cf100clunk 4y ago
        > 1929-10-14 Hmmm, about 2 weeks before the Wall Street Crash of 1929, so I doubt it refers specifically to that.
mikepavone 4y ago
> possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations. This doesn't really make sense as an explanation. For both signed and unsigned multiply, the 68000 has a 16x16 -> 32 multiply. This is indeed kind of inconvenient if you need to multiply 32-bit numbers, but 31-bit numbers are not any easier. If anything, the unsigned cases is easier to reason about than the signed one
- lokedhs 4y ago
  Not only that, the M68k has the mulu.l instruction which is an unsigned 32-bit multiplication instruction. Go it has all the instructions you need.
  - mikepavone 4y ago
    The 68000 lacks that instruction. It was added in the 68020.

TonyTrapp 4y ago

Up to this day I find it fascinating that the runtime error number just so perfectly coincides with the approximate speed at which the error will happen.

nottorp 4y ago

Ohh I was there on my first programming job, still a student :) I think we recompiled the RTL and then distributed new binaries with the working RTL.

tpmx 4y ago
At Borland? Cool!
- nottorp 4y ago
  Lol no. At a company selling products done in Turbo Pascal and then Delphi. As our customers for the Turbo Pascal product upgraded their machines, the application started to freeze on launch...

the_af 4y ago

One early videogame that got this right was Alley Cat... in '83! The x86 version, coded in assembly language, works at the right speed regardless of CPU speed. MobyGames has this to say [1]: > "Alley Cat was one of the few games of the 1980s that was programmed with full attention to different PC speeds. It's an early, old game--yet it runs perfectly on any machine. The reason it runs on any computer today is, upon loading, the first thing it performs is a mathematical routine to determine the speed of your processor, and as of 2003 we've yet to build an Intel PC too fast to play it." I had a lot of fun with this game back in the day, when I got my first PC, an XT clone (with Hercules graphics card and "amber" monochrome CRT!). ---- [1] https://www.mobygames.com/game/alley-cat https://www.mobygames.com/game/alley-cat

tpmx 4y ago
I had a lot of fun with Alley Cat, Sopwith Camel, digger (https://digger.org/ https://digger.org/), GW-Basic and Turbo Pascal 3.0 or so when my computer finally got upgraded from a ZX81 (I got it in 1984 as a handmedown from a relative) to an Amstrad PC1512 in 1988 (thanks, supportive parents). The British truly ruled the low-end computer market in Europe back then.
- the_af 4y ago
  Lots of love for GW Basic here! It was my first "true" programming language. I started with C64 BASIC but it was too limited to do actual interesting things, at least while not resorting to the cheat of PEEK and POKE.
astrange 4y ago
That seems like it'd break if your CPU speed changed during runtime, which it could due to power saving, or being AMP instead of SMP, etc…
- KerrAvon 4y ago
  Absolutely. None of that would have been a concern back in 1983, though. And it still won't be as badly broken as every other game released in 1983.

dylan604 4y ago

I was too young to know/understand the hows and whys, but I do remember having a couple of programs that you had to disable the turbo button on the front of the computer for them to run. I always thought it silly to have a button to intentionally slow down the computer, but yet it absolutely was required.