Copy Link
Add to Bookmark
Report
Silicon Times Report Issue 0065
==========================================================================
*---=== ST REPORT WEEKLY ONLINE MAGAZINE ===---*
"The Original Online ST Magazine"
-------------------------------
December 12, 1988 Monday Volume II No.65
==========================================================================
ST Report Online Magazine
------------------------------
Post Office Box 6672
Jacksonville, Florida
32236 6672
R.F. Mariano
Publisher - Editor
_________________________________________
Headquarters Bulletin Boards
----------------------------
North South
201-247-8252 904-786-4176
Central West
216-784-0574 916-962-2566
--------------------------------------------------------------------------
Highlights
==========
~ From the Editor's Desk.............~ Spectre and Discovery.........
~ Living in Atari World..............~ NEW on GEnie..................
~ Pro GEM Windows #16................~ ST REPORT CONFIDENTIAL........
and....much more!
========================================================================
AVAILABLE ON: COMP-U-SERVE ~ DELPHI ~ GENIE ~ THE SOURCE
========================================================================
From the Editor's Desk:
-----------------------
"What???? My St is going to be a GAME MACHINE? The nerve!" Have any
of you heard this remark or ones similar to it? Seems a little foolish to
me to hear folks who know and love their ST to say such pompous tripe.
Think over what I just said before you go off on a tirade about this.
Don't you think that Atari is entitled to make a handsome PROFIT on
the fruits of it's labors? Consider that fact that when they had the
multi-million dollar market of game machines all to themselves we at least
knew they would come out with something new REGULARLY. Now, we don't know
what is coming next, (mainly because they don't), realistically speaking,
I hope they blow all the home video game companies right out of the water
with the STGS (ST Game System). That'll provide the cushion of funds
needed to get Federated running properly and for the needed R&D for the
ST computer market.
Federated Stores could very easily become a very strong factor in
the resurgence of Atari US. Give this some serious thought, we have been
told the major reason Atari bailed out of the mail order scheme of things
was because they had no control over the pricing. For example, a dealer
in N.J. is selling a 1040 ST color system for list price or even 10% off
list. The average consumer in the USA is accustomed to receiving the
benefit of a discount and it usually is a GOOD discount. What Atari has
done is open the flood gates of GOUGE by removing the stabilizing factor
on prices the mail order houses provided.
We propose this, use the facilities of the Federated Stores for a
National Mail Order Operation, build in a discount that takes into
consideration that there is no heavy after purchase support. Allow a
better than 90 day warranty on the high end items. By using the Federated
Chain as your mail order outlets you will [a] have a strong control on
pricing of ALL Atari products (both mail order and Dealer retail levels)
thus eliminating the rip off now taking place. [b] Have an avenue of supply
to those areas in the country that are not serviced by a conveniently
located dealer. [c] Atari will, in effect, have a more direct and
positive relationship with the customer base it is attempting to build.
In the coming months we hope to see some of the wrongs so strongly
in evidence be corrected. Atari.. IS our computer by CHOICE.
Ralph.....
PLEASE, Don't drink and Drive....
*************************************************************************
IMPORTANT NOTICE!
-----------------
As a reader of ST Report Magazine, you are entitled to take advantage of
a special DELPHI membership offer. For only $29.95 ($20 off the standard
membership price!), you will receive a lifetime subscription to DELPHI, a
copy of the 500-page "DELPHI: The Official Guide," and a credit equal to
one free evening hour at standard connect rates.
Signing up with DELPHI
----------------------
Using a personal computer and modem, members worldwide access DELPHI
services via a local phone call.
Join--- DELPHI
--------------
1. Dial 617-576-0862 with any terminal or PC and modem (at 2400 bps, dial
576-2981).
2. At the Username prompt, type JOINDELPHI.
3. At the Password prompt enter STREPORT.
For more information, call DELPHI Member Services at 1-800-544-4005, or
at 617-491-3393 from within Massachusetts or from outside the U.S.
DELPHI is a service of General Videotex Corporation of Cambridge,
Massachusetts.
**************************************************************************
SPECTRE and DISCOVERY
=====================
by R.F. Mariano
Almost all items provided for mankind's convenience and use have a
downside, if we are to look for only the 'downside' these items will
indeed appear to be detrimental. I read all the strings and found a great
many injustices on both sides of the issue and statements made by folks
who were, by the way they said things, one sided and unfair. I propose
that the Discovery Cart be used in conjunction with the Spectre Cart and
that both manufacturers come to terms on that point and agree. We cannot
and will not condone 'bootlegging' ROM chips or any other illegitimate
practice.
Last week's release from HCP pertaining to Discovery and Spectre
was, in our opinion, inflammatory and suggestive and it could have been
altered or not released at all..but, in the same vein, we saw where the
"groupies" on a certain service saw fit to tear apart the Discovery Cart
with every possible and impossible accusation they could come up with.
To me, and (by the large quantity of mail received) a good many readers
took exception with this unfair display. In fact, that is the major
reason the information was published in the first place to allow the users
to see that NOT ALL avenues of information were caught up in the "Down
with Discovery" nonsense and that we at ST Report have faith in the
userbase to choose right from wrong.. Now, since all this is water under
the bridge, we look to the future and hope the entire picture for Atari
matures and develops into a very strong upward growth pattern as it has in
Europe.
We respectfully request of both David Small and Richard Adams...
"Both of you have provided magnificent products to the ST marketplace.
The shame is, that you two must be bitter with each other. Our only wish
is that the two of you get over your differences and make your products
totally compatible." Actually, the only real victims in this, hopefully
reversible, conflict is the userbase, each and every owner of an ST and
every potential owner...
I followed the directions listed in last week's item and now am able
to use the Discovery Cart and Spectre together, no more do I see myself
wearing out the PCB trace at my cart port on the mega4 by installing
either one or the other cartridge continually. Now, all I need do is
power down, flip a switch and power up. The Discovery Cart is plugged into
the mega4 cart port and my Spectre 128 Cart is inserted into the port on
the Discovery Cart. It works perfectly.
Spectre 128 and Discovery are both very well designed and engineered
products and without the slightest hesitation we highly reccommend BOTH
products to all users who are interested in emulation and ease of
operation.
--------------------------------------------------------------------------
Living in the World of Atari
============================
Up until about a year ago last December, I was a happy-go-lucky
IBMer. What's an IBMer? That's usually someone who works for a
big company and uses whatever computer his boss tells him to. In
this case, though, I was the boss who chose IBM. I was convinced
that Ventura Publisher was the best Desktop Publishing system
available and it only runs on IBM PCs. I'd been using Ventura for
about a year and was also using Lotus Freelance, Publisher's
Paintbrush, Displaywrite/4 and several other products that ran
chiefly on IBM.
One of my favorites was SPF/PC, from CTC. It is virtually
identical to the SPF resident on IBM mainframes as part of TSO.
By the way, I've worked with mainframes since I began writing
books about them back in 1974. I also did my share of
big-company systems analysis, and some programming with a
language called SAS. I wrote a lot of formatters, index-
generators, and other programs related to producing programming
manuals using the mainframe like a great big typewriter.
Like so many IBMers, when I had finally saved enough money and
psyched myself up into a spending mood, I was thinking IBM.
You've heard it before -- get a home computer that will be as
much as possible like the one in the office. They call it
compatibility.
So I called my friendly neighborhood discount dealer and got some
prices and specs. For just a little under $3,000.00, he could fix
me up with a computer a lot like the one I had at work only not a
true IBM. That sounded fine and so I called my friend Ron to tell
him all about the computer I planned to buy.
"But", said Ron, (Atarians say that a lot), "before you actually
plunk down any money, you might take a look at the Atari ST." It
can run IBM and MacIntosh programs as well as its own.
Now I pride myself on being an open-minded fellow but Atari? It
just didn't seem quite possible. I called Virgil. He sided with
Ron!
The next thing I knew, I was over at Randall's Home Computer
Store with a copies of SPF/PC and PC/DOS under one arm. Sure
enough, they ran just fine on the Atari using a software
environment set up by a product called PC Ditto. (A week or two
later, I saw a demonstration of a product called Magic Sac that
allowed MacIntosh software such as MacPaint and MacDraw to
operate on the Atari.)
"So what about some Atari software," I said, just to be sure I
could say later that I had seen a full demonstration. You see, at
that point, I was just being polite really to appease Ron and
Virgil. "is there any publishing software in the Atari world?"
That's when I first saw Publishing Partner. I couldn't get over a
$69 program that could do so very many of the same things that
Ventura Publisher did. It not only did them easily -- it did them
in far less time. For example, paging from page one to page 55 in
a Ventura document takes several minutes. In Publishing Partner,
it took several seconds! I was hooked.
A few days later, I went to a meeting of the ACE St. Louis club.
Matt Ratcliffe, the outgoing president, at that time had just
sold his Atari because it was too slow when doing PC emulation.
He nearly talked me out of buying an Atari. I was worried. I got
some reassurance from Ron and Virgil and Tom W. that I probably
wouldn't be troubled as much as Matt because he had been doing
things that I didn't have to worry about. Matt was absolutely
right and I know that now. The Atari is too slow in that mode to
be of any real use over any extended period of time. That's just
one of those things, -- at the time, I didn't know who to believe
for sure.
So I went back to Randall's and bought it. I bought the Mega ST2
because I liked the feel of its keyboard so much better than the
one on the 1040. I also bought a hard drive, extra 5 1/4 inch
drive (for PC Ditto use), and a copy of Publishing Partner. Since
then I've added many more software products. All are Atari rather
than IBM.
Little by little, people found out that I had bought an Atari.
"Of course," they said, "no doubt because of its musical
capabilities."
"No," I said, "I bought it to publish with." What's this about
musical capabilities?"
"Oh sure, a lot of big rock stars use them."
You just can't imagine how confusing and troublesome that became.
I've worked in electronics, computers, and technology since 1957.
I've been a musician even longer than that. So how did I miss all
this? How did a complete technology with its own language, its
own rules, its own separate culture grow up without me knowing
about it? More important, how come I didn't understand a single
word printed in "Music Technology" magazine? Okay, I'll tell you
how. I was living in an IBM world. All work and no play. I was
playing good old fashioned music to get away from all that.
Perhaps, I got a little too far away.
Luckily, there was and is a special interest group for people
interested in Atari's musical abilities. I've been to quite a few
of their meetings by now and soon I hope to be able to speak
their language.
But was Ron satisfied? Did the fact that I spent all my money on
Atari-related hardware and software get him off my back? If you
know Ron, you know better. As I write this, I am looking over at
a Magic Sac that Ron insisted on lending me over the long weekend
so I could try it out first hand. I suppose he thinks that once
I've used MacDraw, SuperPaint and a few other MacIntosh programs
on my Atari, I won't be able to rest until I've bought a Magic
Sac of my own.
Ha! It's only two-o'clock in the morning and some of the
excitement is beginning to wear off already. I'll bet in a few
hours, I'll be able to rest easily on my decision not to buy a
Magic Sac.
But you know something, I was browsing through the latest issue
of PC Magazine yesterday and noticed that there's a new version
of Ventura Publisher now. I wonder if I've become as close-minded
about IBM as I once was about Atari. I have no desire at all to
try out the new Ventura.
--------------------------------------------------------------------------
PRICE REDUCTION ON VIDEOKEY, THE RGB TO COMPOSITE ENCODER
FROM PRACTICAL SOLUTIONS!
VideoKey has been on the market long enough to pay off some of the
expensive manufacturing setup costs. Thus we are happy to announce a price
reduction!
VideoKey debuted for $119.95 earlier thus year. Effective immediately, the
price has been reduced to $99.95, making it more affordable than ever.
There are some ads out with the old price since advertising has to be done
so far in advance, but we and our dealers are honoring the new pricing.
For those of you not familiar with the VideoKey.........
a description follows:
The VideoKey converts the RGB output of the ST into color composite video.
We have put a lot of effort into making the colors brilliant and true, the
picture excellent in low resolution. You now have the ability to record
the fantastic graphics of the ST. Games take a new dimension when watched
on your television or big screen TV!
The VideoKey has several nice features as well:
1. The exclusive Colorlock(tm) circuitry locks the color burst to the
ST's system timing with no modification needed to the ST, so that there
is no color flickering or crawl on sharp vertical edges.
2. The Auto power circuit detects when the ST is on, and in color mode,
and powers up the VideoKey as needed. No power supply required!
3. A 13 pin din socket is supplied (just like the monitor port
on the ST) so that a RGB monitor can be connected to the VideoKey
at the same time. Perfect for doing all of your work on the RGB
monitor, and viewing the composite monitor or TV for final
product! This causes no signal loss to the RGB monitor. In addition,
VideoKey is compatible with Monitor Master, our monitor switch box. You can
still switch between your monitors with ease.
VideoKey is compatible with all low resolution software, and comes
with a limited 90 day warranty.
Call Practical Solutions, or write for further details (or better yet,
order!):
Practical Solutions
1930 E. Grant Rd.
Tucson Az, 85719
(602) 884-9612
Mark Sloatman 74206,356
--------------------------------------------------------------------------
MACINTOSH DISK READING AND WRITING WITH ATARI DRIVES
====================================================
THE SIMPLE TRUTH
----------------
NOTE: You may find this article is a bit too technical for you.
---- Please don't miss out on the conclusions I have formulated.
Atari really has only one requirement for their 3.5" microfloppy drive
system. This requirement is that it can accurately read and write the
MFM 250K bits per second data, which is the standard form of recording
used by the ST computer system.
Along comes MACINTOSH. They use a completely different recording
system, which is GCR. The MACINTOSH always uses a constant data rate.
All GCR bits recorded on the disk wind up being spaced either 2, 4, or
6usec apart. However, the MACINTOSH uses 5 different drive speeds, one
for each of the 5 groups of 16 tracks (cylinders). The MACINTOSH drives
vary the drive speed from about 400 RPM to 600 RPM. This gives the MAC
disk a different quantity of bytes available in each of the 5 groups.
It also lets the MAC record a higher density than the ATARI's on the
outer tracks, and a lower density on the inner tracks. The whole
purpose of this is to try and maintain the bit density between groups,
since the circumference decreases for each track going toward the disk
center.
The Atari drive does not vary the speed. It does its best to keep the
speed at 300 RPM. A MACINTOSH disk inserted in an Atari drive will read
back as 5 different data rates. So, the MAC keeps the data rate
constant and varies the speed, and a MAC disk inserted in an Atari
drive will read as varying data rates, since the drive speed is
constant.
A standard MFM format disk in an Atari drive needs to read and write
disk data bits that are spaced 4, 6, and 8 usec apart. A MACINTOSH disk
inserted in an Atari drive needs a disk formatter circuit that can read
and write data bits that are at various spacings between about 2.6 and
12 usec apart.
Some specialized hardware device must be added to the Atari to read and
write these varying data rates. Currently, the Translator One from Data
Pacific, and the Discovery Cartridge from Happy Computers are available
to accomplish this job. Gadgets by Small has also been hinting about a
forthcoming product for this purpose.
In addition to a special hardware device for reading and writing the
larger range of data bit spacings, the drive mechanism must also permit
this wider range of spacings to be read from and written to the disk
media's surface.
Regardless of the unique characteristics of the particular specialized
hardware device, all of these devices will require that the drive
mechanism, and all other associated disk drive interface circuitry,
will permit the larger bandwidth needed for emulating the MACINTOSH
disk format.
How does this compare with Atari's drive requirement? It doesn't! We
are not aware of any intention on Atari's part to supply drives for ST
computers that can accommodate this wider bandwidth. There will always
be some uncertainty whether a particular drive will allow this wider
bandwidth, since the drives are not required to do this. If a
particular drive can do this, it is only a pleasant coincidence!
Now wait a minute, didn't HAPPY COMPUTERS say that the DISCOVERY
CARTRIDGE will allow standard Atari drives to read and write in the
MACINTOSH format? Yes we did, but as stated in our May 1988 product
literature- "It is conceivable that a particular drive may have trouble
reading or writing in the MACINTOSH format."
Between HAPPY COMPUTERS and our customers, thousands of drives have
been tested. We do not have the test results for each drive. Our
statistics, based on a sample of about 200 units, is that 92% of the
drives will properly read and write in the MACINTOSH format with the
DISCOVERY CARTRIDGE. This is subject to change. Atari could begin
shipping a bunch of drives where none could read MAC disks, even though
they worked perfectly for normal MFM reading. Again, reading and
writing the increased bandwidth for MACINTOSH emulation has not been a
requirement for the drives shipped by Atari.
Some of the after market drive suppliers will take the hint. There is a
marketplace need for drives that can handle the extra bandwidth. This
may become a major selling point for some aftermarket drives.
The fact is that this whole business of reading and writing MACINTOSH
disks with Atari drives is an extension beyond the original design
criteria for the system. Regardless of the high quality disk signal
processing done by the Discovery Cartridge, there must be some
uncertainty about the ability of the other elements of the disk system
to effect the reading and writing of MAC format disks.
CONCLUSIONS:
In effect, the MFM disk format used by the standard Atari ST will
ultimately be more reliable than any system which emulates the variable
density MAC disk reading. Still, there is the need to read and write
MAC disks. Since this process is less reliable, it should be the second
choice when you have a choice. Therefore, even if your MAC disk reading
device can operate online with the MAC emulation device, you are better
off using the native "MAGIC" or "SPECTRE" format, when you can make
this choice.
Richard Adams, chief designer
HAPPY COMPUTERS, Inc.
--------------------------------------------------------------------------
NEW ON GEnie
============
New Library Join/Ignore Command
-------------------------------
We are testing out a new option that will soon be deployed in all of the
Genie Roundtables. You can now join or ignore libraries of YOUR choice by
using option 12 on page 476. Follow the menus below to see how the option
works.
GEnie Page 476
Atari ST Software Library
Library: All Libraries <-- Be sure to be set to ALL
libraries
1. Description of this Library
2. Directory of files
3. Search File Directory
4. Browse through files
5. Upload a new file
6. Download a file
7. Delete a file you own
8. Set Software Library
9. Save Current Software Library
10. Instructions for Software Exchange
11. Directory of New Files
12. Join/Ignore Library Category <<<-- This is the new option.
Item #, or <RETURN> for more?12 <<<-- Select this option
Please stand by...
Change access to what library # <<<-- You will see this display
Enter <D>isplay to display status?d <<<-- Select D to display libraries
and the status. Once you know
this, you can bypass the
display by just entering the #
of the library you want to
change instead of D for display
1. Genie Help Files -J 2. Utilities -J
3. Language/Programming -J 4. Graphic Animation -J
5. Graphics & Art -J 6. Business -J
7. Telecomputing -J 8. Games -J
9. Educational -J 10. Demos -J
11. Music -J 12. Adult Library -J
13. Atari Archives -J 14. Product Support -J
15. User Group Newsletters &-J 16. OS-9/68000 for the ST -J
17. Digitized Sounds -J 18. Desktop Publishing -J
19. ST-REPORT -J 20. Printer Drivers -J
21. T.O.S (The Other Stuff) -J 22. ICD Product Support -J
23. ST-LOG -J 24. ST-Profile -J
25. ST-PROFILE Articles (P) -J
Change access to what library #
Enter <D>isplay to display status?12 <<-- Select the number of the library
you want your status changed on
Library: 12 - Adult Library - ignored <<-- You will receive the message
ignored if you did not
previously ignore this
library.
Please stand by...
GEnie Page 476
Atari ST Software Library
Library: All Libraries
1. Description of this Library
2. Directory of files
3. Search File Directory
4. Browse through files
5. Upload a new file
6. Download a file
7. Delete a file you own
8. Set Software Library
9. Save Current Software Library
10. Instructions for Software Exchange
11. Directory of New Files
12. Join/Ignore Library Category
Item #, or <RETURN> for more?12 <-- Select 12 to change to join again
Please stand by...
Change access to what library #
Enter <D>isplay to display status?d <-- Check notations above on this
option on how to reduce time
1. Genie Help Files -J 2. Utilities -J
3. Language/Programming -J 4. Graphic Animation -J
5. Graphics & Art -J 6. Business -J
7. Telecomputing -J 8. Games -J
9. Educational -J 10. Demos -J
11. Music -J 12. Adult Library -I
13. Atari Archives -J 14. Product Support -J
15. User Group Newsletters &-J 16. OS-9/68000 for the ST -J
17. Digitized Sounds -J 18. Desktop Publishing -J
19. ST-REPORT -J 20. Printer Drivers -J
21. T.O.S (The Other Stuff) -J 22. ICD Product Support -J
23. ST-LOG -J 24. ST-Profile -J
25. ST-PROFILE Articles (P) -J
<<--as shown above, you will receive a display when selecting
this option that will show you which libraries you are
presently ignoring and which you have not ignored.
<<-- -I above means you have presently ignored the library.
<<-- -J above means you have joined this library.
Change access to what library #
Enter <D>isplay to display status?12
Library: 12 - Adult Library - joined <-- notice you rejoined
After joining and ignoring the libraries, you can use option 2 "Directory
of Files" or Option 4 "Browse the files" to see ONLY the files of the
libraries you chose.
Be aware that you can continue to select libraries or push your return
key to end your session of selections as shown below:
Please stand by...
Change access to what library #
Enter <D>isplay to display status?12
Library: 12 - Adult Library - joined
Change access to what library #
Enter <D>isplay to display status? <<-- Push return here if you are
finished selecting or enter an
additional library number
selection.
Be aware that we have private libraries and the capabilities of such.
Please contact DARLAH for admittance if appropriate as well as for
installation/details on how you as a company can use a private library.
-------------------------------------------------------------------------
ANTIC PUBLISHING INC.
COPYRIGHT 1988
REPRINTED BY PERMISSION.
** Professional GEM 16 ** - by Tim Oren **
- Interface Potpourri #1 -
This issue of ST PRO GEM, number 16 in the series, presents code
implementing several user interface techniques: progress
indicators, rubber boxes, and draggable boxes with mouse sensitive
targets. The code also includes some utility routines for
handling resources, event calls, and VDI line drawing.
The downloads for this column are available on DL3 of the ATARI16
SIG: PCS-58. Note the plural - in addition to the usual C sources
stored in GMCL16.C, the files GMCL16.RSC, GMCL16.DFN, GMCL16.H,
and GMCL16.RSH are a template resource for building progress
boxes. GMCL16.RSC is the resource binary, and GMCL16.H is its
symbol binding file, to be used with GMCL16.C. The RSH file is a
C image of the resource - you would need STCREATE to regenerate
it.
GMCL16.DFN is the binary symbol file for the resource. It is in
the format used by the NEW ST Resource Construction Set. If you
are a developer, you should download this new version from DL7 of
PCS-57. It fixes a number of bugs, and has a much faster user
interface.
MAKING PROGRESS
The need for feedback in interface designs has been discussed in
previous columns. One instance which is often necessary is the
so-called progress indicator. A progress indicator is used when
your application is doing a long operation. It shows that the
function is continuing satisfactorily, and is not hung in a loop.
When possible, it also gives an indication of the fraction of the
operation which has been completed. The thermometer bars on the
Desktop format and copy operations are examples.
The sample code shows two types of progress indicator. Both are
built within the structure of a dialog resource. The first type
uses a variable line of text to describe each phase of an
operation as it occurs. The rewriting of the text provides action
on the screen; the fact that it is different each time gives
reassurance that the program is not hung. The second type of
indicator is the thermometer bar. This is more useful when the
operation is uniform, allowing you to estimate the fraction
completed. Let's look at the code.
The routines beg_prog() and end_prog() are common to the two
types. The code is very similar to the standard dialog handling
procedure, but is broken into two parts. Beg_prog() assumes that
the progress indicator box is defined by a dialog tree named
PROGRESS. Such a tree is provided in GMCL16.RSC. Beg_prog()
makes the usual calls to center and draw the box. The rectangle
computed in the centering operation is stored via a GRECT pointer
passed in the parameter. This rectangle compensates for the
outline around the box, and must be supplied to end_prog() when
the operation is complete.
The first version of set_prog() in the download implements the
changing text progress indicator. It looks in a tree labelled
STRINGS for the object number which is passed as a parameter. It
is assumed that this object is a G_STRING. The address of the new
text is loaded from the object's ob_spec field. (For those with
the new RCS, it would be easy to alter this routine to use free
strings. Simply replace the first two lines with:
rsrc_gaddr(R_STRING, strno, &saddr); and supply parameters which
are the names of strings in a FRSTR box.)
Once the new text is found, the set_text() utility is called to
update the TEDINFO attached to object PLINE in the PROGRESS tree.
Set_text() will insert the new text address in te_ptext, and the
new text length in te_txtlen. Disp_obj() is then used to redraw
only the rectangle belonging to PLINE.
PLINE must be defined as a G_BOXTEXT object with a solid white
background, and with the CENTERED attribute set. It must extend
entirely across the progress box. This guarantees that the
previous text will be covered over, and the new text will be
centered in the box.
The second version of set_prog() implements the thermometer bar
progress indicator. The PROGRESS tree also includes an object
PROBOX which defines the outline of the thermometer. It is a
G_BOX object with a solid white background, and a one-outside
border. The object PROBAR is nested inside it, with the left
edges matching. PROBAR is also a G_BOX, with a solid red
background and a one-outside border as well. Set_prog() creates
the thermometer effect by growing and redrawing PROBAR.
Set_prog() requires two parameters. Maxc is an estimate of the
total duration of the operation, in arbitrary units. Value is the
(new) amount completed, in the same units. Set_prog performs two
operations. First, it computes the fraction value/maxc, and sets
PROBAR to that fraction of the width of PROBOX. Second, it
computes the rectangle which is the difference between the old and
new widths of PROBAR, and redraws only that part of the progress
box. This prevents an annoying flash on the screen when the
indicator is updated.
These two types of progress indicators have been presented in
separate routines for convenience in explanation. You can easily
combine them in a single procedure to create an indicator with
both effects.
The final progress indicator routine is called esc_prog(). During
many lengthy operations is desirable to provide an abort option to
the user. Esc_prog() lets you do this by polling the keyboard for
an escape (ESC) character. A zero timer value is used to
guarantee an immediate return if no character is found.
Characters other than escape are ignored.
Esc_prog() returns TRUE if an abort is requested, and FALSE if the
operation is to continue. In your application, you can either
pair calls to set_prog() and esc_prog(), or recode set_prog() to
automatically make the abort check. In any case, you should add
an information line to the progress box, telling the user how the
operation may be halted.
Of course, this type of progress indicator is not the only option
available on the ST. Other ideas such as changing window titles,
or displaying a succession of differing icons are equally valid.
Sometimes the nature of your application may suggest an alternate
metaphor. For instance, the progress of recalculating a
spreadsheet might be indicated by darkening successive columns in
a miniature image of the sheet. Occasionally, the computing
operation is visual itself, and will not require an explicit
indicator. An example is redisplaying objects in a 2D or 3D
drawing program.
BOXED IN
The second part of the download implements two types of user
interaction using the mouse. The first creates a "rubber box" on
the screen, that is, a box whose size is controlled by moving the
mouse. This is similar to the AES graf_rubberbox call, but allows
the box to move in any direction from its origin, while the GEM
function only allows movement to the lower right.
The second technique allows the user to drag the outline of a box
around the screen using the mouse. Again, this is similar to the
AES graf_dragbox call, but this version is augmented with code
which "hotspots" selectable objects when the mouse and object pass
over them. These routines are another illustration of the usage
of the evnt_multi function, and its combination with VDI drawing
to create new interaction techniques.
The "rubber box" subroutine is called fourway_box(). Its
parameters are the current VDI handle (NOT a window handle!), and
two GRECT pointers. The first GRECT must have its g_x and g_y
initialized with the fixed point of the rubber box. The second
GRECT contains an outer bound box for the stretching action.
Fourway_box() begins by setting the VDI drawing mode and color.
The exclusive or, black combination guarantees that redrawing a
figure twice in the same location will exactly erase it. Next,
the routine asserts the mouse control flag. This stops the window
manager from tracking the mouse, with the effect that menus will
not drop down during the operation.
The fixed coordinates are saved in the variables ox and oy, and an
initial mouse reading is obtained with graf_mkstate. At this
point, the event loop is entered.
At each iteration, the loop finds the upper left most of the fixed
vertex and the current mouse position, and updates the tracking
GRECT accordingly. A call to the utility rc_intersect() is used
to restrict the size of the rubber box to the given limiting
rectangle. Note that if you need a lower limit to the size of the
rubber box, it can be achieved by adding another GRECT pointer
"lower" to the parameter list, and using the call rc_union(lower,
rubber); This works because the union operation selects the larger
of two rectangles if they are nested.
Rub_wait() will be described in detail below. Its returns are the
new mouse position, and an indication of the current mouse button
state. If the button remains down, the loop continues. When the
button is released, the rubber box terminates, since it is a
"spring-loaded" modal operation. Before ending, fourway_box()
returns mouse control to the window manager. The return from the
routine is found in the rubber GRECT, and is the final extent of
the box.
Rub_wait() is a utility used by both box techniques. Its purpose
is to do one step of the box animation, and wait for a mouse
movement, or the release of the button. Rub_wait() preserves the
state of the screen.
The first action is to draw an exclusive or'ed dotted line box at
the given rectangle. Next, rub_wait() calls evnt_multi to wait
for the mouse button to come up, or the mouse to move out of a one
pixel rectangle. When the event is detected, the same code is
used to remove the box. A value of TRUE is returned if the mouse
button is still down; the curious logical construction is
necessary since BOTH events could occur at once.
A short examination of the vdi_xbox() code is also useful. After
converting the rectangle to polyline format, the vdi_xline()
routine is called. Vdi_xline draws a dotted line, but does not
use the VDI line style attribute. This is avoided because the VDI
has problems with corner points when drawing styled lines in XOR
mode. Instead, a selection is made from a set of user defined
line styles, based on the direction of the stroke, and the
odd/evenness of the starting horizontal pixel. This assures that
the figure will be exactly erasable.
HOT STUFF
The drag box routine is more subtle, because care is needed to
correctly synchronize the movement of the mouse cursor and the
box, and the highlighting of target objects. The parameters
vdi_handle and limit are identical to those in fourway_box(). The
GRECT pointed to by box contains the width and height of the
movable box when hot_dragbox() is entered. On exit it also
contains the last x,y coordinates of the box. The variable tree
is a pointer to the root of a resource tree defining the hot spots
for the drag operation. Only objects tagged SELECTABLE are
hotspotted. Hot_dragbox() returns the number of such an object if
the box is "dropped" on it, otherwise a NIL is returned.
Initialization proceeds as above, until the graf_mkstate call.
Here is the first potential synchronization problem. If the user
moves the mouse very quickly after initiating the drag, it may
already be outside the box by the time graf_mkstate samples the
position. The min/max operations given lock the box onto the
cursor, no matter where it has strayed. The mouse/box offsets, ox
and oy, will remain constant for the rest of the operation.
Hover_obj will contain the number of the object which is currently
highlighted. It is initialized to NIL, indicating no object is
currently marked. Hot_dragbox() now enters a loop with
termination conditions identical to the rubber box.
The current desired position of the box is computed by subtracting
the box/mouse offset from the current mouse position. The
rc_constrain() call ensures that the box will not leave the
bounding rectangle. Note that rc_intersect would not work here -
it would alter the size of the draggable box, rather than
"nudging" it back into the bounds.
Upon return from rub_wait(), a number of conditions must be
checked to determine the correct object to highlight, if any.
First, we must make sure that the mouse is actually within the
legal bounds. If not, there may be an ambiguous selection, with
the mouse over one object and the box over another. We choose to
do nothing in this case, and set hover_obj to NIL. If the mouse
is in bounds, objc_find looks for a target object. If one exists,
it must be SELECTABLE, or it is forced to NIL.
Next the new object, stored in ret_obj, is compared to the old
highlighted object, in hover_obj. If they are different, a switch
must be made. Since either could be NIL, a check is necessary
before calling obj_toggle to invert/reinvert the screen image of
the object. When the loop is complete, the final hover_obj is
returned to normal state before its number is returned.
You may notice that this method of highlighting objects is
different from the incremental tree descent and rectangles method
presented in column 13. While not as efficient, the objc_find
technique is simpler to code and may be adequate for many uses.
If your program will make heavy use of the drag box routine, or
will have large trees of target objects, you may wish to integrate
the incremental hotspotting algorithm with hot_dragbox(). This
would be simple to do; just use evnt_multi's second mouse
rectangle for the states associated with the hot- spotter. The
single pixel rectangles would have to remain, in order to maintain
the animation effects.
A FEW CHANGES
The observant may have noticed that the promised code for popup
menus did not make it into this column. Instead, it will appear
in column 18 along with more "graphics potpourri" and feedback
replies. The intervening installment, number 17, will present and
document the source code for a complete IBM/Atari GEM Resource
conversion program. This will appear concurrently with Mark
Skapinker's article on IBM/ST GEM conversions in the second issue
of START. While this program will be of direct use to only a
minority of ST developers, it will contain utility code useful to
all, as well as demonstrations of dialog handling and the internal
structure of resources.
Finally, you may also notice that the so-called portability macros
have disappeared from the download. Indeed, they are gone for
good. Since the beginning of this column, the growth of the ST
GEM developer community has outstripped that on the PC. It no
longer seems appropriate to inconvenience ST developers and
violate standard C syntax for the sake of Intel's design flaws.
Those who still need compatibility with the PC may achieve it by
compiling under Intel large model, or by writing "sed" scripts to
translate (tree+obj)->ob_spec and the like to their macro
equivalents. On is the same as the Open entry in the "File" menu.
-------------------------------------------------------------------------
ST REPORT CONFIDENTIAL
======================
NYC,NY Consumer Reports, in it's latest issue picks the ST
------ over the "other" computer.
London, UK European Developers are becoming 'antsy' over all
---------- the different troubles they are seeing in certain
areas of the US ST marketplace.
Sunnyvale, CA Atari is working feverishly to make the new TOS work
------------- properly in partitions larger than 16mb. They
expect to have the situation under control shortly.
NYC, NY DR. RUTH in your CPU? yep! Intimate Software is fast
------- becoming a very popular medium. No game here folks,
this is a sincere and serious effort.
Call: 718-768-1427
Wheat Ridge, CO A company here has introduced a car seat for your
--------------- laptop! Now it can go anywhere with you safely.
call Zirco Car Seat: 303-421-2013
Sunnyvale, CA John Townsend, was queried by this reporter seeking
------------- assistance about MS Write, he did not know who I was
until I announced myself, he was quite professional
and extremely courteous and HELPFUL.
Los Angeles, CA A number of area developers have expressed hopes
--------------- that as a result of the upcoming developer's
conference a National Atari Developer Association is
formed that will have some strength and real input
to the company.
-------------------------------------------------------------------------
A SysOp's Lot
=============
by R.F.Mariano
What is a SysOp? ...probably the most harried and ignored
person in the world. Most sysops are almost never highly visible on the
systems they care for. The reasons are many for the less than visible
posture, but perhaps one of the most important reasons falls into three
critical sub-topics.
a: Service to the Users of the System
b: Preserving Integrity of the Libraries
c: Keeping apart from any and all issues on the system
To go deeper into the reasons service to the users comes in many
forms; a 'good' sysop is concerned for all the users, not just a "favored
few", (which easily happens), also, keeping an eye out for potential "hot
spots", this means, arguments, emotional issues etc....a 'good' sysop makes
honest attempts to stabilize and set the example for all to keep a
discussion lively, yet respectful after all, the users are only human and
all sysops are superhuman right?. Well, expected to be anyway. <grin>
Most folks feel the sysop has luxurious "powers" on a system, well,
the EXACT opposite is true! When one becomes a sysop, the responsibility
assumed is awesome and a great many, "taken for granted freedoms", must be
voluntarily given up. "An outspoken sysop is a disaster going someplace
to happen." ---------
Another point to be made for the 'good' sysop is; in most cases
he/she is usually the person saddled with the job of acquainting the new
user with his equipment and the ways to best use it and pointing out the
usergroups local to that person.
Libraries are very important part of any information system and the
manner in which a sysop approaches taking care of the library is always
reflected in the ease of which files are found, run and serve a useful
purpose to the userbase of the system. In addition, the sysop is expected
to know how to implement 'every' item in the library and be able to teach
same to anyone.
A sysop who gets involved in the issues that 'percolate' up from
time to time is courting disaster. Why? Easy....Most users look for some
sign from the 'powers to be' when embarking on a 'mission of purpose'
..the sign is taken from any input from the sysop that appears to "join",
"condone" or agree with one side or the other in an issue. Most issues
have a tendency to get old in a hurry but....some get bad, so bad that
things are said and done that are regrettably seen as dumb after the fact.
Sadly though, many of the hot statements and such leave scars that never
disappear. A sysop who takes sides in this sort of thing is worse than
the loudest rabble rouser because by becoming involved, the sysop
"endorses" the issue and spurs the clique on.
For a SysOp to be directly involved in ANY such melee is flirting
with disaster, the "combatants" usually come to terms but the unfortunate
sysop who "took" sides is left with the choice of either an apology to
the "unfavored side" or having to continue a cold attitude toward that
side.
Anytime a sysop shows any partiality or, in fact, makes statements
pro or con in an issue they indirectly sway the body of the users in that
system..and give a green light to the more vocal users to continue the
fray with renewed vigor. The proper situation is that the sysop remain
virtually transparent to the users except in severe rule breaking,
moderating live functions online or in the performance of routine operator
functions.
Hopefully, those sysops who find that this group of observations are
helpful, will try to use them. (regardless of the source). For those who
snub these ideas, well...'guess they 'know it all' or will eventually
experience the "rude awakening"...... -----------
To all the caring, conscientious SysOps running fine BBS systems
across this country I wish to extend to you a positive note of thanks for
a job well done! I care not what program you are using, only that you are
using the program you like correctly.
To all of you I wish you a very......
MERRY CHRISTMAS and a HAPPY an PROSPEROUS NEW YEAR.
-=****=-
-------------------------------------------------------------------------
THIS WEEK'S QUOTABLE QUOTE
==========================
THE LAW OF THE "CLIQUE"
-----------------------
There are two sides to every argument or discussion, unless a member
of the "clique" is involved, in which case, it becomes one side!
*** Happy Holidays to all our Friends ***
------------------------------------------------------------------------
ST-REPORT Issue #65 December 12, 1988
ALL RIGHTS RESERVED (c)copyright 1988
------------------------------------------------------------------------
ALL reprints must include ST-Report and the author in the credits.
Views Presented herein are not necessarily those of STR
COMMERCIAL ONLINE SERVICES MUST HAVE WRITTEN PERMISSION
to offer ST REPORT for download and/or display in any form.
-------------------------------------------------------------------------
