Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
; you should declare this function as :
; extern void enter_v86(uint32_t ss, uint32_t esp, uint32_t cs, uint32_t eip);
enter_v86:
mov ebp, esp ; save stack pointer
push dword [ebp+4] ; ss
push dword [ebp+8] ; esp
pushfd ; eflags
or dword [esp], (1 << 17) ; set VM flags
push dword [ebp+12] ; cs
push dword [ebp+16] ; eip
iret
But I'm so stupid and so I can not understand how to use this function and how to exit from a v8086 task.
I need a help especially for activating VGA 256 colours mode, and floppy disk reading. I know you don't reccomend 8086 disk reading, but I don't care.
I'm a beginner in fact of OSDev programming.
Entering virtual 8086 mode is the same as entering user mode. The only real difference between a virtual 8086 mode task and any other task is the state of EFLAGS.VM.
Exiting virtual 8086 mode is also the same as exiting user mode: the task will perform a system call, or the task will cause an exception, or external hardware will interrupt the CPU.
Reading the floppy disk requires IRQs, which means your kernel will need to catch the floppy disk IRQs (and possibly others, like timer IRQs) and redirect them into the virtual 8086 mode task. This is not exactly a beginner-level task...
I think calling real BIOS functions when developing support for V86 mode is not a good idea. You should start by calling V86 code that just does an iret. Note that you will need to handle exceptions from V86 mode, in particular those that affect flags and those that return back to your kernel.
You also need to create a stack for V86 mode, and then you need to push a reference to something that takes you back to your kernel. For instance, if you use iret to return (which a BIOS function will do), then you need to push 16-bit flags, cs and ip that reference some location in V86 mode that contains code that trigger you to return to your kernel. As an example, you could place an invalid instruction there and handle this exception in your kernel, and detect the source. Of course, you will need to unwind your exception handler and save the return position in your kernel so the exception handler can go there.
There actually is a big difference between calling V86 code and user mode. Generally, user mode code will use syscalls to access your kernel, which works fine with the normal flow. However, with V86 code, you want to "call" certain software in the BIOS, which is in the reverse direction and not part of the normal execution flow.
I have a very basic sample here that enters V8086 mode. V8086 mode is simply exited with a UD2 instruction (not useful way of doing it but was meant as an example). It has very basic support for an INT N wrapper etc. https://github.com/marleyd386/OSDev/tre ... -intn-iret
Are you, unintentionally, making life difficult for yourself?
Set the VGA mode before you go into protected mode.
Write a protected mode floppy disk driver; it's probably easier than grappling with virtual 8086 mode (and getting real mode interrupts to work). When your OS grows up and wants to use 64-bit mode the virtual 8086 mode isn't available.
I know you don't reccomend 8086 disk reading, but I don't care.
Fair enough, but if you don't care why should anyone else care enough to help you?
Are you, unintentionally, making life difficult for yourself?
Set the VGA mode before you go into protected mode.
Write a protected mode floppy disk driver; it's probably easier than grappling with virtual 8086 mode (and getting real mode interrupts to work). When your OS grows up and wants to use 64-bit mode the virtual 8086 mode isn't available.
How can I set a protected mode floppy driver so?
How can I set VGA mode when I use grub that automatically sets protected mode?
Cannot find the GRUB option you said to exist. I'm using a multiboot kernel, this can help you if you want to help me, but actually I found nothing on that site.
Every piece of hardware has an interface you can write a driver for, you should not need to depend on black-box code provided by the BIOS.
Hey! I'm developing two operating systems:
NanoShell --- A 32-bit operating system whose GUI takes inspiration from Windows 9x and early UNIX desktop managers. Boron --- A portable SMP operating system taking inspiration from the design of the Windows NT kernel.
GRUB_TERMINAL_OUTPUT=gfxmode
menuentry "KabiCOM Control Panel for Silly People" {
set gfxmode=320x200x8
multiboot (cd)/boot/CpSp.bin
}
it doesn't work
Did you turn on https://www.gnu.org/software/grub/manua ... ot_002eh-1 MULTIBOOT_VIDEO_MODE in your Multiboot header? This will allow you to use setgfxpayload, which will set the graphics payload. The menuentry is broken right now because you set gfxmode, not gfxpayload, and you don't call "boot", and the gfxpayload set is done before loading the kernel, when it should be after. Here's a fixed configuration:
menuentry "KabiCOM Control Panel for Silly People" {
multiboot (cd)/boot/CpSp.bin
set gfxpayload=800x600x32
boot
}
One more thing, this will set a VBE video mode, if you really want the 320x200 256 color screen mode I recommend checking the resources I posted earlier, or keeping on with V8086
Hey! I'm developing two operating systems:
NanoShell --- A 32-bit operating system whose GUI takes inspiration from Windows 9x and early UNIX desktop managers. Boron --- A portable SMP operating system taking inspiration from the design of the Windows NT kernel.
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.