Error 200 Division By Zero Patch
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
Runtime Error 200 Pascal
is faster then 200 Mhz (though some non-Intel CPU's would avoid the error up to 350 Mhz). tp7p5fix 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
Zero Tsum Tsum
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 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 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 Snover » 2002-7-26 @ 00:40 If you're trying to play an old game and 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 http://www.pcmicro.com/elebbs/faq/rte200.html error 200 on systems with clock 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 http://www.vogons.org/viewtopic.php?t=93 [/p]" will list all file formats in the current 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, c
these compilers when run on a Pentium-class computer faster than about 180mhz. Borland (now Inprise) has no officially-supported fix for this but several unofficial fixes have appeared http://s416217492.onlinehome.us/error200.html on various Pascal programming forums and newsgroups. Some are to patch the CRT http://www.kennedysoftware.ie/patchcrt.htm unit in your compiler (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 source code or the means to re-build the problem program). A patcher for existing problem programs written by AndreasBauer
fix RunTime Errors on some apps A freeware utility, which patches some older MS-DOS EXE files, to permit them to run on fast Pentium CPUs. This speed problem applies only on CPUs which match or exceed the speed of a Pentium 200 (approx), and applies only to some older versions of a specific software module named CRT.ASM, which was part of the Turbo-Pascal offerings from Borland. Be aware that this CRT.ASM module has been used in a variety of other products, and it is often not initially obvious that some flawed CRT.ASM code is embedded in other apps. The symptom is a Divide-by-Zero error message when the app is run on a fast CPU, or a Divide Overflow error message, or a Runtime Error 200 message, or similar. Unfortunately, the error message usually won't simply say that the CPU is too fast !. The preferred solution is to use an updated version of CRT.ASM, or to contact the software developer, and request that an updated CRT.ASM be used to re-build the app/utility. However, if this is not possible, then PatchCRT can be tried. Similar CRT.ASM "patchers" are available from others - though feedback suggests that a few different versions of flawed CRT.ASM code were released, and that this patcher copes with all known releases. Note: we've seen a few EXE files with the 200 error, but which PatchCRT, up to ver 1.5, would not adjust. On looking inside these EXEs, we noticed some code which is similar to published versions of CRT.ASM, but not EXACTLY the same. As of Jan 2000, we released ver 1.6, which also recognises this similar code, and patches it accordingly. Which is another way of saying - TEST your app carefully, if PatchCRT patches it !!. This program is freeware: use it at your own risk; take good backups first; test carefully - the usual small print. We'd appreciate feedback, if it works for you, and feedback if it does not !. Download PatchCRT.ZIP. This file-size is about 30k. (See Download Instructions). Note-1: Sometimes, EXE files are Compressed. PatchCRT does not include any de-compression code, and therefore will not repair compressed EXE files. If PatchCRT does not work for you, you might check if the EXE