Copy Link
Add to Bookmark
Report
QBNews Volume 2 Number 3
Volume 2, Number 3 September 15, 1991
**************************************************
* *
* 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) 1991 by Clearware Computing.
The QBNews Page i
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
T A B L E O F C O N T E N T S
1. From the Editor's Desk
Greetings From The Microsoft Developers Conference ........... 1
2. Ask The Doctor
QB's Hidden Data Copying by Ethan Winer ...................... 2
3. Advertisement
GFA-BASIC for MS-DOS and Windows 3.0 ......................... 6
4. View Print
Spill the Wine By J.D. Hildebrand ............................ 7
5. Graphically Speaking
Fonts in a Can by Larry Stone ................................ 12
Manipulating Sprites in Screen 13 by Fred Sexton Jr. ......... 17
6. Who ya gonna call? CALL INTERRUPT
A Bug Free CALL INTERRUPT by Cornel Huth ..................... 21
7. The QBNews Professional Library
An Event-driven Mouse Support Libary by Tony Elliot .......... 23
8. Advertisement
E-Tree Plus By EllTech Development, Inc. ..................... 37
9. Algorithms
Cardans's Method for Solving Cubes by Richard Jones .......... 39
10. Fun and Games
Lines With Style by Larry Stone and Charles Graham ........... 46
11. EOF
Receiving The QBNews ......................................... 48
Submitting Articles to The QBNews ............................ 49
The QBNews Page ii
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
F r o m t h e E d i t o r ' s D e s k
----------------------------------------------------------------------
Greetings From The Microsoft Developers Conference
I've just returned from the Microsoft Developers Conference held in
Seattle at the end of August. I'm sure it was a good time for all who
attended. It was nice to finally meet some of the people I've been
speaking to electronically over the years. For those who didn't or
couldn't attend, I recommend you try to make the next one when ever it
is held.
The good news from Seattle came during Bill Gates keynote address.
When asked point blank if Microsoft has abandoned QuickBASIC for DOS
to concentrate on their Windows products, BG said no. In fact, he
stated that Microsoft was currently working on an upgrade to
QuickBASIC, and I believe him.
So here is your chance. I want you to send in you suggestions on what
should be added to the next QuickBASIC. I'll compile the best
suggestions and see that Microsoft receives them. I'll also publish
the top 10 in the next QBNews. With a little luck, we may get some of
our suggestions incorporated into the next release.
When making your suggestions, use all the new features included with
BASIC 7.1 PDS as the baseline as to what will be in the next
QuickBASIC. Also, keep in mind that QuickBASIC is a low end product.
Therefore, you aren't likely to see ISAM or OS/2 support ever. They
will always be contained in the PDS version of BASIC.
Look forward to hearing your suggestions. Until next time, happy
reading.
Dave Cleary - Editor of The QBNews
The QBNews Page 1
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
A s k T h e D o c t o r
----------------------------------------------------------------------
Ask The Doctor
Dear Dave,
Enclosed are two sets of functions which are in effect identical, but
their differences cause a strange phenomenon.
The code in Listing 1 appears to me to be much more involved and
confusing. Constantly re assigning variable names from one to another
and GOSUB'ing to a called routine.
The code in listing 2 directly calls the called routine without using
an intermediate variable. This code is more readable, this code is
tighter, this code is smaller, this routine runs microscopically
faster. When I slow my 386 to an effective 8mhz and I run the
routines in a FOR 1000 NEXT Loop, you will notice a time savings of a
wonderful 3 seconds.
This code compiles 502 bytes LARGER !. . . .
Something is not right. . .
Obviously I am missing something. . .
I am not one to quibble over milliseconds, I will sacrifice the 502
bytes for readability, but I would really like to understand why this
happens.
Richard Gray
[See listings at end of the article]
Ethan Winer responds,
Richard,
What you have discovered is BASIC's hidden copying of data, and in
your program this happens in two different but related ways. In the
first program only variables are being passed to the ConcaveFrame and
QPrint routines. The second program passes both numeric and text
constants (that is, literal numbers and quoted strings), and also
numeric and string expressions. Regardless of whether you are passing
constant data or an expression, BASIC must make a copy of the data,
place it somewhere in memory, and then pass the address where the
result was stored.
In contrast, when a variable is passed to a SUB or FUNCTION procedure,
BASIC can simply obtain the variable's address and place it on the CPU
stack. The called routine may then read the data at that address, or
assign a new value based on the statements in your program. But a
constant or expression must be protected from being changed. Consider
The QBNews Page 2
Volume 2, Number 3 September 15, 1991
the following CALL statement and SUB definition:
CALL MySub("Test", 123)
...
...
SUB MyProc(Work$, Value%)
Work$ = "Hi mom!"
IF Value% > 100 THEN Value% = 100
END SUB
BASIC can't allow your program to alter either of the incoming
parameters, since that could affect other parts of the program that
use the same constants. When the same quoted string is used more than
once in a program, BASIC stores a single copy of the data. For
example, if you have the statement PRINT "Insert disk in drive A" four
times in your program, the quoted text is added only once. If BASIC
allowed your program to assign new characters to this constant, the
other PRINT statements would display the wrong text!
The same goes for numeric constants. If BASIC stored the number 123
in memory and passed that address, a subprogram that changed its
incoming parameter would change the number when it is used in other
places in your program. Therefore, BASIC always makes a copy of
constant data before sending it to a SUB or FUNCTION procedure.
A similar situation occurs with data expressions. When you pass the
expression LCol + 1 as an argument to a subprogram, BASIC must
calculate the result and store it somewhere. And when passing the
expression STRING$(Length, "Ä") + "Ù" to QPrint, BASIC again has to
save the result somewhere before passing it on. To make matters worse
BASIC also adds code to delete the temporary strings it creates, to
release the memory they occupy when they are no longer needed. In
your case you assigned Temp$ manually, and did not clear that string
each time after using it as BASIC would.
When fixed-length strings are passed as parameters the situation is
even worse still. In that case BASIC first copies the fixed-length
string to a regular string, passes the copy to the routine, makes the
call, copies the data back in case the routine changed it, and finally
erases the temporary string.
I have a few suggestions that you may find useful. First, if you have
a copy of Microsoft's CodeView debugger you will find it fascinating
to trace through the assembly language instructions that BASIC
creates. Indeed, this is precisely how I learned about BASIC's hidden
data copying. You should also consider buying my book "PC Magazine's
BASIC Techniques and Utilities" which is published by Ziff-Davis
Press. This book is available at your local Waldenbooks and B. Dalton
book stores, and in it I go into great detail about BASIC's internal
workings. There are also many performance and code size optimization
tips, as well as numerous other advanced BASIC topics.
--Ethan Winer, Crescent Software
The QBNews Page 3
Volume 2, Number 3 September 15, 1991
LISTING 1
---------------------------------------------------------------------
DEFINT A-Z
DECLARE SUB SetColor (Colur%)
DECLARE SUB ConcaveFrame (TRow%, LCol%, BRow%, RCol%)
DECLARE SUB QPrint (Text$, Row%, Col%, Colur%)
TRow = 8
BRow = 22
LCol = 7
RCol = 73
CLS
ConcaveFrame TRow, LCol, BRow, RCol
SUB ConcaveFrame (TRow, LCol, BRow, RCol) STATIC
Length = RCol - LCol - 1
R = TRow
C = LCol
Clr = 120
Txt$ = "É"
GOSUB ShowIt1
C = LCol + 1
Txt$ = STRING$(Length, "Í")
GOSUB ShowIt1
C = RCol
Clr = 127
Txt$ = "¸"
GOSUB ShowIt1
FOR N = TRow + 1 TO BRow - 1
R = N
C = LCol
Clr = 120
Txt$ = "º"
GOSUB ShowIt1
C = RCol
Clr = 127
Txt$ = "³"
GOSUB ShowIt1
NEXT
R = BRow
C = LCol
Clr = 120
Txt$ = "Ó"
The QBNews Page 4
Volume 2, Number 3 September 15, 1991
GOSUB ShowIt1
C = LCol + 1
Clr = 127
Txt$ = STRING$(Length, "Ä")
GOSUB ShowIt1
C = RCol
Txt$ = "Ù"
GOSUB ShowIt1
EXIT SUB
ShowIt1:
QPrint Txt$, R, C, Clr
RETURN
END SUB
LISTING 2
---------------------------------------------------------------------
DEFINT A-Z
DECLARE SUB SetColor (Colur%)
DECLARE SUB ConcaveFrame (TRow%, LCol%, BRow%, RCol%)
DECLARE SUB QPrint (Text$, Row%, Col%, Colur%)
CLS
ConcaveFrame 8, 7, 22, 73
SUB ConcaveFrame (TRow, LCol, BRow, RCol) STATIC
Length = RCol - LCol - 1
QPrint "É" + STRING$(Length, "Í"), TRow, LCol, 120
QPrint "¸", TRow, RCol, 127
FOR Row = TRow + 1 TO BRow - 1
QPrint "º", Row, LCol, 120
QPrint "³", Row, RCol, 127
NEXT
QPrint "Ó", BRow, LCol, 120
QPrint STRING$(Length, "Ä") + "Ù", BRow, LCol + 1, 127
END SUB
If you have a question for Ask The Doctor, please submit it to:
The QBNews
P.O. Box 507
Sandy Hook, CT 06482
The QBNews Page 5
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
A d v e r t i s e m e n t
----------------------------------------------------------------------
ONLY ONE PROGRAMMING LANGUAGE
LETS YOU CROSS DEVELOP FOR WINDOWS 3.0 AND
MS-DOS WITHOUT REWRITING CODE.
INTRODUCING GFA-BASIC
GFA-BASIC gives you a simple, but powerful language for developing
sophisticated, state-of-the-art Windows 3.0 and MS-DOS applications.
Write a program with either the DOS or Windows version of GFA-BASIC and
port it to the other platform-Doubling the fruits of your effort and
maintaining a common look and feel between both platforms.
One Set of Source Code
----------------------
Both versions of GFA-BASIC include 500 system and mathematical commands
and functions to facilitate software development. At the same time,
common commands and functions enable you to develop and maintain a
single set of source code for each program.
Simplifies GUI Development
--------------------------
Another 400 commands and functions in the Windows version simplify the
development of a complete GUI interface, including clipboard, DDE,
DLL's and dialog boxes. And, you don't need any additional libraries
or the SDK
In the DOS version, a subset of the same commands and functions
lets you bring Windows-like programs to AT and XT-class PC's without
using any additional tools.
HALF PRICE INTRODUCTORY OFFER
list intro
GFA-BASIC for Windows 3.0 $ 495 $ 295
GFA-BASIC for MS-DOS $ 295 $ 195
Both Windows & DOS versions $ 790 $ 395
Leverage your existing knowledge of BASIC and with GFA you can write
more powerful Windows and DOS programs easily right away.
To see for yourself how powerful GFA-BASIC is, just ask for our free
Demo Disk - or better yet, order either or both products including all
documentation on a trial basis with a full 100% money-back guarantee.
Call 1-800-766-6GFA or write GFA Software Technologies, Inc.
27 Congress Street
Salem, MA 01970
Fax: 1-508-744-8041
VISA/MasterCard accepted
The QBNews Page 6
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
V i e w P r i n t
----------------------------------------------------------------------
Spill the Wine By J.D. Hildebrand
The editors of this publication have asked me to share my observations
about language choices, and about where BASIC fits into the world.
It's my pleasure to toss a few thoughts into the ether. I hope you'll
respond with your own ideas.
I've edited computer magazines for nearly a decade. It's a pretty good
job, but people do hit you up quite a bit for free advice. "Should I
buy a Mac or a PC?" they ask. (Buy a PC.) "Should I upgrade to UNIX?"
(Sure, if you don't like software.) "How much memory and disk space do
I need?" (Fifty percent more than you can afford.)
These questions come up at cocktail parties, usually at trade shows.
I'm attending in my official guise as Editor In Chief, which means
I've got a tie on and I've taken the trouble to shake hands with the
PR director for the sponsoring company, plus whoever he wants to
impress. (PR people accumulate brownie points--and earn commissions,
for all I know--by getting magazine editors to shake hands with
company executives. The theory is that the executives will think the
PR guy is so chummy with the editor that the company's products will
gain favorable attention within the editor's magazine. It's all very
cozy. Since neither the PR guy nor the executives ever bother to read
the magazine, it's quite harmless to let them go on believing what
they want to believe.)
So I'm balancing a plate of fresh shrimp and oysters (they do feed
editors well at these shindigs) in one hand while holding a glass in
the other...and wondering how I'll manage to light a cigarette with
both hands full...when some door-crasher comes wandering over and
squints at my name badge. His eyes light up when he sees he's cornered
an editor.
"So you work for a programming magazine," he says, "even though it's
one I've never heard of. So you must be some kind of expert, right?
What programming language should I use?"
I sigh, resisting somehow the urge to make a too-frank comment about
the door-crasher's complexion. It's the notion that I have something
valid to say in response to this question that gets me invited to
these spill-wine-on-the-carpet bashes, after all, and ultimately make
it possible for me to pay the mortgage. So I look both ways to make
sure no one is listening, lean toward the door-crasher, and whisper
confidentially: "Use the language you know."
"Huh?"
"Look," I continue, "all programming languages do pretty much the same
things. It's amazing how alike they are. The main difference among
them, as far as you're concerned, is that you know one of them and
The QBNews Page 7
Volume 2, Number 3 September 15, 1991
you're considering a jump to another. Don't do it. Your knowledge of
one language's idiosyncracies is at least as valuable as the flashy
features some other language might offer. Use the language you know
and don't apologize for it."
The door-crasher sips his drink (his glass, I notice, is still nearly
full, while I'm stranded across the room from the bar with a tumbler
full of ice cubes) and shakes his head. "No," he says, "I really want
to learn a new language. Which should it be?"
I know what he's doing...he's waiting for me to say he should learn C.
Years ago, I might have. C was, after all, the fastest-growing
language on the PC platform.
But those days are gone. This year, for the first time since C
challenged Pascal in the middle of the last decade, the C market has
stopped growing--even, I'm sure, begun to shrink. So I couldn't just
tell d-c to learn C, nor C++ (while C was the clear successor to
Pascal, C so far has no clear successor).
"Well," I say to him, "in the absence of original thought of your own,
you might do well to emulate your peers."
"Huh?" He gawks at me.
"Consider," I say, "that programmers in different kinds of
organizations choose different kinds of languages. Viz: Programmers
who work in shrinkwrap software companies--at Lotus and WordPerfect,
companies like that--use C and assembler. There are exceptions to the
rule, but the rule is that shrinkwrap software is written in C and
assembler."
"Yes, but--"
"Then there are in-house corporate developers, programmers who develop
software within companies whose main business is not software," I
continue. "These guys use conservative, stodgy, standardized languages
because the bottom line is riding on the programs they write and their
reliability. They use C, COBOL, and FORTRAN."
"I don't think--"
"Yes, there are isolated pockets of Pascal and Modula-2," I say, "and
of course there are the database systems, dBASE and Paradox and the
like--they're very strong in the in-house corporate developer
community."
"But what about--"
"Then there are the consultants," I continue. "This is the largest
group so far, and the most highly motivated. They have to finish their
software today so they can ship out the invoice first thing in the
morning. They can't afford to wrestle with bit-twiddling--they have to
install working apps. And they have to be able to correct or change
The QBNews Page 8
Volume 2, Number 3 September 15, 1991
the apps months or years later. These guys use high-level languages to
write maintainable code--BASIC, Pascal, dBASE. The programs they write
often perform well, but performance isn't the primary concern for
these programmers. Staying in business is the important concern."
"I still think--"
"And hobbyists," I conclude, "use all kinds of languages, especially
BASIC, Pascal, and C. They don't have customers or deadlines,
generally, so they can afford to use any language they like."
At this point the door-crasher is starting to look for an excuse to
sidle away. He holds up his now-empty glass and gestures toward the
bar, but I grab him by his tie.
"Unless of course you're looking to become a Windows programmer," I
say, giving his tie a tug as his face turns red. "That's it, isn't it?"
"Mrffle," he gasps.
"Good thinking," I congratulate him. "These days there are three kinds
of PC programmers: the ones who already support Windows, the ones who
are developing a Windows strategy, and the ones who are out of
business but don't realize it yet."
The door-crasher wheezes.
"The way I see it," I say, "there are four routes to Windows
programming. Want to hear 'em?"
The door-crasher shakes his head, signalling "no," but I'm on a roll.
"First, there's C and the SDK. That's the Microsoft Software
Development Kit, got it? You've heard of it. For years, this was the
only way to write WinApps. But unless you've got the financial
resources of Lotus Development Corp. and the intellectual resources of
Charles Petzold to throw at the project, this just isn't a reasonable
way to write software. Life's too short."
The door-crasher struggles as his face starts to flush.
"Then there's C++ and class libraries. C++ is turning out to be a
pretty good language for writing Windows applications. I expect most
professional Windows programmers will use C++. Are you learning C++?"
The door-crasher doesn't respond.
"If you don't like C++, you could try one of the proprietary
object-oriented languages: Smalltalk, Actor, Turbo Pascal, TOOL, one
of those. The OOP languages promise to make it simple to write
WinApps, but so far most of them don't have very good libraries of
reusable classes. Without reusable class and object libraries, you
don't get many benefits from OOP."
The QBNews Page 9
Volume 2, Number 3 September 15, 1991
The door-crasher shakes his head vigorously. He seems to agree with me
quite fervently.
"Or you could check out one of the drag-and-drop tools," I say, "like
Visual Basic. These tools let you design your application visually,
then integrate the graphical front-end with efficient processing
engines written with the same tool or in some other language.
Descendants of the screen-painter UI tools available under DOS, these
flashy new tools offer the best payoff in making Windows programming
accessible. If you're looking to get started as a Windows programmer,
I'd recommend these tools. Got it?"
I release the door-crasher and he falls to his knees wheezing.
"Look," I say, "I know you appreciate the advice, but this is
ridiculous. Get up, get up."
The door-crasher wanders off and I make another quick cruise past the
food tables. Oddly enough, no one else comes over to talk with me.
It's good being an editor.
Now, this is a funny little story, and portions of it aren't true...
but there are some nuggets of truth in it too.
We get caught up too often in defending our language choices. Bah.
They don't need defending. Use whatever works for you--that's the
strategy that's kept me writing 15,000 lines of BASIC code per year,
at a minimum, since 1978.
When I joined the Programmer's Journal staff last month, I was
appalled to find a bunch of workers clustered around a table counting
names on a mailing list. Turns out they had to do a ZIP Code zone-
count for the Postal Service for third-class mailing. "I could write
a program to do this," I said.
"Oh, we know," they said, "but it would take too long."
Take too long? Well, maybe. They'd asked some of the other
programmers on the staff about the project, and they rightly
estimated that it would take a week or two of C coding. I wrote the
program for them in three hours using BC7.
I'm pretty sure a C version of the program would work faster than my
BASIC version...but Programmer's Journal has been around for 10
years, and the zone counts have always been a manual process. Scary,
I think.
BASIC is the language I choose whenever I have to finish a project
the same day I start it.
Nine out of 10 BASIC programmers don't get paid for the programs they
write. That's one of the reasons BASIC has a reputation as a
hobbyists' language.
The QBNews Page 10
Volume 2, Number 3 September 15, 1991
What most folks don't know is that the 1 out of 10 professional BASIC
programmers outnumber the professional Pascal programmers and match
the number of professional C programmers. That's a lot of people.
If I were to leave the editorial trades and return to programming,
and if I could choose just one language, it would surely be BASIC. I
can always earn a living with a good BASIC compiler. I may not get
much business from the Fortune 500, but the Unfortunate 5 Million
will know where to find me.
Stay warm.
JDH
*********************************************************************
J.D. Hildebrand has edited computer magazines since joining Miller
Freeman Publications as technical editor of PORTABLE COMPUTER in 1983.
Along the way, he has worked on MICRO COMMUNICATIONS, PORTABLE 100,
EPSON WORLD, DATA GENERAL MICRO WORLD, PROFESSIONAL COMPUTING, VAR, PC
COMPANION, PORTABLE COMPUTER REVIEW, LAPTOP USER, CFO, AI EXPERT,
COMPUTER LANGUAGE, EMBEDDED SYSTEMS PROGRAMMING, SOFTWARE DEVELOPMENT
INTERNATIONAL, UNIX REVIEW, PROGRAMMER'S JOURNAL and the C GAZETTE. He
currently serves as editorial director at Springfield, Oregon-based
Oakley Publishing Co., and as editor of WINDOWS TECH JOURNAL, which
will commence monthly publication in January 1992.
*********************************************************************
The QBNews Page 11
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
G r a p h i c a l l y S p e a k i n g
----------------------------------------------------------------------
Fonts in a Can by Larry Stone
You know how it goes - in the process of creating a nifty program,
you get side tracked on an even more nifty subprogram. Eventually,
this nifty subprogram turns into an extrodinary piece of work. Such
is the story behind PrintROMtable - a routine to produce a library of
graphics fonts without a font library!
The original PrintROMtable was developed for FUSION (published in
this issue). Based upon code published by PC Magazine,
PrintROMtable was limited in it's scope. Because my time, like most
of us, is limited, I made an early release of the code on the Quik_BAS
internation echo, and asked others to join in it's development. The
responce was outstanding. Rob Smetana immediately jumped into it with
code to create italics. Francois Roy supplied code to elongate char-
acters for a bold appearance. Bill Beasley supplied code to create
tall characters, inspiring Mike Kelly to offer code that creates fonts
that are 8, 14, 16, 28, or 32 pixel points in height. Both Rob and
Mike supplied code to allow CGA systems access to the extended ASCII
set (characters 128 through 255). Of course, my contribution continued
with left-handed italics, underlined characters, inverse and backward
characters, strike through, stencil characters, double wide and even
condensed characters, and, not least of all, intergrating the various
code supplied by the other, aforementioned contributors, into the one
highly useful and variable module. You know how it goes - while in the
process of creating a nifty program, it goes on and on and on...
Before we get much further, you should know that PrintROM is run
from a test program called, ROMtest.bas, and, although ROMtest traps
and sets the screen to your highest resolution, the pixel positioning
is coded for SCREEN 12. This means that if your computer monitor can't
handle this resolution then you will see only some of the nifty things
displayed or, in some cases, some of the diplay will be outside of the
monitor's graphic boundaries (you can always tweek the xAxis and yAxis
locations coded in the ROMtest program to place any string into your
system's view area).
So, what's so special about PrintROMtable? Plenty! It is a huge
library of fonts without needing external libraries! The external libs
supplied provide extended ASCII set 128 through 255. These are not
necessary to the program unless your system is CGA and passes a string
containing a high ASCII character to PrintROMtable. Even if your pro-
gram runs on EGA or VGA, you may wish to include one or more of these
font files for the special characters they provide, such as the copy-
right and registered trade mark symbols (more on this subject later!)
PrintROMtable compiles to around a 13K object file - as small or smal-
ler than most "standard" font libraries! As small as this is, you are
provided fonts ranging from 8 to 64 pixels tall in condensed, normal,
bold, or double wide sizes; characters can be underlined, shadowed,
italic (slanted left or right), inverted, backwards, stenciled, or
The QBNews Page 12
Volume 2, Number 3 September 15, 1991
contain a strike through mark. Furthermore, you can print from left
to right, right to left, top-down, bottom-up, or even at an angle!
PrintROMtable has limitations. CGA systems can only use characters
8 pixels tall - this can be expanded to 16 by setting PR.Tall = True.
EGA systems cannot access sizes 16, 32. However, EGA can have size 8
expanded to 16 by setting PR.Tall = True. If you try to have an EGA
system use font size 16 or 32, PrintROMtable will reset the size to 14
or 28, respectively. This means that using PR.Height = 32 and PR.Tall
equals True on EGA systems will produce a font 56 pixels high, not 64
as intended. Only VGA has the entire range of 8, 14, 16, 28, 32, 56
and 64 height characters.
The heart of PrintROMtable is it's code to access the where-abouts
of the ROM BIOS segment containing the character shape table.
Once PrintROMtable has the pointer into the ROM segment that con-
taining the character shape tables, it loops through the passed-in
string, once for each character in the string. If a background color
is called for, it uses LINE with a box and fill (BF) argument to paint
a background color. If a background color is not requested then the
background color is transparent. The code then loops 4, 8, 14, 16, 28
32, 56, or 64 times for each scan line of the character (depending on
such factors as PR.Height, PR.Condesned, and PR.Tall).
The 1st item of business is to determine what value, based upon the
font size, need to be loaded into the BX register so that a subsequent
call to BIOS interrupt 10h, function 1130h can point us to the correct
memory address containing our scan lines:
SELECT CASE PR.Height
CASE 8 ' 8x8 font
reg.bx = &H300
CASE 14, 28 ' 8x14 font or 8x14 font double high
reg.bx = &H200
CASE 16, 32 ' 8x16 font or 8x16 font double high
reg.bx = &H600
CASE ELSE
CLS : PRINT "Invalid Character Size": END
END SELECT
Having determined the BX value, PrintROMtable then sets AX = &H1130
before it calls BIOS Video Service, &H10:
reg.ax = &H1130
InterruptX &H10, reg, reg
ofst& = reg.bp
sgmt& = reg.es
For those with inquiring minds, function AX = 1130h is called with AX
and BX set as follows:
AX = 1130h
BX = pointer specifier
The QBNews Page 13
Volume 2, Number 3 September 15, 1991
&H0 INT 1Fh pointer
&H100 INT 44h pointer
&H200 ROM 8 by 14 character font pointer
&H300 ROM 8 by 8 double dot font pointer
&H400 ROM 8 by 8 DD font (top half)
&H500 ROM alpha alternate (9 by 14) pointer
&H600 ROM alpha alternate (9 by 16) pointer
On return, the ROM BIOS function supplies:
ES:BP = specified pointer
CX = bytes/character
DL = character rows on screen
Even though PrintROMtable has the appropriate segment and offset to
the character shape table, they may not be correct! The above call to
the BIOS is only good for EGA, MCGA, or VGA systems. If PR.ScreenMode
is less than 7 or, if you tell PrintROMtable to force the CGA address
then PrintROMtable sets the character shape table's segment to &HFFA6.
IF PR.ForceAddress OR PR.ScreenMode < 7 THEN sgmt& = &HFFA6
Segment &HFFA6 contains the character table but, unlike our INT 10h
table pointer, this table only goes to the first 127 ASCII characters.
This means that if PR.ScreenMode is 1, 2, or 3 (same as SCREEN 1, 2,
or 3) or, if you instruct PrintROMtable to force the address then, you
cannot access the upper ASCII set without defining a disk font file.
Since the objective of all of the contributors to this program was
to create a self-contained, linkable module, we wanted to avoid asking
users to have to have, or load, a 3rd-party file just to access the
upper ASCII character set. Several people answered our call for ideas.
Mike Kelly was 1st to supply code to accomplish this aim. Although
his code was self-contained, it required 4k of memory to use the data.
Cornel Huth described an approach similar to the one eventually taken
with PrintROMtable: to use Int 1Fh to point to an array containing the
high characters. Similar approaches were suggested by Bill Beeler and
Dave Cleary. The final approach developed was by Rob Smetana and is
similar in operation to the DOS program, Graftabl. Unlike Graftabl,
Rob's approach does not require a TSR and it uses a meager 1024 bytes
of memory. It does, however, use small, 1024 byte external files.
External fonts are loaded by the routine with one GET statement:
j% = FREEFILE 'Get a handle
OPEN FontFile$ FOR BINARY AS #j% 'Open with this handle
font$ = SPACE$(1024) 'Our fonts need just 1024 bytes (128 * 8).
GET #1, , font$: CLOSE #j% 'Close file with handle j%
PrintROMtable is supplied with four disk font files that access the
characters used in international, U.S., Portuguese, and French-Canada
ASCII sets. There can be additional 1024 font files added to the list
by altering the appropriate area of the PrintROMtable routine. To add
The QBNews Page 14
Volume 2, Number 3 September 15, 1991
a new font file, search PrintROMtable for:
'**** You could create your own 1024 byte
The code is self-expanatory and you should not have any trouble adding
to the list.
If your program is to access one or more of these font files, you
might want to establish a default file to use (if you don't designate
a default file then the routine sets the default to number 1 -- inter-
national). To set a default font file, before you make any calls to
PrintROMtable, LET PR.DefaultFile = ? Where ? is the number of the
file to use (presently, 1 through 4).
Whether a default font file is established or not, you can, at any
time, instruct the routine to load any of the font files. First, you
should reset the current font file:
PR.ReadHiAscFile = -1
CALL PrintROMtable(a$, PR)
Then, to set the new file, simply:
PR.ReadHiAscFile = 2 (or 3, or 4, etc.)
The next call to PrintROMtable will then read and use the new fonts.
If your font files are not located in the default path, before you
you make your first call to PRINTROMtable, you need to inform it where
to look. This, too, is a simple instruction:
LSET PR.DiskFontLoc = "C:\OFF\IN\URANUS"
Many QB programmers set their SCREEN mode by using literals, ie.,
they use code similar to, SCREEN 9. PrintROMtable needs to know what
screen you are using. To inform it which screen mode is in use, do
something like:
PR.ScreenMode = 12
SCREEN PR.ScreenMode
Putting it all together, your program should look something like:
REM $INCLUDE: 'printrom.bi'
LSET PR.DiskFontLoc = "D:\SNAZZY\FONT\AREA\"
PR.DefaultFile = 1
PR.ScreenMode = 9
SCREEN PR.ScreenMode
PR.Height = 8: PR.xAxis = 20: PR.yAxis = 30
PR.StepX = 9: PR.CharClr = 15: PR.Shadow = -1
PrintROMtable "Hello there, my name is", PR
The QBNews Page 15
Volume 2, Number 3 September 15, 1991
PR.Tall = -1: PR.xAxis = 20: PR.yAxis = 48
PrintROMtable "John Doe", PR
When working from within the QB environment, you need to load QB
by typing, "QB /Lqb". The sample program that demonstrates how to use
PrintROMtable is named, "ROMTEST.BAS". It is in the file, PRINTROM.ZIP
along with PRINTROM.BI, and ROMTEST.MAK. Run QB with the "/Lqb" switch
then open the file RomTest.Bas. That's all you have to do.
One final note. PrintROMtable can do a great deal of fancy work to
your strings. The fancier your output, the more time required to per-
form the work. One saving grace is that all of the fancy manipulation
performed by PrintROMtable is considerably faster once compiled as an
EXE file. However, compiled or not, expect certain processes, such as
PR.Elongate = 2 (double wide) to be slower than the simpler processes
like 8 pixel high, normal character writes.
[EDITOR'S NOTE]
All code for this article can be found in PRINTROM.ZIP
**********************************************************************
Larry Stone is President of LSRGroup and is involved in writing
instructional and large data base application systems for business and
institutional clients. He is also the author of SERVICES, a shareware
application program rated a trophy by "Public Brand Software". He can
be reached at LSRGroup, 2945 "A" Street, North Bend, OR 97459, or in
care of this newsletter.
**********************************************************************
The QBNews Page 16
Volume 2, Number 3 September 15, 1991
Manipulating Sprites in Screen 13 by Fred Sexton Jr.
In January I bought my first real computer(386SX).I don't count the
TI-99 that's still in the closet.After a month or so of GWBASIC I
bought QuickBasic 4.5 .I was instantly hooked,and have spent alot of
my spare time coding.
I wanted to make a few animated educational games for my kids.I soon
found that animation would require alot of "sprites".I needed an easy
to use drawing program to create sprites in my favorite mode SCREEN 13
(320x200x256).So I set out to create one.I ended up with "THE SPRITE
MASTER" (so named because I finally had mastered them). Along the way
I learned alot about SCREEN 13.I decided to pass along some of it.
NOTE:I always use DEFINT A-Z.So,all arrays discussed here are integer
arrays.
The easiest way to store an image is with Q.B.'s GET statement. To
find the minimum size to dimension an array,I set up a loop getting a
10w X 10h image decreasing the number of elements each time until an
error occurred.I don't care for the formula in the book.The result was
that a 10w X 10h image required 52 elements or, DIM ary(51).The
elements are numbered starting with zero by default. So,always
remember to DIM an array with a value that is one less than you really
want.Knowing that the colors are in the range of 0 - 255 we can
determine that each pixel requires 8 bits (1byte) to store it's color
value (255 = 11111111 B).So,in a 10w X 10h image there are 100 bytes
or 50 words.We can conclude that GET needs the number of words in the
image plus two additional words.
Therefore : elements = ((width * height) + 1) \ 2 + 2
(the "+ 1" takes care of odd values)
To find out what the two extra words are for,we'll GET a couple of
different size images from a blank screen. Then we'll compare the
values in the resulting arrays.
With image1 = 10w X 10h and image2 = 20w X 5h:
ary1(0) = 80 ary2(0) = 160
ary1(1) = 10 ary2(1) = 5
ary1(2-51) = 0 ary2(2-51) = 0
Now we know the first two elements are used by GET to store the image
size information.The first element is the image width in bits.
Remember we said 1 pixel = 8 bits.To find pixel width just divide by
8.The second element is the height. To determine the rest of the
pattern let's set a few points and get the image.
FOR t = 0 TO 3
PSET(t , 0), t + 1
PSET(t , 1), t + 5 NEXT
GET (0 , 0) - (3 , 1), ary
We already know what's in the first two elements so let's look at the
rest.
The QBNews Page 17
Volume 2, Number 3 September 15, 1991
ary(2) = 513
on the byte level
low byte = 1 => value of the pixel (0,0)
high byte = 2 => value of the pixel (1,0)
ary(3) = 1027
on the byte level
low byte = 3 => value of the pixel (2,0)
high byte = 4 => value of the pixel (3,0)
ary(4) = 1541
on the byte level
low byte = 5 => value of the pixel (0,1)
high byte = 6 => value of the pixel (1,1)
ary(5) = 2055
on the byte level
low byte = 7 => value of the pixel (2,1)
high byte = 8 => value of the pixel (3,1)
This was a 4w X 2h image.Starting at the low byte the third
element,the next four bytes correspond to the first row of four
pixels.The next four bytes correspond to the second row of four
pixels.Analysis of other images will show the same pattern.Thus we can
conclude for an image with a width of W :
Starting with the low byte of the third element,the first W # of
bytes will correspond to the pixels in the first row and the
second W # of bytes will correspond to the pixels in the second
row and so on for each row.
Once the pattern is known manipulating the arrays can accomplish many
things.Here are a few examples.
Change a color:
To change a color in an image array we would search the array at the
byte level for the source color.When it is found we will replace it
with the new color.
In pseudo code:
FOR t = 0 TO bytes - 1 (because we start with zero)
IF PEEK (t + start offset) = oldcolor THEN
POKE t + start offset, newcolor
END IF
NEXT
Mirror an image:
To create a mirror image we need to reverse the order of each row of
pixels.We know the pixels are stored in groups corresponding to the
width of the image.So,in a 10w X 10h image starting with the low byte
The QBNews Page 18
Volume 2, Number 3 September 15, 1991
of the third element the first byte would be the first pixel in the
first row and the tenth byte would be the last pixel in the first
row.To make it easier let's dimension a second array the same size as
the first.Then after making the size information the same we can just
copy the bytes from one to the other in the proper order (first to
tenth,second to ninth,etc.).
In pseudo code:
aofs=offset of first pixel in first row of source
bofs=offset of last pixel in first row of target
FOR first row TO last row
FOR first pixel TO last pixel
PEEK at aofs + increasing pixel number (0 to start)
POKE to bofs
decrease bofs to next lower pixel
NEXT source pixel
aofs=offset of first pixel in next row of source
bofs=offset of last pixel in next row of target
NEXT row
Superimpose an image:
To superimpose an image ie. put it front of or behind existing images
without destroying them or messing the colors up.Again it is easiest
to use a second array of the same size.First we get the area of the
screen where we are planning to put the image.Then to put in front we
take all non-zero (background) pixels from the first array and put
them into the second array.To put behind we only poke pixels from the
source array there are zeros in the second array. The result can be
PUT with PSET and we won't end up with the blacked out area we
normally have.
In pseudo code:
IN FRONT:
GET target area into work array
FOR first pixel in first row TO last pixel in last row
PEEK at a source pixel
IF pixel is not zero THEN POKE pixel into work array
NEXT
PUT work array PSET
BEHIND:
GET target area into work array
FOR first pixel in first row TO last pixel in last row
PEEK at a work pixel
IF pixel is zero THEN
PEEK at same pixel in source
POKE pixel into work array
END IF
The QBNews Page 19
Volume 2, Number 3 September 15, 1991
NEXT
PUT work array
PSET
These are just a few of many possibilities.(The superimpose routine
could be easily modified to allow partial PUTS.) The documented source
for each routine discussed is in G13UTIL.BAS .
I recently started learning MASM and have converted these to faster
versions.I plan to release a shareware library of fast routines for
SCREEN 13,as well as a shareware version of "THE SPRITE MASTER". I
plan to Upload them to COMPUSERVE and AMERICA ON LINE. Comments and/or
suggestions would be appreciated.
[EDITOR'S NOTE]
All code for this article can be found in SPRITE.ZIP
*********************************************************************
Fred Sexton Jr. is an electrician for Ford Motor Co. He works
extensively with Allen Bradley Programmable controllers and Kuka
robotics.He received electrical training in the NAVY as an electronics
technician / reactor operator. He can be reached on Compuserve at
70253,163 and on A.O.L. at 7408.
*********************************************************************
The QBNews Page 20
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
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
----------------------------------------------------------------------
A Bug Free CALL INTERRUPT by Cornel Huth
There is a problem with the CALL INTERRUPT routine in QuickBASIC
and BASIC PDS 7. This table highlights the problems.
Problem 4.0 4.0b 4.5 CH 6.0 7.0 7.1
-----------------------------------------------+--------------
1. DI parameter X | . .
2. INT25/26 X X X | . . X
3. INT24 environment X X X X | . .
4. INT24 EXE ON ERROR GOTO | . . D
5. INT24 EXE NO ERROR TRAP X X X X | . . D
|
. not tested
X - error present
D - DOS INT24 fatal error handler gains control
CH - The CH version is the INTRPT.OBJ that's in QBNWS105.
--------------------------------------------------------------
1) typo causes the passed DI register parameter to NOT be used
2) DOS INT25/26 will always report success even if it failed
-- DOS fatal error (INT24) in:
3) QB environment causes system crash
4) EXE w/ ON ERROR GOTO handler causes system crash
5) EXE with no ERROR handler causes system crash
In the QuickBASIC 4.x environment any fatal DOS error during a CALL
INTERRUPT crashes the system. In QB 4.x EXEs with ON ERROR GOTO
handlers the error is trapped by the error handler. In QB 4.x EXEs
without ON ERROR GOTO the runtime code starts to print the error text
to the screen but only gets part of it printed before it locks up.
In PDS 7, the evironment does not crash on a fatal DOS error because
the BP register is saved (in b$SaveBP) before executing the interrupt.
Apparently BASIC needs the original BP if a fatal DOS error occurs so
that it can reference the return address of the caller.
In PDS 7 EXEs, with or without ON ERROR GOTO handlers, fatal errors
are simply passed through to the INT24 error handler. This brings up
the Abort, Retry, Fail prompt. Pressing F returns to INTERRUPT.
INTERRUPT then returns with the carry flag set and DOS error 83d in AX
(83d=Fail on INT24). The ON ERROR GOTO handler is never invoked.
Pressing A causes the entire program to immediately exit to DOS.
Wouldn't it be great if CALL INTERRUPT worked predictably all the
time? Now it does. INTRPT2.OBJ is a direct replacement for either QB
or PDS that traps fatal DOS errors and returns control, and decision
making, to your program. When a fatal DOS error occurs, the carry flag
is set and the DOS error code is returned in AX.
For example, let's say you want to see if a file exists. What you
The QBNews Page 21
Volume 2, Number 3 September 15, 1991
could do is open the file and check for any errors. This works fine as
long as the drive of the file is valid and ready. But if the drive is
a floppy and the door is open, boom. In the QB4 environment the system
would lockup, even if ON ERROR GOTO were set. In PDS EXE programs the
default DOS INT24 handler pops up on a fatal error, even with ON ERROR
GOTO. This messes up the screen with the infamous Abort, Retry, Fail
prompt and lets the user abort with files possibly open. My B-tree
shareware libraries QBTree 5.5 and QBXDBF 1.0 (dBASE .DBF format) have
support functions that make use of the INTERRUPT routines and I can't
allow them to crash the system or present an Abort prompt. No more
surprises!
To update your version of INTERRUPT(X) put INTRPT2.OBJ in your
library directory and then do the following:
C>lib QB.LIB -INTRPT +INTRPT2;
C>link /qu QB.LIB,QB.QLB,nul,BQLB45.LIB;
BQLB45.LIB pertains to QuickBASIC 4.5. Use BQLB40 for QB 4.00 and
BQLB41 for QB 4.00b. For BASIC PDS 7.x replace references to QB with
QBX.LIB and QBX.QLB, and use QBXQLB.LIB for the library prompt.
The source to INTRPT2.ASM, a sample FileExists() function, a DOS
error listing and INTRPT2.OBJ are in INTRPT2.ZIP file.
*********************************************************************
Cornel Huth is chief designer and programmer for ScanSoft. He can be
reached at 6402 Ingram Road, San Antonio, Texas 78238. When he's not
twiddling bits he's thinking of ways he could.
*********************************************************************
The QBNews Page 22
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
T h e Q B N e w s P r o f e s s i o n a l L i b r a r y
----------------------------------------------------------------------
An Event-driven Mouse Support Libary by Tony Elliot
The mouse is one of the easiest-to-use interface devices available for
PCs. Even though it has been extremely popular over the last several
years, Microsoft didn't provide direct support for it in the BASIC
programming language until the recent release of Visual BASIC for
Windows (although the BASIC Professional Development System [PDS]
includes indirect support of the mouse through routines in the "User
Interface Toolbox" included with that product). This doesn't mean that
the mouse has been unreachable from BASIC programs. Mouse services can
be easily accessed through BASIC's "CALL Interrupt" routine (as
illustrated in a previous issue of QBNews). Also, most BASIC add-on
developers include mouse routines written in assembly language as part
of their regular complement of functions. So why the need for
*another* set of mouse routines? Well, there are several reasons:
1. If you don't already own one, commercial add-on libraries can get
rather expensive. If you are only interested in adding mouse support
to your programs, you might have to shell out $100 to $200 (or more)
for a product that consists of several hundred routines, only a few of
which you'll use for this purpose. However, add-on libraries like
MicroHelp's "Muscle" ($189) or Crescent's "QuickPak Professional"
($199) are definitely the way to go if you can afford it. Many of the
other routines included in those products will no doubt be useful to
you down the road.
2. Many of the public domain or "shareware" mouse support alternatives
are written in BASIC, usually invoking BASIC's "CALL Interrupt"
service. Although this is a completely functional approach, there is a
substantial amount of overhead required (in terms of speed and code
generation). CALL Interrupt is a relatively slow service to begin
with, and the results returned by it must then be translated into a
usable form. Doing all of this from BASIC may not allow you to poll
the mouse as frequently as required by some applications, therefore
you may occasionally miss some real-time events such as button-clicks.
3. Using routines written in assembly language for minor tasks such as
mouse support is, in my humble opinion, the way to go. It adds a
minimal amount of overhead to your BASIC programs and does the job as
quickly as possible. This equates to smaller, faster, and from the
users' point of view, more responsive programs.
4. The set of mouse routines described in this article has one
important feature that I haven't seen elsewhere in DOS-based BASIC.
Utilizing the "ON UEVENT" service available since QB 4.00a, they allow
you to create "mouse event-driven" programs. That is, instead of
constantly polling the mouse for activity, you can go about your
normal business and when a programmer-defined type of mouse activity
occurs (a button press, release, or mouse movement), your program is
interrupted and control is transferred to a subroutine that you
The QBNews Page 23
Volume 2, Number 3 September 15, 1991
specify. This allows you to logically group your mouse-specific code
instead of having it sprinkled here and there throughout your program.
The two mouse-programming paradigms, "polled" and "event-driven," each
have advantages and disadvantages. We will discuss each in detail as
the routines are being presented below. The file MOUSE.REF contains a
reference listing each of the routines individually, along with the
appropriate descriptions and parameter lists associated with them.
The various code fragments used below each assume that the file
MOUSE.BI is $Included at the top of your program. It contains the
declarations and the TYPE..END TYPE structures required by these
routines. Many of the code fragments also assume that you have already
reset the mouse and the pointer is visible.
Also keep in mind that we won't be talking too much about -how- the
routines actually work. Fully commented assembly source code is
provided for those enquiring minds that "what to know." An example
program called MOUSE.BAS is also included. It demonstrates all of the
mouse routines described in
this article.
----------------------------------------------------------------------
Resetting the Mouse Driver
----------------------------------------------------------------------
When writing programs that will recognize and accept input from a
mouse, the first step is to determine if a software "driver" for the
mouse is installed. If one is found, it must be "reset" before our
program can actually communicate with the mouse. Calls to any of the
other mouse routines described here (besides the three "reset"
routines) will simply be ignored if the mouse has not been reset or is
not present at all. As a convenience, three routines are provided to
determine the presence of the mouse and to reset it, if desired:
MouseReset% - An integer function that checks to see if a mouse driver
is installed, and if so, resets it. The number of buttons the mouse
has is returned as a result, or zero if a mouse driver is not
installed. When the mouse is reset, it is left in the following
state:
- Mouse pointer is at the center of the screen
- Display page for mouse set to 0
- Mouse pointer is hidden (off)
- Mouse pointer shape is the default arrow shape in the
graphics video modes or a reverse block in the text modes.
MouseAlreadyReset% - An integer function that checks to see if the
mouse has already been reset by this program. If so, it returns the
number of buttons the mouse has, otherwise it returns zero and takes
no further action. This is handy in situations where you don't want to
reset the mouse if it has been reset previously (doing so
The QBNews Page 24
Volume 2, Number 3 September 15, 1991
unnecessarily takes a couple of seconds and has other, sometimes
undesirable, effects such as those listed above).
MouseInstalled% - An integer function that checks for the presence of
a mouse without resetting it.
Most of the time, MouseReset% will be all that you need. For example:
NumberOfButtons% = MouseReset%
IF NumberOfButtons% THEN
PRINT NumberOfButtons%; " button mouse found and reset!"
ELSE
PRINT "Mouse not found."
END IF
Once the mouse has been successfully reset, you are then free to use
any of the other functions.
----------------------------------------------------------------------
Obtaining Information About Mouse Hardware and Software
----------------------------------------------------------------------
If you wish to obtain specific information about the mouse hardware
and software currently in use, the MouseGetInfo routine can be used to
identify the version number of the mouse driver software, the type of
mouse (bus, serial, InPort, PS/2, or HP), and the hardware interrupt
line (IRQ) the mouse is sitting on. For example:
CALL MouseGetInfo(MajorV%, MinorV%, MouseType%, Irq%)
PRINT "Mouse software version:";MajorV% + MinorV% / 100
PRINT "Mouse type: ";
SELECT CASE MouseType%
CASE 1
PRINT "Bus"
CASE 2
PRINT "Serial"
CASE 3
PRINT "InPort"
CASE 4
PRINT "PS/2"
CASE 5
PRINT "HP"
CASE ELSE
PRINT "Beats the heck outta me! Type#";MouseType%
END SELECT
PRINT "Using IRQ";Irq%
This information is useful in some cases, but generally there's no
particular need for you to be aware of it.
----------------------------------------------------------------------
The Mouse Pointer
----------------------------------------------------------------------
The QBNews Page 25
Volume 2, Number 3 September 15, 1991
After the mouse has been reset, you'll want to make the mouse
"pointer" (or "cursor") visible. The visibility state of the mouse
pointer is controlled by the MousePointerOn and MousePointerOff
routines. Remember, the MouseReset function initially turns the
pointer OFF. For example:
NumberOfButtons% = MouseReset%
LINE INPUT "The mouse pointer is invisible. Press <Enter> .. ",A$
CALL MousePointerOn
LINE INPUT "The mouse pointer is visible. Press <Enter> .. ",A$
CALL MousePointerOff
PRINT "The mouse pointer is invisible again. Press <Enter> .. "
By default, the mouse driver uses a "software pointer" while in the
text video modes. This means that a mouse pointer is visible on the
screen because the mouse driver is altering the screen's color
attribute and/or the character at the location where the pointer is to
be placed. This makes that location stand out from the rest of the
data displayed on the screen. The default software pointer simply
reverses the color attributes at the pointer position. When the
pointer is moved, it restores the original attribute and character at
the current position, stores the original attribute and character for
the new position, and then applies the defined masks to the new
position.
Before updating the screen using PRINT, CLS, etc., it's necessary to
turn the mouse pointer off. If you were to overwrite the screen at the
mouse pointer position while the pointer is visible, the mouse driver
would not be aware of this occurrence. The next time the pointer is
moved, the original attribute and character stored by the mouse driver
would be restored to that location. The result is what I like to refer
to as "mouse droppings." For this reason, it's generally considered
good practice to leave the mouse pointer off except when your program
is waiting for input from the user.
The mouse driver provides a service whereby you can customize the
effects that the pointer has on the color attribute and character at
the pointer position. This is accomplished by providing two
"bit-masks" that define which bits comprising the attribute/character
will be preserved (ANDed) and which will then be toggled (XORed).
Since manipulation of the mouse pointer on this level is of little
interest to most programmers and would require a crash course in video
memory and bit manipulation, I'll skip the nitty-gritty and describe
the supplied routine. If you would like more in-depth information
about this function, refer to the Microsoft Mouse Programmers Guide,
or leave a message for me on Compuserve. I'll be happy to help.
The routine MouseSetSoftwarePointer is used to define the "AND" and
"XOR" bit masks for the software cursor. For example:
AndMask% = &H77FF
XorMask% = &H7700
CALL MouseSetSoftwarePointer(AndMask%, XorMask%)
The QBNews Page 26
Volume 2, Number 3 September 15, 1991
The first byte of each mask represents the changes made to the color
attribute. The "77" part of the AND mask indicates that the foreground
color (bits 0-2) and background color (bits 4-6) will be preserved and
the high- intensity (bit 3) and blink (bit 7) bits will be turned-off.
The "77" part of the XOR mask indicates that the bits comprising the
foreground and background colors should then be toggled. The "FF" part
of the AND mask indicates that all bits comprising the character
should be preserved. The "00" part of the XOR mask indicates that none
of the character's bits will be toggled. In other words, when the
mouse pointer appears on the screen, the color of the cell will be
modified but the character won't. To take another example, we'll leave
the color attribute alone, but will change the mouse pointer to an
asterisk:
AndMask% = &HFF00 'Preserve all attribute bits and discard the char
XorMask% = &H002A 'Don't mess with attribute, make char an "*"
CALL MouseSetSoftwarePointer(AndMask%, XorMask%)
Another type of pointer available in text video modes is the "hardware
pointer." It is called that because it is similar to the normal scan
line-oriented text cursor that we're all familiar with. It appears on
the screen as a blinking block. You can define it size, and to a
degree, it's shape. Like the text cursor, the mouse hardware pointer
is comprised of from 0 to 7 scan lines. When defining a hardware
pointer, you specify the starting and ending scan line number, with 0
at the top of the character cell and 7 at the bottom, much like you
would use BASIC's LOCATE statement to alter the shape of the text
cursor. For example:
'A full "block"
StartScan% = 0
EndScan% = 7
CALL MouseSetHardwarePointer(StartScan%, EndScan%)
'Or
'A thin line in the middle of the character cell
StartScan% = 3
StartScan% = 4
CALL MouseSetHardwarePointer(StartScan%, EndScan%)
As some of you may be aware, the actual height of a character cell
varies between 8 to 16 scan lines depending on the display adapter and
the video mode used. This function automatically translates the
requested 0-7 range into the scan line range appropriate for the
display adapter and video mode in use.
----------------------------------------------------------------------
What's the Mouse Up To?
----------------------------------------------------------------------
When working with the mouse, the big questions are "Where is the mouse
pointer?" and "Is a button pressed or released?" This information is
required to process the most rudimentary mouse action, the "click."
The QBNews Page 27
Volume 2, Number 3 September 15, 1991
The routine MouseGetStatus can used to answer these questions for you.
For example:
REM $INCLUDE: 'MOUSE.BI'
DECLARE FUNCTION Pressed$(Button%) 'Used only by this example
NumberOfButtons% = MouseReset%
IF NumberOfButtons% = 0 THEN
PRINT "No mouse detected."
END
END IF
CALL MousePointerOn
CLS
PRINT "Press any key to end:"
DO
CALL MouseGetStatus(Lb%, Rb%, Cb%, Row%, Column%)
LOCATE 3,1
PRINT " Left Button :"; Pressed$(Lb%)
PRINT " Right Button:"; Pressed$(Rb%)
IF NumberOfButtons% > 2 THEN
PRINT " Center Button:"; Pressed$(Cb%)
END IF
PRINT " Current Row:"; Row%
PRINT "Current Column:"; Column%
LOOP UNTIL LEN(INKEY$)
CALL MousePointerOff
END
FUNCTION Pressed$(Button%)
IF Button% THEN
Pressed$ = "Pressed"
ELSE
Pressed$ = "Released"
END IF
END FUNCTION
Again, the MouseGetStatus routine returns information about what is
going on with the mouse -right now-. If your program was busy doing
other things (e.g. "polling" the mouse infrequently) and the user
clicked the left button quickly, you might not detect it. As you might
have expected, there are contingencies for this situation as well.
Let's take another situation. Say you are only interested in the mouse
pointer position when a button is pressed or released, and you don't
want to worry about polling the mouse frequently enough. The routines
MousePressInfo and MouseReleaseInfo return the row and column position
of the mouse pointer when the specified mouse button was *last*
pressed or released, respectively. For example:
The QBNews Page 28
Volume 2, Number 3 September 15, 1991
Button% = 0 '0=left, 1=right and 2=center
IF MousePressInfo%(Button%, Row%, Column%) THEN
'Returns number of times the specified button was pressed
' since the last check
PRINT "Left button last pressed at"; Row%; ","; Column%
END IF
Button% = 1 'Right button
IF MouseReleaseInfo%(Button%, Row%, Column%) THEN
'Returns number of times the specified button was released
' since the last check
PRINT "Right button last released at"; Row%; ","; Column%
END IF
Along the same lines, you can also determine the net physical distance
that the mouse has moved. The routine MouseMovement returns the number
of "Mickeys" (approximately 1/200th of an inch) the mouse has moved
since the last time this routine was called. For example:
CLS
PRINT "Left button display distance and right button ends
program"
CALL MouseMovement(Rows%, Columns%) 'To zero the counter
DO
CALL MouseStatus(Lb%, Rb%, Cb%, Row%, Column%)
IF Lb% THEN
CALL MouseMovement(Rows%, Columns%)
LOCATE 3,1
PRINT " Mickeys moved (vertically):"; Rows%
PRINT "Mickeys moved (horizontally):"; Columns%
CALL MouseWaitForRelease
END IF
LOOP UNTIL Rb%
If you were paying attention, then you noticed that I snuck a new
routine into the above listing. MouseWaitForRelease suspends the
program until all mouse buttons have been released. It's very handy
for mouse-specific program "flow control."
----------------------------------------------------------------------
Writing Mouse Event-driven Programs
----------------------------------------------------------------------
The various methods of gathering mouse-related information we've
discussed so far require you to poll the mouse driver periodically to
see if a specific event has occurred (mouse click, etc.). Wouldn't it
be much easier if the mouse driver could simply interrupt your program
anytime it needs attention and then transfer control to a specified
subroutine? This way, you wouldn't have to be concerned about polling
the mouse periodically.
In QuickBASIC 4.00a (distributed with BASIC 6.x), 4.00b (bug fix
update to 4.00 and 4.00a), 4.50, and QBX (distributed with PDS) there
The QBNews Page 29
Volume 2, Number 3 September 15, 1991
exists a little-known and seldom-used statement called "ON UEVENT
GOSUB LineLabel." It's much like other BASIC event processing
statements like "ON TIMER", "ON KEY", "ON COM", etc. in that it allows
program control to be transferred to a subroutine when a special event
occurs. A "UEVENT" or "User Event" is programmer-definable. In this
case, we establish a "hook" into the mouse driver and when a specified
type of mouse event occurs, the mouse driver notifies our assembly
routine, which in turn notifies BASIC. The next time the BASIC runtime
code processes events (at each line label or after each statement,
depending on the use of the /V and /W compiler switches) control is
transferred to the desired subroutine. Neat, huh?
The routine MouseSetEvent is used to define the type of event(s) that
you are interested in. These events can include any combination of a
specific button being pressed or released, or any mouse movement at
all. Once an event has occurred and program control has been
transferred to your BASIC subroutine, the MouseGetEventInfo routine is
used to determine exactly what type event occurred and where the mouse
pointer was located at the time. When you wish to turn off the mouse
event trap, call the MouseCancelEvent routine. Here's how it's done:
REM $INCLUDE: 'MOUSE.BI'
Buttons% = MouseReset%
IF Buttons% = 0 THEN
PRINT "Mouse not present."
END
END IF
CALL MousePointerOn
'First, define the types of event(s) you want to trap. This is
' done by passing value in EventMask%. Just pick the events you
' wish to trap, add up their values and pass it to the
' MouseSetEvent routine.
' 1 = Any mouse movement
' 2 = Left button pressed
' 4 = Left button released
' 8 = Right button pressed
' 16 = Right button released
' 32 = Center button pressed
' 64 = Center button released
'Let's trap a left or right button release. That's 4 + 16 = 20.
EventMask% = 4 + 16
CALL MouseSetEvent(EventMask%)
'Next, tell BASIC to watch for the event and to transfer program
' control to the at the MouseEvent line label when an event
' occurs.
The QBNews Page 30
Volume 2, Number 3 September 15, 1991
ON UEVENT GOSUB MouseEvent 'Watch for the event
UEVENT ON 'Enable UEVENT checking
'Let's set up an idle loop to demonstrate the event processing
CLS
PRINT "Each time you release the left or right mouse button, our"
PRINT "event-handling code will be called. When you've seen"
PRINT "enough, press any key to end this program."
PRINT
DO
LOOP UNTIL LEN(INKEY$) 'Loop until a key press is detected
'To turn off event checking
UEVENT OFF
CALL MouseCancelEvent
CALL MousePointerOff
END
MouseEvent: 'Transfer control here on a mouse event
CALL MouseGetEventInfo(EventType%, Lb%, Rb%, Cb%, Row%, Column%)
PRINT "Mouse event occurred: - ";
'"AND" EventType% with the value of the event being checked
IF EventType% AND 4 THEN
PRINT "Left Button was released."
END IF
IF EventType% AND 16 THEN
PRINT "Right Button was released."
END IF
PRINT "Mouse location:"; Row%; ","; Column% RETURN
Using BASIC's event-trapping services generates larger executable
programs because of the additional event-checking code required at
runtime. However, there are ways to reduce this added overhead to a
minimum.
1. Use "UEVENT ON" and "UEVENT OFF" around code in which you wish to
have event-trapping active. Putting a "UEVENT ON" at the top of your
program without a following UEVENT OFF will cause BASIC to generate
event-checking code for your entire program. If you selectively use
UEVENT ON and UEVENT OFF (e.g. around your input or selection code), -
you- can keep the overhead to a minimum.
2. Programs that use BASIC event-traps must be compiled with the /V or
/W switches. /V directs BASIC to check for an events after *every
BASIC statement* (within the UEVENT ON and UEVENT OFF boundaries, that
is). /W directs BASIC to check for events only when crossing line
labels. The latter will obviously generate less overhead, but
requires you to be more careful with your placement of line labels -
no line labels, no event-checking.
The QBNews Page 31
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
Fine-tuning the Mouse
----------------------------------------------------------------------
In addition to controlling the mouse's visual characteristics, you can
control its physical characteristics as well. This includes its
sensitivity and double-speed threshold.
"Sensitivity" is the ratio between the distance the mouse is
physically moved (in Mickeys) and the distance the mouse pointer
actually moves (in pixels) on the screen. The default ratios are one
Mickey per pixel horizontally and two Mickeys per pixel vertically.
The higher the ratio, the more physical mouse movement is required to
move the mouse pointer. The routine MouseSetRatio is used to adjust
the mouse sensitivity. For example:
VertRatio% = 2
HorizRatio% = 1
CALL MouseSetRatio(VertRatio%, HorizRatio%)
The "double-speed ratio" is the physical speed (in Mickeys per second)
that the mouse must travel before the mouse pointer shifts into
overdrive and moves across the screen twice as fast. The default is 64
Mickeys per second (about 1/3 of an inch per second). The routine
MouseSetDblSpd is used to adjust the double-speed ratio. For example:
MickeysPerSecond% = 200 'Set to one inch per second
CALL MouseSetDblSpd(MickeysPerSecond%)
Using the MouseGetSensitivity routine, you can also retrieve the
current sensitivity settings from the mouse driver. For example:
CALL MouseGetSensitivity(VertRatio%, HorizRatio%, _
MickeysPerSecond%)
----------------------------------------------------------------------
Miscellaneous Mouse Routines
----------------------------------------------------------------------
The following list of "miscellaneous" mouse routines can be useful
from time-to-time. They allow you to restrict the mouse movement,
position the mouse pointer through software, save and restore the
mouse "state," allow you to define the coordinate system the mouse
pointer location is returned in (character-based row/column format or
X/Y pixel-based format), and more.
MouseSetWindow - Used to define a rectangular area on the screen in
which the mouse pointer movement will be restricted. Once called, the
user will not be able to move the mouse pointer out of the defined
area. To disable a previously defined window, call this routine again
with the dimensions of the entire screen. For example:
The QBNews Page 32
Volume 2, Number 3 September 15, 1991
TopRow% = 6
LeftColumn% = 10
BottomRow% = 20
RightColumn% = 70
CALL MouseSetWindow(TopRow%, LeftColumn%, BottomRow%,_
RightColumn%)
'To turn the window off (assuming an 80 X 25 screen)
TopRow% = 1
LeftColumn% = 1
BottomRow% = 25
RightColumn% = 80
CALL MouseSetWindow(TopRow%, LeftColumn%, BottomRow%,_
RightColumn%)
MouseSetExclusionArea - When the mouse pointer is moved into the
rectangular area of the screen defined by this routine, it is made
invisible. Use the MousePointerOn routine to make the pointer visible
again. For example:
TopRow% = 6
LeftColumn% = 10
BottomRow% = 20
RightColumn% = 70
CALL MouseSetExclusionArea(TopRow%, LeftColumn%, BottomRow%,_
RightColumn%)
'To turn the mouse pointer back on:
CALL MousePointerOn
MouseSetPointer - Used to position the mouse pointer on the screen.
For example:
Row% = 5
Column% = 20
CALL MouseSetPointer(Row%, Column%)
MousePixelsOn - Used to change the default coordinate system used by
the mouse routines discussed in this article from character-based
row/column coordinates (which is the default) to X/Y pixel-based
coordinates. This routine defines the coordinate system used for both
input -and- output. This routine is provided because row/column
coordinates are generally preferred in text video modes and X/Y pixel-
based coordinates are generally preferred in graphics video modes. Use
the MousePixelsOff routine to switch back to row/column coordinates.
For example:
CALL MousePixelsOn 'Switch to X/Y pixel-based coordinates
CALL MousePixelsOff 'Switch back to row/column format
MouseSaveState - Saves the current mouse "state." This includes the
current position, visibility, shape, and other mouse pointer
characteristics. You could use this routine just prior to a SHELL so
the original state could be easily restored on returning to your
The QBNews Page 33
Volume 2, Number 3 September 15, 1991
program. This routine automatically allocates the required amount of
memory from DOS and releases it on the call the MouseRestoreState. The
MouseSaveState routine can be declared as a SUB or an integer
FUNCTION. If declared as a FUNCTION, it returns -1 (TRUE) if the
state was successfully saved and 0 (FALSE) if insufficient memory was
available. We have it DECLAREd as a FUNCTION in the MOUSE.BI file
included with this article. For example:
Success% = MouseSaveState%
IF Success% THEN
PRINT "Mouse state saved!"
CALL MouseRestoreState
ELSE
PRINT "Insufficient memory to save mouse state!"
END IF
MouseSetPage - Sets the video display page on which the mouse pointer
will be visible. Normally, the mouse driver is aware of changes in
active video pages, so it is not usually necessary to call this
routine. However, if you are using non-standard methods of switching
video pages, this is how you can tell the mouse driver what you are up
to. The function MouseGetPage% is used to return what the mouse driver
believes to be the active video page number current in use. For
example:
SCREEN ,,1,1 'Switch BASIC into page 1
PageNum% = 1
CALL MouseSetPage(PageNum%) 'Tell the mouse driver about it
PRINT "Mouse pointer on page";
PRINT MouseGetPage%
MouseExit - Releases all memory allocated by these mouse routines and
unhooks the "user mouse service" function required by MouseSetEvent.
You need to call this routine ONLY if:
You are about to CHAIN to another program and the MOUSE.OBJ is
*not* in a BASIC 6.X or PDS extended runtime library, or
You are about to SHELL and the MOUSE.OBJ file -is- in an extended
runtime library.
If your BASIC program terminates normally (with an "END" or "SYSTEM"
statement), there is no need to call MouseExit at all.
----------------------------------------------------------------------
Special Considerations
----------------------------------------------------------------------
If your BASIC program terminates via the "END" or "SYSTEM" statements,
we automatically release memory that we've allocated and "unhook" the
mouse driver. Using a service called "B_OnExit", the BASIC runtime
code calls our internal clean-up code just prior to returning system
control back to DOS.
The QBNews Page 34
Volume 2, Number 3 September 15, 1991
However, if you CHAIN to another program, the CHAINing program
actually terminates but BASIC does not process the B_OnExit chain
allowing us to clean up our mess. Essentially this means that your
system can potentially lock up if you've used the MouseSetEvent or the
MouseSaveState routines. See the entry for MouseExit above for more
information.
----------------------------------------------------------------------
Using the Routines
----------------------------------------------------------------------
Now since we've gotten all of that technical stuff out of the way,
you're probably about ready to actually being using the routines.
Included with this article, you find a file called MOUSE.OBJ. It is an
object file which contains all of the mouse routines described here.
You can put this .OBJ file in a QuickLibrary, a LINK library, or LINK
it directly to your compiled programs. It's completely compatible with
QuickBASIC versions 4.00a - 4.50, BASIC 6.X, and PDS 7.x.
Distributed with this article is a batch program called BLDLIB.BAT.
It will automatically build a QuickLibrary (.QLB) and LINK library
(.LIB) for your compiler version. Type "BLDLIB" at the DOS prompt for
instructions. However, if you prefer to know about the "hows" and
"whys" and would like to build your libraries manually, read on.
To build a QuickLibrary so you can call the mouse routines from with
the QB(x) development environments, issue the following command at the
DOS prompt:
LINK /Q MOUSE, MOUSE.QLB, NUL, BQLB45;
The above LINK command will generate a QuickLibrary for QuickBASIC
version 4.50. Change the QuickLibrary support module name (listed
above as BQLB45) to BQLB41 or QBXQLB to build a QuickLibrary for
QuickBASIC 4.00x and QBX, respectively.
To build a LINK library or to add the MOUSE.OBJ file to an existing
LINK library, type the following at the DOS prompt:
LIB MOUSE +MOUSE.OBJ ;
The above LIB command will create a library called MOUSE.LIB. If you
wish to add the mouse routines to an existing library, substitute that
library name for the first occurrence of MOUSE above.
To load the example program into the environment, type the following
at the DOS prompt:
QB MOUSETST /L MOUSE For QB 4.X
QBX MOUSETST /L MOUSE For QBX
The above commands load the example program MOUSETST.BAS into the
environment along with the MOUSE.QLB QuickLibrary we created earlier.
The QBNews Page 35
Volume 2, Number 3 September 15, 1991
To compile and LINK your program, you can select "Make an EXE" from
the QB(x) environments (assuming you have constructed matching .QLB
and .LIB files per the above instructions), or you can manually
compile and link from the DOS prompt. The latter is the preferred
method because it gives you more control over compiler switches used.
For example:
BC MOUSETST /O/W ;
LINK /EX MOUSETST + MOUSE ;
Or, if you've placed MOUSE.OBJ in a link library, you can do this:
LINK /EX MOUSETST,,NUL, LibraryName ;
[EDITOR'S NOTE]
All files for this article can be found in the file MOUSE.ZIP.
*********************************************************************
Tony Elliott has been programming in BASIC and assembly langauge for
over ten years. He worked for MicroHelp, Inc. for almost four years as
their Technical Support Manager and was directly involved in the
development of many of their QuickBASIC/PDS products. He has spoken at
a number of BASIC Symposiums conducted around the country between 1989
- 1991, and was a speaker at the August, 1991 Microsoft Developers
Tools Forum held in Seattle. He has written articles for BASICPro
Magazine and MicroHelp's "BASIC Users Group" Newsletter. He is now
Vice President of EllTech Development, Inc. which recently developed
and is currently marketing a network-ready replacement for PDS
ISAM called "E-Tree Plus" (see the ad included in this issue).
**********************************************************************
The QBNews Page 36
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
A d v e r t i s e m e n t
----------------------------------------------------------------------
E-Tree Plus By EllTech Development, Inc.
Finally, a network-ready B+Tree file indexing library designed
specifically for BASIC programmers that's FAST and EASY TO USE! If
you are already familiar with Novell's Btrieve or Microsoft PDS ISAM,
you can be up and running in 15 minutes .. no kidding! For those of
you new to network database programming, it may take a little longer.
For those of you currently using PDS ISAM, this product is an ideal
network solution for you. Our function syntax is very similar, we
provide a conversion utility for your existing databases, and we even
have a section in our manual that will take you step-by-step through
converting your existing program source code.
Easy to Use
Automatically detects the presence of Novell or NETBIOS compatible
networks and handles file and recording locking for you. However, you
still have full control over how the locks are implemented, timeouts,
etc., should you have a need to override our default actions.
11 high-level functions allow you to: create E-Tree database files;
add and delete indexes; change the active index; insert, update,
retrieve and delete records; locate a specific record or groups of
records quickly and easily. In addition, over 40 low-level functions
are provided to give you complete control over almost every aspect of
the database manipulation.
Convert existing PDS ISAM applications to E-Tree Plus with minimal
effort. E-Tree Plus's functions use syntax and naming conventions
similar to PDS ISAM. In many cases, existing code can be used with
only minor modifications.
Simplified database maintenance. We include a utility ("EUTIL.EXE")
you can use to create databases, modify an existing database's
structure (add or delete a field), import and export ASCII data,
convert Btrieve dBase compatible files, and PDS ISAM file to E-Tree,
and more.
We automatically determine the optimum file page size, record
length, etc., for you. There are no complicated formulas and no
cryptic function numbers to remember.
Includes a fully indexed, reference oriented, 200+ page manual. It
includes example programs, a database/network tutorial, complete specs
on the E-Tree Plus database format, and even a "Quick Start" section
for the seasoned database programmer.
The product is provided in LINKable libraries and .OBJect files.
No TSR programs to load or to get in the way.
Fast and Flexible
Written using a combination of BASIC and assembly language for the
perfect mixture of versatility and speed.
All BASIC data types are supported, and then some.
Flexible indexing. You can add or delete indexes at any time. Up to
1023 indexes (more than you'll ever need) can be defined at one time.
Indexed "keys" can be defined as unique, duplicates allowed,
The QBNews Page 37
Volume 2, Number 3 September 15, 1991
modifiable, non-modifiable, segmented (comprised of pieces of one or
more fields), ascending, descending, and auto-incrementing (ideal for
invoice or order numbers).
File sizes up to 4 billion bytes. The maximum number of records per
file is limited only by available disk space.
Supports fixed-length records, variable-length records, and
combinations of both.
Efficiently uses system resources. Automatically detects and uses
LIM Expanded Memory for file I/O buffers.
Reliable
Built-in data integrity checking. Using 32-bit CRC, the integrity
of your data is checked with near 100% accuracy. If a problem should
develop, the chances are very good that all of your data can be
recovered or reconstructed.
Stores data records, indexes, and its "data dictionary" in the same
file. This means that there are no "index" files or "definition" files
for your customers to lose track of, and only one DOS file handle is
required per open database.
Affordable
Distribute E-Tree Plus applications and the EUTIL.EXE database
maintenance utility royalty-free.
One version supports QuickBASIC 4.x, BASCOM 6.x, Microsoft PDS 7.x,
and PowerBASIC 2.x.
Includes structured, fully commented BASIC and assembly language
source code at no additional charge.
Price includes free, full-time technical support. We even provide 24
hour support through our BBS. Customers can download maintenance
releases of E-Tree Plus free of charge! Just ask our competitors if
they can offer the same!
Introductory Offer: $199.00 until 11/30/91
Shipping and handling: $ 6.00 (U.S. addresses)
Orders and Product Info: (800) 553-1327 (U.S. and Canada)
Technical Support: (404) 928-8960
BBS: (404) 928-7111 (HST)
E-Tree Plus will be available for shipping on September 15, 1991.
Prices are listed in US Dollars. All trademarks belong to their
respective owners.
EllTech Development, Inc.
4374 Shallowford Industrial Parkway
Marietta, GA 30066
The QBNews Page 38
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
A l g o r i t h m s
----------------------------------------------------------------------
Cardans's Method for Solving Cubes by Richard Jones
One of the most common tasks in mathematics and its applications is
that of root-finding. That is, we have some function, f(x), and we
want to find the value(s) of x for which f(x) = 0. It is
disillusioning to note that all centuries upon centuries of
mathematics can say about the general case, including monsters like
a * x^2 * exp(-b * x) - sin(c * x) = 0,
is that there may be one, several, or an infinite number of roots, or
maybe none at all, which really tells us a lot. Fortunately, a lot
more is known about a smaller and more common category of functions,
polynomials of degree n, of the form
a(0) + a(1) * x + ... + a(n) * x ^ n = 0, n >= 0.
Back in high school, we all learned about the n = 1, or linear, and
the n = 2, or quadratic, cases of polynomials. We found that the
linear equation a*x + b = 0 has exactly one root given by x = -b/a and
that the two roots of a quadratic a*x^2 + b*x + c = 0 are given by the
reknown quadratic formula:
x = (-b +- (b^2 - 4*a*c)^(1/2)) / 2a. (3)
We then noticed what appeared to be a hint of a relation between the
degree of a polynomial and the number of roots. After high school, we
went off to college and, depending on what field of study we chose,
began to go down the path of one of the various branches of higher
mathematics and, along the way, perhaps learned some theorems about
polynomial equations and the nature of the roots. It's interesting to
note that while a lot may have been said about the nature of the
roots, nothing was really said about how to find them for the case of
n >= 3. It turns out that analytic solutions for polynomials up to the
fourth degree are known (equations of higher degree cannot be solved
exactly by any finite number of arithmetic operations - you have to
resort to approximate numerical methods). The solutions to cubic and
quartic equations are quite involved, though, which is one of the
reasons nobody bothers with them. This, at long last, brings us to the
subject of this article: a QuickBASIC implementation of the solution
to the cubic equation known as the Tartaglia-Cardan solution or simply
Cardan's method.
Roots of Polynomials
A little background theory on polynomial roots will helpful in
understanding how our method works. A polynomial of degree n, pn(x),
will have exactly n roots provided we expand the range of an
acceptable solution to include the set of complex numbers. While the
The QBNews Page 39
Volume 2, Number 3 September 15, 1991
linear equation's root, -b/a, is always real, what happens when the
term under the square root in equation (3) is negative? The notion of
a complex number was actually invented to handle this case. Notice how
complex things become when we go from n = 1 to just n = 2; we have to
"invent" a new class of number. You might think that more numbers
would have to be invented to handle the n = 3 case, but it turns out
that the set of complex numbers will suffice for any n. Unlike the set
of reals, this set is closed, which means that any operation performed
on any of the members will always produce another member of the set.
Complex roots of polynomials with real coefficients (this doesn't
apply if the coefficients themselves are complex) will occur in
conjugate pairs which means that there will always be an even number
of such roots. Therefore, an equation of odd degree must have at least
one real root. This can be easily seen by considering the values of
pn(x) and pn(-x) as x grows large and the high order term dominates.
If n is odd, pn(x) and pn(-x) must be of opposite sign and, since
polynomial functions are nice and continuous, the curve must then
cross the x-axis at least once. Knowing this, we can say that a cubic
equation must have either three real roots, or one real and a pair of
complex conjugate roots.
Cardan's Method.
Unlike the quadratic, it's impractical to write the solution to the
cubic as a single formula - it's far better presented as a series of
steps which are somewhat involved, so hang on. The first step is to
divide through by the coefficient of the cubic term and write the
equation in the so-called standard form:
x^3 + a*x^2 + b*x + c = 0. 4)
There is no direct solution for the equation in this form, however,
and so we must make a change of variable to eliminate the quadratic
term. The substitution x = u - a/3 will accomplish this and we will
have a "reduced" cubic of the following form:
u^3 + p*u + q = 0, 5)
where the new coefficients, p and q are given in terms of those of 4)
by
p = (3b - a^2) / 3,
q = (2a^2 - 9ab + 27c) / 27.
Like a quadratic, a cubic equation has a discriminant, D, whose sign
tells us some things about the nature of our roots. The discriminant
of the cubic in the form of 5) is given by
D = q^2 / 4 + p^3 / 27.
There are three distinct cases depending on the sign of D:
The QBNews Page 40
Volume 2, Number 3 September 15, 1991
D > 0 -> one real root and a pair of complex conjugates.
D = 0 -> degenerate case - 3 real roots of which at least 2 are
equal.
D < 0 -> 3 real and distinct roots.
Now calculate the two values A and B given by the following:
A = (-q/2 + D^(1/2))^(1/3), and
B = (-q/2 - D^(1/2))^(1/3).
And, finally, the 3 roots of 5), u1, u2 and u3, are then given by
u1 = A + B, 6)
u2 = -u1 / 2 + i(A - B) * 3^(1/2) / 2, and 7)
u3 = -u1 / 2 - i(A - B) * 3^(1/2) / 2, 8)
where i represents the famous (or infamous) square root of -1.
The three roots of the original equation, x1, x2 and x3, are given by
the substitution relation above, x = u - a / 3.
Note that if D > 0, x1 is real and x2 & x3 are complex conjugates. If
D = 0, then A = B and the imaginary terms in 7) and 8) are zero and u2
= u3 and hence x2 = x3. Also, our substitution may produce p = q = 0,
in which u1 = u2 = u3 = 0, and our 3 roots will all be equal and given
by x1 = x2 = x3 = -a / 3. Such cases are known as multiple roots - we
still say the equation has 3 roots but it just happens that two or
more are equal to each other.
Now for the hard part, the D < 0 case. Notice that if D < 0, the
calculation of A and B requires us to extract the cube roots of two
complex numbers. Twenty years ago, this would be a time for despair,
but now that we all have enormous amounts of computing power sitting
on our desks and handy-dandy high-level language compilers like MS
QuickBASIC with a wealth of built-in math functions to utilize that
power, it's a piece of cake. A complex number, z, which is usually
written in rectangular form as some x + i*y, also has a so-called
polar form, z = r * exp(i*R), where r, known as the magnitude or
modulus, and R, known as the argument or simply the angle, are given
by a simple pythagorean relation:
r = (x^2 + y^2)^(1/2), and
R = arctan(y / x).
In polar form, exponentiation is simple. We raise the modulus (always
a positive real) to the desired power and simply multiply the angle by
this power. So, to take the cube root of a complex number, we put it
in polar form, take the cube root of the modulus, and divide the angle
by three. Trigonometric functions then get us back to rectangular
The QBNews Page 41
Volume 2, Number 3 September 15, 1991
form. Since in this case A and B are conjugates, things can be
simplified somewhat and we can write our u's as follows:
u1 = 2r * cos(R). 9)
u2 = r * (3^(1/2) * sin(R) - cos(R)), and 10)
u3 = -r * (3^(1/2) * sin(R) + cos(R)), 11)
where r is given by
r = (q^2 / 4 - D)^(1/6),
and the angle R is given by
R = arctan( -2 * D^(1/2) / q ) / 3.
It's rather interesting that, after all this complex arithmetic, the
results are purely real, and that the D < 0 case requires
transcendental operations, elementary trigonometric ones in our case.
(Transcendentals are called such because they "transcend" the realm of
ordinary arithmetic - the only kind we know how to do. They cannot be
calculated exactly by any finite number of additions, multiplications,
or exponentiations.) It's actually cheating a bit to say that we have
an analytic solution for the D < 0 case because of the
transcendentals. We can write a formula down only because we've
invented a special notation for the trig functions, namely "sin",
"cos", and "arctan", which can only be approximated. (Think about it.
Using only a pad and pencil, try to calculate the sine of a 37 degree
angle. If you remember the power series and don't mind doing long
division with 10 - 30 digit numbers, you might get it to 5 places in
an hour or two. Personally, I'd get a protractor and a carpenter's
square and "experimentally" measure it and might manage to get two or
three places.)
Cardan's Method in QuickBASIC
Whew! Now that we've got Cardan's method down pat, it's easy to write
a QB program to carry out the steps. The listing is of the program
which I've written to implement Cardan's method. It consists of a
subroutine, CUBERT, which does the work, and a simple driver which
gets the coefficients of equation from the user, prints out the roots,
and prints out the value of the function at one of the supposed roots
that the subroutine returns as a check. I've also included a function,
POLY, which evaluates polynomials the "right" way. I'll say more about
this later. The driver is fairly simple and pretty much
self-explanatory in function.
CUBERT follows the procedure above fairly closely, and I've tried to
use variable names that correspond to those in the equations above.
The routine expects to be passed an array, A#(), containing the
coefficients of the cubic, an array, X#(), in which to place the roots
it calculates, and a flag, F%, to indicate the type of the roots
returned. If F% = 1, all the roots are real and distinct and their
The QBNews Page 42
Volume 2, Number 3 September 15, 1991
values will be in elements 1 through 3 of X#(). F% = 2 corresponds to
the D >= 0 cases and X#(1) will contain the one real root and the next
two elements will contain the real and imaginary components of the
conjugate pair of complex roots. Notice the use of the STATIC keyword
on the subroutines. This causes the compiler to allocate local
variables statically in DGROUP rather the on the stack and can save
time in routines with a lot of local variable accesses on older 8088
machines. This is not compatible with recursion, though.
The first thing CUBERT does is calculate the coefficients of the
standard form and from this calculates the p and q coefficients and
then finds the discriminant. And IF statement checks the sign of the
discriminant. If D >= 0, the routine calculates the roots according to
equations 6) - 8). The calculation of the numbers A and B requires the
calculation of the cube roots of two values that can be negative. The
QB library code can't raise negative numbers to non-integral powers
(because the method used has to take the logarithm of the base) and
this requires the code to check the signs. If one is negative it
calculates its cube root as the negative of the cube root of the
absolute value. (Related to the fact that a polynomial of degree n has
n roots is the fact that any number has exactly n nth roots. While for
odd n, the principle nth root of a negative number is always complex,
one of these n roots will simply be the negative of the principle nth
root of that number's absolute value. While we are biased toward
principle roots, any of the n nth roots will usually work in most
situations.) After taking these cube roots, the code returns the roots
of the equation as outlined above.
I didn't bother to include an ELSEIF clause to check for the case of D
being exactly equal to zero for a number of reasons. Remember that
computer floating point arithmetic is finite and approximate, not
exact. It is very rare indeed when you'll find two things exactly
equal because there is always a little (or a lot, with unstable
algorithms) bit of "noise" involved in every calculation. Also, the D
= 0 case corresponds to the case of multiple roots and numerical
analysis tells us that in this case the roots are poorly conditioned
with respect to the coefficients anyway. ("Conditioning" is a term
from numerical analysis which can be thought of as a kind of signal-
to-noise ratio. It is a measure of how sensitive a calculation is to
this floating point noise.) So what you'll find in this case is that
the imaginary components returned are very small relative to the real
components, or that two or more of the real and "distinct" roots are
very close if the "noise" makes D slightly negative.
If the discriminant is negative, the code follows equations 9) - 11)
above. The magnitude calculation is straightforward, but the angle
calculation is a tricky affair. We have to calculate the angle as an
arctangent of the ratio of the imaginary and real components. But what
happens if the real part is zero? In this case the angle is 90
degrees, but we'll overflow when we take the ratio if the real part is
small enough. The way to avoid this is to check the denominator before
taking the ratio. If it's > 1, we can go ahead, but if it's < 1 we
The QBNews Page 43
Volume 2, Number 3 September 15, 1991
have to make sure the division won't overflow. We want to make sure
that, say, a / b <= c, but without doing the division. This will be
true only if a <= c * b, and this what CUBERT does. If the ratio will
be greater than a constant, which I called BIG# and set to 1E40, the
code sets the angle to 90 degrees. (While the tangent of a right angle
is infinite, 1E40 is about as close to infinity as we need in this
case.) Finally, if the ratio is negative QB's ATN function will return
an angle in the fourth quadrant, but the angle we want lies in the
second, so the code has to adjust the angle if needed.
That just about wraps up the operation of CUBERT. Once CUBERT returns
the roots, the driver calls function POLY to evaluate the cubic at the
first root. As I said before, POLY evaluates polynomials the right
way. At first blush, we might try something like this to evaluate a
polynomial of degree n at x whose coefficients are in an array:
P# = A#(0)
FOR I% = 1 TO N%
P# = P# + A#(I%) * X# ^ (N%)
NEXT I%
But this requires n additions, n multiplications, and n
exponentiations. POLY# does the same thing using Horner's method with
only n additions and multiplications and no exponentiations. The above
method is also much more "noisy" than POLY#.
Cardan's method certainly falls into the category of the obscure and
as a result many people aren't aware of the way to solve cubic
equations and resort to numerical root-finders when they need to solve
them. CUBERT can be used in any program that needs to find the roots
of cubic equations and, I think, will be a helpful addition to your
library. I hope this program will make solving cubics as easy and as
common as solving quadratics. If you have in questions, comments or
witticisms about this article or the program, feel free to contact me
anytime.
For a bibliography and a "for further reading" section I would
recommend the following texts:
Thompson, J. E.: "Algebra for the Practical Worker," 4th ed.,
Van Nostrand Reinhold Co., New York, NY, 1982.
(While, as its title implies, the above is a lower-level text, it
neverless contains an excellent discussion of Cardan's Method.)
Churchill, R. V. & Brown, J. W.: "Complex Variables and
Applications,"
4th ed., McGraw-Hill, New York, NY, 1984.
Beyer, W. H.: "CRC Standard Mathmatical Tables," 28th ed.,
CRC Press, Boca Raton, FL, 1988.
Mizrahi, A. & Sullivan, M.: "Calculus and Analytic Geometry,"
Wadsworth Publishing Co, Belmont, CA, 1982.
The QBNews Page 44
Volume 2, Number 3 September 15, 1991
Stoer, J. & Bulirsch, R.: "Introduction to Numerical Analysis,"
Springer-Verlag, New York, NY, 1980
The above constitute my standard references on the math covered in the
article, but please note this represents a personal preference and
shouldn't be considered the best possible sources.
**********************************************************************
Richard Jones is an "almost" graduate of Clemson University in SC. He
majored in Physics there, but lack 4 hrs. of a foreign language for
his B.S. His main interests include math, physics, and programming,
and is currently employed with P.C. Electric Co. in Greenville, SC. He
can be reached on Compuserve at 76636,536.
**********************************************************************
The QBNews Page 45
Volume 2, Number 3 September 15, 1991
----------------------------------------------------------------------
F u n a n d G a m e s
----------------------------------------------------------------------
Lines With Style by Larry Stone and Charles Graham
During the Winter of the Big Freeze, with nothing to do and much
time on his hands, Charles Graham, during a state of extreme boredom,
found himself alone with a glass of wine in one hand and his fingers
at the keyboard with his other hand. Thus was born an algorithm later
to be shared with us all as source code for his program, "ENERGY".
Aside: Charles' called to complain that the glass of wine wasn't
in hand until AFTER he created his code <GRIN>.
FUSION, based upon Charles' original algorithm, produces a kaleido-
scope of colors, design, music and sounds that will provide hours of
delightful fascination.
Before we get much further, you should know that FUSION only runs
in EGA screen 9 or VGA screen 12. Even if your monitor cannot handle
these modes you will still benefit from FUSION's many other, useful
routines.
For example, the PrintROMtable subprogram gives you pixel by pixel
control for the ASCII characters 1 through 128. See the article Fonts
in a Can earlier in this issue for more on this subroutine.
If you study FUSION.BAS, you will notice that except for one PAINT
and a couple of PALETTE commands, all graphics are produced via the
BASIC LINE or CIRCLE statement. Closer examination reveals the heart
of the program is the LINE statement. QB's LINE statement is one of
the most powerful graphic commands available. Conversely, it is may
be one of the least understood graphic command. Although entire books
could be written about the LINE statement, only one of its optional
variables will be examined here -- the "style%" argument.
Simply put, the integer variable, style%, is a mask or stencil laid
over the line. When we "paint" the line, the paint falls through the
holes of the "stencil" and is held back by the "mask". Probably the
easiest way to show this is by following the logic of the subprogram
called, PrintROMtable.
One final note to you Tech-Heads. The algorithm that computes and
displays "energy" and "plasma" drawings is derived by calculating the
polar equations for each ellipse generated from weighted, random
numbers. Random numbers are weighted by expressions such as:
g = INT(RND * 590) + 50 '50 - 640 possible points to each drawing
w = INT(RND * 1.9) + .1 'weighted factor used for yavg, etc.
Where g is a random number whose value is forced to lie between 50 and
640 and, where w is a random number whose value is forced to range
between 0.1 and 1.9, respectively. Albert Einstein would have loved
The QBNews Page 46
Volume 2, Number 3 September 15, 1991
this algorithm - the programmer's
universe is totally random but the
programmer is using "dice" that are loaded. The effect is random, yet
symmetrical designs. My additions to Charles' algorithm continue this
mix of order and chaos - "muon" and "quark" trails are produced and
displayed with weighted, random numbers. The same mix of symmetry and
randomness is employed with color and with the number of drawings that
display at one time. Thank you, Charles Graham, for the wonderful
algorithm.
[EDITOR'S NOTE]
All code for this article can be found in FUSION.ZIP
**********************************************************************
Larry Stone is President of LSRGroup and is involved in writing
instructional and large data base application systems for business and
institutional clients. He is also the author of SERVICES, a shareware
application program rated a trophy by "Public Brand Software". He can
be reached at LSRGroup, P.O. Box 5715, Charleston, OR 97420, or in
care of this newsletter.
**********************************************************************
**********************************************************************
Charles Graham is a division head for a local government agency in St.
Louis County, Missouri. He also teaches QuickBASIC part time at a
local community college. He is the author of several shareware
products including MOVIES . ON . LINE and, Quick Dial. He can be
contacted at Post Office Box 58634, St. Louis, MO 63158, and on the
National QuickBASIC Conference.
**********************************************************************
The QBNews Page 47
----------------------------------------------------------------------
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) and PDN (Programmers 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
Apple Capitol BBS Bob Finley Wenatchee, WA 509-663-3618 1:344/61
Finally, you can download The QBNews from these vendors BBS's:
The Crescent Software Support BBS 203-426-5958
The EllTech Support BBS 404-928-7111
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 offer a yearly
subscription for $15.00. This includes four disks containing each
The QBNews Page 48
Volume 2, Number 3 September 15, 1991
issue as it is published. If you would like a disk with all the back
issues of The QBNews, please enclose an additional $5.00. The pricing
structure is as follows:
Base Price for 1 Year - $15.00
Disk with Back Issues - $5.00
3.5" disk surcharge - $5.00
Canada and Mexico surcharge - $5.00
All other foreign orders - $10.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.
----------------------------------------------------------------------
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 49
