OSDev.org

I'm trying to access VESA LFB, in VMware it seens to be OK, but on physical computer it just restarts, whats wrong?

I'm using int to get ModeInfoBlock and 0x28 dword is that physical LFB address.

Thanks.

implementations differ.

when i was demo coding, some cards LFB worked great, other cards (notable Tseng Labs ET6k) had dodgy LFB implementations.

one of my newer GFX agp cards, didnt even have Vesa.. you had to load a TSR to get vesa implemented... (what good is that for an OS!!)

Also, don't rely on an LFB being present. You're likely to get a banked framebuffer, which you access via A0000, and which requires you to switch banks to access more than 64KB.

i should add under vesa2 lfb was part of the spec but most cards did a vesa 1.2.5 implementation. som didnt add in the LFB, some did....

which is why some vesa2.0 cards are a bit dodgy.

however! windowing will always work

i have a whole vesa library somewhere from my demo coding stuff... m i should look it up.

df wrote: one of my newer GFX agp cards, didnt even have Vesa.. you had to load a TSR to get vesa implemented... (what good is that for an OS!!)

a recent AGP card without VESA !? what model is it ?

btw, it shouldn't be too hard (considering what we're facing anyway) to make your bootloader or the VM86 supervisor load the TSR "as if it was under DOS" -- provided that it doesn't require the whole MS-DOS interface to be supported ...

I have video card that has VESA 3.0, I have tested Menutos, that works with VESA LFB, and it works, maybe this 4f01 requires mode 0xXXX or linear 0x4XXX to show interrupt on what mode are you requesting physical address???

Hi,

INHO I wouldn't bother trying to get VESA working. Quite a few cheapo video cards these days don't have VESA built into their BIOS.

For instance, I tried MineutOS (I think it was that one) and found out the hard way the computers at work don't have ANY vesa support at all.

And they were P3s with Intel 810/815 (can't remember off hand) built in graphics.

If I ever get to the graphical side of things I'll have to take a good look at the video drivers in Linux and port them.

Now I have got a physical LFB address, but when I'm trying to plot one pixel in LFB memory, nothing hapends, system reacts just to 0xA0000.

I think, maybe it is problem that physical address isn't a linear adress, I'm trying to put pixel in real mode :-\

I don't use paging for now.

Help!

hehe as the Linear Frame Buffer is usually several MB-wide, and is located at the top of the physical address space, it cannot be accessed in realmode. To be able to use it, you must switch to a VESA video mode with the LFB bit set and be in either protected or VM86 mode (assuming an external supervisor will give you the proper page to map it, banks by banks).

So if you're in real mode, banked video is your only option.

If you are *still* in realmode but will move to pmode soon, enable LFB and wait a little bit to start using the video memory

Now, maybe unreal mode could help too. switch to pmode, set up GS = [base : LFB, limit=0xFFFFFFFF - LFB] and then switch back to real mode: you should be able to read/write to the LFB using GS:[offset] -- never tried, though: that's pure speculation from me, but if it works for RAM, why not for VRAM ... worth the check, imho go to baby steps for unreal mode enabling.

Then physical and linear memory differs, if VESA manual says, that PhysLFBmemory is 32bit, then this memory is shown like in segmentation or like linear.

And what differences are between these memory types?

I'm using pmode Pype

Now I have read intel volume 3 about paging and linear translation to physical through paging, but how I can translate without paging?

without paging, physical = segment base + offset ... thus if you have 0-based segments physical == offset (logical address).

Then if I have base sdlector zero, and without paging the physical address==linear address?

Is that right? :-\