replacement CRT unit for faster CGA
Author |
Message |
Ralf A. Quin #1 / 13
|
 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 |
|
 |
jan #2 / 13
|
 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 |
|
 |
Pedt Scrag #3 / 13
|
 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 |
|
 |
Huub van Doore #4 / 13
|
 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 |
|
 |
jan #5 / 13
|
 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 |
|
 |
Ralf A. Quin #6 / 13
|
 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 |
|
 |
Pedt Scrag #7 / 13
|
 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 |
|
 |
Huub van Doore #8 / 13
|
 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 |
|
 |
jan #9 / 13
|
 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 |
|
 |
Osmo Ronkan #10 / 13
|
 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 |
|
 |
Dr John Stockto #11 / 13
|
 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 |
|
 |
Robert AH Prin #12 / 13
|
 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 |
|
 |
cyclemi.. #13 / 13
|
 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 |
|
|
|