ST Report: 10-Mar-95 #1110From: Bruce D. Nelson (aa789@cleveland.Freenet.Edu)
Date: 03/19/95-11:39:41 AM Z
- Next message by date: Bruce D. Nelson: "ST Report: 17-Mar-95 #1111"
- Previous message by date: Bruce D. Nelson: "ST Report: 3-Mar-95 #1109"
- Return to Index: Sort by: [ date ] [ author ] [ thread ] [ subject ]
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 ==================== INTERNATIONAL ONLINE MAGAZINE ============================= from 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!" """"""""""""""""" - STR INDUSTRY REPORT - PNG GRAPHIC SPEC - CENSORSHIP? - THUMBS+PLUS v2.0c - CPU CRIME SEMINAR - ALI-BABA NIXED - 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. ========================================================================== CIS ~ DELPHI ~ GENIE ~ BIX ~ FIDO ~ ITC ~ NEST ~ EURONET ~ CIX USENET ~ USPOLNET ~ CLEVELAND FREE-NET ~ INTERNET ~ PROWL ~ FNET ~ AOL ========================================================================== 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 ======================================================================== COMPUSERVE WILL PRESENT $15.00 WORTH OF COMPLIMENTARY ONLINE TIME to the Readers of; STREPORT INTERNATIONAL ONLINE MAGAZINE """""""""""""""""""""""""""""""""""""" "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 and 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 ..bar 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. Ralph... 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 "firstname.lastname@example.org" 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 """"""""""""""" PC SECTION AMIGA SECTION MAC SECTION ATARI SECTION ---------- ------------- ----------- ------------- 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 Internet.............RMARIANO@DELPHI.COM IMPORTANT NOTICE ---------------- 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 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" > STR INDUSTRY REPORT LATE BREAKING INDUSTRY-WIDE NEWS """"""""""""""""""" 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 keyboards. >> 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 Inc. The units will be available later this month in North America through NEC's network of authorized dealers with estimated prices starting at $5,899. >> 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 families. 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 improvements. 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 microprocessor. NexGen says the new chip is scheduled to become available by mid- year. >> 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 program. 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 products. >> 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 locations. 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 electronically." 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 keys. 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 headcount. >> 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 portables. Prices range from $3,999 to $8,399 depending on the user-selected configurations. >> 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 Literature.'" 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." _____________________________________________ > INFO HIGHWAY GRIDLOCK? STR FOCUS! """"""""""""""""""""""""""""""""" SUPREME COURT JUSTICES EXPRESS CONCERN ABOUT COMPUTER PRIVACY; OPINIONS SUGGEST MOUNTING INTEREST ON NATION'S HIGHEST COURT For IMMEDIATE RELEASE 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://aclu.org:6601 | 132 W. 43rd Street, NY, NY 10036 mailto:email@example.com| "Eternal vigilance is the ftp://ftp.pipeline.com | price of liberty" ______________________________________________ > HIDDEN RAMPANT CENSORSHIP? STR FOCUS! """"""""""""""""""""""""""""""""""""" 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 hand. 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. PLEASE, WE NEED EACH OF OUR READERS TO DO THIS NOW.... Here's what you have to do to sign the petition: send an e-mail message to: S314firstname.lastname@example.org 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 """""""""""""""""""""" PNG (PORTABLE NETWORK GRAPHICS) SPECIFICATION, NINTH DRAFT 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. Contents * 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. CHANGES SINCE LAST DRAFT * 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 FINALIZATION SCHEDULE 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 masks). * Gamma (brightness) indication, allowing automatic brightness adjustment. * 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?. PRONUNCIATION 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. INTEGERS AND BYTE ORDER 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. COLOR VALUES 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. IMAGE LAYOUT 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. ALPHA CHANNEL 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. FILTERING 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. INTERLACED DATA ORDER 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 display. row = 0 while row < height begin col = 0 while col < width begin visit (row, col, 1, 1) col = col + 1 end 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 begin visit (row, col, 4, 4) col = col + 4 end row = row + 4 end ; Pass 2 row = 0 while row < height begin col = 2 while col < width begin visit (row, col, 2, 4) col = col + 4 end row = row + 4 end ; Pass 3 row = 2 while row < height begin col = 0 while col < width begin visit (row, col, 2, 2) col = col + 2 end row = row + 4 end ; Pass 4 row = 0 while row < height begin col = 1 while col < width begin visit (row, col, 1, 2) col = col + 2 end row = row + 2 end ; Pass 5 row = 1 while row < height begin col = 0 while col < width begin visit (row, col, 1, 1) col = col + 1 end 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 CORRECTION 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. TEXT STRINGS 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. PNG FILE SIGNATURE 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. CHUNK LAYOUT Each chunk consists of four parts: Length 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. CRC 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 NAMING CONVENTIONS 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 copy 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 modifications. 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. CRC ALGORITHM Chunk CRCs are calculated using standard CRC methods. The CRC polynomial employed is as follows: 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 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. CRITICAL 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. ANCILLARY CHUNKS 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, respectively. 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 contains: 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 display. 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 case-sensitive. 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 meter) Conversion note: one inch is equal to exactly 25,400 micrometers by definition. 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 meter) Conversion note: one inch is equal to exactly 25,400 micrometers by definition. 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. SUMMARY OF STANDARD CHUNKS This table summarizes some properties of the standard chunk types. Name Multiple Ordering constraints OK? 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 ftp.cs.wisc.edu 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 image. 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. FILTER TYPE 0: NONE With the None filter, the scanline is transmitted unmodified; it is only necessary to insert a filter type byte before the data. FILTER TYPE 1: SUB 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 scanline. 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. FILTER TYPE 2: UP 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 scanline. 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. FILTER TYPE 3: AVERAGE 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 operation. 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. FILTER TYPE 4: PAETH 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) begin ; 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 begin return a end if pb <= pc begin return b end return c end 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 recommendations. REGISTERING PROPRIETARY CHUNKS If you want others outside your organization to understand a chunk type that you invent, contact the editor of the PNG specification (email@example.com) 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. BITDEPTH SCALING 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 bits. 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). ENCODER GAMMA HANDLING 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. ALPHA CHANNEL CREATION 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. FILTER SELECTION 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 rare. 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. TEXT CHUNK PROCESSING 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 recommendations. CHUNK ERROR CHECKING Unknown chunk types must be handled as described under Chunk naming conventions. 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. PIXEL DIMENSIONS 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. TRUECOLOR IMAGE HANDLING 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. DECODER GAMMA HANDLING 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 "desired_system_gamma".) 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. ALPHA CHANNEL PROCESSING 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. BACKGROUND COLOR 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. PALETTE HISTOGRAM USAGE 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. TEXT CHUNK PROCESSING 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 characters. 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 begin if BitwiseAND(c, 1) begin xorWith = 0xedb88320 else xorWith = 0 end c = BitwiseExclusiveOR( RightShift(c), xorWith) k = k + 1 end 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. WHY A NEW FILE FORMAT? 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. WHY THESE FEATURES? 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. WHY NOT THESE FEATURES? 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 interchangeability. * 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 representation. * 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. WHY NOT USE FORMAT XYZ? 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 method. 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. BYTE ORDER 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.) WHY GAMMA CORRECTION? 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 capability. 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. FILTERING 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. TEXT STRINGS 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 pick.] PNG FILE SIGNATURE 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. CHUNK LAYOUT 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 anyway. 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 besides). CHUNK NAMING CONVENTIONS 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 appropriately. 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. PALETTE HISTOGRAMS 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 EDITOR: Thomas Boutell, firstname.lastname@example.org CONTRIBUTING EDITOR: Tom Lane, email@example.com AUTHORS: Authors' names are presented in alphabetical order. * Mark Adler, firstname.lastname@example.org * Thomas Boutell, email@example.com * Adam M. Costello, firstname.lastname@example.org * Lee Daniel Crocker, email@example.com * Oliver Fromme, firstname.lastname@example.org * Jean-Loup Gailly, email@example.com * Alex Jakulin, firstname.lastname@example.org * Neal Kettler, email@example.com * Tom Lane, firstname.lastname@example.org * Dave Martindale, email@example.com * Owen Mortenson, firstname.lastname@example.org * Greg Roelofs, email@example.com * Paul Schmidt, firstname.lastname@example.org The authors wish to acknowledge the contributions of the Portable Network Graphics mailing list and the readers of comp.graphics. End of PNG Specification //END QUOTE// ___________________________________________ > FRACTINT VERSION 19 STR InfoFile """""""""""""""""""""""""""""""" FRACTINT VERSION 19 RELEASED IN 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, including: .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 name). + 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 Manager. 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 format. - Specify the desired path and file name prefix. - Useful for screen or window capture too (using PrintScreen and ALT+PrintScreen). - Unobtrusive -- you don't have to activate the program for each capture. 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 program. ++ Automatic (or manual, by directory tree or disk) removal of "orphaned" thumbnails (thumbnails for files which were moved or deleted from another program). ++ 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 name. ++ Selection of files to display, or files to select, by file name mask. ++ Export selected thumbnails to Windows bitmap files. NOTE: ----- 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 vnet.net 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 __________________________________________ > INDEO VIDEO UPDATE! STR InfoFile """""""""""""""""""""""""""""""" 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 (fps). 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 Improvements: ------------- 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 -- V126.96.36.199 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 V188.8.131.52. 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: [drivers] VIDC.RT21=ir21.dll VIDC.YVU9=iyvu9.dll VIDC.IV31=ir32.dll VIDC.IV32=ir32.dll Previously, the recommended system.ini entries for Indeo video R3.1 looked as follows: [drivers] VIDC.RT21=indeov.drv VIDC.YVU9=indeov.drv VIDC.IV31=indeov.drv 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: [GLOBAL] DRIVERS=IV31,RT21,YVU9 [IV31] DEC=ir30.dll [RT21] DEC=ir21_r.dll [YVU9] DEC=ir21_r.dll 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) 356-3600. Updates are also available on Internet at: ftp://ftp.intel.com/pub/IAL/Indeo_video and at http://www.intel.com/IAL/indeo/indeo.html. 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 support. MSVIDEO.DLL Added palette and DCI support. MSVIDEO.NT Updated the Windows NT 3.5 to support 16 bit capture. 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 palette. The net result was 24 bit videos, when played back with a requested palette, were dithered twice. This would compromise the quality of the video. 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. Sincerely, The Video for Windows Team * Other brands and names are the property of their respective owners. ____________________________________________ > SPEED DEMON! STR FOCUS! ZEOS PANTERA 90 W/CORAL MOTHERBOARD """""""""""""""""""""" 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 motherboard. 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. Specifications ============== GENERAL SPECIFICATIONS ---------------------- System 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 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 software. 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 ports. 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 'Plug-and-Play'compatible. 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. MECHANICAL ========== 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. CRITICAL BOARD COMPONENTS 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 MEMORY Base 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. Expansion 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. Cache 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 BIOS AND SETUP Version ---------------------- 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. FUNCTIONAL 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 dependent. 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. Security Built in BIOS level password is provided. An optional hardware keyboard lock may be implemented. ENVIRONMENTAL Temperature Operation.................. 5C to 35C Storage/Transportation..... 20C to 60C Humidity 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 FARGO PRIMERA PRO COLOR PRINTERS - 600DPI 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) > COMPUTER CRIME AND COUNTERMEASURES STR InfoFile """"""""""""""""""""""""""""""""""""""""""""""" COMPUTER CRIME AND COUNTERMEASURES 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 participants. 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 magazine. 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 EMail: email@example.com MAIL: NCSA 10 S. Courthouse Ave. Carlisle, PA 17013 FEE --- 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 (1)NAME_________________________________________________________ (2)NAME_________________________________________________________ (3)NAME_________________________________________________________ Organization____________________________________________________ Address_________________________________________________________ ________________________________________________________________ City____________________________________________________________ State/Zip_______________________________________________________ Phone_________________________ Fax_____________________________ Email Address___________________________________________________ COMPUTER CRIME AND COUNTERMEASURES - ON-LINE SEMINAR 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 seminar. Group Discount Schedule: 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. PLEASE TAKE A MOMENT TO TELL US HOW YOU HEARD ABOUT THE SEMINAR: ___ 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 EMail: firstname.lastname@example.org ********************************************************************** 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 then... When connected, press RETURN once or twice and... 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 INTJET.TXT file. ************************************************************ 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 """"""""""""""""""""""""" ~~ NEWS RELEASE ~~ NEWS RELEASE ~~ NEWS RELEASE ~~ NEWS RELEASE ~~ 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 gradient. 6. Uniframes, i.e.; StarScreened frames, can now be used inside vector objects. 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 spacing. 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. ~~ NEWS RELEASE ~~ NEWS RELEASE ~~ NEWS RELEASE ~~ NEWS RELEASE ~~ 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 available. 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 included. 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!! ****************************************************** NEWS RELEASE 15: THE TORONTO ATARI FEDERATION PRESENTS - ACE '95!! ****************************************************** _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/ _/_/ _/_/_/_/ _/_/_/_/_/ _/_/ _/_/_/_/_/_/ _/_/_/_/_/_/ 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 ========================================================= LLLLLLLL EVERYTHING GREAT UNDER THE ATARI SUN! LLLLLLLL 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! LLLLLLLLLLLLL ABC Solutions! LLLLLLLLLLLLLL Esquimalt Digital Logic (OMEN)! LLLLLLLLLLLLLLL GEnie Information Services! LLLLLLLLLLLLLLLL Suzy B's Software (& CDs)! LLLLLLLLLLLLLLLLL chro_Magic! LLLLLLLLLLLLLLLLLL Clear Thinking! LLLLLLLLLLLLLLLLLLL Schauzmoll Software (The first GUI BBS)! LLLLLLLLLLLLLLLLLLLL Anodyne Software (ExtenDOS)! LLLLLLLLLLLLLLLLLLLLL Oregon Research Associates! LLLLLLLLLLLLLLLLLLLLLL Computer Direct! (DirecTT030 & an LLLLLLLLLLLLLLLLLLLLLLL enormous lineup of Atari products!) LLLLLLLLLLLLLLLLLLLLLL Binary Sounds! 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!) ******* CHECK OUT OUR World Wide Web PAGES: http://www.io.org/taf.html ******* or http://www.io.org/ace.html ******* 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, INCREDIBLE SALE PRICES, Software, Hardware, and EVERYTHING you 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! ================================================ BOOK YOUR HOTEL & YOUR TICKETS IN ADVANCE! Call 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 A ROOM WITH THE TORONTO ATARI FEDERATION GROUP! ** 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 - email@example.com firstname.lastname@example.org email@example.com TAF Online - Howard. Carson =end= ________________________________________ > 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 features: 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 America). 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 EMail firstname.lastname@example.org Mail 11034 East 40 Highway Independence MO 64055 USA Obsession ~~~~~~~~~ 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 more... 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 ST/TT/Falcon. 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 ~~~~~~ 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 internet: email@example.com 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: ______________________________________ Address:______________________________________ ______________________________________ ______________________________________ Phone: ______________________________________ Payment: 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 card. 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 powerful. 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 exchange." -/- 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 communications." 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 Japan. "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 survey. 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 products?! 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 change] _____________________________________________ > 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 software. 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: Sb: #73218-#ULTRA VORTEX (ANY GOOD?) 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 more! 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: rec.games.video.atari reorganization Newsgroup: rec.games.video.atari.digest 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 rec.games.video.atari to rec.games.video.atari.discuss and a unique moderation procedure. Proponent: <Chris K. Brown> firstname.lastname@example.org REQUEST FOR DISCUSSION: This is a formal request for discussion (RFD) for the creation of the moderated newsgroup rec.games.video.atari.digest and the renaming of rec.games.video.atari to rec.games.video.atari.discuss. This request is being cross-posted to: news.announce.newgroups news.groups rec.games.video.atari rec.games.video.misc alt.atari-jaguar.discussion Follow-ups are directed to news.groups. This formal request for discussion takes place because of the very low "signal to noise" ratio on rec.games.video.atari. 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 moderator(s). Guidance on this proposal has also came from email@example.com. PROPOSAL: The two parts of this proposal are INDEPENDENT and will be voted on SEPARATELY. Part 1 Create a newsgroup rec.games.video.atari.digest ------------------------------------------------------ Group: The proposed group is rec.games.video.atari.digest [moderated]. Distribution: World Summary line: Discussion of Atari and current and future Atari video game products. Charter: rec.games.video.atari.digest [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 rec.games.video.atari (rec.games.video.atari.discuss if the second part of this proposal passes) will be considered by the moderator(s) for r.g.v.a.digest. Articles 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 <firstname.lastname@example.org> 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 rec.games.video.atari ------------------------------------ Group: rename rec.games.video.atari to rec.games.video.atari.discuss The summary line, distribution and charter of the new group rec.games.video.atari.discuss would be unchanged from those currently in existence for rec.games.video.atari. This change is solely for the purpose of maintaining the structure of the name space. Proposed by: Chris K. Brown <email@example.com> All aspects of the proposal are still open for debate and discussion. All useful suggestions are welcomed. PROCEDURE: 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 <firstname.lastname@example.org>, last modified 18 Jan 1995). Please refer to this article if you have any questions about the newsgroup creation. 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 rec.games.video.atari.digest and 2) rename rec.games.video.atari to rec.games.video.atari.discuss 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 help. GAME OVERVIEW 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. RACING AND GAME PLAY 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 better. SOME DISLIKES 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. CONCLUSION 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. Ralph; 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 money. 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 it. 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! Tony Anthony, 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 experiences. 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 GIFs. 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). Anyway...it 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 about." 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 floppy! Any ideas? Boy, it's depressing just THINKING about using a MAC <grin>." 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 come!" 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 wins. 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 unpunished?): "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 posts: "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? OR Is it _on_ America? ... Alphonse C. """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" STReport International OnLine Magazine -* [S]ilicon [T]imes [R]eport *- AVAILABLE WORLDWIDE ON OVER 70,000 PRIVATE BBS SYSTEMS """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 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 therefrom. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
- Next message by date: Bruce D. Nelson: "ST Report: 17-Mar-95 #1111"
- Previous message by date: Bruce D. Nelson: "ST Report: 3-Mar-95 #1109"
----------------------------------------- Return to message index