Switching to Real Mode from Protected Mode

[Daedalus]

Hi all,
I've scoured the internet for the past 2 weeks and tried many things, but I'm afraid my grasp on protected mode is limited.

I've started out with an example OS that boots from Grub into protected mode and runs from there. Grub is what puts it into protected mode, so I can't do anything in real mode during the boot.

What I want to do is use a software interrupt to move into VGA mode 13 or 12, I'm not too worried about color depth, so VESA can wait.

Mode 13 would be easiest of course. But the actual move to real mode is where I'm stuck.
I have a terminal program running in the OS that, when the user types 'gfxdemo' calls the assembly (NASM source) function setmode13, which should:
Move to real mode
Mov ax, 13h
Int 10
Return to protected mode
Return to where it was called from

Looking over the 'net I found many examples of switching to them from protected mode, but none of these has been able to even get me into graphics mode.

I know I'm missing something here, but I hope someone can help.

[bubach]

You can find example code in both fasm & nasm format that does that here: http://free.pages.at/cosmo86/bubach/

It's discussed in this thread: http://www.osdcom.info/e107_plugins/for ... php?177.10

[Daedalus]

Thank you very much for your reply!

I've tried your examples, but because my OS is using a COFF format, I get the error from NASM: COFF Format does not support non-32bit relocations.

However, it did compile to ELF format, so I decided to compile it on my debian linux machine. However, when linking, I get a 'warning' about relocations being truncated, and ld decides its an error and quits :\

I'm beginning to think I should code it to boot in DOS, that way I can init the video first, then go into protected mode. However, theres the DOS overhead, and the fact that I don't want to be reliant on another OS.

Any further help is greatly appreciated. Perhaps I should switch compile formats?

[bubach]

I don't know if it's even possible to do in coff or elf format, isn't they strictly 32-bit or sth? Anyway, I thinks it would be far easier to compile it to a flat binary. Does GRUB support that? If not they you can get some free fat12 bootsector that loads it for you, like John S. Fine's. The 16-bit code must be below 0xFFFF:0xFFFF, so if you load your OS to for example 1mb (0xFFFF:0x0010) you have about 63kb to put 16-bit code at..

[JAAman]

if you want access to the RMode ints its easier to just write your own boot loader (and you can change video modes before switching to PMode)

whats this about launching from dos? don't do it! it won't give you anything you can't do from your own boot sector (if you properly code it to FAT12 specifications)

the only thing about that is it will be MUCH easier to load a binary image than to load a object format like coff or elf (besides I don't think you CAN until you switch to 32bit mode because object formats must be either entirely 16bit or 32bit and cannot change in the middle

the difficulty of writing your own bootsector/seconds stage loader is way overrated just don't try doing it all in the boot sector

use the boot sector to parse the rootDIR and FAT, then load your second stage loader from a file
(of coures if your second stage is exactly 4k you could name it io.sys and copy it to any disk formated by any MS OS and it will automatically load)

[carbonBased]

vm86 mode is by far the most ideal solution here.

Changing the resolution before switching into pmode is plausable, but if you ever want to change the resolution later on, you'll either need to switch to real mode, or utilize vm86 mode (or which protected mode video drivers).

vm86 is faster, and applicable to much more things then just changing graphics modes. In my opinion, it's a must have for any OS that is going to using any form of bios functionality.

Cheers,
Jeff

[JAAman]

actually if all you want are the standard VGA modes (including, sometimes, the more advanced ones:640x480x256 for ex)
you can easily do this in PMode: just use the standard ports: don't believe those who tell you that some newer cards don't support the standard VGA ports -- any video card that does't support the standard ports will be unbootable useing win9x and winXP (and without using special configurations, win3 also)

the ports aren't that hard to use and are very well documented

[carbonBased]

Absolutely. VGA can be done entirely in pmode. Although, 640x480x256 isn't standard VGA. The best you can expect (to always work) is 640x480x16 (highest res) and 320x200x256 (most colours).

Although, as suggested, with some tweaking, non-standard modes can often be acheived (ala 'mode-x' as Michael Abrash describes it).

Regardless, though, I'd still suggest implementing a vm86 module in your kernel.

--Jeff

[JAAman]

however *MOST* video cards can use the standard methods to access 640x480x256 (which is technicaly nonstandard) in the same way

even win3.1 came with a 'default' 640x480x256 driver that would use the standard VGA ports and would work on *most* video cards (but no, not all)

[Daedalus]

Thanks for the replies everyone!

I did manage to implement VGA modes 12 and 13 using ports, and they'll do until I can implement a VM86.

Speaking of which, all the VM86's I see seem to use a lot of boot code. Currently, I'm using a bootloader than boots from dos (FreeDOS to be precise) so it can load kernel applications before booting the OS.

The booter itself moves into protected mode, and I have the source for this so I could modify it if need be.
My question is, what parts of a VM86 need to run before/just after the move to protected mode?

Thanks again for your replies, much appreciated!

[carbonBased]

vm86 is special mode whereby the processor, while in protected mode, acts as if it's in real mode (through various forms of emulation, so-to-speak). Setting up and using vm86 is done entirely in pmode (and can be done at any time), so I'm not quite sure I understand your question. What 'boot code' do these vm86 modules use?

About the only thing you'll want to be aware of, in the booting process, is you want to save off a copy of the real mode idt (that is, if you overwrite it, like I do).

Hope that helps,
Jeff