[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::atarist

Title:Atari ST, TT, & Falcon
Notice:Please read note 1.0 and its replies before posting!
Moderator:FUNYET::ANDERSON
Created:Mon Apr 04 1988
Last Modified:Tue May 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1433
Total number of notes:10312

250.0. "ST Report" by PNO::SANDERSB (a belagana) Mon Sep 26 1988 17:40

                      ST REPORT WEEKLY ONLINE MAGAZINE
                            Monday, SEPT. 19, 1988
                               Vol II  No. 53
                                ===========

            APEInc., P.O.  BOX 74,  Middlesex, N.J.  08846-0074

  PUBLISHER                                              GENERAL MANAGER
  Ron Kovacs                                               R.F.Mariano

          =======================================================

                     ST REPORT EDITOR: Thomas Rex Reade

                PO Box 6672 Jacksonville, Florida. 32236-6672

                        Headquarters Bulletin Boards

 ST Report North                                         ST Report South
  201-343-1426                                             904-786-4176

                   ------------------------------------
 ST Report Central                                       ST Report West
  216-784-0574                                             916-962-2566
                                 CONTENTS
                                 ========
> From the GM'S Desk..................> A CONFERENCE WITH THE PRESIDENT...
> INSIGHTS, Atari's Future............> ST Pro GEM #4.....................
> Shakespeare and FUJI.................> Garbage on the Line...............
> Of Special Note.....................> ST REPORT CONFIDENTIAL............

=========================================================================
EXCLUSIVELY ON:    COMP-U-SERVE  ~  GENIE  ~  DELPHI ~  THE SOURCE
=========================================================================


From the General Manager's Desk,

Greetings.... Happy New Year to all our Jewish friends!  Perhaps at this
time of year Atari has chosen the best time to have a LANDMARK conference
on CIS.  In fact, we at ST REPORT believe so strongly that this is the
right time, we have included many points to ponder about the future of the
ST and Atari in general throughout this issue.  We have done this so you
have a concise source of good subject matter to build worthwhile questions
for the "BIGWIGS" at Atari.

Please make sure you ask YOUR question and do remember that NO question is
a stupid question ....only someone who says a question is stupid is dumb!
This is a rare opportunity for the Atari Userbase, Usergroups and
potential business users.  Use it to your best advantage!  Ask those
Questions that have been nagging you....the answers may surprise you.

ONLY IN AMERICA!        God, I love to brag about the USA!

                                           R.F.Mariano




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




                      A CONFERENCE WITH THE PRESIDENT
                      ===============================


ATARI TOP EXECS TO ATTEND PUBLIC FORUM
--------------------------------------

The Atari Forums on CompuServe will be sponsoring a world-wide electronic
Teleconference with Sam Tramiel, President and Chief Operating Officer,
Sig Hartmann, Executive Vice President and Software President  of Atari 
Corporation and Neil Harris at the keyboards on Monday, September 26 at 
9:00pm EDT.  Your participation in this conference is welcomed and 
encouraged!

The Presidential Conference is going to be held in CompuServe's
Electronic Convention Center(tm).  The Electronic Convention Center(tm)
was designed specifically for special conferences of this nature and can
have as many as 300 people participating simultaniously without causing
the slightest speed decrease.  In addition, the Electronic Convention
Center(tm) offers the capability of holding a more structured
conference, making it possible for you to ask your questions and be
answered by the respondants without any interruptions.  Top performance is
absolutely guaranteed!  Lastly, the Electronic Convention Center(tm)
offers additional conveniences (discussed later in this text) that will
make your participation in this conference amazingly easy.  If you've
participated in other national conferences of this type before and have
been underwhelmed at the way it was conducted and the performance of the
service during 'heavy' usage, this conference is your opportunity to
experience the communication power of a professional-quality global
information network.

ACCESSING THE CONVENTION CENTER
-------------------------------
As mentioned above, the Presidential Conference will be held in
CompuServe's Electronic Convention Center(tm) -- NOT the conference area
of the Atari 16-Bit Forum.  To access the Convention Center, type GO
CONVENTION at any CompuServe command prompt.

When you type GO CONVENTION, CompuServe will display the following menu:

                     Electronic Convention Center(tm)

                       INFORMATION/RESERVATIONS
                          1 Instructions
                          2 List Conferences/Make Reservations
                          3 Review/Cancel Reservations
                          4 Conference Etiquette

     Enter choice !

Choice 1 allows you to view the complete instruction guide for using the
Convention Center.  Choice 2 and Choice 3 allow you to list upcoming
special conferences and any advance "reservations" (NOT NECESSARY FOR
THIS CONFERENCE!) you might have made.  Lastly, choice 4 provides some
information on the etiquette followed by participants in an electronic
conference.

On Monday, September 26, at 8:30 PM EDT (a half hour before the 
Presidential Conference is scheduled to begin), the Convention Center menu
will appear as shown above with the addition of menu choice 5 which will
allow you to enter the Presidential Conference.  An example of how the
Convention Center menu will appear from 8:30 through the end of the
conference on September 26 appears below:

                   Electronic Convention Center(tm)

                     INFORMATION/RESERVATIONS
                         1 Instructions
                         2 List Conferences/Make Reservations
                         3 Review/Cancel Reservations
                         4 Conference Etiquette

                    JOIN CONFERENCE IN PROGRESS
                   5 Atari President's Conference

     Enter choice !

All you will need to do is select choice 5 in order to join the
conference.

Once you select choice 5, CompuServe will prompt you to enter your name:

   What is your name? John Doe

Enter your name and press a <CR> as shown in the above example.

If you enter the conference area before 9:00 PM EDT, you can chat
briefly with other early arrivers until the moderated conference begins.

ASKING A QUESTION
-----------------
Once the moderated conference begins, only the moderator and guest
speaker will be allowed to openly communicate at all times.  Other
participants must signal that they would like to ask a question or make
a comment by using the /QUESTION (or /QUE) command.  Once you issue the
/QUE command, CompuServe will add your name (in order) to the queue.
When it is your turn to speak, CompuServe will beep your terminal and
display a message explaining that it is your turn and you may now ask
your question.  If you attempt to openly communicate before it is your
turn to speak, the Convention Center will send you a reminder that in
order to ask a question or make a comment, you must enter the /QUE
command and wait for your turn.

If you issue the /QUE command and change your mind about asking a
question, you can enter the /UNQUE command to remove your place from the
queue.

USING THE BUFFER
----------------
The Electronic Conference Center(tm) makes it possible for you to
compose or upload your question or statement into a buffer area,
followed by giving you the option of editing the text using standard
CompuServe EDIT commands (explained in detail in EDIT.TXT, available in
LIBRARY 1 of the Atari 16-Bit Forum).  Then, you can send your
pre-composed buffer when it is your turn to speak in the conference.
Here are the commands you will need to know in order to use the buffer
feature of the Convention Center:

  /BUFFER EDIT  -  Brings you into "edit" mode where you can
                   compose, ASCII-upload, or edit your text.

  /BUFFER SEND  -  Send buffer to all participants.

OTHER COMMANDS YOU SHOULD KNOW ABOUT
------------------------------------
The following list of commands are available to you in the Convention
Center:

/BUFFER EDIT Edit text buffer        /BUFFER SEND Send text buffer
/BULLETIN    Display short bulletin  /COMMANDS    Show list of commands
/DAY         Show date and time      /DISPLAY     Change message display
/ECHO        Show input              /EXIT        Exit the conference
/NOECHO      Do not show input       /HELP        Command help text
/NAME        Change your name        /NOSEND      Refuse private "sends"
/OFF         Log-off                 /SEND        Send a private message
/STATUS      User/guest count        /WHO         Show last speaker
/USERS       List users           
/LOOK        Question status (how many people are in the queue)
/QUESTION    Question request        /UNQUEUE     Cancel a question

If you have any questions, please feel free to post a message to the
Sysops of the Atari Forums.  Otherwise, hope you found this introduction
file useful and we're looking forward to seeing you at the big
conference!



**************************************************************************
  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 09-30-88      ****


  NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
**************************************************************************



                        SPECIAL SUPRA MODEM OFFER!!!
                        ============================


CompuServe's Atari Forums have made very special arrangements with 
Paramount Products Inc. to offer the members of our forums the chance to 
upgrade your system to 2400 baud service at a very special price.  

For a limited time, CompuServe subscribers may purchase the 

             SUPRA CORP. 2400 baud Hayes-compatible modem 
           for the very **LOW** price of just $139.95 !!!!! 

These are brand new, not reconditioned units, with the full SUPRA CORP. 
warranty.  The SUPRA MODEM uses the Hayes Smartmodem 'AT' command set and
operates at 300-1200-2400 baud.  It's an outboard unit (not an internal 
plug-in card) allowing ease of transfer to other computers.  
Connection is thru the standard RS-232 interface. (Just plug it into the 
back of your ATARI ST).

       To take advantage of this special offer, Phone the 800 number 
       listed below or write to:

                        Paramount Products Inc.
                        1405 S.E. Pacific Blvd.
                        Albany, Oregon   97321

         *****          Phone orders: (800)444-4061        *****

     Price:    $139.95 + shipping
     UPS ground:     add $4.00
     UPS Blue label: add $8.00
     C.O.D.:         add $2.25

  MasterCard or VISA accepted Orders will be shipped the next business day

   If you've been accessing CompuServe at 1200 baud, this is a  great way
to lower your total online bill since CIS does *NOT*  charge a premium for
2400 baud access.  (You can get the same amount of information or download
the same amount of programs in approximately 1/2 the time as 1200 baud 
users!) This modem will PAY FOR ITSELF in just a few sessions.




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




                  INSIGHTS INTO THE FUTURE OF THE ATARI ST
                  ========================================


by Michael Arthur

In the computer user's quest for more sophisticated machines that will do
more, function better, and be easier to use, many options have appeared
throughout the brief history of the microcomputer.  For many, the answer,
for some reason, has been IBM machines.  For them, the future lies in many
developments, like OS/2, but mainly in the 386 chip, which will carry them
into the 1990's.  Some, though, have forsaken this route for a new type
of user interface, using a new mechanism called a mouse, and using menus
and windows and dialog boxes to use their machines much easier than what
was previously available.  Many of these people have chosen the Macintosh,
which has the best implementation of this new way of using a computer, and
has a pretty bright future, as Apple is VERY financially secure, and as
products like Hypercard and the Mac II give performance that is equal or
better than the IBM machines, resulting in that many people have stopped
using them whenever possible, and do not prefer IBM's to the Macintosh.

One thing about the Macintosh, though, is that is oftentimes too expensive
for many people, and lacks features necessary in computers in all but the
most expensive Macintosh, the Mac II. Many peripherals (mostly the ones 
made by Apple) and most of the software is also expensive, turning many
people to look elsewhere.

Some of these people have chosen the Amiga, with its amazing graphics, and
built-in multitasking.  The Amiga, though, does NOT have a Mac-like user
interface that is preferable, and has a text-based user interface that is 
even worse than what was in IBM's. Also, its multitasking operating system
crashes a LOT, another thing that is never preferable. 

So many people look elsewhere, and see the Atari ST.

It is VERY fast, has a user interface that is very good, which, although
not better than Mac Finder, is good enough for most people.  It also has
many emulators out for it, a built-in MIDI interface, which makes it the
ONLY choice for many professional musicians, and more built-in memory than
ANY other computer.

But after getting an ST, they find out that the ST also isn't perfect, and
that their fears about Atari itself may not be unfounded.

Things like Federated, Atari's relations with its dealers, Atari's record
of Vaporware, and the shoddy Developer's Kit (something NEVER seen in
companies like IBM;  Atari says that upgrades, newsletters are sent very
often to developers buying one, but....) have caused many otherwise loyal
ST owners to openly protest Atari's actions. These people have been called
Atari Bashers, the most vocal of them said to be in a group called the
Gang of Five.  Such actions, though disagreeable and embarrassing to most
ST users, who both hate to hear such negative things and despise having to
SAY these things about Atari are forced to do so because it is the only 
way, (apparently), to obtain any kind of reaction from Atari that is 
evident.

Even now, while Atari does an admirable job of keeping quiet about 
developments, ST users are being treated to excellent goodies  both from 
Atari and third party developers and companies.  
Here are few of the fine treats to expect from Atari in near future.....
         ---        -----------                -----         ------

IF any of the information  presented is inaccurate, please remember the
limited resources available for this article.  Also, because of the lack 
of space, this article only focuses on the Atari hardware/software areas 
and developments that are certain to have an effect on the ST's future.  


THE ATARI ST COMPUTER LINE
--------------------------
   The ST, right now, has only support of 4 Megabytes, uses only an 8 MHZ
68000, and supports graphics which, although they allow the ST to run at
its fast rate, leaves much to be desired.

Atari HAS announced a 68030 add-on to the ST, known as the EST, though.

It has 4 megs of RAM on board, uses a VME bus, supports the SUN Network
File System, has SCSI/DMA ports, uses XWINDOWS with UNIX Version 5.3, and
comes with an 80 Megabyte Hard Disk. 
 
It supports resolutions of 1280*960 in monochrome (and maybe 16 colors), a
1024*768 display with 256 colors at the same time, and a 640*400 mode 
using the entire palette of 16 million colors, at the same time.

The prototype is running at 16 MHZ, but it will sooner or later support
20-24 MHZ and up.  It will cost around 3500-5000 dollars, and will be
officially announced at Winter Comdex.

This will be one of the first computers of ANY kind to use the 68030, and
the FIRST microcomputer to use it.  But in the long run, it might not 
become that popular.

After the initial reviews saying how powerful it is, how it supports more
colors than previously seen in micros, and how reliable it is, (IF Atari 
wants it to sell, and if they are wise, they will boast about it's
reliablity and make sure the public knows....also, a GENEROUS warranty
program is definately in order.  1 - 3 years!


1) Provide an adequate staff of knowledgable people for Customer Support 
who know more than just a general briefing given by a "marketing experts"!
The only other solution would be to have a well-known third party who
already makes and supports UNIX for several machines provide UNIX support,
and cause the current staff of Technical Support to reflect the above
type of knowledge concerning the hardware and software.  This is
mentioned because the NEW Technology will require expert Technical
Support, and what Atari has in place at this time is totally inadequate
and cannot properly fill this need.


2) Advertise HEAVILY for this machine so people will consider it.  We
ALL know that Atari is not a household name in business computing,
therefore it is encumbent upon Atari to properly promote the entire
ST product line. At least, it's ABOUT TIME!  On these grounds, it might 
be hypothesized that Atari might not have a chance, and is wasting its 
time, but this computer WOULD show the business world that Atari makes 
much more than game machines.  

IF Atari does a FEW things right, then the EST might have a shot at the 
VERY lucrative workstation market, and even become associated with the 
68030 like the Mac II is with the 68020.


Portable ST
-----------
Atari has also "hinted" at a Portable ST, which will have a 20 Megabyte 
hard disk, and a megabyte of memory.  The Portable will probably come 
with features like a MIDI port, built-in floppy drive, the blitter chip 
and the new TOS ROMs.

The display will come from another company, like Zenith, simply because 
"manufacturing LCD panels, where EVERY pixel must be operable, can strain
the fabrication facilities of many companies."  This is taken from the 
September issue of Byte, on page 246.  And, while "prototypes are one 
thing, production runs are quite another", meaning that while Atari might
have a prototype of the Portable ST ready and all might be well, when it 
comes time to produce the LCD screens, not even the new Atari Factory in 
Houston might be able to do it right at a cost that would make it 
feasible, and Atari will get another company to custom-make the panels 
for the Portable ST.

The Portable ST's screen will probably use a rear-lighting, or backlit,
LCD panel, to make it more readable, EVEN in bad lighting.  LCD screens 
can display 640*400 screens, but ALSO support 320*200 and 640*200 
resolutions, without colors, of course. 

Possiby, this ST will be able to switch from Low to Medium to High 
Resolution, and able to run both Low/Medium Resolution AND High 
Resolution software, with Patched TOS ROMs to make it work.

IF Atari is wise, they will seriously consider using an LCD screen that 
displays colors as shades of blue-gray upon a white background, instead of
the (MUCH) worse looking amber screens.  They would also cost about the
same as amber screens....

If Atari chooses to have a detachable keyboard, a smaller version of the
keyboard used for the Mega ST, maybe having a numeric keypad, which is 
often lacking in Laptop keyboards....they would have the "LAPTOP" market
in the basket!

Since the Macintosh became popular, Mac Users have wanted VERY much to 
have a Portable Macintosh, for the same reasons that ST users have wanted
a Portable ST. One or two of these have shown up, but often they have cost
around 4500-5000 dollars, near the price of a Mac II.

The ST is STILL the ONLY computer to emulate a MacIntosh, thanks to Dave
Small, and since the Portable ST will have a Cartridge Port, it could be
optionally sold with Spectre 128 (the Mac Emulator made by Dave Small that
uses 128K ROMs) and advertised to the Mac crowd as the ONLY Portable
computer that can use Mac software.

This would cause a VERY large group of people to become ST Users, and 
would give the ST a LOT more credibility and market penetration among 
business users.


Atari Abaq 
----------
            Transputer Futures and the Helios Operating System
            --------------------------------------------------

The future of the Abaq seems very interesting.  It is obviously aimed at
Universities and research facilities, who have used Transputers, and other
parallel processors, mainly as "calculating engines", with a PC as a
front-end and would more likely use Reduced Instruction Set Computer 
(RISC) Chips in day to day operations.

Two versions of the Abaq are planned.  One will be an add-on for the Mega
ST, which would handle I/O operations, especially for the 40 Megabyte hard
disk that will be included, and the other will be a stand-alone machine,
with a case similar to the Mega ST's, with an ST motherboard underneath 
the Abaq motherboard.

The Abaq supports 4 display modes.  Mode 0 will support a 1280*960 display
with either 16 colors or monochrome,and Mode 1 has a 1024*768 display with
256 colors at the same time.  Mode 2 has a 640*400 display, but has two 
separate screens instead of one, for quick, seamless animation.

When it is released, hopefully December, (with software 
available) the Abaq will have 4 slots, for expansion cards to be made by 
Atari. 
  
   ED. NOTE:  We have it on reliable info that Atari plans to release the
   --------   ABAQ (Transputer) in EUROPE (UK) FIRST!!!

They will come in two configurations, one a Transputer "Farm" card,having
4 Transputers in it, and a memory expansion card, having 20 MEGABYTES of
DRAM chips, resulting in that you could have 84 Megs of Ram, or 17
Transputers, with all slots filled, or combinations using 3 Farm Cards
and 1 memory expansion card to have 13 Transputers and 24 Megs of RAM.

Since one Transputer runs at 10 Million Instructions Per Second (MIPS),
having 4 Farm Cards, or 17 T-800's, would let the Abaq have 170 MIPS of
computing power, qualifying it as a low-end Supercomputer, for around 15
to 25 thousand dollars, a cost MUCH lower than the $100,000 computers that
provide power similar to the Abaq's fastest configuration.


Helios Operating System
-----------------------
The Abaq itself is impressive, but its operating system, Helios, makes it
revolutionary, and the future of the Abaq depends on the popularity
of Helios.  One of its features (and the main goal of Helios) is to allow
Abaqs be networked in a way that all of the Transputers in all of the
machines could potentially be available to ALL users, meaning that if you
had 4 Abaqs in a network, and 3 Abaqs were idle, the fourth one could use
the Transputers in the other three to FURTHER speed up its operations, the
3 Abaqs acting as "compute servers". 

To make it as familiar as possible, Helios is designed to resemble Unix as
much as possible. It's shell is JUST like the Unix C-Shell, using all Unix
commands, and Helios emulates Unix system calls to the point where MUCH
Unix software can be ported by little more than recompiling it.  Meaning
that the Unix software on the EST could be easily ported to the Abaq, so
one computer's software market could theoretically support the other's, or
at least that the Abaq could quickly develop a large software base.

The Abaq will use XWINDOWS, implementing GEM on top of it for a graphic
user interface, adding an entirely new dimension to Unix, and making the
learning curve for the less-experienced user relatively little.

Both parallel processors and RISC chips are said to be the future of
computers, and the Transputer uses both of these technologies. The Abaq is
the first computer to use this chip with a standard operating system, and
has virtually no competition in computers using either type of chip.  It
is, without a doubt, for the high-end of the market, who would need this
type of power available, and who would more likely have a use for this
state of the art technology.  

It will definitely be found in universities and research facilities, and
will be able to grab this end of the market WAY before any other company
comes out with a similarly priced (as in the $10,000-$15,000 range) 
computer having any type of parallel processor, perhaps even becoming a
leading computer in this area.  In fact, it might even find its way into
the segment of the market that the EST is aimed at.  

Helios will help to make the Transputer's popularity possible, although it
will not be exclusive to the Abaq, as several companies, such as
supercomputer firms, will also use it in their Transputer machines.

Even Commodore is working with a German Institute to make a Transputer
equipped workstation, with an Amiga 2000 to handle I/O operations.  This
does not figure to be any competition, as it will not be out for a while,
and even now it is reportedly not as good as the Abaq.


CD-ROM -  Atari PC-5
--------------------
The Atari CD-ROM is supposed to be out at around November, costing 599.95
retail.  At this time, a few software companies will announce CD-ROM 
products for the Atari ST, and it seems that the reason this product has 
been held over so long is that after Atari finished developing it, around
April, they sent developer kits to certain companies, and it is the wait 
for both these companies and the upcoming Atari Factory that have kept 
the CD-ROM from being put out.

But they were not idle during this time.  They have provided support for
CD-ROM standards, like High Sierra, and made an interface card, so IBM's
and compatibles will be able to use it.

The PC-5, Atari's 286 clone, will probably not come out until early next
year, and when it is out, it won't sell that well, as IBM clones are now
a dime a dozen, and NO ONE is likely to buy an Atari PC unless Atari sells
it for an extremely low price, well below the competing IBM Clone prices,
combined with spectacular features (VGA, 2 Megs of LIM/EMS RAM) and HEAVY
advertising, all of which would not make Atari that much profit, and which
would drain resources that would be best spent on the Atari ST.

The AMY chip is still in production, and will probably not be seen in any
Atari product until late 1989!  By that time it will most likely be passe!

The Atari Laser Printer has the potential of being popular, but ONLY with
the Imagen Postscript Module that Atari is planning to include as an
option.

It would be MUCH better to increase the price of the SLM 804, by maybe 200
dollars, but to include the Ultrascript Module as standard.  Some people
need only a "dumb" laser printer, but MANY will want Postscript
compatibility, almost ALL will want to have both at a good price, and it
seems that IF Atari can get it out and advertise for it, then Atari might
still get the market share that they lost by letting it become vaporware.


ST Game Machine
---------------
Atari IS going to make an ST Game Machine, that will be a stripped down ST
with Cartridge-based games to be played on an ordinary TV.  Look for it to
hit the markets during the first quarter of 1989.

                 If you MUST have the 68000 game machine...

              NAME IT SOMETHING TOTALLY ALIEN TO THE ST LINE!  

There is VERY little difference between the terms, "ST Game Machine,
and.. "The ST IS a Game Machine"!!!!


"TOS has a future"
------------------

A quote, from Neil Harris.  While this is about as obvious as saying that 
IBM has a future, it DOES confirm many things about the future of TOS.

This fourth revision of TOS that Atari is developing will be out by the 
first of the year, at a cost of $70.00-90.00.  ST REPORT ISSUE # 51 has
all the ALLEDGED features listed....graciously provided by Atari.

EXCEPT ONE IMPORTANT FEATURE FOR HARD DISK SYSTEMS:  
read & write to more than twelve partitions of more than 16mb max per
partition! 




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




                           ANTIC PUBLISHING INC.
                              COPYRIGHT 1988
                          REPRINTED BY PERMISSION.





    Professional GEM  by Tim Oren
    Column #4 - The Resource file


      Welcome  to  the  fourth installment of ST PRO GEM.  We are about to
   delve  into  the mysteries of GEM resource structure, and then use this
   knowledge  to  create  some  useful utilities for handling dialogs.  As
   with  the  past columns, there is once again a download file.  You will
   find it under the name GEMCL4.C in the ATARI 16-bit Forum (GO PCS-58).

      The  first  and largest part of the download contains a C image of a
   sample  resource file.  To create this listing, I used the GEM Resource
   Construction  Set  to  create  a  dummy  resource  with  three  dialogs
   including  examples  of  all  object  types,  then enabled the C output
   option  and saved the resource.  If you have access to a copy of RCS, I
   suggest that you create your own listing in order to get a feel for the
   results.   Then, using either listing as a roadmap to the resource, you
   can follow along as we enter...


   A MAZE OF TWISTY LITTLE PASSAGES
   --------------------------------
      While  a GEM resource is loaded as a block of binary information, it
   is  actually  composed of a number of different data structures.  These
   structures  are  linked  together  in  a rather tangled hierarchy.  Our
   first job is to map this linkage system.

      The  topmost  structure  in  a resource file is the resource header.
   This  is  an  array  of words containing the size and offset within the
   resource  of  the  other  structures which follow.  This information is
   used by GEM during the resource load process, and you should never need
   to  access  it.  (The  resource  header does not appear in the C output
   file;  it is generated by the RSCREATE utility if the C file is used to
   recreate the resource.)

      The  next structure of interest is the tree index.  This is an array
   of  long  pointers,  each of which addresses the beginning of an object
   tree. Again, you wouldn't normally access this structure directly.  The
   GEM  rsrc_gaddr  call  uses  it  when  finding  trees' addresses.  This
   structure is called "rs_trindex" in the C output.

      If  you  look at the contents of rs_trindex you will notice that the
   values  are  integers,  instead  of the pointers I described.  What has
   happened  is  that  RCS  has converted the pointers to indices into the
   object array. (If you actually used the C file to recreate the resource
   file, then the pointers would be regenerated by RSCREATE.)

      Now you can follow the link from rs_trindex to the objects stored in
   rs_object.   Take  (for  instance)  the  second entry in rs_trindex and
   count  down  that many lines in rs_object.  The following line (object)
   should start with a -1.  This indicates that it is the root object of a
   tree.  The following objects down to the next root belong to that tree.
   We'll pass over the details of inter-object linkage for now, leaving it
   for a later column.

      There  are  a number of different fields in an object, but right now
   we'll  concentrate on two of them: OB_TYPE and OB_SPEC.  The OB_TYPE is
   the  field  which contains mnemonics like G_STRING and G_BOX indicating
   the  type  of  the object. The OB_SPEC is the only field in each object
   which is a LONG - you can tell it by the L after the number.

      What's  in  OB_SPEC  depends  on the object type, so we need to talk
   about what kinds of objects are available, what you might use them for,
   and finally how they use the OB_SPEC field.

      The  box  type objects are G_BOX, G_IBOX, and G_BOXCHAR.  A G_BOX is
   an  opaque  rectangle,  with an optional border.  It's used to create a
   solid  patch  of color or pattern on which to place other objects.  For
   instance, the background of a dialog is a G_BOX.

      A  G_IBOX  is  a hollow box which has only a border.  (If the border
   has  no  thickness,  then the box is "invisible", hence the name.)  The
   favorite  use  for  IBOXes is to hold radio buttons.  There is also one
   neat trick you can play with an IBOX.  If you have more than one object
   (say  an  image and a string) which you would like to have selected all
   at once, you can insert them in a dialog, then cover them with an IBOX.
   Since  the box is transparent, they will show through.  If you now make
   the  box  selectable,  clicking  on it will highlight the whole area at
   once!

      The  G_BOXCHAR  is just like a G_BOX, except that a single character
   is  drawn in its center.  They are mostly used as "control points": the
   FULLER,  CLOSER,  SIZER, and arrows in GEM windows are BOXCHARs, as are
   the components of the color selection gadgets in the RCS.

      The OB_SPEC for box type objects is a packed bit array.  Its various
   fields  contain  the background color and pattern, the border thickness
   and color, and the optional character and its color.

      The  string  type  objects  are  G_STRING,  G_BUTTON,  and  G_TITLE.
   G_STRINGs  (in  addition  to being a bad pun) are for setting up static
   explanatory  text within dialogs.  The characters are always written in
   the "system font": full size, black, with no special effects.

      We have already discussed many of the uses of G_BUTTONs.  They add a
   border  around  the  text.   The  thickness  of  a G_BUTTON's border is
   determined by what flags are set for the object.  All buttons start out
   with  a  border thickness of one pixel.  One pixel is added if the EXIT
   attribute  is  set,  and  one more is added if the DEFAULT attribute is
   set.

      The  G_TITLE  type is a specially formatted text string used only in
   the  title  bar  of  menus.   This type is needed to make sure that the
   menus  redraw  correctly.   The Resource Construction Set automatically
   handles inserting G_TITLEs, so you will seldom use them directly.

      In  a resource, the OB_SPEC for all string objects is a long pointer
   to  a  null  terminated ASCII string.  The string data in the C file is
   shown  in  the  BYTE  array rs_strings.  Again you will notice that the
   OB_SPECs  in  the C file have been converted to indices into rs_string.
   To  find the string which matches the object, take the value of OB_SPEC
   and  count  down  that  many lines in rs_strings.  The next line is the
   correct string.

      The  formatted text object types are G_TEXT, G_BOXTEXT, G_FTEXT, and
   G_FBOXTEXT.   G_TEXTs  are  a  lot  like  strings,  except that you can
   specify  a color, different sizes, and a positioning rule for the text.
   Since  they  require more memory than G_STRINGs, G_TEXTs should be used
   sparingly  to  draw attention to important information within a dialog.
   G_TEXTs are also useful for automatic centering of dialog text which is
   changed  at  run-time.   I will describe this technique in detail later
   on.

      The  G_BOXTEXT type adds a solid background and border to the G_TEXT
   type.   These  objects are occasionally used in place of G_BUTTONs when
   their color will draw attention to an important object.

      The  G_FTEXT  object  is  an  editable  text field.  You are able to
   specify  a  constant  "template"  of characters, a validation field for
   those characters which are to be typed in, and an initial value for the
   input  characters.   You  may  also select color, size, and positioning
   rule for G_FTEXTs.  We'll discuss text editing at length below.

      The  G_FBOXTEXT object, as you might suspect, is the same as G_FTEXT
   with  the addition of background and border.  This type is seldom used:
   the  extra  appearance  details  distract attention from the text being
   edited.

      The  OB_SPEC for a formatted text object is a pointer to yet another
   type  of  structure:  a TEDINFO.  In the C file, you will find these in
   rs_tedinfo.   Take  the  OB_SPEC  value  from each text type object and
   count  down  that  many  entries  in  rs_tedinfo,  finding the matching
   TEDINFO  on the next line.  Each contains pointers to ASCII strings for
   the  template,  validation,  and  initialization.   You  can find these
   strings in rs_strings, just as above.

      There  are  also  fields  for  the  optional  background  and border
   details,  and  for the length of the template and text.  As we will see
   when  discussing  editing,  the  most  important TEDINFO fields are the
   TE_PTEXT  pointer  to  initialized  text  and the TE_TXTLEN field which
   gives its length.

      The G_IMAGE object type is the only one of its kind.  A G_IMAGE is a
   monochrome  bit image.  For examples, see the images within the various
   GEM alert boxes.  Note that monochrome does not necessarily mean black.
   The  image  may  be any color, but all parts of it are the SAME color.
   G_IMAGEs  are  used as visual cues in dialogs.  They are seldom used as
   selectable  items  because their entire rectangle is inverted when they
   are  clicked.  This effect is seldom visually pleasing, particularly if
   the image is colored.

      G_IMAGE  objects  have  an  OB_SPEC  which is a pointer to a further
   structure  type:  the  BITBLK.   By now, you should guess that you will
   find  it  in  the  C  file in the array rs_bitblk.  The BITBLK contains
   fields  describing  the  height  and  width of the image in pixels, its
   color,nd  it also contains a long pointer to the actual bits which make
   up  the  image.   In  the C file, the images are encoded as hexadecimal
   words and stored in arrays named IMAG0, IMAG1, and so on.

      The last type of object is the G_ICON.  Like the G_IMAGE, the G_ICON
   is a bit image, but it adds a mask array which selects what portions of
   the  image  will  be  drawn,  as  well as an explanatory text field.  A
   G_ICON  may  also  specify different colors for its "foreground" pixels
   (the  ones that are normally black), and its "background" pixels (which
   are normally white).

      The  pictures  which  you see in Desktop windows are G_ICONs, and so
   are the disks and trashcan on the desktop surface.  With the latter you
   will  notice  the effects of the mask.  The desktop shows through right
   up  to  the  edge  of  the  G_ICON,  and  only  the  icon itself (not a
   rectangle) is inverted when a disk is selected.

      The  OB_SPEC  of  an  icon  points  to  another  structure called an
   ICONBLK.   It  is  shown  in  the  C  file  as rs_iconblk.  The ICONBLK
   contains  long  pointers  to  its foreground bit array, to the mask bit
   array,  and  to  the ASCII string of explanatory text.  It also has the
   foreground  and  background  colors as well as the location of the text
   area  from  the upper left of the icon.  The most common use of G_ICONs
   and  ICONBLKs  is  not  in dialogs, instead they are used frequently in
   trees  which  are  built  at  run-time,  such as Desktop windows.  In a
   future  article,  we  will  return  to  a  discussion  of building such
   "on-the-fly" trees with G_ICONs.

      Now,  let's recap the hierarchy of resource structures:  The highest
   level structures are the resource header, and then the tree index.  The
   tree  index  points  to  the beginning of each object tree. The objects
   making  up  the  tree are of several types, and depending on that type,
   they  may contain pointers to ASCII strings, or to TEDINFO, ICONBLK, or
   BITBLK  structures.   TEDINFOs  contain  further  pointers  to strings;
   BITBLKs have pointers to bit images; and ICONBLKs have both.


    PUTTING IT TO WORK
    ------------------
      The  most  common  situations  requiring  you to understand resource
   structures  involve  the  use  of  text  and  editable  text objects in
   dialogs.  We'll look at two such techniques.

      Often  an  application  requires  two or more dialogs which are very
   similar  except  for one or two title lines.  In this circumstance, you
   can save a good deal of resource space by building only one dialog, and
   changing the title at run time.

      It  is  easy  to  go  wrong with this practice, however, because the
   obvious  tactic  of  using  a G_STRING and writing over its text at run
   time  can go wrong.  The first problem is that you must know in advance
   the  longest  title  to  be  used,  and put a string that long into the
   resource.   If  you don't you will damage other objects in the resource
   as  you  copy  in  characters.  The other problem is that a G_STRING is
   always drawn at the same place in a dialog.  If the length of the title
    changes  from  time  to  time,  the  dialog will have an unbalanced and
    sloppy appearance.

      A  better  way  to do this is to exploit the G_TEXT object type, and
   the  TEDINFO  structure.   The set_text() routine in the download shows
   how.   The parameters provided are the tree address, the object number,
   and  the  32-bit  address of the string to be substituted.  For this to
   work,  the object referenced should be defined as a G_TEXT type object.
   Additionally,  the  Centered text type should be chosen, and the object
   should  have been "stretched" so that it fills the dialog box from side
   to side.

      In  the code, the first action is to get the OB_SPEC from the object
   which  was  referenced.  Since we know that the object is a G_TEXT, the
   OB_SPEC  must  point to a TEDINFO.  We need to change two fields in the
   TEDINFO.   The TE_PTEXT field is the pointer to the actual string to be
   displayed;  we  replace  it  with  the  address  of our new string. The
   TE_TXTLEN  field  is  loaded  with  the new string's length.  Since the
   Centered attribute was specified for the object, changing the TE_TXTLEN
   will  cause  the string to be correctly positioned in the middle of the
   dialog!

      Editing  text  also requires working with the TEDINFO structure. One
   way  of  doing  this  is  shown in the download.  The object to be used
   (EDITOBJ)  is  assumed  to  be  a G_FTEXT or G_FBOXTEXT.  Since we will
   replace  the initialized text at run time, that field may be left empty
   when building the object in the RCS.

      The basic trick of this code is to point the TEDINFO's TE_PTEXT at a
   string  which is defined in your code's local stack.  The advantages of
   this  technique  are  that you save resource space, save static data by
   putting the string in reusable stack memory, and automatically create a
   scratch string which may be discarded if the dialog is cancelled.

      The text string shown is arbitrarily 41 characters long.  You should
   give  yours  a  length  equal  to  the number of blanks in the object's
   template  field  plus  one.   Note that the code is shown as a segment,
   rather  than  a  subroutine.   This is required because the text string
   must  be  allocated  within  the context of the dialog handling routine
   itself, rather than a routine which it calls!

      After  the  tree  address  is  found,  the code proceeds to find the
   TEDINFO  and  modify  its  TE_PTEXT  as  described above.  However, the
   length  which  is  inserted  into  TE_TXTLEN must be the maximum string
   length, including the null!

      The  final  line  of code inserts a null into the first character of
   the  uninitialized  string.   This  will produce an empty editing field
   when  the  dialog  is displayed.  If there is an existing value for the
   object,  you  should  instead use strcpy() to move it into text[]. Once
   the  dialog is complete, you should check its final status as described
   in  the last article.  If an "OK" button was clicked, you will then use
   strcpy() to move the value in text[] back to its static location.

      Although  I  prefer  this  method of handling editable text, another
   method  deserves  mention also.  This procedure allocates a full length
   text  string of blanks when creating the editable object in the RCS. At
   run-time,  the TE_PTEXT link is followed to find this string's location
   in  the  resource,  and  any pre-existing value is copied in. After the
   dialog  is  run,  the  resulting value is copied back out if the dialog
   completed successfully.

      Note  that  in  both editing techniques a copy of the current string
   value  is  kept  within  the  application's  data  area.  Threading the
   resource  whenever  you  need  to  check  a string's value is extremely
   wasteful.

      One  final  note  on  editable  text objects:  GEM's editor uses the
   commercial  at sign '@' as a "meta-character".  If it is the first byte
   of  the  initialized  text, then the field is displayed blank no matter
   what  follows.   This  can be useful, but is sometimes confusing when a
   user  in  all innocence enters an @ and has his text disappear the next
   time the dialog is drawn!


    LETTERS, WE GET LETTERS
    -----------------------
      The  Feedback  section  on  ANTIC ST ONLINE is now functional and is
   producing  a  gratifying  volume of response. A number of requests were
   made  for  topics such as ST hardware and ST BASIC which are beyond the
   intended  scope  of  this  column.  These have been referred to ANTIC's
   editorial staff for action.

      So  many good GEM questions were received that I will devote part of
   the  next  column to answering several of general interest.  Also, your
   requests  have resulted in scheduling future columns on VDI text output
   and  on  the  principles  (or  mythology)  of designing GEM application
   interfaces.  Finally,  a  tip  of  the  hat to the anonymous reader who
   suggested  including  the  actual  definitions of all macro symbols, so
   that  those  without  the  appropriate  H files can follow along.  As a
   result  of  this  suggestion,  the  definitions for this column and the
   previous  three  are  included  at  the  end  of  the download.  Future
   articles will continue this practice.


    STRAW POLL!
    -----------
      I'd  like  to  make  a  practice  of  using the Feedback to get your
   opinions  on  the  column's format.  As a first trial, I'd like to know
   your  feelings about my use of "portability macros" in the sample code.
   These macros, LLGET for example, are used for compatibility between 68K
   GEM systems like the ST, and Intel based systems like the IBM PC.  This
   may  be important to many developers.  On the other hand, omitting them
   results  in more natural looking C code.  For instance, in the download
   you  will  find  a second version of set_text() as described above, but
   without  the portability macros.  So, I would like to know if you think
   we  should  (A)  Keep  the macros - portability is important to serious
   developers,  (B)  Get rid of them - who cares about Intel chips anyway,
   or  (C)  Who cares?  I'll tally the votes in two weeks and announce the
   results here.


    STAY TUNED!
    -----------
      As  well  as  answers  to  feedback  questions, the next column will
   discuss  how  GEM  objects are linked to form trees, and how to use AES
   calls  and your own code to manipulate them for fun and profit.  In the
   following  installment,  we'll  look at the VDI raster operations (also
   known as "blit" functions).




>>>>>>>>>>>>>>>>>>>>>>>>> Sample C output file from RCS <<<<<<<<<<<<<<<<<<

                         /* (Comments added)     */
BYTE *rs_strings[] = {               /* ASCII data          */
"Title String",
"Exit",
"Centered Text",
"",
"",
"Tokyo",
"",
"Time: __:__:__",
"999999",
"",
"Time: __:__:__  ",
"999999",
"New York"};

WORD IMAG0[] = {                    /* Bitmap for G_IMAGE */
0x7FF, 0xFFFF, 0xFF80, 0xC00,
0x0, 0xC0, 0x183F, 0xF03F,
0xF060, 0x187F, 0xF860, 0x1860,
0x187F, 0xF860, 0x1860, 0x187F,
0xF860, 0x1860, 0x187F, 0xF860,
0x1860, 0x187F, 0xF860, 0x1860,
0x187F, 0xF860, 0x1860, 0x187F,
0xF860, 0x1860, 0x187F, 0xF860,
0x1860, 0x187F, 0xF860, 0x1860,
0x187F, 0xF860, 0x1860, 0x187F,
0xF860, 0x1860, 0x183F, 0xF03F,
0xF060, 0xC00, 0x0, 0xC0,
0x7FF, 0xFFFF, 0xFF80, 0x0,
0x0, 0x0, 0x3F30, 0xC787,
0x8FE0, 0xC39, 0xCCCC, 0xCC00,
0xC36, 0xCFCC, 0xF80, 0xC30,
0xCCCD, 0xCC00, 0x3F30, 0xCCC7,
0xCFE0, 0x0, 0x0, 0x0};

WORD IMAG1[] = {                    /* Mask for first icon */
0x0, 0x0, 0x0, 0x0,
0x7FFE, 0x0, 0x1F, 0xFFFF,
0xFC00, 0xFF, 0xFFFF, 0xFF00,
0x3FF, 0xFFFF, 0xFFC0, 0xFFF,
0xFFFF, 0xFFF0, 0x3FFF, 0xFFFF,
0xFFFC, 0x7FFF, 0xFFFF, 0xFFFE,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0x7FFF,
0xFFFF, 0xFFFE, 0x3FFF, 0xFFFF,
0xFFFC, 0xFFF, 0xFFFF, 0xFFF0,
0x3FF, 0xFFFF, 0xFFC0, 0xFF,
0xFFFF, 0xFF00, 0x1F, 0xFFFF,
0xF800, 0x0, 0x7FFE, 0x0};

WORD IMAG2[] = {                    /* Data for first icon */
0x0, 0x0, 0x0, 0x0,
0x3FFC, 0x0, 0xF, 0xC003,
0xF000, 0x78, 0x180, 0x1E00,
0x180, 0x180, 0x180, 0x603,
0x180, 0xC060, 0x1C00, 0x6,
0x38, 0x3000, 0x18C, 0xC,
0x60C0, 0x198, 0x306, 0x6000,
0x1B0, 0x6, 0x4000, 0x1E0,
0x2, 0xC000, 0x1C0, 0x3,
0xCFC0, 0x180, 0x3F3, 0xC000,
0x0, 0x3, 0x4000, 0x0,
0x2, 0x6000, 0x0, 0x6,
0x60C0, 0x0, 0x306, 0x3000,
0x0, 0xC, 0x1C00, 0x0,
0x38, 0x603, 0x180, 0xC060,
0x180, 0x180, 0x180, 0x78,
0x180, 0x1E00, 0xF, 0xC003,
0xF000, 0x0, 0x3FFC, 0x0};

WORD IMAG3[] = {               /* Mask for second icon */
0x0, 0x0, 0x0, 0x0,
0x7FFE, 0x0, 0x1F, 0xFFFF,
0xFC00, 0xFF, 0xFFFF, 0xFF00,
0x3FF, 0xFFFF, 0xFFC0, 0xFFF,
0xFFFF, 0xFFF0, 0x3FFF, 0xFFFF,
0xFFFC, 0x7FFF, 0xFFFF, 0xFFFE,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0x7FFF,
0xFFFF, 0xFFFE, 0x3FFF, 0xFFFF,
0xFFFC, 0xFFF, 0xFFFF, 0xFFF0,
0x3FF, 0xFFFF, 0xFFC0, 0xFF,
0xFFFF, 0xFF00, 0x1F, 0xFFFF,
0xF800, 0x0, 0x7FFE, 0x0};

WORD IMAG4[] = {               /* Data for second icon */
0x0, 0x0, 0x0, 0x0,
0x3FFC, 0x0, 0xF, 0xC003,
0xF000, 0x78, 0x180, 0x1E00,
0x180, 0x180, 0x180, 0x603,
0x180, 0xC060, 0x1C00, 0x6,
0x38, 0x3000, 0x18C, 0xC,
0x60C0, 0x198, 0x306, 0x6000,
0x1B0, 0x6, 0x4000, 0x1E0,
0x2, 0xC000, 0x1C0, 0x3,
0xCFC0, 0x180, 0x3F3, 0xC000,
0x0, 0x3, 0x4000, 0x0,
0x2, 0x6000, 0x0, 0x6,
0x60C0, 0x0, 0x306, 0x3000,
0x0, 0xC, 0x1C00, 0x0,
0x38, 0x603, 0x180, 0xC060,
0x180, 0x180, 0x180, 0x78,
0x180, 0x1E00, 0xF, 0xC003,
0xF000, 0x0, 0x3FFC, 0x0};

LONG rs_frstr[] = {               /* Free string index - unused */
0};

BITBLK rs_bitblk[] = {            /* First entry is index to image data */
0L, 6, 24, 0, 0, 0};

LONG rs_frimg[] = {               /* Free image index - unused */
0};

ICONBLK rs_iconblk[] = {
1L, 2L, 10L, 4096,0,0, 0,0,48,24, 9,24,30,8,   /* First pointer is mask */
3L, 4L, 17L, 4864,0,0, 0,0,48,24, 0,24,48,8};  /* Second is data, third */
                                               /* is to title string    */
TEDINFO rs_tedinfo[] = {
2L, 3L, 4L, 3, 6, 2, 0x1180, 0x0, -1, 14,1,    /* First pointer is text */
7L, 8L, 9L, 3, 6, 2, 0x2072, 0x0, -3, 11,1,    /* Second is template    */
11L, 12L, 13L, 3, 6, 0, 0x1180, 0x0, -1, 1,15, /* Third is validation   */
14L, 15L, 16L, 3, 6, 1, 0x1173, 0x0, 0, 1,17};

OBJECT rs_object[] = {
-1, 1, 3, G_BOX, O-LINED, 0x21100L, 0,0, 18,12,     /* Pointers are to: */
2, -1, -1, G_STRING, NONE, NORMAL, 0x0L, 3,1, 12,1, /* rs_strings       */
3, -1, -1, G_BUTTON, 0x7, NORMAL, 0x1L, 5,9, 8,1,   /* rs_strings       */
0, 4, 4, G_BOX, NONE, NORMAL, 0xFF1172L, 3,3, 12,5,
3, -1, -1, G_IMAGE, LASTOB, NORMAL, 0x0L, 3,1, 6,3, /* rs_bitblk        */
-1, 1, 6, G_BOX, NONE, O-LINED, 0x21100L, 0,0, 23,12,
2, -1, -1, G_TEXT, NONE, NORMAL, 0x0L, 0,1, 23,1,   /* rs_tedinfo       */
6, 3, 5, G_IBOX, NONE, NORMAL, 0x1100L, 6,3, 11,5,
4, -1, -1, G_BUTTON, 0x11, NORMAL, 0x5L, 0,0, 11,1, /* rs_strings       */
5, -1, -1, G_BUTTON, 0x11, NORMAL, 0x6L, 0,2, 11,1, /* rs_strings       */
2, -1, -1, G_BOXCHAR, 0x11, NORMAL, 0x43FF1400L, 0,4, 11,1,
0, -1, -1, G_BOXTEXT, 0x27, NORM, 0x1L, 5,9, 13,1,  /* rs_tedinfo       */
-1, 1, 3, G_BOX, NONE, OUTLINED, 0x21100L, 0,0, 32,11,
2, -1, -1, G_ICON, NONE, NORMAL, 0x0L, 4,1, 6,4,    /* rs_iconblk       */
3, -1, -1, G_FTEXT, EDIT, NORM, 0x2L, 12,2, 14,1,   /* rs_tedinfo       */
0, 4, 4, G_FBOXTEXT, 0xE, NORMAL, 0x3L, 3,5, 25,4,  /* rs_tedinfo       */
3, -1, -1, G_ICON, LASTOB, NORMAL, 0x1L, 1,0, 6,4}; /* rs_iconblk       */

LONG rs_trindex[] = {               /* Points to start of trees in */
0L,                                 /* rs_object                   */
5L,
12L};

struct foobar {                    /* Temporary structure used by    */
     WORD     dummy;               /* RSCREATE when setting up image */
     WORD     *image;              /* pointers.                      */
     } rs_imdope[] = {
0, &IMAG0[0],
0, &IMAG1[0],
0, &IMAG2[0],
0, &IMAG3[0],
0, &IMAG4[0]};

                         /* Counts of structures defined */
#define NUM_STRINGS 18
#define NUM_FRSTR 0
#define NUM_IMAGES 5
#define NUM_BB 1
#define NUM_FRIMG 0
#define NUM_IB 2
#define NUM_TI 4
#define NUM_OBS 17
#define NUM_TREE 3

BYTE pname[] = "DEMO.RSC";


>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Title change utility <<<<<<<<<<<<<<<<<<<<<

     VOID
set_text(tree, obj, str)
     LONG     tree, str;
     WORD     obj;
     {
     LONG     obspec;

     obspec = LLGET(OB_SPEC(obj));           /* Get TEDINFO address  */
     LLSET(TE_PTEXT(obspec), str);           /* Set new text pointer */
     LWSET(TE_TXTLEN(obspec), LSTRLEN(str)); /* Set new length       */
     }


>>>>>>>>>>>>>>>>>>>>>> Text edit code segment <<<<<<<<<<<<<<<<<<<<<<<<<<

     LONG     tree, obspec;
     BYTE     text[41];

     rsrc_gaddr(R_TREE, DIALOG, &tree);      /* Get tree address     */
     obspec = LLGET(OB_SPEC(EDITOBJ));       /* Get TEDINFO address  */
     LLSET(TE_PTEXT(obspec), ADDR(str));     /* Set new text pointer */
     LWSET(TE_TXTLEN(obspec), 41);           /* Set max length       */
     text[0] = '\0';                         /* Make empty string    */


>>>>>>>>>>>>>>>>>>>> Sample 68K only source code <<<<<<<<<<<<<<<<<<<<<<

     VOID
set_text(tree, obj, str)
     OBJECT     *tree;
     WORD     obj;
     BYTE     *str;
     {
     TEDINFO     *obspec;

     obspec = (TEDINFO *) (tree + obj)->ob_spec;
                                           /* Get TEDINFO address  */
     obspec->te_ptext = str;               /* Set new text pointer */
     obspec->te_txtlen = strlen(str);      /* Set new length       */
     }


>>>>>>>>>>>>>>>>>>>>>>>>>>>> Symbol definitions <<<<<<<<<<<<<<<<<<<<<<<<<

                              /* Window parts */
#define NAME 0x0001
#define CLOSER 0x0002
#define FULLER 0x0004
#define MOVER 0x0008
#define INFO 0x0010
#define SIZER 0x0020
#define UPARROW 0x0040
#define DNARROW 0x0080
#define VSLIDE 0x0100
#define LFARROW 0x0200
#define RTARROW 0x0400
#define HSLIDE 0x0800

#define WF_KIND 1                    /* wind_get/set parameters */
#define WF_NAME 2
#define WF_INFO 3
#define WF_WXYWH 4
#define WF_CXYWH 5
#define WF_PXYWH 6
#define WF_FXYWH 7
#define WF_HSLIDE 8
#define WF_VSLIDE 9
#define WF_TOP 10
#define WF_FIRSTXYWH 11
#define WF_NEXTXYWH 12
#define WF_NEWDESK 14
#define WF_HSLSIZ 15
#define WF_VSLSIZ 16
                              /* window messages     */
#define WM_REDRAW 20
#define WM_TOPPED 21
#define WM_CLOSED 22
#define WM_FULLED 23
#define WM_ARROWED 24
#define WM_HSLID 25
#define WM_VSLID 26
#define WM_SIZED 27
#define WM_MOVED 28
#define WM_NEWTOP 29
                              /* arrow messages     */
#define WA_UPPAGE 0
#define WA_DNPAGE 1
#define WA_UPLINE 2
#define WA_DNLINE 3
#define WA_LFPAGE 4
#define WA_RTPAGE 5
#define WA_LFLINE 6
#define WA_RTLINE 7

#define R_TREE 0                    /* Redraw definitions      */
#define ROOT 0
#define MAX_DEPTH 8

                              /* update flags           */
#define     END_UPDATE 0
#define     BEG_UPDATE 1
#define     END_MCTRL  2
#define     BEG_MCTRL  3
                              /* Mouse state changes    */
#define M_OFF 256
#define M_ON 257
                              /* Object flags           */
#define NONE       0x0
#define SELECTABLE 0x1
#define DEFAULT    0x2
#define EXIT       0x4
#define EDITABLE   0x8
#define RBUTTON   0x10
                              /* Object states     */
#define SELECTED  0x1
#define CROSSED   0x2
#define CHECKED   0x4
#define DISABLED  0x8
#define OUTLINED 0x10
#define SHADOWED 0x20

#define G_BOX     20
#define G_TEXT    21
#define G_BOXTEXT 22
#define G_IMAGE   23
#define G_IBOX    25
#define G_BUTTON  26
#define G_BOXCHAR 27
#define G_STRING  28
#define G_FTEXT   29
#define G_FBOXTEXT 30
#define G_ICON    31
#define G_TITLE   32
                              /* Data structures     */
typedef struct grect
     {
     int     g_x;
     int     g_y;
     int     g_w;
     int     g_h;
     } GRECT;

typedef struct object
     {
     int           ob_next;       /* -> object's next sibling      */
     int           ob_head;       /* -> head of object's children  */
     int           ob_tail;       /* -> tail of object's children  */
     unsigned int  ob_type;       /* type of object- BOX, CHAR,... */
     unsigned int  ob_flags;      /* flags                         */
     unsigned int  ob_state;      /* state- SELECTED, OPEN, ...    */
     long          ob_spec;       /* "out"- -> anything else       */
     int           ob_x;          /* upper left corner of object   */
     int           ob_y;          /* upper left corner of object   */
     int           ob_width;      /* width of obj                  */
     int           ob_height;     /* height of obj                 */
     } OBJECT;

typedef struct text_edinfo
     {
     long          te_ptext;      /* ptr to text (must be 1st)     */
     long          te_ptmplt;     /* ptr to template               */
     long          te_pvalid;     /* ptr to validation chrs.       */
     int          te_font;        /* font                          */
     int          te_junk1;       /* junk word                     */
     int          te_just;        /* justification- left, right... */
     int          te_color;       /* color information word        */
     int          te_junk2;       /* junk word                     */
     int          te_thickness;   /* border thickness              */
     int          te_txtlen;      /* length of text string         */
     int          te_tmplen;      /* length of template string     */
     } TEDINFO;

                         /* "Portable" data definitions */
#define OB_NEXT(x)   (tree + (x) * sizeof(OBJECT) + 0)
#define OB_HEAD(x)   (tree + (x) * sizeof(OBJECT) + 2)
#define OB_TAIL(x)   (tree + (x) * sizeof(OBJECT) + 4)
#define OB_TYPE(x)   (tree + (x) * sizeof(OBJECT) + 6)
#define OB_FLAGS(x)  (tree + (x) * sizeof(OBJECT) + 8)
#define OB_STATE(x)  (tree + (x) * sizeof(OBJECT) + 10)
#define OB_SPEC(x)   (tree + (x) * sizeof(OBJECT) + 12)
#define OB_X(x)      (tree + (x) * sizeof(OBJECT) + 16)
#define OB_Y(x)      (tree + (x) * sizeof(OBJECT) + 18)
#define OB_WIDTH(x)  (tree + (x) * sizeof(OBJECT) + 20)
#define OB_HEIGHT(x) (tree + (x) * sizeof(OBJECT) + 22)

#define TE_PTEXT(x)  (x)
#define TE_TXTLEN(x) (x + 24)




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




                             SHAKESPEARE and FUJI
                             ====================

by Rex Reade

"All the world is a stage ........"Shakespeare was perhaps more a prophet
than we would like to admit or is it that human behavior hasn't really 
changed all that much from his era to ours?  These are heavy points to 
ponder.  Seemingly, the ideals of that era and the upcoming events in the
Atari community are indeed similar....

Will Atari, when they go 

                   "CENTER STAGE" on Sept 26, 1988 ~ CIS 9pm EST
                    --------------------------------------------

and before the whole world, act like the  "Wizard of Oz"!  All noise and 
self righteous justification.  

Or, 

Will they follow the simple and uninvolved method of telling the truth
without all the corporate fluff and fodder.  How refreshing that would be
after the "announcements and statements" of the last few weeks.  Hopefully
they will take the latter course.

We realize that the leadership of Atari is only human ...DO THEY?

Atari will have the "Golden Opportunity" to practically right all the
wrongs and reinstill the enthusiastic support of it's userbase.  Of
course, it is up to them and them alone.  As far as we are concerned, what
Atari does with this upcoming conference (Sept.26 - CIS) will tell the
whole world what they think of the US Userbase and it's future.

One thing is certain, Atari can make the conference a marvelous event that
will have considerable bearing on the future of the Atari in the United
States Marketplace.  

Folks, consider these questions..Feel free to use them in the conference

       1 - Why Europe first, when you got your start here in the USA???

       2 - We in the USA have more bux to spend why do you ship to Europe?

       3 - Is the pursuit of profits so strong as to require the
           administration of a "death blow" to the US Market?

       4 - What are the real plans for the US market, if any and do you
           plan to use a different name on the new line of computers?

       5 - If the STGS is a reality, will you ensure the "protection" of
           the integrity of the ST line by a name change etc..?

We cannot under any circumstances provide all the questions nor would we
even try.  We have included some samples that will make 'em think before
they leap <grin> ....Do not forget to ask about FEDERATED and the deal
there for the users and the INDEPENDANT DEALERS.

Above all else, please refrain from the hysterical "hero worship" we have
seen in the past...ask sensible questions, avoid personal attacks..(this
means against Atari and it's people) they ARE Atari ......let all the
issues concerning Atari and creating unrest in your area be brought
forward. 

        REMEMBER, ATARI USERS....

                              THIS IS YOUR GOLDEN OPPORTUNITY TOO!


                                            Rex...........



                         The Presidential Conference

                    September 26, 1988   --  9 P.M.  EST

                                COMP-U-SERVE


ps: If you are not a user of CIS, NOW is the time to take advantage of the
special offer and join CIS.  (the information is in this issue)



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



Garbage-On-The-Line
-------------------


                        The Prince of Darkness Comes Forward
                        ====================================


by Linda Woodworth


"Yo, CJ, it's me..... Satan!  You Summonded?"

A little over a month ago, the FoReM F Netting BBSs started "getting hit"
by a mysterious phantom Mailer.  HellFire BBS Node 666.  This is easy 
enough to do, and when talk began in the SysOp Bases, I became intrigued.
..................... Who was this Satan of Node 666 ??

THEN, an FNetted/FMail file came thru the Net to all SysOps.  SEREG.ARC. 
Satan had cracked the protection scheme on Jon Radoff's on line game, 
Space Empire.  It gave the ability to run Space Empire to it's full 
abilities.  Many SysOp's were upset... some were amused, all types of
comments were to be heard.  I became even more fascinated.

Did Satan actually run a Board, was he "one of us", many questions and 
why's began running around.  What were his reasons for hitting bords 
randomly in the night.  Time was running out... the New Mailer was going 
into effect, and unless he was a registered SysOp with Dave Chiquelin, 
<the Mailer author> we would lose our communication link.  A message came
through saying Satan was "going after the New Mailer next".  I sent out a
message to all nodes, asking him to log on my board so we could talk.  A 
few thought I was nuts, and was making a pact with the devil.  Is this 
why I had a monitor die ??

About two days after the message went out, Satan logged on.  In fact, I 
had a couple Satan's.  But I had the one I wanted...  I asked his 
permission to do this interview, and we began a fasinating dialog.  I also
called the number he left upon logon.  1-800-HELFIRE.  No connection.

The first set of questions I asked Satan, was if he ran a board, and if 
the Space Empire cracker had a trojan in it <like some had said>.  NO to 
both.  Satan set up HellFire as a "mock" BBS, implemented the Mailer to 
call the boards.  The first thing Satan said to me was this...

"HellFire BBS is as real as a 3 dollar bill, the 666 is just something I 
came up with to fit in with the SATAN bit.  I don't really worship the 
devil or anything.  It's just somethin' controversial and gets people all
"fired up".  I didn't have any real purpose behind the SE ripoff program 
other than to prove it could be done.  As for the long sex file, that 
wasn't all mine.  A few friends helped to 'come' up with some ideas for
it."

A little devilish humor ??  They had some good ideas too..... <grin>

There was NO Trojan in the SEREG, as I had that checked out...

Satan's had his ST for apx. 10 months, and he told me he "liked freaking 
people out and trying to cause things such as the FNet to deviate from the
normal -- the NEW Mailer provides a new challenge for me..."  

      <the new Mailer provides a challenge for all SysOps too - grin>

I felt like I was straddling the fence.  Talking with Satan on one hand, 
and Dave Chiquelin, on the other.  I really was selling my soul... but to
who ??  <grin>  Hi Boris !!  Thanks for trusting me with the background 
information on the protection for the New Mailer.

Satan continued to log on for the next two weeks.  I didn't get to find 
out all the information I wanted... but life isn't over, yet.  Perhaps I 
will do a follow up sometime.  I hope he got some satisfaction out of the
deviation from the norm, and puts his twenty years and obvious talent to 
use to help us all. 

Satan had his turn at the limelight, and yes, I am giving him more... but
I've talked enough with him to know he isn't after doing trojan's or 
considerable continued mayhem.  I must give the devil his due, as I had a
problem on The Chip, and he took the time to let me know.  <Thank You>  
I have the feeling he is a person doing some experimenting with life. His
messages were to the point, consistant, and full of humor.

Jon Radoff is upset however.  But, then we could get into the "cast the 
first stone" type of thing.  Right now, I'm not going to touch that one 
with a ten foot pole.  It COULD raise the devil!

I did find out Satan had no pact on my soul, as he has enough souls to 
last a few centuries.  Seems like there were a lot of souls for sale a 
few years ago.  Hmmm... I had yet another monitor go out just last night!!

The last time I heard from Satan was on Sept 6, 1988 at 9:08 PM <MDT>

"Well, my days at mayhem are over.  No more FNetting from the mysterious
HellFire BBS, no more cracking.  I have accomplished what I wanted, to 
make waves.  Some major tidal waves.  Now that that's done, I don't need 
mysterious fnet mail or code breaking programs."

The Satanic Force was exciting and I thank all SysOp's who allowed my 
messages to remain on their boards.




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



OF SPECIAL NOTE:
===============


>From:(David Small)
Subject: New Data Pacific Newsletter
Keywords: magic sac, dp, translator
Date: 26 Aug 88 


Data Pacific has released a new newsletter in the last few days that
deserves a warning. It's full of distortions, half-truths, is misleading,
and contains some flat false information. It's going to confuse a lot
of people, so I'm trying to spread the word.

   For instance, the newsletter contains columns from people who no
longer work at dP (most of dP's staff quit in March-April, including me).
It talks of a new tech person, "Mike", who does not exist and who always
has been a pseduonym for Joel when taking tech calls.

  More subtly, the newsletter implies that dP is having me look into
a 128K ROM version of the Magic Sac. This is false; I have nothing to do
with Data Pacific(except for one contract job -- version 6.1 of Magic Sac,
in exchange for a LaserWriter). dP (Joel) agreed long ago to stop using
my name to try to sell their products; they've broken their promise.

   The newsletter says Dan Moore (dlm@druhi here) "worked overtime"
to produce Mover 1.7. The truth is, Dan did Mover 1.7 for a flat $150 fee
in July. He was paid by check after dropping off the disk; his bank later
told him that Joel *had stopped the check*. In short, dP is selling a
version of Mover 1.7 that they flat stole from Dan.

  If you appreciate any of the contributions Dan has made to the ST world,
such as the Twister disk format, Meg-a-minute backup, Protect accessory,
and others, you could return him the favor by refusing to buy dP's disk
until they remove Mover 1.7 from it, and letting them know why. Dan's had
a rough month; he broke his hand recently, and is in a cast to his elbow
(any get well cards sent via email would be greatly appreciated),
by the way.


   In my opinion, DP is attempting to present an image that things
are as they were during the good days, while selling off as much stock as
possible, with this newsletter -- then they're getting out. How else to
explain them putting Apple's own Switcher and FONT/DA Mover on their
"public domain" disk -- other than dP isn't planning on being around long
enough for Apple to catch them (and rightfully so; Hertzfeld worked hard
on Switcher).

I'd like it made clear I have nothing to do with Data Pacific anymore; I
answer dP related questions out of courtesy to my old customers, and
nothing more. The same is true for Dan Moore. The tactics Data Pacific is
stooping to, in my opinion, to milk a little more money from the Magic Sac
before folding up are shoddy in the extreme, and I think it's a shame my
name is still associated with this company. Hence, this note.

As for me, I have a new company, Gadgets By Small, Inc, and we're planning
on releasing our first product (the Spectre 128) on Sept. 16, at the Atari
Glendale Atarifest show. Since dP has broken it's word (again) to give me
access to their customer mailing list, which I built, I can't put out the
word about the Spectre 128 upgrade to the Magic Sac except by the
networks.

   For the record, and to answer a previous questions, I left Data Pacific
in March of this year, when it became clear that (a) Joel was not going
to honor our agreements, and (b) when I found out the FCC number being
put on the Translator units had been forged, and Joel had no plans to ever
[having the] FCC certify the unit. Believe me, I want no part of trying to
slip one past the FCC.(Every Translator unit shipped bears this same false
number.)
I wouldn't be party to this; neither would Dan, when he heard. (Thanks
to our friends from Supra for checking the number at the FCC BBS and
telling us what had happened!)

   I plan to carry on support of dP buyers with my new company, here and
on other networks, as a courtesy to the people who shelled out money for
the Magic Sac, but via a new company (Gadgets), as well as "push the
envelope" further on Mac emulation with the Spectre 128 product. I don't
want to advertise here on the net publicly; please drop me email privately
if you're interested (hplabs!well!dsmall or dsmall@well); I don't think
the local community would appreciate a few hundred "Yes, please send me
info" notes here in comp.sys.atari.st.

  Thanks for reading a rather long note; I plead that I'm used to getting
paid by wordcount <grin>.

 -- Thanks, Dave Small
    Gadgets by Small, Inc.
     


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



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

Sunnyvale CA.  Seems Atari wants ALL the usergroups to re-register, it is
------------   a good idea, if you need the forms, call Cindy at Atari. 
               Sig Hartmann has the right idea, "Let's be straight forward
               and only human with the users". Great Idea!

Sunnyvale CA.  Sam Tramiel, President of Atari along with Sig Hartmann
------------   Vice President of Atari will hold a formal conference on
               Compuserve in the Convention Center Sept. 26 9pm EST all
               interested parties are invited to attend.

Houston TX.    Still NO AGREEMENT on the site for the new Atari Factory...
----------

Glendale CA.   Data-Pacific, obvious by their absence, is history,
-----------    according to an informal survey conducted among spectators
               at the show.  Spectre 128 was a SMASH HIT at it's
               introduction and GBS had a sell-out show!  Codehead
               Software was another major attraction showing G+PLUS and
               MASTERDESK along with Charles and John.  Reportedly they 
               had nothing left to sell either.  Great news guys!

Reading PA.    According to a prominent mail order house Soft Logic is
----------     shooting for an end of the month release of the
               "Professional" version of it's DTP package.  Hope so, cause
               this mail order house sez if not, they DROP the whole line!

Ontario CAN.   Seems there is a Demo of "Calamus" making the rounds, only
-----------    problem is ...it's in GERMAN!!




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



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

There is always an easy answer to every human problem.....

                                NEAT, PLAUSIBLE and WRONG!



--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
T.RTitleUserPersonal
Name
DateLines
250.1PNO::SANDERSBa belaganaThu Oct 06 1988 11:391804
Newsgroups: comp.sys.atari.st
Path: decwrl!labrea!rutgers!mailrus!nrl-cmf!ukma!gatech!udel!udccvax1!gdtltr
Subject: ST Report Volume II No. 55 (part 1/2)
Posted: 4 Oct 88 19:14:41 GMT
Organization: University of Delaware
 
 
 
                      ST REPORT WEEKLY ONLINE MAGAZINE
                            Monday, OCT. 03, 1988
                               Vol II  No. 55
                                ===========
 
            APEInc., P.O.  BOX 74,  Middlesex, N.J.  08846-0074
 
  PUBLISHER                                              GENERAL MANAGER
  Ron Kovacs                                               R.F.Mariano
 
          =======================================================
 
                     ST REPORT EDITOR: Thomas Rex Reade
 
                PO Box 6672 Jacksonville, Florida. 32236-6672
 
                        Headquarters Bulletin Boards
 
 ST Report North                                         ST Report South
  201-343-1426                                             904-786-4176
 
                   ------------------------------------
 ST Report Central                                       ST Report West
  216-784-0574                                             916-962-2566
                                 CONTENTS
                                 ========
> From the Editor's Desk..............> The SKY is FALLING!...............
> THE BEAT GOES ON....................> HARD DISK FACTS ..................
> TANGERINE DREAM.....................> PRO GEM WINDOWS #6................
> INSIGHT part III................... > ST REPORT CONFIDENTIAL............
> GEM Multi-Tasking...................> WORD PERFECT & ATARI..............
 
=========================================================================
       COMP-U-SERVE    ~    GENIE    ~    DELPHI     ~    THE SOURCE
=========================================================================
 
 
From the Editor's Desk,
 
      Having had the time to ponder the course of current events I find 
many reasons to rejoice in the changes coming about in the Atari Corp. 
and it's methods of dealing with the US Userbase.....In fact, I HOPE that
they will soon have the Federated, or whatever name they care to use, 
stores all over the country and eliminate the goniffs they have now for 
dealers. 
 
      Granted, not all the dealers are bad guys but, at this point in time
with all the doomsayers in full bloom the average "I got my life savings 
tied up here" dealers are going to react unfavorably and thus "score" for
every buck they can.  This type of situation warrants Atari to get the 
national chain into full swing ASAP.  To the doomsayers I say...you folks
are pure bad news unto yourselves and are doing more harm to the Atari 
Userbase than any good you can possibly imagine.  The time is at hand to
stand by the machine and company we have embraced, changes are being made.
 
      We were extremely vocal in gaining the attention of Atari and we
did so.  Now, with Atari being responsive to our input, we stand ready to
accept the changes we have clamored for.  We dont expect total alignment 
with the userbase suggestions.  We do however, expect some similarities. 
After all, we ARE the ones paying the bills (collectively) and should be 
heard and responded to..and we have been.  Atari is on a course of 
corrective measures that can only lead to true and lasting success.
 
      Having heard that certain members of the Harris types of online folks
from Atari had a "mini" conference a day or so ago with one of the
doomsayers amazed me.  It would seem rather foolish to add fuel to the
fires of those that say, "THE ST IS DEAD" !  To insinuate that Atari will
have little or NOTHING to show at Comdex is truly a hypocrisy of the word
loyalty to one's employer!  In addition, it is just plain vile to
perpetrate such acts while ONLINE representing ATARI!!  That particular
department needs further adjustments.
 
                                    Long Live Atari,  
 
                                          Rex.....
 
 
 
 
**************************************************************************
  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 10-30-88
 
  NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
**************************************************************************
 
 
 
                        SPECIAL SUPRA MODEM OFFER!!!
                        ============================
 
 
CompuServe's Atari Forums have made very special arrangements with 
Paramount Products Inc. to offer the members of our forums the chance to 
upgrade your system to 2400 baud service at a very special price.  
 
For a limited time, CompuServe subscribers may purchase the 
 
             SUPRA CORP. 2400 baud Hayes-compatible modem 
           for the very **LOW** price of just $139.95 !!!!! 
 
These are brand new, not reconditioned units, with the full SUPRA CORP. 
warranty.  The SUPRA MODEM uses the Hayes Smartmodem 'AT' command set and
operates at 300-1200-2400 baud.  It's an outboard unit (not an internal 
plug-in card) allowing ease of transfer to other computers.  
Connection is thru the standard RS-232 interface. (Just plug it into the 
back of your ATARI ST).
 
       To take advantage of this special offer, Phone the 800 number 
       listed below or write to:
 
                        Paramount Products Inc.
                        1405 S.E. Pacific Blvd.
                        Albany, Oregon   97321
 
         *****          Phone orders: (800)444-4061        *****
 
     Price:    $139.95 + shipping
     UPS ground:     add $4.00
     UPS Blue label: add $8.00
     C.O.D.:         add $2.25
 
  MasterCard or VISA accepted Orders will be shipped the next business day
 
   If you've been accessing CompuServe at 1200 baud, this is a  great way
to lower your total online bill since CIS does *NOT*  charge a premium for
2400 baud access.  (You can get the same amount of information or download
the same amount of programs in approximately 1/2 the time as 1200 baud 
users!) This modem will PAY FOR ITSELF in just a few sessions.
 
 
 
--------------------------------------------------------------------------
 
 
 
 
                            THE SKY IS FALLING!
                            ===================
 
 
 
                                   *******
 
NOTE:
-----
      This is Dave Small's response to the announcement by Neil Harris
that he has resigned from Atari.  For those who don't know Dave he is the
developer of the Magic Sac and Spectre 128: devices that emulate the
Macintosh computer on the Atari ST.
 
                                   *******
 
 
This is really stunning.
 
 If you think this is just another "Atari employee splits" note, consider:
 
1) Neil was the spearhead of Atari online. Here, Genie, Usenet, Delphi,
you would find Neil. The support other than Neil has been fragmented to be
charitable. (Due credit goes to Julius, though). Given the power of the
online networks for marketing, and Atari's upper management completely
missing that, this is big trouble.
 
2) Unless I am much mistaken, I'll guess Neil had Atari stock options.
What does it tell you that he's leaving? I don't know how Atari stock 
could drop more (it's down to 6), but there's always a way. Maybe they can
"unsplit" stock to get it back to 12, *grin*. This means Atari is in big
trouble.
 
3) Neil is the *only* effective public speaker Atari had. Atari did
manage to waste much of it by forcing him to go say things that weren't 
so, or were only a little bit true. Neil gave innumerable talks and
presentations to user groups at shows across the country. Just who is 
going to replace him? You don't find people like that easily, or 
sometimes, at all -- look at the number of corporations who have *no one*
like that. This means Atari is in big trouble.
 
4) This happened right before the "big" CO here online with Sam. Big
trouble.
 
5) This happened right before Comdex. Big, big, big trouble. Neil was one
of the few people in an autocratic, 1950's-style management office that 
had any feel at all for reality. Now, what are we going to get? A 
repackaged ST game machine with a laser tag pistol? A VCS / ST? You can 
bet that when it appears (if) at Comdex, there will be ghostly vapor 
surrounding it, the signal of a product not to appear for another year. 
Big, big trouble.
 
6) Atari has no grasp of the current US marketing situation; you can't
stop support the instant the customer walks out the door with their ST and
you cash their check. Atari tries to do that, of course. I remember well
Alex Leavens getting canned for daring to support people who hadn't bought
the developer's kit (among other peccadillios). "Business is war", when 
the people you are warring on are your *customers*, is dumb. We are in a
service economy now; people expect *service*.
 
  No? Atari top management held up release of the auto hard disk booter
for a LONG time, claiming it would "cause a lot of tech support calls". 
The author, one Landon Dyer, is now at Apple, disgusted with Atari. He 
*wrote* most of the ST's BIOS; losing a lore-master like that is always 
very painful for a company.
 
7) Neil Harris has been with Jack T. a *long* time. What does it tell you
that he's bailing out now? Do you think he would if he saw any hope of
things changing? Do you think he'd go through the shock of job loss,
moving, new company, etc, if he saw any chance at all? *Neil is not
stupid*. Atari made him say stupid things, and folks like ST-Report
interpret that to mean Neil is stupid. Wrongo.
 
8) John Skruch -- whose word I trusted, a rarity at Atari -- is gone.
Sandi Austin, who did those user group shows (remember?) is gone. Richard
Frick, who was *instrumental* in getting the Magic Sac going, only to 
watch Atari's top management cold-shoulder it (Quote: "Why would anyone 
want to run Mac software when they have TOS?"), is gone. They've all left
Atari recently.
 
9) Just who is going to get Atari publicity from folks like Jerry
Pournelle anymore? Neil sold a lot of Ataris that way, and made the 
Tramiel people a lot of money.
 
10) Is it possible that Neil feels he's getting out before his reputation
is ruined by an Atari crash? Already it's been damaged by things he had to
say (Atari corporate policy).
 
11) The Comdex timing is especially significant. If Neil saw a future at
Atari, it would be new products announced at Comdex. I have heard from
other sources that Atari's top level management is now backing off from
introducing ANYTHING new or interesting at Comdex -- wouldn't want to
distract people from the ST, folks. Quote: "Atari's domestic market is
Europe. The US is Atari's international market". Unquote. This makes 
Comdex look like a splash to me -- much like the May one, in the 
Abandoned Booth.
 
12) It says a LOT to me about working conditions at Atari that even
Neil,
 who is pretty tough and good at political infighting, is leaving. If
you've never seen a 1950's style autocracy, well, check it out. It is hard
to stand (look at the number of people Atari has gone through at top
management), clearly. Other companies don't tax their personnel like this;
they realize that this is not the 1950's anymore, people are scarce and
hard to find, and need to be *part of the company*, not just some
slave-employee. Many other reports of working conditions at Atari make it
sound like hell to work at.
 
13) If Neil doesn't think there's going to be profit in his stock
options, you ought to be thinking about it too. (Again, this is a guess).
It is possible that Atari is folding up; the collapse will just take 
awhile to reach the public.
 
14) Most ST developers are seriously considering jumping ship; a lot
already have. Even Tom Hudson, arguably the best, is gone. Given how 
little Atari supports its developers (something Neil fought for) and 
gives online support (ditto), and that it could care less about selling 
into the US, it seems a waste of time to develop for the ST for the US 
market, when there's markets like Amiga, IBM, and Mac to develop for -- 
who have good documentation, people who aren't propeller-hat-heads
online, and so on.
 
15) I think this marks the end of Atari US. The Spectre 128 is almost
certainly my last ST product.
 
 
   Dave Small
   Gadgets by Small, Inc.
 
 
 
 
--------------------------------------------------------------------------
 
 
 
 
 
Fm: Neil 70007,1135 
To: David and Sandy Small 76606,666 (X)
 
 I refuse to allow my departure to be used as evidence for such a gloomy
scenario for Atari, even by someone I like as much as you, Dave.
 
 Yes, I passed on some stock.  But not nearly enough to qualify me for 
the "golden handcuffs" club that binds some of the vp level and above.
 
 To address a couple of minor points, John Skruch is most certainly not 
gone.  He seems to be doing very well -- with the success of Atari video
games, members of that division are being treated decently.
 
 And as for Alex Leavens -- it was *my* call, period.  He spent a fair 
amount of time online, which was good.  But he did not spend enough time
on the rest of his job with the tech support group,  and that was why I 
brought him in.  It was painful to have to let him go, but that's the 
price you pay when you're in management.
 
 Yes, I share some of the concerns you expressed.  Mainly I am concerned
for my coworkers at Atari who are underappreciated and underutilized.
 
 There is also some concern over product directions, but it ain't over
until it's over, and that isn't quite yet.
 
Finally, for the record, I take with me a fair amount of Atari stock, 
which I have no immediate plans to sell.
 
                                        --->Neil
 
 
 
 
--------------------------------------------------------------------------
 
 
 
 
                              THE BEAT GOES ON
                              ================
 
by T."Rex" Reade
 
 
AN APOLOGY FROM REX!
 
      Having been given a line of seemingly credible information from a 
very credible source within Atari, I now apologize to all concerned for
the information contained in the ST Report 54 article "The Beat Goes On".
There absolutely WILL be multi-tasking in the 68030 series of ST machines.
I doubt I will receive any further erroneous info from this person as they
are no longer with Atari.
 
      It is very difficult to disagree with a people you know and respect,
but..
 
      To credit ST Report with having caused the demise of certain Atari
employees is wild.  Actually, to those who would say these things, we say
thanks ....but NO THANKS for such flattery.
 
      We are flattered to see that one of the so-called leaders of the 
Atari community feels we wield such power.  I find it equally amazing to 
see this particular item attempt to portray the idea that it is composed
of FACTS... it is NOT!...frankly speaking, this item by Dave Small is ... 
 
                   HIS OPINION and HIS OPINION ONLY!  
 
We all know the joke about opinions.....right? , <<<Big Grin>>>
 
      All the crepe hanging going on is about to turn my stomach!  Atari
is NOT going anywhere but on the sales and service improvement path.  To
pointedly say, (as if armed with facts and figures), that the days of
Atari are "numbered" is a slanderous misrepresentation.  A "better" way of
expressing this is..the days are "numbered" for certain detrimental
individuals in Atari's Employ.
 
      To the respected members of the Atari Community I plead with you..
"TAKE DOWN THE PURPLE AND BLACK FLAGS there is no death of anything that 
we must take notice of.  Besides, there really are those of us who wish to
continue to support Atari and it's future.  We may be critical towards
Atari at times but let me tell you this; We will support Atari until such
time that either they or us are no longer a viable enterprise.
 
      Speaking of Atari needing to get the rest of it's "outspoken"
employees in line.....how about Mike Dendo, the new Vice President in
charge of Computer Sales, going to Michigan, telling the good folks there
that Atari had three soft quarters this year and that they needed the 
fourth to be a huge success to "bail out"!!???   What is this guy?  He 
certainly is NOT an accomplished salesman let alone a VICE PRESIDENT!  
Maybe he works for the other competition!  This bird needs to hit the 
revolving door!  Also, the online folks need to concern themselves ONLY 
with what they are there for, (representing Atari) stay out of politics, 
personalities and endorsements of "other" related products for the ST 
that are not manufactured by Atari.  There is NO need to resurrect certain
practices Neil took with him.
 
In addition;
 
      ALEX LEAVENS...was encouraged to leave because of his spending too
      much time "online" and not enough time at his assigned duties.
 
      John Skrutch has NEVER left Atari, in fact, his division is having a
      very good year.......
      Furthermore, anyone who attended the SPRING COMDEX will recall the
fact that Neil Harris, *** ex-ATARI SPOKESMAN ***  spent the best part of
the time there online playing Games!!!!  AND....when he was away from the
cpu, he left FLASH booted and the system online (he has a system wide free
flag) so no other person would attempt to use the computer.  I saw this as
did a host of others.  In my humble opinion, the handwriting was already 
on the wall.....Neil didn't really care anymore at that time and his 
departure from Atari would soon be forthcoming.  I am NOT putting Neil
down, I AM saying he did the right thing in making a career change before
his depressed attitude caused him severe personal problems.
 
      In conclusion, because of the recent shakeups at Atari, I am lead to
believe that the bosses and most of all, Sam Tramiel, are bent on making
the U.S. Marketplace Atari's best success story.  If such is not the case,
then it would be wise to say ...."they had better go underground" because
a lot of "not so wealthy" people tied up some "big" bucks in the Atari
Dream........Personally, I feel all is well in Sunnyvale, and we still
haven't seen the end of the major changes in staff or in policy.  Besides,
Mega 4s and Laser printers make terrible hats!
 
 
                                         Rex.......
 
 
 
 
--------------------------------------------------------------------------
 
 
 
 
                         HARD DISK FACTS AND FIGURES
                         ===========================
 
The Straight Info!
------------------
 
To begin, 99% of all hard disks are made to conform to IBM standards. With
this thought in mind we shall proceed.........
 
The most readily available and in my opinion, the most reliable hard disk
is from Seagate......next in line is the Miniscribe. There are
others but you must make sure they conform to the IBM standard.
 
                         IBM STANDARD: ST-506/ST-412
                         ---------------------------
Most commonly found hard drives do not have controllers built in. These
are the most reliable and economical drives to use.
 
WHAT IS THE CONTROLLER???
=========================
This goodie is the custodian of your hard disk!  It directs all I/O
functions to the hard disk and it points to and accesses each cylinder.
It "controls" everything.
 
                           FACTS FOR REFERENCE
                           -------------------
ST 412 DRIVES WITH MFM ENCODING    5.0 MEGABITS/SEC.
-------------------------------------------------------------------------
DATA            ST 125        ST138       ST225       ST251       ST251-1
-------------------------------------------------------------------------
SIZE f'm'd       21            32          21          42          42
# HEADS           4             6           4           6           6
CYL's            615           615         615         820         820
STEP RATE uS    3-200         3-200       5-200       3-200       3-200
AC'S TIME mSEC   28            28          65          40          28
WRITE PRE'C      N/A           N/A       300/614       N/A         N/A
POWER watts      10            10          14.8        11          12
-------------------------------------------------------------------------
                ST4038          ST4051        ST4053         ST4096
-------------------------------------------------------------------------
SIZE f'm'd       31              42            44             80
# HEADS           5               5             5              9
CYL'S            733             977           1024           1024
STEP RATE uS    10-70           10-70          3-70           3-70
AC'S TIME mSEC   40              40            28             28
WRITE PRE'C    300-732           N/A           N/A            N/A
POWER watts      25.5            25.5          23             25.5
-------------------------------------------------------------------------
ST 412 INTERFACE DRIVES WITH RLL ENCODING     7.5 MEGABITS/SEC
-------------------------------------------------------------------------
DATA           ST138R    ST157R    ST238R    ST251R    ST277R   ST4141R
-------------------------------------------------------------------------
SIZE f'm't       32        49        31        43        65       122
# HEADS           4         6         4         4         6        9
CYL'S           615       615       615       820       820       1024
STEP RATE uS   3-200     3-200     5-200     3-200     3-200      3-70
AC'S TIME mSEC   28        28        65        40        40        28
WRITE PRE'C     N/A       N/A       N/A       N/A       N/A       N/A
POWER watts      10        10       14.8       11        11       25.5
-------------------------------------------------------------------------
SCSI INTERFACE (EMBEDDED CONTROLLER) HARD DISKS
-------------------------------------------------------------------------
DATA            ST138N      ST157N     ST225N     ST251N      ST227N
-------------------------------------------------------------------------
SIZE f'm't        32          48         21         43          64
SECTORS         63,139      95,015     41,170     84,254      126,790
ACCESS TIME       28          28         65         40           40
POWER watts       12          12        16.8        13           13
-------------------------------------------------------------------------
Be Advised, as of 01/01/88, Seagate began using the new I'ntl light code,
the front light on the drive is GREEN ONLY if it is made after Jan.01 1988.
If you purchase one and the light on the front is red, it's either old 
inventory, used or rebuilt.  I do not advise the use of the "N" type H/D,
they're limited in their flexibility of use by the embedded controller and
are more expensive. Seagate may cost more, but they are the workhorses of
the industry. The Seagate Hard Disk is extremely RELIABLE. Seagate units
40mb, and above, have auto-park.
 
All of the above are:FCC,TUV/UL/CSA [CERTIFIED]
 
The list of other types of drives is large, some are, Disctron, Lapine,
Microscience, Micro-memories, Miniscribe, Priam, Rodime, Shugart, Tandon
and Tulin.  The formatted size of these range anywhere from 5-???Mb.
 
I purposely avoided Brand Names of packaged drives because in most
cases they use Adaptek and Seagate or Miniscribe...I have found that 
Atari and Supra have gone to the 3.5 hard disk. I will cover those next
time.  As far as Atari is concerned, they would have saved a fortune in 
R&D if they had used the standard assembly, as the method they used is so
typical of Atari, "they walked all 'round the barn to walk in the front 
door", why did they have to change the 'prom, it made the SH204 a problem
maker, why the dip switches?,,do they really think the Atari user cant 
handle Terminal resistor packs and jumpers???  Bad Move!  Some of the 
companies have gone to Miniscribe, (the coffee grinder) to cut production
costs, they will go back to SEAGATE as soon as they realize the RMA 
numbers are eating their lunch!
 
Remember that all these drives (except for a few) come without a
controller, you really want it without a controller..it's less expensive
and works out much better for you in the long run.....you will see!
 
The actual chain of connection for a hard drive is:
 
1-hard disk
2-controller
3-interface..and the DMA port.
 
MFM- This is a format style most commonly found in use although recently,
RLL has been becoming far more popular as it is a condensed compact
format thus allowing more data to be stored on an equivalent size hard
disk.  The major difference is the media itself in the hard disk is
PLATED to insure accuracy and longevity.  Think of it like plain
recording tape and Cr02 Chromium Dioxide tape.  The recording media in
the "R" drives (Seagate) is of a high quality and plated.
 
In most cases, the Interface, ( Host Adapter ) determines what type of
system the hard disk will comply with. It also (usually) has a clock/
calendar built in.
 
In reality you can take a hard drive system made for an 8bit XL/XE and
change the interface to one for an ST and it will now work on the ST
(after a format).
 
The two most widely used controllers, and I might add, ARE REALLY THE
BEST, are made by Adaptek they are designed with the user in mind and
provide for expansion for the future.
 
                    ADAPTEK 4000 SERIES CONTROLLERS
                    -------------------------------
          ACB-4000A                                  ACB-4070
          ---------                                  --------
Interface SCSI dr type    ST506/412             ST506/412 [RLL-Certified]
 
While Adaptek does offer other controllers, the 4000 series seem to be the
most reliable.  Note: the 4070 does require sheilding when mounted close
to the drive.
 
These hard disk systems are special in one way, they have embedded
controllers.
                              IOMEGA
                              ------
          ALPHA 10H                                  BETA XXX interface
SCSI dr type    Cart 10mb                                  Cart xxmb
 
                              RODIME
                              ------
          RO650                                      RO652 interface
SCSI  dr type    10mb                                      20mb
 
                              SEAGATE
                              -------
                 ST225N interface  SCSI dr type    20mb
 
*** NOTE Iomega, Rodime, and the 1 Seagate, see listing above, listed are the
    embedded controller type.  These are slowly fading from popularity.
 
                          WESTERN DIGITAL
                          ---------------
          WD1002-SHD interface   SASI dr type     ST506/412
 
                               XEBEC
                               -----
          1410                                          1410A interface
SASI dr type    ST506/412                                    ST506/412
 
* These devices are SASI and are slowly fading into the sunset......
 
ADAPTEK CONTROLLERS
===================
ACB4000A / ACB4070 are highly recomended and of excellent design. These
controllers will handle most any application.
 
HARD DISK INTERFACE
===================
There are three types available for the ST:  ICD, Supra, and Berkley
 
 
THE ICD ST HOST ADAPTER INTERFACE
=================================
The Host Adapter is designed for the 16 bit ST hard drive system or for
most anything you care to couple to it...ie, tape backup and hard disk
and laser printer etc..
 
The host adapter interface is also equipped with an setable clock 
made non-volatile thru the use of a lithium battery. 
 
                                  SUPRA
                                  -----
All of Supra's interfaces are quite good, and as flexible and have the
same features as ICD in fact, at this time we reccomend the use of the
Supra system as it has more recent updates.  Also, Supra provides
additional chaining thru scsi ports.
 
The configurations for the hard disk systems are variable, for example,
if you wished to use the stand alone system with a different computer you
would be able to do so simply by changing the interface.
 
Expandable means you can add another drive at a later date in the
existing cabinet without major circuitry changes.  The proper cabinets are
those made for the IBM twin half height disk drives.  They take up less of
a footprint than the SH204 and have a 70watt switching power supply and
blower included in the cost. Also included in the price is a blank panel
for the empty drive space if you are using only 1 half height drive to
start with.  The cabinet fits like a glove not like an old garbage bag..
 
All Information provided by:
 
                      ABCO COMPUTER ELECTRONICS INC.
                              P.O. Box 6672
                     Jacksonville, Florida 32236-6672
 
                              904-783-3319
 
                  HARD DISK SYSTEMS TO FIT EVERY BUDGET
                  -------------------------------------
 
                20mb   #SG20510   "The Ranger"     519.00
                30mb   #SG32610   "The Hawk"       649.00
                40mb   #SG44810   "The Titan"      849.00
                65mb   #SG60101   "The Saturn"    1149.00
 
          Larger, (Custom) units available - (Special Order Only)
                           All units are expandable
            ***  Available for ST - Amiga - Mac - IBM   ***
 
          6 month Guarantee and a 6 month Parts & Labor Warranty
 
                          FULL YEAR OF COVERAGE!
                           (under normal usage)
 
                              --------------
 
NOTE: This article and the "Hard Disk Series" are for the readers of
      ST REPORT MAGAZINE and may not be duplicated in any form without
      the expressed written permission of the author.
 
 
 
 
--------------------------------------------------------------------------
 
 
 
 
                           -TANGERINE DREAM-
                           =================
 
 
REVIEW SEPT 24 1988 CONCERT, BERKELEY CA.
 
      For those of you out there who do not know who or what 
Tangerine Dream are, here is a short explanation.
 
      Tangerine Dream are a 3 piece sythesizer group from Germany.  They 
have been around making music since the late 60s/early 70s.  I 
have been listening to them since around 1975.  They are probably the 
pioneers of modern electronic music.  They have put out at least 
20 albums and many soundtracks.  The band has gone through lineup 
changes a few times and of the original three only one remains, 
Edgar Froose.  They have retained much of their original style 
although they have evolved as any group worth their artistic 
talent should.  As electronics itself has evolved in music so 
comes the use of computers in electronic music.  Tangerine Dream 
has adopted the Atari ST into their world to control much of what 
they do.  The computers (they use 11, 5 in concert) control sound 
patches and rhythms and do a lot of musical housekeeping.
 
      Tangerine Dream performed live at the Berkeley Community 
Theatre, Saturday September 24th. It was one of three tour stops in 
California.  They have criss-crossed their way from Canada through 
the States and will finish up in Vancover BC this week.  The tour 
promoted their latest album 'Optical Race'.  It states on the 
back side of the album cover 'This album has been produced
on the ATARI ST using Steinberg/Jones Software'.  Even though I 
have been following them for many years, this was the first 
concert of theirs I had ever seen. Atari Computers sponsored the 
tour and you could tell the moment that you walked into the 
theatre.  We were greeted with a big banner with Tangerine Dream 
and Atari logos plastered all over it, a treat for an Atari freak 
like myself.  The stage setup consisted of three stations with 
many synths and a couple of ST's (Megas I think) at each one. 
What a sight for these Atari lovin eyes, especially with 
thousands of Tangerine Dream fans all around. Enuf' of this, on 
to the performance.
 
      Andy Summers (ex-Police guitarist) opened up the show for them 
with a very short set (thank heaven), just a rhythm machine and a 
guitar. It was not exciting. When Tangerine Dream began their 
set they were greeted with cheers that told you were in 
the company of some very excited and loyal fans.  I had not known 
they had such a following.  The music was very well projected with 
the complexity and synchronization that one rarely has the 
pleasure of witnessing.  About half of the material was from the 
'Optical Race' album.  The other must have been new, at least to 
me. The rhythm tracks, synth drum sounds and lead keyboard work 
was simply amazing.  I found myself chuckling with the enjoyment 
that I was in, sometimes wondering if I was listening to a giant 
CD player.  That is how clear and precise it all was.  The music 
was more mainstream, rhythmically 'rolling' and more intricate  
than their past works I am accustomed to.  Their previous stuff 
was more spacy and eerie with a more heavy,synthetic sound. They 
had a great light show that seemed to be controlled by one of the 
sythesizers.  Lights flashing,moving and pulsating creating 
something visual out of the audio. A few times we were shown the 
individual qualities of the group with piano solos and Edgar 
Froose's electric guitar work.  They were called out for two 
encores which they played two or three more numbers each. It was 
a evening that I enjoyed very much.  I hope some of you also 
share my feelings about the concert and were able to attend one 
of the many tour stops.  Some diehard Tangerine Dream fans are undoubtedly
feeling that they are maybe going commercial with their new sound. 
Well, Yes I guess they are.  But it is a healthy step forward to 
reach a wider audience than they have had and they sure sound 
GREAT. Don't get scared off, they are not nearly as commercial as 
say Windham Hill, and I consider myself THE diehard Tangerine 
Dream fan.  I wish I could explain to you better what Tangerine 
Dream are all about.  The only way to know is to experience them 
yourself.  If you are a seasoned fan of electronic music buy 
anything and everything by them.  If you are new to the field or 
are more mainstream (normal?) in your musical tastes then start 
with 'Optical Race' and go backwards from their.  If you share my 
interest in Tangerine Dream drop me a line. 
 
      If anyone can tell me where I may find the video that they were 
selling at the concert please let me know. 
 
                                Rod Swanson
                              2131 Strauss Ct
                            Fairfield Ca. 94533
 
 
 
 
--------------------------------------------------------------------------
 
 
 
 
                           ANTIC PUBLISHING INC.
                              COPYRIGHT 1988
                          REPRINTED BY PERMISSION.
 
 
 
    Professional GEM  by Tim Oren
    Column #6 - Raster Operations
 
 
 
       This installment  of  ST  PRO  GEM, is  devoted to explaining  the
    raster,  or  "bit-blit" portion of the Atari ST's VDI functions.
 
       Please  note  that  this  is  NOT  an  attempt to show how to write
    directly  to  the  video memory, although you will be able to deduce a
    great deal from the discussion.
 
 
    DEFINING TERMS
 
       To  understand  VDI  raster  operations, you need to understand the
    jargon  used  to  describe them.  (Many programmers will be tempted to
    skip  this  section  and  go directly to the code.  Please don't do it
    this time: Learning the jargon is the larger half of understanding the
    raster operations!)
 
       In VDI terms a raster area is simply a chunk of contiguous words of
    memory,  defining a bit image.  This chunk is called a "form".  A form
    may reside in the ST's video map area or it may be in the data area of
    your application.  Forms are roughly analogous to "blits" or "sprites"
    on other systems.  (Note, however, that there is no sprite hardware on
    the ST.)
 
       Unlike  other  systems,  there is NO predefined organization of the
    raster  form.   Instead, you determine the internal layout of the form
    with  an  auxiliary  data  structure  called  the MFDB, or Memory Form
    Definition  Block.  Before going into the details of the MFDB, we need
    to  look at the various format options.  Their distinguishing features
    are  monochrome  vs. color, standard vs. device-specific and even-word
    vs. fringed.
 
 
    MONOCHROME VS. COLOR
 
       Although  these  terms  are  standard,  it  might  be better to say
    "single-color  vs. multi-color".  What we are actually defining is the
    number  of bits which correspond to each dot, or pixel, on the screen.
    In  the ST, there are three possible answers. The high-resolution mode
    has one bit per pixel, because there is only one "color": white.
 
       In the medium resolution color mode, there are four possible colors
    for each pixel.  Therefore, it takes two bits to represent each dot on
    the  screen.   (The  actual  colors which appear are determined by the
    settings of the ST's pallette registers.)
 
       In  the  low  resolution  color mode, sixteen colors are generated,
    requiring  four bits per pixel.  Notice that as the number of bits per
    pixel  has  been doubled for each mode, so the number of pixels on the
    screen  has  been  halved:  640  by 400 for monochrome, 640 by 200 for
    medium-res, and 320 by 200 by low-res.  In this way the ST always uses
    the same amount of video RAM: 32K.
 
       Now we have determined how many bits are needed for each pixel, but
    not  how they are laid out within the form.  To find this out, we have
    to see whether the form is device-dependent or not.
 
 
    STANDARD VS. DEVICE-SPECIFIC FORMAT
 
       The  standard  raster form format is a constant layout which is the
    same  for  all  GEM  systems.   A device-specific form is one which is
    stored in the internal format of a particular GEM system.  Just as the
    ST  has  three  different  screen  modes,  so  it  has three different
    device-specific  form  formats.   We will look at standard form first,
    then the ST-specific forms.
 
       First,  it's  reasonable  to ask why a standard format is used. Its
    main function is to establish a portability method between various GEM
    systems.   For  instance, an icon created in standard format on an IBM
    PC  GEM  setup  can be moved to the ST, or a GEM Paint picture from an
    AT&T 6300 could be loaded into the ST version of Paint.
 
       The  standard  format  has some uses even if you only work with the
    ST,  because  it gives a method of moving your application's icons and
    images  amongst  the  three different screen modes.  To be sure, there
    are  limits  to  this.  Since there are different numbers of pixels in
    the  different  modes,  an icon built in the high-resolution mode will
    appear  twice  as  large  in  low-res mode, and would appear oblong in
    medium-res.   (You  can  see  this effect in the ST Desktop's icons.)
    Also,  colors  defined  in  the  lower  resolutions will be useless in
    monochrome.
 
       The  standard  monochrome format uses a one-bit to represent black,
    and  uses a zero for white.  It is assumed that the form begins at the
    upper left of the raster area, and is written a word at a time left to
    right  on  each row, with the rows being output top to bottom.  Within
    each word, the most significant bit is the left-most on the screen.
 
       The  standard  color  form  uses  a  storage  method  called "color
    planes".  The high-order bits for all of the pixels are stored just as
    for  monochrome, followed by the next-lowest bit in another contiguous
    block,  and  so  on  until  all  of the necessary color bits have been
    stored.
 
       For  example,  on  a 16-color system, there would be four different
    planes.   The  color  of  the  upper-leftmost bit in the form would be
    determined  by  concatenating  the high-order bit in the first word of
    each plane of the form.
 
       The  system  dependent  form  for  the ST's monochrome mode is very
    simple: it is identical to the standard form!  This occurs because the
    ST   uses  a  "reverse-video"  setup  in  monochrome  mode,  with  the
    background set to white.
 
       The video organization of the ST's color modes is more complicated.
    It  uses an "interleaved plane" system to store the bits which make up
    a  pixel.   In  the  low-resolution  mode, every four words define the
    values of 16 pixels.  The high-order bits of the four words are merged
    to  form  the  left-most pixel, followed by the next lower bit of each
    word,  and  so  on.   This  method  is called interleaving because the
    usually  separate  color  planes  described  above  have been shuffled
    together in memory.
 
       The  organization  of the ST's medium-resolution mode is similar to
    low-res,  except  the  only  two words are taken at a time.  These are
    merged to create the two bits needed to address four colors.
 
       You  should  note  that  the  actual color produced by a particular
    pixel value is NOT fixed.  The ST uses a color remapping system called
    a  palette.   The  pixel value in memory is used to address a hardware
    register  in  the  palette  which contains the actual RGB levels to be
    sent to the display.  Programs may set the palette registers with BIOS
    calls,  or the user may alter its settings with the Control Panel desk
    accessory.  Generally, palette zero (background) is left as white, and
    the highest numbered palette is black.
 
 
    EVEN-WORD VS. FRINGES
 
       A  form always begins on a word boundary, and is always stored with
    an  integral  number of words per row.  However, it is possible to use
    only  a  portion  of  the  final  word.  This partial word is called a
    "fringe".   If,  for instance, you had a form 40 pixels wide, it would
    be  stored  with  four  words per row: three whole words, and one word
    with the eight pixel fringe in its upper byte.
 
 
    MFDBs
 
       Now  we  can  intelligently  define  the elements of the MFDB.  Its
    exact  C  structure  definition  will  be  found  in the download. The
    fd_nplanes  entry  determines  the  color  scheme:  a  value of one is
    monochrome,  more than one denotes a color form.  If fd_stand is zero,
    then the form is device-specific, otherwise it is in standard format.
 
       The  fd_w and fd_h fields contain the pixel width and height of the
    form  respectively.   Fd_wdwidth  is  the width of a row in words.  If
    fd_w  is  not exactly equal to sixteen times fd_wdwidth, then the form
    has a fringe.
 
       Finally,  fd_addr  is the 32-bit memory address of the form itself.
    Zero is a special value for fd_addr.  It denotes that this MFDB is for
    the video memory itself.  In this case, the VDI substitutes the actual
    address  of  the  screen,  and it ignores ALL of the other parameters.
    They  are  replaced  with  the  size of the whole screen and number of
    planes   in  the  current  mode,  and  the  form  is  (of  course)  in
    device-specific format.
 
       This  implies  that  any  MFDB  which points at the screen can only
    address  the entire screen.  This is not a problem, however, since the
    the  VDI  raster calls allow you to select a rectangular region within
    the  form.   (A  note  to  advanced  programmers: If this situation is
    annoying, you can retrieve the address of the ST's video area from low
    memory,  add  an  appropriate  offset, and substitute it into the MFDB
    yourself to address a portion of the screen.)
 
 
    LET'S OPERATE
 
       Now we can look at the VDI raster operations themselves.  There are
    actually  three:  transform  form, copy raster opaque, and copy raster
    transparent.   Both  copy  raster  functions  can perform a variety of
    logic operatoins during the copy.
 
 
    TRANSFORM FORM
 
       The  purpose  of  this operation is to change the format of a form:
    from standard to device-specific, or vice-versa.  The calling sequence
    is:
 
        vr_trnfm(vdi_handle,source,dest);
 
    where source and dest are each pointers to MFDBs.  They ARE allowed to
    be  the  same.   Transform form checks the fd_stand flag in the source
    MFDB,  toggles  it  and  writes  it  into  the  destination MFDB after
    rewriting the form itself.  Note that transform form CANNOT change the
    number  of color planes in a form: fd_nplanes must be identical in the
    two MFDBs.
 
       If  you  are writing an application to run on the ST only, you will
    probably  be  able to avoid transform form entirely.  Images and icons
    are  stored  within  resources  as  standard forms, but since they are
    monochrome, they will work "as is" with the ST.
 
       If  you  may  want to move your program or picture files to another
    GEM  system,  then you will need transform form.  Screen images can be
    transformed  to  standard  format  and stored to disk.  Another system
    with  the  same  number  of color planes could the read the files, and
    transform the image to ITS internal format with transform form.
 
       A  GEM  application  which  will be moved to other systems needs to
    contain  code  to  transform the images and icons within its resource,
    since standard and device-specific formats will not always coincide.
 
       If  you  are  in this situation, you will find several utilities in
    the  download  which  you  can  use  to  transform  G_ICON and G_IMAGE
    objects.  There  is  also  a routine which may be used with map_tree()
    from the last column in order to transform all of the images and icons
    in a resource tree at once.
 
 
    COPY RASTER OPAQUE
 
       This  operation  copies  all  or  part  of the source form into the
    destination  form.   Both  the source and destination forms must be in
    device-specific  form.   Copy  raster opaque is for moving information
    between  "like"  forms,  that  is,  it  can  copy  from  monochrome to
    monochrome,  or  between  color forms with the same number of planes.
    The calling format is:
 
        vro_cpyfm(vdi_handle, mode, pxy, source, dest);
 
       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.
-------------------------------------------------------------------------