149 lines
7.5 KiB
Markdown
149 lines
7.5 KiB
Markdown
------------------------ --------------------------------- --------------------
|
||
[Previous](04-08.html) [Table of Contents](index.html) [Next](04-10.html)
|
||
------------------------ --------------------------------- --------------------
|
||
|
||
The answer varies considerably depending on what display adapter and
|
||
what display mode we’re talking about. The display adapter cycle-eater
|
||
is worst with the Enhanced Graphics Adapter (EGA) and the original Video
|
||
Graphics Array (VGA). (Many VGAs, especially newer ones, insert many
|
||
fewer wait states than IBM’s original VGA. On the other hand, Super VGAs
|
||
have more bytes of display memory to be accessed in high-resolution
|
||
mode.) While the Color/Graphics Adapter (CGA), Monochrome Display
|
||
Adapter (MDA), and Hercules Graphics Card (HGC) all suffer from the
|
||
display adapter cycle-eater as well, they suffer to a lesser degree.
|
||
Since the VGA represents the base standard for PC graphics now and for
|
||
the foreseeable future, and since it is the hardest graphics adapter to
|
||
wring performance from, we’ll restrict our discussion to the VGA (and
|
||
its close relative, the EGA) for the remainder of this chapter.
|
||
|
||
#### The Impact of the Display Adapter Cycle-Eater {#Heading21}
|
||
|
||
Even on the EGA and VGA, the effect of the display adapter cycle-eater
|
||
depends on the display mode selected. In text mode, the display adapter
|
||
cycle-eater is rarely a major factor. It’s not that the cycle-eater
|
||
isn’t present; however, a mere 4,000 bytes control the entire text mode
|
||
display, and even with the display adapter cycle-eater it just doesn’t
|
||
take that long to manipulate 4,000 bytes. Even if the display adapter
|
||
cycle-eater were to cause the 8088 to take as much as 5µs per display
|
||
memory access—more than five times normal—it would still take only
|
||
4,000x 2x 5µs, or 40 µs, to read and write every byte of display memory.
|
||
That’s a lot of time as measured in 8088 cycles, but it’s less than the
|
||
blink of an eye in human time, and video performance only matters in
|
||
human time. After all, the whole point of drawing graphics is to convey
|
||
visual information, and if that information can be presented faster than
|
||
the eye can see, that is by definition fast enough.
|
||
|
||
That’s not to say that the display adapter cycle-eater *can’t* matter in
|
||
text mode. In Chapter 3, I recounted the story of a debate among
|
||
letter-writers to a magazine about exactly how quickly characters could
|
||
be written to display memory without causing snow. The writers carefully
|
||
added up Intel’s instruction cycle times to see how many writes to
|
||
display memory they could squeeze into a single horizontal retrace
|
||
interval. (On a CGA, it’s only during the short horizontal retrace
|
||
interval and the longer vertical retrace interval that display memory
|
||
can be accessed in 80-column text mode without causing snow.) Of course,
|
||
now we know that their cardinal sin was to ignore the prefetch queue;
|
||
even if there were no wait states, their calculations would have been
|
||
overly optimistic. There *are* display memory wait states as well,
|
||
however, so the calculations were not just optimistic but wildly
|
||
optimistic.
|
||
|
||
Text mode situations such as the above notwithstanding, where the
|
||
display adapter cycle-eater really kicks in is in graphics mode, and
|
||
most especially in the high-resolution graphics modes of the EGA and
|
||
VGA. The problem here is not that there are necessarily more wait states
|
||
per access in highgraphics modes (that varies from adapter to adapter
|
||
and mode to mode). Rather, the problem is simply that are many more
|
||
bytes of display memory per screen in these modes than in
|
||
lower-resolution graphics modes and in text modes, so many more display
|
||
memory accesses—each incurring its share of display memory wait
|
||
states—are required in order to draw an image of a given size. When
|
||
accessing the many thousands of bytes used in the high-resolution
|
||
graphics modes, the cumulative effects of display memory wait states can
|
||
seriously impact code performance, even as measured in human time.
|
||
|
||
For example, if we assume the same 5 µs per display memory access for
|
||
the EGA’s high-resolution graphics mode that we assumed for text mode,
|
||
it would take 26,000 x 2 x 5 µs, or 260 µs, to scroll the screen once in
|
||
the EGA’s high-resolution graphics mode, mode 10H. That’s more than
|
||
one-quarter of a second—noticeable by human standards, an eternity by
|
||
computer standards.
|
||
|
||
That sounds pretty serious, but we did make an unfounded assumption
|
||
about memory access speed. Let’s get some hard numbers. Listing 4.11
|
||
accesses display memory at the 8088’s maximum speed, by way of a **REP
|
||
MOVSW** with display memory as both source and destination. The code in
|
||
Listing 4.11 executes in 3.18 µs per access to display memory—not as
|
||
long as we had assumed, but a long time nonetheless.
|
||
|
||
**LISTING 4.11 LST4-11.ASM**
|
||
|
||
; Times speed of memory access to Enhanced Graphics
|
||
; Adapter graphics mode display memory at A000:0000.
|
||
;
|
||
mov ax,0010h
|
||
int 10h; select hi-res EGA graphics
|
||
; mode 10 hex (AH=0 selects
|
||
; BIOS set mode function,
|
||
; with AL=mode to select)
|
||
;
|
||
mov ax,0a000h
|
||
mov ds,ax
|
||
mov es,ax ;move to & from same segment
|
||
sub si,si ;move to & from same offset
|
||
mov di,si
|
||
mov cx,800h ;move 2K words
|
||
cld
|
||
call ZTimerOn
|
||
rep movsw ;simply read each of the first
|
||
; 2K words of the destination segment,
|
||
; writing each byte immediately back
|
||
; to the same address. No memory
|
||
; locations are actually altered; this
|
||
; is just to measure memory access
|
||
; times
|
||
call ZTimerOff
|
||
;
|
||
mov ax,0003h
|
||
int 10h ;return to text mode
|
||
|
||
For comparison, let’s see how long the same code takes when accessing
|
||
normal system RAM instead of display memory. The code in Listing 4.12,
|
||
which performs a **REP MOVSW** from the code segment to the code
|
||
segment, executes in 1.39 µs per display memory access. That means that
|
||
on average, 1.79 µs (more than 8 cycles!) are lost to the display
|
||
adapter cycle-eater on each access. In other words, the display adapter
|
||
cycle-eater can *more than double* the execution time of 8088 code!
|
||
|
||
**LISTING 4.12 LST4-12.ASM**
|
||
|
||
; Times speed of memory access to normal system
|
||
; memory.
|
||
;
|
||
mov ax,ds
|
||
mov es,ax ;move to & from same segment
|
||
sub si,si ;move to & from same offset
|
||
mov di,si
|
||
mov cx,800h ;move 2K words
|
||
cld
|
||
call ZTimerOn
|
||
rep movsw ;simply read each of the first
|
||
; 2K words of the destination segment,
|
||
; writing each byte immediately back
|
||
; to the same address. No memory
|
||
; locations are actually altered; this
|
||
; is just to measure memory access
|
||
; times
|
||
call ZTimerOff
|
||
|
||
Bear in mind that we’re talking about a worst case here; the impact of
|
||
the display adapter cycle-eater is proportional to the percent of time a
|
||
given code sequence spends accessing display memory.
|
||
|
||
------------------------ --------------------------------- --------------------
|
||
[Previous](04-08.html) [Table of Contents](index.html) [Next](04-10.html)
|
||
------------------------ --------------------------------- --------------------
|
||
|
||
* * * * *
|
||
|
||
Graphics Programming Black Book © 2001 Michael Abrash
|