OSDev.org

hi friends,

I have run into trouble again. I have wrote a virtual 8086 monitor and have tried a few bios calls from my pmode os. But now when I tried to set SVGA modes - The mode does change(well my monitor goes black && VMware resizes its display area according to the mode).

But that is all I get. After that I cann't get anything on the screen (that also means I can't debug using my os routines).

This is what I have done:

1) Getting ModeInfo for SVGA mode 0x114 (800*600 res bits/pixel = 16)
input:
------
AX: 0x4F01
BX: 0x114
ES: 0x9000
DI: 0x1000
Thus ES:DI = 0x9000<<4|0x1000 = 0x91000

Output:
-------
AX:0x004F //That means SVGA success
ES:DI contains modeInfo and I get the xRes = 800 & yRes = 600 & bpp = 8 & PhyBasePtr = 0xF5000000 (This address has to be mapped into memory by paging - I have done that too)

2)I try setting the mode: Ofcourse the screen does change
input
-----
AX: 0x4F02
BX: 0xC114 //This is mode | linear fram buffer(14bit)  | Don't clean mem(15bit)
output:
------
screen changes to that mode (800 * 600)

3)I think this gets executed next - but only GOD knows
input:
-------
AX: 0x4F06
BX: 800 (bytes per line)

4)This is next
input:
-------
AX: 0x4F07
BX: 0
CX: 0

I have tried this for two days and I cann't get it to work. Do I have to do something else ???

Please help.

rgds
Gandalf

Your calls to 0x4F06 and 0x4F07 are rarely ever needed.  I've never used them, anyway.  I would try commenting them out to see what kind of a result you get.

Also, you're using 0x4F06 incorrectly.  There are two ways to set the line width (bl = 0, or 2).  If you're using bl = 0, then set cx to the width in pixels (ie, 800).  If you're using bl = 2, then set cx to the width in bytes (ie, 1600).

What happens when you poke random data into the LFB?  Is anything displayed?  What about at 0xA0000?

Cheers,
Jeff

hi ,

I have tried doing without 0x4F06 and 0x4F07 (Still the screen is black). Also I have tried to set the LFB(which is 0xF5000000 in VMWare & 0xD0000000 in my real system-I have a SIS 630 card) values to deep green (0x001F - for each pixel).

But even after mapping for the pg directory entries and also tried dereferencing that pointer and I get the same values (0x1f series).

The closest I have got is a green strip on the VMware console(but that was in Window mode(bit 14)). So it was probably the first bank and I had also dumped the 0xA0000 location with green values.

Anything else to be done ?

rgds
Gandalf

hi,

I have found out the problem (I tried remapping the PhyBasePtr to an internal buffer using my pg dir entries). Now I have done 1-to-1 mapping for the modeinfo.PhyBasePtr.

The good news is that this makes VMware to run my Graphical frontend. But the bad news is my system still just goes blank after mode switching.

Also I have set my svga mode from virtual86 and I have initialized paging only after setting up the svga mode. Should I do paging first and then set the mode ?  But when I tried doing that - virtual86 doesn't work - Does that mean I have to have the pg directories within 1Mb ?

Any idea ?

rgds
Gandalf

I have similar problem while using switch in VM86 mode under Virtual PC.
I can't get LFB working (writes at 0xa0000 work, but I don't want to use bank switch crap). I tried it on real PC with GF2MX and it worked. I don't do 1-to-1 mapping, but dynamically allocate space for buffer. When I'm setting video mode in real mode, remapped LFB works.

hi,

Jarek Pelczar does that mean that I will be able to get vbe to work when invoked from real mode ? (I am thinking of moving vbe mode setting to boot loader).

By the way I tried GRUB's testvbe function and it works on my PC but when I read the GRUB code - it just does a (char *) typecasting of modeinfo.PhyBasePtr and then writes to the location.

rgds
Gandalf

The problem with setting the video mode in your boot loader, though, is that you can't change the mode once you've entered your kernel.  It's entirely feasable that the user will want to change video modes, right?

Ideally, I would imagine it would make more sense to track down the bug, and implement mode switching in your kernel.  Unfortunately, I'm at a loss for things to try... sorry I can't be of help, here, but I just thought I'd pass along that suggestions.

Cheers,
Jeff

Hi
Y not swich it to unreal mode, swich modes and back to pmode. I have read this is better ,if you just want to swich modes.
I have vesa2 in my OS,I do the seting up in real mode.At the moment if you set a mode ,you can not change it in pmode ,but i will do the pmode to real mode to pmode ,when i have time.
Try here for example: http://www.v2os.cx/
get the old source eg: 0.64.2b [ source]

ASHLEY4.

That's certainly an option, however it's slower then vm86 tasks, and causes all protection mechanisms to be dropped, as well as other pmode features such as the paging and tasking mechanisms.

It certainly isn't that big of a deal when simply switching modes, but I'm rather curious as to why it's not working in a vm86 task.  It's definitly possible.  Hopefully, when I get some more time for OSDev, myself, I can look into it as well.

Cheers,
Jeff

Hi
That's right, but you just need to do it once or twice ,so it ok, if you had to call it once a sceond then its a no no!!.
My OS is for pmode games ,like the Xbox Os, so it runs in ring 0,no multi-tasking(has multi_thraeding),no paging etc.
So its not such a problem .

ASHLEY4.

hi friends,

After weeks of frustration over vbe mode setting problem using v86 mode, today we made it work.

We hacked through the grub source code and then added the mode setting code there and now our OS boots as a GUI OS. I know it will not allow mode changing right now (But in due course we are thinking of using our v86 to do switching).

Thanks for your help.

rgds
Gandalf