Error 200 Divided By Zero Pascal
Contents |
the CRT.ASM unit included with these compilers. DOS based programs that were compiled using these buggy versions of the CRT unit will generate the RTE200 error when started on a CPU that error 200 division by zero is faster then 200 Mhz (though some non-Intel CPU's would avoid the error up to 350 Mhz). turbo pascal error 200 division by zero One solution is to recompile the source code using a later version of Pascal, or a fixed CRT.ASM unit. Obviously that's only possible if
Runtime Error 200 Dos
you have the source code available. The more common solution is to patch the .EXE file to disable the bug. There are several programs that allow this. The one I recommend is PatchCRT by Kennedy Software. This one is more compatible
Tp7p5fix
then most others, including TPPatch (which is less effecent, and uses German results and error text). I'd suggest keeping PatchCRT.exe in your path, so that you can run it from any directory simply by typing it followed by the name of the .EXE to be patched. PatchCRT will only be able to patch .EXE files which have not been compressed by an EXE compressor, such as aPACK, Diet, LZEXE, PKLite, Petite, UPX, etc. If PatchCRT fails to patch the .EXE, there patchcrt is a good chance it is because the .EXE has been compressed. The best tool I have found to uncompress .EXE files is UNP. This has worked for about 80% of the compressed .EXE files I have encountered. The nice thing about UNP is it runs well under Windows. My second choice would be CUP386, but this works best in a plain DOS environment without any extended memory manager (including himem.sys or emm386.sys) installed. I have used this tool to uncompress several .EXE's which UNP was unable to do. Once you have sucessfully uncompressed a compressed .EXE file, you should then be able to run PatchCRT on it to remove the RTE200 bug. If all the above fails, the other option is to run a TSR (Terminate and Stay Resident) utility that will provide a kluge to the division by zero issue by catching this error as the .EXE is being run, and telling DOS to ignore it. The best TSR I have found to do this is TP7p5fix. Simply run the TP7P5.EXE to load the TSR into memory, and any programs being run in that DOS window will avoid the RTE200. Keep in mind that once you close this DOS Window, or open other DOS Windows the TSR will not be active unless you load it again. Be sure to read our Disclaimer Return to the EleBBS FAQ Copyright © 2000 - 2006 pc micro systems, inc.
games running before you start asking questions. Topic locked 3 posts • Page 1 of 1 Fix "Error 200" (Divide by zero) - by Snover and Stiletto, with thanks to edelbeb by
Dosbox Runtime Error 200
Snover » 2002-7-26 @ 00:40 If you're trying to play an old game and zero tsum tsum it was written in Turbo Pascal, chances are, on any machine over 200MHz, you will get an Error 200 (Divide by zero error). This program corrects the problem by patching your executable. From the readme... ctbppat v1.2 © Andreas Stiller [April 2000]ctbppat fixes programs coded in Borland Pascal that cause runtime error 200 on systems with clock http://www.pcmicro.com/elebbs/faq/rte200.html speeds of over 200MHz. This error occurs due to incorrect initialisation of the DELAY counter.ctbppat is also a universal EXE scanner, monitor, and patcher. It supports the usual EXE formats -- MZ for DOS; NE for OS/2, DPMI, and Windows 3.11; and PE for 32-bit environments -- and can detect the language with which the file was created. Running "bppatch *.* /s [/p]" will list all file formats in the current http://www.vogons.org/viewtopic.php?t=93 directory.If you use the switches /NE, /MZ, or /PE, ctbppat will be restricted to the respective EXE format. This will increase the speed with which it can analyse files. Running in pure DOS mode with SmartDrive (if possible) will also increase analysation speed.If ctbppat finds an executable made with Borland Pascal 7.0, it will examine the file further to determine if it uses an original or changed CRT unit, whether this unit is already patched, and whether the DELAY function is called at all. (If it is not, patching is unnecessary.)Depending on the result of this examination, ctbppat may offer to patch the file. If the DELAY function is used, it can be fixed by using a different delay routine that should function properly up to ~4GHz.To do this, the BREAK routine in the CRT unit is shortened and the delay code patched into the free space.If DELAY is not used, the divisor is simply increased to 65535. This will prevent DELAY from operating; however, this will ensure that the program is able to run (theorhetically) on a 300GHz CPU.If the CRT unit has been changed, but contains the same incorrect initialisation, ctbppat will modify the faulty divisor (255 => 1).ctbppat only analyses original CRT units -- routines with similar incorrect cod
these compilers when run on a Pentium-class computer faster than about 180mhz. Borland (now Inprise) has http://s416217492.onlinehome.us/error200.html no officially-supported fix for this but several unofficial fixes have appeared on various Pascal programming forums and newsgroups. Some are to patch the CRT unit in your compiler http://www.oocities.org/siliconvalley/network/6493/tppatch.html (so you can produce programs free of the problem) and others are programs to patch executable programs that have the problem (in which case you do not need the error 200 source code or the means to re-build the problem program). A patcher for existing problem programs written by AndreasBauer
are no longer functioning. Instead they reply with an error message like 'Runtime Error 200: Divide by zero'. In this case, the program is a Pascal program using the CRT unit. At startup of the program, the Crt.Delay loop is executed. The loop counter, divided by 55 is on these machines larger than what fits in a 16-bit register. So the 'divide by zero' error message isn't really correct. There are a couple of patches available for this problem. Some patches are RT (runtime): they fix the actual program. Other patches actually alter the source code of the CRT. But this is only useful if you compile Pascal programs yourself. Already built programs won't be changed. Runtime patch I have one patch here that should work with any Pascal programs compiled with TP/BP 6.0/7.00/7.01. I have finally been able to check this patch (unfortunately not on my very own PC, which is still too old, I'm afraid...) and guess what... IT WORKS! The patch has background information in German (TPPATCH.DOC) and English (TPPATCH.ENG). The patch can be executed by starting TPPATCH.EXE. If you want to patch from inside Windows NT, run NT.BAT instead. Get TPPATCH.ZIP. BP7 CRT source patches (compiletime) I have two of those patches here. The patches have been tested, but only the second one seems to work for protected mode programs. The patches work with versions 7.00/7.01 only. See readme.txt in the files for instructions. Get BP7PATC1.ZIP. Get BP7PATC2.ZIP. Back to homepage.