More VESA Graphics

[Buck Huffman]

Karl, That code wasn't very friendly to all systems in 24 bit mode. Did
you try any other modes? Anyway I made some modifications to the sources
that will make it compatible with more systems in the 24 bit modes(I Hope).
Actually the demo should not have been set to start in mode 118, I meant
to start that in mode 117(a much friendlier mode). Guess nobody's Perfekt.

Stephane, if you give me an E-mail address I'll try to mail you a compiled
exe and pbu. Also the code might compile if you add
$DIM NONE
to it, or even better yet get the new edited version of it from the source
code forum which already has the $dim directive added to it. I should have
already put that in before(I guess that's why we have to test and debug...).

Buck

------------------

[Stephane Fonteyne]

Hey Buck

I try to compiled your code and has errors duplicate variables.
Can you please send the compiled unit of your source?

Kind regards
Stephane


------------------

[Karl Lessmann]

Buck:
Your VESA stuff ran okay on my WinME system.

Unfortunately, not so on the WinXP system I just
purchased. This system is equipped with a flat
panel monitor and that "may" be the problem.

I got a message that it was “auto readjusting” and
it went into La-La Land.
-Karl

------------------

[Stephane Fonteyne]

Hi Programmer

I'm used the registered version of SVGAPB and does work fine on an
DOS Window in Win98/Win98SE/WinME

It's doesn't work on WinNT/Win2k/WinXP

Kind regards
Stephane

------------------

[Buck Huffman]

Well, I just discovered something that I didn't know before. It appears
that some Vesa graphics cards(probably most) will allow you to address
32 bit values into the video memory while in 24 bit modes. It works just
fine on my newer machine with onboard VIA video adapter. On the other
hand, my older machine with graphics blaster 3d card installed will go
ape if you try to use 32 bit color values in 24 bit modes. I knew that
certain inconsistant behaviors occured between different cards, but that's
a new one to Me.

Anyway I've got the 24 bit and 32 bit mode stuff working on my newer
machine. which means it should probably work on most machines now. I'll
post the new code in the source code forum now then I'll be working on the
24 bit code on my other computer for a while.

Also thank you for the links Georg and Tom. I never even would have known
that some cards would accept 32 bit vals in 24 bit mode if I hadn't seen a
code sample on one of those sites doing it. That's very handy to know since
I'd like to make this Vesa lib capable of working on as many machines as
possible. The Vesap code is also an excellent example of Vesa programming,
unfortunately the flat memory model can limit your programs ability to run
on certain platforms. for example if the code uses DPMI then it will require
a DPMI server application to run in plain DOS. On the other hand if you use
the so called flat real mode(or voodoo mode) then it won't work under windows
95. DPMI is definately the best option for most purposes, but for now I just
don't want to limit my options. I still like to use plain old DOS for some
tasks.

Thank you again
Buck

------------------


[This message has been edited by Buck Huffman (edited October 05, 2003).]

[Georg Potthast]

Buck, on the basicguru site there is a vesap.zip file by Erika Schulze in the 1997 packet. This shows how to use vesa to address the video memory of a svga card set in a flat memory model. They use XMS with that.

By the way, this weekend I started to adapt your WIN95 style front-end to my vesa lib. Got it to work in true color and other modes. Still have to do the savescreen and restorescreen routines or find some other way to restore the screen after e.g. messagebox.

------------------

[Buck Huffman]

Thanks for your replies Tom and Georg.

From what I've been able to find out so for, direct screen writes
via the video memory was chosen for use by the originators of the
Vesa bios extensions because it was the method preferred by most
programmers at the time. This because it could be fast(if done right)
and is very flexable. I like it that way myself, except that the
16 color modes do not use a linear memory model, but instead break
the screen up across banks by color, in the same way as Vga mode 12h
does. This was done so that programmers could access it the same way
as mode 12. The real problem is that I never figured out how to access
mode 12 video directly either, and just stuck with using PSET. I even
tried using PSET in vesa mode 102h, but since it assumes a reolution
of 640 x 480 the pixels wern't in the right places, everything was
skewed.

I've seen mode 12 pixel routines before, but never quite grasped the
metrics behind finding the exact pixel location you wanted to access
and the Vesa modes add the extra complication of larger screen areas,
which compound it all with further bank switching dynamics.

I think I'm going to shelf the 16 color mode stuff for now and
concentrate my efforts on the 16 million color mode problems for a
while, Georg's links provided me with some reading materials that
should bring me right up to speed(Thanks Georg), but if anyone has
any more ideas, info, etc... please please toss it right in.

thank you very much
Buck



------------------

[Tom Hanlin]

? VESA doesn't give you any special ability to just write one graphics
routine. It doesn't expand on the basic BIOS services one iota, in that
respect. You still need to write individual graphics routines for every
kind of graphics mode you want to support. The big advantage of VESA is,
your program can find out what modes are possible with the current card.
This will typically include modes that are built with the same general
requirements as the old VGA-specific modes, which makes VGA routines a
key foundation to using VESA graphics.


------------------
Tom Hanlin
PowerBASIC Staff

[Georg Potthast]

With int10h I refered to the VESA bios extensions, subfunction 4Fh. Of course int10h/0C is very slow.

Using VESA you need to write just one routine to address the video memory for different vga cards and it is not much slower than writing card-specific code.

I can recommend to use VESA when doing high-resolution graphics in DOS.


------------------

[Tom Hanlin]

The presence of VESA support does not mean that you can (or should)
avoid writing directly to video memory. The INT 10h services offer
only the most primitive low-level functionality, and are almost
completely useless for graphics handling. Being able to plot only
a point at a time using INT 10h isn't so much "slow" as "glacial".

The advantage of VESA support is that it describes what graphics
modes are available on a given machine, and the way video memory
must be handled in order to write your own graphics routines.

------------------
Tom Hanlin
PowerBASIC Staff

[Georg Potthast]

Just found an assembler program that demonstrates true color programming:

<A HREF="http://www.geocities.com/SiliconValley/Bay/4104/truecol.htm" TARGET=_blank> http://www.geocities.com/SiliconVall...04/truecol.htm </A>

------------------




[This message has been edited by Georg Potthast (edited October 03, 2003).]

[Georg Potthast]

Buck,

you did not write what you are trying to achieve with your code fragment, I assume you try to write directly to the video memory of the VGA card.

Even if you feel that int10h is slow, I would not spend my time trying to write directly to the video memory of a VGA card, since this will be specific to your VGA card and you will have to do a different routine for other VGA cards.

The objective of the VESA standard is that programmers don't have to do specific code for each VGA card.

I think using int10h will be at least as fast as using the windows api.

------------------

[Buck Huffman]

Thank you for the response guys. I've been working on this for a
few hours now, and here's what i've come up with so far.

case0:               ' 4 bit color mode
   ! mov dx,&H03c4
   ! mov ax,2
   ! out dx,al
   ! mov dx,&H03c5
   ! mov ax,c                  ; Color of pixel
   ! out dx,al
   ! mov ax,&H0A000            ; VGA segment
   ! mov si,offset
   ! mov ds,ax
   ! lodsb                     ; Get current byte
'
  just need to figure out how to determine which nibble to
  merge with the new color value, then "AND" it with new color
  value and place the combined value in the "AL" register
  Like this?:
   !mov al, (the value of current nibble)
   !and al, c    ;color of pixel
  only with more emphasis on determining where the high and low
  nibbles go
'
   ! stosb                     ; Send new byte to video
   ! jmp endselect

Can anyone see if I'm on the right track here or if this is totally
going in the wrong direction or what???
I think that the even numbered pixels will always use the low nibble
and odd numbers the high nibble. So by determining if the pixel being
addressed by offset is odd or even, I can easily determine which
nibble to keep and which to discard. Does that sound right?

Any way, I sure would appreciate any thoughts or ideas anyone here
might have. Even if it's a simple idea, I probably haven't thought
of it. I'm pretty slow.

Thank You
Buck


------------------

[Georg Potthast]

You can find a vesa lib written in PB which supports true color at:

<A HREF="http://pbsound.basicguru.com/fdb132.html" TARGET=_blank> http://pbsound.basicguru.com/fdb132.html </A>

Maybe that lib gives you some information to support 32bit.

Just in case: the Vesa-Standard 3.0 can be downloaded from:

<A HREF="http://www.vesa.org/vbelink.html" TARGET=_blank> http://www.vesa.org/vbelink.html </A>


------------------

[Tom Hanlin]

I'd suppose the 16-color modes use the original EGA/VGA display organization.
It shouldn't be too hard to dig up example code. Try here, first:

http://www.powerbasic.com/files/pub/pbdos/graphics/


I have no idea how the 24-bit or 32-bit modes might be arranged.

------------------
Tom Hanlin
PowerBASIC Staff

[Buck Huffman]

I have posted a slightly improved version of my VESA routines in
the source code forum, but it stil has many bugs and weaknesses.
I was hoping that someone here could help me out with direct screen
writes in the 16 color modes. I've never quite grasped the whole
concept involved with that.

Also my vPut routine crashes in 24 and 32 bit modes, stating that
the far heap is corrupt(error 241). To me that sounds like I'm
writing over memory that should be left alone. Can anyone see what's
wrong in the code? Does anything just jump right out at you? I've
been racking my little pea sized brain, but have come up with squat.
If anyone could please help me out, You would have my undieing
gratitude.

Thank you so very much
Buck


------------------