RTE 200 and upgrade questions 
Author Message
 RTE 200 and upgrade questions

I'm involved in bringing a legacy communication app into the 21st
century, and we recently ran into a snag.  I successfully recompiled
it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
away, but now we're hearing from users with machines at or near
1 gHz who are still reporting the same error... and I see in another
recent message ("RT 200: Not old problem") that someone else
is also experiencing problems on faster-than-fast machines.

Are we at a dead end with the patch?  We're looking at the remaining
options.  I thought about porting to Free Pascal, but this application
uses Object Pro and Async Pro.  No problem, I said, they come with
source code so I can recompile.  Alas!  They both use so much
nonstandard ASM routines that FPC threw up on the very first
source file.  It would take weeks to clean up OP and AP to the
point that they would recompile in FPC.

The boss suggested moving to Delphi... but I'm afraid that would
lead to the same porting problems that I ran into with FPC.  Unless
delphi can compile old TP source as-is with no modifications, I don't
see how that could help us.  Can anyone clue me in on whether that
avenue is worth pursuing?

I'd be grateful for any suggestions, insights, or general derision;
post 'em here or to the email address below.  Thanks, all.

Peter B. Steiger
Cheyenne, WY
----
If you reply by email, send it to pbs at com dot
canada (or vice-versa).  All adverti{*filter*}ts will be
returned to your postmaster, eh!



Tue, 03 Jun 2003 00:37:31 GMT  
 RTE 200 and upgrade questions


Quote:
>I'm involved in bringing a legacy communication app into the 21st
>century, and we recently ran into a snag.  I successfully recompiled
>it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
>away, but now we're hearing from users with machines at or near
>1 gHz who are still reporting the same error... and I see in another
>recent message ("RT 200: Not old problem") that someone else
>is also experiencing problems on faster-than-fast machines.

What kind of patched Turbo.tpl you use? Use a proper patch and you
cannot get the RET not even with a 1000 THz processor.

Quote:
>Are we at a dead end with the patch?  We're looking at the remaining
>options.  I thought about porting to Free Pascal, but this application
>uses Object Pro and Async Pro.  No problem, I said, they come with
>source code so I can recompile.  Alas!  They both use so much
>nonstandard ASM routines that FPC threw up on the very first
>source file.  It would take weeks to clean up OP and AP to the
>point that they would recompile in FPC.

Are you sure that it is the same error and not a bug in your code?

Osmo



Tue, 03 Jun 2003 03:02:05 GMT  
 RTE 200 and upgrade questions

Quote:

>I'm involved in bringing a legacy communication app into the 21st
>century, and we recently ran into a snag.  I successfully recompiled
>it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
>away, but now we're hearing from users with machines at or near
>1 gHz who are still reporting the same error... and I see in another
>recent message ("RT 200: Not old problem") that someone else
>is also experiencing problems on faster-than-fast machines.

Personally, even as FPC enthusiast, I would dive deeper
into the RTE 200 problem for now, and try to fix it in TP.

Only if you have other problems too (too little memory), I would consider
FPC.

Quote:
>Are we at a dead end with the patch?  We're looking at the remaining
>options.  I thought about porting to Free Pascal, but this application
>uses Object Pro and Async Pro.

Are those Turbo Power libraries?
A member of the FPC team converted some TurboPower apps, and submitted them
to Turbo Power. You could inform there.

Quote:
> No problem, I said, they come with
>source code so I can recompile.  Alas!  They both use so much
>nonstandard ASM routines that FPC threw up on the very first
>source file.

Assembler is hard to port. It is possible, and if you are an experienced FPC
and assembler programmer
(or any 32-bit compiler for that matter), it could be doable, but otherwise
I wouldn't start with it.

Quote:
> It would take weeks to clean up OP and AP to the
>point that they would recompile in FPC.

I'm afraid that's true. Unless you only use small parts, and can rip out 90%

Quote:
>The boss suggested moving to Delphi... but I'm afraid that would
>lead to the same porting problems that I ran into with FPC.

And even more. Not only you have to deal with 16->32bit too, but also with
the dos -> win32 conversion. FPC at least has a support unit to be able to
communicate with real mode, and users with some experience.

The problem however is the proprietary code. Try the vendors first.

There is a dosextender wdosx for Delphi, but that would only be more
trouble.

Quote:
> Unless
>Delphi can compile old TP source as-is with no modifications, I don't
>see how that could help us.  Can anyone clue me in on whether that
>avenue is worth pursuing?

Only standard apps, forget comms.

Quote:
>I'd be grateful for any suggestions, insights, or general derision;
>post 'em here or to the email address below.  Thanks, all.

I suggest first get to the bottom of the RTE 200, on BP and get access to
machine with problems for testing, and FPC should be your last resort
unless you also have problems with other BP limitations. (memory, long files
names etc). I can't help you with the RTE 200 problem, haven't touched BP
seriously in 3 years now.

To speed up things I would recommend, in parallel to the checking for a BP
solution, to contact the authors of those packages to see if FPC updates are
available.



Tue, 03 Jun 2003 04:38:11 GMT  
 RTE 200 and upgrade questions


Quote:

>I'm involved in bringing a legacy communication app into the 21st
>century, and we recently ran into a snag.  I successfully recompiled
>it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
>away, but now we're hearing from users with machines at or near
>1 gHz who are still reporting the same error... and I see in another
>recent message ("RT 200: Not old problem") that someone else
>is also experiencing problems on faster-than-fast machines.

>Are we at a dead end with the patch?  

To write "the patch" is absolutely useless.  There are many patches of
various sorts.

The *FIRST* question is whether you can run a simple "Hello World" type
program.  If that can be run, the second is whether it still runs with
"uses Crt" and a call to some Crt routine (NoSound may be the easiest to
use).

Try the crt???.pas/exe demo programs, linked from Web <URL: http://www.m
erlyn.demon.co.uk/pas-r200.htm> .  Try Pedt's replacement CRT unit.

Alternatively, try removing the Crt unit; most of the functions can
easily enough be done independently, as is shown by a combination of
TSFAQP #124 and my pas-extn.htm

--

 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.



Tue, 03 Jun 2003 05:50:27 GMT  
 RTE 200 and upgrade questions
As I mentioned in my previous post, I am using Turbo Power obcrt. The
assembler source shows a 32 bit register that is incremented in a loop for
on tick of the bios timer. The result is divided by 55 using the DIV
instruction. The loop is the AX,DX registers,  the divisor is in the CX,
and the result is in the AX. According Intels processor manual, if the
result exceeds the capacity of the AX a type 0 interupt is generated.
According to my calculations the AX,DC cannot exceed 65535 or an erro will
be generated.

Now the problem is to determine if a 1 GHz processor can drive this loop
more than 65535 in one timer tick (55Ms).

Frank

Quote:

> I'm involved in bringing a legacy communication app into the 21st
> century, and we recently ran into a snag.  I successfully recompiled
> it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
> away, but now we're hearing from users with machines at or near
> 1 gHz who are still reporting the same error... and I see in another
> recent message ("RT 200: Not old problem") that someone else
> is also experiencing problems on faster-than-fast machines.

> Are we at a dead end with the patch?  We're looking at the remaining
> options.  I thought about porting to Free Pascal, but this application
> uses Object Pro and Async Pro.  No problem, I said, they come with
> source code so I can recompile.  Alas!  They both use so much
> nonstandard ASM routines that FPC threw up on the very first
> source file.  It would take weeks to clean up OP and AP to the
> point that they would recompile in FPC.

> The boss suggested moving to Delphi... but I'm afraid that would
> lead to the same porting problems that I ran into with FPC.  Unless
> Delphi can compile old TP source as-is with no modifications, I don't
> see how that could help us.  Can anyone clue me in on whether that
> avenue is worth pursuing?

> I'd be grateful for any suggestions, insights, or general derision;
> post 'em here or to the email address below.  Thanks, all.

> Peter B. Steiger
> Cheyenne, WY
> ----
> If you reply by email, send it to pbs at com dot
> canada (or vice-versa).  All adverti{*filter*}ts will be
> returned to your postmaster, eh!



Tue, 03 Jun 2003 09:02:53 GMT  
 RTE 200 and upgrade questions

Quote:

>As I mentioned in my previous post, I am using Turbo Power obcrt. The
>assembler source shows a 32 bit register that is incremented in a loop for
>on tick of the bios timer. The result is divided by 55 using the DIV
>instruction. The loop is the AX,DX registers,  the divisor is in the CX,
>and the result is in the AX. According Intels processor manual, if the
>result exceeds the capacity of the AX a type 0 interupt is generated.
>According to my calculations the AX,DC cannot exceed 65535 or an erro will
>be generated.

How could it be that they independently make same serious bug as
Borland did?

Quote:
>Now the problem is to determine if a 1 GHz processor can drive this loop
>more than 65535 in one timer tick (55Ms).

The following unit should solve it just as it solves the original bug.
Note there is another unit that is used by the first. Also any delays
will of course be effected. (The constant Dfix can be used to fix the
delays, though only if there is just one buggy unit. If there are two
then it does not know how many times each called the interrupt)

Now of course you need to add (or replace the crt with) the obcrt in the
first unit to make sure that it affects the obcrt also/instead.

The units play with the order in the initialization codes are executed.
First the RT200Sub is executed. It does the actual stuff by installing
the new handler, then the initialization code of CRT is executed and
finally the initialization code of RT200Fix. That clears the handler from
the memory so that real RTEs will not be affected.  (DOS is used just to
get the getintvec/setintvec). You should put that as the first as if you
use the obcrt before it then there is no use.

You could also explicitly use the Sub-unit then the offending units: crt
and/or obcrt and the the fix-unit.

Unit RT200fix;

interface

uses RT200Sub,crt,dos;

implementation

{$ifdef ver70}
{$ifdef msdos}
Begin
 SetIntVec(0,Int0Save);
{$endif}
{$endif}
End.

Unit RT200Sub;            

interface

const dfix:word=1;       { call delay() dfix times }

Var int0Save:pointer;

implementation

{$ifdef msdos}
{$ifdef ver70}

uses dos;

Procedure Int0; assembler;
          asm
          shr dx,1        { divide dx:ax by 2 }
          rcr ax,1
          shl Dfix,1      { multiply Dfix by 2 }
          iret            { return to the DIV (286+) }
          end;

begin
  GetIntVec(0,Int0Save);

{$endif}
{$endif}
end.



Tue, 03 Jun 2003 09:53:14 GMT  
 RTE 200 and upgrade questions
I goofed! The magic number is 3,604,479 at which the DIV instruction
overflows.

frank

Quote:

> As I mentioned in my previous post, I am using Turbo Power obcrt. The
> assembler source shows a 32 bit register that is incremented in a loop for
> on tick of the bios timer. The result is divided by 55 using the DIV
> instruction. The loop is the AX,DX registers,  the divisor is in the CX,
> and the result is in the AX. According Intels processor manual, if the
> result exceeds the capacity of the AX a type 0 interupt is generated.
> According to my calculations the AX,DC cannot exceed 65535 or an erro will
> be generated.

> Now the problem is to determine if a 1 GHz processor can drive this loop
> more than 65535 in one timer tick (55Ms).

> Frank


> > I'm involved in bringing a legacy communication app into the 21st
> > century, and we recently ran into a snag.  I successfully recompiled
> > it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
> > away, but now we're hearing from users with machines at or near
> > 1 gHz who are still reporting the same error... and I see in another
> > recent message ("RT 200: Not old problem") that someone else
> > is also experiencing problems on faster-than-fast machines.

> > Are we at a dead end with the patch?  We're looking at the remaining
> > options.  I thought about porting to Free Pascal, but this application
> > uses Object Pro and Async Pro.  No problem, I said, they come with
> > source code so I can recompile.  Alas!  They both use so much
> > nonstandard ASM routines that FPC threw up on the very first
> > source file.  It would take weeks to clean up OP and AP to the
> > point that they would recompile in FPC.

> > The boss suggested moving to Delphi... but I'm afraid that would
> > lead to the same porting problems that I ran into with FPC.  Unless
> > Delphi can compile old TP source as-is with no modifications, I don't
> > see how that could help us.  Can anyone clue me in on whether that
> > avenue is worth pursuing?

> > I'd be grateful for any suggestions, insights, or general derision;
> > post 'em here or to the email address below.  Thanks, all.

> > Peter B. Steiger
> > Cheyenne, WY
> > ----
> > If you reply by email, send it to pbs at com dot
> > canada (or vice-versa).  All adverti{*filter*}ts will be
> > returned to your postmaster, eh!



Tue, 03 Jun 2003 14:01:27 GMT  
 RTE 200 and upgrade questions
John,
In my case using OPCRT the RT 200 occurs with a simple program that just adds a
couple of integers together. The problem is not present if OPCRT is not used. The
important thing here is that the problem is only happening on 800MHz + systems. My
question is do we have the old RT 200 problem cropping up again even with the
patch.

I don't need the offending delay instruction, but do need OPCRT for some of it's
other procedures. I'm planning on putting an upper bounds on the calibrate value
even if it messes up the calibration on fast machines.

frank

Quote:




> >I'm involved in bringing a legacy communication app into the 21st
> >century, and we recently ran into a snag.  I successfully recompiled
> >it with a patched TURBO.TPL (it's in TP6) and the RTE 200 went
> >away, but now we're hearing from users with machines at or near
> >1 gHz who are still reporting the same error... and I see in another
> >recent message ("RT 200: Not old problem") that someone else
> >is also experiencing problems on faster-than-fast machines.

> >Are we at a dead end with the patch?

> To write "the patch" is absolutely useless.  There are many patches of
> various sorts.

> The *FIRST* question is whether you can run a simple "Hello World" type
> program.  If that can be run, the second is whether it still runs with
> "uses Crt" and a call to some Crt routine (NoSound may be the easiest to
> use).

> Try the crt???.pas/exe demo programs, linked from Web <URL: http://www.m
> erlyn.demon.co.uk/pas-r200.htm> .  Try Pedt's replacement CRT unit.

> Alternatively, try removing the Crt unit; most of the functions can
> easily enough be done independently, as is shown by a combination of
> TSFAQP #124 and my pas-extn.htm

> --

>  <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
>  <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ;
>  <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.



Tue, 03 Jun 2003 14:07:23 GMT  
 RTE 200 and upgrade questions

Quote:
>>As I mentioned in my previous post, I am using Turbo Power obcrt. The
>>assembler source shows a 32 bit register that is incremented in a loop for
>>on tick of the bios timer. The result is divided by 55 using the DIV
>>instruction. The loop is the AX,DX registers,  the divisor is in the CX,
>>and the result is in the AX. According Intels processor manual, if the
>>result exceeds the capacity of the AX a type 0 interupt is generated.
>>According to my calculations the AX,DC cannot exceed 65535 or an erro will
>>be generated.

>How could it be that they independently make same serious bug as
>Borland did?

Because they expected people would use 32-bit code on 1 GHz processors? :-)

Anyway, I don't see the problem as long as the source code for the units is
capable. One could make the division 32-bit, or even the counter 64-bit.



Tue, 03 Jun 2003 15:26:31 GMT  
 RTE 200 and upgrade questions

Quote:

> Are those Turbo Power libraries?
> A member of the FPC team converted some TurboPower apps, and submitted them
> to Turbo Power. You could inform there.

I only converted Technojock's Turbo Roolkit version 5.10 to FPC
Dos/go32v2 (though I recently discovered there are still some bugs in
my conversion regarding detection of a mouse, it works pretty well for
a pretty large application). When I first contacted Turbo Power
software asking whether I could put the converted sources online, I got
the following reply:

***
The founding fathers at TechnoJock Software have never undertaken the
path to Free Pascal. Since our efforts must be placed in the direction
of putting food on the table, We have long since moved away from DOS
and into the Windows/Internet market.

I know that your efforts have paid off richly in the knowledge that you
have gained doing the conversion. I am told that any modification and
distribution of our copyrighted toolkit for gain would be in violation
of that copyright.

I would like to see a copy of your work and get some input from you as
to its potential. I was contacted recently about converting to another
version of Pascal, it may have been FPK, I don't remember at this
point. It was supposed to be compatible with Linux. Do you know of
anything like that?

George
***

Note the "for gain". I didn't mention anything about asking money in my
original message (and didn't intend either). Anway, I sent him a copy
of my conversion and asked whether it would be ok to distribute my
conversion, since I wasn't intending on asking money. I never heard
back from them...

Jonas



Tue, 03 Jun 2003 19:46:37 GMT  
 RTE 200 and upgrade questions

RE: RTE 200 and upgrade questions

Quote:
>options.  I thought about porting to Free Pascal, but this application
>uses Object Pro and Async Pro.  No problem, I said, they come with
>source code so I can recompile.  Alas!  They both use so much
>nonstandard ASM routines that FPC threw up on the very first
>source file.  It would take weeks to clean up OP and AP to the

     I started to reply by E-mail and realized that at this time of the morning
and in my rush to work, I could not deciver your email address.  This should
resolve your problem.

OBJECT PRO and ASYNC PRO both have problems with the infamous Runtime 200 error
alogrithms within.

Turbopower has publized this problem and has resolved it for fast machines.
See "ftp://ftp/turbopower.com/misc/crtfixes", for fixes.

There are compiled copies of the offending units available and resolution for
the sources so that you may re-compile your Turbopower units.

Art Johnston


    (714) 903-9920 -* Westminster, California*-



Tue, 03 Jun 2003 22:16:44 GMT  
 RTE 200 and upgrade questions


Quote:
>>>As I mentioned in my previous post, I am using Turbo Power obcrt. The
>>>assembler source shows a 32 bit register that is incremented in a loop for
>>>on tick of the bios timer. The result is divided by 55 using the DIV
>>>instruction. The loop is the AX,DX registers,  the divisor is in the CX,
>>>and the result is in the AX. According Intels processor manual, if the
>>>result exceeds the capacity of the AX a type 0 interupt is generated.
>>>According to my calculations the AX,DC cannot exceed 65535 or an erro will
>>>be generated.

>>How could it be that they independently make same serious bug as
>>Borland did?

>Because they expected people would use 32-bit code on 1 GHz processors? :-)

That is no excuse as the bug could have been avoided with a simple
check. I have always learned that you check divisions before doing them:

The code could have been instead of just

MOV CX,55
DIV CX

one uses:

MOV CX,55
CMP DX,CX
JB OK
MOV AX,65535
MOV DX,54
OK:
DIV CX

Only if there is not even a theoretical chance of overflow can one omit
the checking like if one first multiplies and then divides and the
divisor is larger than either of the multipliers.

Quote:
>Anyway, I don't see the problem as long as the source code for the units is
>capable. One could make the division 32-bit, or even the counter 64-bit.

True, but I assume that is not the case. If the person had the source
why did he post here instead of fixing the problem himself.

Osmo



Tue, 03 Jun 2003 23:31:10 GMT  
 RTE 200 and upgrade questions
The counter could be converted to 64 bit, but I am wondering if there is a real
problem or just something isolated on a particular computer. Since I don't have
access to the computer I can't verify the results of a fix.


Quote:
> >>As I mentioned in my previous post, I am using Turbo Power obcrt. The
> >>assembler source shows a 32 bit register that is incremented in a loop for
> >>on tick of the bios timer. The result is divided by 55 using the DIV
> >>instruction. The loop is the AX,DX registers,  the divisor is in the CX,
> >>and the result is in the AX. According Intels processor manual, if the
> >>result exceeds the capacity of the AX a type 0 interupt is generated.
> >>According to my calculations the AX,DC cannot exceed 65535 or an erro will
> >>be generated.

> >How could it be that they independently make same serious bug as
> >Borland did?

> Because they expected people would use 32-bit code on 1 GHz processors? :-)

> Anyway, I don't see the problem as long as the source code for the units is
> capable. One could make the division 32-bit, or even the counter 64-bit.



Wed, 04 Jun 2003 08:04:23 GMT  
 RTE 200 and upgrade questions
Thanks, this is what I was hopping for. Somehow I missed it on the Turbo Power web
site.
Quote:

> RE: RTE 200 and upgrade questions

> >options.  I thought about porting to Free Pascal, but this application
> >uses Object Pro and Async Pro.  No problem, I said, they come with
> >source code so I can recompile.  Alas!  They both use so much
> >nonstandard ASM routines that FPC threw up on the very first
> >source file.  It would take weeks to clean up OP and AP to the

>      I started to reply by E-mail and realized that at this time of the morning
> and in my rush to work, I could not deciver your email address.  This should
> resolve your problem.

> OBJECT PRO and ASYNC PRO both have problems with the infamous Runtime 200 error
> alogrithms within.

> Turbopower has publized this problem and has resolved it for fast machines.
> See "ftp://ftp/turbopower.com/misc/crtfixes", for fixes.

> There are compiled copies of the offending units available and resolution for
> the sources so that you may re-compile your Turbopower units.

> Art Johnston


>     (714) 903-9920 -* Westminster, California*-



Wed, 04 Jun 2003 08:06:06 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. RTE 200 question

2. RTE 200: division by zero

3. RTE 200: Division by zero

4. RTE 200: division by zero

5. crtfix.zip Borland Pascal Crt unit RTE 200 fix, E.Toder

6. Why am I not getting the RTE 200?

7. crtfix15.zip Borland Pascal Crt unit RTE 200 fix

8. RTE-200 Terror

9. RTE 200 solution --- would it work???

10. Strange RTE 200? (NOT THE CRT BUG)

11. Q: PENTIUM II machines and RTE 200

12. Disregard error 200 question below!

 

 
Powered by phpBB® Forum Software