Pascal Error 200 Fix
Contents |
MSS03USA 2006South Africa 2008 Last updated: July 18th, 1999(Uploaded May 17th, 1998) Runtime Error 200 running a Pascal program on fast systems (PII 266+) Contents of this document General information Programmers information Programmers Option 1: Enhancing the Delay-routine Programmers Option 2: Removing the Delay-routine Optional replacement delayloop Users tp7p5fix Patch-program General information The Runtime Error 200 (Division by zero) bug is not part dos runtime error 200 of the Pentium Errors. It's a mistake Borland made. The initialization part of the CRT unit has a calibration loop
Freedos Runtime Error 200
for the procedure DELAY. The resulting value of a counter depends on the speed of the cpu. This counter has an overflow on high speed cpu's, including Pentium II 266 Mhz and faster. Actually it
Patchcrt
is the same bug that on earlier processors caused Delay to be inaccurate, that now causes programs to fail with a runtime error if they use the CRT unit! Some (earlier?) compiler versions mysteriously seem to go free of this bug - Delphi doesn't have them, for instance, and Turbo Pascal 6 seems to work too. Please note: I take no responsibility for the potential damage people may do dosbox runtime error 200 to their RTL's, working programs or vital data while using the instructions in this document. Keep backups of the appropriate files! (and then some...) Programmers As a programmer you have several different options. First of all you can disable the delay-routine completely. If you need a delay routine you can use the one found in this document, you can create your own, or you can find another one somewhere on the web. Another solution is to change the Delay-routine so it will work on todays fast systems. This solution found in this document should push the problem about 10 years into the future if we assume that Moores Law is correct. If you're having Borland Pascal, you also have the sources of the runtime library. Just make the following changes and recompile the complete runtime library. A MAKEFILE is included with the sources. If you have Turbo Pascal only, it's a bit more complicated. You'll need the sources of unit CRT. At least the files CRT.PAS, CRT.ASM and SE.ASM. They are the same in 7.0 and 7.01. Unfortunately copyright laws prevent me from letting you download the patched CRT.TPU file from this server, so please change it yourself (it is pretty easy): Implement the change
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 http://mtech.dk/thomsen/program/pasbug.php 2000]ctbppat fixes programs coded in Borland Pascal that cause runtime 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 -- http://www.vogons.org/viewtopic.php?t=93 and can detect the language with which the file was created. Running "bppatch *.* /s [/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
the delay factor to the maximum possible value. Note: this program speaks only German, but English docs are included. Note: This program is recommended by Borland. Use: if your program http://pedrowa.weba.sk/docs/Delphi/Pascal/Fixes%2520for%2520Pascal%2520'Run%2520Time%2520Error%2520200'/download.html is program.exe , enter the command tppatchprogram.exe Warning: This patch will cause delay to run too fast on computers that are significantly faster than Pentium II with about 233MHz. Some programs require http://www.heise.de/ct/hotline/Nicht-schon-wieder-Runtime-Error-200-307662.html correct timing, for those this patch may do more harm than help! Other programs should work fine with this. Technical details: A patched program will test if the computer is too fast. If no error 200 it proceeds with calculating the delay factor as usual. If yes the factor is instead set to the maximum possible value. Program makes room for the required additional code by rewriting two variable assignments directly before the patched region with shorter code that is functionally equivalent. (If you don't see that it's equivalent after looking at the assembler code, note the registers that are used!). t7TplFix.zip patch program for runtime error 200 Run Time Library file of Turbo Pascal 7.01 Program patches the file TURBO.TPL, the run time library file of Turbo Pascal version 7.01. Use: replace your file TURBO.TPL with the one generated by this program, then recompile your pascal sources. Technical Details: applies the same patches as in bp7patch (c't magazine), but uses the bugfixed Pascal version 7.01. No other files are changed, no other undocumented modifications are done to the CRT unit (unlike in the other distributed RTL files, see some of the other solutions below). NewDelay.pas unit with delay replacement and error trap (maybe newer version available here) This unit comes as pascal source. It contains two things: a new delay procedure that prevents the overrun by using a 32 bit delay factor instead of only 16 bit. a trap procedure to catch the runtime error as it occurs. It will still occur internally, but catched before the program aborts, then it's skipped and the program continued. That's a nasty trick, I don't like it, but it seems to work. Additional feature: tries to make a program behave nice during delays if it runs in a multitasking environment. This will of course delay to be a too long and a bi
mehr WissenSonderhefte zum Shop Test & Kaufberatung Praxis & Tipps Wissen Trends & News @ctmagazin Go! iOS 10 Patchday Raspberry Pi Künstliche Intelligenz Windows 10 WhatsApp iPhone 7 Fritzbox Virtual Reality c't Praxis & Tipps Tipps & Tricks Nicht schon wieder: Runtime Error 200 Nicht schon wieder: Runtime Error 200 Praxis & Tipps | Tipps & Tricks 08.04.2000 Mit dieser Meldung verweigern DOS-Programme auf schnelleren PC-Systemen ihren Dienst, wenn sie mit Borland-Pascal kompiliert worden sind. Schuld ist eine schlampige Programmierung der Initialisierung für die Delay-Routine in der Unit CRT, die bei schnellen Prozessoren überläuft und den Runtime-Fehler provoziert. Der Effekt ist nicht neu, er trat schon bei Pentium-II-Systemen ab etwa 266 MHz auf. c't hatte schon vor drei Jahren unter ‘Borlands Zeitbombe’ (c't 7/97, Seite 232) auf diesen Fehler bei der Division hingewiesen und für Programmierer eine verbesserte CRT-Routine vorgestellt, die 32-bittig dividiert und die erst bei Pentium-II-Systemen ab etwa 256 GHz überläuft. Um sie nutzen zu können, braucht man aber den Sourcecode der betreffenden Programme und den Borland-Pascal-Compiler. Oft liegt jedoch vom Programm nur der ausführbare Binärcode (EXE) vor. Hier half damals ein einfacher Patch weiter, der in den EXE-Dateien ein Byte änderte und so den schuldigen Teilerwert von 55 auf 110 verdoppelte, was den Überlauf erst mal verhinderte - wenn auch mit dem Nebeneffekt, dass gleichzeitig die Delay-Dauer halbiert wird. Statt 1000 ms wartete dann ein Delay (1000) nur noch 500 ms. Doch mit Pentium II oder Athlon ab 550 MHz und schneller reicht nun der Teilerwert 110 nicht mehr aus: das Runtime-Error-Spielchen wiederholt sich aufs Neue. Man kann nun höhere Werte für den Teiler einpatchen. Mit maximal 255 reichts etwa bis zu den Gigahertz-Prozessoren. Da der Teiler 16-bittig ist, kann man schließlich auch das nächste, höherwertig Byte patchen und hat dann Reserve bis etwa 256 GHz. Dummerweise wird dadurch aber die Delay-Dauer immer kürzer und kürzer, was mitunter neue Probleme aufwirft. c't hat daher einen anderen, etwas aufwändigeren Patch entwickelt, der die Delay-Funktion nicht beeinflusst. Er ist derzeit zwar nur bis etwa 3 GHz Pentium II/III tauglich, aber das dürfte erst mal reichen. Das Programm BPPatch2.exe (auf www.heise.de/ct/ftp/ctsi.shtml) vereinfacht auch die Bedienung. Es erkennt, ob es sich bei einem vorliegenden EXE-Programm um Borland-Pascal 7/7.01, TP 6, TP5.x oder TP4 handelt, ob es die CR