getting VESA Mode list

[amirsadig]

Sorry for my alot of Question ;D. but I am not a real mode programmer .

I need now to get a list of all supported vesa mode.
I have define the VESA Info structure and got the VESA Signature "VESA" and far pointer for available mode "VideoModePtr" (example 0x100C000, linear 0xD000).

Code: Select all

memcpy(&vbe_info, (char *)0x2000, sizeof(struct VbeInfoBlock));
    mode_ptr = ((vbe_info.VideoModePtr &0xFFFF0000)>>12)+(vbe_info.VideoModePtr&0xFFFF);
modevar = (char *)mode_ptr;
/* only test code */
for(i=0; i< 30; i++)
    {
   short x;
   memcpy(&x, ptr, 2);
   kprintf("%X ",x);
   modevar = modevar + 2;   
    }

is this Code correct to get the LIST, because I receive a big numbers and minus numbers.

my Code segment base is 0.

[Pype.Clicker]

the Data segment base would be more relevant for this proble, but i assume it is 0 aswell ...

I also assume that you have good reasons to move content from 0x2000 into the structure 'vbeinfo'

If vbeinfo.VideoModePtr is a offset-then-segment pointer ? la realmode, then everything should lead to a good mode_ptr value, as far as i can tell ...

i guess "memcpy(&x, ptr,2)" is a typo for "memcpy(&x,modevar,2)"

Code: Select all

short *modeshorts=(short*)mode_ptr;
for (i=0;i<30;i++) {
   kprint("%X",*modeshorts);
   modeshorts++;
}

should have done it aswell

[Pype.Clicker]

VBE Far Pointers Throughout this specification references will be made to a pointer of the type `vbeFarPtr'.
This isa DWORD pointer that can have two different interpretations depending on whether the BIOS is being called via the real mode INT 10h software interrupt, or via the protected mode entry point.

When functions are called via the real mode INT 10h software interrupt, a `vbeFarPtr' will be a real mode segment:offset style pointer to a memory location below the 1Mb system memory boundary.

When functions are called via the protected mode entry point, a `vbeFarPtr' will be a valid 16-bit protected mode selector:offset style pointer, the selector of which may point to the base of the protected mode BIOS image loaded in memory, user data passed in to the protected mode BIOS or to the information blocks passed in to the protected mode BIOS.
In any case the calling application and BIOS can simply reference the pointer as a 32-bit far pointer to access the data, but should avoid doing any real mode specific pointer arithmetic on the selector:offset values.

So it sounds like my assumption on what "modes pointer" was was wrong. Especially if you got the list from the VBE protected mode interface (now how did *GRUB* get it is another tricky question ...)

[Pype.Clicker]

(example 0x100C000, linear 0xD000).

waitaminute ... is "0x100c000" a value you actually get for the mode pointer ? if this is the case, i rather expect it to code C000:0100 than 0100:C000, knowing that the video rom is located at C000:xxxx ...

<please ignore>

Yep. That might be it. When you encode some pointer by hand (for instance for the jump far hack at TASM), you always tell the segment DWORD first, so the lowest part of the dword is the realmode segment and the highest part is the offset ...

</ignore>

Sorry. It looks like i was wrong. all encodings put offset first, then segment, including LxS, IVT, etc.

[amirsadig]

yes my Data Segment base is 0 and 0x100C000 is what I get from the VESA BIOS return. I get also as I said the Signatur "VESA". that mean I get the correct structure.

I could query getting VESA Mode info (function 02) begining from mode number 0x100 to 0x200 or maximum, which can be used. I think 0x200 will be enough.
so I can get what is supported and save them on linked list to use them to switch between modes.
in performance it is not very dramaticaly, becaue I should also query all geting mode from the vbeFarPtr to get Xresolu...., which are not standard. every mode number on different VBE implementation can set different modes.

[proxy]

BTW, the code can be simplified a lot by using proper pointer types:

Code: Select all

short *modevar;

memcpy(&vbe_info, (char *)0x2000, sizeof(struct VbeInfoBlock));
    mode_ptr = ((vbe_info.VideoModePtr &0xFFFF0000)>>12)+(vbe_info.VideoModePtr&0xFFFF);
modevar = (short *)mode_ptr;
/* only test code */
for(i=0; i< 30; i++)
    {
   short x = *modvar++;
   kprintf("%X ",x);
    }

[amirsadig]

I do not use now function 00 to get available modes, I use it only to check if VESA is suported.

for geting Modes I query between 0x100 to 0x200 all available mode (function 01 ) and save them on modes database (linked list).
so I can jump between Modes as requered later ( when building the GUI)

[amirsadig]

Code: Select all

CRTCInfoBlock struc
HorizontalTotal dw ? ; Horizontal total in pixels
HorizontalSyncStart dw ? ; Horizontal sync start in pixels
HorizontalSyncEnd dw ? ; Horizontal sync end in pixels
VerticalTotal dw ? ; Vertical total in lines
VerticalSyncStart dw ? ; Vertical sync start in lines
VerticalSyncEnd dw ? ; Vertical sync end in lines
Flags db ? ; Flags (Interlaced, Double Scan etc)
PixelClock dd ? ; Pixel clock in units of Hz
RefreshRate dw ? ; Refresh rate in units of 0.01 Hz
Reserved db 40 dup (?) ; remainder of ModeInfoBlock
CRTCInfoBlock ends

I have not understand this structure, which could be used during setting VBE Mode. now I do not use it. in Bochs and VMWare VBE work fine, but in my real PC by switching to my default Mode Monitor said wrong HF VF frequence.

should I use the above structure to define the frequence? if yes, could someone declare it (VBE documentation was not unstandable for me)

[Pype.Clicker]

i cannot remember of having to fill such a structure ... could that be that you're trying to set up a video mode that your screen doesn't support ? ...

[amirsadig]

I scan all supported Mode first and set only what I want, when
the mode it not supported then I does not set video Mode.

I set 800x600 32 bits and my Video card surely support it. it support VBE 3.0 ( nvidia Gforce 4 64MB).

[amirsadig]

I have recompiled the kernel. now I receive a double fault.
but I can not catch it correctly because CPU are reset. normaly my OS stay in panic when there an exception I do not implement it.

I stop interrput by "cli" before entrying unreal mode and enable it after return from unreal mode "sti".

why CPU has been reset? I see my Panic Messages for a second and then rebooted :'(. I can not pause here, it is a real PC not Virtual M.
if I have superman Eye I could see it clearly ;D.
I think why setting Mode has not worked is a result of this double fault.

[amirsadig]

why cpu make a reset? that because during fetching the double fualt execption another execption or interrupt occure.

[Pype.Clicker]

cpu resets because it cannot dispatch the double fault correctly. "dispatching correctly" means that it cannot even execute the first instruction of the double fault: there's a problem *even before* this.

The cleanest way to handle this is to provide a separate TSS for double faults and to use a task gate for that kind of exceptions.

try to keep that Task as simple as possible, give it a dedicated stack segment and pointers.

Chances are that the double fault is issued because of a kernel stack overflow ...

[amirsadig]

it is not a problem to set TSS for that fault, but what should I handle it. I mean what should I do insite that Execption handler?

[Pype.Clicker]

- display "double fault" panic message
- try to get the "faulty status" from the backlinked TSS
- display that status (registers, etc)
- halt.

There's virtually no way to resume from a double fault. At least it will give you the opportunity of checking system status before it resets.