Subject: Re: Fast CPU Division By Zero Error Fix?
      Date: Fri, 1 Jan 1999 12:49:54 +0100
      From: "ML" <michro@usa.net>
Organization: A Customer of Tele2
Newsgroups: borland.public.turbopascal

Hi,

Jonathan Dunne skrev i meddelandet <76h03i$m713@forums.borland.com>...
>Hi!
>Is there an official (or universally recommended) fix for the Division By
>Zero Error I get on my PC (Pentium Pro 350 Mhz) when running a program that
>uses "crt"?
>
>Thanks!
>
>Jonathan Dunne
 

There is an easy solution and an explanation to this special problem. Below
I've pasted information that I think should be enough for You. Read
everything!

Regards,
Michael michro@usa.net

Pentium® II processors
"Runtime Error 200", "Divide Overflow", "Divide by 0" errors when running
software that was compiled on a Borland TurboPascal* compiler.

TP7 contians a bug which causes with a faster processor a runtime-error with
starting the program (Division by zero). This bug is caused by the unit crt.
This unit uses it's procedure delay by starting the program. You have not
this problem with TP6, but there the procedure "delay" is a lot more
incorrect.

A "Runtime Error 200", "Divide Overflow", or a "Divide by 0" error message
that is displayed when you try to run a program may be a result of a timing
loop that affects any program compiled on Borland’s TurboPascal* compiler.
All versions (including version 7.0) of Borland’s TurboPascal compilers are
affected by this issue. This compiler problem is dependent on the speed the
processor is running, but it is not a processor issue.

When executed at speeds greater than or equal to 233 MHz, a speed-dependent
timing loop in the compiled program generates a large number. The code
following the timing loop then attempts to divide this large number by a
smaller constant number. This division results in a quotient too large to be
represented in the quotient register designated by the specific divide
instruction. The program will not run, and the system displays the "Runtime
Error 200" message, or a "Divide Overflow" error message.

The root cause of this problem appears to be the software libraries that
come with the compiler. Any compilers that are dependent on software-based
timing loops are affected, but this issue is specifically known to affect
Borland’s TurboPascal compilers.

If you have a piece of software that was compiled on a Borland Turbo Pascal
compiler, you will likely encounter this problem when run at speeds of 233
MHz and higher. One possible solution is to contact your software vendor to
see if they have a newer version of that software that is not dependent on
timing loops.

Intel is also aware of two patches for this problem, one for programs that
have been compiled with a Borland TurboPascal compiler, and one that will
patch the software libraries of the compiler itself.

Intel has worked with Inprise (formerly Borland), and Inprise has
communicated that there is more information about this problem on the
Inprise Developer Support web site.

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 Inprise 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+tpbug.zip' without the quotes.

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

If you get this error while launching a (previously) OK program, the reason
is, your new processor is too fast. There is a routine within the Borland
Pascal compilers called "CRT". It attempts to determine how fast the
processor is by issuing a 1 millisecond tick (wait). While "waiting", it
starts counting.  1,2,3,...  At the end of the wait, it loads that number
into a register. Unfortunately, due to the speed of the processor, the
number is greater than FFFF and, therefore, won't fit. The register reports
this error but the junior (I hope) programmer at Borland didn't bother to
check that the register is still at zero. The next instruction is a division
of that register number (zero, remember) into a fixed integer, namely 55.
Ergo, divide by zero (RUNTIME 200 ERROR). All the fix does is to find the
routine and insert "FFFF" into the register so that it cannot overflow.
Simple.

BTW, the explanation given by Tim Mc Carthy of Intel is well meaning and
close but wrong.  This is NOT meant to disparage Tim, he is trying his best
to get this out. Unfortunately Intel in their normal legal lethargy is
stonewalling him. I wish that people would charge at Borland instead of
Intel, Borland are the perpetrators of this monstrosity. I found it because
I ordered a PII on announcement date and Dr. Solomons Anti-Virus promptly
failed, written in Turbo Pascal.  After digging long and deep, I found a
patch that "almost" fixed the problem. I modified it and sent it to Intel
and Ken (along with about another 200+/- people). So far, only Ken seems to
care enough to post it.

Note: Always backup any pertinent and important files PRIOR to implementing
any software patches, fixes or upgrades!

Here are three solutions:

One is the original patch which will fix precompiled programs for which you
have no source. The second is to replace the defective portions of the
compiler and allows one to compile programs that will actually operate
correctly, what a concept. Third is a comprehensive solution for the crappy
Borland compiler. They have all been tested by (now) 2,000+ people. Still, I
would caution a back-up first.

Newdelay.Pas, 14KB, PAS File
tpbug.zip, 65KB, ZIP File
tppatch.zip, 10KB, ZIP File

NOTE: Beware, your anti-virus software will report it as having a virus. It
does not, but it does modify EXE files which is why the report. Think about
it, if it did not modify the EXE, how could it work???

The program (TPPATCH.EXE) examines the file it is commanded to patch
exactly, so no exe file will be "patched to death". The position of the
variables are scanned automatically, so the patch should work with *all*
versions of TP7/BP7. But I haven't tested it with TP6. Of course it is
possible that it also can patch those files.

Of course, the whole thing is only necessary if the unit CRT is used in the
program.

It is possible to make a batch run TPPATCH on all executables on the hard
disk, because TPPATCH does a bunch of tests with every file, so not a single
wrong file will be patched.

Download the bugfix (tpbug.zip) containing a new turbo.tpl, tpp.tpl and a
fixed crt.asm.
Download he bugfixer (tppatch.zip)which fixes already existing exe-files.

http://support.intel.com/support/processors/pentiumII/run200.htm
http://www.inprise.com/devsupport/pascal/
http://www.pro-desk.com/inside/special/error200.htm