========================================================================== *---=== 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 for more?12 <<<-- Select this option Please stand by... Change access to what library # <<<-- You will see this display Enter 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 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 for more?12 <-- Select 12 to change to join again Please stand by... Change access to what library # Enter 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 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 isplay to display status?12 Library: 12 - Adult Library - joined Change access to what library # Enter 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. 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. -------------------------------------------------------------------------