Normal quotes

04-08.md

@@ -5,17 +5,17 @@
 Wait states exist because the CPU must to be able to coexist with any
 adapter, no matter how slow (within reason). The 8088 expects to be able
 to complete each bus access—a memory or I/O read or write—in 4 cycles,
-but adapters can’t always respond that quickly for a number of reasons.
+but adapters can't always respond that quickly for a number of reasons.
 For example, display adapters must split access to display memory
 between the CPU and the circuitry that generates the video signal based
-on the contents of display memory, so they often can’t immediately
+on the contents of display memory, so they often can't immediately
 fulfill a request by the CPU for a display memory read or write. To
 resolve this conflict, display adapters can tell the CPU to wait during
 bus accesses by inserting one or more wait states, as shown in Figure
 4.6. The CPU simply sits and idles as long as wait states are inserted,
 then completes the access as soon as the display adapter indicates its
 readiness by no longer inserting wait states. The same would be true of
-any adapter that couldn’t keep up with the CPU.
+any adapter that couldn't keep up with the CPU.
 
 Mind you, this is all transparent to executing code. An instruction that
 encounters wait states runs exactly as if there were no wait states,
@@ -23,11 +23,11 @@ only slower. Wait states are nothing more or less than wasted time as
 far as the CPU and your program are concerned.
 
 By understanding the circumstances in which wait states can occur, you
-can avoid them when possible. Even when it’s not possible to work around
-wait states, it’s still to your advantage to understand how they can
+can avoid them when possible. Even when it's not possible to work around
+wait states, it's still to your advantage to understand how they can
 cause your code to run more slowly.
 
-First, let’s learn a bit more about wait states by contrast with DRAM
+First, let's learn a bit more about wait states by contrast with DRAM
 refresh. Unlike DRAM refresh, wait states do not occur on any regularly
 scheduled basis, and are of no particular duration. Wait states can only
 occur when an instruction performs a memory or I/O read or write. Both
@@ -43,9 +43,9 @@ perform the access.
 ![](images/04-06.jpg)\
  **Figure 4.6**  *Video wait states inserted by the display adapter.*
 
-As with DRAM refresh, wait states don’t stop the 8088 completely. The
+As with DRAM refresh, wait states don't stop the 8088 completely. The
 Execution Unit can continue processing while wait states are inserted,
-so long as the EU doesn’t need to perform a bus access. However, in the
+so long as the EU doesn't need to perform a bus access. However, in the
 PC, wait states most often occur when an instruction accesses a memory
 operand, so in fact the Execution Unit usually is stopped by wait
 states. (Instruction fetches rarely wait in an 8088-based PC because
@@ -96,11 +96,11 @@ VGA clones.)
 ![](images/04-07.jpg)\
  **Figure 4.7**  *Allocation of display memory access.*
 
-Second, because the displayed dots (or *pixels,* short for “picture
-elements”) must be drawn on the screen at a constant speed, many display
+Second, because the displayed dots (or *pixels,* short for "picture
+elements") must be drawn on the screen at a constant speed, many display
 adapters provide memory accesses only at fixed intervals. As a result,
 time can be lost while the 8088 synchronizes with the start of the next
-display adapter memory access, even if the video circuitry isn’t
+display adapter memory access, even if the video circuitry isn't
 accessing display memory at that time, as shown in Figure 4.8.
 
 Finally, the time it takes a display adapter to complete a memory access
@@ -110,27 +110,27 @@ the time taken for display memory to complete an 8088 read or write
 access is often longer than the time taken for system memory to complete
 an access, even if the 8088 lucks into hitting a free display memory
 access just as it becomes available, again as shown in Figure 4.8. Any
-or all of the three factors I’ve described can result in wait states,
+or all of the three factors I've described can result in wait states,
 slowing the 8088 and creating the display adapter cycle.
 
 ![](images/04-08.jpg)\
  **Figure 4.8**  *Display memory access slots.*
 
-If some of this is Greek to you, don’t worry. The important point is
+If some of this is Greek to you, don't worry. The important point is
 that display memory is not very fast compared to normal system memory.
-How slow is it? *Incredibly* slow. Remember how slow IBM’s ill-fated
-PC*jr*was? In case you’ve forgotten, I’ll refresh your memory: The
+How slow is it? *Incredibly* slow. Remember how slow IBM's ill-fated
+PC*jr*was? In case you've forgotten, I'll refresh your memory: The
 PC*jr*was at best only half as fast as the PC. The PC*jr* had an 8088
 running at 4.77 MHz, just like the PC—why do you suppose it was so much
-slower? I’ll tell you why: *All the memory in the PCjr was display
+slower? I'll tell you why: *All the memory in the PCjr was display
 memory.*
 
 Enough said. All the memory in the PC is *not* display memory, however,
-and unless you’re thickheaded enough to put code in display memory, the
-PC isn’t going to run as slowly as a PC*jr.* (Putting code or other
+and unless you're thickheaded enough to put code in display memory, the
+PC isn't going to run as slowly as a PC*jr.* (Putting code or other
 non-video data in unused areas of display memory sounds like a neat
 idea—until you consider the effect on instruction prefetching of cutting
-the 8088’s already-poor memory access performance in half. Running your
+the 8088's already-poor memory access performance in half. Running your
 code from display memory is sort of like running on a hypothetical
 8084—an 8086 with a *4-bit* bus. Not recommended!) Given that your code
 and data reside in normal system memory below the 640K mark, how great