Board index » delphi » rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit

t...@UWasa.Fi (Timo Salmi)

Delphi Developer
Mon, 23 May 2005 17:40:43 GMT

rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit

Thank you for your contribution. This upload is now available as
 48663 Dec 4 01:00 ftp://garbo.uwasa.fi/pc/turbopas/rpcrt100.zip

; Date: Wed, 4 Dec 2002 16:03:00 -0000
; From: "Audrone & Robert Prins" <pr...@onetel.net.uk>
; Subject: RPCRT100.ZIP Optimised TP 5.0/5.5/6.0/BP7.0 CRT unit
;
; File name: RPCRT100.ZIP
; One line description: Optimized TP50/TP55/TP6/BP7 CRT Unit
; Replaces: None
; Suggested Garbo directory: TURBOPA7
; Uploader name & email: Robert AH Prins <pr...@bigfoot.com>
; Author or company: Robert AH Prins
; Email address: pr...@bigfoot.com
; Surface address: 52 Lummis Vale, Kesgrave, IPSWICH, SUFFOLK, IP5 2FJ, UK
; Special requirements: CPU >= 80386 required
; Shareware payment required from private users: N
; Shareware payment required from corporates: N
; Distribution limitations: None
; Garbo CD-ROM distribution allowed without preconditions: Yes
; Demo: No
; Nagware: No
; Self-documenting: Yes
; External documentation included: Yes
; Source included: Some
; Size: 49K / 97 K
; 10 lines description:
; RPCRT100.ZIP contains optimized versions of the Borland TP5.0/5.5/6/BP7
; CRT unit. It also contains the modified CRT.PAS file and .OBJ files for
; all routines to allow users of Delphi 1 to roll their own. The main
; improvement of the unit is the removal of the RTE 200 bug in the Delay()
; function. It also allows the use of extended (F11/F12/etc) keys and it
; will (try to) not reset extended text-modes.
;
; This CRT unit uses 386 instructions and should not be used on 8086/88 or
; 80286 PCs.
;
; Long description:
;
; Like the offering from Pedt Scragg, this unit offers the elimination of
; the RTE 200 bug on fast PCs, but does so through using the quite well
; known technique of using a multiply by the inverse of the divisor. The
; technique ensures that RTE 200 will never ever reoccur, no matter how
; fast PCs will become in years to come. The Delay() function is also
; fully smartlinkable, i.e. if Delay() is not used, not a single byte of
; its code is included. The (small) drawback of this approach is the fact
; that the very first call to Delay() will be slightly less accurate, a
; dummy Delay(1) can be used to cure this "problem". The source code for
; the improved Delay() function has been included, which would allow some
; fine-tuning of the constants if a really accurate delay is required.
;
; Like the offering of Pedt Scragg, this unit also detects the presence
; of an enhanced keyboard, but does so by accessing the BIOS data area
; and it will also (try to) detect and not change video textmodes over
; mode 7.
;
; The unit has been split up into 18 separate .OBJ files, to improve its
; smartlink capability, but given that the bulk of the code is needed in
; the routines that do the required initialisations and handle the CRT
; TFDD, the savings are not all that big.
;
; Where possible, the unit uses 386 instructions to reduce the size of the
; code and/or to improve the speed. The speed of the unit is increased a
; bit more through the replacement of complex (loop/lods/stos/etc)
; instructions by their post-386 faster equivalents.
;
; Included in the archive is a slightly modified version of Pedt Scragg's
; test program. It is enhanced with an explicit test for the Delay()
; function and uses code originally written by Norbert Juffa to give
; millisecond accurate timings.
;
; To allow recompiles of the unit, the full Pascal source is included and
; so are all necessary .OBJ (.OBP where required) files.

   All the best, Timo

--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland
Digital photos collection at http://www.uwasa.fi/ktt/lasktoim/photo/

 
Dr John Stockto

Delphi Developer
Tue, 24 May 2005 06:33:04 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


JRS:  In article <ts0212050939.4...@poiju.uwasa.fi>, seen in
news:comp.lang.pascal.borland, Timo Salmi <t...@UWasa.Fi> posted at Thu, 5
Dec 2002 11:40:43 :-

Quote
>Thank you for your contribution. This upload is now available as
> 48663 Dec 4 01:00 ftp://garbo.uwasa.fi/pc/turbopas/rpcrt100.zip

>; Date: Wed, 4 Dec 2002 16:03:00 -0000
>; From: "Audrone & Robert Prins" <pr...@onetel.net.uk>
>; Subject: RPCRT100.ZIP Optimised TP 5.0/5.5/6.0/BP7.0 CRT unit
>; Special requirements: CPU >= 80386 required

:-(  ...  Earlier today, I fired up my Amstrad PPC640 to run a Pascal
program - but one whose source does not contain 'crt'.

I've swiped the following for <URL:http://www.merlyn.demon.co.uk/pas-
r200.htm#RAHP> - RSVP if any objections :

Quote
>; RPCRT100.ZIP contains optimized versions of the Borland TP5.0/5.5/6/BP7
>; CRT unit. It also contains the modified CRT.PAS file and .OBJ files for
>; all routines to allow users of Delphi 1 to roll their own. The main
>; improvement of the unit is the removal of the RTE 200 bug in the Delay()
>; function. It also allows the use of extended (F11/F12/etc) keys and it
>; will (try to) not reset extended text-modes.
>;
>; This CRT unit uses 386 instructions and should not be used on 8086/88 or
>; 80286 PCs.

Is there a Web page or similar with the

Quote
>; Long description:

??  I don't want to make my page much bigger, and it would be nice to
link to where any new info will magically appear.

Quote
>; Like the offering from Pedt Scragg, this unit offers the elimination of
>; the RTE 200 bug on fast PCs, but does so through using the quite well
>; known technique of using a multiply by the inverse of the divisor. The
>; technique ensures that RTE 200 will never ever reoccur, no matter how
>; fast PCs will become in years to come.

I don't quite understand that; ISTM that every time that CPUs get 256
times faster, another bytes-worth must be needed to store the
calibration.  Or does your resolution get less and less as CPUs get
faster ?

Quote
>The Delay() function is also
>; fully smartlinkable, i.e. if Delay() is not used, not a single byte of
>; its code is included. The (small) drawback of this approach is the fact
>; that the very first call to Delay() will be slightly less accurate, a
>; dummy Delay(1) can be used to cure this "problem".

One might observe that the Borland Crt init, and perhaps others, uses
(IIRC) an implicit effective Delay(55) in the calibration stage of
initialisation, preceded by a delay of up to that value (wait for a
tick, calibrate using interval to next tick).

Quote
>; Like the offering of Pedt Scragg, this unit also detects the presence
>; of an enhanced keyboard,

I have a test program which is intended to see if Pedt's fix has been
applied, by asking for an F11 or similar and showing a 10s delay.
 <URL:http://www.merlyn.demon.co.uk/20010716/crt003.pas> - there's also
crt001 (trivial) and crt002.  Help yourself if interested; it's not
Pedt-specific.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
  <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.

Robert AH Prin

Delphi Developer
Sat, 28 May 2005 08:31:52 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


Sorry, new thread, One.Tel is playing up gain...

Quote
>JRS:  In article <ts0212050939.4...@poiju.uwasa.fi>, seen in
>news:comp.lang.pascal.borland, Timo Salmi <t...@UWasa.Fi> posted
>at Thu, 5 Dec 2002 11:40:43 :-
>>Thank you for your contribution. This upload is now available as
>> 48663 Dec 4 01:00 ftp://garbo.uwasa.fi/pc/turbopas/rpcrt100.zip

>>; Date: Wed, 4 Dec 2002 16:03:00 -0000
>>; From: "Audrone & Robert Prins" <pr...@onetel.net.uk>
>>; Subject: RPCRT100.ZIP Optimised TP 5.0/5.5/6.0/BP7.0 CRT unit

>>; Special requirements: CPU >= 80386 required
>:-(  ...  Earlier today, I fired up my Amstrad PPC640 to run a Pascal
>program - but one whose source does not contain 'crt'.

My father still uses his original 1983 IBM PC...

I'm sorry for both of you, but I'm not going to change the unit to
make it run on a CPU that is well past its sell-by date. I suggest
that you use a decent hex-editor and make a few copies of your TPC/
TURBO.EXE files and patch them with different names for TURBO.TPL,
it's what I'm doing. I currently use TURBO.TPL, JUFFA.TPL, PRINS.TPL
and DEBUG.TPL...

Quote
>I've swiped the following for <URL:http://www.merlyn.demon.co.uk/pas-
>r200.htm#RAHP> - RSVP if any objections :

>>; RPCRT100.ZIP contains optimized versions of the Borland TP5.0/5.5/6/
>>; BP7 CRT unit. It also contains the modified CRT.PAS file and .OBJ
>>; files for all routines to allow users of Delphi 1 to roll their own.
>>; The main improvement of the unit is the removal of the RTE 200 bug
>>; in the Delay() function. It also allows the use of extended
>>; (F11/F12/etc) keys and it will (try to) not reset extended
>>; text-modes.
>>; This CRT unit uses 386 instructions and should not be used on 8086
>>; 8088 or 80286 PCs.

>Is there a Web page or similar with the

>>; Long description:

No, at this moment in time I own a domain, but it just contains an ad
for the company that sold it to me. I'm in the process of leaving the
UK, I've had enough of two parties trying to out-rightwing each other.

Quote
>??  I don't want to make my page much bigger, and it would be nice to
>link to where any new info will magically appear.

>>; Like the offering from Pedt Scragg, this unit offers the elimination
>>; of the RTE 200 bug on fast PCs, but does so through using the quite
>>; well known technique of using a multiply by the inverse of the
>>; divisor. The technique ensures that RTE 200 will never ever reoccur,
>>; no matter how fast PCs will become in years to come.

>I don't quite understand that; ISTM that every time that CPUs get 256
>times faster, another bytes-worth must be needed to store the
>calibration.  Or does your resolution get less and less as CPUs get
>faster ?

You hit the nail on the proverbial head. Once the CPU speeds get high
enough to countdown 2^32 in 55 ms, the multiply will result in zero and
the delay will no longer delay... That's why I included the source.

Quote
>>; The Delay() function is also fully smartlinkable, i.e. if Delay() is
>>; not used, not a single byte of its code is included. The (small)
>>; drawback of this approach is the fact that the very first call to
>>; Delay() will be slightly less accurate, a dummy Delay(1) can be
>>; used to cure this "problem".

>One might observe that the Borland Crt init, and perhaps others, uses
>(IIRC) an implicit effective Delay(55) in the calibration stage of
>initialisation, preceded by a delay of up to that value (wait for a
>tick, calibrate using interval to next tick).

I know, but having already sacrificed some compatibility by using 386
instructions, I think this further incompatibility is worth it.

Quote
>>; Like the offering of Pedt Scragg, this unit also detects the
>>; presence of an enhanced keyboard,

>I have a test program which is intended to see if Pedt's fix has been
>applied, by asking for an F11 or similar and showing a 10s delay.
> <URL:http://www.merlyn.demon.co.uk/20010716/crt003.pas> - there's
>also crt001 (trivial) and crt002.  Help yourself if interested; it's
>not Pedt-specific.

Pedt's program contains the test, so there's no need to take up your
offer, but thanks.

Robert

PS: Over Christmas I'm in Lithuania again, I hope I will be able to
finally finish the last unit, SYSTEM. (Initially it will be the TP6
version and it will run only on 386/7(+) CPUs)
--
Robert AH Prins
pr...@bigfoot.com

Dr John Stockto

Delphi Developer
Sat, 28 May 2005 22:52:59 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


JRS:  In article <3df53...@212.67.96.135>, seen in
news:comp.lang.pascal.borland, Robert AH Prins <pr...@onetel.net.uk>
posted at Tue, 10 Dec 2002 00:31:52 :-

Quote
>>I don't quite understand that; ISTM that every time that CPUs get 256
>>times faster, another bytes-worth must be needed to store the
>>calibration.  Or does your resolution get less and less as CPUs get
>>faster ?

>You hit the nail on the proverbial head. Once the CPU speeds get high
>enough to countdown 2^32 in 55 ms, the multiply will result in zero and
>the delay will no longer delay... That's why I included the source.

My PII/300, in Delphi, can count to a six{*word*249}th of that in 2.7 seconds,
so has a factor of 16*2700/55 = 785 to spare.

New CPUs are more than ten times faster - it may be worth adding a
warning of possible future trouble. By six year's time, the delays may
be becoming noticeably in error.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 Web  <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
 Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

Robert AH Prin

Delphi Developer
Mon, 30 May 2005 04:08:29 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


Quote
Dr John Stockton wrote in message ...
>JRS:  In article <3df53...@212.67.96.135>, seen in
>news:comp.lang.pascal.borland, Robert AH Prins <pr...@onetel.net.uk>
>posted at Tue, 10 Dec 2002 00:31:52 :-
>>>I don't quite understand that; ISTM that every time that CPUs get 256
>>>times faster, another bytes-worth must be needed to store the
>>>calibration.  Or does your resolution get less and less as CPUs get
>>>faster ?

>>You hit the nail on the proverbial head. Once the CPU speeds get high
>>enough to countdown 2^32 in 55 ms, the multiply will result in zero
>>and
>>the delay will no longer delay... That's why I included the source.

>My PII/300, in Delphi, can count to a six{*word*249}th of that in 2.7 seconds,
>so has a factor of 16*2700/55 = 785 to spare.

>New CPUs are more than ten times faster - it may be worth adding a
>warning of possible future trouble. By six year's time, the delays may
>be becoming noticeably in error.

I'll have a look at it in Vilnius, my stepson has a 400MHz P2, it should
make it easier to test things than on the 32Mhz 486 and 60MHz P1 I have
here. However, Pedt's unit will do a divide of 0 by 55 so his unit will
also fail. It might be useful to add a very slow instruction to the
delay loop at some stage.

Robert
--
Robert AH Prins
pr...@bigfoot.com

Dr John Stockto

Delphi Developer
Tue, 31 May 2005 00:59:33 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


JRS:  In article <3df79...@212.67.96.135>, seen in
news:comp.lang.pascal.borland, Robert AH Prins <pr...@onetel.net.uk>
posted at Wed, 11 Dec 2002 20:08:29 :-

Quote
>Dr John Stockton wrote in message ...
>>JRS:  In article <3df53...@212.67.96.135>, seen in
>>news:comp.lang.pascal.borland, Robert AH Prins <pr...@onetel.net.uk>
>>posted at Tue, 10 Dec 2002 00:31:52 :-
>>>>I don't quite understand that; ISTM that every time that CPUs get 256
>>>>times faster, another bytes-worth must be needed to store the
>>>>calibration.  Or does your resolution get less and less as CPUs get
>>>>faster ?

>>>You hit the nail on the proverbial head. Once the CPU speeds get high
>>>enough to countdown 2^32 in 55 ms, the multiply will result in zero
>>>and
>>>the delay will no longer delay... That's why I included the source.

>>My PII/300, in Delphi, can count to a six{*word*249}th of that in 2.7 seconds,
>>so has a factor of 16*2700/55 = 785 to spare.

>>New CPUs are more than ten times faster - it may be worth adding a
>>warning of possible future trouble. By six year's time, the delays may
>>be becoming noticeably in error.

>I'll have a look at it in Vilnius, my stepson has a 400MHz P2, it should
>make it easier to test things than on the 32Mhz 486 and 60MHz P1 I have
>here. However, Pedt's unit will do a divide of 0 by 55 so his unit will
>also fail. It might be useful to add a very slow instruction to the
>delay loop at some stage.

Since your DelayCnt is a DWORD, range >2E9 even if sign matters, and
since "no-one can need delay accuracy of better than one in a thousand",
then, if anything is done, ISTM that you might as well add a factor of
the order of 1000 to the loop time - perhaps by inserting an inner loop
that counts to 256 without using CX.

Having a slow machine also, I've been thinking about the other end too.
All methods really assume a count of at least about several in a
millisecond or in 55ms.  The earliest PCs easily beat that.

But one might have a portable in which the clock could be very slow
indeed; or one might choose to emulate a PC on an alien machine - I once
emulated an LSI-11 program by interpreting LSI-11 op-codes in Pascal on
an Amstrad PPC640 and an HP Vectra ES/12 - it was very slow, but not too
slow to be of use.

There seems to be no cause for concern; but it's nice to have thought
about both ends of the range.

Regards,

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
  <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.

hwcar

Delphi Developer
Sat, 04 Jun 2005 02:24:31 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


Quote
Robert AH Prins wrote:

> Sorry, new thread, One.Tel is playing up gain...

> cut
> --
> Robert AH Prins
> pr...@bigfoot.com

Hello

I have tried you're CRT unit and it has the undesirable effect of
writing with white on black even though the background and foreground
colors have been changed. This does not happen with the original crt
unit. Am I doing something wrong or did you plan it this way?

Regards Hanford

hwcar

Delphi Developer
Sat, 04 Jun 2005 02:35:20 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


Quote
Hanford Carr wrote:

> Robert AH Prins wrote:

> > Sorry, new thread, One.Tel is playing up gain...

> > cut
> > --
> > Robert AH Prins
> > pr...@bigfoot.com

> Hello

> I have tried you're CRT unit and it has the undesirable effect of
> writing with white on black even though the background and foreground
> colors have been changed. This does not happen with the original crt
> unit. Am I doing something wrong or did you plan it this way?

> Regards Hanford

Hello again

Disregard the above I (blush) accidentally linked in an old file.

Cheers Hanford

Osmo Ronkan

Delphi Developer
Sat, 04 Jun 2005 19:06:37 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


"Robert AH Prins" <pr...@onetel.net.uk> wrote in message <news:3df53633@212.67.96.135>...
 My father still uses his original 1983 IBM PC...

Quote

> I'm sorry for both of you, but I'm not going to change the unit to
> make it run on a CPU that is well past its sell-by date.

Turbo Pascal itself is well past its sell-by date. I find the
idea of fixing a bug with means that prevent running on some
computers strange. In anyway can that much be gained by 386 instructions
that it warrants such limitation of the users? Rememeber also that
you might not have control on the computer you have. What if
you have a disk and program on it but the computer you have to use the
program happens to be a 286.

Do you even check the CPU?

Osmo

Georg {*word*259}le

Delphi Developer
Mon, 06 Jun 2005 07:01:33 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


"Osmo Ronkanen" <ok...@hotmail.com> schrieb im Newsbeitrag
news:d0d3e7d9.0212170306.6a4108be@posting.google.com...

Quote
> Turbo Pascal itself is well past its sell-by date. I find the
> idea of fixing a bug with means that prevent running on some
> computers strange. In anyway can that much be gained by 386 instructions
> that it warrants such limitation of the users? Rememeber also that
> you might not have control on the computer you have. What if
> you have a disk and program on it but the computer you have to use the
> program happens to be a 286.

> Do you even check the CPU?

> Osmo

A hobby-pascal-programmer who sometimes distributes  programs written in
Turbo Pascal certainly wellcomes a crt-unit that works on very fast machines
as well as on slow ones, new and old.

Thanks for your sharing fixes,

Georg {*word*259}ler.

Ross Simps

Delphi Developer
Mon, 20 Jun 2005 17:00:50 GMT

Re:rpcrt100.zip Optimized TP50/TP55/TP6/BP7 CRT Unit


Quote
"Robert AH Prins" wrote in message...
> Sorry, new thread, One.Tel is playing up gain...

> >>Thank you for your contribution. This upload is now available as
> >> 48663 Dec 4 01:00 ftp://garbo.uwasa.fi/pc/turbopas/rpcrt100.zip

> >>; Date: Wed, 4 Dec 2002 16:03:00 -0000
> >>; From: "Audrone & Robert Prins" <pr...@onetel.net.uk>
> >>; Subject: RPCRT100.ZIP Optimised TP 5.0/5.5/6.0/BP7.0 CRT unit

> >>; Special requirements: CPU >= 80386 required
> >:-(  ...  Earlier today, I fired up my Amstrad PPC640 to run a Pascal
> >program - but one whose source does not contain 'crt'.

> My father still uses his original 1983 IBM PC...

> I'm sorry for both of you, but I'm not going to change the unit to
> make it run on a CPU that is well past its sell-by date. I suggest
> that you use a decent hex-editor and make a few copies of your TPC/
> TURBO.EXE files and patch them with different names for TURBO.TPL,
> it's what I'm doing. I currently use TURBO.TPL, JUFFA.TPL, PRINS.TPL
> and DEBUG.TPL...

Surely this bunch of utilities would exist in some shape or form for a
machine < 386, wouldn't it?

Besides, anyone who is using CP/M-86 & a computer which is at least a
386, is missing out right now! :-(

Regards,
Ross.

Other Threads

1. over-110.zip Optimized TP6/BP7 Overlay unit

2. over-101.zip Optimized TP6/BP7 Overlay unit

3. em8x-110.zip Optimized TP6/BP7 hardware emulator files

4. em8x-101.zip Optimized TP6/BP7 hardware emulator files

5. textset.zip Replacement for TextMode in TP6+/BP CRT unit, Pedt Scragg

6. crt.zip Replacement CRT units for Turbo/Borland Pascal

7. Release LFN v1.10 - Long filename unit for Win9x and TP6 up to BP7

8. Release LFN v1.09 - Long filename unit for Win9x and TP6 up to BP7

9. Release LFN v1.08 - Long filename unit for Win9x and TP6 up to BP7

10. win98-compatible BP7-CRT-Unit available?