Change bold code snippets to inline code blocks

26-03.md

@@ -20,7 +20,7 @@ without rotation characters could only be drawn on byte boundaries.
 > ![](images/i.jpg)
 > As I pointed out in Chapter 25, the CPU is perfectly capable of rotating
 > the data itself, and it's often the case that that's more efficient. The
-> problem with using the Data Rotate register is that the **OUT** that
+> problem with using the Data Rotate register is that the `OUT` that
 > sets that register is time-consuming, especially for proportional text,
 > which requires a different rotation for each character. Also, if the
 > code performs full-byte accesses to display memory—that is, if it
@@ -68,7 +68,7 @@ character to the left of the byte boundary) and then draw the left
 portions only of all 40 characters in write mode 3. Then the bit mask
 could be set up for the right portion of each character, and the right
 portions of all 40 characters could be drawn. The VGA's fast rotator
-would be used to do all rotation, and the only **OUT**s required would
+would be used to do all rotation, and the only `OUT`s required would
 be those required to set the bit mask and data rotation. This technique
 could well outperform single-character bit-mapped text drivers such as
 the one in Listing 26.1 by a significant margin. Listing 26.2
@@ -425,7 +425,7 @@ by ANDing in software. Even more significantly, we would have the CPU
 combine adjacent characters into complete, rotated bytes whenever
 possible, so that only one drawing operation would be required per byte
 of display memory modified. By doing this, we would eliminate all
-per-character **OUT**s, and would minimize display memory accesses,
+per-character `OUT`s, and would minimize display memory accesses,
 approximately doubling text-drawing speed.
 
 As a final note, consider that non-transparent text could also be