Path: utzoo!utgpu!attcan!uunet!cbmvax!rutgers!mailrus!nrl-cmf!ukma!gatech!udel!udccvax1!gdtltr From: gdtltr@vax1.acs.udel.EDU (Gary D Duzan) Newsgroups: comp.sys.atari.st Subject: ST Report Volume II No. 55 (part 2/2) Message-ID: <1996@udccvax1.acs.udel.EDU> Date: 4 Oct 88 19:16:01 GMT Organization: University of Delaware Lines: 797 As above, the source and dest parameters are pointers to MFDBs (which in turn point to the actual forms). The two MFDBs may point to memory areas which overlap. In this case, the VDI will perform the move in a non-destructive order. Mode determines how the pixel values in the source and destination areas will be combined. I will discuss it separately later on. The pxy parameter is a pointer to an eight-word integer array. This array defines the area within each form which will be affected. Pxy[0] and pxy[1] contain, respectively, the X and Y coordinates of the upper left corner of the source rectangle. These are given as positive pixel displacements from the upper left of the form. Pxy[2] and pxy[3] contain the X and Y displacements for the lower right of the source rectangle. Pxy[4] through pxy[7] contain the destination rectangle in the same format. Normally, the destination and source should be the same size. If not, the size given for the source rules, and the whole are is transferred beginning at the upper left given for the destination. This all sounds complex, but is quite simple in many cases. Consider an example where you want to move a 32 by 32 pixel area from one part of the display to another. You would need to allocate only one MFDB, with a zero in the fd_addr field. The VDI will take care of counting color planes and so on. The upper left raster coordinates of the source and destination rectangles go into pxy[0], pxy[1] and pxy[4], pxy[5] respectively. You add 32 to each of these values and insert the results in the corresponding lower right entries, then make the copy call using the same MFDB for both source and destination. The VDI takes care of any overlaps. COPY RASTER TRANSPARENT This operation is used for copying from a monochrome form to a color form. It is called transparent because it "writes through" to all of the color planes. Again, the forms need to be in device-specific form. The calling format is: vrt_cpyfm(vdi_handle, mode, pxy, source, dest, color); All of the parameters are the same as copy opaque, except that color has been added. Color is a pointer to a two word integer array. Color[0] contains the color index which will be used when a one appears in the source form, and color[1] contains the index for use when a zero occurs. Incidentally, copy transparent is used by the AES to draw G_ICONs and G_IMAGEs onto the screen. This explains why you do not need to convert them to color forms yourself. (A note for advanced VDI programmers: The pxy parameter in both copy opaque and transparent may be given in normalized device coordinates (NDC) if the workstation associated with vdi_handle was opened for NDC work.) THE MODE PARAMETER The mode variable used in both of the copy functions is an integer with a value between zero and fifteen. It is used to select how the copy function will merge the pixel values of the source and destination forms. The complete table of functions is given in the download. Since a number of these are of obscure or questionable usefulness, I will only discuss the most commonly used modes. REPLACE MODE A mode of 3 results in a straight-forward copy: every destination pixel is replaced with the corresponding source form value. ERASE MODE A mode value of 4 will erase every destination pixel which corresponds to a one in the source form. (This mode corresponds to the "eraser" in a Paint program.) A mode value of 1 will erase every destination pixel which DOES NOT correspond to a one in the source. XOR MODE A mode value of 6 will cause the destination pixel to be toggled if the corresponding source bit is a one. This operation is invertable, that is, executing it again will reverse the effects. For this reason it is often used for "software sprites" which must be shown and then removed from the screens. There are some problems with this in color operations, though - see below. TRANSPARENT MODE Don't confuse this term with the copy transparent function itself. In this case it simply means that ONLY those destination pixels corresponding with ones in the source form will be modified by the operation. If a copy transparent is being performed, the value of color[0] is substituted for each one bit in the source form. A mode value of 7 selects transparent mode. REVERSE TRANSPARENT MODE This is like transparent mode except that only those destination pixels corresponding to source ZEROS are modified. In a copy transparent, the value of color[1] is substituted for each zero bit. Mode 13 selects reverse transparent. THE PROBLEM OF COLOR I have discussed the various modes as if they deal with one and zero pixel values only. This is exactly true when both forms are monochrome, but is more complex when one or both are color forms. When both forms are color, indicating that a copy opaque is being performed, then the color planes are combined bit-by-bit using the rule for that mode. That is, for each corresponding source and destination pixel, the VDI extracts the top order bits and processes them, then operates on the next lower bit, and so on, stuffing each bit back into the destination form as the copy progresses. For example, an XOR operation on pixels valued 7 and 10 would result in a pixel value of 13. In the case of a copy transparent, the situation is more complex. The source form consists of one plane, and the destination form has two or more. In order to match these up, the color[] array is used. Whenever a one pixel is found, the value of color[0] is extracted and used in the bit-by-bit merge process described in the last paragraph. When a zero is found, the value of color[1] is merged into the destination form. As you can probably see, a raster copy using a mode which combines the source and destination can be quite complex when color planes are used! The situation is compounded on the ST, since the actual color values may be remapped by the palette at any time. In many cases, just using black and white in color[] may achieve the effects you desire. If need to use full color, experimentation is the best guide to what looks good on the screen and what is garish or illegible. OPTIMIZING RASTER OPERATIONS Because the VDI raster functions are extremely generalized, they are also slower than hand-coded screen drivers which you might write for your own special cases. If you want to speed up your application's raster operations without writing assembly language drivers, the following hints will help you increase the VDI's performance. AVOID MERGED COPIES These are copy modes, such as XOR, which require that words be read from the destination form. This extra memory access increases the running time by up to fifty percent. MOVE TO CORRESPONDING PIXELS The bit position within a word of the destination rectangle should correspond with the bit position of the source rectangle's left edge. For instance, if the source's left edge is one pixel in, then the destination's edge could be at one, seventeen, thirty-three, and so. Copies which do not obey this rule force the VDI to shift each word of the form as it is moved. AVOID FRINGES Put the left edge of the source and destination rectangles on an even word boundary, and make their widths even multiples of sixteen. The VDI then does not have to load and modify partial words within the destination forms. USE ANOTHER METHOD Sometimes a raster operation is not the fastest way to accomplish your task. For instance, filling a rectangle with zeros or ones may be accomplished by using raster copy modes zero and fifteen, but it is faster to use the VDI v_bar function instead. Likewise, inverting an area on the screen may be done more quickly with v_bar by using BLACK in XOR mode. Unfortunately, v_bar cannot affect memory which is not in the video map, so these alternatives do not always work. FEEDBACK RESULTS The results of the poll on keeping or dropping the use of portability macros are in. By a slim margin, you have voted to keep them. The vote was close enough that in future columns I will try to include ST-only versions of routines which make heavy use of the macros. C purists and dedicated Atarians may then use the alternate code. THE NEXT QUESTION This time I'd like to ask you to drop by the Feedback Section and tell me whether the technical level of the columns has been: A) Too hard! Who do you think we are, anyway? B) Too easy! Don't underestimate Atarians. C) About right, on the average. If you have the time, it would also help to know a little about your background, for instance, whether you are a professional programmer, how long you have been computing, if you owned an 8-bit Atari, and so on. COMING UP SOON The next column will deal with GEM menus: How they are constructed, how to decipher menu messages, and how to change menu entries at run-time. The following issue will contain more feedback response, and a discussion on designing user interfaces for GEM programs. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> MFDB Structure <<<<<<<<<<<<<<<<<<<<<<<<<<<<< /* Memory Form Definition Block */ typedef struct fdbstr { long fd_addr; /* Form address */ int fd_w; /* Form width in pixels */ int fd_h; /* Form height in pixels */ int fd_wdwidth; /* Form width in memory words */ int fd_stand; /* Standard form flag */ int fd_nplanes; /* Number of color planes */ int fd_r1; /* Dummy locations: */ int fd_r2; /* reserved for future use */ int fd_r3; } MFDB; >>>>>>>>>>>>>>>>>>>>>>> Resource Transform Utilities <<<<<<<<<<<<<<<<<<<<< /*------------------------------*/ /* vdi_fix */ /*------------------------------*/ VOID vdi_fix(pfd, theaddr, wb, h) /* This routine loads the MFDB */ MFDB *pfd; /* Input values are the MFDB's */ LONG theaddr; /* address, the form's address, */ WORD wb, h; /* the form's width in bytes, */ { /* and the height in pixels */ pfd->fww = wb >> 1; pfd->fwp = wb << 3; pfd->fh = h; pfd->np = 1; /* Monochrome assumed */ pfd->mp = theaddr; } /*------------------------------*/ /* vdi_trans */ /*------------------------------*/ WORD vdi_trans(saddr, swb, daddr, dwb, h) /* Transform the standard form */ LONG saddr; /* pointed at by saddr and */ UWORD swb; /* store in the form at daddr */ LONG daddr; /* Byte widths and pixel height */ UWORD dwb; /* are given */ UWORD h; { MFDB src, dst; /* These are on-the-fly MFDBs */ vdi_fix(&src, saddr, swb, h); /* Load the source MFDB */ src.ff = TRUE; /* Set it's std form flag */ vdi_fix(&dst, daddr, dwb, h); /* Load the destination MFDB */ dst.ff = FALSE; /* Clear the std flag */ vr_trnfm(vdi_handle, &src, &dst ); /* Call the VDI */ } /*------------------------------*/ /* trans_bitblk */ /*------------------------------*/ VOID trans_bitblk(obspec) /* Transform the image belonging */ LONG obspec; /* to the bitblk pointed to by */ { /* obspec. This routine may also */ LONG taddr; /* be used with free images */ WORD wb, hl; if ( (taddr = LLGET(BI_PDATA(obspec))) == -1L) return; /* Get and validate image address */ wb = LWGET(BI_WB(obspec)); /* Extract image dimensions */ hl = LWGET(BI_HL(obspec)); vdi_trans(taddr, wb, taddr, wb, hl); /* Perform a transform */ } /* in place */ /*------------------------------*/ /* trans_obj */ /*------------------------------*/ VOID trans_obj(tree, obj) /* Examine the input object. If */ LONG tree; /* it is an icon or image, trans- */ WORD obj; /* form the associated raster */ { /* forms in place. */ WORD type, wb, hl; /* This routine may be used with */ LONG taddr, obspec; /* map_tree() to transform an */ /* entire resource tree */ type = LLOBT(LWGET(OB_TYPE(obj))); /* Load object type */ if ( (obspec = LLGET(OB_SPEC(obj))) == -1L) /* Load and check */ return (TRUE); /* ob_spec pointer */ switch (type) { case G_IMAGE: trans_bitblk(obspec); /* Transform image */ return (TRUE); case G_ICON: /* Load icon size */ hl = LWGET(IB_HICON(obspec)); wb = (LWGET(IB_WICON(obspec)) + 7) >> 3; /* Transform data */ if ( (taddr = LLGET(IB_PDATA(obspec))) != -1L) vdi_trans(taddr, wb, taddr, wb, hl); /* Transform mask */ if ( (taddr = LLGET(IB_PMASK(obspec))) != -1L) vdi_trans(taddr, wb, taddr, wb, hl); return (TRUE); default: return (TRUE); } } >>>>>>>>>>>>>>>>> Macro definitions for the code above <<<<<<<<<<<<<<<<<< #define BI_PDATA(x) (x) #define BI_WB(x) (x + 4) #define BI_HL(x) (x + 6) #define OB_TYPE(x) (tree + (x) * sizeof(OBJECT) + 6) #define OB_SPEC(x) (tree + (x) * sizeof(OBJECT) + 12) #define IB_PMASK(x) (x) #define IB_PDATA(x) (x + 4) #define IB_WICON(x) (x + 22) #define IB_HICON(x) (x + 24) >>>>>>>>>>>>>>>>>>>>>>>>> VDI Copy Mode Table <<<<<<<<<<<<<<<<<<<<<<<<<<<< Symbols: N = new destination pixel value (0 or 1) D = old destination pixel value (0 or 1) S = source pixel value (0 or 1) ~ = Boolean not (inversion) & = Boolean and | = Boolean or ^ = Boolean xor (exclusive-or) Mode Number Action ----------- ------ 0 N = 0 (USE V_BAR INSTEAD) 1 N = S & D 2 N = S & ~D 3 N = S (REPLACE) 4 N = ~S & D (ERASE) 5 N = D (USELESS) 6 N = S ^ D (XOR) 7 N = S | D (TRANSPARENT) 8 N = ~ (S | D) 9 N = ~ (S ^ D) 10 N = ~D (USE V_BAR INSTEAD) 11 N = S | ~D 12 N = ~S 13 N = ~S | D (REVERSE TRANSPARENT) 14 N = ~ (S & D) 15 N = 1 (USE V_BAR INSTEAD) ------------------------------------------------------------------------- ST REPORT CONFIDENTIAL ====================== Sunnyvale CA Sam Tramiel will press for continued upswing in ------------ activity at Atari by personally overseeing all PR releases for accuracy. New York NY Atari will be showing a number of new products at the ----------- Comdex show this fall. The rumor mill has it just the opposite ....why? Washington DC The show was a success but why the NO SHOWS?? Migraph ------------- Astra, Alpha etc.... Rockville MD GEnie Online Services has awarded Gadgets by Small ------------ it's own Roundtable. Congratulations Dave! It will open in a few days. Toronto CA Seems a Beta Copy of Calamus got loose and is now in ---------- the US even with a translation of the RSC file! From what we have seen, the "other DTP packages" had better watch out, this one is ULTRA SUPERB. Orem UT Word Perfect Corp. has announced through Jeff Fowler, ------- that Version 4.1 will be the FINAL release of the ST VERSION. Hmmm, here we go again! ARRRRG! Sunnyvale CA Watch for all the ST units to be shipped with "mega" ------------ type cases and keyboards. Long Island NY Magic Shadow Archiver will process a "boot" disk so it -------------- can be arced and sent over the modem, unarced and processed and be as good as the original. Look for this program it is shareware! ------------------------------------------------------------------------- INSIGHT into the ST'S FUTURE ============================ Part III - Software ------------------- by Micheal Arthur Of course, NO computer has a future without innovative software. PC-Ditto is an example of how innovative ST software can be, and has also had a great effect on the ST market. Right now, it is about 80 percent as fast as an 8086 chip, only in SOFTWARE. Avant Garde is upgrading PC-DITTO, though, so it will be JUST as fast as the 8086 chip. Meaning that it, a $90 product, will be just as good as the Amiga Bridgeboard, a $590 product. But Commodore is making a new Bridgeboard, having the 286 chip inside, and although it will probably not support OS/2, it WILL support other 286 specific programs, like Windows/286,(A new version of Windows custom made for the 286 chip, intended to replace Windows 2.0)and will be MUCH faster, at 10-12 MHZ. Although PC-Ditto will run at a similar speed with Turbo ST, it won't have much room for improvement after the update in December. So Avant Garde might take either of two paths: 1) Make a 286 version of PC-Ditto, which could only effectively run with Turbo ST. Although this would be logical, as well as pretty good, as it would upgrade PC-Ditto's capabilities, it would require MUCH more work, and might not be of much advantage to a lot of ST users. 2) Make a Hardware/Software combination, with most of the emulator itself in software, but having the parts that would hamper the software's performance, or could be done better in hardware in an expansion card that would go in the ST Expander. This would be more versatile than software, as it would make support of OS/2 possible, shorten the time that the emulator would take to be made and could be subject to further improvement, including built-in graphics chips letting PC-Ditto support the EGA standard with an ST Color Monitor. Avant Garde could also take a third route, deciding to make other products for the ST (Although they have said that they are a "one trick pony") or making an expansion card so PC-DITTO can use the ST's extra (above 703K) memory as LIM/EMS memory. Omnicard -------- NOT Hypercard, Omnicard. A company called BerrysBit A.S.C is planning to come with a "Hypercard-like" application, called Omnicard, at around November. This program will have an Iconic User Interface, which is now lacking in similar programs such as Zoomracks. From their announcement on GEnie: "A completely integrated software package is also available from the new desktop, including a word-processor, paint program, database, telecommmunications, mini-desktop (particularly of interest to the power user with a lot of folders), and an exceptionally easy to use program "Authoring Environment" akin to Hypercard itself." "This Authoring Environment allows the novice to begin programming in the most effective way, without him even realizing it! A card metaphor is used throughout, to heighten the Stack (We call them decks) image. If you can organize a speech, you can write a program. Buttons, icons, graphics and text replace hundreds of lines of code, that to most look like Greek!" "Optimized on a Mega 2 or above, this will be THE program for the Atari ST." In this respect, they are partly right, as Omnicard would give the ST many benefits that Hypercard has brought to the Macintosh, like a simple, but powerful programming language using the latest concepts in how computers work. While it will not be THE program for the ST, it will have a great impact, at least on how OTHER computer users view the ST. Desktop Publishing ------------------ Desktop Publishing (or DTP) products for the ST will begin to rival their IBM and Mac counterparts, as shown by the upcoming Publishing Partner Professional, and Calamus (by ISD, the makers of VIP Professional). The ST will also become a very good choice for it, as the 1280*960 monitor w/card being made in Europe makes it to the US, maybe also being sold by ISD. While the Mega ST and SLM 804 will also help the ST to further penetrate this market, the ST will never become remotely as successful in the DTP market as they have,and will continue to be in the MIDI market, as IBM and Mac products will continue to bring more performance than ST programs, causing it to only be considered in a small degree Spreadsheets ------------ Spreadsheets are the most widely used applications for computers today, and it is not coincidence that most computers setting a standard have had their first big break with a spreadsheet having features above and beyond what had been previously seen. (Lotus 123 and Excel, for examples) Even though some GOOD spreadsheets are coming out for the ST, and one in particular, LDW Power, will be better than Lotus 123 Revision Two, I don't think the ST has much chance in this area, as Lotus is making a Revision THREE of 123, and products like Wingz for the Macintosh,which OUTDO Excel, will be light years ahead of the ST, which won't have anything even half as good as Excel for a while. As ST users can just get a Spectre 128, this won't really matter if you need to use its features NOW, but that doesn't count when people consider a computer based on its own merits and applications. In fact, this might just be a "chicken and egg" problem, as ST spreadsheets as good as Excel won't come out as quickly unless more businesses buy ST's, and more businesses WON'T buy ST's if it doesn't have a spreadsheet powerful enough for them. Advertising, and Public Opinion about Atari ------------------------------------------- Contrary to opinions of a few, MOST people will NOT consider the ST based on the rational, "Is it a good computer, with good applications out for it at a decent price?", but will most likely express strong reservations towards the ST. NOT because they have anything against it, but simply because of the belief out there that an Atari is not really a computer. While this is an OBVIOUS fact to almost ALL ST Enthusiasts, it seems that some people at Atari do not seem to realize that the general consensus of opinion is that the name Atari stands for "Good Game Machines". Thanks to the Atari 2600, and the Arcade Machines that Atari Games (the only part of Atari still owned by Warner Brothers) is noted for. And usually, the ONLY way to completely cure a bad PR problem is to do the ONE thing that Atari has not said they will do, the MAIN thing that Apple did to make the Macintosh popular among IBM users, who never before saw a need for anything other than DOS, the MAIN thing that caused the C-64 to become the second best selling microcomputer of ALL TIME, and one of the things that Commodore has said they WILL do for the Amiga. ADVERTISE. And NOT just in ST Magazines, where the readership ALREADY owns Ataris. I am NOT suggesting that Atari start a major advertising campaign when they are obviously not ready to meet the demand that it would bring, but I DO suggest this: That Atari start advertising,at least on a small scale,with a few good ads on TV for the ST, or with a few good business-related ads in computer magazines such as Byte. When the Atari Factory starts up next year, and Atari WILL be able to meet the demand that advertising will bring for the ST's, then Atari will probably start a major advertising campaign. Their main focuses should (and probably will) be: 1) In TV advertisements, to educate the American public about the ST's capabilities, and to FIX the perception that Atari is just a Game Machine company. 2) To start advertising in business-related publications, emphasizing the ST's raw power with the good products now out for it, while showing the option of using Mac software. IBM applications won't be emphasized so much, as PC-Ditto is only as fast as an IBM PC. 3) To support large-scale advertisements of ST software products. 4) In the Educational Market, advertising HEAVILY to both Universities directly,trying to displace the trend of using Macs and IBMs there, and to publications that deal with this market, with ads showing its superiority to the Apple II series. To better aid this, though, Atari MUST support ST software developers in making products for this segment of the market, as well as supporting a network of educational dealers, who would already have been full-service ST dealers, but who would have a staff specifically targeted for the needs of this market. Commodore has already begun to do this with the Amiga. IF Atari is smart, they will also give GOOD Educational Discounts and Specials to Schools for the ST, maybe having a 520 or 1040 ST with Color Monitor and a package of several good pieces of educational software, for a price of under 1000 dollars, directly competing with the Apple IIgs. Also, Atari's problems with "Atari Bashers" will definitely decrease SOON, maybe even STAYING at a tolerable level if Atari makes sure that the Atari Factory is open before December. Also, Atari will be MUCH more open to suggestions in the future. The Atari Factory ----------------- Of course, ANY plans that Atari makes must be dependent on the ability to manufacture these products, as experienced business executives know that you cannot successfully come out with a product that will be VERY popular unless you have a decent manufacturing base to meet the demand. Seeing this, Atari plans to make a manufacturing plant in the US, to be in Houston, Texas. This plant will primarily attend to the demands of the US ST market, and will probably preclude any advertisements by Atari. IF Atari is smart, they will seriously consider making their OWN RAM chips for the ST in THIS factory. Not only would making their own RAM chips be less expensive than buying them, in ANY RAM market, but the import fees of things made in Europe and Japan are generally more than the price of importing things from the US there. However,they haven't yet gotten the facilities, and it will probably not be producing ST's or ST peripherals with it until the beginning of next year. This would be a disaster, meaning that there would be little to no advertising for the Atari ST during most of the Christmas season. Also meaning that the momentum generated by the new ST computers/peripherals would be a fraction of what it could be. And Commodore plans to advertise HEAVILY for the Amiga, both coming out with new Amiga products (like the 286 Bridgeboard) and advertising to sell Amiga 500's in the home and educational markets. Miscellaneous ST Info --------------------- Here are the addresses and phone numbers for info on some of the products previously mentioned: OmniCard BeerysBit ASC,Inc; 8174 Century Circle East #8 Indianapolis, In 46260 (317)872-8622 Spectre 128 Gadgets By Small, Inc. 40 W. Littleton Blvd., #210-211 Littleton, Colorado 80120 (303)791-6098 Turbo ST, ST Expander Megabyte Inc. 109 W. Bay Area Webster, Tx 77598 (800)255-5786 (A little sidenote on this; Megabyte Inc.'s 800 Number is VERY GOOD, superlative in fact, having people who KNOW a LOT about their products, and who are VERY courteous. THIS should be the model for ALL companies, ST or otherwise, to follow, as even the LONG DISTANCE numbers of some companies tend to bring less than preferable service.) ------------------------------------------------------------------------- GEM Multi-Tasking ----------------- 30-Sep-88 20:50:31 Sb: #111893-#Farewell Fm: JOHN RULEY 76227,117 To: Neil Harris 73256,3275 (X) I just got the word that I can let the cat out of the bag NOW: I spent last weekend at DRI in Monterey. GEM multitasks. Read that again: GEM MULTITASKS! No compromises - and a *nice* interface, with multiple "virtual consoles", each of which can hold several windows. Desk accs are gone - but, then again, they really aren't. The DESK menu still has 6 positions for application names, which can be used to launch any GEM app as if it was an accessory. This is all running RIGHT NOW - I saw it work. And here are two biggies: I saw it running on a Hercules monochrome system (720x348 BW graphics) and it was updating as fast as the graphics would allow WITH FOUR WINDOWS OPEN, and you can run DOS programs in it! It traps the screen I/O and displays inside a window - I saw WORDSTAR running on screen concurrently with GEM output. Folks - it's a whole new ballgame! John. ------------------------------------------------------------------------- a short but sad note... WORD PERFECT & ATARI ==================== a few words from: Jeff WILSON, Word Perfect Corp ....Once again, the situation has changed, probably for the last time for a while. I will still be working on the ST, but at this point primarily to support and enhance the existing version of WordPerfect. New major versions of WordPerfect and other products have been placed on hold for primarily one reason: WordPerfect Corporation has watched the presence of Atari Corporation in the US marketplace significantly diminish over the last year. Atari has reduced the number of dealers supporting them, and been allowing only a minimal number of ST's into the US marketplace, has failed to support dealers, developers, or Atari owners, and has, quite frankly, lost WordPerfect Corporation's faith. WPCorp will not commit itself to several years worth of R&D for a market in this condition. The hold will probably remain in effect until Atari market conditions change significantly. This is not an official statement, but I will not misrepresent the current state of affairs. As a die-hard Atari fanatic, it disappoints me terribly to have come down to this. However, from a business standpoint, I understand and agree with the decision. I hope that WordPerfect Corporation will be able to complete and release the many exciting projects that have been underway since the release of WordPerfect 4.1 for the Atari, but this will only happen on the condition stated above. We will continue to fully support 4.1 for the Atari, in fact, you will probably see enhancements that would not have come about any other way. Jeff R. Wilson ------------------------------------------------------------------------- THIS WEEK'S QUOTABLE QUOTE ========================== READE'S LAW ----------- There are two sides to every argument, unless I am personally involved, in which case there is only one..MINE! ------------------------------------------------------------------------- ST-REPORT Issue #55 OCT. 03, 1988 (c)'88 APEInc. All Rights Reserved. Reprint permission granted except where noted in the article. Any reprint must include ST-Report and the author in the credits. Views Presented herein are not necessarily those of ST-Report or of the Staff. All items and articles appearing in ST-REPORT are copywrite (c)APEInc. -------------------------------------------------------------------------