![]() |
| | #1 |
| Registered User Join Date: Oct 2009
Posts: 11
| No acess to the video memory???? 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);
}
Last edited by joseCarlos; 10-27-2009 at 09:29 AM. |
| joseCarlos is offline | |
| | #2 |
| Registered User Join Date: Sep 2004 Location: California
Posts: 2,845
| Are you actually programming on the DOS operating system?
__________________ bit∙hub [bit-huhb] n. A source and destination for information. |
| bithub is offline | |
| | #3 |
| Registered User Join Date: Oct 2009
Posts: 11
| yes i am, my fryend and im shure i am in 0x101 mode width out problems |
| joseCarlos is offline | |
| | #4 |
| Registered User Join Date: Mar 2003
Posts: 3,844
| What version of DOS? What compiler? What [video] hardware? Where are the "vbeXXX" functions from? gg Last edited by Codeplug; 10-27-2009 at 10:35 AM. |
| Codeplug is offline | |
| | #5 |
| Registered User Join Date: Oct 2009
Posts: 11
| 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, ®, ®, &sreg); return (reg.x.ax == 0x004f); } [\CODE] thanks for your time Last edited by joseCarlos; 10-27-2009 at 11:15 AM. |
| joseCarlos is offline | |
| | #6 |
| Registered User Join Date: Mar 2003
Posts: 3,844
| Is the OS running in a virtual machine or directly on the HW? gg |
| Codeplug is offline | |
| | #7 |
| Registered User Join Date: Oct 2009
Posts: 11
| is directly on HW im just learning to comunicate width VESA card and i can work width vga modes also width mode 12h but when i go to svga modes, the screen is black |
| joseCarlos is offline | |
| | #8 |
| Registered User Join Date: Mar 2003
Posts: 3,844
| You are not checking for errors when calling vbe[Get/Set]Mode(). Does it return success? gg |
| Codeplug is offline | |
| | #9 |
| Registered User Join Date: Oct 2009
Posts: 11
| 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 Last edited by joseCarlos; 10-27-2009 at 12:43 PM. |
| joseCarlos is offline | |
| | #10 |
| Super Moderator Join Date: Aug 2001
Posts: 7,470
| It's been a loooong time since I've done any linear frame buffer code but I'm sure Ralph Brown's Interrupt List would be a good place to start learning about VESA. You must get a far pointer to the LFB and then you can access the LFB just like an array. However to access the LFB I believe you will need a DOS extender. You will be able to set the mode but you will not be able to write to it. If you do not have an extender the max you can memcpy at any one time will be limited to 64KB. Also if you do not have an extender there is no way to map the LFB into your address space.
__________________ If you aim at everything you will hit something but you won't know what it is. |
| Bubba is offline | |
| | #11 | |
| l'Anziano Join Date: Aug 2001
Posts: 2,573
| Quote:
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). | |
| DavidP is offline | |
| | #12 |
| Registered User Join Date: Mar 2003
Posts: 3,844
| 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 |
| Codeplug is offline | |
| | #13 |
| Registered User Join Date: Oct 2009
Posts: 11
| I feel like an idiot I think you are right, I chose a very dark color Thank you for your time one can laugh at will, happens to those who have little experience |
| joseCarlos is offline | |
| | #14 | |
| l'Anziano Join Date: Aug 2001
Posts: 2,573
| Quote:
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);
}
![]() [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] Last edited by DavidP; 10-28-2009 at 01:32 PM. | |
| DavidP is offline | |
| | #15 |
| Super Moderator Join Date: Aug 2001
Posts: 7,470
| 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.
__________________ If you aim at everything you will hit something but you won't know what it is. Last edited by Bubba; 10-28-2009 at 10:17 PM. |
| Bubba is offline | |
![]() |
| Thread Tools | |
| Display Modes | |
|
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| tools for finding memory leaks | stanlvw | C++ Programming | 4 | 04-03-2009 11:41 AM |
| Help with insert/delete binary search tree | Nazgulled | C Programming | 39 | 03-25-2009 04:24 PM |
| Problems with shared memory shmdt() shmctl() | Jcarroll | C Programming | 1 | 03-17-2009 10:48 PM |
| pointers | InvariantLoop | C Programming | 13 | 02-04-2005 09:32 AM |
| Onboard video card memory access | HermioneFan | Game Programming | 1 | 05-28-2003 09:53 AM |