1. Vertical Retrace Interval An introduction to VGA techniques for smooth graphics animation

2. 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).

3. 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)

4. 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

5. 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

6. 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)

7. 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

8. 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.

9. 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

10. 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

11. 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

12. 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

13. Offscreen VRAM Extra VRAM available CRTC Start_Address (default = 0) VRAM for the visible screen-image 16MB on our Radeon 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)

14. 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

15. 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

16. 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)

17. 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

18. ‘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

19. 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

20. 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

21. 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!