How to generally enter virtual 8086 mode?

[uruseiyatsura]

But then, you should really use at least PAE these days, anyway, unless you are planning a 386 revival project.

That would be fun but I no longer own a functional 386, not even a functional 486. My first 386EX had a CMOS battery backup that no longer worked, and I couldn't find an easy way to fix it, so I recycled it.

Nowadays, even finding a real computer that isn't multicore and have an APIC instead of the original PIC & PIT is a bit hard, although I have a few of those running my OS on them in the field.

However, I have support for both 386 paging and PAE, and I only enable PAE when there is physical memory above 4G. PAE uses twice as much memory for page tables, so no sense in using it when there is no reason for it.

OT
is this a topic about pae and 386???????????
no i isn't.

[nullplan]

I've got an idea: I won't use graphics mode! I'll use TUI! I'm a genius!

Yes, run away from the challenge, I'm sure things will only get easier from here.

My first 386EX had a CMOS battery backup that no longer worked,

That bloody Dallas chip with the integrated battery? Yeah, that is a PITA to work around; I have seen people use a dremel very creatively to get at the battery (and then solder in a CR1820 battery holder).

However, I have support for both 386 paging and PAE, and I only enable PAE when there is physical memory above 4G.

Well, I had briefly considered a 32-bit OS, and then looked at PAE and non-PAE paging and noticed that supporting both would basically be twice the work, due to the details being just different enough so that an abstraction in code is either not possible or horribly slow. However, then I decided to just start on 64-bits, and that obviated the need for a decision. The jump to 5-level paging won't be nearly as far.

is this a topic about pae and 386???????????
no i isn't.

You know, I was on board until you gave me the finger. That's just obnoxious. Beyond that, it does happen that conversations evolve. You do not have a monopoly on on-topic answers here.

[Octocontrabass]

I've got an idea: I won't use graphics mode! I'll use TUI! I'm a genius!

Your OS won't work with UEFI, since there's no text mode in UEFI.

[iProgramInCpp]

Actually, if he just wants to set a video mode, then it would be much easier to do his own boot-loader, and in the boot process call BIOS to set the desired mode.

No real OS will depend on GRUB anyway. Takes away all the fun.

Sure. Ditch Multiboot and go with a better boot protocol instead.

Developing in 16-bit real mode is already outdated and quickly gets harder and harder to do. UEFI systems that don't support compatibility booting (for example, your real machine), won't run your 16-bit code. Bootloaders are overrated and give a bad impression of operating system development

[Gigasoft]

UEFI & BIOS still coexist, but eventually, most new PCs will only support UEFI. Anyway, if you are concerned about UEFI taking over, you also should know that there is no VBE if you boot with UEFI, and so you cannot use V86 mode to set video mode. With UEFI, you must either write your own video-drivers or setup a suitable video mode before leaving UEFI.

Your OS won't work with UEFI, since there's no text mode in UEFI.

This might be true with onboard graphics, but with add on cards there is usually no problem, the only difference being that you have to load and initialize the option ROM yourself.

[Octocontrabass]

This might be true with onboard graphics, but with add on cards there is usually no problem, the only difference being that you have to load and initialize the option ROM yourself.

If you can figure out how to load and initialize an option ROM by yourself, you can figure out how to use a linear framebuffer to emulate text mode. (Plus, new display adapters often don't include a legacy ROM anyway.)

...Although, if you're really serious about running option ROMs, it's usually possible to extract the onboard device ROMs from the BIOS ROM...

[rdos]

Actually, if he just wants to set a video mode, then it would be much easier to do his own boot-loader, and in the boot process call BIOS to set the desired mode.

No real OS will depend on GRUB anyway. Takes away all the fun.

Sure. Ditch Multiboot and go with a better boot protocol instead.

Developing in 16-bit real mode is already outdated and quickly gets harder and harder to do. UEFI systems that don't support compatibility booting (for example, your real machine), won't run your 16-bit code. Bootloaders are overrated and give a bad impression of operating system development

All multicore x86 processors need to be able to run 16-bit real mode code. That's because UEFI will only boot your BSP processor, and so you need start the AP processors yourself, which need to go through real mode. So just forget that Intel or AMD will be able to get rid of real mode. Won't happen anytime soon.

I have boot loaders for at least four different boot modes:
* I can boot from 32-bit UEFI
* I can boot from 64-bit UEFI by switching back to compatibility mode and turn off long mode & paging
* I can boot with BIOS through real mode
* I can boot with multiboot (GRUB).

Just limiting oneself to only one mode seems a bit problematic to me.

[Octocontrabass]

All multicore x86 processors need to be able to run 16-bit real mode code.

ACPI 6.4 defines a method to start APs directly in 64-bit long mode.

[rdos]

This might be true with onboard graphics, but with add on cards there is usually no problem, the only difference being that you have to load and initialize the option ROM yourself.

If you can figure out how to load and initialize an option ROM by yourself, you can figure out how to use a linear framebuffer to emulate text mode. (Plus, new display adapters often don't include a legacy ROM anyway.)

...Although, if you're really serious about running option ROMs, it's usually possible to extract the onboard device ROMs from the BIOS ROM...

Initializing option ROMs is pretty easy. If I remember it properly, you just call a fixed address of the ROM (in real or V86 mode). I think it is offset 3, but I'm not sure. It's in the BIOS manual that I still have somewhere...

[rdos]

All multicore x86 processors need to be able to run 16-bit real mode code.

ACPI 6.4 defines a method to start APs directly in 64-bit long mode.

ACPI is just software, so they might still use real mode to implement it.

I would want to see such a method in Intel's or AMDs processor manual...

Anyway, even if it would be required to start APs in long mode, I can still switch them back to compatibility mode and turn off long mode to make them run 32-bit code. 32-bit compatibility mode won't disappear anytime soon, and neither will protected mode (they are basically the same).

[Octocontrabass]

Initializing option ROMs is pretty easy. If I remember it properly, you just call a fixed address of the ROM (in real or V86 mode).

You also need a BIOS.

ACPI is just software, so they might still use real mode to implement it.

Sure, but that means the OS doesn't need to use real mode anymore, and if the OS doesn't need it then the CPU doesn't need it either.

[nullplan]

ACPI is just software, so they might still use real mode to implement it.

I believe you miss the point: Once there is an interface for the OS to start the APs without caring about real mode, the hardware can be changed to cut out real mode without hurting then-extant operating systems.

Anyway, even if it would be required to start APs in long mode, I can still switch them back to compatibility mode and turn off long mode to make them run 32-bit code.

For now yes. A future processor that doesn't let you turn off long mode is conceivable.

32-bit compatibility mode won't disappear anytime soon, and neither will protected mode (they are basically the same).

No they are not. There is no support for hardware task switching in long mode (a rarely used feature, I know, and therefore a prime candidate for removal), and I was under the impression that in long mode, you needed much of the OS to be 64-bit. I honestly never considered a 32-bit compat mode OS. Meaning that a processor that doesn't let you turn off long mode would be able to cut out quite a lot of weird stuff nobody ever needs (task gates, real mode address creation), and all of those transistors could then be reused to do something useful instead.

[rdos]

Initializing option ROMs is pretty easy. If I remember it properly, you just call a fixed address of the ROM (in real or V86 mode).

You also need a BIOS.

ACPI is just software, so they might still use real mode to implement it.

Sure, but that means the OS doesn't need to use real mode anymore, and if the OS doesn't need it then the CPU doesn't need it either.

Certainly, but it also depends on major OSes adopting to use this or later ACPI versions. I see quite a bit of lag in this area.

[rdos]

ACPI is just software, so they might still use real mode to implement it.

I believe you miss the point: Once there is an interface for the OS to start the APs without caring about real mode, the hardware can be changed to cut out real mode without hurting then-extant operating systems.

Only if people install these operating systems on the target hardware, and the OS developers decide to rely on ACPI for booting AP cores.

Anyway, even if it would be required to start APs in long mode, I can still switch them back to compatibility mode and turn off long mode to make them run 32-bit code.

For now yes. A future processor that doesn't let you turn off long mode is conceivable.

That's possible, but I can still run my 32-bit OS under long mode using compatibility mode. Done that, and it works.

32-bit compatibility mode won't disappear anytime soon, and neither will protected mode (they are basically the same).

No they are not. There is no support for hardware task switching in long mode (a rarely used feature, I know, and therefore a prime candidate for removal), and I was under the impression that in long mode, you needed much of the OS to be 64-bit. I honestly never considered a 32-bit compat mode OS.

Nope, only some basics like interrupt & exception handlers needs to be 64-bit. The documentation is not so clear on this, but it is possible to call 32-bit code (using far calls) from long mode both on Intel and AMD. A feature that is unlikely to be removed as long as 32-bit compat mode is supported.

Actually, the long mode paging structure is fully compatible with PAE paging (only has more levels), and so the compat mode OS can use the page tables as if it operated under PAE paging.

I originally experimented with this as part of supporting long mode applications on my 32-bit OS. I would switch the core that currently run the long mode application to long mode, and load IDT with a prefabricated 64-bit variant. I had this running on real hardware, but then decided not to continue with it.

Meaning that a processor that doesn't let you turn off long mode would be able to cut out quite a lot of weird stuff nobody ever needs (task gates, real mode address creation), and all of those transistors could then be reused to do something useful instead.

Most of the complexity is in descriptor handling, and that cannot be removed. Even long mode requires a GDT and a code & data selector.

[Ethin]

Uh... Once ACPI 6.4 gets supported by firmware -- which is happening pretty quickly, I'm pretty sure EDK II/OVMF already supports a large majority of it -- you bet that I'll be using it and I'm pretty sure other OSes will switch to it too when supported. It makes AP initialization significantly easier -- no need to mess about with assembly language or any of that stuff, just point the AP at a function to run and boom. I imagine it might also speed up OS startup by small margins too -- it ultimately means that, since most of the work is already done for you, all you have to do is swap out the page tables and your good to go. If I remember right its also architecture independent, unlike previous methods, meaning you can do that same strategy on any architecture that aCPI supports. But I might be wrong on that last point.