Does anyone have a comprehensive explanation of how the graphics system works?

[chrstrbrts]

Hello,

OK, so I finished Intel's big manual, and, as I lamented in another recent post, there was no mention whatsoever of the graphics system.

I find this unusual as for many cheap models like my laptop the graphics system is actually a part of the CPU.

But, alas, no mention at all.

Does anyone know, or can anyone point me to a thorough explanation of how the graphics system works?

I know that either on a graphics card or in RAM there is a memory structure called a frame buffer.

The monitor pulls that data 60 times/second and sends it to the pixels.

The pixels in turn shine a certain frequency of light as a function of the voltage applied across them.

This is how 0's and 1's become colors.

No matter what you're doing: looking at your desktop, watching a video, writing a word document, etc. this is how images are placed on the screen.

But how do we get there?

What about all the abstraction layers above this bottom hardware layer?

Also, in what state is the graphics system in the pre-boot environment?

If I write my own bootable code on a USB or something and boot my own "OS" of sorts and don't jump into protected mode and just keep things in real mode, what kind of control do I have over the screen?

Would I be able to write to each pixel individually?

Thanks.

 

[TheELF]

If I write my own bootable code on a USB or something and boot my own "OS" of sorts and don't jump into protected mode and just keep things in real mode, what kind of control do I have over the screen?

Would I be able to write to each pixel individually?

Thanks.

Yup,the frame buffer is a predefined area of memory wich is always the same adresses you can directly send hexadecimal values to that adresses and make the pixels light up.
For a quick example have a look at plop boot manager.
Under dos you should be looking for the vesa documentation or maybe even older protocols like cga ega and so on.
For windows it's all done through directx.

 

[exdeath]

If I write my own bootable code on a USB or something and boot my own "OS" of sorts and don't jump into protected mode and just keep things in real mode, what kind of control do I have over the screen?

Call BIOS / VIDEO INT 10 to set mode 13h.
Write bytes to A000:0000-FFFF in 256 color index mode and they appear on the screen. Address = y * 320 + x.

Change palettes by setting pallette index to IO 3C8 and 3 successive writes to 3C9 with your RGB triplet.

Simple as that. Should be some old graphics programming books available that are applicable for learning basics. (Zen of Graphics Programming, etc)

These functions and addresses existing and doing these actions are what it means to be a VGA compatible device. They are set up during POST by the BIOS and VGA option ROM which points INT 10 to itself to implement the well known standard called VGA before the bootstrap is even called to load an OS. In essence INT 10 itself is a driver / API built into ROM. Yet it's merely convenience in this case as the hardware registers and IO ports and protocols for VGA are well documented and you could do anything yourself that INT 10 does if you really wanted.

Anything more than that you'll need VBE 2 or 3 (SVGA, true color, etc). VGA was the last common ancestor of all graphics cards. Now they are vendor specific and register and command packet level documents and programming details are stingily guarded IP secrets unless it's outdated open source for Linux drivers.

No hardware acceleration was ever exposed in BIOS/DOS level real mode access. By the time SVGA+ and hardware acceleration started to become a thing it was via Windows GDI and DX drivers, and the implementation details were vendor specific, proprietary, and deviated from any common VGA or VESA standard per vendor by then. This is when graphics vendors were getting extremely competitive, proprietary, closed, secret, wanted a leg up on rivals instead of following standards, and when things started getting really IP and copyright heavy handed.

There was a short lived attempt to standardize acceleration for basic blit copies and shape drawing using acceleration via VBE/AF but by then everyone had moved to Windows so it was never realized. Eg programming some IO to tell video card to move 64k pixels from here to there vs having the CPU do it looping mov instructions 64k times over the bus.

Many SVGA cards have hardware acceleration functions to do VRAM to VRAM copies or filled rectangles (recall the marketing term "SVGA Windows accelerators") but there was never a low level standard for accessing this as a programmer outside of GDI drivers and using Windows or DX APIs. This is why there was a dead spot for PC games during the DOS to Windows migration and many games continued to be built for DOS for years and why intermediate solutions like Glide came about until Direct X matured once 3D became a thing.

Without detailed documentation of the accelerator you're working with, all you're getting is linear framebuffer access and CPU software drawing of everything. Also keep in mind the framebuffer size of even the earliest SVGA cards 1 MB+ in VRAM alone require protected mode to access and map a linear framebuffer due to the 1MB limitation of real mode.

These are all the exact reasons I moved to game consoles for my low level kick. I wanted to do graphics at a hardware level, even Win32 DDK drivers if I had to, but was impossible on PC as a hobbyist since the hardware details of most cards worth working with are vendor secrets that they won't share unless you work for them or are a vendor partner (EVGA, etc).

With consoles graphics acceleration and interfaces are fixed (all the same) and well documented (eg PS2 GIF packets, SNES/NES/GBA video OAM and scroll registers, etc).

Not really easy to do on PC unless you reverse engineer a really old card from a Linux driver source or use a vendor specific library like Glide.

 

[dogen1]

https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

 

[Apathetic]

I second a recommendation for Michael Abrash's "Zen of Graphics Programming". It's one of the best books from that era.

Also, https://www.gamedev.net/ may have some information for you.

Dave

 

[Apathetic]

Here's an example of what exdeath was refering too:

http://devdocs.inightmare.org/x86-assembly-graphics-part-i-mode-13h/

Dave

 

[chrstrbrts]

Call BIOS / VIDEO INT 10 to set mode 13h.
Write bytes to A000:0000-FFFF in 256 color index mode and they appear on the screen. Address = y * 320 + x.

In essence INT 10 itself is a driver / API built into ROM. Yet it's merely convenience in this case as the hardware registers and IO ports and protocols for VGA are well documented and you could do anything yourself that INT 10 does if you really wanted.

OK, I assume that A000:0000-FFFF is not actually the memory range for the pertinent registers and IO ports on the graphics hardware.

Otherwise, there would be no point in calling INT 10 in the first place.

I assume that when you call INT 10, the A000:0000-FFFF memory range is aliased to the actual registers and IO ports.

Am I correct?

How would you find out where the actual memory ranges and IO ports are?

In a published specification somewhere?

 

[chrstrbrts]

exdeath, you around?

 

[chrstrbrts]

exdeath has died....