
                      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.
-------------------------------------------------------------------------
