Programming Super-VGA Graphics Devices Introduction to VESA graphics modes and to organization of the linear frame-buffer memory

Motivation The impetus for high-quality PC graphics was an early incentive for developing the 32-bit Intel x86 processor, since graphics images with realistic color and animation requires efficient access to a much larger memory-segment than can be addressed with the original 20-bit real-mode scheme

Raster Display Technology The graphics screen is a two-dimensional array of picture elements (‘pixels’) These pixels are redrawn sequentially, left-to-right, by rows from top to bottom

Special “dual-ported” memory VRAM RAM CPU CRT 128-MB of VRAM 4096-MB of RAM

Screen-resolution by-480 = pixels (i.e., picture-elements)

Early ‘planar’ memory Each cpu byte-address controlled 8 adjacent pixels in 4 parallel color-planes 640-by-480 times 4-planes, divided by 8 bits-per-byte = byte-addresses

Greater picture fidelity by-960 = pixels (i.e., picture-elements) times 4 bytes-per-pixel = bytes of vram

Typical Chipset Layout MCH Memory Controller Hub (Northbridge) ICH I/O Controller Hub (Southbridge) CPU Central Processing Unit DRAM Dynamic Random Access Memory NIC Network Interface Controller HDC Hard Disk Controller AC Audio Controller Graphics Controller TimerKeyboardMouseClock Multimedia Controller Firmware Hub

PCI Configuration Space PCI Configuration Space Body (48 doublewords – variable format) 64 doublewords PCI Configuration Space Header (16 doublewords – fixed format) A non-volatile parameter-storage area for each PCI device-function

PCI Configuration Header Status Register Command Register Device ID Vendor ID BIST Cache Line Size Class Code Class/SubClass/ProgIF Revision ID Base Address 0 Subsystem Device ID Subsystem Vendor ID CardBus CIS Pointer reserved capabilities pointer Expansion ROM Base Address Minimum Grant Interrupt Pin reserved Latency Timer Header Type Base Address 1 Base Address 2Base Address 3 Base Address 4Base Address 5 Interrupt Line Maximum Latency doublewords Dwords

reserved Interface to PCI Configuration Space CONFADD ( 0x0CF8) CONFDAT ( 0x0CFC) ENEN bus (8-bits) device (5-bits) doubleword (6-bits) function (3-bits) 00 PCI Configuration Space Address Port (32-bits) PCI Configuration Space Data Port (32-bits) 31 0 Enable Configuration Space Mapping (1=yes, 0=no)

Reading PCI Configuration Data Step one: Output the desired longword’s address (bus, device, function, and dword) with bit 31 set to 1 (to enable access) to the Configuration-Space Address-Port Step two: Read the designated data from the Configuration-Space Data-Port: # read the PCI Header-Type field (byte 2 of dword 3) for bus=0, device=0, function=0 movl$0x C, %eax# setup address in EAX movw$0x0CF8, %dx# setup port-number in DX outl%eax, %dx# output address to port mov$0x0CFC, %dx# setup port-number in DX inl%dx, %eax# input configuration longword shr$16, %eax# shift word 2 into AL register movb%al, header_type# store Header Type in variable

Graphics programs What a graphics program must do is put appropriate bit-patterns into the correct locations in the VRAM, so that the CRT will show an array of colored dots which in some way is meaningful to the human eye So the programmer must understand what the CRT will do with the contents of VRAM

How ‘truecolor’ works R B G alpharedgreenblue pixel longword The intensity of each color-component within a pixel is an 8-bit value

Intel uses “little-endian” order BGRBGRBGR VRAM Video Screen

Vendor incompatibilities Several competing vendors manufacture graphics controllers for the PC market They’re based in various parts of the world (e.g., United States, Canada, Taiwan, etc.) Their hardware designs are not identical The VESA (Video Electronics Standards Association) organization was created to create a standardized firmware interface

VBE 3.0 The VESA BIOS Extensions document is accessible on our CS 630 course website It implements services in a manner similar to the ROM-BIOS routines we’ve used in our previous boot-time applications (e.g., via software interrupt-0x10) We’ve created a demo-program (named ‘vesademo.s’) illustrating VESA’s use

Typical ‘program-structure’ Usual steps within a graphics application: – Initialize video system hardware – Display some graphical imagery – Wait for a termination condition – Restore original hardware state

Hardware Initialization The SVGA system has over 300 registers which must be individually reprogrammed It would take us many months to learn how they all work to support a graphics mode For now, we just ‘reuse’ vendor-supplied routines, built into the SVGA firmware They usually support quite a few different screen-resolutions and color-depths

Physical Memory Layout Graphics frame-buffer our code/data 0x Base-Address is dynamically assigned by firmware at power-on CPU address space (4GB)

VESA function 1 Obtains a block of parameter-values for the desired graphics display-mode: –Scanline-width (in bytes) –Horizontal resolution (in pixels) –Vertical resolution (in pixels) –Pixel-size (in bits-per-pixel) –Frame-buffer’s physical address

VESA function 2 Reprograms all the graphics controller’s internal device registers for the selected VESA-standard display-mode

In-class exercise #1 Can you reprogram the colors used in our ‘vesademo.s’ application to use another border-color and another annulus-color? ALPHAREDGREENBLUE 31…… ……16 15…..… ……… 0

In-class exercise #2 Can you modify our demo-program so as to use a standard VESA graphics mode that has a higher screen-resolution? –Mode 0x0115 was for 800-by-600, 32bpp –Mode 0x0118 is for 1024-by-768, 32bpp