Board index » delphi » delay() info

delay() info

I have been testing the TP6 delay() procedure (with the patch) in the
CRT unit. On a DX2/75 it works correctly. On a P166 and P200MMX the
delay is too fast but the CRT unit init code DOES NOT cause a divide by
zero error. Others have reported the divide by zero error on P200. I
wonder if it depends upon the chip type or motherboard? Any one else
have any experiences?

 

Re:delay() info


Quote
Bob Lewis (rle...@staffnet.com) wrote:
> I have been testing the TP6 delay() procedure (with the patch) in the
> CRT unit. On a DX2/75 it works correctly. On a P166 and P200MMX the
> delay is too fast but the CRT unit init code DOES NOT cause a divide by
> zero error. Others have reported the divide by zero error on P200. I
> wonder if it depends upon the chip type or motherboard? Any one else
> have any experiences?

Did you try the first patch or the second one (#NewDelay at URL below)?
All I know is that my patch seems to solve the problem. I don't have a
Pentium and never saw the problem myself, so I can only guess, but
AFAIR, it depends only on the speed. If it's a little to fast, Delay
gets too fast, if it's much to fast, the runtime error occurs.

--
Frank Heckenbach, Erlangen, Germany
heck...@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Re:delay() info


Quote
On Wed, 11 Jun 1997, Bob Lewis wrote:
> I have been testing the TP6 delay() procedure (with the patch) in the
> CRT unit. On a DX2/75 it works correctly. On a P166 and P200MMX the
> delay is too fast but the CRT unit init code DOES NOT cause a divide by
> zero error. Others have reported the divide by zero error on P200. I
> wonder if it depends upon the chip type or motherboard? Any one else
> have any experiences?

I don't think it ever did cause a divide by zero error.  It just seemed
to cause problems (system lock-ups) on Pentium+ CPU's.   It could depend
on things like:  - what length of time is passed to the Delay() procedure
                 - is the programming running under a multitasker
                 - is x87 opcodes being used..

--
 Jeff Patterson, Computer Consultant            Internet: aa...@fan.nb.ca
  Programmer:  Author of jpIRC DOS IRC Client    PGPKey : http://www.pgp.net/
| HomePage: http://www.geocities.com/SiliconValley/Vista/7104/               |
| PGP Info: 2048/A8A1DCD5 : E0 9E 9B EF C8 E4 68 3D  B5 9C 72 4C EC 61 DD 7A |

Re:delay() info


Quote
On Wed, 11 Jun 1997, Bob Lewis wrote:
> I have been testing the TP6 delay() procedure (with the patch) in the
> CRT unit. On a DX2/75 it works correctly. On a P166 and P200MMX the
> delay is too fast

Use TP7, your problem is caused by the fact that TP6 delay
is disturbed by modern processor cache in 486 and 586 processors.
Processors are not always 100% compatible even if Intel claims so.

Klaus
--
Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104 Freiburg
hartn...@uni-freiburg.de   http://www.brain.uni-freiburg.de/~klaus/

Re:delay() info


Hi, Klaus.  Is there another way to resolve this Delay () problem for 486's
and Pentiums - using TP 6.0?  I can't get TP 7.0 or BP 7.0 any longer.

I am wondering if there is code out there that will allow a TP 6 program to
detect whether it is running on a 486 or Pentium and adjust a different
Delay () for that processor.  

For instance:

If 486 then

Delay(10,000);

If 586 then
Delay(30000);

Would this work?  

Thanks.

BTW, do you know where this TP 6.0 CRT patch (that Bob Lewis mentions
below) for Delay() can be obtained?  Thanks.

Regards, -= Lou Rizzuto =-

j-mr@mhv,net  (Remove hyphen.)

Klaus Hartnegg <hartn...@sun2.ruf.uni-freiburg.de> wrote in article
<5o07qc$...@n.ruf.uni-freiburg.de>...

Quote
> On Wed, 11 Jun 1997, Bob Lewis wrote:

> > I have been testing the TP6 delay() procedure (with the patch) in the
> > CRT unit. On a DX2/75 it works correctly. On a P166 and P200MMX the
> > delay is too fast

> Use TP7, your problem is caused by the fact that TP6 delay
> is disturbed by modern processor cache in 486 and 586 processors.
> Processors are not always 100% compatible even if Intel claims so.

> Klaus
> --
> Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104
Freiburg
> hartn...@uni-freiburg.de   http://www.brain.uni-freiburg.de/~klaus/

Re:delay() info


Quote
Louis Rizzuto wrote:

> Hi, Klaus.  Is there another way to resolve this Delay () problem for 486's
> and Pentiums - using TP 6.0?  I can't get TP 7.0 or BP 7.0 any longer.

> I am wondering if there is code out there that will allow a TP 6 program to
> detect whether it is running on a 486 or Pentium and adjust a different
> Delay () for that processor.

> For instance:

> If 486 then

> Delay(10,000);

> If 586 then
> Delay(30000);

> Would this work?

> Thanks.

> BTW, do you know where this TP 6.0 CRT patch (that Bob Lewis mentions
> below) for Delay() can be obtained?  Thanks.

> Regards, -= Lou Rizzuto =-

> j-mr@mhv,net  (Remove hyphen.)

> Klaus Hartnegg <hartn...@sun2.ruf.uni-freiburg.de> wrote in article
> <5o07qc$...@n.ruf.uni-freiburg.de>...
> > On Wed, 11 Jun 1997, Bob Lewis wrote:

> > > I have been testing the TP6 delay() procedure (with the patch) in the
> > > CRT unit. On a DX2/75 it works correctly. On a P166 and P200MMX the
> > > delay is too fast

> > Use TP7, your problem is caused by the fact that TP6 delay
> > is disturbed by modern processor cache in 486 and 586 processors.
> > Processors are not always 100% compatible even if Intel claims so.

> > Klaus
> > --
> > Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104
> Freiburg
> > hartn...@uni-freiburg.de   http://www.brain.uni-freiburg.de/~klaus/

It's available on the Borland FTP site and from Timo's page.

Re:delay() info


Quote
"Louis Rizzuto" <j...@mhv.net> wrote:
>Hi, Klaus.  Is there another way to resolve this Delay () problem for 486's
>and Pentiums - using TP 6.0?  I can't get TP 7.0 or BP 7.0 any longer.

>I am wondering if there is code out there that will allow a TP 6 program to
>detect whether it is running on a 486 or Pentium and adjust a different
>Delay () for that processor.  

I'm not familiar with other solutions for pre-6.0 versions of
TP, but I put together a delay replacement unit that contains a
single delay procedure that "should" calibrate for everything
from a plain vanilla pc on up and is compatible for TP 4.0
through 7.0.  

Unit initialization assumes that the new unit is immediately
followed by the crt unit, so you should list the two units in
the program's uses clause.  The order of definition allows the
new unit to initialize before the crt unit and to locate the crt
unit itself.  Conditional defines assure that the proper
"installation" is compiled. This includes code to identify and
disable the crt delay's initialization thereby preventing any
divide by zero error.  It also patches CRT.DELAY with a jmp
instruction which vectors all calls made to the CRT.Delay to the
new delay.  This technique assures that existing TPU's that
reference the CRT delay will also use the new delay.

If interested, follow the links at
<http://users.southeast.net/~rdonais/index.html>
and download RDELAY.ZIP

    ...red

--
Support the anti-Spam amendment
  Join at http://www.cauce.org/

Re:delay() info


Quote
> I'm not familiar with other solutions for pre-6.0 versions of
> TP, but I put together a delay replacement unit that contains a
> single delay procedure that "should" calibrate for everything
> from a plain vanilla pc on up and is compatible for TP 4.0
> through 7.0.

> Unit initialization assumes that the new unit is immediately
> followed by the crt unit, so you should list the two units in
> the program's uses clause.  The order of definition allows the
> new unit to initialize before the crt unit and to locate the crt
> unit itself.  Conditional defines assure that the proper
> "installation" is compiled. This includes code to identify and
> disable the crt delay's initialization thereby preventing any
> divide by zero error.  It also patches CRT.DELAY with a jmp
> instruction which vectors all calls made to the CRT.Delay to the
> new delay.  This technique assures that existing TPU's that
> reference the CRT delay will also use the new delay.

> If interested, follow the links at
> <http://users.southeast.net/~rdonais/index.html>
> and download RDELAY.ZIP

>     ...red

> --
> Support the anti-Spam amendment
>   Join at http://www.cauce.org/

Question. What do you do with RDELAY when your program uses multiple
units which each use CRT? Do you use the RDELAY unit in front of each
use of CRT? Thanks.

Re:delay() info


Quote
Louis Rizzuto (j...@mhv.net) wrote:

: Hi, Klaus.  Is there another way to resolve this Delay () problem for 486's
: and Pentiums - using TP 6.0?  I can't get TP 7.0 or BP 7.0 any longer.

Isn't it sold by Borland any more?

: I am wondering if there is code out there that will allow a TP 6 program to
: detect whether it is running on a 486 or Pentium and adjust a different
: Delay () for that processor.  

: > Use TP7, your problem is caused by the fact that TP6 delay
: > is disturbed by modern processor cache in 486 and 586 processors.
: > Processors are not always 100% compatible even if Intel claims so.

You could do yourself what Borland Pascal tries to do but fails.
Run a loop and count the number of iterations while waiting for the
interrupt to be triggered that is excecuted 18.2 times a second.
From this number determine how many loop iterations are required
for 1 millisecond.

The interrupt usually does nothing but increase a number.
The variable to check is the Bios Time Counter at address $40:$6c

const
  BiosTimeCounter : longint absolute $40:$6c;

i := BiosTimeCounter;
repeat until BiosTimeCounter <> i;
n := 0;
repeat
  inc (n);
  myloop;
until BiosTimecounter <> i;

Myloop is anything that needs a bit time.
This gives you in n the number of times myloop
must run for this to take 1/18.2 seconds,
i.e. do it 18.2 times and it takes a second,
divide that by 1000 do find how often to call
it for one millisecond.

Of course you could also use my millisecond timer,
check the pascal sources on my web page.

var
  timer : htimerobj;
begin
  timer.setzero;
  repeat until timer.getmusecs >= 1000;  { wait 1 ms }
end;

hope this helps,
Klaus
--
Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104 Freiburg
hartn...@uni-freiburg.de   http://www.brain.uni-freiburg.de~/klaus/

Re:delay() info


Quote
Klaus Hartnegg (hartn...@sun13.ruf.uni-freiburg.de) wrote:
> You could do yourself what Borland Pascal tries to do but fails.
> Run a loop and count the number of iterations while waiting for the
> interrupt to be triggered that is excecuted 18.2 times a second.
> From this number determine how many loop iterations are required
> for 1 millisecond.

> The interrupt usually does nothing but increase a number.
> The variable to check is the Bios Time Counter at address $40:$6c

> const
>   BiosTimeCounter : longint absolute $40:$6c;

> i := BiosTimeCounter;
> repeat until BiosTimeCounter <> i;

  i := BiosTimeCounter; {again!}

Quote
> n := 0;
> repeat
>   inc (n);
>   myloop;
> until BiosTimecounter <> i;

> Myloop is anything that needs a bit time.
> This gives you in n the number of times myloop
> must run for this to take 1/18.2 seconds,
> i.e. do it 18.2 times and it takes a second,
> divide that by 1000 do find how often to call
> it for one millisecond.

For this to work exactly, you should use the exact (repeat..until)
loop for the calibration and the actual delay. Not just the same
code, but the same routine, because the actual timings on modern
processors depend on a lot of things. The trick Borland used to do
this is a loop that checks if a certain memory location changes
(which is the BIOS timer for calibration, and another address, which
won't change, during delay), *or* a certain number of loops have been
done (where the maximum number of loops is set to something like
MaxLongInt for calibration and the actual number of loops required
during delay).

BTW: My own Delay replacement (which uses a similar technique) is
at #NewDelay, URL below.

--
Frank Heckenbach, Erlangen, Germany
heck...@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Other Threads