@database "ar311.guide" @Node MAIN "Amiga Report Online Magazine #3.11 -- June 1, 1995" @{" Turn the Page " link MENU} _ ____ ___ ______ _______ _ d# ####b g#00 `N##0" _agN#0P0N# d# d## jN## j##F J## _dN0" " d## .#]## _P ##L jN##F ### g#0" .#]## dE_j## # 0## jF ##F j##F j##' ______ dE_j## .0"""N## d" ##L0 ##F 0## 0## "9##F" .0"""5## .dF' ]## jF ##0 ##F ##F `##k d## .dF' j## .g#_ _j##___g#__ ]N _j##L_ _d##L_ `#Nh___g#N' .g#_ _j##__ """"" """"""""""" " """""" """""" """"""" """"" """""" ###### ###### ###### ###### ###### ######## TM ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #### ## ## ## #### ## ## ## #### ## ## ## ## ## ## ## ## ## ## ## ### ###### ## ###### ## ### ## "THE Online Source for Amiga Information!" Copyright 1995 FS Publications All Rights Reserved // =====================================//==================================== == June 1, 1995 \\// Issue No. 3.11 == =========================================================================== @endnode @node MENU "Amiga Report Main Menu" @toc MAIN =========================================================================== == Main Menu == =========================================================================== @{" Editorial and Opinion " link OPINION} @{" Featured Articles " link FEATURE} @{" Reviews " link REVIEW} @{" News & Press Releases " link NEWS} @{" FTP Announcements " link FTP} @{" Reader Mail " link MAIL} --------------------------------- @{" About AMIGA REPORT " link ABOUT} @{" Dealer Directory " link DEALER} Contact Information and Copyrights Amiga Dealer Addresses and Numbers @{" Where to Get AR " link WHERE} @{" Advertisements " link COMMERCIAL} Mailing List & Distribution Sites Online Services, Dealers, Ordering ______________________________________________ // | | // ========//====| Amiga Report International Online Magazine |======//===== == \\// | Issue No. 3.11 June 1, 1995 | \\// == ==============| "THE Online Source for Amiga Information!" |============= |______________________________________________| @endnode =========================================================================== == The Amiga Report Staff == =========================================================================== @node JASON "Editor" @toc STAFF =========================================================================== == EDITOR == =========================================================================== Jason Compton ~~~~~~~~~~~~~ Internet Address -------- ------- jcompton@shell.portal.com 1203 Alexander Ave jcompton@xnet.com Streamwood, IL 60107-3003 USA Fax Phone --- ----- 708/741-0689 708/289-7047 @endnode @node ROBERT "Senior Editor" @toc STAFF =========================================================================== == SENIOR EDITOR == =========================================================================== Robert Niles ~~~~~~~~~~~~ Internet Address -------- ------- rniles@Wolfe.NET 506 W. Orchard Selah, WA 98942 FidoNet Fax ------- --- 1:3407/103 509/697-5064 @endnode @node KATIE "Assistant Editor" @toc STAFF =========================================================================== == ASSISTANT EDITOR == =========================================================================== Katherine Nelson ~~~~~~~~~~~~~~~~ Internet -------- Kati@cup.portal.com @endnode @node SEAN "Games Editor" @toc STAFF =========================================================================== == GAMES EDITOR == =========================================================================== Sean Caszatt ~~~~~~~~~~~~ Internet -------- Sean.Caszatt@f512.n2601.z1.fidonet.org @endnode @node EDITORIAL "compt.sys.editor.desk" @toc OPINION =========================================================================== == compt.sys.editor.desk By: @{" Jason Compton " link JASON} == =========================================================================== A couple of days ago, Escom (Amiga Technologies) held a press conference and laid their cards out on the table. The reports that came out of that conference (including the one in this issue, courtesy of Angela Schmidt) focused on the straightforward points made-4000Ts and 1200s to be built this year, how many, etc. RISC technology on the horizon, direction a toss-up between PowerPC and HP-PA RISC. (Despite a recent report by PowerPC News, Escom has NOT committed to the PowerPC chip.) In all, it was not the supercharging event it could have been. No distribution channels were announced outside of Europe. I sincerely hope that is because the channels have not been selected yet-with emphasis on the "yet." There was something else going on there, under the surface. What struck me was that an official from Scala, an official from Viscorp, and a business professor spoke. It was not so much the content of what they said but their presence that was significant for me. It has been wondered, more than once, whether Escom will simply make the existing machines until demand has disappeared, and call it a tidy profit. If that was the case, though, why bring in a professor to talk about how great the Amiga's design is for the future? Why bring in more than one person to talk about how important licensing and consortiums are? Why get a redesigned tower case? Why spend so much time dwelling on the past of Commodore and the Amiga? Just for my benefit? I don't think so. Don't get me wrong. I still think there are a number of things Amiga Technologies needs to do. Hopefully, this is a step in that direction. Jason [For those with FTP access, I recommend getting a hold of the Aminet file AmigaPressConf.lha in pix/misc. It is a huge set of scans of most of the speeches given at the press conference. If a text version ever becomes available, I'll certainly include the more significant speeches in AR.] @endnode @node COMMERCIAL "Commercial Products" @toc MENU =========================================================================== == Commercial Products == =========================================================================== @{" Editor's Choice " link EDITORCHOICE} Jason's picks @{" Commercial Online Services " link ONLINE} Sign-Up Information --------------------------------------------------------------------------- @{" Opinion " link OPINION} @{" News " link NEWS} @{" Articles " link FEATURE} @{" Reviews " link REVIEW} @{" Announce " link FTP} @endnode @node MAIL "Reader Mail" @toc MENU =========================================================================== == Reader Mail == =========================================================================== From: jimd@slip106.termserv.siu.edu (Jim Dutton) [There was a strong reaction to Mr. Chandley's letter about poor Scala customer support. This is one of the more straightforward letters. -Jason] With regards to B. Chandley's note in AR310 about obtaining information about Scala, a person with AMosaic can go to Scala's new Web page (though the actual server is really run by Hyperion). John Chang is always available in comp.sys.amiga.multimedia, and has a CompuServe userid. On Apr 30, JPChang wrote: |-------------------- text of forwarded message follows ------------------| Hello All, Visit our new homepage at http://www.scala.com. Regards, John Chang ____ John Chang, Technical Support Manager, Scala, Inc. USA Reply to: john.chang@scala.com, Scala Computer Television "Multimedia by SCALA. Why Make It Harder?" |------------------------- end of forwarded message ----------------------| @endnode @node NEWS1 "Personal Paint 6.3" @toc NEWS Announcing Personal Paint 6.3 for the Amiga Personal Paint is a powerful and intuitive paint, image processing, animation and 24-bit printing package. Employ stunning effects like transparencies, emboss, water-colors and stereograms (as in "Magic Eye"), while virtual memory frees precious Chip RAM by using other storage resources! Plus: support of RTG graphics cards, different file formats (IFF, PNG, PCX, encrypted, C source code, DataTypes etc.), nine brushes, two independent working environments, multi-level Undo/Redo, animation storyboard, Bizier curves, autoscroll painting, professional color reduction, superior text editor, color fonts, PostScript output, screen grabber, ARexx... Features of Personal Paint 6.3 Include: - First paint program worldwide to support the new PNG (Portable Network Graphics) file format. Includes an ARexx script to convert GIFs to PNG. - Animation (featuring a storyboard, superior compression, multiple palettes, frame-by-frame timing, ANIM-5/7/8 and hybrid formats, etc.) - Sophisticated "behind the scenes" memory management, including virtual memory (swaps inactive image data to Fast RAM and disk storage) and multiple levels of undo and redo - New, faster image processing effects, including transparencies, alpha channel and single image stereograms (both SIRDS and custom pattern stereograms, as in "Magic Eye") - Support of Retargetable Graphics (display cards like the Picasso, Retina, Piccolo, Rainbow, EGS, Talon, Cybergraphics etc.) - Animation on RTG display cards (with or without double-buffering) - Direct, high quality 24-bit printing (Color and Black & White) and interface to third-party software such as Studio Print Server - Professional and fast modes for converting 24-bit pictures (IFF, PNG, PCX, PBM etc.) to 256 colors or less - HAM, HAM8 and Picasso 24-bit viewer active during color reduction - External input/output modules (loaders and savers) for easy extensions and upgrades. Modules for IFF, PNG, PCX, PBM, Amiga DataTypes and several others are included. GIF module is available from public domain sources. - Support and editing of IFF, PNG and GIF project annotations (Author, Copyright and Comment fields, plus Amiga filenotes) - Autoscroll painting - Workbench Application Icon (Drag and Drop) - Basic set of ARexx commands for presentations, format conversions and printing - ASL-compatible file requester - More power through machine language code: the software is in part up to 500% faster - "New Look" user interface - A collection of utilities, including color fonts, new DeskJet printer drivers (up to four inks) and JPEG DataType Requirements: - 1 Mbyte RAM, 1 disk drive required; 1 Mbyte of Chip RAM recommended - Amiga Kickstart from 1.2, Amiga Workbench from 1.3 - Actively exploits 2.x and 3.x operating systems, FPU, CPU Cache RAM and RTG boards - JPEG DataType requires at least 68020 CPU For more information please contact: Cloanto Italia srl Tel +39 432 545902 PO Box 118 Fax +39 432 609051 33100 Udine Bbs +39 432 545905 Italy E-mail @endnode @node NEWS2 "Graphics File Format" @toc NEWS From: mcb@cloanto.it (M. Console Battilana) --------------------------------- PLEASE COPY AND DISTRIBUTE WIDELY --------------------------------- Graphics Community Endorses a New File Format May 1, 1995. A coalition of major software developers, publishers and technical writers announced today its endorsement for the new PNG graphics format. PNG (Portable Network Graphics, pronounced "ping") is a flexible and open format for storing bitmapped graphics images. This effort began in late 1994, when CompuServe and Unisys stunned the online world by announcing that royalties would be required on the formerly freely used GIF file format. Several companies claim a patent on the LZW compression algorithm, which is an integral part of the GIF file format. Unisys is now requiring developers, publishers, and vendors to pay royalties on any software that either creates or displays GIF files. In response to this announcement, developers hastened to replace the GIF file format with an improved royalty-free format. A coalition of experienced independent graphics developers from the Internet and CompuServe formed a working group and proceeded to design the new format. The result is the PNG format. PNG is a major advance over the venerable GIF format. By adopting PNG, you would not only be helping the computer graphics community free itself from the Unisys patent, but you would be enjoying the advantages of a powerful new graphics file format. Converting your GIF collections to PNG offers the following benefits: * PNG retains GIF's strength as a simple and portable graphics format. * PNG's compression method has been thoroughly researched and judged free from patent problems. * PNG allows support for true color and alpha channel storage. Its extensible structure leaves room for future requirements. * PNG's feature set allows conversion of all GIF files. * On average, PNG files are smaller than GIF files. * PNG offers a new, more visually appealing, method for progressive display than the scanline interlacing used by GIF. * PNG is designed to support full file integrity checking as well as simple, quick detection of common transmission errors. * Implementations of PNG are royalty-free. The advantages of making PNG an industry-standard file format are clear. We are now presented with a rare opportunity to move forward in the area of royalty-free graphics display and archiving software. Please help with the adoption of PNG by supporting it as your preferred graphics file format. For more information, source code, file specifications, developer tools, and freeware file converters, you can contact the comp.graphics Internet newsgroups or the Graphics Support Forum on CompuServe (GO GRAPHSUP). For files, check the ftp.uu.net:/graphics/png directory, or email png-info@uunet.uu.net. Thank you for supporting this project. Signed by: Michael Abrash, author, Zen of Graphics Programming Michael Console Battilana, Cloanto (Personal Paint/Write, etc.) Bradley Bell & Elizabeth Piegari, TriSoft (Depth Dwellers) Andrei Belogortseff, ChaoSoft (FM StepUp, FM Toolbar, FM Guard, etc.) C. Steven Blackwood, Cytherean Adventures (Cargo Bay) Robert K. Blaine, ECONO-SOFT John Bradley, author of XV John Bridges, author of GRASP, PC Paint and PICEM Rick Byrnes, The Software Development Group (NoteWorthy, MoneyWise, Eventz, and various shareware products.) Tony Caine, ARCaine Technology George Campbell, OsoSoft (Winclip, etc.) Mike Ceranski, President, Dvorak Development Lee Crocker (Piclab, PGIF, GTools) Karen Crowther, Redwood Games (Math Rescue, Word Rescue, Pickle Wars) E. Nicholas Cupery, Farba Research (Farba Utilities (tm)) Thomas Boutell, author of the gd library and the World Wide Web FAQ Gary Elfring, Elfring Soft Fonts (Clip Art) Steve Estvanik, Cascoly Software (Winzle, Windows in Time, MVP Bridge) Jim Faliveno, Monumental Computer Applications, Inc. (TagVue-CaddView) Dan Farmer, POV-Team (POV-Ray) Oliver Fromme, TBH-Softworx (QPEG, PicDex) John Gallant, First Magnitude (3-Ball Juggler, Beat the Bomb, Math Sampler) Lawrence Gozum, author (VIDVUE) Phil Grenetz, Ivden Technologies Diana Gruber, Ted Gruber Software, Inc. (Fastgraph) David Hofmann (Computer Graphics Artist, Germany) Michael D. Jones, Insight Software Solutions (Finance/Hobbies/Word Games) Lutz Kretzschmar, coauthor of Ray Tracing Worlds (Moray) Tom Lane, organizer, Independent JPEG Group (IJG JPEG software) Steve Lee (Atlantic Coast plc) Ralph Mariano @ STReport International Online Magazine David K. Mason, author of Morphing on Your PC, coauthor of Making Movies on Your PC (DTA, DFV, DMorf) Randy Maclean, Formgen Corp. Brad McLane, Caladonia Systems Inc. (Code.Print, ToolThings) Al Meadows/Fineware Systems (Author of Space Hound, Peeper, etc.) Scott Miller, Apogee Software, Sultans of Shareware Jeff Napier, Another Company (Computer Magic) Peter Nielsen, Raja Thiagarajan, Julie England (PMView & PMSnap for OS/2) David Noakes, Fugue Software Dick Oliver, author of PC graphics books and software including Tricks of the Graphics Gurus, PC Graphics Unleashed, and FractalVision Dan Richardson, illustrator, author of Create Stereograms on Your PC John Richardson, Rogue Marketing (Amazing Secrets Series, Gambling Secrets, JobDisk) Steve Rimmer, Alchemy Mindworks Inc. (Graphic Workshop, etc.) Greg Roelofs, Info-ZIP (Zip, UnZip and related utilities) Guy Eric Schalnat, Group 42 (PNGLIB, GraphX Viewer) Paul Schmidt, Photodex Corporation, GDS (The Graphics Display System) Monty Shelton, CrystalWorks (EZCosmos, SIRDS for NIRDS, Language Wiz) Steve Sneed, Ozarks West Software, Inc. (OzCIS, OzWin, OZBEXT/OZGIF) David Snyder, MVP Software (MVP Paint) Chuck Steenburgh, Tay-Jee Software (Palantir for DOS & Windows, S.O.S.) Peter Tiemann (author of TrueBase) Glen Tippetts, NeoSoft Corporation (NeoPaint, NeoBook, etc.) Rod Underhill, Computer Fine Artist (CIS Comic Forum's Underhill Gallery) John Wagner (Improces) Bruce F. Webster, Pages Software Inc (WebPages by Pages) Tim Wegner, author of Image Lab and Fractal Creations (Fractint) Rosemary West, R. K. West Consulting (By The Numbers, LoveDOS, etc.) Thomas R. White, Recreational Engineering Associates (MultiMedia Swiss Army Knife) Charles L. Wiedemann, Rexxcom Systems (XL2001, E-Z-Book, etc.) Terry Wilkinson, CIO, AffNet Publishing Ben Williams, Black Belt Systems Inc. (WinImages, Imagemaster, etc.) Jeff Woods, deltaComm Development, Inc. (Telix for Windows) @endnode @node NEWS3 "Obituary: Pierre Carrette" @toc NEWS Obituary: Pierre Carrette From rougier@ss3.univ-poitiers.fr Mon May 15 02:50:00 1995 On friday 12 may 1995 the Amiga fan lost a great programmer. I personaly lost one of my best friends. Pierre Carrette, co-author of BrowserII, died in a moto-car accident. @endnode @node NEWS4 "Adventure Design System" @toc NEWS Title: ADVENTURE DESIGN SYSTEM Author: Travis Riggs Aminet Filename: AdventureDesig.lha under games/role This program is by far the easiest game creator available for the Amiga today! With Adventure Design System, you can create any type of role playing game you can imagine. Anything from the typical D&D style game, to a space adventure game, or even a spy game! Whatever you want! ADS is so easy to use, and you can put a decent game together in a matter of minutes. You don't need to have any programming experience. ADS also has an on-line help feature that will answer any questions who might have about designing your game. If that wasn't enough, ADS also checks your game for errors! Very nice! The basic concept works very well. You create "Objects" and "Creatures" and then place them into "Rooms" that you design in your game layout. Then ADS takes care of the rest! You can use any standard IFF picture or sound to include in your game. You can attach pictures and sounds to creatures, rooms, objects, keyevents, etc. It even supports AGA! Adventure Design System is Shareware. With the registered version you will be able to save out your games as STAND ALONE, and freely distributeable games! You can't find a more powerful games creator for less money! To receive a registered copy of Adventure Design System send $ 20 U.S. dollars, plus $ 5.00 shipping & handling to: Spectrum Video 1039 Sterling Road 1-(703) 471-5001 in Virginia and outside U.S. Suite # 104-B 1-(800) 471-5001 Toll Free inside the U.S Herndon VA 22070 Attn: Travis Some of Travis' other credits include: Composite Studio Profeesional (Copyright 1995 Dimension Technologies), Bikini Karate Babes, and many others including current FMV CDRom projects and other commercial software for the Amiga! @endnode @node NEWS5 "The Music Maker" @toc NEWS May 24, 1995 For Immediate Release Laughing Cat Records is announcing the debut release of "The Music Maker" CD, a 10 song collection of contemporary New Age music by John Mc Donough. The program material ranges from the gentle flute-piano sounds of the title track to the progressively alternative edged tracks such as "An Irish Melody" and "An Okinawa Dream". "The Rain", a piano piece with subtle dynamics touts a neo-classical air. As an instrumental effort the album stays close to the listener in an uplifting spirit as presented in the tracks "Castle Maine" and "The Eyes Hear All". All songs on this debut CD were written, arranged and co-produced by the composer. Studio recording, engineering and co-production were provided by John Cittrich of Two-Real Productions. CD insert and back cover photos were taken by Diane Mc Donough. The artist, John Mc Donough was born in Elizabeth, New Jersey in September of 1958. He grew up in Bayonne, New Jersey moved to Hackettstown, New Jersey at the age of 10 years and now resides in Wanaque, NJ with his wife Diane. John began playing the piano when he was 7 years old and was trained in classical and jazz stylings. John is a regular on the music scene in the New York-New Jersey area and has performed as keyboardist/vocalist/guitarist in bands such as The Party Dolls, Flashback, Waterfront, Voices, The Thrill, The Click, Bobby Curtis Trio, Indian Summer and Urban Cactus as well as many hours in the studio as a session player. His television experience includes performance and music production for MTV's "Unplugged" Spoken Word Special in April 1994. Having been Influenced by artists such as Billy Joel and Elton John in the rock/pop genre who have classical training themselves, John's resulting piano/songwriting style shows a refreshing blend of the old and new musical flavors. Formerly only exhibited in movie/film sound- tracks and other alternative sources, New Age music has been gaining in popularity in the recent years and is well established as a music form. "The Music Maker" is a fine addition to anyone's music library for their listening enjoyment. ------------------ The equipment Mc Donough used to compose the album includes- 2 Amiga 500s (7mhz) in a MIDI hookup to a mobile recording unit SEQUENCING ---------- Master Tracks Pro (Latest Version) KCS 3.5 w/Level II (For those tough edits!) Copyist v1.6 (notation) Clarity 16 Sample Edit Software (not bad for the price) ALBUM COVER and TYPESETTING --------------------------- Pagestream 2.2 (layout and proofing) Imagine 3.0 (Cover texture design) Final Writer (word processing) DPaint IV (preliminary art design) BME 3.0 (image processing) ************************************************************************** FOR MORE INFORMATION CONTACT: Laughing Cat Records 1356 Ringwood Ave. Haskell, NJ 07420 RE: "The Music Maker" voice: (201) 831-9785 email: midikat@gti.net @endnode @node FEATURE1 "Windows95" @toc FEATURE =========================================================================== WINDOWS95: IT'S NOT PARANOIA, THEY ARE OUT TO GET YOU Taken from the Risks-Forum Digest =========================================================================== RISKS-LIST: Risks-Forum Digest Thursday 18 May 1995 Volume 17 : Issue 13 Date: Wed, 17 May 95 13:44:40 EDT From: cnorloff@tecnet1.jcte.jcs.mil Subject: Microsoft plans corporate espionage Microsoft officials confirm that beta versions of Windows 95 include a small viral routine called Registration Wizard. It interrogates every system on a network gathering intelligence on what software is being run on which machine. It then creates a complete listing of both Microsoft's and competitors' products by machine, which it reports to Microsoft when customers sign up for Microsoft's Network Services, due for launch later this year. "In Short" column, page 88, _Information Week_ magazine, May 22, 1995 The implications of this action, and the attitude of Microsoft to plan such action, beggars the imagination. Chris Norloff cnorloff@tecnet1.jcte.jcs.mil [Also reported by jyoull@cs.bgsu.edu (Jim)" and herzog@uask4it.eng.sun.com (Brian Herzog - Sun Microsystems, Inc.). The following analysis was also sent to RISKS by a contributor who requested anonymity. PGN] ------------------------------ Date: Wed, 17 May 95 12:22 xxT From: [identity withheld at submitter's request] Subject: RISKS in Microsoft's Windows95 Sometime in the latter part of the summer, Microsoft is planning to release their Windows95 follow-on for Windows 3.1 to the masses. Whether the effort required to keep things working after installing the release vs. the perceived benefits of Win95 makes the installation a sensible decision is quite an open question. Reports from beta testers are indicating that even for Windows experts, getting their system running again after the upgrade can be a bad experience, given the wide variety of complex hardware, drivers, and other components that have been integrated into Windows 3.1 environments over the years. For Windows users who are less than experts, the problems risk being even more serious, with various applications (or even entire systems) effectively useless without various "tweaks", fixes, new drivers, new software, etc. In other words, the backwards compatibility of Win95 in the real world of people's existing Windows 3.1 installations should be an issue of grave concern, especially among users concerned about prolonged downtime. We may be reaching a stage where the sheer complexity of PC application software and hardware is making the entire concept of major operating system upgrades being installed successfully by average users extremely problematical. It seems very likely that large numbers of Windows 3.1 users will (or at least should) be extremely cautious about being an early adopter of Win95. By the way, here's a new feature announced for Win95 that carries new RISKS of its own. Called "AutoPlay" it is apparently a feature of the Win95 CD-ROM driver that allows CD-ROM authors to create a special init file on the disc that will automatically start running programs from the disc as soon as a disc is inserted into the CD-ROM drive. From the descriptions available so far, there doesn't seem to be a system-wide way to disable such a feature, you have to remember to hold down the shift key on your keyboard while inserting the disc to disable it for that particular insertion (apparently folks with remote keyboards might just be out of luck!) What sorts of harm could come from autoloading of CD-ROMs? Outside of the obvious malicious applications (don't laugh, CD-ROMs are getting so cheap to produce that all manner of nasties could be planted on purpose or by accident), there's the obvious problem that most PC CD-ROM applications need considerable software and disk support, often involving significant use of disk space, changes to system-wide configuration and other driver data, etc. It is not unusual for these changes to conflict in some manner with other programs and installations, needing manual intervention. At least when you do the installation manually you can stop, look for README files, etc. before starting the guts of the install, but if the CD-ROM fires off on its own there's no telling what might happen. True, a reasonable CD-ROM author would query the user about this process rather than running off and starting the install without user input, but it's probable that many authors who want things to look "slick" won't bother with this. In fact, Microsoft seems to be encouraging the "slick" attitude in their description of this feature. Another point. You're about to start seeing music CDs that carry CD-ROM programs and data on the initial part of the disc before music track 1. If such discs tried to make use of the Win95 AutoPlay feature, an unsuspecting user who stuck the music disc into his or her CD-ROM player planning to hear only music (lots of PC users play music CDs on their CD-ROM drives these days) could end up getting a lot more than bargained for. @endnode @node FEATURE2 "Letter to Escom" @toc FEATURE =========================================================================== AN OPEN LETTER TO ESCOM FROM THE ITALIAN AMIGA COMMUNITY ON FIDONET =========================================================================== From: so98@beta0.lica.unimo.it (Gruppo di lavoro corso Sistemi Operativi) The following document is the result of one month of hard work and discussion inside the Italian-speaking Fidonet Amiga users community. More than 50 people, including software developers, professional DTV users and normal users joined their efforts to make this document possible. In the name of the Italian-speaking Amiga users community we wish you the best of lucks in making the Amiga once again a successful platform. According to the various opinions we have come across, the most important aspect in a future operating system is the ability to configure and customize all of its features. Of course a standard configuration must be provided, and this configuration should show all of the power of the system. The configuration provided with the current operating system hides the real power and flexibility of the Amiga Workbench and operating system. The Amiga's unique Screen handling allows all of its programs to open an appropriate screen to fit their own needs. This is the reason why in our opinion the Workbench should not follow other operating systems where the main desktop has 256 or more colors. We think that a 32 or even 16 color Workbench is the right way between speed, memory usage and a sufficiently colorful environment. There are utilities in the public domain such as MagicWB and many others that accomplish this job with as low as 8 colors through some impressive dithering. We have gathered many and very different opinions about how to improve the operating system for a new release, but we would like to emphasize that all of the different personal tastes can be satisfied with an operating system that is totally configurable as we mentioned before. In the following list you will find many references to existing software that is usually either under the Public Domain or Shareware concept. For further details on how this software operates, we have included a reference guide at the end of the document, complete with the addresses of the authors in case you might want to contact them. Here follow the most important opinions, some bug-reports and complains. xx. Installation and help facilities The first and most important thing is that the system is not user friendly enough to a new user. First thing off we need a tutorial that shows all of the basics to start to get around your brand new Amiga. There used to be something similar a few years ago; it was better than now that we have nothing like it but it had too many static images. The user did not have the chance to interact enough with the operating system environment. If a CD-ROM is to be fitted as standard in future machines as we hope, the tutorial could be made as a multimedia presentation with a speaker and all of the features this media allows. It is strongly recommended to have a "Help" menu in the Workbench that activates an interactive Amiga Guide help such as the Balloon Help in the Apple Macintosh or like the one in Directory Opus, but more user- friendly. What we mean by this is that while the help is active you can click everywhere and get information about the function or gadget you chose in the Workbench. This help should be supported through the usage of shared libraries so that also all other programs can use a system standard on-line help. Usage of such on-line help should be mandatory in the developer kit programming guidelines. The second but not less important thing is the following. We have a good hypertext viewer such as MultiView and a nice system standard hypertext format such as the AmigaGuide format. Why is it that there is no on-line help for any command whatsoever!? Even the power users often need these! Every single program of the OS should have an on-line help made with AmigaGuide. It would be useful to finally use the "Help" key that for YEARS nobody has EVER used. This is essential. The same goes for the AmigaDOS commands. Too often the template given with " ?" is not enough even for the most experienced programmer. We should keep the " ?" -> template but add a help command. It should work something like: "Help " We should have a new system assignment called "HELP:" where all of the help text files are kept, and all we would have to do would be to call More - it would be useful if also the system default text viewer was configurable... - We can't just pick up the Workbench or AmigaDOS manuals every time; in fact, there shoould be a copy of these manuals in ASCII format included with the operating system. Also the ARexx manual should be given in a file in either AmigaGuide (better) format or just plain text. xx. Workbench operation There are a few things that could be improved to make the Workbench an even more powerful environment. - There is a horrible bug (we believe it is something with the AGA chipset though) in the Screen opening routines. This shows up clearly on the Workbench if the external border is set to black with one of the many borderblanker PD programs around. There is a verical line in the left side of the screen, whose color register is 0. The width of this color-0 line is independent of the resolution of the screen (that is why we suppose it is a problem with the AGA chipset, but we might be wrong). Correct this immediately, as it makes look backdrops with black as the background color horrible. - The Workbench should allow asynchronous operation. The operating system allows other program to multitask with each other but the Workbench does not multitask with itself. Specifically some actions may take very long, like opening drawers with large amounts of files or copying/moving files. The Workbench should allow to work while a directory is being read. It is crucial that the copy/move function opens a progress requester that allows to abort the copying/moving and that allows the user to do other things in the meantime on the Workbench itself. In fact, any action that could take the Workbench busy should open its own progress requester and should work asynchronously. - There should be a way to open the window of a drawer inside a disk without having to open all of its parents before. Now if we need to enter the drawer "DH0:Prefs/Env-Archive/Sys" we must open first the DH0: drawer by double clicking on it, then the Prefs icon, then the Env-Archive icon, and finally the Sys icon. These are 4 actions that open windows that are totally useless for our purposes if all we want to do is just see the contents of the "Sys" directory. This means that the new operating system should allow you to open a drawer skipping all of the parent drawers. This can be accomplished by showing the tree of the device and letting the user browse through it until he/she finds the needed drawer and only then see its contents as icons, like in OS/2. To accomplish this something as simple as a file requester can be used. The AmigaDOS command "RequestFile" with the DRAWERSONLY option would already allow this if the Workbench supported it. - On the other hand, there is an option in the Workbench "Window" menu that is called "Open parent" that would cause problems with the former directory tree choosing option and currently causes memory problems even on 2MB machines. Part of what this function does should be removed. In fact this function keeps track (and takes huge amounts of memory to do it) of all of the icons, its images and positions. The point is that even with 2MB memory after a few sub-directories the user runs out of memory. It would be enough just to preserve the complete path name of the parent drawer. All it would take then would be to rescan the directory. It would be slower, but much more memory effective. - We recommend the usage of a 3-button mouse. We feel that all 3 of the mouse buttons would be extensively used, for example in the choosing of the directory in a tree (see above) you could double click the central button while on top of a drawer icon to get an hypothetical 'tree window'. All button actions should be configurable, and mouse buttons functions should be switchable (also for left handed people). - The keyboard shortcuts of the menu items in the Workbench screen are not all assigned. This caused many complains. In particular, the widely used "Show all files", "Show only icons", "View by name", and "View by icon" don't have keyboard shortcuts. ALL items should have a shortcut, including items in the Tools menu. - The multiselection in the Workbench is not well supported. The current way of deselecting a mistakenly chosen file is very uncomfortable. It should be changed to simple clicking again on the icon with the left mouse button. - The trashcan handling is not appropriate. We need a global trashcan, and right now we have to put up with one trashcan for every partition. - The Workbench must have an ARexx port. - The "Execute Command" requester is not pointer sensitive and always opens with the Topaz 8 font, independently of the system font the user chooses. This is unacceptable for hires screens. - All of the functions that ToolManager by Stefan Becker has should be directly supported by the operating system. These include: - Ability to add menu items in the 'Tools' menu. This feature is specifically indicated in the Workbench manual but none of the programs that come with the operating systems use it. - Ability to add Images and Icons associated with actions to the Workbench desktop - Ability to add AppIcons to the Workbench. - The handling of the scroll bars in the drawers is not smart. When one of these sliders is moved, the contents do not follow it in real time, so that we are only able to see the contents of the drawer in the initial and in the final slider positions. This should be changed or such sliders lose much of their utility. - An interesting idea would be the possibility to have more desktops. What we mean by that is the ability to open multiple Workbench screens at once. Of course all of their data would have to be shared to save memory. The programs that are run from one desktop (or call it 'view' if it seems more appropriate) of course should open only on that view. This would also make public screens useless for most things... xx. Workbench configuration programs The Workbench does not have any standard configuration provided with it, but it should. There should be a number of default configurations, possibly divided according to the screen resolution they're best for. These should be ready-to-use configurations, including palette, font, patterns, sounds, icons, and so on. Another very important option that is required in all of the preferences programs is, together with 'Save', 'Use', and 'Cancel', a 'Test' gadget. Furthermore there should be keyboard shortcuts for all of these programs, in fact the whole system should be entirely keyboard controllable. For example currently there are no default patterns given with the OS. The ones in the WBPattern are built-in the program and therefore are quite useless, because they are not flexible enough. Instead, what we would need is a directory with some nice backdrop patterns such as the ones that MagicWB by Martin Huttenloher, a directory with some sounds, and so on. The current configuration programs often have bugs; below a list with all of our suggestions follows. - ScreenMode The standard screen mode MUST be a 31Khz mode. However, 15Khz video output support must be kept for graphic users. Developers and normal users currently have to buy expansive multiscan monitors to be able to use all of the programs. Default 31Khz modes would allow Amiga users to buy better and bigger VGA only monitors, as we noticed that very small minority uses 15Khz standard tv output. Unfortunately since games, the Bootmenu and the system Alerts are in 15Khz mode (refer to the appropriate sections for details) low end users now cannot use all of the Amiga screen modes because multiscan monitors are too expansive. Note that this point is crucial. - WBPattern This program only supports tiled patterns and does not allow absolute positioning of a picture as backdrop pattern. In particular, we feel necessary to have a 'center' option. This program is also incredibly slow due to the fact that the palette is remapped each time the backdrop is loaded (for example in the boot operations). There should be an option that disables the backdrop remapping and simply uses the desktop colors, changing only the ones that are not locked by the system. This way we could have the system calculate the remapping just once, and speed up the operatons quite impressively. - Palette The current palette program is totally inadequate even for the low end user. On Workbench 3.0+ even if the Workbench can be opened to up to 256 colors the user can only change the palette of the first four and of the last four colors, and cannot lock nor edit any of the other 248 colors. This problem is connected to some severe limitations of the icons structure and of the icons editors provided with the Workbench that are discussed in the Icon section. The new palette program should be able to: - Edit all of the colors in the desktop (up to 256) - Lock any of them if asked - Assign custom colors to ALL of the graphical elements in the OS. This includes: gadget colors, window colors, text, background text, window titles, menus, etc - Have many ready-to-use complete color setups to choose from as already mentioned. - Sound We need: - datatype support - configurable sounds for every system event such as: - window opening/closing - screen opening/closing - system requests - and so on... - The handling of just one type of beep (with flashing) is not enough. Different classes of DisplayBeep()'s should be added and every one should have a different sound associated with it. In particular there should be different classes and priority for example for beeps that indicate finished activity and ones that warn of a failure of some program function. - IControl The IControl program now supports screen dragging with a key. It would be very useful to have window dragging with another key. Furthermore, now it is very unclear how to snapshot the Workbench window in backdrop mode or not. Currently you have to choose from the menu item "Backdrop" and then select "Snapshot window", but this approach it is not intuitive at all. We recommend that this preference is included in the IControl program. However both ways of configuring the Workbench window should be available. As explained in the GUI section, many users like popup menus like the ones in MagicMenu by Martin Korndorfer, but many others don't. The solution is adding a menu config option that allows to toggle popup menus on and off. - Font The font preview window is too small and is not resizeable. This means that fonts higher than 24 pixels cannot be fully seen, even if they perfectly work in the Workbench environment. Furthermore, if the Workbench is open with many colors (for example 256) the window that the Font program opens is not big enough as to fit all of the color gadgets and many are cut outside the visible area. This is a real bug in the Font program requester that should open a window that is big enough as to fit all of the necessary gadgets. Also, the system (shell) font should not be restricted only to FIXEDWIDTH fonts. The fonts provided are not appropriate for high resolution screens. The users need some that are specifically studied for the single monitor types. The font engine should support other font types, such as the Adobe Type 1-3 and True Type, if the royalties allow it. - Pointer The Pointer preference program should have a variety of default pointers. Also, support for alternate busy pointers and animated pointers would be useful. The Pointer program is bugged. It will only open in PAL mode and there is no way to promote it to any VGA-type screen. - Printer The printer support is so important that it deserves a dedicated section. Refer to that section for more information. - Time The date format should be FULLY localized. xx. MultiView and datatypes The datatypes are one of the strongest points that make the difference between the Amiga operating system and others. The concept behind them should be left behind for no reason whatsoever. Using the datatypes we have a completely modular operating system. We suggest including many more datatypes especially for usage with MultiView. The most important are picture and animation datatypes to leave finally out all of the non standard picture and anim viewers around. We have the chance to use one program to see every single file in our computer, so let's use it. Many of these datatypes are already in the public domain and could be included. Datatypes should be included for: IFF24 ( which surprisingly is not supported yet ) TIFF TARGA PCX PCHG PICT SUN rasterfile images JPEG HTML for Mosaic Icon files (.info) the most used audio formats such as .WAV .VOC .AIFF .AU .HCOM .SF true support for ANIM5, ANIM6 and ANIM7 and CDXL postScript files (screen output) TeX files FAX files In fact there should be datatypes for as many filetypes as possible, but the most critical are the picture datatypes. The MultiView program should also allow the possibility to open more than one file within the same screen. Right now if you want to view more files at the same time it is necessary to load a copy of MultiView for each file. One user also suggested that for the color reduction algorithms the Floyd-Steinberg or other dithering algorithms should be supported. Also, there is no support for 24bit images in the IFF datatype, and must be included. MultiView has a bug if both BACKDROP and SCREEN flags are set with an AmigaGuide document. Datatypes should also have saving routines for picture formats other than IFF. The AmigaGuide format should be improved too. MultiView does not support full keyboard control. In fact, there are no keyboard shortcuts for the "Contents", "Index", and all of the other gadgets that allow browsing through the guides, and should be added to increase the ease of use. Furthermore there is no color control. An AmigaGuide document that is opened with the SCREEN option should allow customizable palette. A "Search" gadget is necessary. Pictures and any other datatype defined object should be supported within the AmigaGuide document. Some users suggested that pictures should be rescaled to small gadgets that show the picture when the gadget is selected. Finally, the AmigaGuide document handling in MultiView is quite slow. See also the section about the Clipboard and about the Workbench desktop improvements for other suggestions about the usage of datatypes for other tasks. xx. Clipboard A more powerful clipboard system that supports a data conversion system through datatypes would be appreciated. This way we would be able to cut a piece of screen from a paint program and paste it in a word processor. The clipboard functions should also apply to string gadgets that now do not support cutting and pasting. There are many utilities in the public domain, including one by Carolyn Scheppner, former Amiga developer. PowerSnap by Nico Francois is one of the most used utilities by all users and should be included in the operating system. This program allows to cut a portion of bitmap from anywhere in a window and attempts to interpret it as a string which is then pasted to the system clipboard. Note that this tool allows cutting from programs that do not support the system clipboard. Font support is included. PowerSnap is a 'must be there' in a future OS according to ALL of the users' opinions. xx. Icons Currently the icons are de facto limited to 8 colors. If the icons attempt to use any other than the first 4 or the last 4 colors, since the icon structure does not include the palette definitions the icons will show with the wrong (unlocked) colors. We need the new .info format for icons to save up to 256 colors (more colors, though, would be a waste and would be useless) and to save the palette together with the images. The icon editor should of course be rewritten accordingly, and should save only the used bitplanes to avoid wasting memory. We need some icon collections like in other operating systems because we have our HDs full of thousands of identical icons (the def_* ones). We need to be able to get information with the Workbench menu "Info" from AppIcons too. Adding a new tag for this is very easy and solves the annoying 'Info failed' message on the Workbench. It would be useful if AppIcons would also support custom menus with an appropriate tag. We need more default icons like in Directory Opus. The user should be able to set match parameters (ex. match name or extension with wildcard support) so that when the Workbench finds a file that matches the customizable file type the proper icon is assigned to it. Datatypes could also be used to get a similar result. It does not make sense to use a graphic interface that uses icons with images if all of the icons are hammers as in the def_tool.info, because this way we have to go and read the name. It is against the concept of "Intuition". Defaults types should include: - executable files - libraries - handlers - devices - ASCII texts - AmigaGuide documents - pictures (more formats) - sounds - catalogs - datatypes and all of the other system files and more. Again, new file types should be fully customizable. Directory Opus shows a good way of doing this in the configure program under the item "Filetypes". xx. Graphics User Interface The GadTools Library has been heavily criticized. In the opinion of most of us it has to be totally rewritten. The layout engine is not flexible enough for the user and it is too complicated to handle for the programmers that often spend much more time developing a graphic user interface rather than the algorithm of the programs with obvious consequences. Many users are now using the Magic User Interface by Stefan Stunz, and many of the ideas were taken from this graphic engine. Its flexibility makes it a unique product that yet does nothing but use Intuition and the BOOPSI classes to their full potential. Still, the new graphic engine should be faster than MUI. RTG in future GUIs is mandatory. A very important feature is the ability to have replaceable default gadget images. This would lead to a totally upgradable GUI system. With proper image upgrades, the look of such an operating system would very hardly look outdated. Also this would avoid problems such as the ones caused by the fact that many of the 2.0+ gadgets were designed for non interlaced usage (such as the window resizing gadgets), which caused many complains. This system could allow the usage of libraries of gadgets whose sizes are specifically designed for certain resolutions, therefore solving many aspect-ratio problems. Still, a scale engine such as the one in the Magic User Interface should be supported. This engine should allow real window resizing as in the MUI. This means that when a window is resized, all of its graphic parts should be resized accordingly, provided that the aspect-ratio is kept constant. So, we will have bigger buttons with bigger fonts and so on. The windows handling routines should be updated too. We suggest that an 'iconify' (zoom) gadget for every window should be put as standard. Also, there should be other ways to resize windows aside the current ones. The gadget on the bottom right of the window is not sufficient. We suggest that all four sides of the windows should be draggable sizing gadgets like in X windows. The new libraries should also support dragging windows partially outside of the visible screen area. Dragging the entire window and its contents instead of just the border should also be supported. This function should be configurable in one of three possible ways: - Always move only the border (like now) - Move the border for size greater some user selectable value and for smaller windows move the whole window - Always move the entire window The cycle gadgets should be popup gadgets as in the MUI. This means that if a cycle gadget is clicked in the 'real' cycle image, to the left of the gadget, as it is now it should browse through the possible options one by one, while if it is clicked in the item part, it should open a popup window showing all of the possible options. This is what CycleToMenu by Federico Giannici and many other public domain utilities do. Also the screen depth gadgets should be popup gadgets. There already is a utility in the public domain called ScrMenu by Martin Blom that does this. Popup menus should also be supported by the GUI libraries. These are menus that open a window with the menu items anywhere on screen (and not just in the top part like now) when the right mouse button is clicked. Since many people like popup menus but as many don't, we do not mean in any way that the current menu handling should be replaced by popup menus. Instead, both ways should be supported. Also for some applications detachable menus are useful and should be supported. It is also important for menus to be fully keyboard controllable not only with the Amiga+key keyboard shortcuts. Opening the menus with the alt key and browsing through them with the arrow keys should also be supported together with the classic right mouse button Amiga approach. Support for screens in any number of colors greater than 256 is crucial. It would be useful to have the ability to open a screen in any number of colors, such as 512, 1024, and 2^n, with n up to 24 and 32, unlike other platforms that usually only support 256, 32k, 64k or 24 bit palettes. This feature alone could really make the difference. xx. ASL and other requesters The ASL library is outdated, uncomfortable to use and not configurable. Most of the users replaced it with the reqtools.library by Nico Francois and we feel that all of the featureos of this library should be straight- forward included in the next release of the ASL.library. The new requester library should allow: - Configurable default size and position of the requesters - Pointer relative requesters, meaning that all requesters should open where the mouse pointer is. - A standard palette requester that ASL does not have. The file requesters should have the following features: - The file requesters should show the available devices upon pressing the (middle?) mouse button as in the Reqtools.library requesters. - The file requesters should support multiselection by dragging the mouse. - It would be very useful to have 'MakeDir' and 'Rename' gadgets in file requesters. - Bring the screen they appear on to the front. - Should always appear in the visible portion of the screen (support of virtual screens). This means that if the requester opens outside the visible area, they should automatically move the screen so as to be visible. - Should be completely keyboard controllable like reqtools' file requesters. Most of the features listed were plainly taken from the ReqTools library documentation but there are so many more that cannot be listed here. xx. ARexx. The ARexx language is very powerful and widely used, but it can be improved. It is recommended that the ARexx integration into the operating system becomes even deeper. For example, for even more ease of use, it would be better if all menu items were automatically available to the ARexx port of a program. Also, it would be very useful to have GUI libraries usable from within ARexx. The Workbench should have an ARexx port too, so that all of its commands are available to outside programs. This single option would make the operating system much more powerful, with programs able to automatically open drawers and select files. xx. AmigaDOS and the Shell environment a. AmigaDOS does not include a true MOVE command. The Rename command does not support moving files across different devices. A simple macro called 'Move' can solve the problem. All it should do is check whether the source and destination are in the same device or not and call 'Rename' or 'Copy' and 'Delete' respectively. b. It would be useful to have command to split big files. c. AmigaDOS does not currently support multiple redirectioning. In particular the ability to redirect the output to both a file and the stdout is essential for some applications. In the public domain 'EchoHandler' by Henrik Nordstr does exacly this, or a command like 'tee' in UNIX could be used. d. The 'Dir' command sorts only the file names and not the directories. e. Some commands have not been localized properly, like 'List', 'Avail', and others. f. The Format command has some bugs and does not have allow a high density disk to be formatted in double density mode (880k) with an HD drive. Since only a minority of existing Amigas have built-in high density drives this is very annoying. g. The Search command algorithm should be optimized because now it is just too slow. See the utility list below for a better command already present in the public domain. Also, 'Search' should support multiple keyword search. h. The 'Initial-CLI' process does not use the new console handlers, does not have a close gadget, and does not have clipboard support. In fact, this Shell window has always had less features than the normal ones, and we can't figure out why. This is annoying when selecting 'Boot with no startup sequence' in the bootmenu. i. The support of multiple assigns is not "real". 'ADD'ed assigns are not sufficient. If one types "Dir ASSIGNEDPATH:", he/she should get a list of all files in all directories associated with that name, including the 'ADD'ed ones. j. The 'Please insert volume xxxx in any drive' requester should not only have the Retry and Cancel gadgets but should also have a 'Deny' gadget but most important it should have an 'Assign' and a 'Mount' gadget like in AssignWedge by Olaf Barthel. k. The 'List' would be even more useful if it displayed the total bytes used and not only the total blocks. l. The console handler is good but outdated. There are many substitutes in the public domain like 'KingCON' by David Larsson and 'GMC' by Goetz Mueller. Here are the main features that a new console handler should support: - File name completion with 'tab' key . - Output history buffer as in 'KingCON' with configurable memory usage. - Scrollbars in text Shells - Customizable F1 through F10 function keys (also with Shift, Ctrl, and Alt identifiers) - Ability to save the history buffer to a file with or without ANSI codes. - Possibility to have the current path in the title bar instead than in the prompt as in GMC. - Configurable actions such as shift-up/down ctrl- up/down, shift- return as in GMC. - Ability to store a line in the history without executing it. - Ability to enable the 'Pg Up', 'Pg Dn' and 'PrtSc' keys. The latter should allow to print either only the visible area or the entire buffer (in text mode). - Jump scrolling (selectable) m. The v39 serial.device is SLOW, and has serious speed problems with the new v.fast and v.34 28.800 bps modems. n. In addition to RAM: and RAD: there should be also (in fact the majority of the users use one) a dynamic recoverable ram disk. An example of this is STAT-RAM, in the Shareware market. This device is a mixture of both RAM and RAD. It dynamically allocates memory like RAM-DISK: but is also recoverable and reset-proof like RAD. xx. Disk and hard drive handling and maintenance The Amiga operating system has not either a defragmentation utility nor a recovery tool for both deleted files and corrupt media. We feel that these programs are essential in an operating system. The defragmentation program should have appropriate warnings about the possible damage that it can cause, for example in case of a black-out. Also, an 'Undelete' command should be included within the system. This program, however, should allow to undelete files only in a given directory, unlike current public domain and commercial programs that scan the entire device. There is not a data recovery utility such as DiskSalv by Dave Haynie either. Such a program is mandatory. This software should also allow partial recovery capabilities (for data files). Also, for data protection a small anti virus program should be included. Since an anti virus program cannot be kept up-to-date as necessary if it was included, what the system anti virus program should do is just checking the system vectors. On the other hand, it would be useful if a system brain file editor would be included, with the updates being left to the PD programmers. The system should also automatically mark the bad blocks of all devices, and any access to these blocks should be forbidden to avoid dreadful requesters like "Volume xxx has a read/write error on block yyyy". 19. Memory and task management. The memory and task management is not adequate for a real multitasking environment such as the Amiga operating system. All the people who contributed to the making of this document agree that the control that the operating system has over its tasks and the memory they allocate is not sufficient. There are many faulty programs out there and when they crash the system cannot recover in any way the memory they allocated. Memory fragmentation is also one of the single most important problems to be solved. Furthermore, the operating system should be able to quit a program and restore all of its resources. Note that this is very different from quitting from within the program. This could be done by making the usage of the commodities.library mandatory for all programs. Still, some form of memory protection should be implemented anyway. Most of us agree that such a feature is crucial for the new operating system, but we do realize that such features cause a huge waste of resources and processing time. This would make impossible to have low end and consumer computers, so something in the middle has to be found. We also feel that a flexible virtual memory support is required. xx. Software failures The software failures alerts are not appropriate for many reasons. a. They open only at 15khz. People that use VGA ONLY monitors can't see what's going wrong. We do realize that it is not easy, but all ALERTS should check for the monitor type, or the VGAONLY option is crippled. b. The messages of the software failures are too complicated for the low end user that always gets scared the first times these happen. We DO know this is much better than just freezing the computer, though. We recommend a much more friendly explanation of the error that occurred with the task name, not only the error number and task address. There are various utilities that add a short explanation to the error messages. One of these is the now outdated NewAlert by Martin Mares. The user should be given as much (verbose) information as possible about what happened. xx. Bootmenu The Bootmenu routines should be rewritten. One of the most incredible oversights in the operating system is the handling of the bootmenu only at 15khz. Users with VGA ONLY monitors have no access to the bootmenu options. This makes VGA ONLY monitors useless on Amigas. The user should be able to SAVE its custom boot configuration in a small nonvolatile RAM like in the Amiga CD32. We even have a support library 95% already done with the nonvolatile.library and with the battmem.resource found on the Amiga CD32. On the other hand, there should also be a "Reset to defaults" button, like in all preferences programs. Quite a few options would make the Bootmenu better: 1. Monitor type selection between PAL, NTSC, VGA, and MULTISCAN. 2. Better control over the processor options. All features should be present, like selectable Burst Mode, ExternalCache, Datacache, CopyBack, etc. and all should have a separate toggle button. 3. ROM password protection, also with a enable/disable button. 4. Ability not only to view the autoconfig cards present, but also to disable them at your need. 5. Ability to set the drive clicking on and off. 6. Ability to save all of the options. This should include also autoconfig cards, automount drives, processor mode, monitor type, etc. In particular, it should be possible to set a certain device not to automount and save it with this configuration. xx. Printers The printer support on Amigas has always been underdeveloped and below average standard quality. Here are some of our ideas: - There should be a printer spooler worthy of the Amiga multitasking - More, newer and up-to-date printer drivers. - Every printer driver should have its own configuration program - A printer driver editor should be included either in the operating system or in the Developer Kit. xx. Miscellaneous tools and goodies This is a list of all the utilities we think would complete the operating system. Many are just too massive to be included, but again if the system will be distributed on CD-ROMs then some public domain versions of these pieces of software should be included within the CD. - An external font viewer program should be included. This utility should allow to view the complete character set of any font. - A real-time compression commodity with different compression algorithms support. This would make up for utilities like 'Stacker' on PC-IBMs. - A small terminal program. - The support for the narrator.device and translator.library should be restarted and these libraries should be localized. - LAN and Internet support programs like E-Mail, Telnet, Mosaic, FTP... Since of course not every useful program around can be included within the operating system, there should be a guide of which programs are considered to be the most useful, with a short description of their functions and where to find them. xx. Compatibility with obsolete machines. All functions that retain compatibility with 1.0 and 1.1 should be removed from the Kickstart. These include OldOpenLibrary(), FattenLayerInfo() and others. Also, all functions that have been substituted starting from release 2.0 of the operating system should be considered obsolete and all support should be dropped for os < 2.0 Specifically, compatibility with Kickstart 1.3 should be abandoned in the preferences handling. IPrefs should be automatically executed together with LoadWB, and the DEVS:system-configuration file support should be dropped. List of mentioned utilities and authors --------------------------------------- 1. Name : ToolManager Function : Improve the desktop configurabilty trough customizable menus, docks, images, icons, appicons and hotkeys. Author : Stefan Becker E-Mail : stefanb@pool.informatik.rwth-aachen.de stefanb@yello.adsp.sub.org 2. Name : KingCON Function : Improved console handler Author : David Larsson Address : Gibraltarg. 82:150 S-412 79 GOTEBORG Sweden E-Mail : Internet : f92dala@dd.chalmers.se 3. Name : Reqtools.library and connected utilities Function : Better looking, easy-to-use, configurable requester library. Author : Nico Francois Address : Corbielaan 13 B-3060 Bertem BELGIUM E-Mail : Fidonet : 2:292/603.10 (Nico Francois) Internet : Internet: nico@augfl.be UUCP: Nico.Francois@p10.f603.n292.z2.FidoNet.Org 4. Name : MUI (Magic User Interface) Function : Totally new, customizable, stunning GUI Author : Stefan Stuntz Address : Eduard-Spranger-Strabe 7 80935 Munchen GERMANY E-Mail : InterNet : stuntz@informatik.tu-muenchen.de 5. Name : CycleToMenu Function : Transforms Cycle gadgets to popup menu gadgets Author : Federico Giannici Address : Viale Francia 4 90146 Palermo Italy E-Mail : mc4080@mclink.it 6. Name : GMC console handler Function : Flexible console handler Author : Goetz Mueller Address : Beim Wasserturm 3 W-7050 Waiblingen Germany 7. Name : EchoHandler Function : Allows mulitple redirection from the Shell Author : Henrik Nordstrom Address : Angsvagen 1 756 45 Uppsala Sweden Phone : +46-(0)18-303763 or +46-(0)18-300104 E-Mail : FidoNet: Henrik Nordstrom 2:206/108 (The Crystal) 8. Name : MagicWB 2.0 Function : How the operating system icons should look. Author : Martin Huttenloher of SASG Address : Am Hochstraess 4 D-89081 Ulm Germany E-Mail : Z-Netz : XEN@NATHAN.ZER Internet: xen@nathan.zer.sub.org Phone : ++49-(0)8362-81104 9. Name : ZGIF Datatype - Public Domain - could be included directly Function : A GIF datatype Author : ? E-Mail : sgoddy@cix.compulink.co.uk or 100014,674 on CIS 10. Name : ScrMenu Function : Opens a menu window with a list of open screens when the screen depth gadget is clicked with the right mouse button Author : Martin Blom Address : Alsattersgatan 15A.24 S-58251 Linkoping SWEDEN E-Mail : lcs@lysator.liu.se or d93marbl@und.ida.liu.se 11. Name : ArcHandler Function : Allows archived files to be viewed like directories, and all files inside can be read and/or executed transparently to the operating system. Author : Rafael D'Halleweyn Address : Perckhoevelaan 17 B-2610 Antwerpen BELGIUM E-Mail : Rafael.DHalleweyn@rug.ac.be 12. Name : MagicMenu Function : Allows popup menus. Author : Martin Korndorfer (con la dieresi sulla seconda o) Address : Pommernstr. 15 D-W8912 Kaufering, Germany E-Mail : Internet: korndorf@informatik.tu-muenchen.de Z-Netz: M.Korndoerfer@NATHAN.ZER or SYSOP@NATHAN.ZER (NATHAN BBS: +49 8191 65542/66085) Phone : (+49) 08191 / 6383 14. Name : NewAlert Function : Displays useful info about software failures Author : Martin Mares E-Mail : mjsoft@k332.feld.cvut.cz 15. Name : DiskSalv Function : Data restore utility Author : Dave Haynie Address : 284 Memorial Avenue, Gibbstown, NJ 08027 USA E-Mail : dave.haynie@scala.com hazy@cup.portal.com hazy@bix.com 16. Name : AssignWedge Function : Adds 'Assign', 'Mount' and 'Deny' gadgets in volume requesters Author : Olaf Barthel Address : Brabeckstrasse 35 D-30559 Hannover Federal Republic of Germany E-Mail : olsen@sourcery.han.de Concept and making by Federico Chiesa Ideas, contribution, support and help by (in alphabetical order): Paolo Agazzone Vincenzo Fodera` Mikael Osterhed Danilo Aghemo Rolando Francini Antonello Pardi Enrico Altavilla Mark Gallina Roberto Patriarca Claudio Alviggi Edoardo Galvagno Jan Pasotto Luca Baumer Gabriele Giambonini Denis Pavan Massimiliano Belletti Eugenio Gori Giuliano Pochini Giovanni Beltrame Bernardo Innocenti Luca Pompei Giovanni Calderone Vincenzo Iodice Marco Roma Norman Casagrande Raffaele Irlanda Francesco Ronchi Gino Casavecchia Marco Losurdo Michele Santucci Rocco Coluccelli Mauro Maltoni Demetrio Siragusa Marco Della Vecchia Maurizio Mugelli Flavio Stanchina Cesare Di Mauro Marco Musso Massimo Tantignone Luca Di Meo Luca Nonato Alessandro Zummo Fabio Filippi Massimiliano Origgi @endnode @node FEATURE3 "Escom Press Conference" @toc FEATURE =========================================================================== REPORT ON ESCOM'S MAY 30th FRANKFURT PRESS CONFERENCE By: Angela Schmidt uk8b@rz.uni-karlsruhe.de Translated by: Giorgio Gomelsky gio@phantom.com Thanks to Baffy and Fionn for proofreading/German-checking =========================================================================== [Faced with a $1,600 plane fare, I was unable to attend Escom's press conference. It was much cheaper to send Angela Schmidt instead, and she brought back the most important points of the presentation. -Jason] Escom has founded a division called Amiga Technologies GmbH. Escom considers the patents and rights they obtained from Commodore to be their keys in the multi-media market. The Amiga line will be continued under the name "Amiga" and distributed worldwide. Escom will use the "Commodore" label for Intel-based multi-media-PCs which will be distributed in Europe only. They did a market study in Germany and found that 93% of all PC users knew the name Commodore-literally, only the name IBM is better known here. As of August, there will be Pentium PCs with the name "Commodore", and Escom plans to sell between 50,000 and 60,000 before the end of the year. One month later, the Amiga 4000T should be produced in appreciable numbers. In the past, less than 1,000 were produced. They are planning to sell around 25,000 by the end of the year, 10,000 in the United States. The new 4000T will also have a new design. They are making big efforts so as to have a new design from the very beginning. It has been mentioned that the new A4000T will have a SCSI connection that was missing from the 4000s. This was considered to be a major disadvantage in the original 4000s. A month after that (October), it is planned to make the A1200 available again. They are estimating that between 120,000 and 150,000 will be sold by the end of the year. They will try not to miss Christmas sales by all means. With the CD32, several problems have shown up: It is not easy to get hold of all necessary components needed for the production of the CD32. There seem to be problems in supplying those parts. For this reason there wont be CD32's until next year. Until then, the CD32 will get a far more attractive design, to compete with the game consoles. Eventually, in the future, there will also be slightly altered CD32s for set-top boxes. It is possible that next year there will also be an A1300, based on a 68EC030, which would also have a CD-ROM drive as a standard feature. Also, the first of the Amiga Technologies-based set-top boxes may be built immediately. Escom has licensed Viscorp to build such a unit. In this area of licensing, they will be open to other possibilities. With regards to the future, they are considering building a RISC-chip based Amiga. PowerPC and the HP-PA RISC chip are being considered, but no decision has been made yet. At any rate, there shall be an Amiga operating system for this RISC-based system, because AmigaOS simply belongs to the Amiga. The porting of AmigaOS to non-Amiga platforms is also being talked about. This would bring the Amiga closer to the mainstream. With regards to the use of AAA, no decision has been made. Jeff Frank, Engineering Director of Amiga Technologies, has announced an expansion of the A4000T, one based on the 68060 turbo card which is will likely be very similar to the CyberStorm 060 card, since there seem to be licensing agreements with Phase5. An expansion of the A1200 to an 68EC030 may also be considered. The new Amigas will be bundled with a product from Scala (MM 300). Whether a good word processor and paint program would have been preferable is open to argument. Amiga Technologies plans a turnover of 100,000,000 DM in 1995, which mainly is to be achieved by Christmas business. At the moment, the monthly expenditure is in the region of 600,000 DM. But the intention is to get into the black by the end of the year, and by spring of '96, the $10 million cost of acquisition should also be covered. The central distribution will be in Holland. There will be different methods of distribution-for instance, through wholesalers, store chains, and mail order houses. The Amigas will additionally be distributed through special distributors. Commodore will offer sales- and marketing support to their resellers. Furthermore, there will be a program in Europe for the training of distributors. The customer support should also be considerably improved. It has been mentioned several times that ESCOM received an overwhelming amount of faxes and letters, most of which had to remain unanswered. Many have sent them their wishes for the future. There were also expressions of concern from the users about the Amiga being taken over by a PC manufacturer. Amiga Technologies would also like to be directly on the Internet very soon. For this purpose, there will be an Amiga connected to the net. @endnode @node FEATURE4 "Interview with Dr. Peter Kittel" @toc FEATURE =========================================================================== RADIO HAMBURG INTERVIEW WITH DR. PETER KITTEL, AMIGA TECHNOLOGIES German transcription by: Olaf Schaper eaa@sk.shnet.org English translation by: Giorgio Gomelsky gio@phantom.com =========================================================================== Klaus Dieter Ackermann, in his Radio Hamburg program Online, included an Amiga item-a telephone interview with Dr. Peter Kittel, head of the Product Planning Group for Amiga Technologies GmbH. KDA: Hello, Dr. Kittel! You have for many users, a couple million at least, you've pulled the straw out of the water! You've done it again, so to speak. PK: Right. You know, you have to start from the point that in Germany we have quite a big Commodore community. In Germany, there has always been a big Commodore community, with many collaborators, who were always busy with the Amiga. There was a lot of passion. At the moment, we are gathering all these people together again so that we may be able from Germany to be able to bring the Amiga back to full strength. It's nice to consider that there is a lot of Amiga competence in Germany so that we don't have to start from scratch. KDA: Yes, I've got four computer freaks here who know the machine inside-out. You might have heard my introduction earlier. What the Amiga is capable of today or was 5 or 6 years ago, that's what the PCs of today slowly have become capable of imitating. PK: Yes. And we're always surprised by this fact. We never had the impression that we had achieved something incredible. But there are still things that neither the PC nor the Mac can do without trouble. KDA: Things which of course even today are not even quite been achieved by them today. Just a few days ago I spoke with Karola Bode, whom you probably know, about the situation. Although she also lost her job with Commodore, she is also happy that the system is coming back to life. PK: Correct. That is what is so fantastic in the Amiga community. Consider also that on the level of the company here, there are all kinds of cross-refences to the whole of the German microcomputer business scene, so that one is involved with old friends, that being back on the scene you bump into your old friends again. So much so that now we know, more than ever, what our competitors are up to. KDA: Good. Now, let's look a little bit at the future. When is the whole thing going to start? When will the first Commodore reappear? And which models will we see again soon in the shops? PK: At the moment, we already have two people who do nothing else than, all day long, make phone calls all across the world to get the production going again-to track down the special parts which we need from every corner of the planet. That will take a bit of time, then we have to find manufacturers that will build our boards because we cannot as yet do this at Escom. As you know, Escom has until now only done assembly of computers (adding to that hard drives). We have to give it to outside people to do. But there are many factories abroad, where Commodore used to manufacture. And if nothing abnormal happens inbetween, we'll get that going as well. And our timing is such that we hope to deliver the first machines in September. If something unforseen happens, it could be a little later. This means that at the moment, we can't really seriously promise anything, but let's say that if everything goes well, we'll release the first machines in September. KDA: Well, how does it look, then? In Braunschweig, there was a very important production site. Is that not available? PK: No, the production in Braunschweig was closed down some years ago. In more recent times it was only a warehouse with service attached to it. Anyway, Braunschweig was assembly, they didn't make any boards there. In this respect, it wouldn't have been a solution. KDA: There was a big fuss with regards to the taking over of Commodore. The rumors said there was a big Japanese wholesaler in what we call "brown-ware" wanted to take over the company. And then we heard that nobody was doing it, and then suddenly, like the phoenix from the ashes, we saw over the wires that Escom had bought it. [Brown ware is a term for radios and home electronics. We puzzled over this one for a long time... -Jason] PK: Yes, in hindsight, and I wasn't as yet employed by Escom, I've only been there two weeks, I've heard from my new colleagues that the action to take over Commodore started over half a year ago. But they behaved in a very skillful way for not letting it come out, and that way other potential competitors were not aware of their desire. If they had noticed, they probably would have pushed the price up. So I think Escom had a skillful politic here and for all intents and purposes saved quite a lot of money. KDA: Correct. Otherwise, the price would probably have really gone up. The rumor has it that you have a Commodore 64 as a headrest, and as a comforter, an Amiga, and that you know the system partially better than the developers. PK: No, no, no, that's not correct. I have to insist upon this-I knew the 64 only a little bit, because the C-64 resembled the old CBM 8000s. I first came together with Commodore on the Pet 2001, and later became an 8000 freak. Since the C-64 was 90% similar to the 8000, I was able to do something with the 64. As my headrest, at most, there would be a small Amiga 1200. KDA: Dr. Kittel, this is a hectic life. We have a lot of questions here. But to start, let's speak about the software. You are going to re-activate the whole developer support community so that programmers go back to the Amiga. PK: Luckily enough, we don't have to reactivate that much. These guys are always ready to go. They were all following the Internet, and as soon as the communication came that everything was falling into place, they announced themselves immediately. (They called Escom) Also, our infrastructure is here, we had an internal network for registered developers that was never stopped. We found in some countries partners who already had taken care of the network while the Commodore subsidiaries shut down. They kept the network running, always ready to go. We can let the whole thing come back to life quite easily, continue it like nothing happened. KDA: Is it realistic that we say that the first Amigas will be seen in the shop by the end of the year? PK: As stated before, as far as we're concerned we're going ahead full-steam. If nothing else comes up, in September. We of course do not want to miss the Christmas season. KDA: I can imagine. Where will we be able to buy the Amiga? Will it be exclusively your stores, or in other stores as well? PK: No, no, the new Amiga company will be very different in this respect from the old Commodore situation. The intention is to have a very liberal policy. On the one side with regards to sales-anyone that wants to sell an Amiga will get one to sell. And exactly what it will look like with the Escom chain stores has not as yet been totally discussed. But I proceed from the point of view that they also will get Amiga computers to sell. At the same time, this liberal policy that we want to follow would also be applied to things concerning licensing. For instance, if someone wants to create an Amiga compatible computer or something really great like a laptop, he will be able to get the license for that immediately, as well as the special chips which are needed, which in the old days of Commodore was never possible. KDA: Correct. How will it then look? I have here for instance a question with regards to 'Will there be a card for the PC that will simulate the Amiga or emulate the Amiga?' PK: Well, at least we're thinking about this. You also should be aware that such a board could be very expensive to put out, and you have to be practical. To put three-quarters of an Amiga on a board like that so it really functions as a compatible device might not be all that cheap to put together-and then it wouldn't be that certain that many people would buy it. We are thinking about it, we're looking into it, but I cannot promise at the moment that this will happen. KDA: You already notice the question-many with an Amiga have gotten a PC for themselves, without having discarded the Amiga-just in case. So it seems that there is quite a lot of people out there that are a captive audience. I wish you all the best, and I hope that you can come out with the Amiga in the German market as soon as possible, and all the users will probably, and I'm saying this quite soberly, be sitting at your feet and will rejoice that finally the machine is rising again. PK: Thank you very much. KDA: Good, so I wish you a very wonderful evening, and thank you for having this interview. @endnode @node FEATURE5 "The GIF Controversy" @toc FEATURE =========================================================================== THE GIF CONTROVERSY: A SOFTWARE DEVELOPER'S PERSPECTIVE Michael Console Battilana mcb@cloanto.it =========================================================================== [Yes, we ran an earlier copy of this article when the story first broke. However, considering Mr. Battilana's close relationship to the story, particularly the emergence of the new PNG graphics format, I feel that if he has something more to say, it's worth a second look. -Jason] January 27, 1995 - Text revision 2 - March 31, 1995 by Michael Console Battilana Copyright (c) 1995 Cloanto Italia srl, All rights reserved Parts are quoted with permission from CompuServe Information Service Parts are excerpted from the PNG specification Permission granted for non-profit electronic distribution Suggested file name: "giflzw1.txt" Keywords: GIF PNG LZW WELCH COMPRESSION UNISYS PATENT HISTORY TEXT Free by mailing before May 31, 1995 This article was written with great care. It may reflect personal opinions of the author, which are not necessarily shared by the publishers, who cannot assume any responsibility for mistakes or misprints. Nothing in this article should be regarded as legal counsel. If you require legal or other expert assistance, you should consult a professional advisor. Many of the designations used by manufacturers and sellers to distinguish their products are trademarks. The author of this article has made every attempt to supply trademark information about manufacturers and their products. GIF and Graphics Interchange Format are service marks of CompuServe Inc., an H&R Block Company. PostScript is a registered trademark of Adobe Systems Inc. TIFF is a trademark of Aldus Corp. Abstract During the past eight years, GIF (Graphics Interchange Format) peacefully became the most popular file format for archiving and exchanging computer images. At the end of December 1994, CompuServe Inc. and Unisys Corporation announced to the public that developers would have to pay a license fee in order to continue to use technology patented by Unisys in certain categories of software supporting the GIF format. These first statements caused immediate reactions and some confusion. As a longer term consequence, it appears likely that GIF will be replaced and extended by the new PNG (Portable Network Graphics) format. Introduction This is a very interesting case, which could teach more than one lesson on the theory and practice of software and the laws. There are many entities involved. Fingers have been pointed at lawmakers, Unisys, CompuServe and developers. In theory, it may have been possible for any or all of these parts to prevent the matter from creating so much anxiety in the first place. Yet we are all here, debating on this issue. This article intends to provide a collection of information from the history of the controversy to the most recent events, as they were perceived by a software developer. CompuServe released GIF as a free and open specification in 1987. GIF soon became a world standard, and also played an important role in the Internet community. It was well supported by CompuServe's Information Service, but many developers wrote (or acquired under license) software supporting GIF without even needing to know that a company named CompuServe existed. GIF was relatively simple, and very well documented in books, articles and text files. GIF images are compressed to reduce the file size. The technique used to compress the image data is called LZW (after Lempel-Ziv-Welch) and was first described by Terry A. Welch in the June 1984 issue of IEEE's Computer magazine. Unisys holds a patent on the procedure described in the article, but the article describing the algorithm had no mention of this. The LZW procedure was simple and very well described, and it soon became a very popular technique for data compression (just as GIF would become a standard in its own field). It appears that neither CompuServe, nor the CompuServe Associate who designed GIF, nor the computer world in general were aware of the patent. GIF is not alone in the use of LZW. The TIFF file specification also includes LZW-compression among its compression methods, and so do dozens of very popular file archiving programs (such as Compress). While having the right to pursue legal action or seek damages against infringing LZW developers and publishers, Unisys has so far been very accomodating and fair. It is likely that the success of LZW and its thousands of implementations, especially among small developers, caught Unisys unprepared. Otherwise, it would be difficult to understand how Unisys could first allow a very large number of small and big developers to use LZW for years, and then, after the establishment of various standards based on LZW, change its attitude. The original CompuServe/Unisys licensing agreement text which had upset so many developers was immediately followed by clarifications from both CompuServe and Unisys. Given that the online community tends to be suspicious about anything that is big, has a legal department or owns software patents, Unisys had to face a particularly delicate challenge. But it probably wasn't easier for CompuServe, who had to explain the patent issue to its own developers, some of whom felt "betrayed". The outside world would learn about this issue from the press in the following days. Even Time Magazine reported about this matter, although like most of the newspapers it concentrated on GIF more than on TIFF, LZW, Unisys or software patents. In the meantime, a group of leaders of the online graphics community began working on a patent-free future of GIF. These efforts would later converge into the PNG specification (scan this text for #1). The full texts of official statements from CompuServe and Unisys are also included at the end of this article (scan this text for #2). Among the first reactions, some bulletin board systems had all GIF files deleted from their hard disks (or converted into JPEG format). Common remarks included: "PROTEST OF NEW COMPUSERVE-UNISYS GIF USAGE TAX !!" "They [CompuServe] seem to think that GIF is the greatest thing since free online magazines." "The announcement by CompuServe and Unisys that users of the GIF image format must register by January 10 and pay a royalty or face lawsuits for their past usage, is the online communications community's equivalent of the sneak attack at Pearl Harbor." These reactions may require some clarification. Unisys, and not CompuServe, has been "trying to impose" a royalty. The problem is not specific to GIF, but includes TIFF and archiving software. GIF files are not covered by the patent. There is no risk in distributing GIF files or in using the GIF name. According to a CompuServe spokesperson, "Recent discussions of GIF taxes and fees are totally without merit. For people who view GIF images, who keep GIF images on servers, or who are creating GIF images for distribution, the recent licensing discussions have no effect on their activities." Only the software employing the LZW algorithm for writing GIF files is "at risk". The Unisys patent includes claims which specifically cover the decompression of LZW-compressed material, so it may also affect simple GIF readers. Several patent attorneys consulted on this matter have concluded that decompression-only programs do not infringe upon the Unisys patent. Unisys however does not appear to share this opinion. A format such as JPEG cannot be used as a substitute for GIF. Unlike GIF (and PNG), JPEG was designed as a "lossy" format. This means that it slightly changes an image as it is compressed. This is unacceptable for many applications. Also, while JPEG excels in compressing real world true color images, it offers no support for palette-based images. The CompuServe licensing agreement was intended as a voluntary service to the few dozen developers creating software for use primarily in conjunction with the CompuServe Information Service (CIS). This includes applications such as CompuServe "navigators", but does not apply to general purpose GIF readers/writers (which are not intended for use primarily in conjunction with CIS). On January 27, 1995, Unisys announced new licensing policies regarding "The Welch Patent". These include a .45% royalty on the total unit selling price of GIF/LZW products (minimum $0.10, maximum $10.00 per unit) and a .65% royalty on GIF/TIFF/LZW products (minimum $0.20, maximum $25.00). For further information and a copy of the written agreement it is possible to call Unisys at +1 215 986-4411, or send E-mail to . Any organization using LZW should look at whether they have an infringement on Unisys' patent. CompuServe is not involved in any of these discussions - they are between Unisys and outside developers. Software Patents Normally, procedures such as LZW are published in magazines so that they can be shared by the community of software developers. LZW itself is a refinement of other algorithms published in the years before (Ziv-Lempel and others). Software is usually protected by copyright law, but in recent years (since 1981 in the USA) in several countries it has become possible to patent software. Initially, only software used to control hardware could be patented. This interpretation was soon extended to include all types of software (except for "pure mathematical algorithms"). While software patents have become an opportunity for many, they remain a controversial danger for others. Any programmer or publisher might be trapped at any time by a patent infringement claim that could not be foreseen or avoided. Publication of an algorithm in a magazine does not automatically exclude a patent application. In many countries, including the USA, it is possible to apply for a patent and still publish the paper without mention of the application. In the USA (but not in many other countries), the patent application may even be filed within 12 months of the publication. Under such regulations, the only algorithms that might be used freely and without risk would be those published prior to 1981 (e.g. Donald Knuth's "The Art of Computer Programming"). Today, even designing a graphics file format can become a programmer's nightmare. One very active member of the Internet community (and author of the GZIP compressor) has collected information on more than 350 patents on lossless data compression and 100 on lossy image compression. Lempel, Ziv, Cohn and Eastman patented their original LZ78 algorithm (US patent 4,464,650). The LZW algorithm which is now attracting so much attention is patented by both IBM (4,814,746) and Unisys (4,558,302), while British Telecom (BT) holds a similar patent. The IBM patent application was filed three weeks before that of Unisys, but the US patent office apparently failed to recognize that they covered the same algorithm. (The IBM patent is more general, but its claim 7 is said to be exactly LZW.) 10 Years of LZW While the original article on LZW was published in 1984, the LZW patent issue first surfaced in the press in 1989, when the BTLZ algorithm (a procedure similar to LZW developed and patented by British Telecom) was to be approved for data compression into the V.42bis modem standard. Unisys said on at least one occasion that it first began to learn of the widespread use of LZW in connection with the development of this standard. The first licensing arrangements put into place included those with modem manufacturers ($ 20,000 for each one-time license) and with Adobe PostScript developers ($ 10,000). An article on "LZW Data Compression" was published in the October 1989 issue of Dr. Dobb's Journal (see the Bibliography section for more details - scan this text for #4). A reader replied in the December issue explaining that the algorithm was patented. The author of the article added that he was unaware of any patent on the algorithm. More readers wrote, and in the March 1990 issue the editor-in-chief dedicated his Editorial to this topic, which in his words "sparked a forest of fires". The same issue also contained an official statement by Unisys Corporation, which confirmed that LZW was patented, mentioned the modem industry, and indicated how developers could contact Unisys. In the October 2, 1989 issue of PC Week a columnist wrote: "Alas, there's no consolation for developers of archiving programs that rely on the LZW data-compression algorithm. While cruising the bulletin boards last week, Spencer learned that Unisys has a patent on the algorithm, upon which a slew of data-compression programs are based. Watch out." In about the same period, an article in InfoWorld mentioned the fact that modem manufacturers were facing the possibility of having to pay royalties to Unisys and to other patent holders for the right to use LZW. Page 132 ("LZWEncode Filter") of the PostScript Language Reference Manual, Second Edition, published in December 1990, contains the address of the Welch Licensing Department at Unisys Corporation. In the March 1991 issue of Byte, Steve Apiki ("Lossless Data Compression") explained that LZW is used in GIF, and that "The [LZW] algorithm itself is patented by Sperry [now Unisys]." At this point, at least the readers of some publications were potentially aware of the LZW patent. But still, there were few links to GIF. Unisys apparently didn't know about GIF, nor did most GIF developers know that GIF contained LZW technology. And those who may have known, not necessarily knew about the patent. This issue was also discussed among a small group of the better informed members of the CompuServe PICS Forum (now GRAPHSUP). The general feeling at that time was that "Unisys only intends to get royalties from hardware vendors," and there was some consensus on the idea that Unisys "wouldn't do anything about pure software implementations". Until the end of 1994, discussions on CompuServe's Information Service showed no clear mention of the requirement to get a license from Unisys for using LZW in GIF applications. During 1988 at least one developer stopped working on GIF tools because of considerations regarding the LZW patent, and reportedly "made CompuServe aware of it". This apparently was limited to private verbal conversations, and information on this behalf could be found neither in the press nor in CIS. Among the developers who contacted Unisys between the end of 1990 and the beginning of 1991, there was at least one GIF developer. He recently described his experience: "Finding the right person was the most difficult part of licensing LZW, but hopefully it's easier today (perhaps only 5 phone calls would be needed!)... When talking to Unisys back then, my recollection is that we had to basically tell the people at Unisys, 'Believe me, you DO own a patent on LZW; who do we talk to about LICENSING?' When we finally reached the licensing/legal department, THEY knew they had a patent, and spelled out the terms. I recall the person we were dealing with saying something like, 'They [Unisys] laugh when I make all these $1 deals, but we have to charge something to protect the patent.'" In those days, the standard license fee for PC-based software products was $1 per copy sold (or a 1% royalty), after a $100 advance payment. Apparently, Unisys still didn't know that GIF was based on LZW. In January 1995, Unisys stated: "Two years ago, Unisys learned that the LZW method was incorporated in the GIF specification and immediately began negotiations with CompuServe in January of 1993. We reached agreement with CompuServe on licensing the technology in June 1994..." Two years before the Unisys statement, at the end of 1992, Cloanto, an Italian software house, contacted Unisys because it was interested in a license for the possible use of LZW in its PostScript Level 2 drivers. That correspondence also mentioned GIF and TIFF as using LZW, and anticipated some of the controversies which would follow 25 months later. Unisys replied: "... You raise a number of interesting issues which require consideration..." While disclosing the full contents of this correspondence would probably not serve anyone's interest, the text of two letters sent to Unisys in 1992 is included at the end of this article (scan this text for #3), because the author feels that this 1992 perspective could complement the article with a few interesting ideas. The letters have not been edited, so some details (such as the reference to ZIP) may be incomplete with respect to current knowledge. Unisys offered Cloanto a $ .25 per unit royalty (1% of the net income) as an alternative to the PostScript one-time license, but did not answer the question raised by Cloanto: "If we implemented a software GIF or TIFF image file loader and saver (both formats are based on the LZW algorithm), would we need a license from Unisys Corp., as far as U.S. Patent 4,558,302 is concerned?". According to public statements, Unisys did however contact CompuServe the following month. December 29, 1994 - The Days After Between 1993 and 1994, the majority of developers still didn't know that GIF employed a patented algorithm, although both Unisys and CompuServe were aware of this (as the developers would learn in December 1994). Different opinions have been expressed on this. Some developers feel that reaching an agreement behind the scenes was the least destructive thing that could be done. Other (at times passionate) opinions picked up on electronic media are similar to these three: "Consider this. CompuServe admits to knowing about patent problems with the GIF file format as early as January of 1993. ... We added GIF support to Fastgraph months after CompuServe admits knowledge of the patent problem... We relied on the information that was supplied to us by CompuServe. If CompuServe had told us the truth when they knew it, we never would have added GIF support..." "If I chose to put GIF encode/decode functions in my software development toolkits, my main threat of legal liability would not come from Unisys, but rather from one of my customers being sued by Unisys, who would turn around and sue me for selling them some code that contained patented algorithms." "I still don't have a clue what my situation is if I want to sell source and object code that imports and exports GIF images. I am not in the end-user app business, but my customers are, and they certainly will have to have an LZW license, but what about me? I've talked with Unisys by voice and E-mail, and the voice discussion was entirely unsatisfactory as I posted when it happened - basically the Unisys guy said anyone who sells code for $100-$300 a pop was a total _____ for selling it that cheap. The E-mail discussions I've had said 'OK - we hear you - we'll get back to you.' Never happened." Unisys replied in part with reassuring clarifications to the general public, explaining that if the software was developed prior to 1995, or if it is public domain or freeware, the developer need not to worry: "... Unisys does not intend to pursue previous inadvertent infringement by versions of GIF-based software products marketed prior to 1995... Unisys does not require licensing, or fees to be paid, for non-commercial, non-profit GIF-based applications, including those for use on the online services... Commercial developers... are expected to secure a licensing agreement with Unisys for software products introduced beginning in 1995, or enhancements of products that were introduced prior to 1995." However, these statements were followed by far more restrictive interpretations. It soon became clear that Unisys could be demanding royalties for everything "manufactured" after 1994. One developer contacted Unisys and reported: "I called the Unisys lawyer you referred me to and he confirmed this position. Even a book or CD containing *pre 1995* freeware is subject to royalties if the disk is put together in 1995... Royalties must be collected *again* for each update release." While the new Unisys licensing policies (announced on January 27, 1995) enabled many software publishers to again ship their products after a month-long pause, other developers preferred to wait, hoping for a patent-free evolution of GIF. Comments included: "What if I sign up and then they announce a new GIF specification which does not use LZW?" "Labeling and user notification requirements in the agreement are ridiculous. I understand their desire to 'spread the word' about their patent, but they're telling me that I have to provide far more info on their ownership of the patent than they require in the docs/packaging of modem manufacturers and other users of LZW. Fair is fair. A blurb in the online help and docs should be sufficient; a 'non-defeatable' splash screen at startup is going too far." "Unisys is attempting to control how we (and other shareware authors) do business, and to make us billboards for their LZW patent... By making me tell my users how many security backups they can make, etc., they're telling me how to run my business and how to interface with my customers." "Imagine the nightmare of having to pay royalties to 10 patent holders, each of whom tells you how to run your business..." "Unisys has given us a chance to work together to change the system - rather than waiting to be sued one by one for this patent or that. We can win the fight against software patents, if we speak loud and clear against them." Some of the most active developers decided to collaborate on the design of a patent-free evolution of GIF (and TIFF's LZW compression mode). A variety of different procedures and data structures (such as Shannon-Fano and AVL trees) have been used to compress data in ways similar, if not equivalent, to LZW. But this diversity apparently does not escape the patent. As one expert said, "If the output data is GIF, the compressor infringes the Unisys patent regardless of the algorithm." On January 16, 1995, CompuServe declared its intention to coordinate the development of GIF24, a freely usable successor to GIF capable of 24-bit lossless compression. Several developers invested a lot of time and energies to solve the Unisys patent problem, and rapidly worked out different modifications to the GIF specification. One of the better known efforts was the project for a "GEF" graphics-exchange format. GEF and GIF24 converged into PNG (official abbreviation of "Portable Network Graphics", unofficially "Png is Not Gif"). The open architecture of PNG preserves the simplicity that made GIF so popular, and adds features such as true color. Test results indicate that PNG is capable of (losslessly) compressing true color images better than any other widely used image format. It is also more effective than GIF in storing palette-based images. (More information on PNG is included in the Reference and Bibliography sections.) At the end, it appears that if so many efforts converge into a new, improved standard, we still have to give part of the credit to the LZW patent... The author of this text can be contacted at . Any comments, or experience you would like to share, would be very appreciated. Reference [search key: #1] If the excerpts from the PNG specification are not included here in order to keep the file size reasonable ("lossy compression"), please check for another file accompanying this text (suggested file name: "giflzw2.txt"), or send E-mail to before April 30, 1995. The latest hypertext version of the full document is available on the World Wide Web: ----------------------------------------------------------------------- Excerpts from the PNG (Portable Network Graphics) Specification, Ninth Draft - Revision date: 7 March, 1995 [The text is not included here - Newer PNG specs have been released] ----------------------------------------------------------------------- [search key: #2] If the official texts from CompuServe and Unisys are not included here in order to keep the file size reasonable, please check for another file accompanying this text (suggested file name: "giflzw2.txt"), or send E-mail to before April 30, 1995. ----------------------------------------------------------------------- AGREEMENT FOR USE OF GRAPHICS INTERCHANGE FORMAT(SM) [The text of the Graphics Interchange Format (GIF) Developer Agreement, released by CompuServe on December 29, 1994 is not included here. It became obsolete when Unisys announced its new licensing policies regarding "The Welch Patent" on January 27, 1995.] ----------------------------------------------------------------------- Bibliography [search key: #4] [Author Unknown - Information Appreciated] "Spencer the Katt" PC Week, October 2, 1989 Adobe Systems Incorporated "LZWEncode Filter" PostScript Language Reference Manual, Second Edition Addison-Wesley Publishing Company ISBN 0-201-18127-4 Apiki, Steve "Lossless Data Compression" Byte, March 1991, pages 309-314, 386-387 Association of Shareware Professionals Forum CompuServe GO ASPFORUM Bell, Timothy C., Cleary, John G. and Witten, Ian H. "Adaptive Dictionary Encoders" Text Compression Prentice Hall ISBN 0-13-911991-4 Boutell, Thomas (Editor) PNG (Portable Network Graphics) Specification Ninth Draft - Revision date: 7 March, 1995 Hypertext version available on the World Wide Web: Clay, Betty "Texas Tales" ICPUG Newsletter, January/February 1995, pages 18-23 Cloanto Italia srl Supplement to Personal Paint Manual Version 6.1/1995, January 27, 1995 CompuServe Graphics Developers Forum (GO GRAPHDEV) CompuServe Graphics Support Forum (GO GRAPHSUP) Console Battilana, Michele "LZW Data Compression without Hashing" University of Udine Exam Project, July 9, 1987 Elmer-Dewitt, Philip "Will Gates Get the Net?" Time, January 30, 1995, Page 47 Erickson, Jonathan "Patent Letter Suits" (Editorial) Dr. Dobb's Journal, March 1990, page 6 Erickson, Jonathan "The Green, Green Cash of Gnomes" (Editorial) Dr. Dobb's Journal, April 1995, page 6 Gardner, Ray "LZW Patent Issues" (Letter) Dr. Dobb's Journal, December 1989, page 8 Internet comp.graphics Newsgroups Internet comp.sys.graphics Newsgroup Knuth, Donald E. The Art of Computer Programming Volume 3 / Sorting and Searching Addison-Wesley Publishing Company ISBN 0-201-03803-X Landy, Gene K. The Software Developer's and Marketer's Legal Companion Addison-Wesley Publishing Company ISBN 0-201-62276-9 Miles, J. B. "Patent Issues May Stall Approval of New V.42bis Modem Standard" InfoWorld, approximately fall of 1989, pages 43-44 [Author, Article Title and Exact Date Unknown - Information Appreciated] [InfoWorld Article on LZW and Modem Implementations - Is this it?] Nelson, Mark R. "LZW Data Compression" Dr. Dobb's Journal, October 1989, pages 29-36, 86-87 Nelson, Mark R. "LZW Patent Issues" (Reply to Letter) Dr. Dobb's Journal, December 1989, pages 8-12 PNG (Portable Network Graphics) Information and support material available from: Internet comp.graphics Newsgroups Internet comp.sys.graphics Newsgroup CompuServe Graphics Support Forum (GO GRAPHSUP) Via FTP from The PNG specification is also available on the World Wide Web: Unisys Corporation "Patented Algorithms" (Letter) Dr. Dobb's Journal, March 1990, page 8 Vaughan-Nichols, Steven J. "Saving Space", "Squeeze, Squash, and Crush" and "Legal Seagull" Byte, March 1990, pages 237-243 Welch, Terry A. "A technique for high-performance data compression" IEEE Computer, June 1984, pages 8-19 Ziv, Jacob and Lempel, Abraham "A universal algorithm for sequential data compression" IEEE Transactions on Information Theory, May 1977, pages 337-343 Ziv, Jacob and Lempel, Abraham "Compression of individual sequences via variable-rate coding" IEEE Transactions on Information Theory, September 1978, pages 530-536 Special thanks to Dave, David, Diana, Frank, Jason, Jean-loup, Jon, Kevin, Larry, Pierce, Richard, Tim, Tom and many others for their precious help. @endnode @node FEATURE6 "Quasar/Chris Hames Conference" @toc FEATURE =========================================================================== QUASAR DISTRIBUTION/CHRIS HAMES ONLINE CONFERENCE =========================================================================== [An IRC conference was recently held with Chris Hames, author of PC-Task 3.1, DirWork 2.1, and the wildly useful Degrader, to name a few. His publishers, Quasar Distribution, were also on hand.] jcompton Welcome, everyone, and thanks for coming to the Amiga Report-Quasar Distribution/Chris Hames online conference. No sneaky reprinting in magazines without asking. Our guests are Bytey, Chris Hames, author of many outrageously useful Amiga products,and JustinD and PeterF from Quasar Distribution. Justin, would you please introduce the entourage? JustinD Well First and foremost we hace ChrisH (Chris Hames), developer of PC-Task, DirWork, Degrader VMK and a few other odds and sods, PeterF (Peter Fregon) is a director of Quasar Distribution, and apart from the daily rigours of life in the Amiga business community writes most of our user manuals, as well as offering Tech Support for DirWork & PC-Task and finally me (Justin Deeley). I'm the other director of Quasar Distribution and provide Tech Support for PC-Task, as well as doing bits and pieces of manuals... I'll hand back to you now Jason. jcompton Chris or Peter, anything to add? PeterF Nope ChrisH I am stupid enough to write the software, including emulation, also to get up at 7:30am jcompton BTW, Quasar has been nice enough to donate a PC-Task T-shirt and a three pack of DirWork2, PC-Task 3, and a PC-Task 3 t-shirt. More on that when people win them. :) jcompton (BTW, the t-shirt goes to the first question. Congrats.) Arc First off, let me say that all of you do truly rock, and deserve a huge amount of respect for not only what you do for the Amiga community, but as good coders as well... Heres my question. Q: Have any of you been approached by UU/Jim Drew regarding work on the Emplant PC, and, will you guys soon move your efforts into hardware rather than software? ChrisH I was emailed by Jim years ago saying "we were going to license your PC-Task but that company has already done so. Of course that wasn't true and I have never heard of them. As for hardware, I don't plan to require giant dongles :-) PeterF Quasar Distribution has not been approached in any way. Harv Hi. I have a two part question for you. Part (1): I own the DevWare-packaged PC Task 2. How do I upgrade to 3.1 (DevWare never notified me in any way) and what's the cost in US$? part (2) - asuming I get 3.1, what kind of x86 emulation speed could I realistically expect running windows '95 (can that be done?) on a 40mhz 030. GA done. thanks. ChrisH I will let Quasar handle the upgrade question. But I would like to add DevWare are bastards and still owe me money, rot in hell guys. JustinD Upgrading from PC-Task 2 (DevWare version) is simply a matter of providing us with some form or proof or purchase and payment for the upgrade. Upgrades are priced at AUD $50.00 + AUD $10.00 shipping (currently about USD $44.00). ChrisH Windows 95 requires a 386 and hence can't be done with the current release PC-Task. And any new release will be faster but I am not going to estimate how much at this time. BloodHaw_ Okay, I've heard that disabling multitasking, and having PC-Task use the full CPU won't speed it up significantly, is this true, and why? ChrisH Yes it doesn't make barely any difference. This is because a high priority task gets most of the CPU time when multitasking i already running. I did test this. ChrisH Also if you go non-multitasking you have to write Hard dik drivers for everything under the sun a well as the rest of the default hardware etc. Not Worth it. Tau (Amiga task switching is really fast.. that's why it doesn't hurt) alias Tnxs for great pgms - when or will you support the Retina Z2 card? PeterF When we get one :-) JustinD Screenmode Database support on the retina's part might also help ... ChrisH Ww will support anything that supports the display database. Frotz OK, so how do you see the current market changing, and how do you compare this to a few years ago? ChrisH The problem at the moment is that you don't have the new users so for many products it is a hard slog. When new machines appear this should change. JustinD Market? What Market - no seriously the Amiga Market has been doing some funny things over the last year. As for the next few years that remains to be seen after EScoms conf. on the 30th. JustinD If the outlook at that conference is rosy, I would expect markets to become more active (for a while at least) as some buyer confidence returns.. In the long term - we can only wait and see.. (oh for a crystal ball that worked!) Kai My english is not very well, so I will only ask two questions: 1. Will there be a Version of PC-Task, that emulates a better Processor than the '286? 2. Will there be a version, that makes really use of GFX-Carts Chunky-Mode? GA, Sirs! jcompton (A question about support of higher processors than the 286 is good for the three-pack. Congratulations, Kai!) ChrisH I am working on PC-Task, processor, processor speed and graphics speed being the priorities. I however make no guarantees about release, as I might be run over by a truck tommorow. PeterF Or a bus! JustinD and we'd know who'd be driving :-) ChrisH But any new major release of PC-Task would have to have higher processor support. ChrisH As well as better gfx board support. jcompton Justin or Peter, is Chris under any contractual obligations not to get run over by a truck? JustinD no. We'll just have to hope in that eventuality Fang gets aquainted with the source quickly enough... ChrisH jcompton: You know what these publishers are like, I can't sneeze..:) PeterF Did you want milk in your coffe Chris? PlayGroun I have been told that PC-Task can use a2286 and a2386 hardware ie a video card or a disk drive ? isn't that just for boards like the golden gate? ChrisH Only the goldengate bridge type card is currently supported. I don't see other bridgeboard emulators being supported (or a need for it). People often ask can you use the slots without a bridge card, the answer to that is definate no. JustinD As for cards running with PC-Task - video cards most likely won't but we have users using everything from games ports to sewing machine controllers... jalovick_ I havent played with PC-Task for a very long time .. so I dont really know what your currently upto. My questions are .. Does it support Gfx boards (not just the AGA VGA emmulation, like the last time I looked), and will it run stuff that runs in protected mode ? I was hoping for the 3 pack ... :) .. BTW, good work ChrisH PC-task currently supports anything in the display mode database (ie is RTG). Faster more specific stuff will probably appear in next version. JustinD PC-Task currently supports any (as much as we can test it) graphics card that allows you to select from the ScreeMode database. This includes EGS, Picasso, Cybergraphics .... ChrisH Yes it does run protected mode. Windows 3.1 requires protected mode. HeadQuake If we will see a RISC based Amiga in the future, any plans on rewriting this fab 286 emulator for Risc Amiga (or just make it work under Risc 680x0 emulation)? How do u look at RISC Amiga and the PC-task future ? Tried Pctask on 060 yet ? Ok, Thanx.. :) ChrisH Yes porting to RISC wouldn't be any major hassle and would of course increae speed a fair bit. JustinD We haven't got our hands on an '060 yet (donations welcome :-) but have had reports of benchmarks getting 15x the speed of an XT. No Stopwatch tests yet though, and thats what would really give an indication of speed. ChrisH I think the PPC (or similar) is the way to go for the Amiga range and with a bundled PC-Task 486 Escom could do it very well. The real question is how long would a port of the AMigaOS take. ChrisH I only have a 040/25 (stock A4000) so I can only envy these 060 people! ga Gary Hi. Will you make a Pentium-on-a-card for the Amiga? It needs all the speed it can get. Window should be useful? ChrisH I am not a hardware type person. I could write the drivers I suppose! jcompton As an aside, there are no active bridgeboard companies for the Amiga at present. Vortex dropped manufacture and, well, we know what happened to Commodore. PeterF Not yet! Seriously though, at the moment we are concentrating on software. Hezu When shall we see new DirWork version which uses real cycle gadgets (no stupid WB1.3 support anymore), windows instead of separate screens in config, fixes the few bugs and so on? :) PeterF Bugs??? PeterF Chris is always eager to improve his products... ChrisH I honestly don't know when a new DW will appear. But when one does it will use real cycle gadgets I assure you. PeterF There are still HEAPS of pelple using WB1.3. ChrisH And more than two filelists etc. But I have done minimal work on it so far :(. Tau (I can't see 1.3 users buying application software, though) Rich Does the current PCTask 3.1 (Turbo/Standard) use dynamic compilation of 80x86 code to 680x0? And if so, how is raw CPU performance? ChrisH No the current _release_ version does not do dynamic compilation. THe turbo version does what I call static compilation :-) ChrisH Dynamic is the next step and it does give much better speed results than the nomal (interpretive) approach. ga Tau (another name for this is cpu transcription, I believe) Camaro what is the minimum memory requirements for turbo and non-turbo versions? ChrisH The turbo version requires a machiche with at leat 4Meg plus free so you have to have a machine with 5 or more meg (continuos memory ie not broken up on different boards etc). JustinD Of course, the more memory the better because if things start using Chip RAM things start to slow down... ChrisH The normal version requires a min of 512K but you need 1Meg or above to get 640K pc mem for emulation. ga Tau how much of the 4M in turbo mode is left to the PC? JustinD tau: 1MB is usable under DOS. The Turbo version uses 4x the memory you allocate to the emulation whizzkid 1> Will a future verion of PC-task be able to handle writes to the TCC: device from amiga-dos while running PC-task? 2> Will dirwork be enhanced to be a 'workbench replacement' like Directory Opus 5 ?? ChrisH It is possibility, The AMiga pc filesystem (CrossDOS etc) would have to be notified if MSDOS has writes pending or done but you still have the situation with a MSDOS cache holding info that is still to be written. So in my opinion it would require some heavy MSDOS coding. JustinD Why do people want to replace workbench ? I Like workbench... I feel that a program like DW complements WB. As to the future... Chris ? ChrisH I don't instend to make DW a WB replacement. Just a complement. kscully I have a 2 part question. (1) Will you do any other emulators in the future, possibly MacTask or something? (2) Why the large price jump between PCTask 2.x and 3.x? (About $100 US) ChrisH I don't intend on writing a emulator of another machine. MacTask was the biggest possibility but since ShapeShifter has appeared that chnce hs seriously decreased. ChrisH You can buy PC-Task direct from the publisher at Australian RRP $129. V2 used to cost $60AUD here. I don't see any $100 increase. JustinD The price increase was due to PC-Task 2 being available as Crippleware. A published version had to compete with this. Also, support costs money, and we don't charge users any extra for it, but we do like to cover our costs. ChrisH It ws easy for DevWare to sell it cheap since they still hven't paid me what they admit they owe. ChrisH I must point out SoftPC costs a fortune. ChrisH And Amiga users that buy software are few and fr between JustinD Also, in the US, the version published by DevWare at some stages did not contain a printed manual (disk based docs only). jcompton Let me jump in here. Mostly for Justin and Peter, I suppose-have you given any thought to talking with Mr. Bauer of Shapeshifter fame? It seems you could offer an Emplant alternative at, what, 1/3 of the price? jcompton (Emplant meaning combining PC-T 3.1 and SS against Emplant Mac and PC) PeterF Could be a possibility... But remember, we don't want to be caught up into LARGE, HUGE and COSTLY legal wrangles, with LARGE MULTINATIONAL corporations :-) ChrisH PeterF: And don't forget the patents :-) PeterF Oh yes.. I forgot about those JustinD ChrisH: and those incredibly long .sigs :-) PeterF And no 80 columns :-) jcompton So, is that a "we're not going to tell you"? PeterF It's with our lawyers :-) PeterF Though seriously, everything is a possibility. SS works very well and it is great for those A1200 users! Frotz I'd really like for you folks to do an ad that directly compares your emulator with emplant's promises/delivery... JustinD We do not comparitive advertising. We do not consider it a fair form of advertising (especially in many of the forms its used in) BluThundr My question goes back to the last version of PCtask that I seen. I was going to purchase it, however, I am not wanting to use a hardfile, I would rather just buy another 200 meg hd, but I have never been able on older versions to make the math of the partition work. Does version 3 support hard partitions better than previous versions? JustinD Version 3 has better documenting of partitions. I use it with Real MS-DOS SyQuest cartridges as HD's (easy for different setups). ChrisH Yes. All you have to do currently is go to HDToolbox nd change the DOSType to use a real partition. jcompton I can answer that from experience. Yes, absolutely. MrGandalf I'de first like to thank you for still supporting the Amiga in development, we truely need more people willing to go out on a limb and believe the Amiga isn't dead. MrGandalf Question: What type of hardware does PCTask support with a GG2+? Does it support it as it would a normal PC bus? ChrisH Well it doesn't support memory mapping things currently like VGA cards etc. It does support port type things like serial cards etc. The AMiga is still my choice machine that is a pleasure to work with. thanks. JohnUnix Thank you. I think that cross platform (read PC) compatibility will be important. Do you intend to approach Escom to have PC-Task bundled with the new machines? Thank you for supporting the Amiga through these bad times :-) PeterF It would be great if all new machines were bundled with PC-Task. PeterF The Amiga would be a much more sellable machine. Definitely help it. jcompton It wouldn't be bad if they were bundled with Degrader, either. :) Tau (having to bundle degrader would be bad PR, IMO) jcompton We'd have Chris rename it "Enhancer". :) ChrisH Call it Boot Menu I say :) Tau (I'd be happy enough if they were bundled with AmigaOS :/) MrGandalf It would surely help the Amiga market. JustinD Yep. A Bundled machine with PC-Task, Degrader, ShapeShifter and a licensed MS-DOS and MacOS ChrisH I would love escom to bundle. And thanks to users who support (buy) the products. JustinD True. If users didn't buy the products we couldn't keep support the Amiga. MisterX Hi all. My question is one of speed. Just what config would u need to get some decent speed out of a software emu with your progs, not having used on of them. Also, if the speed is no so good, why emulate windows + vga? PeterF To get the most out of PC-Task, you would use a hard disk partition, CGA graphics, and a fast machine! ChrisH Depends what you call decent I suppose. I Wouldn't wnt to run windows without 40Mhz 030 or higher. I have run windows on A600 :-) JustinD In my experience with support, the average user of PC-Task who is running Windows is just bringing home some work from the office. jcompton The EGA is quite nice, now that the infamous Wasteland Bug has been fixed. :) Tau chris, how long did it take to boot Win on A600? ;) JustinD it was 25 mins :-) ChrisH Tau: 25Minutes I think it was JustinD then again there are some people who use PC-Task for playing games (like Jason here) jcompton JustinD: And Lotus. ChrisH Don't ever expect software emulation of 8086 on 68000 to get faster than 1/3 speed. That is being very optimistic. Arc Q: A two-parter. :) What feelings do you guys have towards Escom? And will any new packages besides new versions of Degrader, DirWork and PC-Task be added to the lineup soon? (If so, can you tell us about it?) JustinD Escom - we'll know more after the 30th I suppose but with appointment of Peter Kittel I think things could be positive. They seem to have far more money than any of the other parties people though would be good for the Amiga ChrisH Well I don't know Escom. So far so good, they hven't make ridiculous claims and they do seem to intend to get machine production going and AMigaOS developement continuing. ChrisH As for other software, I have too much on my hands now, Justin/Peter are a different matter.. JustinD In fact I'd even heard on the grapevine that ESCOM are planning to do something with OS3.1 (like doing it themselves) so I think they at least have a good financial head on their corporate shoulders.... PeterF Quasar is always on the lookout to publish new products. But its now use mentioning them until they are ready. Otherwise, it's just vapourware. dracon I know this is going to sound weird but..will PCtask ever have a winsock.dll that will interface with amitcp or the like to run network connections? Thanks.. ( If this is already able to be done..sorry I'm not a huge PC-task user ;) JustinD Network support hasn't been an often requested feature from current users, although I see it would have its uses.. ChrisH Well not in the near future. I would like to do a lot with PC-task. But I am the only porgrammer and have to devote my time wisely. That isn't high on priority list (it is way low). PeterF We are working on genetic engineering to increase productivity RobB Greetings! Is PC-Task 68030 , 040 optimized, or are there any plans for such? Thanks! ChrisH 68020 and 68030 are _very_ similar. I haven't really found enough situations where the 68040 optimizations slow the 68020/30 so it hasn't become a issue. ChrisH Let me assure you that if I got a decent speed difference doing seperate versions I would and will if I do in the future(060 to chris please). Intrd ok well id like first to say big thanks to all at Quasar to still believe in amigas!!! 8-) And id like to know your positions about the future of the amiga devlopment of your products and what yah think of ESCOM! i am also a Software devloper and we are looking the thing positively but it will be nice to see we are not alone 8-) ChrisH In case it wasn't made clear before I am not part of Quasar, they are my publisher. I am a freelance programmer. PeterF I think a lot of developers have left the Amiga over the last year. But we can hope that they will come back once Amigas are produced again. I'm optimistic JustinD The future of Amiga Development of our products - well as long as there is a viable Amiga market here, we'll continue to support the Amiga. As for ESCOM, well as long as they support developers better than Commodore did, the future could be positive...we just have to wait and see... ChrisH Escom can only improve things. If they get 060 based A4000's out that will allow high end user to keep with Amiga. As well as A1200 etc for the majority of users. ChrisH So I am hopeful that escom will move things forward enough to keep the Amiga alive. JustinD I don't think developers would care if they had to pay up to $1000.00 for a support program , if it worked! MrGandalf Question: Does the current version of PCTask support real copressor (FPU) emulation? If not, will a future version? ChrisH No FPU has been done so far, just takes time. Not many applications that I would recommend for emulation use FPU. It is on the higher todo list. cyberfm Did anybody at Quasar try PC-Task in conjunction with text modes & cybergraphics displays yet ? I only get inverse text here. No idea why this happens (The 3.1 manual says that pc-task 3.1 is running without problems with cybergraphics) JustinD Yes we did try that and we get the same problems with text modes. However Mode13 is considerably faster with Cybergraphics (ie. fades in Wolf 3d occure in real-time) ChrisH We recommend running the text modes in native mode currently for best speed. But I think that color problem with cybergraphics in text modes with be a cybergraphics problem but we will work it out either way. PeterF Same thing happens with EGS. The EGS libraries do not support everything the OS does. Arc Q: 1) Have any of you heard any other whispers on the Grapevine you can tell us? Please? :) 2) Also, have you considered a joint hardware/software solution for PC-Task down the line? Like a small Zorro-II card with the chip(s) on it to do x86>>0x0 conversion at the silicon level? Arc 3) ... If you could send a message directly to Escom.. What would it be? JustinD Whispers on the grapevine.. None that I can tell yet:-) ChrisH 1) I heard Justins girlfriend is the devil. :) JustinD ChrisH: She can be ;-) JustinD As for what I'd tell ESCOM. I've already (in e-mail with Peter Kittel) told them what I consider to be one of the most impoartnt things they can do - support developers as they are supported on other platforms PeterF Chris, don't tell them about the quad 060 board JustinD or "The Corner" Gfx card ChrisH PeterF: I told you to keep your mouth shut about the double-quad edge-060 ChrisH 2) You might as well use a real 80x86 if you are going to go hardware. ChrisH 3) Escom bundle PC-Task (cost them next to nothing anyway) get machines out, get AMigaOS developement RTG etc going, work on 060 card. Get a kick ass PPC machine running AAmigaOS going.ga kscully I was wondering if there will be another version of Degrader, and if so, what improvements might it have? I really like Degrader, and the only thing it doesn't do is boot me into 1.3. :) Tau (isn't it kind of time to get rid of the stuff that has to be degraded already?) PeterF Tau: Yes MrGandalf I would hope so... ChrisH I don't know if I will get the free time. I would like to add MMU and kick 1.3 support for better compatibility but time just seems to disappear. Frotz OK, what I'm wondering is if your product will run Netscape, and if it's possible to enhance a future version specifically for things like netscape... since the amiga is lacking in this particular area. PeterF Run Netscape under ShapeShifter. Would be faster... Sorry Chris ChrisH Currently I wouldn't recommend that sort of sstuff. Maybe next version. N`Kognito as talking about disappearing time earlier: have I understood right that you're currently mostly concentrating into PC-Task and leaving DW and Degrader kind of secondary products? ChrisH Yes that is a fair statement. PC-Task pays the bills, and they need paying :-) JustinD Definitely agree with Chris there :-) PeterF There is only one Chris. Thank God. Arc Q: Whats Quasar's policy in reards to hiring shareware authors? Do you actively seek out good authors in the Amiga community, or do you wait for them to come to you? You have to admit, there is a huge array of extremely well-written software for the Amiga out there. Also....... Arc And lastly, are those damn Mentos "The Fresh-Maker!" commercials from Australia or Canada? :) I had a debate over dinner about this last week. :) jcompton Arc: I think they're German, actually. PeterF At the moment we don't hire programmers. Royalties are paid. But we are willing to publish any good software :-) ChrisH We have crap commercials about them! Tau on that note, how should an author contact you? ;) JustinD I don't think they're from Australia as they seem to be dubbed pretty badly. Probably from Canada - which side of the road are the cars on - we drive on the left here... JustinD ChrisH: about the programmers ? ChrisH Royalties are paid, gee that is strange for a publisher. :-) PeterF A software author just has to phone/fax/e-mail... That's all JustinD Quasar can be comntacted at dweaver@quasar.dialix.oz.au or by phone/fax PeterF We don't pay Chris, because he does it for the love of it ChrisH PeterF: It seems so. JustinD ChrisH: Who do you think we are? DevWare? ChrisH If you were DevWare I would be in court with you. PeterF But for other authors we have no problems PeterF Courting us Chris.. How nice! Lighty Hi Chris! Just wanted to ask what your favorite directory utility is? PeterF JPDir ?? ChrisH DW is such a cool product I just pirted it. :-) JustinD Actually I'd agree with Chris Here. DW is the only choice :-) ChrisH Ask Justin. DW all the way. If you want things done fast and simple. Get DirWork the mans dirutil. jcompton Ok, I think that concludes the remotely serious part of this conference. Thank you, Chris, Justin, and Peter for coming so early in the morning, and thanks to everyone else for showing up. ChrisH Thanks to the people who buy software! MrGandalf Many thanks to those that still support a great machine. PeterF Yes, definitely thanks to all who have supported and stuck with the Amiga. @endnode @NODE TSreview "TypeSmith 2.5a - reviewed" @toc REVIEW =========================================================================== REVIEW: TYPESMITH 2.5a Maxwell Daymon mdaymon@rmii.com =========================================================================== [Readers who do not have WB3.X AmigaGuide could see unusual formatting characters which may not translate well for earlier versions of AmigaGuide. - Jason] @{jcenter}TypeSmith 2.5a @{jcenter}@{"Soft-Logik Publishing" LINK SoftLogik} @{jleft} Whether you do desktop publishing, electronic pre-press, video, or any other application that benefits from the use of type, there may come a time when you need to create, convert, or manipulate fonts. TypeSmith may be the answer to your needs. It is designed specifically to handle various outline font formats, but it also manipulates (to a lesser degree) bitmap fonts and it works as a font format conversion utility. @{jcenter}Installation @{jleft} TypeSmith comes on a single 3½" double density diskette. The files are compressed and installation is handled by Commodore's Installer utility. The installation allows full control over where TypeSmith will live and what extras are installed. The last step in the installation process displays the "readme.first" file, but assumes that the installation disk is in drive DF0:. If you install from a different drive, the computer will ask for a disk in drive DF0: or, if a disk is already in the drive, attempt to get the file "readme.first" from it. The error is non-critical, but it really shouldn't have made it through testing. I do not understand why TypeSmith wants a logical assignment (TypeSmith:) to be put in the User-Startup. This assignment is not needed when @{"PROGDIR:" LINK progdir} is available on OS 2.0+ and TypeSmith is an OS 2.0+ program. TypeSmith should use PROGDIR: unless the user wants to use TypeSmith: for some reason. If your list of assignments is starting to look like a zoo, you'll have another animal to look after. @{jcenter}As a program @{jleft} The TypeSmith executable weighs in at just under half a megabyte. To use the software, you need at least 512K of chip RAM and 1.5MB of fast RAM, but I recommend more of both. TypeSmith is essentially a structured drawing program which can handle as many as 255 drawings at once in each project you have open. In all its glory, TypeSmith tends to use a good deal of chip RAM. Unless you have a 2MB Agnus or run TypeSmith in a fractional zoom mode, you will probably encounter low chip memory conditions while multi-tasking with other chip memory intensive programs. Chip RAM usage is minimized, but not eliminated, when running TypeSmith with a graphics card. If you have a graphics card and/or 2 megabytes of chip RAM, you're not likely to notice. Using TypeSmith on a machine with 512K of Chip RAM and no graphics card is a tight fit, but it is certainly possible. In a multi-tasking system, straight memory requirements don't mean much so I made a sample @{"table" LINK TSmemtable} of memory consumption for various tasks. TypeSmith has a beautiful, font-sensitive interface. It's obvious that the programmers closely followed the Amiga User Interface Style Guidelines. Most of its windows are resizable. The program automatically adapts to the aspect ratio of the selected screenmode, so opening TypeSmith on an oddly-sized screen (like 1280x400) won't make the letterforms appear squished, stretched, or otherwise distorted. The OS standard ASL file requester is sized according to the current screen and font, so you rarely need to worry about moving or adjusting it. The program interface is stunning on a high resolution 1280x1024 screen with a 24 pixel high proportional font (like Times) as the interface font. Fonts are loaded based on a user-editable pattern which can be set independently for each file type. Ineligible files (those that don't match the current pattern) are hidden for convenience. For instance, importing a Compugraphic Intellifont will use the pattern (#?.type|#?.lib) so you won't have to wade through unrelated files to get what you are looking for even if you keep all your font files in the same directory. The Amiga clipboard is also supported so you can easily share TypeSmith data with another OS clipboard compliant structured drawing tool or a program like Soft-Logik's PageStream 3. Professional Page and Professional Draw (Gold Disk) users will be exposed to a remarkable concept: a floating toolbox! You can put the toolbox wherever you think appropriate, and you can have it come up on the right or left side by default. Another useful feature is a fuel gauge for operations which have the potential to take a long time. The graphic and percentage-based display reports how much of a given task the program has accomplished and takes away the uncertainty of whether the program has locked up or is just doing a lot of thinking. Enough cannot be said for keeping the user apprised of program activity. There is also a status bar, at the bottom (or top) of the screen, which displays coordinates, scale, and status. If you have AmigaOS 3.x, the status bar will display a description of whatever your pointer happens to be positioned over at any given time. It even explains the drag bar and close gadget. Under OS 2.x, this status bar will only report actual TypeSmith operations, such as the particular guide line you are dragging around, but only a select few functions are reported under this operating system. Users with AmigaOS 3.x are treated to a context-sensitive on-line help facility. OS 2.x users still get on-line help, but without the context sensitivity. TypeSmith also allows you to open multiple copies of the program, but warns you if the program is already running. Other programmers would be wise to look at TypeSmith when designing the graphic user interface to a program. This is certainly how a program should be done! @{jcenter}As a font designer @{jleft} TypeSmith comes equipped with a powerful set of drawing tools including an ARexx interface which allows drawing control through ARexx commands. Real-time manipulation of the letterforms is acceptable on an ECS machine with a 25MHz 68030, and exceptional on an ECS machine with a 33MHz 68040. Like a full scale drawing program, there are a number of ways to constrain the drawing and manipulation functions. If you hold down [SHIFT], ellipsis and rectangles will be constrained to circles and squares. Holding down the [ALT] key while adjusting a @{"bézier" LINK bezier} curve power/angle point will cause the opposite power/angle point to be mirrored. Holding down [SHIFT] after you select a point and before you drag will constrain movement vertically or horizontally, whichever direction the mouse moves first. One surprising catch is that the initial line segment must be just that: a line. If you want a completely curved shape, you have to add a second point on top of the initial point to create the curve. This makes a "non-existent" line, but still satisfies the requirement. The ellipse tool does it automatically. This requirement can make some functions appear unstable or erratic, but if you realize that the initial "point" with a curve from each end is actually two points, the behavior makes sense. No structured drawing editor would be complete without the ability to use bitmap templates of some sort. TypeSmith will import Amiga, Soft-Logik, and Adobe ABF bitmap fonts, and IFF ILBM images as templates and it will export the above mentioned bitmap font formats. Bitmap fonts can be used as templates for designing outline fonts. To do this, you must create a new outline project and load a bitmap font. Although it is possible, it is not recommended by Soft-Logik or myself, to @{"Autotrace" LINK autotrace} a bitmap font to get a start on the outline version. The results are poor (if not completely unusable) with most bitmap fonts. There simply isn't enough information for the trace algorithm to create a usable outline version. Once the bitmap font has loaded, TypeSmith will display a gray "shadow" of the font in the workspace. You can use this form to draw a rough sketch of the letter and then turn off the template display to finish the outline font in detail, or you can leave it up as a guide throughout the operation. A 60 pixel high Amiga bitmap font is the smallest I tried that would yield even a usable trace result, but even then it's only a modest start. The intended purpose of the Autotrace feature is to create outline versions of IFF ILBM bitmaps. For example, you might scan a high resolution image of a particular letter and Autotrace will create a fairly faithful outline version of the graphic. This is very memory intensive. If you are low on memory, only one letterform should be imported at a time, then cleared before going on to the next letter. A great deal of resources would be required to hold a 150-600 DPI scan for each letter in the whole character set. You can use TypeSmith to create bitmap fonts from outline fonts. One reason for doing this is to make attractive screen fonts for programs in which text speed is important. Another reason to use this is to get type into a program that does not directly support outline font formats. Some desktop publishing software (such as Professional Page) allows you to use bitmap screen fonts to speed up font display considerably, at the cost of display quality. TypeSmith is not a replacement for a dedicated bitmap font editor. It does not allow control of all the functions possible with Amiga bitmap fonts. TypeSmith is a powerful tool which can generate and refine a bitmap font, but precise control of the Amiga bitmap font data such as kerning and spacing information still requires a font editor that directly addresses such needs. @{jcenter}Making international font design easier: Character Compositions @{jleft} TypeSmith supports a feature called Character Compositions which makes creating and maintaining international character sets simple. With Character Compositions you can define the base letters and accent marks, and give TypeSmith instructions on how to combine these for the various accented characters. Any change to one of the components will change ALL of the compositions. For instance, if you change the lower case 'a' in the main character set, all the accented character composed versions reflect that change. There are a couple caveats when dealing with character compositions: Fonts designed without the feature must be reconstructed, and character compositions are lost if saved in a format that doesn't support the feature. TypeSmith can also import IFF DR2D drawings. You can design the letterforms in your favorite IFF DR2D-supporting drawing program and simply use TypeSmith to import and put together the drawings as a font. You cannot, however, import extremely complex DR2D files - TypeSmith will inform you that there are too many paths. Remember, you are dealing with a single letterform, not complicated line art. @{jcenter}As a font format conversion utility @{jleft} TypeSmith works as an effective font conversion utility, but not without some difficulty. The process is by no means seamless. TypeSmith will import Compugraphic Intellifont, TrueType, IFF RFF, PostScript Type 1, PostScript Type 1 Hybrid, PostScript Type 3, Adobe metric and PostScript metric, IFF ILBM templates and Amiga bitmap, Soft-Logik bitmap, and Adobe ABF bitmap fonts formats. It will export Compugraphic Intellifont, TrueType, IFF RFF, PFB PostScript Type 1, AFM font metric, PostScript Type 3, and IFF DR2D. It will also export IFF ILBM, Amiga bitmap, Soft-Logik bitmap, and Adobe ABF bitmap fonts. First, not all font formats use the same curve definitions. Compugraphic Intellifonts and TrueType fonts do not use the bézier curves of TypeSmith and the PostScript Type 1 font formats. Alien curves must be converted to a format TypeSmith understands. In the process, information is lost. When loading and saving Compugraphic Intellifonts or TrueType fonts, you are likely to lose quality and/or gain unwanted complexity. Loading a Compugraphic Intellifont and resaving it yielded a font that was much dirtier, especially at lower resolutions (12 to 48 pixels) when used in programs. Loading and saving a Compugraphic Intellifont or TrueType font in its native format is devastating because of the conversion difficulties. If TypeSmith could handle B-splines and any other curve definitions, this wouldn't be a problem unless you specifically wanted to convert the font to another format. As it is, editing and resaving fonts that do not conform to the bézier font definition results in loss of quality. If you are planning to use TypeSmith to convert a disk of TrueType fonts to PostScript, my first suggestion would be to look for PostScript versions of those fonts. However, converting PostScript or Soft-Logik fonts to another formats works fairly well for non-professional use (e.g. a small newsletter). If you are a professional, avoid anything except PostScript, Soft-Logik, and RFF font formats. Another problem that stems from conversion is the loss of specialized information like character compositions and kerning information. TypeSmith will not load or save the kerning information of Compugraphic Intellifonts (called kerning segments) or character compositions, so external means of such information must be maintained. Character Compositions are fused together as a complete character when you output to a format that does not support such compositions. You should always keep a copy of fonts in the highest feature format possible (Soft-Logik recommends IFF RFF). The Amiga Compugraphic Intellifont engine (OS 2.1 - 3.1) doesn't seem to like anonymous fonts. I could not get the Amiga to use an exported Compugraphic Intellifont without giving it some sort of ID, but without having an assigned number it could conflict with other fonts. Importing and re-exporting CS Times (PageStream 3) yielded a font that had poor-quality and a size of almost a quarter megabyte. TypeSmith's ARexx interface allows complete automation of the program as well as allowing other programs to use TypeSmith transparently with automated macros. TypeSmith comes with a marco to batch convert whole font directories while you work on other projects or sleep. Another included macro that I found very useful was an ARexx shell that allows you to enter ARexx commands directly into a Shell interface to watch the results on the screen. If you can't draw but you are mathematically and spatially aware, you can design fonts with commands in a fashion similar to the language LOGO. The manual is beyond excellent. It is full of all kinds of information about font design, history, where to officially register your fonts, and of course usage of the program. The 144 page manual (created with PageStream 2.2) coupled with the complete on-line help system, both indexed and recommended reading are a surprising and refreshing change from what I'm used to seeing, even from high-end Macintosh and PC products. If all manuals and on-line help systems were this good, there wouldn't be a #? for Dummies series of books. @{jcenter}Utilities @{jleft} TypeSmith is billed as being able to convert Gold Disk's Professional Draw clips into IFF DR2D drawings. After loading the Convert utility and selecting a source file and destination directory it reported that the file was not a ProDraw clip file. I attempted to simply point it at the directory with the clips, but it found none. Running the Convert program from the shell gave the same results, but would not release the shell window even after exiting. Quitting from the Workbench interface resulted in a 0100000F recoverable alert under OS 3.1. OS 2.1 sometimes added the fatal failures 8700000E followed by 80000008 bringing the whole machine down. To insure that I was throwing real ProDraw clips at it, I tried using PageStream3. PageStream3 successfully recognized and converted every single ProDraw clip file I tried to run through Convert. Most of the resulting IFF DR2D files imported into TypeSmith without a problem. The rest had to be simplified or parts had to be deleted to function properly. Font Downloader worked fine. I sent fonts to my printer and they were used when I sent a file that called upon them. @{jcenter}Some gripes @{jleft} · I turned off the "White Background" to speed up the display as recommended in the manual. Eventually, many specs of pixel garbage appeared in the type window. Resizing, covering, and moving the window did nothing. Scaling the font (to redraw the contents) only caused the letterform to draw UNDER the pixel garbage. · As another speed up, I tried to force the program into the Picasso's "chunky" mode. The colors went completely wrong and the window redrew every time I clicked the mouse in the window. I cannot place any blame without more information, but it wasn't convenient whichever program is at fault. · Status bar is not notified of objects in inactive windows. Can make context-sensitive help appear to be "broken". Simply insure that the window containing the function you want help with is active. · Starting a new outline followed by new bitmap causes problem. The bitmap is not editable. You MUST import the bitmap or create it from an existing outline. I would like to see more bitmap font control in TypeSmith. @{jcenter}Conclusions @{jleft} TypeSmith is not the perfect solution for everyone, but (with the exception of "Convert") is a beautiful, stable, functional program. True professionals should consider the Compugraphic Intellifont and TrueType import functions as "good starting points" for designing a bézier curve version of the font. The results from just importing and using the point reduction feature aren't good enough for truly professional use. Professionals tend to hang around the PostScript font format anyhow. While found in professional environments, TrueType is not the font format of choice in the field. TypeSmith is a boon to Professional Page and Professional Draw users. It makes fonts that otherwise cause Gold Disk's Font Manager to choke into usable files. Of all the fonts that caused Font Manager to crash or resulted in incorrect or scrambled conversions, loading and resaving them with TypeSmith resulted in a completely usable file. Font Manager will keep the PostScript version available for high end output on PostScript devices, so there is no concern about the slight loss in quality from converting a Type 1 to a Compugraphic Intellifont format. It will also directly convert the fonts for you, but does not copy a downloadable PostScript version to the Gold Disk fonts directory (easily solved with an ARexx macro, however). I was able to convert nearly all of the fonts I tried from my collection of thousands. A few were too complicated (each letter was an entire drawing of a scene!) but for the most part everything imported without difficulty. I could not test all the fonts or I would not have finished this review before 1998, but the fonts I did try had good to excellent results! If you work with fonts, TypeSmith is an essential utility and is one of few high quality products that actually deserves to be called professional. @ENDNODE @NODE TSmemtable @TITLE "Memory consumption based on task" TypeSmith Memory Usage ------------------------------ State of program CHIP: USED FAST: USED (bytes) ------------------------------ MaxFactor=1 (100% Zoom) ------------------------------ TypeSmith loaded. No projects CHIP: 516,992 FAST: 761,608 ------------------------------ Loaded with one project in memory CHIP: 569,856 FAST: 835,136 ------------------------------ Loaded with two projects in memory CHIP: 625,056 FAST: 908,648 ------------------------------ CS Times.type (from PageStream 3) loaded as an outline font CHIP: 569,856 FAST: 1,031,736 ------------------------------ CG Times (AmigaOS) loaded as a 60pt bitmap font CHIP: 703,792 FAST: 846,088 ------------------------------ CG Times (AmigaOS) loaded as a 60pt bitmap font and autotraced CHIP: 703,792 FAST: 848,912 ------------------------------ MaxFactor=2 (50% Zoom possible) ------------------------------ TypeSmith loaded. No projects CHIP: 195,968 FAST: 756,048 ------------------------------ Loaded with one project in memory CHIP: 248,832 FAST: 829,592 ------------------------------ @ENDNODE @NODE progdir @TITLE "OS 2.0+ and the dynamic PROGDIR: assignment" PROGDIR Before OS 2.0, a problem reared its ugly head. Many programs needed a logical assignment to find related data and code files. The problem with this is that assignment lists got so long and unreadable that they started losing their usefullness as a tool. Getting rid of software required a few hoops (you cannot delete an assigned directory) and relocating programs was an affair that required trips to the Startup-Sequence and tracking down other scripts and configuration files with assignment names. The answer to this was to create a dynamic assignment called "PROGDIR:" that is relative to the program calling it. Any program can now call "PROGDIR:" and find the directory it was launched from. Related files can be stored in a predefined tree that no longer was "fixed" on the drive. At this point, it became possible to simply drag a drawer from anywhere to anywhere and no MS-DOS like config and startup file editing was required. Getting programmers to @{i}use@{ui} this feature is the new problem. The next time you are in a program and you have the file requester open, type in "PROGDIR:" as the path and see what happens. If all goes well, you'll be looking at the directory you ran the program from. @ENDNODE @NODE autotrace @TITLE "So what is autotracing anyway?" Autotrace In order to create an outline version of a bitmap font or image, a program must use a special algorithm to try to determine what the original intent of the bitmap was. If you look at the letter 'o' in the topaz font, you will know based on past experience that the corners are meant to be curved. The computer cannot make such a determination without assistance in the form of a tracing engine. The problem is that without @{i}many pixels@{ui}, the computer cannot extrapolate the original meaning of the graphic. If you only have a few pixels to define a corner of an image, the computer cannot determine whether the corner is meant to be a curve, angled edge, or simply a hard corner that wasn't well defined (or anti-aliased). Autotracing tends to work best when you are dealing with a large high-resolution scan. @ENDNODE @NODE bezier @TITLE "Bézier curve definition" Bézier curves The bézier (bays-yay) curve method is one of way to define a curve. Different curve definitions are used and created depending on the need of the system. Some curves are more accurate while others calculate faster with a given processor. The bézier curve system uses three points to define a curve (B-splines use four points to define a curve). The two exterior points control the power and angle of the curve in relation to the center point. @ENDNODE @NODE SoftLogik @TITLE "Soft-Logik contact, warranty, and technical support information" @{jcenter}Company Contact Information @{jleft} Soft-Logik Publishing 315 Consort Drive St. Louis, MO 63011 USA Sales: 1-800-829-8608 Intl Sales: 314-256-9595 Tech Support: 314-256-9333 Paid Support: 1-800-829-5816 Fax: 314-256-7773 BBS: 314-256-8971 @{jcenter}Warranty and technical support @{jleft} · Each Soft-Logik application comes with 90 days of free technical support from the date of your @{i}first call@{ui} · (Upgrades get 30 days free support from the first call after the upgrade is received) Minor revisions (letter upgrades) do not apply. · Free On-Line support on GEnie, CompuServe, Portal, BBS, and Internet · Free mail support · Fax support (faxes will be received and responses will be mailed out) · Paid Annual Support (access to the toll free number for US residents) · Pay per call Support ($25 per resolution, 15 minute maximum) You are only allowed access to the toll-free technical support number if you have paid for use. @ENDNODE @node REVIEW2 "Further Comments: fMSX Amiga 0.4" @toc REVIEW =========================================================================== FURTHER COMMENTS: fMSX AMIGA 0.4 A Letter to AR - Hans Guijt, of fMSX Amiga =========================================================================== [In response to the AR 3.10 review of fMSX Amiga 0.4, the porting-author, Hans Guijt, wrote a letter clarifying and expanding on some points, particularly on MSX machine specifics, where my information was admittedly lacking. -Jason] Hi Jason! [Bracketed quotes are from AR 3.10's review.] >Everyone has their own reasons for using emulators. Some need the >compatibility for business purposes. Some just like screwing around with >software that would otherwise take up desk space for a separate computer. >And then there are programs such as the Spectrum emulators and fMSX, that >make machines that didn't quite have worldwide markets widely usable. There is another reason as well - I believe that there are several games available for the MSX2 (not MSX1) that make a significant addition to the Amiga games market. I have a whole stack of Zelda-clones here (actually I would call Zelda a Xak- or Ys-clone ;-) ) as well as a series of shoot'em ups that really have no equivalent on the Amiga. These games are very different from the 16/32Kb cartridges you have seen so far: Dragonslayer 6 (Legend of Heroes) comes on 4 disks, as does Wanderers from Ys, Princess Maker comes on 8 floppies, etc. This means that both graphics and sound are spectacularly improved over the old MSX1 games. One problem: many of these games (especially the Zelda-clones) require knowledge of the Japanese language. Oh, and I still have to make them work as well... My HD is filled with games. 1500 Spectrum games, 150 MSX games, 40 PC games (the Infocom collection) and even a few Amiga games! >The MSX OS has a copyright date of 1983 (so you'd better hope MicroSoft >doesn't beat down your door for it), and while I don't have the machine's >specs handy, it seems to have pixel resolution similar to the Spectrum, but >with a greater availability of colors (16, I believe.) To run, the That's correct. There is a list of specs in the docs, in the section called 'about MSX'. The restriction for screen 2 (the screenmode used for most MSX1 games) is that 8 consecutive pixels can only have two colors. This differs from the Spectrum where a whole 8*8 block can only have two colors (just like some new AAA modes!). And of course there are sprites, which the Spectrum does not have. The MSX2 ROMs boot in screen 6. This is a 512*212 screen with 4 colors. In v0.4 this is the only supported MSX2 screenmode, with very minimal support as well. No sprites, no vertical scroll, etc. Normally the MSX logo would scroll smoothly upwards rather than drop down in three big steps... >software requires an 020+ and OS 3.0 or above, although the author is open >to consideration of support for 2.04 and above (but 68000 is out of the >question, for speed reasons) It will be easy enough to go through the code searching for v39 calls, and I have no way to test my work as I don't know a single person with v36 and 68020+. This is one of the primary reasons for the current situation, although I admit that memory pools helped a lot as well ;-) . The reason for the 68020+ requirement is that I need many of the special 68020+ instructions and addressing modes. Especially the bitfield instructions proved invaluable when doing MSX emulation (these are only available with 68020 and upwards). >So, why bother? Well, there are an awful lot of games available. >Certainly nothing of epic proportions, but sometimes it's nice to just kick >back and play a round of Konami Ping-Pong and take one's mind off of the >"AAA vs. 3DRISC" question. The system is multitasking, so you can leave >Ping-Pong running in case you're hit with a stress panic over AAA vs. >3DRISC after a grueling session on Usenet or IRC. This has happened to me >more than once. The big problem with support for the bigger games is the way memory is laid out inside the MSX. It works like this: The z80 can address only 64Kb of memory. This 64Kb is split into four pages of 16Kb. A page can be switched into any of four slots. Thus, standard memory looks like this: SLOT: | 0 1 2 3 --------------------------------------------------------- Address: | 0x0000-0x3FFF | BIOS reserved reserved RAM EXAMPLE 0x4000-0x7FFF | BASIC1 for for RAM SETUP 0x8000-0xBFFF | (empty) cartridges cartridges RAM 0xC000-0xFFFF | (empty) RAM Currently the emulation works with a 64Kb RAM buffer. This has several disadvantages: every time a page is switched a 16Kb block is copied to (and possibly from) the buffer; and every write must be monitored to make sure that ROM isn't accidentally overwritten. This is the reason why MSX2 basic takes such an incredibly long time to start: the MSX2 ROMs bankswitch over 9000 times during the boot sequence, and copying all that memory takes a long time. I am working on a new version of the CPU emulation that does away with the 64Kb buffer. This has the big disadvantage that every memory read or write must go through a translation sequence (causing slowdown) but there is no more need for ROM protection or block copying (causing speedup). Naturally I am hoping to get more speedup than slowdown! A big problem is that the new CPU emulation is *very* complicated. Currently I have not been able to get it up and running, despite the fact that I have been working on it for several weeks. My greatest success so far is actually getting it to compile! To complicate matters further I have included several optimizations (which would also have worked in the old code), most notably delayed calculation of the H flag, the bane of all Z80 emulations. So, this is a short timeline of what to expect in the future: Disk emulation requires MSX2 basic to be running (at least for my version of the disk ROMs). However, MSX2 basic really needs the new CPU emulation for speed. So, expect to see the new CPU first, better MSX2 support and diskbasic next. In the meantime I'll do interim releases like v0.5 just to keep things going and remove bugs. With the new CPU emulation it will be easy (and totally free in terms of performance) to add support for the so-called memory mapper. This device allows an extra measure of bankswitching to be added to the MSX, so that a maximum of 256 16Kb blocks can be controlled in one slot. Unfortunately this still does not mean that the MegaROMs from the web page can be played, as these require yet another kind of bankswitching: expanded slots. Fortunately almost every MegaROM out there has been revised to use the memory mapper instead of expanded slots (a more common term would be 'hacked' ;-) ), so this is only a minor problem. You will have noticed that by now I have support for two layers of bankswitching: slots and memory mapping. Why not add support for the third layer as well (expanded slots)? The answer lies in the hardware implementation of these techniques. Slots and the memory mapper are controlled through Z80 OUT instructions; these can easily be trapped by the emulation. However, expanded slots are controlled by writing to certain memory addresses, and checking *every single write* means a lot of overhead and a great deal of slowdown. Note that the UNIX version does this regardless of the effect. This is Marat's choice; he can count on 100MHz RISC monsters, while I am aiming for something like a1200+fastram if at all possible. In due time I will need to rewrite the disk ROMs, in order to interface directly to the Amiga, probably through mfm.device although I am open to suggestions (I am looking into fms.device as well so that people can keep MSX disk images on their HD's). Because I am currently sick of the CPU emulation, and because I think too much time has passed since the last release, I decided to stick some new stuff into the v0.4 code. I wanted to make a hardware hitting video emulation for some time now (it is possible to use the copper to control the blitter which automatically redraws the screen every frame, but I see no method of doing this inside the normal intuition screen context. Instead I build my own display with my own copperlist, and so far everything works fine even though it isn't quite finished.) I will release v0.5 once I have this running, and if I have time I may add some extra MSX2 screenmodes (these are quite easy if I leave out some features like sprites). Of course the use of the MSX2 screenmodes is limited when you have no games to run on them. Other new stuff in v0.5: - There was a bug in v0.4 that caused the emulation to run a lot slower than necessary. Fixed. - A simple change to the bankswitching code caused some speedup, especially notable when starting with MSX2 ROMs. - If one of the libraries could not be opened the general shut-down routines would still call functions from that library. Fixed. - No longer hangs when it cannot allocate soundchannels. >What sort of speed do you get? Well...the author of the Amiga version >claims that his 030/25 machine is just short of 100%. Based on my >experiences on an 040/25 machine, I'm not so sure-then again, I've never >seen a real MSX machine. I know that by playing with the included timing >settings (only two sliders that can be changed while running the emulator), >very nice speeds can be achieved on an 040/25. On the 030, well, I'd >rather use the 040, but it is tolerable to a point. And you are right, v0.4 is a lot slower than v0.3 (in which I did the timing). The reason is that I placed an important buffer in CHIP ram, in preparation for the new video-update scheme. I made sure that the user could not access the new 'features' (which leads to hard crashes unless you know *exactly* what you are doing) but I forgot to take out the MEMF_CHIP. >Promised for future support are MSX disks and the MSX2 specification, which >I presume includes MegaROMs. As stated, only hacked MegaROMs. >I've always admitted it-I'm someone that enjoys using emulators, so fMSX is >a goldmine for me. For others, who need a good reason to use them, I point >to the dozens (if not hundreds) of games readily available for diversion. >Some 8-bit classics are even available, including Loderunner, Raid on >Bungling Bay, Pastfinder, and Thexder. It's worth a look. My internet connection is a 14k4 line, and I pay for every hour I use it, but once I have something uploaded I can send it to lots of people for free. For this reason I have a list of users that will automatically get a new version once it is available. To get on (or off) the list all you need to do is send mail to h.guijt@inter.nl.net stating what you want. Also welcome: talk about MSX/fMSX, bug reports, verbal encouragement, suggestions, etc. @endnode @node REVIEW3 "Review: Meeting Pearls II CD-ROM" @toc REVIEW =========================================================================== REVIEW: MEETING PEARLS II CD-ROM By: @{" Jason Compton " link JASON} =========================================================================== Meeting Pearls II picks up where the first CD left off-as a wildly inexpensive source of an eclectic variety of freely redistributable software. Weighing in at roughly US$14, MP II brings hundreds (649, to be precise) of megs of useful software to the user, including full distributions of the Linux and NetBSD Unix operating systems. The span of the software is impressive-from DiskSalv2 to a demo of Real3D, there is a wide variety of useful utilities. Archive tools, demos, and benchmark software also fill the disc (although AIBB, one of the flagship benchmark packages, isn't included. Strange.) A decent assortment of pictures is included-some general, some taken from the "Beauty of Chaos" CD, and others of the partipants in the meetings that made this disc possible. Remember-the basic concept of the Meeting Pearls CD is that, basically, there's a big party and a big hard drive, and everyone fills it. That was the story for MP I. On this disc, things seem to be a more more "formalized", there are subdirectory "admins" who were responsible for collecting the files, and contributions were more widely solicited. But it's still got the spirit behind it. The idea is that the disc is sold at zero profit for the compilers (but the publisher and distributors get their slice), and that contributions can be made with the enclosed bank deposit/transfer slip. Some interesting collections grace the disc-for example, the collected works of Amiga Report, Blaze...uh, I mean, BLAZEMONGER, and the novel The Hacker Crackdown. (As an aside, I rather like the idea of novels being included on CD-ROMs. It lends computer users some legitimacy, I believe-and there really are books worth reading.) Part of the contents are in HTML format, accessible through the included AMosaic. This is a nice touch, although it is not really a total solution for accessing everything. (The logos and such are rather nice, however.) The rest of the CD can be comfortably browsed with the directory utility of your choice or with the FindPearls search utility. It relies on MUI, which may upset some people, but it does work. Noteworthy is the use of "Metatool", which basically ensures that the disc can be comfortably used without a lot of assigns and trouble. MP I was a bit touchy about how the system was configured for use. On this disc, the "clickme.first" file pretty much takes care of all the bases. I suppose if there is a glaring drawback it's that the CD is rather German. This is not a BAD thing, per se, and there is a lot of English, to be sure. But it has to be kept in mind that most of the work was done natively in German, and some things (largely docs in some programs that have been included, but there are pictures as well) just didn't get translated. Or, sometimes, a joke or comment will get lost. The features of primary importance, though, are in English. In the cluttered field of compilation CD-ROMs, Meeting Pearls II is a standout at an unbeatable price and a very nice collection. For some, it may be worth it simply for the easily-accessible Unix installations, since they aren't exactly a quick download. For others-well, you can never have too much software. Compiled and Copyright by Angela Schmidt Distributed by Stefan Ossowski's Schatztruhe ++49 0201 788778 voice ++49 0201 798447 fax stefano@tchest.e.eunet.de @endnode @node CHARTS1 "Aminet Charts - May 26, 1995" @toc FTP | The 10 most downloaded files from Aminet during the week until 26-May-95 | Updated weekly. Most popular file on top. | |File Dir Size Age Description |----------------- --- ---- --- ----------- ar310.lha docs/mags 81K 1+Amiga Report 3.10, May 17, 1995 AquaSim1_0.lha misc/sci 281K 0+3D Aquarium Simulator (Uses MUI2.0). VChck654.lha util/virus 123K 1+Version 6.54 of Virus_Checker. Amiga flick-1.5.lha gfx/show 77K 0+OCS/ECS/AGA/EGS/CyBERgfx FLI/FLC vie IconDeluxe.lha gfx/edit 70K 1+Full-featured icon editor (V1.03) VMM_V3_1.lha util/misc 230K 0+Virtual memory for Amigas with MMU GoldED303.lha text/edit 860K 0+Programmer's editor with many featur GfxLab24.lha gfx/conv 551K 0+GfxLab24 v1.2. Image Processing prog Jouster3.lha game/misc 599K 1+Decent Joust Clone with Extras. MCP104.lha util/wb 218K 1+The ultimate AmigaUtil! New Features @endnode @node CHARTS2 "Aminet Charts - May 29, 1995" @toc FTP | The most downloaded files from Aminet during the week until 29-May-95 | Updated weekly. Most popular file on top. | |File Dir Size Age Description |----------------- --- ---- --- ----------- ar310.lha docs/mags 81K 1+Amiga Report 3.10, May 17, 1995 VMM_V3_1.lha util/misc 230K 0+Virtual memory for Amigas with MMU flick-1.5.lha gfx/show 77K 0+OCS/ECS/AGA/EGS/CyBERgfx FLI/FLC vie GoldED303.lha text/edit 860K 0+Programmer's editor with many featur fview147.lha gfx/show 84K 0+FastView for IFF/GIF/BMP/JPG/PCX ANews18.lha docs/mags 168K 0+AmyNews #18; info on new Amiga produ FingerInfo10.lha comm/net 2K 49+Finger useful/interesting sites VGA_Hack.lha hard/hack 7K 0+Connect VGA-monitor to Amiga RGB VChck654.lha util/virus 123K 1+Version 6.54 of Virus_Checker. Amiga ImageStudio_2.lha gfx/conv 366K 0+Image processing program v2.1.0 Part a1400.lha game/gag 66K 0+First picture of the new A1400 AquaSim1_0.lha misc/sci 281K 1+3D Aquarium Simulator (Uses MUI2.0). DosMan121.lha util/wb 145K 0+Complete GUI Dos Manual xfig1.lha gfx/edit 271K 0+Xfig - a structured drawing tool. 02 GfxLab24.lha gfx/conv 551K 1+GfxLab24 v1.2. Image Processing prog ImageStudio_1.lha gfx/conv 712K 0+Image processing program v2.1.0 Part ExtraInfo.lha util/wb 116K 0+Deluxe Replacement for WB2+ Info, V1 ArcsPack-8.lha pix/wb 1.0M 0+AmigaDOS 3.1 Startup-Pix, Vol 8 by A svlib116U.lha gfx/show 361K 0+Superview.library - loads, saves, di xfig_docs.lha gfx/edit 274K 0+Xfig - a structured drawing tool. 02 @endnode @node MAILLIST "Amiga Report Mailing List" @toc WHERE =========================================================================== == Amiga Report Mailing List == =========================================================================== If you have an internet mailing address, you can receive Amiga Report in @{"UUENCODED" link UUENCODE} form each week as soon as the issue is released. To be put on the list, send Email to jcompton@bbs.xnet.com and in the body of the message ask nicely to be added to the list. ie: Please add me to the mailing list for Amiga Report magazine. My addresss is . Your account must be able to handle mail of any size to ensure an intact copy. For example, many systems have a 100K limit on incoming messages. ** IMPORTANT NOTICE: PLEASE be certain your host can accept mail over ** ** 100K! We have had a lot of bouncebacks recently from systems with a ** ** 100K size limit for incoming mail. If we get a bounceback with your ** ** address in it, it will be removed from the list. Thanks! ** *** The following is only for Australian readers! *** To circumvent the new pay-per-megabyte system for Australian Internet communication, Paul Reece has been kind enough to set up an AUSTRALIAN-ONLY mailing list, to save his fellow countrymen some money. You can join the list by sending mail to: majordomo@info.tas.gov.au with the single line (in body of message): subscribe ar Amiga Report will then be bounced to you. @endnode @node UUENCODE @toc MAILLIST =========================================================================== == UUDecoding Amiga Report == =========================================================================== If you receive Amiga Report from the direct mailing list, it will arrive in UUEncoded format. This format allows programs and archive files to be sent through mail by converting the binary into combinations of ASCII characters. In the message, it will basically look like a lot of trash surrounded by begin and end, followed by the size of the file. To UUDecode Amiga Report, you first need to get a UUDecoding program, such as UUxT by Asher Feldman. This program is available on Aminet in pub/aminet/arc/ Then you must download the message that it is contained in. Don't worry about message headers, the UUDecoding program will ignore them. There is a GUI interface for UUxT, which should be explained in the docs. However, the quickest method for UUDecoding the magazine is to type uuxt x ar.uu at the command prompt. You will then have to decompress the archive with lha, and you will then have Amiga Report in all of its AmigaGuide glory. If you have any questions, you can write to @{"Jason Compton" link JASON} @endnode @node AMINET "Aminet" @toc WHERE Aminet ~~~~~~ To get Amiga Report from Aminet, simply FTP to any Aminet site, CD to docs/mags. All the back issues are located there as well. Sites: ftp.cdrom.com, ftp.wustl.edu, ftp.tas.gov.au, ftp.doc.ic.ac.uk @endnode @node WWW "World Wide Web" @toc WHERE World Wide Web ~~~~~~~~~~~~~~ AR can also be read with Mosaic (in either AmigaGuide or html form). Reading AmigaReport with Mosaic removes the necessity to download it. It can also be read using programs found in UNIX sites such as LYNX. Simply tell Mosaic to open one of the following URLs: http://www.cs.cmu.edu/~mjw/Amiga/News/AR/ http://sun1000.ci.pwr.wroc.pl/AMIGA/AR/ http://mm.iit.uni-miskolc.hu/Data/AR The following AR site also has a mailto form, allowing you to mail to Amiga Report from the web site.