Copy Link
Add to Bookmark
Report
Silicon Times Report Issue 0051
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.
-------------------------------------------------------------------------
