Any other reason to have V86?
Any other reason to have V86?
My understanding of V86 mode is allow for 16-bit code execution, such as when you want to allow access to the BIOS. Other than that is there any reason why you would want to support this mode?
It's only purpose is to run 16-bit code, so there are no reasons beyond that.
The cake is a lie | rackbits.com
Do you know of any resources worth check out on the subject? I assume that a lot of this would be done is assembler?
Reflect Desktop Operating System - ' You only remember the name of the OS when it crashes '
Once you have multitasking set up, there really isn't much more to do - simply set the VM bit in EFLAGS for the new task and you're away. All you have to do then is handle GPF exceptions gracefully as per the wiki atricle: Virtual Monitor. If you can enable VME in CR4, you may find that you don't even need much of a virtual mode monitor.
Cheers,
Adam
[/wiki]
Cheers,
Adam
[/wiki]
No, there is no use for it unless you want to support legacy r-mode code for some reason. I can change my video resolution just fine while running without a v86, i just disable ints, drop to r-mode, do interrupt, come back to p-mode and re-enable ints... sure it might be a tad slower, but how often/fast do you really need to call it, and how large is it to implement v86 with properly handling vs. my < 64 byte function call? And, it doesn't even have to be implemented in the kernel, so when i get 'real' drivers for video, it won't even happen anymore, and the kernel doesn't care one way or another. With the v86, you implement it, waste a ton of space, then if you ever make it to the point of implementing a real driver, you haev legacy code in your kernel for no reason (or as a fall-back), but I would rather the legacy code in my fall-back/generic driver than my kernel. I dont' see why so many people are adament on using v86.
I dunno, I use my own bootloader, and my function is about 40bytes, requires no multitasking support, or anything else in the kernel. I load my kernel to a memory location down low, then memory map it to 0xF0000000. What is GRUB saving the lower 1mb for? Also, it doesn't have to be the kernel, like I said, my vesa driver does the dropping to real-mode, so as long as your kernel can allocate memory below 1mb, i don't see the problembluecode wrote:That is not so easy for a kernel that is above 1MB (which is every kernel loaded by grub). Besides that the coded needed for v86 is not as big as you pointed out (if you use vme).Ready4Dis wrote:i just disable ints, drop to r-mode, do interrupt, come back to p-mode and re-enable ints...
. I know it's not that huge, but then your video driver needs to spawn a thread, and do special case IPC to tell that thread what to do (set screen mode + resolution, or whatever you need). Mine doesn't require any special code in my kernel (besides having a 16-bit entry setup so i can drop back into 16-bit pmode before going rmode). I just don't see the point in doing the work to get v86 working just to set a video mode, all that extra code in your kernel. I know it's not that huge of a difference, i just don't see a point in doing it personally.
can you post yuor code? I'm very interested to it.Ready4Dis wrote:I dunno, I use my own bootloader, and my function is about 40bytes, requires no multitasking support, or anything else in the kernel. I load my kernel to a memory location down low, then memory map it to 0xF0000000. What is GRUB saving the lower 1mb for? Also, it doesn't have to be the kernel, like I said, my vesa driver does the dropping to real-mode, so as long as your kernel can allocate memory below 1mb, i don't see the problem
Hi,
In addition, AFAIK nothing guarantees that the video ROM won't enable interrupts, causing IRQs to be delivered while the CPU is in real mode. There's nothing you can do to prevent this from causing your devices to fail, your OS to crash, etc that doesn't make things worse (e.g. you could mask the IRQs to prevent crashes, etc but then you'd miss IRQs completely instead of postponing them). Most video cards probably don't enable interrupts, but unless you test every video card ever made you can't know that all video cards don't enable interrupts.
Of course there are other problems, like being unable to use this method to support multiple video cards. For virtual80x86 you can map each video card's ROM at 0x000C0000 in different virtual address spaces (and build a fake BDA, IVT, etc for them).
It's a bit like using paint to make your naked body look like it's fully clothed - it works while you're lucky (but let's hope it doesn't rain, and don't ask which pocket the car keys are in)...
Cheers,
Brendan
In general, interrupts should only be disabled for a few instructions. Switching video modes takes ages and you'll have extremely high interrupt latency because interrupts are disabled for far too long. This can cause some major problems for some devices - packets lost for high speed ethernet, missed timer IRQs, missed keypresses causing the keyboard to lock up, etc.Ready4Dis wrote:i just disable ints, drop to r-mode, do interrupt, come back to p-mode and re-enable ints...
In addition, AFAIK nothing guarantees that the video ROM won't enable interrupts, causing IRQs to be delivered while the CPU is in real mode. There's nothing you can do to prevent this from causing your devices to fail, your OS to crash, etc that doesn't make things worse (e.g. you could mask the IRQs to prevent crashes, etc but then you'd miss IRQs completely instead of postponing them). Most video cards probably don't enable interrupts, but unless you test every video card ever made you can't know that all video cards don't enable interrupts.
Of course there are other problems, like being unable to use this method to support multiple video cards. For virtual80x86 you can map each video card's ROM at 0x000C0000 in different virtual address spaces (and build a fake BDA, IVT, etc for them).
It's a bit like using paint to make your naked body look like it's fully clothed - it works while you're lucky (but let's hope it doesn't rain, and don't ask which pocket the car keys are in)...
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.
I would say, going to and from realmode for mode changing is as safe as any other method.
I use this method and have never had or had any reports of problems.
If you set the OS in a state, that it would be in, if you where going to realmode or Pmode to stay, then you should have no problems.
This has some good info
http://www.tenberry.com/dpmi/02.html#0101
I use this method and have never had or had any reports of problems.
If you set the OS in a state, that it would be in, if you where going to realmode or Pmode to stay, then you should have no problems.
This has some good info
http://www.tenberry.com/dpmi/02.html#0101