Board index » delphi » Need a (very) fast write-routine for the full screen

Need a (very) fast write-routine for the full screen

Hi everybody,

As my program has often to write the full screen at one moment, I have
written procedures that write the characters first to a buffer in the
heap and then I copy the buffer to the video-memory with the command:

Move(Buffer^, Mem[VideoSeg ; $0000], 8000);
{ 8000 'cause I often use mode 8x8;
  VideoSeg should always be $B800 (no Herculs support) }

But my problem is that the procedure move isn't very fast. Maybe someone
has a faster routine that does the same as the Move-command?

Please mail me, if you have.

Thank you in advance,

Olaf
(Olaf.Uebersch...@t-online.de)

 

Re:Need a (very) fast write-routine for the full screen


In article <6ss3pr$fj...@news00.btx.dtag.de>,

Quote
Olaf Uebersch?r <Olaf.Uebersch...@t-online.de> wrote:
>Hi everybody,

>As my program has often to write the full screen at one moment, I have
>written procedures that write the characters first to a buffer in the
>heap and then I copy the buffer to the video-memory with the command:

>Move(Buffer^, Mem[VideoSeg ; $0000], 8000);
>{ 8000 'cause I often use mode 8x8;
>  VideoSeg should always be $B800 (no Herculs support) }

Do not hardcode it to 8000 if you only often use 80x50 screen.

Quote

>But my problem is that the procedure move isn't very fast. Maybe someone
>has a faster routine that does the same as the Move-command?

Here are two:

Procedure Wmove(var src,dest; size: word);  assembler;
            asm
            cld
            push ds
            mov cx,size
            jcxz @out
            mov bx,cx
            les di,dest
            lds si,src

            mov ax,di
            and ax,1
            mov cx,ax
            rep movsb                   { word align DI }

            sub bx,ax
            mov cx,bx                   { Adjust the size }
            shr cx,1

            rep movsw

            mov cx,bx
            and cx,1
            rep movsb
   @out:    pop ds

            end;

Procedure Fmove(const src;var dest; size: word);  assembler;

            asm
            cld
            push ds
            mov dh,[test8086]
            mov cx,size
            jcxz @out
            les di,dest
            lds si,src
            cmp cx,12
            jbe @short
            mov bx,cx

            mov ax,di
            and ax,1
            mov cx,ax
            rep movsb                   { word align DI }

            sub bx,ax
            mov cx,bx                   { Adjust the size }

            shr cx,1
            mov dl,1

            cmp dh,2                    { Is the cpu 386+ }
            jb @not386

            cmp  cx,10
            jbe  @not386                { moves of 0-3 words }

            mov ax,di
            shr ax,1
            and ax,1
            mov cx,ax
            rep movsw                   { dword align DI }

            sub bx,ax
            sub bx,ax                   { Adjust the size }
            mov cx,bx

            {$ifopt g+}
            shr cx,2
            {$else}
            shr cx,1
            shr cx,1
            {$endif}

            mov dl,3
            db $66

   @not386: rep movsw

            xor dh,dh
            mov cx,bx
            and cx,dx
   @short:  rep movsb
   @out:    pop ds

            end;

As in your case the source and destination will be automatically dword
aligned one could simplify the above routines.

Osmo

Re:Need a (very) fast write-routine for the full screen


In article: <6su5sb$...@kruuna.Helsinki.FI>  ronka...@cc.helsinki.fi (Osmo

Quote
Ronkanen) writes:

[...]

Quote
>Procedure Fmove(const src;var dest; size: word);  assembler;

[...]

Quote
>            {$ifopt g+}
>            shr cx,2
>            {$else}
>            shr cx,1
>            shr cx,1
>            {$endif}

Just a minor point Osmo, I don't understand why you check the "Use 286
instructions" compiler directive when this bit of code will only be executed by
386+ machines? Why not hard-code the "shr cx,2" instruction instead;

 db $C1,E9,$02; { shr cx,2 }

Quote
>            mov dl,3
>            db $66

>   @not386: rep movsw

[...]

Jay
--

 -----------------------------------------
| Jason Burgon - author of Graphic Vision |
| g...@jayman.demon.co.uk                   |
| http://www.jayman.demon.co.uk           |
 -----------------------------------------

Re:Need a (very) fast write-routine for the full screen


In article <252197707...@jayman.demon.co.uk>,

Quote
Jason Burgon <Ja...@jayman.demon.co.uk> wrote:
>In article: <6su5sb$...@kruuna.Helsinki.FI>  ronka...@cc.helsinki.fi (Osmo
>Ronkanen) writes:

>[...]

>>Procedure Fmove(const src;var dest; size: word);  assembler;

>[...]

>>            {$ifopt g+}
>>            shr cx,2
>>            {$else}
>>            shr cx,1
>>            shr cx,1
>>            {$endif}

>Just a minor point Osmo, I don't understand why you check the "Use 286
>instructions" compiler directive when this bit of code will only be executed by
>386+ machines? Why not hard-code the "shr cx,2" instruction instead;

> db $C1,E9,$02; { shr cx,2 }

Because I hate such hard coding. This is one reason why I'd want a
local $G directive.

I am pleased to see that someone uses that much time to analyze my
posts to notice that.

Osmo

Re:Need a (very) fast write-routine for the full screen


Hi !

Quote
>As my program has often to write the full screen at one moment, I have
>written procedures that write the characters first to a buffer in the
>heap and then I copy the buffer to the video-memory with the command:

>Move(Buffer^, Mem[VideoSeg ; $0000], 8000);
>But my problem is that the procedure move isn't very fast. Maybe someone
>has a faster routine that does the same as the Move-command?

Hmm... my guess is that it's NOT the move-command that's slowing your
program down! Moving 8000 bytes is NO amount of memory - and you'll not see
any great boost in performance with any FastMove routine there is in the
world!

Perhaps it's something else in your code that slows the program down!
Perhaps the way you are filling the buffer!!!  Either post some of your code
or analyze it yourself - I bet that you can optimize the rest of the code to
a better performance than you'll get by changing the Move command!!!

How many Frames per second does your text-mode program need anyway :))

Telemachos

Re:Need a (very) fast write-routine for the full screen


Hi !

Quote
>As my program has often to write the full screen at one moment, I have
>written procedures that write the characters first to a buffer in the
>heap and then I copy the buffer to the video-memory with the command:

>Move(Buffer^, Mem[VideoSeg ; $0000], 8000);
>But my problem is that the procedure move isn't very fast. Maybe someone
>has a faster routine that does the same as the Move-command?

Hmm... my guess is that it's NOT the move-command that's slowing your
program down! Moving 8000 bytes is NO amount of memory - and you'll not see
any great boost in performance with any FastMove routine there is in the
world!

Perhaps it's something else in your code that slows the program down!
Perhaps the way you are filling the buffer!!!  Either post some of your code
or analyze it yourself - I bet that you can optimize the rest of the code to
a better performance than you'll get by changing the Move command!!!

How many Frames per second does your text-mode program need anyway :))

Telemachos

Re:Need a (very) fast write-routine for the full screen


Hi !

Quote
>As my program has often to write the full screen at one moment, I have
>written procedures that write the characters first to a buffer in the
>heap and then I copy the buffer to the video-memory with the command:

>Move(Buffer^, Mem[VideoSeg ; $0000], 8000);
>But my problem is that the procedure move isn't very fast. Maybe someone
>has a faster routine that does the same as the Move-command?

Hmm... my guess is that it's NOT the move-command that's slowing your
program down! Moving 8000 bytes is NO amount of memory - and you'll not see
any great boost in performance with any FastMove routine there is in the
world!

Perhaps it's something else in your code that slows the program down!
Perhaps the way you are filling the buffer!!!  Either post some of your code
or analyze it yourself - I bet that you can optimize the rest of the code to
a better performance than you'll get by changing the Move command!!!

How many Frames per second does your text-mode program need anyway :))

Telemachos

Re:Need a (very) fast write-routine for the full screen


Quote
Telemachos wrote:

> Hi !

> >As my program has often to write the full screen at one moment, I have
> >written procedures that write the characters first to a buffer in the
> >heap and then I copy the buffer to the video-memory with the command:

> >Move(Buffer^, Mem[VideoSeg ; $0000], 8000);
> >But my problem is that the procedure move isn't very fast. Maybe someone
> >has a faster routine that does the same as the Move-command?

> Hmm... my guess is that it's NOT the move-command that's slowing your
> program down! Moving 8000 bytes is NO amount of memory - and you'll not see
> any great boost in performance with any FastMove routine there is in the
> world!

> Perhaps it's something else in your code that slows the program down!
> Perhaps the way you are filling the buffer!!!  Either post some of your code
> or analyze it yourself - I bet that you can optimize the rest of the code to
> a better performance than you'll get by changing the Move command!!!

> How many Frames per second does your text-mode program need anyway :))

> Telemachos

Hi there,

Telemachos's got a point there, I guess. Although I find the
ASM-routines
superb (in fact I'm going to use them as well I think; thanx to all who
shared their knowledge with us) I do think you should check whether
there
are any _other_ parts of your code slowing your program down. Check it
with Turbo Profiler provided by Borland ... or email me for a crude
profiler
which I use for analyzing my PM-programs.

By the way, does anybody know why TPROF doesn't work properly with
PM-programs?

Greetings

   Bernd Heutling

Re:Need a (very) fast write-routine for the full screen


Hi all,

At first I wanna thank everybody who helped me with that problem.
I think the asm-code which was sent to me will speed up my program
although I must say that it's very possible that not the Move-command
but another routine is the really reason of the slow speed:

For special window-operations I save and load the screen (and many other
data) to disk and I'm very sure that this is the really problem.
Well, now you could think: "Why doesn't this fellow save the screen to
memory???" - It has a simple answer: As my program has to execute very
large other programs I need every byte of the memory!

Please mail me, if you know how to speed up the read/write-access or if
you have an idea how to write the store/restore-routines in another way.
:-))

Thanks,
Olaf

Re:Need a (very) fast write-routine for the full screen


In article: <6t32k7$...@kruuna.Helsinki.FI>  ronka...@cc.helsinki.fi (Osmo

Quote
Ronkanen) writes:

>In article <252197707...@jayman.demon.co.uk>,
>Jason Burgon <Ja...@jayman.demon.co.uk> wrote:

[...]

Quote
>>Just a minor point Osmo, I don't understand why you check the "Use 286
>>instructions" compiler directive when this bit of code will only be executed
by
>>386+ machines? Why not hard-code the "shr cx,2" instruction instead;

>> db $C1,E9,$02; { shr cx,2 }

>Because I hate such hard coding. This is one reason why I'd want a
>local $G directive.

Yes, that would be nice. Even better would be a PUSH and POP of compiler
directives, like you can with TASM (I think you can anyway). eg:

{$PUSH} { Save current directives }
{$G+}

286 code goes here

{$POP} { Restore previous directives }

Quote
>I am pleased to see that someone uses that much time to analyze my
>posts to notice that.

;-)

-- Jay

 -----------------------------------------
| Jason Burgon - author of Graphic Vision |
| g...@jayman.demon.co.uk                   |
| http://www.jayman.demon.co.uk           |
 -----------------------------------------

Re:Need a (very) fast write-routine for the full screen


JRS:  In article <6t6hl4$mf...@news00.btx.dtag.de> of Wed, 9 Sep 1998
18:33:08 in comp.lang.pascal.borland, =?iso-8859-1?q?Olaf_Uebersch=E4r?=

Quote
<Olaf.Uebersch...@t-online.de> wrote:
>...
>For special window-operations I save and load the screen (and many other
>data) to disk and I'm very sure that this is the really problem.
>Well, now you could think: "Why doesn't this fellow save the screen to
>memory???" - It has a simple answer: As my program has to execute very
>large other programs I need every byte of the memory!

>Please mail me, if you know how to speed up the read/write-access or if
>you have an idea how to write the store/restore-routines in another way.
>:-))

QHAH.  You have, I trust, considered screen-paging?  Many screen modes,
using per screen as they do much less video memory than exists, break it
into a number of pages; some users only ever use Page 0.  See, for
example, Int10/05.

--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    MIME.
  Web <URL: http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
  Correct 4-line sig. separator is as above, a line precisely "-- " (SoRFC1036)
  Do not Mail News to me.    Before a reply, quote with ">" or "> " (SoRFC1036)

Re:Need a (very) fast write-routine for the full screen


Re:Need a (very) fast write-routine for the full screen


JRS:  In article <35FE1DC5.3...@urlfor.addr> of Tue, 15 Sep 1998
04:57:04 in comp.lang.pascal.borland, Mike <ch...@urlfor.addr> wrote:

Quote
>Dr John Stockton wrote:

>[...]

>> QHAH.  You have, I trust, considered screen-paging?  Many screen modes,
>> using per screen as they do much less video memory than exists, break it
>> into a number of pages; some users only ever use Page 0.  See, for
>> example, Int10/05.

>> John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    
>MIME.
>>   Web <URL: http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, &
>links.
>>   Correct 4-line sig. separator is as above, a line precisely "-- "
>(SoRFC1036)
>>   Do not Mail News to me.    Before a reply, quote with ">" or "> "
>(SoRFC1036)

>John, do you publish a list anywhere of the abbreviations you use? I've
>seen some wierd ones, but I don't think I've seen you use this one
>before.

It is common practice to snip signatures.  In this case, you have
included another half dozen abbreviations by not doing so.  Moreover,
one should not rely on the Subject line, especially if changed, being
obvious to the reader; that is reader- and eyeballs- dependent.

It's also a good idea to read signatures - see Line 2 of the one you
quoted above.  "Acronym" is in the better dictionaries.

You do not give a valid-looking E-mail address, and your Message-ID RHS
appears non-compliant.

--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    MIME.
  Web <URL:http://www.merlyn.demon.co.uk/> - TP/BP/&c.  FAQqish topics & links.
  Timo's TurboPascal <A HREF="ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip">FAQ</A>.
  <A HREF="http://www.merlyn.demon.co.uk/clpb-faq.txt">Mini-FAQ</A> of c.l.p.b.

Re:Need a (very) fast write-routine for the full screen


Quote
Dr John Stockton wrote:

  [...]

  > Moreover, one  should not rely on the Subject line,  especially if
  > changed, being  obvious   to   the   reader;   that  is reader-and
  > eyeballs-dependent.

  Sorry, that's the best I could do. "Off-Topic" indicates a different
  thread, "QHAH?"  indicates  a   question   on  the  specific acronym
  referenced in  your  post.  That way, you  wouldn't  have  to search
  DejaNews to  find the reference. This saved you enormous  amounts of
  time and effort.

  Clearly, the only reader who could answer the question  is yourself,
  and you  got the meaning fairly easily. So I guess you could  say it
  worked.

  > It's also  a good idea to read signatures - see Line 2 of  the one
  > you quoted above. "Acronym" is in the better dictionaries.

  Your list has some, but it omits "AIUI". This is fairly  common, but
  if you  do make a list, it might be helpful to newcomers  to include
  any acronyms that you use on the same page.

  Your list  also  omits  "ISTM", which you use  often,  and  is found
  nowhere else. Can you add it to your list?

  > You do  not  give   a   valid-looking   E-mail  address,  and your
  > Message-ID RHS appears non-compliant.

  Under "Personal  Identification",   you   discuss   reasons  for not
  including a correct email address. Spam is the obvious reason.

  I regret such measures are necessary, but nothing else seems to work.

Best Regards,

Mike

Re:Need a (very) fast write-routine for the full screen


JRS:  In article <35FF6C96.6...@urlfor.addr> of Wed, 16 Sep 1998
04:45:42 in comp.lang.pascal.borland, Mike <ch...@urlfor.addr> wrote:

Quote
>Dr John Stockton wrote:

>  [...]

>  > Moreover, one  should not rely on the Subject line,  especially if
>  > changed, being  obvious   to   the   reader;   that  is reader-and
>  > eyeballs-dependent.

>  Sorry, that's the best I could do. "Off-Topic" indicates a different
>  thread, "QHAH?"  indicates  a   question   on  the  specific acronym
>  referenced in  your  post.  That way, you  wouldn't  have  to search
>  DejaNews to  find the reference. This saved you enormous  amounts of
>  time and effort.

You miss the point.  It is comprehensible, but inconspicuous.  I read
everything in this group, ignoring the subject list.  Convention is that
the body should stand alone, and not need the subject.  Don't worry
about DejaNews; I would not have searched it; and my software is
designed to keep all my posts.

Quote
>  > It's also  a good idea to read signatures - see Line 2 of  the one
>  > you quoted above. "Acronym" is in the better dictionaries.

>  Your list has some, but it omits "AIUI"
>  Your list  also  omits  "ISTM"

It does not list the standard ones, which are well described elsewhere,
such as in TOOTKA, to which there is a link on that page, above my list.

Quote
>  > You do  not  give   a   valid-looking   E-mail  address,  and your
>  > Message-ID RHS appears non-compliant.

>  Under "Personal  Identification",   you   discuss   reasons  for not
>  including a correct email address. Spam is the obvious reason.

AIUI, the efficient way of collecting addresses from News can only
access the From line, so a genuine ReplyTo is relatively safe.  One can
also put the address in the Sig, possibly subtly disguised.  I believe
that your chosen pseudo-address, ending in "addr", causes unnecessary
load on the top level name servers.

You have been reading my news-use page rather selectively, it seems.

--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    MIME.
  Web <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqn.zip> -- Timo Salmi's Usenet Q&A.
  Web <URL:http://www.merlyn.demon.co.uk/news-use.htm>  -  about usage of News.
  Don't Mail News. No Encoding. Quote before replies. Snip well. Write clearly.

Other Threads