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

38
34-04.md
View file

@ -15,19 +15,19 @@ directly? With interrupts enabled or disabled? *Et cetera?*
However you like, actually. Four equates at the top of Listing 34.1
select the sort of color cycling performed; by changing these equates
and **CYCLE\_SIZE**, you can get a feel for how well various approaches
and `CYCLE_SIZE`, you can get a feel for how well various approaches
to color cycling work with whatever combination of computer system and
VGA you care to test.
The **USE\_BIOS** equate is simple. Set **USE\_BIOS** to 1 to load the
The `USE_BIOS` equate is simple. Set `USE_BIOS` to 1 to load the
DAC through the block-load-DAC BIOS function, or to 0 to load the DAC
directly with **OUT**s.
directly with `OUT`s.
If **USE\_BIOS** is 1, the only other equate of interest is
**WAIT\_VSYNC**. If **WAIT\_VSYNC** is 1, the program waits for the
leading edge of vertical sync before loading the DAC; if **WAIT\_VSYNC**
If `USE_BIOS` is 1, the only other equate of interest is
`WAIT_VSYNC`. If `WAIT_VSYNC` is 1, the program waits for the
leading edge of vertical sync before loading the DAC; if `WAIT_VSYNC`
is 0, the program doesn't wait before loading. The effect of setting or
not setting **WAIT\_VSYNC** depends on whether the BIOS of the VGA the
not setting `WAIT_VSYNC` depends on whether the BIOS of the VGA the
program is running on waits for vertical sync before loading the DAC.
You may end up with a double wait, causing color cycling to proceed at
half speed, you may end up with no wait at all, causing cycling to occur
@ -35,42 +35,42 @@ far too rapidly (and almost certainly with hideous on-screen effects),
or you may actually end up cycling at the proper one-cycle-per-frame
rate.
If **USE\_BIOS** is 0, **WAIT\_VSYNC** still applies. However, you will
always want to set **WAIT\_VSYNC** to 1 when **USE\_BIOS** is 0;
If `USE_BIOS` is 0, `WAIT_VSYNC` still applies. However, you will
always want to set `WAIT_VSYNC` to 1 when `USE_BIOS` is 0;
otherwise, cycling will occur much too fast, and a good deal of
continuous on-screen garbage is likely to make itself evident as the
program loads the DAC non-stop.
If **USE\_BIOS** is 0, **GUARD\_AGAINST\_INTS** determines whether the
If `USE_BIOS` is 0, `GUARD_AGAINST_INTS` determines whether the
possibility of the DAC loading process being interrupted is guarded
against by disabling interrupts and setting the write index once for
every location loaded and whether the DAC's autoincrementing feature is
relied upon or not.
If **GUARD\_AGAINST\_INTS** is 1, the following sequence is followed for
If `GUARD_AGAINST_INTS` is 1, the following sequence is followed for
the loading of each DAC location in turn: Interrupts are disabled, the
DAC Write Index register is set appropriately, the RGB triplet for the
location is written to the DAC Data register, and interrupts are
enabled. This is the slow but safe approach described earlier.
Matters get still more interesting if **GUARD\_AGAINST\_INTS** is 0. In
that case, if **NOT\_8088** is 0, then an autoincrementing load is
Matters get still more interesting if `GUARD_AGAINST_INTS` is 0. In
that case, if `NOT_8088` is 0, then an autoincrementing load is
performed in a straightforward fashion; the DAC Write Index register is
set to the index of the first location to load and the RGB triplet is
sent to the DAC by way of three **LODSB/OUT DX,AL** pairs, with **LOOP**
sent to the DAC by way of three `LODSB/OUT DX,AL` pairs, with `LOOP`
repeating the process for each of the locations in turn.
If, however, **NOT\_8088** is 1, indicating that the processor is a 286
or better (perhaps **AT\_LEAST\_286** would have been a better name),
If, however, `NOT_8088` is 1, indicating that the processor is a 286
or better (perhaps `AT_LEAST_286` would have been a better name),
then after the initial DAC Write Index value is set, all 768 DAC
locations are loaded with a single **REP OUTSB**. This is clearly the
locations are loaded with a single `REP OUTSB`. This is clearly the
fastest approach, but it runs the risk, albeit remote, that the loading
sequence will be interrupted and the DAC registers will become garbled.
My own experience with Listing 34.1 indicates that it is sometimes
possible to load all 256 locations cleanly but sometimes it is not; it
all depends on the processor, the bus speed, the VGA, and the DAC, as
well as whether autoincrementation and **REP OUTSB** are used. I'm not
well as whether autoincrementation and `REP OUTSB` are used. I'm not
going to bother to report how many DAC locations I *could* successfully
load with each of the various approaches, for the simple reason that I
don't have enough data points to make reliable suggestions, and I don't
@ -93,7 +93,7 @@ First of all, I'd like to point out that when color cycling does work,
it's a thing of beauty. Assemble Listing 34.1 so that it doesn't use the
BIOS to load the DAC, doesn't guard against interrupts, and uses
286-specific instructions if your computer supports them. Then tinker
with **CYCLE\_SIZE** until the color cycling is perfectly clean on your
with `CYCLE_SIZE` until the color cycling is perfectly clean on your
computer. Color cycling looks stunningly smooth, doesn't it? And this is
crude color cycling, working with the default color set; switch over to
a color set that gradually works its way through various hues and