🚀 go-pugleaf

       As  above,  the  source  and  dest parameters are pointers to MFDBs
    (which in turn point to the actual forms).  The two MFDBs may point to
    memory  areas  which  overlap.  In this case, the VDI will perform the
    move in a non-destructive order.  Mode determines how the pixel values
    in  the source and destination areas will be combined.  I will discuss
    it separately later on.

       The  pxy  parameter  is  a pointer to an eight-word integer array.
    This  array  defines the area within each form which will be affected.
    Pxy[0]  and  pxy[1]  contain, respectively, the X and Y coordinates of
    the  upper  left  corner  of the source rectangle.  These are given as
    positive  pixel displacements from the upper left of the form.  Pxy[2]
    and  pxy[3]  contain  the X and Y displacements for the lower right of
    the source rectangle.

       Pxy[4] through pxy[7] contain the destination rectangle in the same
    format.  Normally, the destination and source should be the same size.
    If  not,  the  size  given  for the source rules, and the whole are is
    transferred beginning at the upper left given for the destination.

       This  all  sounds  complex,  but  is  quite  simple in many cases.
    Consider  an example where you want to move a 32 by 32 pixel area from
    one  part  of the display to another.  You would need to allocate only
    one MFDB, with a zero in the fd_addr field.  The VDI will take care of
    counting color planes and so on.  The upper left raster coordinates of
    the  source  and  destination  rectangles  go  into pxy[0], pxy[1] and
    pxy[4],  pxy[5]  respectively.  You add 32 to each of these values and
    insert the results in the corresponding lower right entries, then make
    the  copy  call  using the same MFDB for both source and destination.
    The VDI takes care of any overlaps.


    COPY RASTER TRANSPARENT

       This  operation  is  used  for  copying from a monochrome form to a
    color  form.   It is called transparent because it "writes through" to
    all   of   the   color  planes.   Again,  the  forms  need  to  be  in
    device-specific form.  The calling format is:

        vrt_cpyfm(vdi_handle, mode, pxy, source, dest, color);

       All  of  the  parameters  are  the same as copy opaque, except that
    color has been added.  Color is a pointer to a two word integer array.
    Color[0]  contains  the  color  index  which  will  be used when a one
    appears  in  the  source form, and color[1] contains the index for use
    when a zero occurs.

       Incidentally,  copy  transparent is used by the AES to draw G_ICONs
    and  G_IMAGEs  onto  the screen.  This explains why you do not need to
    convert them to color forms yourself.

       (A  note  for  advanced  VDI programmers: The pxy parameter in both
    copy  opaque  and  transparent  may  be  given  in  normalized  device
    coordinates  (NDC)  if  the workstation associated with vdi_handle was
    opened for NDC work.)


    THE MODE PARAMETER

       The  mode variable used in both of the copy functions is an integer
    with  a  value between zero and fifteen.  It is used to select how the
    copy   function  will  merge  the  pixel  values  of  the  source  and
    destination  forms.   The  complete table of functions is given in the
    download.   Since  a  number  of  these are of obscure or questionable
    usefulness, I will only discuss the most commonly used modes.


    REPLACE MODE

       A  mode  of 3 results in a straight-forward copy: every destination
    pixel is replaced with the corresponding source form value.


    ERASE MODE

       A  mode  value  of  4  will  erase  every  destination  pixel which
    corresponds  to  a  one in the source form.  (This mode corresponds to
    the  "eraser" in a Paint program.)  A mode value of 1 will erase every
    destination pixel which DOES NOT correspond to a one in the source.


    XOR MODE

       A mode value of 6 will cause the destination pixel to be toggled if
    the  corresponding  source bit is a one. This operation is invertable,
    that is, executing it again will reverse the effects.  For this reason
    it  is  often used for "software sprites" which must be shown and then
    removed  from the screens.  There are some problems with this in color
    operations, though - see below.


    TRANSPARENT MODE

       Don't  confuse this term with the copy transparent function itself.
    In  this  case  it  simply  means  that  ONLY those destination pixels
    corresponding  with  ones  in  the source form will be modified by the
    operation.   If  a  copy  transparent is being performed, the value of
    color[0]  is  substituted for each one bit in the source form.  A mode
    value of 7 selects transparent mode.


    REVERSE TRANSPARENT MODE

       This  is  like  transparent mode except that only those destination
    pixels  corresponding  to  source  ZEROS  are  modified.   In  a  copy
    transparent,  the  value of color[1] is substituted for each zero bit.
    Mode 13 selects reverse transparent.


    THE PROBLEM OF COLOR

       I  have  discussed  the  various modes as if they deal with one and
    zero  pixel  values  only.   This  is exactly true when both forms are
    monochrome, but is more complex when one or both are color forms.

       When  both  forms are color, indicating that a copy opaque is being
    performed,  then  the  color  planes are combined bit-by-bit using the
    rule  for  that  mode.   That  is,  for  each corresponding source and
    destination  pixel,  the VDI extracts the top order bits and processes
    them,  then  operates  on the next lower bit, and so on, stuffing each
    bit  back  into  the  destination  form  as  the copy progresses.  For
    example,  an XOR operation on pixels valued 7 and 10 would result in a
    pixel value of 13.

       In  the  case of a copy transparent, the situation is more complex.
    The  source  form  consists of one plane, and the destination form has
    two  or  more.  In order to match these up, the color[] array is used.
    Whenever  a one pixel is found, the value of color[0] is extracted and
    used  in the bit-by-bit merge process described in the last paragraph.
    When  a  zero  is  found,  the  value  of  color[1] is merged into the
    destination form.

       As  you can probably see, a raster copy using a mode which combines
    the  source and destination can be quite complex when color planes are
    used!   The  situation is compounded on the ST, since the actual color
    values  may  be  remapped  by the palette at any time.  In many cases,
    just  using  black  and  white  in color[] may achieve the effects you
    desire.   If need to use full color, experimentation is the best guide
    to what looks good on the screen and what is garish or illegible.


    OPTIMIZING RASTER OPERATIONS

       Because  the  VDI  raster functions are extremely generalized, they
    are  also  slower than hand-coded screen drivers which you might write
    for   your   own  special  cases.   If  you  want  to  speed  up  your
    application's  raster  operations  without  writing  assembly language
    drivers,  the  following  hints  will  help  you  increase  the  VDI's
    performance.


    AVOID MERGED COPIES

       These are copy modes, such as XOR, which require that words be read
    from  the  destination  form.   This extra memory access increases the
    running time by up to fifty percent.


    MOVE TO CORRESPONDING PIXELS

       The  bit position within a word of the destination rectangle should
    correspond  with the bit position of the source rectangle's left edge.
    For  instance,  if  the  source's  left edge is one pixel in, then the
    destination's  edge  could be at one, seventeen, thirty-three, and so.
    Copies which do not obey this rule force the VDI to shift each word of
    the form as it is moved.


    AVOID FRINGES

       Put  the  left  edge of the source and destination rectangles on an
    even  word  boundary, and make their widths even multiples of sixteen.
    The VDI then does not have to load and modify partial words within the
    destination forms.


    USE ANOTHER METHOD

       Sometimes  a  raster operation is not the fastest way to accomplish
    your  task.   For instance, filling a rectangle with zeros or ones may
    be accomplished by using raster copy modes zero and fifteen, but it is
    faster  to use the VDI v_bar function instead.  Likewise, inverting an
    area  on the screen may be done more quickly with v_bar by using BLACK
    in  XOR  mode.  Unfortunately, v_bar cannot affect memory which is not
    in the video map, so these alternatives do not always work.


    FEEDBACK RESULTS

       The  results  of  the  poll  on  keeping  or  dropping  the  use of
    portability  macros  are in.  By a slim margin, you have voted to keep
    them.   The vote was close enough that in future columns I will try to
    include  ST-only  versions  of  routines  which  make heavy use of the
    macros.   C  purists and dedicated Atarians may then use the alternate
    code.


    THE NEXT QUESTION

       This  time  I'd like to ask you to drop by the Feedback Section and
    tell me whether the technical level of the columns has been:

         A)  Too hard!  Who do you think we are, anyway?
         B)  Too easy!  Don't underestimate Atarians.
         C)  About right, on the average.

       If  you  have  the  time, it would also help to know a little about
    your   background,  for  instance,  whether  you  are  a  professional
    programmer,  how  long  you have been computing, if you owned an 8-bit
    Atari, and so on.


    COMING UP SOON

       The next column will deal with GEM menus: How they are constructed,
    how  to  decipher  menu  messages,  and  how to change menu entries at
    run-time.   The  following  issue will contain more feedback response,
    and a discussion on designing user interfaces for GEM programs.




>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MFDB Structure <<<<<<<<<<<<<<<<<<<<<<<<<<<<<

                    /* Memory Form Definition Block */
typedef struct fdbstr
{
     long         fd_addr;        /* Form address               */
     int          fd_w;           /* Form width in pixels       */
     int          fd_h;           /* Form height in pixels      */
     int          fd_wdwidth;     /* Form width in memory words */
     int          fd_stand;       /* Standard form flag         */
     int          fd_nplanes;     /* Number of color planes     */
     int          fd_r1;          /* Dummy locations:           */
     int          fd_r2;          /*  reserved for future use   */
     int          fd_r3;
} MFDB;


>>>>>>>>>>>>>>>>>>>>>>> Resource Transform Utilities <<<<<<<<<<<<<<<<<<<<<

/*------------------------------*/
/*          vdi_fix             */
/*------------------------------*/
     VOID
vdi_fix(pfd, theaddr, wb, h)          /* This routine loads the MFDB  */
     MFDB          *pfd;              /* Input values are the MFDB's  */
     LONG          theaddr;           /* address, the form's address, */
     WORD          wb, h;             /* the form's width in bytes,   */
     {                                /* and the height in pixels     */
     pfd->fww = wb >> 1;
     pfd->fwp = wb << 3;
     pfd->fh = h;
     pfd->np = 1;                     /* Monochrome assumed           */
     pfd->mp = theaddr;
     }


/*------------------------------*/
/*          vdi_trans           */
/*------------------------------*/
     WORD
vdi_trans(saddr, swb, daddr, dwb, h)    /* Transform the standard form  */
     LONG          saddr;               /* pointed at by saddr and      */
     UWORD          swb;                /* store in the form at daddr   */
     LONG          daddr;               /* Byte widths and pixel height */
     UWORD          dwb;                /* are given                    */
     UWORD          h;
     {
     MFDB          src, dst;            /* These are on-the-fly MFDBs   */

     vdi_fix(&src, saddr, swb, h);      /* Load the source MFDB         */
     src.ff = TRUE;                     /* Set it's std form flag       */

     vdi_fix(&dst, daddr, dwb, h);      /* Load the destination MFDB    */
     dst.ff = FALSE;                    /* Clear the std flag           */
     vr_trnfm(vdi_handle, &src, &dst ); /* Call the VDI                 */
     }


/*------------------------------*/
/*        trans_bitblk          */
/*------------------------------*/
     VOID
trans_bitblk(obspec)                /* Transform the image belonging  */
     LONG     obspec;               /* to the bitblk pointed to by    */
     {                              /* obspec.  This routine may also */
     LONG     taddr;                /* be used with free images       */
     WORD     wb, hl;

     if ( (taddr = LLGET(BI_PDATA(obspec))) == -1L)
          return;                   /* Get and validate image address */
     wb = LWGET(BI_WB(obspec));     /* Extract image dimensions       */
     hl = LWGET(BI_HL(obspec));
     vdi_trans(taddr, wb, taddr, wb, hl);     /* Perform a transform  */
     }                                        /* in place             */


/*------------------------------*/
/*         trans_obj            */
/*------------------------------*/
     VOID
trans_obj(tree, obj)               /* Examine the input object.  If  */
     LONG     tree;                /* it is an icon or image, trans- */
     WORD     obj;                 /* form the associated raster     */
     {                             /* forms in place.                */
     WORD     type, wb, hl;        /* This routine may be used with  */
     LONG     taddr, obspec;       /* map_tree() to transform an     */
                                   /* entire resource tree           */

     type = LLOBT(LWGET(OB_TYPE(obj)));            /* Load object type */
     if ( (obspec = LLGET(OB_SPEC(obj))) == -1L)   /* Load and check   */
          return (TRUE);                           /* ob_spec pointer  */
     switch (type) {
          case G_IMAGE:
               trans_bitblk(obspec);               /* Transform image  */
               return (TRUE);
          case G_ICON:                             /* Load icon size   */
               hl = LWGET(IB_HICON(obspec));
               wb = (LWGET(IB_WICON(obspec)) + 7) >> 3;
                                                  /* Transform data   */
               if ( (taddr = LLGET(IB_PDATA(obspec))) != -1L)
                    vdi_trans(taddr, wb, taddr, wb, hl);
                                                  /* Transform mask   */
               if ( (taddr = LLGET(IB_PMASK(obspec))) != -1L)
                    vdi_trans(taddr, wb, taddr, wb, hl);
               return (TRUE);
          default:
               return (TRUE);
          }
     }


>>>>>>>>>>>>>>>>>  Macro definitions for the code above <<<<<<<<<<<<<<<<<<

#define BI_PDATA(x)     (x)
#define BI_WB(x)        (x + 4)
#define BI_HL(x)        (x + 6)
#define OB_TYPE(x)      (tree + (x) * sizeof(OBJECT) + 6)
#define OB_SPEC(x)      (tree + (x) * sizeof(OBJECT) + 12)
#define IB_PMASK(x)     (x)
#define IB_PDATA(x)     (x + 4)
#define IB_WICON(x)     (x + 22)
#define IB_HICON(x)     (x + 24)


>>>>>>>>>>>>>>>>>>>>>>>>> VDI Copy Mode Table <<<<<<<<<<<<<<<<<<<<<<<<<<<<

Symbols: N = new destination pixel value (0 or 1)
         D = old destination pixel value (0 or 1)
         S = source pixel value (0 or 1)
         ~ = Boolean not (inversion)
         & = Boolean and
         | = Boolean or
         ^ = Boolean xor (exclusive-or)

Mode Number     Action
-----------     ------
    0          N = 0          (USE V_BAR INSTEAD)
    1          N = S & D
    2          N = S & ~D
    3          N = S          (REPLACE)
    4          N = ~S & D     (ERASE)
    5          N = D          (USELESS)
    6          N = S ^ D      (XOR)
    7          N = S | D      (TRANSPARENT)
    8          N = ~ (S | D)
    9          N = ~ (S ^ D)
   10          N = ~D         (USE V_BAR INSTEAD)
   11          N = S | ~D
   12          N = ~S
   13          N = ~S | D     (REVERSE TRANSPARENT)
   14          N = ~ (S & D)
   15          N = 1          (USE V_BAR INSTEAD)




-------------------------------------------------------------------------




ST REPORT CONFIDENTIAL
======================

Sunnyvale CA        Sam Tramiel will press for continued upswing in
------------        activity at Atari by personally overseeing all PR
                    releases for accuracy.

New York NY         Atari will be showing a number of new products at the
-----------         Comdex show this fall.  The rumor mill has it just the
                    opposite ....why?

Washington DC       The show was a success but why the NO SHOWS??  Migraph
-------------       Astra, Alpha etc....

Rockville MD        GEnie Online Services has awarded Gadgets by Small
------------        it's own Roundtable. Congratulations Dave!  It will
                    open in a few days.

Toronto CA          Seems a Beta Copy of Calamus got loose and is now in
----------          the US even with a translation of the RSC file!  From
                    what we have seen, the "other DTP packages" had better
                    watch out, this one is ULTRA SUPERB.

Orem UT             Word Perfect Corp. has announced through Jeff Fowler,
-------             that Version 4.1 will be the FINAL release of the ST
                    VERSION. Hmmm, here we go again!  ARRRRG!

Sunnyvale CA        Watch for all the ST units to be shipped with "mega"
------------        type cases and keyboards.

Long Island NY      Magic Shadow Archiver will process a "boot" disk so it
--------------      can be arced and sent over the modem, unarced and
                    processed and be as good as the original. Look for
                    this program it is shareware!




-------------------------------------------------------------------------




                         INSIGHT into the ST'S FUTURE
                         ============================
Part III - Software
-------------------

by Micheal Arthur

Of course, NO computer has a future without innovative software.  

PC-Ditto is an example of how innovative ST software can be, and has also
had a great effect on the ST market.  Right now, it is about 80 percent as
fast as an 8086 chip, only in SOFTWARE.

Avant Garde is upgrading PC-DITTO, though, so it will be JUST as fast as
the 8086 chip. Meaning that it, a $90 product, will be just as good as the
Amiga Bridgeboard, a $590 product.

But Commodore is making a new Bridgeboard, having the 286 chip inside, and
although it will probably not support OS/2, it WILL support other 286
specific programs, like Windows/286,(A new version of Windows custom made
for the 286 chip, intended to replace Windows 2.0)and will be MUCH faster,
at 10-12 MHZ. Although PC-Ditto will run at a similar speed with Turbo ST,
it won't have much room for improvement after the update in December.

So Avant Garde might take either of two paths:

1) Make a 286 version of PC-Ditto, which could only effectively run with
Turbo ST.  Although this would be logical, as well as pretty good, as it
would upgrade PC-Ditto's capabilities, it would require MUCH more work,
and might not be of much advantage to a lot of ST users.

2) Make a Hardware/Software combination, with most of the emulator itself
in software, but having the parts that would hamper the software's 
performance, or could be done better in hardware in an expansion card
that would go in the ST Expander.

This would be more versatile than software, as it would make support of
OS/2 possible, shorten the time that the emulator would take to be made
and could be subject to further improvement, including built-in graphics
chips letting PC-Ditto support the EGA standard with an ST Color Monitor.

Avant Garde could also take a third route, deciding to make other products
for the ST (Although they have said that they are a "one trick pony") or
making an expansion card so PC-DITTO can use the ST's extra (above 703K)
memory as LIM/EMS memory.


Omnicard
--------

NOT Hypercard, Omnicard.  A company called BerrysBit A.S.C is planning
to come with a "Hypercard-like" application, called Omnicard, at around
November.  This program  will have an Iconic User Interface, which is now
lacking in similar programs such as Zoomracks.

From their announcement on GEnie:

     "A completely integrated software package is also available from the
new desktop, including a word-processor, paint program, database,
telecommmunications, mini-desktop (particularly of interest to the power
user with a lot of folders), and an exceptionally easy to use program
"Authoring Environment" akin to Hypercard itself."

     "This Authoring Environment allows the novice to begin programming in
the most effective way, without him even realizing it!  A card metaphor is
used throughout, to heighten the Stack (We call them decks) image.  If you
can organize a speech, you can write a program. Buttons, icons, graphics
and text replace hundreds of lines of code, that to most look like Greek!"

     "Optimized on a Mega 2 or above, this will be THE program for the 
Atari ST."

In this respect, they are partly right, as Omnicard would give the ST many
benefits that Hypercard has brought to the Macintosh, like a simple, but
powerful programming language using the latest concepts in how computers
work.

While it will not be THE program for the ST, it will have a great impact,
at least on how OTHER computer users view the ST.


Desktop Publishing
------------------

Desktop Publishing (or DTP) products for the ST will begin to rival their
IBM and Mac counterparts, as shown by the upcoming Publishing Partner
Professional, and Calamus (by ISD, the makers of VIP Professional). The ST
will also become a very good choice for it, as the 1280*960 monitor w/card
being made in Europe makes it to the US, maybe also being sold by ISD.

While the Mega ST and SLM 804 will also help the ST to further penetrate
this market, the ST will never become remotely as successful in the DTP
market as they have,and will continue to be in the MIDI market, as IBM and
Mac products will continue to bring more performance than ST programs,
causing it to only be considered in a small degree


Spreadsheets
------------

Spreadsheets are the most widely used applications for computers today, 
and it is not coincidence that most computers setting a standard have had
their first big break with a spreadsheet having features above and beyond
what had been previously seen. (Lotus 123 and Excel, for examples)

Even though some GOOD spreadsheets are coming out for the ST, and one in
particular, LDW Power, will be better than Lotus 123 Revision Two, I don't
think the ST has much chance in this area, as Lotus is making a Revision
THREE of 123, and products like Wingz for the Macintosh,which OUTDO Excel,
will be light years ahead of the ST, which won't have anything even half
as good as Excel for a while.

As ST users can just get a Spectre 128, this won't really matter if you
need to use its features NOW, but that doesn't count when people consider
a computer based on its own merits and applications.  In fact, this might
just be a "chicken and egg" problem, as ST spreadsheets as good as Excel
won't come out as quickly unless more businesses buy ST's, and more
businesses WON'T buy ST's if it doesn't have a spreadsheet powerful enough
for them.


Advertising, and Public Opinion about Atari
-------------------------------------------

Contrary to opinions of a few, MOST people will NOT consider the ST based
on the rational, "Is it a good computer, with good applications out for it
at a decent price?", but will most likely express strong reservations
towards the ST.

NOT because they have anything against it, but simply because of the
belief out there that an Atari is not really a computer.  While this is
an OBVIOUS fact to almost ALL ST Enthusiasts, it seems that some people at
Atari do not seem to realize that the general consensus of opinion is that
the name Atari stands for "Good Game Machines".  Thanks to the Atari 2600,
and the Arcade Machines that Atari Games (the only part of Atari still 
owned by Warner Brothers) is noted for.

And usually, the ONLY way to completely cure a bad PR problem is to do the
ONE thing that Atari has not said they will do, the MAIN thing that Apple
did to make the Macintosh popular among IBM users, who never before saw a
need for anything other than DOS, the MAIN thing that caused the C-64 to
become the second best selling microcomputer of ALL TIME, and one of the
things that Commodore has said they WILL do for the Amiga.


ADVERTISE.

And NOT just in ST Magazines, where the readership ALREADY owns Ataris.

I am NOT suggesting that Atari start a major advertising campaign when
they are obviously not ready to meet the demand that it would bring, but I
DO suggest this:

That Atari start advertising,at least on a small scale,with a few good ads
on TV for the ST, or with a few good business-related ads in computer
magazines such as Byte.

When the Atari Factory starts up next year, and Atari WILL be able to meet
the demand that advertising will bring for the ST's, then Atari will
probably start a major advertising campaign.

Their main focuses should (and probably will) be:

1) In TV advertisements, to educate the American public about the ST's
capabilities, and to FIX the perception that Atari is just a Game Machine
company.

2) To start advertising in business-related publications, emphasizing the
ST's raw power with the good products now out for it, while showing the
option of using Mac software.

IBM applications won't be emphasized so much, as PC-Ditto is only as fast
as an IBM PC.

3) To support large-scale advertisements of ST software products.

4) In the Educational Market, advertising HEAVILY to both Universities
directly,trying to displace the trend of using Macs and IBMs there, and to
publications that deal with this market, with ads showing its superiority
to the Apple II series.

To better aid this, though, Atari MUST support ST software developers in
making products for this segment of the market, as well as supporting
a network of educational dealers, who would already have been full-service
ST dealers, but who would have a staff specifically targeted for the needs
of this market.  Commodore has already begun to do this with the Amiga.

IF Atari is smart, they will also give GOOD Educational Discounts and
Specials to Schools for the ST, maybe having a 520 or 1040 ST with Color
Monitor and a package of several good pieces of educational software, for
a price of under 1000 dollars, directly competing with the Apple IIgs.

Also, Atari's problems with "Atari Bashers" will definitely decrease SOON,
maybe even STAYING at a tolerable level if Atari makes sure that the Atari
Factory is open before December.  Also, Atari will be MUCH more open to
suggestions in the future.


The Atari Factory
-----------------

Of course, ANY plans that Atari makes must be dependent on the ability to
manufacture these products, as experienced business executives know that
you cannot successfully come out with a product that will be VERY popular
unless you have a decent manufacturing base to meet the demand.

Seeing this, Atari plans to make a manufacturing plant in the US, to be in
Houston, Texas.  This plant will primarily attend to the demands of the US
ST market, and will probably preclude any advertisements by Atari.

IF Atari is smart, they will seriously consider making their OWN RAM chips
for the ST in THIS factory.  Not only would making their own RAM chips be
less expensive than buying them, in ANY RAM market, but the import fees
of things made in Europe and Japan are generally more than the price of
importing things from the US there.


However,they haven't yet gotten the facilities, and it will probably not
be producing ST's or ST peripherals with it until the beginning of next
year.

This would be a disaster, meaning that there would be little to no
advertising for the Atari ST during most of the Christmas season.  Also
meaning that the momentum generated by the new ST computers/peripherals
would be a fraction of what it could be.

And Commodore plans to advertise HEAVILY for the Amiga, both coming out
with new Amiga products (like the 286 Bridgeboard) and advertising to sell
Amiga 500's in the home and educational markets.



Miscellaneous ST Info
---------------------

Here are the addresses and phone numbers for info on some of the products
previously mentioned:


OmniCard

      BeerysBit ASC,Inc;
      8174 Century Circle East #8
      Indianapolis, In 46260
      (317)872-8622


Spectre 128

      Gadgets By Small, Inc.
      40 W. Littleton Blvd., #210-211
      Littleton, Colorado 80120
      (303)791-6098


Turbo ST, ST Expander

      Megabyte Inc.
      109 W. Bay Area
      Webster, Tx 77598
      (800)255-5786

(A little sidenote on this;  Megabyte Inc.'s 800 Number is VERY GOOD, 
superlative in fact, having people who KNOW a LOT about their products,
and who are VERY courteous.  THIS should be the model for ALL companies,
ST or otherwise, to follow, as even the LONG DISTANCE numbers of some
companies tend to bring less than preferable service.)




-------------------------------------------------------------------------



                            GEM Multi-Tasking
                            -----------------

30-Sep-88  20:50:31
Sb: #111893-#Farewell
Fm: JOHN RULEY 76227,117
To: Neil Harris 73256,3275 (X)

I just got the word that I can let the cat out of the bag NOW:

I spent last weekend at DRI in Monterey.  GEM multitasks.  Read that 
again: GEM MULTITASKS!  
No compromises - and a *nice* interface, with multiple "virtual

consoles", each of which can hold several windows.  Desk accs are gone - 
but, then again, they really aren't.  The DESK menu still has 6 positions
for application names, which can be used to launch any GEM app as if it 
was an accessory.

This is all running RIGHT NOW - I saw it work.  And here are two biggies:
I saw it running on a Hercules monochrome system (720x348 BW graphics) and
it was updating as fast as the graphics would allow WITH FOUR WINDOWS
OPEN, and you can run DOS programs in it!  It traps the screen I/O and 
displays inside a window - I saw WORDSTAR running on screen concurrently 
with GEM output.

Folks - it's a whole new ballgame!

John.



-------------------------------------------------------------------------

a short but sad note...


                            WORD PERFECT & ATARI
                            ====================


a few words from:

Jeff WILSON, Word Perfect Corp

....Once again,  the situation has changed, probably for the last time for
a while.  I will still be working on the ST, but at this point primarily
to support and enhance the existing  version  of WordPerfect.  New major
versions of WordPerfect and other products have  been placed on hold for 
primarily one reason:   WordPerfect Corporation  has watched the presence
of Atari Corporation in the US marketplace significantly diminish over the
last year.

Atari has reduced the number of dealers supporting them,  and been 
allowing  only a minimal number of ST's into the  US  marketplace, has 
failed to support dealers, developers, or Atari owners, and has, quite 
frankly, lost WordPerfect Corporation's faith.  WPCorp will not commit 
itself to several years worth of R&D for a  market in this condition.  
The hold will probably remain in effect until Atari market conditions 
change significantly.  This is not an official statement, but I will not
misrepresent the current state of affairs.

As a die-hard Atari fanatic, it disappoints me terribly to have come down
to this.  However, from a business standpoint, I understand and agree 
with the decision.  I hope that WordPerfect Corporation will be able to  
complete and release the many exciting  projects  that have been underway
since the release of WordPerfect 4.1 for the Atari, but this will only 
happen on the condition stated above.  We will continue to fully support
4.1 for the Atari, in fact, you will probably see enhancements that would
not have come about any other way.

                                             Jeff R. Wilson




-------------------------------------------------------------------------

THIS WEEK'S QUOTABLE QUOTE
==========================

  READE'S LAW
  -----------
        There are two sides to every argument, unless I am 
        personally involved, in which case there is only one..MINE!


-------------------------------------------------------------------------
ST-REPORT Issue #55   OCT. 03, 1988   (c)'88 APEInc. All Rights Reserved.
Reprint permission granted except where noted in the article. Any reprint
must include ST-Report and the author in the credits.  Views Presented 
herein are not necessarily those of ST-Report or of the Staff.  All items
and articles appearing in ST-REPORT are copywrite (c)APEInc.
-------------------------------------------------------------------------