Otherware

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

/ Otherware / Otherware_1_SB_Development.iso / amiga / info / amrep204.lzh / AMREPORT-2.04

Wrap

Text File | 1992-06-01 | 58.5 KB | 1,355 lines

*---== AM-REPORT INTERNATIONAL ONLINE MAGAZINE ==---* """"""""""""""""""""""""""""""""""""""" "The Online Magazine of Choice!" from STR Publishing Inc. """""""""""""""""" May 31, 1992 Volume 2.04 ========================================================================= > 05/31/92: AM-Report #2.04 The Online Magazine of Choice! -Amiga on TV -Amiga in Print -Programming Tutorials -Northgate Sold -Mitsubish Sells Macs -Compaq Rating Down -IBM Robotics -Soft-Logik News -IBM Micro-Transistors -AT&T Movies -ImageMaster & Toaster -* GFA Basic Review *- -* Soft-Logik's HotLinks *- -* ViewPort *- -* Much, Much More *- TODAY'S NEWS ..TODAY! """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" > AMReport's Staff The regulars and this week's contributors! ================ Publisher - Editor ------------------ Ralph F. Mariano PC DIVISION AMIGA DIVISION MAC DIVISION ----------- -------------- ------------ Robert Retelle Charles Hill R. ALBRITTON Contributing Correspondents --------------------------- Mike Todd (CIX) Jim Shaffer, Jr. (UseNet) 70117,634 on CompuServe amix.commodore.com!vanth!jms Andrew Farrell Australian Commodore and Amiga Review & Professional Amiga User Magazine Mike Ehlert, SysOp: PACIFIC COAST MICRO BBS -- FidoNet 1:102/1001 IMPORTANT NOTICE ================ Please, submit letters to the editor, articles, reviews, etc... via E-Mail to: Compuserve.................... 76370,3045 Internet/Usenet............... 76370.3045@compuserve.com **************************************************************************** EDITORIAL ~~~~~~~~~ IMAGEMASTER - TOASTER ~~~~~~~~~~~~~~~~~~~~~ [The following two messages were posted on CompuServe's Amiga Vendor forum. They were posted by John Foust of Syndesis Corp. and Ben Williams of Black Belt System.] If you saw Brent Malnack's column in this month's issue of "AV Video" and were excited to hear about a product from Syndesis Corporation that would magically link Black Belt Systems' Imagemaster to the Toaster, I've got bad news. This product is an unfortunate victim of the time-shift of press lead times and unfavorable legal restrictions. Yes, the product does exist, but we (Syndesis) developed it using proprietary information we gained in the process of making the TIO conversions we made for Toaster 2.0. Because the code was based on proprietary information, we needed to ask NewTek's permission to release this product. Before they reached a decision, I'd heard that AV Video was covering Imagemaster and I told Brent about our product. Later, NewTek decided that we should not release it. Why? Releasing this would force them to release these undocumented hooks to other developers who've been anxious to link to the Toaster. These links are currently undocumented, unsupported, subject to change, and otherwise impossible to hand out in their present state. In the future, things may change. I'm just as sad about this as you are, but we had to play it clean and above-board. From the outset we knew it was dependent on NewTek's decision. It didn't even have a name. This was a cool little gizmo, I wish I could have sold a million of them. With it, you paint in Imagemaster and it automatically renders through to the Toaster's composite output *and* updates ToasterPaint's buffers with the same changes to the image, or vice versa, moving the current frame grab into ImageMaster and back again. John Foust President Syndesis Corporation ----------------------- John, Thanks for posting these details for those of our customers (and yours) who have been interested. We will continue to encourage those Toaster users who wish to see this product released to contact NewTek and express their opinion(s) on the matter via voice, fax and mail. It is extremely unfortunate that Toaster users must suffer this type of arbitrary restriction from NewTek; it's also a shame that you, and we, wasted the time completely developing a solution for a company that puts it's customers and external supporters last. Ben Williams Black Belt Systems ---------------------------------------------------------------------------- IBM BREAKTHROUGH ~~~~~~~~~~~~~~~~ IBM scientists have announced that they have made the world's smallest transistor. This transistor is 20 times smaller than the current crop and should allow memory chip fabrication in the realm of four gigabits (four billion bits), compared with the capacity of 16 megabits offered by the largest memory chip now available. Look for commercial availability of such chips around the year 2000. ---------------------------------------------------------------------------- AT&T MOVIES ~~~~~~~~~~~ AT&T Paradyne, a subidiary of AT&T announced that it has developed a way to send television and movie images over ordinary copper phone wires. The new system is called carrierless, amplitude-phase modulation and it sends information along the wires as rapidly as needed and without the need for boosters. AT&T predicts that this will lead to the final acceptance of video telephones as well as practical video conferencing and two-way television -- all of which could operate over the telephone lines already in use. No time table or productions costs were released. The product was developed in conjunction with Bell Labs. ---------------------------------------------------------------------------- EVEREX BUYS NORTHGATE ~~~~~~~~~~~~~~~~~~~~~ PC Clone computer maker, Everex Systems, Inc. is buying the direct market computer manufacturer, Northgate Computer Corp. for $4.3 million in stock. Earlier in the month, analysts were speculating that IBM was courting Northgate for a buyout. Everex President Hal Clark said that Northgate would be operated as a separate subsidiary, continuing to market under the Northgate name. ---------------------------------------------------------------------------- MITSUBISHI TO SELL MACS ~~~~~~~~~~~~~~~~~~~~~~~ It is being reported that Mitsubish Corp. has received marketing rights to sell all models of Apple Computers in Japan. ---------------------------------------------------------------------------- COMPAQ RATING LOWERED ~~~~~~~~~~~~~~~~~~~~~ Smith Barney investment house has lowered its rating on Compaq Computer Corp.'s stock to "avoid" from "sell". ---------------------------------------------------------------------------- APPLE SHOWING NEW QUADRA SYSTEM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Apple Computer Inc. is unveiling the latest in its high-end Quadra line, said to be its most powerful computer yet. The new Quadra 950 is powered by the 33MHz Motorola Inc. 68040 microprocessor and comes with 24-bit color capabilities as well as a sound generator and microphone for multimedia applications. The new Apple also comes with a minimum of 8MB of RAM, a hard drive with up of to 430MB of storage space and Apple's SuperDrive. ---------------------------------------------------------------------------- MAGAZINE SHUFFLE ~~~~~~~~~~~~~~~~ Just a .info note: COMPUTE is happy to announce the addition of two new columnists to the Amiga Resource edition of the magazine: Mark Brown, former editor of .info, who'll be doing general industry news, opinion, and product info. Oran J. Sands, .info video columnist, will be doing a column on the latest and greatest Amiga video happenings. They join Steve Worley, whose 3-D Rendering tutorials starts in the September issue, and Mike Nelson, who reports on all the new happenings from the U.K. While we're sorry to see .info cease publication (it was the magazine we most anxiously awaited hitting COMPUTE's mailbox each month), we're pleased to be able to welcome Mark and OJ to the COMPUTE team. ...Denny Atkin [Compute] ---------------------------------------------------------------------------- IBM ROBOTS ~~~~~~~~~~ IBM scientists say they have solved the problem of making robots more flexible in the high-precision operations necessary for assembling parts of high-technology products like computer packages, electronic circuit boards and disk drives. IBM is quoted as saying robots are limited to movements in the range of a tenth of a millimeter at best, while some applications require a thousandth of a millimeter, or less. A new IBM micro-robot called a fine positioner "works down to two-tenths of a thousandth of a millimeter, more than 100 times greater precision than current models. The device, which is attached to a macro-robot's arm, takes 30 minutes to construct, IBM says. The device works alongside the macro-robot, and is activated by a variable electromagnetic field, and at the same time, is forced apart by a layer of compressed air. ---------------------------------------------------------------------------- SOFT-LOGIK NEWS ~~~~~~~~~~~~~~~ [The following message was posted on CompuServe's AmigaVendor forum by a representative of Soft-Logik.] Miscellaneous News Everyone will be happy to know our shipping department just moved into much, much larger quarters. This will put us another week behind in shipping due to the move, but will make shipping much easier as soon as the move is complete in a few days. We are still 2-3 weeks behind in orders at this time. We hope to be caught up within a few weeks. Registered Soft-Logik dealers should call our BBS for their copy of the Dealer Handbook, which is now online for their downloading. This is only available to dealers. We have tested a lot of the fonts from Agfa's Type library for the Amiga and every font so far has worked great with PageStream. Don't hesitate to order these fonts if you own a non-PostScript printer. We have tested a number of our fonts with the Gold Disk Type 1 -> Intellifont converter, with mixed results. Some didn't work and all of them had incorrect style settings. This is not a recommended conversion method at this time. For those needing to call tech support, the lines have been pretty quiet the last few weeks, so it's fairly easy to get through. Michael Soft-Logik Publishing Corporation ============================================================================ *** GFA BASIC 3.5 REVIEW *** ** by: Stewart C. Russell ** GFA BASIC 3.5 is a fast BASIC interpreter, with advanced commands which include matrix manipulation and direct access to the Exec, Intuition, Dos, and Graphics libraries. The optional compiler generates code which is comparable in execution speed to a good C compiler. *** Statement of Interest *** I have no commercial links with any part of the GFA organisation. I have written several tutorial articles on GFA BASIC in Jeff Walker's Just Amiga Monthly (JAM) magazine, the UK's only non-games Amiga magazine. I have never received any incentive, financial or otherwise, to write about GFA BASIC; I paid cash for my GFA system. *** Product Preamble *** Product: GFA BASIC 3.5 Interpreter GFA BASIC 3.5 Compiler Supplier: GFA Data Media (UK) Ltd Box 121 Wokingham Berkshire RG11 1FA England Price: Interpreter #49.95 Sterling Compiler #29.95 " Those hashes are pound signs, btw; ASCII doesn't support them. I have tried to find the suppliers outside the UK, but have received no answers yet. The product is advertised in Amiga World, discounted to around $85 (for the Interpreter, I assume) and one of the advertisements suggests that the US distributor is Antic. *** Reviewer Info *** Stewart C. Russell Paper Mail Address: 140 Capelrig Road Newton Mearns Glasgow G77 6LA Scotland Telephone: 041-639 5372 (in UK) E-Mail: clcp16@vaxa.strath.ac.uk (This account should be active until July, when I graduate.) scruss@cix.compulink.co.uk (This is my "professional" account. I get charged for any international mail I receive or send, so use only as a last resort.) [Ed. note: Mr. Russel has informed me that he can forward any queries to Les Player, the MD of GFA Data Media (UK) Ltd. I prefer not to give Mr. Player's address publicly.] AmigaBASIC isn't one of the world's marvels of high speed execution. It also get bored with the tedium of running your programs sometimes, and wanders off into oblivion. The first version of GFA BASIC I saw (v3.041) was fast, but was so bug ridden as to be completely useless. In a way, it was like the first release of the Amiga's operating system; it had something special, but the bugs made it less than useful. And now the bugs are (mostly) gone, people remember it as it used to be - unstable. GFA BASIC has been long in development, originally appearing on the Atari ST around 1986. There is still the lingering feeling that, although the authors are clearly excellent programmers, they are still not 100% sure of the Amiga. What you get ------------ There are at least 300 commands in GFA BASIC, ranging from bit operations to a file requester. Most of the inch-thick manual is given over to command descriptions, with very small program fragments illustrating command usage. There is no tutorial in the manual, and the lack of properly commented examples (they are commented - but in German) is worrying. The manual suffers from truly appalling translation in places, which can range from the faintly amusing to the downright misleading. The GFA BASIC 3.5 interpreter is some 135 KB in length, allowing it to run comfortably on a basic A500. Only one program can be edited at a time, but multiple interpreters can be run. When this is done, blocks of text can be cut from one interpreter and pasted to another. A shorter run-only interpreter is also supplied, and this may be freely distributed with your programs. This program only accepts tokenised GFA BASIC files, and consequently could never be used for program development. The Front End ------------- The single-bitplane editor screen has two rows of ten gadgets along the top, with a clock and a line number indicator on the right hand side. These gadgets allow various file operations (Load, Save, etc) and edit operations (Block, Find, etc). These gadgets correspond to function and Shift-function key combinations. A couple of these gadgets merit special mention. The Test gadget tests the integrity of your program's flow control structures, and warns you of any problems. The Direct gadget drops you into a command line, where BASIC commands are executed as you type. You should be able to work out what the Run gadget does. The GFA editor is rather strange. It parses the input line when you press Return, and won't let you continue if there is a syntax error. It also does not allow blank lines, insisting on an apostrophe at the least. You'll hate it at first, but when you realise that it allows abbreviated input (p for PRINT, inp for INPUT) and automatically indents loop structures, you'll begin to like it more. Only one command is allowed per line, and line numbers must not be used. In line comments are allowed though, but these must be prefixed with an exclamation mark. Functions & Features -------------------- GFA BASIC knows about most of the commands in the Intuition, Dos, Exec, Layers, Diskfont Graphics and Icon libraries, and parses them appropriately; typing in "a%=allocremember(...)" for example would result in "a%=AllocRemember(...)" being returned. (The very pedantic would also note that a syntax error would be returned too; ellipsis is not a valid input to AllocRemember()... :-) ) If your favourite routines exist in another library, you can use the FD file to create the basis for a stub. I've already used this to create interfaces for the iff.library (for IFF handling) and the medplayer.library (for playing MED modules). In this respect, being able to call these library functions from an interpreted language makes GFA BASIC a great prototyping tool. As with most modern BASICs, GFA supports SELECT...CASE structures, and ELSEIF clauses in IF structures. All structures support an EXIT IF clause, which works similarly to "break" in C. INC, DEC, ADD, SUB, MUL and DIV manipulate variables far more quickly than the more usual infix operators. Bitwise operators exist which are similar to (when compiled, identical to) 68000 instructions. Windows and Screens are handled well, with HAM and Halfbrite as accessible as in any other language. All the Window/IDCMP flags are available too. Graphics commands are slightly better than AmigaBASIC's offerings; the DRAW command contains a full turtle graphics package, based on HPGL. A slight nasty is the DISPLAY command; this is a hangover from the Atari, where it's quite safe to switch off Display DMA. DISPLAY on the Amiga results in horrific flickering and all-over nastiness; avoid. Two useful hangovers from the Atari are ALERT and FILESELECT. ALERT creates a small requester similar to the GEM Dialog box, and nothing like as frightening as an Intuition red Alert(). FILESELECT creates a usable file selector; it's not as good as the ARP one, but it works well. ALERT and FILESELECT are not Requesters, so they don't need a window to be attached to. Arrays are used in the way that BASIC originally intended; as matrices. Matrices can be added, subtracted, multiplied, inverted, transposed, copied (in whole or part, with optional transposition) and the determinant and rank obtained. Matrix housekeeping tasks for storing, recalling and printing matrices are supplied; a reasonable package. Arrays can also have members inserted, deleted or moved, so dynamic list handling is a possibility. Hardcoded quicksort and shellsort routines (fast) mean that the old bubble sort routine you've trusted since your PET days can finally be put out to grass. Sound handling is OK. I rarely use it though. Variable Types -------------- The standard GFA integer is 32 bits long, unlike AmigaBASIC's sixteen which corresponds to GFA's Word type. The byte variable type is unique to GFA BASIC, being identical to C's unsigned char type. The Boolean type uses only one bit per entry if used in an array, or one byte otherwise. This would be fine if GFA hadn't chosen non-standard suffixes for its variables. A table shows the problem - Suffix Variable Type Microsoft GFA ============= ========= === Boolean (not supported) ! 8-bit Integer (not supported) | 16-bit Integer % & 32-bit Integer & % Single Precision FP ! (not supported) Double Precision FP # # String $ $ GFA's mathematical routines use a proprietary double precision format as the default variable type. It is very fast (see the benchmarks later on) but unfortunately does not take advantage of a 68881/68882 coprocessor, since it was originally developed on the Atari ST. Pointers are handled quite well for a BASIC, but not with the flexibility of C. Memory access is enhanced too; the {...} operator can be used to read and write different types of variable. Thus rp%={WINDOW(0)+50} could return the address of a window's Rastport structure, and CHAR{attr%+8}="diamond.font" could put a zero terminated font name into a pre-prepared TextAttr structure. Although structures aren't directly supported, they can be fudged using Malloc() and the {..} operator. This is not C, after all. (In)Compatibility ----------------- GFA BASIC is compatible with, well, only GFA BASIC I guess. ASCII files can be merged into the editor, and anything that isn't understood gets `==>' placed in front of it. Screen and window commands differ greatly from AmigaBASIC, but file handling and OBJECT (Bob) commands are almost identical. Sprites, however, merit a separate command. Major differences between Amiga and GFA BASIC include - - "IF...THEN...END IF" is written "IF...ENDIF" (THEN being optional). - "GOSUB name" branches to "PROCEDURE name". Subroutines can have parameters, and can be recursive; SUB...STATIC does not exist. Procedures can be folded down to one line by hitting the Help key. - "DEF FNname(a,b)" becomes "DEFFN name(a,b)". Multiline recursive functions can be defined using FUNCTION, and can be folded using the Help key. Functions can be voided using "VOID func" or "~func". - Menu and Interrupt handling is wildly different, and is unfortunately identical with the Atari ST's system, which busy waits on signals. It is possible, however, to interrogate IDCMP directly and Wait() on the message ports. If portability is an issue to you, GFA BASIC is available on the Atari ST and PC, though the latter is still slightly buggy. OS/2, Windows 3 and Unix (386) versions are said to be under development. GFA BASIC 4 should be with us before the third quarter of 1991, according to Les Player of GFA Data Media (UK). (I know of people who run the program on A3000 machines with no ill effects, and also on Fatter Agnus B2000s. Runs just fine on my A500 too.) The Compiler ------------ The interpreter is fast, but if you want real speed you need the optional compiler. The compiler and linker run from the CLI, but a Workbench graphical shell is provided. Maybe it's just the way my machine is set up, but the GFA shell seldom works properly for me, and I always use the CLI. The compiler only reads tokenised files, and produces a standard Metacomco object file ready for linkage. The GFA linker "gl" is very minimal, and reads the GFA library and library index in a proprietary file format. External functions can be linked into GFA programs, and the compiler manual details how to do this. The GFA library is also supplied in Metacomco format if you wish to use a different linker. Compilation is quick; all of the benchmark test programs actually compiled in under two seconds. Most of the time is spent in the linker, since it has about 150 KB of library to wade through. All programs are compiled with code for Workbench and window opening; producing CLI programs requires the opening of a CON: (or "*") output file and using stream printing. A large amount of optimisation is done by the compiler, but a good part of the manual is given over to optimisations that the programmer can include for better performance. An example of this is integer multiplication; if you stick to 16-bit integers, you can set the compiler to use the 68000 MULS instruction. Verdict ------- I bought GFA BASIC 3.5 back in October, and have been using it on a daily basis since then. If I prototype something using it, it often interprets fast enough to do the job. If not, I compile it, and it's fast enough. If I really needed extra speed, I'd link in assembly language subroutines. GFA BASIC isn't bug free yet; but what large product is? The interpreter must be 99.5% solid, and the compiled code has never crashed on me. I trust it enough to be writing my undergraduate project with it. If you get C sick, take a long hard look at GFA BASIC. Benchmarks ---------- (These are at the end since not everyone might want to read them - SCR) It's easy to say that GFA BASIC is fast, but exactly how fast can only be demonstrated by comparison with other languages. HiSoft (Professional) BASIC is a popular integrated compiler system, and is broadly compatible with AmigaBASIC. AmigaBASIC is packaged with every Amiga, and has the unique ability to run more slowly on a 16MHz 68020/68882 machine than a 7.1MHz 68000 machine. DICE is Matt Dillon's C compiler, noted for its rapid compilation and efficient executables. All times derived from the internal timer routines in each interpreter or compiler, and then rounded to the nearest quarter second. Default compiler options were used in all cases. The test machine was a 3MB A500/A590. (If you ask me very, very nicely, and I happen to be in a good mood at the time (and not too busy either), I can send you the actual benchmark sources. You'll have to give me a pretty good reason for wanting them though.) CALC The old CALC benchmark; 5000 loops of two multiplications and two divisions each. Tests floating point speed and accuracy. GFA uses its own 64-bit floating point format, while HiSoft and AmigaBASIC use single precision in this test. (An IEEE Double Precision CALC using Matt Dillon's DICE is given for comparison. Out of the four different math packages, IEEE was the only one to leave a residual error (of ~-5E-8). Most odd.) GFA GFA Interpreted Compiled HiSoft AmigaBASIC DICE ============================================================ Run Time 5.0 3.0 3.25 16.75 6.5 (seconds) Compile Time - 13.5 5.0 - 11.0 (seconds) Code Size - 11184 19208 - 7592 (bytes) I/O TEST A small (and not very stringent) test of my own devising. `Write' writes out the integers 1-10000 to a file in RAM:. `Read' reads them back again. `Print' tests text output by printing 1000 lines of 56 characters to the Workbench screen. (The RAM: used here is not Commodore's, but The Other Guys' Recoverable RAM Disk running FFS.) GFA GFA Interpreted Compiled HiSoft AmigaBASIC ========================================================== Run Time (seconds) Write 14.25 12.0 161.0 42.75 Read 7.75 7.0 20.25 49.75 Print 37.5 37.25 78.75 149.75 Compile Time - 14.0 4.5 - (seconds) Code Size - 14496 23096 - (bytes) PCW A suite of benchmarks used many years ago by PCW Magazine to test machine performance when running BASIC. PCW1 - FOR k=1 TO 10000:NEXT k, with k floating point PCW2 - 10000 GOTOs and 10000 floating point additions PCW3 - Floating Point divide, multiply, add, subtract; all 10000 times PCW4 - Same as PCW3, but with explicit constants PCW5 - PCW4 plus 10000 GOSUBs PCW6 - PCW5 plus 10000 "FOR l=1 TO 5:NEXT l" PCW7 - PCW6 with an array access in the FOR...NEXT loop PCW8 - 10000 additions, exponentiations, LOG()s and SIN()s GFA GFA Interpreted Compiled HiSoft AmigaBASIC ========================================================== Run Time (seconds) PCW1 0.75 0.75 1.25 4.0 PCW2 2.75 0.5 2.5 21.5 PCW3 7.75 3.0 5.0 43.0 PCW4 7.5 1.25 5.5 48.0 PCW5 8.0 1.25 7.25 53.5 PCW6 13.25 4.0 14.25 90.75 PCW7 21.5 6.5 23.75 140.75 PCW8 34.25 29.5 20.75 179.75 Average 12.0 5.75 10.0 72.75 Compile Time - 16.0 6.5 - (seconds) Code Size - 15272 22944 - (bytes) SIEVE The Sieve of Eratosthenes with 5 loops of 7000 short integers each. (The DICE benchmark is a slightly different program to the BASIC ones, which used GOTO liberally. The result is the same, though.) GFA GFA Interpreted Compiled HiSoft AmigaBASIC DICE ============================================================ Run Time 53.5 3.5 40.75 258.75 1.75 (seconds) Compile Time - 17.0 4.5 - 11.0 (seconds) Code Size - 11256 19256 - 5732 (bytes) %*%* end *%*% -- |Stewart C. Russell | University of Strathclyde, Glasgow, Scotland, UK| |clcp16@vaxa.strath.ac.uk | (opinions my own, not theirs) | ============================================================================ SOFTLOGIK'S HOTLINKS ~~~~~~~~~~~~~~~~~~~~ What is HotLinks? HotLinks is Soft-Logik's data interchange environment. It allows any HotLinks aware program to exchange data with any other HotLinks aware program. Although the HotLinks interface was developed by Soft-Logik, we are opening it up to the whole Amiga community in much the way ARexx or IFF is open the community. In fact the data formats used by HotLinks all follow established IFF guidelines. What HotLinks offers is a method for documented data interchange via a document database and live update. Having said that mouth full, what does it all mean. To best answer that, here are some of the most asked questions about HotLinks: Q: Is HotLinks the same as ARexx? A: No. HotLinks is designed around the idea of data interchange, not command interchange. HotLinks is perfectly suited for exchanging large bitmap files and word processing documents. It does not send commands to programs other than to let them know the HotLinks edition they have subscribed to has been updated. In feel and operation, it is much more like the DOS library than ARexx. Together though, ARexx and HotLinks are a powerful team. Q: Is HotLinks proprietary? A: No. We want everyone to use HotLinks and help shape its future. The actual HotLinks library, resident code and support programs however are copyrighted by Soft-Logik. Q: Do I have to license HotLinks from Soft-Logik? A: No. We are making information about HotLinks freely available. The HotLinks resident code itself is a product from Soft-Logik, much like ARexx is a product from William Hawes. Currently the HotLinks resident code is sold with two HotLinks compatible programs, BME and PageLiner. Q: What sort of support will Soft-Logik offer, and to whom? A: We are interested in supporting all developers who wish to include HotLinks in their products. In some ads, we have restricted this to those registered with CATS. We do not require this, but would encourage any Amiga developer to be registered with Commodore in their native country or region. As for the support itself, we will be sending a developers kit to those who request it. This kit includes example code in the C language for interacting with HotLinks, all associated includes, development tools and a complete set of libs and programs that make up the HotLinks environment. It also includes a paper manual full of HotLinks programming and development information. Soft-Logik also wants to ensure those products that claim to be Hot-Links compatible, are. To this end, Soft-Logik asks that those developers that integrate HotLinks into their products provide Soft-Logik with two copies of the product. This is so Soft-Logik may validate, demonstrate and better answer questions about supporting products. Furthermore Soft-Logik intends on including lists of HotLinks compatible products in its ads and producing a "HotLinks Compatible" sticker much like the green 2.0 sticker. This is necessary to assure users that a program that claims to be HotLinks compatible, truly is. Q: How does HotLinks compare to similar systems on other platforms? A: HotLinks is often compared to systems like DDE and OLE on DOS platforms, Publish and Subscribe in Macintosh System 7 and NeXt step 3.0Us Linking. HotLinks uses a Publish and Subscribe metaphor, not unlike the Apple Macintosh System 7. Also like DDE and System 7, HotLinks uses the operating system's standard message passing system. HotLinks functions are accessed via a disk based library called HotLinks.library. The library packages up your messages and sends them to the HotLinks resident program, and returns to your program the results. Furthermore the library provides a uniform interface, with the new 2.0 look, for all HotLinks interaction. Q: How does the Publish and Subscribe metaphor in HotLinks work? A: When you wish to make a block of data available to HotLink users, you Publish it. If you make changes to that data and want to give users the new data, you Update it. If at any point you no longer want users to receive further changes from your document, you can break the link that associates your data with the HotLinks Edition. At this point people could still subscribe to the old data and update it, unless you delete the Edition. If you wish to use the data that HotLinks has to offer, you may Subscribe to an Edition. When you Subscribe, you can: (1) link the data and ask for notification, (2) link the data and not ask for notification, or (3) receive the data and immediately break the link. Each case it has its own uses. In the event that you save a file with a HotLink in it, that file will not be updated until it is reopened. When a file is reopened, you can check to see if you have the most recent version of the Edition. If not, you can update at that time. Q: How does HotLinks physically interchange the data? A: In all cases an actual disk based file is created when data is exchanged. This file contains the data as well as security and audit information. Currently HotLinks maintains a special directory where HotLinked files are kept. Files in the HotLinks directory are not meant to be accessed by the normal OS, but can be as they are normal Amiga files. In the future however, files may be kept in many places, possibly across networks. By using the calls in the HotLinks library, the program does not need to know where the file is physically located. The files are written by the program, via HotLinks, in much the same manner as if using the DOS library. Open, Read, Write, Seek and Close calls all have HotLink equivalents. For this reason, implementing HotLinks is very similar to implementing traditional file I/O. Q: What kind of data can be exchanged? A: Eventually, everything. At this time, only the formats for bitmapped graphics and formatted text have been defined. The bitmapped format is a simple extension of the existing IFF ILBM format, and the text format is IFF DTXT. It is our intention that wherever possible, any existing approved IFF format will be used. In this way, a minimal amount of redevelopment will need to be done. Of course many kinds of data that will be exchanged do not yet have an established IFF format. We will work with any developer or group of developers to establish new standards. This will expand the IFF standard as well as focus program data interchange in and out of HotLinks. We also want to include those members of the Amiga community that are involved in the BIX amiga.dev/iff section, as they have helped shape several standards. Q: Can you give me an example of how HotLinks is used? A: Here are a few examples: A user scans in an image using HotLinks aware software. The user has the choice of saving the image as a normal file, and/or publishing it to HotLinks. They publishes it to HotLinks, then switches into a page layout program. Next, the user subscribes to the image, places, rotates and scales the image. After having done this they realize that there is a minor problem with the image, not enough to require re-scanning, just touch up. The user then enters the touch up program and subscribes to the file, touches it up and updates it. Now when they flip back to the page layout program the file has updated, but none of the position, rotation, scaling information has been lost. Another example could involve text. A user may first create a body of text in a fast text or word processor, then publish the file to HotLinks. From here the file could be grammar checked, flowed into page layout, re-edited, re-checked and re-flowed. The document could make many trips around the loop without losing any important information. In each case the subscribing program only changes the information it understands, and passes on the rest. Finally, HotLinks would be an excellent way to update parts of a multi-media presentation without disturbing the whole. Each part, text, sounds, animations, graphics, could be Hot-Linked editions. The user could work on these while maintaining the originals in the presentation. When the user feels that the updated version is now better, then they can choose to update that portion. In the meantime, the integrity of the whole presentation is maintained. Q: What do I have to do to support HotLinks? A: At its heart, HotLinks merely enhances the file I/O environment. To use a HotLinks edition, you will have to do the equivalent of reading and writing a standard file. For the most part this means treating HotLinks like another format you import or export. The major difference is that you get HotLinks edition requesters when asking for an edition instead of the standard ASL or ARP requester. There is also an edition infor- mation requester available. Depending on what options you support, you may want to add a HotLinks menu or sub-menu. Q: What is in the future for HotLinks? A: One of the biggest things in the future of HotLinks is network support. The real power of HotLinks can be unleashed when multiple users on a network can be collaborating on a single venture, each providing the other with different parts of the whole. The current version of HotLinks is not network compatible, but due to the multi-tasking nature of the Amiga, it offers a powerful way for programs to interact. Also we foresee the integration of ARexx, for seamless computer control of the whole environment. [Soft-Logik] ============================================================================ ** VIEWPORT ** GEnie's Amiga forum, the *Starship* Amiga has started publishing a online newsletter centered around the activities and happenings on GEnie. The Publisher is Peggy Herrington, the Producer is Deb Christensen and the Editor is Jim Meyer. Currently it is all ASCII, though it was written on the premise that it is physically printed before read. (It is written in two-column style with embedded form-feeds [CTRL-L] and page numbers.) Aside from the goings on on *Starship* Amiga, Viewport has reviews, news and tutorial articles. It looks like they are on about their third or fourth issue, and so far it looks quite good. The tutorial articles especially well done. Viewport is freely redistributable as long as the archive is kept intact (text file, icon, read.me and possibly a note). There is also a provision to reprint some of the articles in newsletters as long as credit is given. I am going to take advantage of that provision now and give you a little taste of Viewport. If you like what you see, Viewport is available on a monthly basis on GEnie. I do not know if GEnie mail has provisions for internet mail, so I don't know if subscriptions are available. Contact JIM.MEYER on GEnie for more information. "Reprinted from ViewPort, a *StarShip*(tm) production available on GEnie(R)." PRO/AM SOLUTIONS: INTEGER TO ASCII CONVERSIONS IN ASSEMBLY By Chris Papademetrious ViewPort March 1992 Converting a 16-bit integer to ASCII sounds fairly simple, but there are some factors to be aware of. Below, we will examine the design of an integer to ASCII routine, and point out problems and solutions, in the hope that they will help you to see solutions to any similar problems you may encounter. The design of such a routine is rather standard. Take the integer N, for example. If you divide it by ten, the answer will consist of two parts: a quotient, which is basically the number without its right- most digit (integers have no fractional components); and the remainder, which is actually the digit that was just lopped off the main number. The MC68000-series processors makes this approach very easy for us, since it has a 16-bit integer division instruction, DIVU.W, which handily provides for us both the quotient and the remainder. The routine, need only continue looping until the quotient is zero; in other words, until there is no more number to convert! A side-effect of this method is that we obtain the digits of the number from right to left. Since we would much rather store the digits from left to right in our buffer, we must reverse the digits. The key to this is fairly simple, however; as we receive each digit, we push it on the stack. Then, we can pull them off in reverse order, when we're finished. We can even push an end-of- string character (a NULL) on the stack, which will be convenient (as a moment's study of the code should reveal). A second consideration is negative numbers. Since the DIVU.W instruction is both faster and more convenient than the signed flavor, DIVS.W, we would do well to make the number positive. We must still remember if the number is negative or not, so that we can add the negative side when the time comes to stuff everything into the buffer. If we wished, we could even write a 32-bit integer to ASCII routine. There are two easy ways to approach it: we could use the DIVUL.L instruction, which only exists on MC68020 (and better) processors, or you could use 2.04's utility.library, which provides a handy little UDivMod32() routine (which will use DIVUL.L whenever possible, for speed's sake). The routine below consists of two entry points. First, there is UIntToASCII, which immediately assumes a positive 16-bit integer, clears the negative flag, and drops down to IntToASCII. For signed numbers, use SIntToASCII, which will set the negative flag accordingly, and ensure the number is indeed positive by the time the routine falls through to IntToASCII. * a0 - pointer to buffer * d0 - number to convert (WORD or UWORD) * d1 - negative number flag UIntToASCII: clr.w d1 beq.s IntToASCII SIntToASCII: clr.w d ; clear ; negative flag tst.w d0 ; test the number bpl.s IntToASCII ; branch if ; plus... neg.w d0 ; make it positive ; again not.w d1 ; and invert the ; negative flag ; fall through ; to main routine ; IntToASCII: ext.l d0 ; ensure that it's ; 32 bits for DIVU.W ; (it only returns ;a 16-bit quotient, ; though) move.b #0,-(sp) ; store a zero ; marker on the ; stack 1$ divu.w #10,d0 ; divide the ; number by 10 swap d0 add.b #'0',d0 ; convert it to ; an ASCII digit move.b d0,-(sp) ; and push it on swap d0 ; switch the ; quotient and ; remainder ext.l d0 ; make it a full ; 32-bit ; value again bne.s 1$ ; and continue ; if there's ; still more 2$ tst.w d1 beq.s 3$ move.b #'-',(a0)+ 3$ move.b (sp)+,(a0)+ ; pull ;character ; off stack ; and stuff it bne.s 3$ ; branch ; while ; non-zero ; (non-end- ; of-string) rts ---------------------------------------------------------------------------- Pro/Am Solutions: Structuring Your C Programs ______ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (__ __) by Chris Papademetrious (April 1992 ViewPort) / / / / (_/he three steps to writing a program are design, coding, and de- bugging. Design is the most important stage, because a proper design greatly eases the burden of the remaining two steps. Likewise, the coding and debugging of a poor design will waste precious time and effort. However, once your design is finalized, there are still some hints that can aid in the actual coding of your project. The large majority of programs share two fundamental code units: initialization and cleanup. In simple projects, the initialization is often short and uncomplicated. In larger projects, it may be broken down into several subsections, which may not even execute in sequential order. A good example of this is an application that allows multiple project windows, such as a word processor. While the application itself obviously involves initialization, each separate project opened will require its own initialization. Careful study of your design will help you determine the most efficient solution. Cleanup is often easier than initialization, since little or no error- checking needs to be performed; one doesn't often run into problems closing something! Cleanup has its own set of potential problems to look out for, however; be sure to avoid situations where you free something that's still needed, such as a message port or a memory buffer. Again, an analysis of your design will help a great deal in spotting such pitfalls. For very small applications, you can follow this format, which elegantly unifies initialization and cleanup: if (OpenResource1()) { if (OpenResource2()) { ... /* continue this as needed */ CloseResource2(); } else ErrorResource2(); CloseResource1(); } else ErrorResource1(); A quick study of this pseudo-code fragment shows that initialization and cleanup complement each other very well. The main problem in this approach lies in the ever-rightward-shifting indentation. One solution to this problem would be to further break the program down into more functions; in other words, modularize! This code model may also break down in more complex situations, where an initialization failure may not require a complete abort or exit. Another approach for somewhat larger applications is to use isolated initialization and cleanup functions, removed from the main body of code. In my own projects, I tend to use the names OpenAll() and CloseAll() respectively. A code model for this method is shown below and on the next page: OpenAll(); ... CloseAll(0); /* normal exit */ OpenAll() { if (! OpenResource1()) /* if it fails */ CloseAll(20); if (! OpenResource2()) CloseAll(20); ... } CloseAll(int ReturnCode) { if (Resource2) CloseResource2(); if (Resource1) CloseResource1(); exit(ReturnCode); } Notice that an error anywhere during initialization will automatically abort with a call to CloseAll(), with a return code of 20. This will allow for cleanup of partial initialization in almost all cases. The CloseAll() function can even be expanded on, as shown below: CloseAll(char *ErrorMessage) { if (ErrorMessage) Show(ErrorMessage); ... /* Note: if you are not familiar */ exit( ErrorMessage ? 20 : 0); /* with conditionals, you may wish */ } /* to refer to a C-language reference */ This flavor of CloseAll() will automatically inform the user of any appropriate errors during initialization, while returning with the proper return code automatically! Although I have not shown an example for calling the routine with an error message of some sort, you are welcome to come to the Pro/Am conferences for assistance (page 670;2, every Wednesday night at 10PM EST). Until (Conference || NextMonth), happy programming! ---------------------------------------------------------------------------- You and Your Complex Interface Adapter: Part One by Greg R. Guthman (a.k.a. AmigaDoc) May/June 1992 Viewport Q: I seem to be having problems formatting disks. A: Hmmmm, it must be your 8520's! Q: My VCR is not recording as well as it used to. A: It must be your 8520's! ______ (__ __) / / he most misunderstood and most maligned component in the Amiga / / has got to be the 8520 Complex Interface Adapter (CIA). It has (_/ been blamed for everything including world hunger at one point or another. A discussion of what a CIA does and more importantly what it does NOT do is in order. There are two CIA's in every Amiga system. They are designated CIAA and CIAB. These 8520 IC's (Integrated Circuits) are general purpose Input/Output controllers that are used in other microcomputer systems as well. In the Amiga, they handle keyboard, serial, parallel and other I/O functions like portion of joystick data. The table below details the pin- outs for each of these IC's and their corresponding function (Pin #, Signal name, Amiga function). CIAA (U7 on A500/U300 on B2000) [] CIAB(U8 on A500/U301 on B2000) [] Pin # | Signal | Amiga Function [] Pin # | Signal | Amiga Function --------------------------------------------------------------------------- 2 | PA0 | MEM Overlay Bit [] 2 | PA0 | Centronics Busy (1) 3 | PA1 | LED Light DIM [] 3 | PA1 | Paper out (1) 4 | PA2 | Disk change [] 4 | PA2 | Centronics SEL (1) 5 | PA3 | Write protect [] 5 | PA3 | RS232C DSR (2) 6 | PA4 | Disk track 00 [] 6 | PA4 | RS232C CTS (2) 7 | PA5 | Disk ready [] 7 | PA5 | RS232C CD (2) 8 | PA6 | Game port 0 Fire(3)[] 8 | PA6 | RS232C RTS (2) 9 | PA7 | Game port 1 Fire(3)[] 9 | PA7 | RS232C DTR (2) 10 | PB0 | Data 0 (1)[] 10 | PB0 | Disk step 11 | PB1 | Data 1 (1)[] 11 | PB1 | Disk DIR 12 | PB2 | Data 2 (1)[] 12 | PB2 | Disk side select 13 | PB3 | Data 3 (1)[] 13 | PB3 | Select 1st drive 14 | PB4 | Data 4 (1)[] 14 | PB4 | Select 2nd drive 15 | PB5 | Data 5 (1)[] 15 | PB5 | Select 3rd drive 16 | PB6 | Data 6 (1)[] 16 | PB6 | Select 4th drive 17 | PB7 | Data 7 (1)[] 17 | PB7 | Motor control 18 | _PC | Strobe(clock) (1)[] 18 | _PC | Not Used 24 | _F | Ack control (1)[] 24 | _F | Disk index 26-33| D0-D7 | Input Data [] 26-33 | D0-D7 | Input Data 34 | _Reset | Reset line [] 34 | _Reset | Reset line 35-38| RS0-RS3| Register storage [] 35-38 | RS0-RS3| Register storage 39 | SP | Keyboard Data [] 39 | SP | Tied to Busy (1) 40 | CNT | Keyboard Clock [] 40 | CNT | " to Paper out(1) --------------------------------------------------------------------------- Legend for Pinout Chart: (1) Centronics compatible parallel port (printer etc.) (2) RS232C compatible serial port (Modem etc.) (3) This can either be a joystick fire button, a mouse left button or a light pen beam trigger. The main purpose of this chart is to show you exactly what is connected to these devices and more importantly what is not! For example, take the case of a joystick that does not respond to up and down movements or a problem with a mouse that seems to have a mind of it's own. Neither of these pro- blems could have anything to do with our friendly 8520's. Many people have stated that the best way to troubleshoot a problem with an 8520 is to exchange them and see if the problem corrects itself for moves to another area of the system. If you look at the CIAA and CIAB carefully, you will notice that many I/O functions are split between them. For instance, the parallel port gets its data from the CIAA, but is controlled via the CIAB. The most common failure of an 8520 is due to ignoring the first rule of computing: NEVER PLUG OR UNPLUG ANYTHING INTO YOUR AMIGA WITH THE POWER ON! Many ports that are handled via the 8520 are directly connected to the IC. When you pull off a mouse cable or a serial cable that has that nice metal shield around it, you are asking for trouble. Just in case you decide not to head this warning, here are the part numbers!: 8520 Commodore part #: 318029-02 These can be obtained from Commodore dir- ectly or by any number of mail-order dealers. In part two, we will discuss some easy troubleshooting methods for these critters. [Read the rest of this article in the next issue of ViewPort!] ============================================================================ ** IN THE NEWS *** Q. When is an Amiga commercial not an Amiga commercial? A. When it is a commercial produced by The Church of Jesus Christ of Latter Day Saints. The middle-school classroom is full of politically correct students (neat, tidy, attentive as well as black, white, hispanic, asian, male and female). TEACHER: "Today's assignment is simple...make this Earth as beautiful as possible." [He rotates a monitor screen to show DPaint running with an outline drawing of Earth's western hemisphere.] The next series of shots shows students using mice and "prettying" the image. They color it in, cycle colors, use animal clip-art, etc. The entire classroom is a network of Amiga 2000s (about twenty to thirty in all). *MANY* shots are shown of the computers and the screens, and the Amiga logo and nameplate is clearly visible. [One student gets up and leaves.] TEACHER: "Has any one seen {student}?" OTHER STUDENT: [standing at window] "I know where she is." [All students and teacher rush to window. Lost student is picking up trash in the courtyard.] [All students run down to help. The teacher is left alone in a room full of Amiga 2000s.] All in all it is a nice commercial. It shows off the Amiga more than anything else. It does a good job with DPaint and showing the students doing something creative as well as entertaining. Commodore should take notes. ---------------------------------------------------------------------------- ** VIDEOGRAPHY ** Q. Is it another Amiga magazine? A. No. But from the latest issue, they sure fooled me! Videography magazine (April 1992 Volume 17 Number 4) has enough Amiga articles and advertisements to make you think they are produced specifically for the Amiga. Let's start at the start: the front cover The cover has the main shot and four insets. The main shot is of an Amiga 3000 with 1950 monitor and a Commodore screen (not the logo alone, but one of the standard demos) showing. There are "boing!" balls floating in from the left. Of the four insets, one is of a camera; one of a DAT audio recorder; one of a Mac; and one is a spaseship graphic done on Lightwave from Babylon V. The magazine spine reads: Videography Video and the Amiga April 1992 The cover blasts AMIGA VIDEO 1992 (a Special Report). Not enough? There are thirteen (13) full pages of advertising directed almost exclusively at the Amiga. You want articles? PRODUCTION [commentary on production technique]: "Keep Your Eye on the Bouncing Amiga" (2 full pages) MULTIMEDIA [commentary on the user interface]: "Getting Video Out of Your Computer" (3 full pages - about 1/3 Amiga) VIDEO AND THE AMIGA [feature]: "Amiga Video Computing Gets Down to Business" (4 full pages) CLOSING COMMENT: Written by Leo L. Schwab Finally, how about a 32 page special insert entitled "Amiga Video 1992" which duplicates the cover but without the inset graphics. This includes a 9 page "Buyers Guide to Amiga Video Products" which is quite good. Still, this isn't an Amiga rag. The majority of the advertisements are general industry and are placed by the likes of Sony, JVC and Hitachi. They tout the latest-and-greatest in S-VHS, 3/4", SMPTE timecoders, DAT audio, cameras, editing and recording equipment. Articles deal with the reality of getting decent video output from a Mac or a PC as well as discuss computer-generic issues like the FCC & HDTV, set safety and other things. However, after reading this magazine, you can only come to one conclusion -- the Amiga is the king of the video hill and it is *not* resting on its laurels. ============================================================================ """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" AMReport International Online Magazine Available through more than 10,000 Private BBS systems WorldWide! """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" AMReport "YOUR INDEPENDENT NEWS SOURCE" May 31, 1992 16/32bit Magazine copyright 1992 Volume 2.04 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""