Xref: news2.mv.net comp.os.msdos.djgpp:5957
From: brucef AT central DOT co DOT nz (Bruce Foley)
Newsgroups: comp.os.msdos.djgpp
Subject: Any VBE experts out there?
Date: Sun, 14 Jul 1996 00:55:16 GMT
Organization: Internet Company of New Zealand
Lines: 65
Message-ID: <4s9jq3$3p5@status.gen.nz>
NNTP-Posting-Host: brucef.central.co.nz
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Hi. I'm having some proplems with some VBE 2 protected
mode functions.  I'll try to explain as clearly as possible,
in the hope that someone out there can help me out.

(Don't bother reading this if you don't know VBE)

First of all, these problems are only related to bank
switching (4F05) & setting the display start (4F07).
Using a linear frame buffer (under VBE 2) works fine,
and if I can't resolve the issues I'm having, I may limit
the library functions I'm developing to either a protected
mode linear buffer, or real mode banking, and exclude
any support for protected mode banking.

I should also point out I am using a Mach 64 with
UNIVBE in order to obtain VBE 2 support.  I am
using UNIVBE's command line option to switch off
the linear frame buffer in order to test the
protected mode bank-switching code.
but anyway....


Function 4F0A offers you the opportunity to copy 
protected mode code from DOS and into your DPMI
application.  I started out by copying function 4F05.
It worked just the same as the DOS version, but I
subsequently noticed a strange side-effect:
My DOS call to 4F07 was performing like a dog.
I could not understand this, and so as a test, I removed
my call to 4F0A and went back to using the DOS
version of 4F05.  Hey presto, performance of 4F07 was
great again.
This raises the question: If you call 4F0A, should
you then only use the protected mode code that
it returns, and not attempt to use the DOS versions?

(Shawn Hargraves ALLEGRO game library sets
up the DPMI version of 4F05, but as far as I can
tell, continues to use DOS to call function 4F07.)

Assuming that the answer might be yes, I then went
back to calling 4F0A, and also set up a function
pointer to the DPMI version of 4F07.  I changed my
test code to use this function, and left DOS totally alone.
The result was partial success.  Performance was
good, but the DPMI version of 4F07 does not work
the same way as it's DOS counterpart.
(which might be why ALLEGRO only uses DOS for
this function (?))

I won't go into the details of how it differs, except to
say that I cannot do hardware scrolling in the same
way as the DOS version, as the pixel & scan-line
values (stored in cx & dx) do not seem to be treated
the same way in the DPMI code.

Does anyone in the know have a suggestion as to
what might be going on?  I sure as hell don't.  I see
the only solution being to drop support for DPMI
banking, which means I would support  VBE 2 with a
linear frame buffer, or else do DOS thunking.

Regards, Bruce.