Change bold code snippets to inline code blocks

03-05.md

@@ -13,7 +13,7 @@ pages: 048-050
 ### Notes on the Zen Timer {#Heading10}
 
 The Zen timer subroutines are designed to be near-called from assembly
-language code running in the public segment **Code**. The Zen timer
+language code running in the public segment `Code`. The Zen timer
 subroutines can, however, be called from any assembly or high-level
 language code that generates OBJ files that are compatible with the
 Microsoft linker, simply by modifying the segment that the timer code
@@ -26,9 +26,9 @@ transparent to the calling code.
 
 If you do change the Zen timer routines to far procedures in order to
 call them from code running in another segment, be sure to make *all*
-the Zen timer routines far, including **ReferenceZTimerOn** and
-**ReferenceZTimerOff**. (You'll have to put **FAR PTR** overrides on the
-calls from **ZTimerOff** to the latter two routines if you do make them
+the Zen timer routines far, including `ReferenceZTimerOn` and
+`ReferenceZTimerOff`. (You'll have to put `FAR PTR` overrides on the
+calls from `ZTimerOff` to the latter two routines if you do make them
 far.) If the reference routines aren't the same type—near or far—as the
 other routines, they won't reflect the true overhead incurred by
 starting and stopping the Zen timer.
@@ -76,9 +76,9 @@ computers.
 Listing 3.2 shows a test-bed program for measuring code performance with
 the Zen timer. This program sets DS equal to CS (for reasons we'll
 discuss shortly), includes the code to be measured from the file
-TESTCODE, and calls **ZTimerReport** to display the timing results.
+TESTCODE, and calls `ZTimerReport` to display the timing results.
 Consequently, the code being measured should be in the file TESTCODE,
-and should contain calls to **ZTimerOn** and **ZTimerOff** .
+and should contain calls to `ZTimerOn` and `ZTimerOff` .
 
 **LISTING 3.2 PZTEST.ASM**
 
@@ -124,10 +124,10 @@ Code  ends
 
 Listing 3.3 shows some sample code to be timed. This listing measures
 the time required to execute 1,000 loads of AL from the memory variable
-**MemVar** . Note that Listing 3.3 calls **ZTimerOn** to start timing,
-performs 1,000 **MOV** instructions in a row, and calls **ZTimerOff** to
+`MemVar` . Note that Listing 3.3 calls `ZTimerOn` to start timing,
+performs 1,000 `MOV` instructions in a row, and calls `ZTimerOff` to
 end timing. When Listing 3.2 is named TESTCODE and included by Listing
-3.3, Listing 3.2 calls **ZTimerReport** to display the execution time
+3.3, Listing 3.2 calls `ZTimerReport` to display the execution time
 after the code in Listing 3.3 has been run.
 
 **LISTING 3.3 LST3-3.ASM**
@@ -160,7 +160,7 @@ Skip:
 ```
 
 It's worth noting that Listing 3.3 begins by jumping around the memory
-variable **MemVar**. This approach lets us avoid reproducing Listing 3.2
+variable `MemVar`. This approach lets us avoid reproducing Listing 3.2
 in its entirety for each code fragment we want to measure; by defining
 any needed data right in the code segment and jumping around that data,
 each listing becomes self-contained and can be plugged directly into
@@ -169,7 +169,7 @@ anything else precisely so that data can be embedded in code fragments
 being timed. Note that only after the initial jump is performed in
 Listing 3.3 is the Zen timer started, since we don't want to include the
 execution time of start-up code in the timing interval. That's why the
-calls to **ZTimerOn** and **ZTimerOff** are in TESTCODE, not in
+calls to `ZTimerOn` and `ZTimerOff` are in TESTCODE, not in
 PZTEST.ASM; this way, we have full control over which portion of
 TESTCODE is timed, and we can keep set-up code and the like out of the
 timing interval.