diff --git a/README.md b/README.md index ecb612d..6ac2cee 100644 --- a/README.md +++ b/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`. diff --git a/src/chapter-01.md b/src/chapter-01.md index 0e27fbc..8f4a05e 100644 --- a/src/chapter-01.md +++ b/src/chapter-01.md @@ -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 ``` diff --git a/src/chapter-02.md b/src/chapter-02.md index 25baba6..b8a7b76 100644 --- a/src/chapter-02.md +++ b/src/chapter-02.md @@ -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 diff --git a/src/chapter-04.md b/src/chapter-04.md index c0b364d..67ce38f 100644 --- a/src/chapter-04.md +++ b/src/chapter-04.md @@ -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. diff --git a/src/chapter-59.md b/src/chapter-59.md index ff13c30..376634f 100644 --- a/src/chapter-59.md +++ b/src/chapter-59.md @@ -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