Change bold code snippets to inline code blocks

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

View file

@ -11,15 +11,15 @@ pages: 599-600
---
The interesting aspects of Listing 31.1 are three. First, the
**Set320x400Mode** subroutine selects 320x400 256-color mode. This is
`Set320x400Mode` subroutine selects 320x400 256-color mode. This is
accomplished by performing a mode 13H mode set followed by then putting
the VGA into standard planar byte mode. **Set320x400Mode** zeros display
the VGA into standard planar byte mode. `Set320x400Mode` zeros display
memory as well. It's necessary to clear display memory even after a mode
13H mode set because the mode 13H mode set clears only the 64K of
display memory that can be accessed in that mode, leaving 192K of
display memory untouched.
The second interesting aspect of Listing 31.1 is the **WritePixel**
The second interesting aspect of Listing 31.1 is the `WritePixel`
subroutine, which draws a colored pixel at any *x,y* addressable
location on the screen. Although it may not be obvious because I've
optimized the code a little, the process of drawing a pixel is
@ -44,14 +44,14 @@ which is equivalent to:
The pixel's color is then written to the addressed byte in the addressed
plane. That's all there is to it!
The third item of interest in Listing 31.1 is the **ReadPixel**
subroutine. **ReadPixel** is virtually identical to **WritePixel**, save
that in **ReadPixel** the Read Map register is programmed with a plane
number, while **WritePixel** uses a plane *mask* to set the Map Mask
The third item of interest in Listing 31.1 is the `ReadPixel`
subroutine. `ReadPixel` is virtually identical to `WritePixel`, save
that in `ReadPixel` the Read Map register is programmed with a plane
number, while `WritePixel` uses a plane *mask* to set the Map Mask
register. Of course, that difference merely reflects a fundamental
difference in the operation of the two registers. (If that's Greek to
you, refer back to Chapters 23-30 for a refresher on VGA programming.)
**ReadPixel** isn't used in Listing 31.1, but I've included it because,
`ReadPixel` isn't used in Listing 31.1, but I've included it because,
as I said above, the read and write pixel functions together can support
a whole host of more complex graphics functions.
@ -81,12 +81,12 @@ graphics function. A fast line draw for 320x400 256-color mode would be
simple (although not as fast as would be possible in mode 13H). Fast
image copies could be implemented by copying one-quarter of the image to
one plane, one-quarter to the next plane, and so on for all four planes,
thereby eliminating the **OUT** per pixel that sequential processing
thereby eliminating the `OUT` per pixel that sequential processing
requires. If you're really into performance, you could store your images
with all the bytes for plane 0 grouped together, followed by all the
bytes for plane 1, and so on. That would allow a single **REP MOVS**
bytes for plane 1, and so on. That would allow a single `REP MOVS`
instruction to copy all the bytes for a given plane, with just four
**REP MOVS** instructions copying the whole image. In a number of cases,
`REP MOVS` instructions copying the whole image. In a number of cases,
in fact, 320x400 256-color mode can actually be much faster than mode
13H, because the VGA's hardware can be used to draw four or even eight
pixels with a single access; I'll return to the topic of
@ -96,7 +96,7 @@ high-performance programming in 256-color modes other than mode 13H
It's all a bit complicated, but as I say, you should be able to design
an adequately fast—and often *very* fast—version for 320x400 mode of
whatever graphics function you need. If you're not all that concerned
with speed, **WritePixel** and **ReadPixel** should meet your needs.
with speed, `WritePixel` and `ReadPixel` should meet your needs.
### Two 256-Color Pages {#Heading7}
@ -108,7 +108,7 @@ memory, and is—unsurprisingly—displayed by setting the start address to
8000H.) Finally, Listing 31.2 draws vertical color bars in page 0 and
flips back to page 0 when another key is pressed.
The color bar routines don't use the **WritePixel** subroutine from
The color bar routines don't use the `WritePixel` subroutine from
Listing 31.1; they go straight to display memory instead for improved
speed. As I mentioned above, better speed yet could be achieved by a
color-bar algorithm that draws all the pixels in plane 0, then all the