------------ BITS 'N PC'S ------------ In this series, we will give various hints, tips, and tricks, to let you make the best use of your personal computer. Whether you are a "hacker," or a non-technical user, you should be able to find information here that will help your PC perform at its best. ---------------------------------------------- GETTING COLOR IN HIGH-RESOLUTION GRAPHICS MODE ---------------------------------------------- IBM's documentation of the PC's graphics modes states that the High Resolution mode supports only black-and-white graphics. Since most people tend to believe what the manufacturer of a computer says about its capabilities, this is seldom challenged. Certainly, for users of BASIC, there is no reason to believe otherwise; black and white are the colors that come up when you invoke this mode, and BASIC offers no command to change it. Trying to use the COLOR statement while in high-resolution mode yields only an error message. But in fact, black and white are ^Bnot^N the only colors available in this graphic mode. Actually, you have a choice of sixteen colors. The catch is that only one color can be visible at once, other than the background, which is always black. In BASIC, you can change the color of Hi-Res graphics with the following line: ^1OUT &H3D9, color^0 where ^1color^0 is the number (from 0 to 15) of the color you wish; these numbers correspond to the color numbers used in text mode. This command tells your graphics adapter to switch the color for High- Resolution plotting to the given color, if you are in High-Resolution mode when you type this command. If you are instead in text or Low-Resolution mode, this same command will set the border color to the given value; in Medium-Resolution mode, this command will set the background color. Since only one color can be on the screen at once, all previously-plotted graphics will change to the most recently selected color. As for the background, it's sort of like the original Model T Ford; it's available in any color you like, so long as what you like is black. There's no way of changing this color; sorry. What you are actually doing is sending a value to an output port. Your PC has 65,536 such ports, and they are used for a number of purposes we will not get into right now. BASIC uses the OUT command for port output, as shown above -- other languages and assemblers generally have equivalent features. Consult your reference manual to find out how to do it in whatever language you are using; all you have to do is send the number corresponding to the color you want to port number 3D9 (in Hexadecimal). In Turbo Pascal, you can use the ^1Port^0 system array to do this, but it's unnecessary: Borland International, the creators of Turbo Pascal, showed more sense than IBM, and provided a direct command to change the color in High- Resolution mode. Just use the command ^1HiResColor(color)^0 and it will be changed. In other languages, check for such a command in your manual before you resort to direct port access. Your code will be much easier to understand and more portable to other systems if you refrain whenever possible from direct PEEKing, POKEing, port access, et cetera. -------------------------------------------- PREVENTING CONFIRMATION LINES IN BATCH FILES -------------------------------------------- If you make regular use of .BATch files to get your PC to perform a series of DOS commands without human intervention, you probably know that the command ECHO OFF is used to prevent DOS from echoing all the command lines back to you. This is commonly used so that you don't have to see all these ugly commands scrolling by, spoiling whatever screen format you may have set up, and confusing the user. However, if your file includes a COPY command to copy files around on your disks, then even in ECHO OFF mode a confirmation line will still be output as each file is copied, and yet another line will show how many files have been copied. But there's a way of suppressing these lines, too. Simply append to each COPY command, or other command which generates unwanted confirmation lines, the sequence ^1>NUL^0. This causes all output that would have gone to the console during execution of the command to go instead to the null device, which simply means it is "thrown away." For example: ^1COPY \dir1\*.bas \dir2 >nul^0 would copy all BASIC programs in the subdirectory ^1dir1^0 to the subdirectory ^1dir2^0, without echoing any confirmation. This trick will work in immediate mode as well as in .BATch files. ------------------------------- WAITING FOR A KEYPRESS IN BASIC ------------------------------- Here is a tip for you if you are writing a BASIC program which needs to wait for a keypress, such as when you say "Hit Any Key To Continue," or you ask a question and wait for a Y or N response. There are several commands you might think of using for such a thing. The plain old INPUT command is not very good; it requires the user to press ENTER before it returns control back to BASIC; it also allows the user to press all sorts of cursor-movement keys which might mess up your screen format. Many programmers use a loop with the INKEY$ function. When INKEY$ has a value other than CHR$(0), a key has been pressed. Thus, this function can be used to check for a keypress and return its value. However, this is very inefficient. Every iteration of such a loop causes a new string value to be created, even if it is only a null character. Due to the way BASIC handles strings, the old values of a string that is repeatedly reasigned stick around wasting memory, until BASIC does a garbage collect. Such garbage collections slow down the execution of your program. There's a better way, though. Use the ^1INPUT$(n)^0 function. The parameter ^1n^0 indicates how many characters you wish to input, usually 1. ^1INPUT$^0 returns the input character(s) as its result. Thus, the following BASIC line will wait for one keypress, and return its value as the variable I$: ^1I$ = INPUT$(1)^0 ------------------------------------ That's all for now; next month we'll be back with more hints and tips for you and your PC. Please write to us (on paper, through feedback text files created with the BlueLine editor, or through our Bulletin Board System) and tell us any hints you have discovered, or any areas you'd like some tips on.