Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Change bold code snippets to inline code blocks

Browse source
This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions
Download patch file Download diff file Expand all files Collapse all files

22
03-03.md
View file

@ -27,8 +27,8 @@ and you'll be on the right road.
#### Starting the Zen Timer {#Heading6}
**ZTimerOn** is called at the start of a segment of code to be timed.
**ZTimerOn** saves the context of the calling code, disables interrupts,
`ZTimerOn` is called at the start of a segment of code to be timed.
`ZTimerOn` saves the context of the calling code, disables interrupts,
sets timer 0 of the 8253 to mode 2 (divide-by-N mode), sets the initial
timer count to 0, restores the context of the calling code, and returns.
(I'd like to note that while Intel's documentation for the 8253 seems to
@ -36,21 +36,21 @@ indicate that a timer won't reset to 0 until it finishes counting down,
in actual practice, timers seem to reset to 0 as soon as they're
loaded.)
Two aspects of **ZTimerOn** are worth discussing further. One point of
interest is that **ZTimerOn** disables interrupts. (**ZTimerOff** later
restores interrupts to the state they were in when **ZTimerOn** was
called.) Were interrupts not disabled by **ZTimerOn**, keyboard, mouse,
Two aspects of `ZTimerOn` are worth discussing further. One point of
interest is that `ZTimerOn` disables interrupts. (`ZTimerOff` later
restores interrupts to the state they were in when `ZTimerOn` was
called.) Were interrupts not disabled by `ZTimerOn`, keyboard, mouse,
timer, and other interrupts could occur during the timing interval, and
the time required to service those interrupts would incorrectly and
erratically appear to be part of the execution time of the code being
measured. As a result, code timed with the Zen timer should not expect
any hardware interrupts to occur during the interval between any call to
**ZTimerOn** and the corresponding call to **ZTimerOff**, and should not
`ZTimerOn` and the corresponding call to `ZTimerOff`, and should not
enable interrupts during that time.
### Time and the PC {#Heading7}
A second interesting point about **ZTimerOn** is that it may introduce
A second interesting point about `ZTimerOn` is that it may introduce
some small inaccuracy into the system clock time whenever it is called.
To understand why this is so, we need to examine the way in which both
the 8253 and the PC's system clock (which keeps the current time) work.
@ -89,11 +89,11 @@ connected to the hardware interrupt 0 (IRQ0) line on the system board,
so every 54.925 ms, timer 0 causes hardware interrupt 0 to occur.
The interrupt vector for IRQ0 is set by the BIOS at power-up time to
point to a BIOS routine, **TIMER\_INT,** that maintains a time-of-day
count. **TIMER\_INT** keeps a 16-bit count of IRQ0 interrupts in the
point to a BIOS routine, `TIMER_INT`, that maintains a time-of-day
count. `TIMER_INT` keeps a 16-bit count of IRQ0 interrupts in the
BIOS data area at address 0000:046C (all addresses in this book are
given in segment:offset hexadecimal pairs); this count turns over once
an hour (less a few microseconds), and when it does, **TIMER\_INT**
an hour (less a few microseconds), and when it does, `TIMER_INT`
updates a 16-bit hour count at address 0000:046E in the BIOS data area.
This count is the basis for the current time and date that DOS supports
via functions 2AH (2A hexadecimal) through 2DH and by way of the DATE