mrr@rayssd.UUCP (02/05/85)
New Product Review: GRAX 1.1
Company: General Overall Design,
P.O. Box 2039
West Lafayette, IN 47906
Media: Disk
Price: $15 (source available for $30)
Some weeks ago, a new graphics product for the Commodore 64, named GRAX,
was announced to the net, along with a request for users to test it. The
product was purported to "blow the competition out of the water" or "blow the
competition's doors off" or similar claim. I enthusiastically responded,
having in mind the conversion of a sketchpad program I created for use with
Commodore's Super Expander.
In a couple of hours after receiving my copy of GRAX, I had decided that
I probably didn't want to make the conversion. As a matter of fact, I really
didn't want to pursue the matter any further. However, after some soul-
searching and gathering together what little self-discipline I have that
isn't already channeled into my latest diet, I decided to go ahead with the
review anyway.
Right up front, let me say that the package works as documented and
works well. The authors obviously have a good grasp of the complex graphics
mechanisms and modes in the Commodore 64 and have made an honest effort to
exploit them fully. My major observation with regard to performance is that
the plotting algorithms underlying this package are FAST - from slightly to
dramatically quicker than the other packages I have used. Painting speed
is very impressive. The tradeoff for this speed appears to be the lack of
sufficient error checking, however. The document states that out-of-bounds
parameters usually give unpredictable results. The syntax, though it may
be quite confusing to a beginner, is quite flexible. Default values are
implied in just about every situation. Parameter lists typically consist of
sublists, terminated by a semicolon. Where appropriate, these sublists can
be repeated (as in drawing lines, where each sublist is a coordinate pair).
The elements of a sublist are separated by commas and the last element of a
sublist may be repeated, when appropriate. Parameter lists are enclosed by
parentheses.
"OK, so where's the boeuf?", you ask. This package adds 27 new keywords
to BASIC 2.0. All new keywords begin with the letters "GR", followed by an
additional letter or special character, thus forming a new, unique keyword.
A reasonable example of this is the GRB command which fills a Block of the
screen with color. The flip side of the coin is GRI which fIlls (paInts?) a
shape. BASIC syntax conventions imply that a keyword followed by a
parenthetical expression ( PEEK, SIN, SQR, etc) is a function call which
returns a value. This may, in turn, be used as part of an expression. All
parameterized GRAX commands require parentheses, yet not one is implemented
as a function. Commands which should be functions, such as GRX (pixel test)
require a subsequent call to USR to retrieve the returned value. I feel this
is a little too "kludgey" for a commercial package, even if it's only $15.
It is apparent that the authors chose to patch BASIC by copying it to
underlying ram and replacing the code for the STOP token with a call to GRAX.
This strategy favors ease of implementation (of GRAX, not the application),
rather than ease of use and more self-documenting programs. It is not very
difficult to extend BASIC by redirecting crunch, list and execute vectors
and adds only miniscule overhead to execution time. I also object to the
"packaging" of GRAX. I view packages of this sort as "add-ons" to an
application, which should be transparent to the end-user. In order to use
GRAX, you must first load it, run it and then load and run your application.
I would much prefer to see GRAX object delivered as a program which is loaded
and run, either interactively or by the application, as follows:
LOAD"GRAX",8,1:SYSXXXX:REM LOAD AND INITIALIZE GRAX
Other minor peculiarities include GRAX's ignoring the STOP key and leaving
the screen in "strange mode" if you abort via RUN/STOP - RESTORE. I was
very disappointed to note that though there are some extensions to access the
SID chip (synthesizer) there is no support for the joysticks, paddles or
light pen. Some programming aids, such as auto line numbering, renumbering and
merging are also niceties that I feel an add-on should offer. The document is
fairly well done, consisting of about 40 double-sided pages. There are a few
typos and minor errors, but the text is clearly written. The examples could
be a little better, but the disk comes with a complete set of demo programs
which illustrate every feature of GRAX. A few of the demos are downright
impressive.
GRAX Commands
Initially, this review was going to include a comparison of like
commands in the Super Expander and Simon's Basic but the project proved too
ambitious (or I'm getting lazy) so I yanked that section. Where appropriate,
I've added comparisons to the descriptions of the GRAX commands. If there is
sufficient interest, I'll review those products later.
GR@ - Read the disk error channel.
GR@("command$") - Send a command to the disk. The need to type parentheses
AND quotes is annoying.
GR$ - Print directory
GR$(drive;pattern$) - Allows alternate drive selection and wildcard
specification.
GR&(i,j) - Continue previous plot. Continuation for GRG, GRH, GRW.
GRA(display code) - Used in conjunction with USR(128+0)..USR(128+7) to copy
a character definition matrix to a program variable.
GRB(x,y,i,j;color,bit) - Color blocks of the screen; x,y are the starting
coordinates; i,j are the width and depth; color,bit are the color code and
"layer" (0..3) to be set.
GRC(bkgd0,ext1,bkgd2,bkgd3;print,smc0,smc1) - Set screen colors
GRD - Select default video modes.
GRD(charbase,vidmatrix,bank;"bcemrv") - Set new video modes. It would be nice
if this command could clear the screen as well.
GRE - Build Multi-Set. Builds a special character set for use in low-res
multi-color mode which will provide reasonable screen display codes for each
combination of the four multi-colors. This is a nice feature that I haven't
seen before.
GRF - Clear all sound registers.
GRF - (volume,resonance,cutoff;"123hblxo") - Set sound chip filter parameters.
GRG(x,y,bit;i,j) - Plot points and lines. By repeating the i,j coordinates,
complete polygons may be drawn. However, this command pales in comparison to
Super Expander's DRAW command which allows vectors (distance;angle) to be
specified in addition to coordinates.
GRH(char,fill$;x,y,bit) - Set up user defined characters.
GRI(x,y,bit) - Fill (paint) area. Fills an area created by GRG or GRO.
GRK - On first call, disables warm start protection. Second call returns to
BASIC.
GRK(a,x,y,p;entry) - A very nice interface to the KERNAL. a,x,y,p represent
the contents to be loaded into the a,x,y and status registers prior to calling
the desired entry address.
GRL(x,y;i,j) - Lineprinter dump, works for both lo-res and hi-res.
GRM - Same as GRK
GRM(printbit,bit) - Sets multi-color shading. printbit can be either 0 (light)
or 1 (dark) and affects the color layer specified by bit (0..3). Used in
conjunction with GRI
GRO(x,y,bit;radius,mask) - Draw circle; mask, if specified, is an 8 bit value
indicating which arcs of the 8-segment circle are to be displayed. radius
is both x and y, thus preventing scaling to achieve "true" circle. This
command draws a very fast circle. However, the lack of separate x and y radii
prevent drawing a "true" circle. Also, the arbitrary choice of 8 segments
severly limits the capabability for drawing arcs.
GRP(x,y) - Test point. Must be followed with USR(0) to determine if bit is
set. USR(1) returns the color code of the bit, if the bit is on.
GRR(window) - Copies the specified sprite definition block, window (0..255), to
the GRAX pattern space which may be subsequently read with
USR(128)..USR(128+62) into a program variable.
GRS - Turns off all sprites
GRS(sprite,window,"bdmxy";x,y,color,smc0,smc1) - Defines characteristics for
a given sprite.
GRT - Copy upper case character set from ROM to RAM
GRT(address) - Copy character set at address to RAM
Prior to using this command, you must have established the new character base
using the GRD command.
GRV - Kill all voices.
GRV(voice,attack,decay,sustain,release,"npsteryg",frequency,pulse)
Turns on or off one or more of the three SID voices and sets the associated
parameters.
GRW(window,fill$;x,y,bit) - Used in conjunction with GRS to put a desired
shape on the screen as a sprite.
GRX(x,y) - Pixel test. Similar to GRP but used with lo-res screen, I think.
GRY(flag) - Check amount of memory available, per GRD, for a bit-map screen
or character set. If flag=0, print an error message if no room. If flag=1,
set an error flag which may be read with USR(0).
GRZ - Clear hi-res screen
GRZ(bit) - Clear hi-res screen and set to color; bit= 0,85,170,255.
If you hadn't noticed already, this review is highly subjective. I have
evaluated GRAX based on my own experiences, likes and dislikes. I did perform
some minor benchmarks and have determined that GRAX is quicker than either
the Super Expander or Simon's Basic. However, as an application's complexity
increases, the ratio of time spent performing calculations and other "overhead"
processing to time spent plotting grows, the net effect is not as great.
In terms of pure graphics capabilites, my choice is the Super Expander.
Though it doesn't provide the degree of support for character graphics that
GRAX does, its self-documenting, easily-remembered keyword set are more
friendly and at about $18 is a competetive product. The power and ease of use
of the DRAW and CIRCLE commands are unmatched. GRAX provides only limited
arc drawing capability (multiples of 1/8 of a circle, using GRO) and no
vector capability, dumping the burden of much trigonometry on the programmer.
Since graphics are usually only a portion of a given application,
however, I find myself ignoring my Super Expander and sticking with Simon's
Basic (at least, until my Oxford Pascal compiler gets here). Simon's Basic
adds 114 new commands to BASIC 2.0 and offers some very nice features,
including structured programming keywords which, if used cleverly, can allow
you to write just about any program without a goto or gosub. Combined with
the MERGE command, modular programming, even in a crummy language like BASIC,
becomes a semi-reality. Since Simon's also offers a fairly rich set of
graphics commands, it has become my choice for most new applications. I
guess what I'm trying to say is that add-on packages should offer more than
a specialized set of features, especially if they must run exclusively of
any other enhancements
In closing, let me say thanks to Kevin Braunsdorf and Marc Mengel for
allowing me the opportunity to test their product. I hope this review hasn't
gained me any enmity. I think the guts of GRAX is good stuff - the outside
needs some polish and we could use some more "extras".
Mark Rinfret
--
----------------
Mark R. Rinfret
SofTech, Inc.