Board index » delphi » CRT unit doesn't work with Pentium II?

CRT unit doesn't work with Pentium II?

I have several BP7.0 programs that won't run on my new
Gateway Pentium II machines.  I narrowed it down to the
CRT unit causing the problem.  I made a test program
as follows:

program test;
uses crt;
begin
end.

This produced run time error 200.  If you rem out the
"uses crt" clause the program will work fine.  I tried
a different video card in the machine to see it maybe
there was a video bios conflict but it produced the
same results.  I booted clean to do with no drivers
at all and still the same.  Anyone care to try and
reproduce this?

Thanks!

Joe

 

Re:CRT unit doesn't work with Pentium II?


Quote
On Tue, 17 Jun 1997 10:32:45 -0500, Joe Konecny <g...@wcnet.org> wrote:
>I have several BP7.0 programs that won't run on my new
>Gateway Pentium II machines.  I narrowed it down to the
>CRT unit causing the problem.  I made a test program
>as follows:

>program test;
>uses crt;
>begin
>end.

>This produced run time error 200.  If you rem out the
>"uses crt" clause the program will work fine.  I tried
>a different video card in the machine to see it maybe
>there was a video bios conflict but it produced the
>same results.  I booted clean to do with no drivers
>at all and still the same.  Anyone care to try and
>reproduce this?

>Thanks!

>Joe

Well there seems to be a problem with BP 7.0 programs running with
Pentium II machines. According to the german ct magazine this is a
result of the interrupt hook for the delay-function. The CRT-Unit
seems to count a loop every second timer-tick to provide the machine
speed for the delay-function. The result of this loop is stored in a
longint variable and then divided with the 16-bit-division-instruction
by 55. But on fast machines the loop-count becomes greater than 55 *
65536. This results in a overflow during the division and, since the
overflow handler is shared with the division-by-zero handler in a
run-time-error 200.
The solution (according to the magazine) is to either (if you have
access to the sources of the run-time-library) correct this mistake or
patch the compile program by replacing the factor 55 by a bigger one,
e.g. 110. Just look for these instrctions with a de{*word*81} :
 F7D0           NOT     AX
 F7D2           NOT     DX
 B93700 MOV     CX,     37h
 F7F1           DIV     CX      
Then replace the 37h (55) with 7Eh (110). After that the program
should work fine.
-- (please note that I just translated the instructions from the mag.
Since I do not have a Pentium II :( i cant test this myself.)

- Hope that helps
(please excuse my bad english, I am not a nativ speaker)

Daniel
(DanielvDinckl...@usa.net)

Re:CRT unit doesn't work with Pentium II?


Quote
Joe Konecny <g...@wcnet.org> wrote:
>I have several BP7.0 programs that won't run on my new
>Gateway Pentium II machines.  I narrowed it down to the
>CRT unit causing the problem.

The problem is that earlier versions of TP used a word to
calibrate the delay.  The word overflows on faster machines
and results in unpredictable delays.  TP 7.0 uses a 32-bit
integer. However it too fails on machines like a P200, usually
with a divide by zero error.

Frank Heckenbach and I approached the problem two different
ways.  I'm sure you'll find one or the other solution to your
liking.  You can get a copy of Frank Heckenbach's NewDelay at
http://www.mi.uni-erlangen.de/~heckenb/programs.htm#NewDelay
or source for my TP 4.0 to 7.0 compatible runtime patch at
http://users.southeast.net/~rdonais/tpascal/rdelay.zip

    ...red

Re:CRT unit doesn't work with Pentium II?


In article <33a6bd26.1027...@news.nacamar.de>,
Daniel von Dincklage <DanielvDinckl...@usa.net> wrote:

Quote

>Well there seems to be a problem with BP 7.0 programs running with
>Pentium II machines. According to the german ct magazine this is a
>result of the interrupt hook for the delay-function. The CRT-Unit
>seems to count a loop every second timer-tick to provide the machine
>speed for the delay-function. The result of this loop is stored in a
>longint variable and then divided with the 16-bit-division-instruction
>by 55. But on fast machines the loop-count becomes greater than 55 *
>65536. This results in a overflow during the division and, since the
>overflow handler is shared with the division-by-zero handler in a
>run-time-error 200.

IMO that is very sloppy programming. There is no excuse whatsoever for
such a mistake. One should always either clear DX or check that it is
not greater than the divisor before one does division.

Osmo

Other Threads