How to generally enter virtual 8086 mode?

[uruseiyatsura]

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.

You know BIOS will be removed by Intel, they will install UEFI. So, if I use grub, i need only to update grub and not to rewrite my bootlader.
Furthermore, I don't know how to use BIOS read func to read FAT, even FAT12.
If u help me, I'm happy.

[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.

You know BIOS will be removed by Intel, they will install UEFI. So, if I use grub, i need only to update grub and not to rewrite my bootlader.
Furthermore, I don't know how to use BIOS read func to read FAT, even FAT12.
If u help me, I'm happy.

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.

[uruseiyatsura]

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.

You know BIOS will be removed by Intel, they will install UEFI. So, if I use grub, i need only to update grub and not to rewrite my bootlader.
Furthermore, I don't know how to use BIOS read func to read FAT, even FAT12.
If u help me, I'm happy.

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.

So, you are saying that I can't use GRUB in UEFI to set video mode, aren't you?
I'm not expert, but I think it's not possible.

[rdos]

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.

So, you are saying that I can't use GRUB in UEFI to set video mode, aren't you?
I'm not expert, but I think it's not possible.

No, GRUB can still set the video mode (using the UEFI interface), but your OS cannot do it with BIOS calls in V86 mode.

[uruseiyatsura]

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

Linux for example is based on grub, and not on his boot loader (if i'm not wrong).

[uruseiyatsura]

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.

So, you are saying that I can't use GRUB in UEFI to set video mode, aren't you?
I'm not expert, but I think it's not possible.

No, GRUB can still set the video mode (using the UEFI interface), but your OS cannot do it with BIOS calls in V86 mode.

Okay. So, the problem is this:

I need to modify my multiboot header
Here is it, my bootstrap code:

Code: Select all

# set magic number to 0x1BADB002 to identified by bootloader 
.set MAGIC,    0x1BADB002

# set flags to 0
.set FLAGS,    0x2

# set the checksum
.set CHECKSUM, -(MAGIC + FLAGS)

# set multiboot enabled
.section .multiboot

# define type to long for each data defined as above
.long MAGIC
.long FLAGS
.long CHECKSUM


# set the stack bottom 
stackBottom:

# define the maximum size of stack to 512 bytes
.skip 1024


# set the stack top which grows from higher to lower
stackTop:

.section .text
.global _start
.type _start, @function


_start:

  # assign current stack pointer location to stackTop
	mov $stackTop, %esp

  # call the kernel main source
	call KERNEL_MAIN

	cli


# put system in infinite loop
hltLoop:

	hlt
	jmp hltLoop

.size _start, . - _start

Don't care about asm code, the matter is the header, isn't it?

[kzinti]

You didn't ask for the video mode in your header (flag 0x04). Here is what I use:

Code: Select all

.equ MULTIBOOT_HEADER_MAGIC          , 0x1BADB002
.equ MULTIBOOT_HEADER_FLAGS          , 0x00000007   # VIDEO_MODE (4) + MEMORY_INFO (2) + PAGE_ALIGN (1)
.equ MULTIBOOT_HEADER_CHECKSUM       , -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS) & 0xFFFFFFFF

.align 16, 0
multiboot_header:
    .long   MULTIBOOT_HEADER_MAGIC
    .long   MULTIBOOT_HEADER_FLAGS
    .long   MULTIBOOT_HEADER_CHECKSUM

    # aout kludge (unused)
    .long 0,0,0,0,0

    # Video mode
    .long   0       # Linear graphics please?
    .long   0       # Preferred width
    .long   0       # Preferred height
    .long   32      # Preferred pixel depth

[rdos]

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

Linux for example is based on grub, and not on his boot loader (if i'm not wrong).

Yes, because GRUB was developped as the boot-loader for Linux. I don't want to rely on the boot-loader of a competing operating system.

I once had an option to boot my OS through GRUB, but nowadays I have native bootloaders for both BIOS and UEFI. The UEFI loader generally is the easiest to use since it doesn't rely on putting boot-sectors on the disc. The GRUB option is more or less useless.

Another issue is that your choice of partitioning system is connected to your choice of bootloader. For BIOS, you must use the old legacy disc format, while for UEFI, you must use GPT.

[uruseiyatsura]

Is this code OK?

Code: Select all

.equ MULTIBOOT_HEADER_MAGIC          , 0x1BADB002
.equ MULTIBOOT_HEADER_FLAGS          , 0x00000007   # VIDEO_MODE (4) + MEMORY_INFO (2) + PAGE_ALIGN (1)
.equ MULTIBOOT_HEADER_CHECKSUM       , -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS) & 0xFFFFFFFF

.align 16, 0
multiboot_header:
    .long   MULTIBOOT_HEADER_MAGIC
    .long   MULTIBOOT_HEADER_FLAGS
    .long   MULTIBOOT_HEADER_CHECKSUM

    # aout kludge (unused)
    .long 0,0,0,0,0

    # Video mode
    .long   1       # Linear graphics please?
    .long   320       # Preferred width
    .long   200       # Preferred height
    .long   32      # Preferred pixel depth

# set the stack bottom 
stackBottom:

# define the maximum size of stack to 512 bytes
.skip 1024


# set the stack top which grows from higher to lower
stackTop:

.section .text
.global _start
.type _start, @function


_start:

  # assign current stack pointer location to stackTop
	mov $stackTop, %esp

  # call the kernel main source
	call KERNEL_MAIN

	cli


# put system in infinite loop
hltLoop:

	hlt
	jmp hltLoop

.size _start, . - _start

[Octocontrabass]

For BIOS, you must use the old legacy disc format, while for UEFI, you must use GPT.

GPT works perfectly fine with BIOS. Linux supports it.

Is this code OK?

No. You need to set mode_type to 0 for linear graphics, but you've set it to 1.

You're also placing your stack in the .multiboot section instead of in the .bss section where it should be.

You're also not passing the Multiboot information structure to KERNEL_MAIN. You need the Multiboot information structure to find the address of your framebuffer. The address of the framebuffer is not 0xA0000.

[rdos]

For BIOS, you must use the old legacy disc format, while for UEFI, you must use GPT.

GPT works perfectly fine with BIOS. Linux supports it.

OK, but it is a bit of overkill unless you want to support very large discs. It's most convient to use the legacy format for BIOS boots.

[uruseiyatsura]

You're also not passing the Multiboot information structure to KERNEL_MAIN. You need the Multiboot information structure to find the address of your framebuffer. The address of the framebuffer is not 0xA0000.

What should I do??

The address of the framebuffer is not 0xA0000.

Why? Is OSDEV wiki kidding me?

[nullplan]

What should I do??

You should read the multiboot specification. Not a tutorial, no handholding. Just read the spec. It explains where the multiboot info is located and how to interpret it. Then write code interpreting it. In particular, the framebuffer address is given as a 64-bit value 88 bytes into the multiboot info structure. It ought to be below 4GB, but might be above that. But then, you should really use at least PAE these days, anyway, unless you are planning a 386 revival project.

The spec can be found here: https://www.gnu.org/software/grub/manua ... iboot.html

[uruseiyatsura]

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

[rdos]

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.