Remove colour attributes from body and strip most of the font tags out

04-09.html

@@ -24,7 +24,7 @@
 <!--CHAPTER=4//-->
 <!--PAGES=104-106//-->
 <!--UNASSIGNED1//-->
-<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
+<!--UNASSIGNED2//--></HEAD><body>
 
 <CENTER>
 <TABLE BORDER>
@@ -38,7 +38,7 @@
 <P><BR></P>
 <P>The answer varies considerably depending on what display adapter and what display mode we&rsquo;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&rsquo;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&rsquo;ll restrict our discussion to the VGA (and its close relative, the EGA) for the remainder of this chapter.
 </P>
-<H4 ALIGN="LEFT"><A NAME="Heading21"></A><FONT COLOR="#000077">The Impact of the Display Adapter Cycle-Eater</FONT></H4>
+<H4 ALIGN="LEFT"><A NAME="Heading21"></A>The Impact of the Display Adapter Cycle-Eater</H4>
 <P>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&rsquo;s not that the cycle-eater isn&rsquo;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&rsquo;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&micro;s per display memory access&mdash;more than five times normal&mdash;it would still take only 4,000x 2x 5&micro;s, or 40 &micro;s, to read and write every byte of display memory. That&rsquo;s a lot of time as measured in 8088 cycles, but it&rsquo;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.
 </P>
 <P>That&rsquo;s not to say that the display adapter cycle-eater <I>can&rsquo;t</I> 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&rsquo;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&rsquo;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 <I>are</I> display memory wait states as well, however, so the calculations were not just optimistic but wildly optimistic.</P>
@@ -116,7 +116,7 @@
 
 <hr width="90%" size="1" noshade>
 <div align="center">
-<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
+Graphics Programming Black Book &copy; 2001 Michael Abrash
 </div>
 <!-- all of the reference materials (books) have the footer and subfoot reveresed -->
 <!-- reference_subfoot = footer -->