Board index » delphi » Fastest speed???

Fastest speed???

What is the fastest computer that Borland Pascal 7.01 can run on with
the replacement CRT unit?  Will it run on a 500 Mhz computer? Is there a
limit? Please  send e-mail. Thanks in advance.

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.com
mailto:patri48...@aol.com

 

Re:Fastest speed???


Quote
"Patrick D. Rockwell" wrote:
>  What is the fastest computer that Borland Pascal 7.01 can run on with
> the replacement CRT unit?

Depends on the processor. On Intel CPUs, 200 MHz is the limit,
approximately. AMD CPUs can be faster than 200 MHz, and the error won't
occur.

Quote
> Will it run on a 500 Mhz computer? Is there a limit?

It will definitely not run on a 500 MHz Intel computer. I don't know
about 500 MHz AMD processors.

Quote
> Please  send e-mail.

This is a newsgroup, and refrain from posting HTML messages.

Re:Fastest speed???


In article <37F7212B.F8898...@altavista.net>,

Quote
Frederic  <f...@altavista.net> wrote:
>"Patrick D. Rockwell" wrote:

>>  What is the fastest computer that Borland Pascal 7.01 can run on with
>> the replacement CRT unit?

>Depends on the processor. On Intel CPUs, 200 MHz is the limit,
>approximately. AMD CPUs can be faster than 200 MHz, and the error won't
>occur.

Note that he talked about a replacement unit. Of course he did not
specify what replacement he is talking about.

In general any replacement should do away the RTE200 for good. The delay
might get problems when one starts about 100GHz or so.

Osmo

Re:Fastest speed???


Frederic <mailto:f...@altavista.net> said:

Quote
>"Patrick D. Rockwell" wrote:

>>  What is the fastest computer that Borland Pascal 7.01 can run on with
>> the replacement CRT unit?
>> Will it run on a 500 Mhz computer? Is there a limit?

There will be a limit depending on which 'replacement' you have used.
Some reports have been made about a 'fix' not working >450MHz but no-one
has yet been able to provide a definitive statement.

Quote
>It will definitely not run on a 500 MHz Intel computer.

Can you provide full information of which fix *you* used that failed at
500MHz Intel please as Patrick did not give any indication of which fix
he is using. Preferably, which fix, the file timestamp, where it was
downloaded from, your CPU and OS.

FWIW, I have made a slightly amended version of my CRT replacement to
report the longint I use before the division and can report that:
PIII 450MHz gives 2556611 as the value before division
IBM  266MHz gives 1374997 as the value before division
AMD  133MHz gives  666552 as the value before division

Based on these figures then it is likely that we have a few years to go
yet before my current fix fails as I reckon around 250-270GHz CPU speed
before any failure.

Program to report value at <URL: http://www.pedt.demon.co.uk/crt/v2.zip>
and web page to follow with any results. If anyone wants to use on other
machines and report back to <mailto: c...@pedt.demon.co.uk> I will put up
a web page with the reports. Please run from a DOS boot (not a Win DOS
box) and give the first figure reported plus your CPU make and speed.

--
Pedt

Year 2000 Managers do it by extra-century perception

Re:Fastest speed???


Quote
Pedt Scragg wrote:
> >It will definitely not run on a 500 MHz Intel computer.

> Can you provide full information of which fix *you* used that failed at
> 500MHz Intel please as Patrick did not give any indication of which fix
> he is using.

I had not read the original message carefully. I though the original poster
was talking about the crt unit without the patch.

Re:Fastest speed???


JRS:  In article <37F6A2AA.7912D...@thegrid.net> of Sat, 2 Oct 1999
17:26:19 in news:comp.lang.pascal.borland, Patrick D. Rockwell

Quote
<prockw...@thegrid.net> wrote:
>    What is the fastest computer that Borland Pascal 7.01 can run on
>    with the replacement CRT unit?? Will it run on a 500 Mhz computer?
>    Is there a limit? Please? send e-mail. Thanks in advance.

You've been using News for long enough now; you should have learnt NOT
to post in HTML and NOT to demand E-mail replies.

You should also realise that "the replacement CRT unit" is not a
satisfactorily precise description.

Have you established, as it seems that you might have, that any SPECIFIC
RTE200 fix is not needed below about 200MHz, works above about 200MHz,
and fails at a higher speed?  If so, EXACTLY which is it, and in exactly
what manner and at what speed does it fail?

--
 ? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
  <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c. FAQqish topics, links.
  Timo's TurboPascal <A HREF="ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip">FAQ</A>.
  Pedt: <A HREF="http://www.merlyn.demon.co.uk/clpb-faq.txt">c.l.p.b. mFAQ</A>.

Re:Fastest speed???


JRS:  In article <KnWeSGAvZ193Y...@pedt.demon.co.uk> of Sun, 3 Oct 1999
14:13:19 in news:comp.lang.pascal.borland, Pedt Scragg

Quote
<newsmas...@pedt.demon.co.uk> wrote:

>FWIW, I have made a slightly amended version of my CRT replacement to
>report the longint I use before the division and can report that:
>PIII 450MHz gives 2556611 as the value before division
>IBM  266MHz gives 1374997 as the value before division
>AMD  133MHz gives  666552 as the value before division

>Based on these figures then it is likely that we have a few years to go
>yet before my current fix fails as I reckon around 250-270GHz CPU speed
>before any failure.

For completeness, can you confirm that the maximum safe value without
your modification is (55*65536 - 1) = 3604479 ... can't be that -
(55*32768 - 1) = 1802239 ... no ... what is it?  Ah, is your count loop
different? - - - and that the maximum safe value for yours is 2147483647
or 4294967295?

I forget, or never knew, *exactly* how your fix works; but ISTM that a
fix is possible by adding inside the delay loop the ASM equivalent of "J
:= X ; repeat Inc(J) until J := Y ;" ; and that inside *that* loop one
might add another loop, etc.; these would nicely break the present
barriers indefinitely.

There's no need to have better than 0.5% accuracy in delays, IMHO; so
Borland's original word count and division would suffice, if the loop
were selected to keep the count in 11000..32767/65535.

H'mmm - in coding fixes for high frequency clocks, one needs to consider
the low frequency behaviour.  I still have my PPC 640, and am currently
booting it for use.

--
 ? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
  <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c. FAQqish topics, links.
  Timo's TurboPascal <A HREF="ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip">FAQ</A>.
  Pedt: <A HREF="http://www.merlyn.demon.co.uk/clpb-faq.txt">c.l.p.b. mFAQ</A>.

Re:Fastest speed???


Quote
Dr John Stockton wrote:
> JRS:  In article <37F6A2AA.7912D...@thegrid.net> of Sat, 2 Oct 1999
> 17:26:19 in news:comp.lang.pascal.borland, Patrick D. Rockwell
> <prockw...@thegrid.net> wrote:
> >    What is the fastest computer that Borland Pascal 7.01 can run on
> >    with the replacement CRT unit?  Will it run on a 500 Mhz computer?
> >    Is there a limit? Please  send e-mail. Thanks in advance.

> You've been using News for long enough now; you should have learnt NOT
> to post in HTML and NOT to demand E-mail replies.

Thanks for the lesson in manners! >:-( I changed a setting on my Netscape so that it
posts in plain text, and I DIDN'T demand. I said 'PLEASE' send e-mail. Ok??? I
didn't think that such a simple questionwould cause a whole thread. As of yet, I
haven't replaced my CRT unit. It's just that I've been reading
some users accounts of BP7.01 working at 200Mhz, but not working at 500Mhz. I wanted
some
clarification about this because when it's time for me to get a new computer, I
don't want one that
CAN'T use BP7.01 and all of its units.

So basically, I was hoping that different users would let me know what speed their
CRT replacement
units worked at and that way I'd know what the fastest was.

[snip!]

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.com
mailto:patri48...@aol.com

Re:Fastest speed???


Patrick D. Rockwell <mailto:prockw...@thegrid.net> said:

Quote

>So basically, I was hoping that different users would let me know what speed
>their
>CRT replacement
>units worked at and that way I'd know what the fastest was.

AFAIAA, there is only one 'replacement' unit. The rest of the solutions
are 'fixes'. All the solutions aim to solve the division by 55 that
overflows a 16bit word.

There have been vague reports that one fix does not work with a CPU

Quote
>450MHz but no-one has yet to substantiate it.

--
Information on Newsgroup posted weekly on Sunday - read before writing!
Contains links to    |  http://homepages.force9.net/pascal/faq/
helpful information  |  http://www.merlyn.demon.co.uk/clpb-faq.txt
and some guidelines  |  ftp://garbo.uwasa.fi/pc/doc-net/faqclpb.zip

Re:Fastest speed???


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

Quote
>JRS:  In article <KnWeSGAvZ193Y...@pedt.demon.co.uk> of Sun, 3 Oct 1999
>14:13:19 in news:comp.lang.pascal.borland, Pedt Scragg
><newsmas...@pedt.demon.co.uk> wrote:

>>FWIW, I have made a slightly amended version of my CRT replacement to
>>report the longint I use before the division and can report that:
>>PIII 450MHz gives 2556611 as the value before division
>>IBM  266MHz gives 1374997 as the value before division
>>AMD  133MHz gives  666552 as the value before division

>For completeness, can you confirm that the maximum safe value without
>your modification is (55*65536 - 1) = 3604479 ... can't be that -
>(55*32768 - 1) = 1802239 ... no ... what is it?  Ah, is your count loop
>different? - - - and that the maximum safe value for yours is 2147483647
>or 4294967295?

My loop is slightly different and the max. safe value in mine before
division will be 4294967295. Max safe value in the original before
division would be 3604479.

Quote

>I forget, or never knew, *exactly* how your fix works;

Basically, the figure you get at the end of the calibration loop is
shuffled around so both parts of the longint are divided separately
and recombined to store as a longint rather than a word.

Quote
>but ISTM that a
>fix is possible by adding inside the delay loop the ASM equivalent of "J
>:= X ; repeat Inc(J) until J := Y ;" ; and that inside *that* loop one
>might add another loop, etc.; these would nicely break the present
>barriers indefinitely.

It would be possible but pipelining effects would be likely to cause
problems, IMHO. Better would be, when needed, to go to using the 32 bit
registers as I doubt there will be anything left around using 16 bit
code by then.
Quote

>H'mmm - in coding fixes for high frequency clocks, one needs to consider
>the low frequency behaviour.  I still have my PPC 640, and am currently
>booting it for use.

Sadly, my PPC512 gave up the ghost a few months back.
--
Information on Newsgroup posted weekly on Sunday - read before writing!
Contains links to    |  http://homepages.force9.net/pascal/faq/
helpful information  |  http://www.merlyn.demon.co.uk/clpb-faq.txt
and some guidelines  |  ftp://garbo.uwasa.fi/pc/doc-net/faqclpb.zip

Re:Fastest speed???


In article <3NAj+dEWd593E...@merlyn.demon.co.uk>,
Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:

Quote

>I forget, or never knew, *exactly* how your fix works; but ISTM that a
>fix is possible by adding inside the delay loop the ASM equivalent of "J
>:= X ; repeat Inc(J) until J := Y ;" ; and that inside *that* loop one
>might add another loop, etc.; these would nicely break the present
>barriers indefinitely.

True, but that would sacrifice compatibility with old machines.

Quote
>>There's no need to have better than 0.5% accuracy in delays, IMHO; so
>Borland's original word count and division would suffice, if the loop
>were selected to keep the count in 11000..32767/65535.

The original Borland way was BUGGY. I repeat BUGGY. One should fix it
instead of trying gimmicks to slow down the loop.

Quote
>H'mmm - in coding fixes for high frequency clocks, one needs to consider
>the low frequency behaviour.  I still have my PPC 640, and am currently
>booting it for use.

Bingo. Therefore it is good to fix it. If one wants to make it work with
machines over 100GHz, then one should simply increase the counter to 48
or 64 bits instead of 32, or one could use the BIOS delay function.

Osmo

Re:Fastest speed???


In article <37F803FB.D83F3...@thegrid.net>,
Patrick D. Rockwell <prockw...@thegrid.net> wrote:

Quote
> I wanted
>some
>clarification about this because when it's time for me to get a new computer, I
>don't want one that
>CAN'T use BP7.01 and all of its units.

Is this some kind of bad joke? You would buy a slower computer because
of the bug instead of fixing the bug?

Quote
>So basically, I was hoping that different users would let me know what speed their
>CRT replacement
>units worked at and that way I'd know what the fastest was.

What replacement???? Thwe TP 7.01 did nothing relating to the RET200 bug.

Do you have some problems understanding that the Borland CRT has a bug?
There is no law of nature that says that a CRT unit should fail at some
specific speed. So if someone fixes the bug (the RTE200) is fixed for
good. It does not reappear ever. period.  Sure the 32 bit counter
overruns at some point but it will take some two decades until
computers are fast enough. This only causes problems in the timing.

There is one exception for  the rule. A fix that operates on ex
executables might just increase the divisor. It is hard to make a proper
fix that works on executables (I mean a fix that also keeps delay
working).

Osmo

Re:Fastest speed???


Quote
Osmo Ronkanen wrote:
> In article <37F803FB.D83F3...@thegrid.net>,
> Patrick D. Rockwell <prockw...@thegrid.net> wrote:
> > I wanted
> >some
> >clarification about this because when it's time for me to get a new computer, I
> >don't want one that
> >CAN'T use BP7.01 and all of its units.

> Is this some kind of bad joke? You would buy a slower computer because
> of the bug instead of fixing the bug?

I DIDN'T say that. If the fix exists, that's fine. I'll buy the faster computer.

Quote
> >So basically, I was hoping that different users would let me know what speed their
> >CRT replacement
> >units worked at and that way I'd know what the fastest was.

> What replacement???? Thwe TP 7.01 did nothing relating to the RET200 bug.

> Do you have some problems understanding that the Borland CRT has a bug?

IF I HAD A PROBLEM uinderstanding that Borland CRT had a bug, I wouldn't have started
thisthread!!!!!

Quote
> There is no law of nature that says that a CRT unit should fail at some
> specific speed. So if someone fixes the bug (the RTE200) is fixed for
> good. It does not reappear ever. period.  Sure the 32 bit counter

Thsnks for the clarification. The reason that I asked in the first place was because

A. I thought that there were a number of versions of the CRT replacement,

B. Based on certain messages that I've read, I thought that while each replacement was
good for
some speed higher then 200Mhz, it would fail at some even higher speed.

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.com
mailto:patri48...@aol.com

Re:Fastest speed???


Quote
"Patrick D. Rockwell" wrote:
> A. I thought that there were a number of versions of the CRT replacement,

Yes, there are a lot of patches.

Quote
> B. Based on certain messages that I've read, I thought that while each replacement was
> good for
> some speed higher then 200Mhz, it would fail at some even higher speed.

I was wrong in my message. Keep in mind the following points:

- The Crt unit without the patch will fail on Intel processors
  >= 200 MHz.
- I have no idea when the Crt unit without the patch will fail on AMD
  processors, but 200 MHz is definitely not enough.
- Quoting Osmo Ronkanen: "In general any replacement should do away the
  RTE200 for good. The delay might get problems when one starts about
  100GHz or so."

Since 100 GHz processors are not likely to appear within the next few
years, you don't need to worry once you have applied the patch. I hope
this answers your questions now (and I hope I did not make another
mistake in this post).

Re:Fastest speed???


In article <37F8CBC1.FF32...@thegrid.net>,
Patrick D. Rockwell <prockw...@thegrid.net> wrote:

Quote
>Osmo Ronkanen wrote:

>> Is this some kind of bad joke? You would buy a slower computer because
>> of the bug instead of fixing the bug?

>I DIDN'T say that. If the fix exists, that's fine. I'll buy the faster computer.

There are plenty of fixes. I have personally written four different
ones.

...

Quote

>> There is no law of nature that says that a CRT unit should fail at some
>> specific speed. So if someone fixes the bug (the RTE200) is fixed for
>> good. It does not reappear ever. period.  Sure the 32 bit counter

>Thsnks for the clarification. The reason that I asked in the first place
>was because

>A. I thought that there were a number of versions of the CRT replacement,

It is hard to comment as you do not specify the replacements you mean. I
have only seen one mentioned but the legality of it is questionable.

Quote
>B. Based on certain messages that I've read, I thought that while each replacement was
>good for
>some speed higher then 200Mhz, it would fail at some even higher speed.

And why would you think so?

Here is one fix. It is not a replacement but an unit that is used before
CRT (or any unit that uses CRT). It catches the error and allows also
fixing the delays (though this is not automatic, one has to call the
delay procedure dfix times)

Unit Fdelay;             { Use this before CRT }

interface

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

implementation

{$ifdef msdos}
{$ifdef ver70}

uses dos;

procedure oldints; assembler; { "variables" in the code segment }
          asm dd 0,0 end;

Procedure error;
begin
  runerror(200);
End;

Procedure Int0; assembler;
          asm
          cmp cx,55       { If CX<>55 we are at some other point }
          je @ok
          sti
          call error
@ok:
          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;

{ Int21h handler removes the int0 handler (as well as itself) from the
  memory when CtrlBreak vector is set by CRT right after calculating
  the delay counter. Note DS does NOT point to the data segment when
  this is called }

Procedure Int21h; assembler;
          asm
          cmp ax,$251B
          jne @old               { Not setint 1Bh? }

          push es; push si; push di
          mov si,offset oldints
          xor di,di
          mov es,di
          cld
          segcs; movsw
          segcs; movsw           { restore int 0 }

          mov di,$21*4
          segcs; movsw           { restore int 21h }
          segcs; movsw
          pop di; pop si; pop es

@old:     jmp dword ptr cs:[oldints+4]
          end;

type tr=record int0,int21:pointer; End;
     pr=^tr;

begin
  GetIntVec(0,pr(@oldints)^.int0);
  GetIntVec($21,pr(@oldints)^.int21);

  SetIntVec(0,@int0);
  SetIntVec($21,@int21h);
{$endif}
{$endif}
end.

Osmo

Go to page: [1] [2]

Other Threads