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

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

38
47-02.md
View file

@ -3,14 +3,14 @@
------------------------ --------------------------------- --------------------
Given the tremendous advantages of Mode X over the documented mode 13H,
I’d very much like to get it into the hands of as many developers as
possible, so I’m going to spend the next few chapters exploring this odd
but worthy mode. I’ll provide mode set code, delineate the bitmap
I'd very much like to get it into the hands of as many developers as
possible, so I'm going to spend the next few chapters exploring this odd
but worthy mode. I'll provide mode set code, delineate the bitmap
organization, and show how the basic write pixel and read pixel
operations work. Then, I’ll move on to the magic stuff: rectangle fills,
operations work. Then, I'll move on to the magic stuff: rectangle fills,
screen clears, scrolls, image copies, pixel inversion, and, yes, polygon
fills (just a different driver for the polygon code), all blurry fast;
hardware raster ops; and page flipping. In the end, I’ll build a working
hardware raster ops; and page flipping. In the end, I'll build a working
animation program that shows many of the features of Mode X in action.
The mode set code is the logical place to begin.
@ -18,18 +18,18 @@ The mode set code is the logical place to begin.
### Selecting 320x240 256-Color Mode {#Heading4}
We could, if we wished, write our own mode set code for Mode X from
scratch—but why bother? Instead, we’ll let the BIOS do most of the work
by having it set up mode 13H, which we’ll then turn into Mode X by
scratch—but why bother? Instead, we'll let the BIOS do most of the work
by having it set up mode 13H, which we'll then turn into Mode X by
changing a few registers. Listing 47.1 does exactly that.
The code in Listing 47.1 has been around for some time, and the very
first version had a bug that serves up an interesting lesson. The
original *DDJ* version made images roll on IBM’s fixed-frequency VGA
monitors, a problem that didn’t come to my attention until the code was
original *DDJ* version made images roll on IBM's fixed-frequency VGA
monitors, a problem that didn't come to my attention until the code was
in print and shipped to 100,000 readers.
The bug came about this way: The code I modified to make the Mode X mode
set code used the VGA’s 28-MHz clock. Mode X should have used the 25-MHz
set code used the VGA's 28-MHz clock. Mode X should have used the 25-MHz
clock, a simple matter of setting bit 2 of the Miscellaneous Output
register (3C2H) to 0 instead of 1.
@ -41,23 +41,23 @@ innocuous—until it was distributed broadly and everybody started banging
on it.
IBM makes only fixed-frequency VGA monitors, which require very specific
frame rates; if they don’t get what you’ve told them to expect, the
frame rates; if they don't get what you've told them to expect, the
image rolls. The corrected version is the one shown here as Listing
47.1; it does select the 25-MHz clock, and works just fine on
fixed-frequency monitors.
Why didn’t I catch this bug? Neither I nor a single one of my testers
Why didn't I catch this bug? Neither I nor a single one of my testers
had a fixed-frequency monitor! This nicely illustrates how difficult it
is these days to test code in all the PC-compatible environments in
which it might run. The problem is particularly severe for small
developers, who can’t afford to buy every model of every hardware
developers, who can't afford to buy every model of every hardware
component from every manufacturer; just imagine trying to test
network-aware software in all possible configurations!
When people ask why software isn’t bulletproof; why it crashes or
doesn’t coexist with certain programs; why PC clones aren’t always
When people ask why software isn't bulletproof; why it crashes or
doesn't coexist with certain programs; why PC clones aren't always
compatible; why, in short, the myriad irritations of using a PC
exist—this is a big part of the reason. I guess that’s just the price we
exist—this is a big part of the reason. I guess that's just the price we
pay for the unfettered creativity and vast choice of the PC market.
**LISTING 47.1 L47-1.ASM**
@ -97,9 +97,9 @@ pay for the unfettered creativity and vast choice of the PC market.
.code
public _Set320x240Mode
_Set320x240Mode proc near
push bp ;preserve caller’s stack frame
push bp ;preserve caller's stack frame
push si ;preserve C register vars
push di ; (don’t count on BIOS preserving anything)
push di ; (don't count on BIOS preserving anything)
mov ax,13h ;let the BIOS set standard 256-color
int 10h ; mode (320x200 linear)
@ -146,7 +146,7 @@ pay for the unfettered creativity and vast choice of the PC market.
pop di ;restore C register vars
pop si
pop bp ;restore caller’s stack frame
pop bp ;restore caller's stack frame
ret
_Set320x240Mode endp
end