Normal quotes

03-04.md

@@ -22,7 +22,7 @@ interrupt. Recall that **ZTimerOn** initially sets timer 0 to 0, in
 order to allow for the longest possible period—about 54 ms—before timer
 0 reaches 0 and generates the timer interrupt.
 
-Now we’re ready to look at the ways in which the Zen timer can introduce
+Now we're ready to look at the ways in which the Zen timer can introduce
 inaccuracy into the system clock. Since timer 0 is initially set to 0 by
 the Zen timer, and since the system clock ticks only when timer 0 counts
 off 54.925 ms and reaches 0 again, an average inaccuracy of one-half of
@@ -42,10 +42,10 @@ Zen timer. The 8259 interrupt controller is capable of remembering at
 most one pending timer interrupt, so all timer interrupts after the
 first one during any given Zen timing interval are ignored.
 Consequently, if a timing interval exceeds 54.9 ms, the system clock
-effectively stops 54.9 ms after the timing interval starts and doesn’t
+effectively stops 54.9 ms after the timing interval starts and doesn't
 restart until the timing interval ends, losing time all the while.
 
-The effects on the system time of the Zen timer aren’t a matter for
+The effects on the system time of the Zen timer aren't a matter for
 great concern, as they are temporary, lasting only until the next warm
 or cold boot. System that have batteryclocks, (AT-style machines; that
 is, virtually all machines in common use) automatically reset the
@@ -56,7 +56,7 @@ by at most a total of a few seconds, unless code that takes much longer
 than 54 ms to run is timed (in which case the Zen timer will notify you
 that the code is too long to time).
 
-Nonetheless, it’s a good idea to reboot your computer at the end of each
+Nonetheless, it's a good idea to reboot your computer at the end of each
 session with the Zen timer in order to make sure that the system clock
 is correct.
 
@@ -83,12 +83,12 @@ including the state of the interrupt flag that was in effect when
 **ZTimerOn** was called to start timing, and returns.
 
 One interesting aspect of **ZTimerOff** is the manner in which timer 0
-is stopped in order to read the timer count. We don’t actually have to
+is stopped in order to read the timer count. We don't actually have to
 stop timer 0 to read the count; the 8253 provides a special latched read
 feature for the specific purpose of reading the count while a time is
-running. (That’s a good thing, too; we’ve no documented way to stop
-timer 0 if we wanted to, since its gate input isn’t connected. Later in
-this chapter, though, we’ll see that timer 0 can be stopped after all.)
+running. (That's a good thing, too; we've no documented way to stop
+timer 0 if we wanted to, since its gate input isn't connected. Later in
+this chapter, though, we'll see that timer 0 can be stopped after all.)
 We simply tell the 8253 to latch the current count, and the 8253 does so
 without breaking stride.
 
@@ -113,7 +113,7 @@ ZTimerReport** can be called at any time right up until the next call to
 You may want to use the Zen timer to measure several portions of a
 program while it executes normally, in which case it may not be
 desirable to have the text printed by **ZTimerReport** interfere with
-the program’s normal display. There are many ways to deal with this. One
+the program's normal display. There are many ways to deal with this. One
 approach is removal of the invocations of the DOS print string function
 (INT 21H with AH equal to 9) from **ZTimerReport**, instead running the
 program under a debugger that supports screen flipping (such as Turbo
@@ -144,7 +144,7 @@ be stored in a buffer within the driver, to be dumped at a later time.
 David Miller for passing the idea on to me.)
 
 You may well want to devise still other approaches better suited to your
-needs than those I’ve presented. Go to it! I’ve just thrown out a few
+needs than those I've presented. Go to it! I've just thrown out a few
 possibilities to get you started.
 
   ------------------------ --------------------------------- --------------------