                      ST REPORT WEEKLY ONLINE MAGAZINE
                            Monday, SEPT. 5, 1988
                               Vol II  No. 51
                                ===========

            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..................> TOS IN ROM  A Description.........
> BOOTSTRAP A SECOND LOOK.............> A Day at the Races-new release....
> The Transputer......................> The Beat Goes On..................
> Pro GEM Windows #2..................> Good Times Ahead..................
> ST REPORT CONFIDENTIAL..............> Latest ST XFORMER NEWS............

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

From the GM's Desk:

In the past month or two, we have seen the entire scenario change three
times as far as Atari is concerned.  Of these changes Atari can be held
directly responsible for two and therefore be given the credit for having
made the changes.

The Dram situation is not the fault of Atari but you can be sure they are
not sitting still over this matter....Jack Tramiel has been in Washington
D.C. (The Hill) attempting to "enlighten" a few of our uninformed
legislators....GOOD LUCK TO YOU SIR!

The other changes are sure to, in the future, be a veritable golden bonus
to the users but for now are rather painful and aggravating to put up
with.  My hope is that both Atari and the UserBase (Us Too!) can tolerate
the inconveniences and clumsiness closely associated with the total, in 
the field, reorganisation we are witnessing.

The time is at hand for all parties concerned to maintain level heads and
cool tempers ....we all are aware that an emotional statement will roll on
for what seems to be an eternity and produce nothing but more hard
feelings and personal attacks this must come to a screeching halt.

We at ST Report are dedicated to forthright information without the
pressure of any IOUs and when we see what we feel is either hurting Atari
or it's users we will indeed make what we find known to all.  The Flip
side of the coin is treated the same way We shall report fully and
completely all positive matter that effect either Atari and/or the
Userbase.

As of this issue, we will strive to point out to the readers as many of
the positive items we can find.  Some have asked; why do we reprint
certain things we find on the major services?  The answer is simple, many
of the folks who eventually get to read ST Report have no modem...
therefore, everything we have here is "new" to them.  We are now
opening an extended hand and asking for reader submitted articles.  We
hope to see full participation by all.  Reader Submissions maybe U/Led to
any of the services attached to E-Mail or, sent to ST Report via FNET NODE
# 350.


                                         R.F.MARIANO
                                       Gen'l Mgr. APEInc.



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



                               THE "NEW" TOS
                               =============

AUG/88

     TOS ROM set, configured for local keyboard and American text.
     Diskette (D/S) containing:

        RAM loadable image of TOS, same configuration as ROM
        Disk cache program "CACHExxx"
        HDX Hard Disk utility, HINSTALL and associated programs
        Product Tracking System front-end program "SPRgen"
        Release Notes for:
           TOS
           CACHExxx
           HDX, HINSTALL etc (modified to 30/60MB hard disks)
        Draft User Manual for HDX, HINSTALL etc.
        User guide for Product Tracking System
        Various programs, files and tools to assist in translation

Each subsidiary has been invited to select a small set of Beta  sites,
and  has  been requested to ensure that each  such  site  accepts,  in
writing,  certain terms and conditions, including:

        No copies to be made.
        Products and documentation are prerelease and without warranty
        All  communications  are  to  be  made  solely  to  the  Atari
        subsidiary, and not through public channels.
        All   copies  and  documentation  to  be  returned  to   Atari
        subsidiary on demand.
        Weekly report indicating name(s) of tester(s), tests performed,
        observations to be filed with Atari subsidiary each Friday.
        Any  bug  reports to be first verified against  the  currently
        released hardware/firmware, to ensure problem is with new TOS.

We want to know what works as well as what doesn't work.  A report  of
"no problems" is worthless if it is not accompanied by an  explanation
of what testing has been performed. If a program fails, it is critical
that it be  tested with other RELEASED configurations,  so that it  is
very  clear whether or  not the failure is attributable solely to  the
new TOS.

In  our  testing we have found MANY ill-behaved  programs  which  fail
because  they appear to access beyond the Mega 4's 4MB  RAM  limit.  I
believe  they are accessing "just beyond" where they are supposed  to,
and  it's  only on the Mega 4 where they run out of  physical  address
space rather than physical memory. Almost all programs which fail this
way have been retested on the current TOS and fail in a similar way.

This  beta  release  is not the final  one.  Programs  should  not  be
modified to look for the date encoded in this version.

PLEASE DO *NOT* CONTACT ANYONE IN ATARI R&D TO SUPPORT THIS BETA TEST.
ALL  ENQUIRIES  SHOULD  BE DIRECTED TO THE TECHNICAL  MANAGER  OF  THE
APPROPRIATE ATARI SUBSIDIARY,  OR TO JOE FERRARI (408-745-2010) IN THE
USA.    The R&D group must now address the port of TOS to revised  and
new hardware platforms,  and so I would appreciate your NOT disrupting
the development activity.  We have support groups in place,  and  they
MUST  be your first line of support if development of new products  is
to continue at optimum speed.

     A summary of the major improvements to TOS follows:

     Floppy formatting is "more compatible" with IBM-PC format.
     A file may be moved (i.e. copy/delete) in one operation.
     File Copy/Delete/Move can be interrupted with "undo".
     GEM programs can be autobooted from disk.
     If a name conflict occurs during a file copy, Copy/Skip/Quit are
     allowed.
     A folder may be renamed via "Show Info".
     The static file allocation limit of 400 is removed; limited now
     by free memory.
     "Show/Print File" are completely rewritten.
     File copying on a single floppy system uses all available memory
     for buffers.
     "wind_update(FALSE)" is set when recovering from an application
     crash.
     All date separators are now "/".
     File Selector has had major rework:
        16 drive buttons.
        Application can send a "title" string to FSEL.
        FSEL now takes first <RETURN> on pathname edit as end-of-edit.
        Static file allocation of 100 files is removed.
        Long pathnames and "ABORT/CONTINUE" now handled correctly.
        Preserves  current DTA buffer addresses,  clip rectangles  and
        default directories.
     New bindings available.
     "appl_init" returns version 0130 in global(0).
     Editable fields may now be followed by non-editable characters in
     dialog boxes
     "wind_get()"  with  field parameter  WF_SCREEN  returns  address/
     length of AES menu/alert buffer.
     "Ptsin" (VDI) allows 512 vertices (true since 4/22/87).
     "vqt_extent": Pixel errors on some 270 degree rotations are fixed
     "vq_mouse" reliability enhanced.
     40-folder bug alleviated to the point of improbability.  A folder
     only  takes  up  space when "active".  Limited now  by  depth  of
     folders and the accumulated depth of open files.  FOLDRxxx  still
     available.
     "Malloc" restriction of 20 blocks/process lifted.
     FAT searching code for floppy and hard-disk is MUCH faster.
     Sector   buffering  greatly  improved,   and  "CACHExxx"   allows
     expansion.
     "Frename" can now rename a folder.
     Archive bit (0x20) fully supported.
     Time stamps for "." and ".." are now correct.
     "Fsettime/Fsetdate" match BIOS and GEMDOS values
     "Fdatime" input value byteswap fixed
     Major improvements to "Ccon*" and redirection in general
     OS  Pool reduced to same size as 11/20/85 ROMs (pre  Mega).  This
     may allow some programs which fail on Mega ROMs to work again.
     Soft  Reset  available from Keyboard if using  standard  keyboard
     handler.
     Soft reset by CTRL/ALT/DEL.
     Cold Boot clears all available memory (CTRL/ALT/right SHFT/DEL).
     "Rsconf(-2,-1,-1,-1,-1,-1)  returns last baud rate value  set  by
     Rsconf.
     Structure  of the reserved part of DTA has changed,  and  remains
     reserved.
     Improvements made to detection of media change.

THE ABOVE IS A SUBSET OF THE ENHANCEMENTS MADE.  THERE ARE MANY  MORE,
FULLY DOCUMENTED IN THE RELEASE NOTES SENT TO EACH SUBSIDIARY.

----------------------------------------------------------------------
Roy J.  Good
Product Development,  Atari Corporation
Views expressed are my own. Atari may agree or disagree; they have the
right.
----------------------------------------------------------------------
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                      -
                                 


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



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



                          BOOTSTRAP - A SECOND LOOK
                          =========================

The Sequel
----------

by M. Arthur

  After writing STSUPORT, (the original name of the essay) I realized that
I made a few errors which, though minor, ARE serious enough to require
a clarification.

I am glad the article appeared in ST REPORT, however I feel this note is 
needed because ST REPORT is usually under tight scrutiny by Knowledgable 
ST Users from a wide and diversified readership.  I do not wish the few
errors in the essay criticizing Atari to become an excuse for dismissing 
it as "Atari Bashing", I would hope this clears up any errors in the
article: BOOTSTRAPPING ATARI.  

And Now:
-------
1)  The Timex Sinclair Spectrum QL (not to be confused with the OTHER 
Timex Sinclairs) wasn't AS FAST as the ST, but was, in many areas, faster
or equally as fast as the Amiga.

2)  As known by most ST users, the number of colors in each resolution of
the ST are the most possible to use while not slowing down the 68000.

 While this DOES come in handy, there ARE times when many colors
are needed (Spectrum 512?), and when slowing down the processor chip as a
result is NOT important.  This is when the "Extended Resolutions" could be
useful.

For those unfamiliar with the Extended Color Resolution specs requested,
they are: A 512 color Low Resolution, and a 16 Color Medium Resolution,
(Like EGA?) out of a palette of 4096 colors if possible, and 16 Shade 
gray scaling for High Resolution.  This would be an "Extended" Color Mode
available as options like EXTENDED LOW, EXTENDED MEDIUM, and EXTENDED HIGH
RESOLUTION, so the current ST Resolutions would be standard, but that ST
Users/Developers wanting better graphics could use any Extended
Resolution.

This idea SHOULD be done in HARDWARE, as software solutions to problems
like this, which usually emulate the preferred feature, like PC Ditto for
IBM Emulation, or Spectrum 512, have been slower than if they were done 
in hardware.  And NOT EVERYONE can spend 3000-4000 dollars ,has the time 
to learn UNIX or, the skill needed to make applications for Atari's 68030
Machine to obtain superior graphics. Contrary to beliefs of a few, having
LOTS of colors has also become a fact of life for microcomputers. 
(EGA, VGA, Mac II, Amiga for examples)

If Atari R&D (or the Tramiels) is wary of this idea, ALL they need do is
incorporate the Trio  routines into the MMU chips and coupled with TOS
support having 512 colors at the same time WON'T take up 80-90% of
processor time.  Which is what Atari WANTED to keep from happening to ST
displays, wasn't it?

3)  A quote, from BOOTSTRAPPNG ATARI:

"There is no reason why Atari could not come out with a Mega board with
the Motorola 68851 MMU chip providing the functions of a TRUE MMU, such as
memory paging for virtual memory, this would make TOS support of all the
68000 address space easier.  Perhaps selling it through DEALERS along with
the new ROMs is a way to go.  Fact is, using the MMU chip for other 
purposes, would definately be improving the ST's capabilities in the 
process."   No other logical reason except that the 68000 chip cannot 
support MMUs of this type, OR hardware memory protection, making use of 
a 68851 impossible.

But.. the 68020, which has been neglected by TOS, Does support the 68851.
Thereby making hardware memory protection, and bomb-free multitasking, 
possible.  MT C-SHELL, while a good ST multitasker, is not bomb free, 
because of the use of the 68000, and while being reliable, isn't that 
foolproof, just as Multifinder isn't.  IF Atari would cause TOS to 
support the 68020 we would have true multi tasking

Along with Mac II emulation, if the 68020 ST were to have an expansion 
card making the ST meet Mac II resolution and use a 20-25 MHZ 68020 
along with an optional hardware "box" that had  2-6 NuBus (Mac II board 
type) slots.

4) Another quote which isn't QUITE true:

"the Mac II, which is..not powerful enough, except in the area of speed"

I meant to edit this before I sent it anywhere, but it slipped by.  The
Mac II is the BEST in some areas of computing, having super graphics and
a good design, except for it's speed, which it isn't as good.  Atari's 
68030 UNIX machine ought to be its main competition, if it doesn't become
vapor.


5) The comments relating to piracy are about the ST being perceived as 
the segment of computers having the most pirates.  Perhaps this is a
very logical conclusion.   When one compares the number of machines in use
to the number of the number of pirates that have been caught.  However, 
this is a deceptive impression.   The amount of machines in use is in 
question, some say 225,00 others say 400,000+, we are inclined to go
with the higher number, since certain program sales would show this figure
to be more accurate.... Ratio and proportion would dictate that the more
machines in use, the more pirates...True, but consider this, the more
machines in use...the more sales recorded for new releases.  This is the
fly in the ointment; Each and every Atari ST owner could buy a copy of
a new release and a version of it released in the IBM or MAC market would
casually out sell it!

COUPLED with erratic product supply and the lack of advertising, can 
anyone expect the publishers and developers for the ST market to be 
bubbling over with enthusiasm and high expectations?  Just ask 'em about 
the developer's kit.

The above comments and corrections were supplied by the Author of the
article, A KEEN OBSERVATION.....BOOTSTRAPPING ATARI, Micheal Arthur.  We
thank him for his candor and sincere attempts for real accuracy.


               "A little caution outflanks a large cavalry"
                                               - Bismarck -




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




                           TOP UPLOADER CONTEST!!
                           ======================


               Beginning September 3,1988 till October 3, 1988
               -----------------------------------------------

PRIZE LIST
----------
1st PRIZE:........... 5 hours of Genie connect time non-prime time

2nd PRIZE:........... 3 hours of Genie connect time non-prime time

3rd PRIZE:........... 2 hours of Genie connect time non-prime time

RULES:
------
Prizes will be credited to ones account when winners are announced shortly
after October 3,1988.  

We will be awarding 3 prizes for:  The MOST files uploaded.
                                   Pictures and song files are excluded
                                   also non-functioning slideshows. 
                                   
                   Duplicates will not be counted.

           Advertising/and or text files are also excluded. 

Remember uploading is FREE at 300/1200/2400 baud during non-primetime. 
Get those files to us and win. Besides the prizes, sharing feels good...
doesn't it?? <smile>


                                   Darlah J <Hudson> Pine
                                         Atari Sysop



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




NEW RELEASE INFO:
-----------------
                                A DAY AT THE RACES
                                ==================


              After three years of research and development we are proud
         to announce "A Day at the Races".  It was designed and
         written by Marshall Lake and Piet Francke and is being
         distributed by TEAM Software.

              "A Day at the Races" is a simulation of the horse race
         track environment.  Much more than the horse race itself,
         this simulation allows you to buy and sell horses, choose
         jockeys, and of course wager on races.  Each horse and jockey
         have their own distinct attributes and abilities which affect
         the outcome of each race.  Just like at a real track it is up
         to you to discern which abilities each horse and jockey
         possess and to attempt to pick the probable winner of the
         race.  It is as close to the real world of horse racing as
         you can get without going to the track.  The actual horse
         race itself is presented in exciting, nail-biting real time.
         Dynamic data base files are kept for the horses and the jockeys.
         All the various statistical items (including horses' past
         performances) are maintained to assist in an intelligent wager,
         horse purchase, or jockey selection.  "A Day at the Races" is
         a multi or single player game.
         
              This simulation was designed specifically for the Atari ST
         line of microcomputers.  There is nothing like it available
         for ANY other microcomputer today that we are aware of!

              Knowledge of horses or the race track is not necessary
         at all to enjoy "A Day at the Races".  The simulation is
         presented in such a manner as to make it easy for all users
         to understand.  Depth is combined with simplicity to create a
         real-world environment which can be enjoyed by everyone
         whether or not they are race track aficionados.

              "A Day at the Races" operates in the GEM environment, is
         entirely mouse controlled, and makes full use of the ST's
         superb graphics and sound.

              The simulation requires 512K of RAM with TOS in ROM, at
         least 1 disk drive, and a color monitor.  Optional equipment
         include a second disk drive and a printer.  "A Day at the
         Races" IS installable onto a hard disk drive.  Using a
         printer, you may obtain hard copy output of the Racing
         Program, the Racing Form, the Cheat Sheet, various standings,
         and many other statistics that are available.  You will,
         of course, be able to view these items on the screen, also.

              This program will be available by October 15, 1988.


                                 TEAM Software
                                P. O. Box 7332
                           Washington, D. C.  20044
                                (703) 533-2132
                                (603) 679-1211

                       Please send any comments to MLAKE.



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




                           THE TRANSPUTER
                           ==============

Captured from the ST-Report area on The Source. (PARTI)
(Atari Users Group)

Subject - Atari's new transputer

From: anc@camcon.uucp (Adrian Cockcroft)
Newsgroups: comp.sys.transputer,comp.sys.amiga,comp.sys.atari.st
Subject: Atari/Perihelion Transputer Machine Spec
Keywords: transputer atari workstation
Message-ID: <986@titan.camcon.uucp>
Date: 15 Oct 87 13:37:21 GMT
Organization: Cambridge Consultants Ltd., Cambridge, UK
Lines: 176
 
There have been rumours about Atari and Transputers circulating so I
thought that I had better get some hard information out there. I have no
involvement in Perihelion, neither has my employer although I have been
aware of events at Perihelion and know some of the people who work there.
I do want one of their workstations however, I rate it as better than a
SUN 3/260C+fpa for numbercrunching with a single T800.

A presentation was given by Atari and Perihelion at the Cafe Royal in
London on 22/9/87, over 100 software developers, hardware manufacturers
and press people attended and no restrictions were made on the information
presented at the meeting. I attended and this a quick summary of the notes
I took at the meeting.
 
First a benchmark reported by Inmos: Multivariate regression analysis
 
        IBM PC          45 minutes
        T800            18 seconds
        T800 x 4         7 seconds
 
Inmos also had a T800 powered multiuser flight simulator that kept 4
people at a time happy shooting each other down. 4 T800's per user plus a
T4 graphics card and a load of T2's handling the joysticks.

All in an ITEM box together.  The graphics animation was VERY smooth, far
better than a SUN3/260C+fpa+gpone flight simulator I have played with.
 
Atari and Perihelion have got together so that Perihelion are designing
the hardware and the software for a high performance workstation to be
manufactured and sold by Atari.
 
Perihelion Hardware
-------------------
 
Perihelion is headed by Jack Lang in Cambridge, England.
 
Stage 1 Hardware is a Mega ST add-on system intended for software
developers.
 
Stage 2 Hardware is a compatible single box workstation.
 
The Mega ST is a front end I/O processor only. The block diagram looks
like:

                                              --------- -------------
                                              |blitter| | 4 Mb DRAM |
-----------   ---------------    ---------    --------- -------------
| Mega ST |   | Interface   |    |T800-20|         |         |
| kbd I/O |---| Link Adaptor|----|       |--------------------
| mouse   |   | SCSI disk   |    |       |         |         |
| floppy  |   ---------------    ---------     ----------- ----------
-----------             |          | | |       |1 Mb VRAM| |Graphics|
                   4Mb/s|SCSI      | | |       ----------- ----------
                   ----------   3 ECL buffered
                   | 40 Mb  |   20 MHz links
                   | Winch  |
                   ----------
 
The box takes up to 16 Mb on the motherboard (using 4Mbit DRAMS) and has
three expansion slots which can take either 4Mb (1Mbit) or 16Mb (4Mbit) of
DRAM each for a total in the box of 64 Mb. The expansion slots use a
single
DIN plug (VME-type) and the 3 ECL buffered links go onto them so that a
slot can contain a board with more transputers on it. Size is enough for
four T800s + 1 Mb each per card. Graphics cards can also be used to
replace
the built-in hardware.
 
The Blitter 2D fills at 128 Mpixels/sec, 2D block copy at 16 Mpixels/sec.
(It has a novel architecture based on work by Phil Willis at Bath
University).
 
Graphics modes:
                1280 * 960 * 4 bpp
                1024 * 768 * 8 bpp
                 640 * 480 * 8 bpp 2 screens for animation
                 512 * 480 * 32 bpp true colour + overlay and tag bits
 
60 Hz, not sure about interlace.
 
Probably uses Inmos G170 CLUT giving 256K colour shades.
 
SCSI disk uses true DMA synchronous SCSI interface to get 4Mbytes/s, 40Mb
is minimum size.
 
A photo of a completed motherboard in box was shown, smaller than an IBM
PC box with 3 fair sized slots.
 
Perihelion Software
-------------------
This is based in Shepton Mallet, Somerset, England and is headed by Tim
King ex of Metacomco, Amigados fame.
 
Operating system called Helios written in C to support single processor
workstations, 4 processor workstations, 1000 processor farms or anything
in between.
 
Helios is distributed, multiprocessor, multiuser, sympathetic to the
Transputer and familiar to Unix users. Tim King has listened to the
criticism of Amigados and has avoided a lot of the complaints about that
system.
 
It is based on message passing with transparent passing across processors,
it uses a client/server model, has per-processor protection and capability
based access.
 
Networking and diskless workstations will be supported via the 3 ECL
buffered links with no extra hardware.
 
Applications can be written in 3 modes, the traditional single threaded
program, unix-like multiple processes at a coarse grain level or parallel
algorithms using a medium grain level.  Existing TOS/GEM applications can
run on the Mega ST front end processor.
 
User Interface
--------------
X-11 window system standard.
GEM - translating GEM traps on the 68K i/o proc to the T800.
GEM running under X-11 may be provided.
Standard unix like shell command line interface.
 
Compatibility
-------------
MSDOS floppy disk format
UNIX(TM) hard disk format
UNIX(TM) compatible C library
UNIX(TM) command subset
 
Languages
---------
C       Pascal  Lisp
Fortran BCPL    Occam
 
Development Tools
-----------------
Hosted on ST or Unix(TM) or MSDOS or native
 
Asm/link
C
Debugger
 
 
Atari's Position
----------------
 
They are looking for wider markets and will go upmarket into workstation
technology. The hardware design will be Atari's property but Helios is
already spreading wider, another 4 companies are likely to use it so far.
 
It will be launched at COMDEX as a Mega ST add-on for developers.
Development systems available in Dec 87/Jan 88. The standalone system will
be launched at Hannover in March 88. Product in the shops in June 88 in
the UK. Product in Europe 6 months later and US launch June 89, giving a
years head start to the UK software developers and a chance for the
machine
to gather some applications software before it hits the US.
 
Priced well below Mac II,base level entry price (no winchester or monitor)
aimed at 1000 pounds according to Jack Lang.
 
For now they will provide a set of 3 manuals, User Manual, Developers
Manual and Technical Manual for 50 pounds, you then become a registered
developer and get a priority place in the queue for developers hardware
in December.
 
Apply for more information to:  Perihelion Software Limited
                                24 Brewmaster Buildings
                                Charlton Trading Estate
                                Shepton Mallet
                                Somerset BA4 5QE



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


ATARI SHOW!
-----------

                 THE FIRST CANADIAN ATARI USER CONVENTION
                 ========================================

NOVEMBER 06, 1988.


This is CANADAS first and only Atari user convention this year.  This
convention is staged and sponsored by "THE TORONTO ATARI FEDERATION"
user group.  This group maintains 500 members both in the TORONTO/ONTARIO
CANADA area and across the country as well as having associate members 
from around the world.  We have a 40 mb 24hr BBS 416-235-0318 available.
It has everything anyone would require when using ATARI SYSTEMS.  If 
anyone wants more info on the computer show leave a message on the board 
and we will be in touch.  If this is not convenient contact the people 
listed below.

      This unique computer show is dedicated exclusively to ATARI
COMPUTER SYSTEMS.This exciting new event promises to be jam packed with
information, demonstrations, lectures and hands on work shops.  One of the
main exhibitors will be Atari Canada, showing off all the latest software
as well as its new and innovative products.  That's not all, there will be
lots of retailers selling their wares as Special Low Convention prices,
hardware and software manufacturers displaying their latest products, user
groups demonstrating Atari products and selling their PD software disks, 
lectures by knowledgeable speakers, seminars by prominent developers and 
even hands-on workshops where the registered participants can actually 
work on projects under the guidance of an expert.  There will be something
for everyone.  From multi-player adventure games on the 8-bit to business
applications for the Atari IBM clones.  So, if you are an Atari owner, or 
plan to be one or just looking for information, this is the place you 
will want to be.

  THE FIRST CANADIAN ATARI USERS CONVENTION is being held at THE SKYLINE
  TRIUMPH HOTEL located just off highway 401 on Keele Street.  

                NOVEMBER 6TH, 1988 from 10:00am to 6:00pm.  

         (Special hotel rates available)     Phone:1-800-268-1332.

For more information contact:

            PRESS: (Mike Searl) ..........416/245-5543
            EXHIBITORS: (Jim Jorritsma)...416/242-3413
            PUBLIC INFO LINE..............416/425-5357
            TAF ONLINE BBS (24hr).........416/235-0318

or, Call:  Jim Clark, President, Toronto Atari Federation 416/928-1143

      For more information send all inquiries to:

                      "TORONTO ATARI FEDERATION" 
                            Computer Show
                            5334 Yonge ST. 
               1527 WILLOWDALE, ONTARIO CANADA M2N 6M2



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



                             THE BEAT GOES ON
                             ================

The following is from one of the major online services, we felt it held
enough significance to be reprinted here.  The staff of ST Report is
withholding comment on the following matters.


31-AUG 06:55 General Information
RE: Mega/Federated (Re: Msg 6064)
From: NEILHARRIS   To: MADMODIFIER

The service idea for Federated is to start with service on a district 
basis (covering up to 8 stores) and adding more facilities as volume 
warrants.

Because the stores within a district are close enough together, turnaround
will still be minimal -- trucks will be going between the stores daily.

This is precisely how the existing regional chains do their service.  We
can't expect a chain of stores to make the capital investment in a full
repair facility for each location right up front.

As far as outside sales goes, that, too, is in the works for Federated.
And from what I have seen, it is likely that the sales efforts from
Federated could be more serious than the lip service some dealers pay to
outside sales.

Lloyd, getting off the specifics to the general -- the reason we tend to
ignore posts like your diatribe (and lately that's what you have been
leaving) is because, no matter what move Atari makes, it causes a storm of
criticism.  You would think that based on the critics, all was fine with
the ST market two years back and all the moves since then have been 
causing the problems.  From where I sit, the market was going in the wrong
direction then, and efforts have been made (and are continuing to be made)
to establish the ST.

Furthermore, these efforts are being undermined by a group of people who
take perverse pleasure in tearing down what we are trying to build up.
Lloyd, you are not even active on CIS, so I doubt you were included in the
"gang" label.  Why are you so anxious to join the club?  Is it a badge of
honor?

People seem to think we have no plans for future machines.  That could not
be farther from the truth.  There are some good moves being made up in
engineering.  Good people have been brought in to get the work done.  But
the user community doesn't seem to want to give them a chance.  It is a
terrible situation to be in. The reaction here in Sunnyvale is to pull 
away from the online areas and from the community in general, because all
we get is abuse which we cannot counter because we cannot reveal our new
products prematurely.

From my personal perspective, I am still fighting.  Much of the user
support and communications efforts in the last few years have been my
doing.  For a while, it looked like there was going to be a close
relationship between Atari and the users.  Now, it looks bleak for that
prospect.

Back to the marketplace.  "Rex" seems to think mail order is the answer.
Lloyd likes the dealers.  From inside the company, we feel very strongly
that dealers are the answer, from solid evidence that sales dropped
steadily as the product moved into mail order.  We have made moves to
cement relationships with dealers, which many dealers have appreciated and
reacted to favorably.

As to Federated, well, it is certainly a bit of a mess that needs to be
fixed.  But in the few weeks I have been involved with it, I see a lot of
potential.  At the very least, it brings the focus here much much closer
to the "front lines" of the marketplace, where lessons can be learned that
will profoundly influence the future direction of the company.

Furthermore, there is good potential to develop a group of full-service
stores catering to the entire Atari line (and more, of course).  8-bit
sales through Federated have been strong, and we're looking at expanding
that line.  What other dealer could have brought that off?

To reiterate the main point from above, every time we make a move there is
a storm of criticism, much of it from out of left field. Only time will
tell, and if those of us here who are actually fighting the war can stick
it out despite all this, I think the outcome will be what we all want -- a
robust, thriving line of quality, inexpensive computers.

--->Neil


31-AUG 06:59 General Information
RE: The Future of TOS
From: NEILHARRIS   To: ALL

Without getting specific in any way, here is a message for everyone:

                          TOS has a future.

This information comes after chats with the engineers to find out what
they're up to, and with top management here to determine our own level of
commitment.

                          TOS has a future.

--->Neil



31-AUG 21:57 General Information
RE: Mega/Federated (Re: Msg 6100)
From: MADMODIFIER  To: NEILHARRIS

Neil,

   I want to thank you for your reply, it was appreciated.  And no, I'm 
not really interested in being 'one of the gang of five', but I was told 
that I had been included as one of the 'gang'.  And I don't feel that I
'bash'.

When you guys do something right, I tell you so. But when *I feel* that 
you are doing something wrong, I'm going to tell you that also.  Now let 
me give you my side..........

   1)  I don't really care about mail-order.  I think you could allow 
mail-order stores to carry the 520 but it's not that important to me one 
way or the other.

   2)  I find that Atari seems to have two sets of rules..one for the
independent stores and another for Federated.  Why were the independent
dealers *required* to be service centers but not the Federated stores? My
local dealer was told (and I think he has it in writing) that NO stores
locally would be allowed to carry the Mega/Laser unless they had a 
complete service center.  But you don't enforce that rule when it comes to
Federated.

   3)  I understand about district servicing....but couldn't the
independents have been allowed the same thing?  Two or three local stores
would have liked to have carried the Mega/Laser but couldn't because they
didn't have service centers in their store.  BUT they all could have got
together with the one that did have a local store and formed a 'district
service center'....but they weren't allowed that option.

   4)  I think you (and Atari) have a higher regard for the Federated name
than the common person/businessman.  The vast majority of the people I
know, think that Federated is almost a joke.  Yes, they'll go there to buy
a stereo/tv when they're on sale, but they'd never rate Federated as a
'quality' store.

   5)  I have no qualms about allowing Federated to carry the ST line. I
just believe the independent dealers should be given the same breaks that
Federated gets.  Told about specials at the same time, etc. This has NOT
happened in the past.  Radio Shack for years had company stores and
independently owned stores and both got along with no problems (most of 
the independent dealers got rich).  But they only had ONE set of rules for
both....not two.

   6)  I've seen and talked to Federated employees that have been to your
seminar.  Before the seminar they were horrible, now they're just simply
bad.

   7)  I feel (my opinion) the worse thing that Atari could do would be to
stop supporting the online services.  The ST owners are leary of Atari the
way it is, if there were no communications (and that's what there would
be....) between the two groups, you'd be in worse shape than you are
now.

   8)  Finally, look at things from our perspective.  We've heard promises
about changes from Atari for almost three years now....and have seen very
few changes (from a users standpoint).  We're still waiting for the CD
Roms, IBM hardware emulator, PC clones, etc.  You tell us that there are
new great and glorious things in the works...that's great, but we haven't
seen a lot of the past great and glorious things that were promised yet.
There's still no national advertising and by reading between the lines in
Sam's post (i.e. dram shortage will continue until 1st part of next year),
there won't be any national advertising this year.  In three years there
has been no upgrades to the o/s (the Mega roms don't count...if it hadn't
been for the blitter chip, they would have never came out.  And 97% of the
people can't get them anyway).  Yes, I know about the new roms (and I've
got a current version)....but there's no upgrade to them.  Atari simply
fixed some bugs that should have been fixed 2 years ago and made some
cosmetic changes (a item selector like CFJ's, show the program/folder 
names during file transfer, etc.).  But nothing major....no support for a
68020, no support for 32-meg partitions, etc.

        Neil, the average Atari owner feels like the proverbial mushroom,
(kept in the dark and covered with manure), so there is a reason that we
get 'antsy' at times.  Every once in a while we get a pat on the head
to pacify us, but nothing substantial (still no blitter for the ST's).

    I hope this post wasn't a diatribe.  I've tried to be calm and
rational....giving you my reasons for why I say what I do.  I'm on tons of
local BBS's across the country (I'm a BBS addict) and a LARGE percentage 
of ST owners feel even more strongly than I do. It's up to Atari to open 
up and calm it's users, not me.  We need more open communications between
Atari and the user base.  The "We can't talk about that yet" gets old 
after 6-8 months.  We never hear or have any open communication with 
Atari, so it's no wonder that we start listening to every rumor that 
comes down the pike.

Lloyd E. Pulley, Sr.




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




                           ANTIC PUBLISHING INC.
                              COPYRIGHT 1988
                          REPRINTED BY PERMISSION.




    Professional GEM  by Tim Oren
    Column #2 - Windows, part 2


    EXCELSIOR!

       In  this  installment,  we continue the exploration of GEM's window
    manager  by  finding  out  how  to process the messages received by an
    application when it has a window defined on the screen.

       Also,  beginning  with this column, sample C code demonstrating the
    techniques discussed will be available on SIG*ATARI in DL5.  This will
    allow  you  to  download  the  code  without  interference  by the CIS
    text-formatter  used by ANTIC ONLINE output.  The file for this column
    is  GEMCL2.XMO.   All  references  to  non-GEM routines in this column
    refer  to  this  file.   Please note that these files will not contain
    entire  programs.   Instead,  they  consist of small pieces of utility
    code which you may copy and modify in your own programs.


    REDRAWING WINDOWS

       One  of  the  most misunderstood parts of GEM is the correct method
    for  drawing  within  a  window.   Most  requests  for  redrawing  are
    generated  by  the  GEM  system,  and  arrive  as  messages (read with
    evnt_multi)  which  contain  the  handle of the window, and the screen
    rectangle  which  is "dirty" and needs to be redrawn. Screen areas may
    become  dirty  as  a  result  of  windows being closed, sized down, or
    moved,  thus  "exposing"  an  area  underneath.   The  completion of a
    dialog,  or closing of a desk accessory may also free up a screen area
    which  needs  to be redrawn.  When GEM detects the presence of a dirty
    rectangle,  it  checks  its  list  of  open  windows,  and  sends  the
    application  a redraw message for each of its windows which intersects
    the dirty area.


    CAVEAT EMPTOR

       GEM   does   not  "clip"  the  rectangle  which  it  sends  to  the
    application;  that  is,  the rectangle may not lie entirely within the
    portion  of  the window which is exposed on the screen.  It is the job
    of  the  application  to determine in what portion of the rectangle it
    may  safely  draw.   This  is  done  by examining the "rectangle list"
    associated  with the window. A rectangle list is maintained by GEM for
    each active window.  It contains the portions of the window's interior
    which  are  exposed, i.e., topmost, on the screen and within which the
    app may draw.

       Let's  consider  an example to make this clear.  Suppose an app has
    opened  two windows, and there are no desk accessory windows open. The
    window  which  is  topmost  will always have only one rectangle in its
    list.   If  the two are separate on the screen, then the second window
    will  also  have  one rectangle.  If they overlap, then the top window
    will  "break" the rectangle of the bottom one.  If the overlap is at a
    corner,  two  rectangles  will be generated for the bottom window.  If
    the  overlap  is on a side only, then three rectangles are required to
    cover the exposed portion of the bottom window.  Finally, if the first
    window  is  entirely within the second, it requires four rectangles in
    the list to tile the second window.

       Try  working  out a few rectangle examples with pencil and paper to
    get  the feel of it.  You will see that the possible combinations with
    more  than  two windows are enormous.  This, by the way, is the reason
    that  GEM  does  not send one message for each rectangle on the list:
    with  multiple windows, the number of messages generated would quickly
    fill up the application's message queue.

       Finally,  note that every app MUST use this method, even if it only
    uses a single window, because there may be desk accessories with their
    own  windows  in  the  system at the same time.  If you do not use the
    rectangle lists, you may overwrite an accessory's window.


    INTO THE BITS

       First, we should note that the message type for a redraw request is
    WM_REDRAW,  which  is  stored  in  msg[0],  the  first location of the
    message  returned  by  evnt_multi.   The  window  handle  is stored in
    msg[3].   These  locations  are  the same for all of the message types
    being  discuss.   The rectangle which needs to be redrawn is stored in
    msg[4] through msg[7].

       Now let's examine the sample redraw code in more detail. The redraw
    loop is bracketed with mouse off and mouse on calls.  If you forget to
    do  this,  the  mouse pointer will be over-written if it is within the
    window  and  the  next  movement of the mouse will leave a rectangular
    blotch  on  the  screen  as a piece of the "old" screen is incorrectly
    restored.

       The  other  necessary  step is to set the window update flag.  This
    prevents  the  menu  manager from dropping a menu on top of the screen
    portion  being  redrawn.  You must release this flag at the end of the
    redraw, or the you will be unable to use any menus afterwards.

       The  window  rectangles  are  retrieved using a get-first, get-next
    scheme  which  will be familiar if you have used the GEM DOS or PC-DOS
    wildcard  file  calls.  The end of the rectangle list has been reached
    when  both the width and height returned are zero.  Since some part of
    a  window  might be off-screen (unless you have clamped its position -
    see  below), the retrieved rectangle is intersected with the desktop's
    area, and then with the screen area for which a redraw was requested.

       Now you have the particular area of the screen in which it is legal
    to  draw.   Unless  there  is only one window in your application, you
    will  have to test the handle in the redraw request to figure out what
    to  put in the rectangle.  Depending on the app, you may be drawing an
    AES  object  tree,  or executing VDI calls, or some combination of the
    two.   In  the AES case, the computed rectangle is used to specify the
    bounds  of  the objc_draw.  For VDI work, the rectangle is used to set
    the clipping area before executing the VDI calls.


    A SMALL CONFESSION

       At  the  beginning  of  this discussion, I deliberately omitted one
    class  of redraws: those initiated by the application itself.  In some
    cases  a  part  of  the  screen  must  be  redrawn immediately to give
    feedback  to  the user following a keystroke, button, or mouse action.
    In these cases, the application could call do_redraw directly, without
    waiting  for  a  message.  The only time you can bypass do_redraw, and
    draw  without walking the rectangle list, is when you can be sure that
    the  target  window  is  on  top,  and  that the figure being drawn is
    entirely contained within it.

       In  many  cases,  however,  an application initiated redraw happens
    because  of a computed change, for instance, a spreadsheet update, and
    its timing is not crucial.  In this instance, you may wish to have the
    app send ITSELF a redraw request.

       The main advantage of this approach is that the AES is smart enough
    to see if there is already a redraw request for the same window in the
    queue,  and,  if  so,  to merge the requests by doing a union of their
    rectangles.   In  this  fashion,  the  "blinky" appearance of multiple
    redraws  is  avoided,  without  the  need to include logic for merging
    redraws within the program.

       A  utility routine for sending the "self-redraw" is included in the
    down-load for this article.


    WINDOW CONTROL REQUESTS

       An application is notified by the AES, via the message system, when
    the  user manipulates one of the window control points.  Remember that
    you  must  have  specified  each  control  point  when  the window was
    created, or will not receive the associated control message.

       The most important thing to understand about window control is that
    the  change  which  the  user  requested does not take place until the
    application  forwards  it  to  the AES.  While this makes for a little
    extra work, it gives the program a chance to intervene and validate or
    modify the request to suit.

       A second thing to keep in mind is that not all window updates cause
    a  redraw  request  to  be  generated  for the window, because the AES
    attempts to save time with raster moves on the screen.

       Now  let's  look  at  each  window  control request in detail.  The
    message  code  for  a  window move is WM_MOVED.  If you are willing to
    accept any such request, just do:

        wind_set(wh, WF_CXYWH, msg[4], msg[5], msg[6], msg[7]);

    (Remember that wh, the window handle, is always in msg[3]).

       The  AES  will  not  request  a redraw of the window following this
    call,  unless  the  window  is  being  moved  from a location which is
    partially  "off-screen". Instead, it will do a "blit" (raster copy) of
    the  window  and its contents to the new location without intervention
    by the app.

       There  are two constraints which you may often wish to apply to the
    user's  move  request.   The first is to force the new location to lie
    entirely  within  the  desktop, rather than partially off-screen.  You
    can do this with the rc_constrain utility by executing:

        rc_constrain(&full, &msg[4]);

    before  making  the  wind_set  call.   (Full is assumed to contain the
    desktop dimensions.)

       The  second common constraint is to "snap" the x-dimension location
    of  the new location to a word boundary.  This operation will speed up
    GEM's  "blit" because no shifting or masking will need to be done when
    moving  the window.  To perform this operation, use align() before the
    wind_set call:

        msg[4] = align(msg[4], 16);

    The message code for a window size request is WM_SIZED.  Again, if you
    are  willing to accept any request, you can just "turn it around" with
    the same wind_set call as given for WM_MOVED.

       Actually,  GEM  enforces a couple of constraints on sizing.  First,
    the  window  may  not be sized off screen.  Second, there is a minimum
    window size which is dependent on the window components specified when
    it  was created.  This prevents features like scroll arrows from being
    squeezed into oblivion.

       The  most  common  application  constraint on sizing is to snap the
    size  to  horizontal words (as above) and/or vertical character lines.
    In  the latter case, the vertical dimension of the output font is used
    with align().

       Also,  be  aware  that the size message which you receive specifies
    the  EXTERNAL  dimensions of the window.  To assure an "even" size for
    the  INTERNAL  dimensions,  you  must make a wind_calc call to compute
    them,  use  align() on the computed values, back out the corresponding
    external  dimensions  with  the  reverse  wind_calc, and then make the
    wind_set call with this set of values.

       A  window resize will only cause a redraw request for the window if
    the  size  is  being  increased  in  at  least one dimension.  This is
    satisfactory  for  most  applications, but if you must "reshuffle" the
    window  after  a  size-down,  you  should  send  yourself a redraw (as
    described  above)  after  you  make  the  wind_set  call.   This  will
    guarantee  that  the display is updated correctly.  Also note that the
    sizing  or  movement  of  one  window  may cause redraw requests to be
    generated for other windows which are uncovered by the change.

       The window full request, with code WM_FULLED, is actually a toggle.
    If  the  window  is  already  at  its  full  size (as specified in the
    wind_create),  then  this is a request to shrink to its previous size.
    If  the window is currently small, then the request is to grow to full
    size.

       Since  the  AES  records  the current, previous, and maximum window
    size,  you  can  use  wind_get  calls  to  determine  which  situation
    pertains.  The  hndl_full  utility  in  the  down-load  (modified from
    Doodle),  shows  how to do this.  The "zoom box" effects when changing
    size  are  optional, and can be removed to speed things up.  Again, if
    the  window's  size is decreasing, no redraw is generated, so you must
    send  yourself  one  if necessary.  You should not have to perform any
    constraint  or "snap" operations here, since (presumably) the full and
    previous sizes have had these checks applied to them already.

       The  WM_CLOSED  message  is received when the close box is clicked.
    What  action  you  perform depends on the application.  If you want to
    remove the window, use wind_close as described in the last column.  In
    many applications, however, the close message may indicate that a file
    is  to  be saved, or a directory or editing level is to be closed.  In
    these  cases,  the  message  is  used to trigger this action before or
    instead  of the wind_close.  (Folders on the Desktop are an example of
    this situation.)

       The  WM_TOPPED  message  indicates  that the AES wants to bring the
    indicated window to the "top" and make it active.  This happens if the
    user  clicks  within a window which is not on top, or if the currently
    topped  window  is  closed  by  its  application  or  desk accessory.
    Normally, the application should respond to this message with:

        wind_set(wh, WF_TOP, 0, 0);

    and allow the process to complete.

       In  a  few  instances, a window may be used in an output only mode,
    such  as  a status display, with at least one other window present for
    input.  In this case, a WM_TOPPED message for the status window may be
    ignored.   In  all  other cases, you must handle the WM_TOPPED message
    even  if  your  application  has only one window: Invocation of a desk
    accessory could always place another window on top.  If you fail to do
    so,   subsequent   redraws  for  your  window  may  not  be  processed
    correctly.


    WINDOW SLIDER MESSAGES

       If you specify all of the slider bar parts for your window, you may
    receive up to five different message types for each of the two sets of
    sliders.   To  simplify  things a little, I will discuss everything in
    terms  of  the  vertical  (right  hand side) sliders.  If you are also
    using  the horizontal sliders, the same techniques will work, just use
    the alternate mnemonics.

       The WM_VSLID message indicates that the user has dragged the slider
    bar  within  its  box,  indicating  a new relative position within the
    document.   Along  with  the  window handle, this message includes the
    relative position between 1 and 1000 in msg[4].

       Recall from last column's discussion that this interval corresponds
    to  the "freedom of movement" of the slider. If you want to accept the
    user's request, just make the call:

        wind_set(wh, WF_VSLIDE, msg[4], 0, 0, 0);

    (Corresponding horizontal mnemonics are WM_HSLID and WF_HSLIDE).

       Note  that this wind_set call will not cause a redraw message to be
    sent.   You  must  update  the  display  to  reflect  the new scrolled
    position,  either  by  executing  a  redraw  directly,  or  by sending
    yourself  a  message.   If  the  document  within  the window has some
    structure,  you  may not wish to accept all slider positions.  Instead
    you  may  want  to  force the scroll position to the nearest text line
    (for  instance).   Using  terms  defined  in  the last column, you may
    convert the slider position to "document units" with:

        top_wind = msg[4] * (total_doc - seen_doc) / 1000 + top_doc

    (This will probably require 32-bit arithmetic).  After rounding off or
    otherwise  modifying  the request, convert it back to slider units and
    make the WF_VSLIDE request.

       The  other  four  slider  requests  all  share  one  message  code:
    WM_ARROWED.   They  are  distinguished  by sub-codes stored in msg[4]:
    WA_UPPAGE, WA_DNPAGE, WA_UPLINE, and WA_DNLINE.  These are produced by
    clicking  above  and  below the slider, and on the up and down arrows,
    respectively.   (I  have  no  idea why sub-codes were used in this one
    instance.)   The corresponding horizontal slider codes are: WA_LFPAGE,
    WA_RTPAGE, WA_LFLINE, and WA_RTLINE.

       What  interpretation  you give to these requests will depend on the
    application.   In  the  most  common  instance,  text  documents,  the
    customary method is to change the top of window position (top_wind) by
    one  line for a WA_UPLINE or WA_DNLINE, and by seen_doc (the number of
    lines in the window) for a WA_UPPAGE or WA_DNPAGE.

       After  making  the  change, compute a new slider position, and make
    the  wind_set call as given above.  If the document's length is not an
    even  multiple  of "lines" or "pages" you will have to be careful that
    incrementing  or  decrementing  top_wind  does not exceed its range of
    freedom:  top_doc  to  (top_doc  + total_doc - seen_doc).  If you have
    such  an  odd  size document, you will also have to make a decision on
    whether to violate the line positioning rule so that the slider may be
    put  at  its  bottom-most  position, or to follow the rule but make it
    impossible to get the slider to the extreme of its range.


    A COMMON BUG

       It  is easy to forget that user clicks are not the only things that
    affect  slider  position.  If the window size changes as a result of a
    WM_SIZED  or  WM_FULLED  message, the app must also update its sliders
    (if  they  are  present).   This  is  a good reason to keep the top of
    window information in "document units".

       You  can just redo the position calculation with the new "seen_doc"
    value, and call wind_set.  Also remember that changing the size of the
    underlying  document  (adding or deleting a bottom line, for instance)
    must also cause the sliders to be adjusted.


    DEPT. OF DIRTY TRICKS

       There  are  two remaining window calls which are useful to advanced
    programmers.   They require techniques which I have not yet discussed,
    so you may need to file them for future reference.

       The  AES  maintains  a quarter-screen sized buffer which is used to
    save  the  area  under alerts and menu drop-downs.  It is occasionally
    useful  for  the application to gain access to this buffer for its own
    use in saving screen areas with raster copies.  To do so, use:

        wind_get(0, WF_SCREEN, &loaddr, &hiaddr, &lolen, &hilen);

    Hiaddr and loaddr are the top and bottom 16-bits (respectively) of the
    32-bit  address  of the buffer.  Hilen and lolen are the two halves of
    its  length.   Due  to  a  preculiarity  of  the  binding  you have to
    reassemble  these  pieces  before  using  them.   (The actual value of
    WF_SCREEN  is  17;  this  does  not  appear  in  some  versions of the
    GEMDEFS.H file.)

       If  you  use this buffer, you MUST prevent menus from dropping down
    by  using  either  the  BEG_UPDATE  or  BEG_MCTRL  wind_update calls.
    Failure  to  do so will result in your data being destroyed.  Remember
    to use the matching wind_update: END_UPDATE or END_MCTRL, when you are
    done.

       The  other  useful call enables you to replace the system's desktop
    definition with a resource of your choosing.  The call:

        wind_set(0,WF_NEWDESK, tree, 0,0);

    where  tree  is  the 32-bit address of the object tree, will cause the
    AES  to  draw  your  definition  instead  of  the  usual gray or green
    background.  Not  only that, it will continue to redraw this tree with
    no  intervention  on your part.  Obviously, the new definition must be
    carefully  built  to  fit  the desktop area exactly or garbage will be
    left  around  the  edges.  For the truly sophisticated, a user-defined
    object  could  be  used  in  this  tree,  with  the  result  that your
    application's  code would be entered from the AES whenever the desktop
    was  redrawn.   This  would  allow  you to put VDI pictures or complex
    images onto the desktop background.


    A SIN OF OMISSION

       In  the  last  column,  I  neglected  to mention that strings whose
    addresses are passed in the WF_NAME and WF_INFO wind_set calls must be
    allocated  in  a  static  data  area.   Since  the  AES  remembers the
    addresses  (not  the characters), a disaster may result if the storage
    has  been  reused  when  the  window manager next attempts to draw the
    window title area.


    COMING SOON...

       This   concludes   our   tour  of  GEM's  basic  window  management
    techniques. There have been some unavoidable glimpses of paths not yet
    taken (forward references), but we will return in time.

       On  our  next  excursion,  we  will  take  a look at techniques for
    handling  simple  dialog  boxes,  and start exploring the mysteries of
    resources and object trees.




>>>>>>>>>>>>>>>>>>>>>>>>>>   Sample  Redraw  Code 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<


     VOID
do_redraw(wh, area)          /* wh = window handle from msg[3] */
     WORD     wh;          /* area = pointer to redraw rect- */
     GRECT     *area;          /*   tangle in msg[4] thru msg[7] */
     {
     GRECT     box;

     graf_mouse(M_OFF, 0x0L);
     wind_update(BEG_UPDATE);

     wind_get(wh, WF_FIRSTXYWH, &box.g_x, &box.g_y, &box.g_w, &box.g_h);
     while ( box.g_w && box.g_h )
          {
          if (rc_intersect(full, &box))       /* Full is entire screen */
          if (rc_intersect(area, &box))
               {
               if (wh == w1_handle)       /* Test for window 1 handle */
                    {            /* AES redraw example           */
                    objc_draw(w1_tree, ROOT, MAX_DEPTH, box.g_x,
                         box.g_y, box.g_w, box.g_h);
                    }
               else if (wh == w2_handle) /* Test for window 2 handle */
                    {            /* VDI redraw example           */
                    set_clip(TRUE, &box);
                    /*  Put VDI drawing calls here */
                    }
               /* add more windows here */
               }
          wind_get(wh, WF_NEXTXYWH, &box.g_x, &box.g_y, &box.g_w,
               &box.g_h);
          }

     wind_update(END_UPDATE);
     graf_mouse(M_ON, 0x0L);
     }


>>>>>>>>>>>>>>>>>>>>>>>>> Utilities used in do_redraw
<<<<<<<<<<<<<<<<<<<<<<<

     VOID
set_clip(clip_flag, area)     /* set clip to specified area     */
     WORD     clip_flag;
     GRECT     *area;
     {
     WORD     pxy[4];

     grect_to_array(area, pxy);
     vs_clip(vdi_handle, clip_flag, pxy);
     }

     VOID
grect_to_array(area, array)     /* convert x,y,w,h to upr lt x,y and    
*/
     GRECT     *area;          /*                lwr rt x,y     */
     WORD     *array;
     {
     *array++ = area->g_x;
     *array++ = area->g_y;
     *array++ = area->g_x + area->g_w - 1;
     *array = area->g_y + area->g_h - 1;
     }

     WORD
rc_intersect(p1, p2)          /* compute intersect of two rectangles    
*/
     GRECT     *p1, *p2;
     {
     WORD     tx, ty, tw, th;

     tw = min(p2->g_x + p2->g_w, p1->g_x + p1->g_w);
     th = min(p2->g_y + p2->g_h, p1->g_y + p1->g_h);
     tx = max(p2->g_x, p1->g_x);
     ty = max(p2->g_y, p1->g_y);
     p2->g_x = tx;
     p2->g_y = ty;
     p2->g_w = tw - tx;
     p2->g_h = th - ty;
     return( (tw > tx) && (th > ty) );
     }


>>>>>>>>>>>>>>>>>>>>>>>>> "Self-redraw" Utility
<<<<<<<<<<<<<<<<<<<<<<<<<<<

     VOID
send_redraw(wh, p)
     WORD     wh;
     GRECT     *p;
     {
     WORD     msg[8];

     msg[0] = WM_REDRAW;          /* Defined in GEMBIND.H         */
     msg[1] = gl_apid;          /* As returned by appl_init */
     msg[2] = 0;
     msg[3] = wh;               /* Handle of window to redraw */
     msg[4] = p->g_x;
     msg[5] = p->g_y;
     msg[6] = p->g_w;
     msg[7] = p->g_h;
     appl_write(gl_apid, 16, &msg);     /* Use ADDR(msg) for portability
*/
     }


>>>>>>>>>>>>>>>>>>>>>> Utilities for Window Requests <<<<<<<<<<<<<<<<<<<<

     VOID
rc_constrain(pc, pt)
     GRECT          *pc;
     GRECT          *pt;
     {
     if (pt->g_x < pc->g_x)
          pt->g_x = pc->g_x;
     if (pt->g_y < pc->g_y)
          pt->g_y = pc->g_y;
     if ((pt->g_x + pt->g_w) > (pc->g_x + pc->g_w))
          pt->g_x = (pc->g_x + pc->g_w) - pt->g_w;
     if ((pt->g_y + pt->g_h) > (pc->g_y + pc->g_h))
          pt->g_y = (pc->g_y + pc->g_h) - pt->g_h;
     }

     WORD
align(x,n)          /* Snap position x to an n-bit grid         */
     WORD      x, n;   /* Use n = 16 for horizontal word alignment */
     {
     x += (n >> 2) - 1;          /* Round and... */
     x = n * (x / n);          /* remove residue */
     return (x);
     }


>>>>>>>>>>>>>>>>>>>>>>>>> Window full utility <<<<<<<<<<<<<<<<<<<<<<<<<<

     VOID
hndl_full(wh)          /* depending on current window state, make window  
 */
     WORD     wh;     /*   full size -or- return to previous shrunken size
*/
     {          /* graf_ calls are optional special effects.          */
     GRECT     prev;
     GRECT     curr;
     GRECT     full;

     wind_get(wh, WF_CXYWH, &curr.g_x, &curr.g_y, &curr.g_w, &curr.g_h);
     wind_get(wh, WF_PXYWH, &prev.g_x, &prev.g_y, &prev.g_w, &prev.g_h);
     wind_get(wh, WF_FXYWH, &full.g_x, &full.g_y, &full.g_w, &full.g_h);
     if ( rc_equal(&curr, &full) )
          {          /* Is full, change to previous           */
          graf_shrinkbox(prev.g_x, prev.g_y, prev.g_w, prev.g_h,
               full.g_x, full.g_y, full.g_w, full.g_h);
          wind_set(wh, WF_CXYWH, prev.g_x, prev.g_y, prev.g_w, prev.g_h);
                    /* put send_redraw here if you need it */
          }
     else
          {          /* is not full, so set to full          */
          graf_growbox(curr.g_x, curr.g_y, curr.g_w, curr.g_h,
               full.g_x, full.g_y, full.g_w, full.g_h);
          wind_set(wh, WF_CXYWH, full.g_x, full.g_y, full.g_w, full.g_h);
          }
     }

     WORD
rc_equal(p1, p2)          /* tests for two rectangles equal     */
     GRECT     *p1, *p2;
     {
     if ((p1->g_x != p2->g_x) ||
         (p1->g_y != p2->g_y) ||
         (p1->g_w != p2->g_w) ||
         (p1->g_h != p2->g_h))
          return(FALSE);
     return(TRUE);
     }

Next Week, #3 in the ongoing series...........

                           ANTIC PUBLISHING INC.
                              COPYRIGHT 1988
                          REPRINTED BY PERMISSION.




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




                            GOOD TIMES AHEAD?
                            =================

by T."Rex Reade

Here I sit, staring at the equipment before me saying to myself, "Self,
why do you carry on with the folks at Atari like you do and when are you
going to realize that those who give the most rediculous answers and 
replies are the lowest on the totem pole?  Well, today I answered that 
question and by golly, I realized that the TOP BRASS at Atari want the 
same things I do!  It's the turkeys that are making all the problems in 
the rumor mill and hard feelings department. Therefore, from now on, Self
is going to fly with the Eagles and let the turkeys roast themselves.
Also, a concentration on the positive aspects of Atari will prevail if at
all possible. 

An important point to make is Atari has a super good concept in the ST
computer line and a very weak approach to national marketing.  It
has been said by a few that I favor the mail order houses...in a way I do
and my reason is very simple...there are some dealers who relish charging
LIST PRICE for the Atari products....at least mail order stopped the
gouge...I know of one dealer who is charging 500.00+ for the older (used)
SC1224...he tells folks that the newer monitors are junk compared to the
older models..(He offers the new stylish monitor for 100.00 as long as the
older one has the box and booklets in his trade-in upgrade deal..cute???) 
This appears sleezy and detremental to Atari's good name!  Others are 
very busy trying to market multi-sync monitors which is ok as it stands..
but when a "dealer" tries to tell folks it is as good as the SC1224...that
dealer needs a "slap!"  The SC1224 is a fine RGB monitor and will 
outperform 99% of what is out there in it's class.  We all know 
the multi-sync is a nice space saver but, it's a compromise on quality in
"certain areas" like text in medium resolution....it is not even close to
the quality of the SC1224.  The "pin cushion" effect on the multisync was
more than evident, the SC1224 was just dandy.

When the dealers resort to wholesale snake oil sales it is time to rethink
the entire program and we believe that is just what Atari is doing....the
area representatives do not, as a whole, keep their appointments.  The
exisiting dealers feel neglected thus, they carry on with the attitude
that Atari doesn't care about them, so...let's milk it for all it's
worth.  The Federated thingy that Neil is trying to polish and groom may
just be the answer!  Company stores through out the Nation, centralized
service centers with pick up and delivery to company stores in that hub, 
an outside sales force dedicated to commercial sales and application.  

Folks, I do not think this is a pipe dream, this IS coming down the road.
It has to, in order to save the userbase we have and build upon it. There
are some very FINE dealers out there who will become a part of the Atari 
chain of stores and this is good....the time has come for sure, to 
eliminate the charletans and snake oil merchants from the ranks of good 
dealers representing Atari.

One of the really nice things about encouraging folks to send in their
experiences with dealers (good or bad) is the diversification of opinions
we receive.  Without risking real outcry, it is safe to say, Atari is on
the right track in trying to establish a national chain as long as the
GOOD dealers are assured of being treated equally and on the same footing
as the "company stores".  Neil Harris may be many things, but one he will
do is try his best to make sure the independents (deserving) get a fair
shake throughout the entire big picture.


When we hear about bashing and the gang of five and all the other colorful
non-sense, we think of hard feelings and emotion.  There is no reason for
any of this!  If one were to really step back and take a long hard look at
what the majority of the bashers have been doing, it's simple!  Pointing
out the shortfall and using any means to obtain the attention of those at
Atari who are in a position to bring about change and improvement.  As we
know there are always those who, in their BLIND faith and hero worship,
will defend any premise brought forward by an outspoken person or by an
individual who may disagree with one or more critics.  Seemingly, these 
are the folks who have unwittingly perpetuated the SILLY arguments.  The
Time has come TO ALLOW ATARI the opportunity to SHOW ALL OF US their
stuff.  Comdex is right around the corner, the new ROMs are due for
release (hopefully they read more than 16mb per partition), and they did
say we would be proud of the advertising this year....remember the CO
during the SPRING COMDEX?  WE......shall see.  In any case, the time is at
hand to demonstrate to all that our support for Atari has not waivered.
Nor has any of our faith in JACK TRAMIEL been eroded.


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




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




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

Sunnyvale CA       Our favorite company may be headed for a very nice
------------       bonus..Seems the folks at Federated "lost" 43 million
                   somewhere in the offering...penalties could double the
                   amount for Atari.

NYC  NY            The "Mega4 Deal" is over and now the Mega 2 deal is 
-------            here!  After Labor Day, Dealers will be offering
                   the Mega2 at a very good price....less than 1395.00...
                   certain dealers wanted this kept hush-hush..another 
                   reason why the ads are so very neccessary.

Norcross GA.       Hayes Micro, has been inundated with a super positive
------------       response for its special Sysops modem discount offer. 
                   Delivery time is hovering around three to eight weeks.

Jacksonville FL.   ABCO Hard Disks announced the new 130mb Hard Drive
---------------    System is highly successful and like it's predecessors
                   it is fully upgradable. 

Sunnyvale CA       The New TOS in ROM chips are expected to be shipping
------------       and in good supply....it's nice to see Atari "ON TIME!"



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




Latest ST Xformer News 
=======================

                             File Transfer Service
                             ---------------------
               Using the ST with Atari 810 and 1050 disk drives!!
               --------------------------------------------------

by Darek Mihocka

Users of the ST Xformer II emulator are familiar with methods of
transfering 8 bit software to the ST. Using modems, null modem
cables, and 5 1/4" ST drives (with the Xformer File Xfer Program),
it is possible to transfer over files and most boot disks for
use with the emulator.

I am pleased to announce the development of an interface for the
ST, that allows 8 bit peripherals like the 810, 1050 and XF551 disk
drives to connect directly to the 520/1040/Mega ST. Other devices,
like the 850 interface, modems, and printers can also be connected.
Everything just plugs in, so no warranties have to be voided.

Using a new version of ST Xformer II not yet released, it is
possible to boot directly from these drives, thus allowing copy-
protected commercial software to run under the emulator, and
eliminating the hassles of the other methods. Now run Text Wizard,
B/Graph, Visicalc, APX and Antic disks and many more. This opens
new doors to the world of 8 bit emulation. Also, the new
Xformer II runs on 512K, something the regular Xformer II can't do.

But that's not all! Users of the ST who are not particularly
interested in emulation because they still parts of an 8 bit
system will also find this useful. This interface allows for file
transfers between the 8 bit drives and the 3 1/2" drives, thus allowing
easy movement of files back and forth without the need of null modem
cables or the 850 interface.

So if you have a 520ST with a single disk drive, and were considering
buying another drive, consider getting the less expensive 1050 or
XF551 drives instead of an ST drive.

Users who do not own an 8 bit disk drive, but who can still borrow
one for a few days and get their hands on their user group's 8 bit
library of disks, will be able to copy them to the ST in as little
time as it takes to copy the disks normally.

Although I do not plan to develop this feature unless there is
specific demand, it is possible to reverse roles and allow the
Atari 400/800 computers to access the ST as a virtual disk drive,
thus allowing, for example, a BBS running on an Atari 800 to access
a 520ST as a large RAMdisk.

I will produce the interface, and sell it for about $20 to $30.
One of the reasons that kept me from developing this earlier is
that I originally wanted the emulator to remain software-only.
It will remain this way for users without access to 8 bit peripherals,
but for those users who have access to both systems, this is a
low cost add-on to increase their enjoyment of their ST.

At this time, I am unable to predict how long it will take make this
available to all ST users. Hopefully only a few months. Right now the
biggest stumbling block is finding those 13 pin 8 bit serial I/O
connectors, which seem to be very scarce. Dealers and distributors
interested in carrying this product should contact me by voice.

Anyone interested in buying one, please phone or write, so that I
will know how many interfaces to initially produce.


File transfer service
---------------------

Any Xformer users who are finding it difficult to port software over,
either due to a lack of a modem or null modem cable, should phone me
about arranging to send me their disks to copy over to the 3 1/2"
format. With my prototype interface, I can copy hundreds of disks a
day, and all I require is that you pay for the postage and disks.

I would be especially interested in obtaining a large database of
public domain 8 bit software (a user group library?).


Other Xformer news
------------------

Other improvements are being made to the Xformer. I am working
out the details of the full speed emulator, which is now on the
horizon. However, I fell that I will prevent me from devoting further
time to the Apple and C64 emulators, which have been pretty neglected
so far, so I will be making the entire source code to ST Xformer II
available. It is written in Laser C, so only Laser C users will be able
modify it unless they convert it to another language first. Any
developers interested in further improving the Apple and Commodore
emulators will then be able to do so.

Sometime later in September, I will be putting up the Xformer support
BBS, to allow modem users without access to Compuserve, Delphi, or
Genie to call and download the latest emulator and 8 bit files. The
number will be the same as the current voice number, and operate from
around midnight to 6am EST/EDT.

Finally, if you are a user of ST Xformer II and have not yet registered
your copy, please do so by sending your name, mailing address, phone,
and a $20 money order. You will receive a manual and an updated version
of the software and 8 bit files. Please indicate whether you want the
regular double sided version of Xformer II, or the 512K single sided
version of Xformer Junior.


The address is: 
                            Darek Mihocka
                        310-D Bluevale St. N.
                      Waterloo, Ontario  N2J 4G3
                               CANADA

In the US, remember that postage for Canada is about 5 cents more.

The Xformer hotline, voice, and soon by modem, is (519)-747-0386.


Other sources of ST Xformer 2.10:
---------------------------------
    Compuserve - go to the ATARIDEV SIG and enter DL 5 (the Xformer
    ----------   download library)

    Delphi - go the ST LOG SIG by typing "gr st" at the main menu.
    ------   Enter the libraries with the "da" command.

    Genie - go to the Atari ST roundtable by typing "m 475;3" and
    -----   download files #7651 thru #7654.

             and, various ST bulletin boards across the country.



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



THIS WEEK'S QUOTE:
==================


         "A PAT ON THE BACK IS ONLY A FOOT FROM A KICK IN THE BUTT!"



-------------------------------------------------------------------------
ST-REPORT Issue #51   SEPT. 5, 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.
-------------------------------------------------------------------------
