Board index » delphi » yet another runtime error 200 prob...

yet another runtime error 200 prob...

I am running Borland's turbo pascal 7.0 on a pII 300Mhz, Win98.
I've tried all of the patches (newdelay, tpbug, Fdelay, etc.)
Still I get that BLEEDING ERROR!
The programs work normally unless i try to read in a dat file, and then it's
200....200....200....200.....Arrrggghhh!
the error occurs at 099B:0091
Oh mighty wizards of turbo pascal.....heed my call and answer my prayers!

            -Jamie Rosner  (jros...@sentex.net)

 

Re:yet another runtime error 200 prob...


In comp.lang.pascal.borland, Jamie Rosner uttered:

Quote
>I am running Borland's turbo pascal 7.0 on a pII 300Mhz, Win98.
>I've tried all of the patches (newdelay, tpbug, Fdelay, etc.)
>Still I get that BLEEDING ERROR!
>The programs work normally unless i try to read in a dat file, and then it's
>200....200....200....200.....Arrrggghhh!
>the error occurs at 099B:0091

It *cannot* be the delay calibration bug as your program is getting past
this point. Therefore there is an error in your code leading to "divide
by zero"

Try recompiling with debugging on then run the program. When you get the
RTE200 use search/find error from the menu to find the error.
Alternatively, step through the code if you know roughly where the error
is occurring.

--
Pedt Scragg

No-one is completely useless, they can always be a bad example.

Re:yet another runtime error 200 prob...


Pedt Scragg responded:

Quote
>It *cannot* be the delay calibration bug as your program is getting past
>this point. Therefore there is an error in your code leading to "divide
>by zero"

>Try recompiling with debugging on then run the program. When you get the
>RTE200 use search/find error from the menu to find the error.
>Alternatively, step through the code if you know roughly where the error
>is occurring.

>--
>Pedt Scragg

>No-one is completely useless, they can always be a bad example.

Thanks for the response Pedt, your help is appreciated however, I may have
neglected to mention that I am using a library that is required for my
course, i believe that it might be the source for the runtime error 200.
I am pretty sure the code is intact because it is an example provivded by
the course. Just to be sure i have double checked it and it seems fine (it's
extremely simple).
Any other ideas?

Thanks

Re:yet another runtime error 200 prob...


In comp.lang.pascal.borland, Jamie Rosner uttered:

Quote

>Pedt Scragg responded:
>>It *cannot* be the delay calibration bug as your program is getting past
>>this point. Therefore there is an error in your code leading to "divide
>>by zero"

>>Try recompiling with debugging on then run the program. When you get the
>>RTE200 use search/find error from the menu to find the error.
>>Alternatively, step through the code if you know roughly where the error

>Thanks for the response Pedt, your help is appreciated however, I may have
>neglected to mention that I am using a library that is required for my
>course, i believe that it might be the source for the runtime error 200.

It is simple to check by recompiling as described above, generating a
map file as well, and seeing where the error address is. If this is
within the supplied library then there is a problem with the library.

Quote
>I am pretty sure the code is intact because it is an example provivded by
>the course. Just to be sure i have double checked it and it seems fine (it's
>extremely simple).

Is that double checked the example source only? Maybe the source that
provides the example is flawed :-)

Email me the location of the run-time error message and the detailed map
file (/gd switch with TPC.EXE or options/linker/map file/detailed in the
IDE) and I'll have a look.

--
Pedt Scragg

No-one is completely useless, they can always be a bad example.

Re:yet another runtime error 200 prob...


Pedt Scragg <newsmas...@pedt.demon.co.uk> wrote in article
<5AviLEAeqCI2Y...@pedt.demon.co.uk>...

Quote
> In comp.lang.pascal.borland, Jamie Rosner uttered:
> >I am running Borland's turbo pascal 7.0 on a pII 300Mhz, Win98.
> >I've tried all of the patches (newdelay, tpbug, Fdelay, etc.)
> >Still I get that BLEEDING ERROR!
> >The programs work normally unless i try to read in a dat file, and then
it's
> >200....200....200....200.....Arrrggghhh!
> >the error occurs at 099B:0091

> It *cannot* be the delay calibration bug as your program is getting past
> this point. Therefore there is an error in your code leading to "divide
> by zero"

If that is true, then the error address is a strange coincidence, 0091
being the address that would be expected for the delay calibration bug. Can
the question be reinterpreted to allow that bug?

"unless i try to read in a dat file" - I assume that means reading a data
file, using Reset etc. (long shot/wild guess: if it means shelling to a
program that reads a file, maybe that program would have the bug?)

Could there be multiple TURBO.TPLs available to the machine? I'm wondering
about a scenario something like this: copy TURBO.TPL into a temp directory
and patch it. Write a small test program to see if the patch works. It
does. Go back to the directory where the program which reads the data file
and recompile, try to run _that_ program, and of course you "Still get that
BLEEDING ERROR!", because the patched TURBO.TPL, being in the temp
directory, is not the one being read by the compiler. Or you copy TURBO.TPL
back to the directory where TURBO.EXE or BP.EXE is but you have _another_
one in the directory you would be working from. Could that be the problem?

FP

Re:yet another runtime error 200 prob...


In comp.lang.pascal.borland, Frank Peelo uttered:
Quote
>Pedt Scragg <newsmas...@pedt.demon.co.uk> wrote in article
><5AviLEAeqCI2Y...@pedt.demon.co.uk>...
>> In comp.lang.pascal.borland, Jamie Rosner uttered:
>> >I am running Borland's turbo pascal 7.0 on a pII 300Mhz, Win98.
>> >I've tried all of the patches (newdelay, tpbug, Fdelay, etc.)
>> >Still I get that BLEEDING ERROR!
>> >The programs work normally unless i try to read in a dat file, and then

>> It *cannot* be the delay calibration bug as your program is getting past
>> this point. Therefore there is an error in your code leading to "divide
>> by zero"

>If that is true, then the error address is a strange coincidence, 0091
>being the address that would be expected for the delay calibration bug. Can
>the question be reinterpreted to allow that bug?

>"unless i try to read in a dat file" - I assume that means reading a data
>file, using Reset etc. (long shot/wild guess: if it means shelling to a
>program that reads a file, maybe that program would have the bug?)

That's something I missed as a possibility. The more I think of it, the
more likely it may be, esp. as I had also picked up the 0091 address.

It would seem from his post that other parts of the program (before the
reading of the dat file) seem to be working OK which precludes multiple
turbo.tpl's as per the second suggestion.

I've asked Jamie to mail me a detailed map file, the error address and
the source to the example. This at least should pin his problem down.

--
Pedt Scragg

No-one is completely useless, they can always be a bad example.

Re:yet another runtime error 200 prob...


Another possibility:
Perhaps i'm not using the patch correctly?
Could someone please give me a detailed description of how to use tppatch?
This could be the problem...

Re:yet another runtime error 200 prob...


Quote
>Is that double checked the example source only? Maybe the source that
>provides the example is flawed :-)

>Email me the location of the run-time error message and the detailed map
>file (/gd switch with TPC.EXE or options/linker/map file/detailed in the
>IDE) and I'll have a look.

>--
>Pedt Scragg

>No-one is completely useless, they can always be a bad example.

Thanks again Pedt,
i'll get back to you in a couple of days with that info!!!
-Jamie

Other Threads