Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

32
04-09.md
View file

@ -3,43 +3,43 @@
------------------------ --------------------------------- --------------------
The answer varies considerably depending on what display adapter and
what display mode we’re talking about. The display adapter cycle-eater
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
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
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
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
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
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
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. (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;
@ -63,15 +63,15 @@ 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,
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
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
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.
@ -107,7 +107,7 @@ long as we had assumed, but a long time nonetheless.
mov ax,0003h
int 10h ;return to text mode
For comparison, let’s see how long the same code takes when accessing
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
@ -136,7 +136,7 @@ cycle-eater can *more than double* the execution time of 8088 code!
; times
call ZTimerOff
Bear in mind that we’re talking about a worst case here; the impact of
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.