replacement CRT unit for faster CGA 
Author Message
 replacement CRT unit for faster CGA


Quote:

>...Pardon me if this is obvious, but am I understanding this correctly that
>the replacement CRT unit will be slower than the Borland-supplied CRT until
>when using direct-video writes to the CGA screen?   I am looking for a CRT
>replacement which is faster than the Borland CRT unit in the following
>functions in CGA mode (this is for a high-speed process-control application
>which uses the CGA screen for status display):

That has nothing to do with "CGA mode". They document refers to "TRUE"
CGA cards (which are barley around anymore, i found one after two
years searching on eBay). Due to the design, they tend to flicker
(showing "snow") when the video ram was accessed. So to avoid flicker,
you had to wait for the retrace until you could safely write (or read)
the video ram.
On a  EGA card or anything thereafter, this check is not necessary
anymore, as the timeing/access logic has been modified so that the
"snow" effect doesn't occur anymore. And the check whether to write
with or without retrace check doesn't cost much time anymore on a fast
machine, the difference would be in ns.

Ralf



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

Hi.

I was reading the following web page:

http://www.pedt.demon.co.uk/crt/

...and was a bit unsure about these paragraphs:

-------begin quote------------

CheckSnow is set false on EGA, VGA or better grahpics by default on both
initialisation and TextMode changes. CheckSnow
still sets true on CGA cards. The assembly code used is as fast as the need
to explicitly set CheckSnow to false on EGA/VGA
cards after using TextMode.

Writing via DirectVideo or BIOS writes: checking conditions changed so that
non-CGA Text Ouput 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.

----------end quote------------

...Pardon me if this is obvious, but am I understanding this correctly that
the replacement CRT unit will be slower than the Borland-supplied CRT until
when using direct-video writes to the CGA screen?   I am looking for a CRT
replacement which is faster than the Borland CRT unit in the following
functions in CGA mode (this is for a high-speed process-control application
which uses the CGA screen for status display):

1) write and writeln
2) scrolling
3) gotoxy
4) wherex and wherey
5) clreol
6) clrscr

Thank you.



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

Quote:

>Writing via DirectVideo or BIOS writes: checking conditions changed so that
>non-CGA Text Ouput 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.

>----------end quote------------

>...Pardon me if this is obvious, but am I understanding this correctly that
>the replacement CRT unit will be slower than the Borland-supplied CRT until
>when using direct-video writes to the CGA screen?   I am looking for a CRT
>replacement which is faster than the Borland CRT unit in the following
>functions in CGA mode (this is for a high-speed process-control application
>which uses the CGA screen for status display):

I think you'll find the difference is that it is slower by only a few ns
on machines with a fast processor. For fastest speed the set checksnow
to false and directvideo to true but the consequence is that most CGA
screens are prone to some 'snow' when the direct write to the screen
unless you waited for the retrace.

I'm not aware that anyone has tried to optimise the routines that you
need for use on a CGA other than write one of the many "screenwrite" and
"videowrite" type procedures which would be quicker if you can keep a
note internally of the cursor position. The scrolling could be achieved
with a simple screen read and redraw or prehaps keeping the 'real'
cursor at the bottom of the screen and just using writeln; to do the
scrolling.

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



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

jane heeft geschreven in bericht

Quote:

>Hi.

>I was reading the following web page:

>http://www.pedt.demon.co.uk/crt/

>...and was a bit unsure about these paragraphs:
<snip>
>   I am looking for a CRT
>replacement which is faster than the Borland CRT unit in the
following
>functions in CGA mode (this is for a high-speed process-control
application
>which uses the CGA screen for status display):

<snip>

>Thank you.

Letting your display-card be the bottleneck of your (high-speed)
application is IMHO the wrong thing to do. Trying to make it
better with new software still doesn't make the hardware go
faster.

I have experienced the Borland CRT-unit as _pretty_fast_ on my
XT with HGC (1984) and later EGA-card (1989). Only plain
assembler could outrun it.

Possible solutions to your problem:

1. Buy a HGC-card and monitor. It is probably twice as fast. You
can
then use inverse text, underline (=blue) and blink instead of
colors.

2. Since VGA-cards (with 48MHz displays and 486DX33) are thrown
away as garbage here by the dozen, maybe I can still obtain an
_regarded_as_old_  EGA-card and send it to you.
Estimated speed: three times as fast as CGA.
Note: With the proper settings you can still connect it to the
CGA-display.
3. A VGA-card with mono display would even be a better (but I
think
in your country costly) alternative.

Just let me know.

Sincerely, Huub.

PS. What a sad thing to throw so much away, that others can make
good use of. Worth nothing over here, hundreds of dollars over
there.



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA
On Thu 11 May 2000 01:03:45a,  In article

Quote:


>>...Pardon me if this is obvious, but am I understanding this correctly
>>that the replacement CRT unit will be slower than the Borland-supplied
>>CRT until when using direct-video writes to the CGA screen?   I am
>>looking for a CRT replacement which is faster than the Borland CRT unit
>>in the following functions in CGA mode (this is for a high-speed
>>process-control application which uses the CGA screen for status
>>display):

>That has nothing to do with "CGA mode". They document refers to "TRUE"
>CGA cards (which are barley around anymore, i found one after two
>years searching on eBay). Due to the design, they tend to flicker
>(showing "snow") when the video ram was accessed. So to avoid flicker,
>you had to wait for the retrace until you could safely write (or read)
>the video ram.
>On a  EGA card or anything thereafter, this check is not necessary
>anymore, as the timeing/access logic has been modified so that the
>"snow" effect doesn't occur anymore. And the check whether to write
>with or without retrace check doesn't cost much time anymore on a fast
>machine, the difference would be in ns.

I should have been clearer when I posted the question.  I didn't realize
people would think I was using a CGA card and monitor.  The machine in
question is a 100MHz Pentium Compaq Prolinea.  I imagine it has an SVGA
card.

Is there anything available to write to the screen in CGA mode that is
faster than the default Borland CRT unit with directvideo=true and
checksnow=false?  Or is the Borland CRT until about as fast as anything
else?

Thanks again.



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

Quote:
>On Thu 11 May 2000 01:03:45a,  In article


>I should have been clearer when I posted the question.  I didn't realize
>people would think I was using a CGA card and monitor.  The machine in
>question is a 100MHz Pentium Compaq Prolinea.  I imagine it has an SVGA
>card.

Ok, maybe my answer was not as clear either... ;-)
I didn't think that you actually have a CGA card, as they are VERY
RARE these days....
Quote:
>Is there anything available to write to the screen in CGA mode that is
>faster than the default Borland CRT unit with directvideo=true and
>checksnow=false?  Or is the Borland CRT until about as fast as anything
>else?

That's what i tried to tell you before. There's only a significant
delay when using a TRUE CGA, for everything else the only addition to
the optimal procedure is a small check for a TRUE CGA. If it's not
there, the CRT routines use the fast version.
And most of the functions that you mentioned have quite some overhead
anyway (writeln for example) or are using relative slow BIOS routines
anyway (GotoXY, Scrolling)
Quote:
>Thanks again.

No problemo....


Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

Quote:

>I should have been clearer when I posted the question.  I didn't realize
>people would think I was using a CGA card and monitor.  The machine in
>question is a 100MHz Pentium Compaq Prolinea.  I imagine it has an SVGA
>card.

Certainly VGA or SVGA. It becomes clearer as to what you are looking for
Quote:

>Is there anything available to write to the screen in CGA mode that is
>faster than the default Borland CRT unit with directvideo=true and
>checksnow=false?  Or is the Borland CRT until about as fast as anything
>else?

Do you mean by 'CGA mode' a 80x25 text screen ? If so then your computer
is using at least VGA based on the spec you gave. My CRT replacement is
slightly faster [and we are talking probably ms based on the spec you
give] in VGA/SVGA mode than Borlands as it has been optimised for EGA
and above graphics cards.

How quickly do you need this output ? It is rather more possible, from
what you have said already, that the program code itself is providing a
bottleneck rather than the speed of output.

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



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

jane heeft geschreven in bericht

<snip>

Quote:
>I should have been clearer when I posted the question.  I didn't
realize
>people would think I was using a CGA card and monitor.  The
machine in
>question is a 100MHz Pentium Compaq Prolinea.  I imagine it has
an SVGA
>card.

>Is there anything available to write to the screen in CGA mode
that is
>faster than the default Borland CRT unit with directvideo=true
and
>checksnow=false?  Or is the Borland CRT until about as fast as
anything
>else?

>Thanks again.

Dear Jane,

I'm very interested in your problem. I think a P-100 should do
the job on
most high-speed control processes. Unless I am terribly mistaken,
you have to reconsider about your program code instead of using a
CRT
replacement.

A few years back I have encountered a similar problem in a
draw-application I was constructing. The problem was:
The screen couldn't keep up with the data coming from the
ligthpen used to draw on the screen.

From this experience I have got some things for you to consider
about your program code.
(Please refer to CRT as 'Text Mode' in stead of CGA-mode since
it applies to all graphic-cards)

Tips:
- Is it really neccessary to process all the incoming data?
- Can you occasionnally skip one or to samples?
- Is it necessary for the program to react on a sample that is
the same as the previous one, or can you skip until the
sample changes ?

- Is it really necessary to update the screen all the time?
- Are the items to be updated as little as possible?
(That is: are you perhaps displaying output that has not changed)

- Have you considered an output-screen with fixed positions?
Since you need WhereX and  WhereY, a lot of valuable time is lost
looking where the cursor is. Since you know what you are
displaying, you can easily update your own copy of
(CursorX,CursorY) to be aware of the cursor location all the
time.

- If you are displaying a graph bar, can the column positions be
stored in such a way that WhereX, WhereY are not needed?

- Is 'process_data'  in the loop:

repeat
   get_input
   process_data
   display_them
until quit

as short as possible?
That is: are you trying to managing things in 'process_data' that
don't matter to procedure 'display_them' ?
Can these sub_procedures in process be postponed to a time
when there is no more input to read?
Can (some of the) values read from 'get_input' be stored
temporarily to be processed at a later time?

If you have already considered these things, then there is
nothing more to do about it.
Perhaps you could take a closer look at your system
configuration.
- Are there any things running in the background that do not
matter to the process but mess up your timing? (Win 95/98,
TSR-programs or a LAN connection).

Please send more details or some program code to the
newsgroup to help me (and others) understand the problem better.

Good luck. Huub.



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA


Quote:

>jane heeft geschreven in bericht

><snip>
>>I should have been clearer when I posted the question.  I didn't
>realize
>>people would think I was using a CGA card and monitor.  The
>machine in
>>question is a 100MHz Pentium Compaq Prolinea.  I imagine it has
>an SVGA
>>card.

>>Is there anything available to write to the screen in CGA mode
>that is
>>faster than the default Borland CRT unit with directvideo=true
>and
>>checksnow=false?  Or is the Borland CRT until about as fast as
>anything
>>else?

>>Thanks again.

>Dear Jane,

>I'm very interested in your problem. I think a P-100 should do
>the job on
>most high-speed control processes. Unless I am terribly mistaken,
>you have to reconsider about your program code instead of using a
>CRT
>replacement.

>A few years back I have encountered a similar problem in a
>draw-application I was constructing. The problem was:
>The screen couldn't keep up with the data coming from the
>ligthpen used to draw on the screen.

>From this experience I have got some things for you to consider
>about your program code.
>(Please refer to CRT as 'Text Mode' in stead of CGA-mode since
>it applies to all graphic-cards)

>Tips:
>- Is it really neccessary to process all the incoming data?
>- Can you occasionnally skip one or to samples?
>- Is it necessary for the program to react on a sample that is
>the same as the previous one, or can you skip until the
>sample changes ?

>- Is it really necessary to update the screen all the time?
>- Are the items to be updated as little as possible?
>(That is: are you perhaps displaying output that has not changed)

>- Have you considered an output-screen with fixed positions?
>Since you need WhereX and  WhereY, a lot of valuable time is lost
>looking where the cursor is. Since you know what you are
>displaying, you can easily update your own copy of
>(CursorX,CursorY) to be aware of the cursor location all the
>time.

>- If you are displaying a graph bar, can the column positions be
>stored in such a way that WhereX, WhereY are not needed?

>- Is 'process_data'  in the loop:

>repeat
>   get_input
>   process_data
>   display_them
>until quit

>as short as possible?
>That is: are you trying to managing things in 'process_data' that
>don't matter to procedure 'display_them' ?
>Can these sub_procedures in process be postponed to a time
>when there is no more input to read?
>Can (some of the) values read from 'get_input' be stored
>temporarily to be processed at a later time?

>If you have already considered these things, then there is
>nothing more to do about it.
>Perhaps you could take a closer look at your system
>configuration.
>- Are there any things running in the background that do not
>matter to the process but mess up your timing? (Win 95/98,
>TSR-programs or a LAN connection).

>Please send more details or some program code to the
>newsgroup to help me (and others) understand the problem better.

>Good luck. Huub.

Thanks.  You have some good suggestions there, which are probably better
solutions to the problem.  When time permits, I plan to implement some of
the suggestions.  In the meantime, I searched the web and found a fast
80x25 TextMode screen write procedure at the SWAG site (It is more than
twice as fast as Turbo's "write").  That put me well under budget for the
screen updates.  (budget = 4% of realtime; 2ms every 20Hz cycle).

const
    BaseOfScreen : word=$b800;

procedure  FastWrite(Strng : String; Row, Col, Attr : Byte); assembler;
  asm
      PUSH    DS                     { ;Save DS }
      MOV     CH,Row                 { ;CH = Row }
      MOV     BL,Col                 { ;BL = Column }

      XOR     AX,AX                  { ;AX = 0 }
      MOV     CL,AL                  { ;CL = 0 }
      MOV     BH,AL                  { ;BH = 0 }
      DEC     CH                     { ;Row (in CH) to 0..24 range }
      SHR     CX,1                   { ;CX = Row * 128 }
      MOV     DI,CX                  { ;Store in DI }
      SHR     DI,1                   { ;DI = Row * 64 }
      SHR     DI,1                   { ;DI = Row * 32 }
      ADD     DI,CX                  { ;DI = (Row * 160) }
      DEC     BX                     { ;Col (in BX) to 0..79 range }
      SHL     BX,1                   { ;Account for attribute bytes }
      ADD     DI,BX                  { ;DI = (Row * 160) + (Col * 2) }
      MOV     ES,BaseOfScreen        { ;ES:DI points to
BaseOfScreen:Row,Col }

      LDS     SI,DWORD PTR [Strng]   { ;DS:SI points to St[0] }
      CLD                            { ;Set direction to forward }
      LODSB                          { ;AX = Length(St); DS:SI -> St[1] }
      XCHG    AX,CX                  { ;CX = Length; AL = WaitForRetrace }

      MOV     AH,Attr                { ;AH = Attribute }

      LODSB                          { ;Load next character into AL }
                                     { ; AH already has Attr }
      STOSW                          { ;Move video word into place }


      POP     DS                     { ;Restore DS }
  end; {asm block}



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

Quote:

>Thanks.  You have some good suggestions there, which are probably better
>solutions to the problem.  When time permits, I plan to implement some of
>the suggestions.  In the meantime, I searched the web and found a fast
>80x25 TextMode screen write procedure at the SWAG site (It is more than
>twice as fast as Turbo's "write").  That put me well under budget for the
>screen updates.  (budget = 4% of realtime; 2ms every 20Hz cycle).

But a routine should work on any screen size, not just 80x25.

Osmo



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA


Quote:


>>Thanks.  You have some good suggestions there, which are probably better
>>solutions to the problem.  When time permits, I plan to implement some of
>>the suggestions.  In the meantime, I searched the web and found a fast
>>80x25 TextMode screen write procedure at the SWAG site (It is more than
>>twice as fast as Turbo's "write").  That put me well under budget for the
>>screen updates.  (budget = 4% of realtime; 2ms every 20Hz cycle).

>But a routine should work on any screen size, not just 80x25.

Jane's initial post, starting this thread, included : "(this is for a
high-speed process-control application which uses the CGA screen for
status display)".

It is evidently a very specific application, for which a specific
solution must be acceptable, particularly if its limitations are
understood by its installer.

I have written something which might be called a "high-speed process-
control application" - its display was specifically designed for 80*25,
and anything else would have had too few characters, or have had
characters too small to read from the necessary (non-seated) distance,
or have used a screen too large to fit in the space available.  There
was *no* chance of exporting the program, since it used a pair of
peripherals designed & built in-house (we only made four), and the only
other places in the world who might have wanted such were rivals.

Going back to the original question : it could be quicker to write
directly to the screen buffer area, in well-considered Pascal; and, once
that had been proved to work correctly, to implement the inner parts of
the more time-consuming routines in ASM.  That FastWrite appears to
conform to that.

Pedt may be wrong, or incomplete, in asserting that the machine must be
using at least VGA : I guess it has VGA capability, and maybe a VGA
card, but I'd expect that it could be put into a CGA mode, and that such
a mode might under some circumstances be preferred.

--

 Web <URL: http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper 4-line sig. separator is as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA


Quote:
> On Sat 13 May 2000 12:07:34p,  In article <8fju09$bi4


Quote:

> Thanks.  You have some good suggestions there, which are probably
> better solutions to the problem.  When time permits, I plan to
> implement some of the suggestions.  In the meantime, I searched the
> web and found a fast 80x25 TextMode screen write procedure at the
> SWAG site (It is more than twice as fast as Turbo's "write").  That
> put me well under budget for the screen updates.  (budget = 4% of
> realtime; 2ms every 20Hz cycle).

> const
>     BaseOfScreen : word=$b800;

> procedure  FastWrite(Strng : String; Row, Col, Attr : Byte);
> assembler;
>   asm
>       PUSH    DS                     { ;Save DS }
>       MOV     CH,Row                 { ;CH = Row }
>       MOV     BL,Col                 { ;BL = Column }

>       XOR     AX,AX                  { ;AX = 0 }
>       MOV     CL,AL                  { ;CL = 0 }
>       MOV     BH,AL                  { ;BH = 0 }
>       DEC     CH                     { ;Row (in CH) to 0..24 range }
>       SHR     CX,1                   { ;CX = Row * 128 }
>       MOV     DI,CX                  { ;Store in DI }
>       SHR     DI,1                   { ;DI = Row * 64 }
>       SHR     DI,1                   { ;DI = Row * 32 }
>       ADD     DI,CX                  { ;DI = (Row * 160) }
>       DEC     BX                     { ;Col (in BX) to 0..79 range }
>       SHL     BX,1                   { ;Account for attribute bytes }
>       ADD     DI,BX                  { ;DI = (Row * 160) + (Col * 2) }
>       MOV     ES,BaseOfScreen        { ;ES:DI points to
> BaseOfScreen:Row,Col }

>       LDS     SI,DWORD PTR [Strng]   { ;DS:SI points to St[0] }
>       CLD                            { ;Set direction to forward }
>       LODSB                          { ;AX = Length(St);
> DS:SI -> St [1] }
>       XCHG    AX,CX                  { ;CX = Length; AL =
> WaitForRetrace }

>       MOV     AH,Attr                { ;AH = Attribute }

>       LODSB                          { ;Load next character into AL }
>                                      { ; AH already has Attr }
>       STOSW                          { ;Move video word into place }


>       POP     DS                     { ;Restore DS }
>   end; {asm block}

Depending on the CPU (ie 486+), this may be sped up a little more by
replacing the "LOOP" by a faster "DEC CX / JNZ ..." and the LODSB and
STOSW with the equivalent "MOV AL, ... / INC SI" / "MOV ..., AX / ADD
DI, 2"

Robert
--
Robert AH Prins

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 replacement CRT unit for faster CGA

Quote:
>Depending on the CPU (ie 486+), this may be sped up a little more by
>replacing the "LOOP" by a faster "DEC CX / JNZ ..."

Or better yet, use JZ (depending on expected string length):

{$IFDEF JZ}

asm

dec cx


end;

{$ELSE}

asm

dec cx

end;

{$ENDIF}

On my PC (100MHz Pentium), the JNZ code is slower
for values of * less than 8.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

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

2. wwin20.zip Crt unit TP/BP6+ replacement also for Windoze

3. Problem with replacement CRT unit

4. ANN: Replacement CRT Unit and request for Source

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

6. ANN: Replacement CRT Unit

7. CRT unit div 0 err on fast computers

8. CRT unit problem on fast machines

9. CRT replacement

10. CRT-replacement

11. Crt Replacement- working,but in what Mode?

12. Crt replacement

 

 
Powered by phpBB® Forum Software