ST Report: 10-Mar-95 #1110

From: Bruce D. Nelson (aa789@cleveland.Freenet.Edu)
Date: 03/19/95-11:39:41 AM Z

From: aa789@cleveland.Freenet.Edu (Bruce D. Nelson)
Subject: ST Report: 10-Mar-95 #1110
Date: Sun Mar 19 11:39:41 1995

                            SILICON TIMES REPORT
                       STR Electronic Publishing Inc.
                               A subsidiary of
                         STR Worldwide CompNews Inc.
   March 10, 1995                                                No. 1110
                            Silicon Times Report
                        International OnLine Magazine
                            Post Office Box 6672
                      Jacksonville, Florida  32221-6155
                            R.F. Mariano, Editor

                   Featured in ITCNet's ITC_STREPORT Echo
                     Voice: 1-904-783-3319  10am-4pm EST
                         STR Publishing Support BBS
                       * THE BOUNTY INTERNATIONAL BBS *
                    Featuring: * 45GB * of Download Files
          Operating with * Mustang Software's WILDCAT! BBS v4.01 *
                 Fully Networked within the following Nets:
                ITCNet 85:881/253 JAX HUB ~ FIDO Net 1:112/35
                 Prowl ~ USPOLNet ~ FNET 350 ~ Nest 90:301/3
               Delivered via Subscriber List through Internet
                    904-786-4176 MULTI-NODE 24hrs-7 days
                    2400-115.2 bps V.32-34 v.42 bis 28.8
                       Hayes Optima 28.8 V.FC Data/Fax
                USRobotics D/S Data/Fax 28.8 V.34 Everything
                       FAX: 904-783-3319 12am-6am EST
           The Bounty STReport Support Central .... 1-904-786-4176
           FNET. 620 : Leif's World ................1-904-573-0734
           FNET. 690 : PASTE BBS....................1-206-284-8493
           FNET. 489 : Steal Your Face BBS..........1-908-920-7981
           MNET - Toad Hall BBS.....................1-617-567-8642

 > 03/10/95 STR 1110  "The Original * Independent * OnLine Magazine!"
 - IBM CLEARED!           - FRACTINIT 19           - IBM BUTTERFLY 
 - CF Review              - People Talking         - Jaguar News 

                       -* WINDOWS'95 - AUGUST 1995! *-
                        -* INFO AGE FUTURE BLEAK? *-
                         -* SUPREME COURT & YOU! *-

                   STReport International OnLine Magazine
                The Original * Independent * OnLine Magazine
                           -* FEATURING WEEKLY *-
                 "Accurate UP-TO-DATE News and Information"
      Current Events, Original Articles, Tips, Rumors, and Information
              Hardware - Software - Corporate - R & D - Imports
 STReport's  BBS  -  The Bounty BBS, invites all BBS systems, worldwide, to
 participate in the ITC/Fido/Internet/PROWL/USENET/USPOLNet/NEST/F-Net Mail
 Networks.    You  may  also  call  The Bounty BBS direct @ 1-904-786-4176.
 Enjoy  the  wonder  and  excitement  of  exchanging  all  types  of useful
 information  relative to all computer types, worldwide, through the use of
 excellent   International  Networking  Systems.  SysOps  and  users  alike
 worldwide, are welcome to join  STReport's International Conferences.  ITC
 Node  is  85:881/250,  The Fido Node is 1:112/35, Crossnet Code is #34813,
 and  the  "Lead  Node"  is  #620.    All computer enthusiasts, hobbyist or
 commercial on all platforms and BBS systems are invited to participate.

     SOFTWARE CREATIONS BBS is proud to distribute Silicon Times Report
                   STReport International OnLine Magazine
      With more than 130 Lines of PCBOARD access, Internet, Telnet and
     X.25 local access in every major city world-wide through SprintNet
                   Software Creations delivers the files!
       Silicon Times Report joins names like Apogee Software, Borland,
     id Software, TriSoft, Interactive Gaming, PC Techniques, Coriolis,
               Fastgraph, PC Information Group, and many more.
           Real-Time Credit Card Approval and Membership Upgrades
                The Software Download Store - for on the spot
                   purchase/approval and download ability!
   Call 1-800-4SWCBBS (479-2227); Fax 1-508-365-7214 for more information!
           So, Get the latest releases from SOFTWARE CREATIONS BBS
                            "Home of the Authors"
            * Software Creations, Voted #1 BBS for 1993 & 1994 *

                  1200/2400 V.42/MNP Lines : (508) 365-2359
              2400-14.4k HST US Robotics Lines : (508) 368-7036
         2400-16.8k V.32/V.42bis US Robotics lines : (508) 368-7139
       14.4-28.8k V.32/V.42bis/V.fc Hayes Optima lines: (508) 365-9352
  14.4-28.8k V.32/V.42bis/V.32terbo/V.fc US Robotics lines: (508) 368-3424


                             to the Readers of;
                   "The Original 16/32bit OnLine Magazine"

                          NEW USERS; SIGN UP TODAY!

                CALL: 1-800-848-8199 .. Ask for operator 198

                  You will receive your complimentary time
                        be OnLine in no time at all!

     "Enjoy CompuServe's forums; where information is at its very best!


   LottoMan Results: 03/04/95: four 2# matches

 > From the Editor's Desk             "Saying it like it is!"

      OUCH!  This is a BIG issue!!  Sorry 'bout that ..but we have some
 very important information in this issue and we felt that it would be best
 if you got it all at once instead of in segments.  The NEW Graphic
 Specification is here courtesy of the Go Graphics Group.  This is the spec
 that's to replace the now clobbered GIF spec.  Yes, clobbered.  Unisys'
 and it's GIFiasco has brought about this speedy upgrade and change. 
 Remember, everything happens for the best.
      Also in this issue, is the news of the upgrade to Thumbs+Plus. 
 Version 2.0c is announced and available.  Friends, this program has got to
 be one of the very best overall graphics tools available anywhere in the
 world.  It does it all and does it well.  I might add, it provides the
 very best looking thumbnails of your graphics libraries none.  Read
 about the powerful update to this fine program in this issue.

      AND... INDEO Video has been updated with the updates already in
 release.  Plus... Microsoft re-affirms the shipping date for Win'95 will
 be August of 1995.  Read all about how you can update your Video for
 Windows 1.1d.  Spring Comdex is less than eight weeks away.  Already the
 new goodies are in the spotlights.  The teasers are flying wildly
 throughout the computing community.  It'll be a fun time for all.


 Of Special Note:
      STReport will be branching out further to Internet's userbase in the
 very near future.  We've received numerous requests to receive STReport
 from a wide variety of Internet addresses.  As a result, we're putting
 together an Internet distribution/mailing list for those who wish to
 receive STReport on a regular basis, and we'll UUENCODE each issue and
 mail it to you.
      If you're interested in being added to our mailing list, please, send
 your requests to either "" or, RMARIANO@DELPHI.COM.  Look
 for mailings to begin by October first.  We are also considering a number
 of Internet ftp sites in which to post our issues for as well.  Whatever
 we can do to make STReport available to you. we'll try it!


  STReport's Staff                      DEDICATED TO SERVING YOU!

                             Publisher -Editor
                              Ralph F. Mariano

                  Lloyd E. Pulley, Editor, Current Affairs

 Section Editors
      ----------     -------------       -----------    -------------
      R.D. Stevens     R. Niles           J. Deegan     D. P. Jacobson

 STReport Staff Editors:

           Michael Arthur           John Deegan         Brad Martin    
           John Szczepanik          Paul Guillot        Joseph Mirando
           Doyle Helms              Frank Sereno        John Duckworth
           Jeff Coe                 Steve Keipe         Guillaume Brasseur
           Melanie Bell             Jay Levy            Jeff Kovach    
           Marty Mankins            Carl Prehn          Paul Charchian

 Contributing Correspondents:
           Dominick J. Fontana      Norman Boucher      Clemens Chin   
           Eric Jerue               Ron Deal            Mike Barnwell  
           Ed Westhusing            Glenwood Drake      Vernon W.Smith
           Bruno Puglia             Paul Haris          Kevin Miller   
           Craig Harris             Allen Chang         Tim Holt  
           Patrick Hudlow           Tom Sherwin

       Please, submit letters to the editor, articles, reviews, etc...
                               via E-Mail to:

                  CompuServe................... 70007,4454
                  Delphi......................... RMARIANO
                  GEnie......................... ST.REPORT
                  BIX............................ RMARIANO
                  FIDONET........................ 1:112/35
                  FNET........................... NODE 620
                  ITC NET...................... 85:881/253
                  NEST........................ 90:21/350.0
                  America OnLine..................STReport

 STReport,  with its policy of not accepting any paid advertising, has over
 the years developed the reputation of "saying it like it really is".  When
 it  comes  to our editorials, product evaluations, reviews and over-views,
 we  shall  always keep our readers interests first and foremost.  With the
 user  in  mind, STReport further pledges to maintain the reader confidence
 that  has  been  developed  over  the  years and to continue "living up to
 such".    All  we  ask is that our readers make certain the manufacturers,
 publishers  etc.,  know exactly where the information about their products
 appeared.    In  closing,  we shall arduously endeavor to meet and further
 develop  the  high standards of straight forwardness our readers have come
 to expect in each and every issue.

                                              The Staff & Editors



                         IBM/POWER-PC/PC SECTION (I)

                   Computer Products Update - CPU Report
                   ------------------------   ----------
                  Weekly Happenings in the Computer World
                                Issue #10
                    Compiled by: Lloyd E. Pulley, Sr.

                  ******* General Computer News *******
                    >> Jury Clears IBM in RSI Suit <<
    Ending the first case of its kind against IBM to go to trial, a jury 
 in Hastings, Minnesota, this week ruled the company is not liable for 
 the disabling repetitive stress injuries a secretary said she suffered 
 from using IBM keyboards.
    Plaintiff Nancy Urbanski also sued Apple Computer Inc. That suit was 
 part of the same trial until Apple settled for an undisclosed amount 
 last week because of attorney errors.

    The suit contended IBM and Apple did not adequately warn her about 
 the potential for repetitive stress injuries to her hands and arms. She 
 says she is unable to perform her job or household tasks.
    Thousands of similar suits have been filed alleging computer manufac-
 turers were negligent in designing keyboards and warning users.
    Last February, a jury in Houston decided that Compaq Computer Corp. 
 was not liable for injuries suffered by a secretary who used one of its 
 computers.  The company, which is the largest maker of personal 
 computers, has since started putting warning labels on some of its 
                         >> IBM Cuts PC Prices <<
    IBM Corp., saying it is intent on maintaining competitive prices, has 
 announced price cuts of up to 22% on selected desktops and servers.
    The cuts range up to 22% on IBM's Personal Computer 300 and 700 
 Series and Performance Series, and up to 17% on selected IBM Server 95 
 and PC Server 300 models.

    For example, the IBM PC 300, with a 66MHz 486DX2 microprocessor, 8MB 
 of RAM and a 540MB hard disk, is now priced at $1,645, down from $1,885. 
 The PC Server 300, with a 60MHz Pentium microprocessor, 16MB of RAM, 
 nine storage bays, eight expansion slots and a 1GB hard disk, is now 
 priced at $3,799, down from $4,499.
                    >> Toshiba, NEC Consider Hikes <<
    Officials of Toshiba Corp. this week indicated the Japanese giant is 
 considering raising its export prices of semiconductors to the U.S. to 
 cope with the yen's recent surge against the dollar.
    Meanwhile NEC Corp., Japan's biggest chip maker, plans to raise its 
 export prices of memory chips to the U.S. for the same quarter, but has 
 yet to decide by how much.
    The rest of Japan's five major semiconductor producers - Hitachi 
 Ltd., Fujitsu Ltd. and Mitsubishi Electric Corp - have not decided 
 whether they will increase export prices.
                 >> IBM Expects Large OS Market Share <<

    IBM Corp. said this week that it hopes to capture 40% of the European 
 market for the latest generation of operating system software.
    IBM's German software director, Richard Siebt, is reported as saying 
 that by the end of 1996 -- after the introduction of Microsoft Corp.'s 
 Windows 95 -- IBM expects to have a 40% share of the market for this new 
 type of operating system.
    In Germany alone, IBM's key business software clients will have 
 installed at least one million versions of OS/2 Warp by the end of next 
 year, Seibt said. "This is a conservative estimate," he said, adding 
 that IBM sold 270,000 versions of the software package in Germany during 
 the first two months of this year and that it was currently shipping 
 1,000 copies a day.
                  >> Justice Dept., Microsoft Appeal <<
    A federal appellate court now officially has been asked to reverse 
 U.S. District Judge Stanley Sporkin's rejection of the antitrust 
 agreement hammered out by the Justice Department and Microsoft Corp.
    Sporkin, on Feb. 14, rejected the controversial consent decree 
 reached last July by Microsoft and the Justice Department. The judge 
 ruled the agreement, which deals mainly with Microsoft's licensing 
 practices for its operating systems, was too narrow and didn't address 
 numerous allegations against Microsoft.
                    >> NEC Offers Pentium Notebooks <<

    Three new Versa P Series notebooks with a 10.4-inch screen and based 
 on Intel Corp.'s Pentium chip have been introduced by NEC Technologies 

    The units will be available later this month in North America through 
 NEC's network of authorized dealers with estimated prices starting at 
                       >> Compaq Cuts PC Prices <<
    Compaq Computer Corp. has lowered prices on a wide array of its 
 business desktop PCs.  The reductions, which range up to 23%, affect 66 
 models in the Compaq Deskpro XL, Compaq Deskpro XE and Compaq ProLinea 
    Current models in the flagship Compaq Deskpro XL family were reduced 
 in price from 8 to 14 percent. Prices for these models with hard disks 
 now start at less than $2,100. Most of the price reductions for the 
 Compaq Deskpro XL line affect current Pentium-based models. In addition, 
 Compaq has added eight new 75 and 100MHz Pentium-based models to the 
 high performance line.
    Models in the Compaq Deskpro XE family, which are being replaced by 
 new Deskpro product, have been cut in price from 8 to 23 percent. These 
 products will be available while supplies last. Prices for the 486-based 
 Compaq Deskpro XE with a 170MB hard disk now start at about $1,199.
    The current Compaq ProLinea desktop and mini-tower products have been 
 reduced in price from 5 to 18% to align them with the prices of newer 
 models. Current Compaq ProLinea models, with a 270MB hard disk, now 
 start at about $1,049.

    Compaq has also lowered prices of its most popular memory options for 
 both desktop and server PCs by as much as 36 percent.
                    >> NexGen Promises Smaller Chip <<
    NexGen Inc. says it will expand its Nx586 microprocessor line with a 
 new, smaller design that will result in significant price-performance 
    The new chip will be 40% smaller in size than the current Nx586 CPU 
 as well as comparable Pentium microprocessors from Intel Corp. NexGen 
 says the smaller die size offers a higher chip per wafer yield. In 
 addition, with the chip's active elements positioned more closely 
 together, data is transmitted more quickly, giving a higher speed to the 
    NexGen says the new chip is scheduled to become available by mid-
                    >> Hayes Drops Smartcom Prices <<
    Hayes Microcomputer Products Inc. is shipping Smartcom Data/Fax Pro, 
 its Windows communications fax modem software, for an estimated retail 
 price of $79.99.
    Hayes officials said the new price for its software is less than half 
 the price of competitive software programs from companies.
    Hayes also said it cut prices for its Smartcom for Windows product to 
 $49.99, its Smartcom BBS Dialer to $14.99 and Smartcom II for the Mac to 
 $119.99. Both Smartcom Data/Fax Pro and Smartcom II for the Mac software 
 were formerly priced at $149.
                  >> Microsoft Nixes 'Ali Baba' Plan <<
    The controversial "Ali Baba" plan to include encrypted versions of 
 new products on the same compact disk that will carry the upcoming 
 Windows 95 software has been killed by Microsoft Corp.
    Microsoft Vice President Michael J. Maples is quoted as saying Chairman
 Bill Gates decided to drop the link to Windows 95, not because of angry
 reaction to the proposal by competitors and retailers, but because of
 "logistical problems" of maintaining a mixed inventory of some disks 
 that had the feature and others that did not.
    The Ali Baba plan would have allowed users of Windows 95, due out in 
 late summer, to preview other Microsoft products on the CD, such as 
 spreadsheet or word-processing software, then purchase them by calling 
 in a credit-card number and receiving a special code to "unlock" the 
    Maples told the wire service that even though Microsoft will not link 
 Ali Baba to Windows, it still plans to use the approach with future 
                   >> Toshiba Unit Sports ROM Drive <<
    Toshiba Corp. is bringing to the U.S. its first notebook computer 
 with an integrated 5.25-inch compact-drive read-only-memory drive.
    The new Satellite Pro T2150 CD series is equipped with a "hot plug" 
 for an external floppy disk drive, allowing consumers to simultaneously 
 use a CD-ROM drive and a floppy disk drive.
    A Toshiba spokesman said a higher-end model with active-matrix color 
 screen, which comes standard with a hard disk drive capacity of 520 
 million bytes, starts at $4,899.
                    >> K-Mart to Offer CD-ROM Line <<

    SoftKey International Inc. reports that after a test market program, 
 K-Mart Inc. has agreed to carry its One Stop CD Shop product line in all 
 2,208 retail stores nationwide.
    The software publisher says the One Stop products will be sold off 
 free-standing racks -- the first time the retail chain has installed a 
 stand-alone consumer software rack system in virtually all store 
    One Stop CD Shop is SoftKey's line of value-priced multi-CD ROM pack-
 ages for Windows and Macintosh computers. The initial version offers 11 
 CD- ROMs that include a mix of games, personal productivity, lifestyle 
 and reference titles.
                  >> Info Age's Bleak Future Forecast <<
    The Information Age could bring a world where corporations take over 
 from nation states and a tiny elite defends itself from dispossessed 
 masses, predicted a British professor at a business conference taking 
 place today in London.
    Ian Angell, a professor at the London School for Economics gave this 
 gloomy view: "Some people foresee a new Middle Ages with a natural state 
 of inequality, with urban areas protected as castles, but 
    It is the growing value of information over other commodities that 
 will propel the world to such a dark future, weakening ties between big 
 business and any fixed place. Information technology will encourage 
 teleworking and video conferencing, eliminating the need for an office 
 except as a social event for employees to bond as community and cement 
 their ties of loyalty to the company.
    Angell predicted property prices will crash and corporations will 
 move where profit is highest and regulation weakest. In addition, nation 
 states will break up as regions dump poorer areas in the fight to get 
 global business, which would seek the securest haven for its information 
 and prized "knowledge workers." Global enterprises would see themselves 
 as owners of their staff and demand their undivided allegiance.
    He forecast that the prized and wealthy elite will form one-tenth of 
 the world's population, while the rest will become the "information 
 poor" -- unwanted and of decreasing use to business.
                  >> IBM Butterfly Emerges This Week <<

    Butterfly, the latest ThinkPad model in IBM's portable computer line, 
 is to officially launch this week and analysts are predicting the 
 computer maker won't be able to meet initial demand.
    The Butterfly has an expanding keyboard that unfolds from inside the 
 machine into a larger size keyboard when the tiny 4.5- pound computer is 
 opened. The screen is a notebook size 10.4- inch color screen. Upon 
 opening, the keyboard inside the ThinkPad 701C mechanically expands and 
 opens to a fuller size keyboard with 85 keys, some hanging over the 
 machine's edges, the closest a subnotebook has come to the standard 102 
    The units are pricey -- ranging from $3,800 to about $5,600, depen-
 ding on the screen, the processor, memory and the size of the hard drive 
 -- and the first versions are designed on Intel Corp.'s '486 processors, 
 not the faster Pentium.
    The new ThinkPads also include a modem, an internal speaker for 
 audio, alight AC adapter and a thin external floppy drive. It can act as 
 answering machine, fax recipient and speaker phone. Battery life 
 averages three hours.
                   >> IBM to Make Autodesk Software <<
    For undisclosed terms, IBM has agreed to make and distribute software 
 products for Autodesk Inc. through a new outsourcing agreement.
    Reports say the deal calls for the IBM Software Manufacturing 
 Solutions to handle CD-ROM and traditional diskette replication, 
 packaging and product distribution for Autodesk products.
    Officials with Autodesk, a major supplier of design software and PC 
 animation tools, said the increased flexibility and additional resources 
 IBM brings will allow Autodesk to invest in new products, markets and 
 channels, and expand its business without significantly increasing 
                  >> Panasonic Pentium Portable Ships <<
    Panasonic Personal Computer Co. this week launched its first Pentium 
 multimedia notebook computer with a 5.25-inch integrated CD-ROM drive.
    Part of Panasonic's V41 line of computers, the new machine features 
 the Intel Pentium 75 MHz chip with 16KB internal cache and 256KB 
 external cache. The company said the V41 Pentium model runs 50% faster 
 than DX4/100 MHz models and up to 20% faster than leading Pentium 
    Prices range from $3,999 to $8,399 depending on the user-selected 

                  >> Compton's Sued Over Alleged Slur <<
    Offended by a computer program's ability to recognize and respond to 
 a racial slur, a man has filed a $40 million libel suit against electronic
 encyclopedia publishers at Compton's NewMedia.
    Thomas D. Wallace says in his suit that he and his sons, Terry, Todd
 and Troy, suffered emotional distress after finding the word "nigger" in 
 the Compton's encyclopedia software. The suit also names Compton's owner,
 Tribune Co. of Chicago, and Best Buy, where the software was purchased.

    Reports say that "Wallace, who is black, said he discovered the slur 
 when he inadvertently typed 'nigger' while looking up the Niger River. 
 In response, the computer found references under 'Drama,' 'Martin Luther 
 King Jr.,' 'Black Americans or African Americans' and 'English 

    Wallace's first suit in state district court was dismissed in 
 December and that he refiled the suit in U.S. District Court in Los 
 Angeles last week.
    Meanwhile, Tribune Co. spokesman Joseph A. Hays said the word appears 
 in a manuscript, the title of a play, the title of a book and a quote in 
 which someone attempted to slur King.
    "The complaint is without merit," he said. "What's more, it's just 
 plain silly."




 March 1, 1994

 A majority of the justices of the U.S. Supreme Court, ruling in a criminal
 evidence case, today suggested that they had serious concerns about the
 potential invasion to individual privacy raised by the nation's increasing
 reliance on computer technology.

 In a series of opinions in a case from Arizona about whether evidence
 seized by the police because of a computer error could be used during
 trial, the justices raised questions about the impact of computers,
 particularly on law enforcement.

 "Although we believe the Court ruled incorrectly in deciding that the
 evidence could be used during trial, I think the majority opinion is quite
 narrow," said Steven Shapiro, ACLU Legal Director. "The more lasting
 significance of the case," he added, "may be that a majority of the Court
 seems quite troubled by the risk that computer technology poses to
 personal privacy.

 "In particular," Shapiro said, "a majority of the Court was clearly
 unwilling to create a new and broad exception to the Exclusionary Rule
 whenever government officials violate the Fourth Amendment based on a
 computer error."

 In his majority opinion for the Court, Chief Justice Rehnquist reversed a
 decision of the Arizona Supreme Court, which had ruled that the evidence
 could not be used because it had been seized during what turned out to be
 an arrest based on a mistaken warrant. Justices O'Connor, Scalia, Kennedy,
 Souter, Thomas and Breyer joined the Chief Justice's decision.

 But Justice O'Connor wrote a concurring opinion, which was joined by
 Justices Souter and Breyer, that discussed the growth of technology and
 its impact on law enforcement.  "In recent years, we have witnessed the
 advent of powerful, computer-based recordkeeping systems that facilitate
 arrests in ways that have never before been possible," O'Connor said. "The
 police, of course, are entitled to enjoy the substantial advantages this
 technology confers. They may not, however, rely on it blindly. With the
 benefits of more efficient law enforcement mechanisms comes the burden of
 corresponding constitutional responsibilities.

 And in another brief concurring opinion, Justice Souter, who was joined by
 Justice Breyer, wrote that "our very concept of deterrence by exclusion of
 evidence should extend to the government as a whole, not merely the
 police, on the ground that there would otherwise be no reasonable
 expectation of keeping the number of resulting false arrests within an
 acceptable minimum limit."

 Justice Ginsburg, in a dissenting opinion joined by Justice Stevens, wrote
 that "widespread reliance on computers to store and convey information
 generates, along with manifold benefits, new possibilities of error, due
 to both computer malfunctions and operator mistakes."  "Most germane to
 this case, computerization greatly amplifies an error's effect, and
 correspondingly intensifies the need for prompt correction; for inaccurate
 data can infect not only one agency, but the many agencies that share
 access to the database," she wrote.

 In a particularly "conspicuous example," Justice Ginsburg said that the
 computerized databases of the FBI's National Crime Information Center
 (NCIC) contain over 23 million records, identifying, among other things,
 persons and vehicles sought by law enforcement agencies nationwide.
 "Thus," she wrote, "any mistake entered into the NCIC spreads nationwide
 in an instant."

           ACLU Free Reading Room  |  American Civil Liberties Union
           gopher://  | 132 W. 43rd Street, NY, NY 10036
 |    "Eternal vigilance is the
   |         price of liberty"



                          MISGUIDED SENATORS TO AID
                          UNCONTROLLED CENSORSHIP?

 The following has been confirmed:

      A matter has come to my attention that is of the utmost importance to
 all of us online.  Simply put, a couple of senators have proposed a
 particularly heinous piece of legislation titled the "Communications
 Decency Act of 1995"  (Senate Bill S. 314).  Basically, the bill would
 subject all forms of electronic communication -- from public Internet
 postings to your most private email -- to government censorship.  The
 effects of the bill onto the online industry would be devastating -- most
 colleges and private companies (AOL, Compuserve, etc.) would probably have
 to shut down or greatly restrict access, since they would be held
 criminally liable for the postings and email of private users.

 Obviously, this bill is designed to win votes for these senators among
 those who are fearful of the internet and aren't big fans of freedom of
 speech -- ie., those who are always trying to censor "pornography" and
 dirty books and such.  Given the political climate in this country, this
 bill might just pass unless the computer community demonstrates its
 strength as a committed political force to be reckoned with.  This, my
 friends, is why I have filled your mailbox with this very long message.

 A petition, to be sent to Congress, the President, and the media, has
 begun spreading through the Internet.  It's easy to participate and be
 heard -- to sign it, you simply follow the instructions below -- which
 boil down to sending a quick email message to a certain address.  That's
 all it takes to let your voice be heard. (You know, if the Internet makes
 democracy this accessible to the average citizen, is it any wonder
 Congress wants to censor it?)

 Finally, PLEASE forward this message to all your friends online. The more
 people sign the petition, the more the government will get the message to
 back off the online community.  We've been doing fine without censorship
 until now -- let's show them we don't plan on allowing them to start now. 
 If you value your freedoms -- from your right to publicly post a message
 on a worldwide forum to your right to receive private email without the
 government censoring it -- you need to take action NOW.  It'll take
 fifteen minutes at the most, a small sacrifice considering the issues at

 Remember, the age of fighting for liberty with muskets and shells is most
 likely over; the time has come where the keyboard and the phone line will
 prove mightier than the sword -- or the Senate, in this case.


 Here's what you have to do to sign the petition:

 send an e-mail message to: 

 The message (NOT the subject heading) should read as follows: 
 SIGNED <your online address> 
 <your full name>  <U.S. Citizen> (y/n) 
 eg.  SIGNED
 lsewell@leland.Stanford.EDU  Laura Sewell  YES


 > PNG SPEC STR Spotlight


    Revision date: 3 March, 1995

      Permission is granted to reproduce this specification in complete
      and unaltered form. Excerpts may be printed with the following
      notice: "excerpted from the PNG (Portable Network Graphics)
      specification, ninth draft." No notice is required in software that
      follows this specification; notice is only required when reproducing
      or excerpting from the specification itself.


      * 0. Status
      * 1. Introduction
      * 2. Data Representation
      * 3. File Structure
      * 4. Standard Chunks
      * 5. Deflate/inflate compression specification
      * 6. Filter algorithms
      * 7. Multi-image extension
      * 8. Recommendations for encoders
      * 9. Recommendations for decoders
      * 10. Appendix: CRC pseudocode
      * 11. Appendix: Rationale
      * 12. Credits

  0. Status

    (This chapter will not be part of the finished Specification.)

    This is the ninth draft of the PNG specification discussion document,
    replacing all previous drafts. There are several significant changes
    from the previous drafts.

      * cHRM: Chromaticity chunk
      * gAMA: Fixed (4 bytes)
      * Extensive editing
      * Filters chapter rewritten
      * Line-by-line filter selection
      * Adam5 interlacing in preference to GIF-style
      * Gamma will remain ancillary
      * Text chunks will be Latin-1
      * New text keywords
      * Compressed text support
      * Pixel unit in oFFs chunk
      * sBIT chunk added
      * HEAD renamed IHDR, TAIL renamed IEND
      * Time chunk is now modification time


    This is the final draft, barring necessary revisions stemming from the
    reference implementation project. It is anticipated that a reference
    implementation will be available by the end of March, after which all
    changes made to the standard chunk set will be backward-compatible.
    Changes made between now (3 March, 1995) and the release of the
    reference implementation will be kept to a minimum. The reference
    implementation will be freely usable in all applications, including
    commercial applications.

  1. Introduction

    The PNG format is intended to provide a portable, legally
    unencumbered, well-compressed, well-specified standard for lossless
    bitmapped image files.

    Although the initial motivation for developing PNG was to replace GIF,
    the design provides some useful new features not available in GIF,
    with minimal cost to developers.

    GIF features retained in PNG include:
      * Palette-mapped images of up to 256 colors.
      * Streamability: files can be read and written strictly serially,
        thus allowing the file format to be used as a communications
        protocol for on-the-fly generation and display of images.
      * Progressive display: a suitably prepared image file can be
        displayed as it is received over a communications link, yielding a
        low-resolution image very quickly with gradual improvement of
        detail thereafter.
      * Transparency: portions of the image can be marked as transparent,
        allowing the effect of a nonrectangular image area to be achieved.
      * Ancillary information: textual comments and other data can be
        stored within the image file.
      * Complete hardware and platform independence.
      * Effective, 100% lossless compression.

    Important new features of PNG, not available in GIF, include:
      * Truecolor images of up to 48 bits per pixel.
      * Grayscale images of up to 16 bits per pixel.
      * Full alpha channel of 8 bits per pixel (general transparency
      * Gamma (brightness) indication, allowing automatic brightness
      * Early and straightforward detection of file corruption.

    PNG is intended to be:
      * Simple and portable: PNG should be widely implementable with
        reasonably small effort for developers.
      * Legally unencumbered: to the best of the knowledge of the PNG
        authors, no algorithms under legal challenge were used.
      * Well compressed: both palette-mapped and truecolor images are
        compressed as effectively as in any other widely used lossless
        format, and in most cases more ffectively.
      * Interchangeable: any standard-conforming PNG file will be readable
        by any PNG decoder.
      * Flexible: the format allows for future extensions and private
        add-ons, without compromising interchangeability more than
        absolutely necessary.
      * Robust: the design supports full file integrity checking as well
        as simple, quick detection of common transmission errors.

    The main part of this specification simply gives the definition of the
    file format. An appendix gives the rationale for many design
    decisions. Although the rationale is not part of the formal
    specification, reading it may help implementors to understand the
    design. Cross-references in the main text point to relevant parts of
    the rationale.

    See Rationale: Why a new file format?, Why these features?, Why not
    these features?, Why not use format XYZ?.


    PNG is pronounced "ping".

  2. Data Representation

    This chapter discusses basic data representations used in PNG files,
    as well as the expected representation of the image data.


    All integers which require more than one byte will be in network byte
    order, which is to say the most significant byte comes first, then the
    less significant bytes in descending order of significance (MSB LSB
    for two-byte integers, B3 B2 B1 B0 for four-byte integers). References
    to bit 7 refer to the highest bit (value 128) of a byte; references to
    bit 0 refer to the lowest bit (value 1) of a byte. Values are unsigned
    unless otherwise noted. Values explicitly noted as signed are
    represented in two's complement notation.

    See Rationale: Byte order.


    All color values range from zero (representing black) to most intense
    at the maximum value for the bit depth. Note that the maximum value at
    a given bit depth is not 2^bitdepth, but rather (2^bitdepth)-1.
    Intensity is not necessarily linear; the gAMA chunk specifies the
    gamma response of the source device, and viewers are strongly
    encouraged to properly compensate. See Gamma correction, below.

    Source data with a precision not directly supported in PNG (for
    example, 5 bit/sample truecolor) must be scaled up to the next higher
    supported bit depth. Such scaling is reversible and hence incurs no
    loss of data, while it reduces the number of cases that decoders must
    cope with. See Recommendations for encoders: Bitdepth scaling.


    PNG images are laid out as a rectangular pixel array, with pixels
    appearing left-to-right within each scanline, and scanlines appearing
    top-to-bottom. (For progressive disclosure purposes, the data may not
    actually be transmitted in this order; see Interlaced data order.) The
    size of each pixel is determined by the bit depth, which is the number
    of bits per stored value in the image data.

    Three types of pixel are supported:
      * Palette-mapped pixels are represented by a single value that is an
        index into a supplied palette. The bit depth determines the
        maximum number of palette entries, not the color precision within
        the palette.
      * Grayscale pixels are represented by a single value that is a
        grayscale level, where zero is black and the largest value for the
        bit depth is white.
      * Truecolor pixels are represented by three-value sequences: red
        (zero = black, max = red) appears first, then green (zero = black,
        max = green), then blue (zero = black, max = blue). The bit depth
        specifies the size of each value, not the total pixel size.

    In all cases, pixels are packed into scanlines consecutively, without
    wasted space between pixels. (The allowable bit depths are restricted
    so that the packing is simple and efficient.) When pixels are less
    than 8 bits deep, they are packed into bytes with the leftmost pixel
    in the high-order bits of a byte, the rightmost in the low-order bits.

    However, scanlines always begin on byte boundaries. When pixels are
    fewer than 8 bits deep, if the scanline width is not evenly divisible
    by the number of pixels per byte then the low-order bits in the last
    byte of each scanline are wasted. The contents of the padding bits
    added to fill out the last byte of a scanline are unspecified.

    An additional byte is added to the beginning of every scanline to
    specify filtering, as discussed in more detail below. The filter byte
    is not considered part of the image data, but it is included in the
    data stream sent to the compression step.


    An alpha channel, representing transparency levels on a per-pixel
    basis, may be included in grayscale and truecolor PNG images.

    An alpha channel value of 0 represents full transparency, and a value
    of 255 represents a fully opaque pixel. Intermediate values indicate
    partially transparent pixels that may be combined with a background
    image to yield a composite image.

    Alpha values are always represented by one byte per pixel, regardless
    of the pixel bit depth. (Alpha channels may be included with images
    that have either 8 or 16 bits per sample, but the alpha channel is 8
    bits in either case.) The alpha value is stored immediately following
    the grayscale or RGB values of the pixel.

    The color stored for a pixel is not affected by the alpha value
    assigned to the pixel. This rule is sometimes called "unassociated" or
    "non pre-multiplied" alpha. (Another common technique is to store
    pixel values premultiplied by the alpha fraction; in effect, the image
    is already composited against a black background. PNG does not use
    premultiplied alpha, since it precludes lossless storage.)

    One other technique is available to provide transparency control
    without the storage cost of a full alpha channel. In a palette image,
    an alpha value may be associated with each palette entry. In grayscale
    and truecolor PNG images without an alpha channel, a single pixel
    value may be identified as being "transparent". These techniques are
    controlled by the tRNS ancillary chunk type.

    If no alpha channel nor tRNS chunk is present, all pixels in the image
    are to be treated as fully opaque.

    Viewers may support transparency control partially, or not at all. See
    Recommendations for encoders: Alpha channel creation and
    Recommendations for decoders: Alpha channel processing.


    PNG allows the image data to be filtered before it is compressed. The
    purpose of filtering is to improve the compressibility of the data.
    The filter step itself does not reduce the size of the data. All PNG
    filters are strictly lossless.

    PNG defines several different filter algorithms, including "none"
    which indicates no filtering. The filter algorithm is specified for
    each scanline by a filter type byte which precedes the filtered
    scanline in the compressed data. An intelligent encoder may switch
    filters from one scanline to the next. The method for choosing which
    filter to employ is up to the encoder.

    See Rationale: Filtering.


    A PNG image can be stored in interlaced order to allow progressive
    disclosure. The purpose of this feature is to allow images to "fade
    in" when they are being displayed on-the-fly. Interlacing slightly
    expands the file size on average, but gives the user a meaningful
    display more rapidly. Note that decoders are required to be able to
    read interlaced images, whether or not they actually perform
    progressive display.

    With interlace type 0, pixels are stored sequentially from left to
    right, and scanlines sequentially from top to bottom (no interlacing).
    This order can be described by the following pseudocode, where the
    "visit" function outputs the value at the specified row and column.
    The other two arguments are the width and height in pixels of the area
    to be filled during progressive display in order to produce a solid

 row = 0
 while row < height begin
           col = 0
           while col < width
                     visit (row, col, 1, 1)
                     col = col + 1
           row = row + 1 end

    Interlace type 1, known as Adam5 after its author, Adam M. Costello,
    consists of five distinct passes over the image. The five passes are
    described by the following pseudocode.

    Again, the function visit() outputs a pixel at the specified row and
    column, and the other two arguments are the width and height of the
    rectangle to paint for a solid progressive display.

  ; Pass 1

  row = 0
  while row < height begin
           col = 0
           while col < width
                 visit (row, col, 4, 4)
                 col = col + 4
           row = row + 4 end

  ; Pass 2

  row = 0
  while row < height begin
           col = 2
           while col < width
                 visit (row, col, 2, 4)
                 col = col + 4
           row = row + 4 end

  ; Pass 3

  row = 2
  while row < height begin
           col = 0
           while col < width
                 visit (row, col, 2, 2)
                 col = col + 2
           row = row + 4 end

  ; Pass 4

  row = 0
  while row < height begin
           col = 1
           while col < width
                 visit (row, col, 1, 2)
                 col = col + 2
           row = row + 2 end

  ; Pass 5

  row = 1
  while row < height begin
           col = 0
           while col < width
                 visit (row, col, 1, 1)
                 col = col + 1
           row = row + 2 end

    Important note: each row of each pass should be regarded as a scanline
    for all purposes, specifically filtering and image layout.


    Gamma is a way of defining the brightness reproduction curve of a
    camera or display device. When brightness levels are expressed as
    fractions in the range 0 to 1, such a device produces an output
    brightness level obright from an input brightness level bright
    according to the equation

   obright = bright ^ gamma

    PNG images may specify the gamma of the camera (or simulated camera)
    that produced the image, and thus the gamma of the image with respect
    to the original scene. To get accurate tone reproduction, the gamma of
    the display device and the gamma of the image file should be
    reciprocals of each other, since the overall gamma of the system is
    the product of the gammas of each component. So, for example, if an
    image with a gamma of 0.4 is displayed on a CRT with a gamma of 2.5,
    the overall gamma of the system is 1.0. An overall gamma of 1.0 gives
    correct tone reproduction.

    In practice, images of gamma around 1.0 and gamma around 0.45 are both
    widely found. PNG expects encoders to record the gamma if known, and
    it expects decoders to correct the image gamma if necessary for proper
    display on their display hardware. Failure to correct for image gamma
    leads to a too-dark or too-light display.

    See Rationale: Why gamma correction?, Recommendations for encoders:
    Encoder gamma handling, and Recommendations for decoders: Decoder
    gamma handling.


    A PNG file can store text associated with the image, such as an image
    description or copyright notice. Keywords are used to indicate what
    each text string represents.

    ISO 8859-1 (Latin-1) is the character set recommended for use in text
    strings. This character set is a superset of 7-bit ASCII.

    Provision is also made for the storage of compressed text.

    See Rationale: Text strings.

  3. File Structure

    A PNG file consists of a PNG signature followed by a series of chunks.
    This chapter defines the signature and the basic properties of chunks.
    Individual chunk types are discussed in the next chapter.


    The first eight bytes of a PNG file always contain the following
    (decimal) values:

    137 80 78 71 13 10 26 10

    This signature indicates that the remainder of the file contains a
    single PNG image, consisting of a series of chunks beginning with an
    IHDR chunk and ending with a IEND chunk.

    See Rationale: PNG file signature.


    Each chunk consists of four parts:

           A 4-byte unsigned integer giving the number of bytes in the
           chunk's data field. The length counts only the data field, not
           itself, the chunk type code, or the CRC. Zero is a valid
           length. Although encoders and decoders should treat the length
           as unsigned, its value may not exceed (2^31)-1 bytes.

    Chunk Type
           A 4-byte chunk type code. For convenience in description and in
           examining PNG files, type codes are restricted to consist of
           uppercase and lowercase ASCII letters (A-Z, a-z). However,
           encoders and decoders should treat the codes as fixed binary
           values, not character strings. For example, it would not be
           correct to represent the type code IDAT by the EBCDIC
           equivalents of those letters. Additional naming conventions for
           chunk types are discussed in the next section.

    Chunk Data
           The data bytes appropriate to the chunk type, if any. This
           field may be of zero length.

           A 4-byte CRC (Cyclical Redundancy Check) calculated on the
           preceding bytes in that chunk, including the chunk type code
           and chunk data fields, but not including the length field. The
           CRC is always present, even for empty chunks such as IEND. The
           CRC algorithm is specified below.

    The chunk data length may be any number of bytes up to the maximum;
    therefore, implementors may not assume that chunks are aligned on any
    boundaries larger than bytes.

    Chunks may appear in any order, subject to the restrictions placed on
    each chunk type. (One notable restriction is that IHDR must appear
    first and IEND must appear last; thus the IEND chunk serves as an
    end-of-file marker.) Multiple chunks of the same type may appear, but
    only if specifically permitted for that type.

    See Rationale: Chunk layout.


    Chunk type codes are assigned in such a way that a decoder can
    determine some properties of a chunk even if it does not recognize the
    type code. These rules are intended to allow safe, flexible extension
    of the PNG format, by allowing a decoder to decide what to do when it
    encounters an unknown chunk. The naming rules are not normally of
    interest when a decoder does recognize the chunk's type.

    Four bits of the type code, namely bit 5 (value 32) of each byte, are
    used to convey chunk properties. This choice means that a human can
    read off the assigned properties according to whether each letter of
    the type code is uppercase (bit 5 is 0) or lower case (bit 5 is 1).
    However, decoders should test the properties of an unknown chunk by
    numerically testing the specified bits; testing whether a character is
    upper or lower case is inefficient, and even incorrect if a
    locale-specific case definition is used.

    It is also worth noting that the property bits are an inherent part of
    the chunk name, and hence are fixed for any chunk type. Thus, TEXT and
    Text are completely unrelated chunk type codes. Decoders should
    recognize codes by simple four-byte literal comparison; it is
    incorrect to perform case conversion on type codes.

    The significance of the property bits is as follows:

    First Byte: 0 (uppercase) = critical, 1 (lower case) = ancillary
           Chunks which are not strictly necessary in order to
           meaningfully display the contents of the file are known as
           "ancillary" chunks. Decoders encountering an unknown chunk in
           which the ancillary bit is 1 may safely ignore the chunk and
           proceed to display the image. The offset chunk (oFFs) is an
           example of an ancillary chunk.

           Chunks which are critical to the successful display of the
           file's contents are called "critical" chunks. Decoders
           encountering an unknown chunk in which the ancillary bit is 0
           must indicate to the user that the image contains information
           they cannot safely interpret. The image header chunk (IHDR) is
           an example of a critical chunk.

    Second Byte: 0 (uppercase) = public, 1 (lower case) = private
           If the chunk is public (part of this specification or a later
           edition of this specification), its second letter is uppercase.
           If your application requires proprietary chunks, and you have
           no interest in seeing the software of other vendors recognize
           them, use a lowercase second letter in the chunk name. Such
           names will never be assigned in the official specification.
           Note that there is no need for software to test this property
           bit; it simply ensures that private and public chunk names will
           not conflict.

    Third Byte: reserved, must be 0 (uppercase) always
           The significance of the case of the third letter of the chunk
           name is reserved for possible future expansion. At the present
           time all chunk names must have uppercase third letters.

    Fourth Byte: 0 (uppercase) = unsafe to copy, 1 (lower case) = safe to
           This property bit is not of interest to pure decoders, but it
           is needed by programs that modify a PNG file.

           If a chunk's safe-to-copy bit is 1, the chunk may be copied to
           a modified PNG file whether or not the software recognizes the
           chunk type, and regardless of the extent of the file

           If a chunk's safe-to-copy bit is 0, it indicates that the chunk
           depends on the image data. If the program has made any changes
           to critical chunks, including addition of, modification of, or
           deletion of critical chunks, then unrecognized unsafe chunks
           must not be copied to the output PNG file. (Of course, if the
           program does recognize the chunk, it may choose to output an
           appropriately modified version.)

           A PNG file modifier is always allowed to copy all unrecognized
           chunks if it has only added, deleted, or modified ancillary
           chunks. This implies that it is not permissible to make
           ancillary chunks that depend on other ancillary chunks.

           PNG file modifiers which do not recognize a critical chunk
           should report an error and refuse to process that PNG file at
           all. The safe/unsafe mechanism is intended for use with
           ancillary chunks. The safe-to-copy bit will always be 0 for
           critical chunks.

    See Rationale: Chunk naming conventions.


    Chunk CRCs are calculated using standard CRC methods. The CRC
    polynomial employed is as follows:


    CRC computation is not difficult, nor as computationally intensive as
    the above may suggest. See Appendix: CRC pseudocode.

  4. Standard Chunks

    This chapter presents the standard types of PNG chunks.


    All implementations must understand and successfully render the
    standard critical chunks. A valid PNG image must contain an IHDR
    chunk, one or more IDAT chunks, and an IEND chunk.

    IHDR Image Header
           This chunk must appear FIRST. Its contents are:

  Width:            4 bytes
  Height:           4 bytes
  Bit depth:        1 byte
  Color type:       1 byte
  Compression type: 1 byte
  Filter type:      1 byte
  Interlace type:   1 byte

    Width and height give the image dimensions in pixels. They are 4-byte
           integers. Zero is an invalid value. The maximum for each is
           (2^31)-1 in order to accommodate languages which have
           difficulty with unsigned 4-byte values.

           Bit depth is a single-byte integer giving the number of bits
           per pixel (for palette images) or per sample (for grayscale and
           truecolor images). Valid values are 1, 2, 4, 8, and 16,
           although not all values are allowed for all color types.

           Color type is a single-byte integer that describes the
           interpretation of the image data. Color type values represent
           sums of the following values: 1 (palette used), 2 (color used),
           and 4 (full alpha used). Valid values are 0, 2, 3, 4, and 6.

           Bit depth restrictions for each color type are imposed both to
           simplify implementations and to prohibit certain combinations
           that do not compress well in practice. Decoders must support
           all legal combinations of bit depth and color type. (Note that
           bit depths of 16 are easily supported on 8-bit display hardware
           by dropping the least significant byte.)

  Color    Allowed    Interpretation
  Type    Bit Depths

  0       1,2,4,8,16  Each pixel value is a grayscale level.

  2       8,16        Each pixel value is an R,G,B series.

  3       1,2,4,8     Each pixel value is a palette index;
                     a PLTE chunk must appear.

  4       8,16        Each pixel value is a grayscale level,
                     followed by an alpha channel byte.

  6       8,16        Each pixel value is an R,G,B series,
                     followed by an alpha channel byte.

    Note that an alpha channel, where present, is always represented by
           one byte per pixel, even when the bit depth is 16.

           Compression type is a single-byte integer that indicates the
           method used to compress the image data. Compression methods are
           defined in a later chapter. At present, only compression type 0
           (inflate/deflate compression with a 32K sliding window) is
           defined. All standard PNG images must be compressed with this
           scheme. The compression type code is provided for possible
           future expansion or proprietary variants. Decoders must check
           this byte and report an error if it holds an unrecognized code.

           Filter type is a single-byte integer that indicates the
           preprocessing method applied to the image data before
           compression. Filtering methods are defined in a later chapter.
           At present, only filter type 0 (adaptive filtering with five
           basic filter types) is defined. As with the compression type
           code, decoders must check this byte and report an error if it
           holds an unrecognized code. See Filter algorithms for details.

           Interlace type is a single-byte integer that indicates the
           transmission order of the pixel data. Two values are currently
           defined: 0 (no interlace) or 1 (Adam5 interlace). See
           Interlaced data order for details.

    PLTE Palette
           This chunk's contents are from 1 to 256 palette entries, each a
           three-byte series of the form:

  red:   1 byte (0 = black, 255 = red)
  green: 1 byte (0 = black, 255 = green)
  blue:  1 byte (0 = black, 255 = blue)

    The number of entries is determined from the chunk length. A chunk
           length not divisible by 3 is an error.

           This chunk must appear for color type 3, and may appear for
           color types 2 and 6. If this chunk does appear, it must precede
           the first IDAT chunk.

           For color type 3 (palette data), the PLTE chunk is required.
           The first entry in PLTE is referenced by pixel value 0, the
           second by pixel value 1, etc. The number of palette entries
           must not exceed the range that can be represented by the bit
           depth (for example, 2^4 = 16 for a bit depth of 4). It is
           permissible to have fewer entries than the bit depth would
           allow. In that case, any out-of-range pixel value found in the
           image data is an error.

           For color types 2 and 6 (truecolor), the PLTE chunk is
           optional. If present, it provides a recommended set of from 1
           to 256 colors to which the truecolor image may be quantized if
           the viewer cannot display truecolor directly. If PLTE is not
           present, such a viewer must select colors on its own, but it is
           often preferable for this to be done once by the encoder.

           Note that the palette uses 8 bits (1 byte) per value regardless
           of the image bit depth specification. In particular, the
           palette is 8 bits deep even when it is a suggested quantization
           of a 16-bit truecolor image.

    IDAT Image Data
           This chunk contains image data. The data has been filtered and
           compressed according to the filter type and compression method
           specified by the IHDR chunk.

           There may be multiple IDAT chunks; if so, they must appear
           consecutively with no other intervening chunks. The compressed
           data stream is the concatenation of the contents of all the
           IDAT chunks. The encoder may divide the compressed data stream
           into chunks as it wishes; chunk boundaries have no semantic
           significance. (Multiple IDAT chunks are allowed so that
           encoders can work in a fixed amount of memory; typically the
           chunk size will correspond to the encoder's buffer size.)

    IEND Image Trailer
           This chunk must appear LAST. It marks the end of the PNG data
           stream. The chunk's data field is empty.


    All ancillary chunks are optional, in the sense that encoders need not
    write them and decoders may ignore them. However, encoders are
    encouraged to write the standard ancillary chunks when the information
    is available, and decoders are encouraged to interpret these chunks
    when appropriate and feasible.

    gAMA Gamma Correction
           This chunk's contents are:

  Image gamma value: 4 bytes

    The gamma correction chunk specifies the gamma of the camera (or
           simulated camera) that produced the image, and thus the gamma
           of the image with respect to the original scene. Note that this
           is not the same as the gamma of the display device that will
           reproduce the image correctly.

           A value of 100000 represents a gamma of 1.0, a value of 45000 a
           gamma of 0.45, and so on (divide by 100000.0). Values around
           1.0 and around 0.45 are common in practice.

           If the encoder does not know the gamma value, it should not
           write a gamma chunk; the absence of a gamma chunk indicates the
           gamma is unknown.

           If the gamma chunk does appear, it must precede the first IDAT
           chunk, and it must also precede the PLTE chunk if present.

           See Gamma correction.

    sBIT Significant Bits
           To simplify decoders, PNG specifies that only certain bit depth
           values be used, and further specifies that values stored must
           be scaled to the full range of possible values at that bit
           depth. However, the sBIT chunk is provided in order to store
           the original number of significant bits.

           For color type 0 (grayscale), the sBIT chunk contains a single
           byte, indicating the number of bits which were significant in
           the source data.

           For color type 2 (RGB truecolor), the sBIT chunk contains three
           bytes, indicating the number of bits which were significant in
           the source data for the red, green, and blue channels,

           For color type 3 (palette color), the sBIT chunk contains three
           bytes, indicating the number of bits which were significant in
           the source data for the red, green and blue components of the
           palette entries, respectively.

           For color type 4 (grayscale with alpha channel), the sBIT chunk
           contains two bytes, indicating the number of bits which were
           significant in the source grayscale data and the source alpha
           channel data, respectively.

           For color type 6 (RGB truecolor with alpha channel), the sBIT
           chunk contains four bytes, indicating the number of bits which
           were significant in the source data for the red, green, blue
           and alpha channels, respectively.

           If the sBIT chunk does appear, it must precede the first IDAT
           chunk, and it must also precede the PLTE chunk if present.

    cHRM Primary Chromaticities and White Point
           Applications that need more precise specification of colors in
           a PNG file may use this chunk to specify the chromaticities of
           the red, green, and blue primaries used in the image, and the
           referenced white point. These values are based in the 1931 CIE
           (International Color Committee) XYZ diagram. Only the
           chromaticities (X and Y) are specified.

           The chunk stores eight values, each encoded as a 4-byte
           integer, representing the X or Y value times 100000. They are
           stored in the order White Point X, White Point Y, Red X, Red Y,
           Green X, Green Y, Blue X, Blue Y.

           The cHRM chunk must appear precede the PLTE and IDAT chunks.

    tRNS Transparency
           Transparency is an alternative to the full alpha channel.
           Although transparency is not as elegant as the full alpha
           channel, it requires less storage space and is sufficient for
           many common cases.

           For color type 3 (palette), this chunk's contents are a series
           of alpha channel bytes, corresponding to palette indexes in the
           PLTE chunk. Each entry indicates that pixels of that palette
           index should be treated as having the specified alpha value.
           Alpha values have the same interpretation as in the full alpha
           channel: 0 is fully transparent, 255 is fully opaque,
           regardless of image bit depth. The tRNS chunk may contain fewer
           alpha channel bytes than there are palette entries. In this
           case, the alpha channel value for all remaining palette entries
           is assumed to be 255. In the common case where only palette
           index 0 need be made transparent, only a one-byte tRNS chunk is
           needed. The tRNS chunk may not contain more bytes than there
           are palette entries.

           For color type 0 (grayscale), the tRNS chunk contains a single
           gray level value, stored in the format

  gray:  2 bytes, range 0 .. (2^bitdepth) - 1

    (For consistency, 2 bytes are used regardless of the image bit depth.)
           Pixels of the specified gray level are to be treated as
           transparent (equivalent to alpha value 0); all other pixels are
           to be treated as fully opaque (alpha value 255).

           For color type 2 (RGB), the tRNS chunk contains a single RGB
           color value, stored in the format

  red:   2 bytes, range 0 .. (2^bitdepth) - 1
  green: 2 bytes, range 0 .. (2^bitdepth) - 1
  blue:  2 bytes, range 0 .. (2^bitdepth) - 1

    (For consistency, 2 bytes per sample are used regardless of the image
           bit depth.) Pixels of the specified color value are to be
           treated as transparent (equivalent to alpha value 0); all other
           pixels are to be treated as fully opaque (alpha value 255).

           tRNS is prohibited for color types 4 and 6, since a full alpha
           channel is already present in those cases.

           When present, the tRNS chunk must precede the first IDAT chunk,
           and must follow the PLTE chunk, if any.

    bKGD Background Color
           This chunk specifies a default background color against which
           the image may be presented. Note that viewers are not bound to
           honor this chunk; a viewer may choose to use a different
           background color.

           For color type 3 (palette), the bKGD chunk contains:

  palette index: 1 byte

    The value is the palette index of the color to be used as background.

           For color types 0 and 4 (grayscale, with or without alpha),
           bKGD contains:

  gray:  2 bytes, range 0 .. (2^bitdepth) - 1

    (For consistency, 2 bytes are used regardless of the image bit depth.)
           The value is the gray level to be used as background.
           For color types 2 and 6 (RGB, with or without alpha), bKGD

  red:   2 bytes, range 0 .. (2^bitdepth) - 1
  green: 2 bytes, range 0 .. (2^bitdepth) - 1
  blue:  2 bytes, range 0 .. (2^bitdepth) - 1

    (For consistency, 2 bytes per sample are used regardless of the image
           bit depth.) This is the RGB color to be used as background.

           When present, the bKGD chunk must precede the first IDAT chunk,
           and must follow the PLTE chunk, if any.

           See Recommendations for decoders: Background color.

    hIST Image Histogram
           The histogram chunk gives the approximate usage frequency of
           each color in the color palette. A histogram chunk may appear
           only when a palette chunk appears. If a viewer is unable to
           provide all the colors listed in the palette, the histogram may
           help it decide how to choose a subset of the colors for

           This chunk's contents are a series of 2-byte (16 bit) unsigned
           integers. There must be exactly one entry for each entry in the
           PLTE chunk. Each entry is approximately equal to the number of
           pixels with that palette index, multiplied by 65535, and
           divided by the total number of pixels, rounding up.

           Histogram entries are approximate, with the exception that a
           zero entry specifies that the corresponding palette entry is
           not used at all in the image. It is required that a histogram
           entry be nonzero if there are any pixels of that color.

           When the palette is a suggested quantization of a truecolor
           image, the histogram is necessarily approximate, since a
           decoder may map pixels to palette entries differently than the
           encoder did. In this situation, zero entries should not appear.

           The hIST chunk, if it appears, must follow the PLTE chunk, and
           must precede the first IDAT chunk.

           See Rationale: Palette histograms, and Recommendations for
           decoders: Palette histogram usage.

    tEXt Textual Data
           A tEXt chunk contains a keyword followed by a text string. The
           keyword and text string are separated by a zero byte (null
           character). Neither the keyword nor the string may contain a
           null character. Note that the text string is not
           null-terminated (the length of the chunk is sufficient
           information to locate the ending). Both keyword and text are
           interpreted according to the ISO 8859-1 (Latin-1) character
           set. Newlines in the text string should be represented by a
           single linefeed character (decimal 10); use of other ASCII
           control characters is discouraged. Nulls (decimal 0) are not
           permitted inside the keyword or the text.

           Any number of tEXt chunks may appear, and more than one with
           the same keyword is permissible.

           The keyword indicates the type of information represented by
           the string. The following keywords are predefined and should be
           used where appropriate:

  Title            Short title or caption for image
  Author           Name of image's creator
  Copyright        Copyright notice
  Description      Description of image (possibly long)
  Software         Software used to create the image
  Disclaimer       Legal disclaimer
  Warning          Warning of nature of content
  Source           Device used to create the image
  Comment          Miscellaneous comment; conversion from GIF comment

    Other keywords, containing any sequence of printable characters in the
           character set, may be invented for other purposes. Keywords of
           general interest may be registered with the maintainers of the
           PNG specification.

           Keywords must be spelled exactly as registered, so that
           decoders may use simple literal comparisons when looking for
           particular keywords. In particular, keywords are considered

           See Recommendations for encoders: Text chunk processing and
           Recommendations for decoders: Text chunk processing.

    zTXt Compressed Textual Data
           A zTXt chunk contains textual data, just as tEXt does; however,
           zTXt takes advantage of compression.

           A zTXt chunk consists of an uncompressed Latin-1 keyword
           followed by a null (0) character, analogous to the tEXt chunk.
           The next byte after the null contains a compression type byte,
           for which the only legitimate value is presently zero
           (inflate/deflate compression). The compression-type byte is
           followed by a compressed Latin-1 text data stream which makes
           up the remainder of the chunk.

           Any number of zTXt and tEXt chunks may appear in the same file.
           See the preceding definition of the tEXt chunk for the
           allowable keywords and the exact format of the text.

           See Recommendations for encoders: Text chunk processing and
           Recommendations for decoders: Text chunk processing.

    pHYs Physical Pixel Dimensions
           This chunk's contents are:

  4 bytes: units per pixel, X axis (unsigned integer)
  4 bytes: units per pixel, Y axis (unsigned integer)
  1 byte: unit specifier

    The following values are legal for the unit specifier:

  0: unit is unknown (aspect ratio only)
  1: unit is the micrometer (also known as the micron; 1/1,000,000th of a

    Conversion note: one inch is equal to exactly 25,400 micrometers by

           If this ancillary chunk is not present, pixels are assumed to
           be square, and the physical size of each pixel is unknown.

           If present, this chunk must precede the first IDAT chunk.

           See Recommendations for decoders: Pixel dimensions.

    oFFs Physical Image Offset
           This chunk's contents are:

  4 bytes: image position on the page, X axis: signed integer
  4 bytes: image position on the page, Y axis: signed integer
  1 byte: unit specifier

    Both position values are signed. The following values are legal for
           the unit specifier:

  0: unit is the pixel (true dimensions unknown)
  1: unit is the micrometer (also known as the micron; 1/1,000,000th of a

    Conversion note: one inch is equal to exactly 25,400 micrometers by

           This chunk gives the position on a printed page at which the
           image should be output when printed alone. The X position is
           measured rightwards from the left side of the page to the left
           side of the image; the Y position is measured downwards from
           the top side of the page to the top of the image.

           If present, this chunk must precede the first IDAT chunk.
   tIME Image Last-Modification Time
           This chunk's contents are:

  2 bytes: Year (complete; for example, 1995)
  1 byte: Month (1-12)
  1 byte: Day (1-31)
  1 byte: Hour (0-23)
  1 byte: Minute (0-59)
  1 byte: Second (0-61)

    This chunk gives the time of the last image modification. Universal
           Time (UTC, also called GMT) should be specified rather than
           local time.


    This table summarizes some properties of the standard chunk types.

  Name  Multiple  Ordering constraints
  IHDR    No      Must be first
  PLTE    No      Before IDAT
  IDAT    Yes     Multiple IDATs must be consecutive
  IEND    No      Must be last
  gAMA    No      Before PLTE, IDAT
  sBIT    No      Before PLTE, IDAT
  cHRM    No      Before PLTE, IDAT
  tRNS    No      After PLTE; before IDAT
  bKGD    No      After PLTE; before IDAT
  hIST    No      After PLTE; before IDAT
  tEXt    Yes
  zTXt    Yes
  pHYs    No      Before IDAT
  oFFs    No      Before IDAT
  tIME    No

    Standard keywords for tEXt and zTXt chunks:

  Title            Short title or caption for image
  Author           Name of image's creator
  Copyright        Copyright notice
  Description      Description of image (possibly long)
  Software         Software used to create the image
  Disclaimer       Legal disclaimer
  Warning          Warning of nature of content
  Source           Device used to create the image
  Comment          Miscellaneous comment; conversion from GIF comment

  5. Deflate/inflate compression specification

    This draft proposes use of the inflate/deflate compression scheme, an
    LZ77 derivative which is used in zip, gzip, pkzip and related
    programs, because extensive research has been done supporting its
    patent-free status. Inflate and deflate code is available in the
    zip/unzip packages with a very permissive license (yes, permissive
    enough for commercial purposes, see those packages for details).

    A formal, detailed specification of inflate and deflate will be
    included in the final standard, and is being written at this time. The
    current draft of the inflate/deflate specification is now available by
    anonymous FTP from in the directory
    pub/ghost/gzip-doc. The compressed data stream will be stored in the
    Ziplib format, the specification of which has been written and will be
    referenced shortly.

  6. Filter algorithms

    This chapter describes the pixel filtering algorithms which may be
    applied in advance of compression. The purpose of these filters is to
    prepare the image data for optimum compression.

    PNG defines five basic filtering algorithms, which are given numeric
    codes as follows:

  Code    Name
  0       None
  1       Sub
  2       Up
  3       Average
  4       Paeth

    The encoder may choose which algorithm to apply on a
    scanline-by-scanline basis. In the image data sent to the compression
    step, each scanline is preceded by a filter type byte containing the
    numeric code of the filter algorithm used for that scanline.

    Filtering algorithms are applied to bytes, not to pixels, regardless
    of the bit depth or color type of the image. The filtering algorithms
    work on the byte sequence formed by a scanline that has been
    represented as described previously (Image layout).

    When the image is interlaced, each pass of the interlace pattern is
    treated as an independent image for filtering purposes. The filters
    work on the byte sequences formed by the pixels actually transmitted
    during a pass, and the "previous scanline" is the one previously
    transmitted in the same pass, not the one adjacent in the complete
    image. Note that the subimage transmitted in any one pass is always
    rectangular, but is of smaller width and height than the complete

    For all filters, the bytes "to the left of" the first pixel in a
    scanline must be treated as being zero. For filters that refer to the
    prior scanline, the entire prior scanline must be treated as being
    zeroes for the first scanline of an image (or of a pass of an
    interlaced image).

    To reverse the effect of a filter, the decoder must use the decoded
    values of the prior pixel on the same line, the pixel immediately
    above the current pixel on the prior line, and the pixel just to the
    left of the pixel above. This implies that at least one scanline's
    worth of image data must be stored by the decoder at all times. Note
    that although some filter types do not refer to the prior scanline,
    the decoder must always store each scanline as it is decoded, since
    the next scanline might use a filter that refers to it.

    PNG imposes no restriction on which filter types may be applied to an
    image. However, the filters are not equally effective on all types of
    data. See Recommendations for encoders: Filter selection.

    See also Rationale: Filtering.


    With the None filter, the scanline is transmitted unmodified; it is
    only necessary to insert a filter type byte before the data.


    The Sub filter transmits the difference between each byte and the
    value of the corresponding byte of the prior pixel.

    Apply the following formula to each byte of each scanline, where x
    ranges from zero to the number of bytes representing that scanline
    minus one (1), and Raw(x) refers to the raw data byte at that byte
    position in the scanline:

    Sub(x) = Raw(x) - Raw(x-bpp)

    Note this is done for each byte, regardless of bit depth. Unsigned
    arithmetic modulo 256 is used, so that both the inputs and outputs fit
    into bytes. The sequence of Sub values is transmitted as the filtered

    bpp is defined as the number of bytes per complete pixel, rounding up
    to one (1). For instance, for color type 2 with a bit depth of 16, bpp
    is equal to 6 (three channels, two bytes per channel); for color type
    0 with a bit depth of 2, bpp is equal to 1 (rounding up); for color
    type 4 with a bit depth of 16, bpp is equal to 3 (two-byte grayscale
    value, plus one-byte alpha channel).

    Important: for all x < 0, assume Raw(x) = 0.

    To reverse the effect of the Sub filter after decompression, output
    the following value:

    Sub(x) + Raw(x-bpp)

    (computed mod 256), where Raw refers to the bytes already decoded.


    The Up filter is just like the Sub filter except that the pixel
    immediately above the current pixel, rather than just to its left, is
    used as the predictor.

    Apply the following formula to each byte of each scanline, where x
    ranges from zero to the number of bytes representing that scanline
    minus one (1), and Raw(x) refers to the raw data byte at that byte
    position in the scanline:

    Up(x) = Raw(x) - Prior(x)

    where Prior refers to the unfiltered bytes of the prior scanline.

    Note this is done for each byte, regardless of bit depth. Unsigned
    arithmetic modulo 256 is used, so that both the inputs and outputs fit
    into bytes. The sequence of Up values is transmitted as the filtered

    Important: on the first scanline of an image (or of a pass of an
    interlaced image), assume Prior(x) = 0 for all x.

    To reverse the effect of the Up filter after decompression, output the
    following value:

    Up(x) + Prior(x)

    (computed mod 256), where Prior refers to the decoded bytes of the
    prior scanline.


    The Average filter uses the average of the two neighboring pixels
    (left and above) to predict the value of a pixel.

    Apply the following formula to each byte of each scanline, where x
    ranges from zero to the number of bytes representing that scanline
    minus one (1), and Raw(x) refers to the raw data byte at that byte
    position in the scanline:

    Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2)

    where Prior refers to the unfiltered bytes of the prior scanline, and
    bpp is defined as for the Sub filter.

    Note this is done for each byte, regardless of bit depth. The sequence
    of Average values is transmitted as the filtered scanline.

    The subtraction of the predicted value from the raw byte must be done
    modulo 256, so that both the inputs and outputs fit into bytes.
    However, the sum Raw(x-bpp)+Prior(x) must be formed without overflow
    (using at least nine-bit arithmetic). floor() indicates that the
    result of the division is rounded to the next lower integer if
    fractional; in other words, it is an integer division or right shift

    Important: for all x < 0, assume Raw(x) = 0. On the first scanline of
    an image (or of a pass of an interlaced image), assume Prior(x) = 0
    for all x.

    To reverse the effect of the Average filter after decompression,
    output the following value:

    Average(x) + floor((Raw(x-bpp)+Prior(x))/2)

    where the result is computed mod 256, but the prediction is calculated
    in the same way as for encoding. Raw refers to the bytes already
    decoded, and Prior refers to the decoded bytes of the prior scanline.


    The Paeth filter computes a simple linear function of the three
    neighboring pixels (left, above, upper left), then chooses as
    predictor the neighboring pixel closest to the computed value. This
    technique is taken from Alan W. Paeth's article "Image File
    Compression Made Easy" in Graphics Gems II, James Arvo, editor,
    Academic Press, 1991.

    Apply the following formula to each byte of each scanline, where x
    ranges from zero to the number of bytes representing that scanline
    minus one (1), and Raw(x) refers to the raw data byte at that byte
    position in the scanline:

    Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp))

    where Prior refers to the unfiltered bytes of the prior scanline, and
    bpp is defined as for the Sub filter.

    Note this is done for each byte, regardless of bit depth. Unsigned
    arithmetic modulo 256 is used, so that both the inputs and outputs fit
    into bytes. The sequence of Paeth values is transmitted as the
    filtered scanline.

    The PaethPredictor function is defined by the following pseudocode.

    Note that the order in which ties are broken is fixed and must not be
    altered. The order is: pixel to the left, pixel above, pixel to the
    upper left.

      function PaethPredictor (a, b, c)
           ; a = left, b = above, c = upper left
           p = a + b - c         ; initial estimate
           pa = abs(p - a)       ; distances to a, b, c
           pb = abs(p - b)
           pc = abs(p - c)
           ; return nearest of a,b,c,
           ; breaking ties in order a,b,c.
           if pa <= pb AND pa <= pc
                return a
           if pb <= pc
                return b
           return c

    Note that non-overflowing integer arithmetic is required for the
    calculations within the PaethPredictor function; arithmetic modulo 256
    is to be used only for the final step of subtracting the function
    result from the target pixel value. (Also note that the tie break
    order differs from that given in Paeth's article.)

    Important: for all x < 0, assume Raw(x) = 0 and Prior(x) = 0. On the
    first scanline of an image (or of a pass of an interlaced image),
    assume Prior(x) = 0 for all x.

    To reverse the effect of the Paeth filter after decompression, output
    the following value:

    Paeth(x) + PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp))

    (computed mod 256), where Raw and Prior refer to bytes already
    decoded. Exactly the same PaethPredictor function is used by both
    encoder and decoder.

  7. Multi-image extension

    PNG itself is strictly a single-image format. However, it may be
    necessary to store multiple images within one file; for example, this
    is needed to convert some GIF files. For this purpose, a multi-image
    format will be defined in the near future. PNG decoders will not be
    required to support the multi-image extension.

  8. Recommendations for encoders

    This chapter gives some recommendations for encoder behavior. The only
    absolute requirement on a PNG encoder is that it produce files which
    conform to the format specified in the preceding chapters. However,
    best results will usually be achieved by following these


    If you want others outside your organization to understand a chunk
    type that you invent, contact the editor of the PNG specification
    ( and specify the format of the chunk's data and
    your preferred chunk type name. The authors will assign a permanent,
    unique chunk type name. The chunk type will be publicly listed in an
    appendix of extended chunk types which can be optionally implemented.
    Note that the creation of new critical chunk types is discouraged
    unless absolutely necessary. This process will begin as soon as the
    basic specification is finalized. In the event that Mr. Boutell is
    unable to maintain the specification, the task will be passed on to a
    qualified volunteer or organization.

    New proprietary chunks will be only be registered if they are of use
    to others and do not violate the design philosophy of PNG. Chunk
    registration is not automatic, although it is the intent of the
    authors that it be straightforward when a new chunk of potentially
    wide application in one or several fields is needed.

    If you do not require or desire that others outside your organization
    understand the chunk type, you may use a private chunk name by
    specifying a lowercase letter for the second character.

    Please note that if you want to use a private chunk for information
    that is not essential to view the image, and have any desire
    whatsoever that others not using your internal viewer software be able
    to view the image, you should use an ancillary chunk type (first
    character is lowercase) rather than a critical chunk type (first
    character uppercase).

    Also note that others may use the same private chunk name, so it is
    advantageous to keep additional identifying information at the
    beginning of the chunk data.

    If an ancillary chunk is to contain textual information that might be
    of interest to a human user, it is recommended that a special chunk
    type not be used. Instead use a tEXt chunk and define a suitable
    keyword. In this way, the information will be available to users not
    using your software.

    New keywords for tEXt chunks may be registered with the maintainers of
    the PNG specification. Keywords should be reasonably self-explanatory.


    When scaling input values with a bit depth that cannot be directly
    represented in PNG, an excellent approximation to the correct value
    can be achieved by shifting the valid bits to begin in the most
    significant bit and repeating the most significant bits into the open

    For example, if 5 bits per channel are available in the source data,
    conversion to a bitdepth of 8 can be achieved as follows.

    If the value for a sample in the source data is 27 (in a range from
    0-31), then the original bits are:

  4 3 2 1 0 ---------
  1 1 0 1 1

    Converted to a bitdepth of 8, the best value is 222:

  7 6 5 4 3  2 1 0 ----------------
  1 1 0 1 1  1 1 0
  |=======|  |===|
     |      Leftmost Bits Repeated to Fill Open Bits
  Original Bits

    Note that this scaling can be reversed simply by shifting right.

    Scaling by simply shifting left by three bits is incorrect, since the
    resulting data would have a range less than the desired full range
    (continuing the example, 248 = 11111000 is not full brightness).


    If it is possible for the encoder to determine the image gamma, or to
    make a strong guess based on the hardware on which it runs, then the
    encoder is strongly encouraged to output the gAMA chunk.

    A linear brightness level, expressed as a floating-point value in the
    range 0 to 1, may be converted to a gamma-corrected pixel value by

   gbright = bright ^ gamma
   pixelval = ROUND(gbright * MAXPIXVAL)

    Computer graphics renderers often do not perform gamma encoding,
    instead making pixel values directly proportional to scene brightness.
    This "linear" pixel encoding is equivalent to gamma encoding with a
    gamma of 1.0, so graphics programs that produce linear pixels should
    always put out a gAMA chunk specifying a gamma of 1.0.

    It is not recommended that encoders attempt to convert supplied images
    to a different gamma. Store the data in the file without conversion,
    and record the source gamma. Gamma conversion at encode time is a bad
    idea because gamma adjustment of digital pixel data is inherently
    lossy, due to roundoff error (8 or so bits is not really enough
    accuracy). Thus encode-time conversion permanently degrades the image.
    Worse, if the eventual decoder wants the data with some other gamma,
    then two conversions occur, each introducing roundoff error. Better to
    store the data losslessly and incur at most one conversion when the
    image is finally displayed.


    Encoders should keep in mind the possibility that a viewer will ignore
    transparency control. Hence, the colors assigned to transparent pixels
    should be reasonable background colors.

    For applications that do not require a full alpha channel, or cannot
    afford the price in compression efficiency, the tRNS transparency
    chunk is also available.

    If the image has a known background color, this color should be
    written in the bKGD chunk. Even viewers that ignore transparency may
    use the bKGD color to fill unused screen area.


    For images of color type 3 (palette-based color), filter type 0 (none)
    is usually the most effective.

    Filter type 0 is also recommended for images of bit depths less than
    8. For low-bit-depth grayscale images, it may be a net win to expand
    the image to 8-bit representation and apply filtering, but this is

    For truecolor and grayscale images, any of the five filters may prove
    the most effective. If an encoder wishes to use a fixed filter choice,
    the Paeth filter is most likely to be the best.

    For best compression of truecolor and grayscale images, we recommend
    an adaptive filtering approach in which a filter is chosen for each
    scanline. The following simple heuristic has performed well in early
    tests: compute the output scanline using all five filters, and select
    the filter which gives the smallest sum of absolute values of outputs.
    (Consider the output bytes as signed differences for this test.) This
    method usually outperforms any single fixed filter choice. However, it
    is likely that much better heuristics will be found as more experience
    is gained with PNG.

    Filtering according to these recommendations is effective on
    interlaced as well as noninterlaced images.


    If an encoder chooses to support output of zTXt compressed text
    chunks, it is recommended that text less than 1K (1024 bytes) in size
    be output using uncompressed tEXt chunks. In particular, it is
    recommended that the basic title and author keywords be output using
    uncompressed tEXt chunks. Lengthy disclaimers, on the other hand, are
    an ideal candidate for zTXt.

    Encoders should discourage the creation of single lines of text longer
    than 79 characters in order to facilititate easy reading.

  9. Recommendations for decoders

    This chapter gives some recommendations for decoder behavior. The only
    absolute requirement on a PNG decoder is that it successfully read any
    file conforming to the format specified in the preceding chapters.
    However, best results will usually be achieved by following these


    Unknown chunk types must be handled as described under Chunk naming

    It is strongly recommended that decoders verify the CRC on each chunk.

    For known-length chunks such as IHDR, decoders should treat an
    unexpected chunk length as an error. Future extensions to this
    specification will not add new fields to existing chunks; instead, new
    chunk types will be added to carry any new information.

    Unexpected values in fields of known chunks (for example, an
    unexpected compression type in the IHDR chunk) should be checked for
    and treated as errors.


    Non-square pixels can be represented (see the pHYs chunk), but viewers
    are not required to account for them; a viewer may present any PNG
    file as though its pixels are square.

    Conversely, viewers running on display hardware with non-square pixels
    are strongly encouraged to rescale images for proper display.


    To achieve PNG's goal of universal interchangeability, decoders are
    required to accept all types of PNG image: palette, truecolor, and
    grayscale. Viewers running on palette-mapped display hardware need to
    be able to reduce truecolor images to palette form for viewing. This
    process is usually called "color quantization".

    A simple, fast way of doing this is to reduce the image to a fixed
    palette. Palettes with uniform color spacing ("color cubes") are
    usually used to minimize the per-pixel computation. For
    photograph-like images, dithering is recommended to avoid ugly
    contours in what should be smooth gradients; however, dithering
    introduces graininess which may be objectionable.

    The quality of rendering can be improved substantially by using a
    palette chosen specifically for the image, since a color cube usually
    has numerous entries that are unused in any particular image. This
    approach requires more work, first in choosing the palette, and second
    in mapping individual pixels to the closest available color. PNG
    allows the encoder to supply a suggested palette in a PLTE chunk, but
    not all encoders will do so, and the suggested palette may be
    unsuitable in any case (it may have too many or too few colors).
    High-quality viewers will therefore need to have a palette selection
    routine at hand. A large lookup table is usually the most feasible way
    of mapping individual pixels to palette entries with adequate speed.

    Numerous implementations of color quantization are available. The PNG
    reference implementation will include code for the purpose.


    To produce correct tone reproduction, a good image display program
    must take into account the gammas of both the image file and the
    display device. This can be done by calculating

   gbright = pixelval / MAXPIXVAL
   bright = gbright ^ (1.0 / file_gamma)
   gcvideo = bright ^ (1.0 / display_gamma)
   fbval = ROUND(gcvideo * MAXFBVAL)

    where MAXPIXVAL is the maximum pixel value in the file (255 for 8-bit,
    65535 for 16-bit, etc), MAXFBVAL is the maximum value of a frame
    buffer pixel (255 for 8-bit, 31 for 5-bit, etc), pixelval is the value
    of the pixel in the PNG file, and fbval is the value to write into the
    frame buffer. The first line converts from pixel code into a
    normalized 0 to 1 floating point value, the second undoes the encoding
    of the image file to produce a linear brightness value, the third line
    pre-corrects for the monitor's gamma response, and the fourth converts
    to an integer frame buffer pixel. In practice the third and fourth
    lines are merged into

   gcvideo = gbright ^ (1.0 / (file_gamma * display_gamma))

    so as to perform only one power calculation.

    (Note that this assumes that you want the final image to have a gamma
    of 1.0 relative to the original scene. Sometimes it looks better to
    make the overall gamma a bit higher, perhaps 1.25. To get this,
    replace the first "1.0" in the formula above with

    It is not necessary to perform transcendental math for every pixel!
    Instead, compute a lookup table that gives the correct output value
    for every pixel value. This requires only 256 calculations per image
    (for 8-bit accuracy), not one calculation per pixel. For palette-based
    images, a one-time correction of the palette is sufficient.

    In some cases even computing a gamma lookup table may be a concern. In
    these cases, viewers are encouraged to have precomputed gamma
    correction tables for file_gamma values of 1.0 and 0.45 and some
    reasonable single display_gamma value, and to use the table closest to
    the gamma indicated in the file. This will produce acceptable results
    for the majority of real files.

    In practice, it is often difficult to determine the gamma of the
    actual display. It is common to assume a display gamma of 2.2 (or 1.0,
    on hardware for which this value is common) and allow the user to
    modify this value at their option.

    Similarly, when the incoming image has unknown gamma (no gAMA chunk),
    choose a likely default value, but allow the user to select a new one
    if the result proves too dark or too light.

    Finally, note that the response of real displays is actually more
    complex than can be described by a single number (display_gamma). If
    actual measurements of the monitor's light output as a function of
    voltage input are available, the third and fourth lines of the
    computation above may be replaced by a lookup in these measurements,
    to find the actual frame buffer value that most nearly gives the
    desired brightness.


    In the most general case, the alpha channel can be used to composite a
    foreground image against a background image; the PNG file defines the
    foreground image and the transparency mask, but not the background
    image. Decoders are not required to support this most general case,
    and most likely, few will. It is expected that most will be able to
    support compositing with a single background color, however.

    Viewers which cannot blend colors smoothly with the background should
    interpret all nonzero alpha values as fully opaque (no background).
    This case is reasonably simple to implement: transparent pixels are
    replaced by the background color, others are unchanged.

    If a viewer has no particular background against which to present an
    image, it may ignore the alpha channel or tRNS chunk. (But alpha
    channel values must still be properly skipped over when reading the
    image data.)

    However, if the background color has been set with the bKGD chunk, the
    alpha channel can be meaningfully interpreted with respect to it even
    in a standalone image viewer.


    Viewers which have a specific background against which to present the
    image will ignore the bKGD chunk, but viewers with no preset
    background color may choose to honor it. The background color will
    typically be used to fill unused screen space, as well as any
    transparent pixels. If no bKGD chunk is present, the viewer must make
    its own decision about a suitable background color.


    If the viewer is only short a few colors, it is usually adequate to
    drop the least-used colors from the palette. To reduce the number of
    colors substantially, it's best to choose entirely new representative
    colors, rather than trying to use a subset of the existing palette.
    This amounts to performing a new color quantization step; however, the
    existing palette and histogram can be used as the input data, thus
    avoiding a scan of the image data.

    If no histogram chunk is provided, a decoder can of course develop its
    own, at the cost of an extra pass over the image data.


    If practical, decoders should have a way to display to the user all
    tEXt and zTXt chunks found in the file. Even if the decoder does not
    recognize a particular text keyword, the user may well be able to
    understand it.

    Decoders should be prepared to display text chunks which contain any
    number of printing characters between newline characters, although
    encoders are encouraged to avoid creating lines in excess of 79

  10. Appendix: CRC Pseudocode

    (This appendix is not part of the formal PNG specification.)

    The CRC definition may look formidable, but it is possible to
    implement CRC efficiently without much trouble. This appendix gives
    pseudocode showing one practical implementation. Of course, encoders
    and decoders are not required to use this particular implementation,
    provided that the result is always the same.

    In the following pseudocode, hexadecimal numbers are presented in the
    format used by the C programming language: the characters "0x"
    followed by one or more hexadecimal digits.

    The following pseudocode calculates the 32-bit crc for the bytes
    b(0..n-1), where n is the total number of input bytes. The polynomial
    is x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1.
    Reversed in bit form this is the four-byte unsigned hexadecimal
    integer 0xedb88320. The crc is preconditioned with one's and inverted
    for placement in the stream. This ensures that a data stream of zeroes
    modifies the crc, and that an empty set gives a zero crc.

    The function BitwiseExclusiveOR returns the result of an exclusive OR
    (XOR) operation on the bits of two unsigned integers. The function
    BitwiseAND returns the result of an AND operation on the bits of two
    unsigned integers.

    The function RightShift returns the result of shifting the bits of an
    unsigned integer one bit to the right, displacing the rightmost bit
    and filling the leftmost bit with the value zero.

    The function BitwiseNegation returns the result of inverting the bits
    of an unsigned integer.

  ; n is the number of bytes on which to compute the CRC
  ; b(0..n-1) contains the input bytes
  ; c is an unsigned four-byte integer
  ; i is an unsigned integer large enough to represent n
  ; k is an unsigned integer
  ; xorWith is an unsigned four-byte integer

  c = 0xffffffff
  i = 0
  while i < n begin
      c = BitwiseExclusiveOR(c, b(i))
      k = 0
      while k < 8
           if BitwiseAND(c, 1)
                xorWith = 0xedb88320
                xorWith = 0
           c = BitwiseExclusiveOR( RightShift(c), xorWith)
           k = k + 1
      i = i + 1 end
  result = BitwiseNegation(c)

  11. Appendix: Rationale

    (This appendix is not part of the formal PNG specification.)

    This appendix gives the reasoning behind some of the design decisions
    in PNG. Many of these decisions were the subject of considerable
    debate. The authors freely admit that another group might have made
    different decisions; however, we believe that our choices are
    defensible and consistent.


    Does the world really need yet another graphics format? We believe so.
    GIF is no longer freely usable, but no other commonly used format can
    directly replace it, as is discussed in more detail below. We might
    have used an adaptation of an existing format, for example GIF with an
    unpatented compression scheme. But this would require new code anyway;
    it would not be all that much easier to implement than a whole new
    file format. (PNG is deliberately designed so that it is very simple
    to implement, with the exception of the compression engine, which
    would be needed in any case.) We feel that this is an excellent
    opportunity to design a new format that fixes some of the known
    limitations of GIF.


    The features chosen for PNG are intended to address the needs of
    applications that previously used the special strengths of GIF. In
    particular, GIF is well adapted for on-line communications because of
    its streamability and progressive disclosure capability. PNG shares
    those attributes.

    We have also addressed some of the widely known shortcomings of GIF.
    In particular, PNG supports truecolor images. We know of no widely
    used image format that losslessly compresses truecolor images as
    effectively as PNG does. We hope that PNG will make use of truecolor
    images more practical and widespread.

    Some form of transparency control is desirable for applications in
    which images are displayed against a background or together with other
    images. GIF provided a simple transparent-color specification for this
    purpose. PNG supports a full alpha channel as well as
    transparent-color specifications. This allows both highly flexible
    transparency and compression efficiency.

    Robustness against transmission errors has been an important
    consideration. For example, images transferred across Internet are
    often mistakenly processed as text, leading to file corruption. PNG is
    designed so that such errors can be detected quickly and reliably.

    PNG has been expressly designed not to be completely dependent on a
    single compression technique. Although inflate/deflate compression is
    mentioned in this document, PNG would still exist without it.


    Some features have been deliberately omitted from PNG. These choices
    were made to simplify implementation of PNG, promote portability and
    interchangeability, and make the format as simple and foolproof as
    possible for users. In particular:
      * There is no uncompressed variant of PNG. This would merely create
        another case for decoders to worry about, and it would make the
        format appear more complex for users. ("Why did my 60K file
        suddenly become 300K?")
      * There is no lossy compression in PNG. Existing formats such as
        JFIF already handle lossy compression well. Furthermore, available
        lossy compression methods (eg, JPEG) are far from foolproof to use
        --- a poor choice of quality level can ruin an image. To avoid
        user confusion and unintentional loss of information, we feel it
        is best to keep lossy and lossless formats strictly separate.
        Also, lossy compression is complex to implement. Adding JPEG
        support to a PNG decoder might increase its size by an order of
        magnitude. This would certainly cause some decoders to omit
        support for the feature, which would destroy our goal of
      * There is no support for CMYK or other unusual color spaces. Again,
        this is in the name of promoting portability. CMYK, in particular,
        is far too device-dependent to be useful as a portable image
      * There is no standard chunk for thumbnail views of images. In
        discussions with software vendors who use thumbnails in their
        products, it has become clear that most would not use a "standard"
        thumbnail chunk. This is partly because every vendor has a
        distinct idea of what the dimensions and characteristics of a
        thumbnail should be, and partly because vendors who keep
        thumbnails in separate files to accommodate varied image formats
        are not going to stop doing that simply because of a thumbnail
        chunk in one new format. Proprietary chunks containing
        vendor-specific thumbnails appear to be more practical than a
        common thumbnail format.

    It is worth noting that private extensions to PNG could easily add
    these features. We will not, however, admit them as part of the basic
    PNG standard.

    Basic PNG also does not support multiple images in one file. This
    restriction is a reflection of the reality that many applications do
    not need and will not support multiple images per file. (While the GIF
    standard nominally allows multiple images per file, few applications
    actually support it.) In any case, single images are a fundamentally
    different sort of object from sequences of images. Rather than make
    false promises of interchangeability, we prefer to draw a clear
    distinction between single-image and multi-image formats.

    There is at present no provision for text employing character sets
    other than the ISO 8859-1 (Latin-1) character set. It is recognized
    that the need for other character sets will increase. However, PNG
    already requires that programmers implement a number of new and
    unfamiliar features, and text representation is not PNG's primary
    purpose. Since PNG provides for the creation and public registration
    of new ancillary chunks of general interest, it is expected that
    chunks for other character sets, such as Unicode, will be registered
    and increase gradually in popularity.


    Numerous existing formats were considered before deciding to develop
    PNG. None could meet the requirements we felt were important for PNG.

    GIF is no longer suitable as a universal standard because of legal
    entanglements. Although just replacing GIF's compression method would
    avoid that problem, GIF does not support truecolor images, alpha
    channels, or gamma correction. The spec has more subtle problems too.
    Only a small subset of the GIF89 spec is actually portable across a
    variety of implementations, but there is no codification of the most
    portable part of the spec.

    TIFF is far too complex to meet our goals of simplicity and
    interchangeability. Defining a TIFF subset would meet that objection,
    but would frustrate users making the reasonable assumption that a file
    saved as TIFF from Software XYZ would load into a program supporting
    our flavor of TIFF. Furthermore, TIFF is not designed for stream
    processing, has no provision for progressive disclosure, and does not
    currently provide any good, legally unencumbered, lossless compression

    IFF has also been suggested, but is not suitable in detail: available
    image representations are too machine-specific or not adequately
    compressed. The overall "chunk" structure of IFF is a useful concept
    which PNG has liberally borrowed from, but we did not attempt to be
    bit-for-bit compatible with IFF chunk structure. Again this is due to
    detailed issues, notably the fact that IFF FORMs are not designed to
    be serially writable.

    Lossless JPEG is not suitable because it does not provide for the
    storage of palette-color images, and because its lossless truecolor
    compression is typically inferior to that of PNG.


    It has been asked why PNG uses network byte order. We have selected
    one byte ordering and used it consistently. Which order in particular
    is of little relevance, but network byte order has the advantage that
    routines to convert to and from it are already available on any
    platform that supports TCP/IP networking, including all PC platforms.
    The functions are trivial and will be included in the reference
    implementation. (In any case, the difficulty of implementing
    compression is considerably greater than that of handling byte order.)


    Although gamma 1.0 (linear brightness response) might seem a natural
    standard, it is common for images to have a gamma of less than 1.
    There are three good reasons for this:
     1. "Gamma correction" is a standard part of all video signals. It
        makes receiver design easier, and it also reduces noise in the
        transmission of video signals, both analog and digital. Video
        cameras have a gamma of 0.45 (NTSC) or 0.36 (PAL/SECAM), so images
        obtained by frame-grabbing video already have this value of gamma.
     2. Typical CRT hardware is designed to have a gamma around 2.2, so as
        to compensate for standard video image gamma. Hence, an image
        gamma of around 0.45 enables the image to be directly displayed on
        a CRT without an extra correction step.
     3. An image gamma less than 1 allocates more of the available pixel
        codes or voltage range to darker areas of the image. This allows
        photographic-quality images to be stored in only 24 bits/pixel
        without banding artifacts in the darker areas (in most cases).
        This makes "gamma encoding" a much better way of storing digital
        images than the simpler linear encoding.

    In practice, image gamma values around 1.0 and around 0.45 are both
    widely found. Older image standards such as GIF often do not account
    for this fact, leading to widespread problems with images coming out
    too dark or too light.

    PNG expects viewers to compensate for image gamma at the time that the
    image is displayed. Another possible approach is to expect encoders to
    convert all images to a uniform gamma at encoding time. While that
    method would speed viewers slightly, it has fundamental flaws:
      * Gamma correction is inherently lossy due to roundoff error.
        Requiring conversion at encoding time thus causes irreversible
        loss. Since PNG is intended to be a lossless storage format, this
        is undesirable; we should store unmodified source data.
      * The encoder might not know the image gamma. If the decoder does
        gamma correction at viewing time, it can adjust the gamma (correct
        the displayed brightness) in response to feedback from a human
        user. The encoder has no such option.
      * Whatever "standard" gamma we settled on would be wrong for some
        displays. Hence viewers would still need gamma correction

    Since there will always be images with no gamma or an incorrect
    recorded gamma, good viewers will need to incorporate gamma correction
    logic anyway. Gamma correction at viewing time is thus the right way
    to go.


    PNG includes filtering capability because filtering can significantly
    reduce the compressed size of truecolor and grayscale images.
    Filtering is also sometimes of value on palette images, although this
    is less common.

    The filter algorithms are defined to operate on bytes, rather than
    pixels, for simplicity and speed. Tests have shown that filtering is
    ineffective for images with fewer than 8 bits per pixel. The filters
    will most often be used on 8-bit-precision data.

    A final reason for not using pixel-based filtering is that if an 8-bit
    decoder plans to discard the low order byte of 16-bit data, it can do
    so before reversing the filter, boosting decoder speed.

    The encoder is allowed to change filters for each new scanline. This
    creates no additional complexity for decoders, since a decoder is
    required to contain unfiltering logic for every filter type anyway.
    The only cost is an extra byte per scanline in the pre-compression
    data stream. Our tests showed that when the same filter is selected
    for all scanlines, this extra byte compresses away to almost nothing,
    so there is little storage cost compared to a fixed filter specified
    for the whole image. And the potential benefits of adaptive filtering
    are too great to ignore. Even with the simplistic filter-choice
    heuristics so far discovered, adaptive filtering usually outperforms
    fixed filters. In particular, an adaptive filter can change behavior
    for successive passes of an interlaced image; a fixed filter cannot.

    The basic filters offered by PNG have been chosen on both theoretical
    and experimental grounds. In particular, it is worth noting that all
    the filters (except "none" and "average") operate by encoding the
    difference between a pixel and one of its neighboring pixels. This is
    usually superior to conventional linear prediction equations because
    the prediction is certain to be one of the possible pixel values. When
    the source data is not full depth (such as 5-bit data scaled up to
    8-bit depth), this restriction ensures that the number of prediction
    delta values is no more than the number of distinct pixel values
    present in the source data. A linear equation can produce intermediate
    values not actually present in the source data, and thus reduce
    compression efficiency.


    Most graphics file formats include the ability to store some textual
    information along with the image. But many applications need more than
    that: they want to be able to store several identifiable pieces of
    text. For example, a database using PNG files to store medical X-rays
    would likely want to include patient's name, doctor's name, diagnosis,
    etc. A simple way to do this in PNG would be to invent new proprietary
    chunks holding text. The disadvantage of such an approach is that
    other applications would have no idea what was in those chunks, and
    would simply ignore them. Instead, we recommend that text information
    be stored in standard tEXt chunks with suitable keywords. Use of tEXt
    tells any PNG viewer that the chunk contains text that may be of
    interest to a human user. Thus, a person looking at the file with
    another viewer will still be able to see the text, and even understand
    what it is if the keywords are reasonably self-explanatory. (For the
    same reason, we recommend spelled-out keywords, not abbreviations that
    will be hard for a person to understand. Saving a few bytes on a
    keyword is false economy.)

    [Need rationale for specifying Latin-1, or UTF if that's what we


    The PNG signature is equivalent to (in C notation)

    \211 P N G \r \n \032 \n

    The first two bytes distinguish PNG files on systems that expect the
    first two bytes to identify the file type uniquely. The first byte is
    chosen as a non-ASCII value to reduce the probability that a text file
    may be misrecognized as a PNG file; also, it catches bad file
    transfers that zero bit 7. Bytes two through four (overlap with the
    first two intentional) name the format. The CR-LF sequence catches bad
    file transfers that alter these characters. The control-Z character
    stops file display under MSDOS. The final line feed checks for the
    inverse of the CR-LF translation problem.

    Note that there is no version number in the signature, nor indeed
    anywhere in the file. This is intentional: the chunk mechanism
    provides a better, more flexible way to handle format extensions, as
    is described below.


    The chunk design allows decoders to skip unrecognized or uninteresting
    chunks: it is simply necessary to skip the appropriate number of
    bytes, as determined from the length field.

    Limiting chunk length to (2^31)-1 bytes avoids possible problems for
    implementations that cannot conveniently handle 4-byte unsigned
    values. In practice, chunks will usually be much shorter than that

    A separate CRC is provided for each chunk in order to detect
    badly-transferred images as quickly as possible. In particular,
    critical data such as the image dimensions can be validated before
    being used. The chunk length is excluded in order to permit CRC
    calculation while data is generated (possibly before the length is
    known, in the case of variable-length chunks); this may avoid an extra
    pass over the data. Excluding the length from the CRC does not create
    any extra risk of failing to discover file corruption, since if the
    length is wrong, the CRC check will fail (the CRC will be computed on
    the wrong bytes and tested against the wrong value from the file


    The chunk naming conventions allow safe, flexible extension of the PNG
    format. This mechanism is much better than a format version number,
    because it works on a feature-by-feature basis rather than being an
    overall indicator. Decoders can process newer files if and only if the
    files use no unknown critical features (as indicated by finding
    unknown critical chunks). Unknown ancillary chunks can be safely
    ignored. Experience has shown that version numbers tend to be set
    unnecessarily high, leading to older decoders rejecting files that
    they could in fact process (this was a serious problem for several
    years after the GIF89 spec came out, for example). Furthermore,
    private extensions can be either critical or ancillary, and standard
    decoders will react appropriately; version numbers are no help for
    private extensions.

    A hypothetical chunk for vector graphics would be a critical chunk,
    since if ignored, important parts of the intended image would be
    missing. A chunk carrying the Mandelbrot set coordinates for a fractal
    image would be ancillary, since other applications could display the
    image without understanding what it was. In general, a chunk type
    should be made critical only if it is impossible to display a
    reasonable representation of the intended image without interpreting
    that chunk.

    The public/private property bit ensures that any newly defined public
    chunk types cannot conflict with proprietary chunks that may be in use
    somewhere. However, it does not protect users of private chunks from
    the possibility that someone else may re-use the same chunk name for a
    different purpose. It is a good idea to put additional identifying
    information at the start of the data for any private chunk type.

    When a PNG file is modified, certain ancillary chunks may need to be
    changed to reflect changes in other chunks. For example, a histogram
    chunk needs to be changed if the image data changes. If the encoder
    does not recognize histogram chunks, copying them blindly to a new
    output file is incorrect; such chunks should be dropped. The
    safe/unsafe property bit allows ancillary chunks to be marked

    Not all possible modification scenarios are covered by the safe/unsafe
    semantics; in particular, chunks that are dependent on the total file
    contents are not supported. (An example of such a chunk is an index of
    IDAT chunk locations within the file: adding a comment chunk would
    inadvertently break the index.) Definition of such chunks is
    discouraged. If absolutely necessary for a particular application,
    such chunks may be made critical chunks, with consequent loss of
    portability to other applications. In general, ancillary chunks may
    depend on critical chunks but not on other ancillary chunks. It is
    expected that mutually dependent information should be put into a
    single chunk.


    A viewer may not be able to provide as many colors as are listed in
    the image's palette. (For example, some colors may be reserved by a
    window system.) To produce the best results in this situation, it is
    helpful to have information on the frequency with which each palette
    index actually appears, in order to choose the best palette for
    dithering or drop the least-used colors. Since images are often
    created once and viewed many times, it makes sense to calculate this
    information in the encoder, although it is not mandatory for the
    encoder to provide it.

    The same rationale holds good for palettes which are suggested
    quantizations of truecolor images. In this situation, it is
    recommended that the histogram values represent "nearest neighbor"
    counts, that is, the approximate usage of each palette entry if no
    dithering is applied. (These counts will often be available for free
    as a consequence of developing the suggested palette.)

  12. Credits


    Thomas Boutell,


    Tom Lane,


    Authors' names are presented in alphabetical order.
      * Mark Adler,
      * Thomas Boutell,
      * Adam M. Costello,
      * Lee Daniel Crocker,
      * Oliver Fromme,
      * Jean-Loup Gailly,
      * Alex Jakulin,
      * Neal Kettler,
      * Tom Lane,
      * Dave Martindale,
      * Owen Mortenson,
      * Greg Roelofs,
      * Paul Schmidt,

    The authors wish to acknowledge the contributions of the Portable
    Network Graphics mailing list and the readers of

                          End of PNG Specification

                                //END QUOTE//



                        FRACTINT VERSION 19 RELEASED
                          GRAPHICS DEVELOPERS FORUM

      The Stone Soup Group is pleased to announce the release of Fractint
 version 19, the first major upgrade of the classic freeware DOS-based
 fractal generator in a year and a half. Fractint generates and manipulates
 dazzling graphic images created by an enormous variety variety of
 mathematical algorithms, including formulas you can type in yourself.

      Some of the new features in version 19 include Random Dot Stereogram
 generation, magnification of up to 10 to the 1600th power, browser
 functions, bailout tests, and enhanced formula and fractal type support.

      Fractint is the result of an programming effort by an international
 group of enthusiastic volunteers informally known as the "Stone Soup
 Group". The name "Stone Soup" comes from the familiar story of the
 vagabond soldier who started a pot of soup with a stone, and then inspired
 an entire village to add mouth-watering ingredients from their private
 pantries. Recent contributions to the "soup" came from Great Britain,
 Australia, Brazil, and the USA.

      The Stone Soup Group has its online home with the 'Go Graphics' Group
 on the CompuServe Information Service, currently in section 4 (Fractal
 Sources) of the Graphics Developers Forum (GO GRAPHDEV). Look for the file
 FRAINT.EXE, which is the complete Fractint package. The C and assembler
 source code is avauilable in FRASRC.EXE.

      Fractint is featured in the Waite Group Press book _Fractal Creations
 2nd Edition_ by Stone Soup programmers Tim Wegner and Bert Tyler (1994
 Waite  Group Press, ISBN # 1-878739-34-4), and the upcoming book _Image
 Lab Second Edition_ (1995 Waite Group Press.)

 For more information on graphics and your computer, GO GRFWELCOME. The
 Graphics forums are part of CompuServe's extended services.


 > THUMBS+PLUS 2.0c STR InfoFile    This IS "The REAL thing!"

                          THUMBS+PLUS VERSION 2.0C

 Announcing Thumbs+Plus version 2.0c, the only effective, elegant and
 inexpensive way to locate and organize your graphic files.  You will be
 amazed by this sleek, fast, efficient graphics browser, which includes the
 following features. Version 2.0 features are marked with a "+"; features
 added in 2.0c are marked with "++".

 o  Fast and accurate thumbnail generation -- by individual file, 
 directory or entire disk.  Disk and directory scans can be done in the
 background, allowing you to continue working.

 +  Support for many image and clip-art formats, both raster and vector,

    .BMF       Corel Gallery clip-art        .PAT      *Corel pattern files
    .BMP,.DIB  Windows or OS/2 bitmaps       .PCD       Kodak PhotoCD
    .CDR      *CorelDRAW!                    .PCX,.PCC  Zsoft PC Paintbrush
    .CGM       Computer Graphics Metafiles   .PSD    ++ Adobe Photoshop 2.5
    .CMX      *Corel Presentation Exchange   .RAS,.SUN  Sun Raster files
    .CPT       Corel PhotoPaint              .RAW       Raw Grayscale
    .EPS      *Encapsulated Postscript       .RLE       Compressed Win Bmps
    .GEM       GEM Metafiles                 .TGA,.WIN  Targa TrueVision
    .GIF       CompuServe GIFs               .TIF       Tagged Image Format
    .ICO       Windows Icon files            .TTF       TrueType fonts
    .IFF,.LBM  Amiga Images, Deluxe Paint    .WAV       Sound files
    .IMG       GEM Images                    .WMF       Windows metafiles
    .JPG       JPEG (JFIF) files             .WPG    ++ WordPerfect (v1&2)
    .MND       Mandelbrot for Windows

   * Only the preview image is accessibly directly for those types marked
 with a (*).  The complete image may be available if an OLE server for the
 type is loaded on your system.

 +  Using Aldus Rev1 graphic filters, which Thumbs+Plus can automatically
 locate on your hard disk, you may be able to handle the following formats 
 (and others)

    .DRW      Micrographx Designer/Draw      .PIC      Lotus 1-2-3 Pictures
    .DXF      AutoCAD (2-D) files            .PLT      AutoCAD Plot files
    .HGL      HP Graphics Language           .WPG      DrawPerfect graphic
    .PCT      Macintosh PICT files

 +  Using OLE, Thumbs+Plus can thumbnail and view any file for which an OLE
    server is present on your system. Some possible types include:

    .AVI      Video for Windows animation    .PPT  Power Point presentation
    .DOC      Word for Windows document      .PUB  Microsoft Publisher
    .GRA      Microsoft Graph 

 +  Multiple graphic viewing windows with file save (BMP, GIF, JPG, TGA,
 PCX TIF, WMF), print, copy, paste, crop, auto-crop, convert metafiles to
 bitmaps and more.

 +  On-the-fly gamma correction and quick dithering of 24-bit images for
 8-bit (256-color) displays.

 +  Zoom-in (2x - 9x), stretch to fit, and stretch to fit width.

 o  Enhanced solid color metafile viewing with 8-bit (256-color) drivers, 
 which eliminates that ugly dithering which Windows does by default.

 +  Image editing and conversion capabilities:
    - Color adjustment (contrast, gamma, brightness, RGB)
    - Color depth (bi-level, 4-256 color, grayscale, truecolor) with
      several palette selections and dithering options.
    - Rotate and re-size with interpolation (anti-aliasing)
    - Miscellaneous: Invert, flip vertical, flip horizontal, auto-crop,
      swap red and blue.
    - Edit or add comments to supported types (TIF, GIF, JPEG).
    - Batch (unattended, background) mode to edit and convert multiple
      files, while still using your computer for other tasks.

 +  For saving JPEG files, Thumbs+Plus provides a "loss preview" so you can
 see an indication of the difference between the original and the
 compressed file. (Requires 16- or 24-bit display.)

 +  Install and remove TrueType fonts quickly and easily  --  while looking
 at them. ++ It also shows which fonts are currently installed (by font

 +  Support for drag-and-drop from File Manager to view, drag-and-drop to
 other applications (like File Manager), and DDE support for using
 Thumbs+Plus to view files (or open Thumbs+Plus databases) from File

 o  File management capabilities, including  drag-and-drop for file
 organization, a color-coded directory tree for quickly locating
 directories with graphics, directory creation and file renaming, copying, 
 deleting and moving.

 o  Off-line (removable) device support, for cataloging floppies, CD-ROMs
 or other removable media.  The thumbnails are available even when the disk
 is not on-line -- and Thumbs+Plus can even label disks.

 o  Complete or partial catalog printing, with scaleable thumbnails, file
 captions (if desired), and user layout control.

 o  User-specified editors let you pick the editor of your choice -- by
 file type, or use the File Manager association.

 +  "Automatic Clipboard Save" provides the ability to automatically save
 clipboard contents to disk files. Thumbs+Plus saves each time the
 clipboard changes.

    - Select format (BMP, GIF, JPG, PCX, TGA).
    - Clipboard metafiles can be saved as .WMF or converted to a raster
    - Specify the desired path and file name prefix.
    - Useful for screen or window capture too (using PrintScreen and
    - Unobtrusive -- you don't have to activate the program for each

 o  A built-in Windows Wallpaper hanger (centered or tiled) for any
 supported file type, and a customizable full-screen slide show.  ++ Now
 you can remove wallpaper from the program, too.

 o  A toolbar and keyboard shortcuts for common functions.

 o  Extensive on-line help and customization of many aspects of the

 ++ Automatic (or manual, by directory tree or disk) removal of "orphaned"
 thumbnails (thumbnails for files which were moved or deleted from another

 ++ Customization of the file list, so that it can include the date and
 time or size of the files, and for sorting by date, size, extension or

 ++ Selection of files to display, or files to select, by file name mask.

 ++ Export selected thumbnails to Windows bitmap files.

 Thumbs+Plus  is  distributed  as  shareware  and  may be evaluated free of
 charge  for  up  to thirty days.  If you continue to use Thumbs+Plus after
 the  thirty  days  have  elapsed,  you  must  register.   The price for an
 individual  license is US $50.  Site and corporate licenses are available.
 Further  information  about  licensing  and  ordering  is available in the
 on-line help file.

 To obtain Thumbs+Plus version 2.0c:
 CompuServe:     THMPLS.EXE in GRAPHSUP forum, library 3 (GIF viewers)
                 THMPLS.EXE in DTPFORUM, library 6 (PC DTP Utilites)
           THMPLS.EXE in WPUSER forum, Library 16 (Presentations/Graphics)
                 THMPLS.EXE in WINFUN forum, library 9 (Graphics Utilities)
                 Also available in other forums.
 America Online: THMPLS.EXE in the Windows area
 Internet:       cerious/thmpls.exe via anonymous ftp from
 The Bounty BBS: 1-904-786-4176 Graphics Library

 Installation is simplicity itself: Just run the program and it will set up 
 and configure itself automatically.


 > WIN'95 NEWS STR FOCUS!         "..on Track for August Ship Date"

                         MICROSOFT REMAINS ON TRACK
                                 FOR WIN'95
                            AUGUST 1995 SHIP DATE

 Seattle WA -- February 18, 1995 --Forrester Research, Inc., issued a
 report on February 17, 1995 which stated Microsoft Windows 95 would not
 ship until November 1995.  This report is not accurate; Microsoft remains
 on track for an August, 1995 ship date.  More detail on the report and
 Windows 95 is attached below.

 In their report, Forrester cites several data points which are inaccurate. 
 Specifically Forrester references ISV feedback, the addition of new
 product features, and makes incorrect assumptions about Microsoft s
 desktop application product development plans.

 Microsoft would like to provide clarification on each of these points. 
 Firstly, contrary to the Forrester report, feedback from ISVs on Windows
 95 progress is quite positive.  In fact, Microsoft is in constant touch
 with ISVs and other beta testers and the feedback received is consistent
 with Microsoft s readying of the M8 Beta and Windows Preview Program
 releases for March.  Secondly, contrary to the Forrester report, Microsoft
 is focused on fixing the remaining compatibility bugs in the product and
 is not adding new features at this time.  Finally, Microsoft has not made
 any announcements regarding its desktop suite of products other than
 affirming a committment to deliver 32-bit versions of its applications
 within 90 days of the shipment of Windows 95.

 In addition, Microsoft is working closely with corporate accounts to beta
 test and rollout the Windows 95 beta releases to select departments in an
 effort to help reduce the cost of Windows 95 deployment.  Microsoft also
 continues to work with PC manufacturers to produce great Plug and Play
 machines which will be ready for the Christmas selling season.  Thus, all
 evidence and feedback Microsoft has received points to Windows 95 being
 ready for release to 400,000 testers in the form of the Windows Preview
 Program in March with final shipment in August 1995.

 Press Contacts: 
 Colleen Lacter, Karla Wachter--Waggener Edstrom, 503/245-0905



               Intel Indeo(R) Video R3.2 Update -- V3.23.01.01
                      Microsoft Video for Windows 1.1d 
                              February 22, 1994

 This software update is provided to enhance your existing Indeo(R) Video
 drivers to the latest video technology for compressing, editing and
 playing back video on your Intel microprocessor-based desktop computer,
 using Microsoft's Video for Windows* Version 1.1d. 

 Indeo Video technology gives you the capability to capture and compress
 video in a single step using Intel's Smart Video Recorder (ISVR) and ISVR
 Pro.  It also allows you to encode and decode (i.e. play back) video using
 only software on your PC.

 The ISVR Pro works with camcorders, VCRs and laser disks to capture Indeo
 Video.  It immediately compresses NTSC or PAL format files at 320x240,
 240x180, and 160x120 pixel resolutions at up to 30 frames per second

 In addition, the built-in scalability of Indeo technology automatically
 adjusts the playback frame rate depending on your computer's performance
 capabilities.  This allows you to play Indeo video files on any Intel
 Pentium(R) or Intel486(TM) processor-based computer.

 Readme.txt Topics:
   * Improvements
   * Indeo Video Drivers
   * Differences from Microsoft's VfW 1.1d Update
   * System.ini Entries
   * AVI File Editors
   * Known Operating Characteristics
   * Software Requirements
   * Optimum System Recomendation
   * Technical Support and Updates
   * Microsoft Readme.txt file for VfW 1.1d

 This version of the Indeo Video R3.2 driver is an update to Indeo Video
 R3.1 and Video for Windows V1.1d. It provides:
    * Supports the Display Control Interface (DCI).
    * Supports active palette.
    * Improved visual quality.  There is significantly more foreground 
      and background detail for most sequences, particularly at 15fps 
      with data rates of 135KB/sec or higher.
    * Improved video playback performance at low data rates.
    * Improved 16-bit image quality and playback performance.
    * Improved audio playback at low data rates.
    * Compression and decompression of images up to 640x480 size in
      4-pixel increments.  Note: 640x480x10 video with a 240KB/sec transfer 
      rate, has been measured to play back at close to 10 fps.
    * Improved software encoder performance (2 to 5 sec/frame on a Pentium 
      processor system).
    * Faster initialization.
 Improvements in V3.23.01.01 over V3.22.01.44:

 1) Less memory allocated during playback.
 2) More tolerant of errors in the video bit stream.  Not as likely to
    GPF if a bit stream error is encountered during playback.
 3) Subsampling changed to minimize color bleeding.

 Improvements in V3.22.01.44 over V3.22.01.43:

 1) Fixes a potential problem with the floating point library not being
    exited correctly while compressing a file.

 Improvements in V3.22.01.43 over V3.22.01.30:

 1) Fixes color shift when using Active Palette support.
 2) Fixes sustained palette flash when video is placed in the background.
 3) Correctly rejects AVI files with odd size images.
 4) Fixed a possible GPF when insufficient memory was available.
 5) The new Raw driver displays correctly under Adobe Premiere*.

 Indeo Video Drivers:
 Indeo(TM) Video R3.2  -- V3.23.01.01 incorporates the new Indeo 
                 Video R3.2 software codec that produces
                 the highest quality video for software
                 playback on Intel microprocessor based
                 desktop computers.
                 [filename: ir32.dll]

 Indeo(TM) Video Raw   -- V1.10.1.6 incorporates the raw/YVU9 codec.
                 [filename: iyvu9.dll]

 Indeo(TM) Video R2.1  -- V2.17.003 incorporates a decompressor only.
                 It plays back files created with the older
                 R2.1 codec.
                 [filename: ir21.dll]

 Differences from Microsoft's VfW 1.1d Update:
 The Setup utility used to install this update is a modified version of the
 Setup utility Microsoft provides with their runtime package.  It is
 possible to make further changes to this program.  The Microsoft Setup
 program used to come with V3.1 of the Windows SDK.  It is now available to
 registered users of Visual C++ by calling Microsoft Product Support.

 All of the Intel and non-Intel codecs are installed by this update. 
 Listed below are the differences between this update and the one supplied
 by Microsoft:

 1.  Installs R3.2 V3.23.01.01 driver rather than V3.22.1.43.
 2.  The Raw driver (iyvu9.dll) is updated.
 3.  A file called ir30.dll is installed.  See the following section
     for details.
 4.  The R2.1 driver is renamed to ir21.dll.
 5.  The readme.txt and copyrite.txt files are added.  This
     readme.txt file may be deleted prior to distribution.
 6.  The files in this update do not all fit on one 3.5" diskette.
 7.  The file dcisvga.drv is not installed.

 System.ini Entries:
 The Setup program installs the Indeo video drivers along with the latest
 Video for Windows runtime.  It places the following entries in the
 system.ini file for the Indeo video drivers:


 Previously, the recommended system.ini entries for Indeo video R3.1 looked
 as follows:


 Indeov.drv was an "umbrella" driver that used a text file called indeo.ini
 to point to the various Indeo video drivers.  The indeo.ini file had the
 following entries:


 Indeov.drv and indeo.ini are no longer used and may be deleted if desired.
 However, older applications, which install the Indeo video drivers, may
 still use indeov.drv and indeo.ini.  Since the name of the latest Indeo
 video driver has changed from ir30.dll to ir32.dll, this would prevent
 IV31 files from accessing the latest driver.  To avoid this problem, an
 exact copy of the latest ir32.dll file, named ir30.dll, is also installed
 by this setup program.

 It is hoped the ir30.dll file will not be used.  But if another setup
 program should change the system.ini entries to point to indeov.drv, then
 the correct driver will still be accessed through ir30.dll.  In the
 future, this precaution should not need to be taken.

 AVI File Editors:
 This is a recommendation for developers of AVI file editors.  To avoid
 unnecessary recompression, it is recommended the IV31 and IV32 video
 formats be treated as the same video format. This speeds up editing
 operations and improves video quality.  When a video editor saves an
 edited AVI file, the video formats of the source video frames are compared
 to the video format chosen for the target file.  Typically, any frames not
 in the target format are recompressed.  If a clip contains a mixture of
 IV31 and IV32 frames, and the output format is IV32, it is not necessary
 to recompress the IV31 frames.  The Indeo video R3.2 codec will play back
 both video formats.  

 Known Operating Characteristics:
  1) The new Indeo Video R3.2 driver can play back AVI files
     compressed using the older R3.0 and R3.1 drivers.  However, AVI
     files created by the R3.2 software encoder cannot be played back
     using the Indeo video R3.0 or R3.1 drivers.  Microsoft's Media
     Player will report the error "Video not available, cannot find
     'vids.iv32' decompressor."   
  2) The R2.1 driver does not display a setup dialog box from
     the Control Panel.

  3) Digital Video Arts, Ltd. has an Indeo video R3.2 driver that
     supports hardware playback.  Call 215-576-7920 to inquire about
     their NewWorld Operating Environment.

  4) The Setup utility could fail unexpectedly at the end of installation.
     If this occurs, it is usually due to low memory conditions.  Close all
     other applications before installation.
 Software Requirements:
   * Video for Windows V1.1d
   * Windows 3.1

 Optimum System Recomendation:                     
 For the highest image quality and playback, the following system 
 requirements are recommended:

    * Intel Pentium processor
    * System RAM: 12+ MB
    * PCI bus graphics controller with DCI-enabled drivers
    * SCSI or Enhanced IDE hard drive

 For best frame rate performance, put the graphics card in 8-bit
 color mode.  For best image quality, put the graphics card in
 24-bit color mode.     

 Technical Support and Updates:
 For technical assistance, post a message on the IntelArch forum of
 CompuServe in library #9.

 As new Indeo video drivers are released, they will be made available on
 CompuServe INTELARCH forum and Intel's Application Support BBS at (916)

 Updates are also available on Internet at: and at

 Microsoft Readme.txt file for VfW 1.1d:
 Dear Video for Windows Developer:

 Enclosed you will find the Video for Windows 1.1d Runtime.  This release
 includes some important enhancements requested by you, including improved
 palette support, Display Control Interface (DCI) support and overall
 improvements in performance. 

 The files that have changed are the following:
 File Name               Change Description
 AVICAP.DLL              Added application pre-roll and post-roll support.
 DVA.386                 Added DCI support.
 ICCVID.DRV              Cinepak Codec: Added palette support.
 IMAADPCM.ACM            IMA ADPCM Codec: Change in the compression
                         algorithm used in order to fully meet the
                         official format specifications.
 IR32.DLL                Indeo Codec: Updated to version 3.2, added palette
 MSVIDEO.DLL             Added palette and DCI support.
 MSVIDEO.NT              Updated the Windows NT 3.5 to support 16 bit
 OLE2DISP.DLL            Updated to current release of OLE.
 OLE2NLS.DLL             Updated to current release of OLE.
 SETUP.INF               Updated to new file sizes, versions and dates.
 STDOLE.TLB              OLE file missing from original VfW runtime.
 TYPELIB.DLL             Updated to current release of OLE.

 Palette Support
 Video for Windows has always allowed the application to select a specific 
 palette for playback on 8 bit displays.  Unfortunately, the codecs 
 (compressor\decompressors) were never aware of this palette request.  
 Instead the codecs would dither to their own standard palette.  Video for 
 Windows would then further dither the video to the requested color

 The net result was 24 bit videos, when played back with a requested
 palette, were dithered twice.  This would compromise the quality of the

 This problem has been solved with this new drop of MSVIDEO.DLL, and the 
 Cinepak and Indeo codecs.  The codecs will now decompress directly to a 
 requested palette.  You can request the codecs to use a palette with
 either the SETVIDEO <alias> PALETTE HANDLE TO <hpal>, or REALIZE <alias>
 BACKGROUND MCI commands.  You can find these commands in the Video for
 Windows 1.1 documentation.

 DCI Support
 DCI allows Video for Windows to take advantage of the enhanced
 capabilities of your display cards. Video for Windows will support all
 DCI-enabled display adapters.  Furthermore, the performance of stretched
 and clipped videos will be drastically improved for all displays.

 For further information on API changes, please see the "New Performance 
 APIs" listed in the DEV_KIT.TXT of the Video for Windows SDK.  This SDK is 
 available from the Fall '94 addition of the MSDN Level II. 


 The Video for Windows Team

 * Other brands and names are the property of their respective owners.



                          SPEED DEMON & POWERHOUSE
                               ZEOS PANTERA-90

 Here are the specs:

 Overview and Features

 Product Overview
 The Coral-Max is a highly integrated baby-AT form factor system

 Using one Pentium-90 interstitial ZIF sockets, it offers an upgrade path
 from a single processor Pentium On board voltage regulation is provided to
 allow CPUs of other  voltages than 3.3V to be used. Alternativly this
 allows a supply without 3.3V to power the board. The board features three
 PCI local bus master slots.

 Integrated features include two local-bus IDE ports, FLASH BIOS, floppy
 controller, two enhanced high-speed serial ports, one enhanced parallel
 port, 16-bit games-compatible audio, and optional local-bus Ethernet
 and/or SCSI ports.. The system secondary cache is optionally upgradable to
 256K or 512K.

 Main memory uses standard 32 or 36 bit SIMMs and may be as much as 384MB.


   Processor Type............. Intel Pentium-75/90/100 (aka P54C)
   Chipset.................... Intel 'Neptune' chipset
   System Speed............... 90MHz, 100MHz
   Expansion Interface........ ISA Bus w/ 3 PCI local bus slots

   Memory Type................ 1, 2, 4,16, 32MB X36 or X32 SIMMS
   Memory Speed............... 50ns,60ns,70ns
   Configurations............. 2,4,6,8,10,12,16,32,64,128,192,384MB, etc.
     Min. Capacity............ 2MB
     Max. Capacity............ 384MB

 System Cache
  Cache Memory Type........... 256KB or 512KB SIMM, Burst or Async.
  Mapping..................... Direct-mapped
  Write Policy................ Write-back
  Configurations.............. 0KB, 256KB, 512KB
  Standard Capacity........... 0KB
  Min. Capacity............... 0KB
  Max. Capacity............... 512KB

 I/O Bus
  Bus Configuration........... 5 ISA, 3 PCI Local Bus (One slot is shared)
  I/O BUS Speed............... 7.5Mhz for 90Mhz; 8.25Mhz for 100Mhz systems
  I/O Transfer Rate........... Up to 33MB/s
  PCI Bus..................... Up to 132MB/s(l00Mhz), 120MB/s(90Mhz)

 I/O Interfaces
  I/O Chipset................. NCR82C742 (Machete)
  Serial Ports................ Two, one D69, one DB25
  Serial Uart Type............ 16550
  Parallel Ports.............. One, Bidirectional port on DB25 connector.
                               Port configurable to uni-direction via
  Floppy...................... Control two drives: 360 Kbytes, 1.2 Mbytes,
                               720 Kbytes, 1.44 Mbytes, 2.88Mbytes.
  IDE......................... PC Tech RZ1000 PCI Bus IDE controller with
                               support for four IDE type drives thru two
  SCSI option................. AMD Am53C974 on PCI bus
  Network option.............. AMD Am79C970 on PCI bus
  SCSI/Network option......... AMD Am79C974 on PCI bus

  BIOS Subsystem
  BIOS Type................... FLASH,lMb
  BIOS Vendor................. Phoenix Technologies, Ltd.
  BIOS Features............... Built-in SETUP, Power-on self-test(POST)
                               diagnostics. Drive table with four user
                               definable drives.  Auto-Configuring I/O. ISA
  ROM shadowing............... System and Video ROM shadowing

 Operating Environment
  Power Consumption........... Typical 25 Watt(dependent on CPU and memory)
  Air Flow.................... [TBA]
  Temperature................. 0 degrees C to 40 degrees C
  Humidity.................... Up to 1 00% non-condensing

  Additional Features
  Audio option................ On-board Windows compatible 16-bit games
                               compatible audio solution using ESS1488
                               CODEC.  ADPCM compression supported. DMA and
                               IRQs are programmable.
  Connectors.................. Reset switch, Keyboard lock with power LED,
                               Speaker, 2 Serial headers/cables with DB9
                               and DB25 connector, Parallel header/cable
                               with DB25 connector, two IDE headers, Floppy
                               header, SCSI header, ethernet AUI and
                               0Base-T headers, and audio header.

 Electrical/Component Restrictions
 Motherboard mounting holes will conform to standard baby-at footprint.
 System board uses a logical layout which allows for easy option upgrade
 and assembly.

  Mfg. PN         Description            Vendor Qty/Asy
  82434NX         Chipset-PCMC           Intel   1
  82433NX         Chipset-LBX            Intel   1
  82378ZB         Chipset-SIO            Intel   1
  82379IB         Chipset-SIO.A          Intel   1 (optional, for dual CPU)
  ESS1488         Audio CODEC            ESS     1 (optional)
  CELP2X80SC3Z48  Cache Connector        Burndy  1

 Configurable options
  512K Synchronous Cache Option
  Mfg. PN         Description            Vendor Qty/Asy
  IDT7MP6182S9M   512K Cache Module      IDT     1

 256K Synchronous Cache Option
  IDT7MP6181S9M   256K Cache Module      IDT     1

  256K Asynchronous Cache Option
  Mfg. PN         Description            Vendor Qty/Asy
  IDT7MPV6179Sl7M 256K Cache Module      IDT     1
  AS7M64P3256-15C 256K Cache Module      Alliance1

 512K Asynchronous Cache Option
  Mfg. PN         Description            Vendor Qty/Asy
  IDT7MPV6180S17M 1M Cache Module        IDT     1 Note: Only 512K useable
  AS7M64P3256-15C 1M Cache Module        Alliance1

 SCSI Option
  Mfg. PN         Description            Vendor Qty/Asy
  Am53C974        SCSI Controller        AMD     1

 Network Option
  Mfg. PN         Description            Vendor Qty/Asy
  Am79C970        Ethernet Controller    AMD     1
  ACT2T-01        10Base-2/T Adapter CardHalo 1 -OR-
  ACT5T-01        10Base-5/T Adapter CardHalo 1

 SCSI/Network Option
  Mfg. PN         Description            Vendor Qty/Asy
  Am53C970        SCSI/Network ControllerAMD     1
  ACT2T-01        10Base-2/T Adapter CardHalo    1 -OR-
  ACT5T-01        10Base-5/T Adapter CardHalo    1

  The system uses from two to six high speed x36 or x32 based simms. The
  minimal amount of memory that can be installed is 2MB. Modules must
  ALWAYS be installed as pairs. The system is capable of using both page,
  interleaved and page-interleaved memory schemes depending on the amount
  of system memory installed.

  The system is memory is upgradable to 2MB, 4MB, 8MB, 10MB, 12MB, 24MB,
  32MB, 64MB, 128MB, 192MB, 256MB and 384MB of memory.  The following chart
  shows some of the many available memory configurations.

  Memory Size  How     Memory Scheme

  2MB   2-1MB simm    Page
  4MB   2-2MB simms   Page/interleaved
  8MB   2-4MB simms   Page/interleaved
  10MB  2-4MB, 1-2MB simm Page/Interleaved
  12MB  6-2MB simms   Page/Interleaved
  16MB  4-2MB simms   Page/Intedeaved
  24MB  6-4MB simms   Page/Interleaved
  32MB  4-8MB simms   Page/Interleaved
  64MB  4-16MB simms  Page/interleaved
  128MB 4-32MB simms  Page/Interleaved
  256MB 4-64MB simms  Page/interleaved
  384MB 6-64MB simms  Page/Interleaved

  Other possibilities exist which are not shown.

  ROM Shadowing
  System BIOS and Video shadowing options can be enabled and disabled via
  system setup.

  The Base system cache is 0K. The cache is upgradable to 256K and 512K of
  cache via a single industry-standard cache SIMM. The cache controller is
  integrated into the system chipset.

  Mapping..................... Direct-mapped
  Write Policy................ Write-back
  Configurations.............. 256KB,512KB
  Standard Capacity........... 0KB
  Min. Capacity............... 0KB
  Max Capacity................ 512KB
  Cache memory type........... Cache SIMM, Synchronous or Asynch.
  Cache memory Speed.......... 9ns Burst /15ns Async.
  Cache memory Part number.... IDT7MPV6179/80/81/82

  The BIOS is Phoenix Technologies based code customized for this design.
  The base code is called 'NuBIOS'. Refer to ZEOS PCI Product BIOS
  Specification document for complete BIOS details.

  Reset Switch
  A connect for an external reset is implemented on the system board.
  Activation of this switch will cause the CPU to perform a system reset.

 Turbo Mode
  Keyboard selectable turbo/slow mode switch is provided. Activation of 
  this switch will cause the system performance to decrease. While the
  processor speed is not affected, the decrease in performance will provide
  an acceptable means of executing application that are CPU speed

 LED Indicators
  Connectors for LEDs are to provide to indicate the following conditions:
  power on, low-power mode and IDE disk activity. No indication is given
  for SCSI activity.

 Serial Port
  Two 16550 compatible serial ports are integrated into the system board.
  The system board headers will accommodate one DB9 and one D625. Pins out
  of serial port headers are consistent with Cobra/Rattler/Gosling/Martin
  board serial port headers.

 Parallel Port
  The parallel port is a bidirectional, Centronics-compatible 25-pin
  parallel port. In setup, the user can select the system to boot with the
  port in uni- or bidirectional modes. The port defaults to bidirectional.

  Built in BIOS level password is provided. An optional hardware keyboard
  lock may be implemented.

   Operation.................. 5C to 35C
   Storage/Transportation..... 20C to 60C
   Operation.................. 20%RH to 80%RH
   Storage/Transportation..... 10%RH to 90%RH

         A T T E N T I O N -- A T T E N T I O N -- A T T E N T I O N


 For  a  limited time only; If you wish to have a FREE sample printout sent
 to  you  that  demonstrates  FARGO  Primera & Primera Pro SUPERIOR QUALITY
 600dpi  24  bit Photo Realistic Color Output, please send a Self Addressed
 Stamped Envelope [SASE] (business sized envelope please) to:

                       STReport's Fargo Printout Offer
                                P.O. Box 6672
                      Jacksonville, Florida 32205-6155

 Folks, the FARGO Primera Pro has GOT to be the best yet.  Its far superior
 to the newest of Color Laser Printers selling for more than three times as
 much.  Its said that ONE Picture is worth a thousand words.  Send for this
 sample now.  Guaranteed you will be amazed at the superb quality. (please,
 allow at least a one week turn-around)

         A T T E N T I O N -- A T T E N T I O N -- A T T E N T I O N

                     :HOW TO GET YOUR OWN GENIE ACCOUNT:

       Set your communications software to Half Duplex (or Local Echo)
                      Call: (with modem) 800-638-8369.
                Upon connection type HHH (RETURN after that).
                          Wait for the U#= prompt.

                  Type: XTX99587,CPUREPT then, hit RETURN.

       GENIE Information Services copyright   1995 by General Electric
             Information Services/GENIE, reprinted by permission

        ___   ___    _____     _______
       /___| /___|  /_____|  /_______/           The Macintosh RoundTable
      /____|/____| /__/|__| /__/                 ________________________
   /__/ |___/ |__|_/   |__|_/____                  Managed by SyndiComm
  /__/  |__/  |__|/    |__|______/

          An Official Forum of the International Computer Users Group
                    *** STReport available in MAC RT ***
                                 ASCII TEXT
                            for ALL GENIE users!

                           MAC/APPLE SECTION (II)
                         John Deegan, Editor (Temp)



                      ON-LINE SEMINAR -=- May 01, 1995

 IT'S COMING . . .   May 1, 1995
 What is It?         An Entirely New, More Effective and More
                     Efficient Form of Professional Education

 What's It Called?   Computer Crime and Countermeasures.  
                     It's professional education
                     delivered by the National Computer
                     Security Association (NCSA) Forum on
                     CompuServe (GO NCSAEDU).

 How Long Will It Last?   30 Days

 What's the Topic?   Preventing damage to information technology
                     by understanding and countering common techniques
                     of computer crime.

 Who's the Teacher?  M. E. Kabay, Ph.D., Director of Education of the NCSA.

 Who Is It For ?

    - Security Managers
    - Online and MIS Professionals
    - Office Managers
    - Microcomputer, LAN, WAN Administrators

 What Will I Learn About ?

    - Definitions of the Information Technology Security Mission
    - Extent and sources of damage to I.T. systems
    - Risk management
    - Sabotage
    - Impersonation
    - Spoofs
    - Data diddling
    - Superzapping
    - Scavenging
    - Wiretapping
    - Data Leakage
    - Logic bombs
    - Trap doors
    - Trojan horse programs
    - Salami attacks
    - Forgery and counterfeits
    - Viruses
    - Anti-virus technology

 Why Learn About That ?
    => Information drives modern organizations of all kinds
    => Information in the wrong hands can ruin your effectiveness
    => Damaged data cause disastrous decisions
    => Missing data cause delays
    => Stolen data damage competitiveness
    => Computer crime is a growing problem
    => Countermeasures are not difficult to implement

 Why on-line         *  No Travel
 professional        *  No Time Away from Home/Office
 education?          *  No Schedule Conflicts
                     *  Interactive Discussion for 30-days
                     *  Rich Learning Environment
                     *  Ample Opportunity for Questions
                        from the Floor
                     *  Accessible 24 hours a day;
                        participate from home, while you
                        are on the road, from anywhere!

 How will the seminar work?

 An exclusive discussion group will be opened as a private section of the
 NCSA Security Vendor Forum (GO NCSAEDU) on CompuServe.  The seminar will
 run for 30 days.  On each weekday during that period, the instructor will
 post new material for all participants to consider.  Then (at any time
 that is convenient) each participant will retrieve the material using
 their computer.

 Each major topic of discussion will be maintained as a unique "thread".

 Participants may next post questions or comments in the discussion group.
 Dr Kabay will respond to questions and facilitate debate among the

 As this process proceeds, there will likely be several issues under
 discussion at any particular time.  Wright will keep the discussion
 organized so you can easily follow it.  If parts do not interest you, you
 can ignore them.  If you are out of touch for a day, or two, or even a
 week, you will not miss what happened during that time.  None of the core
 material or discussion will be deleted until the end of the seminar. 
 Questions about any issue in the curriculum may be raised and discussed
 at any time -- even if the core material has moved on to other issues.

 To keep the seminar moving through the many topics in the curriculum, the
 instructor will post new material each business day.  Even if there are no
 questions and no debate from participants (highly unlikely), the core
 material Kabay brings to the seminar will give you a solid grounding in
 the law of electronic commerce.

 Seminar Instructions
 The instructor will send private EMail to all students prior to the start
 of the course to provide last minute instructions.

 Meet Your Instructor- Michel E. Kabay, Ph.D.
 Dr. Kabay has specialized in consulting and training for systems
 performance, systems operations, and systems security.  He is Director of
 Education for the National Computer Security Association in the U.S.  and
 is security columnist for Network World, Computing Canada and INTERACT

 He teaches Information Security, Current Technology, and Security in the
 John Abbott College Programmers' Course.  In addition, he teaches The Art
 of Technical Support in the John Abbott program in Technical Support and
 is the instructor for the Information Technology Security course at the
 Institute for Government Informatics Professionals under the aegis of the
 University of Ottawa.

 Dr Kabay has published over 150 technical papers and is completing a
 college textbook Enterprise Systems Security for publication in late 1995. 
 He won the Best Paper Award at the 16th National Computer Security
 Conference in 1993 for his submission, "Social Psychology and INFOSEC:
 Psycho-social Factors in the Implementation of Information Security
 Policy." He was the Program Chair for the Second International Conference
 on Information Warfare in Montreal, 18-19 January 1995.

 Dr Kabay earned his M.Sc. (McGill, 1972) in Teratology, the study of
 developmental malformations.  In 1976, he received his Ph.D. in applied
 statistics and invertebrate zoology.  Until 1979, he was a university
 professor in applied statistics.

 Kabay joined the Montreal practice of LGS Group Inc., a multinational
 information technology consulting firm, in January 1995 as a Management
 Consultant specializing in operations and security.

 Views expressed in the seminar are those of the individuals expressing
 them and not necessarily those of sponsors, employers or anyone else.

 Ways to Register
 FAX:       717-243-8642
 CALL:      717-258-1816

 MAIL:       NCSA
             10 S. Courthouse Ave.
             Carlisle, PA  17013

 Covers your access to a private section of NCSAs CompuServe forum, which
 is accessed via GO NCSAEDU.  You pay for your regular on-line charges for
 using CompuServe unless you have elected the "usage free" plan.  You can
 keep on-line charges to a minimum by reading material and composing
 responses off-line.

 CompuServe Membership
 To obtain a free introductory CompuServe membership, courtesy of NCSA,
 call 800-848-8199 and ask for Representative 433.  If you plan to use
 CompuServe and are not presently a subscriber, be sure to allow several
 weeks for CompuServe to process your application.

 Group Discounts and Repostings:
 Group discounts are available if your organization brings two or more
 people to the seminar.  Your organization can -- indirectly -- send many
 people to the seminar by reposting the seminar content on an internal
 corporate bulletin board (access to which is restricted) or by
 redistributing content via private e-mail.

 Your organization must pay for all of the people within your organization
 who will view the seminar content.

 If you have a group discount, your organization must access the seminar
 through at least one account on CompuServe.  Your organization would be
 responsible for delivering the content of the seminar to people who are
 not on CompuServe and for posting questions from those people in the forum
 on CompuServe.

 Cancellation Policy:
 After you have registered for the seminar, you may cancel under these
 terms: $35 fee charged if cancellation is received by NCSA before seminar
 starts. Full amount charged if cancellation is made on the day of the
 course or if the student is a no-show.  Substitutions are accepted.

 Late Registrations
 Late registrations will be accepted for each date.  You can register and
 start a course as much as two weeks after it starts.  All of the material
 will be waiting for you.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

                       REGISTRATION FORM

 Phone_________________________  Fax_____________________________

 Email Address___________________________________________________


 Choose Date :  o  May 1, 1995

 Choose Plan:   o  $395 + normal CompuServe usage charges
                o  $450   CompuServe usage charges suspended
                          within the NCSAFORUM during seminar.
                          You remain responsible for obtaining a
                          CompuServe account and for paying for all
                          fees and connect charges outside of the

 Group Discount

       2 people   $ 690
       3           1035
       4           1295
       5           1545
     $220 for each additional person from 6 through 9
     $150 for each additional person from 10 through 19
     $100 for each additional person from 20 and up

                                    $_____________ TOTAL DUE

 Method of Payment:

   o Check Enclosed     o AMEX     o VISA     o MasterCard

 #________________________________________Exp Date__________

 Caution: It is not recommended that you send credit card
 information via the InterNet.


   ___  CompuServe:       Forum Name: _______________________________

   ___  World Wide Web    Home Page:  _______________________________

   ___  InterNet:         NewsGroup:  _______________________________

   ___  Press Announcement: Magazine: _______________________________

   ___  NCSA Mailing 

   ___  OTHER (Please explain):

 I'd like more information:

 Please send me : o NCSA Membership Information 
                  o InfoSecurity Resource Catalog

 NCSA, 10 South Courthouse Ave., Carlisle, PA 17013
    Phone : 717-258-1816     Fax : 717-243-8642



                              IMPORTANT NOTICE!

 STReport International OnLine Magazine is available every week for your
 reading pleasure on DELPHI.  STReport's readers are invited to join DELPHI
 and become a part of an extremely friendly community of enthusiastic
 computer users there.

                           SIGNING UP WITH DELPHI

        Using a personal computer and modem, members worldwide access
                   DELPHI services via a local phone call

                                JOIN --DELPHI

                 Via modem, dial up DELPHI at 1-800-695-4002
                 When connected, press RETURN once or twice
                At Password: type STREPORT and press RETURN.

                       DELPHI's 20/20 Advantage Plan 
                           20 Hours for Only $20!

 Advantage Members have always enjoyed the lowest DELPHI access rates
 available. On the new 20/20 Advantage Plan, members receive their first 20
 hours of access each month for only $20. If you happen to meet someone
 OnLine or find some other diversion, don't worry because additional usage
 is only $1.80 per hour.

 20/20 Advantage rates apply for access via SprintNet or Tymnet from within
 the continental United States during home time or via direct dial around
 the clock. Home Time is from 6pm to 6am weekdays. Access during business
 time carries a surcharge of $9 per hour. These rates apply for most
 services, but note that there are some surcharged areas on DELPHI which
 are clearly marked with a "$" sign.

 Who is eligible to take advantage of the plan?  Any DELPHI member in good
 standing.  Applications are reviewed and subject to approval by Delphi
 Internet Services Corporation.

 It's easy to join. If you meet the eligibility requirements, you can apply
 OnLine -- at any time -- for membership in the DELPHI 20/20 Advantage
 Plan. Your membership becomes active at 4 a.m. Eastern Time on the first
 billing day of the following month. 

 The $20 charge will be billed to you at the beginning of the month to
 which it applies. Any portion of the 20 hours not used in any month does
 not carry forward into the next month. 

      Advantage rates may be changed with 30 days notice given OnLine.

                         TRY DELPHI FOR $1 AN HOUR!

 For a limited time, you can become a trial member of DELPHI, and receive 5
 hours of evening and weekend access during this month for only  $5.  If
 you're not satisfied, simply cancel your account before the end of the
 calendar month with no further obligation. If you keep your account
 active, you will automatically be enrolled in DELPHI's 10/4 Basic Plan,
 where you can use up to 4 weekend and evening hours a month for a minimum
 $10 monthly charge, with additional hours available at $3.96. But hurry,
 this special trial offer will expire soon! To take advantage of this
 limited offer, use your modem to dial 1-800-365-4636.  Press <RET> once or
 twice. When you get the Password: prompt, type IP26 and press <RET> again.
 Then, just answer the questions and within a day or two, you'll officially
 be a member of DELPHI!  

         DELPHI-It's the BEST Value and getting BETTER all the time!

                -* ANNOUNCING: DELPHI INTERNET JET v2.009 *-
 Windows-based  graphic interface for the otherwise text-only Delphi online
 service.    In  addition  to  providing the user with a graphic interface,
 Delphi  Internet  Jet  can  be  configured  to automatically gather Delphi
 Internet  e-mail  and forum messages, and place them into a QWK packet for
 the  user's  existing  QWK  mail reader!  Complete instructions for setup,
 operation,  Delphi  membership, and a FREE five hour trial included in the


                           ATARI/JAG SECTION (III)
                            Dana Jacobson, Editor

 > From the Atari Editor's Desk              "Saying it like it is!"

      Spring is near, or should be real soon.  There's something about
 this month that makes one want to get through it quickly so the warm
 temperatures of April get here.  I think we should skip this month;
 it's boring!

      Atari shows are picking up again, next month, north of the border
 this time.  The folks at TAF are putting the finishing touches on their
 show; and it looks to be a terrific one (see details below).  I wish
 that it were going to be a little closer; and I'd like to have a little
 extra cash to afford to go.  Alas, it doesn't appear that either will
 happen!  We're looking forward to hearing the reports from this show in
 a few weeks.

      Well, let's get on with the show - I'm rather speechless this
 week, for some strange reason.

      Until next time...


 > DMC NewsWire STR InfoFile                  Line Art, version 1.5


  March 2, 1995                         For further information, contact:

  Toronto, Ontario, Canada              Nathan Potechin - President
                                        DMC Publishing
    DMC announces Line Art 1.5          Tel: (905) 479-1880
    for Calamus SL                      Fax: (905) 479-1882
    **************                      Compuserve: 76004,2246
                                        Delphi/GEnie: DMCPUBLISH
 DMC, who bring you Calamus SL, the    Internet: DMCPUBLISH@GENIE.GEIS.COM
 premier desktop publishing program
 on the Atari computer, is pleased to announce an upgrade to a most
 valued member of the Calamus family, Line Art. Line Art, version 1.5, is
 now available.
 The Line Art module is an advanced vector editing tool that
 combines features found in both the Vector Graphic module and Outline Art
 3.0, and then some. The Line Art module is the definitive tool for
 creating and editing vector graphics without leaving Calamus SL.

 Line Art features the creation of graphic primitives, blends, text
 objects, paths and transformation nets which allow the distortion of
 objects using these nets. Vector objects can be created by using either
 the included vector editor or one of the Calamus primitives.

 New primitives include: lines, outlines and circular segments. The
 vector objects can also be defined using a variety of writing modes which
 include outline on/off, fill on/off, and EOR for intersecting paths. You
 can also define corners as either bevelled or sharp. Objects can also be
 defined as color blends, allowing the transformation and rotation of
 these objects by using the functions in the blends command area.

 The types of blends include horizontal, vertical, rectangular corner
 origin blend, circular and transformational blend with starting and
 ending angles as well as starting and ending colors (as well as a
 definable transition color). Text can be made to follow paths inside or
 outside and to include/exclude the kerning values in the font or allow
 manual adjustment of the character spacing. You may also justify text
 left, right or center and change the text direction. The text may then be
 converted to a path object for further manipulation.

 New Features now available in Line Art, Version 1.5

 Line Art, version 1.5, contains a number of new features that should
 excite our Calamus SL customers; the new Toolbox type alignment
 functions, for use in both creation and editing of vector objects, is one
 example. Line Art's new Toolbox command group includes relative
 positioning in both absolute and relative measurement options and more.

 The gradient fill section has been improved in both speed and
 functionality. In terms of features you can now change the angle of
 gradient fill with real time preview for any of FOUR gradient types:
 circular, rectangular, linear and the new conical style.

 Here is a partial list of the new features in Line Art 1.5:

 1.  Any objects, text paths or groups can now be filled with a
     gradient. The gradients can be viewed as new fill patterns.

 2.  New options for gradients: angle of gradient, offset of the start
     and end, and position of the gradient in the vector object.

 3.  Conical gradient pattern added to linear, circular and rectangular.

 4.  You can also move the origin point on either X or Y axis. For
     linear gradients, you can move the left or right edge IN or OUT of
     the object. This is like "windowing" the gradient pattern.

 5.  For the radial gradients, the center of the gradient can be moved
     anywhere on the X or Y axis. The same is true for the conical

 6.  Uniframes, i.e.; StarScreened frames, can now be used inside vector

 7.  Exact placement with enhanced Toolbox options plus the ability to
     move objects forward and backward.

 8.  Objects can be automatically sized to the same width or height.

 9.  Objects can be sorted and placed with even horizontal or vertical

 10. Objects can be placed along a selected path.

 11. All Toolbox functions have UNDO.

 12. The object alignment functions are straightforward: Edge Alignment,
     Center Alignment plus relative positioning (object to object).

 13. The new functions include instant matching of height or width for one
     or more objects. You can also Distribute Objects Horizontally or
     Vertically with a group of three or more objects.

 The Line Art Module costs US $150.00, $210.00 Cdn. For those of you
 that already own Line Art, version 1.0, upgrade to version
 1.5, for US $50.00, $70.00 Cdn. Place your order today.

 Note: You must have the latest version of Calamus SL (Oct. 94) in order
       to use this or any other new module.


  March 2, 1995                         For further information, contact:

  Toronto, Ontario, Canada              Nathan Potechin - President
                                        DMC Publishing
    DMC announces the PhotoFX           Tel: (905) 479-1880
    Module for Calamus SL               Fax: (905) 479-1882
    *********************               Compuserve: 76004,2246
                                        Delphi/GEnie: DMCPUBLISH
  DMC, who bring you Calamus SL, the    Internet: DMCPUBLISH@GENIE.GEIS.COM
  premier desktop publishing program
  on the Atari computer, is pleased to announce a new member in the family.
  The newest addition to the Calamus SL family of modules, PhotoFX is now
  This new module allows you to apply special effect filters to images
  from within Calamus. Four filters, for use in the Calamus PhotoFX Module,
  come standard; Sharpen/Blur, Effect, Emboss and Generic (Matrix).

  Sharpen/Blur allows you to increase the detail or to Blur the currently
  selected image.

  The Effects filter creates a variety of special effects such as
  texturise, exposure and image streaking. The effects will vary depending
  on the image.

  The Emboss module will create an emboss affect on any image.

  The Generic Matrix filter is based on a user definable mathematical
  matrix that allows you to define your own filters. It is quite powerful
  and allows an enormous amount of possibilities. Six Matrix filters are

  Sample images with some PhotoFX's applied to them, have been uploaded to
  a few of the main bulletin boards.

  Your cost for the new PhotoFX Module for Calamus SL is US $50.00,
  $70.00 Cdn.

  Note: You must have the latest version of Calamus SL (Oct. 94) to use
        this or any other new module.

 > TAF Show Update! STR AtariFest InfoFile!  -  ACE '95 Is Almost Here!

                 **** SPECIAL VISITORS INFORMATION ****
                             JAGUAR ALERT!!
         _/_/        _/_/_/_/       _/_/_/_/_/ 
        _/_/     _/_/_/_/_/_/    _/_/_/_/_/_/    Software Demos! 
       _/_/     _/_/    _/_/    _/_/            Hardware Demos!
      _/_/     _/_/_/_/_/_/    _/_/_/_/_/      Membership!
     _/_/     _/_/_/_/_/_/    _/_/_/_/_/      Phoenix Newsletter!
    _/_/     _/_/    _/_/    _/_/            16/32 Bit Library!
   _/_/     _/_/    _/_/    _/_/            Monthly Meetings!
  _/_/       _/    _/_/      _/            Flea Market!
   _/                                     Seminars!
                                         Raffles! BBS!
      #*#*#*#*#*#*#*#*#*#*#*#           Support! GRAPHICS!
    Official Sponsor of ACE'95!        SPREADSHEETS! DATABASES!
      #*#*#*#*#*#*#*#*#*#*#*#         DESKTOP PUBLISHING!
                                     TELECOMMUNICATIONS! MIDI!
                                    WORDPROCESSING! MUCH MORE!
               ~~~ THE TORONTO ATARI FEDERATION ~~~
            Largest Atari User Group in North America!
   ~~~ (416) CALL-TAF (225-5823) For Recorded Information ~~~
             ~~~  TAF Online BBS (416) 421-8999  ~~~
        ~~~ CALL 416-752-2744 For ACE'95 Information ~~~
      ACE '95   ***      IS ONLY 4 WEEKS AWAY     ***   ACE '95
                           JAGUAR ALERT!!
 FEATURE EXHIBITOR > Oregon Research Associates of Tigard Oregon
                     Bob Luneski and company are the culprits 
                     responsible for such pieces of genius as 
                     Diamond Back 3 & Diamond Edge - probably the 
                     two most popular and well known items in the
                     Atari market, for Hard Drive maintenance! 
                     And as if that isn't enough, Bob is also the 
                     man who persevered to bring us Papyrus, the 
                     entire HiSoft line of software, a slew of 
                     topnotch MIDI & Video software (Breakthru, 
                     VideoMaster and more!), in addition to his 
                     long-standing reputation for support and 
                     customer service. ACE'95 will be the best 
                     chance many of us will ever have to talk to 
                     'The Man' himself! Do it! Come to ACE'95 and 
                     look for the sign in Booth #6 that says, 
                     'Genius At Work!'
 ACE'95 Visitors and Exhibitors will be treated to all that 
 Toronto has to offer (and it's a *LOT*!). Everyone will be also 
 be treated to an Exhibition taking place in a really bright, 
 modern, intimate venue. As a matter of fact, once you arrive at
 the North York Civic Center you've got the run of a fine complex:
 Shopping, Restaurants, Subway (did you know you can visit most of
 downtown Toronto without ever going outside? It'll take you 
 about a week to see everything, mind you; Toronto is a *big* 
 place!), Theatres ... and of course MEMORIAL HALL & ACE'95!!
 FEATURE EXHIBITOR > Branch Always Software of Bellevue, Washington
                     GEMulator has saved lives! It is a little 
                     known fact ... but it's true! Far too many 
                     people have spent hour after agonizing hour, 
                     toiling away over a balky DOS box, and then 
                     found euphoric surcease (just in the nick of 
                     time, naturally!), by booting TOS from good 
                     old GEMulator. Hmmm ... GEMulator may have 
                     been 'around' for awhile, but it sure as 
                     heck isn't 'old'! As a matter of fact, 
                     GEMulator 4 will be at ACE'95 in all its 
                     hi-speed glory. Darek Mihocka will be 
                     on-hand of course (Booth #17), and he'll be 
                     providing expert advice on taming the Intel 
                     beast with a little Motorola horse sense!
 The *GREATEST*ATARI*EXHIBITION*IN*YEARS* is happening on April 
 1st & 2nd, 1995, in TORONTO!! The ACE '95 Exhibitors List is 
 impressive ... and there are still MORE to come!!
 LLLL Gribnif Software!
 LLLLL TOAD Computers!
 LLLLLL Branch Always Software!
 LLLLLLL Cybercube Research (Cyrel)!
 LLLLLLLL DMC Publishing!
 LLLLLLLLL Scarborough Computers!
 LLLLLLLLLL Missionware Software!
 LLLLLLLLLLL ICD INC/4Play/Black Cat Designs!
 LLLLLLLLLLLL It's All Relative!
 LLLLLLLLLLLLLL Esquimalt Digital Logic (OMEN)!
 LLLLLLLLLLLLLLL GEnie Information Services!
 LLLLLLLLLLLLLLLL Suzy B's Software (& CDs)!
 LLLLLLLLLLLLLLLLLLL Schauzmoll Software (The first GUI BBS)!
 LLLLLLLLLLLLLLLLLLLLL Oregon Research Associates!
 LLLLLLLLLLLLLLLLLLLLLL Computer Direct! (DirecTT030 & an 
 LLLLLLLLLLLLLLLLLLLLLLL enormous lineup of Atari products!)
 LLLLLLLLLLLLLLLLLLLLL Fine Tooned Engineering (MIO2, Sweet 16)
 LLLLLLLLLLLLLLLLLLLL Compuworld (Service, Parts, Upgrades!)
 LLLLLLLLLLLLLLLLLLL Encore Music (Falcon MIDI systems!)
 LLLLLLLLLLLLLLLLLL Wizztronics (The Falcon Rack, Barracuda!)
 LLLLLLLLLLLLLLLLL Steinberg/Jones (everybody knows what they do!)
 *******                         or    
 FEATURE EXHIBITOR > Clear Thinking of Ann Arbor, Michigan
                     Who is Craig Harvey? I mean really? He 
                     programs this little text editor called 
                     Edit Plus. It's only claims to fame are that 
                     it is probably in use on half the Atari 
                     computers in North America, and that it is a 
                     fascinating, complex, intuitive and *useful* 
                     text editor. Every time you look at Edit 
                     Plus, it seems to reveal yet another handy 
                     feature! Craig has an encyclopedic knowledge 
                     of his superb software, and he will sell it 
                     to you, teach it to you and support it for 
                     you. All you have to do is walk up to him 
                     (he'll be in Booth #16a) and say, "Hey 
                     Craig, show me the light! I want Edit Plus!"
 How'd you like to use the GROLIER'S CD-ROM ENCYCLOPEDIA on your
 Atari .... hmmm? SARA-CD for Grolier's will be debuting at
 ACE'95! It's Great!! It's Incredible!! It Works!! It will be up 
 and running in the ABC Solutions Booth (#5)!! Replace three 
 shelves worth of Americana, Brittanica or Funk & Wagnall's, with 
 one little CD!! This is truly amazing stuff ... stay tuned for 
 more details ...
 ACE'95 will feature continuous, hour-on-the-hour SEMINARS and
 LECTURES. We'll be posting a Seminar schedule very soon!!
 A fabulous lineup of Door Prizes, Creativity Contest Prizes
 .... and the ACE'95 Grand Prize!
 MIDI, DTP, Wordprocessing, Graphics, Power Computing, Software 
 Libraries, Utilities, Accessories, Databases, Spreadsheets, 
 Custom Solutions, Games, Educational, Internet, BBS, Networks,
 Accelerators, Emulators, JAGUAR Stations, User Group Center,
 need to get the VERY BEST out of your Atari!
               Getting to ACE'95 is *easy*. Toronto is directly 
               accessed by Highway 401 or the Queen Elizabeth Way, 
               or Highway 400/69. Crossing the US/Canada border 
               at Detroit, Buffalo, Niagara Falls, Ft. Erie, 
               Ogdensburg, Kingston, etc., will lead you directly
               to Highway 401 or the Queen Elizabeth Way. Take the 
               Yonge St. Ramp north off the 401 and drive to 5110 
               Yonge St. (5 lights) If you take the Queen Elizabeth
               Way, follow the signs to get to highway 401. *ANY*
               AAA or CAA or other Motor League can provide you with 
               a map of Toronto, Ontario & Canada. Please call us
               if you have any trouble! Pearson International 
               Airport is only 15 minutes away! Toronto Transit 
               subway access is direct, too - there's a subway 
               stop at the Civic Center!
               or e-mail for info ... for INDIVIDUALS, USER GROUPS,
               ORGANIZATIONS, DEVELOPERS & DEALERS! The Show Site 
               (North York Civic Center, Memorial Hall Exhibition
               Facility) has hotel, shopping, restaurants and more! 
                                      NOVOTEL: $89 Cdn PER NIGHT
                                     (single OR double occupancy)
               ** Call Novotel direct @ 416-733-2929 and ASK FOR 
                              ACE'95 TICKETS: $6 PER DAY
                                              $10 WEEKEND PASS
               CALL 416-752-2744 FOR HOTEL & TICKET RESERVATIONS
               Meet Dan Wilga, Darek Mihocka, Bob Luneski, Peter 
               Zalesak, John Trautschold, Craig Harvey, Nathan 
               Potechin, Mario Georgiou, Greg Kopchak, Al Fasoldt,
               Rick Ladage, Jim Fouch, David & Jennifer Troy,
               Michael Burkley, Roger Burrows, DARLAH, Craig 
               Carmichael, Tom Harker, Chris Krowchuck, Jim 
               Collins, Ralf Dowich, Shawn Tedder, Mike Wilhelm,
               Mike Hohman, Christian Ernst, Michael Snape, Ray 
               Williams, Stuart Watt, Stephen Christian, Steve 
               Cohen, Jeff Neveu, Sonny Ang, Bill Annand and
               Michael Buffer ... well you never know, Michael 
               *might* show up: LLLLLLLLLLLLLLLLLLET'S GET READY 
               TO COMPUUUUUUUUUUUUUUUUUUUUUTE!! There will be 
               plenty more of the greatest dealers, developers
               & supporters Atari users have seen in years!
               *CALL US*  416-752-2744 or 416-225-5823 *CALL US*
 ACE'95 is being held at:
 North York Civic Center
 Memorial Hall Exhibition Facility
 5110 Yonge St. (at Parkhome Ave.)
 Toronto, Canada
 April 1-2, 1995
 Saturday 9AM - 6PM
 Sunday   9AM - 5PM
 ~~ Howard Carson, ACE'95 Chief Organizer ~~~
 E-Mail: GEnie - H.Carson1
         Atarinet - Howard. Carson@51:5/6
         Internet -
         TAF Online - Howard. Carson


 > ExtenDOS Update! STR NewsFile!  -  ExtenDOS News from Anodyne Software!

 From Roger Burrows.........

 Well, I was a bit lazy about supplying this a few days ago, and then I
 got another request for the same info, so I decide to create a summary
 of ExtenDOS And thanks again to those folks who prodded me into
 producing this!

 Roger Burrows / Anodyne Software

 ExtenDOS v1.22:

    Supported hardware:
      Atari systems: ST, STe, Mega, TT, and Falcon.  The ST/STe/Mega
                     require a host adapter that can pass the entire
                     SCSI command set, such as the ICD AdSCSI+ or Link.

      CD-ROM drives:
        Multisession photoCD:
          Apple CD-300/CD-300+/PowerCD
          Chinon 535
          Sony 561
          NEC 38/74-1/84-1/210/3Xe/3Xi/3Xp
          Plextor/Texel 3028/5028/4plex
          Toshiba 3401/4101

        Single-session photoCD:
          Chinon 435
          NEC 37/74/84
          Plextor/Texel 3024/5024
          Toshiba 3301

        No photoCD:
          Toshiba 3201
          NEC 25/35/72/77/80/82
          Sony 541/6211/8022
          Any fully SCSI-compatible drive

    Supported software:
      Operating environments: TOS, MultiTOS, Geneva, and Mag!X.
      CD-ROM file formats: ISO9660 and High Sierra.

    Other features:
      Configurable cache.
      Updates to ExtenDOS (bug fixes, enhancements) are typically
      distributed electronically at no charge.

    The next update will support more drives, including Chinon 525,
    Mediavision Reno, Sony 55S, Toshiba 3501/5201.

    Extendos v1.22 lists at $29.95(North America).

 ExtenDOS Pro v2.0B:

    Supported hardware:
      Atari systems: ST, STe, Mega, TT, and Falcon.  The ST/STe/Mega
                     require a host adapter that can pass the entire
                     SCSI command set, such as the ICD AdSCSI+ or Link.
      CD-ROM drives:
        Multisession photoCD:
          Apple CD-300/CD-300+/PowerCD
          Chinon 535
          Sony 561
          NEC 38/74-1/84-1/210/3Xe/3Xi/3Xp
          Plextor/Texel 3028/5028
          Toshiba 3401/4101

        Single-session photoCD:
          Chinon 435
          NEC 37/74/84
          Toshiba 3301

        No photoCD:
          Toshiba 3201
          NEC 25/35/72/77/80/82
          Sony 541/6211/8022

    Supported software:
      Operating environments: TOS, MultiTOS, Geneva, and Mag!X.
      CD-ROM file formats: ISO9660 and High Sierra.

    Other features:
      Configurable cache.
      Updates to ExtenDOS Pro (bug fixes, enhancements) are typically
      distributed electronically at no charge.
      Audio support for all the above drives (except the Chinon 435 at
      this time).  This support includes an audioCD player (both as
      program and accessory) and the capability of controlling the CD-ROM
      via a user-written program.

    The next update, due out in April 1995,  will include the following
      An installation/reconfiguration program.
      Support for multi-LUN drives (changers) such as the Pioneer 60x.
      Support for more drives, including the Chinon 525, Mediavision
        Reno, NEC 4x, Pioneer 602X/604X, Sony 55S, Toshiba 3501/5201.
      Audio support for any SCSI-2 compatible drive.

    Extendos Pro lists at $39.95(North America). Owners of ExtenDOS may
    upgrade to ExtenDOS Pro at a special rate (currently $15 in North

 From now till April 1, get a CD starter pack of ExtenDOS Pro and three
 CD's to get you going for $39.99 US, Postpaid, from It's All Relative,
 2233 Keeven Lane, Florissant MO 63031.

 Been waiting to get a CD drive? Better start shopping around.

 The CD starter pack requires a Kodak Photo CD ready drive.


 > Obsession & Vintage Games Update! - New at Systems For Tomorrow!

 SFT Contact Info
 Orders  (800)875-4943
 Info    (816)353-1221
 FAX     (816)252-3611
 Mail    11034 East 40 Highway
         Independence MO 64055

     There is a point beyond Addiction......... Obsession!
     Obsession is Unique Developments incredible pinball game for the
     STE and Falcon brought to us by chro_Magic. Obsession contains 4
     tables for your enjoyment (Aquatic Adventure, X-ile Zone, Balls &
     Bats, and Desert Run!)  Obsession provides realistic ball
     movement, over 40 colors on screen, super fast scrolling, and

     Obsession has already received a massive 98% rating from ST
     Review and 94% from ST Format.  Buy this game today!
     System Requirements: STe/MegaSTE/Falcon Only (Bummer,no TT)
                          1MB RAM
                          Color Monitor
     Obsession            $39.99

 Mailing Manager ST Pro
     The Ultimate Dedicated Mailing List Program For Your Atari
     Keep track of Friends, Family, and Customer Mailing Lists.
     Provides powerful printing and report features including Form
     Letters, Address Labels, Phone number listings, and more...
     Other features: supports subscriptions, 28 flags, Extended Notes,
     and more... 
     System Requirements: ST/TT/Falcon
                          1MB RAM
     Mailing Manager ST Pro      $49.99

 Atari 7800 Deal
     We now have a limited quantity of Atari 7800 Pro Systems.  The
     7800 Pro System Allows you to play both Atari 7800 and 2600 games!
     Each system comes with the Base Unit, two joysticks, Pole
     Position Game Cartridge, Power Supply, and TV connections!
     As an added bonus all 7800 and 2600 Cartridges are 25% OFF normal
     pricing when purchased with a System!
     Atari 7800 Pro System       $29.99

 Atari 7800 Games
     All 7800 games are $7.99! Buy 3 or more and take 20% OFF!
     Joust           Commando        Crossbow        Winter Games
     One-on-One      Fight Night     Mario Bros.     Summer Games
     Scrapyard Dog   Donkey Kong     Centipede       Hat Trick
     TD Football     Ballblazer      Crack'ed        Mean 18 Golf
     Xevious         Ninja Golf      Robotron 2084   Jinks
     Mat Mania       Ace of Aces     Super Huey      Asteroids
     Ikari Warriors  Dark Chambers   RS Baseball

 Atari 2600 Games
     All 2600 games are $3.99! Buy 3 or more and take 20% OFF!
     Off the Wall    Desert Falcon   Millipede       Yars' Revenge
     Kangaroo        Dig Dug         Mouse Trap      Football
     Battlezone      Jungle Hunt     Venture         Galaxian
     Ms. Pac-Man     Jr. Pac-Man     Pac-Man         Defender II
     Space Invaders

 orders          (800)875-4943   Monday-Friday 10AM-7PM 
                                 Saturday 10AM-5PM
 info/orders     (816)353-1221   Monday-Friday 10AM-7PM (central) 
                                 Saturday 10AM-5PM 
 FAX             (816)252-3611
 mail to:        Systems For Tomorrow
                 11034 East 40 Highway
                 Independence MO 64055

 We accept MasterCard and Visa.  COD orders add $5.
 All prices are subject to change without notice.  Some items may be
 available in limited quantities only. All prices are in US dollars.

 ---------------Order Form-------------------------------------------

 Name:   ______________________________________




 Phone:  ______________________________________

     O COD 
     O PrePAID
     O Credit Card #_____________________________ Exp _____ 
       Card holder signature:_______________________________
       Note: For your protection, we require that all credit card
             orders must be shipped to the billing address for the
 Item #   Description            Price   Qnty    Extension
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
 ______   _____________________  ______  ______  _______
                                     Sub Total   _______
                     Tax - MO residents add 6%   _______

                            COD orders add $5   _______

                                     Shipping   _______

                                        Total   _______

 Fax order to - (816) 252-3611
 Mail order to - SFT - 11034 East 40 Highway - Independence MO 64055


 > STR NewsPlus

                 -/- Online 'Decency' Bill Targeted -/-

     U.S. Sen. Jim Exon's proposed "Communications Decency Act" -- which
 would impose $100,000 fines on anyone who uses computers "to annoy,
 abuse, threaten, or harass" -- is being viewed with alarm by online
 free speech activists.

     When the Nebraska Democrat introduced his bill Feb. 1, he said it
 necessary to "extend the standards of decency which have protected
 telephone users to new telecommunications devices." (A companion bill
 has been introduced in the House by Rep. Timothy Johnson, D-S.D.)

     Associated Press writer Elizabeth Weise reports some computer users
 and free speech activists are gearing up for a fight against what they
 fear are the first in a "flood of U.S. laws designed to control access
 to the freewheeling global computer network," Internet.

     Says Weise, "while Exon wants to keep the Internet from becoming a
 red light district, many computer users see his proposal as a misguided
 attempt to control the global network of computer connections. ... As
 word of the proposal spreads, just about every watchdog group on the
 Internet has come together, circulating electronic petitions and urging
 computer users to lobby Congress against the bill."

     Among the opponents are computer industry groups, the Electronic
 Frontier Foundation, the ACLU and People for the American Way.

     Says AP, "Many computer users acknowledge that some regulation of
 cyberspace is necessary. And while some say the original creators of
 material should be held liable for its content, most argue that
 responsibility lies with anyone who takes the effort to obtain it from
 the Internet. After all, they argue, the Internet is different from
 television or the telephone."

     Shabbir J. Safdar of the Voters Telecommunications Watch in New York
 told the wire service, "It's not as if I'm sitting at home eating dinner
 and the salesman calls me. I have to go looking for whatever I want to
 find. If it offends me, I should stop going looking for it."

     Exon's bill would hold responsible anyone who "transmits or
 otherwise makes available" the offensive words or images. Opponents
 argue that would make universities, companies and other Internet access
 providers responsible for screening everything from public postings to
 private email.

     Safdar said the proposed law "seems to make everyone in between
 liable as well, not just the end points. Everybody there is sueable."
     And Marc Rotenberg, director of the Electronic Privacy Information
 Center, said requiring U.S. providers of access to the Internet to
 police everything that flows through their wires would violate the
 very freedom that has made this global exchange of information so

     But Exon spokesman Russ Rader told Weise that's not the intention,
 and that the senator is willing to refine the language of the bill
 (although that has not yet been done).

     Still, the broader problem, say the opponents, is that lawmakers
 don't really understand what the Internet is and how it works.

     Weise comments, "No one has quite figured out yet where the Internet
 fits. The service providers who give access to it at times look like all
 three -- sometimes a phone company, sometimes a radio network, sometimes
 a magazine publisher. Rotenberg also points out that the Internet is a
 global network. If U.S. computer networks are required to cut off
 contact with overseas systems which don't meet our standards for
 informational purity, America will be left out of the global information

                  -/- School to Limit Usenet Access -/-

     The University of Pittsburgh has become the latest school to
 propose limiting Usenet access.  The university says it will establish a
 standing committee of faculty, students and others to help determine which
 of the more than 10,000 Usenet news groups on the Internet will be carried
 on its computer network.

     The school says the move is one aspect of a new policy that will
 review the use of university computer resources to access, display,
 post or print materials that may have obscene or sexually explicit
 content.  The school notes that the policy addresses the need to provide
 appropriate protection for First Amendment rights, while at the same
 time adhering to federal and state statutes governing obscenity and
 sexually explicit material.

     The policy calls for the suspension of computing privileges as well
 as the possible imposition of additional sanctions upon anyone who is
 found to have employed university computer resources to use obscene or
 sexually explicit material in a way that violates university policies
 and guidelines.

                    -/- Delrina Buys BBS Company -/-

     Delrina Corp. says it has entered into a purchase agreement to
 acquire CRS Online Ltd., a 10,000-subscriber computer bulletin board
 system (BBS) in Canada.

     Delrina notes that the acquisition is part of its long term strategy
 to expand its presence in online communications and services, and will
 allow the company to test the marketability of new communications
 offerings. Terms of the deal weren't disclosed.

     Delrina's plans include further expansion of CRS Online, which
 currently employs 13 people.  "The key to success in the world of online
 communications is the ability to simplify the way users access and use
 services," says Mark Skapinker, Delrina's president. "Clearly, stand-alone
 products can only go so far to deliver easy, flexible and robust
 connectivity without some integration between the software the customer
 uses and the point at which he or she makes a connection."

     "The acquisition of CRS Online will enable Delrina to build and test
 the type of integrated online communications solutions that will appeal
 to a broader marketplace," adds Ron Close, vice  president of Delrina's
 communication services business unit. "In addition, we will gain a staff
 with proven operational and strategic expertise in the area of online

     CRS Online, based in Toronto, Ontario, can trace its roots back to
 the early 1980s. It provides subscribers with a centralized information
 source in which users can exchange electronic mail, retrieve files or
 participate in online group events.
     Delrina publishes software in the fax, data and voice communications,
 electronic forms, and consumer software markets.

                   -/- Fujitsu, CompuServe Team Up -/-

     Worlds Away -- an animated, cartoon-like service where online
 visitors can meet and create personalities in a virtual world -- is
 being jointly created by Japan's Fujitsu Ltd. and CompuServe Inc.

     Reporting from the PC Forum conference in Phoenix, Arizona, the
 Reuter News Service quotes Fujitsu officials as saying the service now
 is in testing and will be available later this year.

     Says Reuters, "Unlike the traditional chat rooms in online services,
 where visitors exchange instant messages on the screen in a group,
 Worlds Away has graphics and animation so users can create a setting
 like a cafe or a living room. They can also play with props or objects,
 such as a coffee cup."

     Visitors also can create their own identities, called "avatars,"
 and they can portray real personalities or create one, says the wire
 service, adding, "With computer graphics users can convey facial
 expressions and gestures and talk to one another with text and
 comic-book-like thought balloons."

     Reuters reports Worlds Away was designed by two former Lucas Films
 designers who developed Habitat, the first graphical cyber community in
 the 1980s. Fujitsu purchased the Habitat technology and introduced it
 in Japan in 1989. Last year, Fujitsu formed a multimedia unit, called
 Cultural Technologies, to re-engineer Habitat for the U.S. market.

     The service is the first product of Fujitsu's Cultural Technologies
 unit, based in San Jose, Calif., and it is being demonstrated at the
 Phoenix conference.

                  -/- Home PC Market Strong in U.S. -/-

     A new marketing study says the home PC market is considerably more
 developed in the United States than in major countries of Europe and

     "Not only do a much higher percentage of homes have personal
 computers, but the use of emerging consumer applications such as
 education, entertainment, and online services are considerably more
 developed in the United States," says a statement from International
 Data Corp., which released results of its new worldwide consumer

     Based on some 7,000 interviews with consumers in the United States,
 Western Europe and Japan, IDC's Global Home Market Survey found:

     -:- When home computers provided by employers or schools are
 included, some 37 percent of U.S. households now have one or more
 personal computers.

     -:- This compares with 28 percent in Germany, 24 percent in the
 United Kingdom, 15 percent in France, and less than 10 percent in Japan.
 (Northern European markets such as Denmark and the Netherlands have
 personal computer usage closer to, but still lower than the U.S. level.)

     -:- The current gaps show no sign of closing in 1995, because roughly
 10 percent of homes without a PC are seriously considering a PC
 acquisition in 1995 in most of the countries surveyed.

     -:- Apple computer has the largest installed base of home personal
 computers, and will be the largest supplier of PCs to the home in 1995.

     "In addition to different PC penetration levels" among different
 countries, says the statement from the researchers' Framingham,
 Massachusetts, headquarters, "home PC usage patterns also differ
 sharply. Although job-related work is the most important home
 application in all of the countries surveyed, U.S. consumers are much
 more interested in education, entertainment, home finance, and online
 services compared to consumers across Europe."

     For instance, 47 percent of U.S. homes with a PC also have a modem,
 compared to just 13 percent in Europe. Similar details of the Japanese
 results will be released shortly.


                               JAGUAR SECTION

 Ultra Vortex!  CATscan BBS!
 Internet News!  And More!

 > From the Editor's Controller  -  Playin' it like it is!

      I believe that the flood gates are about to burst open, any day
 now.  We know that Atari's 4th quarter financial report is expected to
 be released next week.  What better way to top off a positive report
 (if that's going to happen!) with a number of announcements for new

      Syndicate and Troy Aikman Football are out, with little fanfare.
 All of the sudden, we just see some messages from those who have seen
 or bought them.  No announcements, which was strange.  But the
 important thing is, they're out.

      We're guessing that we'll see an announcement for the CatBox and
 the Jaguar CD-player shortly, also.  Those, plus a number of new games
 (both cart and CD), seem to be imminent.  Hmmm, did I say something
 above about March being a boring month?  Maybe I should retract that
 comment, for this year!

      Well, let's get to the news and information for this week!  It's
 quiet right now, but our crystal ball tells us that the next few weeks
 are going to be very interesting.  As usual, we'll be here to bring it
 all to you!

      Until next time...


 > Jaguar Catalog STR InfoFile  -   What's currently available, what's
   """""""""""""""""""""""""""      coming out.

    Current Available Titles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    CAT #   TITLE                 MSRP      DEVELOPER/PUBLISHER

     J9000  Cybermorph           $59.99         Atari Corp.
     J9006  Evolution:Dino Dudes $49.99         Atari Corp.
     J9005  Raiden               $49.99     FABTEK, Inc/Atari Corp.
     J9001  Trevor McFur/
            Crescent Galaxy      $49.99         Atari Corp.
     J9010  Tempest 2000         $59.95     Llamasoft/Atari Corp.
     J9028  Wolfenstein 3D       $69.95       id/Atari Corp.
     JA100  Brutal Sports FtBall $69.95          Telegames
     J9008  Alien vs. Predator   $69.99     Rebellion/Atari Corp.
     J9029  Doom                 $69.99        id/Atari Corp.
     J9036  Dragon: Bruce Lee    $59.99         Atari Corp.
     J9003  Club Drive           $59.99         Atari Corp.
     J9007  Checkered Flag       $69.99         Atari Corp.
     J9012  Kasumi Ninja         $69.99         Atari Corp.
     J9042  Zool 2               $59.99         Atari Corp
     J9020  Bubsy                $49.99         Atari Corp
     J9026  Iron Soldier         $59.99         Atari Corp
     J9060  Val D'Isere Skiing   $59.99         Atari Corp.
            Cannon Fodder                         Virgin
            Syndicate                             Ocean
            Troy Aikman Ftball                   Williams

     Available Soon ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     CAT #   TITLE               MSRP          DEVELOPER/PUBLISHER

             CatBox              $69.95               ICD
             Hover Strike        $59.99              Atari
             Jaguar CD-ROM       $149.99             Atari

     Hardware and Peripherals ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     CAT #   TITLE               MSRP          MANUFACTURER
     J8001  Jaguar (complete)   $189.99        Atari Corp.
     J8001  Jaguar (no cart)    $159.99        Atari Corp.
     J8904  Composite Cable     $19.95      
     J8901  Controller/Joypad   $24.95         Atari Corp.
     J8905  S-Video Cable       $19.95


 > Jaguar Developers STR InfoFile  -  Current Developer Lists & Titles

 Game Title             Date   Game Type           MSRP      Publisher
 Air Cars               1Q/95  Racing              $59.99    Midnight Ent.
 Alien vs Predator       NOW   Role Play/Adventure $69.99    Atari
 Arena Football         1Q/95  Sports               TBD      V Reel
 Assault                1Q/95  Action/Combat       $59.99    Midnight Ent.
 Barkley Basketball     2Q/95  Sports               TBD      Atari
 Battlemorph            1Q/95  Flying/Action       $59.99    Atari
 Battle Wheels          1Q/95  Racing/Combat        TBD      Beyond Games
 Blue Lightning (CD)    1Q/95  Flying/Action       $59.99    Atari
 Brett Hull Hockey (CD) 2Q/95  Sports               TBD      Atari
 Brutal Sports Football  NOW   Sports/Combat       $69.99    Telegames
 Bubsy                   NOW   Action/Adventure    $49.99    Atari
 Burnout                1Q/95  Sports               TBD      Atari
 Cannon Fodder           NOW   Action/Adventure              Virgin
 Checkered Flag          NOW   Racing              $69.99    Atari
 Club Drive              NOW   Racing              $59.99    Atari
 Creature Shock (CD)    1Q/95  Adventure/Sci-Fi     TBD      Atari/Virgin
 Cybermorph              NOW   Flying/Action       $59.99    Atari
 Dactyl Joust           2Q/95  Action               TBD      Atari
 Demolition Man         1Q/95  Action/Combat       $59.99    Atari
 Doom                    NOW   Action/Combat       $69.99    Atari
 Double Dragon V        1Q/95  Action/Adventure    $59.99    Williams
 Dragon:Bruce Lee Story  NOW   Combat              $59.99    Atari
 Dragon Lair (CD)       1Q/95  Adventure            TBD      Ready Soft
 Dreadnought (CD)       2Q/95  Adventure            TBD      Atari
 Dungeon Depths         1Q/95  Action/Adventure    $59.99    Midnight Ent.
 Evolution: Dino Dudes   NOW   Puzzle/Adventure    $49.99    Atari
 Flashback              1Q/95  Action/Adventure     TBD      US Gold
 Fight For Life         1Q/95  Combat               TBD      Atari
 Hardball Baseball      2Q/95  Sports               TBD      Atari
 Highlander (CD)        1Q/95  Action/Adventure    $59.99    Atari
 Horrorscope            1Q/95  Combat               TBD      V Reel
 Hover Strike           1Q/95  Action/Combat       $59.99    Atari
 Iron Soldier            NOW   Action/Strategy     $59.99    Atari
 Jack Nicklaus Golf(CD) 2Q/95  Sports               TBD      Atari
 Kasumi Ninja            NOW   Combat              $69.99    Atari
 Rage Rally             1Q/95  Racing               TBD      Atari
 Raiden                  NOW   Action/Adventure    $49.99    Atari
 Rayman                 1Q/95  Action/Adventure     TBD      UBI Soft
 Robinson Requiem       1Q/95  Adventure            TBD      Atari
 Soccer Kid             1Q/95  Sports               TBD      Ocean
 Space War              1Q/95  Action/Adventure    $59.99    Atari
 Star Raiders           1Q/95  Space Simulation     TBD      Atari
 Syndicate               NOW   Simulation           TBD      Ocean
 Tempest 2000            NOW   Action/Adventure    $59.99    Atari
 Theme Park             1Q/95  Simulation           TBD      Ocean
 Tiny Toon Adventures   1Q/95  Action/Adventure    $59.99    Atari
 Trevor McFur            NOW   Action/Adventure    $49.99    Atari
 Troy Aikman NFL Ftball  NOW   Sports              $69.99    Williams
 Ultimate Brain Games   1Q/95  Puzzle               TBD      Telegames
 Ultra Vortex           1Q/95  Action/Adventure    $69.99    Beyond Games
 Val D'Isere Skiing...   NOW   Sports              $59.99    Atari
 White Men Can't Jump   1Q/95  Sports               TBD      TriMark
 Wolfenstein 3D          NOW   Combat/Action       $59.99    Atari
 Zool2                   NOW   Action/Adventure    $59.99    Atari

 [Editor's note: Titles, scheduled release dates, and prices are
 verified from Atari and Edelman Public Relations - all subject to


 > Jaguar Online STR InfoFile         Online Users Growl & Purr!

 CATnips... Jaguar notes from Don Thomas

 First off, I apologize to anyone if I have missed your message lately.
 I'm trying to do my best to keep up with E-Mail, but I haven't been in
 the forums as much over the past couple of days. My attention is on
 new BBS software recommended to me by Steve Kipker of Steve's
 Software. Although, RATSoft is an unusual name for BBS software, it so
 far seems to live up to Steve's enthusiasm.

  My only setback is that there were (and are) a lot of features on
 CATscan and I want to switch as many over I can in advance, such as
 the dealer referral module, the T-shirt lottery, game descriptions,
 download areas, etc. I am sorry to see my old BBS software (Michtron
 BBS) go especially since I spent many hours writing scripts, but users
 want higher baud rates and they are just not supported by the older

 I am pleased to report that my "code of silence" in the form a of a
 non-disclosure agreement regarding the core Jaguar, it's price and
 availability has been lifted. AS many of you have been discussing,
 retailers are jockeying their inventories around while preparing for
 the new base systems shipping over the next few weeks. Atari is
 suggesting to dealers that the 64-bit Jaguar base unit (without a cart)
 is a tremendous value at only $159.99. Of course, retailers may vary a
 little as they ultimately set their own prices. 

 I'll let everyone know when CATscan is on the new software.

 --Don Thomas
   Atari Corporation

 From Compuserve's Atari Gaming Forums, an update on Ultra Vortex:

 Fm: Kris Johnson 73150,1553
 To: Thomas A. Lenaway 76430,1263

 > If Ultra Vortex controls like KN (which it's rumored to), I'm going
 to lock the Jag away > and go find a system with some quality. <

 For the record, Ultra Vortex controls rock! It's not KN controls with
 a special moves button. More like MKII or SFII (i.e. A,A, HP  or sweep
 + LP), Block is Away. The play is very fluid running at 30 fps. Between
 8-10 special moves per characters + multiple fatalities per character.
 Many hidden characters, 2 bosses, board fatalities, turbo play and

 The last review in DieHard GameFan stated that the controls were not
 final! Why, because we had all the special moves on the keypad for
 demo purposes.

 UV should be out by April '95, we're just putting in the final sound FX
 and tuning fatalities. It will be worth the wait!

 -Kris @ Beyond Games

 >R.G.V.A.! STR Internet InfoFile! - Atari Games Usenet Group to Change?

 RFD: reorganization

 Status:         Moderated
 Distribution:   World
 Summary:        New group intended for the discussion of video game
                 products currently produced, sold, or supported by the
                 company "Atari", and all associated peripherals and games
                 for said products.  Includes renaming
                 to and a unique moderation
 Proponent:      <Chris K. Brown>


 This is a formal request for discussion (RFD) for the creation of the
 moderated newsgroup and the renaming of to

 This request is being cross-posted to:

 Follow-ups are directed to news.groups.

 This formal request for discussion takes place because of the very low
 "signal to noise" ratio on  Discussion of
 creating a moderated newsgroup has come up many times before, and has
 been met with mixed results.  This proposal attempts to address the
 main issues that have appeared in previous discussions and propose a
 solution acceptable to all.

 Recently, the discussion has turned to seeing if such a group were to
 be created, whether or not moderator(s) would be available.  Several
 volunteers have been identified.  Selection of moderator(s) will
 take place during the RFD period.

 The charter of r.g.v.a.digest will be nearly identical to that of
 r.g.v.a.  The method of moderation is unique, and will be outlined in
 the charter.  In summary, it will set up a relationship between
 r.g.v.a.digest and r.g.v.a(.discuss), where all articles posted to
 the latter will be considered for posting to the former by the

 Guidance on this proposal has also came from


 The two parts of this proposal are INDEPENDENT and will be voted

 Part 1  Create a newsgroup

 Group:  The proposed group is [moderated].

 Distribution:  World

 Summary line: Discussion of Atari and current and future Atari video
 game products.

 Charter: [moderated] is for the
 discussion of the Atari Corporation and current and future Atari video
 games products, including related products that are to be used with or
 by said Atari products.  Specifically forbidden are discussion of
 older Atari video game products (e.g. 2600, 5200, etc.) and Atari
 computers (e.g. 400, 520ST, Falcon, etc.)

 Appropriate material includes the Atari Jaguar FAQ, the Atari Lynx
 FAQ, constructive discussion of the current video game hardware sold
 by Atari (e.g. Jaguar and Lynx) and games and peripherals for said
 hardware (including reviews), information about the availability of
 said hardware, new discussion of the Atari Corporation and its
 business practices and informative posts from developers and Atari
 representatives about anything listed above.

 Inappropriate material includes things discussed fully in any of the
 group's recognized FAQs, un-informative posts which attack or promote
 the Atari corporation without regard, anything which adds little or no
 new information to the discussion of which it is a part, and
 unconfirmed speculation and rumor about Atari and its products,
 especially when stated as fact.

 Moderation Policy:

     Articles will be:
         1) accepted, as is
         2) accepted, with revisions
         3) declined (with reasons and suggestions if posted directly to
                      r.g.v.a.digest.  See below)

 Every article posted to
 ( if the second part of this proposal
 passes) will be considered by the moderator(s) for r.g.v.a.digest. 
 may also be submitted in the normal fashion (i.e. posting to the group
 directly or sending a request to the moderator).

 It is expected that the article acceptance rate will be low, due to
 the large amount of noise in r.g.v.a.  Eventually, this rate should
 increase dramatically as the new moderated group draws people who are
 truly interested in discussing the subject.  For articles posted to
 r.g.v.a(.discuss), authors will be notified of acceptance but
 articles will not be returned.  For articles posted directly to
 r.g.v.a.digest, authors will be notified of of acceptance or rejection
 but articles will not be returned to eliminate unnecessary traffic.

 Moderation Procedure: The settling of this issue will be the first
 order of business during the RFD.  Software to support the scheme
 outlined in the "Moderation Policy" above will be developed by Chris
 K. Brown <> using standard moderation software as a model.

 Main topics of discussion will be settling on the number of
 moderators and the identity of the moderators.

 Part 2  Rename

 Group: rename to

 The summary line, distribution and charter of the new group would be unchanged from those
 currently in existence for  This change is
 solely for the purpose of maintaining the structure of the name space.

 Proposed by:  Chris K. Brown <>
 All aspects of the proposal are still open for debate and discussion.
 All useful suggestions are welcomed.


 This RFD is being issued in concordance with the guidelines set in
 the "How to create a new Usenet newsgroup" FAQ regularly posted to
 news.announce.newgroups ("Guidelines for USENET Group Creation, David
 C Lawrence <>, last modified 18 Jan 1995).  Please
 refer to this article if you have any questions about the newsgroup

 The public discussion period will last a maximum of 30 days after this
 RFD has been posted.

 If, after the discussion period, it has been determined that this new
 group is really desired, and the name, charter, and moderator(s) are
 agreed upon, a Call for Votes will be posted to news.announce.newgroups
 and to the other groups to which this RFD was cross-posted.  Votes
 will then be collected by a neutral third-party vote-taker from the
 Usenet Volunteer Votetakers (UVV).

 The two parts of the proposal 1) create
 and 2) rename to
 will be voted on SEPARATELY.  Each part passing or failing
 INDEPENDENTLY on its own merits, although both parts of the proposal
 will be contained in the same Call for Votes (CFV).


 > STReport Jaguar Game Review:                 Checkered Flag

                        -= Available Now =-
                  Developed by: Rebellion Software
                     Published by: Atari Corp.
                     Sugg. Retail Price: $59.95
                 Ease of Play: Average/Intermediate

                          by Marty Mankins

 Imagine if you will in the drivers seat of a race car, getting
 ready to race for the title.  Amongst you are others who wish to
 take the opportunity away from you of becoming the next Al Unser
 or Mario Andretti.  After your drive, you realize that you should
 have picked different tires and maybe had some adjustments in your
 steering control.  This is the experience of Atari's Checkered Flag.
 It is a good driving game and has a good level of options for your
 car, but controlling the car is something that needs some serious


 Pick your car and configure it how you want it.  Choose the color of
 your car.  It can be red & black, yellow & blue, white & yellow,
 blue & green, red & white or green & white.  Next, you can have
 your weather conditions remain sunny, raining or foggy for your laps. 
 Your airfoil can be either low or high, depending how much wind
 resistance you need.  Change the tires to be best for dry pavement or
 wet traction.  There are two transmissions to pick from: manual 6-speed
 or automatic 5-speed.  You can have anywhere from one to five drone
 cars follow you and cause you grief on your race.  If this is your
 first game, you can pick to race in a free practice, or choose a
 single race or a tournament, where you have 10 laps to finish before
 you can claim the crown.  In free practice or single race, you can
 choose to race between 1 and 99 laps.

 Your choice of tracks is probably the best thing about this game.  You
 can choose from 10 different race tracks, some based on real race
 tracks.  In tournament mode, you start with one track and race it until
 you finish your 10 laps.  In going through all of these settings, I
 found that the blue and yellow car with sunny weather, a low airfoil,
 wet tires, automatic transmission, 2 drones and Green Valley were the
 best combinations to race and really enjoy myself.

 The sounds were realistic, but could have refined a bit more,
 considering how long it took for this game to be released (not to
 mention it's many title changes: from Checkered Flag to Red Line Racing
 to Checkered Flag 2 back to Checkered Flag).  Others who played the
 game also commented on how the sounds could have been better.  I
 guess it's from all of those arcade sessions with Sega's Virtua
 Racing that's spoiled us.


 I went through every single track in free practice and single race
 modes and tried as many options as I could.  I decided that I am
 sticking (no pun intended) with the wet tires.  They help you keep
 on the track much better than the dry tires.  Even in the sunny
 weather condition, the wet tires made a world of difference and
 helped make up for the lack of control with the car.

 I ended up liking the Green Valley track the best for it's
 consistent layout.  It had the same number of turns and same amount
 of straight-away.  It was very easy to get used to and I got really
 good at beating the drones.  I still like the 2 drones, since I like
 to race without other cars on the road (taken from my 2am freeway
 drives at 100+ mph!).

 One of the best tips that I can give for playing Checkered Flag,
 besides using wet tires, is to play with an open mind and forget
 other driving games.  I mentioned earlier that I've been spoiled by
 Sega's Virtua Racing, but this doesn't mean I am tied to it's ways
 in Checkered Flag.  You have to learn to turn with a small amount of
 movement.  Any more and you find yourself driving into one of the
 mountains or guardrails.  Also, slowing down when the road says,
 "Slow Down", is good advice.  I've played around with trying to take
 sharp turns at the highest possible speed and have only made it once.
 I may practice this more, but I don't think it's going too get any


 The first thing I disliked was the controls of the car.  And sure
 enough, I wasn't alone.  Many of the people I talk with on CompuServe's
 Atari Gaming forum felt the same way.  Now it didn't leave the game
 completely crippled, but missing was a control for steering.  If this
 would have been included, then all of the control problems could have
 been solved for most players.  My business partner's son mentioned
 they should have just paid Sega the rights to port Virtua Racing onto
 the Jaguar.  Could have been a good thing.  Actually, I prefer the
 Atari Lynx version of Checkered Flag.  It's controls for a handheld
 system were much better than the Jaguar game play.  And the selection
 of tracks was slightly expanded, which could have helped, even though
 I did find all 10 tracks to be very good.

 Polygons bother some people, but not myself.  The only change here
 would have been a little more action with the car.  It looked too
 rigid on the screen, not moving well enough with the road to provide,
 once again, that realistic look and feel.


 Checkered Flag is one game that is worth about half it's retail price
 (Note: some stores are actually selling it for $19.95 or $29.95),
 considering the control problems.  But, beneath this fault, the game
 can be used with it's options to provide some fun and challenging
 racing on your Jaguar.

                    Graphics:               7.0
                    Sound FX/Music:         6.0
                    Control:                5.0
                    Manual:                 7.5
                    Entertainment:          6.0
                    Reviewer's Overall:     6.5


 > STR Editor's Mail Call    "...a place for the readers to be heard"

                              Editor's MailBag

                     Messages * NOT EDITED * for content

 This is a letter from Anthony T. Talarico Jr. 73065,364.
 Posted on March 06, 1995 in the Atari Gaming areas on CompuServe.


 This is a reply to your message to John Mathieson from the;
 "You're the Boss" section

 Ralph, while your point that Atari management doesn't seem to go for the
 brass ring is well taken, I do differ with you on a couple of things.

 >>  From high powered computers to high tech game consoles they've all
 made it to market.  Only to be ultimately clobbered by the competition
 which was clearly outclassed by Atari's obviously superior hardware
 offerings. <<

 Atari's offerings have not always been obviously (by me) superior. In
 1977, Atari didn't just have the best game console in the VCS, they had
 the ONLY console. A year later, when the RCA Studio II and Fairchild F1
 were out, the VCS was definitely superior. However, the next released
 Intellivision blew the Atari away - at a 50 percent increase in price.
 When Colecovision appeared at a competitive price, the public - and
 developers - flocked to it in droves.

 At this point, the 400 and 800 were out - definitely superior to
 everything else on the market - and started to attract a LOT (for the
 time) of interest. Then the VIC-20 grew up and became the C64. It was NOT
 a superior design EXCEPT that it could show more than 4 colors at once. It
 was harder to program, but the results were MUCH more marketable.

 Now, admittedly, this all took place during the Warner years. They
 definitely made bad decisions where home computing was concerned. Witness
 their reluctance to develop the 1450XLD (or any 16-bit computer) and their
 creation of the incompatible-with-everything 5200. Probably the best thing
 they did was to sell the company.

 On to the Tramiel years -

 The very first bad decision, in my mind, was shelving the 7800. However, I
 do not have ESP and do not know what other considerations Jack et. al. may
 have had. I imagine that they were pretty strapped for cash at that point,
 what with having just bought an entire company and all.

 Their first piece of hardware on the market was the XE computers. Too
 little too late against the growing tide of EGA PCS. But, it was an
 inexpensive (relatively) upgrade to a somewhat popular computer. Then came
 the ST line. Superior to PCS (and Macs) in every way - 64 colors, 3 + inch
 disks, audio, MIDI - but NOT superior to the Amiga. What sold the STs was
 price. They were the FIRST 16-bit computers that could be purchased for
 under $1000.

 The next thing the T's did was to FINALLY release the 7800. Definitely
 better than the NES or the Sega Master System. Only problem was that the
 Genesis showed up at almost the same time - for not a whole lot more

 The Jaguar is, in my opinion, the first design from the Tramiels that
 TOTALLY outclasses the competition.

 "... obviously superior hardware ..."??? I think not. However, in most
 cases, the hardware was DEFINITELY good enough for the price. Then, what
 was the problem? Why didn't Atari succeed?

 >> Its really very clear to those of us who owe no allegiance to Atari,
 for whatever reason, and take the time to observe and analyze the course
 of action Atari repeatedly  takes.  It is quite clear that Atari's
 Tramiels do indeed run a full blown dictatorship that is heavily
 influenced with emotional decisions and knee jerk reactions on the part of
 the Tramiels. <<

 It is NOT very clear to me, and the only allegiance I have is to have
 Atari produce enough games for the Jag so that I can enjoy it after it
 goes the way of my 800XL and 130XE and 7800 (and it will, trust me.
 Consumer electronics is a tough market.) as long as I have enjoyed the
 aforementioned devices.

 As I have stated before, I do not have ESP and cannot determine what runs
 through the Tramiels collective heads. I do not know what market
 considerations and business decisions must influence someone running a
 company on a shoestring budget. I do not know how tough it must be to
 convince vendors and distributors to work with me. I cannot know what
 marketing surveys should be conducted to determine consumer tastes 1-2
 YEARS down the road. If you do have this capability, I applaud you. I'm
 sure the Tramiels would be more than happy to compensate you for it.

 One thing I am (mostly) sure of, though, is that Atari MUST rely on their
 dealers and end-users (us) for some of their marketing support. They do
 not have the megabucks necessary to compete on the same scale as Nintendo
 or Sega. Dealers, however, don't like to push one company over another
 UNLESS they are absolutely sure that company would make a profit for said
 dealer. Witness the "Microsoft Wall" in most software shops. That leaves
 us. Word of mouth, in-home demos (invite your friends over) and letters to
 magazines are our contributions. And NONE of us will be compensated for

 All this still does not answer the question you posed in your message -
 "Why is Atari not number one (or at least, a MAJOR player)?" or mine, as I
 stated, "Why didn't Atari succeed?".

 Well, Ralph, to answer my question first, Atari HAS succeeded. They are
 still around after over 20 YEARS. A company the size of a small grocery
 chain - or even one of IBM's sales offices - is INTERNATIONAL! They have
 products in development for the future. They have the money to develop
 these products - AT THEIR OWN PACE. There is NO evidence that they are
 going away in the near future.

 I answer your question with another - Why should they be? They are making
 money. They produce products that people enjoy (well, some of us anyway).
 And, they still have name recognition in the minds of the consuming
 public. They are successful, and that's all ANY company can hope for.

 None of this (lengthy) note is meant to dissuade you from being you. This
 is just my take on the whole Atari situation. This forum needs you. Unlike
 others who continually post messages here that boil down to "Atari sucks,
 and you should never buy their stuff", you provide many though-provoking
 questions and thoughts.  Without you, or someone like you, this forum
 could easily devolve into "Our stuff is the greatest and nothing else
 compares." like some other forums. Yechh!



      There is very little in your observations that I can disagree with. 
 After all, aside from descriptive assertions, we are pretty much in
 agreement.  The only area in which we may fully disagree is the "Atari has
 succeeded" area.  Even there, its only to the point where its my opinion
 that they've succeeded ok, but only as far as survival is concerned.  They
 have not and do not offer any example of having succeeded in a manner we
 are all accustomed to.  

      Atari by its sheer existence at this time has, after so many failed
 computer and game machine releases (ever mindful that the hardware was
 excellent) by their own sheer stupidity in the marketing and public
 relations areas, literally wrote the rule book on magnanimous foot shots. 
 The sad part is, they've apparently learned nothing from their past

      A simple but thorough examination of their PR Firm hiring and
 management policies will quickly show they are still "playing the same
 hire & fire game".  Its obvious they hire these PR firms to satisfy the
 stockholders and use them at the high visibility shows.  Soon thereafter
 the PR firm hits the bricks.  Its hilarious!  No..  Its really quite
 tragic as they are proving beyond a shadow of a doubt they've learned
 nothing by their past mistakes in this area.  In fact, they're blatantly
 giving strong testimony by their performance that they believe they know
 what they are doing.  Its simply incredible.  With Atari, the more things
 change the more they remain the same.

      Thank you for your input and please go easy on the compliments my
 "admirers and cheerleaders" will say I put you up to the praise. <g>
 Thanks again for the fine post.

                                              Ralph Mariano, Editor


 > ONLINE WEEKLY STReport OnLine          The wires are a hummin'!
                            PEOPLE... ARE TALKING
 On CompuServe
 compiled by
 Joe Mirando
 CIS ID: 73637,2262

 Hidi ho friends and neighbors.  I'm hoping that this is only the calm
 before the storm for Jaguar announcements.  It's been quite for a while
 now and it's about time someone did something to shake us all up.  I
 know that most of you aren't really game machine enthusiasts, but you
 really should take a look at the Jag.  Just the things that are
 available now make it a very cool possession, but when you think of all
 the radical new things that are "just around the corner" (voice-modem,
 catbox, virtual reality helmet, the CD-ROM player, JagLink) and the
 prices that they'll be offered at (quite a bit less than similar items
 for other platforms), the Jaguar truly is a great machine.

 It's just too bad that the same can't be said for the computer side of
 Atari.  I was thinking the other day about what it would take to upgrade
 my trusty STe to compete with some of the latest whiz-bang systems out
 there.  Unfortunately, it just ain't gonna happen.  While you _could_
 upgrade the ST series with more memory and a faster, more advanced CPU,
 it would be expensive, and it still wouldn't be as fast as most of the
 current generation of machines out there... while the internal processes
 might be able to compete, the rest of the machine would still slow down
 the 'whole shootin' match'.

 And then there's the software... no Excel, no WordPerfect, no DOS
 upgrades and, perish the thought... no DOOM! (But hey, I've got it on
 the Jaguar and it's even better)

 Then I had a thought (will wonders never cease?)... Do I need new
 software?  I've got everything I currently need and I don't see my needs
 changing anytime soon.  I've got NeoDesk and Geneva, which are more
 compatible with TOS programs than Windows is with DOS programs, I've got
 LDW Works, which does all I need a spreadsheet to do, I've got
 Calligrapher, WordWriter, STWriter, and AtariWorks for all of my word
 processing needs, and I've got literally HUNDREDS of
 shareware/freeware/public domain programs that do all kinds of cool
 things.  Not to mention that I've got my BBS (Transcendence) and a MIDI
 network set up between my STe and STacy for a fraction of what it would
 cost to do those things on that other platform.  Maybe one day I'll get
 tired of my ST, but today is not that day.  I'll use this puppy 'till
 the day it curls up its virtual toes and goes belly-up.  How 'bout you?

 Well, let's take a look at what other people are talking about right
 here on Compuserve...

 From the Atari Computing Forums

 "Asher" posts:

   "I'm new to compuserve and could use some advice. I'm using FLASH and
   am trying to determine the best way to set it up with the service. Can
   I actually see graphics while in VIDTEX mode? I havent any success with
   that yet. I'm using an Atari ST with mono monitor. I would appreciate
   any tips."

 Albert Dayes of Atari Explorer Online Magazine tells Asher:

   "You should be able to see the RLE (run length encoding) type of
   graphics on Compuserve.  If you want to view GIF the only program that
   I know of is Flash II by Missionware that supports online viewing of
   It works very well even in monochrome on my Atari too."

 Sysop Bob Retelle tells Asher:

   "As Albert mentioned, the only online graphics format that the
   original Flash telecom program supported was RLE, a much older format
   than is used these days.
   Flash II, which will display GIF files online is a commercial program
   available from Missionware Software who have a section in the Atari
   Vendors' Forum if you'd like to check out a demonstration version of
   the program.. (unfortunately I don't know if the online viewing is
   enabled in the demo version.)
   Just  GO ATARIVEN  to find them, and they can give you more info about
   the program."

 John Trautschold of Missionware Software tells Bob and Asher:

   "Yes, the 2.21 demo of Flash II does have online GIF viewing enabled."

 I can honestly tell anyone who asks that Flash II is a truly superior
 terminal program (it's one of my two favorites).  The service that
 Missionware offers is superb, and that's always a big consideration.
 Meanwhile, Mark Westendorf asks for help:

   "I am trying to find a zmodem program that will work with Interlink
   ST. I am trying to bring my ST back on line after a lengthy time of
   collecting dust. I forgot a lot about what I learned of the ST.
   Interlink looks for a file that ends in ".txf". Not sure what that is.
   Any help would be appreciated. It seems like I had a file for this
   before but can't find it now."

 Our own Atari Section Editor, Dana Jacobson, tells Mark:

   "When I was an avid Interlink user, I used XYZ.TTP as my zmodem
   transfer program.  You'd need to run it as an external program, but it
   worked very well.  You may also want to consider "trading" Interlink in
   for something more "modern", like Flash II.  It took some doing for me
   to give up Interlink, so I know it might not be easy! <grin>"

 Mark then asks:

   "What is the best way to stay in touch with new programs, etc for the
   ST? I know not much is going on probably, but want to stay in the loop.
   Please let me know."

 Dana tells him:

   "The best way to stay in touch with new (and old) programs is right
   here on Compuserve!  The Atari Forums are a wealth of information and
   the users here are a great help.  Another source, and something that
   you can get right here, are the online magazines.  I'll shamelessly
   plug the one that I'm affiliated with - STReport.  Also, you can find
   Atari Explorer Online mag here also.  STReport is a weekly mag and AEO
   is out every couple of weeks or so.  Both can be found in this Forum,
   or in the Atari Gaming Forum (as well as other CIS areas)."

 And as long as someone mentioned magazines, Rod MacDonald tells Mark:

   "You could also subscribe to ST Informer Magazine, or Current Notes.
   Each is ST Informer is $22 for 12 issues, Current Notes $24 for 6
   issues. They both have extensive reviews of software and releases on
   new products for the Atari. If you need more info, call 1-800-800-2563
   weekdays Noon to 5PM Pacific Time..."

 Asher posts:

   "I've just had the pleasure of using CIM on an IBM clone and all I can
   say to all ATARI die-hards (of which I am one) is: WHAT THE HECK ARE WE
   WAITING FOR!!!????  Lets get with the program here. Or should I say
   lack of programs here. We can emulate and spectre-ate while the others
   just perpetually update."

 Mike Mortilla tells Asher:

   "For what it's worth, I've used CIM on my wife's MAC and hate it.  I
   much prefer manual, even though I can be in "Forum" mode.  Guess I'm an
   old fashion kinda guy...<grin>."

 Greg Kopchak of It's All Relative Software tells Asher:

   "We have CIM on our Pentium here, but to access CIS I always use a
   scripted logon with Flash 1.6. I find it the most efficient way to
   access the service.
   CIM doesn't give me the control I like."

 Benjamin Eby tells Greg:

   "I agree.  I prefer to be in manual mode, because of the flexibility.
   I sometimes access with DOSCIM on my AT&T, but always in terminal mode.
   I like the song, "Don't Fence Me In!"  Once you get the hang of manual
   mode, CIM is a pain in the lower extremities."

 Paul Weinstein asks:

   "Does anyone know the difference between an Atari ST & STe &STf?"

 Sysop Bob Retelle tells Paul:

   "There are only a few differences between all the ST models...
   Generally the ones with an "f" in their model number, ie: 1040STf,
   means that the computer has a built in Floppy drive.
   The "m" in a model number like 520 STfm  means it has an RF Modulator
   that will let you plug the output into a normal TV set instead of using
   a monitor.
   The "e" in 1040STe means the computer is Enhanced.. it has better
   graphics and sound than the previous models, as well as letting you
   expand the memory with industry standard SIMM memory modules.
   Those are only general guidelines.. some models don't follow them,
   like the original  520ST.. it had no internal floppy drive, but it did
   have the RF modulator.
   Is there a specific model you're interested in finding more about..?"

 Jamie Bonk asks:

   "Does anyone know of a way to save Atari files as Mac files or better
   yet have a Mac read Atari files."

 Frank Heller tells Jamie:

   "If I'm not mistaken Oregon Research has a program called DFORMAT.
   They used to ship this with some of their other progams as an "extra".
   There is an AFE (Apple File Exchange) boot sector routine built into
   the early revision of this program (it wasn't on the later ones). works. I have been sending midi files made on my Falcon to
   a pal of mine with a Mac using this program. It works. I'm sure there
   must be some other solutions out there...this is just the one I know

 Boris Molodyi tells Jamie:

   "If your Mac has Superdrive (1.44Meg floppy drive), you can read DOS
   format disks (which Atari also uses) using Apple File Exchange or PC
   Exchange. To make sure that Mac reads those floppies, it is a good idea
   to format them in Apple File Exchange as DOS disks (720K, as most
   Ataris do not have 1.44 drives), and save files on them.
   Whether your application will be able to make any sense of these files,
   depends on actual programs you are using."

 Mike Mortilla tells Boris:

   "I just got my wife a Mac IIsi and I'm running sys 7.5 but can't seem
   to get the PC Xchang to want to look at the floppy.  It LOVES to look
   at the SCSI port (always thinking about sex!) but no interest in a
   Any ideas?  Boy, it's depressing just THINKING about using a MAC

 Boris tells Mike:

   "Hmm, that's strange. What happens when you insert a disk a) formatted
   in DOS format and b) not formatted at all?
   In case a) it should spin the disk for 15 minutes (that's a Mac,
   nothing happens quickly), and mount it on the desktop, with large "PC"
   written over it.  In case b) it should spin for 15 more minutes and ask
   you whether you want to eject the disk or format it. It will give you a
   choice of DOS or Mac formatting.
   If it does not do that, something is wrong.
   I, personally, prefer using old Apple File Exchange rather than PC
   Exchange.  It does not write a ton of Finder comments onto disk, and
   can do some reasonable file conversions in process."

 Craig Harvey at Clear Thinking (the Ed-Hack/Edit-Pro guys) tells Boris:

   "I don't think Apple File Exchange works with System 7.  At work we
   use MacLink Plus or Access to read DOS disks on our Macs."

 Boris replies:

   "AFE is not _supposed_ to work with System 7.5, but this is what I use
   instead of PC Exchange ( I do not like it writing a ton of extra files
   on my disks).  Did not have any problems with it so far..."

 Mike Mortilla tells Boris:

   "An Atari disk won't read.  If I format a PC disk on the Mac the Atari
   will read it. Guess there's some funky something that Atari does in the
   formatting process.
   But back to your ??? The Atari disks spin a bit and then I am given
   the option of formating or ejecting."

 Boris replies:

   "I see. As you know, Atari formats floppies *almost* like DOS does.
   Apple's stuff, however, is far more finicky, in regard to disk format,
   then either Atari or DOS are. Thus, if you format a disk on Mac
   (preformatted disks also seem to work), you should be able to read it
   both on Mac and Atari."

 Mike replies to his reply:

   "Thanks Boris, I finally figured that out! <g>

   Now how do I get PageStream to work on the Mac <g> ...Magic Mac here I

 Jon Sanford jumps in and tells Boris:

   "Hehe... I just told Mike your solution might be his problem.

   Experience should count but compared to opinion & wild guesses it never

   Mac's system 7.5 will read Atari or MS-Dos TEXT files with very little
   problem.  It will format MS-DOS disks I can read on the Atari.  Now U
   can just put the disk in and the system opens it. U can move files
   about.  Write Now or any word processor can import plain text. TEXedit
   a 10$ shareware prg can open almost anything.
   Oh! wait-a-minit! I have a STeMega ..reads 1.44M floppies. If your St
   is the older kind with 720k disks Hummmmm"

 Yves Aubut asks for help in helping out a friend (jeez, haven't you guys
 ever heard the second of five universal truths:  No good deed goes

   "I am looking for a way to help a friend of mine.  I have downloaded a
   word processor from this forum for him.  He does not own a modem.  Now
   I need to transfer it to his computer.  I own an IBM 386 and want to
   transfer a file (.lhz) to his atari.  How can this be done?"

 Good old Albert Dayes of Atari Explorer Online Magazine tells Yves:

   "You can format a 720K floppy on the PC and use it to transfer files
   back and forth with your friend's Atari ST.  You can also download the
   LZH program so you can extract all of the files from the archive also."

 Sysop Bob Retelle tells Yves:

   "As Albert mentioned, the PC and Atari ST share almost exactly the same
   floppy disk format, so you can just put the file you downloaded onto a
   3.5 inch floppy disk and give it to your friend.
   The trick to making it work is to format the floppy disk on the PC,
   and be sure to format it as a 720K disk because the Atari can't read
   High Density disks..
   (The DOS command would be   FORMAT A: /F:720  <--substitute A: or B:)
   Also, as Albert mentioned, you can uncompress the file for your friend
   in case he doesn't have the proper uncompression utility yet.
   In the case of the /LZH file you mentioned, the proper IBM utility
   would be LHA.EXE  which is available in the PC forums if you don't have
   it already. Then you could just copy the uncompressed files to the 720K
   disk, and your friend could use them directly in his Atari disk drive.
   Let us know if you have any questions about any of this.."

 Mike Myers asks for help:

   "What I want to do is weed out a lot of older files, and then compress
   them.  There doesn't seem to be any way it can be done without going
   thru manually, choosing them out and setting them aside for
   compressing. Or am I wrong? Please let it be that I'm wrong."

 Always ready to please, Paul Peeraerts tells Mike:

   "You're wrong. The program Diamond Back lets you copy and compress at
   the same time all files that are older than a definite time. You can
   also manually include or exclude files that you (don't) want to be
   copied and compressed.
   I normally copy from my hard disk to a floppy, but all combinations are
   possible. Unfortunately Diamond Back is "payware". It is sold by Oregon
   Research Associates, CompuServe 71333,2655"

 Mark Westendorf asks:

   "Is it possible to link an Atari Megfile hard drive to an IBM machine
   and its hard drive? Sounds interesting. Anyone have any clues? Please
   let me know."

 Andreas Rosenberg tells Mark:

   "Your proposal depends on how you want to link the hard drives. The
   Megafile contains a RLL hard drive with an ST502 connector. If you like
   to use this drive in your PC you need a controller for this (like OMTI
   5527). But you need to reformat the drive, because the partition info
   between Atari and IBM is different. But I believe that is not the
   solution you had in mind. If you need an easy way to ship greater
   amounts of data between Atari and PC you might use an external SCSI
   drive. You need a SCSI host adapter for the Atari and a SCSI controller
   for the PC. But this doesn't solve the problem of different partition
   tables. I'm currently writting a driver for the Atari that is able to
   handle IBM partition tables. But I ran into problems, because Atari
   and IBM use different ways to handle partitions greater 16MB.
   If you had in mind that both computers might use the same drive at the
   same time, I must tell you that such a thing is not possible.
   Hope, I cleared things a bit."

 Sysop Bob Retelle tells Andreas:

   "I'd thought about hooking up a SCSI drive between my ST and PC, but
   never got around to trying it..
   Your driver sounds like the solution... do you think it would work if
   you were to set up a 16 Meg partition just to use as a transfer space
   between Atari and PC areas on the disk..?
   For that matter, do you think it would be possible to format separate
   Atari and PC areas..?"

 And from our "Reunions With Old Friends" department, Simon Churchill

   "A month ago I left you all due to the loss of the company account and
   am now back to cause no end of hell for you all.   (DOOM fanatic here!)
   So to anyone and everyone please note the change in the number and if
   you would care to send me a ditty or a welcome back for the third and
   probably finale time then your message will be welcomed.
   All messages will get a reply, even if there not printable.  8-)
   But, no more of this noncence, it's time to party, so all meet at my
   place and we will throw down.
   If you need help to throw down then send me a message and I might have
   an answer to your problem.
   See ya round the forum.
   Simon J Churchill. T28, faster than the average PC!"

 Sysop Bob, never being one to miss out on fun, tells Simon:

   "Welcome back, Simon..!
   So the party's at your place, eh..  sounds good to me..!"

 Mike Mortilla adds:

   "Now he's in trouble! 2 Italians!!!!! (count me in!)  ...where's the
   wine (whine?)"

 Hey Simon, make that three Italians!  I'll be there with bells on.  Well
 folks, that's about it for this week.  I tried to get some conversations
 from the Graphics Support Forum, but it was temporarily unavailable...
 that's what I get for waiting 'till the last minute.

 Tune in again next week, same time, same channel, and be prepared to
 listen to what they are saying when...

                             PEOPLE ARE TALKING


                       STReport's "EDITORIAL CARTOON"

 > A "Quotable Quote"        A true "Sign of the Times" 
   """""""""""""""""            A "real" meaning?

                        Of the Republican Contract...

                            Is it _with_ America?
                             Is it _on_ America?

                                                   ... Alphonse C.


                   STReport International OnLine Magazine
                      -* [S]ilicon [T]imes [R]eport *-
 STR OnLine!         "YOUR INDEPENDENT NEWS SOURCE"          March 10, 1995
 Since 1987         copyright   1995 All Rights Reserved            No.1110
 All Items quoted, in whole or in part, are done so under the provisions of
 The  Fair  Use Law of The Copyright Laws of the U.S.A. Views, Opinions and
 Editorial  Articles  presented  herein  are  not  necessarily those of the
 editors/staff  of  STReport  International OnLine Magazine.  Permission to
 reprint    articles  is  hereby granted, unless otherwise noted.  Reprints
 must,  without exception, include the name of the publication, date, issue
 number  and the author's name.  STR, CPU, STReport and/or portions therein
 may  not  be  edited,  used,  duplicated or transmitted in any way without
 prior written permission.  STR, CPU, STReport, at the time of publication,
 is  believed  reasonably  accurate.  STR, CPU, STReport, are trademarks of
 STReport  and  STR  Publishing  Inc.    STR,  CPU, STReport, its staff and
 contributors are not and cannot be held responsible in any way for the use
 or  misuse  of  information  contained  herein  or  the  results  obtained

Return to message index