OSDev.org

Hi. I'm thinking. When i entered to protected mode, can i use real mode interrupts with IDT?

hi,

it's only in virtual-8086-mode possible. This is a sub-mode of the i386+ protected-mode. Google, osfaq or intel manuals will help you more....

But, without int 0x10 interrupts, how can i use SVGA? Is it possible with ports?

Tolga wrote: But, without int 0x10 interrupts, how can i use SVGA? Is it possible with ports?

Welcome to the world of osdev
As I said it is possible, you have to switch to virtual-8086-mode temporarily and execute the interrupt there, then switch back. This implies having a virtual monitor or using the "virtual mode extensions" (supported by pentium and above).
Another thing you can use to access your graphics card is VBE (VESA BIOS Extensions), which offer a protected-mode interface (which is actually rarely used).
You can also use direct port I/O, but you won't find any info about newer cards (like ATI's Radeon and NVidia's Geforce), because this is kept secret by most companies. So forget about this option.

Generally, which is useful?

Interrupt redirection map in virtual 8086 mode may be useful but I know only little about it

I also think that virtual-8086-mode (which is an emulation of real-mode within protected-mode) with Virtual Mode Extension (=VME) enabled is the best approach. To enable these vme you have to set one bit in the cr4 register (look it up in the intel manuals).
Then you need a piece of 16bit code which executes the int0x10 with the right parameters. In your protected-mode kernel you then have to create a task-state-segment with an interrupt-redirection-bitmap. the int-redir-bmap has a size of 258/8 and contains one bit for every interrupt. If this bit is set an software interrupt is redirected to protected-mode. If not the software interrupt gets executed in virtual-8086-mode (<- which is what you want for int0x10). The And you need a stack frame which jumps to the 16bit code and enables v8086mode on execution of "iret". That implies an eflags register with the virtual-mode-enable bit set. Then execute iret and have fun.

Heres some info for vga mode switching without BIOS ints
http://bos.asmhackers.net/docs/vga_without_bios/
Also you can switch to realmode and back for mode switching, that how i do it, in my OS.

bluecode wrote:

Tolga wrote: But, without int 0x10 interrupts, how can i use SVGA? Is it possible with ports?

Welcome to the world of osdev
As I said it is possible, you have to switch to virtual-8086-mode temporarily and execute the interrupt there, then switch back. This implies having a virtual monitor or using the "virtual mode extensions" (supported by pentium and above).

http://www.osdev.org/osfaq2/index.php/G ... beModeInfo,
this
and http://www.osdev.org/osfaq2/index.php/VirtualMonitor can help here ...

Another thing you can use to access your graphics card is VBE (VESA BIOS Extensions), which offer a protected-mode interface (which is actually rarely used).

yes, for they require 16bits pmode and that they're non-uniformly supported (and many implementations don't work properly).

You can also use direct port I/O, but you won't find any info about newer cards (like ATI's Radeon and NVidia's Geforce), because this is kept secret by most companies. So forget about this option.

Hmm. don't forget it too fast anyway. some information is available like e.g. mode switching or bitblt'ing for nvidia cards ... what's still heavy secret is 3D
stuff.

see the FAQ for details.

Pype, when you say "some information is available like e.g. mode switching or bitblt'ing for nvidia cards" do you mean one can get that information from those opensource drivers or is this actual information nVidia has available somewhere?

sorry, but i must comment:

You can also use direct port I/O, but you won't find any info about newer cards (like ATI's Radeon and NVidia's Geforce), because this is kept secret by most companies. So forget about this option.

everyone keeps forgetting the big boys:
pop quiz:

what is the largest video-controller maker (controling almost 50% of the total market -- and almost 100% of its specific specialty niche)?






answer:
Intel!! (not AMD or nVidia)

and intel gives all its information away freely and openly -- not even a contract in site on the download pages!

JAAman wrote: everyone keeps forgetting the big boys:
pop quiz:

what is the largest video-controller maker (controling almost 50% of the total market -- and almost 100% of its specific specialty niche)?






answer:
Intel!! (not AMD or nVidia)

and intel gives all its information away freely and openly -- not even a contract in site on the download pages!

In which part of the market and world? All I see around me in computers of friends and so on are ATI or Nvidia cards.

I guess nearly all business computers in the US have Intel cards etc, plus all the servers. Of the computers I work with, two have SiS cards, one ATI (home), one ATI (work), one ATI (old work), sister has an ati as well and my mom has an nvidia. Where does Intel come?

I'm guessing Intel pulled that statistic out by virtue of half the PCs having onboard intel graphics, even though very few people actually use that because it tends to suck. The people around me use nVidia and ATI cards in preference to any onboard graphics.

Rob wrote: Pype, when you say "some information is available like e.g. mode switching or bitblt'ing for nvidia cards" do you mean one can get that information from those opensource drivers or is this actual information nVidia has available somewhere?

Those are mainly information available through sources of drivers. i don't remember i've seen something like "programming guide for nVidia chips" so far ... not in the sense we expect for a "programming guide", at least.

And indeed Intel is maybe the only chipmaker that provides more complete development information ... But still the step of V86-based video driver cannot be avoided because you'll need to support *all* graphic cards: not only intels. card-specific drivers will mainly provide accelerants or enable higher resolutions, etc.

I'm tempted to dig through as much driver source as I can find (only those with appropriate licenses obviously) and create manuals for the various cards with information such as port locations and functions, etc. It's probably too much work for one person, but I may make a start next time I'm bored.