4 ms·

Would echoing the chracter on screen require a seperate video driver to mark the pixels that make up the character ? Considering how hard is to make the keyboar

Would echoing the chracter on screen require a seperate video driver to mark the pixels that make up the character ? Considering how hard is to make the keyboard driver, wouldn't the video driver be many folds harder?

Sanddancer 13y ago
Most video cards (some newer ones have stopped shipping with it) have, baked in, a text mode buffer. It's included in the Vesa Bios Extensions.
ghewgill 13y ago
PC video systems support text mode, where making a character appear amounts to simply writing the correct bytes to the correct memory mapped video buffer address. Graphics mode is similar but with more bytes (say, four per pixel).
stephen_g 13y ago
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.
- sown 13y ago
  > Writing an actual graphics driver is tricky 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
  - LukeShu 13y ago
    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.
    - sown 13y ago
      Thanks for the tips.
    - lmm 13y ago
      As a concrete suggestion, I quite like the "sun12x22" font.
    - girvo 13y ago
      Does that work (changing the font) even when you swap to TTY2 for example? If so, you're a lifesaver!
      - LukeShu 13y ago
        Yes.
- gizmo686 13y ago
  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.
- pbsd 13y ago
  0xB8000, to be precise. This is 16-bit 8086 legacy, where addresses were 20-bit and segmented. The most fun mode was mode 0x13 from INT 0x10, with its fantastic 320x200 resolution and 256 colors. That one had the buffer at 0xA0000.
  - Sharlin 13y ago
    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.
  - chinpokomon 13y ago
    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.
- exDM69 13y ago
  > 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.

Sanddancer 13y ago

Most video cards (some newer ones have stopped shipping with it) have, baked in, a text mode buffer. It's included in the Vesa Bios Extensions.

ghewgill 13y ago

PC video systems support text mode, where making a character appear amounts to simply writing the correct bytes to the correct memory mapped video buffer address. Graphics mode is similar but with more bytes (say, four per pixel).

stephen_g 13y ago

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.

sown 13y ago
> Writing an actual graphics driver is tricky 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
- LukeShu 13y ago
  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.
  - sown 13y ago
    Thanks for the tips.
  - lmm 13y ago
    As a concrete suggestion, I quite like the "sun12x22" font.
  - girvo 13y ago
    Does that work (changing the font) even when you swap to TTY2 for example? If so, you're a lifesaver!
    - LukeShu 13y ago
      Yes.
gizmo686 13y ago
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.
pbsd 13y ago
0xB8000, to be precise. This is 16-bit 8086 legacy, where addresses were 20-bit and segmented. The most fun mode was mode 0x13 from INT 0x10, with its fantastic 320x200 resolution and 256 colors. That one had the buffer at 0xA0000.
- Sharlin 13y ago
  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.
- chinpokomon 13y ago
  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.
exDM69 13y ago
> 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.