I have co-authored a suite of Turbo Pascal 7 statistical programs
(using crt) that produce "Runtime error 200" messages when used
with fast processors.  This problem is apparently cured by at
least three of the solutions I have found on the Internet, and
the following query relates to a different phenomenon:

A user of the (unmodified and unpatched) programs, who has
switched to a Pentium II processor running at 266 MHz, reports
strange behaviour when he tries them in a DOS shell from Windows
95.  Usually they give "Runtime error 200" messages. But he can
get them to work if he first uses DIR or DIR /p.  Here is what he
says:

In article <35733E98.3...@vms.huji.ac.il>,
Joe Abramson  <j...@vms.huji.ac.il> wrote:

Now consider what happens if something that causes significant delay
(typically disk access) is done on the first timer interrupt, like a disk
cache wants to write modified blocks on the disk. Such a disk access can
easily cause 20ms delay. Now with that delay TP only gets 35ms for the
actual loop count and thus the counts will be smaller and if the
processor is just above the threshold and not, say, twice faster no error
will occur.

The above of course shows also why the delay is inaccurate. Any
significant background activity can cause the delays to become too short.
This means a single random event during the calibration can cause an
error for all the delays during that execution.

Now I do not specifically know why or how (or even if) the disk caching
does that in the particular case. You could try turning delayed writes
off by "smartdrv c" (for c drive).