Merge branch 'master' into master
This commit is contained in:
James Gregory
GitHub
commit
b61c1dc6eb
5 changed files with 21 additions and 21 deletions
18
README.md
18
README.md
|
|
@ -4,19 +4,19 @@ This is the source for an ebook version of Michael Abrash's Black Book of Graphi
|
|||
|
||||
Reproduced with blessing of Michael Abrash, converted and maintained by [James Gregory](mailto:james@jagregory.com).
|
||||
|
||||
The [Github releases list](https://github.com/jagregory/abrash-black-book/releases) has an Epub and Mobi version available for download, and you can find a mirror of the HTML version at [www.jagregory.com/abrash-black-book](http://www.jagregory.com/abrash-black-book/).
|
||||
The [GitHub releases list](https://github.com/jagregory/abrash-black-book/releases) has an EPUB and Mobi version available for download, and you can find a mirror of the HTML version at [www.jagregory.com/abrash-black-book](http://www.jagregory.com/abrash-black-book/).
|
||||
|
||||
## How does this differ from the previously released versions?
|
||||
|
||||
The book is now out of print, and hard to come by. Last time I checked, it was going for over $200 on ebay.
|
||||
The book is now out of print, and hard to come by. Last time I checked, it was going for over $200 on eBay.
|
||||
|
||||
The version which Michael and Dr. Dobbs released in 2001 was a collection of PDF files. That version is [still available](http://www.drdobbs.com/parallel/graphics-programming-black-book/184404919). However, the structure (multiple files) and the format (PDF) result in a poor user experience on an ebook reader or other mobile device.
|
||||
|
||||
This version has been thoroughly cleaned of artifacts and condensed into something which can easily be converted into an ebook-friendly format. You can read this version online at Github, or download any of the Epub or Mobi releases. You can clone the repository and generate your own version with [pandoc](http://johnmacfarlane.net/pandoc/) if necessary.
|
||||
This version has been thoroughly cleaned of artifacts and condensed into something which can easily be converted into an ebook-friendly format. You can read this version online at GitHub, or download any of the EPUB or Mobi releases. You can clone the repository and generate your own version with [pandoc](http://johnmacfarlane.net/pandoc/) if necessary.
|
||||
|
||||
## Contributing
|
||||
|
||||
Changes are welcome, especially conversion-related ones. If you spot any problems while reading, please [submit an issue](https://github.com/jagregory/abrash-black-book/issues) and I'll correct it. Pull Requests are always welcome.
|
||||
Changes are welcome, especially conversion-related ones. If you spot any problems while reading, please [submit an issue](https://github.com/jagregory/abrash-black-book/issues) and I'll correct it. Pull requests are always welcome.
|
||||
|
||||
Some larger changes could be made to improve the content. I'd love to see some of the images converted to a vector representation so we can provide higher-resolution versions. Formulas and equations could be typeset with [MathJax](http://www.mathjax.org/).
|
||||
|
||||
|
|
@ -24,16 +24,16 @@ Some larger changes could be made to improve the content. I'd love to see some o
|
|||
|
||||
You need to have the following software installed and on your `PATH` before you begin:
|
||||
|
||||
* [pandoc](http://johnmacfarlane.net/pandoc/) version 2.0 or greater for Markdown to HTML and Epub conversion.
|
||||
* [pandoc](http://johnmacfarlane.net/pandoc/) version 2.0 or greater for Markdown to HTML and EPUB conversion.
|
||||
* [kindlegen](http://www.amazon.com/gp/feature.html?docId=1000765211) for Epub to Mobi conversion.
|
||||
|
||||
To generate an e-reader friendly version of the book, you can use `make` with one of the following options:
|
||||
|
||||
* `html` - build a HTML5 single-page version of the book
|
||||
* `epub` - build an Epub3 ebook
|
||||
* `html` - build an HTML5 single-page version of the book
|
||||
* `epub` - build an EPUB3 ebook
|
||||
* `mobi` - build a Kindle-friendly Mobi
|
||||
* `all` - do all of the above
|
||||
|
||||
Once complete, there'll be an `out` directory with a `black-book.epub`, a `black-book.mobi` and a `html` directory with a `black-book.html` file.
|
||||
Once complete, there will be an `out` directory with a `black-book.epub`, a `black-book.mobi` and an `html` directory with a `black-book.html` file.
|
||||
|
||||
> Note: Generating a mobi requires an epub to already exist. Also, mobi generation can be *slow* because of compression. If you want a quick mobi conversion you can just run `kindlegen out/black-book.epub`.
|
||||
> Note: Generating a Mobi requires an EPUB to already exist. Also, Mobi generation can be *slow* because of compression. If you want a quick Mobi conversion you can just run `kindlegen out/black-book.epub`.
|
||||
|
|
|
|||
|
|
@ -363,12 +363,12 @@ _ChecksumFile proc near
|
|||
ChecksumLoop:
|
||||
mov ah,3fh ;DOS read file function #
|
||||
int 21h ;read the byte
|
||||
jcErrorEnd;an error occurred
|
||||
jc ErrorEnd ;an error occurred
|
||||
and ax,ax ;any bytes read?
|
||||
jz Success ;no-end of file reached-we're done
|
||||
add si,[TempWord] ;add the byte into the
|
||||
;checksum total
|
||||
jmpChecksumLoop
|
||||
jmp ChecksumLoop
|
||||
ErrorEnd:
|
||||
sub ax,ax ;error
|
||||
jmp short Done
|
||||
|
|
@ -381,7 +381,7 @@ Done:
|
|||
pop si ;restore C's register variable
|
||||
pop bp
|
||||
ret
|
||||
_ChecksumFileendp
|
||||
_ChecksumFile endp
|
||||
end
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ much different from the original, and in fact still contains exactly the
|
|||
same number of instructions, the performance of the entire subroutine
|
||||
improved by about 10 percent from just this one change. (Incidentally,
|
||||
that wasn't the end of the optimization; I eliminated the `DEC` and
|
||||
`JNJ` instructions by expanding the four iterations of the loop—but
|
||||
`JNZ` instructions by expanding the four iterations of the loop—but
|
||||
that's a tale for another chapter.)
|
||||
|
||||
The point is this: To write truly superior assembly programs, you need
|
||||
|
|
|
|||
|
|
@ -878,8 +878,8 @@ the PC must be completely refreshed about once every four milliseconds
|
|||
in order to ensure the integrity of the data it stores. Obviously, it's
|
||||
highly desirable that the memory in the PC retain the correct data
|
||||
indefinitely, so each DRAM chip in the PC *must* always be refreshed
|
||||
within 4 µs of the last refresh. Since there's no guarantee that a given
|
||||
program will access each and every DRAM block once every 4 µs, the PC
|
||||
within 4 ms of the last refresh. Since there's no guarantee that a given
|
||||
program will access each and every DRAM block once every 4 ms, the PC
|
||||
contains special circuitry and programming for providing DRAM refresh.
|
||||
|
||||
#### How DRAM Refresh Works in the PC
|
||||
|
|
@ -900,8 +900,8 @@ purpose of refreshing the DRAM; the data that is read isn't used.)
|
|||
The 256 addresses accessed by the refresh DMA accesses are arranged so
|
||||
that taken together they properly refresh all the memory in the PC. By
|
||||
accessing one of the 256 addresses every 15.08 µs, all of the PC's DRAM
|
||||
is refreshed in 256 x 15.08 µs, or 3.86 µs, which is just about the
|
||||
desired 4 µs time I mentioned earlier. (Only the first 640K of memory is
|
||||
is refreshed in 256 x 15.08 µs, or 3.86 ms, which is just about the
|
||||
desired 4 ms time I mentioned earlier. (Only the first 640K of memory is
|
||||
refreshed in the PC; video adapters and other adapters above 640K
|
||||
containing memory that requires refreshing must provide their own DRAM
|
||||
refresh in pre-AT systems.)
|
||||
|
|
@ -1053,7 +1053,7 @@ reduction can vary considerably and unpredictably, depending on how the
|
|||
DRAM refreshes interact with your code's pattern of memory accesses.
|
||||
When you use the Zen timer and get a fractional cycle count for the
|
||||
execution time of an instruction, that's often the DRAM refresh
|
||||
cycle-eater at work. (The display adapter cycleis another possible
|
||||
cycle-eater at work. (The display adapter cycle is another possible
|
||||
culprit, and, on 386s and later processors, cache misses and pipeline
|
||||
execution hazards produce this sort of effect as well.) Whenever you get
|
||||
two timing results that differ less or more than they seemingly should,
|
||||
|
|
@ -1223,7 +1223,7 @@ display, and even with the display adapter cycle-eater it just doesn't
|
|||
take that long to manipulate 4,000 bytes. Even if the display adapter
|
||||
cycle-eater were to cause the 8088 to take as much as 5µs per display
|
||||
memory access—more than five times normal—it would still take only
|
||||
4,000x 2x 5µs, or 40 µs, to read and write every byte of display memory.
|
||||
4,000x 2x 5µs, or 40 ms, to read and write every byte of display memory.
|
||||
That's a lot of time as measured in 8088 cycles, but it's less than the
|
||||
blink of an eye in human time, and video performance only matters in
|
||||
human time. After all, the whole point of drawing graphics is to convey
|
||||
|
|
@ -1261,7 +1261,7 @@ seriously impact code performance, even as measured in human time.
|
|||
|
||||
For example, if we assume the same 5 µs per display memory access for
|
||||
the EGA's high-resolution graphics mode that we assumed for text mode,
|
||||
it would take 26,000 x 2 x 5 µs, or 260 µs, to scroll the screen once in
|
||||
it would take 26,000 x 2 x 5 µs, or 260 ms, to scroll the screen once in
|
||||
the EGA's high-resolution graphics mode, mode 10H. That's more than
|
||||
one-quarter of a second—noticeable by human standards, an eternity by
|
||||
computer standards.
|
||||
|
|
|
|||
|
|
@ -547,7 +547,7 @@ void WalkTree(NODE *pNode)
|
|||
// Pop the next node from the stack so
|
||||
// we can visit it and see if it has a
|
||||
// right subtree to be traversed
|
||||
if ((pNode = *—pNodeStack) == NULL)
|
||||
if ((pNode = *--pNodeStack) == NULL)
|
||||
{
|
||||
// Stack is empty and the current node
|
||||
// has no right child; we're done
|
||||
|
|
|
|||
Loading…
Reference in a new issue