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.
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.
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:
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.
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.
I may add a little more to these - see that directory.
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'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'.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.
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.
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.
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.
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
I have copies of some of them, as bp7patc?.zip.
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.
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???).
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.
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.
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.
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).
Nevertheless, all links from these pages to my
site should currently work.
| Coursework Questions | Home Page | JRS@merlyn.demon.co.uk |