Replace invalid characters with HTML entities
— with — ’ with ’ + with + × with x ç with ç “ with “ ” with ” ‘ with ‘ • with • – with - µ with µ † with † Fix C++ θ with θ Yen symbol instead of times Fix broken apos Bullet again E-circumflex
This commit is contained in:
James Gregory
parent
9e52de9586
commit
500e7f5654
353 changed files with 5091 additions and 5091 deletions
22
47-02.html
22
47-02.html
|
|
@ -36,18 +36,18 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<P>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 organization, and show how the basic write pixel and read pixel 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 animation program that shows many of the features of Mode X in action.
|
||||
<P>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 organization, and show how the basic write pixel and read pixel 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 animation program that shows many of the features of Mode X in action.
|
||||
</P>
|
||||
<P>The mode set code is the logical place to begin.</P>
|
||||
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Selecting 320x240 256-Color Mode</FONT></H3>
|
||||
<P>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 changing a few registers. Listing 47.1 does exactly that.
|
||||
<P>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 changing a few registers. Listing 47.1 does exactly that.
|
||||
</P>
|
||||
<P>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 <I>DDJ</I> 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.</P>
|
||||
<P>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 clock, a simple matter of setting bit 2 of the Miscellaneous Output register (3C2H) to 0 instead of 1.</P>
|
||||
<P>Alas, I neglected to change that single bit, so frames were drawn at a faster rate than they should have been; however, both of my monitors are multifrequency types, and they automatically compensated for the faster frame rate. Consequently, my clock-selection bug was invisible and innocuous—until it was distributed broadly and everybody started banging on it.</P>
|
||||
<P>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 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.</P>
|
||||
<P>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 component from every manufacturer; just imagine trying to test network-aware software in all possible configurations!</P>
|
||||
<P>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 pay for the unfettered creativity and vast choice of the PC market.</P>
|
||||
<P>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 <I>DDJ</I> 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.</P>
|
||||
<P>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 clock, a simple matter of setting bit 2 of the Miscellaneous Output register (3C2H) to 0 instead of 1.</P>
|
||||
<P>Alas, I neglected to change that single bit, so frames were drawn at a faster rate than they should have been; however, both of my monitors are multifrequency types, and they automatically compensated for the faster frame rate. Consequently, my clock-selection bug was invisible and innocuous—until it was distributed broadly and everybody started banging on it.</P>
|
||||
<P>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 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.</P>
|
||||
<P>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 component from every manufacturer; just imagine trying to test network-aware software in all possible configurations!</P>
|
||||
<P>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 pay for the unfettered creativity and vast choice of the PC market.</P>
|
||||
<P><B>LISTING 47.1 L47-1.ASM</B></P>
|
||||
<!-- CODE //-->
|
||||
<PRE>
|
||||
|
|
@ -86,9 +86,9 @@ CRT_PARM_LENGTH equ (($-CRTParms)/2)
|
|||
.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)
|
||||
|
|
@ -135,7 +135,7 @@ SetCRTParmsLoop:
|
|||
|
||||
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
|
||||
|
|
|
|||
Loading…
Reference in a new issue