Copy Link
Add to Bookmark
Report
Silicon Times Report Issue 0060
ST REPORT WEEKLY ONLINE MAGAZINE
--------------------------------
Monday, NOV. 31, 1988
Vol. II No. 60
==========================================================================
ST Report Online Magazine Inc.
------------------------------
Post Office Box 6672
Jacksonville, Florida
32236 6672
R.F. Mariano
Publisher - Editor
====================['The Original Online ST Magazine']===================
Headquarters Bulletin Boards
----------------------------
North South
201-343-1426 904-786-4176
Central West
216-784-0574 916-962-2566
=======================================================================
CONTENTS
========
~ From the Editor's Desk.............~ The Melting Pot Runneth Over..
~ DC Atari FEST......................~ Pro GEM Windows #11...........
~ The Archival Bit...................~ A New Blivitt!................
~ ST REPORT CONFIDENTIAL ............~ PC Pursuit Help...............
========================================================================
AVAILABLE ON: COMP-U-SERVE ~ DELPHI ~ GENIE ~ THE SOURCE
========================================================================
From the Editor's Desk;
Some folks said, "you have too much editorial content in ST Report"
and I tended to agree with them. However, after reviewing the situation a
number of times, this conclusion has been reached. ST Report is looked to
for hard hitting information. Being up to date, as accurate as humanly
possible and timely.
We are concerned mainly with the Atari ST market and just about
everything that occurs in that market. Sure, we ARE critical of Atari
when they obviously need it. On the other hand, we are the first to pass
out compliments when deserved. We will not "sugar coat" any situation or
soft peddle any issue. ST Report pledges to bring you, the Atari user,
the most up to date, accurate, information possible.
In another development, we at ST Report have heard that the userbase
in general is an easily confused group of users. We discovered that this
is one of the totally inane reasons given by Atari, when asked, why they
didn't incorporate more of the fine features seen in the UIS file selector
in the new TOS 1.4. After having stated this, they then come along with
this as the second reason "There is absolutely no room"....they really do
think we are idiots and boobs out here! That is not an excuse, it is an
admission of incredible "tunnel vision"!
If one were to "look" at two locations in the TOS 1.4 code, one can
find "room", ($FCF716 and $FD2404). To selfishly consume valuable space
to "hide" love notes in TOS is the same to me as carving your initials in
your desktop at 4th grade school. Also, TOS could be converted to Machine
Language (ML) it would then become (A) much faster, (B) much smaller in
size, thus allowing for further first class enhancements it so desperately
needs.
Some have called UIS a kludge, I say that if Atari were to
incorporate it's DELUXE and needed features into TOS 1.4, it would be
called a STROKE OF GENIUS.
Ralph.....
As we approach another Christmas Holiday, Atari is prepared to miss the
boat again. No real quantities of ST product for sale in the USA. What
fantastic corporate leadership and planning! And you thought that the
Katzenjammer Kids were only cartoon characters.
**************************************************************************
NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
FOR A LIMITED TIME ONLY
COMPUSERVE WILL PRESENT $15.00 WORTH OF COMPLIMENTARY ONLINE TIME
to the Readers
ST REPORT ONLINE ELECTRONIC MAGAZINE
NEW USERS SIGN UP TODAY!
Call any of the St Report Official BBS numbers
(Listed at the top of ST REPORT)
or
Leave E-mail to St Report, Ron Kovacs or Rex Reade
Be sure to include your full mailing address so your
Compuserve kit can be immediately mailed to you!
Expires 11-30-88
NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
**************************************************************************
So, you'd like to tell that guy Rex Reade a thing or two Eh?
-------------
Spend an evening with ST Report, ask the questions you would like
answered, find out what motivates ST Report, become informed.
YOU WILL HAVE YOUR CHANCE!
--------------------------
NOVEMBER 09, 1988 WEDNESDAY, 8 P.M. EST
COMP-U-SERVE CONVENTION CENTER
All are invited to Attend
--------------------------------------------------------------------------
THE MELTING POT RUNNETH OVER
============================
by Rex Reade
This is the time of the year when speculation runs high and facts
seem to become obscure amid the dreams and hopes for the future. That is
the limbo of the days prior to Fall Comdex every year. Obvious by their
absence in the Comdex Preview is Atari, Why? easy....they registered too
late to make it into the preview, not even into the maps and directions on
how to find an exhibitor. Great planning at the corporate level,
(outstanding guys). You do know Atari had no plans to attend the Fall
Comdex earlier this year. It seems some voice in the distance said "Hey
Atari, wake up the whole country is WATCHING you and what you do this
year".
Developers, Distributors, Dealers, Usergroups and Users have long
been known to be the life blood of any company doing business directly
with the consumer. Every major, well organized, corporation will readily
admit that each is a vital component in the formula for success. Does
Atari? Apparently not..
Consider these latest moves:
----------------------------
A) Atari routes a huge percentage of it's ST product to Europe thus
justifying Developer "dropout" in the USA.
B) Atari drops the "Houston Project" thus indirectly confirming the
often percieved, "Lack of true corporate leadership and direction
in the USA." I feel sorry for all the Houston Dealers who, in
the past few months were "busy" singing the praises of Atari.
This could go on and on, but that is not the point here, the point
is this; Atari needs:
A) A Professional Marketing Department.
B) A full National Sales Department.
C) A REAL National Service Organization.
D) Corporate Leaders, not the Katzenjammer Kids who appear to SEE
the company like its a HOBBY!
E) TO DEVELOP THE US MARKET PROPERLY
F) TO Recognize the signs, look at Atari in Europe and Canada, they
ARE successful WHY??.. the handwriting is on the wall guys..
GET PROFESSIONAL LEADERSHIP.
Nota Bene:
---------
The "get even" attitude or the "suit" happy attitude is going to
be the ruination of a good thing. Any time a "for profit" venture falls
in the hands of the barristers, serious problems are afoot or in store for
the future.
Atari DRAM supply is about to go down the tubes, remember when
everybody was gloating about the alledged upper hand had with Micron?
Remember the boasting about how the ST in Europe was kicking the a** of a
certain computer in it's own backyard? Read on Bunky, this is what hard
nosed legal beagle bargaining can get you......Amstrad has bought into
Micron Technologies on a rather heavy scale, guess who supplies DRAM to
our favorite company. What's that about; "Turn about is fair play???"
....When will Katzenjammer be controlled and real leadership LEAD?
as the Fuji turns...will continue
--------------------------------------------------------------------------
D.C. ATARIFEST
==============
by Bruce Hansford
Editor, MVACE
The Washington (DC) Area Atari Computer Enthusiasts, a cooperative
of several DC-area Atari user groups, sponsored their fourth annual
Atarifest on the 1st and 2nd of October... and WE WERE THERE. The MVACE
caravan consisted of myself, Doug Hodson, Ken Lare, Dan Steffen, Boyd
Bradford, Ashish Ranpura, George Baker, Michael McHale, and Ray Hendrix,
traveling in two vehicles connected by walkie-talkies. Whew! What a
trip!
The Fest itself was not all that impressive. I really expected
more; I think the Detroit Atarifest last year was better. After talking
to the show's organizer, I began to realize why it wasn't so great. One
reason was that they used a school and had to follow special rules
established by the city of Fairfax. They also didn't allow enough time
for notification of dealers and developers.
The best part of the show for me was the fact that David Small had
his newest product, SPECTRE 128, available for sale there, (I got mine!)
and the 128K Mac ROMs were available also (I got mine!). Another aspect
that stands out was meeting Brian Sarrazin, Vice President of SoftLogik,
who was showing the "final release" version of Publishing Partner
Professional. He said that they were just waiting for the documentation
to get back from the printers before sending out the upgrades and
releasing the package to distributors.
--------------------------------------------------------------------------
ANTIC PUBLISHING INC.
COPYRIGHT 1988
REPRINTED BY PERMISSION.
PROFESSIONAL GEM by Tim Oren
Column #11 - GEM Hooks and Hacks, An Insider's AES Tricks
Welcome to the eleventh episode of ST PRO GEM, which is
devoted to exploring some of the little documented, but powerful,
features of GEM. Like the authors of most complex systems, the
GEM programmers left behind a set of "hooks", powerful features
which would aid them in enhancing the system later. I am going to
lay out a number of these methods which have served me well in
making creative use of the AES. You will find that most of them
concern the object and form libraries, since I was most involved
in those parts of GEM. There are probably many more useful tricks
waiting to be found in other parts of GEM, so if you happen onto
one, please let me know in the Feedback!
POWERFUL OBJECTS. The first four tricks all involve
augmenting standard AES objects. This is a powerful technique
for two reasons. First, you can take advantage of the regular
AES object and form libraries to draw and handle most of your
objects, so that your program need only process the exceptions.
Second, you can use the RCS to copy the special objects into
multiple dialogs or resources. These four tricks are Extended
Object Types, User-defined Objects, TOUCHEXIT, and INDIRECT.
Let's look at each of them in turn.
EXTENDED OBJECT TYPES. If you look at the AES Object Library
documentation, you will notice that the values for the OB_TYPE
field in an object are all 32 or less. This means that a number
of bits are unused in this field. In fact, the AES completely
ignores the top byte of the OB_TYPE field. In addition, the RCS
ignores the top byte, but it also preserves its value when an
object is read, written, or copied.
This gives you one byte per object to use as you see fit.
Since the processing of an object or dialog is (so far) in the
hands of the AES, the best uses of Extended Types are in flagging
methods for initializing an object or handling its value when the
dialog completes.
For example, you might have several dialogs containing
editable numeric fields. The Extended Type of each numeric field
could be set to the index of the corresponding value in an array.
Then your application's dialog initialization code could scan the
object tree for such objects, pick up the appropriate value
from the array and convert it to ASCII, storing the result in the
resource's string area. When the dialog was finished, another
pass could be made to reconvert the ASCII to binary and store away
the results in the array. (Note that the map_tree() utility from
column #5 will scan an entire resource tree.)
Another application is to assign uniform codes to exit
buttons in dialogs. If you give every "OK" button an Extended
Type of one, and every "Cancel" button an Extended Type of two,
then you needn't worry about naming every exit object. Just
examine the Extended Type of the object returned by form_do, and
proceed accordingly.
The catch, of course, is that you have to find a way to enter
the Extended Type code in the first place. Version 1.0 of the
RCS, as shipped with the Atari developer's kit, makes no provision
for this. So you have your choice of two methods for creating the
first object with each Extended Type code.
First, you can dump out a C source of a resource, insert the
new type code by hand, and regenerate the resource with STCREATE.
Alternately, you could carefully modify the binary resource using
SID. You will probably want to reread the AES object manual, ST
PRO GEM #4 and #5, and use the C source as a guide when doing so.
In both cases, you should make things easy on yourself by creating
a one dialog resource with only a single object other than the
root. Version 2.0 of the RCS will let you directly enter an
Extended Type, but it has not yet been released for the ST by DRI.
Once you have created a prototype extended object by either
method, you can use the RCS to propogate it. The safest way is to
use the MERGE option to add the modified tree to the resource you
are building. Then copy the prototype object via the clipboard to
your dialog(s), deleting the extra tree when you are done. If you
are using several different extended objects, you can use MERGE
and clipboard copies to get them all into one tree which will then
become your own object library.
The second way of using RCS is easier, but more dangerous.
If you want to try the following technique, BACK UP YOUR RCS DISK
FIRST! Put simply, the RCS does not care what is in its dialog
partbox. It will make copies of anything that it finds there! This
gives you the option of using the RCS on ITS OWN RESOURCE in order
to add your customized objects to the partbox.
To do this, open RCS.RSC from the RCS. Since there is no DEF
file, you will get a collection of question mark icons. Use the
NAME option to make TREE5 into a DIALOG. Open it, and you will
see the dialog partbox.
Now you can use the MERGE technique described above to insert
your customized objects. Then SAVE the modified resource, and
rerun the RCS. Your new objects should now appear in the partbox.
If you added several, you may have to stretch the partbox to see
them all. You can now make copies of the new objects just like
any other part. (Note: DO NOT modify the alert or menu partboxes,
you will probably crash the RCS.)
USER-DEFINED OBJECTS. The one type of object which was not
discussed in the earlier articles on AES objects was G_USERDEF,
the programmer defined object. This is the hook for creating
objects with other appearances beyond those provided by the
standard AES. By the way, you should note that the G_PROGDEF
and APPLBLK mnemonics used in the AES documents are incorrect;
the actual names as used defined OBDEFS.H are G_USERDEF and
USERBLK.
The RCS does not support the creation of G_USERDEF objects,
since it has no idea how they will be drawn by your program.
Instead, you must insert a dummy object into your resource where
you want the G_USERDEF to appear, and patch it after your
application performs its resource load.
You must replace the object's existing OB_TYPE with
G_USERDEF, though you may still use the upper byte as an Extended
Type. You must also change the OB_SPEC field to be a 32-bit
pointer to a USERBLK structure. An USERBLK is simply two LONG
(32-bit) fields. The first is the address of the drawing code
associated with the user defined object. The second is an
arbitrary 32-bit value assigned to the object by your application.
You can designate objects for conversion to G_USERDEFs in the
normal fashion by assigning them names which are referenced one by
one in your initialization code. You can also combine two tricks
by using the Extended Type field as a designator for objects to be
converted to G_USERDEF. Each tree can then be scanned for objects
to be converted. There is a short code segment in the download
which demonstrates this technique.
My usual convention is to define new drawing objects as
variants of existing objects, using the Extended Type field to
designate the particular variation. Thus an Extended Type of one
might designate a G_BUTTON with rounded corners, while a value of
two could flag a G_STRING of boldface text. When using this
technique, the RCS can be used to build a rough facsimile of the
dialog by inserting the basic object type as placeholders. The
existing OB_SPEC information can then be copied to the second
position in the USERBLK when the object is initialized.
One final note before moving on: There is no reason that the
USERBLK cannot be extended beyond two fields. You might want to
add extra words to store more information related to drawing the
object, such as its original type.
The AES will call your drawing code whenever the G_USERDEF
needs to be drawn. This occurs when you make an objc_draw call
for its tree, or when an objc_change occurs for that object. If
your user-defined object is in a menu drop-drop, then your drawing
code will be called any time the user exposes that menu.
Before getting into the details of the AES to application
calling sequence, some warnings are in order. First, remember
that your drawing code will execute in the AES' context, using its
stack. Therefore, be careful not to overuse the stack with deep
recursion, long parameter lists, or large dynamic arrays. Second,
the AES is NOT re-entrant, so you may not make ANY calls to it
from within a G_USERDEF procedure. You may, of course, call the
VDI. Finally, realize that drawing code associated with a menu
object may be called by the AES at any time. Exercise great care
in sharing data space between such code and the rest of the
application!
When your drawing code is called by the AES, the stack is set
up as if a normal procedure call had occured. There will be one
parameter on the stack: a 32-bit pointer to a PARMBLK structure.
This structure lies in the AES' data space, so do not write beyond
its end!
The PARMBLK contains 15 words. The first two are the long
address of the object tree being drawn, and the third word is the
number of the G_USERDEF object. You may need these values if the
same drawing code is used for more than one object at a time.
Words four and five contain the previous and current OB_STATE
values of the object. If these values are different, your drawing
code is being called in response to an objc_change request.
Otherwise, the active AES call is an objc_draw.
Words six through nine contain the object's rectangle on the
screen. Remember that you cannot call objc_offset within the
drawing code, so you will need these values! The next four words
contain the clipping rectangle specified in the active objc_change
or objc_draw call. You should set the VDI clip rectangle to this
value before doing any output to the screen.
The last two words in the PARMBLK contain a copy of the extra
32-bit parameter from the object's USERBLK. If you have followed
the method of copying an OB_SPEC into this location, these words
will be your pointer to a string, or BITBLK, or whatever.
When your drawing routine is done, it should return a zero
value to the AES. This is a "magic" value; anything else will
stop the drawing operation.
The download contains a sample drawing routine which defines
one extended drawing object, a rounded rectangle button. You can
use this procedure as a starting point for your own User Defined
objects.
PUT ANYTHING YOU WANT ON THE DESKTOP! In ST PRO GEM #2, I
described the use of the WF_NEWDESK wind_set call to substitute
your own object tree for the normal green desktop background.
If the tree you supply contains User Defined objects, you can draw
whatever you want on the desktop! Some of the things you might
try are free hand drawings imported in metafile format from
EasyDraw, or whole screen bit images generated by Degas. If you
do the latter, you will have to store the entire image off screen
and blit parts of it to the display as requested.
In any case, remember that your desktop drawing code can be
called any time that a window is moved, so exercise the same care
as with a menu drawer. Also, be aware that making the WF_NEWDESK
call does not force an immediate redraw of the desktop. To do
that, do a form_dial(3) call for the entire desktop rectangle.
THE TOUCHEXIT FLAG. The TOUCHEXIT attribute is an alternative
to the more usual EXIT. When the TOUCHEXIT bit is set in an
object's OB_FLAG word, the form_do routine will exit immediately
when the mouse button is pressed with the cursor over the object.
Your code can immediately take control of the mouse and display,
without waiting for the release of the button. This method is
used for generating effects such as slider bars within otherwise
normal dialogs.
The easiest way to code a TOUCHEXIT handler is to place a
loop around the form_do call. If the object number returned is
TOUCHEXIT, then the animation procedure is called, followed by a
resumption of the form_do (WITHOUT recalling form_dial or
objc_draw!). If the object returned is a normal EXIT, the dialog
is complete and control flows to the cleanup code.
There is one idiosyncrasy of TOUCHEXIT which should be noted.
When the AES "notices" that the mouse button has been pressed over
a TOUCHEXIT, it immediately retests the button state. If it has
already been released, it waits to see if a double click is
performed. If so, the object number returned by form_do will have
its high bit set. If you don't care about double clicks, your
code should mask off this flag. However, you may want to use the
double click to denote some enhanced action. For example, the GEM
file selector uses a double click on one of the file name objects
to indicate a selection plus immediate exit.
THE INDIRECT FLAG. If the INDIRECT bit is set in an object's
OB_STATE word, the AES interprets the 32-bit OB_SPEC field as a
pointer to the memory location in which the ACTUAL OB_SPEC is to
be found. Like User Defined objects, this capability is not
supported by the RCS, so you have to set up the INDIRECT bit and
alter the OB_SPEC at run time.
The value of INDIRECT is that you can use it to associate an
AES object with other data or code. The general technique is to
set up a table with a spare 32-bit location at its beginning.
Then, when initializing the application's resource, you move the
true OB_SPEC into this location, set the INDIRECT flag, and
replace the OB_SPEC field with a pointer to the table. The object
behaves normally during drawing and form handling. However, if you
receive its number from form_do or objc_find, you have an
immediate pointer to the associated table, without having to go
through a lookup procedure.
This technique works well in programs like the GEM Desktop.
Each G_ICON object is set up with INDIRECT. Its OB_SPEC goes to
the beginning of a data area defining the associated file. The
blank location at the beginning of file table is filled up with
the former OB_SPEC, which points to a ICONBLK.
You can also combine INDIRECT with TOUCHEXIT when creating
objects that must change when they are clicked by a user. For
instance, a color selection box might be linked to a table
containing the various OB_SPEC values through which the program
will cycle. Each time the user clicked on the box, the TOUCHEXIT
routine would advance the table pointer, copy the next value into
the dummy OB_SPEC location at the front of the table, and redraw
the object in its new appearance.
A programmer who wanted to follow a truly object-oriented
"Smalltalkish" approach could use the INDIRECT method to bind AES
drawing object to tables of associated procedures or "methods".
For instance, one procedure could be flagged for use when the user
clicked on the object, one when the object was dragged, one for
double-click, and so on. If the table structure was capable of
indicating that the true method was stored in another table, a
rudimentary form of class inheritance could be obtained.
INSTANT CO-ROUTINES. We turn to the AES event and message
system for this trick. While some languages like Modula 2
provide a method for implementing co-routines, there is no such
capability in C. However, we can effectively fake it by using the
AES event library.
As already seen in an earlier column, an application can
write a message to its own event queue using the appl_write call.
Usually, this is a redraw message, but there is nothing to prevent
you from using this facility to send messages from one routine in
your program to another. To set up co-routines using this method,
they would be coded as separate procedures called from the
application's main event loop.
When one of the co-routines wanted to call the other, it
would post a message containing the request and any associated
parameters into the application's queue and then return. The main
loop would find the message and make the appropriate call to the
second co-routine. If it was necessary to then re-enter the first
co-routine at the calling point, the original message could
contain an imbedded reply message to be sent back when the request
was complete. A simple switch structure could then be used to
resume at the appropriate point.
There are two potential problems in using this method. The
first is the limited capacity of the application event queue. The
queue contains eight entries. While the AES economizes this
space by merging redraws and multiple events, it cannot merge
messages. Because of this limit, you must be extremely careful
when one message received has the potential to generate two or
more messages sent. Unless this situation is carefully managed,
you can get a sort of "cancer" which will overflow the queue and
probably crash your application.
The second danger involves race conditions. Message sent by
the application are posted to the end of the queue. If other
events have occurred, such as mouse clicks or keyboard presses,
they will be seen and processed ahead of the application generated
message. This implies that you cannot use this method if the
program must complete its action before a new user generated event
can be processed.
THAT'S ALL FOR NOW. Hopefully these hints will keep you
profitably occupied for a while. ST PRO GEM number twelve will
return to the topic of user interfaces. Reaction to the first
article on this subject was mostly positive, but a lot of folks
wanted to see real code as well. In response to your feedback,
there will also be code for implemented your own "mouse sensitive"
objects which highlight when the cursor touches them. This will
be presented as part of an alternate form manager.
UPDATE: ATARI ST. I have recently gotten more information on
some topics mentioned in earlier articles. These notes will bring
you up to date:
A number of developers reported that they were unable to get
the self-redraw technique described in ST PRO GEM #2 to work.
This is usually due to a bug in the appl_init binding in Alcyon C.
The value returned from the function, which would normally be
assigned to gl_apid, is coming back as garbage. To work around
the problem, declare EXTERN WORD gl_apid; in your program and DO
NOT assign the value from appl_init. The binding WILL make the
assignment. A tip of the hat to Russ Wetmore for this report.
The last column mentioned that turning off the clip
rectangle while drawing graphics text will speed things up. It
turns out that the VDI will also run at the non-clipped speed if
the ENTIRE string to be written is within the current clip
rectangle. To compound the problem, there is a one-off bug in the
detection algorithm for the right edge. That is, the clip
rectangle has to be one pixel BEYOND the right edge of the text
for the fast write to work.
The Feedback in ST PRO GEM #10 mentioned that there are known
bugs in the Alcyon C floating point library. In fact, this
library has been replaced with a new, debugged version in recent
shipments of the Toolkit. If you need to use floating point and
have run into this bug, you should be able to get an update from
Atari. Also, check the Atari Developer's SIG (PCS-57) for a
possible download.
In addition, it turns out there is an undocumented feature in
Alcyon C which allows you to imbed assembly code in-line. Try
using:
asm(".....");
where the dots are replaced with an assembly instruction. You get
one instruction per asm(), one asm() per line. Thanks to Leonard
Tramiel for both of the above tidbits.
>>>>>>>>>>>>>>> Sample code for initializing User Objects <<<<<<<<<<<<<<<<
GLOBAL USERBLK extobjs[MAX_OBJS]; /* APPLBLK defined in OBDEFS.H */
GLOBAL WORD n_extobjs; /* Set MAX_OBJS to total user */
/* objects in resource */
VOID
obj_init() /* Scan whole resource for user */
{ /* objects. Uses map_tree() */
LONG tree, obspec; /* from GEMCL5.C */
WORD itree, i, obj;
n_extobjs = 0; /* Replace TREE0 with your first */
/* tree, TREEN with the last */
for (itree = TREE0; itree <= TREEN; itree++)
{
rsrc_gaddr(R_TREE, itree, &tree);
map_tree(tree, ROOT, NIL, fix_obj);
}
}
WORD
fix_obj(tree, obj) /* COde to check and fix up */
LONG tree; /* a user defined object */
WORD obj;
{
WORD hibyte;
hibyte = LWGET(OB_TYPE(obj)) & 0xff00; /* check extended */
if (!hibyte) /* type - if none */
return (TRUE); /* ignore object */
extobjs[n_extobjs].ub_code = dr_code; /* set drawcode */
extobjs[n_extobjs].ub_parm = LLGET(OB_SPEC(obj)); /* copy obspec */
LLSET(OB_SPEC(obj), ADDR(&extobjs[n_extobjs])); /* point obspec */
LWSET(OB_TYPE(obj), G_USERDEF | hibyte); /* to userblk & */
n_extobjs++; /* patch type */
return (TRUE);
}
>>>>>>>>>>>>>>>>>>>>>> Sample User Object Drawing Code <<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>> Implements Rounded Box based <<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>> on G_BOX type <<<<<<<<<<<<<<<<<<
WORD
dr_code(pb) /* Sample user object drawing */
PARMBLK *pb; /* code. Caution: NOT portable */
{ /* to Intel small data models */
LONG tree, obspec;
WORD slct, flip, type, ext_type, flags;
WORD pxy[4];
WORD bgc, interior, style, bdc, width, chc;
tree = pb->pb_tree;
obspec = LLGET(pb->pb_parm); /* original obspec from USERBLK */
ext_type = LHIBT(LWGET(OB_TYPE(pb->pb_obj)));
slct = SELECTED & pb->pb_currstate;
flip = SELECTED & (pb->pb_currstate ^ pb->pb_prevstate);
set_clip(TRUE, &pb->pb_xc); /* These two routines in GEMCL9.C */
grect_to_array(&pb->pb_x, pxy);
switch (ext_type) {
case 1: /* Rounded box */
/* Crack color word */
get_colrwd(obspec, &bgc, &style, &interior,
&bdc, &width, &chc);
/* For select effect, use char color */
if (slct) /* In place of background */
bgc = chc;
/* Fill in background */
rr_fill(MD_REPLACE, (width? 0: 1), bgc, interior,
style, pxy);
/* Do perimeter if needed */
/* rr_perim is in GEMCL9.C */
if (width && !flip)
{
pxy[0] -= width; pxy[2] += width;
rr_perim(MD_REPLACE,bdc,FIS_SOLID,width,pxy);
}
break;
default: /* Add more types here */
break;
}
return (0);
}
VOID /* Cracks the obspec color word */
get_colrwd(obspec, bgc, style, interior, bdc, width, chc)
LONG obspec;
WORD *bgc, *style, *interior, *bdc, *width, *chc, *chmode;
{
WORD colorwd;
colorwd = LLOWD(obspec);
*bgc = colorwd & 0xf;
*style = (colorwd & 0x70) >> 4;
if ( !(*style) )
*interior = 0;
else if (*style == 7)
*interior = 1;
else if (colorwd & 0x80) /* HACK: Uses character writing mode */
*interior = 3; /* bit to select alternate interior */
else /* styles! */
*interior = 2;
*bdc = (colorwd & 0xf000) >> 12;
*width = LHIWD(obspec) & 0xff;
if (*width > 127)
*width = 256 - *width;
if (*width && !(*width & 0x1)) /* VDI only renders odd */
(*width)--; /* widths! */
*chc = (colorwd & 0x0f00) >> 8; /* used for select effect */
}
VOID /* Fill a rounded rectangle */
rr_fill(mode, perim, color, interior, style, pxy)
WORD mode, perim, color, style, interior, *pxy;
{
vswr_mode(vdi_handle, mode);
vsf_color(vdi_handle, color);
vsf_style(vdi_handle, style);
vsf_interior(vdi_handle, interior);
vsf_perimeter(vdi_handle, perim);
v_rfbox(vdi_handle, pxy);
}
--------------------------------------------------------------------------
___________________________
| SUPPORT YOUR LOCAL BBS |
---------------------------
THE BUMPER STICKER FOR ALL BBS USERS!
3 1/2" X 11"
Blue Letters on White Vinyl
---------------------------
$3.75ea. - 2 for $7.00
postage and handling Incl.
Linda Woodworth
4604 East 16th Street
Cheyenne, WY. 82001
--------------------------------------------------------------------------
THE ARCHIVAL BIT
================
As a service to our readers we include here a grouping of statements
made by the President of Atari Sam Tramiel, at the CIS Presidential
Conference a few weeks ago....
We present these as a "record" for all to use as reference to see if
in fact, these things come to pass or just pass on.
Also, we took the liberty to comment where we felt it appropriate.
"At present I think that we are shipping all the models (shown at
the fall COMDEX last year) in Europe, even the Abaq, to developers. We
will start shipping in earnest to the US market in early 1989, including
the ST and the line of PC compatibles and our new members of the ST
family. The Abaq is now called the ATW (ATari Work station)."
STR NOTE: You "THINK", aren't you SURE?
"We just signed a major deal with a big Dram supplier and the
situation will get better I hope in early 1989."
"We have already published the details of new TOS (ver 1.4) to
developers and will do so for the rest of the users when it is released.
We are working on the TT (the 68030 system), and hope to show it in early
'89. Until then, no further comments on the TT... but it will knock your
socks off! :-) "
"We feel that advertising without product availability is helpful
in selling our competitors' machines and therefore, will just waste
money. As far as a national computer chain is concerned, we are already
diverting machines to the US and ship them to our few but loyal ST
dealers."
STR NOTE: Advertise the software available and display the machines at
the same time, thus keeping the interest level high. Show support to the
developers of software for the ST..thats the kind of advertising you
could be doing at this time. Stop suffering from the CHEAPS!
"We agree that the Atari 8-bit line is the best available.
However, the US market seems to want more powerful machines. We are
selling many tens of thousands of the XE/XL line in Europe, and in the
middle east, and in Latin America. We are trying to push the XE Game
System in the US as a computer and a game for the same price as the
Nintendo with an exercise mat. (i.e. $149)"
"By the way, there is now a fifty dollar rebate on the XE Game
machine."
{Portable ST - Fact or Fiction} "Fact. We are working on it, and
will ship it as soon as it is ready."
"...we plan for Atari to be number two or number three in the world
personal computer market and we hope to make the ST one of the standard
machines in the US during 1989. I would prefer not to comment on
details of future ST or TT machines at present."
"I appreciate the support of all of you, and I really hope that in
1989, you will not be such a minority in the US personal computer world.
It is a pleasure to see Atari so successful in Europe and I'm sure that
with more DRAM as we expect in '89, we will be able to be successful in
the US as well. Good night."
NOTE: Then we all woke up and saw the real questions go unanswered!
We purposely left out the part where Sam told the US Developers to
go sell their products in Europe. That "GEM" was just too revolting to
bring up again. Better he should get product on the US Dealer shelves
instead of trying to sway the developers to turn to Europe.
Hey Sam, read YOUR address at least once a day, it SEZ: "U.S.A.!"
------
-------------------------------------------------------------------------
ABCO COMPUTER ELECTRONICS INC.
P.O. Box 6672
Jacksonville, Florida 32236-6672
904-783-3319
HARD DISK SYSTEMS TO FIT EVERY BUDGET
-------------------------------------
20mb #SG20510 519.00 30mb #SG32610 649.00
40mb #SG44710 789.00 65mb #SG60101 949.00
80mb #SG840110 1019.00 130mb #SG3A1210 1449.00
larger units are available - (special order only)
*** Available for ST - Amiga - Mac - IBM ***
6 month Guarantee
followed by
6 month Parts & Labor Warranty
(under normal usage)
--------------
-------------------------------------------------------------------------
A NEW BLIVITT!
==============
From "Computer & Software News"
Dated: Oct. 1988
"It looks like ATARI may bring out a 68030-based computer at COMDEX.
The base unit of the system, aimed at getting the company into the
workstation business, will have a price tag of about $2,000, and will be
targeted at the education, scientific and engineering markets, a la Steve
Jobs' Next. The ATARI machine reportedly will feature a 1280-by-960 pixel
screen with 8-bit gray-scale, a Motorola 56000 digital processor for up to
eight channels of 16-bit sound, and a 1.44-Mbyte, 3.5-in. floppy disk
drive. It will also have four VME expansion slots which will allow it to
accomodate add-in boards that fit in Apollo and Sun workstations, sources
explained."
--------------------------------------------------------------------------
ST REPORT CONFIDENTIAL
======================
Sunnyvale, CA The real hope for Atari lies in the first and second
------------- quarters of 1989, with the real push on for the
second quarter.
NYC, NY Amstrad has bought into MICRON which means after the
------- initial committment to Atari is fullfilled, there
will be NO MORE Dram chips for Atari from them.
Phoenix, AZ Atari is once again BACK ORDERED ON SC1224 and you
----------- can forget getting ANY 1040 STs! It is suggested
that you use the Magnovox monitor as it is the
closest to SC1224 performance. Dealers are being
forced to upgrade 520stfm units to 1mb in the field.
Las Vegas, NV Will Comdex be the shot that's heard 'round the
------------- world? According to some informed sources if Poppa
Jack holds the KATZENJAMMER KIDS in check, Atari
could quite possibly do well in the Public
Relations Dep't.
Sunnyvale, CA "Rumor" has it, that the centerpiece of Atari's
------------- Comdex show will be the Laptop, also an elaborate
Desktop Publishing Display will be in action.
NYC, NY Insiders at the "market" are very skeptical of the
------- remark: "Watch Atari in the first 2 quarters of
1989". We have heard all that before. they said.
St. Louis, MO Page Stream, the "new" name for Publishing Partner
------------- Professional has been released. As always, with
"new" programs, it is experiencing some slight
problems. According to one reviewer, the 20 some
odd "listed" quirks (bugs) are soon to be hit with
raid and "all" will be ok. This is a DTP program
that, if it's problems are ironed out, will be the
top US DTP program.
Los Angeles, CA FEDERATED, the ATARI owned and operated chain of
--------------- stores west of the Mississippi, has more Commodore
AMIGA 500s is their stores than they do of Atari
computers is this another "coup" for ATARI?
-------------------------------------------------------------------------
Atari ST GFA-BASIC 3.1
======================
The original version of GFA BASIC was released in June of 1986 to
rave reviews in all the major computer publications. Even the often
cynical programmers were impressed by the speed of this new language,
the command vocabulary and the structured programming. At last a way for
every owner to unleash the powerof their ST!
Early in 1987: The GFA BASIC Compiler became available. The already
fast programs became even faster. The compiled source code made
professional software development a possibility, and several products,
ranging from game programs to productivity utilities were introduced by
professional programmers.
Version 2.0 of GFA BASIC implemented compiler commands, and was
delivered in October of 1986.
During the past two years, over 50,000 copies of the GFA BASIC
Interpreter, and 20,000 copies of the GFA BASIC Compiler have been
purchased world wide.
A New Standard
GFA BASIC, Version 3.0 was first shown to the general public at CeBIT
the world's largest consumer computer show, in West Germany. Again, GFA
BASIC has astounded the computer world.
With over three hundred new commands and an enormous increase in
speed. Tests have indicated speed increases ranging between 40 and 60
percent over the previous version of GFA BASIC. Once again GFA BASIC is
setting new standards!
Compatibility
Even more important to the many present user's of GFA BASIC, Version
3.0 remains compatible. You can still use all of the existing
GFA- BASIC programs and books. The huge library of public domain GFA
BASIC programs has just been improved! ALL programs will benefit from
the improvements in the latest version of GFA BASIC.
New Editor
The editor in the previous version of GFA BASIC has been highly
praised. Automatic syntax checking, and the interactive programming
environment made program development a snap.
But, even something this good can be improved.
One of the more impressive features is the ability to "hide"
procedures. Once a procedure has been debugged, the programmercan "hide"
it. Only the procedure name is shown in the listing. This makes your
visible code more readable. No longer will it be necessary page through
screen after screen of procedures. Just view the names, expanding them
as needed to review the contents.
There's also more help in editing your programs. Now with just a key
stroke, characters above the normal ASCII-Code can be input into your
program. The new GFA-BASIC Editor also includes a larger number of
keyboard implemented commands.
Other useful new features include: a clock in the menu field, up to
10 editor-marks may be placed in your program, and a line counter is
included.
More Power!
There isn't enough room here to list all the possibilities of GFA
BASIC 3.0, but here are a few of the new functions:
-- All AES functions have been implemented
-- Additional functions for management and handling of objects
-- Structures
-- Line-A commands are now supported
-- Joystick commands
-- Case distinction (SELECT-CASE and ELSE-IF)
-- Multiple line functions in addition to assigned parameters
-- Variable parameters are also possible-
-- Many bit operations have been implemented
(move, rotate, bit test, erase, set, change)
-- Fast Integer operations
-- And much more!
Atari ST GFA-BASIC 3.1
For ALL Atari ST Computers
By Frank Ostrowski
MICHTRON, Inc.
576 S. Telegraph
Pontiac, Mi. 48053
Phone (313) 334-5700
-------------------------------------------------------------------------
INTERLINK PC Pursuit Help
By: Randy Mears
Until INTERLINK ST is upgraded to contain a script language (and it will
be so upgraded) you can get around quite well in PC Pursuit without one.
The first thing you need to do is create a special Phone File for your
PC Pursuit dialing. The primary difference between this file and a normal
Phone File is that the Modem Parameters are changed to disable the Hang-Up
and increase the timeout values. This will allow you to use the standard
dialer buttons to dial numbers within a given area. You can even use the
group dialing capability to check multiple numbers within that area.
In addition, function key definitions that will allow you to disconnect
from your current area and connect to a new area need to be defined so
that you can easily move from one area to another.
And, finally, a recording that will allow you to continuously retry area
dialing until you get a CONNECT rather than those all too familiar BUSY's.
Enclosed in this archive is a sample PC Pursuit Dial File (PCDIAL.DAT).
You can load it into INTERLINK as a Phone File and create your own
function keys using the model contained in the Control/F10 Function.
Just insert the desired area code and your userid and password. If you
desire automatic retry keys add this string to the end of your area call
function ````^nn
where nn is the function number (1-20) of the key being defined. This
will cause the key to be repeated after a 12 second pause. When you get
connected you can break out of this loop by pressing a function key that
has nothing defined (I use ALT/F2). You can break out of this loop
manually or, you can use the enclosed recording to do it automatically.
In versions of INTERLINK below 1.74 you must start the recording after
you initiate function key processing (sorry about that bug), in later
versions you can start the recording and then press the function key you
desire or change to another function key mid-stream. Don't forget to save
this new Phone File with some other name than your normal one!
The recording is called PCCOD.REC. It waits forever for a CONNECT from
PC Pursuit and, upon getting one, breaks the Function Key loop by pressing
ALT/F2 (important that you leave it blank) and sending ATZ<cr> to PC
Pursuit. It plays the completion tone to let you know that you have
connected.
I use this technique constantly on PC Pursuit and find that I can move
around quickly and find lots of Boards to connect to. It is convenient
to add the required Area Code for a given board to its NAME description
in the dialer window. This way you know what area is needed for a given
board. You may just want to make a different Phone File for each area
but I tend to put about 4 areas per Phone File and have about 6 such
files descriptively named.
Hope the enclosed files and information have been of help in your PC
Pursuits. If you would like further information or clarification please
feel free to call our BBS at (813)924-4590. It will be a long distance
call for most of you so we try to answer your questions within 24 hrs.
--------------------------------------------------------------------------
THIS WEEK'S QUOTABLE QUOTE
==========================
BUG-A-BOO
---------
In any collection of data, the figures that are obviously
correct beyond all need of checking, contain all the errors!
------------------------------------------------------------------------
ST-REPORT Issue #60 November 07, 1988
ALL RIGHTS RESERVED (c)copywrite STR Inc.
------------------------------------------------------------------------
Any reprint must include ST-Report and the author in the credits.
Views Presented herein are not necessarily those of STR Inc. or APEInc.
COMMERCIAL ONLINE SERVICES MUST HAVE WRITTEN PERMISSION
to offer ANY APEInc. REPORT and/or ZMAG in any form.
-------------------------------------------------------------------------
