From: "Flemming Stig Larsen" <flemming DOT larsen AT private DOT dk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Slow MOV opcode
Date: 15 Dec 97 19:16:59 GMT
Organization: Telia Internet
Lines: 31
Message-ID: <01bd098d$d94d4340$11fbffc2@fsl22.novo.dk>
References: <01bd08e7$dfe77f00$10fbffc2 AT fsl22 DOT novo DOT dk> <3494C7D5 DOT 9305B6CA AT umich DOT edu>
NNTP-Posting-Host: d2o101.telia.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk



Michael Krause <mhkrause AT umich DOT edu> wrote in article
<3494C7D5 DOT 9305B6CA AT umich DOT edu>...

> You're writing to video memory.  Video memory accesses can take from two
> to ten times longer than regular memory accesses.  Try to point edi to
> something else instead, and time it.
> 

Hi again!

Thanks for the answers, I got a fair speedup :-)
As you recommended me to, I did the graphic operation somewhere else, and 
then copied to VRAM (rep movsl), and yes, it ran on about double speed. 

Drawing a pixel (on my PC):
	to VideoRam  takes about 20 clocks
	to a buffer  takes about  9 clocks

The buffer is allocated this way: (the only way I know of)

	char *mybuffer[64000];

Drawing to it still takes some time, and I like to do it even faster.
Can I allocate my buffer on a better way?
Could I possibly take advantage of the internal cache?

Thank you

  -Lars