home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
No Fragments Archive 10: Diskmags
/
nf_archive_10.iso
/
MAGS
/
STEN
/
STEN08.MSA
/
NEWS.TXT
/
GFA_TUTR.ASC
< prev
next >
Wrap
Text File
|
2010-04-21
|
90KB
|
2,152 lines
GFA TUTORIAL - FROM INSIDE INFO #54
===================================
(from INSIDE INFO #49)
T - Returns to this menu
F1 - Introduction F2 - Part 1
F3 - Part 2 F4 - Part 3
F5 - Part 4 F6 - Part 5
F7 - Part 6 F8 - Part 7
F9 - Part 8 F10 - Part 9
~~~OOOO~~~
***** ***** ***** ***** ***** ***** ***** *****
* * * * * * * * * * *
* * * * * * * * * * *
* *** ***** ***** ***** ***** ***** * *
* * * * * * * * * * * *
* * * * * * * * * * * *
***** * * * ***** * * ***** ***** *****
YOU NO LONGER HAVE AN EXCUSE NOT TO TRY IT!
====================== by John Hutchinson ====================
In the January 1989 issue of Start Magazine, published by
Antic Publications, readers found a very pleasant surprise.
Included on the magazine disk was one of the most successful
commercial programs ever made for the Atari ST. It was, in
fact, GFA BASIC 2.0!
While not "exactly" public domain (Antic reserves the
rights to all programs published by their magazines), the effect
is the same. Thousands of Atari ST users now have immediate,
almost zero-cost access to the second best programming language
ever created for the ST. Why only "second best"? Well
obviously, those kudos belong to GFA BASIC 3.0.
GFA BASIC 2.0 is miles (alright, alright... kilometers)
ahead of any other BASIC for the ST and often vastly superior to
lower level languages such as Pascal, C, and Modula II. I'll try
to justify those claims in a moment, so stay with me.
As is common practice, ACE-NSW is making the Start magazine
disk available to its members via the ST public domain library.
(As with any program published by Antic, you should own a copy
of the magazine containing the software to be legally entitled
to use it.)
So why am I decidely sold on GFA BASIC? Look at the facts:
1) First and foremost, like most lesser BASICs, GFA is an
interpreted language. Simply put, this makes it easier to use
and takes less time to see the results of your programming
efforts. You use it's built-in editor (much like a word
processor) to enter your command statements and then push two
buttons to RUN the program. None of this edit, compile, link,
run business. It's all done from the editor.
2) GFA BASIC supports a "structured programming" style
which does not use line numbers. This may seem bewildering at
first but it makes a lot of sense. Lower level languages such
as Pascal, C, Modula II, and assembly don't use line numbers
because they are a pain and lead to sloppy, difficult to manage
and debug code. Face it, if you have to "jump" to another part
of the program, it's much more intuitive to use the statement
"show_the_picture" than "GOSUB 1210"!
3) You can call C and assembly programs and routines
direct from GFA BASIC whenever you wish. When the external
program finishes, control is passed back to your GFA BASIC
program. You can even pass parameters back and forth.
4) GFA BASIC has a very "healthy" set of commands, includ-
ing graphics and AES functions (GFA 3.0 added over 300 new
ones!). If you can't do it in GFA BASIC, it probably doesn't
need to be done in the first place!
5) GFA BASIC is, in a word, FAST! Speed used to be the
downfall of BASIC but not any longer. As an admitedly biased
example, check out the benchmark times below for sorting 1000
random strings in alphabetical order:
ST BASIC ................. 304.00 seconds
GFA BASIC V2.0 ........... 23.50 "
GFA BASIC V3.0 ........... 18.10 "
GFA BASIC V3.0 (QSORT) ... 0.82 "
If you want your program to be even faster, you can buy the
GFA BASIC 2.0 Compiler to convert your *.BAS files into stand-
alone *.PRG programs (the compiler for GFA BASIC 3.0 should be
available in February 1989). You will find that the speed of
compiled GFA BASIC programs compare very favourably with (if not
surpassing) those of Pascal and C.
6) Absolutely no royalty fees need ever be paid for any
commercial usage of GFA BASIC. In fact, you don't even have to
mention your published code was written in GFA. There are even
separate run-time only versions of GFA BASIC 2.0 and 3.0 which
Michtron has placed in the public domain.
7) GFA BASIC is the preferred language for submissions to
both START and ST-LOG magazines (I myself have had four articles
and programs published in START which ALL concerned GFA BASIC).
The *** INFO DISK *** program which you are using now to read
this newsletter was written in GFA BASIC.
9) Michtron has published a series of books to help
you learn how to use GFA to its fullest. The book GFA BASIC
TRAINING REBOOT CAMP is a great beginner's tutorial even if it
does have a silly name. Separate intermediate to advanced books
are also available for GFA 2.0 and 3.0.
10) Lastly, it's just plain FUN to use.
So if you are still using ST BASIC, do yourself a favor and
FORMAT the disk (at least it will be worth something then). Buy
the GFA BASIC 2.0 disk from the ACE library.
Whether you are a novice beginner or a seasoned programmer,
I'm sure you will find GFA BASIC to be a real winner. I did!
++++++++++++++++++++++++++++
Using GFA BASIC - Part One
by John Hutchinson
GREETINGS...
Welcome to the first installment of "Using GFA BASIC", a new
monthly column for INSIDE INFO. If reader response is
encouraging, each month I will try to pass along a few tips and
tricks intended to make your GFA BASIC programming efforts more
effecient, productive, and hopefully... fun!
WHO IS THIS COLUMN FOR?...
Sorry, but I don't intend to make this a beginner's
tutorial series. There are other sources of information better
suited to that task (see below). But neither will I restrict
discussion of use only to those with considerable programming
experience. I will initially assume that most readers of this
column are somewhat familiar with the GFA BASIC editor, and have
likely dabbled a little with other BASICs as well.
WHY GFA BASIC?...
As of this writing, GFA BASIC is undoubtedly the most
popular programming language for most ST users. It's easy to
use, fast, powerful, and very inexpensive. This is not to say it
is best for all purposes (Assembly, C, et al, certainly have
their place) but if you only have the time or inclination to
learn one ST programming language, GFA should be it.
WHERE DO I GET GFA BASIC 2.0?...
Antic Publications recently bought the distribution rights
to GFA BASIC 2.0 and included it on their December 88 Start
magazine disk. You can get a copy of the disk from the ACE[NSW]
library but you need to purchase the magazine to legally use it.
An equally good bargain is that Antic is selling the GFA BASIC
manual for only $US9.95. This is an exceptionally good deal so
be fair and send them the money required for the back issue and
manual to be a legal user:
Start
544 Second Street
San Francisco, CA 94107
USA
If you have never programmed in BASIC before but want to
learn, I recommend you purchase a copy of Michtron's book, GFA
BASIC TRAINING REBOOT CAMP by D.A. Brumleve (US$19.95). Yes,
it's a silly title but it is quite an excellent tutorial that
doesn't treat you like an idiot yet it's not overwhelming either.
If you can't find it locally, you can order it direct from:
Michtron, Inc.
576 Telegraph Road
Pontiac, MI 48053
USA
Michtron also has available several other books on GFA you
might be interested in. George Miller's new book, the GFA BASIC
REFERENCE GUIDE, VOLUME 1, is a superb, massive volume with loads
of information for new and experienced users alike. Another is
the GFA BASIC BOOK which is a guide for advanced users.
WHAT ABOUT GFA BASIC 3.0?...
GFA BASIC 3.0 is the latest version and is jam-packed with
features including over 300 NEW commands and a 600 page manual.
It retains all the good features of the 2.0 version while
improving the editor and overall run-time speed plus full AES
implementation. If you already own GFA BASIC 2.0, I strongly
recommend you upgrade to 3.0 (US$40 for the upgrade). Otherwise,
I recommend you start off with GFA 2.0 because it's so cheap.
This column will be written with the 2.0 user in mind, but since
3.0 is entirely downward compatible, any routines mentioned will
work fine with both versions. [NOTE: Michtron has just
announced availability of a NEW BASIC called HiSoft which they
claim to be even more powerful than GFA 3.0. I hope to have a
hands-on review of HiSoft soon so stay tuned!]
DO I NEED THE GFA BASIC COMPILER?...
No, but you will probably want it eventually. Essentially,
the compiler takes your GFA BASIC source code and converts it
into a standalone executable program (*.PRG) file. The end
result is an even faster running program that anyone can use (and
your source code is kept private as well). The 2.0 compiler
retails for US$80. The 3.0 compiler is not yet available.
GETTING STARTED...
Now that all that rubbish is out of the way, let's get down
to business. Load GFA BASIC and when the editor screen comes up,
press the ESCape key to put you in "immediate" mode. Now type
the following line and press RETURN:
DEFLIST 0
Now return to the editor by pressing ESCape followed by RETURN.
All this did was to change the display mode of your editor so
that all GFA BASIC reserved words will be displayed in upper case
and all others in lower case. This will be the format I will use
in this column so it will be easier to understand if we all use
the same mode.
OPTIMIZING YOUR CODE...
Let's try a little experiment. Enter the following code in
the editor, then press SHIFT+F10 to run it:
a=1
start=TIMER
FOR i=1 TO 1000
a=a+i
a=a-i
a=a*i
a=a/i
NEXT i
PRINT (TIMER-start)/50;" seconds"
PRINT FRE(0);" bytes free"
Note the "seconds" and "bytes free" amounts then make the
following changes and try it again:
a%=1
start%=TIMER
FOR i%=1 TO 1000
ADD a%,i%
SUB a%,i%
MUL a%,i%
DIV a%,i%
NEXT i%
PRINT (TIMER-start%)/50;" seconds"
PRINT FRE(0);" bytes free"
Quite a difference, isn't it? The whole point of this little
exercise is to demonstrate simple ways to optimize your code for
speed and memory usage. This leads to Hutch's Optimization Rules
#1 and #2, namely... "Use INTEGER variables (those with a "%"
suffix) whenever possible" and "Use GFA's built-in integer math
functions whenever possible". INTEGER variables operate much
faster in loops and require less memory than REAL variables and
the math functions are considerably faster too. If your program
needs REAL numbers then by all means, use them, but only when you
have to. Conserving memory may not seem like a big deal when you
have 1/2 to 4 Megabytes to play with but as your programming
efforts expand in complexity, it becomes important.
There are many other ways to optimize your programs, of
course, and we will deal with some of them when appropriate. As
a general rule of thumb, however, simply try to write your code
so it does what it needs to do in as few lines as possible and it
will generally be more efficient. That may seem self-apparent
but many programmers seem to become "oblivious to the obvious".
This leads us to Hutch's Optimization Rule #3... "If a given
routine needs to be duplicated more than twice in a program, make
it a procedure call". For example, if you have a program that
has the following lines repeated at several places in the code:
IF key$<>right_key$
OUT 2,7
SETCOLOR 0,7,0,0
ALERT 1,"Wrong key,| Dummy!|,1," Rats! ",dummy%
SETCOLOR 0,7,7,7
ENDIF
it's more efficient (and elegant) to do this:
IF key$<>right_key$
GOSUB wrong_key_alert ! User messed up
ENDIF
'
PROCEDURE wrong_key_alert
OUT 2,7 ! Ring the bell
SETCOLOR 0,7,0,0 ! Turn screen red
ALERT 1,"Wrong key,| Dummy!|,1," Rats! ",dummy%
SETCOLOR 0,7,7,7 ! Turn screen white
RETURN
Again, use your best judgement but if the use of procedures can
result in fewer lines of code then go for it! You will likely
find that your code is easier to read and understand as well.
One more thing, note the use of my comments, above. I use a LOT
of comments in my code. If you have ever written a complicated
piece of code, put it away, then came back again after six months
and scratched your head trying to figure out what the heck you
were trying to do then you will understand why.
I believe that's more than enough for this session. Next
month we will talk about "structured programming" (ARGHHH!) and
perhaps demonstrate a couple of handy graphics routines.
HELP!!!
Your feedback is IMPORTANT! Send your comments, questions,
suggestions, hate mail, etc, to me via E-mail on the ACE [NSW]
BBS. We hope to have a GFA SIG up and running on the BBS soon so
stay tuned for announcements.
Enjoy,
<HUTCH>
* * * * * * * * * * * * * *
Using GFA BASIC - Part Two
by John 'Hutch'inson
IS ANYONE OUT THERE???
----------------------
In the course of writing articles for newsletters, one
sometimes wonders whether or not anyone out there is actually
reading them. In the last month, I have had very little response
to this column and absoultely ZERO input to the GFA BASIC SIG
(message area number 20) on the ACE [NSW] BBS. To be honest, if
we don't get any positive feedback soon, then I'll recommend we
release the much needed disk space back to the Editor and Sysop
for topics of more widespread interest to members. So if anyone
out there wishes this GFA support to continue, let me know, O.K.?
STRUCTURED PROGRAMMING
----------------------
You hear a lot about structured programming nowadays, and
perhaps it's time that someone (me, for instance) cleared out the
cobwebs and put the issue in its proper perspective. First of
all, what is it? Quite simply, it is a programming style which,
when followed in a logical manner, will tend to make your programs
more understandable and easier to debug and maintain. That's all
there is to it. It won't make your programs faster or more user
friendly, but it can help make YOUR life as the programmer a
little less tiresome in the long run.
The first rule in structured programming is that there are no
rules. After all, it's YOUR program (discounting those of you who
hack for a living, of course). What you can do though is to set
up a few guidelines for yourself and try to follow them in each
program that you write, hence establishing a sort of pattern. For
example, here are a few guidelines that I TRY to follow:
1) Use a program header. I always include a program
header which consists of a bunch of remarks at the very top of my
listing which identifies the program name, filename, date last
revised, major modifications made, and a list of bugs that still
need to be corrected.
2) Write your program like you are writing a story.
Have an "introduction" (initialization), "body" (main), and a
"conclusion" (finish). Keep the main routine as short as possible
by using procedures to do the dirty work. Put the main routine
near the beginning of your program and arrange your procedures in
a logical order, putting those less frequently used near the end.
3) Use one command/statement per line. Fortunately,
GFA BASIC pretty much forces this requirement on you by not
allowing concatenation of multiple commands on a single line.
Yes, this may make your program listings longer but also makes
them SO-O-O-O-O much easier to read.
4) Use intuitive variable and procedure names. The
days of 8 character long variable names are long since past. GFA
allows variable names of up to 256 characters in length, and these
may consist of letters, numbers, underscores, etc. Why use
"d=1.5" and "GOSUB gc" when "dollar_amount=1.5" and "GOSUB
get_colors" are so much more understandable.
5) Be consistent in variable names. Use the same
variables as loop counters throughout your program, and establish
a common rule for nameing integer, real, and boolean variables.
6) Minimize GOTO instructions. Note that I say
"minimize", not "eliminate". There are times when a GOTO
instruction may, in fact, be not only appropriate but the most
efficient way to handle an exit condition. Even so, GOTOs are
notorious for making code hard to follow so do try to use them
sparingly, if at all.
7) Make your code self documenting. Each procedure
should be relatively understandable when taken by itself. Make
liberal use of comments (remarks) to clarify what each procedure
or function does.
Remember, these are just some of MY guidelines. Develop a
programming style that is comfortable to YOU and stick to it. GFA
BASIC is not near as restrictive as Pascal or Modula II but it has
a lot of features to support structured programming so use them!
LOADING GRAPHICS SCREENS INTO GFA BASIC
---------------------------------------
One of the most common tasks faced by ST programmers
(especially for games) is the loading of a DEGAS (*.PI*) format
picture file. While there are many ways to accomplish this in GFA
BASIC, what follows is a short standalone program with procedures
I have found to work well for this task. The following example is
for color files but monochrome works the same way.
' GETDEGAS
' Use the following routine to load an uncompressed, 32K DEGAS
' picture file into GFA BASIC.
'
' Do this DIM statement only ONCE at the beginning of your program
DIM sa%(16) ! Array for DEGAS palette
'
' Your program goes here
'
' Set a$ to the DEGAS file you wish to load. Include proper path.
a$="A:FILENAME.PI1"
@get_degas ! GOSUB to the procedure
'
' The rest of your program goes here
'
END
'
PROCEDURE get_degas
CLS ! Clear the screen
HIDEM ! Turn the mouse off
' Optional "black-out" routine to turn off screen during loading
' FOR i%=0 TO 15
' SETCOLOR i%,0,0,0
' NEXT i%
BLOAD a$,XBIOS(2)-34 ! Load the picture
a%=XBIOS(2)-32
FOR i%=0 TO 15 ! Read DEGAS colors
sa%(i%)=DPEEK(a%)
ADD a%,2
NEXT i%
FOR i%=0 TO 15 ! Set the ST's colors
a=XBIOS(7,i%,sa%(i%))
Next i%
SHOWM ! Turn mouse back on
RETURN
'
Similarly, you may load NEOCHROME (*.NEO) format picture
files with this routine:
PROCEDURE get_neo
BLOAD a$,XBIOS(2)-128 ! Load the file
a%=XBIOS(2)-124
FOR i%=0 TO 15 ! Get the NEO colors
sa%(i%)=DPEEK(i%)
ADD a%,2
NEXT i%
FOR i%=0 TO 15 ! Set the ST colors
a=XBIOS(7,i%,sa%(i%))
NEXT i%
RETURN
'
CHANGING SCREEN RESOLUTION ON THE FLY...
----------------------------------------
In the above examples, the DEGAS or NEOCHROME format picture
files must match the screen current resolution. But what if your
application runs in medium resolution but you wish to display a
low resolution picture file (or vice versa). Try this routine:
PROCEDURE switch_res
res%=XBIOS(4) ! Get screen resolution
' If pix is medium & screen is low:
IF RIGHT$(a$,1)="2" AND res%<1
VOID XBIOS(5,L:-1,L:-1,W:1) ! switches to med res
ELSE
' Or if pix is low & screen is medium:
IF RIGHT$(a$,1)="1" AND res%>0
VOID XBIOS(5,L:-1,L:-1,W:0) ! switches to low res
ENDIF
RETURN
Note the use of the XBIOS(4) call. This simple function
returns the current screen resolution:
0 = Low resolution color
1 = Medium resolution color
2 = High resolution monochrome
That's it for now. Stay tuned for more hints next time.
HELP!!!
-------
Your feedback is IMPORTANT! Send your comments, questions,
suggestions, hate mail, etc, to me via E-mail or the GFA SIG on
the ACE BBS.
Enjoy,
<HUTCH>
*******************************************************
******************************
* *
* Using GFA BASIC - Part 3 *
* *
* by John Hutchinson *
* *
******************************
GREETINGS
---------
Last month I asked for some reader feedback to gauge the
level of interest in this column. I'm pleased to report that I
have received several encouraging comments from ACE[NSW] members
so for the time being, "Using GFA BASIC" will continue as a
regular feature of Inside Info. Thanks for the kudos folks!
BACK TO BASICS
--------------
Since Start magazine's recent publication of GFA BASIC v.2.0
there are a great deal of brand new GFA users out there, some of
which are attempting to learn the language without benefit of the
manual which is in short supply. Therefore, to help get these
people started, we will digress a little this month with a quickee
introductory tutorial. If you are a more experienced GFA user,
stick around because we will begin a series on GEM programming
next month, concentrating on the AES routines.
THE GFA BASIC EDITOR
--------------------
When you run GFABASIC.PRG from the desktop, you will enter
the editor from which all your GFA commands will be entered. The
editor is much like a word processor and consists of an 80 column
text display (even in low res) with the following menu bar at the
top of the screen:
--------------------------------------------------------------------
|Save|Save,A|Quit |New |Blk Sta|Replace| Pg up | |Direct|Run |
|Load| Merge|Llist|Block|Blk End| Find |Pg down|Insert| Flip |Test|
--------------------------------------------------------------------
(NOTE: Version 2's editor is shown but Version 3's is similar).
You may select any of the menu items by pointing and clicking with
the mouse or by use of the function keys (F1=Load, Shift+F1=Save;
etc). Here is a brief rundown on the use of each item:
LOAD (F1) - brings up a fileselector box from which you may
load existing GFA BASIC programs (files ending in .BAS).
SAVE (SHIFT+F1) - brings up a fileselector box from which you
may enter the path and filename to save whatever GFA BASIC
program is currently in memory (the editor) at the time. You
should always give your GFA programs a filename extension of
.BAS so you can easily recognize them as BASIC programs.
MERGE (F2) - brings up a fileselector box from which you may
choose an ASCII GFA file (one saved with the "Save,A"
command) to be merged with whatever program is currently in
memory. The merge will take place at whatever line the
cursor is on when MERGE is called.
SAVE,A (SHIFT+F2) - brings up a fileselector box from which
you may enter the path and filename to save whatever GFA
BASIC program is currently in memory as an ASCII file. Since
ASCII files are pure text they may be shown/printed from the
desktop, merged into a word processor, etc. You should
always save ASCII files with a .LST extension.
LLIST (F3) - If you have a printer connected to your ST, this
command will allow you to get a printed listing of whatever
program is currently in memory.
QUIT (SHIFT+F3) - Takes you back to the desktop. Save your
work first!
BLOCK (F4) - Brings up a sub-menu of block commands that let
you move, copy, write as a text (.LST) file, print, hide, or
delete a block of text previously defined with the START
BLOCK and END BLOCK editor commands.
NEW (SHIFT+F4) - Erases whatever program is currently in
memory. Be careful... once it's gone, it's really gone!
BLOCK START (SHIFT+F5) - Lets you specify the beginning of a
block of code which begins with the line the cursor is on.
BLOCK END (F5) - Lets you specify the end of a block of GFA
code. The block will be highlighted and ends with the line
directly above the line the cursor is on.
FIND (F6) - Allows you to enter a string of text which will
be searched for from the present cursor position to the end
of the program in memory. FIND is case sensitive.
REPLACE (SHIFT+F6) - Like the FIND command, but allows you to
replace text with other text of your choice. REPLACE is case
sensitive.
PG DOWN (F7) - Moves the program listing down one page.
PG UP (SHIFT+F7) - Moves the program listing up one page.
INSERT (F8) - Toggles between the insert and overwrite mode
of text entry.
FLIP (F9) - This command allows you to switch to the output
screen of the last previously run program. Press any other
key to return to the editor.
DIRECT (SHIFT+F9) - Calls the direct mode in which GFA BASIC
commands can be entered and carried out directly after
pressing the RETURN key. Return to the editor by pressing
the ESCAPE key followed by RETURN.
TEST (F10) - Tests the structure and integrity of all loops
and subroutines in the current program in memory.
RUN (SHIFT+F10) - Executes the current program in memory.
CONTROL COMMANDS
----------------
Several additional commands can be carried out via keyboard
commands without using the mouse:
LEFT ARROW - moves cursor one character to the left.
RIGHT ARROW - moves cursor one character to the right.
UP ARROW - moves cursor up one line.
DOWN ARROW or RETURN - moves cursor down one line.
CONTROL+RIGHT ARROW - moves cursor to end of line.
CONTROL+LEFT ARROW - moves cursor to beginning of line.
CONTROL+UP ARROW - scrolls program up one page.
CONTROL+DOWN ARROW - scrolls program down one page.
TAB - moves cursor one tab position to the right.
CONTROL+TAB - moves cursor one tab position to the left.
HOME - moves cursor to top of present page.
CONTROL+HOME - moves cursor to beginning of program.
CONTROL+Z - moves cursor to end of program.
UNDO - cancels all changes made to a program line as long as
the cursor has not left the line after changes were made.
INSERT - inserts a blank line into the program at cursor.
CONTROL+DELETE - completely deletes the line cursor is on.
CONTROL+F - find the next occurrence of the search string
entered in the FIND command.
CONTROL+R - replaces the next occurrence of the search string
entered in the FIND command with the text string entered in
the REPLACE command.
ESC - shifts into the DIRECT mode (same as SHIFT+F9).
CONTROL+SHIFT+ALTERNATE - Breaks the execution of a program.
USING THE EDITOR
----------------
Here are some basic points to remember about GFA:
* GFA does not require archaic line numbers (thank God) and
each line's syntax is automatically checked everytime you press
the RETURN key.
* If you make a typo, a bell will ring and an error message
will appear in the menu line at the top of the screen.
* GFA automatically indents your program for you to make loops and
conditions and procedures easier to read.
* If you are using the editor in low resolution, your mouse
cursor will "disappear" about half-way across the screen. Nothing
is wrong, that's just how they support 80 columns of text in low
resolution mode (this problem does not exist in GFA 3.0 however).
* GFA does not allow concatenated lines. In other words,
only one command per program line, please.
* GFA subroutines are called PROCEDURES and must end with a
RETURN statement:
PROCEDURE example
PRINT "This is an example PROCEDURE."
RETURN
* Remarks must begin with the REM (or ' symbol) and be placed
at the beginning of a program line. Comments may be placed on the
same line as a command if separated by a ! symbol:
REM This is a remark.
' This is a remark too.
PRINT "Hello" ! This is a comment
* Variable names may consist of alphanumeric characters and
the underscore _ symbol and may be up to 256 characters long. The
assignment command, LET (i.e., LET A=2), is entirely optional.
GFA supports multiple variable types but the most useful are:
A = 12345.12345678 ! real
A% = 12345 ! integer
A! = -1 ! boolean (TRUE or FALSE)
A$ = "HELLO" ! string
* Single and multi-dimensional real, integer, boolean, and
string arrays are supported.
* Standard arithmetic operators (+,-,*,/,^) are supported
plus fast integer math functions ADD,MUL,DIV,INC,DEC plus trig
functions SIN,COS,TAN,ATN,SQR,PI and other numerical operators
MIN,MAX,INT,TRUNC,ROUND,FRAC,MOD,ODD,EVEN,TRUE,FALSE,AND,OR,XOR,
EQV,IMP, etc.
QUICKEE TIP OF THE MONTH
------------------------
Need a simple timing routine in your programs? Why not use
the built in TIMER function in GFA? TIMER is a system variable
that returns the time in 200ths of a second since your computer
was turned on. Here's a simple example of how to use it to time
something in seconds:
' TIMER demo
PRINT "GFA BASIC Timer Demo"
PRINT " Press any key to start timer..."
REPEAT
UNTIL INKEY$<>""
t%=TIMER
PRINT " Press any key to stop timer..."
REPEAT
UNTIL INKEY$<>""
et%=TIMER-t%
PRINT " Time elapsed = ";et%/200;" seconds."
THAT'S ALL FOLKS
----------------
Hope this month's article helps to get our new GFA BASIC
users off to a good start. The last I heard was that Antic
Publications in San Francisco was sold out of the GFA 2.x manuals
so if you need a GFA reference book, I recommend the following:
-> For the beginner:
GFA BASIC Training Reboot Camp
by D. Brumleve and M. Marks
-> For the advanced user:
The GFA BASIC Book
by F. Ostrowski
-> Very good all around reference (good manual substitute):
GFA BASIC Programmers Reference Guide, Volume I
by G. Miller
Each of these are about US$20-$25 and are available from:
Michtron, Inc.
576 S. Telegraph
Pontiac, MI 48053 USA
And remember, if you like what you see in GFA BASIC 2.x, you will
love the latest 3.x version, now being distributed by Antic. And
hopefully by the time you read this, the 3.x compiler will have
been released. Stay tuned for an upcoming review in Inside Info!
Till next time, keep on hackin'... <HUTCH>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GFA COMMAND TABLE (Ver 2.0+)
^^^^^^^^^^^^^^^^^
(From Probe by Alf)
1. Arithmetic Commands
ABS ADD ATN BIN$ COS DEC
DEFFN DEFNUM DIV EVEN EXP FALSE
FIX FRAC HEX$ INC INT LOG
LOGIO MUL ODD OCT$ PI RANDOM
RND SGN SIN SQR SUB TAN
2. Graphic Commands
BOX CIRCLE CLS DEFFILL DEFLINE DEFMARK
DEFTEXT DRAW ELLIPSE FILL GRAPHMODE LINE
PBOX PCIRCLE PELLIPSE PRBOX PLOT POINT
POLYFILL POLYLINE POLYMARK RBOX SPRITE
3. I/O Commands
BGET BLOAD BPUT BSAVE CHAIN CLOSE
CRSCOL CRSLIN EOF FORM INPUT FORM INPUT AS GET
HARDCOPY INKEY$ INP INP? INPUT INPUT$
LINE INPUT LIST LLIST LOAD LOC LPOS
LPRINT OPEN OUT OUT? POS PRINT
PRINT USING PSAVE PUT REAS RELSEEK SAVE
SEEK SGET SPC SPUT TAB TEXT
WRITE
4. Disk Commands
CHDIR CHDRIVE DFREE DIR DIR$ EXIST
FILES FILESELECT KILL LOF MKDIR NAME
RMDIR
5. Gem Commands
ALERT BIOS CLEARW CLOSEW FULLW GEMDOS
GEMSYS INFOW MENU ON MENU OPENW TITEW
VDIBASE VDSYS VOID WINDTAB XBIOS
6. Structure Commands
CONT DO..LOOP END ENDIF EXIT FOR..NEXT
GOSUB GOTO IF..THEN..ELSE ON BREAK ON ERROR ON..GOSUB
PROCEDURE REPEAT..UNTIL RESUME RETURN STOP WHILE..WEND
@
7. System Commands
ARRPTR BASEPAGE C: CALL DATE$ DEFLIST
DEFMOUSE DPEEK DPOKE EDIT ERR ERROR
EXEC FATAL FRE HIDEM HIMEM LPEEK
LPOKE MONITOR MOUSE MOUSEK MOUSEX MOUSEY
NEW PAUSE PEEK POKE QUIT RESERVE
SETTIME SDPOKE SHOWM SLPOKE SPOKE SYSTEM
TIME$ TIMER TROFF TRON VARPTR VSYNC
8. Data Commands
ARRAYFILL ASC BITBLT BMOVE CHR$ CLEAR
CLR CVD CVF CVI CVL CVS
DATA DIM DIM$ ERASE FIELD INSTR
LEFT$ LEN LET LOCAL LSET MAX
MID$ MIN MKD$ MKF$ MKI$ MKL$
MKS$ OPTION RESTORE RIGHT$ RSET SPACE$
STRING$ STR$ SWAP TYPE UPPER$ VAL
VAL? #
9. Other Commands
COLOR REM SETCOLOR SOUND WAVE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using GFA BASIC - Part 4
by John Hutchinson
GREETINGS
---------
Due to a couple of requests from members, this month we will
begin looking into incorporating GEM routines in GFA BASIC. GEM
is great stuff, but taking full advantage of all it has to offer
can become quite complicated. Nonetheless, we will take it a
small step at a time so as not to overwhelm you (or me!).
AN INTRODUCTION TO GEM
----------------------
GEM, or Graphics Environment Manager, is the graphics
operating system built-in to your Atari ST. It alone is
responsible for the user-friendly (ACKKK! I hate that term!)
windows, icons, and menus that mouse lovers adore. It is not
without its faults, of course, but its relative ease of use as
compared to a command line operating system has opened the door to
thousands of people who heretofore were intimidated by computers.
GEM consists of two major subsystems, namely VDI (Virtual
Device Interface) and AES (Application Environment System). These
are actually just libraries of program routines that the operating
system (or you, as a programmer) calls when needed.
The VDI contains all the essential graphic functions needed
for drawing boxes, circles, lines, etc, that make your life as a
programmer much easier. GDOS, GIOS, and Metafiles are all logical
components of the VDI but we won't concern ourselves too much
about VDI in this article. Its sufficient enough to know what
it is and that its always there ready to do its thing.
The AES, however, is of considerable more interest. It
contains all the functions that handle windows, menus, icons,
dialog and alert boxes, etc. These are the goodies that can give
your programs that extra flair and ease of use. Unfortunately,
programming the AES functions is at times a daunting task.
Fortunately, GFA BASIC comes with an assortment of AES
commands inbuilt to the language and can access all others through
procedure calls. Let's take a look at some of the simpler AES
routines you can use in your programs with very little effort.
ALERT BOXES
-----------
The GFA BASIC ALERT command places a GEM (or more accurately,
AES) alert box on the screen. An alert box is an ideal way to
provide small amounts of information to a user and receive limited
feedback in return. For example:
_____________________________________________
| |
| ------ THIS IS A SAMPLE ALERT BOX |
| \ ? / |
| \ / BIG DEAL, HUH? |
| \/ ------- ------ --------- |
| | YES | | NO | | MAYBE | |
| ------- ------ --------- |
|___________________________________________|
The alert box consists of a bordered box centered on screen
with up to four rows of text, each row consisting of up to 30
characters each. At the bottom of the alert box is from 1 to 3
buttons through which the user enters his response to the alert.
One of these buttons may be made the 'default' which may be
selected by the user simply by pressing the return key. An
optional symbol (explanation mark, question mark, or stop sign)
may also appear at the left side of the alert box.
Using the ALERT command in GFA BASIC is the easiest way to
add a bit of AES flash to your program. For example, the sample
alert box, above, would be called by this simple command:
ALERT 2, "THIS IS A SAMPLE ALERT BOX| BIG DEAL, HUH?|",
1,"YES|NO|MAYBE",choice%
The syntax for the ALERT command is:
ALERT sym,text$,default,button$,choice
The expression "sym" defines which symbol is to appear in
your alert box. Your symbol choices are:
0 - no symbol
1 - Explanation mark (!)
2 - Question mark (?)
3 - Stop sign
The "text" that you want to appear in the alert box comes
next, separating each row (up to four) with a vertical bar
character (|).
The expression "default" specifies which button in the box
will be highlighted for automatic selection by the user pressing
the RETURN key. You may have up to three buttons in your alert
box. Use "0" if you don't want a default button specified.
The variable "choice" will contain the number of the button
selected by the user. In the above sample, selecting "YES" would
set choice to 1, "NO" would be 2, and "MAYBE" 3. For efficiency,
the above sample used an integer variable (choice%) although a
real number (e.g., choice) would work as well.
Since alert boxes are controlled by the AES, all program
activity halts until the box is exited by selecting one of the
buttons. AES takes care of screen redraws so this simple one line
command is neat and effecient in use although quite limited in the
amount of information it can exchange with the user.
NOTE for GFA BASIC 3.x users: Version 3.2 and 3.5 both
possess an annoying bug when calling alert boxes. If the mouse
display is turned off via a HIDEM command prior to calling the
alert box, the mouse will remain hidden when the alert box is
displayed. The workaround is to simply do a SHOWM just prior to
calling any alert boxes.
FILESELECT BOXES
----------------
A fileselect box is another easy way to add AES flash to your
program, IF you need to read or write user-specified disk files.
When envoked, the FILESELECT command will place a standard file
select box centred on the screen from which the user can choose
the disk file to be actioned upon. The syntax for the FILESELECT
command is:
FILESELECT path$,default$,name$
The expression path$ is the name of the disk drive and folder
that is to be shown when the box appears, using the standard
hierarchical file system notation. If no path is specified (i.e.,
a null string, "") then the current disk drive path will be used.
Note that if using the GFA BASIC interpreter, this will be the
path from which GFABASIC.PRG was run.
The expression default$ is the name of the file, if any, that
is to appear when the box first appears. If the user selects "OK"
or simply presses RETURN, this default filename will be selected.
If you don't want a default, just use a null string again ("").
The expression name$ will be the name of the file that the
user finally selects by highlighting and selecting "OK" or by
double-clicking. Note that if the user selects the "CANCEL"
button, then name$ will contain a null string.
As an example, suppose you want the user to select a data
file with the filename extension of ".DAT" from a "DATA" folder
which resides in another folder called "WHIZBANG" on floppy disk
A. The fileselect command could look like this:
FILESELECT "A:\WHIZBANG\DATA\*.DAT","",name$
The fileselect box would display only those files ending with
".DAT" from the "WHIZBANG\DATA" folders on disk A and no default
file would be named. Note that although uppercase letters are
used in the example, they are not required as GFA will convert
them to uppercase automatically when the command is envoked.
DEFINING THE MOUSE SHAPE
------------------------
You don't have to be stuck with that dull, drab arrow mouse
shape. Besides the default arrow shape, there are 7 other shapes
built-in to the system that you can call with the DEFMOUSE
command. These shapes and their corresponding shape numbers are:
0 -> Arrow
1 -> Double parentheses
2 -> Bee
3 -> Pointing hand
4 -> Open hand
5 -> Thin cross hairs
6 -> Thick cross hairs
7 -> Framed cross hairs
To change the mouse shape to a pointing hand, for instance, just
issue this command:
DEFMOUSE 2
Pretty simple, huh? Just remember that whenever an AES function
is called that uses the mouse (like an alert or fileselect box)
the default mouse shape of the arrow will reappear. When the AES
function is finished, you'll have to redefine your mouse with
anouther DEFMOUSE command.
You can also define the mouse to be any shape you wish that
will fit in a 16 x 16 grid bit pattern string. The easiest way to
do so is to make use of the public domain mouse/sprite editor,
EDSPRITE.BAS. This program lets you design and save your design
to disk and even writes a ".LST" file of the implementing code to
disk as well. For example:
' Mouse-Convert data in string
LET custom$=MKI$(0)+MKI$(3)+MKI$(0)+MKI$(0)+MKI$(2)
FOR i%=1 TO 16
LET custom$=custom$+MKI$(0)
NEXT i%
FOR i%=1 TO 16
READ foregrnd
LET custom$=custom$+MKI$(foregrnd)
NEXT i%
DATA 0,0,0,64478,35344,35344,64030,35344,35344,35806,0,
35746,51754,43946,39094,35746
After running once through the code above, the custom mouse
shape may be envoked at any time by simply using this command:
DEFMOUSE custom$
EDSPRITE.BAS is very simple to use for creating custom mouse forms
and can be used to generate sprites as well (but that's another
topic).
That's enough for this month. While many of you may be
anxious to discuss windows, menus, dialog boxes, and event
management you must remember that these are relatively complex
subjects and we want to do this a little at a time, OK? But fear
not for next month I'll show you how to create a simple yet fully
functioning GEM menu system.
If you want to learn all about using real AES dialog boxes
with resource (*.RSC) files, I suggest you read the 3-part series
on "Resourceful GFA BASIC" which began with the Summer 1988 issue.
It shows you how to use a Resource Construction Set as well as
the necessary GFA code. The author? Oh, some guy by the name of
John Hutchinson. <grin> See you next time!
*******************************************
Using GFA BASIC - Part 5
by John Hutchinson
GREETINGS
---------
Last month we began looking into incorporating GEM routines
and discussed some very rudimentary examples. These included
Alert boxes, Fileselect boxes, and custom mouse shapes. This
month we will concentrate on how to set-up and use a drop down
menu with GFA. Menus can add a lot of flair to your programs but
take heart, they are NOT difficult to create (at least under GFA).
MENU COMPONENTS
---------------
Let's begin by looking at what things a typical drop down
menu system consists of:
Headers... A menu usually has from one to nine menu headers
which are displayed horizontally across the top of your screen.
These headers are used to categorize the menu 'items' which will
appear in vertical 'drop downs' below the headers when you drag
your mouse cursor over them.
Items... These are the lines of text which appear under a
menu header when the mouse cursor is dragged over it. Moving the
mouse cursor over each menu item causes them to be highlighted and
if the left mouse button is pressed, to be 'selected'.
Desk Header... Typically, the first or left most header is
given the name 'Desk'. The first item below this header is
traditionally a credits item that will present the program's
credits, e.g., "About this program". Desk accessories, if
enabled, will be presented below the credits item.
Separators... These are a special form of menu items which
consist of a line of one or more hypen or minus sign (-)
characters which are used to help separate and distinguish between
different items of a single header. These are convenient in that
GEM will not allow a separator item to be selected by the mouse.
All these menu components will be held in a standard string
array for easy access by your GFA BASIC program.
DESIGNING YOUR MENU
-------------------
The first thing to do in building a drop down menu is to get
a clear picture in your mind of exactly what you want the menu to
do and how you want it to appear on screen while in use. I
recommend you sketch your menu's intended structure on a piece of
paper before you begin coding it in GFA. A little prior thought
in this area goes a long way towards saving you considerable
frustration in the long run.
After you have your rough sketch on paper, sum the number of
headers and menu items you intend to use. To this sum, add a
number equal to the total number of headers. This will give you
the minimum size of the string array that must be dimensioned to
hold all the components of your menu. HINT: Memory is abundant
nowadays, so unless you are really concerned about it, always make
this array size slightly larger (by 5-10) than what you plan for.
This way, if you decide to add another menu item later on, you
already have space reserved for it.
CODING IT IN
------------
OK, for an example, let's suppose we wish to design a menu
which will have 3 menu headers (including the 'Desk' header) and
14 menu items (including 2 separator items). Thus, we will need
to dimension our menu string array to at least 20. Why 20 when
all we have is a total of 17 headers and items? Because you MUST
include a null or empty string ("") after the last item of each
menu header and TWO null strings after the last item of the entire
menu. As I mentioned above, however, to plan for future enhance-
ment we'll bump this up to 25 just to be safe:
'
DIM Strip$(25) ! String array for menu
'
'
Strip$(0)="Desk" ! Header
Strip$(1)=" About This Demo " ! Item
Strip$(2)="-----------------" ! "
Strip$(3)="1" ! Reserved for desk accs
Strip$(4)="2" ! "
Strip$(5)="3" ! "
Strip$(6)="4" ! "
Strip$(7)="5" ! "
Strip$(8)="6" ! "
Strip$(9)="" ! Null string
Strip$(10)="Options" ! Header
Strip$(11)=" Option 1 " ! Item
Strip$(12)=" Option 2 " ! "
Strip$(13)="-----------" ! "
Strip$(14)=" Quit " ! "
Strip$(15)="" ! Null string
Strip$(16)="Choices" ! Header
Strip$(17)=" Choice 1 " ! Item
Strip$(18)=" Choice 2 " ! "
Strip$(19)="" ! Null string
Strip$(20)="" ! Null string
'
'
MENU Strip$()
'
'
MENU 12,2 ! Disable "Option 2"
MENU 17,1 ! Checkmark "Choice 1"
'
'
ON MENU GOSUB Handle_menu ! Check for chosen items
DO
ON MENU ! The main loop
LOOP
'
'
PROCEDURE Handle_menu
MENU OFF ! Disable menu temporarily
Item%=MENU(0) ! Item selected
IF Item%=1
ALERT 0,"GFA BASIC Menu Demo| | by Hutch|",1,"Okeydoke",D%
ENDIF
IF Item%=11 ! "Option 1" chosen
MENU 12,3 ! enable "Option 2"
MENU 11,2 ! disable "Option 1"
ENDIF
IF Item%=12 ! "Option 2" chosen
MENU 11,3 ! enable "Option 1"
MENU 12,2 ! disable "Option 2"
ENDIF
IF Item%=17 ! "Choice 1" chosen
MENU 18,0 ! remove check from "Choice 2"
MENU 17,1 ! place check on "Choice 1"
ENDIF
IF Item%=18 ! "Choice 2" chosen
MENU 18,1 ! place check on "Choice 2"
MENU 17,0 ! remove check from "Choice 1"
ENDIF
IF Item%=14 ! "Quit" chosen
END
ENDIF
RETURN
'
Note that this example code will work with either GFA BASIC
2.0 or 3.0. Users of GFA 3.0 may wish to take advantage of its
flexible CASE statement instead of all those IF-ENDIF conditions.
And that's all there is to building a simple drop down menu
under GFA BASIC. A little prior planning and very little coding
effort will get you underway. For your convenience, the entire
demo program is listed below, ready to be MERGED into your GFA
BASIC interpretor.
NEXT MONTH
----------
Our discussion of GEM will continue with a brief introduction
to windows. "I don't do windows" but fortunately, GFA does!
Until then, keep hackin'!
<HUTCH>
=================================================================
' MENU DEMO for ACE[NSW]
' August 1989, by <Hutch>
'
' *** INITIALIZATION ***
' First dimension an array big enough to hold all menu data
DIM Strip$(25) ! String array for menu
'
' Now define each header and item in order of their appearance
Strip$(0)="Desk" ! Header
Strip$(1)=" About This Demo" ! Item
Strip$(2)="------------------" ! "
Strip$(3)="1" ! Reserved for desk accs
Strip$(4)="2" ! "
Strip$(5)="3" ! "
Strip$(6)="4" ! "
Strip$(7)="5" ! "
Strip$(8)="6" ! "
Strip$(9)="" ! Null string
Strip$(10)="Options" ! Header
Strip$(11)=" Option 1 " ! Item
Strip$(12)=" Option 2 " ! "
Strip$(13)="-----------" ! "
Strip$(14)=" Quit" ! "
Strip$(15)="" ! Null string
Strip$(16)="Choices" ! Header
Strip$(17)=" Choice 1 " ! Item
Strip$(18)=" Choice 2 " ! "
Strip$(19)="" ! Null string
Strip$(20)="" ! Null string
'
MENU Strip$() ! Call the menu routine
MENU 12,2 ! Disable "Option 2"
MENU 17,1 ! Checkmark "Choice 1"
'
' *** MAIN LOOP ***
' Look for menu events (mouse selections)
ON MENU GOSUB Handle_menu ! Check for chosen items
DO
ON MENU ! The main loop
LOOP
'
' *** HANDLE MENU CHOICES ***
PROCEDURE Handle_menu
MENU OFF ! Disable menu temporarily
Item%=MENU(0) ! Item selected
IF Item%=1
ALERT 0,"GFA BASIC Menu Demo| | by Hutch|",1,"Okeydoke",D%
ENDIF
IF Item%=11 ! "Option 1" chosen
MENU 12,3 ! enable "Option 2"
MENU 11,2 ! disable "Option 1"
ENDIF
IF Item%=12 ! "Option 2" chosen
MENU 11,3 ! enable "Option 1"
MENU 12,2 ! disable "Option 2"
ENDIF
IF Item%=17 ! "Choice 1" chosen
MENU 18,0 ! remove check from "Choice 2"
MENU 17,1 ! place check on "Choice 1"
ENDIF
IF Item%=18 ! "Choice 2" chosen
MENU 18,1 ! place check on "Choice 2"
MENU 17,0 ! remove check from "Choice 1"
ENDIF
IF Item%=14 ! "Quit" chosen
END
ENDIF
RETURN
'
*************************************************
Using GFA BASIC - Part 6
by John Hutchinson
GREETINGS
---------
Nice to "see" you back! I hope everyone had an enjoyable
holiday season and I trust you are ready to jump right back into
our tutorial series on GFA BASIC. If we have any new members
reading this column, welcome aboard. If by chance you are just
beginning to learn how to program in GFA, don't be discouraged if
you feel somewhat bewildered right now. Copies of the last five
'Using GFA BASIC' articles are available on back issues of the
'Inside Info' newsletter disk, available from your ever dutiful
librarian, Cathy Tuck. You'll find quite a few tips in those
earlier articles well suited for the beginner and will help you
digest the information presented here as well.
GFA BASIC 3.0 UPDATE
--------------------
The more I use GFA BASIC version 3.0, the more I like it. If
you have not yet invested in a programming language for your ST, I
strongly suggest you snap this one up. Version 2.0 was fast, but
3.0 is considerable faster and its command set has been vastly
expanded as well. And now that the 3.0 compiler has been
released, you can create standalone executable programs (PRG
files) or even desk accessories (ACC files) that are even faster
and more capable than ever before. If you are still using version
2.0, you should seriously consider an upgrade to 3.0. The
routines presented in this column will work in either version but
I may occasionally describe a 3.0 specific procedure just to
familiarize you with their differences.
DIALOG BOXES
------------
Yeah, yeah... I know that last time (a long time ago in a
galaxy far, far away) I promised that we would look at window
routines this month. But in retrospect, I thought some example
dialog box routines might be more appropriate to our discussion of
GEM. I promise that we will get around to windows soon, OK?
So what is a dialog box? It's just a little GEM goodie that
allows you, the user, to impart information to the program. Actually,
the alert box we discussed last month is itself a dialog box, albeit
a very simplistic one. Remember, that an alert box created using GEM's
AES routines (i.e., the ALERT command in GFA BASIC), restricts you to a
maximum of 3 radio buttons for user input. A dialog box, however,
allows you a great deal more flexibility. The user can input
text, select a multitude of standard and radio-type buttons, among
a host of other features. The catch-22 is that with this
flexibility comes complexity in creating a dialog box.
Most true AES dialog boxes are created through the use of a
separate utility program called a Resource Construction Set or
RCS. This utility allows the programmer to "draw" his envisioned
dialog box on screen and "paste" the objects (buttons, editable
text fields, icons, etc) in place and then save this information
to disk in what is known as a resource file. Resource files
normally have a filename extension of RSC. You may have seen
these already, though you might not have known what they were for.
True AES dialog boxes can add a lot of flair to your program.
Unfortunately, you not only have to purchase a separate RCS
program but it takes quite a bit of additional code to utilize
resource files. Describing the use of resources is beyond the
scope of this article but if you are insistent, borrow the club's
copies of START magazine issues Summer, September, and October 88
for an in-depth tutorial series on 'Resourceful GFA BASIC'. All
is not lost, however, as you DO have an alternative.
PSEUDO-DIALOG BOXES
-------------------
With GFA's graphics capability and raw speed, you can quite
often create a pseudo-dialog box that looks and functions just
like its more complex AES generated counterpart. As an example,
let's say you've written a child's program that requires the user
to enter his/her name and identify the user's sex, boy or girl.
You would like this to be all in one nice little box for ease of
use. Clearly, this is not possible in a standard alert box but
you can create a pseudo-dialog box to handle the job easily.
Included on this month's Inside Info disk is a sample routine
which creates and manages a simple pseudo-dialog box. It's in
ASCII format so you can merge it into your GFA BASIC editor and
run it. For your convenience, it's reproduced below. Let's look
at the sample code to try to make this more understandable:
(NOTE: This demo is set up for medium resolution color only!)
' PSEUDO-DIALOG BOX EXAMPLE
' for ACE[NSW]
' by <HUTCH>, Jan 1990
'
DEFMOUSE 3 ! pointing hand mouse shape
REPEAT
CLS ! clear the screen
CLR name$,sex$,ans$ ! clear the old variables
my_dialog ! call the procedure
'
PRINT "The name you entered was: ";name$ ! check the results
PRINT
PRINT "The sex you selected was: ";sex$
PRINT
PRINT "Try it again (Y/N)? ";
FORM INPUT (1) AS ans$ ! input 1 letter only
UNTIL ans$<>"Y" AND ans$<>"y"
'
' the rest of your program would go here
'
END
'
'
PROCEDURE my_dialog
'
LOCAL screen$,x%,y%,k% ! some local variables
'
' First, let's save the current screen image
SGET screen$
'
' Now, let's draw the box shape itself
DEFFILL 1,0,0 ! define our fill color
PBOX 220,50,420,150 ! draw a white box, black border
BOX 219,49,421,151 ! make the box a little thicker
BOX 218,49,422,151 ! make it thicker still
BOX 215,47,425,153 ! put an outline around box
'
' Draw the button shapes
BOX 250,120,300,140 ! the 'boy' box
BOX 247,118,303,142 ! outline it
'
BOX 340,120,390,140 ! the 'girl'box
BOX 337,118,393,142 ! outline it
'
' Add in the box text
TEXT 288,60,"Hi there!"
TEXT 255,70,"What's your name?"
TEXT 285,110,"Are you a"
TEXT 312,133,"OR"
'
' Add in a line to mark the editable text field
TEXT 239,92,"--------------------"
'
' Add in the button text
DEFTEXT ,1 ! bold face text
TEXT 263,133,"BOY"
TEXT 349,133,"GIRL"
DEFTEXT ,0 ! normal text again
TEXT 403,133,"?"
'
PRINT AT(31,11); ! position the text cursor
FORM INPUT 20 AS name$ ! enter name (20 characters max)
'
' Now handle the button selections
CLR sex$ ! same thing as sex$=""
SHOWM ! make the mouse appear
REPEAT ! loop #1
REPEAT ! loop #2
MOUSE x%,y%,k% ! check mouse position & btns
UNTIL MOUSEK ! exit when a button is pressed
'
IF y%>120 AND y%<140 ! is mouse in button area?
IF x%>250 AND x%<300 ! is mouse over 'BOY'?
sex$="boy"
ENDIF
'
IF x%>340 AND x%<390 ! is mouse over 'GIRL'?
sex$="girl"
ENDIF
ENDIF
UNTIL sex$<>"" ! until sex$=something!!!
'
SPUT screen$ ! restore original screen image
'
RETURN ! all done!
CODE TAKE-APART
---------------
Note that the above routine is written as a procedure so it
can be easily incorporated into your program. The first thing the
procedure does is define some local variables that will be used
only by this procedure and nowhere else. You could have a global
variable called x% elsewhere in your program but it would not be
changed by the LOCAL x% in the procedure. You also save on memory
as LOCAL variables are cleared when you exit the procedure. LOCAL
variables are not always needed, of course, but it's a good habit
to get into.
We don't want our dialog box to permanently screw up whatever
is on our screen so we save the current screen image as a string
with SGET. Then we use DEFFILL to define our fill patterns as
desired and draw the dialog box shape with PBOX and BOX. Next we
add whatever dialog box text we want and draw the buttons. Then
we position our text cursor just so and ask the user to input
his/her name with the FORM INPUT AS command. The parameter of
'20' restricts the user to input 20 characters or less.
Next, we enter a double REPEAT-UNTIL loop. This nested loop
(one within another) handles our mouse and button selection. The
first loop repeats itself forever until the variable sex$ has been
defined as something other than "" (a null or empty condition).
Then the second loop goes on until the user presses a mouse
button. If the mouse is positioned over one of the two boxes when
a mouse button is clicked, sex$ is set appropriately and we exit
the loop. Finally, we restore the original screen with a SPUT
command and RETURN from the procedure.
And there you have it. A functioning dialog box created with
simple GFA commands. Admitedly, this is a VERY simplistic dialog
and more complex ones would be, well, more complex. You could
easily jazz this one up with a few bells and whistles, however.
How about an exit ("OK") button? How about using GRAPHMODE
commands to highlight the buttons when they are selected? How
about a colored border around the box? How about using
GRAF_GROWBOX and GRAF_SHRINKBOX for special effects when opening
and closing your dialog box. Why not ring a bell or another sound
when a button is selected? And why not use blue text for 'BOY'
and pink for 'GIRL'? And how about... well, you get the idea.
WRAP IT UP
----------
Remember, the only reason a pseudo-box such as this is
feasible is because of GFA's speed. It just wouldn't look right
if it took a few seconds to draw the box would it? Of course,
there ARE ways to speed up this example. We could use an XBIOS
routine to draw the box on a hidden (logical) screen in memory,
save it to a string with the GET command, and then pop it on our
visible (physical) screen with PUT. This technique relies on a
method known as page-flipping, but we'll save that for a later
discussion.
Until next time, keep on 'hackin'!
<HUTCH>
* * *
Using GFA BASIC - Part 7
by John Hutchinson
GREETINGS
---------
This month I thought we would discuss something a little more
esoteric than usual, specifically, page flipping. Page flipping
is a technique used for certain special effects, most often for
animation. It gets its name from the manner in which the
animation is perceived by the human eye. If you take a pad of
paper and draw a stick figure of a man on each page, altering each
one ever so slightly, then flip through the sheets rapidly, it
will look as if the figure is moving. Thus the name "page
flipping" (real tech, huh?). It is essentially the same principle
used in cartoon animation or any moving pictures for that matter.
You can use the same trick on your ST. In its simplest
terms, what we want is to have TWO screens in our computer's
memory at one time and rapidly switch the display between them,
thus providing animation or the illusion of movement. This is
easily done with GFA BASIC, as shown in the following demo:
' *** Page flipping demo #1 ***
'
' First reserve some space for the alternate screen. It's address
' must be on a 256K boundary therefore the "/4".
DIM s%(32255/4)
'
' Now determine the addresses of the logical and alternate screens.
screen_1%=XBIOS(3) ! Logical screen address
screen_2%=VARPTR(s%(0))+255 AND &HFFFF00 ! Alternate screen address
'
' Draw a ball on screen #1.
CLS
PCIRCLE 100,100,20
TEXT 200,100,"screen #1"
'
' Now do a "page flip" by changing pointer to alternate screen #2.
VOID XBIOS(5,L:screen_2%,L:screen_2%,-1)
'
' Draw another ball in a different position on alternate screen #2.
CLS
PCIRCLE 110,110,20
TEXT 200,100,"SCREEN #2"
'
' Now alternate displaying the two screens (animation).
REPEAT
FOR i%=1 TO 10
VOID XBIOS(5,L:screen_1%,L:screen_1%,-1) ! Flip pointer to #1
PAUSE 5
VOID XBIOS(5,L:screen_2%,L:screen_2%,-1) ! Flip pointer to #2
PAUSE 5
NEXT i%
'
VOID XBIOS(5,L:screen_1%,L:screen_1%,-1) ! Flip pointers back
'
CLR ans$
PRINT AT(20,12);"Want to see it again (Y/N)? ";
FORM INPUT (1) AS ans$
ans$=UPPER$(ans$)
PRINT AT(20,12);" "
UNTIL ans$<>"Y"
'
END
Understandably, an animation sequence with only two frames
(images) is not be very exciting. You could draw many frames,
saving each one to a particular segment of memory, but this takes
up a LOT of memory as each screen needs 32K! To get around this,
we make use of the ability to swap between the logical and
physical screens with that tricky 'VOID XBIOS(5,L:a%,L:b%,-1)'
command. By setting a% equal to the address of screen_1 and b%
equal to the address of screen_2, we can actually draw on one
hidden screen while we view the other. Take a look at the next
program, still quite simple, but demonstrating this technique:
' *** Page flipping demo #2 ***
'
' First reserve some space for the alternate screen. It's address
' must be on a 256K boundary therefore the "/4".
DIM s%(32255/4)
'
' Now determine the addresses of the logical & alternate screens.
screen_1%=XBIOS(3) ! Logical base address
screen_2%=VARPTR(s%(0))+255 AND &HFFFF00 ! Alternate screen addr
'
' Draw a ball on screen #1 and save it as a string image.
CLS
PCIRCLE 100,100,20
GET 80,80,120,120,c$
CLS
'
' Now alternate displaying the two screens, changing during flips.
REPEAT
FOR i%=1 TO 175 STEP 5
VOID XBIOS(5,L:screen_1%,L:screen_2%,-1) ! See #1, draw on #2
VSYNC ! optional (avoids flicker)
CLS ! clear the screen
PUT 20+i%,20+i%,c$
VOID XBIOS(5,L:screen_2%,L:screen_1%,-1) ! See #2, draw on #1
VSYNC
CLS
PUT 21+i%,21+i%,c$
NEXT i%
'
VOID XBIOS(5,L:screen_1%,L:screen_1%,-1) ! Flip pointers back
'
CLR ans$
PRINT AT(20,12);"Want to see it again (Y/N)? ";
FORM INPUT (1) AS ans$
ans$=UPPER$(ans$)
PRINT AT(20,12);" "
UNTIL ans$<>"Y"
'
END
Note the use of the VSYNC commands in the above code. All
the VSYNC command does is hold changing the screen until the
beginning of the vertical blank interrupt. That's techo talk for
"reducing flicker". It does have a drawback in that it tends to
slow things down quite a bit. To see how much, comment out the
VSYNC commands and try the sample code again. You'll notice the
animation runs much faster but with a little more screen flicker.
The choice is up to you whether or not to use VSYNC. It all
depends on your application.
One important point you need to remember is to always change
the logical and physical screen pointers back to the original
values so that "what you see is what you get". If you don't, your
commands will continue going to the hidden screen instead of the
visible one. That can get confusing might quickly!
I should mention that there are a number of ways to
accomplish page flipping but I use the techniques shown above most
often as they prove to be the most memory efficient (the disk
newsletter **InfoDisk** program uses page flipping extensively).
As you can see, these are VERY simple demonstrations, but
perhaps you get the idea. If it all seem confusing right now
(and it should be) don't sweat it. You really don't need to know
WHY it works, just HOW. With a little experimentation, you will
soon come to understand how to get the most out of page flipping.
Til next month.... keep on hackin'!
<HUTCH>
*********************************************
Using GFA BASIC - Part 8
by John Hutchinson
GREETINGS
---------
This month we will take a break from our discussion of GEM
and related techniques in order to take a look at a few more
practical procedures that can be used in most any program. I'd
like to thank our editor, Greg Smith, for the suggestion for this
month's topic. Readers' feedback is always appreciated!
ANY COLOR YOU WANT... AS LONG AS IT'S BLACK
-------------------------------------------
How many times have you used a program on your ST only to
find that when you exited the proggy that your desktop colours had
changed, usually to something billious? This is a common problem
with many public domain programs that were, well, let's be honest
here, just not written very well. You may have come across the
same problem in a program you have written yourself. No worries,
for you will be amazed at how EASY it is to avoid "MUDS" (Messed
Up Desktop Syndrome) in just a few short lines of code.
But first, a little background info on how the ST manages all
those 512 wonderful colours it's capable of producing. In low
resolution, the ST can display any 16 of those 512 colours at one
time (without resorting to software tricks as in SPECTRUM 512).
In medium resolution, the choice narrows to any 4 colours and in
high resolution you are stuck with good old black and white. You,
the programmer, decide which colours you want displayed in low and
medium resolution modes. This colour choice is known as the ST
colour palette. At the desktop, you can adjust these colours to
your liking via Atari's Control Panel Accessory. Among other
things, it controls the intensity of your ST's three primary
colours of RED, GREEN and BLUE from which ALL those 512 possible
colours are derived.
For example, setting each primary colour to a value of 0
(minimum intensity) yields BLACK. Conversely, setting each to its
maximum setting of 7 yields WHITE. Set RED to 7, GREEN to 6 and
BLUE to 0 gives you a bright YELLOW colour. Set RED to 6, GREEN
to 2 and BLUE to 5 yields a vile purple hue. By juggling the
values of each colour, you can get up to 512 different colour
combinations (8 * 8 * 8 = 512). Each colour in our palette can
then be described by the amount of RED-BLUE-GREEN in its makeup.
Therefore, WHITE is 777, BLACK is 000, pure RED is 700, etc.
These values are stored in the ST's colour registers (16 of 'em).
OK, so how do you put this knowledge to work for you? Let's
assume you have a program which displays different colours using
GFA's SETCOLOR command. It works find and dandy but you don't
want it to alter the desktop colours. Here's how to avoid it:
Near the beginning of your program or in your initialization
routine, include the following line:
DIM palette%(15)
This simply dimensions an integer array to 16 (0-15) places.
Next, gosub to the following procedure:
PROCEDURE Save_palette
FOR i%=0 TO 15
palette%(i%)=XBIOS(7,W:i%,W:-1)
NEXT i%
RETURN
XBIOS(7) is a special operating system routine which sets or
determines the value of a given colour register. What this
routine does is look at the desktop's colour registers and saves
them to the integer array palette%().
OK, so now you can go ahead and change colours in your
program to your hearts content. But... before you exit or end
your program, gosub to the procedure shown below first.
PROCEDURE Restore_palette
FOR i%=0 TO 15
SETCOLOR i%,palette%(i%)
NEXT i%
RETURN
See what we just did? We restored the colour registers to
the values of the original desktop colour palette. Simple, eh?
Ah, but what if you are using MEDIUM resolution? There are only 4
colour registers involved then, right? Well, not really. It's
just that only the first 4 registers are used. So while you could
change the FOR-NEXT loops shown above to read from 0 to 3 instead
of 0 to 15 it 'doesn't matta' because the other 12 registers will
just be ignored anyway. So you can use the above routines for
any screen resolution.
HOLY DESK ACCESORY, BATMAN!!!
-----------------------------
One of the problems with GFA BASIC 2.0 rears it's ugly head
when your program calls a desk accessory. Oh, it usually works
alright. It's just that when you close the accessory, you are
usually left with a big gaping "hole" where the accessory was!
Actually, this "hole" is just a portion of the screen which was
not properly updated when the accessory was closed allowing a
background colour to show through. Not a devastating bug, but an
unsightly one anyway. Well, GFA BASIC 3.0 pretty much cured this
problem but there is an EASY fix for 2.0 users.
Just before the desk accessory is called, save the current
screen with a command such as:
SGET screen$
This saves the current screen data in a 32000 byte string.
Then allow the desk accessory to be called up, used, and
closed. Immediately after closing the desk accessory, get rid of
the "hole" left behind by restoring the entire screen with:
SPUT screen$
Sure, this may be a "sledge hammer" approach, but it works
and it's so fast as to be unnoticeable! Sometimes the best
solution IS the easiest too! (I still recommend GFA 3.0 though).
BUFFER STUFFER
--------------
As you may or may not know, the ST has a keyboard buffer.
This is a tiny bit or memory which holds your most recent
keystrokes (up to 256 I think). This is usually a good idea in
that it allows the ST to keep up with you light speed typists.
However, it can lead to problems in programs you write which
requires user input of some kind.
For example, at some point in your program you may ask the
user to "Press any key to continue". If the user has not pressed
any key up to that point, all should go according to plan. But if
he or she fell asleep with their head on the keyboard, that old
keyboard buffer will be plumb full and ZAP right through your user
friendly prompt! Again, an easy fix can be gained through the use
of another XBIOS call. Immediately before you want the user to
enter something at the keyboard, issue this command:
LPOKE XBIOS(14,1)+6,0
What's it do? Well, this is your all purpose "Buffer
Stuffer" command. It fills the buffer with "null" values (0) or
in other words, it erases it! So now the user can enter in his or
her response without having to worry about earlier accidental
keystrokes messing things up.
OK, that's all well and good. But what if you want to know
what the last keystroke was that the user made? You may not know,
but the keyboard buffer sure does. To find out, just do this:
key%=LPEEK(XBIOS(14,1)+6)
The integer variable key% will now hold the keyboard value of
the last key the user pressed. Keep in mind that this is NOT the
ASCII value (A=65, B=66, etc). This is the KEYBOARD value which
is very different and will require some experimentation on your
part to fully understand.
RESOLUTION REVOLUTION
---------------------
I've mentioned this one before but it's so handy and so
simple it bears repeating again. To find out what resolution the
program is currently in, use our old friend XBIOS(4):
res%=XBIOS(4)
If res%=0 you are in LOW resolution; 1=medium and 3=high.
Yes, you can even change the resolution if you wish although it
may cause you fits if you are using GEM routines in your program.
I told you how to do this back in PART ONE of this series so dig
it out or get a copy from the ACE BBS or PD Librarian if curious.
CHECK OUT?() THE PRINTER
------------------------
Have you written or used a program that requires use of a
printer? What does the program do if you try to print something
from it and you forgot to turn the printer on? Does it give you a
nice error message (politely of course) or does it just sit there
waiting for the ST to realize something went wrong? Well you can
ensure the former and avoid the latter with a very simple but
often overlooked GFA command called OUT?(). All it does is send a
single byte to a specified peripheral (your printer, keyboard,
RS232 port, MIDI port, monitor, etc) and determines its status. A
returned value of -1 (meaning TRUE) indicates the peripheral is
ready. A value of 0 (FALSE) means it is not ready. Here's an
example routine:
PROCEDURE check_printer
' *** Makes sure printer is turned on and online
REPEAT
IF OUT?(0)=0
ALERT 3,"| Please place your | | printer on-
line.|",1," OK | CANCEL ",d%
ENDIF
UNTIL OUT?(0)=TRUE OR d%=2
RETURN
The OUT?() command has a sister command known as INP?().
Logically enought,the INP?() command READS a single byte from a
peripheral device. It's most common use is shown below:
PRINT AT(1,1);"Please press any key"
~INP(2)
PRINT AT(1,3);"Thank you"
The "~" symbol is short for "VOID". What this means is to
read the value and then throw it away. Sounds dumb at first but
remember, we didn't care WHAT key the user pressed. We just
wanted to know WHEN he did so! What do the numbers in parentheses
following the OUT? and INP? commands mean? Glad you asked. They
represent the device number according to the chart shown below:
0 Printer
1 RS232 Serial Port
2 Keyboard
3 MIDI Port
4 Keyboard Processor
5 Monitor
ACE[NSW] BULLETIN BOARD SYSTEM
------------------------------
If you own a MODEM and have not checked out the ACE[NSW] BBS
then you are definitely missing out! Andrew Davies and Swavek
Jabrzemski and several others have put a lot of effort into the
system to make sure it offers something for everyone. It's
available 24 hours a day; has the latest PD software available for
downloading; local, national and international message areas; on-
line games; trading post and much, much more. We even have a
special section just for programming hints. Give the system a
call at (02) 664-1303 right now and check it out!
If you don't have a MODEM, then GET one. It's the only way
to have the most fun you'll ever get for a 30 cent phone call!
MENU BUILDER UTILITY
--------------------
Back in 'Inside Info #44' in 'GFA Part 6' we discussed an
easy way to create drop-down GEM menus in GFA BASIC. Well, Mr.
W.J. Sanderson of Haymarket, NSW asked if there was a utility
available to make menu creation just a little bit easier. I'm
happy to report that indeed there is such a utility! It's called
'MENU BUILD' and was written by David Plotkin, a frequent
contributor to Antic's START magazine. Although somewhat limited
in the number of menu items it supports, it is extremely easy to
use. It is available on the ACE[NSW] BBS or from Cathy Tuck, the
club PD software librarian. There is a wealth of superb public
domain programs available in the library. Be sure to check out
the update in this issue and see or call Cathy for more info. You
can even order your PD selections through the mail by using the
order form on this disk. Make use of the PD library!
Til next month... keep on hackin'!
<HUTCH>
**********************************************
Using GFA BASIC - Part 9
by John Hutchinson
GREETINGS
---------
News from Germany is that a whole new series of GFA BASIC
modules is about to be released from GFA Data Media, the European
distributor for all GFA products. Unsure at this time if a
totally revamped version of GFA BASIC itself will be forthcoming
but it wouldn't surprise anyone if it did appear. Rumour has it
that the "new" GFA will contain much improved commands and
functions for accessing the special sounds and graphics
capabilities of the STe machines as well as earlier STs. Hmmm,
rather sounds like a STOS competitor doesn't it? When we we see
these goodies here in Australia? Well, I'm not holding my breath
but I hope it will be soon.
READING A DISK DIRECTORY
------------------------
GFA includes a number of handy commands and functions to help
you deal with disk directories, pathnames, and such stuff. If
your program needs to write a large data file to a floppy,
wouldn't it be nice to check to see if the file will FIT on the
disk BEFORE attempting to write to it? You can easily check to
see how much free space exists on a given disk using the DFREE(n)
command where n=the number of the drive you wish to check. You
can set n to a value from 0 to 15 where 0 is the standard drive
and 1 to 15 is for disk drives A through O.
Other directory related commands that come in very handy are
CHDRIVE (changes the current drive); DIR$(n) (shows the current
path of a disk); CHDIR (changes the current directory); DIR and
FILES (show or print the contents of the current drive); MKDIR and
RMDIR (make and remove directories/folders from a disk); EXIST(n$)
(looks to see if a given filename exists on the disk); NAME
(names/renames disk files); and KILL (deletes disk files).
These commands are all well and good but what if you need to
read a disk directory into a string for later display or
manipulation? Sorry, but the commands DIR$ and DIR don't do that.
Perhaps the next version of GFA will include a simple one-shot
command but for now, you can make use of a GEMDOS function and the
~FSETDTA() command. Whenever you need to read (and store) the
contents of a given disk directory, just use the routine
demonstrated in the following example:
DIRSTRNG.LST
This program demonstrates the use of ~FSETDTA [GEMDOS(26)] to
read a disk directory into a character string.
dir("A:\","*.*") ! Specify the path & mask you want
PRINT "Files:"'file_count&
FOR count&=1 TO file_count&
PRINT file$(count&),length%(count&)
NEXT count&
PROCEDURE dir(path$,mask$)
DIM file$(300),length%(300)
ABSOLUTE length%,BASEPAGE+154
~GEMDOS(26,L:BASEPAGE+128)
search$=path$+mask$+CHR$(0)
finished&=GEMDOS(78,L:V:search$,0)
DO UNTIL finished&
file$=CHAR{BASEPAGE+158}
INC file_count&
file$(file_count&)=file$
length%(file_count&)=length%
finished&=GEMDOS(79)
LOOP
RETURN
AND A FOND FAREWELL...
----------------------
That's all from my end, folks. Try as I might to keep a low
profile, my ruse has been discovered and I am being recalled back
to work in the United States. My membership in A.C.E. has been
but one of the highlights of my all too short stay in this
fabulous land we lovingly call Oz. Many thanks to all those
friends and associates who have made me feel so welcome here, and
taught me what "mateship" was really all about. I hope this
column has been of some minor help (or at least amusement) to
those interested in GFA BASIC.
Last but not least, enjoy your Atari computer, but don't
forget your families in the process... ya gotta have your
priorities in the right place!
And remember... keep on hackin'!
<HUTCH>
****************************************
