Simtel MSDOS 1992 December

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS 1992 December / simtel1292_SIMTEL_1292_Walnut_Creek.iso / msdos / c / cnews009.arc / CNEWS009.NWS next >

Wrap

Text File | 1988-07-17 | 56KB | 1,199 lines

*------------------------------------------------------------------------* | | | C News - International C Newsletter, Compiler review, and | | Tutorial. | | | *------------------------------------------------------------------------* Volume 1, Number 9 15 July 1988 Editor | Editor's Corner: The Heap .................... 1 Barry Lynch | by Barry Lynch | Australian | Office: | Resident C: a review ......................... 2 David Nugent | by Bill Querry | | Programming the Hercules Graphics Card ....... 4 | Part II: by David Cheslow | | Practical C: Everyday C Solutions............. 18 | by Readers of C News | | Latest PD/Commercial Software Release ....... 19 | | Article Submission Standards ................ 20 | | Address's ................................. 21 | | Index ...................................... 22 | | Distribution Points ........................ 24 | | User Response Form .......................... 25 | | C News is an Electronic Journal published by the | C BBS in Burke, VA Bi-Monthly. All rights are | reserved, and all opinions expressed are of the | authors and any damage sustained, either physically | or financially via use of the routines in this | journal are at the sole expense of the reader. | | C News 1-09 Page 1 15 Jul 1988 ================================================================ The Heap: Messages from the editor ================================================================ Issue 9 represents a milestone of sorts for C News: Our 6th month anniversary. This is truly remarkable considering what C News started as, a couple of pages of notes by yours truly on Christmas Day 1987. C News has grown to proportions that I personally never thought it would, and with issue we continue to add new features and announce a few future enhancements as well. PRACTICAL C: Everyday problems with C solutions This column was founded this past week at the first ever C BBS user meeting. One of the users had a small problem that required him to write a small, yet powerful, C program. This problem and the program are included in this issue. C BBS New Phone Number: The C BBS has changed the type of phone service that we use here, from Local to Metro DC area. This means that users in the Metro DC area can call the C BBS as a local call and vice versa. This also means that the C BBS is once again PC Pursuitable. The new number is (703) 644-6478. I apologize for the inconvenience, and will get the phone company to get a message on the old number as soon as possible. Future Enhancements: In this issue of C News, David Cheslow continues his series on programming the Hercules Graphics Adapter. In future issues, art- icles on the following subjects will be included: - Database Design and Implementation. - cMail - a Fidonet compatible Mail Check. - An article on a Comm program with src. As you can see with these future topics, C News will be providing more code samples and theory. If you are interested in assisting in any of these areas, or in one that you are particularly interested in. Please send me a note at any of the address's listed later on in this document. C News 1-09 Page 2 15 Jul 1988 ================================================================ /*resident_C*/ by Essential Software, Inc. ================================================================ Everybody has their favorite TSR "pop-up" software that they use every day. Until now though, if one wanted to create their own TSR "pop-up" that did anything significant at all or wanted to create one that did something just like FAMOUS.EXE. An intimate knowledge of assembler and MS-DOS "tricks" was an absolute necessity. Now with /*resident_C*/ from Essential Software, Inc., almost anything you want to do (including DOS calls!) can be done from C. /*resident_C*/ is a C language library package that handles all the tricky MS_DOS documented and undocumented interfaces so that the C programmer can put full effort and concentration on the program function and know that the MS-DOS TSR details are already handled via a function call. The authors (and so do I) suggest that you create and test and develop your program in a non-TSR environment first, and then add the function calls for residency after the program works properly. To make it a TSR will add three function calls: 1. Make sure the program isn't already "loaded". 2. Install program as a TSR. 3. Optionally "unload" your program when desired and safe. The library installs your programs as a well behaved TSR (if there is such a thing) by chaining to the previous owner of any used interrupts (unlike the original SIDEKICK). By not hogging the interrupts, your TSR can be loaded concurrent with other "well behaved" TSR's. The /*resident_C*/ library has two other similar load functions for creation of ISR's (interrupt service routines and what Essential Software calls a hybrid-TSR. ISR's are very useful for creation of "shared" software functions in larger projects. Shared functions can be made resident and then invoked via a software interrupt, saving memory for the common code. The "hybrid-TSR" is an interesting feature. Instead of using the normal "hot-key" method of invoking a function, a chain to the system clock interrupt is made. Your TSR program checks for the "condition" for popping up to occur and either returns or pops up. A "hot-key" can also be assigned to this hybrid giving a large amount of flexibility in your program design. I have successfully used this "hybrid-TSR" scheme to check and control a hardware device that needed to be interfaced to a commercial EGA graphic intensive software package. C News 1-09 Page 3 15 Jul 1988 ================================================================ /*resident_C*/ by Essential Software, Inc. Cont' ================================================================ Memory overhead for a /*resident_C*/ TSR/ISR is relatively small (4-6k bytes depending on model used). The /*resident_C*/ library package lists for $99.00 and is available with source for a list price of $198.00. The source code is well commented and is a good method to learn the tricks of MS-DOS TSR interfacing. The library comes with a 43 page manual of which almost 20 pages of it is a tutorial on TSR/ISR development and how /*resident_C*/ does its thing. The software comes one disk with language support for Microsoft C5.x, Turbo C, and Lattice C. Nice for us that develop in different compilers for different projects. Also included are demo programs showing how to use the library in all three of the supplied interfaces. I have included one of their demos in both source and executable format so that you can see how easy it is to make a TSR. If you purchase the library source and want to make changes, a Microsoft MASM 5.x compatible assembler will be needed for re-compiling. As with all of Essential's library packages, no royalties are required for software incorporating /*resident_C*/ functions into your programs. I have on occasion used their technical support, and have found willing, helpful and knowledgeable people (including the authors of the packages). I have used this package along with other libraries, mostly Essential's Utilities, Essential's Graphics, and Essential's Communications (I DO like these Essential Software products!) and have had no problems using any of their functions MS-DOS or otherwise. DISCLAIMER: I have no connection or interest with Essential Software, Inc. other than a loyal user of their products for the last 2 years. /*resident_C*/ list $99.00 ($198.00 with source) Essential Software, Inc. 76 South Orange Avenue South Orange, New Jersey 07079 201-762-6965 Reviewer: Bill Querry, VP Engineering Paragon Technologies, Inc. 8383 Mentor Ave Mentor, Ohio 44060 216-255-8343 C News 1-09 Page 4 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ Editor's Note: This is the second in a series of Articles on programming for the Hercules Graphics Adapter. The 1st article in this series was included in C News Issue 8. All comments regarding this series should be directed to the author: David Cheslow. Part II: Programming for the Hercules Graphics Adapter. SHIFT & LOGICAL OPERATORS Shifts are very fast binary operators, they work like this: 11111111 >> 1 = 01111111 11111111 << 1 = 11111110 Logical operators are also faster than the equivalent mathematical operators, they work,like this: 10101010 & 00001111 = 00001010 10101010 | 00001111 = 10101111 10101010 ^ 00001111 = 10100101 ~ 00001111 = 11110000 Many of the H_GRAPH functions use the shift and logical operators to improve execution speed. Some optimizing compilers may automatically substitute shift and logical operators for the more time consuming multiplication, division and modulus operators. Using the more efficient (binary) operators in our code ensures that they will be used and forces us to think of things the same way the computer does. The bottom line is this: x>>1 is equivalent to x/2; x>>2 is equivalent to x/4; x>>3 is equivalent to x/8; etc. x<<1 is equivalent to x*2; x<<2 is equivalent to x*4; x<<3 is equivalent to x*8; etc. x&1 is equivalent to x%2; x&3 is equivalent to x%4; x&7 is equivalent to x%8; etc. Where x is a two byte integer. C News 1-09 Page 5 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ Note that the result of 32768<<1 is 0 whereas the result of 32768*2 will depend upon your compiler (i.e. numbers too small or large to fit in a two byte integer are always 0 when shift operators are used but will be unpredictable and incorrect when higher level operators are used). Some compilers will produce an overflow error when high level operators are used to produce a result out of the range of a two byte integer (most just give an incorrect answer). I have never heard of a compiler that does not support shift and logical operators, but if yours does not you may make the above substitutions. If shift and logical operators are new to you, I suggest that you find a good book on binary arithmetic. One that I found helpful was 'COMPUTE'S MACHINE LANGUAGE FOR THE IBM PC' published by COMPUTE magazine. Your time and effort will be well spent learning about binary arithmetic. Such knowledge will improve your understanding of your computer and will allow you to write much more efficient code. HERCULES/CGA COMPATIBILITY Most Hercules compatible graphics adapters (but not all) have the capability of operating in three distinct modes: DIAG, HALF and FULL. DIAG mode is used for 100% IBM monochrome compatibility and masks all of the Hercules graphics capabilities. HALF mode allows the Hercules to coexist with a CGA card, but disables the second graphics page. FULL mode enables all of the graphics features of the card but disallows the presence of any other graphics adapter in the computer. All of the H_GRAPH functions are written based on the assumption that the Hercules is the only graphics card installed in the computer and is, therefore, in FULL mode. For those people who would like to experiment with using the H_GRAPH functions on a dual monitor system or whose computer does not default to FULL mode, here is a function to change the Hercules's operating mode (don't confuse this with the graphics/text mode operations of the card). The prototype is - void h_opmode(int newmode). Note - If you are using the H_GRAPH functions on a dual monitor system you should use HALF mode - and not use the second graphics page. C News 1-09 Page 6 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ #define H_OPPORT 0x3BF #define H_DIAG 0 #define H_HALF 1 #define H_FULL 3 #include <conio.h> h_opmode(newmode) int newmode; { outp(H_OPPORT,((newmode==H_HALF)?1:((newmode==H_FULL)?3:0))); } Where 'newmode' may have the values H_HALF or H_FULL, any other value will result in the DIAG mode (the safest of all the modes) being selected. The FULL mode must never be selected when another graphics card is present in the computer! If you intend to use this function, always call it BEFORE calling the h_init function. If you are using an EGA card along with the Hercules card, it's O.K. because the h_init function will always request a mode change to CGA emulation before initializing the Hercules graphics mode. DO NOT use the video mode change function supported by your compiler to change to an EGA graphics mode while the Hercules is in graphics mode. The two are definitely incompatible and the result of requesting an EGA graphics mode while in Hercules graphics mode may be disastrous. If the Hercules is in graphics mode, then the EGA must be in CGA emulation mode (as set by the h_init function). If the Hercules is in text mode, then the EGA may be in any mode. If you use the HALF mode of operation in your programs, it is YOUR responsibly to make sure that you do not attempt to make the second graphics page of the Hercules card visible. Writing to the second graphics page is permissible but will really mess up the image on the other monitor. SCREEN BLANKING Last month, I included a function to disable the Hercules card (blank the screen). The routine will work correctly ONLY if the h_init function of the H_GRAPH functions is used. Use of any other function to initialize the Hercules (maybe one that came with your compiler) will definitely destroy your monitor. This is a result of the fact that other programs/functions do not have any way to find out which graphics/text mode the adapter is currently in. C News 1-09 Page 7 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ You have two options at this point: 1) do not mix H_GRAPH functions with other graphics library functions or 2) do not use the screen blanking function. In the September 1988 article I will cover a method of soft- ware screen blanking which will be just as effective and will work with functions from other sources. Also, any other set of functions which you might find will undoubtable have certain variables which are used to store the current graphics mode, operation mode, cursor position, etc. Failure to set those variables will almost certainly cause you trouble. Unless you get a lot of documentation with the functions from another source (the code is really what you need), it is probably best to stick with functions from one source. If you find a function from another source that you would like to use, I will be happy to try to write an H_GRAPH compatible function to perform the same task; just leave me a note in the C NEWS message section of the Mclean VA (USA) C BBS. To all those who have already sent me messages - THANK YOU - your input is greatly appreciated. CLIPPING All of the H_GRAPH functions that draw on the screen will perform clipping at the edges of the current window as defined by the external variables h_xmin, h_ymin, h_xmax, and h_ymax. This will allow us to develop a full blown windowing package over time. While I have not yet presented any window control functions but you are invited to experiment with the external variables. If you have any suggestions, just drop me a line. TEXT IN GRAPHICS MODE Text is one of the most important parts of any graphic image you might conjure up. A bar or pie chart without labels, while pretty, is not terribly informative. Even a video game must display the current score and other information in textual form. Two types of text images are called raster and vector fonts. Raster fonts are exact images of the text to be drawn on the screen. Raster fonts are quick to display and relatively easy to implement, but are not very versatile. They can not easily be rotated or scaled. Vector fonts, on the other hand, are not stored as exact screen images but as a set of points connected in order by lines. C News 1-09 Page 8 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ Vector fonts can easily be rotated and scaled, but are much harder to design and implement. Vector fonts are typically dis- played more slowly than their raster counterparts because the position of each screen pixel making up the font must be calculated. This month, I will present a raster font system made up of two functions. First is a function to load a font from a disk file into near memory. Near memory is used to increase speed. The function returns a pointer to the raster image data which is then passed to the character drawing function. All of the fonts are stored in the same amount of memory space (3,590 bytes = 256 characters x 14 bytes per character + a 6 byte header describing the font). The header information is: 1 byte cursor movement horizontally 1 byte cursor movement vertically 1 byte height of character 1 byte width of character 2 bytes start and stop position for 9th bit quoting --- 6 bytes The first two bytes determine the offset from the current cursor position to the beginning of the next character. They are interpreted as signed values, allowing negative offsets both horizontally and vertically. For the standard font they are +9 and +0 respectively, indicating that each character is 9 pixels wide and printed horizontally. Other fonts can have different values. For example, the sideways font has values of 0 and -10 indicating that the font is 10 pixels tall and printed vertically from bottom to top. Note that the starting position for displaying fonts is always the upper left corner of the first character. The sideways font appears to be rotated but the starting point has not been rotated with the font. The next two bytes contain the actual height and width of the raster image. The width may only have the values 8 or 9. The height may range from 1 to 14 inclusive (although heights less than about 5 are pretty useless). A width of 8 allows 90 characters to be displayed horizontally on the screen and a width of 9 allows 80 characters. This feature, when combined with 9th bit quoting (next 2 bytes) can be used to produce primitive animation effects. Note that 14 bytes of memory are set aside for the raster image even if the font is less than 14 pixels tall. C News 1-09 Page 9 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ This was done to standardize the font files, font loading function and the character drawing function. I admit that in some cases it wastes valuable near memory but I feel that the trade-off is worth while. Most characters are followed by a small blank space called the inter-character spacing. In the standard font this inter- character spacing includes the 9th bit. Some of the box graphic characters in the standard font, however, require that the 9th bit be used to make the characters join on the screen (no inter-character spacing). The 9th bit quoting feature allows for the situation in which some of the characters in a font must contain a 9th bit. For those characters the 9th bit in each row of pixels is the same as the 8th bit. Thus the 9th bit quotes the 8th bit. If the last 2 bytes of the font header are 179 and 224, then the characters whose ascii values are greater than 179 and less than 224 will have 9th bits which quote the 8th bit, all other characters will have blank 9th bits (inter-character spacing). Naturally, 9th bit quoting is only useful if the font is 9 bits wide. I have included a primitive string drawing function in this months' release. It simply displays a string of characters starting in the current graphics cursor position. No attempt is made to accommodate line feeds, tabs or other white space characters (i.e. all characters are printable). While this is somewhat inelegant, it serves our purposes nicely for the moment. Next month I will present a couple of more powerful string drawing functions. Three 'put modes' are supported by the character drawing function. Those of you with a background in BASIC may recognize put modes. For those who don't know about such things, here is a brief description of the three supported put modes: PSET - this mode completely overwrites any background image. XOR - this mode (exclusive or) is used whenever the background image needs to be completely restorable and the program can not regenerate the image effi- ciently. It is most often used in animation (video games). The trans- lation to English would be something like "one image or the other image, but never both images". If that doesn't make any sense, just remember that XORing the same text in the same place twice will restore the original image behind the text as if the text had never been there. C News 1-09 Page 10 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ OR - this mode displays the text overtop of the existing image creating a combination of the two. It is most useful for labeling graphs. Also this month I am presenting a box fill function that is quite powerful. It supports one additional put mode - AND. AND - only those pixels which are part of both images are displayed. This mode is useless in the text drawing function but when text is drawn and then a filled box is overlayed in the AND mode various grey scale text images can be achieved. The box fill function also uses TILES. A TILE is simply an eight byte character array. Think of the TILES as stationary. They all start at position 0,0 and repeat until the end of the the screen is reached. You can think of the box fill function as simply exposing the pre-existing tiles. The advantage of using TILES over a moveable fill image is that very few calculations are needed to determine which byte is going to be exposed - yielding an increase in speed. The remaining functions presented this time are pretty straight forward. To conserve space, the functions are not reprinted here in the text as they were last month. Instead, I have included a file called H_GRAPH2.NUM. It is simply a copy of the H_GRAPH functions with line numbers in the right margin. To follow the discussion of the functions you will need to print out a copy of the H_GRAPH2.NUM file. THE FUNCTIONS The m_init and m_cursor functions (lines 70 - 230) were discussed in C NEWS #8. The m_status function (lines 250 - 340) is not included in this months demo program but it is the primary way to get information from the mouse. It returns an integer indicating which buttons are pressed (0 = no buttons, 1 = left button, 2 = right button, 3 = middle button on a 3 button mouse or both buttons together on a 2 button mouse). Two other values are returned via pointer. They are the current horizontal and vertical pixel positions of the mouse cursor, respectively. Note that the addresses of 2 integer variables are passed (i.e. the function call will look something like x=m_status(&y,&z). In a mouse driven program, this becomes the primary function call for input. For that reason it is a good candidate for assembly language. Maybe next time. C News 1-09 Page 11 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ The m_move function (lines 360 - 440) forces the mouse cursor to the pixel position specified by the two passed variables. Of course the mouse itself does not move, only the cursor. The m_limit function (lines 460 - 580) sets the minimum and maximum values for the horizontal and vertical movement of the mouse. When the m_init function is called, these values are set to 0,0 - 639,199. That's fine if you are working with a CGA adapter, but we're not. To get the mouse to move freely across the entire screen, we must call the m_limit function with the values 0,0,719,347. This function can also be used to confine the mouse cursor any a smaller area of the screen. You must turn the mouse cursor off whenever you change the image on the screen (add text, draw a box, anything ...). In a video game these added function calls will greatly slow execution. To overcome this problem, simply limit the mouse cursor to the "playing area" , separate from the "scoring area" which is being continually updated. The m_shape function (lines 600 - 710) allows you to create your own mouse cursors (within reason). You will have to be able to convert a near pointer to a far pointer and then split the far pointer into its segment and offset portions. Some compilers simply use long integers as far pointers. If your compiler does not have built in functions for splitting apart far pointers, try setting a long integer equal to the far pointer. Then create 2 short integers from the long integer. Long >> 16 may equal the segment and Long & 65536 may equal the offset. It's worth a try if you don't have the functions already. The mouse.h file contains instructions for creating your own cursors as well as five predrawn ones. The functions h_isherc, h_init, h_setvpage and h_onoff (lines 740 - 1510) were covered in C NEWS #8. The h_drawc function (lines 1530 - 3030) (no that's not a misprint) takes two parameters, the character to print and a pointer to a 3590 byte near memory character array containing a raster font (loaded with the h_loadfont function). I decided to pass this para- meter so that you may have multiple fonts loaded at the same time. Lines 1570 - 1650 define the external variables affected by this func- tion. Line 1660 defines the variables used to store the font header information. Line 1670 contains the definitions for a bunch of stuff; i is a counter, offset is the number of pixels from the start of the memory byte to the starting position of the character, byte_loc is the location of the memory byte currently being changed, x1 and y1 are temporary storage for the graphics cursor position, start and stop_loc are the actual first and C News 1-09 Page 12 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ last bit positions to be changed (after accounting for clipping), edge_locis used in the calculation of clipped boundaries. Line 1680 defines still more stuff - andmask1 and andmask2 are used when changing memory bytes. When a bit is set to 1 in the and mask, the corresponding bit in the memory bytes will remain unchanged. If a bit is set to 0then the corresponding bit in the memory byte will be replaced beth raster font data. Andmask1 is for the left edge of the character,andmask2 for the right. This_byte is the byte from the font array currently being displayed. Last_bit is used during 9th bit quoting. Lines 1690 - 1760 extract the necessary data from the font header. If the 8th bit of the delta_x or delta_y variables is set then the change in cursor position is interpreted as negative. Some compilers support signed character variables, others do not. This method will work in either case. Line 1770 determines whether or not the entire character is outside of the current window boundaries. If it is, then there is no need to continue. The current cursor location is updated and the function returns. Lines 1830 - 2200 perform the left and right side clipping calculations. I'm not going to go into any detail about this section. Suffice it to say that the edges of the character are calculated and compared to the edges of the current window. The greater of the two left edges and the lessor of the two right edges is used to create the and masks. The next three sections (lines 2250 - 2490, 2510 - 2740, and 2760 - 2990) of the function are quite redundant, so I will describe just one of them and then explain the differences between the three parts. They are redund- antly coded in this way to maximize speed (at the expense of code space). For each row of pixels making up the font (line 2260), we first extract the matching byte from the font array (line 2280). Since in most cases 9th bit quoting is not used, we set the 9th bit to 0 (line 2290). Then we store the current pixel row in y1 (line 2300). The next line performs the vertical clipping (which is much easier than horizontal clipping). If the current byte is inside the current working window (line 2310), then the exact byte in memory to be changed is found (line 2330). The byte is actually changed with the strange looking code on line 2340. The memory byte h_p+byte_loc is banded with andmask1 to produce the por- tion of the memory byte which will not be changed. The result is ored with the byte from the font array (after it is shifted into the proper position). C News 1-09 Page 13 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ Since all of the raster fonts are either 8 or 9 bits wide we assume that the character will span a byte boundary and affect the following memory byte as well. The second memory byte is changed in lines 2350 - 2460 which also contains the 9th bit quoting calculations (lines 2370 - 2400). The only difference between this part of the function and the other two lines in the memory changing lines (the lines that start with *(h_p+ ... ). There are three such lines in each section. It would be more efficient to code these sections using the logical equate operators (|= and ^=) but the Mix Power C optimizer freaks out when you do this so I have left those changes for you to check out on your own compiler. Similarly, since the Mix Power C compiler does a pretty good job at optimizing registers, I have made no effort to identify the best choices for register variables. Finally, in line 3010 and 3020, the current graphics cursor position is updated appropriately. The h_loadfont function takes two character array pointers as parameters. The first points to a path\file name for the font and the second points to a 3590 byte character array which will hold the font data. The function is set up this way to avoid dynamic memory allocation (an area in which many compilers differ). The function is pretty straight forward. It simply reads 3590 bytes from the specified file and stores them in the designated array. If the file is not found, then the function returns -1. If all goes well it returns 0. The h_boxfill function is the other biggie this month. It takes three parameters. The first two identify the bottom right corner of the boxed area. Note that the current cursor position is ALWAYS interpreted as the upper left corner! The third parameter is a pointer to one of many tile patterns (you are free to create more if you like). Most of the variables have equivalent counterparts in the h_drawc function. These are new; Whole_bytes is the number of complete bytes between the left and right edges (normally, whole bytes will be equal to total bytes effected - 2 but if the box starts or ends on a byte boundary, the value may differ); save_byte is the current byte in use from the tile array; temp_byte is used to overcome the register allocation problem with the Mix optimizer. Line 3270 returns from requests for boxes entirely out of the current window. Lines 3280 - 3340 perform clipping, create the and masks and calculates the exact number of whole bytes. C News 1-09 Page 14 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ The next section should look vaguely familiar to you. It very closely follows the logic in the h_drawc function. The bigg- est difference is in the way the ~ operator is used to effectively mask out unwanted portions of the tile pattern. Remember, we shifted the font data. Since the titles are stationary it is not necessary to calculate the correct amount to shift, etc. Also note the 4 assembly function calls (one for PSET, OR, AND and XOR). One of these was presented last time but I will repeat it in case you didn't key it in last month. It is well worth taking the time to make these ASM functions. I calculate about a 600% speed increase for PSET and about 125% for the other functions. It's not often that you find ten lines of code that create speed improvements like that! Here they are: In each case, [bp+12] is the number of bytes to fill, [bp+10] is the byte from the tile, and [bp+8] and [bp+6] are the segment and offset portions of a far pointer respectively. h_mempse push bp mov bp,sp mov di,[bp+6] mov es,[bp+8] mov ax,[bp+10] mov cx,[bp+12] jcxz cld rep stosb QUIT: retfar h_memor push bp mov bp,sp mov cx,[bp+6] mov ax,[bp+8] mov es,[bp+10] mov bx,[bp+12] DOIT: es: or byte ptr [bx],al ds: inc bx loop DOIT pop bp retfar h_memxor push bp mov bp,sp C News 1-09 Page 15 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ mov cx,[bp+6] mov ax,[bp+8] mov es,[bp+10] mov bx,[bp+12] DOIT: es: xor byte ptr [bx],al ds: inc bx loop DOIT pop bp retfar h_memand push bp mov bp,sp mov cx,[bp+6] mov ax,[bp+8] mov es,[bp+10] mov bx,[bp+12] DOIT: es: and byte ptr [bx],al ds: inc bx loop DOIT pop bp retfar If you REALLY hate assembly language you can substitute the following: Replace the h_mempse function call with: for(i=0;i<whole_bytes;i++) { *(h_p+ ++byte_loc)=save_byte; } Replace the h_memor function call with: for(i=0;i<whole_bytes;i++) { *(h_p+ ++byte_loc)|=save_byte; } Replace the h_memxor function call with: for(i=0;i<whole_bytes;i++) { *(h_p+ ++byte_loc)^=save_byte; } C News 1-09 Page 16 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ Replace the h_memand function call with: for(i=0;i<whole_bytes;i++) { *(h_p+ ++byte_loc)&=save_byte; } The h_moveto function simply provides a consistent way of changing the current graphics cursor location to the position specified by the two parameters. The h_box function takes the same parameters as the h_boxfill function but does not fill the box. Using different tiles produces various dashed and dotted lines. The h_setpmode function provides a consistent method of changing the current put mode. The h_clrw function clears the current window by trying to fill the entire screen (the boxfill function does the clipping). The only parameter is a tile pointer. The graphics cursor position is not changed and the pre-existing put mode is restored. The h_explode function is used in the demo to give you an idea of the many possibilities designed into the h_boxfill function. The h_draws function simply displays a string at the current cursor location, using the font pointed to by the alphabet parameter. No control codes or white space characters are intercepted. The h_pattern function is used by the demo program to display some possible tile patterns. Note the use of the OR put mode to create a crosshatch pattern by combining the left and right hatch patterns. C News 1-09 Page 17 15 Jul 1988 ================================================================ PROGRAMMING FOR THE HERCULES GRAPHICS ADAPTER: PART II ================================================================ ABOUT THE AUTHOR I am currently employed as an economist for the Virginia Department of Taxation. I have a Bachelor's degree in Business Administration from Radford University and a Master's of Business Administration from Virginia Polytechnic Institute. My wife, son and I are about to embark on a journey to Texas so I can begin work on a Ph.D. in Management Information Systems at Texas A&M. For this reason, next months' article will be rather short. I will continue to monitor the action in the C NEWS message area of the Virginia C BBS and try my best to respond to your inquiries quickly. = DAVE = C News 1-09 Page 18 15 Jul 1988 ================================================================ PRACTICAL C: Everyday C Solutions ================================================================ RSE: A Program to redirect standard error. Scott Houck submitted this utility out our C BBS user meeting this past week. Scott needed a utility to redirect standard error, so that he could get compiler errors into a file. Polytron Version Control System, had an RSE but Scott felt that he should not be distributing it. As it is a copyrighted product. Thus began the creation of his own RSE program, which is shown below: /* RSE.C -- a program to redirect standard error * * Written by Scott R. Houck * * This program will redirect standard error to standard output so * that a program's standard error output can be sent to a file * using the redirection symbols '>' or '>>' on the command line. * * The syntax is: RSE program [arguments] */ #include <stdio.h> #include <io.h> #include <process.h> int main(argc, argv) int argc; char **argv; { if (argv < 2) { fprintf(stderr, "Usage: RSE program [arguments]\n"); exit(1); } ++argv; dup2(fileno(stdout), fileno(stderr)); return spawnvp(P_WAIT, *argv, argv); } C News 1-09 Page 19 15 Jul 1988 ================================================================ Latest Versions of Commercial/PD Software. ================================================================ Compilers: Ver: --------- ---- Microsoft C 5.10 QuickC 1.01 TurboC 1.5 /* With a rumored 2.0 out */ Datalight 2.1 MIX C ? PowerC ? Lattice C ? Watcom 6.0 C News 1-09 Page 20 15 Jul 1988 ================================================================ ARTICLE SUBMISSION STANDARDS AND ADDRESSES ================================================================ As I have repeatedly stated in this newsletter and previous issues, I would like to see user-submitted articles, reviews or questions. Listed below are the standards that should be followed to make my job easier as an editor. - Articles should be submitted in a ASCII non-formatted file. (Margins 0-65 PLEASE) - If the article include code fragments as examples. Then you can include the entire source file if you like for inclusion with the newsletter. - Book or magazine reviews should follow the same format, that is outlined in this issue. The publisher, author, title, and ISBN number are a must. - Compiler/and or product reviews, should include the version number and manufacture. If possible, reviews should include a sample program with benchmarks. If you have any questions you can contact me at the address's included on the next page. C News 1-09 Page 21 15 Jul 1988 ================================================================ ADDRESSES ================================================================ The C BBS is located at: C BBS % BCL Limited P.O. Box 9162 McLean VA, 22102 or you can send netmail to: 1:109/713 C News 1-09 Page 22 15 Jul 1988 ================================================================ INDEX ================================================================ Subject: Issue: Articles: Additional Comments of Filename Wild.. 6 Beginning C Functions 7 C Spot Run: A User Supported Library 7 Filename Wildcard Expansion in MSC 4 Integrated Environment: TC & QC 5 Programming the Hercules Graphics Card 8 Talking with a Fossil 5 TurboC and Interrupts: A few Questions 2 Book Reviews: C Chest: and other treasures. 6 C Database Development 1 C Programming Guide 1 C Programming Language 1 C Programmer's Guide to Serial Communications 3 C Programmer's Library 1 C Primer Plus 1 C the Complete Reference 2 Crafting C Tools for the IBM PC 2 Learning to Program in C 1 Microsoft C Programming on the IBM PC 1 MS-DOS Developer's Guide 4 Programming in Windows 3 Reliable Data Structures in C 1 TurboC: Memory Resident Utilities 5 TurboC Programmer's Reference Book 2 Compilers: QuickC 1 Software Reviews: Bplus11.arc 3 C_Dates.arc 4 Cdate.arc 4 Casm.arc 3 C-subr.arc 4 Docu.arc 3 Ezwind.arc 8 Jcl-src.arc 4 Mscpopup.arc 3 Ndmake41.arc 4 C News 1-09 Page 23 15 Jul 1988 ================================================================ INDEX ================================================================ Subject: Issue: Software Reviews Cont: Nuc-subr.arc 3 Prndoc.arc 6 Sed.arc 6 Shift_c.arc 4 Sysact11.arc 4 Tp_to_qc.arc 3 Xenixarc.arc 4 C News 1-09 Page 24 15 Jul 1988 ================================================================ DISTRIBUTION POINTS ================================================================ Board Name Number Net/Node Sysop United States C BBS (703) 644-6478 1:109/713 Barry Lynch Burke, VA Jaz C-Scape (904) 724-1377 1:112/1027 Tom Evans Jacksonville, FL Eastern C Board (201) 247-6748 1:107/335 Todd Lehr OTHER BOARDS THAT CARRY C NEWS: Exec-PC (414) 964-5160 .. Bob Mahoney Milwaukee, WI Tamaini (813) 793-2392 Gerhard Barth Naples, FL Canada Another BBS System (416) 465-7752 1:148/208 Mark Bowman Toronto, Canada Europe Fido_N1_1 31-8350-37156 2:500/1 Henk Wevers The Netherlands Australia Alpha-Centuri BBS 011-61-3-874-3559 3:632/348 David Nugent C News 1-09 Page 25 15 Jul 1988 ================================================================ USER RESPONSE FORM ================================================================ This form will be included as a regular feature in all future issues of C NEWS. What did you think of the content of this Issue? _____________ _______________________________________________________________ What improvements can you think of that would make C News a better tool for the C Community? _______________________________________________________________ _______________________________________________________________ What is your favorite section or sections? ___________________ _______________________________________________________________ What don't you like about C News? ____________________________ _______________________________________________________________ Additional Comments: _________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________