Vertical Retrace Interval

An introduction to VGA techniques for smooth graphics animation

The CRT Display

Screen’s image consists of horizontal scanlines, drawn in top-down order,and redrawn about 60-70 times per second (depending on display mode).

Image “persistence”

• The impression of a steady screen image is purely a mental illusion of the viewer’s

• The pixels are drawn on the CRT screen too rapidly for the human eye to follow

• And the screen phosphor degrades slowly• So the brain blends a rapid succession of

discrete images into a continuous motion• So-called ‘motion pictures’ are based on

these phenomena, too (30 frames/second)

Color “dithering”

• The mind’s tendency to “blend” together distinct images that appear near to one another in time can be demonstrated by using two different colors -- alternately displayed in very rapid succession

• This is one technique called “dithering”

• Some early graphics applications actually used this approach, to show extra colors

Timing mechanism

• Today’s computers can “redraw” screens much faster than a CRT can display them

• We need to “slow down” the redrawing so that the CRT circuitry will be able keep up

• Design of VGA hardware allows programs to “synchronize” drawing with CRT refresh

• Use the “INPUT STATUS REGISTER 1” accessible (read-only) at I/O port 0x3DA

Input Status Register One 7 6 5 4 3 2 1 0

Vertical Retrace status 1 = retrace is active 0 = retrace inactive

Display Enabled status1 = VGA is reading (and displaying) VRAM0 = Horizontal or Vertical Blanking is active

I/O port-address: 0x3DA (color display) or 0x3BA (monochrome display)

void vertical_retrace_sync( void )

{// spin if retrace is already underwaywhile ( ( inb( 0x3DA ) & 8 ) == 8 );// then spin until a new retrace startswhile ( ( inb( 0x3DA ) & 8 ) == 0 );

}// This function only returns at the very beginning// of a new vertical blanking interval, to maximize// the time for drawing while the screen is blanked

Animation algorithm

1) Erase the previous screen

2) Draw a new screen-image

3) Get ready to draw another screen

4) But wait for a vertical retrace to begin

5) Then go back to step 1.

How much drawing time?

• Screen-refresh occurs 60 times/second

• So time between refreshes is 1/60 second

• Vertical blanking takes about 5% of time

• So “safe” drawing-time for screen-update is about: (1/60)*(5/100) = 1/1200 second

• What if your screen-updates take longer?

• Animation may exhibit “tearing” of images

Retrace visualization

• Our demo-program ‘instatus.cpp’ provides a visualization for the (volatile) state of the VGA’s Input Status Register One

• It repeatedly inputs this register’s contents and writes that value to the video memory

• The differences in pixel-coloring show how much time is spent in the ‘retrace’ states

• You can ‘instrument’ its loop to get percent

Programming techniques

• Your application may not require that the whole screen be redrawn for every frame

• Maybe only a small region changes, so time to “erase-and-redraw” it is reduced

• You may be able to speed up the drawing operations, by “optimizing” your code

• Using assembly language can often help

Using off-screen VRAM

• You can also draw to off-screen memory, which won’t affect what’s seen on-screen

• When your ‘off-screen’ image is finished, you can quickly copy it to the on-screen memory area (called a ‘BitBlit’ operation)

• Both CPU and SVGA provide support for very rapid copying of large memory areas

Offscreen VRAM

Extra VRAM available

CRTC Start_Address (default = 0) VRAM for the visible

screen-image

16MB on ourRadeon X300

Our classroom machines have 16-megabytes of video display memory The amount needed by the CRT for a complete screen-image depends upon your choice of the video display mode

Example: For a 1280-by-960 TrueColor graphics mode (e.g., 32 bits per pixel) the visible VRAM is 1280x960x4 bytes (which is less than 5 megabytes)

Our ‘animate1.cpp’ demo

• We can demonstrate smooth animation with a “proof-of-concept” prototype

• It’s based on the classic “pong” game

• A moving ball bounces against a wall

• The user is able to move a “paddle” by using an input-device (such as a mouse, keyboard, or joystick)

• We didn’t implement user-interaction yet

In-class exercises #1

• Investigate the effect of the function-calls to our ‘vertical_retrace_sync()’ routine (by turning it into a comment and recompiling)

• Add a counter to the loop in ‘instatus.cpp’ which is incrementd whenever bit 3 is set, to find the percentage of loop-iteractions during which vertical blanking was active

Adding sound effects

• We can take advantage of Linux’s support for synchronizing digital audio with graphic animation -- adds ‘realism’ to ‘pong’ game

• But for this we will need to understand the basic principles for using PC soundcards

• Linux supports two APIs: OSS and ALSA – Open Sound System (by 4Front Technology)– Advanced Linux Sound Architecture (GNU)

A PC’s ‘Timer-Counter’

• Most PCs have a built-in ‘Timer-Counter’ that is capable of directly driving the PC’s internal speaker (if suitably programmed)

• By using simple arithmetic, a programmer can produce a musical tone of any pitch, and so can play tunes by controlling the sequencing and duration of those tones

• But we can’t hear the speaker in our class

‘Square Wave’ output

• But we can listen to the external speakers that attach to the Instructor’s workstation, or listen to a stereo headset that you plug in to your individual machine’s soundcard

• The same basic principle used by the PC internal speaker and Timer-Counter – if understood – can be used in our software to generate ‘square-wave’ musical tones

Our ‘flipflop.cpp’ demo

• We created a graphics animation that will show you the basic idea for generating a ‘square-wave’ output-stream to vibrate an external speaker (or headset earphones) at any given frequency humans can hear

• This animation also illustrates principles of VGA graphics animation programming for a 4bpp (16-color) “planar” memory-model

Our ‘makewave.cpp’ tool

• We created a tool that will generate actual audio files which play notes of designated frequencies – under Linux or another OS (e.g. WinXP) that understands a standard Waveform Audio File (.wav)

• You can see what application code you’d need to write, to play a .’wav’ file using the simple OSS Linux programming interface, by looking at our ‘pcmplay.cpp’ program

In-class exercises #2

• Use our ‘makewave’ program to produce some .wav files that contain square-wave data for musical tones of different pitches

• Use our ‘pcmplay’ program to play these audio files (and listen with your headset)

• We will learn more about Waveform files in our next lecture – bring your earphones if you have them!