Fujiology Archive

home *** CD-ROM | disk | FTP | other *** search

/ Fujiology Archive / fujiology_archive_v1_0.iso / !MAGS / STREPORT / STR060.ZIP / STR060.TXT < prev

Wrap

Text File | 1988-11-12 | 54.1 KB | 1,196 lines

ST REPORT WEEKLY ONLINE MAGAZINE -------------------------------- Monday, NOV. 31, 1988 Vol. II No. 60 ========================================================================== ST Report Online Magazine Inc. ------------------------------ Post Office Box 6672 Jacksonville, Florida 32236 6672 R.F. Mariano Publisher - Editor ====================['The Original Online ST Magazine']=================== Headquarters Bulletin Boards ---------------------------- North South 201-343-1426 904-786-4176 Central West 216-784-0574 916-962-2566 ======================================================================= CONTENTS ======== ~ From the Editor's Desk.............~ The Melting Pot Runneth Over.. ~ DC Atari FEST......................~ Pro GEM Windows #11........... ~ The Archival Bit...................~ A New Blivitt!................ ~ ST REPORT CONFIDENTIAL ............~ PC Pursuit Help............... ======================================================================== AVAILABLE ON: COMP-U-SERVE ~ DELPHI ~ GENIE ~ THE SOURCE ======================================================================== From the Editor's Desk; Some folks said, "you have too much editorial content in ST Report" and I tended to agree with them. However, after reviewing the situation a number of times, this conclusion has been reached. ST Report is looked to for hard hitting information. Being up to date, as accurate as humanly possible and timely. We are concerned mainly with the Atari ST market and just about everything that occurs in that market. Sure, we ARE critical of Atari when they obviously need it. On the other hand, we are the first to pass out compliments when deserved. We will not "sugar coat" any situation or soft peddle any issue. ST Report pledges to bring you, the Atari user, the most up to date, accurate, information possible. In another development, we at ST Report have heard that the userbase in general is an easily confused group of users. We discovered that this is one of the totally inane reasons given by Atari, when asked, why they didn't incorporate more of the fine features seen in the UIS file selector in the new TOS 1.4. After having stated this, they then come along with this as the second reason "There is absolutely no room"....they really do think we are idiots and boobs out here! That is not an excuse, it is an admission of incredible "tunnel vision"! If one were to "look" at two locations in the TOS 1.4 code, one can find "room", ($FCF716 and $FD2404). To selfishly consume valuable space to "hide" love notes in TOS is the same to me as carving your initials in your desktop at 4th grade school. Also, TOS could be converted to Machine Language (ML) it would then become (A) much faster, (B) much smaller in size, thus allowing for further first class enhancements it so desperately needs. Some have called UIS a kludge, I say that if Atari were to incorporate it's DELUXE and needed features into TOS 1.4, it would be called a STROKE OF GENIUS. Ralph..... As we approach another Christmas Holiday, Atari is prepared to miss the boat again. No real quantities of ST product for sale in the USA. What fantastic corporate leadership and planning! And you thought that the Katzenjammer Kids were only cartoon characters. ************************************************************************** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE FOR A LIMITED TIME ONLY COMPUSERVE WILL PRESENT $15.00 WORTH OF COMPLIMENTARY ONLINE TIME to the Readers ST REPORT ONLINE ELECTRONIC MAGAZINE NEW USERS SIGN UP TODAY! Call any of the St Report Official BBS numbers (Listed at the top of ST REPORT) or Leave E-mail to St Report, Ron Kovacs or Rex Reade Be sure to include your full mailing address so your Compuserve kit can be immediately mailed to you! Expires 11-30-88 NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ************************************************************************** So, you'd like to tell that guy Rex Reade a thing or two Eh? ------------- Spend an evening with ST Report, ask the questions you would like answered, find out what motivates ST Report, become informed. YOU WILL HAVE YOUR CHANCE! -------------------------- NOVEMBER 09, 1988 WEDNESDAY, 8 P.M. EST COMP-U-SERVE CONVENTION CENTER All are invited to Attend -------------------------------------------------------------------------- THE MELTING POT RUNNETH OVER ============================ by Rex Reade This is the time of the year when speculation runs high and facts seem to become obscure amid the dreams and hopes for the future. That is the limbo of the days prior to Fall Comdex every year. Obvious by their absence in the Comdex Preview is Atari, Why? easy....they registered too late to make it into the preview, not even into the maps and directions on how to find an exhibitor. Great planning at the corporate level, (outstanding guys). You do know Atari had no plans to attend the Fall Comdex earlier this year. It seems some voice in the distance said "Hey Atari, wake up the whole country is WATCHING you and what you do this year". Developers, Distributors, Dealers, Usergroups and Users have long been known to be the life blood of any company doing business directly with the consumer. Every major, well organized, corporation will readily admit that each is a vital component in the formula for success. Does Atari? Apparently not.. Consider these latest moves: ---------------------------- A) Atari routes a huge percentage of it's ST product to Europe thus justifying Developer "dropout" in the USA. B) Atari drops the "Houston Project" thus indirectly confirming the often percieved, "Lack of true corporate leadership and direction in the USA." I feel sorry for all the Houston Dealers who, in the past few months were "busy" singing the praises of Atari. This could go on and on, but that is not the point here, the point is this; Atari needs: A) A Professional Marketing Department. B) A full National Sales Department. C) A REAL National Service Organization. D) Corporate Leaders, not the Katzenjammer Kids who appear to SEE the company like its a HOBBY! E) TO DEVELOP THE US MARKET PROPERLY F) TO Recognize the signs, look at Atari in Europe and Canada, they ARE successful WHY??.. the handwriting is on the wall guys.. GET PROFESSIONAL LEADERSHIP. Nota Bene: --------- The "get even" attitude or the "suit" happy attitude is going to be the ruination of a good thing. Any time a "for profit" venture falls in the hands of the barristers, serious problems are afoot or in store for the future. Atari DRAM supply is about to go down the tubes, remember when everybody was gloating about the alledged upper hand had with Micron? Remember the boasting about how the ST in Europe was kicking the a** of a certain computer in it's own backyard? Read on Bunky, this is what hard nosed legal beagle bargaining can get you......Amstrad has bought into Micron Technologies on a rather heavy scale, guess who supplies DRAM to our favorite company. What's that about; "Turn about is fair play???" ....When will Katzenjammer be controlled and real leadership LEAD? as the Fuji turns...will continue -------------------------------------------------------------------------- D.C. ATARIFEST ============== by Bruce Hansford Editor, MVACE The Washington (DC) Area Atari Computer Enthusiasts, a cooperative of several DC-area Atari user groups, sponsored their fourth annual Atarifest on the 1st and 2nd of October... and WE WERE THERE. The MVACE caravan consisted of myself, Doug Hodson, Ken Lare, Dan Steffen, Boyd Bradford, Ashish Ranpura, George Baker, Michael McHale, and Ray Hendrix, traveling in two vehicles connected by walkie-talkies. Whew! What a trip! The Fest itself was not all that impressive. I really expected more; I think the Detroit Atarifest last year was better. After talking to the show's organizer, I began to realize why it wasn't so great. One reason was that they used a school and had to follow special rules established by the city of Fairfax. They also didn't allow enough time for notification of dealers and developers. The best part of the show for me was the fact that David Small had his newest product, SPECTRE 128, available for sale there, (I got mine!) and the 128K Mac ROMs were available also (I got mine!). Another aspect that stands out was meeting Brian Sarrazin, Vice President of SoftLogik, who was showing the "final release" version of Publishing Partner Professional. He said that they were just waiting for the documentation to get back from the printers before sending out the upgrades and releasing the package to distributors. -------------------------------------------------------------------------- ANTIC PUBLISHING INC. COPYRIGHT 1988 REPRINTED BY PERMISSION. PROFESSIONAL GEM by Tim Oren Column #11 - GEM Hooks and Hacks, An Insider's AES Tricks Welcome to the eleventh episode of ST PRO GEM, which is devoted to exploring some of the little documented, but powerful, features of GEM. Like the authors of most complex systems, the GEM programmers left behind a set of "hooks", powerful features which would aid them in enhancing the system later. I am going to lay out a number of these methods which have served me well in making creative use of the AES. You will find that most of them concern the object and form libraries, since I was most involved in those parts of GEM. There are probably many more useful tricks waiting to be found in other parts of GEM, so if you happen onto one, please let me know in the Feedback! POWERFUL OBJECTS. The first four tricks all involve augmenting standard AES objects. This is a powerful technique for two reasons. First, you can take advantage of the regular AES object and form libraries to draw and handle most of your objects, so that your program need only process the exceptions. Second, you can use the RCS to copy the special objects into multiple dialogs or resources. These four tricks are Extended Object Types, User-defined Objects, TOUCHEXIT, and INDIRECT. Let's look at each of them in turn. EXTENDED OBJECT TYPES. If you look at the AES Object Library documentation, you will notice that the values for the OB_TYPE field in an object are all 32 or less. This means that a number of bits are unused in this field. In fact, the AES completely ignores the top byte of the OB_TYPE field. In addition, the RCS ignores the top byte, but it also preserves its value when an object is read, written, or copied. This gives you one byte per object to use as you see fit. Since the processing of an object or dialog is (so far) in the hands of the AES, the best uses of Extended Types are in flagging methods for initializing an object or handling its value when the dialog completes. For example, you might have several dialogs containing editable numeric fields. The Extended Type of each numeric field could be set to the index of the corresponding value in an array. Then your application's dialog initialization code could scan the object tree for such objects, pick up the appropriate value from the array and convert it to ASCII, storing the result in the resource's string area. When the dialog was finished, another pass could be made to reconvert the ASCII to binary and store away the results in the array. (Note that the map_tree() utility from column #5 will scan an entire resource tree.) Another application is to assign uniform codes to exit buttons in dialogs. If you give every "OK" button an Extended Type of one, and every "Cancel" button an Extended Type of two, then you needn't worry about naming every exit object. Just examine the Extended Type of the object returned by form_do, and proceed accordingly. The catch, of course, is that you have to find a way to enter the Extended Type code in the first place. Version 1.0 of the RCS, as shipped with the Atari developer's kit, makes no provision for this. So you have your choice of two methods for creating the first object with each Extended Type code. First, you can dump out a C source of a resource, insert the new type code by hand, and regenerate the resource with STCREATE. Alternately, you could carefully modify the binary resource using SID. You will probably want to reread the AES object manual, ST PRO GEM #4 and #5, and use the C source as a guide when doing so. In both cases, you should make things easy on yourself by creating a one dialog resource with only a single object other than the root. Version 2.0 of the RCS will let you directly enter an Extended Type, but it has not yet been released for the ST by DRI. Once you have created a prototype extended object by either method, you can use the RCS to propogate it. The safest way is to use the MERGE option to add the modified tree to the resource you are building. Then copy the prototype object via the clipboard to your dialog(s), deleting the extra tree when you are done. If you are using several different extended objects, you can use MERGE and clipboard copies to get them all into one tree which will then become your own object library. The second way of using RCS is easier, but more dangerous. If you want to try the following technique, BACK UP YOUR RCS DISK FIRST! Put simply, the RCS does not care what is in its dialog partbox. It will make copies of anything that it finds there! This gives you the option of using the RCS on ITS OWN RESOURCE in order to add your customized objects to the partbox. To do this, open RCS.RSC from the RCS. Since there is no DEF file, you will get a collection of question mark icons. Use the NAME option to make TREE5 into a DIALOG. Open it, and you will see the dialog partbox. Now you can use the MERGE technique described above to insert your customized objects. Then SAVE the modified resource, and rerun the RCS. Your new objects should now appear in the partbox. If you added several, you may have to stretch the partbox to see them all. You can now make copies of the new objects just like any other part. (Note: DO NOT modify the alert or menu partboxes, you will probably crash the RCS.) USER-DEFINED OBJECTS. The one type of object which was not discussed in the earlier articles on AES objects was G_USERDEF, the programmer defined object. This is the hook for creating objects with other appearances beyond those provided by the standard AES. By the way, you should note that the G_PROGDEF and APPLBLK mnemonics used in the AES documents are incorrect; the actual names as used defined OBDEFS.H are G_USERDEF and USERBLK. The RCS does not support the creation of G_USERDEF objects, since it has no idea how they will be drawn by your program. Instead, you must insert a dummy object into your resource where you want the G_USERDEF to appear, and patch it after your application performs its resource load. You must replace the object's existing OB_TYPE with G_USERDEF, though you may still use the upper byte as an Extended Type. You must also change the OB_SPEC field to be a 32-bit pointer to a USERBLK structure. An USERBLK is simply two LONG (32-bit) fields. The first is the address of the drawing code associated with the user defined object. The second is an arbitrary 32-bit value assigned to the object by your application. You can designate objects for conversion to G_USERDEFs in the normal fashion by assigning them names which are referenced one by one in your initialization code. You can also combine two tricks by using the Extended Type field as a designator for objects to be converted to G_USERDEF. Each tree can then be scanned for objects to be converted. There is a short code segment in the download which demonstrates this technique. My usual convention is to define new drawing objects as variants of existing objects, using the Extended Type field to designate the particular variation. Thus an Extended Type of one might designate a G_BUTTON with rounded corners, while a value of two could flag a G_STRING of boldface text. When using this technique, the RCS can be used to build a rough facsimile of the dialog by inserting the basic object type as placeholders. The existing OB_SPEC information can then be copied to the second position in the USERBLK when the object is initialized. One final note before moving on: There is no reason that the USERBLK cannot be extended beyond two fields. You might want to add extra words to store more information related to drawing the object, such as its original type. The AES will call your drawing code whenever the G_USERDEF needs to be drawn. This occurs when you make an objc_draw call for its tree, or when an objc_change occurs for that object. If your user-defined object is in a menu drop-drop, then your drawing code will be called any time the user exposes that menu. Before getting into the details of the AES to application calling sequence, some warnings are in order. First, remember that your drawing code will execute in the AES' context, using its stack. Therefore, be careful not to overuse the stack with deep recursion, long parameter lists, or large dynamic arrays. Second, the AES is NOT re-entrant, so you may not make ANY calls to it from within a G_USERDEF procedure. You may, of course, call the VDI. Finally, realize that drawing code associated with a menu object may be called by the AES at any time. Exercise great care in sharing data space between such code and the rest of the application! When your drawing code is called by the AES, the stack is set up as if a normal procedure call had occured. There will be one parameter on the stack: a 32-bit pointer to a PARMBLK structure. This structure lies in the AES' data space, so do not write beyond its end! The PARMBLK contains 15 words. The first two are the long address of the object tree being drawn, and the third word is the number of the G_USERDEF object. You may need these values if the same drawing code is used for more than one object at a time. Words four and five contain the previous and current OB_STATE values of the object. If these values are different, your drawing code is being called in response to an objc_change request. Otherwise, the active AES call is an objc_draw. Words six through nine contain the object's rectangle on the screen. Remember that you cannot call objc_offset within the drawing code, so you will need these values! The next four words contain the clipping rectangle specified in the active objc_change or objc_draw call. You should set the VDI clip rectangle to this value before doing any output to the screen. The last two words in the PARMBLK contain a copy of the extra 32-bit parameter from the object's USERBLK. If you have followed the method of copying an OB_SPEC into this location, these words will be your pointer to a string, or BITBLK, or whatever. When your drawing routine is done, it should return a zero value to the AES. This is a "magic" value; anything else will stop the drawing operation. The download contains a sample drawing routine which defines one extended drawing object, a rounded rectangle button. You can use this procedure as a starting point for your own User Defined objects. PUT ANYTHING YOU WANT ON THE DESKTOP! In ST PRO GEM #2, I described the use of the WF_NEWDESK wind_set call to substitute your own object tree for the normal green desktop background. If the tree you supply contains User Defined objects, you can draw whatever you want on the desktop! Some of the things you might try are free hand drawings imported in metafile format from EasyDraw, or whole screen bit images generated by Degas. If you do the latter, you will have to store the entire image off screen and blit parts of it to the display as requested. In any case, remember that your desktop drawing code can be called any time that a window is moved, so exercise the same care as with a menu drawer. Also, be aware that making the WF_NEWDESK call does not force an immediate redraw of the desktop. To do that, do a form_dial(3) call for the entire desktop rectangle. THE TOUCHEXIT FLAG. The TOUCHEXIT attribute is an alternative to the more usual EXIT. When the TOUCHEXIT bit is set in an object's OB_FLAG word, the form_do routine will exit immediately when the mouse button is pressed with the cursor over the object. Your code can immediately take control of the mouse and display, without waiting for the release of the button. This method is used for generating effects such as slider bars within otherwise normal dialogs. The easiest way to code a TOUCHEXIT handler is to place a loop around the form_do call. If the object number returned is TOUCHEXIT, then the animation procedure is called, followed by a resumption of the form_do (WITHOUT recalling form_dial or objc_draw!). If the object returned is a normal EXIT, the dialog is complete and control flows to the cleanup code. There is one idiosyncrasy of TOUCHEXIT which should be noted. When the AES "notices" that the mouse button has been pressed over a TOUCHEXIT, it immediately retests the button state. If it has already been released, it waits to see if a double click is performed. If so, the object number returned by form_do will have its high bit set. If you don't care about double clicks, your code should mask off this flag. However, you may want to use the double click to denote some enhanced action. For example, the GEM file selector uses a double click on one of the file name objects to indicate a selection plus immediate exit. THE INDIRECT FLAG. If the INDIRECT bit is set in an object's OB_STATE word, the AES interprets the 32-bit OB_SPEC field as a pointer to the memory location in which the ACTUAL OB_SPEC is to be found. Like User Defined objects, this capability is not supported by the RCS, so you have to set up the INDIRECT bit and alter the OB_SPEC at run time. The value of INDIRECT is that you can use it to associate an AES object with other data or code. The general technique is to set up a table with a spare 32-bit location at its beginning. Then, when initializing the application's resource, you move the true OB_SPEC into this location, set the INDIRECT flag, and replace the OB_SPEC field with a pointer to the table. The object behaves normally during drawing and form handling. However, if you receive its number from form_do or objc_find, you have an immediate pointer to the associated table, without having to go through a lookup procedure. This technique works well in programs like the GEM Desktop. Each G_ICON object is set up with INDIRECT. Its OB_SPEC goes to the beginning of a data area defining the associated file. The blank location at the beginning of file table is filled up with the former OB_SPEC, which points to a ICONBLK. You can also combine INDIRECT with TOUCHEXIT when creating objects that must change when they are clicked by a user. For instance, a color selection box might be linked to a table containing the various OB_SPEC values through which the program will cycle. Each time the user clicked on the box, the TOUCHEXIT routine would advance the table pointer, copy the next value into the dummy OB_SPEC location at the front of the table, and redraw the object in its new appearance. A programmer who wanted to follow a truly object-oriented "Smalltalkish" approach could use the INDIRECT method to bind AES drawing object to tables of associated procedures or "methods". For instance, one procedure could be flagged for use when the user clicked on the object, one when the object was dragged, one for double-click, and so on. If the table structure was capable of indicating that the true method was stored in another table, a rudimentary form of class inheritance could be obtained. INSTANT CO-ROUTINES. We turn to the AES event and message system for this trick. While some languages like Modula 2 provide a method for implementing co-routines, there is no such capability in C. However, we can effectively fake it by using the AES event library. As already seen in an earlier column, an application can write a message to its own event queue using the appl_write call. Usually, this is a redraw message, but there is nothing to prevent you from using this facility to send messages from one routine in your program to another. To set up co-routines using this method, they would be coded as separate procedures called from the application's main event loop. When one of the co-routines wanted to call the other, it would post a message containing the request and any associated parameters into the application's queue and then return. The main loop would find the message and make the appropriate call to the second co-routine. If it was necessary to then re-enter the first co-routine at the calling point, the original message could contain an imbedded reply message to be sent back when the request was complete. A simple switch structure could then be used to resume at the appropriate point. There are two potential problems in using this method. The first is the limited capacity of the application event queue. The queue contains eight entries. While the AES economizes this space by merging redraws and multiple events, it cannot merge messages. Because of this limit, you must be extremely careful when one message received has the potential to generate two or more messages sent. Unless this situation is carefully managed, you can get a sort of "cancer" which will overflow the queue and probably crash your application. The second danger involves race conditions. Message sent by the application are posted to the end of the queue. If other events have occurred, such as mouse clicks or keyboard presses, they will be seen and processed ahead of the application generated message. This implies that you cannot use this method if the program must complete its action before a new user generated event can be processed. THAT'S ALL FOR NOW. Hopefully these hints will keep you profitably occupied for a while. ST PRO GEM number twelve will return to the topic of user interfaces. Reaction to the first article on this subject was mostly positive, but a lot of folks wanted to see real code as well. In response to your feedback, there will also be code for implemented your own "mouse sensitive" objects which highlight when the cursor touches them. This will be presented as part of an alternate form manager. UPDATE: ATARI ST. I have recently gotten more information on some topics mentioned in earlier articles. These notes will bring you up to date: A number of developers reported that they were unable to get the self-redraw technique described in ST PRO GEM #2 to work. This is usually due to a bug in the appl_init binding in Alcyon C. The value returned from the function, which would normally be assigned to gl_apid, is coming back as garbage. To work around the problem, declare EXTERN WORD gl_apid; in your program and DO NOT assign the value from appl_init. The binding WILL make the assignment. A tip of the hat to Russ Wetmore for this report. The last column mentioned that turning off the clip rectangle while drawing graphics text will speed things up. It turns out that the VDI will also run at the non-clipped speed if the ENTIRE string to be written is within the current clip rectangle. To compound the problem, there is a one-off bug in the detection algorithm for the right edge. That is, the clip rectangle has to be one pixel BEYOND the right edge of the text for the fast write to work. The Feedback in ST PRO GEM #10 mentioned that there are known bugs in the Alcyon C floating point library. In fact, this library has been replaced with a new, debugged version in recent shipments of the Toolkit. If you need to use floating point and have run into this bug, you should be able to get an update from Atari. Also, check the Atari Developer's SIG (PCS-57) for a possible download. In addition, it turns out there is an undocumented feature in Alcyon C which allows you to imbed assembly code in-line. Try using: asm("....."); where the dots are replaced with an assembly instruction. You get one instruction per asm(), one asm() per line. Thanks to Leonard Tramiel for both of the above tidbits. >>>>>>>>>>>>>>> Sample code for initializing User Objects <<<<<<<<<<<<<<<< GLOBAL USERBLK extobjs[MAX_OBJS]; /* APPLBLK defined in OBDEFS.H */ GLOBAL WORD n_extobjs; /* Set MAX_OBJS to total user */ /* objects in resource */ VOID obj_init() /* Scan whole resource for user */ { /* objects. Uses map_tree() */ LONG tree, obspec; /* from GEMCL5.C */ WORD itree, i, obj; n_extobjs = 0; /* Replace TREE0 with your first */ /* tree, TREEN with the last */ for (itree = TREE0; itree <= TREEN; itree++) { rsrc_gaddr(R_TREE, itree, &tree); map_tree(tree, ROOT, NIL, fix_obj); } } WORD fix_obj(tree, obj) /* COde to check and fix up */ LONG tree; /* a user defined object */ WORD obj; { WORD hibyte; hibyte = LWGET(OB_TYPE(obj)) & 0xff00; /* check extended */ if (!hibyte) /* type - if none */ return (TRUE); /* ignore object */ extobjs[n_extobjs].ub_code = dr_code; /* set drawcode */ extobjs[n_extobjs].ub_parm = LLGET(OB_SPEC(obj)); /* copy obspec */ LLSET(OB_SPEC(obj), ADDR(&extobjs[n_extobjs])); /* point obspec */ LWSET(OB_TYPE(obj), G_USERDEF | hibyte); /* to userblk & */ n_extobjs++; /* patch type */ return (TRUE); } >>>>>>>>>>>>>>>>>>>>>> Sample User Object Drawing Code <<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>> Implements Rounded Box based <<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>> on G_BOX type <<<<<<<<<<<<<<<<<< WORD dr_code(pb) /* Sample user object drawing */ PARMBLK *pb; /* code. Caution: NOT portable */ { /* to Intel small data models */ LONG tree, obspec; WORD slct, flip, type, ext_type, flags; WORD pxy[4]; WORD bgc, interior, style, bdc, width, chc; tree = pb->pb_tree; obspec = LLGET(pb->pb_parm); /* original obspec from USERBLK */ ext_type = LHIBT(LWGET(OB_TYPE(pb->pb_obj))); slct = SELECTED & pb->pb_currstate; flip = SELECTED & (pb->pb_currstate ^ pb->pb_prevstate); set_clip(TRUE, &pb->pb_xc); /* These two routines in GEMCL9.C */ grect_to_array(&pb->pb_x, pxy); switch (ext_type) { case 1: /* Rounded box */ /* Crack color word */ get_colrwd(obspec, &bgc, &style, &interior, &bdc, &width, &chc); /* For select effect, use char color */ if (slct) /* In place of background */ bgc = chc; /* Fill in background */ rr_fill(MD_REPLACE, (width? 0: 1), bgc, interior, style, pxy); /* Do perimeter if needed */ /* rr_perim is in GEMCL9.C */ if (width && !flip) { pxy[0] -= width; pxy[2] += width; rr_perim(MD_REPLACE,bdc,FIS_SOLID,width,pxy); } break; default: /* Add more types here */ break; } return (0); } VOID /* Cracks the obspec color word */ get_colrwd(obspec, bgc, style, interior, bdc, width, chc) LONG obspec; WORD *bgc, *style, *interior, *bdc, *width, *chc, *chmode; { WORD colorwd; colorwd = LLOWD(obspec); *bgc = colorwd & 0xf; *style = (colorwd & 0x70) >> 4; if ( !(*style) ) *interior = 0; else if (*style == 7) *interior = 1; else if (colorwd & 0x80) /* HACK: Uses character writing mode */ *interior = 3; /* bit to select alternate interior */ else /* styles! */ *interior = 2; *bdc = (colorwd & 0xf000) >> 12; *width = LHIWD(obspec) & 0xff; if (*width > 127) *width = 256 - *width; if (*width && !(*width & 0x1)) /* VDI only renders odd */ (*width)--; /* widths! */ *chc = (colorwd & 0x0f00) >> 8; /* used for select effect */ } VOID /* Fill a rounded rectangle */ rr_fill(mode, perim, color, interior, style, pxy) WORD mode, perim, color, style, interior, *pxy; { vswr_mode(vdi_handle, mode); vsf_color(vdi_handle, color); vsf_style(vdi_handle, style); vsf_interior(vdi_handle, interior); vsf_perimeter(vdi_handle, perim); v_rfbox(vdi_handle, pxy); } -------------------------------------------------------------------------- ___________________________ | SUPPORT YOUR LOCAL BBS | --------------------------- THE BUMPER STICKER FOR ALL BBS USERS! 3 1/2" X 11" Blue Letters on White Vinyl --------------------------- $3.75ea. - 2 for $7.00 postage and handling Incl. Linda Woodworth 4604 East 16th Street Cheyenne, WY. 82001 -------------------------------------------------------------------------- THE ARCHIVAL BIT ================ As a service to our readers we include here a grouping of statements made by the President of Atari Sam Tramiel, at the CIS Presidential Conference a few weeks ago.... We present these as a "record" for all to use as reference to see if in fact, these things come to pass or just pass on. Also, we took the liberty to comment where we felt it appropriate. "At present I think that we are shipping all the models (shown at the fall COMDEX last year) in Europe, even the Abaq, to developers. We will start shipping in earnest to the US market in early 1989, including the ST and the line of PC compatibles and our new members of the ST family. The Abaq is now called the ATW (ATari Work station)." STR NOTE: You "THINK", aren't you SURE? "We just signed a major deal with a big Dram supplier and the situation will get better I hope in early 1989." "We have already published the details of new TOS (ver 1.4) to developers and will do so for the rest of the users when it is released. We are working on the TT (the 68030 system), and hope to show it in early '89. Until then, no further comments on the TT... but it will knock your socks off! :-) " "We feel that advertising without product availability is helpful in selling our competitors' machines and therefore, will just waste money. As far as a national computer chain is concerned, we are already diverting machines to the US and ship them to our few but loyal ST dealers." STR NOTE: Advertise the software available and display the machines at the same time, thus keeping the interest level high. Show support to the developers of software for the ST..thats the kind of advertising you could be doing at this time. Stop suffering from the CHEAPS! "We agree that the Atari 8-bit line is the best available. However, the US market seems to want more powerful machines. We are selling many tens of thousands of the XE/XL line in Europe, and in the middle east, and in Latin America. We are trying to push the XE Game System in the US as a computer and a game for the same price as the Nintendo with an exercise mat. (i.e. $149)" "By the way, there is now a fifty dollar rebate on the XE Game machine." {Portable ST - Fact or Fiction} "Fact. We are working on it, and will ship it as soon as it is ready." "...we plan for Atari to be number two or number three in the world personal computer market and we hope to make the ST one of the standard machines in the US during 1989. I would prefer not to comment on details of future ST or TT machines at present." "I appreciate the support of all of you, and I really hope that in 1989, you will not be such a minority in the US personal computer world. It is a pleasure to see Atari so successful in Europe and I'm sure that with more DRAM as we expect in '89, we will be able to be successful in the US as well. Good night." NOTE: Then we all woke up and saw the real questions go unanswered! We purposely left out the part where Sam told the US Developers to go sell their products in Europe. That "GEM" was just too revolting to bring up again. Better he should get product on the US Dealer shelves instead of trying to sway the developers to turn to Europe. Hey Sam, read YOUR address at least once a day, it SEZ: "U.S.A.!" ------ ------------------------------------------------------------------------- ABCO COMPUTER ELECTRONICS INC. P.O. Box 6672 Jacksonville, Florida 32236-6672 904-783-3319 HARD DISK SYSTEMS TO FIT EVERY BUDGET ------------------------------------- 20mb #SG20510 519.00 30mb #SG32610 649.00 40mb #SG44710 789.00 65mb #SG60101 949.00 80mb #SG840110 1019.00 130mb #SG3A1210 1449.00 larger units are available - (special order only) *** Available for ST - Amiga - Mac - IBM *** 6 month Guarantee followed by 6 month Parts & Labor Warranty (under normal usage) -------------- ------------------------------------------------------------------------- A NEW BLIVITT! ============== From "Computer & Software News" Dated: Oct. 1988 "It looks like ATARI may bring out a 68030-based computer at COMDEX. The base unit of the system, aimed at getting the company into the workstation business, will have a price tag of about $2,000, and will be targeted at the education, scientific and engineering markets, a la Steve Jobs' Next. The ATARI machine reportedly will feature a 1280-by-960 pixel screen with 8-bit gray-scale, a Motorola 56000 digital processor for up to eight channels of 16-bit sound, and a 1.44-Mbyte, 3.5-in. floppy disk drive. It will also have four VME expansion slots which will allow it to accomodate add-in boards that fit in Apollo and Sun workstations, sources explained." -------------------------------------------------------------------------- ST REPORT CONFIDENTIAL ====================== Sunnyvale, CA The real hope for Atari lies in the first and second ------------- quarters of 1989, with the real push on for the second quarter. NYC, NY Amstrad has bought into MICRON which means after the ------- initial committment to Atari is fullfilled, there will be NO MORE Dram chips for Atari from them. Phoenix, AZ Atari is once again BACK ORDERED ON SC1224 and you ----------- can forget getting ANY 1040 STs! It is suggested that you use the Magnovox monitor as it is the closest to SC1224 performance. Dealers are being forced to upgrade 520stfm units to 1mb in the field. Las Vegas, NV Will Comdex be the shot that's heard 'round the ------------- world? According to some informed sources if Poppa Jack holds the KATZENJAMMER KIDS in check, Atari could quite possibly do well in the Public Relations Dep't. Sunnyvale, CA "Rumor" has it, that the centerpiece of Atari's ------------- Comdex show will be the Laptop, also an elaborate Desktop Publishing Display will be in action. NYC, NY Insiders at the "market" are very skeptical of the ------- remark: "Watch Atari in the first 2 quarters of 1989". We have heard all that before. they said. St. Louis, MO Page Stream, the "new" name for Publishing Partner ------------- Professional has been released. As always, with "new" programs, it is experiencing some slight problems. According to one reviewer, the 20 some odd "listed" quirks (bugs) are soon to be hit with raid and "all" will be ok. This is a DTP program that, if it's problems are ironed out, will be the top US DTP program. Los Angeles, CA FEDERATED, the ATARI owned and operated chain of --------------- stores west of the Mississippi, has more Commodore AMIGA 500s is their stores than they do of Atari computers is this another "coup" for ATARI? ------------------------------------------------------------------------- Atari ST GFA-BASIC 3.1 ====================== The original version of GFA BASIC was released in June of 1986 to rave reviews in all the major computer publications. Even the often cynical programmers were impressed by the speed of this new language, the command vocabulary and the structured programming. At last a way for every owner to unleash the powerof their ST! Early in 1987: The GFA BASIC Compiler became available. The already fast programs became even faster. The compiled source code made professional software development a possibility, and several products, ranging from game programs to productivity utilities were introduced by professional programmers. Version 2.0 of GFA BASIC implemented compiler commands, and was delivered in October of 1986. During the past two years, over 50,000 copies of the GFA BASIC Interpreter, and 20,000 copies of the GFA BASIC Compiler have been purchased world wide. A New Standard GFA BASIC, Version 3.0 was first shown to the general public at CeBIT the world's largest consumer computer show, in West Germany. Again, GFA BASIC has astounded the computer world. With over three hundred new commands and an enormous increase in speed. Tests have indicated speed increases ranging between 40 and 60 percent over the previous version of GFA BASIC. Once again GFA BASIC is setting new standards! Compatibility Even more important to the many present user's of GFA BASIC, Version 3.0 remains compatible. You can still use all of the existing GFA- BASIC programs and books. The huge library of public domain GFA BASIC programs has just been improved! ALL programs will benefit from the improvements in the latest version of GFA BASIC. New Editor The editor in the previous version of GFA BASIC has been highly praised. Automatic syntax checking, and the interactive programming environment made program development a snap. But, even something this good can be improved. One of the more impressive features is the ability to "hide" procedures. Once a procedure has been debugged, the programmercan "hide" it. Only the procedure name is shown in the listing. This makes your visible code more readable. No longer will it be necessary page through screen after screen of procedures. Just view the names, expanding them as needed to review the contents. There's also more help in editing your programs. Now with just a key stroke, characters above the normal ASCII-Code can be input into your program. The new GFA-BASIC Editor also includes a larger number of keyboard implemented commands. Other useful new features include: a clock in the menu field, up to 10 editor-marks may be placed in your program, and a line counter is included. More Power! There isn't enough room here to list all the possibilities of GFA BASIC 3.0, but here are a few of the new functions: -- All AES functions have been implemented -- Additional functions for management and handling of objects -- Structures -- Line-A commands are now supported -- Joystick commands -- Case distinction (SELECT-CASE and ELSE-IF) -- Multiple line functions in addition to assigned parameters -- Variable parameters are also possible- -- Many bit operations have been implemented (move, rotate, bit test, erase, set, change) -- Fast Integer operations -- And much more! Atari ST GFA-BASIC 3.1 For ALL Atari ST Computers By Frank Ostrowski MICHTRON, Inc. 576 S. Telegraph Pontiac, Mi. 48053 Phone (313) 334-5700 ------------------------------------------------------------------------- INTERLINK PC Pursuit Help By: Randy Mears Until INTERLINK ST is upgraded to contain a script language (and it will be so upgraded) you can get around quite well in PC Pursuit without one. The first thing you need to do is create a special Phone File for your PC Pursuit dialing. The primary difference between this file and a normal Phone File is that the Modem Parameters are changed to disable the Hang-Up and increase the timeout values. This will allow you to use the standard dialer buttons to dial numbers within a given area. You can even use the group dialing capability to check multiple numbers within that area. In addition, function key definitions that will allow you to disconnect from your current area and connect to a new area need to be defined so that you can easily move from one area to another. And, finally, a recording that will allow you to continuously retry area dialing until you get a CONNECT rather than those all too familiar BUSY's. Enclosed in this archive is a sample PC Pursuit Dial File (PCDIAL.DAT). You can load it into INTERLINK as a Phone File and create your own function keys using the model contained in the Control/F10 Function. Just insert the desired area code and your userid and password. If you desire automatic retry keys add this string to the end of your area call function ````^nn where nn is the function number (1-20) of the key being defined. This will cause the key to be repeated after a 12 second pause. When you get connected you can break out of this loop by pressing a function key that has nothing defined (I use ALT/F2). You can break out of this loop manually or, you can use the enclosed recording to do it automatically. In versions of INTERLINK below 1.74 you must start the recording after you initiate function key processing (sorry about that bug), in later versions you can start the recording and then press the function key you desire or change to another function key mid-stream. Don't forget to save this new Phone File with some other name than your normal one! The recording is called PCCOD.REC. It waits forever for a CONNECT from PC Pursuit and, upon getting one, breaks the Function Key loop by pressing ALT/F2 (important that you leave it blank) and sending ATZ<cr> to PC Pursuit. It plays the completion tone to let you know that you have connected. I use this technique constantly on PC Pursuit and find that I can move around quickly and find lots of Boards to connect to. It is convenient to add the required Area Code for a given board to its NAME description in the dialer window. This way you know what area is needed for a given board. You may just want to make a different Phone File for each area but I tend to put about 4 areas per Phone File and have about 6 such files descriptively named. Hope the enclosed files and information have been of help in your PC Pursuits. If you would like further information or clarification please feel free to call our BBS at (813)924-4590. It will be a long distance call for most of you so we try to answer your questions within 24 hrs. -------------------------------------------------------------------------- THIS WEEK'S QUOTABLE QUOTE ========================== BUG-A-BOO --------- In any collection of data, the figures that are obviously correct beyond all need of checking, contain all the errors! ------------------------------------------------------------------------ ST-REPORT Issue #60 November 07, 1988 ALL RIGHTS RESERVED (c)copywrite STR Inc. ------------------------------------------------------------------------ Any reprint must include ST-Report and the author in the credits. Views Presented herein are not necessarily those of STR Inc. or APEInc. COMMERCIAL ONLINE SERVICES MUST HAVE WRITTEN PERMISSION to offer ANY APEInc. REPORT and/or ZMAG in any form. -------------------------------------------------------------------------