Normal quotes

34-04.md

@@ -18,7 +18,7 @@ directly with **OUT**s.
 If **USE\_BIOS** is 1, the only other equate of interest is
 **WAIT\_VSYNC**. If **WAIT\_VSYNC** is 1, the program waits for the
 leading edge of vertical sync before loading the DAC; if **WAIT\_VSYNC**
-is 0, the program doesn’t wait before loading. The effect of setting or
+is 0, the program doesn't wait before loading. The effect of setting or
 not setting **WAIT\_VSYNC** depends on whether the BIOS of the VGA the
 program is running on waits for vertical sync before loading the DAC.
 You may end up with a double wait, causing color cycling to proceed at
@@ -36,7 +36,7 @@ program loads the DAC non-stop.
 If **USE\_BIOS** is 0, **GUARD\_AGAINST\_INTS** determines whether the
 possibility of the DAC loading process being interrupted is guarded
 against by disabling interrupts and setting the write index once for
-every location loaded and whether the DAC’s autoincrementing feature is
+every location loaded and whether the DAC's autoincrementing feature is
 relied upon or not.
 
 If **GUARD\_AGAINST\_INTS** is 1, the following sequence is followed for
@@ -62,31 +62,31 @@ sequence will be interrupted and the DAC registers will become garbled.
 My own experience with Listing 34.1 indicates that it is sometimes
 possible to load all 256 locations cleanly but sometimes it is not; it
 all depends on the processor, the bus speed, the VGA, and the DAC, as
-well as whether autoincrementation and **REP OUTSB** are used. I’m not
+well as whether autoincrementation and **REP OUTSB** are used. I'm not
 going to bother to report how many DAC locations I *could* successfully
 load with each of the various approaches, for the simple reason that I
-don’t have enough data points to make reliable suggestions, and I don’t
+don't have enough data points to make reliable suggestions, and I don't
 want you acting on my comments and running into trouble down the pike.
 You now have a versatile tool with which to probe the limitations of
 various DAC-loading approaches; use it to perform your own tests on a
 sampling of the slowest hardware configurations you expect your programs
 to run on, then leave a generous safety margin.
 
-One thing’s for sure, though—you’re not going to be able to cycle all
+One thing's for sure, though—you're not going to be able to cycle all
 256 DAC locations cleanly once per frame on a reliable basis across the
-current generation of PCs. That’s why I said at the outset that brute
-force isn’t appropriate to the task of color cycling. That doesn’t mean
-that color cycling can’t be used, just that subtler approaches must be
-employed. Let’s look at some of those alternatives.
+current generation of PCs. That's why I said at the outset that brute
+force isn't appropriate to the task of color cycling. That doesn't mean
+that color cycling can't be used, just that subtler approaches must be
+employed. Let's look at some of those alternatives.
 
 ### Color Cycling Approaches that Work {#Heading8}
 
-First of all, I’d like to point out that when color cycling does work,
-it’s a thing of beauty. Assemble Listing 34.1 so that it doesn’t use the
-BIOS to load the DAC, doesn’t guard against interrupts, and uses
+First of all, I'd like to point out that when color cycling does work,
+it's a thing of beauty. Assemble Listing 34.1 so that it doesn't use the
+BIOS to load the DAC, doesn't guard against interrupts, and uses
 286-specific instructions if your computer supports them. Then tinker
 with **CYCLE\_SIZE** until the color cycling is perfectly clean on your
-computer. Color cycling looks stunningly smooth, doesn’t it? And this is
+computer. Color cycling looks stunningly smooth, doesn't it? And this is
 crude color cycling, working with the default color set; switch over to
 a color set that gradually works its way through various hues and
 saturations, and you could get something that looks for all the world