>...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):

>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):

>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.

>>...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.

>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?

>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.

>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).

>>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.

> 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}