Board index » delphi » ANN: Replacement CRT Unit

ANN: Replacement CRT Unit

Regular readers will know I have been working on a replacement CRT unit
particularly for T/BP7 that would at least cure the RTE200 bug and offer
support for extended keyboards if available.

Following testing, I have uploaded a replacement CRT for public download.
Full information and a download link at http://www.pedt.demon.co.uk/crt/

File has been offered to Garbo, Simtel and the FTP server of my ISP for
consideration. List of download links will be placed in the Mini-FAQ.
Franz: you are very welcome to place a copy on your TP site.

During testing, it was noticed that the same interface worked for V5, V5.5
and V6.0 as well. Test units compiled using the original CRT did not need
recompilation when a program using the test unit. The new CRT is therefore
available for these versions as well.

Main Changes:

a) Split into separate sections (16 *.OBJ files) to maximise the amount
of smart linking that can be done. This means that programs will be
smaller if not using all the procedures and functions in CRT.

b) Supports F11,F12 etc. if extended keyboard available. Uses Int$16
$00/$01 otherwise as per the original CRT unit. Already written code
should be perfectly OK with the extension to ReadKey to read extended
codes as they should come up as unrecognised in older code. Gray cursor
keys and KeyPad give the KeyPad codes on extended keyboards. If you need
to distinguish between the cursor keys and the keypad keys you should
already have your own unit to do this.

c) CheckSnow is set false on EGA, VGA or better graphics by default on
both initialisation and TextMode changes. CheckSnow still sets true on
CGA cards. The assembly code used is at least as fast as explicitly setting
CheckSnow to false on EGA/VGA/SVGA cards after using TextMode and saves the
programmer forgetting to do so to speed up output.

d) Writing via DirectVideo or BIOS writes: checking conditions changed so
that non-CGA Text Output works a little faster on most machines. As most
computers now in use have EGA, VGA or SVGA graphics, the coding is set to
maximise the speed of writing to these cards at the expense of making CGA
writes slightly slower.

e) Modes above $7 checked and, if Text Mode rather than Graphics Mode, no
force into 80x25 Text Mode on program startup. The original CRT unit set
80x25 colour text mode (Mode 3) if the video mode was above Mode 3 and
not Monochrome Adaptor. If you use 132x25 text mode then this will stay
when running programs compiled with the new CRT unit. If you explicitly
need 80x25 then use TextMode to change the mode at program startup whilst
using the LastMode variable to store the original screen mode to restore
this on program termination.

f) Delay fixed to longint/dword status to prevent RTE200. This occurred
on computers above 200MHz using T/BP7.0x and has been the subject of many
questions in comp.lang.pascal.borland and borland.public.turbopascal. The
version of CRT for TP6.00 resolves the incorrect delay of the original
CRT unit for fast computers.

g) Instructions, as far as possible, allow pipelining on P5+ and
compatible CPU to maximise the speed of the unit.

Not changed:

a) In BW40/80 modes, colour EGA/VGA cards will allow changing the colour
of Text or Background to non-BW colours.

b) Interface part of the unit - to remain compatible.

Thanks to everyone who responded to the thoughts I posted here and those
who were able to test the replacement. In particular thanks to Osmo for the
routine to check for non standard text modes and his check for extended
keyboards.

--
Pedt
'Moon Starer' is a perfect anagram of 'Astronomer'

 

Re:ANN: Replacement CRT Unit


   FWIW, I have been one of those so honored/enriched by having the
opportunity to test and use this CRT Unit replacement.  I fully endorse
this package, and it fixes the RTE200 problem in all cases I've tried.  
The only "effort" (minor) I had to make was replacing the CRT Unit in my
TURBO.TPL with Pedt's...and everything's worked flawlessly ever since.
   A public "THANK YOU" truly is in order for Pedt Scragg!
Quote
> Regular readers will know I have been working on a replacement CRT unit
> particularly for T/BP7 that would at least cure the RTE200 bug and offer
> support for extended keyboards if available.

> Following testing, I have uploaded a replacement CRT for public download.
> Full information and a download link at http://www.pedt.demon.co.uk/crt/

> File has been offered to Garbo, Simtel and the FTP server of my ISP for
> consideration. List of download links will be placed in the Mini-FAQ.
> Franz: you are very welcome to place a copy on your TP site.

> During testing, it was noticed that the same interface worked for V5, V5.5
> and V6.0 as well. Test units compiled using the original CRT did not need
> recompilation when a program using the test unit. The new CRT is therefore
> available for these versions as well.

Re:ANN: Replacement CRT Unit


Quote
> > How can I replace the old CRT in the library file??

> I cannot say it for sure with Pedt's new CRT unit, but the standard
> procedure is using TPUMOVER.EXE. Look in your manuals for more
> information.

   Yes, that's how it's done.

Re:ANN: Replacement CRT Unit


On Sun, 15 Aug 1999 09:22:24 +0100, Pedt Scragg

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

[snip]

Quote
>Main Changes:

>a) Split into separate sections (16 *.OBJ files) to maximise the amount
>of smart linking that can be done. This means that programs will be
>smaller if not using all the procedures and functions in CRT.

Have you tested your claims?

My test result are: for the simple program

uses crt;
begin
end.
Original CRT: 3120 Bytes,  Your CRT70.TPU: 3126 Bytes

For your test.pas program:
Original CRT: 11024 Bytes  Your CRT70.TPU: 11440 Bytes.

As I pointed out in another thread (Re: Calling main function), smart
linking is rather ineffective if the initialization code forces most
of the crt code to be included.

In the readme.txt file you show assembler code for readkey. Why you
declare extended_kbd as boolean and do
   mov ah,extended_kbd
   mov cl,4
   shl ah,cl

instead of declaring var extended_kbd: byte, initialize it to either 0
or $10, and forget about the cl stuff?

Quote
>b) Supports F11,F12 etc. if extended keyboard available. Uses Int$16
>$00/$01 otherwise as per the original CRT unit. Already written code
>should be perfectly OK with the extension to ReadKey to read extended
>codes as they should come up as unrecognised in older code. Gray cursor
>keys and KeyPad give the KeyPad codes on extended keyboards. If you need
>to distinguish between the cursor keys and the keypad keys you should
>already have your own unit to do this.

>c) CheckSnow is set false on EGA, VGA or better graphics by default on
>both initialisation and TextMode changes. CheckSnow still sets true on
>CGA cards. The assembly code used is at least as fast as explicitly setting
>CheckSnow to false on EGA/VGA/SVGA cards after using TextMode and saves the
>programmer forgetting to do so to speed up output.

[snip]

>e) Modes above $7 checked and, if Text Mode rather than Graphics Mode, no
>force into 80x25 Text Mode on program startup. The original CRT unit set
>80x25 colour text mode (Mode 3) if the video mode was above Mode 3 and
>not Monochrome Adaptor. If you use 132x25 text mode then this will stay
>when running programs compiled with the new CRT unit. If you explicitly
>need 80x25 then use TextMode to change the mode at program startup whilst
>using the LastMode variable to store the original screen mode to restore
>this on program termination.

Strictly speaking these changes make the new unit incompatible with
the old one, but maybe this incompatibility is not critical.

Wolfgang
--
In order to e-mail me a reply to this message, you will have
to remove PLEASE.REMOVE from the address shown in the header.

Re:ANN: Replacement CRT Unit


How can I replace the old CRT in the library file??

Thanx,
 Tobi.

Re:ANN: Replacement CRT Unit


Quote
Tobias wrote:

> How can I replace the old CRT in the library file??

I cannot say it for sure with Pedt's new CRT unit, but the standard
procedure is using TPUMOVER.EXE. Look in your manuals for more
information.
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser.  Industrial control and instrumentation
http://members.eunet.at/meg-glaser/    http://members.xoom.com/f_glaser/
http://www.geocities.com/~franzglaser/            http://start.at/bedarf

Re:ANN: Replacement CRT Unit


Wolfgang Ehrhardt <mailto:Wolfgang.Ehrha...@PLEASE.REMOVE.munich.netsurf
.de> said:

Quote

>My test result are: for the simple program

>uses crt;
>begin
>end.
>Original CRT: 3120 Bytes,  Your CRT70.TPU: 3126 Bytes

>For your test.pas program:
>Original CRT: 11024 Bytes  Your CRT70.TPU: 11440 Bytes.

Interesting. Will have a look at this. Possibly as a result of the
extended keyboard check.

Quote
>As I pointed out in another thread (Re: Calling main function), smart
>linking is rather ineffective if the initialization code forces most
>of the crt code to be included.

True enough but there is code in the CRT unit that is not used in
initialisation and it seems sensible to knock out 1/3 of the code if not
needed.
Quote

>In the readme.txt file you show assembler code for readkey. Why you
>declare extended_kbd as boolean and do
>   mov ah,extended_kbd
>   mov cl,4
>   shl ah,cl

>instead of declaring var extended_kbd: byte, initialize it to either 0
>or $10, and forget about the cl stuff?

I put Osmo's code, duly credited, in the readme.txt exactly as it was
posted to clpb - I was particularly interested in the handling of #224
codes and the extended keyboard check. The final unit code for readkey
does declare a byte variable:

ReadKey:

        MOV     AL, CRTScanCode
        MOV     CRTScanCode, 0
        OR      AL, AL
        JNE     @@2
        MOV     AH, CRTReadFlag
        INT     16H
        CMP     AL, 0E0H
        JNE     @@1
        CMP     AH, 46H
        JBE     @@1
        XOR     AL, AL
@@1:    OR      AL, AL
        JNZ     @@2
        MOV     CRTScanCode, AH
@@2:    CALL    BreakCheck
        RETF

Quote
>>b) Supports F11,F12 etc. if extended keyboard available. Uses Int$16
<snip>

>>c) CheckSnow is set false on EGA, VGA or better graphics by default on

<snip>

Quote
>>e) Modes above $7 checked and, if Text Mode rather than Graphics Mode, no
<snip>

>Strictly speaking these changes make the new unit incompatible with
>the old one, but maybe this incompatibility is not critical.

The only one that is potentially going to have an effect is (e) when the
program will need to check the Mode and force, say, 80x25 if they need
complete control over the screen.

Older programs won't be aware of the extended keyboard scan codes so
will have no effect. CheckSnow is really only of use to those with CGA
non-LCD screens.

There will be a version of CRT without the (b), (c) and (e) changes but
incorporating the other changes when my job allows the time to finish
testing that version.

Thanks for the feedback.
--
Pedt
'Moon Starer' is a perfect anagram of 'Astronomer'

Re:ANN: Replacement CRT Unit


Quote
>> How can I replace the old CRT in the library file??

>I cannot say it for sure with Pedt's new CRT unit, but the standard
>procedure is using TPUMOVER.EXE. Look in your manuals for more
>information.

Yes, TPUMOVER is the way to go. The principle is in the readme.txt but
specific instructions for each version of TP are not given as TPUMOVER
changed from being screen driven to command line driven. As you say, the
manuals will give instructions on how to use your version of TPUMOVER.

Remember though to back up, as the readme suggests, turbo.tpl [and
tpp.tpl if you have it] before swapping units around.

--
Pedt
'Moon Starer' is a perfect anagram of 'Astronomer'

Re:ANN: Replacement CRT Unit


I would like to thank Pedt for this terrific solution to
the delay problem.

Just a hint for people getting this unit. If you put the file
into \bp\bin and try to unzip the file, it will not work.

It turns out there is a file unzip.exe in \bp\bin which cannot
handle the now standard zip file format.

Brent
--
Brent Beach, Victoria, BC

Re:ANN: Replacement CRT Unit


Brent Beach <mailto:ae...@FreeNet.Carleton.CA> said:
Quote

>Just a hint for people getting this unit. If you put the file
>into \bp\bin and try to unzip the file, it will not work.

>It turns out there is a file unzip.exe in \bp\bin which cannot
>handle the now standard zip file format.

Useful point. Unzip (as provided by Borland) uses the older 1.10 version
of .zip not the 2.04 version. I will place on the web site [in the next
day or so] a copy, suitably annotated, in .zip 1.10 format for those who
may have not have even an evaluation copy of a later version of an
unzipping utility other than the Borland provided.

--
Pedt
'Moon Starer' is a perfect anagram of 'Astronomer'

Re:ANN: Replacement CRT Unit


JRS:  In article <eHcb6AAKMFu3Y...@pedt.demon.co.uk> of Mon, 16 Aug 1999
19:06:02 in news:comp.lang.pascal.borland, Pedt Scragg

Quote
<newsmas...@pedt.demon.co.uk> wrote:
>Brent Beach <mailto:ae...@FreeNet.Carleton.CA> said:

>>Just a hint for people getting this unit. If you put the file
>>into \bp\bin and try to unzip the file, it will not work.

>>It turns out there is a file unzip.exe in \bp\bin which cannot
>>handle the now standard zip file format.

>Useful point. Unzip (as provided by Borland) uses the older 1.10 version
>of .zip not the 2.04 version. I will place on the web site [in the next
>day or so] a copy, suitably annotated, in .zip 1.10 format for those who
>may have not have even an evaluation copy of a later version of an
>unzipping utility other than the Borland provided.

Somewhere I have, or had, a public domain unzipper which accommodates
2.04.  INFO-ZIP, I think.  Perhaps, instead or as well, you might place
on your site either such an unzipper, or a link to a site containing
one?  Normally, I use XALL.EXE to unzip; it came with The Pascal
Magazine, and can I believe be freely used.

ftp://ftp.demon.co.uk/pub/mirrors/simtelnet/msdos/arcers/pkz204g.exe
is definitive, but is shareware; and it may not be PKWARE's latest.

Caveat: I have seen the UNIX Y2038 effect in a ZIP/UNZIP program,
assumed due to transcribed library code.

--
 ? 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
  Dates - miscdate.htm  Year 2000 - date2000.htm  Critical Dates - critdate.htm
  Y2k for beginners - year2000.txt  UK mini-FAQ - y2k-mfaq.txt  Don't Mail News

Re:ANN: Replacement CRT Unit


 <mailto:Higgi...@ftc-i.SpAmZaP.net> said:
Quote

>Will source be available at some future date?

I'm afraid not. Professional advice indicated that, as certain bits were
not able to be changed - such as HighVideo, NormVideo, LowVideo and the
interface to Int $10 - releasing source code that included these parts
would probably breach the Borland Copyright, as it replaced on of their
units, even though the code used would be likely deemed to be the
standard way of approaching the requirements. The interface section of
crt.pas could also not be released as this is Copyright Borland and
could not be made available to anyone who did not already have the
interface.

Although parts could be made available, it seems inappropriate to do so
as they would be useless without the whole source.

If Borland ever release the RTL in their museum I am advised that it
would then be appropriate to release the source code.

--
Pedt
'Moon Starer' is a perfect anagram of 'Astronomer'

Re:ANN: Replacement CRT Unit


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

>Somewhere I have, or had, a public domain unzipper which accommodates
>2.04.  INFO-ZIP, I think.  Perhaps, instead or as well, you might place
>on your site either such an unzipper, or a link to a site containing
>one?  Normally, I use XALL.EXE to unzip; it came with The Pascal
>Magazine, and can I believe be freely used.

I think info-zip is on both Garbo and ftp.dcu, I will find the locations
and put a download link. Thanks for the pointer.

--
Pedt
'Moon Starer' is a perfect anagram of 'Astronomer'

Re:ANN: Replacement CRT Unit


In article <mwY3xPE7IUu3E...@merlyn.demon.co.uk>
Dr John Stockton <j...@merlyn.demon.co.uk> wrote:

[...]

Quote
>>Useful point. Unzip (as provided by Borland) uses the older 1.10 version
>>of .zip not the 2.04 version. I will place on the web site [in the next
>>day or so] a copy, suitably annotated, in .zip 1.10 format for those who
>>may have not have even an evaluation copy of a later version of an
>>unzipping utility other than the Borland provided.

> Somewhere I have, or had, a public domain unzipper which accommodates
> 2.04.  INFO-ZIP, I think.  Perhaps, instead or as well, you might place
> on your site either such an unzipper, or a link to a site containing
> one?  Normally, I use XALL.EXE to unzip; it came with The Pascal
> Magazine, and can I believe be freely used.

[...]

I have full (and portable) unzip Pascal source code on my
homepage (the Chief's Unzip package). It supports TP/BP/BPW,
Delphi, Virtual Pascal, FreePascal, and GNU Pascal. It also
contains a number of simple example programs that you can
just compile and use "as is" or modify to suit your needs.

Best regards, The Chief
--------------
Dr A Olowofoyeku (The African Chief)
Author of Chief's Installer Pro v5.12 for Win32
    ftp://ftp.simtel.net/pub/simtelnet/win95/install/chief512.zip
Email: la...@keele.ac.uk
WWW: http://ourworld.compuserve.com/homepages/African_Chief/

Go to page: [1] [2]

Other Threads