OSDev.org

Hello,
I want to set a resolution for my OS to 1024x600 without touching on VBE. I want this to make the user experience on the command-line, much more better.

• How can I do this?
• Any resource?

Best Regards,
Nathan Paulino Campos

Nathan wrote:Hello,
I want to set a resolution for my OS to 1024x600 without touching on VBE. I want this to make the user experience on the command-line, much more better.

• How can I do this?
• Any resource?

Best Regards,
Nathan Paulino Campos

I'm not sure it's possible to switch to a high resolution without going through VBE. The other way to go would probably be to directly access the graphics card, but that would require documentation (which most of them don't publicly have). VBE and GFX drivers are about the only "easy" ways I know.

I think you can write a driver for your graphics card, but that would be not only hard, but it would also only work on your PC and those who have an identical card. VBE is the easiest way I know.

Good luck though.
David

Greetings,

Nathan wrote:Hello,
I want to set a resolution for my OS to 1024x600 without touching on VBE. I want this to make the user experience on the command-line, much more better.

• How can I do this?
• Any resource?

Best Regards,
Nathan Paulino Campos

I don't think switching video modes isn't possible without using the BIOS/(U)EFI, unless you know how to deal with your graphics card. You could probably write a VGA driver, but I'm not even sure if you would ever be able to get a resolution like 1024x600. So you'll probably need VBE or a graphic card driver.

For my own kernel I am planning to write a 486-emulator so I can simply call INT 0x10 in protected/long mode. That way would allow me to have two basic drivers (VGA and VBE) so I can add NVIDIA/ATI/Intel/Voodoo/Cirrus/whatever support later on.


Regards,
Stephan J.R. van Schaik.

If only you read the FAQ...

The VGA's theoretical limit is just a little under 1024x1024, but you'll have to accept the 20Hz output, which no sane monitor will do for you, as well as the fact that 75% of the pixels will be out of the viewable range. The best you can get is the 800x600x4xheadache@40. Provided your monitor accepts that refresh rate, which still isn't a given.

I suggest you stick to your preconfigured 80x25 text since you are in for more trouble than you're solving.

Ok Combuster, I'm going to try VBE, but when I've tried How do I set a graphics mode and Getting VBE Mode Info, I just got a lot of errors.

Combuster wrote:800x600x4xheadache@40

Nathan wrote:Ok Combuster, I'm going to try VBE, but when I've tried How do I set a graphics mode and Getting VBE Mode Info, I just got a lot of errors.

Combuster wrote:800x600x4xheadache@40

Are you in protected mode, long mode or real mode? For the first two you'll either need 8086-emulation or you'll have to drop back to real mode. 8086-emulation is available in protected mode, but only in protected mode, via Virtual Mode 8086, which you'll have to set up first. 8086-emulation is required in protected/long mode as the BIOS is not available directly, unlike in real mode. If you can make interrupt calls to the BIOS then you can simply use INT 0x10, like stated in the two articles you just read. Keep in mind that you cannot simply copy the code, even if you had VM86-support or if you were in real mode, as they're just samples. (Unless your VM86-setup looks and works exactly the same)


Regards,
Stephan J.R. van Schaik.

Also, the contents of the error messages are much, much more helpful than the presence of error messages

If you start using the VBE, I hope that you start thinking GUI not CUI.

I have an old piece of code here, which is supposed to emulate real mode instructions and interrupts. But it is pure dark magic to me. So I appreciate any help in explaining that code.
I found it floating around quite a long time ago, so there might be a newer version avail.

Erm, I think I will cut this out as a new thread.

StephanVanSchaik wrote:Are you in protected mode, long mode or real mode? For the first two you'll either need 8086-emulation or you'll have to drop back to real mode.

Unfortunately, in long mode you don't get v86 mode. So you have to convert the 16-bit instructions to 32-bit first, but there're far too many problems (there was a thread about it a while ago, which I can't find now)
Basically, if you got it working, you'd be a fair part of the way to writing a clone of Bochs or QEmu...

Speaking of Bochs and QEmu, they use a very simple video device (the BGA), which is easy to write a driver for; the best option would be writing that driver if you're using one of those two, or using the VBE pmode interface (which shouldn't be too much hassle to get working in long mode)

quanganht wrote: I have an old piece of code here, which is supposed to emulate real mode instructions and interrupts. But it is pure dark magic to me. So I appreciate any help in explaining that code.
I found it floating around quite a long time ago, so there might be a newer version avail.

I felt a strange feeling when I saw the name of that file, a feeling from the distant past...
This turned out to be true, when as I read the contents of emu.c, I recognized that faithful collection of conventions that is my own code.

As to a newer version, there isn't one that only does real mode (I have a full x86_64 emulator in the works) but I'm considering working on the RME again, fixing up the bugs and completing support for the 386 (or whatever is needed) instruction set.

Selenic wrote:

StephanVanSchaik wrote:Are you in protected mode, long mode or real mode? For the first two you'll either need 8086-emulation or you'll have to drop back to real mode.

Unfortunately, in long mode you don't get v86 mode. So you have to convert the 16-bit instructions to 32-bit first, but there're far too many problems (there was a thread about it a while ago, which I can't find now)
Basically, if you got it working, you'd be a fair part of the way to writing a clone of Bochs or QEmu...

Speaking of Bochs and QEmu, they use a very simple video device (the BGA), which is easy to write a driver for; the best option would be writing that driver if you're using one of those two, or using the VBE pmode interface (which shouldn't be too much hassle to get working in long mode)

May I make you aware that 8086-emulation doesn't refer to V86 mode only, or at least not in my context. Also, you can't really rely on the VBE protected mode interface as it is something that is usually not implemented, and if it is, it is most likely broken anyway.

quanganht wrote:I have an old piece of code here, which is supposed to emulate real mode instructions and interrupts. But it is pure dark magic to me. So I appreciate any help in explaining that code.
I found it floating around quite a long time ago, so there might be a newer version avail.

Erm, I think I will cut this out as a new thread.

That's basically an emulator which will emulate 16-bit code as 32-bit (or 64-bit), although only some things are supported (most basic instructions). In Bochs when calling INT 0x10, AH=0x0E, you're most likely going to fail already for the second instruction as it is ADD r/8, imm8 (opcode: 0x80; at least that is the case for my version of Bochs). So if you plan to use that, you'll have to add some other instructions as well. If you want to get more insight of how it works, you should try and figure out how instructions are encoded on the x86(-64) architecture (See: http://wiki.osdev.org/X86_Instruction_Encoding or "Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M").


Regards,
Stephan J.R. van Schaik.

StephanVanSchaik wrote:May I make you aware that 8086-emulation doesn't refer to V86 mode only, or at least not in my context.

Ah, fair enough. I assumed you meant v86.

StephanVanSchaik wrote:Also, you can't really rely on the VBE protected mode interface as it is something that is usually not implemented, and if it is, it is most likely broken anyway.

Yeah, that's pretty unfortunate, but since when were standards ever followed properly? (I seem to remember reading that Bochs supports it properly, though)

And that emulator posted above is exactly the one I was referring to in my previous post; I must have found it while searching for something (though I can't remember what) if it was done quite a while ago...