We here at Hacking Headquarters are actually perfect, but the online networks occasionally globally alter the issue after it leaves our hands. The printed version is similarly changed by the print shop. We think it's an attempt to discredit us, but we will thwart them again by simply printing the corrections to the mistakes THEY introduced below.
Brett Tabke wrote in to correct some misinformation contained in this article in Issue #11. In the article's discussion of RAMDOS, it was written that "RAMDOS continually pages its code in and out of main memory" during transfers. Mr. Tabke, who has researched the RAMDOS code extensively, notes that the above is incorrect. RAMDOS pages the main code in to initiate the transfer, but the bulk of transfers are handled by the 256 byte interface that remains in memory at all times.
We reprinted Jeff Jones' electronic mail address as printed in LOADSTAR LETTER #31, but Jeff sent us a note mentioning the address had changed, and the correct email address is jeff@loadstar.com.
In this article in version 1.0 of Issue #12, there were two references to
"Exploiting the 65C816S CPU", an article pulled from the issue for space
reasons. We regret the error. The full article on the 65C816S appears in
this issue (Reference: cpu).
In early versions of Issue #12, the TED IC article was incorrectly attributed to Harsfalvi Levente. Hungarians customarily sign names with the last name first, opposite English notation (implying that the other way must be Hungarian notation :-). The article should be attributed to Levente Harsfalvi. Version 1.3 of the issue fixes this problem.
After the publication of this article in Issue 12, Stephen Judd noted that the following information was not included in the article:
Memory map:
$0800-$1BFF Tables $1C00-$1FFF Color info for bitmap #1 $2000-$3FFF Bitmap 1 $4000-$58FF Fill routine for bitmap #1 $5900-$5BFF Tables $5C00-$5FFF Color info for bitmap #2 $6000-$7FFF Bitmap #2 $8000-$A6FF Code $A700-$BFFF Fill routine for bitmap #2 $C000-$C5FF Yet more tables $C600-$C6FF List of points for plotting routine $C700-$C7FF Fill patterns $C800-$CDFF A few more tablesThe fill pattern table may be broken down further. Each fill pattern is eight bytes, so to get the address in the fill table multiply the pattern number by eight:
0 - Empty (clear) 1 - $FF (solid) 2 - Brick 3 - CrossSmall 4 - Inverse of 3 5 - Dither 1 6 - Dither 2 (inverse of 5) 7 - Zigs 8 - Zags 9 - Zigzag 10- Holes 11- Smiley 12-15 Not used 16-23 Shockwave \ Animated patterns, eight frames each 24-31 Squaredance /If you have a freezer cartridge you might want to try changing the patterns. You might also turn on the multicolor bit (bit 4 of $D016) to see what a multicolor Polygonamy might look like, and change the patterns (not to mention the color info) to be more multicolor-friendly.
In early versions of Issue 12, question $186 in the Commodore Trivia article was incorrect. The correct answer appears below:
| Q $186) | What is the maximum size of RAM available for use for program storage on an expanded VIC-20 |
| A $186) | If you discount the screen area (512 bytes) and Color RAM (512 bytes), up to 28159 bytes can used for BASIC programs and variables (original 3583 bytes and 3 banks of 8192 bytes each), and up to 40448 bytes can be used for ML programs. (0-32767 minus 512 bytes for screen and 40960-49151). |
Copyright © 1992 - 1997 Commodore Hacking
Commodore, CBM, its respective computer system names, and the CBM logo are either registered trademarks or trademarks of ESCOM GmbH or VISCorp in the United States and/or other countries. Neither ESCOM nor VISCorp endorse or are affiliated with Commodore Hacking.
Commodore Hacking is published by:
Brain Innovations, Inc.
Last Updated: 1997-03-11 by Jim Brain