How can i switch from Protected Mode to V8086 mode?

[Ycep]

Nuno, you need interrupt descriptor table and programmable interrupt controller implementation to make your OS work.
I have to tell you that, Windows, Unix and many else OSes did never used V8086 for such thing.
I remember that once when I had Windows 98 couple months ago, File Explorer tried to read floppy drive (don't forget that it reads through V8086 mode) and freezed the whole operating system.

Isn't V8086 little bit too advanced for newbies? I mean you need to emulate some instructions yourself, it works only in user-mode, etc, etc.

It would be easier to do it through interrupts. Come on, it's simple, but adding more features takes long.

[NunoLava1998]

Nuno, you need interrupt descriptor table and programmable interrupt controller implementation to make your OS work.
I have to tell you that, Windows, Unix and many else OSes did never used V8086 for such thing.
I remember that once when I had Windows 98 couple months ago, File Explorer tried to read floppy drive (don't forget that it reads through V8086 mode) and freezed the whole operating system.

Isn't V8086 little bit too advanced for newbies? I mean you need to emulate some instructions yourself, it works only in user-mode, etc, etc.

It would be easier to do it through interrupts. Come on, it's simple, but adding more features takes long.

It's only for a keyboard driver, since i will use bare interrupts. It returns to protected mode right after doing int $0x16. However, i later learned a 0x16 in protected mode is probably gonna work just fine.

[glauxosdever]

Hi,

However, i later learned a 0x16 in protected mode is probably gonna work just fine.

There are two main reasons that will prevent it from working.

For first, BIOS code is in 16-bit real mode. Your code is in 32-bit protected mode. So, if you simply invoke a BIOS interrupt from protected mode, how will the CPU automagically know how to switch between the two different modes?

For second, in protected mode interrupts 0x00 to 0x1F are reserved for protected mode exceptions. So instead of the BIOS interrupt handler, one (reserved) protected mode extension will be executed instead. Unless, of course, you ignore the reserved exception vectors and setup an IDT that points to the BIOS functions, which is broken (for example a SIMD floating-point exception will result in invocation of disk routines).

--------

But to be fair, relying on BIOS for most things is one of the worst things you can do during OS development. But let me quote Brendan on this since he has explained it well in another topic:

[The] disk IO the BIOS provides is unusable (massive performance problems), the keyboard support is completely broken (no IPC/events system, no keyboard layouts), the mouse interface is worthless (often it isn't supported/doesn't work, and when it does work there's no IPC/events system), the video support is also barely usable (no GPU or 3D acceleration, no support for multiple video cards/monitors, etc), the support for serial ports is unusable (you will lose data), there is no support for networking devices at all, there is no support for modern sound at all, there is no support for device insertion/removal (so support for things like USB devices is a joke), etc.

What it does do is make it extremely difficult (and/or impossible) to do anything properly; partly because the BIOS expects hardware to remain in a certain default state (preventing you from doing anything useful with IO APICs, MSI, PCI configuration space, etc); and partly because of physical address space restrictions (e.g. not being able to touch anything outside the first 640 KiB of the physical address space, including things like APICs and HPET, including all memory mapped IO areas for PCI devices, including the BIOSs own ACPI and SMBIOS tables, etc).

But what should I expect from someone that doesn't make the smallest effort to learn some C and/or to try to recognise and fix compiler warnings/errors?


Regards,
glauxosdever

[NunoLava1998]

Hi,

However, i later learned a 0x16 in protected mode is probably gonna work just fine.

There are two main reasons that will prevent it from working.

For first, BIOS code is in 16-bit real mode. Your code is in 32-bit protected mode. So, if you simply invoke a BIOS interrupt from protected mode, how will the CPU automagically know how to switch between the two different modes?

For second, in protected mode interrupts 0x00 to 0x1F are reserved for protected mode exceptions. So instead of the BIOS interrupt handler, one (reserved) protected mode extension will be executed instead. Unless, of course, you ignore the reserved exception vectors and setup an IDT that points to the BIOS functions, which is broken (for example a SIMD floating-point exception will result in invocation of disk routines).

--------

But to be fair, relying on BIOS for most things is one of the worst things you can do during OS development. But let me quote Brendan on this since he has explained it well in another topic:

[The] disk IO the BIOS provides is unusable (massive performance problems), the keyboard support is completely broken (no IPC/events system, no keyboard layouts), the mouse interface is worthless (often it isn't supported/doesn't work, and when it does work there's no IPC/events system), the video support is also barely usable (no GPU or 3D acceleration, no support for multiple video cards/monitors, etc), the support for serial ports is unusable (you will lose data), there is no support for networking devices at all, there is no support for modern sound at all, there is no support for device insertion/removal (so support for things like USB devices is a joke), etc.

What it does do is make it extremely difficult (and/or impossible) to do anything properly; partly because the BIOS expects hardware to remain in a certain default state (preventing you from doing anything useful with IO APICs, MSI, PCI configuration space, etc); and partly because of physical address space restrictions (e.g. not being able to touch anything outside the first 640 KiB of the physical address space, including things like APICs and HPET, including all memory mapped IO areas for PCI devices, including the BIOSs own ACPI and SMBIOS tables, etc).

But what should I expect from someone that doesn't make the smallest effort to learn some C and/or to try to recognise and fix compiler warnings/errors?


Regards,
glauxosdever

"But what should I expect from someone that doesn't make the smallest effort to learn some C and/or to try to recognise and fix compiler warnings/errors?"
Waiting some time.
I also do try to fix errors, i just ask here as last resort when there is absolutely nothing that i can find on the internet that works for me.
I'll try the polling form, which rarely works for me (tried one time. overwrote the IDT and printed the character 0x60. thanks...)

[glauxosdever]

Hi,


As pointed out numerous times already, you should wait with OS development until you have gained some more programming experience. Required Knowledge applies.

I'm sorry if I insulted you with my previous post, it wasn't really my intention, but honestly it's the first impression people get when they see your posts. Are you sure this is the most appropriate forum for asking basic programming questions? I'd rather doubt so.


Regards,
glauxosdever

[rdos]

I am making a getkey(); function. For this, i need interrupts, which is not available in Protected mode. I am looking to switch to the only and most real-mode and protected-mode compatible mode: V8086. I am currently in C and making my own Meaty Skeleton.

How can i do this?
Can i use

Code: Select all

__asm__ volatile

?

In order to even use V8086 mode, you first need interrupts in protected mode.

[Kevin]

It's only for a keyboard driver, since i will use bare interrupts. It returns to protected mode right after doing int $0x16. However, i later learned a 0x16 in protected mode is probably gonna work just fine.

Just forget about int 0x16. Making it work in VM86 is hard. Just write the keyboard driver yourself (using ports 0x60 and 0x64), it's much easier.

[osdever]

It's only for a keyboard driver, since i will use bare interrupts. It returns to protected mode right after doing int $0x16. However, i later learned a 0x16 in protected mode is probably gonna work just fine.

Just forget about int 0x16. Making it work in VM86 is hard. Just write the keyboard driver yourself (using ports 0x60 and 0x64), it's much easier.

+1

Nuno, you can use U365 code for anything, but just stop asking these questions. [url]gitlab.com/bps-projs/U365/tree/testing[/url]. Download and do whatever you want.

[NunoLava1998]

Hi,


As pointed out numerous times already, you should wait with OS development until you have gained some more programming experience. Required Knowledge applies.

I'm sorry if I insulted you with my previous post, it wasn't really my intention, but honestly it's the first impression people get when they see your posts. Are you sure this is the most appropriate forum for asking basic programming questions? I'd rather doubt so.


Regards,
glauxosdever

On the Required Knowledge:

• 1. Yes
  2. Yes
  3. Yes.
  4. Yes
  5. Quite a few useless ones, probably an Okay on here. Improves my score a bit.
  6. Okay
  7. Yep, i got a lot of knowledge about terminals.
  8. Between yes and no. I do search sometimes.
  9. I should know how to use these.
  10. I know a bit of ELF and nothing else. Should learn.
  11. Of course, it's x86.
  12. Yes.

[NunoLava1998]

It's only for a keyboard driver, since i will use bare interrupts. It returns to protected mode right after doing int $0x16. However, i later learned a 0x16 in protected mode is probably gonna work just fine.

Just forget about int 0x16. Making it work in VM86 is hard. Just write the keyboard driver yourself (using ports 0x60 and 0x64), it's much easier.

+1

Nuno, you can use U365 code for anything, but just stop asking these questions. [url]gitlab.com/bps-projs/U365/tree/testing[/url]. Download and do whatever you want.

Okay.
I'll also include the LICENSE file in a comment, which should be:

Code: Select all

/*Copyright 2016 BPS Dev Team
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.*/

[NunoLava1998]

For anyone still interested in this topic:
I've already switched to polling (getting from 0x60) method.