From: Ludvig Larsson <ludvig AT club-internet DOT fr>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: VESA 2.0
Date: Sat, 27 Dec 1997 02:57:21 +0100
Organization: Grolier Interactive Europe
Lines: 22
Message-ID: <34A46081.1292@club-internet.fr>
References: <01bd0bf0$304189e0$150760c3 AT benjamir>
Reply-To: ludvig AT club-internet DOT fr
NNTP-Posting-Host: ppp-122-148.toulouse.club-internet.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

What you might need to access the next 64kb on screen is
to make a bankswitch.

like:
void set_bank(int bank)
{
 __dpmi_regs reg;
reg.x.ax=0x4f05;
reg.h.bh=0x00;
reg.h.dl=bank;
reg.h.dh=0;
__dpmi_int(0x10,&reg);
}
Bank 0:lets you write to the first 64kb, bank=1 to then 64kb after that,
bank=2.....
Not that after starting up a mode the bank is always the first(=0), top
of screen.
This is easier than the lineframe buffer and doesn't need VBE 2.0.

Hope it helps

Ludvig
ly.  I am just new to DJGPP and have been using
Borland
C++ v3.0 for DOS up til now, but figured I could really increase the
speed
with a 32 bit compiler, but with the code I am using, there is not much
difference (speed wise) between the code generated by DJGPP and
Borland's
Turbo C++ 16bit code.  Is there a way that would be faster?  I'm trying
to get speed similar to that in Jazz JackRabbit.. I can't think of a
faster
way than this in 32 bit!!

// xoxoxoxoxoxo    Snipped code... xoxoxoxoxoxoxoxoxoxoxoxox
for(loop1=0;loop1<160;loop1++)
memcpy(screen+loop1*320,screen_hold+offset+loop1*3200,320);

// Now send the screen buffer to VGA Memory..
_dosmemputl(screen, 16000, 0xa0000);  // Send "screen" buffer to VGA
MEMORY

// Ok.. firstly I know I can use shifts << for the multip's.  I just
wrote
it this way to make easier to understand.
I am copyiny 160 lines of 320 bytes from screen_hold to screen buffers
the offset and 3200 are related to where the screen is located in the
buffer screen_hold.

I would appreciate any optimization suggestions, or any different
approaches
you may have.

Thanks!
Dave.