Change bold code snippets to inline code blocks

03-04.md

@@ -26,7 +26,7 @@ see whether an IRQ0 interrupt is pending. (Remember, interrupts are off
 while the Zen timer runs, so the timer interrupt cannot be recognized
 until the Zen timer stops and enables interrupts.) If an IRQ0 interrupt
 is pending, then timer 0 has turned over and generated a timer
-interrupt. Recall that **ZTimerOn** initially sets timer 0 to 0, in
+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.
 
@@ -39,7 +39,7 @@ started. In addition, a timer interrupt is generated when timer 0 is
 switched from mode 3 to mode 2, advancing the system clock by up to
 54.925 ms, although this only happens the first time the Zen timer is
 run after a warm or cold boot. Finally, up to 54.925 ms can again be
-lost when **ZTimerOff** is called, since that routine again sets the
+lost when `ZTimerOff` is called, since that routine again sets the
 timer count to zero. Net result: The system clock will run up to 110 ms
 (about a ninth of a second) slow each time the Zen timer is used.
 
@@ -70,27 +70,27 @@ is correct.
 
 ### Stopping the Zen Timer {#Heading8}
 
-At some point after **ZTimerOn** is called, **ZTimerOff** must always be
-called to mark the end of the timing interval. **ZTimerOff** saves the
+At some point after `ZTimerOn` is called, `ZTimerOff` must always be
+called to mark the end of the timing interval. `ZTimerOff` saves the
 context of the calling program, latches and reads the timer 0 count,
 converts that count from the countdown value that the timer maintains to
-the number of counts elapsed since **ZTimerOn** was called, and stores
+the number of counts elapsed since `ZTimerOn` was called, and stores
 the result. Immediately after latching the timer 0 count—and before
-enabling interrupts—**ZTimerOff** checks the 8259 interrupt controller
+enabling interrupts—`ZTimerOff` checks the 8259 interrupt controller
 to see if there is a pending timer interrupt, setting a flag to mark
 that the timer overflowed if there is indeed a pending timer interrupt.
 
-After that, **ZTimerOff** executes just the overhead code of
-**ZTimerOn** and **ZTimerOff** 16 times, and averages and saves the
+After that, `ZTimerOff` executes just the overhead code of
+`ZTimerOn` and `ZTimerOff` 16 times, and averages and saves the
 results in order to determine how many of the counts in the timing
 result just obtained were incurred by the overhead of the Zen timer
 rather than by the code being timed.
 
-Finally, **ZTimerOff** restores the context of the calling program,
+Finally, `ZTimerOff` restores the context of the calling program,
 including the state of the interrupt flag that was in effect when
-**ZTimerOn** was called to start timing, and returns.
+`ZTimerOn` was called to start timing, and returns.
 
-One interesting aspect of **ZTimerOff** is the manner in which timer 0
+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
 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
@@ -102,48 +102,48 @@ without breaking stride.
 
 ### Reporting Timing Results {#Heading9}
 
-**ZTimerReport** may be called to display timing results at any time
-after both **ZTimerOn** and **ZTimerOff** have been called.
-**ZTimerReport** first checks to see whether the timer overflowed
-(counted down to 0 and turned over) before **ZTimerOff** was called; if
-overflow did occur, **ZTimerOff** prints a message to that effect and
-returns. Otherwise, **ZTimerReport** subtracts the reference count
+`ZTimerReport` may be called to display timing results at any time
+after both `ZTimerOn` and `ZTimerOff` have been called.
+`ZTimerReport` first checks to see whether the timer overflowed
+(counted down to 0 and turned over) before `ZTimerOff` was called; if
+overflow did occur, `ZTimerOff` prints a message to that effect and
+returns. Otherwise, `ZTimerReport` subtracts the reference count
 (representing the overhead of the Zen timer) from the count measured
-between the calls to **ZTimerOn** and **ZTimerOff**, converts the result
+between the calls to `ZTimerOn` and `ZTimerOff`, converts the result
 from timer counts to microseconds, and prints the resulting time in
 microseconds to the standard output.
 
-Note that **ZTimerReport** need not be called immediately after
-**ZTimerOff**. In fact, after a given call to **ZTimerOff,
-ZTimerReport** can be called at any time right up until the next call to
-**ZTimerOn**.
+Note that `ZTimerReport` need not be called immediately after
+`ZTimerOff`. In fact, after a given call to `ZTimerOff,
+ZTimerReport` can be called at any time right up until the next call to
+`ZTimerOn`.
 
 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
+desirable to have the text printed by `ZTimerReport` interfere with
 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
+(INT 21H with AH equal to 9) from `ZTimerReport`, instead running the
 program under a debugger that supports screen flipping (such as Turbo
 Debugger or CodeView), placing a breakpoint at the start of
-**ZTimerReport**, and directly observing the count in microseconds as
-**ZTimerReport** calculates it.
+`ZTimerReport`, and directly observing the count in microseconds as
+`ZTimerReport` calculates it.
 
-A second approach is modification of **ZTimerReport** to place the
+A second approach is modification of `ZTimerReport` to place the
 result at some safe location in memory, such as an unused portion of the
 BIOS data area.
 
-A third approach is alteration of **ZTimerReport** to print the result
+A third approach is alteration of `ZTimerReport` to print the result
 over a serial port to a terminal or to another PC acting as a terminal.
 Similarly, many debuggers can be run from a remote terminal via a serial
 link.
 
-Yet another approach is modification of **ZTimerReport** to send the
+Yet another approach is modification of `ZTimerReport` to send the
 result to the printer via either DOS function 5 or BIOS interrupt 17H.
 
-A final approach is to modify **ZTimerReport** to print the result to
+A final approach is to modify `ZTimerReport` to print the result to
 the auxiliary output via DOS function 4, and to then write and load a
-special device driver named **AUX**, to which DOS function 4 output
+special device driver named `AUX`, to which DOS function 4 output
 would automatically be directed. This device driver could send the
 result anywhere you might desire. The result might go to the secondary
 display adapter, over a serial port, or to the printer, or could simply