OSDev.org

Hello!

I was trying to enter sVGA mode 0x0103 (800x600, 256 colors, graphical) and it all went well. Using mode 0x13 in protected mode, so I knew all about changing memory planes.

But when I was in mode 0x0103, I discovered (through our lovely IRC channel) that planes cannot be used as in mode 103h. I must either drop out of protected mode and ask the BIOS to change plane, OR use the linear frame buffer.

To know the address of the LFB, one shall issue int 0x10 with ax=0x4f01 and cx=mode. And so I do.

When the interrupt is issued, the screen displays some weird shapes of different colors, which I would say is outside of the normal 16-bit color palette. And then the system hangs.
The code is running on a physical machine.

Does anyone have a clue?

Edit: After further inspection it appears that the system does in fact not hang after executing the interrupt. However it seems like it changes to some strange video mode. For some reason the video mode cannot be changed after the interrupt. I can tell that the computer is not hanging, since scroll/num/caps lock toggles the keyboard LED's.

First, if you're talking about color/bit planes in the EGA/VGA sense, there isn't one in 8+ bits per pixel VESA modes (however, in 8bpp modes there's still a palette). You're probably talking (or should be talking) about banks or windows, small "holes", through which you can access all of the video memory by moving them where needed.

Second, the VBE 3.0 document says that the screen may not be cleared and suggests explicitly clearing it before use.

Yes. 'Banks' is the right term indeed. I am very interested in two possible solutions:
1: Getting the BIOS function to work, so I can detect where in memory the LFB is, or
2: Finding a way of manually selecting banks.

The problem is that the BIOS function int 10h/AX=4f01h/CX=mode should NOT set the video mode, which it in my case does.

And the same code does work in a VM?

Hello.

danielbj wrote:1: Getting the BIOS function to work, so I can detect where in memory the LFB is

Address of the LFB = Mode-info-buffer+28h

Mode-info-buffer DB 256 dup (?)

Dirk

In case anyone cares, long time ago I implemented a simulated LFB on top of banking. I used virtual 8086 mode and page translation for the banks to switch transparently to the user.
lfbemu22.zip (I hope it's still accessible worldwide despite the various international issues around Russia)
The demo (LFBEMU.COM) ran in plain DOS and it still runs in DOSBox. I haven't tried other VMs.

freecrac wrote:Hello.

danielbj wrote:1: Getting the BIOS function to work, so I can detect where in memory the LFB is

Address of the LFB = Mode-info-buffer+28h

Mode-info-buffer DB 256 dup (?)

Dirk

I know, thanks. As stated previously, this is not the problem.
The problem is that getting the mode info also sets the video mode for some reason.

Combuster wrote:And the same code does work in a VM?

Will test that for the next few hours

I have now tried in Bochs. SVGA did not work at all.

Back on the real hardware I went back to mode 13h, to which I got some functions to print binary values on screen. I started poking around with VESA BIOS function 4f00h and 4f01h. Fonction 4f00h reports VESA v. 2.0, and it tells me there is a list of available VESA-video-modes at address 0xD000494D. The first entry in this list is 0xffff=end of list. In other words: The machine does have VESA with 0 available modes.

If I look up the computer (Compaq Armada 1592DT), the specs tells me SVGA is supported at 800*600, 24 bpp. VGA, XGA and SXGA is also supported.

Does this mean that whoever made the graphics was nice enough to include VESA but lazy enough to implement it?
Ultimately, does this mean that I'll have to wite my own SVGA-driver from the bottom?

danielbj wrote:0xD000494D

No, that's 0xD000:0x494D, which is 0x000D494D. You should get something a little more sensible if you look at the correct address.

Octocontrabass wrote:

danielbj wrote:0xD000494D

No, that's 0xD000:0x494D, which is 0x000D494D. You should get something a little more sensible if you look at the correct address.

Indeed! Now I get all sorts of video modes! However, I'm currently struggling with some unexpected double faulting (most probably not related to this problem...), so I'll have to suspend the investigation of this subject until that is taken care of.

When that's done, my plan iss to print all available modes, just to see if mode 103h is on the list. If not, I might know why stuff didn't work before

danielbj wrote:However, I'm currently struggling with some unexpected double faulting (most probably not related to this problem...) ...

If you're in protected mode with interrupts enabled, make sure you've remapped the master PIC's offset from 8 to another value. See this Wiki article.

I got the double fault under control now. Turns out I've made some non-terminating recursion in the kernel, so the stack would grow beyond its limits.

So: Back to VESA, VBE and sVGA!

I have now successfully read the list of available modes from int 10h, ax=4f00h, and printed the information to the screen. The following is a list of supported video modes: As we can see mode 103h is on the list. But still when i ask BIOS function int 10h, ax=4f01h, cx=0103h, ES:DI=buffer_pointer about that mode's information, it returns that the physical address of the linear frame buffer is null. Does this mean that the LFB is simply not supported?

You need to sit bit 14 in the mode number to specify that you want to use a linear framebuffer (eg. 0x4103).

Kazinsal wrote:You need to sit bit 14 in the mode number to specify that you want to use a linear framebuffer (eg. 0x4103).

Of course! Forgot all about that.

Also just discovered that i only read a WORD when getting the LFB address. I use the movzx instruction, because of system-specific reasons. I just discovered that, and corrected to a dword read, and now it's giving me an LFB address of 0x40000000, which seems more sane to me.

The weird screen mode selection when doing int 10, ax=4f01, is also fixed. I rewrote most of the mode selection code, and thereby might have done something right for once.

I will now test if I can set the video mode, and set some pixels here and there on the screen.
I have a good feeling about this!


UPDATE!
It all works now. Writing to the Linear Frame Buffer works like a charm!
Thanks guys!