Board index » delphi » BP7.0 DOS App with PentiumPro

BP7.0 DOS App with PentiumPro

I have several DOS applications written in BP 7.0. They worked all fine
until I changed my computer to a PentiumPro 200Mhz with 64Mb. Now when I
start the applications I get sometimes a runtime error 200 (divide by
zero) depending on whether the application is already in cache-memory or
not. I get the same error if I work under Windows NT3.51 or under native
DOS. Under NT I can get out of the error when there is running an other
time consuming application. I guess, it's a problem of the speed of the
computer. Does a BP application at the beginning determine the speed of
the computer, for example to for the Delay() routine ?
The second problem I have with a DOS protected-mode application with the
DPMI. If I have installed more than 32Mb under DOS, I cannot start the
application. Does the DPMI not work with more than 32Mb?
I think other users must have had the same problems and there is
probably
already a solution to ship around.
Many thanks for your help !

Patric  
in...@active.ch

 

Re:BP7.0 DOS App with PentiumPro


In article <323D4CF8.1...@active.ch> of Mon, 16 Sep 1996 14:50:00 in
comp.lang.pascal.borland, Patric Eberle <in...@active.ch> wrote:

Quote
>I have several DOS applications written in BP 7.0. They worked all fine
>until I changed my computer to a PentiumPro 200Mhz with 64Mb. Now when I
>start the applications I get sometimes a runtime error 200 (divide by
>zero) depending on whether the application is already in cache-memory or
>not. I get the same error if I work under Windows NT3.51 or under native
>DOS. Under NT I can get out of the error when there is running an other
>time consuming application. I guess, it's a problem of the speed of the
>computer. Does a BP application at the beginning determine the speed of
>the computer, for example to for the Delay() routine ?

 ....

There's a few words in http://www.merlyn.demon.co.uk/pascal.htm -

<A NAME="Delay"> <H4>Bugs in the Crt.Delay procedure</H4> </A>

It seems that the Crt.Delay procedure uses a count-loop calibrated
during program startup, probably employing the 18.2Hz clock to give a
standard interval, and using this calibration in a similar loop when
Delay is running..

<p> Programs compiled with older versions of TP (TP5, maybe early TP6?)
would miscalibrate when this counter of type WORD, overflowed during
startup - AFAIR, this occurred with a 486DX33, but not with a 286-12.
There was a patch.

<p> I gather that a related problem may occur with a PP-200 using later
software.
 Hans Schleichert (hans.schleich...@uni-tuebingen.de) wrote:
"When you try to run a program written in Turbo Pascal on a CPU running
at 200MHz or more, and the program uses the Crt unit, it will crash
before in executes the first main program line and will report a divide
by zero error."

<p> I'll update this bit as I rediscover more.

<p> An obvious solution seems to me to be to write one's own Delay
routine in Pascal, along the same (or different) lines but with a longer
counter.

<p> Further discussions of timing and delays can be found in Prof.
Salmi's TurboPascal FAQ, in Kris Heidenstrom's Timing FAQ, and in the
newsgroup comp.lang.pascal.borland.

I'd be delighted to replace those words with better ones ...
--
John Stockton, Surrey, UK.  J...@merlyn.demon.co.uk  Turnpike v1.12  MIME
     http://www.merlyn.demon.co.uk/      Inbound E-mail is/was sticky.

Re:BP7.0 DOS App with PentiumPro


Quote
In article <323D4CF8.1...@active.ch> Patric Eberle <in...@active.ch> writes:
>I have several DOS applications written in BP 7.0. They worked all fine
>until I changed my computer to a PentiumPro 200Mhz with 64Mb. Now when I
>start the applications I get sometimes a runtime error 200 (divide by
>zero) depending on whether the application is already in cache-memory or
>not.

This is a problem with the CRT unit; other people will tell you the solution

Quote
>The second problem I have with a DOS protected-mode application with the
>DPMI. If I have installed more than 32Mb under DOS, I cannot start the
>application.

I added the line
      SET DPMIMEM=MAXMEM 20000
to my autoexec.bat to fix a similar problem

Mark Horridge

Re:BP7.0 DOS App with PentiumPro


Dr John Stockton <j...@merlyn.demon.co.uk> writes:

Quote
> It seems that the Crt.Delay procedure uses a count-loop calibrated
> during program startup, probably employing the 18.2Hz clock to give a
> standard interval,

Indeed, that's how Crt does it.

Quote
> and using this calibration in a similar loop when Delay is running..

Actually, it's the very same loop that is used, in order to have exactly the
same execution time of one loop cycle.

Quote
> <p> Programs compiled with older versions of TP (TP5, maybe early TP6?)
> would miscalibrate when this counter of type WORD, overflowed during
> startup - AFAIR, this occurred with a 486DX33, but not with a 286-12.
> There was a patch.

I think the limit was about 486/25 or perhaps 386/40 with cache.
The problem was there up to TP6.0, fixed in TP/BP7.

Quote
> <p> I gather that a related problem may occur with a PP-200 using later
> software.
>  Hans Schleichert (hans.schleich...@uni-tuebingen.de) wrote:
> "When you try to run a program written in Turbo Pascal on a CPU running
> at 200MHz or more, and the program uses the Crt unit, it will crash
> before in executes the first main program line and will report a divide
> by zero error."

That's correct, though the error message isn't quite accurate. There is in
fact no division by 0, but a division of a large number by 55 whose result
won't fit into a 16 bit register. But the CPU generates the same "divide by
zero" exception/interrupt for that.

Quote
> <p> An obvious solution seems to me to be to write one's own Delay
> routine in Pascal, along the same (or different) lines but with a longer
> counter.

This is one solution. I posted such a procedure recently. One minor correction
to it: The line "Dec(count)" in procedure DelayLoop should be compiled with
range checking off, since count is actually an unsigned longint. But this will
only be a problem at a speed of some 100 GHz (!), and I doubt whether this
procedure will be used then...

Another solution would be the following which requires modifying the Crt unit,
and therefore needs the RTL that comes with BP7. (Reposted):

Waste some time in the DelayLoop procedure. This way, the numbers will get
smaller and fit within a 16 bit register for some more time. Rather than
just a few NOPs, I'd do a little loop, using SI, which is not used otherwise.
You have to do the following change in CRT.ASM. Afterwards, you have to
rebuild your RTL, esp. compile CRT.PAS.

DelayLoop:
@@1:    MOV     SI,20  {This}
@@3:    DEC     SI     {is}
        JNZ     @@3    {new}

        SUB     AX,1
        SBB     DX,0
        JC      @@2
        CMP     BL,ES:[DI]
        JE      @@1
@@2:    RET

This will reduce the value by a factor of about 10, and should suffice for
a while... The factor can be made bigger, of course, but then it might get
a little inaccurate on 8086/4.77s... :-)

If haven't checked the above solution because I don't have a 200MHz CPU but I
hope it works. However, it works on my 486 just like the original Crt.

Of course, if you start modifying Crt, it would probably be preferable to use
the pure Pascal solution mentioned, and remove all Delay related parts from
CRT.ASM. This way, you would also allow the smart linker to remove Delay from
all programs not using it. And there is no real advantage of an assembler
Delay to a Pascal Delay, as (to quote someone else, I forgot who it was):
after all, it doesn't matter how efficiently you wait.

Quote
> I'd be delighted to replace those words with better ones ...

I hope I was of some help.

Another problem in connection with Delay is the busy waiting that will be a
real disadvantage in multitasking environments. Busy waiting means that the
waiting process will not be suspended by the OS, in order to give other
processes the full CPU time. Instead, the waiting process wastes much CPU time
for its useless loop.

This problem was mentioned in a posting recently, but I saw no answers to it.
For Windoze programs, one can achieve an unbusy waiting e.g. by using system
timers (that's how I implemented the Delay procedure in my unit WWin, an
extension of WinCrt). But that won't work with Dos programs running under
Windoze, because they don't have access to the Windoze API. Does anyone know a
solution for that, perhaps an interrupt to tell Windoze to suspend the
process? And what about 'doze95, any better there? Actually, I fear not... :-(
But perhaps someone can correct me on that...

Frank

Re:BP7.0 DOS App with PentiumPro


In article <51omd8$...@rznews.rrze.uni-erlangen.de> of Wed, 18 Sep 1996
11:28:40 in comp.lang.pascal.borland, Frank Heckenbach

Quote
<fkhec...@cip.informatik.uni-erlangen.de> wrote:
>Dr John Stockton <j...@merlyn.demon.co.uk> writes:
>> It seems that the Crt.Delay procedure uses a count-loop calibrated
>> during program startup, probably employing the 18.2Hz clock to give a
>> standard interval,
>Indeed, that's how Crt does it.

Etc. I've upgraded the words in http://www.merlyn.demon.co.uk/pascal.htm
using what you've said, and will upload soon.

Quote
>> <p> An obvious solution seems to me to be to write one's own Delay
>> routine in Pascal, along the same (or different) lines but with a longer
>> counter.
>This is one solution. I posted such a procedure recently. One minor correction
>to it: The line "Dec(count)" in procedure DelayLoop should be compiled with
>range checking off, since count is actually an unsigned longint. But this will
>only be a problem at a speed of some 100 GHz (!), and I doubt whether this
>procedure will be used then...

(a) I think you mean overflow checking,
(b) but Dec(count) is not checked, so all checks _can_ be on.
I've tested, in BPW, repeated Dec(L, 100000000) vs. L := L - 100000000 .

Quote
>> I'd be delighted to replace those words with better ones ...
>I hope I was of some help.

Yes indeed.
--
John Stockton, Surrey, UK.  J...@merlyn.demon.co.uk  Turnpike v1.12  MIME
     http://www.merlyn.demon.co.uk/      Inbound E-mail is/was sticky.

Re:BP7.0 DOS App with PentiumPro


Re:BP7.0 DOS App with PentiumPro


Quote
fkhec...@cip.informatik.uni-erlangen.de (Frank Heckenbach) wrote:
>Another problem in connection with Delay is the busy waiting that will be a
>real disadvantage in multitasking environments. Busy waiting means that the
>waiting process will not be suspended by the OS, in order to give other
>processes the full CPU time. Instead, the waiting process wastes much CPU time
>for its useless loop.
>For Windoze programs, one can achieve an unbusy waiting e.g. by using system
>timers (that's how I implemented the Delay procedure in my unit WWin, an
>extension of WinCrt).

No other way to do this?  Any OS-API should have a call for sleeping.
Oh, yes. You said windoze, ok :-)

Quote
> But that won't work with Dos programs running under
>Windoze, because they don't have access to the Windoze API.

Nes. A few can be accessed via int2f. See an older c't  for details
(ca. 1994)

Quote
>Does anyone know a
>solution for that, perhaps an interrupt to tell Windoze to suspend the
>process?

regs.ax := $1680;  { giving u timeslices }
Intr($2f,regs);

works with loose-os/2 too.

In BP/2 (ct) you should of course use DosSleep()

Quote
>And what about 'doze95, any better there? Actually, I fear not... :-(

Gruss,
  Walter

Re:BP7.0 DOS App with PentiumPro


Reposting article removed by rogue canceller.

Quote
fkhec...@cip.informatik.uni-erlangen.de (Frank Heckenbach) wrote:
>Another problem in connection with Delay is the busy waiting that will be a
>real disadvantage in multitasking environments. Busy waiting means that the
>waiting process will not be suspended by the OS, in order to give other
>processes the full CPU time. Instead, the waiting process wastes much CPU time
>for its useless loop.
>For Windoze programs, one can achieve an unbusy waiting e.g. by using system
>timers (that's how I implemented the Delay procedure in my unit WWin, an
>extension of WinCrt).

No other way to do this?  Any OS-API should have a call for sleeping.
Oh, yes. You said windoze, ok :-)

Quote
> But that won't work with Dos programs running under
>Windoze, because they don't have access to the Windoze API.

Nes. A few can be accessed via int2f. See an older c't  for details
(ca. 1994)

Quote
>Does anyone know a
>solution for that, perhaps an interrupt to tell Windoze to suspend the
>process?

regs.ax := $1680;  { giving u timeslices }
Intr($2f,regs);

works with loose-os/2 too.

In BP/2 (ct) you should of course use DosSleep()

Quote
>And what about 'doze95, any better there? Actually, I fear not... :-(

Gruss,
  Walter

Re:BP7.0 DOS App with PentiumPro


Re:BP7.0 DOS App with PentiumPro


Dr John Stockton <j...@merlyn.demon.co.uk> writes:

Quote
> >This is one solution. I posted such a procedure recently. One minor correction
> >to it: The line "Dec(count)" in procedure DelayLoop should be compiled with
> >range checking off, since count is actually an unsigned longint. But this will
> >only be a problem at a speed of some 100 GHz (!), and I doubt whether this
> >procedure will be used then...

> (a) I think you mean overflow checking,
> (b) but Dec(count) is not checked, so all checks _can_ be on.
> I've tested, in BPW, repeated Dec(L, 100000000) vs. L := L - 100000000 .

Oh yes, I saw it. Obviously, the compiler doesn't generate any checks for Dec,
even with all checking options turned on. I'm a bit surprised (one could call
that a bug, though). Thanks for pointing that out.

And the good news to all 500 GHz machine owners: you don't have to change the
code! ;-)

Frank

Re:BP7.0 DOS App with PentiumPro


On 24 Sep 1996, fkhec...@cip.informatik.uni-erlangen.de (Frank Heckenbach)
wrote:

Quote
>Dr John Stockton <j...@merlyn.demon.co.uk> writes:
>> >This is one solution. I posted such a procedure recently. One minor correction
>> >to it: The line "Dec(count)" in procedure DelayLoop should be compiled with
>> >range checking off, since count is actually an unsigned longint. But this will
>> >only be a problem at a speed of some 100 GHz (!), and I doubt whether this
>> >procedure will be used then...

>> (a) I think you mean overflow checking,
>> (b) but Dec(count) is not checked, so all checks _can_ be on.
>> I've tested, in BPW, repeated Dec(L, 100000000) vs. L := L - 100000000 .
>Oh yes, I saw it. Obviously, the compiler doesn't generate any checks for Dec,
>even with all checking options turned on. I'm a bit surprised (one could call
>that a bug, though). Thanks for pointing that out.
>...................
>Frank

You shouldn't be surprised, Frank. It's documented:
"The {$Q+} does not affect the Inc and Dec standard procedures. These
procedures are never checked for overflow." (from BP7 Programmer's
Reference, chapter 2: Compiler directives, Overflow checking).
That's why Inc and Dec are suitable for "strange" programming (with no
checks), whereas + and - (or Pred and Succ) are more safe for regular
use.

Babis Athineos (ba...@hol.gr)

Re:BP7.0 DOS App with PentiumPro


Re:BP7.0 DOS App with PentiumPro


Quote
walt...@ddorf.rhein-ruhr.de (Walter Koch) writes:
> >For Windoze programs, one can achieve an unbusy waiting e.g. by using system
> >timers (that's how I implemented the Delay procedure in my unit WWin, an
> >extension of WinCrt).
> No other way to do this?  Any OS-API should have a call for sleeping.
> Oh, yes. You said windoze, ok :-)

Any OS - probably! But the only *OS* for PCs I know is Linux...

Quote
> Nes. A few can be accessed via int2f. See an older c't  for details
> (ca. 1994)

> regs.ax := $1680;  { giving u timeslices }
> Intr($2f,regs);

> works with loose-os/2 too.

I'll look up the c't when I get around to it, but Ralf Brown's interrupt list
told me about this interrupt. I think one could use that, but it'll take some
work to use it in a Crt compatible Delay procedure. Ok, better than nothing!
Thank for the info! I hope it still works under 'doze95!?

Quote
> In BP/2 (ct) you should of course use DosSleep()

What's that, a BP clone for OS/2? Which c't issue?
And what's the syntax of DosSleep - the same as Delay(ms:Word) (where the
parameter stands for "milli seconds", of course, and not for some $hitware
producer...)?

Frank

Other Threads