rasz_pl wrote on 2023-08-29, 08:21:

Error comes from Turbo Pascal 6 (released in 1990). Both published by Epic (as shareware?). Jazz was Arjan Brussee first game, Tyrian Jason Emery first PC game/program ever. I think Epic dgaf about those games and treated them more as developer orientation.

I'm sure programmer (in)experience played a role with shipping the games in such a state. But it doesn't change the fact that you couldn't play the retail (not just shareware) versions of those games on a Pentium 2 CPU (1997) without getting hit by runtime error 200. That's just two years after Tyrian originally shipped.

Nowadays, there are tools which allow you to patch the executable and bypass that bug, but did those exist in 1997? Somehow I doubt it.

Lastly, as others have mentioned, some game installers were affected by the runtime error 200 bug as well. The CD version of Terminal Velocity (1995) is one such example. And good luck patching the installer executable on the CD. 😁

Joseph_Joestar wrote on 2023-08-28, 18:48:

The retail versions of Jazz Jackrabbit (1994) and Tyrian (1995) both suffer from runtime error 200.
It's not limited to early '90s DOS games.

Runtime error 200 is ususally caused by a library shipped even with with Borland Pascal 7 in late 1992. BP7 was very popular in the heydays of DOS and many programs were written with it in the following years. Strictly speaking it's not the actual game code that has problems running on fast CPUs but it's only the initialization of said library (CRT). There are patches for that

Nowadays, there are tools which allow you to patch the executable and bypass that bug, but did those exist in 1997? Somehow I doubt it.

They did. As soon as faster CPUs were available the problem showed up and was solved pretty quickly. There were even patches for the source code of the pascal library available so that compiled programs were free from this bug.

HanSolo wrote on 2023-08-29, 09:16:

They did. As soon as faster CPUs were available the problem showed up and was solved pretty quickly. There are even patches for the source code of the pascal library available so that compiled programs were free from this bug.

That's nice, but how many PC gamers knew about those patching tools at that time? I personally had no idea such things existed until I started frequenting Vogons. On the other hand, I painfully remember getting a runtime error 200 while attempting to play Tyrian on my Celeron 333 back in the day.

Also, while you can certainly patch games to get rid of this, that becomes really tedious if you're just trying out a bunch of (shareware) games for the first time and getting randomly hit by this bug. I just wouldn't want to bother with this issue when it can be completely avoided by using a Pentium MMX system instead of a Pentium 2 system. But, to each their own, I suppose.

I'm not saying that I find this bug in any way amusing 😀 Only where it comes from and that it can be solved somewhat easily. Of course back then it was a big problem and today any game affected should be on the list.

Here's an article from a popular german computer magazine from 2000. They mention that they already pointed out this bug in 1997 together with a patch for the lib source code.

I'm sure programmer (in)experience played a role with shipping the games in such a state.

But you can't blame the game coders for a bug in a library of the programming language that wasn't known until newer hardware came out. The worst thing about it is that the broken code is executed even if the actual function that the initialization is for (delay) is not used in the program.
I'm sure the writers of the library weren't inexperienced but I'd like to know what they were thinking about when they wrote this code.

HanSolo wrote on 2023-08-29, 09:53:

Here's an article from a popular german computer magazine from 2000. They mention that they already pointed out this bug in 1997 together with a patch for the lib source code.

Heh, I like how they start the article with "Nicht Schon Wieder" (not again) which indicates that this issue wasn't exactly rare. 😁 Pretty cool if they had this already pinned down even back then. Obviously, it's much easier to deal with nowadays, unless the affected executable happens to be on a CD, like with the aforementioned Terminal Velocity. You can of course burn a copy of the disc with a fixed executable, but once again, that takes extra effort.

I guess my points are:

1. Despite its early '90s roots, the "runtime error 200" bug was still affecting retail games which shipped during 1994 and 1995 (maybe even later?)
2. I would prefer to use a slower system for DOS gaming, instead of being forced to apply workarounds for every single game that's affected by this bug

That's just my personal preference though. Maybe someone else wouldn't mind patching all of their affected games and burning backup CDs where needed. I'd rather not deal with that at all, if given the choice.

A cheap i440LX based mainboard (asus P2L97 and the like) might be another option. The 400 would run at 266, which brings it into just above the speed of the fastest Pentium P55C. I don't know how expensive the slot 1 mainboards go in OT's area, but the LX is cheap and versatile, and supports up to the 533/128 Celeron using the simplest of slockets.

flupke11 wrote on 2023-08-29, 11:13:

A cheap i440LX based mainboard (asus P2L97 and the like) might be another option. The 400 would run at 266, which brings it into just above the speed of the fastest Pentium P55C. I don't know how expensive the slot 1 mainboards go in OT's area, but the LX is cheap and versatile, and supports up to the 533/128 Celeron using the simplest of slockets.

Thanks for the advice. The avaibility and the price of the asus P2L97 would be ok.

A board with a lx chipset sounds like option worth considering that is for sure.

Have done some further research in the mean time and many games I am interested in playing might not run that well on a faster machine.

In order to be on the safe side when running these games having a dedicated slower machine for that kind of games seems to be the safest bet.

You might want to check if the VRM on an LX board can go down to the 2.0 volts of the P2-400, I don't know if early boards were only Klamath compatible?

Some 400MHz Pentium-2 CPUs are unlocked. I don't know if anybody has found a reliable way to tell from serial numbers, you'd probably have to try it to find out.
So if it's an unlocked example, it might be able to run at 133MHz (I think 2X is the minimum multiplier) - but from what I've read this simultaneously disables the L2 cache so the effect could be more severe than you want.

If you want to run at 66FSB, you could still get a 440BX board and just set the FSB manually. Most retail boards should have a jumper for that. OEM boards and Intel boards should be avoided as they won't give you this option.
440LX boards should generally be cheaper though, because everybody wants a BX.
A downside with 440LX boards is that many of them have issues with running higher powered AGP video cards. By the time of 440BX boards that issue was mostly resolved.

H3nrik V! wrote on 2023-08-29, 21:21:

You might want to check if the VRM on an LX board can go down to the 2.0 volts of the P2-400, I don't know if early boards were only Klamath compatible?

Voltage shouldn't be an issue, the earlier VRMs on Slot-1 boards still supported down to 1.8V (this was an Intel spec).
Some early LX boards have a BIOS compatibility issue with Deschutes though. If you stick to retail "home build" oriented boards then most of those should have updates to fix this, but you'd need a Klamath to perform the update, unless retep has a separate chip programmer.