OSDev.org

I wanted to actually make interrupts in my os while in 32 bit protected mode .
After searching the web I found that Their are two ways to do that :

I could make a switch to real mode , do what i want to do , and return to Protected mode . But i came to know that this was not a recommended way .

The only way that was left was to run a v86 task and create a v86 monitor . But the problem is that I don't have any idea how to make it.
I read the wiki tutorials about v86 but no success.

I am new to Operating System Development and Need some guidance .

I believe the osdev community can help me out with this problem and also the problems in future.

Thanks in Advance ....

pcdever wrote:I wanted to actually make interrupts in my os while in 32 bit protected mode . After searching the web I found that Their are two ways
to do that : I could make a switch to real mode , do what i want to do , and return to Protected mode . But i came to know that this
was not a recommended way

I recommend it.

Hello mikegonta ,

Thanks for answering , could you just provide me with some code or explanation on how to do it.

Returning to real mode:

• Disable maskable interrupts with CLI.
• Remap the master PIC to 0x08 and the slave to 0x70.
• Disable paging.
• Jump to a 16-bit protected mode descriptor (just a GDT descriptor with granularity bit clear).
• Clear bit 0 of CR0.
• Jump to a 16-bit real mode segment.
• Reset segment registers and stack pointer.

Entering v8086 mode:

• Disable maskable interrupt with CLI.
• If you use paging, make sure the pages are mapped as User and Writeable (because v8086 always runs in ring 3)
• Create a stack frame for IRET, (push 16bitSS; push 16bitESP; push 16bitEFLAGS; push 16bitCS; push 16bitEIP).
• Don't use GDT descriptors here; use normal 16-bit segments. Also, set the VM bit in EFLAGS (value 0x20000) if I remember correctly.
• Do an IRET. You're now in v8086 mode.

I personally don't recommend v8086 mode, as most real BIOSes go to protected mode temporarily, and that goes beyond limits of v8086. Anyway you shouldn't depend on the BIOS for anything except video mode switches.

Do you have any Code sample for these two methods , specially for the second one .

Hi,

pcdever wrote:I wanted to actually make interrupts in my os while in 32 bit protected mode.

The BIOS (and UEFI) exist as minimum functionality just to get a real OS started. For a real OS; you need device drivers to handle things like sound, touchscreen, networking, USB (including "hot-plug USB"), etc (none of which are supported by BIOS); then you need decent disk drivers capable of transferring data to/from disk while the CPUs are doing other things.

The problem is that for a real OS to do anything right it need to take control of the hardware; including (eventually, as it gets more capable) remapping the PIC's IRQs (so they don't conflict with exceptions), starting other CPUs, using APICs, disabling ancient "legacy" modes in things like the FPU and USB controllers, etc. This makes it almost impossible for a real OS to use the worthless puss the BIOS provides because the BIOS expects all the hardware to remain in its default/legacy state.

The danger here is that using the BIOS for a few things early during the implementation of an OS prevents you from doing anything right later (because doing anything right breaks existing "working" stuff). You effectively end up trapped in a sick and twisted "1980's mode" where the only possible outcome is a pathetic BIOS extender that has nothing to do with modern OS development.

Ideally; what you want to do is shift all the "firmware dependencies" into early boot code, so that only (e.g.) the boot loader and nothing else depends on the existence of the BIOS (or UEFI, or anything else). Essentially; your boot code would get a memory map, setup a video mode, load whatever is needed for the remainder of boot into RAM, etc; and then start the next part of the OS (e.g. the kernel). Everything after that should be "firmware independent".

For that very early boot code (e.g. for a "BIOS boot loader"), because it runs before the OS has taken control of the hardware it's simpler to switch between real mode and protected/long mode, and there's no reason to bother with the complexity of V86 mode (e.g. the whole "V86 monitor" that emulates various instructions like CLI, HLT, etc).


Cheers,

Brendan

pcdever wrote:could you just provide me with some code or explanation on how to do it.

Read the CPU manual.

For examples of the protected mode basics (and advancics(!)) you may study these: PMode tutorials in C & Asm.

pcdever wrote:I wanted to actually make interrupts in my os while in 32 bit protected mode .

Define "make interrupts" and explain why you think that that requires using either real mode or v86 mode.

Hello onlyonemac ,
Actually my os boots from GRUB , and therefore i don't need to make the switch to protected mode by setting up the gdt and the control registers and all . But this does not mean i skipped the pmode tutorials . But i was reading a few graphics tutorials and wanted to setup a high resolution vesa mode .
I came to know that it could be set only in real mode but i am using GRUB multiboot and my kernel is in pmode . So its obvious that i need to be in real mode . So i could either switch to real mode or create a emualted 8086 ( V86 ) task to this stuff working.

As i had mentioned i have very little knowledge about os develeopment compared to you all so I'll be loving it if any better solutions would be there for my problem.

Let GRUB set the video mode.

GRUB2 and patched versions of GRUB can set a high-resolution video mode for you, according to what you put in your multiboot header. It also works with UEFI. You can't use real or V86 mode to set the video mode with UEFI.

GRUB will set the graphics mode for you, if you configure it properly.

But it only works once, at boot time. If you want to change the graphics mode after that, you'll have to either write your own driver (recommended), write your own v86 virtual machine, or swap to 16-bit real mode, temporarily.

Swapping to real mode is probably the simplest approach, but if you can live with just editing your grub config file and rebooting, you should probably just do that, for now.

How can we do that in GRUB ?
Any tutorials along with the multiboot specification and grub.cfg will be good.

Wel thanks for that , that really solves the problem .

Does anyone has any idea how to create a graphics driver.

Thanks in advance.

It's your OS, so you can create your drivers however works best for you.

But, in general, you just need to decide what "functions" you want all of your devices to have, and define that in an interface, or base class, and then for each device, implement that interface in a way that works for that specific hardware device.

For example, for a graphics device, you'll probably need ClearScreen(Color color) and SetPixel(int x, int y, Color color). For a storage device, you'll need something like ReadBlock(int block, int Address) and WriteBlock(int block, int Address). And so on.

But it's entirely up to you. You can copy the interfaces that Windows or Linux uses, or you can get creative and create your own.

But, I would suggest staring a new thread if you want to switch to a new topic.