Writing SVGA Driver

[Candy]

Now, if i want to use 1600x1200 32 Bit color, it uses 7 MB. Is this true?

Yes.

[Tolga]

Can i change this address? (Linear Buffer Address) Else, i must use which returns ModeInfoBlock.

[Candy]

Can i change this address? (Linear Buffer Address) Else, i must use which returns ModeInfoBlock.

AFAIK, no, at least not through a method I've used before. It should be a free linear address though (note: not virtual), so you can map it wherever you want it to appear. In case of a non-paged kernel, you must use the given address, optionally with a segment offset.

[Brendan]

Hi,

Can i change this address? (Linear Buffer Address) Else, i must use which returns ModeInfoBlock.

AFAIK for ISA and VLB video cards there's card specific registers for changing the LFB physical address. For PCI cards there's BARs in the card's PCI configuration space instead (and possibly also some card specific alternatives for compatibility with ISA cards that use the same video chipset). For AGP I'm not too sure if you need to mess with AGP to PCI bridge or if it's the same as PCI...

In any case, you may also want to fiddle with the CPUs MTRRs to make sure the physical address range used by the card uses the correct/best caching method. This shouldn't be much of a problem though - most BIOSs leave the MTRRs set to "non-cacheable" for everything that isn't cacheable RAM and assume that the OS will setup the caching for the LFB (regardless of whether it's been relocated or not), according to what gives the best performance for the CPU/OS/driver/device.


Cheers,

Brendan

[Candy]

Can i change this address? (Linear Buffer Address) Else, i must use which returns ModeInfoBlock.

AFAIK for ISA and VLB video cards there's card specific registers for changing the LFB physical address. For PCI cards there's BARs in the card's PCI configuration space instead (and possibly also some card specific alternatives for compatibility with ISA cards that use the same video chipset). For AGP I'm not too sure if you need to mess with AGP to PCI bridge or if it's the same as PCI...

AGP is a dedicated PCI channel afaik. So, I would guess it'd be changing the BARs on the device and then changing the bridge forwarding addresses.

[distantvoices]

IIRC AGP is a dedicated PCI device directly connected to the broader system bus (to which RAM is also connected to) via north bridge.

North Bridge connects to south bridge (where all the other pci devices are sitting) via a narrower bus than the one the cpu shares with the north bridge.

@Tolga: Speed is something I for one don't consider too important in case of mode switching in VBE. Just think: how often do you switch modes? One time? Two times? In my OS, the mode is set via init, by reading a settings file. Honestly, in this case speed is not that important.

[Tolga]

Hmm. Must i write a multitasking kernel to turn the pmode from v86? Another question, when i entered v86, it uses which interrupts? Is system's interrupts(real mode) or system automatically copyies interrupts to v86 memory from ROM?

[bluecode]

Hmm. Must i write a multitasking kernel to turn the pmode from v86?

I'm not sure if it is possible without a tss, but I'm using one. You also need to keep in mind, that you need a seperate routine to switch to a virtual-8086-task, because the stack layout (after an interrupt) is quite different.

Another question, when i entered v86, it uses which interrupts? Is system's interrupts(real mode) or system automatically copyies interrupts to v86 memory from ROM?

All IRQ's & cpu exceptions go to your normal Interrupt handlers in protected-mode. When a v8086-task wants to execute a software interrupt, the cpu throws a general protection fault. So you have to handle e.f. the "int" instruction yourself. See the faq (virtual monitor & what is v8086mode?) for more details.
There are also the virtual-mode-extensions (Pentium+), which allow you to control whether an interrupt is handled in realmode or in pmode without emulating these instructions. Look into the intel manual 3 for more details.

[distantvoices]

@bluecode: No, you don't need a separate routine to switch to a vm86 task. The cpu does that for you.

What you need, is a specialized form of task creation routine for the stack frame for the vm86 context has a different layout to the one of the protected mode context - so the cpu has the proper data at hands when switching to vm86 mode. This works almost seamlessly as soon as you've got it working. Just take your usual isr stubs & sorta.

The important stuff allready happens at int, upon an exception and inside iret. (microcode IS nifty)

[bluecode]

Ok, let me put it different ;D : I'm using a seperate routine for vm86 switching, because vm86 is in my OS not part of the normal schduling cycle.