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 status
1 = VGA is reading (and displaying) VRAM
0 = 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 underway
while ( ( inb( 0x3DA ) & 8 ) == 8 );
// then spin until a new retrace starts
while ( ( 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)
2)
3)
4)
5)
Erase the previous screen
Draw a new screen-image
Get ready to draw another screen
But wait for a vertical retrace to begin
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
CRTC Start_Address (default = 0)
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)
VRAM for the
visible
screen-image
Extra VRAM
available
16MB
on our
Radeon
X300
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!