Change bold code snippets to inline code blocks

55-02.md

@@ -16,7 +16,7 @@ and X-Sharp represents colors internally as ideal, device-independent
 triplets, with 24-bit color precision. It's only after the final 24-bit
 RGB drawing color is calculated that the display adapter's color
 capabilities come into play, as the X-Sharp function
-**ModelColorToColorIndex()** is called to map the desired RGB color to
+`ModelColorToColorIndex()` is called to map the desired RGB color to
 the closest match the adapter is capable of displaying. Of course, that
 mapping is adapter-dependent. On a 24-bpp device, it's pretty obvious
 how the internal RGB color format maps to displayed pixel colors:
@@ -28,7 +28,7 @@ straight to display pixels. But how on earth do we map those
 This is the "color definition" problem I mentioned at the start of this
 chapter. The VGA palette is arbitrarily programmable to any set of 256
 colors, with each color defined by six bits each of red, green, and blue
-intensity. In X-Sharp, the function **InitializePalette()** can be
+intensity. In X-Sharp, the function `InitializePalette()` can be
 customized to set up the palette however we wish; this gives us nearly
 complete flexibility in defining the working color set. Even with
 infinite flexibility, however, 256 out of 16,000,000 or so possible
@@ -41,7 +41,7 @@ One way to deal with the limited simultaneous color capabilities of the
 VGA is to build an application that uses only a subset of RGB space,
 then bias the VGA's palette toward that subspace. This is the approach
 used in the DEMO1 sample program in X-Sharp; Listings 55.2 and 55.3 show
-the versions of **InitializePalette()** and **ModelColorToColorIndex()**
+the versions of `InitializePalette()` and `ModelColorToColorIndex()`
 that set up and perform the color mapping for DEMO1.
 
 **LISTING 55.2 L55-2.C**