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

Deduped images

Browse source
This commit is contained in:
James Gregory 2013-12-30 12:25:34 +11:00
commit 9e52de9586
233 changed files with 128 additions and 128 deletions
Download patch file Download diff file Expand all files Collapse all files

2
11-05.html
View file

@ -42,7 +42,7 @@
<P>In other words, instructions that access display memory won&#146;t run a whole lot faster on ATs and faster computers than they do on PCs. That explains one of the two viewpoints expressed at the beginning of this section: The display adapter cycle-eater is just about the same on high-end computers as it is on the PC, in the sense that it allows instructions that access display memory to run at just about the same speed on all computers.</P>
<P>Of course, the picture is quite a bit different when you compare the performance of instructions that access display memory to the <I>maximum</I> performance of those instructions. Instructions that access display memory receive many more wait states when running on a 286 than they do on an 8088. Why? While the 286 is capable of accessing memory much more often than the 8088, we&#146;ve seen that the frequency of access to display memory is determined not by processor speed but by the display adapter itself. As a result, both processors are actually allowed just about the same maximum number of accesses to display memory in any given time. By definition, then, the 286 must spend many more cycles waiting than does the 8088.</P>
<P>And that explains the second viewpoint expressed above regarding the display adapter cycle-eater vis-a-vis the 286 and 386. The display adapter cycle-eater, as measured in cycles lost to wait states, is indeed much worse on AT-class computers than it is on the PC, and it&#146;s worse still on more powerful computers.</P>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/11-05i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>How bad is the display adapter cycle-eater on an AT? It&#146;s this bad: Based on my (not inconsiderable) experience in timing display adapter access, I&#146;ve found that the display adapter cycle-eater can slow an AT&#151;or even a 386 computer&#151;to near-PC speeds when display memory is accessed.</I></SMALL>
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>How bad is the display adapter cycle-eater on an AT? It&#146;s this bad: Based on my (not inconsiderable) experience in timing display adapter access, I&#146;ve found that the display adapter cycle-eater can slow an AT&#151;or even a 386 computer&#151;to near-PC speeds when display memory is accessed.</I></SMALL>
</TABLE>
<P>I know that&#146;s hard to believe, but the display adapter cycle-eater gives out just so many display memory accesses in a given time, and no more, no matter how fast the processor is. In fact, the faster the processor, the more the display adapter cycle-eater hurts the performance of instructions that access display memory. The display adapter cycle-eater is not only still present in 286/386 computers, it&#146;s worse than ever.
</P>