Text mode is super easy - you just set bytes in the correct memory location (0xb8000000 if I remember correctly).
Writing an actual graphics driver is tricky - although there are some ways to get decent frame buffer modes (like VESA Bios Extentions), to do things really well requires thousands of lines of code before you can even get a pixel on the screen, and is different for every card.
It may be a bit easier now - you could look at the kernel mode setting code in the Linux kernel that exists now for Intel, nVidia (through Norveau) and AMD cards that didn't exist a few years ago when I was dabbling around in OS dev. Still, it would be a massively difficult task. You'd probably want to use the full Mesa stack and open source drivers that use it if possible, but writing the runtime to support it would be a big task.
Oh mode 0x13 and warm memories. Super easy to get working, as well, just an interrupt and start writing pixels to memory. Would probably be one of the first thing I'd do if I were to write a kernel.
I preferred "Mode X" for its 320x240 resolution with square pixels and additional pages that could be used for animations. I still have my EGA/VGA Programmer's Guide "Bible" sitting on my bookshelf. I haven't needed it for many years now, but somehow it is a comfort keeping it around.
> Text mode is super easy - you just set bytes in the correct memory location (0xb8000000 if I remember correctly).
In addition you have to be using I/O ports if you want to move the blinking cursor and other related stuff.
> Writing an actual graphics driver is tricky - although there are some ways to get decent frame buffer modes (like VESA Bios Extentions), to do things really well requires thousands of lines of code before you can even get a pixel on the screen, and is different for every card.
This is particularly painful because you have to switch back to real mode to be able to use VESA and other Bios interrupts.
Thankfully it's not required if you're using a good bootloader like GRUB (which you should if you're doing an OS project, writing another bootloader is just more arcane hardware to work around). The multiboot specification allows you to ask for a video framebuffer from the bootloader, and you'll get a physical memory address where the linear video framebuffer resides. I bet UEFI has something similar too.
So these days, with the help of your bootloader, doing graphics on a bare metal kernel is as easy as using the text mode.
If I remember my go at writing an `OS` you can just ask the BIOS to print the string for you, until you switch to protected mode. Even then, you could jump between protected and real mode to use the BIOS and still get the full address space.
EDIT: Nevermind, that still required putting the string in a magic location.
Does that include things that are not in text mode, if I recall the name correctly? Sometimes I just want my tiniest netbook to display the normal 80x40 resolution but it keeps putting the characters in what I think is video mode
I'm not sure how it is implemented at the graphics card level, but the Linux kernel virtual console can be high-resolution.
The "correct" thing to do here is set the console font to a larger one. If you are on a systemd-using distribution, see vconsole.conf(8).
Now, you could force a lower resolution, but that causes jaggy text, as pixels will be stretched unevenly by the graphics card. This can be done with KMS, or the vga= boot parameter.
Writing an actual graphics driver is tricky - although there are some ways to get decent frame buffer modes (like VESA Bios Extentions), to do things really well requires thousands of lines of code before you can even get a pixel on the screen, and is different for every card.
It may be a bit easier now - you could look at the kernel mode setting code in the Linux kernel that exists now for Intel, nVidia (through Norveau) and AMD cards that didn't exist a few years ago when I was dabbling around in OS dev. Still, it would be a massively difficult task. You'd probably want to use the full Mesa stack and open source drivers that use it if possible, but writing the runtime to support it would be a big task.