X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DOS/Windows Pointer Corruption
Date: 4 Apr 2002 09:10:18 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 26
Message-ID: <a8h59q$g3p$1@nets3.rz.RWTH-Aachen.DE>
References: <3CAA5C53 DOT 6020805 AT vif DOT com> <3CAA9C0E DOT 24631B8C AT is DOT elta DOT co DOT il> <3CAB71AB DOT 3060807 AT vif DOT com>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 1017911418 16505 137.226.32.75 (4 Apr 2002 09:10:18 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 4 Apr 2002 09:10:18 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Sahab Yazdani <sahaby AT vif DOT com> wrote:

> well I am finding a 640X480 by 8 bit screen (standard mode 0x101), and 
> width*height*bitDepth>>3 is 921600 bytes.  

No, it isn't.  640*480*8 >> 3 = 640 * 480 = 307200

The number you give is 640*480*3, which would be about correct for a
640x480x24bit mode, but not for an 8 bit one.

> but I don't think that VESA 
> gives the actual size of the memory region, and that this *is* the way 
> to calculate it).

Actually, VESA doesn't grant that the frame buffer is contiguous in
the way you assume it.  It's possible that each scanline of the buffer
consumes more memory than would be necessary to store all the pixels.
That's why the VESA info block gives you two 'scanline widths'.  One
is the physical size of the display (640 in the case at hand), the
other is the amount of memory space allocated for it.

I think using movedata() would be a saner method than the nearptr hack
and memcpy(), here.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.