                        J R Stockton, >= 2001-06-09

                          Borland Pascal Start-Up
                     Runtime Error 200 (divide by zero)

         My Merlyn Home Page; main Pascal; Delphi; a note on FAQs.

  ------------------------------------------------------------------------

Index

  1. On this RTE200 page :
        o Start-up Runtime Error 200 on machines >~  200 MHz
             + Cause,
             + Onset,
             + Demonstration,
             + Borland Statement,
             + Avoidance,
             + Palliative,
             + Overview of Some Typical Fixes,
             + Pedt Scragg's Replacement Crt Unit,
             + Andreas Bauer's Patch for EXE files,
             + Osmo Ronkanen's Loader "tfix",
             + A Patch for the Crt unit,
             + EXE patch from c't,
             + Other Fixes - Frank Heckenbach, Roger Donais, Klaus
               Hartnegg, etc.,
        o TurboPower "Object Professional",
        o Error at around 500 MHz or Above,
        o Use of my Zip-files Directories.
  2. On other pages : Pascal Time/Date including links, Wait/Delay, and
     Crt.Delay generally.
  3. Dr-Ing. Franz Glaser's site - All known patches, it appears; also many
     other things ...

See also The Crt.Delay Procedure in pas-wait.htm.

Any report of a problem with a fix must specify exactly what the fix was,
indicate that it was correctly applied, and specify the affected system.

  ------------------------------------------------------------------------

Start-up Runtime Error 200

A problem occurs for a PC with an Intel 200 MHz (or better) CPU and any
program using Borland's TP7 (DOS) or BP7 (DOS, DPMI) Crt unit; the program
gives Runtime Error 200, "divide by zero", at start-up. TSFAQP #67 A3
refers, and see #124. There has been much activity in the c.l.p.b and b.p.t
newsgroups. I use fixes by Andreas Bauer (existing EXE files), and Pedt
Scragg (new compilations). Some others are less than fully satisfactory;
see below.

I have read that the Graph unit calls the Crt unit.

I've received a report that : "the bug can also be caused by
over-enthusiastic PC emulators on PowerPC-based Macs".

A sufficient test program is :
    uses Crt ; begin end.
A slightly better one (my crt001.pas) is
    uses Crt ; begin Writeln('OK.') end.

Cause

The Borland Crt unit is included in the TURBO.TPL & TPP.TPL libraries; its
initialisation routine will be linked if Crt is cited in a uses clause. The
problem lies in the initialisation of Crt.Delay, but will appear if the Crt
unit is cited regardless of whether Delay or any other Crt routine is
called.

During Crt unit initialisation, a loop executed for 55 ms increments a
counter. Up to and in TP6, this was a 16-bit counter, and would happily
overflow on a PC above about 20 MHz, leading to subsequent incorrect
delays.

The counter in TP7 & BP7 is now 32-bit, and should not itself overflow
until processor speeds reach the 100 GHz region. But the count is divided
by 55, and if the result cannot fit into a 16-bit word, the CPU raises a
"divide overflow" error. This is reported by Borland as a "divide by zero"
error, Runtime Error 200, since the only way that a user's Pascal code can
cause a divide overflow is by dividing by zero. An asm test shows that
"divide by zero" is indeed given for divide-by-non-zero overflow; the
following program gives RTE200, but with $33 in cx does not:
            begin asm mov ax,$333 ; mov cx,$3 ; div cl end end.

See also these (1999-01-06) URLs :
Intel Support - near-correct.
Borland/Inprise Developer Support Information (general entry point) -
correct explanation.
Inside Intell - slightly wrong explanation, offers patches.

Onset

The critical clock rate evidently depends on CPU type. The error appears at
200 MHz on Intel CPUs, but AMD K6 CPUs seem not to give it at 350 MHz.

When running in a Windows DOS box, the program does not get all of the CPU
time; on my Windows 98 PII/300, I have found that Error 200 occurs in about
half of program start-ups when using the Borland Crt unit.

Reports of higher-frequency onset of the error must give system details;
include a check that removal of the Crt unit from a program removes the
problem.

Demonstration

In my Web directory currently called 20010716 :

   * crt001.pas - a simple test program, needing a Crt unit
   * crt001-a.exe - from Borland BP7, real mode, Borland Crt unit
   * crt001-b.exe - crt001-a.exe, patched with Bauer's TPPATCH.EXE
   * crt001-c.exe - as -a, but compiled with Pedt Scragg's Crt unit
   * crt001-d.exe - crt001-a.exe, patched with c't T-PENT2 ($7E)

   * crt002.pas - a better test program, needing a Crt unit
   * crt002-a.exe - from Borland BP7, real mode, Borland Crt unit
   * crt002-b.exe - crt002-a.exe, patched with Bauer's TPPATCH.EXE
   * crt002-c.exe - as -a, but compiled with Pedt Scragg's Crt unit
   * crt002-d.exe - crt002-a.exe, patched with c't T-PENT2 ($7E)

   * zipcrt.zip - ZIP of the above files, with 00index.txt

   * Further files, 2001 Mar 17-18, needing verification :
   * crt001-n.exe - BP7, protected mode, Borland Crt unit ? (*)
   * crt001-o.exe - crt001-n.exe, patched with Bauer's TPPATCH.EXE
   * crt001-p.exe - as -n, but compiled with Pedt Scragg's Crt unit
   * crt001-q.exe - crt001-n.exe, patched with c't T-PENT2 ($7E)
   * crt002-n.exe - BP7, protected mode, Borland Crt unit ?
   * crt002-o.exe - crt002-n.exe, patched with Bauer's TPPATCH.EXE
   * crt002-p.exe - as -n, but compiled with Pedt Scragg's Crt unit
   * crt002-q.exe - crt002-n.exe, patched with c't T-PENT2 ($7E)

(*) I believe that to be with the genuine Borland unit; but it does not
fail on my PII/300 in a Win98 DOS box.

I may add a little more to these - see that directory.

Borland Statement

In an article of 17 Jun 1998 in news:borland.public.turbopascal, Nap wrote
: Below is the message posted on Borland Website:

     Runtime Error 200 - 'Divide by 0'

     Applications that use the CRT unit may generate this error
     message when running on very fast machines (i.e. Pentium Pro 180
     and above). The cause of this error is a timing loop that occurs
     as part of the initialization of the CRT unit. This timing loop
     counts how many clock ticks occur within the loop and then that
     number is divided by 55. The result of this division is a value
     that is too large to fit into an integer value. The 'Divide by 0'
     error message is the catch-all error that is displayed when this
     overflow occurs.

     There are currently no Borland endorsed patches for this problem.
     There are several user provided patches available on the internet
     that patch both the CRT unit as well as existing EXE files. The
     easiest way to obtain these patches is to go to
     www.altavista.digital.com and search on '+ bp7patch.zip +
     tppatch.zip' without the quotes.

     These patches are not endorsed or supported by Borland and are
     used at your own risk.

That search recommendation naturally finds sites containing itself. Some
helpful documents don't cite both of those files in full; so try also
'bp7patch.zip tppatch.zip', 'bp7patch tppatch', and maybe adding 'crt.zip'.

Avoidance

One solution seems to me, provided that only Delay is needed from the Crt
unit, to be to write one's own Delay routine in Pascal, along the same (or
different) lines but with a longer counter. Many other routines in the unit
are easy enough to emulate.

Palliative

A palliative, for those with Windows, may be to attempt to load numerous
copies, say from a short-cut, in rapid succession. They will compete for
CPU time, and one of the losers may manage not to overflow.

Overview of Some Typical Fixes

N.B. I use those of Pedt Scragg & Andreas Bauer, but have no better than a
PII 300 MHz CPU to test with.
Frequencies are very approximate, depending on CPU design.

  1. Replacement CRT unit :
     Pedt Scragg, see mini-FAQ, OK to ~100 GHz, Delay OK.
  2. EXE patcher :
     (a) Andreas Bauer, see mini-FAQ, OK to ???, Delay OK, language German.

     (b)(i) C'T magazine, see mini-FAQ, OK to ~450 MHz, Delay reduced.
     (b)(ii) C'T magazine, see mini-FAQ, OK to ~ 3 GHz?, Delay ???.
  3. Fixing loader :
     Osmo Ronkanen, see mini-FAQ, OK to ???, Delay ???.
  4. TPL patcher :
     Rob Henningsgard, BP7PATCH, see TS faq, OK to ~100? GHz, Delay OK?.
  5. TSRs.
  6. CPU slowers.

No criticism of other fixes is intended. Are there any other distinct types
of fix?

Patches are intended to be applied to the Crt unit (source, TPU, or TPP) as
supplied by Borland, or to the EXE as generated by Borland's compiler and
library; they should not be expected to work on changed units, whatever the
purpose of the previous change (but they might); they will not work on
compressed or encoded EXEs.

Pedt Scragg's Replacement Crt Unit

Pedt Scragg has written a replacement Crt unit, which contains a number of
improvements including the RTE200 fix; it is available via Crt and at Garbo
(crt.zip). Be very sure to install it both fully and correctly, using
TPUMOVER (for which see the Tools manual, or online Help). The two
libraries TURBO.TPL and TPP.TPL are updated independently. TURBO.TPL is
used for both TP7 and BP7 real-mode; TPP.TPL is used by BP7 protected-mode.

To check installation, compile (with Options, Compiler, Debugging
Information all OFF; or with the source name unchanged), a small test
program (BP7: in each mode) both before and after updating the libraries,
verify that the first (of each) fails with RTE200, verify with DOS FC that
the second (of each) differs from the first, and that the second does not
give RTE200.

It appears that this is an ideal solution for those willing to update their
issued library TURBO.TPL and/or TPP.TPL files; it should suffice until CPU
speeds reach ~ 100 GHz or more. It also cures wrong delays in programs
compiled with versions before TP7.

I now have it installed.

N.B. there are other replacement Crt units.

Speed reports : 2001-05-29 FT mail 1300 MHz OK.

Andreas Bauer's Patch for EXE files

Andreas Bauer <andi.tio@hit.handshake.de> has produced a program (sent to
me by E-mail, ZIPped and UUencoded, 1997-09-13) to cure the
Delay/RunError 200 problem by patching TP7/BP7 executables. The zip-file
contains the patcher, with explanation files in English and German. The
program gives messages in German.

It can be installed in BP7 as a Tool : "~B~auer's TPPATCH" / "TPPATCH" /
"$EXENAME" ; then, with a Crt-using program, <edit> Alt-R R gives a swift
RTE200, then Alt-T B and Alt-R R runs the patched program. It can also be a
Tool in TP7, but that, alas, recompiles on the second Alt-R R - at least on
my present setup (one can, though, install the current program as a Tool,
and use it; but not with $EXENAME).

I had a copy at zipfiles/tppatch.zip; but I renamed it tp-patch on hearing
a report of a virus in it (from a single issue of McAfee), in order to
discourage inadvertent access. The virus scanner F-PROT (228, 228b, ff.)
considers it OK, but I require independent reliable confirmation before
reinstating - see 000-warn.txt in directory (which contains tp-patch). I've
later uploaded another tppatch.zip which contains the same files (by DOS
FC) and a NT.BAT; I do not now consider a virus likely. 2000-01-12: I hear
Dr Solomon's v8.01 finds it clean. 2001-03-30: And Norton Anti-virus
(2001/3/6 virus definitions).

I have myself only moderately tested it; I had no fast PC. But it does
appear to work as it should, and I do use it.

It's also at Garbo.

Whenever patching executables, beware of overlays (don't ask me why; I must
have read it somewhere).

NOTE that a patch must be applied to the executable as generated by the
compiler, and will not work on a compressed version of the executable.

2001-03-07 : Reported OK on Athlon 800 MHz.

Osmo Ronkanen's Loader "tfix"

In news:comp.archives.msdos.announce, Timo Salmi wrote:

     Mon 19-Apr-99: I looked through some useful postings which I have
     stored and come upon Osmo Ronkanen's inventive TPAS.PAS which can
     be used as a loader program to run Turbo Pascal programs with the
     infamous Turbo Pascal 7.0 Crt initialization runtime error 200 on
     fast machines. This is the solution to use if you do not have the
     problem program's source code available. The posting is now
     available from the Garbo archives with my best thanks to Osmo as

         3511 Feb 1 1999 ftp://garbo.uwasa.fi/pc/turbopa7/tfix.zip
         tfix.zip Loader source to avoid TP 7.0 Crt RTE200, Osmo
     Ronkanen

A Patch for the CRT unit

   * Timo Salmi wrote :
     Sat 27-Sep-97: Acquired to the Pascal collection at Garbo archives the
     following patch. It is provided as is. I have not tested it in action.

       62550 Nov 2 1996 ftp://garbo.uwasa.fi/pc/turbspec/bp7patch.zip
       bp7patch.zip CRT Delay patch for TURBO.TPL 48,432 10-27-92 7:00a
   * Scott Earnest: "This works *only* for an unmodified version 7.00
     TURBO.TPL".
   * Steve of TeamB: "Be aware that there are two versions of BP7PATCH,
     depending on whether you're using BP 7.00 or BP 7.01".
   * I've seen mention of at least three...

I have copies of some of them, as bp7patc?.zip.

EXE patch from c't

2000-02-17 - A solid report of the patch PENT2 07-21-97 17:58 in
T-PENT2.ZIP producing an EXE that works on a PII/450 but gives RTE200 on a
PIII/550; T-PENT2.ZIP now placed in my patches directory.
2000-02-18 ff. - I read that this is the simple patch from c't magazine,
intended to double the divisor (so halving the delay given!) though
changing $37=55 not to $6E=110 but to $7E=126 (changing the unit of delay
from 1 ms to (55/126)=0.437 ms.); that it is at
* http://www.databiten.se/products/dos/t-pent2.zip
* ftp://ftp.heise.de/pub/ct/ctsi/bppatch.zip
and that the c't archive (where?) has a better version.
2000-06-15 - SK says c't have a new, fixed patch - he thinks.
2000-07-11 - FC says c't patch of Mar 2000 will fail at ~ 3 GHz.
2000-07-11 - T_PENT2.ZIP contains PENT2.(PAS,EXE) - $7E visible.
  My crt002-d.exe shows the speedup of Delay.
2000-08-03 - from mini-FAQ - C't have now released a new patch, CTBPPAT,
that will work above 450 MHz.

Other Fixes

Frank Heckenbach

Frank Heckenbach's NewDelay or NewDelay patch is now available. He says now
(1996-11-18) :

     I updated the patch for the bug in the Delay procedure of the
     unit Crt. The patch now works for TP 6.0 as well as TP/BP
     7.00/7.01. It can patch Crt at runtime, so you can use it even if
     you don't have the source code of Crt.

2000-09-19 : suggestion seen that this may not work on PIII 800 MHz.

Roger Donais

Heavily adapted from an article by Roger Donais (rdonais@leading.net; Home
Page) :

     Those without source, compiling DOS real mode programs, may find
     his RDELAY.ZIP needing RUTIL10.ZIP or UTIL.ZIP, via tpascal.htm,
     useful. The archive contains source for a Turbo 4.0 through 7.0
     compatible unit designed to prevent the "Divide by 0" error
     encountered on fast machines. ...

His FTP Site URL is now rdonais/.

RDELAY is now also (1997-12-08) at Garbo :
4903 Jan 20 1997 rdelay10.zip Prevent the divide-by-0 Crt error on fast
machines, R.Donais
56849 Jun 21 1997 rutil10.zip Turbo Pascal utilities by R.Donais, (needed
by rdelay)

2001-03-19 : there is a suggestion that this one works where others do not
(with TurboPower???).

Klaus Hartnegg

Klaus Hartnegg: "I wrote ... program that patches ... an existing TURBO.TPL
file."
See his Fix for "Runtime Error 200" bug of Borland Pascal 7 on fast PCs.
2001-05-01 : I hear that his fix is included, as a ZIP, in the free release
of TP7.01 by Borland in France. The fix patches existing .TPL files, TURBO
and TPP, to use 32-bit counting.

Miscellaneous

There are fixes at Stefan Ghler's, Franz Glaser's, and Rich Green's sites.

Any patch which prevents Runtime Error 200 but causes Crt.Delay to generate
inaccurate delays is likely to fail on faster CPUs; the best may give
operation up to the equivalent of (255/55) * Intel 200 MHz.

It appears that one early patch divided the counter by 3, but could be
called more than once.

  ------------------------------------------------------------------------

TurboPower Software Co

This page, and Crt.Delay, are predominantly about the Turbo Pascal /
Borland Pascal Crt unit. Matching errors occur in TurboPower's "Object
Professional" units; fixes for their units are available by FTP. In that
directory, crtfix.txt appears to describe a fix for the Borland unit,
version 7.01, and crt.tpu & crt.tpp are said to be fixed units.

There are unverified suggestions (GK; F) that this fix may fail on faster
CPUs. However, the instructions that I've seen (July 2000) in TurboPower's
crtfix.txt imply a better grade of fix, like Pedt's, which should suffice
for many years.

  ------------------------------------------------------------------------

Error at around 500 MHz or Above

It has been said that one or more of the older RTE200 fixes (e.g.
T-PENT2.ZIP from c't) does not work on a 500 MHz PC. Until 2000-01-17, I
had, however, seen no clear report of what happens; and was not convinced
that the fixes in question were correctly applied. Adequate details are
essential on any error report, including an absolutely clear indication of
which version of what was applied how.

I gather that, at such speeds, Pedt Scragg's replacement CRT unit continues
to work (up to ~ 100 GHz?); see Mini-FAQ #4.1. It is confidently believed
that reports of RTE200 trouble with this crt.zip are entirely due to users
failing to install the unit correctly.

A sufferer should compile a simple program, say :

    program Crt500 ;
    uses Crt ;
    begin Writeln('Crt500 running.') end.

check the EXE patched/unpatched on a slow machine and/or patched on a
medium machine, then try it on a fast machine, reporting the EXACT results,
verbatim, character by character, and repeating the trial without "uses
Crt". Then we will have something to go on, provided that the report
unambiguously identifies the fix used, including its version.

I've wasted too much time in the past with reports of "it crashed" when,
for example, a program terminated as Borland intended giving a standard
run-time error truly reflecting an (unexpected) situation.

Minor Patches

Among the patches written, there seems to be at least one which merely
extends the delay loop a bit, and fails at 300 MHz. One is reported OK at
366 MHz, but not at 400 MHz.

Other Frequencies

Some claim that the problem sets in at 800 MHz. Check that the Crt unit is
actually involved.

  ------------------------------------------------------------------------

Use of my Zip-files Directories

These are provided for use by individuals only, privately or
professionally. Some of the contents are my own; some are public domain or
the work of others. The distinction should be clear enough.

Software suppliers and other organisations should not use my site as a
regular source of supply of public material to their clients; nor should
any of it be regularly auto-downloaded by any person. Such acts are an
abuse of available bandwidth.

Instead, please copy the public domain files and mount them yourselves, or
cite a copy on a large public, mirrored FTP site. My own work may be saved
for reference, but not copied for distribution.

In any case, I am considering complete removal of the patch files; they can
also be found on the site of Ing. Franz Glaser - index (if not found, enter
via root).

P.S. - nevertheless, all links from these pages to my site should currently
work.

  ------------------------------------------------------------------------
             Dr J R Stockton, Surrey, UK. All Rights Reserved.
      Coursework Questions  Merlyn Home Page  JRS@merlyn.demon.co.uk
   These pages are tested mainly with MSIE 4 and by DiDa and W3's Tidy.
  This site, http://www.merlyn.demon.co.uk/, is maintained by webmaster.
  ------------------------------------------------------------------------
