vesa LFB

[pradeep]

I set a vesa LFB mode 4105 under bochs ( 1024x768x8bpp )
But i can't use the LFB address say E000 0000. I have paged it. however it doesn't seem working. it's writing to that address but nothing appears on the screen. However some pixel gets plotted when i plot in the VGA frame buffer. I haven't find any documents so i am not quite sure of how to use LFB.

[Pype.Clicker]

iirc, there's a bit to be set in the mode number that tells the VBE whether regular A000 or LFB should be used. Make sure it's properly defined.

Code: Select all

 log(KLOG_LOG,0,"VBEmodeInfo returned %4x\n"
      "  %ix%i, %ibpp with %c%c%c%c\n"
      "  lfb @ %x",
      out.x.ax,vmi->Xres,vmi->Yres, vmi->bpp,
      vmi->attributes&1?'h':'-', // hardware support
      vmi->attributes&4?'t':'-', // tty support
      vmi->attributes&16?'g':'-',// graphic mode
      vmi->attributes&128?'l':'-',// linear framebuffer
      vmi->physbase
      );

applying that code to "VbeModeInfo" structure should display "h-gl" for linear framebuffer to be supported. If that's the case, then
[tt]mode|0x4000[/tt] should be requested through VBE function 4f02.

[Candy]

I set a vesa LFB mode 4105 under bochs ( 1024x768x8bpp )
But i can't use the LFB address say E000 0000. I have paged it. however it doesn't seem working. it's writing to that address but nothing appears on the screen. However some pixel gets plotted when i plot in the VGA frame buffer. I haven't find any documents so i am not quite sure of how to use LFB.

Did you set it to 4105 or 0x4105 ? 4105 -> 0x100D -> not with LFB.

[pradeep]

Code: Select all

   int   0x10,0x4F01,0,0x111,0,0,Struct_ModeInfoBlock - 0xC0000000 + 0x10000

   memcopy   struct_register - 0xC0000000 + 0x10000,struct_register,SIZE_REGISTER
   memcopy   Struct_ModeInfoBlock - 0xC0000000 + 0x10000,Struct_ModeInfoBlock,SIZE_MIB

   int   0x10,0x4F02,0x4111,0,0,0,0
   memcopy   struct_register - 0xC0000000 + 0x10000,struct_register,SIZE_REGISTER
   cmp   [struct_register.ax],word 0x004F
   jne   .fin

   mov   eax,dword [Struct_ModeInfoBlock.PhysBasePtr]
   call   create_page_table
   mov   eax,dword [Struct_ModeInfoBlock.PhysBasePtr]
   mov   ecx,0x0101
   call   page_bind
   mov   ecx,640
   mov   edi,dword [Struct_ModeInfoBlock.PhysBasePtr]
   mov   eax,0x11223344
   rep   stosd

The function calls are successful. I have enabled paging. I tried this in VMware ( it supports VESA2+).The mode is set (change in size of screen) properly. After setting the mode i created a page table entry for that LFB address and write to it.i am able to write to that address but pixels are not plotted.
Am i doing something wrong?

Thanks
@Pype: i am not good at C. Plz help me with asm. I have set the LFB bit. (0x4115)
@candy: i am quite sure that i used 0x4105 ( here 0x4111) and not 4105

[Candy]

The function calls are successful. I have enabled paging. I tried this in VMware ( it supports VESA2+).The mode is set (change in size of screen) properly. After setting the mode i created a page table entry for that LFB address and write to it.i am able to write to that address but pixels are not plotted.
Am i doing something wrong?

How did you map them? From where to where?

VMWare could locate the frame buffer somewhere else. Did you account for that?

Why does it look like you're memcopying in 16-bit mode to beyond the 1M limit? Are you in unreal mode?

What language is this?

[Pype.Clicker]

@candy: it looks to me that this is ASM code with several macros defined atop of it. What would concern me is whether "memcopy" doesn't trash the content of registers resulting from the call of 'int' ... Also, i'm not too sure whether 'int ...' is a call to VM86 service or just an interrupt call.

@pradeep: it seems to me that you're trying to run that code in some "inbetween" infrastructure where you're not yet in the definitive paged environment (those -C000000 + 64K reminds me of things we do when enabling a higher-half kernel).

Okay, obviously you're correctly requesting a LFB mode, but the question is does that mode support LFB on that machine. You can tell by checking bit 7 of 'modes attributes' iirc.

What i do find surprising is that after you created a page table, you're still using the physical address to write to the screen...

If you have the Bochs available, i suggest you set a breakpoint prior screen writing, and check paging has been correctly set up. For instance, you could use xp (iirc) debugging command to see the content of physical memory, and compare it to what you expected.

[pradeep]

those are real mode calls, i borrowed the idea from rmode_int of bubach's and made a little change for paging.
memcopy is just a macro to copy the contents. If i have to say correctly i am messing up things and i am doing everything in an odd way. However it seems to work for me.The interrupts are successful.i checked the return value (ax=004Fh).The mode is set up correctly.
It maps that linear address to anywhere in memory.I just used the whitepapers from Viridis(quite nice).I am messing up witth lot of tutorials and whitepapers of others.
@Pype:The LFB mode is supported. Obviously the screen size changes and the return values i checked(ax=004F)

What i do find surprising is that after you created a page table, you're still using the physical address to write to the screen...

Isn't that the LFB address (0xE0000000)?

[pradeep]

Sorry for the double post. I fixed it.

What i do find surprising is that after you created a page table, you're still using the physical address to write to the screen...

I thought that PhysBasePtr was the virtual addresss. But it is the physical address. Now i changed my mapping accordingly.It works great in bochs and VMware.Thanks Candy and Pype.

[Pype.Clicker]

np. Waiting to see it running on testing board

[pradeep]

It's happy to know somebody is awaiting to see mine but there is no working console.Flat binaries are loaded succesfully but like to have support a standard executable format. Like to have a gui server similar to that of windows .So will PE be the best choice? i am now laying my hands on PE file format. Could you explain how the linking process goes on in windows.
Is there any documents on loading the PE files.

[AR]

The executable format has nothing to do with the GUI server, PE is a derivative of the DOS format with a 32bit header tacked on after the 16bit header. The design is basically a modified version of COFF.

The format may be easy enough to work with though, there's an article about it on MSDN.
http://msdn.microsoft.com/msdnmag/issue ... fault.aspx
http://msdn.microsoft.com/msdnmag/issue ... fault.aspx

[Candy]

So will PE be the best choice?

No.



at least, there's a very high chance that there's at least one thing that's not entirely perfect for you, which would make a new type with that bit different better.

Practically, there's little difference between most of the common types. The two main types are PE (based on COFF) and ELF (for Unices). There's no good reason to choose either except for minute implementation-level details which you should hide anyway.

[Pype.Clicker]

http://www.osdev.org/osfaq2/index.php/PeBinaries

(just in case someone has something to add there

[pradeep]

Sorry for changing the topic from vesa to pe binaries.
As i was earlier interested in things like virus i got understood a little bit about pe. In windows everything is based on API's. The API seems to be called like this: you get the ordinal number for that API, find the address of that API in IAT. Then it calls that API.
Is kernel32.dll in kernel space or user space? Kernel32.dll seems to be in user space because if it is not Micr0s0ft won't try to hide it in different places. Am i correct?
How do they make system calls?
Can't we do it directly?

[AR]

System calls on Windows are performed using interrupts (INT 0x21 IIRC), SYSENTER or SYSCALL [depending on what the CPU supports]. kernel32.dll is basically just a call through onto ntdll.dll and/or the kernel directly depending on the call.