Thread: No acess to the video memory????

Good morning Srs.



I have check by a vesa card
then i have fill a srtuct ModeInfo
vbeGetModeInfo(0x101,&ModeInfo)
and vbeSetMode(0x101);
now i set some bytes in video memory lyke
_fmemset(far*ptr,val,len)

but i just see the screen all black

and i dont figure out why

can some one give me a idea??

why i dont have acess to the video memory?
all the tests return sucess and that mode is suported by the card
and i have VESA ver 3.0

thanks good day to you

Code:

void main(){
	  short oldmode=0;
	  vbeInfo info;
	  vbeModeInfo modeInfo;
	  if(vbeGetInfo(&info)){
		  if(memcmp(info.vesa,"VESA",4)==0){
				 vbePrintInfo(&info);
				 getch();
				 if(vbeGetModeInfo(0x101,&modeInfo)){
						vbeGetMode(&oldmode);
						vbeSetMode(0x101);
						_fmemset((unsigned char far*)MK_FP(0xa000,0),0x15,20);
				 }
		  }else printf("Not Vesa\n");
	  }else printf("Error\n");
		getch();
		if(oldmode)vbeSetMode(oldmode);
}

Are you actually programming on the DOS operating system?

What version of DOS?
What compiler?
What [video] hardware?
Where are the "vbeXXX" functions from?

gg

sorry!!

OS- Dos 5.1
video Card - Intel(r) 82945GM VESA 3.0
that information i can get from my code, and this mode(0x101) is available
on that card
i can see all the information on vbeModeInfo structure
compiler- Borland 4.5

the vbe functions comes from some exemples
i got in web

[CODE]

int
vbeSetMode(int16 mode){
union REGS reg;
struct SREGS sreg;
reg.x.ax = 0x4f02;
reg.x.bx = mode;
int86x(0x10, &reg, &reg, &sreg);
return (reg.x.ax == 0x004f);
}
[\CODE]

thanks for your time

Is the OS running in a virtual machine or directly on the HW?

gg

You are not checking for errors when calling vbe[Get/Set]Mode(). Does it return success?

gg

yes it return 1 ... ax=0x004f

i have a lapptop ASUS, is that important?

if i put cout<<.. or printf(..)
nathing appears

to see samthing i need old the data, and
after in vga modes print that data

_fmemset((unsigned char far*)MK_FP(0xa000,0),0x15,20);

So this is the line where you actually set pixels.

I can't find any documentation on mode 0x101, so I don't know what palette is available and what your resolution is, but if you look here you will notice that color 0x15 on the 256-color palette is a fairly dark gray color. Since you are only writing 20 bytes (4 pixels per byte using 256-color palette), you are only writing 5 pixels.

5 pixels of a dark gray color could be difficult to see on a high res screen (assuming mode 0x101 is high res). Try mode 0x13 and see what happens.

Then try changing the color you are using to something else, say...0x30 (which according to the wikipedia page is a bright lime green).

0x13 is "OEM" (non-VESA) mode - http://www.delorie.com/djgpp/doc/rbinter/it/10/0.html
0x101 is 640x480@256 - http://www.delorie.com/djgpp/doc/rbinter/it/83/0.html
Older VBE 1.2 spec found here - http://docs.ruudkoot.nl/vesasp12.txt

Definitely been a loooong time. Good catch on only 20 bytes being set

Found op's code here: http://www.gameprogrammer.com/2-frust.html, which was originally implemented for use with a DOS extender. However it still works with 64K chunks of video memory via function 4F05h - http://www.delorie.com/djgpp/doc/rbinter/id/83/2.html

gg

I think you are right, I chose a very dark color
Thank you for your time

It was the first thing I suspected because I remember when I played around with low-level video modes like that several years back, I had encountered something very similar.

Always keep in mind the palette and colors you are using. Keep in mind that you are using a graphics mode in which you specify a color from 0 to 256, and that color is initially defined based upon the palette shown on the wikipedia page I referenced earlier.

You actually can specify colors based on RGB values in this mode, but you have to use the palette as an intermediary way of doing things, and hence even though you can specify RGB values of colors you want, you can only have 256 different colors displayed on the screen at one time.

To change your palette and get different colors based upon RGB values you want to work with, try the following functions:

Code:

void writepal(int color, unsigned char r, unsigned char g, unsigned char b)
{
	outp(0x3C6, 0xFF);
	outp(0x3C8, color);
	outp(0x3C9, r);
	outp(0x3C9, g);
	outp(0x3C9, b);
}

void getpal(int color, unsigned char &r, unsigned char &g, unsigned char &b)
{
	outp(0x3C6, 0xFF);
	outp(0x03C7, color);
	r = inp(0x03C9);
	g = inp(0x03C9);
	b = inp(0x03C9);
}

I just dug this up from some old code I wrote. I don't guarantee it works. I don't really even remember what the function outp does

[EDIT]

Page about outp:
http://developers.cogentrts.com/coge...s/re-outp.html

Page about inp:
http://developers.cogentrts.com/coge...cs/re-inp.html

[/EDIT]

AFAIK you cannot use the LFB without a DOS extender. You can however use the old bank switching either via an interrupt or a far pointer to the bank switch function on the video card. I'm not sure if modern video cards are still using this or even support it but I would imagine the underlying core rasterization of video has probably not changed much through the years. It is my guess that the nitty gritty, while still there, is now handled and masked by the drivers that both OGL and D3D interact with.

Remember that you cannot just memcpy() in 640x480 bit modes or in 1024x768 8 bit modes b/c of the bank switch. In higher color modes the 64kb limit will split one of the pixels in two where 2 bytes will be on the first bank and the next 2 bytes will fall on the second bank. As long as you align everything in those modes on a 4 byte boundary you will be fine and your code will send the right data to the right banks.

I highly recommend using Delorie DJGPP as it comes with a DOS extender and will eliminate the need for the bank switch. It is so much easier to use the near pointer hack from DOS 6.0/6.2 days to get a pointer to the LFB than it is to mess with bank switching.

I also recommend you write your own memcpy() to do the blitting to the screen since the CRT memcpy() is meant to be generic and may not be optimal for what you want to use it for.

@DavidP:
Wow it's been a long time since I changed palettes that way. But ya know even with all the Direct3D and shaders I mess with now something way down deep inside of me still sorta misses all that low level stuff. Maybe I'm just sick.

It's amazing that any of us remember this stuff and our willingness to contribute so much info is a testament to our love for low level graphics. My how far we have come from those days. The newcomers to graphics don't know how easy they have it and how much has been taken off of their shoulders.