To FootJuly
2012 : Garbo has ceased to exist.
See
Garbo
Shareware and Freeware Programs Library.
September : I gather that the French mirror persists at
ftp://ftp.lip6.fr/pub/pc/garbo/pc/.
See also The Crt.Delay Procedure in pas-wait.htm.
To be useful, any report of a problem with an RTE 200 fix must specify exactly what the fix was, indicate that it was correctly applied, and specify the affected system.
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 have used only the fixes by Andreas Bauer (existing EXE files), and Pedt Scragg (new compilations), with complete success. 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.
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.
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 MS-DOS box, the program does not get all of the CPU time; on my Windows 98 PII/300, I found that Error 200 occured 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.
In my Web directory currently called 20010716 :-
(*) I believe that to be with the genuine Borland unit; but it did not fail on my PII/300 in a Win98 MS-DOS box.
I may add a little more to these - see that directory.
2002-03-02 :-
I do not believe that what is quoted next is now the best advice; read the rest of this page and the c.l.p.b mFAQ. (bp7patch.zip tppatch.zip : search fodder)
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'. It may be useful to restrict the search by adding the equivalent, in a language that you can read, of '+Divide'.
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 also easy enough to emulate.
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.
N.B. I use those of Pedt Scragg & Andreas Bauer.
Frequencies are very approximate,
depending on CPU design.
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 work); they will not work on compressed or encoded EXEs.
Other CPU slowers include MOSLO, SLOWDOS, THROTTLE; try a cautious Web search, but I cannot recommend any.
Pedt Scragg has written a replacement Crt unit, which contains a number of improvements including the RTE200 fix; it is available via PDCU and at Garbo (crt.zip). Be very sure to install it both fully and correctly, using TPUMOVER (for which see the Tools manual, or TP7/BP7 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; it works properly.
N.B. there are other replacement Crt units.
Speed reports :-
2001-05-29: FT mail 1300 MHz OK.
2002-04-25: EFD mail 900 MHz K7 Thunderbird OK.
2006: self 3 GHz P4 XP sp2 OK.
2002-12-05 Announced in news:c.l.p.b; is available by FTP from Garbo.
RAHP wrote :- RPCRT100.ZIP contains optimized versions of the Borland TP5.0/5.5/6/BP7 CRT unit. It also contains the modified CRT.PAS file and .OBJ files for all routines to allow users of Delphi 1 to roll their own. The main improvement of the unit is the removal of the RTE 200 bug in the Delay() function. It also allows the use of extended (F11/F12/etc) keys and it will (try to) not reset extended text-modes.
This CRT unit uses 386 instructions and should not be used on 8086/88 or 80286 PCs.
N.B. I have not myself tested it (I already had Pedt Scragg's fix installed; and I still own a pre-386), but I expect it to be good. I understand that it is more modular than the Borland unit, so that only the needed parts are included in a compiled EXE.
I believe that the accuracy of the delay diminishes as the CPU speed reaches a count of 232 in 55 ms, after which there is no delay.
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. I think that it speeds up Delay() for computers needing the patch by a factor of about Effective_Computer_Speed / Critical_Speed.
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.
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
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
I have copies of some of them, as bp7patc?.zip.
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.
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.
Heavily adapted from an article by Roger Donais :-
Those without source, compiling DOS real mode programs, may find his RDELAY.ZIP needing RUTIL10.ZIP or UTIL.ZIP, 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. ...
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: "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.
There are fixes at Franz Glaser's site.
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 seems to be a $15 program, CPUKiller, which slows the CPU to 20% for 10 s while launching a program.
The following, at least, are at Garbo and available by FTP :- crt.zip (P.Scragg) ; rpcrt100.zip(R.Prins) ; bp7patch.zip (?) ; tppatch.zip (A.Bauer) ; rdelay10.zip (R.Donais) ; crtfix15.zip (E.Toder).
Note that much advice and many "fixes" can be found via the Web; some of what is found is good, some bad, some indifferent.
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 (opcrtfix.zip & tpcrtfix.zip ?) were 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.
Seek 'TurboPower' in the c.l.p.b. mini-FAQ.
2003-01-08 : I read that TurboPower is out of business.
2004-05-20 : I read that fixes are at SourceForge, 'Bugs', Request ID 955482.
2004-09-08 : Received E-mail from Kevin Perreault about his EXE patcher for TurboPower programs; details at www.talkaboutprogramming.com which my browser cannot handle. News message-ID <6moSVwE3GuPBFwi+@merlyn.demon.co.uk> should refer.
I've not used TurboPower myself.
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.
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.
Some claim that the problem sets in at 800 MHz. Check that the Crt unit is actually involved.
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.