v86 mode
v86 mode
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 ....
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 ....
Re: v86 mode
I recommend it.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
Re: v86 mode
Hello mikegonta ,
Thanks for answering , could you just provide me with some code or explanation on how to do it.
Thanks for answering , could you just provide me with some code or explanation on how to do it.
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: v86 mode
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.
- 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.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: v86 mode
Do you have any Code sample for these two methods , specially for the second one .
Re: v86 mode
Hi,
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
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.pcdever wrote:I wanted to actually make interrupts in my os while in 32 bit protected mode.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: v86 mode
Read the CPU manual.pcdever wrote:could you just provide me with some code or explanation on how to do it.
For examples of the protected mode basics (and advancics(!)) you may study these: PMode tutorials in C & Asm.
-
- Member
- Posts: 1146
- Joined: Sat Mar 01, 2014 2:59 pm
Re: v86 mode
Define "make interrupts" and explain why you think that that requires using either real mode or v86 mode.pcdever wrote:I wanted to actually make interrupts in my os while in 32 bit protected mode .
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Re: 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.
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.
-
- Member
- Posts: 5587
- Joined: Mon Mar 25, 2013 7:01 pm
Re: v86 mode
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.
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.
Re: v86 mode
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.
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.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: v86 mode
How can we do that in GRUB ?
Any tutorials along with the multiboot specification and grub.cfg will be good.
Any tutorials along with the multiboot specification and grub.cfg will be good.
Re: v86 mode
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: v86 mode
Wel thanks for that , that really solves the problem .
Does anyone has any idea how to create a graphics driver.
Thanks in advance.
Does anyone has any idea how to create a graphics driver.
Thanks in advance.
Re: v86 mode
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.
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.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott