Copy Link
Add to Bookmark
Report
QBNews Volume 2 Number 2
Volume 2, Number 2 May 31, 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 2 May 31, 1991
----------------------------------------------------------------------
T A B L E O F C O N T E N T S
1. From the Editor's Desk
Exciting New Things Happening with BASIC ..................... 1
2. Ask The Doctor
How to Copy Files with QuickBASIC ............................ 2
3. Advertisement
PDQComm - Professional Communications for "Power Programmers" 5
4. View Print
BASICZen by John Richard De Palma ............................ 6
5. Swap Shop
Create Bar Charts in Text Mode with QB by David Rice ......... 12
Create Pie Charts with QB by David Rice ...................... 16
Add BASIC 7's DIR$ Routine to your QB Programs by Dave Cleary 20
6. The Tool Shed
A Look at Crescent Software's PDQComm by Jim Harre ........... 22
7. Who ya gonna call? CALL INTERRUPT
Working with the Rodent by Daniel R. Berry ................... 27
A Graphics Mouse Cursor Design System by Warren G. Lieuallen . 32
8. The QBNews Professional Library
Fast Screen Printing by Christy Gemmel ....................... 34
ROM-BIOS Video Services ...................................... 48
Using FastPrint with BASIC 7 ................................. 49
9. Power Programming
An Improved Cloning Algorithm by Larry Stone ................. 51
10. New and Noteworthy
Custom Control Factory for Microsoft Visual Basic by Desaware 53
11. Fun and Games
ASCII Art -- A Piece of Computer History by Charles Graham ... 54
12. QBNews Special Report
Special Preview of Visual Basic by Dave Cleary ............... 57
13. EOF
Receiving The QBNews ......................................... 59
Submitting Articles to The QBNews ............................ 60
The QBNews Page ii
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
F r o m t h e E d i t o r ' s D e s k
----------------------------------------------------------------------
Exciting New Things Happening with BASIC
Since the last QBNews, quite a bunch of exciting new things has
been happening with our favorite language. First and foremost,
Microsoft has finally released Visual Basic, its Windows Basic
programming environment. Also, BASICPro, a new magazine devoted to
BASIC programmers has been started. Finally, Microsoft is holding
a big developers conference for BASIC programmers in Washington at
the end of August. We will be able to meet the developers of
Microsoft's BASIC products and even Mr. Bill himself. I hope to see
some of you readers up there.
This newsletter will be remain devoted to QuickBASIC programming.
However, the next two issues will be covering Visual Basic as this
is a very exciting new product. There is a VB preview in this issue
and I hope for more in depth stuff for VB and other Windows BASIC
environments for the next issue.
BASICPro magazine is now two issues old. Although a bit pricey,
the magazine holds much promise to become the Dr. Dobbs of QuickBASIC.
If you haven't seen BASICPro, give them a call at 415-688-1808 to
order a trial subscription. Don't forget to tell them you heard of
BASICPro through The QBNews.
Finally, I am kicking off a new series of articles for The QBNews.
It is called The QBNews Professional Library. I am putting together
an assembly language library written by the industries top
programmers. Not only will you get ASM source code of the routines
contained in the library, but you will get an in depth article
explaining what is going on. This series should help people understand
the bits and bytes that make our computers tick and help make them
into better programmers.
Dave Cleary - Publisher of The QBNews
The QBNews Page 1
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
A s k T h e D o c t o r
----------------------------------------------------------------------
Ask The Doctor
Ask The Doctor is a new question and answer area for The QBNews.
You send in your questions and I will try my best to either answer
them myself or get one of the many QB experts I know to answer them
for me. If your question is used, I will send you that issue of The
QBNews on disk as soon as it is published. Because I am not superman,
I will not be able to answer every ones questions so if you don't see
your question in the QBNews, don't expect a reply. Of course, you can
always call the Crescent Software Support BBS to leave me questions
that I will try to answer. That number is 203-426-5958.
Dear Dave:
Keep the QBNews coming. I have been doing simple programming in
QuickBasic for over a year now but have not been able to progress very
far. Your electronic magazine has been extremely helpful. Here is a
question you or one of your contributors might be able to help me
with. I am wanting to copy or move files around on my hard drive. I
do not want to shell to dos and use the copy command. How can I do
this using QB? I have been reading the disk I/O section of my QB
manual but it is not very clear about how I might go about copying or
moving files. I have look at some dos interrupt functions in a book
call, "Programmer's Guide to the IBM PC". But again I am not sure how
to go about using interrupts to copy or move files around.
Is there any help out there for a novice like me?
Thanks,
Steven E. Walker
Wilkinson, IN
Steven,
QuickBASIC has many different ways to read an write files. This may
have caused your confusion. Copying files is easily done in QuickBASIC
and is quite fast also.
Lets first look at the options QB gives us to read a file. The
three major commands to read a file are LINE INPUT, INPUT$, and GET.
LINE INPUT is only good for text files and is also one of the slowest
QB commands as far as file IO goes. That leaves INPUT$ and GET.
GET and PUT are by far the fastest IO commands QB has. This is
because with GET, the area of memory where the data gets placed is
already allocated. All QB has to do is set up some registers and then
call DOS to read the file.
INPUT$ is another command that works for both text and binary
The QBNews Page 2
Volume 2, Number 2 May 31, 1991
files. INPUT$ is slightly slower than the GET command because it
allocates memory to hold the data each time it is called. I have found
this speed difference to be inconsequential though. INPUT$ does offer
some advantages over GET in our CopyFile routine. When you are at the
end of a file, INPUT$ will return a string with the exact number of
bytes left in the file even if you asked for more. This relieves us of
knowing the size of the file we are working with. GET, on the other
hand, will pad your buffer with null characters, causing us to have to
truncate the last read if we want to keep our file lengths the same.
For this reason, I chose INPUT$ over GET to read in the file.
So here is our copy file routine:
DEFINT A-Z
DECLARE FUNCTION DIR$ (FileSpec$) 'Comment out if using BASIC 7
DECLARE FUNCTION CopyFile% (Source$, Dest$)
'$INCLUDE: 'QB.BI' 'Required for CALL INTERRUPT
CONST Block = 4096 'Set this to the length you
'want your buffer to be
'Example of how to call CopyFile
'Ercd = CopyFile("D:\PDQ\HISTORY.DOC", "C:\SCRAP\TEST1")
FUNCTION CopyFile% (Source$, Dest$) STATIC
DIM Regs AS RegType 'Needed for CALL INTERRUPT
'----- See if source file exists
IF LEN(DIR$(Source$)) = 0 THEN 'Use DIR$ function from this
'issues SwapShop if you are
'using QB 4.x.
CopyFile% = 1 'Source doesn't exist
EXIT FUNCTION 'Exit with error code
END IF
'----- See if destination exists
IF LEN(DIR$(Dest$)) THEN
CopyFile% = 2 'Destination already exists
EXIT FUNCTION 'Exit with error code
END IF
'----- Open files for BINARY
SFileNum = FREEFILE
OPEN Source$ FORBINARY AS #SFileNum
DFileNum = FREEFILE
OPEN Dest$ FOR BINARY AS #DFileNum
'----- Now copy the files over
DO
Buffer$ = INPUT$(Block, #SFileNum)
The QBNews Page 3
Volume 2, Number 2 May 31, 1991
PUT #DFileNum, , Buffer$
LOOP UNTIL EOF(SFileNum)
'----- Set the date and time of the copy to that of the original
Regs.ax = &H5700
Regs.bx = FILEATTR(SFileNum, 2) 'This gets DOS's file handle
INTERRUPT &H21, Regs, Regs 'Get date and time of original
'----- Check for an error
IF (Regs.flags AND 1) THEN
CLOSE #SFileNum, #DFileNum 'Close the files
KILL Dest$ 'Kill our copy because something
CopyFile% = 3 'went wrong. Exit with error
EXIT FUNCTION
END IF
Regs.ax = &H5701
Regs.bx = FILEATTR(DFileNum, 2)
INTERRUPT &H21, Regs, Regs 'Set date and time of copy
'----- Check for an error
IF (Regs.flags AND 1) THEN
CLOSE #SFileNum, #DFileNum 'Close the files
KILL Dest$ 'Kill our copy because something
CopyFile% = 3 'went wrong. Exit with error
EXIT FUNCTION
END IF
CLOSE #SFileNum, #DFileNum 'All done
CopyFile% = 0 'Return with success
END FUNCTION
This routine returns a 0 if everything went all right. It will
return a 1 if the source file doesn't exist and a 2 if the destination
file does exist. It will return a 3 if something went wrong in setting
the copy's date and time to that of the original. This routine uses
BASIC 7 PDS DIR$ function. For those of you with QuickBASIC, I have
written a DIR$ function for you that appears in this issues SwapShop
section. The DIR$ I wrote works in much the same way that BASIC 7's
does.
If you have a question for the Doctor, please send them to:
Ask The Doctor
P.O. Box 507
Sandy Hook, CT 06482
The QBNews Page 4
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
A d v e r t i s e m e n t
----------------------------------------------------------------------
PDQComm - Professional Communications for "Power Programmers"
PDQComm contains both low-level and high-level routines that add
advanced communications capabilities to programs written using
Microsoft QuickBASIC version 4.0 or later, and BASIC 7 PDS. PDQComm
was originally designed to be used with our P.D.Q. replacement link
library, however, PDQComm is also ideal for use with regular BASIC
programs.
***** PDQComm is small and fast *****
All of the routines provided with PDQComm are extremely small, and
thus add very little code to your programs. The core routines for
creating a complete terminal program add less than 2500 bytes.
Compare that to the more than 12K which QuickBASIC adds, or perhaps
more important, to other communications libraries that are available!
***** PDQComm is easy to use *****
All of the PDQComm routines have been designed to emulate the syntax
of the QuickBASIC routines they replace as closely as possible.
PDQComm also takes advantage of the features available in QuickBASIC
4.0 and later. For example, to get a string of characters from the com
port, you would do the following:
QuickBASIC: PDQComm:
Work$ = INPUT$(LOC(1), #1) Work$ = ComInput$(ComLoc)
Compare that to what other communications libraries make you do:
CALL MhGetRecvStatus(Port, CharsInBuffer, ECode)
Work$ = SPACE$(100 + CharsInBuffer * 2)
CALL MhGetData(Port, Work$, Length, ECode)
Work$ = LEFT$(Work$, Length)
***** PDQComm supports high speed communications *****
While most communications libraries claim to support baud rates up to
115k, a standard serial port has problems keeping up. To insure error
free high-speed communications, PDQComm supports the NS16550A UART.
This is an advanced IC that contains an on chip buffer, allowing the
PC more time to receive incoming characters.
***** PDQComm comes with many bells and whistles *****
Also included is full emulation for the ANSI, DEC VT52 and VT100, Data
General D215, and generic terminal standards. These emulations can be
instructed to operate within a windowed area, and you can even have
multiple windows active at one time. PDQComm also comes with XModem
and ASCII file transfer routines. The PDQComm manual contains
extensive tutorial information explaining modems, serial cables,
specifying port parameters, and UARTs. All of the important Hayes
commands are described in detail, and each emulation includes a table
of codes that are recognized. PDQComm costs $99. For more information
or to order PDQComm, please call Crescent Software.
Crescent Software - Orders:800-35-BASIC - Tech Supt:203-438-5300
Crescent Software Support BBS:203-426-5958 - 2400,N,8,1
The QBNews Page 5
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
V i e w P r i n t
----------------------------------------------------------------------
BASICZen by John Richard De Palma
Red haired Sandra is the manager of the local Egghead
Software store. Gazing at her collection of software I said,
"Hi Sandra, Uh... can you show me what books and software you
have on learning to program in BASIC?"
"No, no...NOOOO... John, you want this!" Sandra said, as she
thrust an orange 10 pound box of manuals and disks into my arms
and gave me a beaming smile.
She went on, "I studied Pascal and "C" in college for TWO
years, no one, and I mean no one studies BASIC anymore, it's a
dead programming language." She laughed, "Just as dead as
learning Latin."
"Well, Uh," I shifted my feet for better support and put
down Borland's version of Turbo Pascal, "I studied Latin for two
years, and it's not all that dead," . "You see, Latin teaches
you to know intuitively many English prefixes, suffixes and many
of the Romance language verbs and nouns...." my voice trailed
off, even to me that sounded like an apology for spending two
years learning about BIG Julie and wars fought with catapults and
giant slingshots.
"Oh, don't be SILLY," Sandra said, "Here, if you don't like
that, buy this, its C ++ with OOP."
"I'm not even going to ask what "OOP" is, I said, just sell
me something in BASIC," I sighed.
"What KIND of basic programming do you want?" Sandra asked
briskly, swivelling around to check on her employees and
motioning to Brian to stop playing with the joystick and get back
to work.
"Well, hell, I DON'T KNOW, I just want to learn how to make
my own programs like Paul Somerson does. If BASIC is good enough
for him, it's good enough for me," my voice rising a half-octave.
I started looking around for the IBM utilities section in the
hopes of finding some box with basic BASIC information on it.
There was no question that I knew NOTHING about programming.
I was awkward and out of my depth. I knew nothing about
programming except that it had to be better than using batch
files to do things with MS-DOS. I was going to tell Sandra about
batch files. Tell her about all the batch file programs that I
had looked at that promised much and delivered little. I wanted
to tell her about batch techniques that did not allow input into
them except as parameters on the command line or by using the
The QBNews Page 6
Volume 2, Number 2 May 31, 1991
dopey "FOR" command or the klutzy "IF ERRORLEVEL" command. I
wanted to tell her I wanted to make colorful screens with
selections that could be input by cursor control. I wanted to be
able to change directories, do file sorts... I wanted to
understand how the computer worked and then tell it what to do.
Hell and again hell, I wanted to control the computer software.
Who's Paul Somerson?" Sandra queried. "Some computer
propeller head in Santa Monica?"
"Gad, Sandy, give me a break! Paul Somerson is the editor
of my favorite PC bible, "DOS Power Tools," he programs in BASIC.
Look...look, you have his book on your bookshelf right here.
Wait... waaait, I'll find the section and read it to you. Come
back here, Oh let Brian wait on that guy, this will only take a
minute."
I picked up the book, found the page and read from my hero
Paul[1],
"One of the nicest things about BASIC is that if you
suddenly find yourself with a problem BASIC can tackle, you can
load it, stumble your way through a program and emerge with a
solution a few minutes later. So maybe your program wasn't the
most elegant display of programming virtuosity; who cares as long
as it worked?"
Sandra went on, "Well shoot yourself...I mean suit yourself,
heh, heh, a little joke there. BASIC is dumb and slow. Learn
"C" or Pascal, I did when I went to UCLA. No one teaches that
dumb stuff." Sandra was very convincing and convinced.
Backed into a corner and now defending both Latin, a dead
language and BASIC a dead programming language I asked, "Well, if
that's true, let me ask you a couple of questions. Do you use a
computer...? You do. Do you use a computer to do applications,
spreadsheets and mathematics...? You do. Do you use ANY of the
Pascal and "C" you learned to help you to doing things with these
programs. You don't..? Why?"
Sandra went on to tell me how hard it was to keep up these
great skills she learned in college and that she really didn't
have the time to program, or the interest. She freely admitted
that though she studied programming for two years, she never used
it outside of class. She glanced at the clock, at the three
people questioning Brian all at the same time and gave me a book
called "Learn BASIC Now." She said as she walked away, "BASIC,
is too dumb, it's a wimpy language. You're wasting your time,
you'll be sorry. It's really not even a HIGH language."
Apparently I bought a peasant computer language of limited
capacity for limited minds. If I wanted to be part of the
intelligentsia, I should program in "C". At least in "C" if not
in C ++ with OOP or in Pascal. So I went home, loaded the
The QBNews Page 7
Volume 2, Number 2 May 31, 1991
software and wrote my first BASIC program with Microsoft's Quick
Basic 4.5 Interpreter. The program was one line of text which
printed to the screen. Big deal, I want power and I get a batch
file look alike.
If I couldn't learn BASIC how could I learn these more
elitist and complicated computer languages? I needed some
verification and clarification. I began asking my friends about
computer programming.
Harry said, "Gosh John, I learned FORTRAN and COBOL when I
was 17, wrote flocks of programs in them, nope don't know BASIC,
it's too dumb and slow. What's that...do I ever USE FORTRAN and
COBOL? No, not in years. What good was learning it then? What
the !@#$%*!, kind of question is that!"
Harry is always a little sensitive if you imply that he
might be bragging. Harry is a card carrying elitist, he wouldn't
be caught dead using such a peasant computer language as BASIC.
Ray is different. Ray owns his own manufacturing company
and has three Phd.s', a law degree, and went to medical school
for three years. "Of course I can program in BASIC, John, don't
be silly, that's child's play. But don't get too technical, it's
been several years now, Hee Hee..., Ray chuckled.
"Well Ray, that's great, I'm having a dickens of a time, I
didn't realize that there was BASIC, BASICA, GWBASIC, PDB, and
QUICK BASIC. What do all of these names mean and which BASIC
should I learn?" I asked naively.
Ray sputtered a fine spray just as he was tasting the wine.
He ordered another bottle of Petite Sirah; and we were able to
finish dinner with that question hanging like still smoke in the
air.
So it went on, if they did program "in the higher languages"
of C, C +, Pascal they couldn't tell what and how they did the
programming.
"Well John why do you REALLY want to learn to program for,
comm' on, tell me....comm' on...tell the truth," Marvin asked.
Marvin programs in "C" and does programs in artificial
intelligence and makes jokes about "the artificial
intelligentsia."
In desperation, I asked Marvin to write me a program that
could be an all purpose tool, sort of a Swiss Army knife that
would put up menus, take direct input from the keyboard, let you
pick your colors, be user friendly, be modifiable, you know like
software should be. Marvin said that I didn't really know what I
wanted or, I wanted too much. Besides nobody programs in BASIC.
So I went home and dragged out QUICK BASIC again and tried
The QBNews Page 8
Volume 2, Number 2 May 31, 1991
halfheartedly to learn something that no one knew about from
books written by REAL "propeller heads." I read and reread the
texts trying to UNDERSTAND what the writer was driving at.
Unfortunately BASIC is mainly written by programmers who can
write code but who can't write to communicate with humans.
It was a sort of Zen, reading and not understanding. It was
a sort of chant. Reading again and again such stuff as: "DATE$
Statement sets the current date," and "DATE$ Function returns a
string containing the current date," and "FUNCTION Statement
Declares the name, parameters, and the code that form the body of
a FUNCTION procedure.[2]" Well that is as clear as Zen, and like
Zen you have to have a FEEL for the terms. As any Zen master
will tell you once you have the answer to the question, you DON'T
have the answer.
QUICK BASIC is Zen, a doing without knowing. But I
followed the instructions ---cook book style--- and a program
could be made to do something. The sound of one hand clapping
makes sense now. Trying to understand what is the meaning of the
phrase, "What is the sound of one hand clapping?" is no more
difficult than trying to understand books written by programmers.
I would have given up too, except I was given a QUICK BASIC
program that did something that I needed to have done. Pete
programs in QUICK BASIC. Pete is probably the only person I know
that REALLY programs anything for himself and he uses QUICK
BASIC. We have a mutual interest and problem with some data
collection and analysis. Pete had an answer to the problem and
he had a real program that would give an answer all written in
QUICK BASIC.
"Now Pete, I WON'T steal this program. Also, I won't sell
this program and make a million dollars on it (Well... at least
not without giving you HALF). Yes, I promise, yes that's right,
cross my heart and hope to die. And I won't give it to the
Iraqis! Now will you please...please....PLEASE give me a copy to
take home?"
After whining and pleading that I would not sell his first
born program into slavery or copyright it, he gave me a copy.
That is another Zen portion of programming, you have to earn the
knowledge yourself, no one can do it for you. Only with
programmers it's worse than Zen, they won't give you a copy of
what they know! I watched him pull up the file, run it through
his compiler and give me code that would run by its self. It was
like watching someone start a fire by using an ancient ritual, by
using a bow and a stick. It was the dawn of civilization, the
passing of knowledge, the starting of fire by friction. I was
given a real stand-alone executable program written by a real
person, Wow! After more whining he capitulated completely and
gave me the SECOND file, the QUICK BASIC code file.
I put the diskette in my shirt pocket, it was too important
The QBNews Page 9
Volume 2, Number 2 May 31, 1991
to place it anywhere's else. That night I ran it inside of my
QUICK BASIC compiler. Gadsooks! it worked! The damn thing
calculated and printed the results out lightening fast and it was
information that I could really use.
Zen, part two, you can't learn something you have no use
for. That's what Sandra, Harry, Ray and all the others were
talking about. They wrote programs in class on problems that
they were given, not on problems they wanted solutions for
themselves. That's why learning programming is like Zen, it is
meaningless unless you have some use for the knowledge (which is
both very much like and UNLIKE Zen).
Good ole Paul Somerson was right. First, you need a project
that you really...really want to do. Then use the books to look
up the procedures to do the project with. Just learning all 190
QUICK BASIC commands won't cut it. You have to use it ...or lose
it!
I went back to Egghead Software; Sandra and Brian had moved
on. Scott and Lance programmed in Pascal. I asked them if there
was anything new in QUICK BASIC that was fun. Lance gave me
Microsoft's GAMESHOP. It came with the same book that I already
had, but the software contained 6 games which could be run inside
of QUICK BASIC, the code could be examined. With much head
scratching and replaying you could actually figure out how the
programmers did what they did. Again, like Zen you must
persevere, be tested, try and fail, try and fail, knowledge
doesn't come easily. But everyone likes to play games, so it
wasn't all Zen.
That was a month ago, and though it is still slow going, I
am making progress. Pete and GAMESHOP gave me hope. I have
uploaded two programs to CompuServe as shareware. The first
program has attracted two dozen downloads in two weeks. Not
great, but a start and this is also Zen; you work and study long
for small (or no) rewards. I guess some modem users downloaded
the program because it was simple, colorful, and played a song.
Nothing grand, just a program called BIRTHDAY.ZIP that puts up
colored boxes on the screen, accepts user input, and plays "Happy
Birthday" if the computer clock reads the same day and month as
the ones you type in. If it's not your birthday, it flashes
different colors and plays "Happy Unbirthday."
Some one laughed when I played the program for them and
jokingly asked to see it display the EXACT age of anyone whose
birthday was not the day it was run. He also wanted something
that would distinguish if the person inputting the data was young
or old (over or under 21).
That was beyond my ability, but then I found, if you looked
hard enough, someone had already done some of these things in
QUICK BASIC or BASICA. I found a Julian (named after Big Julie
no less) calendar function which does just that, and added it to
The QBNews Page 10
Volume 2, Number 2 May 31, 1991
the program. After struggling to add that formula, it was easy
to figure out a "LOOP" that would change a phrase depending on
what the person's age was. Though the latter was simple math, it
had been years since I had been forced to do any thinking about
mathematics. Zen and math have a lot in common, but that is
another story.
With a program that calculated the person's exact age, every
young woman that played the program exclaimed "<Gasp>, that's
wrong I am NOT 29.078345 years old!" if that was her exact age.
I now warn women over 30 that this might be a traumatic event as
the computer will calculate their exact age, but they sail
blithely ahead, not believing that it will happen. All in all, a
lot of fun and some insight into human nature.
The second program, FOR-LISA.ZIP uses random number formulas
to generate screen colors, changes the screen to 40 characters
wide, and displays more ASCII graphics. This one plays a
Beethoven sonata and takes advantage of some great 1982 music
programming in BASICA that I found on a BBS. Again, I generated
simple mathematical formulas to do the work of many lines of
code. Another secret of programming which could only be
uncovered by doing. Zen is doing and not doing.
So, nothing sensational, but now my batch files are getting
a once over with this new knowledge. Now I realize that the
macros in Microsoft Word, WordPerfect, and the script in ProComm
Plus are written in BASIC. Now these macro formulas make sense!
There has been a mystic clarification of macros, again like Zen
what you learn affects other areas of knowledge.
I am thinking of ordering from Crescent Software[3] a QUICK
BASIC package that allows you to program mice, windows,
accounting, and databases. Now I have hope, and that also is
Zen. Yeah, nothing sensational unless you thought that BASICA
was another name for Zen and that "Real Men only program in C."
References:
(1) Somerson, Paul, PC Magazine Power Tools 2nd Edition,
Bantam Books, 1990 June;1157.
(2) Microsoft, Programming in QuickBASIC Version 4.5,
1988;270-1.
(3) Crescent Software, Inc; 32 Seventy Acres, West Redding,
Connecticut 06896; VOICE: 203-846-2500.
**********************************************************************
John Richard De Palma is a California physician who practices adult
internal-medicine. Though he is old enough to know better, he has
decided to study computers. All the conversations and facts in this
article are true. Only the names and locations have been changed to
protect the unknowing and innocent who talked to him. He can be
reached on Compuserve at 76076,571 or in care of this newsletter.
**********************************************************************
The QBNews Page 11
----------------------------------------------------------------------
S w a p S h o p
----------------------------------------------------------------------
'BARS.BAS by David Rice
' I've been working on a labor scheduling program for
' the past two years, in a manufacturing facility that
' builds an automated blood analyzer for hospitals. When an
' order is placed by a hospital for one of these units, the
' Planner must figure out if her or his manufacturing floor
' can handle the added hours in labor (Standard Hours or
' Demonstrated (actual) Hours), and if the added labor will
' be greater than what the floor can handle (Capacity
' Hours).
'
' The best and easiest way for the Planner to see this
' is by using a graph. In my scheduling program there is a
' spreadsheet to enter quantities (for each week, month,
' year, or quarter), for each assembly. A graph allows the
' Planner to see immediately where she or he has excess
' Capacity, so that assemblies may be scheduled during these
' slack periods. Ideally, Scheduled Actual Hours will meet
' Capacity, never go higher than Capacity, seldom below.
' With a graph, this is easy to see.
'
' In the sample code here, I've excluded the Capacity
' bar and just included the single data set, for simplicity.
' To be functional, the routine must be able to handle large
' numbers mixed with small ones, sizing bars in proportional
' to their original values. It must allow the programmer to
' select how much room to leave at the top of the chart for
' a title, and how much room to allow at the bottom for
' stuff like labels, comments, etc.
'
' I've used text mode and not graphics for several
' reasons. First is that almost any computer monitor will
' handle the graph. Also, if one wants to print out the
' graph, one just hits the print-screen button. Since the
' scheduling program was designed for a Novel Netware
' environment, various and vastly differing hardware may be
' used, and text mode allows the programmer to ignore the
' problem of different monitor types.
'
' So the sample code is presented here for your use.
' The method is extremely simple, works every time, and well
' tested. Since there's no point in everyone inventing the
' wheel, this code is being published in the QuickBASIC News
' letter.
'
'-------------------------- Cut Here ------------------------------
'
' BARS.BAS
' David Rice
' June 16, 1990
The QBNews Page 12
Volume 2, Number 2 May 31, 1991
'
' Define Everything As Integer For Speed
'
defint a-z
'
' Top.Row.Allowed is how high you want the
' bars to be on the screen. Bottom.Row.Allowed
' is how low you want the bars to be on the
' screen. This is to allow text to be placed
' on the screen where you wish, top or bottom.
'
How.Many.Observations = 12
Top.Row.Allowed = 1
Bottom.Row.Allowed = 25
'
' Value!() Will Hold The 12 Bar Values. 12
' Was Chosen For This Example Because It Spans
' One Year (I.e. Bars Represent Months). TOP%()
' will hold the top row on the screen to draw
' the bars.
'
Redim Value!(How.Many.Observations),Top%(How.Many.Observations)
'
' Read in from the DATA statement the sample
' values (called "Observations").
'
for a = 1 to How.Many.Observations
read value!(a)
next
'
data 132.3,532,53,123,433,86,445,335,122,134,505,234.74
'
' Some other sample values you may wish
' to draw. No matter what range the numbers
' are, the largest number will define how
' the bars will be drawn.
'
' data 10,20,30,40,50,60,70,80,90,100,110,120
' data 110,100,80,60,40,20,20,40,60,80,100,110
' data 999,1032,4343,4365,2033,2354,2335,2123,2102,325,3255,1212
'
' If you are using a direct screen writing
' utility such as QPRINT or FASTPRT, you'll
' want to convert the number into a string.
' Also, with the horizontal lines going across
' the screen, you'll not want leading or
' trailing spaces.
'
DEF FN INT.Value$(Value!)
defint a-z
'
' Round up value!
'
If Value! <= 32767 then Value! = cint(Value!)
The QBNews Page 13
Volume 2, Number 2 May 31, 1991
'
' Find how long the string will be.
'
Span% = (len(Str$(Value!)) - 1)
'
' Convert number to string, and remove
' the leading space.
'
XX$ = mid$(str$(Value!),1 - (Value! >=0))
FN INT.Value$ = xx$
END DEF
'
' To avoid dividing by zero later,
' assign the variable HIGH# a negligable
' value. This means that if you try to
' graph all observations of zero, no
' error will occur.
'
high# = 0.02
'
' Find The Highest Bar, and put it's value in HIGH#
'
for Bar = 1 to How.Many.Observations
if Value!(Bar) > high# then high# = Value!(bar)
next
'
' Define the highest bar in terms of
' screen rows. This could be a very small
' number when the values being graphed
' are large. The largest bar will span
' the screen from Top.Row.Allowed to
' Bottom.Row.Allowed, minus 1 for the
' value labels, and all other bars will
' be scaled using PERCENT# to this largest bar.
'
Percent# = ((Bottom.Row.Allowed - 1) / high#)
'
' Place horizontal lines on the screen.
' You may not want these, however. The
' next FOUR lines of code may be removed
' without causing problems elsewhere.
'
color 13,0,0
for row = Bottom.Row.Allowed to Top.Row.Allowed step -2
Locate row,2,0,0,0
print string$(78,196);
next
'
' Draw the observations. Start The Loop.
'
for Bar = 1 to How.Many.Observations
'
color 10,0,0
'
The QBNews Page 14
Volume 2, Number 2 May 31, 1991
' Define each value as a subset of the
' largest.
'
XX% = (Value!(Bar) * percent#)
'
' Convert to screen row value.
'
Top%(Bar) = Bottom.Row.Allowed - (xx - Top.Row.Allowed)
'
' Calculate the column on the screen.
'
col = (6 + (Bar - 1) * 6)
'
' Start at the highest row of the bar and
' fill down to the lowest row allowed.
'
for row = top%(Bar) to Bottom.Row.Allowed
'
' If the value is so small compared to the
' largest, it may be too small to draw on the
' screen. This much be checked for.
'
if row > 1 then
Locate row,col,0,0,0
'
' Print the bar. The characters may be changed
' of course to fit your particular needs. I've
' included some "commented-out" samples of
' different characters: to try them, put a
' squote in front of the first line, and remove
' the squote from the line you'd like to try.
'
print string$(4,219);
'print string$(4,178);
'print string$(4,176);
'
end if
next
'
' If you do not want the values printed at
' the top of the bar, remove the next FIVE
' executable lines that follow.
'
' Find the row to place the number.
'
Row = (Top%(Bar) - 1)
'
' If the bar is so small that the number
' would be placed lower than the bottom row
' allowed, place it on the bottom row allowed.
'
if Row > Bottom.Row.Allowed then row = Bottom.Row.Allowed
'
color 12,0,0
The QBNews Page 15
Volume 2, Number 2 May 31, 1991
Locate Row,Col,0,0,0
print FN INT.Value$(Value!(Bar));
next
'
' Pause for any key press. We're done!
'
while inkey$ = ""
wend
----------------------------------------------------------------------
'PIES.BAS by David Rice
' Make all numeric variables INTEGERS
'
defint a-z
'
' Random tile pattern function.
'
DEF FN Tile$
DefInt a-z
ti$ = ""
char = 0
Randomize timer
'
while char < 1
Randomize timer
char = ((8 * rnd) + 1)
wend
'
for a = 1 to char
Randomize timer
b = int((255 - 32 + 1) * RND + 32)
ti$ = ti$ + chr$(b)
next
fn tile$ = ti$
END DEF
'
' For reasons of demonstration, the number
' of observations (slices) in the pie chart
' have been randomized to a number from 2 to
' 12. The maximum number of slices has been
' set to 12, but if you can do without the
' legends that are placed on the left of the
' screen, you could make room for more slices.
'
start.here:
Observations% = (rnd * 12) + 1
if Observations% > 12 then Observations% = 12
if Observations% = 1 then Observations% = 2
'
' Set aside room for the arrays we need.
'
Redim Wedge!(Observations%),Degrees!(Observations%)
Redim Angle!(Observations%),tile$(Observations%)
Redim x%(Observations%),y%(Observations%)
Redim Diff!(Observations%)
'
The QBNews Page 16
Volume 2, Number 2 May 31, 1991
' Go to EGA mode, clear the screen, and
' set the background color to blue (attribute
' of 1). Attribute 15 looks good, too.
'
screen 8
cls
paint (3,3),1
'
' Get random tile patterns for all observations.
'
for tile% = 1 to Observations%
tile$(tile%) = fn tile$
next
'
' Find the total value for all observations.
' For this demonstration, these values have been
' randomized.
'
Total! = 0
for a = 1 to Observations%
'
Wedge!(a) = (777 * RND)
'
If Wedge!(a) < 1 then Wedge!(a) = 1
Total! = Total! + Wedge!(a)
next
'
' Scale everything down to a percent of a
' circle (360 degrees). Also draw the circle.
'
Pie.Attr% = 14
Perc! = (total! / 360)
circle (400,100),205,Pie.Attr%
'
' Calculate the direction to turn the line,
' from a starting direction of zero (straight
' up).
'
Direction! = 0
'
' For every observation calculate how many
' degrees of the circle the slice will cover,
' then the direction to turn.
'
for a = 1 to Observations%
Degrees!(a) = (Wedge!(a) / Perc!)
Direction! = Direction! + Degrees!(a)
'
' Move to the center of the pie, without
' drawing a line.
'
Draw "BM400,100"
'
' Turn the angle and then store this angle
The QBNews Page 17
Volume 2, Number 2 May 31, 1991
' for use later.
'
Draw "TA=" + Varptr$(Direction!)
Angle!(a) = Direction!
'
' Draw the slice.
'
Draw "U86"
next
'
' In order to fill the slice with a tile,
' we need to know the center of the slice.
' If we tried to PAINT outside the slice,
' we would get undesirable results, such as
' a screen full of trash.
'
' Calculate for every observation.
'
for a = 1 to Observations%
'
' If this iteration is the first, we
' start from zero, take the angle the slice
' was drawn, and find the middle between
' the two.
'
If A = 1 then
half! = (Angle!(1) / 2)
Diff!(1) = Half!
else
'
' For all other iterations, look for the
' distance between this slice and the previous
' one.
'
Half! = (ABS(Angle!(a) - Angle!(a - 1)) / 2) + Angle!(a - 1)
Diff!(a) = (ABS(Angle!(a) - Angle!(a - 1)) / 2)
end if
'
' Throw out a circle if there's more than one.
'
If Half! > 359.9999! then half! = half! - 360
'
' Go to the center of the pie, but do not draw
' any line.
'
Draw "BM400,100"
'
' Make our new course heading good.
'
Draw "TA=" + Varptr$(half!)
'
' Move but DO NOT DRAW up to a point
' almost but not quite to the circle's
' boundry.
The QBNews Page 18
Volume 2, Number 2 May 31, 1991
'
Draw "BU83"
'
' Store this position, then calculate
' the same for all the other observations.
'
x(a) = Point(0)
y(a) = Point(1)
next
'
for a = 1 to Observations%
'
' If the slice is too small to paint,
' do not do so. Otherwise, paint it with
' the proper tile.
'
If Diff!(a) > .5! then paint (X(a),Y(a)),tile$(a),Pie.Attr%
'
' Calculate the legend bubble position ROW.
'
Y = 10 + (A - 1) * 16
'
' Draw bubble and PAINT it with the same tile.
'
circle (80,y),16,Pie.Attr%
Paint (80,y),tile$(a),Pie.Attr%
'
' Calculate the percentage of the whole this
' slice is.
'
percent# = (wedge!(a) / total!) * 100
next
'
call get.1.chr(ii$)
'
' Like a tile pattern? Hit ALT/P
' and it will be saved in as a file.
'
If II$ = chr$(0) + chr$(25) then
Open "Tile.Asc" for output as #1
for a = 1 to observations%
'
print #1, using "Tile.Pattern$(\\) = ";mid$(str$(a),1 - (a >=0));
'
Size% = len(Tile$(a))
for b = 1 to (size% - 1)
print #1, using "CHR$(###) + ";asc(mid$(tile$(a),b,1));
next
print #1, using "CHR$(###)";asc(mid$(tile$(a),size%,1))
next
close
call get.1.chr(ii$)
end if
'
The QBNews Page 19
Volume 2, Number 2 May 31, 1991
if ii$ <> chr$(27) then goto start.here:
'
sub get.1.chr(i$) static
defint a-z
i$ = ""
while i$ = ""
i$ = inkey$
wend
end sub
----------------------------------------------------------------------
'DIR.BAS by Dave Cleary
'
'One of the most useful additions to BASIC 7 PDS is the DIR$ function.
'This function allows you to read a directory of filenames. It also
'allows you to check the existence of a file by doing the following:
'
' IF LEN(DIR$("COMMAND.COM")) THEN
' PRINT "File Found"
' ELSE
' PRINT "File not found"
' END IF
'
'Now QuickBASIC 4.X users can have this useful function for their
'programs.
'
'Calling DIR$ with a FileSpec$ returns the the name of the FIRST
'matching file name. Subsequent calls with a null FileSpec$ return the
'NEXT matching file name. If a null string is returned, then no more
'matching files were found. FileSpec$ can contain both a drive and a
'path plus DOS wildcards. Special care should be taken when using
'this on floppy drives because there is no check to see if the drive
'is ready.
DEFINT A-Z
DECLARE FUNCTION DIR$ (FileSpec$)
'$INCLUDE: 'QB.BI'
'----- Some constants that DIR$ uses
CONST DOS = &H21
CONST SetDTA = &H1A00, FindFirst = &H4E00, FindNext = &H4F00
'--------------------------------------------------------------------
'This shows how to call DIR$ to find all matching files
'CLS
'FileSpec$ = "C:\QB\SOURCE\*.BAS"
'Found$ = DIR$(FileSpec$)
'DO WHILE LEN(Found$)
' PRINT Found$
' Found$ = DIR$("")
'LOOP
'--------------------------------------------------------------------
The QBNews Page 20
Volume 2, Number 2 May 31, 1991
FUNCTION DIR$ (FileSpec$) STATIC
DIM DTA AS STRING * 44, Regs AS RegTypeX
Null$ = CHR$(0)
'----- Set up our own DTA so we don't destroy COMMAND$
Regs.AX = SetDTA 'Set DTA function
Regs.DX = VARPTR(DTA) 'DS:DX points to our DTA
Regs.DS = -1 'Use current value for DS
InterruptX DOS, Regs, Regs 'Do the interrupt
'----- Check to see if this is First or Next
IF LEN(FileSpec$) THEN 'FileSpec$ isn't null, so
'FindFirst
FileSpecZ$ = FileSpec$ + Null$ 'Make FileSpec$ into an ASCIIZ
'string
Regs.AX = FindFirst 'Perform a FindFirst
Regs.CX = 0 'Only look for normal files
Regs.DX = SADD(FileSpecZ$) 'DS:DX points to ASCIIZ file
Regs.DS = -1 'Use current DS
ELSE 'We have a null FileSpec$,
Regs.AX = FindNext 'so FindNext
END IF
InterruptX DOS, Regs, Regs 'Do the interrupt
'----- Return file name or null
IF Regs.Flags AND 1 THEN 'No files found
DIR$ = "" 'Return null string
ELSE
Null = INSTR(31, DTA, Null$) 'Get the filename found
DIR$ = MID$(DTA, 31, Null - 30) 'It's an ASCIIZ string starting
END IF 'at offset 30 of the DTA
END FUNCTION
The QBNews Page 21
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
T h e T o o l S h e d
----------------------------------------------------------------------
A Look at Crescent Software's PDQComm by Jim Harre
Product Review - PDQComm 2.50
Source: Crescent Software
32 Seventy Acres
West Redding, CT 06896
(203) 438-5300
Price: $99.00
PDQComm 2.50 is a communications add-on library written by Dave
Cleary (your illustrious QBNews publisher) and marketed by Crescent
Software. Strangely enough, PDQComm does work with PDQ -- as well as
QuickBasic 4.x and BPDS 7.x. Since PDQ doesn't provide access to the
communications ports as QB does, an add-on package is necessary for
serial work. PDQComm provides this feature.
PDQComm provides you with over 50 low and high level routines. A
number of the procedures have been lifted from Crescent's QuickPak
Pro and PDQ packages. The routines are small and speedy. In short,
it is a complete serial port programmmer's toolkit.
The documentation is absolutely first rate. Those of you upgrading
from version 2.0 are in for a very pleasant surprise. Besides the
usual excellent routine descriptions, a brief communications
tutorial (including a short section on the infamous baud vs. bps
controversy), connector pinouts, UART descriptions and register
info, and a brief summary of 'Standard' Hayes commands and S
registers are included at the end of the manual. If your desk looks
like mine, it's nice to have just ONE reference with just about
everything you need.
Crescent has switched from the old, thin, 'blah' beige covers to
attractively printed heavy card stock covers. This should help keep
your manuals from being floppier than your disks. The only drawback
to the manual (and this is a minor nit) is that they have changed
the binding from a plastic spine to one of those metal double spiral
bindings that get bent up easily and bind up the pages. At least,
you could stick a small label on the old spines - these new ones
don't work well for labeling.
Unlike some add-on libraries, PDQComm provides .QLB and .LIB files
for both QB and BPDS in one package. The source code is provided as
with all Crescent Products. A number of demonstration programs are
provided to acquaint you with using the routines, including a TSR
comm program.
Several new features are added in version 2.50 -
<> Two comm ports can be open simultaneously.
<> Ports with non-standard addresses or IRQs can be opened.
<> A function to determine the UART type has been added.
The QBNews Page 22
Volume 2, Number 2 May 31, 1991
<> You can enable/disable the FIFO buffer in 16550 UARTS.
<> You can adjust the receive buffer size 'on the fly'.
<> Grab status of CTS, DSR, RI, and DCD as a TYPE variable.
<> The timeout delay is adjustable in seconds when sending data.
<> Several routines from PDQ are now included.
QuickBasic and the Basic Professional Development System
(otherwise known as BPDS) already have communications support built
in -- so why would anyone buy an add-on package to do something that
Basic already does? For the same reasons you purchased QB or BPDS when
Basica or GW-Basic was included with your DOS -- functionality and
flexibility. One of the great failings of the routines furnished
with QB is that you need to use ON ERROR to trap errors. This
results in larger, slower code -- exactly what you don't need when
working with communications. QB also has a VERY nasty habit of
dropping Data Terminal Ready when you exit a program. If you are
writing a series of programs to be executed, this is usually deadly
to your modem connection since most modems will go onhook when you
lower DTR.
Over the last couple years that I've carried the QUIK_BAS echo on
my system, there has been a continuing discussion on the merits of
using a prewritten library of routines versus writing your own. It's
no secret that I often use and advocate third party libraries. For
me, the reason is simple - time is money. When you write code for a
living, your production rate tends to directly affect your wages at
salary review time. A hundred bucks for a comm package is a drop in
the bucket compared to how long it would take me to develop (and
especially debug) a similiar set of routines in assembly language.
In a commercial setting and especially a production environment,
downtime due to program 'quirks' is measured in thousands of
dollars. Things must be solid the first time out - there isn't much
time for playing around with it until you get it right. Over the
last year in production programs, PDQComm has proved to be extremely
stable and bug free.
Much of my work with PDQComm has been to build TSR "device drivers"
to communicate with digital scale indicators. Every one of these
rascals tends to work differently, while the main application
program needs to remain the same for the user. To avoid maintaining
a dozen similiar but different programs, the main program simply
issues an interrupt call and receives a numeric string from the
scale.
Before the program is launched, a small (8-9K) TSR driver is loaded
that handles the grunt work of maintaining a conversation with the
scale and responding to requests from the main program for
information. This TSR is compiled using PDQ and PDQComm. Each
different device has it's own driver that handles the peculiarities
of that scale and has a common output format. By having the driver
take over and handle an unused interrupt, all the main program needs
to know is that when it calls INT 61H, the scale data magically
appears - no matter what scale is attached. Because PDQComm can
create compact code and PDQ can create TSR's, what would have been a
The QBNews Page 23
Volume 2, Number 2 May 31, 1991
real drudge with ASM is now almost easy - in BASIC.
To give you an idea what programming with PDQComm feels like,
here's a small program and comments (lifted directly from the PDQComm
manual):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Besides using a syntax as close to BASIC's as possible, PDQComm
also returns error information in the BASIC ERR function. This
lets you easily test the success or failure of the most recent
operations, without requiring ON ERROR. Unlike other communi-
cations libraries you may have seen, PDQComm uses the minimum
number of parameters possible. This greatly reduces the size of
your programs, and also improves their speed.
DEFINT A-Z 'all integers please
DECLARE SUB OpenCom (Action$) 'same as OPEN "COM..."
DECLARE SUB ComPrint (Work$) 'same as PRINT #n,
DECLARE SUB CloseCom () 'same as CLOSE #n
DECLARE FUNCTION BIOSInkey% () 'similiar toASC(INKEY$)
DECLARE FUNCTION ComEof% () 'same as EOF(n)
DECLARE FUNCTION ComInput$(NumChars) 'same as INPUT$(n,#n)
CALL OpenCom("COM1:2400,N,8,1,RB512,XON") 'open the port
IF ERR THEN 'oops
PRINT "Error opening the communications port."
END
END IF
DO
Char = BIOSInkey% 'get what was typed
IF Char = 27 THEN EXIT DO 'exit if it was Escape
IF Char THEN CALL ComPrint(CHR$(Char)) 'anything else, send it
IF NOT(ComEof%) THEN 'was anything received?
ComString$ = ComInput$(ComLoc%) 'yes, get the characters
PRINT ComString$; 'print them on the screen
END IF
LOOP 'loop forever
CALL CloseCom 'close the port and end
Here, the OpenCom routine is called specifying communications
port 1 at a baud rate of 2400, no parity, 8 data bits, and 1 stop
bit. RB512 specifies a receive buffer size of 512 bytes, and XON
indicates that XON/XOFF handshaking is to be performed automat-
ically. We will discuss handshaking as well as selecting an
appropriate buffer size in a moment.
Once the communications port has been opened, an "endless" loop
is entered that alternately checks for keyboard activity and
characters being received. If a character has been entered at the
keyboard it is sent through the port (unless it was the Escape
key). And if any characters have been received and are waiting to
The QBNews Page 24
Volume 2, Number 2 May 31, 1991
be read, the ComInput$ function reads all of them from the receive
buffer.
The ComEof% function is used to determine if any characters are
waiting in the buffer. ComLoc% reports how many, and ComInput$
does the actual reading. Notice that these functions are identical
to the equivalent BASIC functions EOF(), LOC(), and INPUT$
respectively.
The BIOSInkey function is much more efficient than the regular
QuickBASIC INKEY$, because it returns the integer ASCII value
of the key that was pressed. This requires less code in the BASIC
program, since integer assignments and comparisons are simpler
than the equivalent string operations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As you can see, using PDQComm isn't too much different from
standard QB or BPDS. Of course, this simple terminal program doesn't
show off all the features of the library. You can set the amount of
time to wait to transmit using ComPrint$. If you'd rather use RTS/CTS
hardware handshaking instead of software XON/XOFF, it's available.
If you want to run another program after closing the comm port but
not drop the line, a routine called SetMCRExit allows you to select
what happens to the state of the DTR and RTS lines when the port
closes. PDQComm has low-level routines to handle just about any task
you can imagine with the serial ports of your PC.
What about high-level stuff? Crescent packages are famous for
throwing in a number of BASIC routines that not only illustrate the
usage of the low-level routines, but provide you with easy to use
building blocks for your own programs. Several terminal programs are
provided including one that runs as a TSR. For those of you who need
to transfer files, there are routines for transferring an ASCII file
(somewhat useless, in my opinion) and a set of XMODEM routines for
both checksum and CRC (far more useful).
If you need to talk to a terminal, terminal emulation routines are
provided for TTY, ANSI (PC), VT52 & VT100 (Digital Equipment), and
D215 (Data General). Routines are provided to define multiple
windows on the screen - each running a different emulation if you
wish.
If you are looking for source code to a basic, high performance
term program that you can customize to your heart's content, PDQComm
furnishes you with enough tools and toys to keep you busy for
months. The AnsiTerm program included works rather nicely as an
example of what you can do with the package; it shows off both ANSI
emulation and XMODEM file transfers. It also demonstrates the use of
the XStat routine, a pop-up status window for tracking XMODEM
transfers.
Technical Support is something that Crescent does well. While
digging through this package, I ran into a problem running one of
The QBNews Page 25
Volume 2, Number 2 May 31, 1991
the demo programs (DemoAnsi). A call to Crescent solved the problem
with a minimum of fuss. If I'd really read the documentation instead
of skimming it, I'd have found the problem. Instead of reminding me
what a dummy I was for not fully reading the manual, the person on
the other end of the phone (Nash) kindly led me through uncommenting
some lines of code to make things work. Microsoft could learn a few
things about customer service from these people. (I wish they
would!)
Nothing in this world (especially in programming) is perfect, but
PDQComm has few flaws. For those planning to write their own BBS, it
would be nice to see more file transfer routines though it can be
easily argued that external programs (like DSZ) can be used to
provide that service. Other than that, and my earlier nit-picking
about the binding, there's not much to complain about.
To sum up, PDQComm is an excellent communications package for BASIC
programmers. It has a well written manual, plenty of examples that
will interest the novice, and plenty of routines to satisfy the more
advanced programmer. Tech support is very good and the routines work
as advertised. The package continues to be improved and Crescent has
already announced that they will be selling a version of PDQComm for
the new Visual Basic. Overall, if you are looking for a competent
communications package, this is money well spent.
**********************************************************************
Jim Harre is an avid QuickBASIC programmer from St. Louis. He also
runs a BBS that has been in operation since it ran on a TSR-80. You
can call his BBS at 314-843-0001 or write to him in care of this
newsletter.
**********************************************************************
The QBNews Page 26
Volume 2, Number 2 May 31, 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
----------------------------------------------------------------------
Working with the Rodent by Daniel R. Berry
The Rodent (mouse) is one of the easiest input devices for computer
users to adapt to. It allows great flexibility for entering data,
moving around screens and using menus. Over the last few years the
Rodent has truly found a home with computer users. This leads you to
wonder why new programs enter the market without mouse interfaces.
Probably the most common reason for this oversight is the Rodent
intimidates programmers. The pesky little critter isn't the easiest
user interface to program for. Yet, adding a mouse interface to your
programs is easier than most think.
The mouse functions operate through a device driver such as
MOUSE.SYS or MOUSE.COM provided with most MS-DOS compatible rodent
species. This driver ties itself to interrupt 33H allowing the
programmer direct accessed to the mouse functions. Several programmer
references document this interrupt and its functions detailing the
features and complexities of the mouse driver. Over the last few
years I have played around with mouse interfaces and have finally
developed a set of routines that allow me to add a mouse interface to
any QuickBASIC program I write. The routines provide access to most
of the mouse functions and they aren't that hard to use.
To use these routines in your program you must use the following
statement at the beginning of your program:
COMMON SHARED /Mouse/ MouseChk%, MouseStat%
(This statement is provided in the MOUSE.BI file.)
The routines use these variables to track the following:
MouseChk% indicates the availability of an active mouse driver
and the status of these routines (1=Enabled / 0=Disabled).
MouseStat% shows the status of the mouse cursor or pointer
(1=On / 0=Off).
Mouse is the heart of the mouse utilities. It provides access to
interrupt 33h using INTERRUPT provided in the QB.QLB. Almost all the
other mouse routines call Mouse to complete their functions.
Usage: CALL Mouse (M1%, M2%, M3%, M4%)
M1 - M4 are the system registers AX - DX respectively.
MouseCheck is the second most important of these routines.
MouseCheck can determine mouse driver availability; enable the mouse
driver; or disable the mouse driver. This routine must be called at
the beginning of your program if you want to use the mouse.
The QBNews Page 27
Volume 2, Number 2 May 31, 1991
MouseChk updates MouseChk% and MouseStat% as applicable. You
should note that when the mouse driver is installed the mouse cursor
is set to off.
Usage: CALL MouseCheck (MFlag%)
MFlag% = If set to -1 the mouse will be installed, if
available (if not already done so). If set to -2 the mouse
routines will be disabled. Any other value will cause this routine
to determine if the mouse has been installed. A returned value of
1 indicates that the mouse driver is installed, 0 indicates that
the mouse driver has not been installed or is disabled.
MouseCRT will determine or set the mouse video display page. This
is useful when your programs use multiple display pages.
Usage: CALL MouseCRT(CRT%, Flag%)
The video display page is determined or set by using the CRT%
variable. Flag% is used to toggle 0=set/1=determine.
MouseInformation provides specific information for the Rodent used
by the system. This routine provides the mouse driver software
version and mouse type.
Usage: Call MouseInformation(MouseVer$, MouseType%,
MouseType$)
MouseVer$ is the current mouse driver version.
MouseType% and MouseType$ represent the following:
1 - Bus Mouse 2 - Serial Mouse 3 - InPort Mouse
4 - PS/2 Mouse 5 - HP Mouse
MouseLeft determines the position of the mouse at the last left
button depression. Also determines the number of depressions of the
left button since this routine was last called. Position is returned
in screen pixels.
Usage: CALL MouseLeft (LCount%, MouseX%, MouseY%)
LCount% = The number of left button depressions since the
routine was last called.
MouseLeftRC functions the same as MouseLeft except position is
determined by screen row and column.
Usage: CALL MouseLeftRC (LCount%, MRow%, MCol%)
MouseLightPen will enable (1) or disable (0) mouse light pen
emulation mode. Calls to the Basic PEN function return the last pen
down location. Pen down is set when both buttons are depressed.
The QBNews Page 28
Volume 2, Number 2 May 31, 1991
Usage: CALL MouseLightPen (Status%)
MouseLimits will set the mouse limits restricting movement to a
specific area. Limits are set using screen pixels.
Usage: CALL MouseLimits(MouseX1%, MouseY1%, MouseX2%,
MouseY2%)
MouseX1/Y1% = Upper left corner horizontal/vertical (X/Y)
position.
MouseX2/Y2% = Lower right corner horizontal/vertical (X/Y)
position.
MouseLimitsRC functions the same as MouseLimits except the limits
are determined by screen row and column.
Usage: CALL MouseLimitsRC(MRow1%, MCol1%, MRow2%, MCol2%)
MRow1%/MCol1% = Upper left corner row/column limit.
MRow2%/MCol2% = Lower right corner row/column limit.
MouseLocate locates the mouse cursor at a specified X and Y
coordinate. Coordinates are set in screen pixels.
Usage: CALL MouseLocate(MouseX%, MouseY%)
MouseLocateRC functions the same as MouseLocate except coordinates
are set at specified row and column.
Usage: CALL MouseLocateRC(MRow%, MCol%)
MouseMotion returns the horizontal and vertical mouse motion
counters. Motion counts are in 1/200 inch increments.
Usage: CALL MouseMotion(Horz%, Vert%)
Horz% = Horizontal motion counter value (positive = right
motion / negative = left motion).
Vert% = Vertical motion counter value (positive = downward
motion / negative = upward motion).
MouseOn / MouseOFF turns the mouse cursor on/off as desired. These
functions use MouseStat% to determine the status of the cursor and
take action only when needed. This check is used to prevent the
internal cursor flag from being modified unnecessarily.
Usage: CALL MouseOn / MouseOff
MouseRelease returns the position of the mouse after the button
requested was last released. Position is returned in screen pixels.
The QBNews Page 29
Volume 2, Number 2 May 31, 1991
Usage: CALL MouseRelease(Button%, Count%, MouseX%, MouseY%)
Button% = The button to be checked (0 = left / 1=right).
Count% = The number of button releases since the last call to
this routine.
MouseReset resets the mouse driver to the default values and
updates MouseStat%.
Mouse Position: Screen Center Mouse Cursor: Off
Light Pen Emulation: On CRT Page Number: 0
Usage: CALL MouseReset
MouseRight determines the position of the mouse at the last right
button depression. Also determines the number of depression of the
right button since this routine was last called. Position is returned
in screen pixels.
Usage: CALL MouseRight(RCount%, MouseX%, MouseY%)
MouseRightRC functions the same as MouseRight except position is
determined by screen row and column.
Usage: CALL MouseRightRC (RCount%, Row%, Col%)
MouseSensitivity enables programmers to determine or modify mouse
sensitivity to better suit their needs. Horizontal and vertical
movement are defined in mickeys. One mickey equals 1/200-inch of
mouse travel. Mickeys range from 1 to 32,767 (horizontal default is 8
and vertical default is 16). Doublespeed sets threshold for doubling
mouse cursor movement (default 64 mickeys/second).
Usage: CALL MouseSensitivity(GetSet%, HMickey%, VMickey%,
DoubleSpeed%)
GetSet% is used to toggle 0 = Get / 1 = Set.
MouseStatus determines Mouse Status to include position and buttons
currently depressed. Position is returned in screen pixels.
Usage: CALL MouseStatus(Left%, Right%, MouseX%, MouseY%)
Left% = If returned as 1 then the left button is depressed.
Right% = If returned as 1 then the right button is depressed.
MouseStatusRC functions the same as MouseStatus except position is
returned by screen row and column.
Usage: CALL MouseStatusRC(Left%, Right%, MRow%, MCol%)
RODENT.BAS provides a demonstration of these routines and designed
The QBNews Page 30
Volume 2, Number 2 May 31, 1991
to give you a general idea of how the mouse interface works. If your
rodent is having a problem working with these routines read your users
manual to ensure that you have MS Mouse emulation active.
Well, that's about it. I have included a few support routines from
my library to give RODENT.BAS some flair and the *.BIT routines are
needed by MOUSE.MOU to work with some of the bits returned in the
system registers. You have everything you need to get that pesky
rodent to work so why not put that $50 - $90 toy to some use and
program!
Please feel free to write. I am open to comments, suggestions and
will even answer a question or two. Complaints are received only on
Friday, must be in triplicate (no carbons please), must be signed by
your mother, and be accompanied by a personal check for $200.00.
(Laugh - my wife did!)
[EDITOR'S NOTE]
All source code for this article is contained in RODENT.ZIP.
**********************************************************************
Daniel Berry is a member of the U.S. Air Force. Off-duty he
writes a utility library for QuickBASIC. Daniel may can be reached
at 3110-C South General McMullen, San Antonio, TX 78226.
**********************************************************************
The QBNews Page 31
Volume 2, Number 2 May 31, 1991
A Graphics Mouse Cursor Design System by Dr. Warren G. Lieuallen
MOUSCURS.BAS will allow you to draw your own graphics cursor
design without having to worry about all those crazy hex numbers,
and what to do with them! You'll simply draw your cursor shape
on the screen, and then save the data. A complete, stand-alone
QuickBASIC program will be created which will simply define your
cursor and turn it on. The purpose of this is for you to then
add the rest of your program; MOUSCURS will have taken care of
the nitty-gritty of your custom mouse cursor. For the more
adventurous of you, you can also save only the DATA statements,
and then do with them what you will.
MOUSCURS.BAS was designed and tested on a Hercules
monochrome system, and checked on a VGA system. It should work
with any graphics system, but I've not used it with CGA or EGA.
If you have trouble, feel free to fiddle with the code yourself.
To use MOUSCURS.BAS, you must load QuickBASIC with CALL
Interrupt support. The easiest way to do this is to load the
QB.QLB quick library by entering "QB /L QB" to run QuickBASIC.
You'll also need CALL Interrupt support for your program which
uses MOUSCURS to define the cursor. My recommendation is to add
the CALL Interrupt routine to your own custom quick library;
that's what I did!
Once you run MOUSCURS, you'll seen the main (and only!)
screen. You can now use your mouse to draw a shape. Move around
the "cursor mask" screen; pressing the LEFT button will toggle
the individual pixels on and off. Once your shape is defined
(you'll see a true-size representation of the cursor in the
"Custom Cursor" window), you'll then need to work on the screen
mask. The easiest way to do this is to click on the "Expand".
This will copy your cursor to the screen mask window, and draw a
border around it automatically. You can then edit it to
perfection; watch the "Custom Cursor" window to see what the
cursor looks like on a "normal" and "inverse" screen.
Before you finish, you must also define a "hot spot". This
is the single pixel which defines the cursor's location (e.g. the
spot that must be inside the button you're clicking on). To
select a "hot spot" click the RIGHT button in the cursor mask
window. The hot spot will be indicated by an "X". However, by
clicking in the same spot, you can define an "invisible" hot
spot, which will be defined by a "0". The best way to learn how
the RIGHT button works is to just play with it, and watch the
"Custom Cursor" window to see if the spot is turned on or off.
Also, remember to use the RIGHT button for the hot spot, and the
LEFT button for everything else.
At any time, you can also clear either of the windows by
clicking on the "Clear" buttons. You can also copy the cursor
mask to the screen mask by clicking on the "Copy" button.
The QBNews Page 32
Volume 2, Number 2 May 31, 1991
Finally, as a test of your new cursor, you can click on the
"Activate" button to replace the cursor with your own design. Be
sure you have something defined before you do this, or you'll
lose the cursor, and won't be able to see what you're doing! You
can turn your cursor back off and return to the hand by clicking
on the "DeActivate" button.
Once your cursor is finished, you can save it by clicking on
either the "Save Data" or "Save Program" buttons. "Save Data"
does just what it says; it will save only the DATA statements
needed to define your custom cursor. "Save Program" will create
a stand-alone program that will define your cursor and turn it on
(in fact, you can run this program just to see what your cursor
looks like once you're done). Both of these options create a
file called CURSORn, with "n" being a sequential number; you will
not overwrite existing cursor files (old files must be deleted
manually). Data is saved with a .BI extension; programs are
saved with the standard .BAS extension. You can, of course,
rename any of these files after you've created them via DOS.
Finally, if you've already created some cursors, you can
edit them by using the "Load Cursor" button. You'll be asked to
provide the filename and extension; the data will then be loaded
and the cursor displayed just as you had drawn it.
Feel free to examine the code of MOUSCURS.BAS. It was
written primarily as an learning exercise; there are undoubtedly
other (and probably better!) ways to accomplish the same task.
MOUSCURS.BAS was my first (and so far, only) graphic program, so
please bear with me. For more details on programming mouse
functions in QuickBASIC, refer to the QB News (volume 2,
number 2).
[EDITOR'S NOTE]
The code for this article can be found in MOUSECUR.ZIP. This program
will not work in the QBX environment or with far strings. This
program also requires the DIR$ function contained in the SwapShop
section of this newsletter.
The QBNews Page 33
----------------------------------------------------------------------
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
----------------------------------------------------------------------
Fast Screen Printing by Christy Gemmel
[EDITOR'S NOTE]
All code for this article may be found in FASTPRNT.ZIP. This article
also refers to figures which included in FIGURES.TXT which is in
FASTPRNT.ZIP.
This article presents a rapid method of displaying a string of ASCII
characters on the screen without updating the cursor position. The
calling program should pass the string, the row/column co-ordinates of
the screen location where it is to be printed and the number of the
colour or display attribute required.
Many routines in my Assembly-Language Toolbox are concerned with the
video display, this being the primary means through which we
communicate with the users of our program. Later, when we get around
to developing such things as Popup Windows and Dialogue Boxes, we will
need to acquire some pretty sophisticated screen-handling techniques.
For now, however, let us look at the more mundane task of displaying
text on the screen.
For most applications the QuickBASIC PRINT statement is perfectly
adequate. Because it is a general-purpose statement, however, which
can be used to direct output to the printer or a file as well as to
the screen, PRINT is not as fast as it might be. Moreover, to display
a string of characters at a specific place on the screen you must
first position the cursor with a LOCATE statement. Then, if you want
to display the string in a different colour than the background text,
you must issue a preliminary COLOR statement before printing. What we
need is a screen-specific display routine that combines these three
statements into one. Naturally, since we are going to the trouble of
writing it in Assembly-Language, we expect it to be as fast as
possible.
Let us, then, set out our objectives for FastPrint:
1) The ROW/COLUMN location where the string is to be printed is
specified to the routine, so that there is no need for a seperate
LOCATE statement to position the cursor.
2) You must be able to place the string anywhere on the display,
including the bottom line of the screen, no matter what VIEW
PRINT parameters may be in effect.
3) Output to the bottom line of the display should not cause the
screen to scroll.
4) You should be able to specify the colour and/or display attribute
of the text to be printed, so there is no need for a seperate
COLOR statement. Furthermore the attribute specified should appy
The QBNews Page 34
Volume 2, Number 2 May 31, 1991
only to the text being printed, it must not effect the colour of
any subsequent PRINT statements.
5) To obtain maximum performance, FastPrint should write directly to
video display memory. This will be particularly useful when we
need to output large blocks of text.
This last clause needs some explanation. In general, there are two
methods of outputting text to the screen. The first makes calls to the
video services built into the PC's ROM-BIOS and can, consequently, be
used by any computer that is BIOS-compatible with the IBM family of
personal computers. This method, however, is considered to be a little
slow by today's standards.
The alternative technique bypasses ROM-BIOS completely and writes
directly to the video display buffer. Since the display, in most PCs,
is mapped by the video hardware to a fixed location in memory, any
characters that are written to this area will immediately appear on
the screen. This is the fastest method of all, but has the
disadvantage that it will only work on computers that are hardware-
compatible with the original IBM PC. However, since this includes all
modern XT, AT and PS/2 class machines, it is not unduly restrictive,
but it does eliminate some older models like the Tandy 2000.
We will adopt the second method. It is, after all, the one used by 90%
of today's software and has become something of a de facto standard in
its' own right. This is the only way we can achieve some real
performance in our programs.
The bulk of the work is done by a short assembly-language procedure
that is designed to be called from QuickBASIC. It can be part of a
Quick Library for use in the programming environment or assembled into
a single module that can be linked to stand-alone programs compiled
with BC's /O switch. I will show you both methods later.
Although short, FASTPRINT illustrates some important features of
mixed-language programming that I will discuss in some detail. It was
written for MicroSoft's Macro Assembler (MASM) version 5.1 and makes
use of the simplified segment directives that are a feature of that
assembler. This lets us define the Memory Model of the routine to
match that of the calling program.
.model medium
All QuickBASIC programs use the MEDIUM memory model, which means that
all simple data fits within a single 64K segment, although the program
code may be greater than 64K. When we enter the routine, therefore,
the DS (Data Segment) register is already pointing to the segment
containing the string of characters we will be printing and we can use
near pointers, offset from DS, to address this string. The main
procedure, however, must be declared FAR so that the Code Segment (CS)
register is set correctly when it is called. FastPrint is the name you
will be using when you call this routine from your program, declare it
PUBLIC so that QuickBASIC can find it.
The QBNews Page 35
Volume 2, Number 2 May 31, 1991
public FastPrint
Now for the routine itself, here are the first few lines:
.code
FastPrint proc far
push bp ; Save Base pointer
mov bp,sp ; Establish stack frame
push es ; Save Extra Segment
push si ; and index pointers
push di
Remember that QuickBASIC uses the Medium Memory model. This means that
we can't assume our assembled routine will be linked into the same
code segment as the main program that calls it, so the procedure must
be declared as FAR. The next two lines are concerned with setting up a
pointer to the stack so that we can easily get at the parameters that
the routine is expecting, more about this in a minute. We must also
preserve the values of any segment registers (except for CS, which has
already been modified by the call itself) that are altered by the
routine, also the Index registers DI and SI if they are used.
When the routine is called, QuickBASIC pushes a two-byte value
corresponding to each of the supplied parameters onto the program
stack. These are followed by the return address which, since this is a
FAR procedure, is a four-byte pointer (Segment and Offset) to the
statement following the call to FastPrint. When we have finished
saving our own working registers, the stack will look like this:
Figure 1.1 Stack contents after entry into FastPrint.
Note that, since we copied the contents of the Stack Pointer to BP
immediately after BP itself was pushed, This register can now be used
as a fixed pointer through which we access the parameters that were
passed. Normally, QuickBASIC passes these arguments as 2-byte offset
addresses, which point to the named variables in the program's Data
Segment.
We, however, are going to override this and pass the numeric arguments
BY VALue, forcing QuickBASIC to copy the actual contents of the
variables into the appropriate stack locations. Then all we need do is
read the data supplied, directly into the target registers:
mov ax,[bp+12] ; Get row number
Passing by VALUE saves us having to hunt for the variables containing
our data and so makes our routine faster and more compact. It also,
incidently, makes it easier if we ever need to convert FastPrint to a
C function, since the C language does it by default. We'll make use of
the technique in a minute or two, but first we must collect some
important information about the computer our program is running in.
The QBNews Page 36
Volume 2, Number 2 May 31, 1991
Although we have decided that our program need only support machines
that are hardware-compatible with the IBM PC family, this still leaves
a variety of video environments to cater for. We must, for example,
find out whether the host computer is fitted with a colour or
monochrome display adaptor since the address of the screen buffer we
will be writing to depends on this. Computers with EGA and VGA cards,
moreover, can switch between up to eight display pages so, if our
program is running in one of these machines, we must make sure that
FastPrint sends its output to the correct page. Last, but not least,
if the host system does have an EGA or VGA we must find out whether
the current screen is set to a height of 25, 43 or 50 rows, so that we
can format our printing properly.
We could, of course, code the instructions that collect this data
directly into FastPrint itself. It is likely, however, that many
other programs we write will need the same information. Better, then,
to make our video system identification function an independent
procedure that can be called by whichever program needs it. This saves
us repeating the same block of code in every screen routine and makes
the Toolbox tighter and more efficient.
call VideoType ; Get video parameters
Since VideoType, as we have just decided, is going to be called by
many Toolbox routines, we must make sure that the linker can find it
when your program is built. This means that we have to declare it
PUBLIC by putting the following line at the top of the source code.
public VideoType
Note that versions 5 and 5.1 of MASM have a bug which makes all
procedures PUBLIC by default. If you are using either of these
versions of the Macro Assembler, therefore, this line is not strictly
necessary. However, because we cannot rely on this feature being
retained in future releases, it is best to use an explicit PUBLIC
declaration.
VideoType also needs some space to store the data it collects. Insert
the following lines in your source file, immediately after the .CODE
segment declaration but before the first PROC statement. I will
explain them more fully in a few moments.
SnowFlag db 0 ; Snow prevention flag
VideoRam dw 0B000h ; Default video segment
VideoPort dw 03BAh ; Default video status port
Param1 label word
Mode db 7 ; Current screen mode
Columns db 80 ; Current screen width
Param2 label word
Rows db 25 ; Current screen height
ActivePage db 0 ; Current video page
Notice that VideoType, like FastPrint itself, is a FAR procedure. This
is necessary if it is to be called by routines in seperately-linked
The QBNews Page 37
Volume 2, Number 2 May 31, 1991
modules that may have different Code segments.
See the VideoType routine in DISPLAY.ASM.
VIDEOTYPE
As with all assembly-language procedures, it is good practice to
preserve the contents of any registers that will be changed by the
routine and are not used to return data. Do this by pushing the
contents of these registers onto the stack immediately after entry and
popping them again just before you return.
Our first task is to check the current display mode to see if we are
running in a machine with a colour or monochrome monitor. The easiest
way is to call a service routine in the computer's BIOS and let the
system do the work for us. Fortunately there are many such services,
grouped by the hardware devices that they interface with, and with
each group being accessed through a dedicated software interrupt. The
Video services are called through Interrupt 16 (10 Hex).
To gather the information we want, VideoType issues an INT instruction
together with the interrupt number. Interrupt 16 (10 Hex) is a gateway
to some very useful video services. When called with AH set to 15 (0F
hex) it returns with the current display mode in AL, the number of
screen columns in AH, and the current video page in BH.
An interrupt is a signal to the microprocessor that its attention is
required. When one occurs, the processor suspends the current task and
jumps to a routine that is designed to deal with the event that
triggered off the interrupt, this routine is called an interrupt
handler. When the handler has done whatever is required, control
returns to the next instruction in the interrupted task and execution
resumes from there. Just like the return from a BASIC subroutine.
The 80x86 family of processors allows for 256 diffent interrupts,
numbered from 0 to 255. Some are dedicated to hardware devices, every
54.936 milliseconds, for example, the 8253 timer chip generates
interrupt number 8, which executes a subroutine to update the system
clock and date and time flags.
Most interrupt numbers, however, are reserved for software interrupts
that can be generated by programs, using either the assembly-language
INT instruction or the QuickBASIC CALL INTERRUPT statement.
You call an interrupt handler, not by specifying its address, but by
supplying the interrupt number you require. The actual addresses are
stored in an interrupt vector table at the very beginning of memory,
being written there by the initialisation process when your computer
is booted-up. When an interrupt is issued, the processor simply looks
up the table entry for that interrupt number and jumps to the address
contained there. Because different models of computer have different
hardware configurations as well as different versions of DOS and BIOS,
the actual addresses in the table will vary from machine to machine.
But, since the interrupt numbers themselves do not change, programs
The QBNews Page 38
Volume 2, Number 2 May 31, 1991
that use them are still portable between all computers in the PC
family.
When an interrupt is executed, the processor makes the following
actions:
1) The FLAGS register, the current Code Segment (CS) and the
Instruction Pointer (IP) are saved on the stack.
2) The address of the handling routine is looked up in the Interrupt
Vector Table, starting at location 0000:0000 in memory. Since
each table entry is four bytes long, the correct entry can be
found by multiplying the interrupt number by four.
3) The segment and offset address of the interrupt handling routine
are loaded into the CS:IP registers, transferring control to that
routine.
4) The code at the handling routine is executed until the
processor encounters an IRET (RETurn from Interrupt) instruction.
5) The original Instruction Pointer, Code Segment and Flags register
are then restored from the stack and execution proceeds with the
instruction that followed the original interrupt call.
Figure 1.2 The interrupt sequence used on computers such as the
IBM-PC, which use the Intel 80x86 family of micro-
processors.
On return from Interrupt 16, VideoType first checks the current video
display mode. Notice that we are looking to see if AL contains a value
of 7. This is only returned if your computer has a monochrome display.
If AL does equal 7, we can skip the rest of the procedure, since our
local variables are set for a monochrome display by default. Anything
other than 7, however, means that we have a graphics adaptor to
contend with and must adjust the defaults accordingly.
Two variables are involved. The first, labelled VIDEORAM is set to the
segment address of the display memory we will be using. This is at Hex
0B000 for mono adaptors (the default) and 0B800 for colour adaptors.
The other variable is the number of the hardware port that controls
the video display. For mono adaptors this is numbered 3BA (hex). For
colour machines the port number must be reset to 3DAh.
Notice that we are accessing local variables through the CS register,
using a SEGMENT OVERIDE directive; e.g.
mov CS:VideoRam,0B800h
The reason for this is that the DS register, which is normally used to
address data, is still pointing to the calling program's Data Segment.
We need to leave DS intact so that we can use it to get at our display
string when we eventually return to FastPrint. For now, however, we
carry on and store the screen width and display mode, which were
The QBNews Page 39
Volume 2, Number 2 May 31, 1991
returned in the upper and lower bytes of AX, in another of our local
variables. The active page, which is in BH, is saved, temporarily, on
the stack until we can obtain the screen height to go with it.
In computers fitted with EGA and VGA adaptors the video hardware adds
its own set of video functions to the BIOS video services. One of
these, interrupt 16 sub-function 17/48, returns amongst other things,
the information we require; the screen height in rows set in DL.
What if our host computer doesn't have an EGA or VGA? No need to
worry, calling an interrupt service that doesn't exist will not cause
an error. All that happens is that the function returns with registers
unchanged. Since other video adaptors only allow screen heights of 25
rows, if we previously set DL with this number, the correct value will
still be in the register after the interrupt call. Even if an EGA or
VGA isn't present. Notice, however, that the value we set is actually
24. BIOS routines typically use a numbering system based on zero
rather than one, so a screen height of 25 rows is returned as 24. This
is why we increment the return value by one, before storing it in its
destination variable.
One final thing that VideoType must do is to detect whether the host
computer is using a Colour Graphics Adaptor (CGA). The reason for this
is that there is a special problem with CGAs when we write directly to
video memory. I'll go into more detail about this later. For now we
just need to set a flag to indicate the presence of a CGA.
How do we find out if this computer has a CGA? Easy. The trick is to
find a video interrupt service which only works on machines fitted
with an EGA or VGA and set an impossible value into one of the return
registers. If, after the interrupt call has completed, this register
is unchanged then an EGA or VGA is not present and we must have a CGA.
Remember we have already eliminated systems with Monochrome Display
Adaptors (MDA). Video service 18/16 is a suitable candidate. It
returns a value of between 0 and 3 in BL to indicate the amount of
memory, in 64K blocks, installed on your video card. VideoType presets
BL with 16 (10 hex) before calling the interrupt. If this value is
still in BL when the interrupt returns, then we have a CGA to contend
with and we must set the SnowFlag accordingly.
Before popping its saved registers and returning, VideoType's final
task is to retrieve all the information it collected from local
storage. Back in FastPrint, we resume our task by isolating the
information that is needed next, the current screen dimensions. These
are collected in DX so that we can check them against the start
position of the string to be printed, making sure that it is within
the screen boundaries.
mov dh,ah ; Load screen dimensions
mov dl,bl ; into DX
QuickBASIC, conventionally numbers screen rows from 1 to 25 and screen
columns from 1 to 80. Since the ROM-BIOS co-ordinate system uses row
and column numbers starting from zero we need to convert our
The QBNews Page 40
Volume 2, Number 2 May 31, 1991
parameters to base zero before we can start printing. At the same
time it would be a good idea to check for legal values.
This is where we start collecting the parameters that were passed to
us by our caller. First the row co-ordinate:
mov ax,[bp+12] ; Get row number
dec al ; Convert to base zero
cmp al,0 ; Top screen row
jae Fast_01 ; Jump if not below
xor al,al ; Don't go over the top!
Fast_01:
cmp al,dl ; Bottom row?
jb Fast_02 ; Go no further
mov al,dl ; Substitute maximum
dec al ; row number
Now let's do the same for the column co-ordinate supplied:
Fast_02:
mov bx,[bp+10] ; Get column number
mov ah,bl ; into AH
dec ah ; Convert to base zero
cmp ah,0 ; Leftmost column?
jae Fast_03 ; Jump if not below
xor ah,ah ; Don't fall off the screen
Fast_03:
cmp ah,dh ; Rightmost column?
jb Fast_04 ; Go no further
mov ah,dh ; Substitute maximum
dec ah ; column number
Once we have a set of legal row and column co-ordinates we need to
translate them into the actual address in the video display buffer
where the data will be written. Since, like VideoType, this is a task
that our Toolbox routines will have to perform often, we had better
write a seperate procedure to handle it.
Fast_04:
call ScreenAddress ; Calculate target address
ScreenAddress, again, must be a FAR procedure so that it can be called
from programs in seperately-linked modules that may have different
Code segments. As always, we preserve on the stack any working
registers that are not used to return values. The row and column co-
ordinates which ScreenAddress will convert into a memory address are
supplied in the low and high bytes of AX.
See the ScreenAddress routine in DISPLAY.ASM.
ADDRESSING MEMORY
The 80x86 CPU uses two registers to fully describe memory addresses.
It does this by dividing the absolute address by 16 and storing the
The QBNews Page 41
Volume 2, Number 2 May 31, 1991
result of this calculation in a SEGMENT register. Then another, INDEX,
register is used to hold the remainder, which is called the OFFSET of
the object from the start of the segment. The byte at absolute decimal
location 753666, for instance, would be addressed as;
Segment = (753666 \ 16) = 47104 Offset = (753666 MOD 16) = 2
Using hexadecimal (base 16) notation, makes it much simpler to work
with segments and offsets, since all you need do is shift all digits
of the absolute address, one place to the right, the rightmost digit
falling off to become the offset part of the address:
753666 = B8002 (Hex) --------> Segment B800 : Offset 0002
More conventionally, this is written by assembly-language programmers
as B800:0002. It is actually the memory address of the character
displayed in the second column of the top row of the screen (if your
computer has a color adaptor).
Using this method, the PC's 1-megabyte of address space can be divided
into 65536 (0 - FFFFh) possible segments. Each segment starts at a
different paragraph boundary (a paragraph is a block of 16 bytes) and
contains up to 65536 (0 - FFFFh) different byte addresses. Any segment
larger than 16 bytes, of course, will overlap with the segments
starting at the next and subsequent paragraph boundaries.
To obtain the address of the position on the screen where our text is
to be printed, ScreenAddress's first move is to copy the supplied
column co-ordinate into BH. It then obtains the screen width, in
columns, from the local variable that was previously set by VideoType.
Since each column on the screen takes up two bytes of memory, one for
the character stored there and the other for the attribute that
governs how it is displayed, we now need to multiply the screen width
by two to get the number of bytes per row. In assembly-language this
is easy; the SHL instruction shifts all bits of the binary number in
BL one position to the left, effectively doubling its value.
Since AL contains the row number, we can now multiply it by BL and
get the byte offset of this row. The MUL instruction extends the
result of this calculation into AX, which is why we moved the column
number into BH out of the way. Now we must use SHL again to convert
this into bytes and add the result to AX. We now have the target
address, offset from the beginning of the screen and it only remains
for us to copy it into DI, one of the index registers used for
addressing memory.
If PCs only used a single screen page we could return right away.
However machines with CGA, EGA and VGA cards are capable of displaying
multiple pages so we must find which one is currently on the screen.
We already have the page number from VideoType but BIOS makes it even
easier by providing the actual address of the current display page,
which is what we really want.
The QBNews Page 42
Volume 2, Number 2 May 31, 1991
We don't need to use an interrupt call this time. BIOS maintains its
own data block at segment 40h in low memory and this contains, amongst
many other things, the exact information that we're looking for. The
address of the current display page is stored as a two-byte number at
offset 4Eh into this block. Notice, however, that ScreenAddress
actually uses 0000:044Eh to reach it. This is because it is slightly
quicker to clear the ES segment register than it is to load it with a
value. The actual memory location remains the same.
Figure 1.3 PC Memory map highlighting the BIOS data area in low RAM
Once we have the page offset all that remains is to add it to the row
and column offset that is already in DI. VideoType has already stored
the video segment and port address for us so we just need to retrieve
these parameters before returning to FastPrint.
The result of all this register juggling is that we now have the ES:DI
register pair pointing to the address in memory where output is to
start. DX is also loaded with the address of the video controller
port. Now we're ready to find the string to display.
What QuickBASIC passes when a string is specified as parameter to an
external procedure, is a pointer to a STRING DESCRIPTOR in the Data
Segment. This is a four-byte block of data of which the first two
bytes are the string length. In QuickBASIC strings may be up to 32767
bytes in length:
Figure 1.4 Structure of the String Descriptor passed by QuickBASIC
The second two bytes of the string descriptor contain a pointer to the
first character of the string itself. This is an offset address,
relative to the start of DGROUP, QuickBASIC's default Data Segment.
This is the address that is returned by the SADD function in
QuickBASIC. When used with a string, VARPTR returns the address of the
string descriptor instead.
If you are using Microsoft's BASIC 7 Professional Development System
then the method of passing strings is rather different. See the
sidebar for more details.
Before going any further, we should check that there is a string to be
printed. If the first two-bytes of the string descriptor evaluate to
zero, a null string has been passed so there is no point in proceeding
further. Consequently we set the AX register to an error code and jump
to the exit. It is good practice to return a code indicating the
success or failure of an operation when we leave, even if the calling
program will not read it. Most DOS applications return such an
ERRORLEVEL as a matter of course.
Well the string is there, so we can load its address, which is the
second two bytes of the string descriptor, into our other Index
Register, SI.
The QBNews Page 43
Volume 2, Number 2 May 31, 1991
mov bx,[bp+8] ; Index to string descriptor
mov cx,[bx] ; Get string length
cmp cx,0 ; Make sure it isn't
ja Fast_05 ; a null string
mov ax,1 ; If so set Error code
jmp short Fast_07 ; and abort
Fast_05:
mov si,[bx+2] ; DS:SI==> string data
mov ax,[bp+6] ; Get display attribute
xchg ah,al ; into AH
cld ; Clear direction flag
This is a good opportunity to get the final parameter, the display
attribute we are to use, into the AH register. The CLD (Clear
Direction Flag) instruction ensures that any subsequent string
manipulation instructions move data forwards in memory. Now that we
are ready to start printing, the processor registers are set up as
follows:
Segment Registers: ES points to the current video segment.
DS points to the calling program's DATA segment.
Index Registers: DI points to the offset address, relative to ES,
where the string will be copied to.
SI points to the beginning of our source string,
relative to the DS register.
General Registers: DX contains the video status port address.
CX contains the length of the source string.
AH contains the display attribute to be given to
each output character.
The last section of code is a simple loop that copies each byte of the
source string to its destination address in video memory. Instead of
using a MOV instruction to copy each byte of the string into the AL
register before transferring it to the screen, we use another assembly
instruction, LODSB.
Fast_06:
lodsb ; Get a byte from the string
LODSB is one of a set of string manipulation primatives built into the
Intel family of microprocessors. Why they are called 'primitive' I
don't know. They are, in fact,
extremely powerful. In just one
statement, LOSB will load a byte from the address pointed to by DS:SI
into the AL register and then automatically increment SI to point to
the next byte. If we were to prefix it with a REP instruction it would
repeat the whole operation for the number of times that the value in
CX is set to. This, as you can see, is just the thing for loops.
In fact, if we didn't have to cater for systems with CGA video cards,
we could do the remainder of the job in just one line. LODSB has a
companion instruction, MOVSB, which, as it's name implies, moves the
byte at DS:SI to a destination address pointed to by ES:SI. In this
The QBNews Page 44
Volume 2, Number 2 May 31, 1991
case both of the index registers, SI and DI, are incremented ready for
the next byte to be transfered. Like LODSB, MOVSB takes a REP prefix
and, since we already have the length of our string in CX, all that
would be necessary is to enter the instruction ....
rep movsb ; Shift the whole string
... and the job would be done.
But we do have to contend with CGA cards so our task is a little more
complicated and, since it is one that we will need to repeat in other
programs, we had better do it in a sub-routine.
call ScreenWrite ; Write a byte and attribute
loop Fast_06 ; Repeat for each character
See the ScreenWrite routine in DISPLAY.ASM.
The problem with CGAs occurs only when we write directly to video
memory. If the 6845 CRT Controller attempts to fetch a character from
the screen buffer whilst data is being written to that same location,
the resulting interference will cause 'snow' or glitches to appear on
the screen. We can prevent this happening by making sure that we only
output to the display when the 6845 is not reading from it.
Fortunately we do not have to wait long, since every 12 microseconds,
the 6845 performs what is known as a horizontal retrace. During this,
time the controller is not doing any reading so it is safe for our
program to write to the display.
We can detect when a horizontal retrace is in progress by testing bit
zero of the video adaptor status port, its address is now in DX,
remember? If this bit is set then a retrace is under way. In practice
we let any current retrace complete and wait for the next to begin,
before moving data. This ensures that we have we a full retrace period
in which to place the character and attribute byte into their proper
buffer addresses.
Computers with monochrome adaptors and those with more modern versions
of the CGA, do not experience 'snow' problems and, if you are sure
that you will only be using FastPrint in such systems, you are welcome
to leave out the routine. Me, I wouldn't bother. Using it ensures a
good clean display, no matter which computer you use the program in,
and the increase in processing time does not slow your programs down
enough to be noticed. It is a lot faster than PRINT, at any rate.
All that remains, now that our string has been output to the display,
is to tidy up the stack and return safely to the QuickBASIC program
that called us.
First we recover all the registers that were pushed on entry to the
routine.
xor ax,ax ; Report success
The QBNews Page 45
Volume 2, Number 2 May 31, 1991
Fast_07:
pop di ; Clean up the stack
pop si
pop es
pop bp
The final return instruction must adjust the stack so that any
parameters that were originally passed are now discarded. Our routine
received four parameters, each of which took up two bytes of stack, so
we issue a RET 8 to decrement the Stack Pointer by eight, ensuring
that the correct return address is popped back into CS:IP.
ret 8 ; Return to Quick BASIC
FastPrint endp
end
Last of all, don't forget to tell the assembler where the current
procedure and program end.
Here is the full listing of FastPrint again. If you type it in, don't
forget to include the code for the three procedures ScreenAddress,
ScreenWrite and VideoType in their proper places before the final END
directive. Notice that, since all the routines in the file are related
to the video display, I have given it the name DISPLAY.ASM. I suggest
that you use this name as well. We are going to add to it in the
ensuing chapters.
ASSEMBLY AND LINKING
Since all the procedures we have written so far are concerned with the
video display, I propose that we call the source file that contains
them DISPLAY.ASM. Save it as such and then assemble it using the
following command:
MASM /V/W2/Z display;
The /V (VERBOSE) switch instructs the assembler to report statistics
such as the number of program lines and symbols processed.
The /W2 switch sets the assembler's WARNING level to maximum. This
instructs it to report statements that may result in inefficient code,
as well as actual errors. It reports, for example, when you have
issued a normal JMP instruction where a short jump will do. This helps
you write tighter code.
The /Z switch directs MASM to list any lines, where errors are found,
on the screen. Another help in debugging.
If you use an assembler other than MASM, of course, the above
instructions do not apply. In this case consult your own assembler's
documentation.
If the assembly is successful, you will have a file, DISPLAY.OBJ,
The QBNews Page 46
Volume 2, Number 2 May 31, 1991
containing the assembled object code. This is all ready for linking
directly to compiled Quick BASIC programs which are to be run from the
DOS command line. You can link it with the instruction:
LINK yourprog DISPLAY;
(where 'yourprog' is the name of your own program)
If you want to use FastPrint in the QuickBASIC environment, you will
also have to include it in a Quick Library. Use the Linker for this as
well, the command is:
LINK /QU DISPLAY,,,BQLB45.LIB;
BQLB45.LIB is the standard library interface module supplied with
QuickBASIC 4.5, (if you are using the Extended QuickBASIC which comes
with MicroSoft's BASIC 7 PDS, the equivalent module is named
QBXQLB.LIB). Whichever one you use, make sure that it is in the
current directory when you issue the LINK command. You should now have
a file DISPLAY.QLB.
If you've got this far, you will, no doubt be anxious to try out
FastPrint in a QuickBASIC program. Let's start with a small one which
draws coloured boxes on the screen, just to test that it is working
properly. We'll call it PANELS.BAS.
Start up QuickBASIC with the following ...
QB PANELS.BAS /L DISPLAY.QLB
The first thing to do is to declare our routine as an external
procedure. We won't be expecting it to return any value, so we declare
it as a SUBprogram rather than a FUNCTION.
DECLARE SUB FastPrint (BYVAL Row%, BYVAL Col%, Text$, BYVAL Attr%)
Make sure that all the parameters are correctly listed and of the
correct type. Integers for the Row, Column and Attribute arguments and
a string for the text which we will be supplying.
Okay, was that fast enough for you?
What you have done, in effect, is to add your own extension to the
QuickBASIC language. Provided that the procedure is properly declared
at the top of your program, and the object file is linked or in an
attached Quick Library, you can use FastPrint as easily as any other
QuickBASIC statement or function. You don't even have to preface it
with the CALL directive, nor do you need to enclose the parameter list
with parentheses.
If you are not sure how to work out proper values for the colours and
attributes which you want your display to have, Appendix A goes into
this in some detail. By all means experiment, your taste is very
likely different from mine. You may even want to write special SUBS
The QBNews Page 47
Volume 2, Number 2 May 31, 1991
for commonly-used attributes, for instance ...
SUB RevPrint (Row%, Column%, Text$) STATIC
FastPrint Row%, Column%, Text$, 112
END SUB
... calls FASTPRINT with the attribute set for REVERSE VIDEO text,
Black characters on a White background (actually Green on monochrome
monitors.
SUB NormalPrint (Row%, Column%, Text$) STATIC
FastPrint Row%, Column%, Text$, 7
END SUB
... calls FASTPRINT with the attribute set to normal video. Just like
PRINT in fact, only faster.
By the way, what did all those panels remind you of? That's right,
WINDOWS. Well you'll just have to wait. The Windows will be opened in
a future article.
----------------------------------------------------------------------
ROM-BIOS Video Services
ROM-BIOS provides services which enable us to determine the current
display mode, select the video page to which output will be directed,
find the current cursor position and the character and attribute
underneath it, and to selectively scroll a specified area of the
display. They are accessed by loading the AH register with the number
of the service required, and then issuing interrupt 16 (10 Hex). You
may have to preset values into other registers, depending upon the
service being called.
Unless used for returned values, the contents of the BX, CX and DX
registers are preserved across these calls. Likewise, the segment
registers will be returned intact. You should not assume, however,
that the contents of other registers will be maintained. Remember also
that the system, used by the BIOS for numbering screen rows and
columns, differs from QuickBASIC in that the x/y co-ordinate of the
top-left corner of the screen is regarded as being 0,0 instead of 1,1.
----------------------------------------------------------------------
INT 10h Get current video display mode. all systems
Call with: AH = 0Fh (15 decimal)
Returns: AL = display mode (see table below)
AH = screen width in columns
BH = cureent display page
Mode Resolution Colours Screen Mode Resolution Colours Screen
----------------------------------------------------------------------
0 40 x 25 2 text 1 40 x 25 2 text
2 80 x 25 2 text 3 80 x 25 16 text
4 320 x 200 4 graphics 5 320 x 200 4 graphics
The QBNews Page 48
Volume 2, Number 2 May 31, 1991
6 640 x 200 2 graphics 7 80 x 25 2 text
8 160 x 200 16 graphics 9 320 x 200 16 graphics
10 640 x 200 4 graphics 13 320 x 200 16 graphics
14 640 x 200 16 graphics 15 640 x 350 2 graphics
16 640 x 350 16 graphics 17 640 x 480 2 graphics
18 640 x 480 16 graphics 19 320 x 200 256 graphics
----------------------------------------------------------------------
Computers fitted with the Monochrome Display Adaptor (MDA) will only
support mode 7, (80 x 25 character text).
Modes 4 and 6 correspond to QuickBASIC's SCREEN 1 and SCREEN 2.
Modes 8, 9 and 10 are only available on the IBM PCjr (and Tandy 1000).
Modes 13 and up are only available on machines fitted with EGA or VGA
adaptors, Mode 16 supports either 4 or 16 colours, depending upon the
amount of video memory available.
ROM-BIOS VIDEO SERVICES
----------------------------------------------------------------------
INT 10h Get Font information EGA, VGA, MCGA only
Call with: AH = 11h (17 decimal)
AL = 30h (48 decimal)
BH = 00h for default character set.
Returns: CX = point size (number of bytes per character)
DL = screen height in rows - 1
ES:BP => address of character definition table
Note: information about the alternative character sets
provided by your video adaptor is obtained by loading
BH with the appropriate font number. See your EGA or
VGA reference manual for more details.
----------------------------------------------------------------------
INT 10h Get Configuration information EGA, VGA only
Call with: AH = 12h (18 decimal)
BL = 10h (16 decimal)
Returns: BH = display type (0 = colour, 1 = monochrome)
BL = video memory installed
(0 = 64K, 1 = 128K, 2 = 192K, 3 = 256K)
CX = Adaptor feature bits and DIP switch settings
Notes: BL will still return a value of 3 even if more than
256K of video memory is installed.
for more information about the meaning of the value returned in CX
consult your EGA or VGA reference manual.
----------------------------------------------------------------------
The QBNews Page 49
Volume 2, Number 2 May 31, 1991
Using FastPrint with BASIC 7
If you intend using FastPrint with programs compiled under the BASIC 7
Professional Development System then a few changes are necessary. This
is because BASIC 7 uses Far Strings which gives strings a memory
segment of their own instead of putting them into DGROUP, the default
Data Segment pointed to by DS.
To enable you to find the address of a far string, BASIC 7 provides a
built-in function called StringAddress. This must be declared at the
head of your source code file between the .MODEL and .CODE directives,
so that the Linker can fix-up references to the function when your
program is built:
extrn StringAddress: proc
This done, you should rewrite the lines between labels Fast_04: and
Fast_06: as follows:
Fast_04:
push ax ; Save display co-ordinates
mov ax,[bp+8] ; Index to string descriptor
push ax ; Call BASIC for
call StringAddress ; string parameters
pop bx ; Recover co-ordinates
jcxz Fast_06 ; Abort if a null string
mov ds,dx ; String segment to DS
mov si,ax ; DS:SI==> string data
mov ax,bx ; Co-ordinates to AX
call ScreenAddress ; Calculate target address
mov ax,[bp+6] ; Get display attribute
xchg ah,al ; into AH
cld ; Clear direction flag
Notice that, just like QuickBASIC 4.5, we still have to obtain the
address of the string descriptor from our argument list. With BASIC 7,
however, we pass it on to StringAddress by pushing it back onto the
stack before calling this function. On return, BASIC 7 will have set
our registers as follows:
DX = segment of target string
CX = length of target string
AX = offset of target string
The explanation in the BASIC 7 manual and on-line Help implies that
you need to call a seperate function, StringLength, to find the length
of the string. In practice this is not necessary since StringAddress,
itself, returns this information in CX.
**********************************************************************
Christy Gemmell resides in England and was the major author of the
Waite Group book QuickBASIC Bible. Christy also has a shareware
called the Assembly-Language Toolbox for QuickBASIC. Christy can be
reached in care of this newsletter.
**********************************************************************
The QBNews Page 50
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
P o w e r P r o g r a m m i n g
----------------------------------------------------------------------
An Improved Cloning Algorithm by Larry Stone
Who ever said that there is no such thing as a bug free program
must have been very familiar with my work. To my chagrin, the code I
wrote for "The QBNews", Vol. 1, No. 3, concerning programs that clone
to themselves, contained a bug that could hang your system. In the
endeavor to wipe the egg off of my face, I present a new function that
corrects this error and, as a side benefit, executes faster and, for
those of you who use the PDQ library, is compatible with PDQ.
The function, SearchEXE$, as originally published, used a DO...LOOP
terminated with the instruction, "DO WHILE NOT EOF(1)". In the event
that the program does not contain the special marker in the EXE's
token area (refer to QBNWS103), the loop would execute indefinitely
because the EOF is never read with files opened in the BINARY mode.
The solution is one line of code:
IF Bytes + Portion& >= FiSize& THEN EXIT DO
The other major change presented here is the substitution of GET
for INPUT$(). The GET will operate faster and will make the code
compatible with Crescent's PDQ.
FUNCTION SearchEXE$ (FileName$, Key$, DatLen) STATIC
'The Bytes% variable is the number of bytes to read. If your program is
'less than 16000 bytes then this routine adjusts accordingly. Also, if
'a 16000 byte "GET" cuts the marker in two, you don't have to worry
'about it because we adjust the file pointer accordingly.
Bytes = 16000 '16000 bytes to read with each pass.
BytesToData& = 0 'Initialize it to zero.
Portion& = 1 'Initialize to file's 1st byte.
CountToKey = 0 'The count to Key$ location.
Handle = FREEFILE 'Get a number for the file.
OPEN FileName$ FOR BINARY AS #Handle
FiSize& = LOF(Handle)
DO
'---- 16000 bytes is to many so, reduce it.
IF Bytes > FiSize& THEN Bytes = FiSize&
'---- If Portion& + Bytes is greater than FiSize&, reduce Bytes.
IF Bytes + Portion& > FiSize& THEN Bytes = FiSize& - Portion&
'---- Point into the file (Portion&) and input "Bytes".
A$ = SPACE$(Bytes) 'Configure the string to "Bytes" length.
SEEK #Handle, Portion& 'SEEK to the portion.
The QBNews Page 51
Volume 2, Number 2 May 31, 1991
GET #Handle, , A$ 'Using GET works with PDQ & is faster.
CountToKey = INSTR(A$, Key$) 'Is Key in A$?
IF CountToKey THEN 'Yes, we found the Key!
'---- Calculate were the data is located.
BytesToData& = Portion& + CountToKey + LEN(Key$) - 1
A$ = SPACE$(DatLen) 'Configure the string to DatLen.
SEEK #Handle, BytesToData& 'SEEK to the data location.
GET #Handle, , A$ 'Now get the data.
SearchEXE$ = A$ 'Set the function.
CLOSE #Handle 'Close the file.
A$ = "" 'A little garbage collection
EXIT FUNCTION
END IF
'---- We've reached the end of the file and did not find our
' Marker$. This prevents an endless loop.
IF Bytes + Portion& >= FiSize& THEN EXIT DO
'---- We subtract the key length in case it was split by our GET.
Portion& = Bytes + Portion& - LEN(Key$)
LOOP
CLOSE #Handle
PRINT "Error. Could not find key!"
END
END FUNCTION
The QBNews Page 52
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
N e w a n d N o t e w o r t h y
----------------------------------------------------------------------
Custom Control Factory for Microsoft Visual Basic by Desaware
Desaware has announced the Custom Control Factory version 1.0, a
companion product to Microsoft Visual Basic which permits the user to
create a rich variety of custom button controls without the need for
special programming.
The Custom Control Factory has been developed to bridge the gap
between the standard controls included with Visual Basic and custom
controls which require advanced programming with the Windows Software
Development Kit and Control Development Kit for Visual Basic. Custom
Control Factory buttons are created interactively from within the
Visual Basic design environment without the need for special
programming. A runtime version of the product can be distributed with
compiled Visual Basic applications without further licence fees.
The Custom Control Factory version 1.0, along with over fifty sample
controls, is being introduced at only $48 and will be available
immediately after the release of Visual Basic version 1.0.
You can contact Desaware by calling 408-377-4770.
If you have a new product or an upgrade to an existing product you
would like announced in The QBNews, please send info to:
The QBNews
P.O. Box 507
Sandy Hook, CT 06482
The QBNews Page 53
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
F u n a n d G a m e s
----------------------------------------------------------------------
ASCII Art -- A Piece of Computer History by Charles Graham
In The Beginning ...
folks created ASCII Art. Before ANSPAINT, THEDRAW, GIFs and all
the rest, before color and sound and animation techniques, before CGA,
EGA and VGA, people used COPY CON, EDLIN or their favorite text editor
to produce art similar to the typewriter art of earlier, pre-PC
generations.
Over a number of years, I have collected 12 of these pictures from
bulletin boards and individuals. For all I know, these are the only
examples of ASCII art that remain. Evidently, most ASCII artists were
people who liked to draw full-figured nude women. I have never seen
an ASCII picture of anything but this particular subject. To the best
of my knowledge and belief, all of the pictures that come with this
collection are of unknown origin and are in the public domain.
I have always felt these low-tech creations were worth saving if
only for historic or nostalgic purposes -- like the early efforts of
cave dwellers when they drew stick figures of buffalo on the walls of
their abode.
ASCII art is created by using lower-ASCII characters starting with
ASCII 32 (the blank or space character). To my knowledge, no
upper-ASCII (8th bit on) graphics or foreign language characters were
ever used.
Even using this limited palette, however, viewing and printing the
pictures always presented certain problems. When using the DOS TYPE
command, only a small fraction of the work is on screen at any moment,
and the work is badly out of proportion. Printing them can also be
tricky because the default values of most printers (a horizontal pitch
of 10 characters per inch and a vertical pitch of 6 lines per inch)
produces images that are too long and contain too much white space.
So I created ASCIIART.BAS
What Is ASCIIART.BAS?
ASCIIART solves the on-screen viewing problems by translating the
characters that make up an ASCII picture into color attributes. It
uses these attributes to put pixels on your screen. The resulting
image is perhaps closer to the way the artist originally envisioned
his subject then the DOS TYPE command could ever allow. On EGA
systems, the picture is small but high- resolution and may contain up
to five colors plus black. On CGA systems, the picture is of medium
size and resolution and may contain up to three colors plus black.
ASCIIART does not support monochrome systems.
The QBNews Page 54
Volume 2, Number 2 May 31, 1991
Color Selection
I began the color selection process with what I thought was a
logical assumption: ASCII artists would instinctively choose
characters with more "weight" to denote shading and less "weight" to
denote highlights. I defined "weight" as the amount of ink that hits
the paper when a particular character is printed.
I put my dot matrix printer into draft mode and printed all the
printable characters. I used a magnifying glass and inspected each
one. I counted and recorded the number of dots used to print each
character and divided them into six "weight" groups.
Then through trial and error I began associating different colors
with different "weight" groups until I began to get a pattern that
"worked." Further refinement and tinkering developed the pattern that
comes hard coded in ASCIIART.BAS.
Because different ASCII artists favored different characters to
draw with, the method by which ASCIIART assigns color attributes to
characters is a compromise. However, for the twelve ASCII pictures I
have managed to collect, I believe it is the best compromise available.
Users who want to experiment with color selection can easily do so
by altering the DATA statements at the end of ASCIIART's main module
as well as the FOR/NEXT loops in SUB loadarray. You can come up with
some rather garish renditions without much effort.
Printing The Pictures
ASCIIART also assists you in making a decent looking copy of an
ASCII picture on your printer. The printer parameters that I have
found work best are:
-- Condensed Print, i.e., a horizontal pitch of 17 characters per
inch or close to it
-- Near Letter Quality (NLQ or double-strike) printing as opposed
to Draft Quality printing
-- Uni- as opposed to Bi-directional printing, and
-- a vertical pitch of 7/72nds of an inch, i.e., approximately 10
1/4 lines per inch.
To set these parameters on IBM printers, the following ASCII
characters need to be sent:
-- ASCII 15 (to enter condensed mode)
-- ASCII 27 and 71 (to enter NLQ mode)
-- ASCII 27, 85 and 49 (to enter unidirectional mode)
-- ASCII 27, 65and 7 (to store a vertical pitch of 7/72")
-- ASCII 27 and 50 (to begin using the stored vertical pitch).
To produce the best possible rendition, ASCIIART will automatically
send the correct control codes and escape sequences to supported
printers before printing the pictures. And it allows those who don't
want to send any control codes or escape sequences not to do so.
The QBNews Page 55
Volume 2, Number 2 May 31, 1991
ASCIIART also invites the owners of non-supported printers to enter
their own control codes and escape sequences to set the correct
printer parameters. Entering "C" (for Custom) at the printer
selection screen will allow such users to do this.
Printing Other Pictures
ASCIIART has a feature that will allow you to print or view other
ASCII pictures, should you come across one or care to create one.
Place the picture in the same directory as all the other files
included with this collection and name it OTHER.ASC. Then, when you
are prompted for the name of the picture, enter the name OTHER. You
can even view your word processing documents this way -- if you'd like!
In Closing
To help keep this edition of The QBNews at a reasonable size, at
the Editor's request only 2 of the 12 available ASCII pictures have
been included. The full set of 12 may be downloaded as ASCIIPIC.ZIP
on the Crescent Support BBS at no cost. If calling Crescent is
inconvenient, the same set is available from the author on a 360K
diskette for $3.00 to cover the cost of materials, postage and
handling.
I find ASCII art to be quaint and entertaining. If you come across
or create any good ASCII pictures I'd appreciate your sending me a
copy.
Enjoy!
*********************************************************************
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 56
Volume 2, Number 2 May 31, 1991
----------------------------------------------------------------------
Q B N e w s S p e c i a l R e p o r t
----------------------------------------------------------------------
Special Preview of Visual Basic by Dave Cleary
On May 20, 1991, Microsoft announced the long anticipated Visual
Basic Windows Development Environment. Steve Gibson calls it the
"masterstroke of the decade". Stewart Alsop calls it "the perfect
user programming environment - for the 1990s". But what does Visual
Basic mean to me and you, the QuickBASIC developer?
First, I'm going to start out telling you what Visual Basic is and
isn't. Visual Basic isn't an upgrade to QuickBASIC. VB is a whole new
product that requires all new tools and a totally different thought
process in regards to designing your programs. This is because VB
creates Microsoft Windows programs and writing Windows programs is
like write for a whole new operating system. Instead of calling DOS
to perform needed functions, you call the Windows API (Application
Programming Interface).
Windows is an Event Driven environment. This is why writing
programs in VB requires a different thought process. When you create
a VB program, the majority of your subs and functions will not be
invoked by you. Instead, Windows will invoke them depending on
actions performed by the user. We will go deeper into event driven
programming later in the article.
The Visual Basic environment isn't as sophisticated as the
QuickBASIC environment. Although VB does contain many features of the
QB environment, some are left out. The biggest omission is the fact
you can not set up a watchpoint on a variable. Instead, VB allows you
to go the an immediate window to view or set variable values. VB also
lets you insert Debug.Print statements throughout your code to print
values to your immediate window as the program runs. VB does contain
QB's threaded p-code technology allowing you to change code on the
fly without a recompile. The amusing thing is that C and Pascal
programmers who try VB think it is the greatest thing since sliced
bread. I feel, however, that QB programmers who try VB will be a
little disappointed - at first.
VB is probably the easiest and most productive Windows development
environment around. For instance, I can create a Windows file manager
that contains a drive list, a directory list, and a file list, and
give the user three push buttons with the choice of editing, running,
or deleting the selected file. All this can be done with about ten
lines of code. Of course, creating sophisticated programs still
require a good amount of work and skill by the programmer.
Creating programs with VB is a two step process. The first step is
to create your user interface. This is done with VB's visual form
designer and a collection of controls. A control is an object like a
push button, a text box, or a timer event. VB comes with 15 such
controls, but VB also lets you add custom controls. This effectively
lets you extend the VB environment. To create a custom control, you
need to use either C or ASM and the Windows SDK. However, numerous
third party vendors will be selling libraries of custom controls.
The QBNews Page 57
Volume 2, Number 2 May 31, 1991
A control has properties, events and methods. A property is a
physical characteristic of the control. For instance, the text in a
push button is a property of that control. You are allowed to set and
read properties of controls when you create them (design time), and
when you execute your program (run time).
After you are down drawing your user interface a setting up your
default control properties, you are ready to start coding. The big
difference is that most of your code will be associated with a
control event. An event is basically an action by the user that has a
subprogram associated with it. This is how you program for Windows
event driven environment. For instance, when you draw a push button
on the screen, certain events are associated with it. One of these
events is when the user clicks the button. VB creates a procedure
called Command1_Click. Command1 is the default name given to the
first push button you draw, but you can change it to whatever you
like by setting its control name property. The code you put in this
sub is executed every time a user clicks the button.
Finally, controls have methods associated with them. A method can
be thought of as an executable statement of the control. For
instance, VB has a List Box control. You add items to the list box by
using the AddItem method.
If you aren't totally confused by now, then I'm suprised. The
above is not meant to teach you how to program in VB, but rather to
show you how different it is. This is why I feel porting existing QB
programs over to VB will be difficult at best. Now the question is
"Should I buy VB?". If you plan on doing any Windows development at
all, then the answer is a resounding yes. If you don't plan on
writing any Windows programs, but use Windows as your environment of
choice, then the answer is still a resounding yes. You will be able
to create those little utilities you wished you had, but haven't
found yet and you will be able to do it in short order. If you hate
Windows, or don't own an 80286 or 80386 machine, then don't bother.
You won't be able to use VB anyway.
Registered users of any Microsoft BASIC product can buy VB from
Microsoft for $99, half off list price. You can call Microsoft at
1-800-426-9400 or wait for a coupon to appear in your mail. Also, I
have started a Windows BASIC conference on Fidonet. This conference
is for the discussion of all Windows BASIC products, not just VB.
Sysops interested in linking up to this conference should contact me
at 1:141/777. Also, if you are interested in checking out some actual
VB applications, you can give my BBS a call at 203-426-5958.
*********************************************************************
Dave Cleary is an electronics engineer for Vectron Labs in Norwalk,
CT. Besides being a Visual Basic beta tester, Dave is also the author
of Crescent Software's PDQComm and is the publisher of this
newsletter. He can be contacted on Compuserve at 76510,1725, on
Prodigy at HSRW18A, and on Fidonet at 1:141/777.
*********************************************************************
The QBNews Page 58
----------------------------------------------------------------------
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 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
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
The QBNews Page 59
Volume 2, Number 2 May 31, 1991
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 60
