STUDYING VESA 2.0

[jason7007]

Hi,
I am trying to implement the VESA 2.0 in my OS. But this small piece of code is confusing me. This code causes my computer to shutdown. I have only 256 mb of memory on my computer, but this value from VESA is too high, the physical base address.
ModeInfo_PhysBasePtr = 0D8000000H.

Since this is physical address, how did it happen when the memory is just 256mb. The video card memory is 64mb.

Do I need to map this address? how? where?
For now all I need is to paint the whole screen of color BLUE.
Can someone point to me the right direction, pleaseeeeeee.

Thank you so much in advance.

First of all I already setup my video mode to VESA 2.0 800X600 24 bit while the OS loader was in real mode

I used the function 4F00H, 4F01H to get the VESA information.
then used funtion 4F02 to set the video mode.


I got the physical base address from VESA
ModeInfo_PhysBasePtr = 0D8000000H



BELOW CODE IS IN PROTECTED MODE

;''''''''''''''''''''''''';
; fades screen 24bit ;
;.........................;
count dw 0

fade_screen24:

mov edi,[ModeInfo_PhysBasePtr]
mov eax,00000000H
mov byte PTR[count],240
dolop2:
mov ecx,1280 ;640*2
inc al
cli
dolop2a:
stosd
dec edi
loop dolop2a
sti
sub byte PTR[count],1
cmp byte PTR[count],0
jne dolop2

[Seven11]

the VESA LFB (you use the Linear Frame Buffer right?) isn't in the physical memory. You will notice later on when dealing with OSD that alot of devices and things aren't mapped to physical memory.

ecx should be 800 x 600 x 3 = 1440000 = 15F900h if you want to write the whole screen blue.

Why do you use "cli"? it masks all maskable interrupt, I think you need "cld" which makes "stosd" increase (e)di with 4, am I right?
Also, try color 0xFF000000 insteed (that's blue in 24bit).

Try to search for "VGOVBE20.ZIP" it's a zipfile containing a good tutorial by Vector and TimJ of Vertigo and is called "Vesa 2.0 implementation, activation, and just plain how it works."

[jason7007]

Hi,
Yes, I am using LFB. I already read that tutorial of Vertigo, but I am still confused.


Thank you very much for your info.

[jason7007]

Hi,
I'd been searching the internet for sample code, all I got were VESA 2 LFB for DOS using DPMI and DJGPP. Does not help me.
Anyone can tell us how to map this physical address to a base of selector. I have read that this physical address from VESA info will have to be mapped to a base of selector. I am trying but to no avail.

Help pleaseeeeeeeee.

[distantvoices]

Well, in case you are using paging you need to map in the lfb area.

That poster over there claiming the lfb isn't in physical memory should read up on memory mapped IO, Address decoders, & other nifty stuff.

@jason: the address you retrieve from the vesa 2.0 interface is in fact a physical one. It's the vram the video adapter exposes to the cpu as if it were memory. You can write to it as if it were memory. you can read from it as if it were memory. It isn't as fast as memory for it actually is vram on the video adapter. In case you are using paging you need to map it in in order to access it. either 1:1 mapping or map it to any virtual address which is to your liking.

HtH.

[Pype.Clicker]

Hi,
I am trying to implement the VESA 2.0 in my OS. But this small piece of code is confusing me. This code causes my computer to shutdown. I have only 256 mb of memory on my computer, but this value from VESA is too high, the physical base address.
ModeInfo_PhysBasePtr = 0D8000000H.

Since this is physical address, how did it happen when the memory is just 256mb. The video card memory is 64mb.

stop thinking about your physical memory as if it was one, large aray of bytes. Rather see it like a bus where you attach devices that will respond to READ/WRITE commands when they recognize a given physical address. When you read between 0..128MB, for instance, your first 128MB DIMM recognize the address and replies with the value it has. If you read between 128MB and 256MB, reply will come from the second DIMM.

Since you have no device replying for the address range 256MB..2GB, trying to read there always return a "floating wires" value (e.g. electrical noise -- most lifely 0xfffffff). If your CPU supports APIC, it has memory mapped registers somewhere around 0xFExxxxxxx (check intel specs) and your PCI video card has been instructed by the BIOS to react to memory addresses 0D8000000 .. 0D8000000+64MB during PCI initialization.

Do I need to map this address? how? where?

If you're in a paged environment, yes, you need to map it by writing page frames 0xd8000 .. 0xd8400 into some page tables. If you're in a flat model (e.g. have segments you defined yourself with 0 base and 4GB limit), then you just build up a pointer to the location you're told and voil?.

It's not necessary to build a descriptor that has base = 0xd800000, limit=64MB unless your design says you're not happy with a flat data descriptor.

[jason7007]

Hi,
Thank you very much , Pype. Very informative.
Thank you also to others who responded.

[Candy]

ecx should be 800 x 600 x 3 = 1440000 = 15F900h if you want to write the whole screen blue.

If you want to clear the screen to blue you need to write the color blue to each set of 3 values, not to each value.

Why do you use "cli"? it masks all maskable interrupt, I think you need "cld" which makes "stosd" increase (e)di with 4, am I right?

No. cld clears the direction so that stos/movs/etc. goes upward (increases edi) as opposed to going downward (decreases edi). Stosd in/decreases by 4, stosw by 2, stosb by 1 and on 64-bit computers, stosq by 8.

Also, try color 0xFF000000 insteed (that's blue in 24bit).

The lowest 24 bits of your example are 0, and in 32-bit mode you set only reserved bits. Try 0xFF0000.

[Ryu]

Adding to that, stos won't be any use for 3 bytes per pixel modes. The pain about graphics is dealing with differn't color modes such as in 16bit modes can be RGB(5:6:5) or ARGB(1:5:5:5) or ABGR(1:5:5:5), and in 24bit most likely RGB(8:8:8) or BGR(8:8:8). So you will need to find out what exactly is red,green,blue or alpha bitmasks to know they're bitfields, otherwise you be clearing blue for one system and red in the others and some odd color in more others.

I've nevered done any VESA myself but skimming through the VBE 2.0 specification the "ModeInfoBlock" from AX=4F01h function, tells you all bitmask information.