Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE336F624@probe-2.Acclaim-Euro.net>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Gaps between my banks (vesa prog question)
Date: Mon, 21 Dec 1998 15:53:56 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Reply-To: djgpp AT delorie DOT com

jsc AT lds DOT co DOT uk writes:
> int bank_switch(int bank_no)
> {
> union REGS regs;
> regs.x.ax = 0x4F05;
> regs.x.bx = 0;  ///check this line - is it relevant?

Yes, it is very relevant. From the VBE 2.0 spec:

  Input:    AX   = 4F05h   VBE Display Window Control
            BH   = 00h          Set memory window
                 = 01h          Get memory window
            BL   =         Window number
                 = 00h          Window A
                 = 01h          Window B
            DX   =         Window number in video memory in window
                           granularity units  (Set Memory Window only)

So if you want to set window A, %bx must be zero. You may also 
sometimes need to call this routine with %bx=1, to set window B, 
which some cards use for reading video memory (that can be a handy 
feature because it allows you to simultaneously read and write 
different parts of the screen through the two windows, but it is 
surprising how many programs fail to bother with this, so they 
won't work on cards that use a dual window scheme).

> offset = (long)y*2560 + ((long)x * 4) + rgba;
> my_bank=(int)(offset/64000);

Where did you get 64000 from? A 64k bank is 0x10000 bytes in size, 
ie. 65536. This is the cause of your banding problem.

> bank_switch(my_bank);
> offset=offset - (64000*(int)my_bank);

That will work (apart from using the wrong number), but it would be 
much simpler to write it as:

   offset = offset % 0x10000;

or:

   offset &= 0xFFFF;

> _farpokeb(_dos_ds, 0xa0000 + (long)offset, colour);
>
> //rgba is either 1, 2, 3 or 4 and represents whether you are setting
> //the b, g, r or alpha.

You do realise that not every card stores the RGBA values in the same 
order? Almost all use RGB format, but every now and then you will come 
across one that uses a BGR ordering instead, and as it stands your 
program will display the wrong colors on these machines. You need to 
read the color field information from the VESA mode information 
structure, and use this to work out where each color component is 
located within the 32 bit pixel value.

> set_mode(0x112);

That mode number is probably safe to use, but you should always check 
for an error in this function: not every driver will even be capable 
of a 32 bit mode! If you want to make your code really robust, it is 
far better to use the VESA mode list to find the number, rather than 
just hardcoding it. From the VBE 2.0 spec:

   Note: Starting with VBE version 2.0 VESA will no longer define new
   VESA mode numbers and it will not longer be mandatory to support these
   old mode numbers.  However, it is highly recommended that BIOS
   implementations continue to support these mode numbers for
   compatibility with old software.  VBE 2.0-aware applications should
   follow the guidelines in Appendix 5 - Application Programming
   Considerations - for setting a desired mode.


	Shawn Hargreaves.