VESA 2.0 LFB & page flipping

[Alex Khiriac]

Hi All/ Ian
first off all great work for BareMeral !!!
I just wonder if it is really possible to port VESA 2.0 up Protected Mode Code up to 64 Bit linear addressing.
I believe that almost all protected mode original routines  from VESA interface are playing with CRT controller PORT's to setup resolutions and color palette or
WindowA or WindowB address or page-flipping like double-buffer , tripple-buffer   animation.
I wonder ....may be we can query original code for VESA protected mode interface from every card using VBE functions and patch the code  to run on 64 bit enviroment since selector:offset addressing
is no more required and all off the rest of the code is pure SVGA controller programming with IN/OUT ports for CRT controller and not much over.
In those days ,i believe that most of the video cards  are VBE 3.0 compatible which is the last standard. (without proprietary drivers  for  payware OS....etc.).

Anyway this is just like a dream come true!! ...being on your own with the video card on 64 bit addressing ... many good games can come out on OS like BareMetal (and even without GPU graphics ) !!!!

Cheers for you!!
Alex.

[Ian Seyler]

This would be useful. Pure64 is able to set a VESA LFB mode while still in 16-bit mode but you can't change it once it is set.

-Ian

[christos...@gmail.com]

HI Alex,

The only advantage I see for getting the VESA PM BIOS code would have been to be able to switch resolutions. For the rest of the VESA video functions, I does not make that much sense, since LFB adressing is allowed (and pretty fast) on BaremetalOS. So, triple buffering would be quite easy to implement.

Unfortunately, when I was playing with graphics on BMOS, I was working on a QEMU virtual machine which does not have to my knowledge a VESA PM BIOS.

Chris

[alexandru...@gmail.com]

Hi Ian,
i'm trying to figure out where BareMetal  is mapping the Video Physical Address  LFB of video card into CPU 64 bit linear address. I can see looking into the code that in the final step
BM is keeping this address  in sysvars.asm  to  os_VideoBase variable.. but i'm not sure that this is a physical address or a virtual one already.


 Can you point me into the right direction with this ? 

Thanks,
Alex.

[Ian Seyler]

That is the physical address of the LFB. BareMetal doesn't use virtual addresses. All you need to do is write your data to that starting address.

-Ian

[alexandru...@gmail.com]

Hi Ian,
thanks for reply. Regarding virtual address... you state that BM does not use virtual addresses...that leads me to another question are the physical addresses mapped identity to virtual so basically there is no difference between them? ..i'm trying to understand how
memory map works in 64 bit long mode.

Thanks,
Alex.

[Ian Seyler]

Hi Alex,

Yes, everything is mapped 1:1 so there is no difference between virtual and physical.

-Ian

[alexandru...@gmail.com]

Hi Ian,

i run into a crash with BM using this code (assuming that vesa is initialised at 1280x1024x24 bit color):


#include "libBareMetal.h"


unsigned long VideoX, VideoY, VideoBPP;
char* VideoMemory;


void clr() {
    asm(".intel_syntax noprefix                      \n"
               "push      rdi                        \n"
               "push      rsi                        \n"
               "push      rcx                        \n"

               "mov       rdi, VideoMemory           \n"  //pointer screen 8 byte
               "mov       rsi, 0x0000FF00             \n" //        color 4 byte
               "mov       rcx,230400                 \n"

               "repeat:                              \n"

               "mov      [rdi],esi                   \n"
               "add      rdi,3                       \n"
               "loop     repeat                      \n"

               "pop       rcx                        \n"
               "pop       rsi                        \n"
               "pop       rdi                        \n"
              );
}




int main()
{

    unsigned char tchar;

    VideoMemory = (char*)b_system_config(20, 0);
    if (VideoMemory == 0)
    {
        //printf("Video mode is required for this program.\n");
        return 1;
    }
    VideoX = b_system_config(21, 0);
    VideoY = b_system_config(22, 0);
    VideoBPP = b_system_config(23, 0);

    clr();



}

How ever if the inline code is moved into main() like in the example below  the program works.

#include "libBareMetal.h"


unsigned long VideoX, VideoY, VideoBPP;
char* VideoMemory;


int main()
{

    unsigned char tchar;

    VideoMemory = (char*)b_system_config(20, 0);
    if (VideoMemory == 0)
    {
        //printf("Video mode is required for this program.\n");
        return 1;
    }
    VideoX = b_system_config(21, 0);
    VideoY = b_system_config(22, 0);
    VideoBPP = b_system_config(23, 0);

    asm(".intel_syntax noprefix                      \n"
               "push      rdi                        \n"
               "push      rsi                        \n"
               "push      rcx                        \n"

               "mov       rdi, VideoMemory           \n"  //pointer screen 8 byte
               "mov       rsi, 0x0000FF00             \n" //        color 4 byte
               "mov       rcx,230400                 \n"

               "repeat:                              \n"

               "mov      [rdi],esi                   \n"
               "add      rdi,3                       \n"
               "loop     repeat                      \n"

               "pop       rcx                        \n"
               "pop       rsi                        \n"
               "pop       rdi                        \n"
              );
}

My compile options for gcc are from appc.sh script:

gcc -c -m64 -nostdlib -nostartfiles -nodefaultlibs -fomit-frame-pointer -mno-red-zone -o $1.o $1.c

gcc -c -m64 -nostdlib -nostartfiles -nodefaultlibs -fomit-frame-pointer -mno-red-zone -o libBareMetal.o libBareMetal.c

ld -T app.ld -o $1.app $1.o libBareMetal.o I believe that gcc is messing up BareMetal segment registers or stack ..can you please help me on this.I can not figure out what is wrong and crashes BM (and also QEMU reboots).