ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / MAGAZINE / MISC / QBNWS105.ZIP / QBNWS105.NWS < prev next >

Wrap

Text File | 1990-12-01 | 95.1 KB | 2,317 lines

Volume 1, Number 5 December 1, 1990 ************************************************** * * * QBNews * * * * International QuickBASIC Electronic * * Newsleter * * * * Dedicated to promoting QuickBASIC around * * the world * * * ************************************************** The QBNews is an electronic newsletter published by Clearware Computing. It can be freely distributed providing NO CHARGE is charged for distribution. The QBNews is copyrighted in full by Clearware Computing. The authors hold the copyright to their individual articles. All program code appearing in QBNews is released into the public domain. You may do what you wish with the code except copyright it. QBNews must be distributed whole and unmodified. You can write The QBNews at: The QBNews P.O. Box 507 Sandy Hook, CT 06482 Copyright (c) 1990 by Clearware Computing. The QBNews Page i Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- T A B L E O F C O N T E N T S 1. From the Editor's Desk And the winner is . . . ...................................... 1 2. Beginners Corner Common Questions about QuickBASIC by Tom Hanlin .............. 2 How to use Libraries in QuickBASIC by Tom Hanlin ............. 4 3. Advertisement Crescent Software, 32 Seventy Acres, West Redding, CT 06896 . 6 4. Swap Shop Graphics and text screen dumps by Alan J. Fridlund, Ph.D. .... 7 Saving and loading .PCX files for EGA screen 9 by Greg Harder 9 Getting the .PCX palette info by Dwain Goforth ............... 11 DBase III file viewer by David Perry ......................... 11 A Quick Basic archive file viewer by Dick Dennison ........... 12 5. Who ya gonna call? CALL INTERRUPT Format Floppy Disks with QB by Cornel Huth .................. 12 6. Power Programming Scenic Views by way of the Video Map by Larry Stone .......... 14 Self-Cloning Exe's Revisted by Ronny Ong ..................... 18 7. Engineers Corner GPIB Instrument control from IOTech by Dave Cleary ........... 20 8. New and Noteworthy GEOGRAF Level One from GEOCOMP Corporation ................... 24 9. And I Heard it Through the Grapevine Exerpts from the QUIK_BAS echo ............................... 25 10. EOF Receiving The QBNews ......................................... 36 Advertising in The QBNews .................................... 37 Submitting Articles to The QBNews ............................ 37 The QBNews Page ii Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- F r o m t h e E d i t o r ' s D e s k ---------------------------------------------------------------------- And the winner is . . . The winner of the QBNews Reader Contest was Bruce Guthrie of Silver Spring, MD. I'd like to say congratulations to Bruce and I would like to thank all those who entered. I was disappointed with the quantity of entries, but not with the quality. I received entries from all over the U.S. and Canada plus three other continents. It makes me happy to see that all the hard work the authors put into their articles is appreciated. This marks the last issue of volume one. I have decided to commit to one more year of putting out the QBNews, so I am going to be offering subscriptions for volume two. I don't have the time to process disk orders as they come in, so volume two will only be available on disk by buying a whole subscription. Details of this can be found in the back of the newsletter. Of course, the QBNews will still be distributed free through BBS's. As always, the QBNews is looking for new authors. I find that most of the submissions I receive are a result of direct requests to the author from me. I am running out of people I can coerce (er ... I mean ask) to write articles. Please support the QBNews by contributing your time and effort into writing articles. Details on submitting articles can be found in the back of the newsletter. Dave Cleary The QBNews Page 1 Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- B e g i n n e r s C o r n e r ---------------------------------------------------------------------- Common Questions about QuickBASIC by Tom Hanlin After spending much time on CompuServe, BIX, the FidoNet QuickBASIC echo and other national BASIC forums, I've noticed that there is a lot of repetition. People ask the same questions, time after time. They must be good questions! Here is a compilation of a few of the more common questions. Question: How can I disable Control-Break? Answer: Programs compiled with QuickBASIC or BASCOM usually don't have to worry about this. Control-Break is disabled unless you compile with the /D (debug) option. In the event that you are doing something that QuickBASIC doesn't completely control, like printing to the screen via DOS functions, this protection no longer holds. In that case, you may be able to disable Break by getting DOS to check for it less frequently. Use the command BREAK OFF from a batch file, or execute it from BASIC like so: SHELL "COMMAND BREAK OFF" Question: How can I get the error level from a SHELLed program? How can I get my program to return an error level? Answer: You can't. More accurately, you can only do it with assembly language routines. Question: How can I get a directory listing into an array? Answer: Most BASIC libraries can do this for you. Another way to do this is to put the directory listing into a file by SHELL "COMMAND DIR *.* >DIRLIST.TXT" and then read the file into an array. Yet another alternative is to use the FILES statement on a non-displayed screen page (if you have a CGA, EGA or VGA) or in invisible colors (say, black on black), then get the results off the screen with the SCREEN function. Question: How can I see if a file exists? Answer: Most BASIC libraries can do this for you. Or, you can use the directory approach given above. Yet another way to do it is to try to open the file for input: ON ERROR GOTO NotFound OPEN File$ FOR INPUT AS #1 CLOSE #1 Found = -1 Done: RETURN The QBNews Page 2 Volume 1, Number 5 December 1, 1990 NotFound: Found = 0 RESUME Done Question: I'm running out of string space. What can I do? Answer: If you have arrays, try moving them outside of the string space area. Either use REDIM to dimension 'em or use the REM $DYNAMIC metacommand. If this doesn't help enough, use fixed-length strings, which are stored outside the regular string area. Still not enough room? Well, you can buy Microsoft's BASCOM 7.0 "Professional Development System", which will set you back about $300. Question: I'd like to constantly display the time. What do I do? Answer: That's also available in libraries (gee, aren't libraries great?!). You can do it yourself using an approach like this: ON TIMER(1) GOSUB DisplayTime TIMER ON ' your program goes here DisplayTime: OldRow = CSRLIN OldCol = POS(0) LOCATE 25, 70 PRINT TIME$; LOCATE OldRow, OldCol RETURN Question: I need to know how many days lie in between two dates. How do I do it? Answer: As usual... this is something you can get in a library from your local BBS. Try QB4BAS. It's quite possible to do it in BASIC, but I can never remember the proper formulae... you need to account for leap years and leap centuries, so it isn't as straightforward as you might guess. Question: How can I use ANSI display codes? Answer: You need to go through DOS display functions for that to work. Use this: OPEN "CON" FOR OUTPUT AS #1 This makes the DOS display functions available as file (device) number one. You can print to it using normal file statements: PRINT #1, CHR$(27); "[2J"; The above statement will clear the screen if an ANSI driver is installed. See your DOS manual for information on the available ANSI codes. You can also get this information from your friendly local BBS. The QBNews Page 3 Volume 1, Number 5 December 1, 1990 How to use Libraries in QuickBASIC by Tom Hanlin So you've never used a library before and you want to know what gives? A library is a collection of routines, whether written in BASIC, assembly language, or some other language altogether. It provides a convenient way to allow different programs to use the same sets of standard or special-purpose routines (subprograms or functions, in BASIC parlance). There are two forms of libraries for QuickBASIC. The form with the extension ".LIB" is for use with LINK, for creating stand-alone programs which do not require the QuickBASIC environment. This sort of library can be made or manipulated using the LIB utility provided with QuickBASIC. The form of library with the extension ".QLB" is for use in the QuickBASIC environment. It is created with LINK and (unfortunately) can't be manipulated at all. To use a QLB library, you specify the /L parameter when starting up QB: QB /L BASWIZ You can optionally include the name of your program before the /L switch. To use a LIB library, you specify the name of the library when you LINK your program. Either let LINK prompt you for the library or type something like this: BC program/O; (or whatever) LINK program/EX,,NUL,BASWIZ If you are in the QuickBASIC environment and direct the compiler to produce an .EXE file, it will automatically link the library for you if you started up QB with the /L option. Suppose you have more than one library that you wish to use? Well, provided that you have both of the libraries in .LIB form, this presents no problem. To create a combined .LIB library, use the LIB utility to extract all of the .OBJ files from one .LIB and add them to the other one. You can convert the new combined library to .QLB form by using a special LINK syntax: LINK combined.LIB/Q,,NUL,BQLB45 The last two digits of "BQLBxx" represent the version of the compiler that you have. It doesn't necessarily match the formal version number, though, so you might just want to use DIR and see what the name of the file really is. BQLBxx.LIB is one of the files that comes with QuickBASIC. If you experience a LINK error, make sure that you're using the The QBNews Page 4 Volume 1, Number 5 December 1, 1990 current version of LINK. I've heard from many people who turn out to have the wrong version of LINK in their PATH somewhere... when LINK starts up, it will display its version number on the screen. The version should be around 3.69 as of QuickBASIC 4.5. You must use the LINK that came with QuickBASIC-- the one that comes with Quick C is incompatible and the one that came with BASCOM 6.0 (the one with two periods in the version number) has a few bugs. All clear? No?! Check your QuickBASIC manual for more information! ********************************************************************** Tom Hanlin is the author of the ADVBAS and BASWIZ shareware libraries, among others. He can be reached through the QUIK_BAS echo on Fidonet or in care of this newsletter. ********************************************************************** The QBNews Page 5 Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- A d v e r t i s e m e n t ---------------------------------------------------------------------- STAR PROGRAMMERS REACH FOR THE MOON! Crescent Software publishes the highest quality support products available for use with QuickBASIC and BASIC 7 PDS. We offer twelve different libraries, and all are extremely easy to use. Our software has received outstanding reviews in all of the major computer publications, including PC Magazine, Byte, Dr. Dobb's Journal, PC Resource, and too many others to mention here. Our two most popular products are described briefly below. Please call or write for more information. We offer tools for screen design, graphics, scientific applications, and more. All Crescent Software products come with full commented source code, and require no royalty payments when added to your own programs. Free technical support is included. QuickPak Professional ($169) is the most comprehensive collection of QuickBASIC tools ever developed. It features more than 450 routines you can add to your own programs, a beautifully typeset manual in an IBM-style D-ring binder, and 120 demonstration programs. Included are routines for searching and sorting any type of array, DOS services for extremely fast file access, sophisticated pull-down and vertical menus with integrated mouse support, and fast video routines that work in the 25-, 43-, or 50-line EGA and VGA text modes. Also included are a real word processor you can add to your programs, a graphics-mode screen print routine that supports all BASIC video modes, routines to read and write Lotus 1-2-3 .WKS files, an assembly language tutorial, and much more. This is our most popular library, and it offers a wealth of functionality and educational value. Fully commented BASIC and assembler source is included. QuickPak Professional requires QuickBASIC 4.0 or later, or BASIC 7 PDS (the PDS version costs $199). P.D.Q. ($129) is a replacement for the BCOM libraries that come with QuickBASIC, and it lets you write programs in BASIC that are smaller and more efficient than any other high-level language. P.D.Q. also lets you easily create TSR programs and interrupt handlers. Minimum tasks can be written in 1K. P.D.Q. programs are much smaller than an equivalent written in C, and are as little as one-tenth the size of a QuickBASIC counterpart. Of course, they are also very fast. Numerous sample BASIC applications are provided, including a TSR screen capture program, a pop-up calculator, work-alike copies of several Norton Utilities, and much more. Because we also include the complete library source code, examining P.D.Q. is an excellent way to learn about BASIC's internal workings. Please note that P.D.Q. is a subset of Microsoft BASIC, and does not support floating point math. A communications toolbox is available separately for $79. P.D.Q. requires QuickBASIC 4.0 or later, or BASIC 7.x PDS. Please add $6 per order for 2nd day UPS shipping in the US. Crescent Software, 32 Seventy Acres, West Redding, CT 06896 Phone: 203-438-5300, FAX: 203-431-4626, CompuServe 72657,3070 The QBNews Page 6 ---------------------------------------------------------------------- S w a p S h o p ---------------------------------------------------------------------- 'Graphics and text screen dumps by Alan J. Fridlund, Ph.D. DEFINT A-Z SUB DumpScr (DisplayType, PrinterType$) STATIC 'Subroutine DumpScr. 'Alan J. Fridlund, Ph.D., April-August, 1988. 'Adapted from routine by Charles Petzold in PC Magazine, 'Vol 6, No 2, Jan 27, 1987. 'QuickBasic 4.0 Graphics or Text Screen Dumps to: ' Epson (EPS), IBM Proprinter (IBM), or HP LaserJet (HP) printers. 'Dumps graphics screens in landscape (sideways) mode. 'DisplayType: ' 0 = CGA 200x640 pixel mode (SCREEN 2). ' 1 = EGA 200x640 pixel mode (SCREEN 8). ' 2 = EGA 350x640 pixel mode (SCREEN 9). ' 3 = VGA 480x640 pixel mode (SCREEN 11 or 12). ' 4 = Text screens for all display types. 'PrinterType$: ' "EPS" = Epson-compatible dot matrix printer. ' "IBM" = IBM Proprinter-compatible printer. ' "HPL" = Hewlett-Packard LaserJet printer w/ 75 dpi graphics. IF DisplayType = 0 OR DisplayType = 1 THEN BottomPixel = 199: NTAB = 8 IF DisplayType = 2 THEN BottomPixel = 349: NTAB = 12 IF DisplayType = 3 THEN BottomPixel = 479: NTAB = 0 Esc$ = CHR$(27) IF DisplayType = 4 THEN WIDTH LPRINT 80 LPRINT STRING$(9, 13) 'Center dump on page. FOR ROW = 1 TO 25 FOR COL = 1 TO 80 KIN$ = INKEY$: IF KIN$ = Esc$ THEN GOTO GraphEnd'Esc terminates. CHARACTER = SCREEN(ROW, COL) CHAR$ = "-" 'Substitute for unprintable chars. IF CHARACTER > 31 AND CHARACTER < 126 THEN CHAR$ = CHR$(CHARACTER) END IF LPRINT CHAR$; NEXT NEXT END IF IF DisplayType < 4 AND (PrinterType$ = "EPS" OR PrinterType$ = "IBM")_ THEN The QBNews Page 7 Volume 1, Number 5 December 1, 1990 WIDTH LPRINT 255 LPRINT Esc$ + "@": LPRINT STRING$(5, 13)'Reset printer, center graph. PIXEL400$ = Esc$ + CHR$(75) + CHR$(144) + CHR$(1)'400 pixels perline. PIXEL350$ = Esc$ + CHR$(75) + CHR$(94) + CHR$(1)'350 pixels per line. PIXEL480$ = Esc$ + CHR$(75) + CHR$(224) + CHR$(1)'480 pixels perline. IF DisplayType < 2 THEN NPIXEL$ = PIXEL400$'CGA pixels doubleprinted. IF DisplayType = 2 THEN NPIXEL$ = PIXEL350$ IF DisplayType = 3 THEN NPIXEL$ = PIXEL480$ NormSp$ = Esc$ + CHR$(65) + CHR$(12) 'Normal line spacing. NarrSp$ = Esc$ + CHR$(65) + CHR$(8)'Narrow line spacing for graphics. IF PrinterType$ = "IBM" THEN NormSp$ = NormSp$ + Esc$ + CHR$(50) NarrSp$ = NarrSp$ + Esc$ + CHR$(50) END IF LPRINT NarrSp$ FOR COL = 0 TO 639 STEP 8 LPRINT TAB(NTAB); LPRINT NPIXEL$; FOR ROW = BottomPixel TO 0 STEP -1 KIN$ = INKEY$: IF KIN$ = Esc$ THEN GOTO GraphEnd BYTE = 0 FOR PIXEL = 0 TO 7 IF POINT(COL + PIXEL, ROW) > 0 THEN BYTE = BYTE OR 2 ^ (7 - PIXEL) END IF NEXT LPRINT CHR$(BYTE); IF DisplayType < 2 THEN LPRINT CHR$(BYTE); NEXT 'CGA/lowres EGA pixels LPRINT 'are double-printed. NEXT LPRINT NormSp$; END IF IF DisplayType < 4 AND PrinterType$ = "HPL" THEN WIDTH LPRINT 255 IF DisplayType < 2 THEN NPIXEL$ = Esc$ + "*p400x300Y"'Center cursor. IF DisplayType = 2 THEN NPIXEL$ = Esc$ + "*p510x300Y" IF DisplayType = 3 THEN NPIXEL$ = Esc$ + "*p240x300Y" NPIXEL$ = NPIXEL$ + Esc$ + "*t75R" + Esc$ + "*r1A"'Start 75 dpi mode LPRINT NPIXEL$ IF DisplayType < 2 THEN NPIXEL$ = Esc$ + "*b50W" 'Expect xxW pixels. IF DisplayType = 2 THEN NPIXEL$ = Esc$ + "*b44W" IF DisplayType = 3 THEN NPIXEL$ = Esc$ + "*b60W" FOR COL = 0 TO 639 KIN$ = INKEY$: IF KIN$ = Esc$ THEN GOTO GraphEnd LPRINT NPIXEL$; FOR ROW = BottomPixel TO 0 STEP -8 IF DisplayType < 2 THEN 'Separate point into 2 bytes HIBYTE = 0: LOBYTE = 0 ' for CGA/low-res EGA modes. FOR PIXEL = 0 TO 7 IF POINT(COL, ROW - PIXEL) > 0 THEN IF PIXEL <= 3 THEN The QBNews Page 8 Volume 1, Number 5 December 1, 1990 LOBYTE = LOBYTE OR 2 ^ ((3 - PIXEL) * 2) OR _ 2 ^ ((4 - PIXEL) * 2 - 1) END IF IF PIXEL >= 4 THEN HIBYTE = HIBYTE OR 2 ^ ((7 - PIXEL) * 2) OR _ 2 ^ ((8 - PIXEL) * 2 - 1) END IF END IF NEXT BYT$ = CHR$(LOBYTE) + CHR$(HIBYTE) LPRINT BYT$; END IF IF DisplayType >= 2 THEN LOBYTE = 0 FOR PIXEL = 0 TO 7 IF POINT(COL, ROW - PIXEL) > 0 THEN LOBYTE = LOBYTE OR 2 ^ (7 - PIXEL) END IF NEXT LPRINT CHR$(LOBYTE); END IF NEXT NEXT LPRINT Esc$; "*rB"; Esc$; "E" 'Return to text mode. END IF GraphEnd: LPRINT CHR$(12); 'Page eject. SOUND 1000, 1 'Signal termination. WIDTH LPRINT 80 END SUB ---------------------------------------------------------------------- 'PCX SAVE & PCX LOAD FOR EGA SCREEN 9 (640 x 350, 16 COLOR) 'BY G.C.HARDER, RE-ENGINEERED FROM C SOURCE IN ' "FRACTAL PROGRAMMING IN C" DEFINT A-Z DECLARE SUB PCXSAVE (File$, Pal.Array%()) DECLARE SUB PCXLOAD (File$, Pal.Array%()) SCREEN 9, , 0 DIM Pal.Array%(15) FOR I% = 0 TO 15: READ Pal.Array%(I%): NEXT FOR A = 10 TO 360 STEP 10 X = 320 + 48 * 2 * COS(A * .017453) Y = 175 + 40 * 1.75 * SIN(A * .017453) CIRCLE (X, Y), 120, RND * 15 + 1 NEXT PCXSAVE "DEMO.PCX", Pal.Array%() CLS PCXLOAD "DEMO.PCX", Pal.Array%() 'default Palette Colors DATA 0,1,2,3,4,5,20,7,56,57,58,59,60,61,62,63 '---------------------------------------------------------------- The QBNews Page 9 Volume 1, Number 5 December 1, 1990 SUB PCXLOAD (File$, Pal.Array%()) STATIC SCREEN 9, , 0: OPEN File$ FOR BINARY AS #1: SEEK #1, 17 DIM Byte AS STRING * 1 FOR I% = 0 TO 15 GET #1, , Byte: Red% = ASC(Byte) / 85 GET #1, , Byte: Green% = ASC(Byte) / 85 GET #1, , Byte: Blue% = ASC(Byte) / 85 Red% = ((Red% AND 1) * 32) OR ((Red% AND 2) * 2) Green% = ((Green% AND 1) * 16) OR (Green% AND 2) Blue% = ((Blue% AND 1) * 8) OR ((Blue% AND 2) \ 2) Hue% = Red% OR Green% OR Blue%: Pal.Array%(I%) = Hue% NEXT PALETTE USING Pal.Array%(0): SEEK #1, 129: DEF SEG = &HA000 FOR K% = 0 TO 349 Addr% = 80 * K%: Line.end% = Addr% + 80: J% = 1 DO WHILE J% <= 4 B% = J% IF J% = 3 THEN B% = 4 IF J% = 4 THEN B% = 8 OUT &H3C4, 2: OUT &H3C5, B% GET #1, , Byte: Byte.1% = ASC(Byte) IF (Byte.1% AND 192) <> 192 THEN POKE Addr%, Byte.1%: Addr% = Addr% + 1 IF Addr% >= Line.end% THEN Addr% = 80 * K%: J% = J% + 1 ELSE Byte.1% = Byte.1% AND 63 GET #1, , Byte: Byte.2% = ASC(Byte) FOR M% = 1 TO Byte.1% B% = J% IF J% = 3 THEN B% = 4 IF J% = 4 THEN B% = 8 OUT &H3C4, 2: OUT &H3C5, B%: POKE Addr%, Byte.2% Addr% = Addr% + 1 IF Addr% >= Line.end% THEN Addr% = 80 * K%: J% = J% + 1 NEXT END IF LOOP NEXT OUT &H3C4, 2: OUT &H3C5, &HF: DEF SEG : CLOSE #1 END SUB 'PCX SAVE ROUTINE '--------------------------------------------------------------------- SUB PCXSAVE (File$, Pal.Array%()) STATIC OPEN File$ FOR BINARY AS #1 A$ = CHR$(10) + CHR$(5) + CHR$(1) + CHR$(1): PUT #1, , A$ A% = 0: PUT #1, , A%: PUT #1, , A%: A% = 639: PUT #1, , A% A% = 349: PUT #1, , A%: A% = 640: PUT #1, , A%: A% = 350: PUT #1, , A% FOR I% = 0 TO 15 Red% = (((Pal.Array%(I%) AND 32) \ 32) OR _ ((Pal.Array%(I%) AND 4) \ 2)) * 85 Green% = (((Pal.Array%(I%) AND 16) \ 16) OR _ (Pal.Array%(I%) AND 2)) * 85 Blue% = (((Pal.Array%(I%) AND 8) \ 8) OR _ The QBNews Page 10 Volume 1, Number 5 December 1, 1990 ((Pal.Array%(I%) AND 1) * 2)) * 85 A$ = CHR$(Red%) + CHR$(Green%) + CHR$(Blue%): PUT #1, , A$ NEXT A$ = CHR$(0) + CHR$(4): PUT #1, , A$: A% = 80: PUT #1, , A% A% = 0: PUT #1, , A%: A% = 0 FOR I% = 70 TO 127 STEP 2 PUT #1, , A% NEXT I% DEF SEG = &HA000 FOR K% = 0 TO 349 SCREEN 9, , 0: Add1% = 80 * K%: Number% = 1: J% = 0 OUT &H3CE, 4: OUT &H3CF, 0: OUT &H3CE, 5: OUT &H3CF, 0 Old% = PEEK(Add1%): Add2% = 1 FOR I% = 1 TO 320 IF I% = 320 THEN IF Old% <> 1 THEN New% = 1 ELSE New% = 0 ELSE IF Add2% = 80 THEN J% = J% + 1: Add2% = 0 OUT &H3CE, 4: OUT &H3CF, J%: OUT &H3CE, 5: OUT &H3CF, 0 New% = PEEK(Add1% + Add2%) END IF IF New% = Old% AND Number% < 63 THEN Number% = Number% + 1 ELSE Num.Out% = (Number% OR 192) IF (Number% <> 1) OR ((Old% AND 192) = 192) THEN A$ = CHR$(Num.Out%): PUT #1, , A$ END IF A$ = CHR$(Old%): PUT #1, , A$: Old% = New%: Number% = 1 END IF Add2% = Add2% + 1 NEXT PSET (0, K%), 13: PSET (639, K%), 13 NEXT OUT &H3CE, 4: OUT &H3CF, 0: DEF SEG : CLOSE #1 END SUB ---------------------------------------------------------------------- 'Getting the .PCX palette info by Dwain Goforth DIM ByteStr AS STRING * 1 'color data is in bytes OPEN filename$ FOR BINARY AS #1 ' open the PCX file SEEK #1, 17 'position to start of palette info FOR k = 0 TO 15 GET #1, , ByteStr 'get the red byte for color k red = ASC(ByteStr) * 64 \ 256 GET #1, , ByteStr 'get the green byte for color k green = ASC(ByteStr) * 64 \ 256 GET #1, , ByteStr blue = ASC(ByteStr) * 64 \ 256 'get the blue byte for color k PALETTE k, 65536 * blue + 256 * green + red 'now set palette k NEXT k ---------------------------------------------------------------------- The QBNews Page 11 Volume 1, Number 5 December 1, 1990 '+==============================================+ '| DB.BAS 1/25/88 | '| David Perry | '| QuickBASIC 4.0 Source | '| Compile: BC DB /O/D | '| Link: LINK /EX DB; | '| Opens dBASE III .DBF and .DBT files | '| Reads and displays structure .DBF file | '| Then reads and displays data to include | '| up to first 4000 bytes of memo fields | '| This can be redirected to file or printer | '| by typing DB FILENAME.DBF>FILEDAT or | '| DB FILENAME.DBF>PRN | '| Respects flag for deleted records (may | '| be modified--see source below) | '| This is a simple basis for building QB | '| programs which require reading .DBF files | '+==============================================+ [EDITOR'S NOTE] Because of the complexity of this program, it can be found in the file DB.BAS. ---------------------------------------------------------------------- ZV.BAS : A Quick Basic archive file viewer for MS-DOS machines author : Dick Dennison [74270,3636] 914-374-3903 3/12/24 24 hrs supports: ZIP, LZH, ARC, PAK, ZOO archive formats [EDITOR'S NOTE] Due to the complexity of the code, the source code can be found in the file ZV.ZIP. Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- W h o y a g o n n a c a l l ? C A L L I N T E R R U P T ---------------------------------------------------------------------- Format Floppy Disks with QB by Cornel Huth You just wrote a great new program that does everything you could possibly want it to do but one thing - format a blank disk. You could have QB shell to DOS and run FORMAT, but what if FORMAT isn't available? Even if it is, maybe you'd rather not shell because it looks sloppy. Other programs can format blank disks so you ought to be able to do it, too. Right? Well, now you can. QBFORMAT.BAS is a plug-and-play QB4 module that will format a DOS disk with one simple function call. You wil need QB4 or higher and a floppy disk. The code supports 360K drives for XTs and 360K and 1.2M drives for ATs. 720K and 1.44M 3.5- inch drives should format just fine on ATs but without the actual hardware I can't verify that it does. I also can't find XT-BIOS support documentation for the 3.5-in drives so you'll have to do the digging and add the code if you need to support those drives on an XT. To use the code, call the routine with the drive and media type. Floppy drives start at 0, i.e., drive A: is 0, B: is 1 (no, your C: hard drive is not 2, it's 128, so don't worry). The media types are described in the source by CONST declarations. By doing the same in the calling program the call to format a disk would be as simple as this: xerr% = QBFORMAT%(0, DS9) IF xerr% THEN errl% = xerr% \ 256 errc% = xerr% AND 255 END IF 0 is drive A:, DS9 is the media byte for a 360K floppy. The function returns a multiplexed error code. The high byte is the level at which the error occurred and the low byte is the BIOS error code. See the source for more along with descriptions of the level and error codes. Somebody goofed when he assigned the media byte for 720K 3.5-inch floppies. He used the same media byte as the 1.2M 5.25-inch AT floppy. To differentiate the two, QBFORMAT expects 1.2M media byte arguments to be positive &HF9 and 720K media byte arguments to be negative &HF9 (-&HF9). See the source for more. The source is all QB except for the INTERRUPTX routine. This routine is supplied by Microsoft in the QB.LIB/QLB file and the source is INTRPT.ASM. QB 4.00's INTRPT.ASM has 2 bugs, one so bad that it can not be used with QBFORMAT.BAS. QB 4.00b has one bug, not so bad that it can't be used with QBFORMAT but it does prevent the error code from being returned properly if you call INT 25/26h (QBFORMAT calls on BIOS INT 13h). Included with the QBFORMAT code should be the The QBNews Page 12 Volume 1, Number 5 December 1, 1990 corrected version of INTRPT.OBJ. Hopefully the ASM source can also be included (if space allows). Replace your INTRPT.OBJ with this one, especially if you are using QB 4.00 (initial release). The code speaks for itself (it does to me). If you're having trouble understanding the code, drag out the old QB manual and piece through the code. If the logic behind MS-DOS formatting is difficult to follow, consult a PC BIOS book such as those by Peter Norton, Ray Duncan (his Advanced MS-DOS), the Phoenix people or Robert Jourdain (one alone probably won't do it). PCDOS texts usually won't cover the BIOS to the required detail so those won't be of much help in the format process. However, they may provide you with details of the structure of the boot record, file allocation tables, and root directory. ********************************************************************** Cornel Huth is the author of various shareware and commercial tools for use with QuickBASIC. He can be reached through this newsletter. ********************************************************************** [EDITOR'S NOTE] All code and files for this article can be found in the file QBFORMAT.ZIP. I have tested this code and found it to work on all disk types on MY 386. You should thoroughly test this code on any machines you plan to use. If you find any problems, I am sure Cornel would be interested in hearing from you. The QBNews Page 13 Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- P o w e r P r o g r a m m i n g ---------------------------------------------------------------------- Scenic Views by way of the Video Map by Larry Stone Creating an attractive set of screens for your program is, often times, more important than WHAT your program actually does or doesn't do. As Marshall McCluine would say, "the medium is the message". Packaging is everything when selling to the public. After all, how much research, development, and skill went into the "growing" of America's favorite pet, the "pet rock"? None. However, plenty of resources were involved in packaging and promoting it so that the con- sumer would buy it. Computer software is packaged twice. The first packaging is the box itself and is more important for selling games or Vapor-Ware. The next type of packaging is within the software itself. It is the bells and whistles, the pizzazz; the sizzle along with the steak. It is what turns dull, boring, productive software into productive software that is exciting and fun to use. Our bell and whistle stop will be, where else - the monitor. To navigate the monitor, we will need a good map, a video map. Understanding and playing with the video map is the key to many a bell and a whistle. The video map holds text mode screens in a simple and redundant fashion. It is this simplicity and redundancy that allows us to create dazzling windows that implode, slide, push and pop into view. The map is an area of memory that can be considered a grid holding character and color information inside of alternating cells. If we designate a capital "C" to represent "character" and "A" for "color Attribute", we could depict the map as: 012345... ...159 CACACACACACACACACACACACACACACACACACACACACACACACACACACACACACA CACACACACACACACACACACACACACACACACACACACACACACACACACACACACACA CACACACACACACACACACACACACACACACACACACACACACACACACACACACACACA Each column contains either character data or color data but not both. Each "CA" pair represents data for one column-row location on a monitor. This means that there are 80 pairs per row or, 160 pieces of information per row. Knowing this makes accessing the map easier. If we want to read or write to row 1, column 1 (PRINT 1, 1), we go to the map and put our character into position "0" and our color into "1". PRINT 1, 80 would have a map address of 158 for the character and 159 for the color. PRINT 2, 1 address would be 160 and 161. An 80x25 mode screen is mapped from position 0 to 3999 (4000 positions). A screen in 80x50 starts at 0 and ends at 7999 (8000 positions). Knowing how the video map stores data makes it easy to build an array for our windows. The easiest array to build would be an integer array that corresponds to every element in the map. To create a one to one array would require an array DIMensioned for 4000 elements with The QBNews Page 14 Volume 1, Number 5 December 1, 1990 an 80x25 text screen. An array of 8000 elements would be required for an 80x50 screen. Although these arrays make our programming very easy due to the one to one correlation, they are, never-the-less, very in- efficient. This is because a simple integer is a two byte word. The video map uses one integer to hold information for each "CA" pair. The high byte holds character information and the low byte holds the color data. When we make an integer array DIMmed to 4000 elements, there is 4000 bytes of wasted space (each integer is a two byte word - hence, an array DIMmed to 4000 elements uses 8000 bytes.) What we want is an 2000 elements array that houses 4000 bytes. Because we are going for memory efficiency, and because we access into the video map by POKEing one byte at a time, we need a translator to move data from our arrays to the map and back. In other words, we will need to combine bytes into integers and extract bytes from integers. When we do so, we need a convenient method to keep track of where we are in both the map and the array. I find that the easi- est way to do this is to simply keep track of where we are in the map then divide that number by two to correlate it to our position in the array. Fancy screen writes are, generally, accomplished by manipulating data from our array via one or more loops and STEPping through these loops in a manner that will write our screen in a dazzling manner. The accompanying code (DAZZLING.BAS and DAZZDEMO.BAS) illustrates eleven different, dazzling screen writes. Because each of these methods are performed in two different ways (top to bottom, bottom to top and, right to left, left to right), the effect is 22 completely different screen routines in only three subprograms. In addition to the fancy screen display routines, the code supplies five other useful routines. ReadBinFile reads a disk file that was formed by a simple binary dump of the video map. You could create your screens using TheDraw, save your files using the "BIN" option and read them into your screen array with ReadBinFile. An 80x25 text screen will produce a 4000 byte BIN file. This type of file is fast to read into arrays and they are slightly smaller than a Bsave file (4007 bytes). The two BIN files used by my sample code, CRESCENT.BIN and SHUTTLE.BIN are re-creations of screens used by The Crescent Software Support BBS and a modified shuttle used by TheDraw as one of their samples. The ReadBinFile rou- tine also does something no others of its ilk do. It can read the screen to into a row position other than row number one. This allows a screen that was saved in 80x25 mode to be re-positioned for higher resolutions (80x43 or 80x50). The sample code, DAZZDEMO, creates 10 leading rows for high resolution. It then uses the StuffMess routine to fill these leading (and trailing rows). In this manner, one screen can be saved in a low resolution mode and expanded for high resolution systems. The StuffMess subprogram stuffs a message into a screen array BEFORE it is displayed on the monitor. Pass it the message string, the array to stuff, and the fore and background colors, and the row and column location. DAZZDEMO.BAS uses this routine to create a second story to the QBNews Software Library building and to expand the planet The QBNews Page 15 Volume 1, Number 5 December 1, 1990 earth when it runs on a video system that supports screen modes 80x43 or 80x50. If you study the accompanying code,you will notice that when StuffMess adds a second story to the QBNews Library, it uses a string that is 800 bytes long. The call to StuffMess simply locates the Mess string at row 1, column 1. StuffMess, in conjunction with the Curtain routine, produces the illusion of the shuttle doors opening. This is accomplished by filling the monitor with the bytes from the array with the shuttle picture. Once the picture is displayed, StuffMess is used to "redraw" that portion of the array that contains the shuttle doors. The array is, again, sent to the monitor only, this time, it is dis- played over the original shuttle picture with a call to the Curtain routine. The Curtain routine redisplays the shuttle from the middle outward. The effect is that the shuttle doors appear to open before your very eyes! TickPause is a simple delay that pauses in increments of 18 ticks per second. Simply pass in the number of ticks to pause. TickPause does NOT use BASIC's TIMER and, as consequence, does not access any of the Floating point library. This can translate as a huge savings in the compiled size of your exe files (DAZZLING, with it's 8 subprograms that perform 27 routines, compiles to only 7,100 bytes or so). GetMonitorSeg returns the starting address of the video map. If it senses a color system, it returns &HB800. Otherwise, it returns &HB000 as the starting address. Shake is a slight modification of a routine originally published at the end of 1988 by HumbleWare Custom Programming. It reprograms the 6845 CRT controllers viewport into video RAM. The shaking screen produced is quite radical. Don't watch it if you are prone to getting sea sick. Two other routines that are worth mentioning are not included in DAZZLING.BAS but are part of the demo program, DAZZDEMO. One uses the WIDTH statement to test and set your monitor for it's highest resolu- tion. If your monitor is EGA or VGA, "WIDTH , 43" or "WIDTH , 50" will force 80x43 / 80x50 screen mode. This technique uses error trapping. If someone knows how to test for a system's capability to use 80x43 or 80x50 modes without error trapping, I sure would like to know how. The other routine creates a continuous noise by reprogramming the timer with a new clock rate and outputs this straight to the speaker. This routine is one among several, useful sound routines published in "Inside Microsoft BASIC", by the Cobb Group, July 1990. If you don't subscribe to this magazine, this little routine should wet your whistle. If you compile DAZZLING.BAS as an object module, three variables must be declared as COMMON SHARED within your main code: Monitor AS INTEGER, ScrnEls AS INTEGER, and MaxLine AS INTEGER. To simplify your coding and to assure that the COMMON SHARED blocks will be the same, the code includes DAZZLING.BI which contains the declarations for the routines and COMMON SHARED blocks required. If you compile DAZZLING for use with your other code, REM $INCLUDE: 'DAZZLING.BI' immediately The QBNews Page 16 Volume 1, Number 5 December 1, 1990 after your last DECLARE and prior to your COMMON SHARED statement. Or, you could modify DAZZLING.BI and re-compile as your needs dictate. Follow the instructions at the top of DAZZLING.BAS and DAZZDEMO.BAS for linking and compiling into a stand alone program. One final note. The fancy screen routines used by DAZZLING.BAS use the POKE command. On older CGA systems, using a POKE to the sys- tem's monitor may cause snow because these old CGA systems cannot handle the direct screen activity during re-trace. ********************************************************************** Larry Stone is President of LSRGroup and is involved in writing software for marine and aquatic research, as well as, data acquisition software systems. He has also authored various shareware programs such as "SERVICES", a file, directory, disk and archive manager rated a trophy by the "PUBLIC BRAND SOFTWARE" shareware catalog. Larry can be reached at LSRGroup, P.O. Box 5715, Charleston, OR 97420, or in care of this newsletter or, contact him via The Empire Builder BBS 1:356/0 1:356/1 1:356/4 (14400 Baud), (503) 888-4121. ********************************************************************** [EDITOR'S NOTE] All code for this article can be found in the file DAZZLING.ZIP. The QBNews Page 17 Volume 1, Number 5 December 1, 1990 Self-Cloning Exe's Revisted by Ronny Ong In Volume 1, Number 3 of QBNews, Larry Stone presented "How to Make a Self-Cloning Exe in QuickBASIC." In his sample code, you needed to define a value for MyProg$, the filename of the EXE that would be accessing itself. Larry did not go into the considerations involved in defining MyProg$. This article will. You could simply hard-code a filename into the program, but that would prevent users from renaming it, an inconvenience. The program could ask users for its own filename, making the program look unnecessarily dumb. You would also have the headache of getting and validating input, and handling all the possible errors like invalid filenames and valid filenames which are simply wrong, i.e. not the true name of the program. And then there is the drive/path specification. You certainly cannot hard-code that. You might get away with forcing users to keep the program in a certain directory, but not on a certain drive. There are too many different hardware configurations in today's PC world. Think you can leave off the drive/path and let DOS look in the default drive/path? Think again: (1) What if the program is located in the DOS PATH? It can get loaded even if it is not in the default drive/path, but the OPEN statement will not find it (unless users just happen to use DPATH or APPEND and just happen to specify the same drive/path as in PATH). (2) What if the program gets executed through PC Magazine's RUN.COM utility, which searches all directories on a drive regardless of PATH? (3) What if users execute the program from a different drive/path by specifying the drive/path of the program along with the filename? Fortunately, there is a way to avoid all these problems. The sample program contained in FILESPEC.BAS demonstrates how programs written in QuickBASIC Version 4 or higher and compiled and linked to an EXE file can find out the complete drive, path, filename, and .EXE extension the program was loaded as. This information is stored in memory when DOS loads a program through its "EXEC" function. The underlying approach can be applied to COM or EXE files in any language. When incorporating this technique into your self-cloning programs, you should get to the OPEN statement immediately if possible, in case users try to execute your program from diskette and then remove the diskette. If you can put this code and your I/O to the EXE up front, the disk activity will look like it is part of DOS's loading of your program. Hard-coding may look like an easy way out when compared to the code above, but if your program is good enough to deserve a self- cloning feature, then it deserves the flexibility of this approach. The QBNews Page 18 Volume 1, Number 5 December 1, 1990 ********************************************************************** Ronny Ong is a mainframe systems engineer. He can be reached at P.O. Box 260796, Plano, TX 75026-0796. ********************************************************************** [EDITOR'S NOTE] All code and files for this article can be found in the file FILESPEC.ZIP. The QBNews Page 19 Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- E n g i n e e r s C o r n e r ---------------------------------------------------------------------- GPIB Instrument control from IOTech by Dave Cleary This is the start of a new column that I hope gets some support from all you readers. Engineer's Corner is a column that will cater to all the Scientists and Engineers out there that use QuickBASIC. I feel that the QuickBASIC environment makes the PC an invaluable tool to perform our everyday tasks that just can't be done with a package "off the self". I started using QuickBASIC 2.0 to produce some automated testing stations. Although this can be done in other languages, BASIC, in general, is best suited for this purpose. I am going to discuss the software I use that allows me to control GPIB instruments from QuickBASIC programs. The software is called DRVR488 and is sold by IOTech. I buy the software bundled with IOTech's GP488B interface board, but you can buy the software separately. The DRVR488 software should be compatible with interface boards based on the NEC uPD7210 GPIB controller chip. The software is a TSR you load before you start your QuickBASIC program. It takes less than 50k when resident. DRVR488 installs itself as a device so DOS 3.0 or later is required. If you need to control more than one board, alternate drivers are provided that allow you to have four boards in your PC. I currently use version 2.4 of this software, but there may be later versions available. To load the TSR, the typical command line may look like this: DRVR488 /I /D1 /A&H02E1 /B21 /F8 /TCRLFEOI /ECRLF /SC <\DEVCONF1.DAT The install program handles most of the switches for you, but I want to tell you about one in particular. the /SC <[filename] switch allows you to load a text file that contains information about the devices you are going to be using. Mine looks like this: CONFIG /TICRLFEOI /TOLF /NPTS500 01 CONFIG /TCRLFEOI /NANZ3561 06 CONFIG /TICRLFEOI /TOCRLFEOI /NDVM8840 02 CONFIG /TCRLFEOI /NCNTR5334 03 CONFIG /TCRLFEOI /NCNTR5335 10 CONFIG /TCRLFEOI /NCNTR5370 04 CONFIG /TCRLF /NDVM3600 05 CONFIG /TEOI /NSCP2431 07 This tells DRVR488 information about specific devices at specific addresses. For instance, I have a Fluke 8840 DVM located at address 2. The DVM expects certain terminator characters on input and output of GPIB commands. This is specified by the /TI and /TO switches. Best of all, the /N switch allows your to specify a name in place of the address. Instead of issuing a command like this: PRINT #2, "REMOTE 02" The QBNews Page 20 Volume 1, Number 5 December 1, 1990 I can issue this: PRINT #2, "REMOTE DVM8840" Both commands do exactly the same thing. After the TSR is loaded, your QuickBASIC programs can now access GPIB devices. The first thing your QB program needs to do is to open two files. One of these is for input while the other is for output. My GPIB initialization routine looks like this: '===================================================================== ' IEEE BUS INITIALIZATION SUB '===================================================================== '********************************************************************* ' JUL 1989- VERSION 1.0: Initial Release ' ' IeeebusInit(TimeOut) ' Timeout= Bus Timeout ' '********************************************************************* DEFINT A-Z ErrSub: IF ERR = 76 THEN CLS PRINT "DRVR488 SOFTWARE NOT INITIALIZED! Program Terminating." END ELSE CLS PRINT " Undefined Error # "; ERR; ". Program Terminating." END END IF SUB IeeebusInit (TimeOut) ON ERROR GOTO ErrSub OPEN "\DEV\IEEEOUT" FOR OUTPUT AS #2 OPEN "\DEV\IEEEIN" FOR INPUT AS #3 Rst: IOCTL #2, "BREAK" PRINT #2, "RESET" PRINT #2, "STATUS" INPUT #3, A$ A$ = RIGHT$(A$, 2) IF A$ <> "OK" THEN GOTO Rst PRINT #2, "ERROR OFF" PRINT #2, "TIMEOUT"; STR$(TimeOut) The QBNews Page 21 Volume 1, Number 5 December 1, 1990 ON ERROR GOTO 0 END SUB IEEEIN and IEEEOUT are devices that the TSR installs and are accessed through DOS 3.0's DEV. After I open the files, I reset the controller board by issuing BREAK and RESET commands. I then issue a STATUS command and input a response from the controller board. The board responds with a string that contains various info with the last two characters OK. You are now ready to communicate with your devices. I started using this software back in the days of QB2. At that time, I received a "pre-release" version that didn't have pretty docs and was at version 1.0. This software was a big improvement over what was available for GPIB control back then. While it may seem outdated compared to the GUI software that is available now for GPIB control, it offered a very easy way to control GPIB devices that was similar in syntax to dedicated HP controllers running HP BASIC. This is still true today and it allows you to look at examples from instrument manuals and easily translate them into the appropriate QuickBASIC commands. For instance, the programming manual for the HP 5334A counter gives this example for initializing the 5334 using an HP-85 controller: 10 CLEAR 'Clear controller 20 CLEAR 703 'Clear device at address 3 30 OUTPUT 703 ;"ID" 'Issue ID command to device at address 3 40 ENTER 703 ;A$ 'Read 5334 "ID" response into A$ 50 PRINT A$ 'Print A$ 60 OUTPUT 703 ;"IN" 'Set 5334 to initialized state 70 END 'All done To do the same thing with QuickBASIC and DRVR488, you would do this: PRINT #2, "CLEAR" PRINT #2, "CLEAR CNTR5334" 'You could use 03, but I prefer this PRINT #2, "OUTPUT CNTR5334; ID" PRINT #2, "ENTER CNTR5334" 'This puts the counter into TALK mode INPUT #3, A$ PRINT A$ PRINT #2, "OUTPUT CNTR5334; IN" END As you can see, the syntax is very similar to the examples in the HP manuals. This article is not meant to be a review of the DRVR488 software, but is just my experiences using this decent product. Like I said before, there are now a lot of alternatives available for GPIB instrumentation control that weren't available when I first started using this product, but I am completely satisfied with it. For information about this and other IOTech products, you can The QBNews Page 22 Volume 1, Number 5 December 1, 1990 call or write IOTech at: IOTech, Inc. 25971 Cannon Rd. Cleveland, OH 44146 (216) 439-4091 ********************************************************************** Dave Cleary is an electronics engineer for Vectron Laboratories in Norwalk, CT. Besides putting together the QBNews, he is also the author of Crescent Software's PDQComm. He can be reached in care of this newsletter. ********************************************************************** The QBNews Page 23 Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- N e w a n d N o t e w o r t h y ---------------------------------------------------------------------- GEOGRAF Level One from GEOCOMP Corporation GEOCOMP announces the release of GEOGRAF Level One. GEOGRAF Level One enables programmers to add customized graphics to their application programs, without having to develop complex graphics device drivers for each device they wish to support. The device independence of GEOGRAF Level One allows users to output their graphics to virtually any output device. GEOGRAF Level One is priced at $149. GEOCOMP Corporation 66 Commonwealth Ave. Concord, MA 01742 (800)822-2669 If you have a product you would like to announce in New and Noteworthy, send a 5 or 6 line paragraph to: The QBNews P.O. Box 507 Sandy Hook, CT 06482 The QBNews Page 24 Volume 1, Number 5 December 1, 1990 ---------------------------------------------------------------------- A n d I H e a r d i t T h r o u g h t h e G r a p e v i n e ---------------------------------------------------------------------- Exerpts from the QUIK_BAS echo ===================================================================== Integers between 32K and 64K ===================================================================== From: Larry Stone To: Mike Welch Subject: Boy, do I feel dumb MW> In the QBQUIRKS file by MicroHelp (a freely distributed text file MW> with tons of neato QB tidbits), there's the statement: MW> "Converting large numbers to integers" MW> "A common technique to stuff a large number (between 32767 MW> and 65536) into a BASIC integer is: MW> number! = 50000 MW> number% = VAL("&H" + HEX$(number!)) MW> However, QB's VAL() function is quite sluggish. The MW> following technique produces the same result, and runs MW> approximately 20-30% faster, depending upon the compiler: MW> number! = 50000 MW> number% = CVI(CHR$(number! MOD 256) + CHR$(number! \ 256)) MW> Hmmm. Well, I want the book on these "common techniques." I've MW> beat my head against the wall trying to find a way to speed up MW> long integer processing...when the range was just a few MW> thousand > 32767. Gee. I know hex numbers will be 'smaller,' but MW> why didn't I think... The above technique is slow because of the use of single precission number (forcing the use of the floating point library). In the latest issue of the BUG Newsletter from MicroHelp, they suggest an alternative: BigNum& = 65000 'A big number between 0 and 65535 Intg% = BigNum& + 65536 * (BigNum& > 32767) The above will allow your exe to shrink by 10K+ (assuming no other floating point is used) and executes 47 times faster than the code you listed. If you use either of the above posted techniques, you will discover that the resultant number is a signed, negative number for any number between 32767 and 65536. With this in mind, I tried the following: number& = 65000 IF number& > 32767 THEN intg% = number& - 65536 ELSE intg% = number& The QBNews Page 25 Volume 1, Number 5 December 1, 1990 Along the same vein, when an asm routine passes back a large integer, QB will see it as a negative. To convert the negative to a number in the 32K - 64K range, IF intg% < 0 then number& = intg% + 65536 ELSE number& = intg% This code is somewhat faster again because there is no multiplication used. ===================================================================== From: Tom Hanlin To: Mike Welch Subject: Re: Boy, do I feel dumb You can use that unsigned integer trick in QuickBASIC-- it won't work for PRINTing the numbers, calculations, or anything, but it can be a neat way of saving memory during file storage or in arrays. Just convert the number to a LONG integer when you want to use it: L& = CVL(MKI$(UnsignedInt%) + STRING$(2, 0)) The same trick works the other way, too: IF L& < 65536 THEN UnsignedInt% = CVI(LEFT$(MKL$(L&), 2)) ELSE error I don't -think- this brings in the floating point libraries... it shouldn't, but the BASIC runtimes are so tangled,anything is possible! Actually, it would be a good idea to check that L& >= 0 too, on the long --> int conversion. Either case would indicate an overflow. ===================================================================== From: Mike Welch To: Tom Hanlin Subject: Re: Boy, do I feel dumb Long integers& themselves do not require floating point, but I'm not sure about the CVI function...think it does! ===================================================================== Delay Loops ===================================================================== From: Doug Wilson @ 965/9 To: Tim Downey Subject: Re: PowerBASIC On August 14, Tim Downey writes to Mike Welch (but intends for Henry Piper -- go figure...): > Here's a little routine that does away with most of the overhead > (nearly 3k) of the SLEEP function: > SUB Delay (t%) > StopTime& = (TIMER + t%) MOD 86400 > DO > z$ = INKEY$ > IF INT(TIMER) >= StopTime& THEN EXIT DO The QBNews Page 26 Volume 1, Number 5 December 1, 1990 > LOOP UNTIL z$ <> "" > END SUB > Note the MOD 86400. That takes care of the midnight rollover > problem. Works like a champ for me. You are on the right track, but if you specify a delay which takes you beyond midnight, the MOD 86400 sets StopTime& to a value less than the current value of TIMER and your IF-THEN statement kicks you out of the loop immediately. (I verified this by resetting my system clock to a few seconds before midnight before running the routine.) I posted a solution to this quite a few months ago. Darned if I remember how I did it then, but modifying your code: SUB Delay (t%) StopTime& = TIMER + t% DO IF LEN(INKEY$) THEN EXIT DO LOOP UNTIL (StopTime& - TIMER) MOD 86400 <= 0 END SUB This way, StopTime& is always larger than TIMER while in your delay. If you cross over midnight and TIMER drops back to zero, the MOD 86400 takes care of it. Also, there is no need to convert TIMER to an integer. Decimal fractions work just fine, and since the thrust was to get to smaller code than the SLEEP function, why throw in an extra function? (This is also useful for folks using earlier QB versions since SLEEP was not introduced until QB4.5.) I tested this by resetting my system clock to a few seconds before midnight also and it "works like a champ". (Where have I heard that before? <grin>) You'll also notice I reorganized slightly to make the main function a delay loop rather than a key test loop. It seemed to make more sense to have the delay be the controlling factor in the loop, with the key press just being a way to exit the loop on an exception basis. This is strictly personal preference, either way would work. ====================================================================== From: Larry Westhaver To: Tom Hanlin Subject: Re: REM $INCLUDE Tom, thanks for chiming in about the 'recurring timer question'. I've seen so many wierd approaches to creating a timeout within a program that my head spins from the sheer numbers... You beat me to the punch on this one. The QBNews Page 27 Volume 1, Number 5 December 1, 1990 For some odd reason most folks want to base their timeouts on some calculated time in the future (an offset of x minutes from the present time). It really makes more sense to treat BASIC's TIME$ string or TIMER value as a 'metronome'. Who cares about the actual time when all you want to do is pause for some number of seconds or clock ticks? I've used the method you alluded to many times. I usually approach the problem something like this: SecondsToPause% = 10 DO IF CurrentTIME$ <> TIME$ THEN TickCount% = TickCount% + 1 CurrentTIME$ = TIME$ END IF LOOP UNTIL TickCount% > SecondsToPause% I can think of many variations on this theme, each having it's own advantages. Sometimes I use the most active byte of the BIOS master clock count as a metronome when I need higher resolution than that offered by TIME$. Anyway, my point is this: Do I care if my TIME$ string has done a midnight rollover? Not a bit... I'm just tapping out the seconds to the rythm of TIME$. Larry Westhaver PS. I realize that this is like preaching to the converted but I just wanted to throw in my 2 cents :-) ====================================================================== From: Tom Hanlin To: Tim Kilgore Subject: Re: REM $INCLUDE SUB Delay(xxx) xxy = xxx DO t = TIMER WHILE t = TIMER WEND xxy = xxy - 1 LOOP WHILE xxy END SUB Sorry if it's sloppy, my online time is out! ====================================================================== Binary Numbers ====================================================================== From: Richard Randles The QBNews Page 28 Volume 1, Number 5 December 1, 1990 To: Brian Wasserman Subject: Re: Binary to Numbers * Reply on a message originally to All BW> I understand how to convert Binary to Integers, and Integers back BW> to Binary, but I am lost when it comes to negative numbers. Can BW> you tell me how to convert a binary number to a negative integer? BW> How about a negative integer to a Binary number? To change a positive number into a negative number, you do a two's compliment, that is, invert all bits (change 0's to 1's and 1's to 0's), then add 1. To convert 17 decimal to -17: 00000000 00010001 Invert all bits: 11111111 11101110 Add 1: 11111111 11101111 You follow the same procedure to convert negatives to positives. ====================================================================== From: Louis Siadous To: Spencer Wood Subject: Binary To Decimal Sorry to correct you Spencer but binary to decimal is as follows: Bit 7 6 5 4 3 2 1 0 Value 128 64 32 16 8 4 2 1 Even is you can't remember those you can just do a 2^<bit> to get the decimal value of a particular bit. In other words 2^0 = 1, 2^1 = 2. You are correct that for integers BASIC uses the leftmost bit 15 or 31, integer or long integer, set on (1) to indicate a negative number. Hope this clears it up. Louis ====================================================================== From: Donn Bly To: Brett Emery Subject: 16-bit Numbers on <Aug 30 09:03> Brett Emery (1:159/500) writes (to All): BE> I would like to know how to convert a 16-bit (2 byte) number into BE> binary 1's & 0's. The number is the result from a call BE> interruptx but each bit stands for something else. So I need to BE> know how to get each piece of info out of that number - 16-bit to BE> binary. Thanks to All that reply - Brett Emery. Lets see... L% = <Integer> X$ = "" FOR I% = 15 TO 0 STEP -1 The QBNews Page 29 Volume 1, Number 5 December 1, 1990 IF L% AND (2 ^ I%) THEN X$ = X$ + "1" ELSE X$ = X$ + "0" NEXT PRINT X$ This code should make X$ contain the binary representation of the integer L%. ====================================================================== From: Donn Bly To: Larry Stone Subject: 16-bit Numbers on <Sep 01 17:48> Larry Stone (1:129/34) writes (to Donn Bly): LS> Nice code, Donn. About the best I've ever seen for direct LS> conversions. LS> One question. At 07:02am, I'm only good for fishing. How did you LS> do it? Lots of coffee? Thank you. I gave up on coffee before work -- agrivates my ulcers. I got up early that morning, and firured that I would read a few messages before going to work. LS> is easily modified for 32 bit numbers. Also, looking at it, I LS> see how almost LS> the same code could be employed to convert the string back to an LS> integer. LS> L% = 0 LS> FOR I% = 0 TO 15 LS> IF (VAL(X$) AND (2 ^ I%)) = 2 ^ I% THEN L% = L% + (2 ^ I%) LS> NEXT LS> Is this what you do? No. X$ = "1001" Accum& = 0 FOR I% = 1 TO LEN(X$) Accum& = Accum& * 2 IF MID$(X$, I%, 1) = "1" THEN Accum& = Accum& + 1 NEXT PRINT Accum& This code handles variable length "binary" strings. It can also be easily modified to handle any base number. BTW, your line of code: LS> IF (VAL(X$) AND (2 ^ I%)) = 2 ^ I% THEN L% = L% + (2 ^ I%) can be optimized: IF (VAL(X$) AND (2^I%)) THEN L% = L% + 2 ^ I% The QBNews Page 30 Volume 1, Number 5 December 1, 1990 No need to do those extra 16 calculations, and the comparisons should be a wee bit faster. ;-) However, your code give you what I think are your desired results. X$ should contain a series of ones and zeros, and I don't think that you really want to take the VAL() of it. ====================================================================== From: Cornel Huth To: Louis Siadous Subject: DEC 2 BIN (simply) I've seen a couple of convert to binary routines lately but they seem to need the power function. Since I do a lot of work in assembly, and the power function per se is not at all needed for decimal to binary fformatting I decided to hop into QB and punch a routine that does the conversion without using the ^ operator in BASIC...let's UL it: DEFINT A-Z 'routine to convert base 10 to base 2 hibit = 7 'number of significant bits - 1 test = 240 'decimal number to convert FOR i = 0 TO hibit q = test \ 2 IF q THEN r = test MOD (q * 2) ELSE r = test IF r THEN b2$ = "1" + b2$ ELSE b2$ = "0" + b2$ test = q NEXT PRINT b2$ b2$ = "" That's it. Binary to decimal conversion is left to the reader (don't you just hate that?). chh ====================================================================== From: Richard Randles To: Donn Bly Subject: Re: 16-bit Numbers Here's a way that's a little faster. I just compared the two on a 386SX and got these results. Times shown are for looping through each method 1000 times. Using 2 ^ n Using b + b and x$ + x$ and Mid$(x$ ----------- ------------ Environment 59.48 sec 1.82 sec Compiled 57.45 sec .39 sec L% = <integer> x$ = "0000000000000000" The QBNews Page 31 Volume 1, Number 5 December 1, 1990 Byte& = 1 FOR i% = 16 TO 1 STEP -1 IF L% AND Byte& THEN MID$(x$, i%, 1) = "1" Byte& = Byte& + Byte& NEXT i% If more speed is needed, add Pointer& = SADD(x$) - 1 before the FOR and change the IF line to IF L% AND Byte& then POKE Pointer& + i%, 49 ====================================================================== From: Donn Bly To: Richard Randles Subject: Re: 16-bit Numbers on <Sep 09 11:03> Richard Randles (1:157/98.1) writes (to Donn Bly): RR> Here's a way that's a little faster. I just compared the two on I do something similiar at work. I have a program that converts a two-dimentional array (32 x n) that contains flag bits into long integers for storage. If I can remember it, I will bring in the code and post it tomorrow. RR> Byte& = Byte& + Byte& Here is something that I haven't benchmarked to see which is faster, the above or B = B * 2. The optimizer should turn them into the same code... RR> Pointer& = SADD(x$) - 1 RR> before the FOR and change the IF line to RR> IF L% AND Byte& then POKE Pointer& + i%, 49 I wouldn't. I never trust SADD beyond a single line of code. ====================================================================== Colors ====================================================================== From: Larry Stone To: Dan Davidson Msg #153, 29-Sep-90 Subject: monochrome display toggles > I use QuickBASIC 4.5, with a monochrome monitor. I can use bright, > underlined, flashing or reverse display in setting up my DOS prompt, > but haven't found out how to do those things with QuickBASIC. Monochrome COLOR commands: COLOR Description ***** *********** 7, 0 Normal white on black 15, 0 Intense white on black The QBNews Page 32 Volume 1, Number 5 December 1, 1990 0, 7 Inverse video 1, 0 Underlined white on black 9, 0 Intense underlined white on black 23, 0 Flashing white on black 31, 0 Flashing intense white on black 17, 0 Flashing underlined white on black 25, 0 Flashing intense underlined white on black Not all monochrome display adapters will handle all of the above listed colors. BTW, monochrome attributes are either normal, intense, or underlined, or, a combination thereof. Underlined is produced with the forground color attribute *blue*. To calculate intense, add 8 to the attribute, ie, intense white is 7 + 8 = 15, intense underlined is intense blue or 1 + 8 = 9. To calculate flashing, add 16 to the forground color, ie, intense flashing white is 15 + 16 = 31. Inverse video cannot be underlined nor intense. COLOR 7, 0: PRINT "This is normal" COLOR 1, 0: PRINT "Underlined" COLOR 9, 0: PRINT "Intense underline" COLOR 23, 0: PRINT "Flashing" COLOR 25, 0: PRINT "Intense flashing" ====================================================================== BSAVE/BLOAD ====================================================================== From: Larry Westhaver To: Tim Kilgore Subject: Binary files Tim, the 7 byte header that QuickBASIC tacks onto the front of any BSAVE contains some information that QuickBASIC needs to BLOAD the file *if* you choose to use the syntax: BLOAD "filename" without the offset parameter. Have you ever wondered how BLOAD knows where in memory the image came from? Anyway, here's the skinny... Byte #1 - Always an ASCII 253 (identifies the file as BSAVE/BLOAD) Byte #2 - Low byte of segment where image originated Byte #3 - High byte of segment where image originated Byte #4 - Low byte of offset into segment where file originated Byte #5 - High byte of offset into segment where file originated Byte #6 - Low Byte of image length Byte #7 - High byte of image length So, to interpret the header... 'define BSAVE file header TYPE HeaderStruc BSaveID AS STRING * 1 'ID always ASCII 253 (byte) SegByte AS INTEGER 'Segment of data origin (word) The QBNews Page 33 Volume 1, Number 5 December 1, 1990 OffByte AS INTEGER 'Offset of data origin (word) LenByte AS INTEGER 'Length of data (word) END TYPE 'allocate memory for BSAVE file header structure DIM Header AS HeaderStruc 'open a BSAVE file OPEN "E:\GDP\SCREENS\XMAS.80C" FOR BINARY AS #1 LEN = LEN(Header) GET #1, 1, Header CLOSE #1 CLS 'ID byte PRINT " BSAVE file ID byte:"; ASC(Header.BSaveID) 'segment of origin PRINT "BSAVE'd from Segment: "; HEX$(Header.SegByte) 'offset of origin PRINT " BSAVE'd from Offset: "; HEX$(Header.OffByte) 'length of data PRINT "Length of BSAVE data:"; Header.LenByte I hope this helps, I uncovered these facts in 1985 when I wrote GDPEdit (a screen design tool that I sell mail order through Komputerwerk Inc., one of the first QuickBASIC add-on library marketers) Larry ====================================================================== Do It with Booleans ====================================================================== From: Tom Hanlin To: All Subject: Booleans A little bit <!> on Booleans, since it appears they're not as well known as they might be... uickBASIC allows any conditional expression to be converted to a Boolean value. In other words, you can say something like: A = (B <> 0) ...in which case, A will be zero if B is zero, or -1 if B is not zero. The parentheses are important. As far as BASIC is concerned, "true" is any nonzero value. Given a conditional of the type above, "true" will always evaluate to -1, however. This is because QuickBASIC treats its Boolean operations like the equivalent arithmetic operations: NOT -1 is 0, NOT 0 is -1; however, NOT 1 won't give you 0, but rather something like -2, which is also "true"... explanation? The numbers are treated as a sequence The QBNews Page 34 Volume 1, Number 5 December 1, 1990 of bits: zero is 0000,0000, and negative one is 1111,1111. Any Boolean-type operation is essentially equivalent to a math operation in QuickBASIC, operating on all of the bits in the numbers concerned. I'm not sure I'm making sense to y'all here, but so it goes... This equivalence is a bit dangerous but mostly useful. It allows you to make an integer into a Boolean value, essentially. You can do things like: IF PrinterSelected THEN LPRINT St$ ELE PRINT St$ More on this later, I'm running out of time right now. Booleans (named after George Boole, who invented such math... incidentally, he was delighted when he discovered 'em. He was a pure theoretical mathematician and was pleased to come up with something that [he thought] would never have any practical application! In truth, it's fundamental to computers, valuable in symbolic logic and philosophy, and very, very practical for many things!) [EDITOR'S NOTE] The purpose of this conference is to discuss Microsoft QuickBASIC and related applications and utilities. SysOps looking for a GroupMail or EchoMail link into QUIK_BAS should contact Fidonet node 107/323 or call 1-201-247-8252. People wishing to read QUIK_BAS can do so by calling The Crescent Software Support BBS at 1-203-426-5958. The QBNews Page 35 ---------------------------------------------------------------------- E O F ---------------------------------------------------------------------- Receiving The QBNews The QBNews is distributed mainly through BBS systems around the world. Some of the networks it gets distributed through are SDS (Software Distribution System), PDN (Programmers Distribution Network), and SDN (Shareware Distribution Network). Ask the sysop of your local board about these networks to see if there is a node in your area. The QBNews can also be found on CompuServe in the MSLang (Microsoft Language) forum. It can be found in file area 1 or 2 of that forum. Just search for the keyword QBNEWS. The QBNews will also be available on PC-Link. I send them to Steve Craver, who is the BASIC Programming Forum Host on PC-LINK and he will make them available. I would appreciate anybody who could upload The QBNews to other services such as GENIE since I don't have access to these. I have also set up a high speed distribution network for people who would like to download The QBNews at 9600 baud. The following boards allow first time callers download privileges also. They are: Name Sysop Location Number Node # --------------------------------------------------------------------- Treasure Island Don Dawson Danbury, CT 203-791-8532 1:141/730 Gulf Coast BBS Jim Brewer New PortRichey,FL 813-856-7926 1:3619/20 221B Baker St. James Young Panama City,FL 904-871-6536 1:3608/1 EMC/80 Jim Harre St. Louis, MO 314-843-0001 1:100/555 Empire Builder Bob Fetherson Charleston, OR 503-888-4121 1:356/4 Finally, you can download The QBNews from these vendors BBS's: The Crescent Software Support BBS 203-426-5958 The Microhelp BUG BBS 404-552-0567 404-594-9625 You do not have to be a customer of these vendors in order to download The QBNews, but the Microhelp BBS only allows non-members 15 minutes of time per call. If you would like to receive The QBNews on disk, I am now offering a subscription for volume 2 next year. If you subscribe, you will receive a disk with all the issue from volume 1, plus you will The QBNews Page 36 Volume 1, Number 5 December 1, 1990 receive 4 disks next year as each of the 4 issues of volume 2 come out. I have decided against offering individual disks as I don't have the time to administer that. The cost of a subscription is as follows: Base Price for Volume 2: $15.00 Additional charge for 3.5" disks: $5.00 Additional charge for international: $5.00 The base price includes 5.25" 360k disks. Send a check or money order in U.S. funds to: The QBNews P.O. Box 507 Sandy Hook, CT 06482 Please be sure to specify what archive format you want. The QBNews normally uses PKZip as it's archiver. ---------------------------------------------------------------------- Advertising in The QBNews The QBNews now offers an outstanding opportunity to advertise your products to Microsoft QuickBASIC users. For about the same price a "classified" ad goes for in Dr. Dobbs Journal or Computer Language, you receive a full page ad in The QBNews. There is also another important difference. While these magazines cater to C programmers because they feel "professionals" wouldn't use anything else, The QBNews is especially for QuickBASIC programmers. To see an example of the type of ad you will receive, see the Crescent Software ad earlier in the newsletter. You get a 50 line by 70 column ad for $300. If you are interested in placing an ad in a future QBNews, send a check along with the ad (Ascii text on disk preferred) to: The QBNews P.O. Box 507 Sandy Hook, CT 06482 ---------------------------------------------------------------------- Submitting Articles to The QBNews The QBNews relies on it's readers to submit articles. If you are interested in submitting an article, please send a disk of Ascii text of no more than 70 characters per line to: The QBNews P.O. Box 507 Sandy Hook, CT 06482 Articles can also be submitted via E-Mail. Send them via Compuserve to 76510,1725 or via FidoNet to 1:141/777. I can be reached at the above addresses as well as on Prodigy as HSRW18A. The QBNews Page 37