*---== CPU NEWSWIRE ONLINE MAGAZINE ==---* """""""""""""""""""""""""""" "The Original 16/32bit Online Magazine" _____________________________________ from STR Publishing Inc. """""""""""""""""" February 23, 1990 No.4.08 ======================================================================= CPU NewsWire Online Magazine¿ featuring STReport ~ Online¿ __________________________ Post Office Box 6672 Jacksonville, Florida 32205 ~ 6672 R.F. Mariano Publisher - Editor _________________________________________ Voice: 904-783-3319 10 AM - 4 PM EDT BBS: 904-786-4176 12-24-96 HST/14.4 FAX: 904-783-3319 12 AM - 6 AM EDT _________________________________________ ** F-NET NODE 350 ** 500mb Online ** STR'S owned & operated support BBS carries ALL issues of CPU/STR Newswire¿ and An International list of private BBS systems carrying CPU NewsWire for their users enjoyment __________________________________________________________________ > 02/23/90: CPU Newswire¿ #408 The Original 16/32 bit Online Magazine! ---------------------------- - The Editor's Podium - CPU REPORT - CPU STATUS REPORT - THE ICD ADVANTAGE!! - The ALTERNATIVE - Vector Intercepts - PCD2 HELP! - NASA Schedules - CRASWELL Interview - CIS NEW FileFinder - DynaCADD p V - CPU CONFIDENTIAL ---===*** ICD UNVEILS SUPERB NEW PRODUCTS ***===--- ---===** HOW DO YOU SPELL RELIEF? AG ONLINE! **===--- ---====*** BIG ATARI DEALERS UPSET - READY TO QUIT! ***====--- ========================================================================== CPU NEWSWIRE¿ "Only UP-TO-DATE News and Information" -* FEATURING *- Current Events, Up to Date News, Hot Tips, and Information Hardware - Software - Corporate - R & D - Imports ========================================================================== CPU/STR's support BBS, NODE # 350 invites systems using Forem ST BBS to participate in Forem BBS's F-Net mail network. Or, Please call # 350 direct at 904-786-4176, and enjoy the excitement of exchanging ideas about the Atari ST computers through an excellent International ST Mail Network. ========================================================================== AVAILABLE ON: COMP-U-SERVE ~ DELPHI ~ GENIE ~ BIX ========================================================================== > The Editor's Podium¿ Atari offers the STE, the Megafile 44 and the Stacy for sale all over the globe but not in the USA WHY?? Not that its any great news or anything like that, but we make mention of this item to point out another nail in the coffin being built by Atari US called the US market. Their operations in the US market have been abominable. Seriously, though, if I don't laugh at their actions in the USA, I'd find it so very easy to cry! What in heaven's name are they trying to do? Kill this market, a market they have half dead already? Can the rumors of an exodus be true? Is Atari going belly up in the US computer market because they can't compete? Is it all over but the shouting? What is on the horizon for the US ST Userbase. The time is at hand for some real answers from Atari. We (the users) don't see any substantial advertising. Dealers across the country are upset that they cannot get or sell the Lynx. And now, for the best yet is they (dealers) cannot offer the same "thirty day satisfaction Guarantee" the factory does on the sales of Portfolios. Clearly, Atari needs real direction, the first quarter of 1990 is a dead duck, what have they in store for the rest of the year? They are not attending Spring Comdex, at least the new president of Atari US will have a better chance of seeing Fall/Comdex.. Any bets?? Now, we find that they are trying to tell us that an ex-executive from the beverage industry who is heading up the combined Entertainment and Computer division in the USA is just what the doctor ordered. Sounds more like a plumber operating in neurosurgery! The only way I see this being a positive move is if he drowns the incompetents, in Sunnyvale who are killing Atari, in a pool of benzene tainted vichy water. The constant flow of disappointment after disappointment must come to an end. Maybe the Aircraft Carrier really did sink! The above sounds so very terminal and upsetting, well it is! Call your local dealer and ask if they are happy with the relationship they have with Atari Corp. That is, if there is a dealer in your area.... I, for one, am very uncomfortable with the thought that a few concerned developers are heavily burdened with the decision of whether or not the new Mega STE will have the MEGA bus or the VME bus. Please, before anybody gets their wig bent outta shape, the whole matter is being openly discussed online. Sorry guys, but this type of thing belongs in a questionnaire that the ENTIRE USERBASE can participate in. Atari has got to learn that the road to success in the US marketplace is paved with satisfaction on both sides of the fence. Not just a one-sided affair as it is now. All Europe and nuthin' much for the US. It really has gotten to the point where everytime I hear or read a press release coming from Atari, I think of lawyers, you know, (How do you tell a lawyer is lying? ..His lips are moving!) It truly has gotten to this. One cannot trust what Atari says, usually, its denied the following week. I am down on the present leadership of Atari, I feel they are misleading the Tramiels in a most "officious" manner. Something has to be done. And it must be done fast. The latest rumor in the executive recruitment field is; Go with Atari, its only for a short while and the titles look great on your resume. sheesh! Ralph....... ********************************************************************** :HOW TO GET YOUR OWN GENIE ACCOUNT: _________________________________ To sign up for GEnie service: Call: (with modem) 800-638-8369. Upon connection type HHH (RETURN after that). Wait for the U#= prompt. Type: XTX99587,CPUREPT then, hit RETURN. **** SIGN UP FEE WAIVED **** The system will now prompt you for your information. THE GENIE ATARI ST ROUNDTABLE - AN OVERVIEW ___________________________________________ The Roundtable is an area of GEnie specifically set aside for owners and users of Atari ST computers, although all are welcome to participate. There are three main sections to the Roundtable: the Bulletin Board, the Software Library and the Real Time Conference area. The Bulletin Board contains messages from Roundtable members on a variety of Topics, organized under several Categories. These messages are all Open and available for all to read (GEnie Mail should be used for private messages). If you have a question, comment, hot rumor or an answer to someone else's question, the Bulletin Board is the place to share it. The Software Library is where we keep the Public Domain software files that are available to all Roundtable members. You can 'download' any of these files to your own computer system by using a Terminal Program which uses the 'XMODEM' file-transfer method. You can also share your favorite Public Domain programs and files with other Roundtable members by 'uploading' them to the Software Library. Uploading on GEnie is FREE, so you are encouraged to participate and help your Roundtable grow. The Real Time Conference is an area where two or more Roundtable members may get together and 'talk' in 'real-time'. You can participate in organized conferences with special guests, drop in on our weekly Open COnference, or simply join in on an impromptu chat session. Unlike posting messages or Mail for other members to read at some later time, everyone in the Conference area can see what you type immediately, and can respond to you right away, in an 'electronic conversation'. ********************************************************************** > CPU REPORT¿ ========== Issue # 55 By Michael Arthur Remember When.... A company named Metacomco developed a Unix-based operating system based on the 68000 chip, and when in late 1984, Commodore (after firing several of Amiga Corp.'s developers who had been designing an OS around the Exec multitasking OS Kernel), realized that they needed to have a complete OS for the Amiga within 6 months in order to introduce it, and hired Metacomco to "quickly" port what became AmigaDOS to the Amiga? And remember when a group of Amiga developers designed a toolkit called the AmigaDOS Replacement Project, so as to provide a work around for the crippling problems with AmigaDOS, which arose in the "quick" porting process? CPU INSIGHTS¿ ============= FSF, The Hacker Ethic, and The GNU Manifesto -------------------------------------------- In the late 1970s, as the microcomputer industry began to develop, many programmers and computer experts believed that computers were a tool for exchanging information, and that this "information flow" should not be hindered or restricted. This belief in the "freedom of information exchange" became part of what was known as the "Hacker Ethic". This was when the word "hacker" was used to honor and praise a computer "guru" for his abilities.... Richard Stallman, who designed the well-known EMACS text editor in the 1970s, decided to create the Free Software Foundation as part of an effort to place standards in computer software and operating environments in the public domain, where this information could benefit all. The FSF soon began the GNU Project, whose goals were to establish an operating system environment, Unix utilities, and software which would be placed in the public domain, available for all to use. Here is an essay written by Richard Stallman when he established the GNU Project, which not only explains the goals of the FSF, but provide some insight into the ideals behind the "Hacker Ethic".... The GNU Manifesto """"""""""""""""" by Richard M. Stallman What's GNU? Gnu's Not Unix! GNU, which stands for Gnu's Not Unix, is the name for the complete Unix-compatible software system which I am writing so that I can give source level debugger, a yacc-compatible parser generator, a linker, and around 35 utilities. A shell (command interpreter) is nearly completed. A new portable optimizing C compiler has compiled itself and may be released this year. An initial kernel exists but many more features are needed to emulate Unix. When the kernel and compiler are finished, it will be possible to distribute a GNU system suitable for program development. We will use TeX as our text formatter, but an nroff (Note: A Unix text editor) is being worked on. We will use the free, portable X/Windows system as well. After this we will add a portable Common Lisp, an Empire game, a spreadsheet, and hundreds of other things, plus on-line documentation. We hope to supply, eventually, everything useful that normally comes with a Unix system, and more. GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems. In particular, we plan to have longer filenames, file version numbers, a crashproof file system, filename completion perhaps, terminal-independent display support, and perhaps eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages. We will try to support UUCP, MIT Chaosnet, and Internet protocols for communication. GNU is aimed initially at machines in the 68000/16000 class with virtual memory, because they are the easiest machines to make it run on. The extra effort to make it run on smaller machines will be left to someone who wants to use it on them. To avoid horrible confusion, please pronounce the `G' in the word `GNU' when it is the name of this project. Who Am I? I am Richard Stallman, inventor of the original, much-imitated EMACS editor, formerly at the Artificial Intelligence Lab at MIT. I have worked extensively on compilers, editors, debuggers, command interpreters, the Incompatible Timesharing System and the Lisp Machine operating system. I pioneered terminal-independent display support in ITS. Since then I have implemented one crashproof file system and two window systems for Lisp machines, and designed a third window system now being implemented; this one will be ported to many systems including use in GNU. [Historical note: The window system project was not completed; GNU now plans to use the X/Windows system.] Why I Must Write GNU.. I consider that the golden rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement. For years I worked within the Artificial Intelligence Lab to resist such tendencies and other inhospitalities, but eventually they had gone too far: I could not remain in an institution where such things are done for me against my will. So that I can continue to use computers without dishonor, I have decided to put together a sufficient body of free software so that I will be able to get along without any software that is not free. I have resigned from the AI Lab to deny MIT any legal excuse to prevent me from giving GNU away. Why GNU Will Be Compatible with Unix.. Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt. How GNU Will Be Available.. GNU is not in the public domain. Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution. That is to say, proprietary modifications will not be allowed. I want to make sure that all versions of GNU remain free. Why Many Other Programmers Want to Help.. I have found many other programmers who are excited about GNU and want to help. Many programmers are unhappy about the commercialization of system software. It may enable them to make more money, but it requires them to feel in conflict with other programmers in general rather than feel as comrades. The fundamental act of friendship among programmers is the sharing of programs; marketing arrangements now typically used essentially forbid programmers to treat others as friends. The purchaser of software must choose between friendship and obeying the law. Naturally, many decide that friendship is more important. But those who believe in law often do not feel at ease with either choice. They become cynical and think that programming is just a way of making money. By working on and using GNU rather than proprietary programs, we can be hospitable to everyone and obey the law. In addition, GNU serves as an example to inspire and a banner to rally others to join us in sharing. This can give us a feeling of harmony which is impossible if we use software that is not free. For about half the programmers I talk to, this is an important happiness that money cannot replace. How You Can Contribute.. I am asking computer manufacturers for donations of machines and money. I'm asking individuals for donations of programs and work. One consequence you can expect if you donate machines is that GNU will run on them at an early date. The machines should be complete, ready to use systems, approved for use in a residential area, and not in need of sophisticated cooling or power. I have found very many programmers eager to contribute part-time work for GNU. For most projects, such part-time distributed work would be very hard to coordinate; the independently-written parts would not work together. But for the particular task of replacing Unix, this problem is absent. A complete Unix system contains hundreds of utility programs, each of which is documented separately. Most interface specifications are fixed by Unix compatibility. If each contributor can write a compatible replacement for a single Unix utility, and make it work properly in place of the original on a Unix system, then these utilities will work right when put together. Even allowing for Murphy to create a few unexpected problems, assembling these components will be a feasible task. (The kernel will require closer communication and will be worked on by a small, tight group.) If I get donations of money, I may be able to hire a few people full or part time. The salary won't be high by programmers' standards, but I'm looking for people for whom building community spirit is as important as making money. I view this as a way of enabling dedicated people to devote their full energies to working on GNU by sparing them the need to make a living in another way. Why All Computer Users Will Benefit.. Once GNU is written, everyone will be able to obtain good system software free, just like air. This means much more than just saving everyone the price of a Unix license. It means that much wasteful duplication of system programming effort will be avoided. This effort can go instead into advancing the state of the art. Complete system sources will be available to everyone. As a result, a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes. Schools will be able to provide a much more educational environment by encouraging all students to study and improve the system code.Harvard's computer lab used to have the policy that no program could be installed on the system if its sources were not on public display, and upheld it by actually refusing to install certain programs. I was very much inspired by this. Finally, the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted. Arrangements to make people pay for using a program, including licensing of copies, always incur a tremendous cost to society through the cumbersome mechanisms necessary to figure out how much (that is, which programs) a person must pay for. And only a police state can force everyone to obey them. Consider a space station where air must be manufactured at great cost: charging each breather per liter of air may be fair, but wearing the metered gas mask all day and all night is intolerable even if everyone can afford to pay the air bill. And the TV cameras everywhere to see if you ever take the mask off are outrageous. It's better to support the air plant with a head tax and chuck the masks. Copying all or parts of a program is as natural to a programmer as breathing, and as productive. It ought to be as free. Some Easily Rebutted Objections to GNU's Goals.. "Nobody will use it if it is free, because that means they can't rely on any support." "You have to charge for the program to pay for providing the support." If people would rather pay for GNU plus service than get GNU free without service, a company to provide just service to people who have obtained GNU free ought to be profitable. We must distinguish between support in the form of real programming work and mere hand-holding. The former is something one cannot rely on from a software vendor. If your problem is not shared by enough people, the vendor will tell you to get lost. If your business needs to be able to rely on support, the only way is to have all the necessary sources and tools. Then you can hire any available person to fix your problem; you are not at the mercy of any individual. With Unix, the price of sources puts this out of consideration for most businesses. With GNU this will be easy. It is still possible for there to be no available competent person, but this problem cannot be blamed on distribution arrangements. GNU does not eliminate all the world's problems, only some of them. Meanwhile, the users who know nothing about computers need hand-holding: doing things for them which they could easily do themselves but don't know how. Such services could be provided by companies that sell just hand-holding and repair service. If it is true that users would rather spend money and get a product with service, they will also be willing to buy the service having got the product free. The service companies will compete in quality and price; users will not be tied to any particular one. Meanwhile, those of us who don't need the service should be able to use the program without paying for the service. "You cannot reach many people without advertising, and you must charge for the program to support that." "It's no use advertising a program people can get free." There are various forms of free or inexpensive publicity that can be used to inform numbers of computer users about something like GNU. But it may be true that one can reach more microcomputer users with advertising. If this is really so, a business which advertises the service of copying and mailing GNU for a fee ought to be successful enough to pay for its advertising and more. This way, only the users who benefit from the advertising pay for it. On the other hand, if many people get GNU from their friends, and such companies don't succeed, this will show that advertising was not really necessary to spread GNU. Why is it that free market advocates don't want to let the free market decide this? "My company needs a proprietary operating system to get a competitive edge." GNU will remove operating system software from the realm of competition. You will not be able to get an edge in this area, but neither will your competitors be able to get an edge over you. You and they will compete in other areas, while benefitting mutually in this one. If your business is selling an operating system, you will not like GNU, but that's tough on you. If your business is something else, GNU can save you from being pushed into the expensive business of selling operating systems. I would like to see GNU development supported by gifts from many manufacturers and users, reducing the cost to each. "Don't programmers deserve a reward for their creativity?" If anything deserves a reward, it is social contribution. Creativity can be a social contribution, but only in so far as society is free to use the results. If programmers deserve to be rewarded for creating innovative programs, by the same token they deserve to be punished if they restrict the use of these programs. "Shouldn't a programmer be able to ask for a reward for his creativity?" There is nothing wrong with wanting pay for work, or seeking to maximize one's income, as long as one does not use means that are destructive. But the means customary in the field of software today are based on destruction. Extracting money from users of a program by restricting their use of it is destructive because the restrictions reduce the amount and the ways that the program can be used. This reduces the amount of wealth that humanity derives from the program. When there is a deliberate choice to restrict, the harmful consequences are deliberate destruction. The reason a good citizen does not use such destructive means to become wealthier is that, if everyone did so, we would all become poorer from the mutual destructiveness. This is Kantian ethics; or, the Golden Rule. Since I do not like the consequences that result if everyone hoards information, I am required to consider it wrong for one to do so. Specifically, the desire to be rewarded for one's creativity does not justify depriving the world in general of all or part of that creativity. "Won't programmers starve?" I could answer that nobody is forced to be a programmer. Most of us cannot manage to get any money for standing on the street and making faces. But we are not, as a result, condemned to spend our lives standing on the street making faces, and starving. We do something else. But that is the wrong answer because it accepts the questioner's implicit assumption: that without ownership of software, programmers cannot possibly be paid a cent. Supposedly it is all or nothing. The real reason programmers will not starve is that it will still be possible for them to get paid for programming; just not paid as much as now. Restricting copying is not the only basis for business in software. It is the most common basis because it brings in the most money. If it were prohibited, or rejected by the customer, software business would move to other bases of organization which are now used less often. There are always numerous ways to organize any kind of business. Probably programming will not be as lucrative on the new basis as it is now. But that is not an argument against the change. It is not considered an injustice that sales clerks make the salaries that they now do. If programmers made the same, that would not be an injustice either. (In practice they would still make considerably more than that.) "Don't people have a right to control how their creativity is used?" "Control over the use of one's ideas" really constitutes control over other people's lives; and it is usually used to make their lives more difficult. People who have studied the issue of intellectual property rights carefully (such as lawyers) say that there is no intrinsic right to intellectual property. The kinds of supposed intellectual property rights that the government recognizes were created by specific acts of legislation for specific purposes. For example, the patent system was established to encourage inventors to disclose the details of their inventions. Its purpose was to help society rather than to help inventors. At the time, the life span of 17 years for a patent was short compared with the rate of advance of the state of the art. Since patents are an issue only among manufacturers, for whom the cost and effort of a license agreement are small compared with setting up production, the patents often do not do much harm. They do not obstruct most individuals who use patented products. The idea of copyright did not exist in ancient times, when authors frequently copied other authors at length in works of non-fiction. This practice was useful, and is the only way many authors' works have survived even in part. The copyright system was created expressly for the purpose of encouraging authorship. In the domain for which it was invented -- books, which could be copied economically only on a printing press-- it did little harm, and did not obstruct most of the individuals who read the books. All intellectual property rights are just licenses granted by society because it was thought, rightly or wrongly, that society as a whole would benefit by granting them. But in any particular situation, we have to ask: Are we really better off granting such license? What kind of act are we licensing a person to do? The case of programs today is very different from that of books a hundred years ago. The fact that the easiest way to copy a program is from one neighbor to another, the fact that a program has both source code and object code which are distinct, and the fact that a program is used rather than read and enjoyed, combine to create a situation in which a person who enforces a copyright is harming society as a whole both materially and spiritually; in which a person should not do so regardless of whether the law enables him to. "Competition makes things get done better." The paradigm of competition is a race: by rewarding the winner, we encourage everyone to run faster. When capitalism really works this way, it does a good job; but its defenders are wrong in assuming it always works this way. If the runners forget why the reward is offered and become intent on winning, no matter how, they may find other strategies - such as, attacking other runners. If the runners get into a fist fight, they will all finish late. Proprietary and secret software is the moral equivalent of runners in a fist fight. Sad to say, the only referee we've got does not seem to object to fights; he just regulates them ("For every ten yards you run, you are allowed one kick."). He really ought to break them up, and penalize runners for even trying to fight. "Won't everyone stop programming without a monetary incentive?" Actually, many people will program with absolutely no monetary incentive. Programming has an irresistible fascination for some people, usually the people who are best at it. There is no shortage of professional musicians who keep at it even though they have no hope of making a living that way. But really this question, though commonly asked, is not appropriate to the situation. Pay for programmers will not disappear, only become less. So the right question is, will anyone program with a reduced monetary incentive? My experience shows that they will. For more than ten years, many of the world's best programmers worked at the Artificial Intelligence Lab for far less money than they could have had anywhere else. They got many kinds of non-monetary rewards: fame and appreciation, for example. And creativity is also fun, a reward in itself. Then most of them left when offered a chance to do the same interesting work for a lot of money. What the facts show is that people will program for reasons other than riches; but if given a chance to make a lot of money as well, they will come to expect and demand it. Low-paying organizations do poorly in competition with high-paying ones, but they do not have to do badly if the high-paying ones are banned. "We need the programmers desperately. If they demand that we stop helping our neighbors, we have to obey." You're never so desperate that you have to obey this sort of demand. Remember: millions for defense, but not a cent for tribute! "Programmers need to make a living somehow." In the short run, this is true. However, there are plenty of ways that programmers could make a living without selling the right to use a program. This way is customary now because it brings programmers and businessmen the most money, not because it is the only way to make a living. It is easy to find other ways if you want to find them. Here are a number of examples. - A manufacturer introducing a new computer will pay for the porting of operating systems onto the new hardware. - The sale of teaching, hand-holding and maintenance services could also employ programmers. - People with new ideas could distribute programs as freeware, asking for donations from satisfied users, or selling hand-holding services. I have met people who are already working this way successfully. - Users with related needs can form users' groups, and pay dues. A group would contract with programming companies to write programs that the group's members would like to use. All sorts of development can be funded with a Software Tax: Suppose everyone who buys a computer has to pay x percent of the price as a software tax. The government gives this to an agency like the NSF (the National Science Foundation) to spend on software development. But if the computer buyer makes a donation to software development himself, he can take a credit against the tax. He can donate to the project of his own choosing--often, chosen because he hopes to use the results when it is done. He can take a credit for any amount of donation up to the total tax he had to pay. The total tax rate could be decided by a vote of the payers of the tax, weighted according to the amount they will be taxed on. The consequences: * the computer-using community supports software development. * this community decides what level of support is needed. * users who care which projects their share is spent on can choose this for themselves. In the long run, making programs free is a step toward the post- carcity world, where nobody will have to work very hard just to make a living. People will be free to devote themselves to activities that are fun, such as programming, after spending the necessary ten hours a week on required tasks such as legislation, family counseling, robot repair and asteroid prospecting. There will be no need to be able to make a living from programming. We have already greatly reduced the amount of work that the whole society must do for its actual productivity, but only a little of this has translated itself into leisure for workers because much nonproductive activity is required to accompany productive activity. The main causes of this are bureaucracy and isometric struggles against competition. Free software will greatly reduce these drains in the area of software production. We must do this, in order for technical gains in productivity to translate into less work for us. Copyright ½ 1985 Richard M. Stallman Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Modified versions may not be made. ------------ The GNU Project is funded primarily by grants from companies such as Hewlett Packard, the Open Software Foundation, and NeXT Inc. The ongoing results of this endeavor, such as the GNU C Compiler and GNU Emacs, are arguably some of the best software programs available in the industry. It seems that while the ideals of the Free Software Foundation may not truly be implementable in today's increasingly business-oriented computer industry. However, the continuing support of Richard Stallman's work, as well as the beliefs exemplified by the GNU Project, hold many implications about the attitudes and practices which have formed the present state of the computer industry.... But ponder, if you will, this question: 1) Are there any aspects of the Free Software Foundation's beliefs which are feasible enough to be widely implemented throughout the computer industry? ---===***===--- > CPU STATUS REPORT¿ >>> INDUSTRY-WIDE LATE BREAKING NEWS & VIEWS <<< ================= - Cupertino, CA ** APPLE LAYS OFF 400 AS FINANCIAL SLOWDOWN CONTINUES ** ------------- In its first such measure since 1985, Apple has laid off over 400 employees in several Apple divisions, including Customer Service, Finance, and Apple USA Marketing and Distribution. These employees will receive severance pay, and the services of a Transition Resource Center to help with job counseling. Interestingly enough, Apple is going to continue hiring efforts for Apple's R&D and USA Sales Divisions, as well as in their European and Asian operations. Also, it seems that some Apple employees are upset over the monetary size of special "bonus" packages being given to current and departing Apple execs in Upper Management.... - Fremont, CA *** NEXT SELLS IN ENGLAND, LOSES TOP MARKETING HEAD *** ----------- Businessland has announced that it is selling NeXT Computers in England. Per the terms of NeXT Inc.'s agreement with Businessland, they will have exclusive sales rights for the NeXT Computer in Britain. Also, Dan'l Lewin, NeXT's former Chief Marketing Officer, recently left NeXT Inc. to handle the marketing efforts of Go Corporation, another upcoming computer company startup.... - Washington, DC ***** OZONE LAYER SAVED? ***** -------------- The Environmental Protection Agency has recently approved a compound which can replace the use of chlorofluorocarbons (CFC's) in chemicals. While such chemicals are now used heavily for industrial purposes (in freon and in cooling computers, for example), they also cause serious damage to the Earth's Ozone layer. Called Genesolv 2010, this chemical (made of HCFC's, or hydrochlorofluorocarbons) has been determined to not cause damage to the ozone layer. The EPA is now continuing further testing, in order to verify these findings.... - Osaka, Japan ** MATSUSHITA MAKES 64-BIT VERSION OF SUN'S SPARC CHIP ** ------------ Matsushita, parent company of Mitsubishi, has developed a 64-bit version of Sun's SPARC (Scalable Processor ARChitecture) RISC chip, which is capable of running at up to 80 MIPS. Designed by Solbourne Computer, who plans to make clones of Sun's SPARCStation line using the chip, this version of the SPARC chip uses 1 million transistors in combining a 32-bit CPU, a Floating Point chip, and a 64-bit bus controller on one chip. Given that Sun originally licensed out the SPARC chip to just generate industry support for it, and the possibility of a Sun clone on the horizon.... Errata: CPU Report Issue 54 stated that Frank Loren was Apple's new COO ======= (Chief Operating Officer). Michael Spindler is actually their COO, while Alan Z. Loren, Apple's former sales and marketing head, recently resigned from Apple. Also, Jean Louis Gassee has expressed his intentions to soon resign from Apple.... ____________________________________________________________ > ICD LEADS the WAY! CPU/STR InfoFile¿ The ICD Advantage =================================== :The ICD Advantage: ================= Totally NEW AND UNIQUE designs to answer all your SCSI needs. Since 1984, ICD has been providing Atari owners with innovative and superior peripherals and enhancements for their computing needs. ICD products have always added value and performance to computer systems. In 1987 ICD introduced their SCSI ST Host Adapter, defining a new market for third party hard drives and setting the standard for DMA daisy chaining. ICD's progressive vision continues in 1990. This year they are introducing the NEW ADVANTAGE SCSI PRODUCTS FOR ATARI, AMIGA, APPLE, MACINTOSH, AND IBM PC/AT COMPUTERS. This introduction includes three totally new SCSI designs for the Atari ST market which are available now. ICD has also developed new versions of our ST Host Adapter software. New features have been added in response to your needs. What this means to you, the Atari ST owner is this; the ICD Advantage allows you to take your SCSI Hard Drive investment and use it on virtually any computer in use today. And the ICD tradition will keep your investment working for you in the future. ICD Advantage ST Software combined with any of their ST host adapters is already the quickest available for the ST computer. With an ICD system, some hard drive operations are actually three times faster than the competition! Advantage ST software now supports up to 64 hard drive partitions per drive and 128 total partitions per system. Volume names are allowed on all partitions and can be passed through to the desktop icons. Partition swapping through the new ICD DESKTOP.ACC allows any partition to become active in any of the 14 possible desktop icons. Partition sizes of up to half a gigabyte are possible under TOS 1.4. 256 Megabyte partitions are supported under older TOS versions. ICD Advantage ST Software does require at least one ICD ST Host Adapter in the system. The full ANSI SCSI command set is supported with our new Advantage SCSI Host Adapters. Advantage ST Software is included with all ICD Advantage Host Adapter kits and is available as a $10 upgrade for our ICD ST Host Adapter (STHA) owners. It can also be downloaded from GEnie, CompuServe, or the ICD BBS. The BEST is now even BETTER =========================== ICD Advantage Micro ST SCSI Host Adapter - At 1.3 by 2.7 inches, it is the smallest SCSI host adapter commercially available. The Advantage Micro ST is a zero footprint design which makes it the perfect host adapter for internal MEGA needs. The Advantage Micro ST plugs directly into the 50 pin connector of an embedded SCSI drive and powers itself from the SCSI bus. The adjustable power-up delay circuit provides up to two minutes of delay before allowing your Mega computer to boot. The Advantage Micro ST kit includes a sturdy mounting bracket for a 3 1/2 inch hard drive mechanism, internal DMA cable, drive power cable, our famous software, and excellent manual: everything you need to install a 3 1/2 inch hard drive inside you MEGA computer. ICD Advantage ST SCSI Host Adapter - Less than half the size of our original ST Host Adapter, the Advantage ST has all of its features except the clock. Added features include full SCSI command set, parity generation, dual mode DMA daisy chaining, and 48 ma drivers. The ICD Advantage ST includes our unique new dual mode DMA daisy chaining providing both the drivers for standard pass-through operation invented by ICD and full compatibility with devices that use parallel daisy chaining. The Advantage ST kit includes the ICD Advantage ST Host Adapter, 3 foot molded DMA cable, DC power adapter cable, Advantage Software, and manual. ICD Advantage Plus ST SCSI Host Adapter - With all the features of the Advantage ST plus a real-time clock, this board is the same size as the previous ST Host Adapter and it can easily replace the original ICD ST Host Adapter in existing applications. (For replacements: Please specify side or end mounting of the DMA connectors.) The Advantage Plus ST kit includes an ICD Advantage Plus ST Host Adapter, 3 foot molded DMA cable, DC power adapter cable, powerful software, and excellent manual. ICD Advantage Micro ST SCSI Host Adapter $109.95 (Internal Mega Kit) ICD Advantage ST SCSI Host Adapter $119.95 ICD Advantage Plus ST SCSI Host Adapter $135.95 ICD ST Host Adapter Comparison and Specifications Features Micro Advantage Advantage+ Old ICD STHA SCSI Commands* All All All Grp 0 only Driver Power 24 ma 48 ma 48 ma 24 ma Parity Generation No Yes Yes No Real Time Clock No No Yes Yes Usable Device IDs 0-3 0-5,7 0-5,7 0-5,7 DMA Daisy Chaining** Parallel Dual Dual Pass-Through ICs Used 5 8 11 14 Total Parts Used 17 31 44 60 Autobooting from HD Yes Yes Yes Yes Atari Compatible Yes*** Yes Yes Yes AHDI 3.xx Compatible Yes Yes Yes Yes PCB Dimensions (in) 1.3 x 2.7 2.5 x 3.95 3.93 x 6.3 3.93 x 6.3 US Retail Price $109.95 $119.95 $135.95 $135.95 * SCSI Commands conforming to the ANSI X3.131-1986 specification as well as the preliminary SCSI-2 specification except for arbitration which is not supported on any models. ** Parallel means that all DMA lines are in common with no drivers in between. Pass-Through means that there are line drivers in between each DMA port. A pass-through type DMA device will not work when its IN (computer) port is plugged into a parallel device. (That is why the standard SLM804 laser printer cannot be plugged directly into a Mega DMA port with internal hard drive.) ICD's unique Dual Mode ports function when plugged into either port type and allow either type to be plugged into the OUT (expansion) port. The noise immunity benefit of using line drivers is still retained. *** The DMA daisy chaining capabilities of the Micro Series Host Adapter is not Atari compatible except with the SH204. Otherwise, you must have a 'Dual' mode device in between the Mega Hard Disk port and another pass-through device. Advantage ST¿ is a trademark of ICD, Inc. __________________________________________________________ > ANOTHER REVOLUTION? CPU/STR SOUND OFF¿ This just may work! ===================================== A Silent Revolution =================== by Tim Holt President, ST Club of El Paso As I write this article, I really do not know how well the Atari Revolution is doing. I hope it is doing well. I have even got my little "Join the Revolution" stamp. (If you see some dollar bills with "Join the Revolution: Use Atari Computers" stamped on them, I did it.) Although the revolution is a downright noble cause, it has it's drawbacks: First of all, writing to the Tramiels is sorta like trying to move the proverbial mountain. If you haven't guessed by now that the Gang of Three doesn't give a lot of thought to us U.S. users, then you haven't been paying attention. Smell the coffee Bubba, they are in it to make a buck. What the U.S provides is pocket change. Secondly, the Revolution appears to many to be like trying to stop a hemorrhage with a band aid. It is a nice try, but it doesn't do much good. The damage has already been done, and calling 20/20 won't do much good simply because the folks in Sunnyvale(what a misnamed place if ever there was one!) do give a hoot what users think. (See reason #1) Thirdly (Is that a word?), the main focus of the Revolution is terribly misdirected. Roseanne Barr doesn't give a flying flip if her family wins a computer. Have you seen that show? The computer would end up as a door stop, or worse yet, Roseanne might sit on it. (In the process, a palmtop ST would be born.) The Revolution needs to go to only one place: WHERE THE MONEY IS. That is why I wrote this short essay. The Atari Revolution will only succeed when we make some ECONOMIC impact, somewhere. All the letters in the world won't do as much good as the sight of money lost. Think about it. If you were a businessman, what would make you think more: A few hundred letters from a bunch of computer fanatics (and that is what we are folks, don't try to deny it), or the loss of a few thousand dollars in sales? Well, I think the latter. May I humbly offer the following as a CO-Revolutionary proposal: Let us target some software company. (Just for no other reason than I have a current catalog, I will use Broderbund as an example, although ANY software company will do.) I know that they make a nifty program called "If it moves, Shoot it!". I also know that, from the catalog, it only is made for the IBM and Amiga line of computers. What if three thousand of us sent Broderbund checks made out, all for $29.95, for this product, BUT ONLY IF IT WERE FOR THE ATARI ST? This would have several effects: 1. The company would see that there is a market that they have missed. 2. If the company had any brains, they would see that they were losing a of a lot of money. In this case, close to ten thousand dollars in lost sales. (The more checks sent, the more money that they would be losing.) 3. The company would consider the ST community the next time they came out with a new product. 4. They would actually LOSE MONEY because they would have to spend man hours refunding our checks, since they did not have the item we wished to order. And that, my friends, is where this revolution would take off. If we could benignly cause companies to lose money, simply because they didn't carry ST software, hit them in the pocket book, then we would make our mark. Let me give you another example: Suppose Company X sold a grammar checker for it's popular word processor for the IBM, but not for the ST. Again, suppose this grammar checker sold for $300. If this company received 5000 checks, all made out for $300, but ONLY FOR THE ST VERSION of the program, this company would see rather quickly that they just lost 1.5 million dollars in sales. PLUS, they had to refund the checks, using office personnel, so in effect, they lost EVEN MORE than the 1.5 million. I think they would get the picture rather QUICKLY. What would this cost the ST user? Just the cost of a stamp, and a little letter writing. You would not lose the money on the check, because the company did not have the item you ordered. They would have to refund your money, so you lose NOTHING. What do you get out of the deal? Well, ever see a program on IBM or MAC or Amiga that really looked nice, only to find out it was never made for the ST? If enough checks are written, I'd be willing to bet money that you would see that program finally written for the ST. The time has come for us to stop goofing around, and stop looking like a bunch of children who are unhappy because daddy never comes home. To hell with those that won't pay attention to us. To hell with Atari if they ignore us. They sold the computer, that is all they wanted to do anyhow. The time has come to hit the software companies where it hurts the most.. in the pocket book. Show them that we are out here, we have money, and we are ready to spend it. Because in this big a beautiful country of ours, let's face it: When push comes to shove, it is MONEY that TALKS. Let's show them that we have money, we want to spend it, but ONLY on ST items. Then we will be heard, and then we will have won the Atari Revolution! To join the ST Club of El Paso, write to us at: ST Club of El Paso 10953 Yogi Berra EL Paso, Texas 79934 We hope you enjoyed this article. Please check out our other articles on line on GEnie, or in the Atari Interface Magazine, the official newsletter of the St Club. Editor Note; Folks, this "POSITIVE ACTION" sounds like it may work and work well! I can just a National Sales Manager in any of these companies watching all those commissions going out the window because of some short sighted bean counter's decision to not support the ST computers. _______________________________________________________ > VECTOR INTERCEPTS CPU/STR InfoFile¿ Tried and true techniques ================================== A Programmer's Eleven Commandments for Coexistent Vector Stealing ----------------------------------------------------------------- Tried and true techniques used by the CodeHeads for successfully intercepting vectors in the midst of numerous ST vector thieves. Copyright 1990 John Eidsvoog and Charles F. Johnson (CodeHead Software) Last revised: Wednesday, February 14, 1990 5:47:44 pm We have prepared this document in the interest of attaining and furthering compatibility between resident programs and accessories for the Atari ST. Since the TOS operating system has no provisions for managing its interrupt and trap vectors, ST developers who need to intercept these vectors are forced to use the "trial and error" system to determine what works. This is a very dangerous situation. More and more programs are appearing which enhance the ST's GEM operating system by patching into the vectors which handle system calls. Many of these programs work perfectly as long as no other resident programs are used, or as long as certain combinations of programs are used. But when these programs are released into the "real world," the conflicts quickly start showing up. At CodeHead Software we've encountered more than our share of these types of problems, since almost all of our commercial products intercept one or more of the ST's system vector(s). From this boiling witches' brew of potential pitfalls, we've managed to distill some pragmatic methods that can alleviate most, if not all of the conflicts. If you follow these guidelines when programming Atari ST applications which require the interception of system vectors, you will be compatible with _most_ of the programs currently in use. At the very least, your code will be compatible with all of the CodeHead Software products. If any program has general compatibility problems with other resident programs or accessories, it's very likely that the offending program is breaking one of the following Eleven Commandments: -------- I. -------- Always fall through to the previous address when your routine has completed its function. (The only exception to this rule is if your code replaces an entire system call; in this case, you'll probably want to terminate your routine with an RTE. Be aware that if you do this, any program which was previously installed in that vector will not "see" this call come through.) The "fall through" can be accomplished by storing the previous vector address two bytes past a JMP instruction; this approach solves any possible problems with pushing the return address on the stack (see Commandment V below), or destroying an address register to do an indirect JMP. There are some cases where it doesn't make sense to fall through to a previous routine, such as when you replace the Alt-Help vector which performs a screen dump. Even here, however, it's a good idea to make allowances for other programs which may use the Alt-Help vector for purposes other than a screen dump...such as the Templemon and AMON debuggers. AMON avoids conflicts with other programs in the Alt-Help vector by requiring the user to press the left shift key in addition to Alternate and Help. Another special case where falling through makes no sense is the ST's vertical blank queue list, which allows you to install a routine to be executed as a subroutine from the main system VBI. There are eight entries in the default queue list, and the correct way to install a routine in one is to search the list for a zero longword. When your VBI queue routine is finished, it may remove itself by clearing its entry in the list. (This is why it makes no sense to fall through to a previous queue entry -- that entry should have been zero when you grabbed it.) Even this mechanism is subject to abuse, however; an unfortunate number of programs simply stuff an address into one of the queue slots, without checking first to see if that slot has been taken. (A good example of this kind of vector abuse is the first version of STARTGEM.PRG.) Remember: when using the vertical blank queue list, always search the list for a zero entry in which to install your routine. With more and more programs appearing that replace entire operating system functions, compatibility is going to become even more problematic. For example, clashes will occur because Program A needs to "see" a certain call being made, but Program B is intercepting the call, handling it, and returning to the caller. In this scenario, Program A will just stop doing anything since it will never see the call for which it's watching. Keep this in mind when you're writing code intended to replace an entire system call; and be sure to test your code with as many other resident vector-grabbers as possible. -------- II. -------- Never replace a vector after grabbing it, unless you're in a controlled situation where there is no chance that another program could intercept the same vector and fall through to your code. Here's an example of what can go haywire if you do replace a vector at the wrong time: An early public domain ST program had a feature to select DESKTOP.INF files for different resolutions. The program grabbed the trap #1 vector (GEMDOS) and then used the Ptermres() call to make itself resident. Then, as a resident program, it monitored all GEMDOS calls, looking for the Fopen() call for the filename DESKTOP.INF. When that call was detected, the program replaced the system's filename ("DESKTOP.INF") with either LOW.INF, MEDIUM.INF, or HIGH.INF depending on the current resolution. Then it made the big mistake -- to remove itself, our example program took the address that it originally found in the trap #1 vector (when it first ran) and stored it back into the vector. Why is this such a big mistake? Because other programs that can run AFTER our example program may also need to grab the trap #1 vector. If this happens, the next program to install itself in trap #1 will be CUT OUT of the chain of fall-throughs when our example program replaces the vector. If you're lucky, the only ill effect will be that one of your TSR's will suddenly stop working. If you're unlucky, the system will crash or hang. (It all depends on what the program that got cut out of the chain was doing with that vector.) Oh, and by the way, our unnamed example program has since been updated to fix this thorny problem. The fix was simple; the program now remains in the trap #1 vector after replacing the system's DESKTOP.INF filename; after doing its job, the code does nothing but fall through to the previous vector. If you are a resident program and you want to remove yourself, do it by setting a flag to bypass your code and fall through (see Commandment I.) Remember that some other program may run after yours and grab the same vector; in this case, the other program will be falling through to your code. If you remove yourself by replacing the original vector address, you'll also be removing everything else that ran after you. -------- III. -------- Don't use a "magic cookie" (the infamous Diablo emulator mistake). That is, if you are trying to find another program (or yourself), don't look for a "magic" word near the address in the vector that the program steals. This technique will fail as soon as some other program grabs the same vector; and this is exactly how the Diablo emulator (for the SLM804 laser printer) breaks. The Diablo emulator consists of two separate programs, one that goes in an AUTO folder (the emulator code itself), and a configuration program that installs as a desk accessory. The AUTO program grabs the BIOS vector, so that it can redirect printer output to the laser via the DMA port. The desk accessory configuration program tries to find the AUTO program (every time it's activated) by looking for a "magic cookie" stored by the AUTO program in the location immediately before its BIOS interception code. Problem: if another program intercepts the BIOS vector AFTER the Diablo emulator AUTO program, the configuration accessory is unable to find the AUTO program (because the "magic cookie" is not where the accessory thinks it should be). There are a number of ways to reliably find another program. One of the easiest is to make a "fake" call to one of the trap routines with an undefined function code. The ST's BIOS and XBIOS will ignore calls with undefined function codes, and simply return with no ill effects if the program you're searching for is not present. We suggest using unusual function codes, such as $4857 (for example), so that your code will not conflict with future additions to the BIOS or XBIOS functions. The receiving program can then return whatever kind of information you need from it (you've got lots of registers to use). Here's an example (in assembly language) of some code that uses an undefined BIOS call to detect the presence of another program: ------------------------------------------------------------------- * The "target" program (the program being searched for) must intercept * the trap #13 vector and examine the stack after each trap #13 call * to see if the magic word function number is present. If it is, the * target program should load the return value into d5 and perform an RTE. moveq #0,d5 ; Clear d5 in preparation move #$4857,-(sp) ; Magic word - undefined BIOS call trap #13 ; Call BIOS addq #2,sp ; Correct the stack tst.l d5 ; If d5 is still zero, we didn't find anyone beq.s notfound ; If non-zero, it's a returned value move.l d5,returned ; Save the returned value somewhere ------------------------------------------------------------------- (NOTE: The version of TOS (1.6) that will be supplied with Atari's STE and TT machines has a new feature called the "Cookie Jar," which does not suffer from the problems described here. It provides a documented address where programs can search for "magic cookies"; it's a nice solution. Our only complaint with the "Cookie Jar" is that we wish it had been implemented three years ago.) -------- IV. -------- Do not try to monitor and maintain a vector from a vertical blank or other timed interrupt (in other words, don't keep watching it and replacing it if it changes). Think for a moment about what happens if two programs do this at the same time. (Ouch.) This extremely bad practice may seem to work when no other programs are using the same vector, but you will definitely have coexistence problems down the road. Don't do it. -------- V. -------- Do not use the (system) stack from an interrupt or trap vector. There is _very_ little stack headroom available in the location used by the operating system. A system stack overflow will cause crashes that can be extremely difficult to diagnose. If you need to save registers during some vector-handling code, it's best to save them in a location in your own program, instead of on the system stack. For example: ------------------------------------------------------------------- movem.l d0-a6,-(sp) ; Don't do this! ------------------------------------------------------------------- movem.l d0-a6,regsave ; Do this instead. ------------------------------------------------------------------- -------- VI. -------- Always restore all registers and the status register when your routine is finished. Don't even assume that you can destroy D0 or A0 because some programs (believe it or not) actually rely on them to return from a trap unchanged. (The exceptions to this rule are the BIOS and XBIOS vectors; the dispatching routines for these vectors always trash register A0, so it's safe to use A0 in a BIOS or XBIOS routine without saving it.) -------- VII. -------- Don't alter the processor state. That is, don't 'rte' into your own code in order to be in USER mode because other programs down the line may expect the machine to be in SUPERVISOR mode. -------- VIII. -------- When intercepting frequently called traps (such as trap #2), always use optimized assembly language routines to eliminate a slowdown in system operation. Don't make the "GDOS mistake". -------- IX. -------- Never assume something simply because it always "seems to be." This includes using "hard" addresses specific to a particular ROM, assuming that certain vectors will be pointing to ROM routines, assuming that 8 bytes into the GEM base page is pointing into the OS, or making _any_ decision based on an empirical condition. -------- X. -------- Use the source code provided below for maintaining the trap #2 vector from a resident program. This somewhat oblique method is required because the operating system stuffs its own address into the trap #2 vector (with no regard for what is there) after running a TOS program, and possibly at other times as well. (Yes, we are aware that this routine breaks Commandment IX.) The routine which handles trap #13 in this code also demonstrates a method to remain compatible with 68010/68020/68030 processors, by checking a new BIOS variable Atari has documented. -------- XI. -------- Commandment XI may be the most difficult one to follow. Have the wisdom to know when it's necessary to break any of the other commandments, and the responsibility to think through the consequences if you do. Some of these rules should _never_ be broken; others can be bent once in a while, as long as you carefully consider all the ramifications. Above all, just as in any other endeavor, you have to learn the rules and understand the reasons for their existence before you can get away with breaking them. ***************************************** * * * Intercept the trap #2 vector * * * * Code by Charles F. Johnson * * * * Includes ideas, techniques and * * refinements by Bob Breum, * * Chris Latham, and John Eidsvoog * * * * Last revision: 06/26/88 12:13:32 * * * ***************************************** .TEXT * ------------------------ * Program initialization * ------------------------ move.l #prog_end,d6 ; Get address of end of this program sub.l 4(sp),d6 ; Subtract start of basepage - save in d6 move.l #not_auto,addrin ; Try to do an alert box move #1,intin move.l #f_alrt,aespb move.l #aespb,d1 move #$C8,d0 trap #2 tst intout ; If intout is zero, we're in \AUTO beq.s .start1 cmp #1,intout ; Install? beq.s .0 ; Yes, continue clr -(sp) ; Pterm0 trap #1 ; outta here .0: pea prg_start(pc) ; Steal trap #2 right away if run from desktop move #38,-(sp) ; Supexec trap #14 addq #6,sp move #1,prgflg ; Set flag indicating desktop load bra.s .start2 .start1: pea title ; Print title message move #9,-(sp) trap #1 addq #6,sp .start2: dc.w $A000 ; Don't you just love Line A? move.l a0,line_a ; Save the address of the Line A variables pea set_bios(pc) ; Appropriate the Trap #13 vector move #38,-(sp) trap #14 addq.l #6,sp clr.w -(sp) ; Terminate and Stay Resident move.l d6,-(sp) ; Number of bytes to keep move #$31,-(sp) ; That's all folks! trap #1 ; We are now happily resident in RAM * ------------------------------- * Desktop vector initialization * ------------------------------- prg_start: move.l $88,t2_vec ; Set my fall throughs move.l $88,aesvec move.l #my_trap2,$88 ; Steal trap #2 (GEM) rts * ----------------------- * Steal the BIOS vector * ----------------------- set_bios: move.l $B4,t13adr ; Set Bios fall through move.l #my_t13,$B4 ; Steal trap #13 (BIOS) rts * ------------------------ * Trap #13 wedge routine * ------------------------ my_t13: btst #5,(sp) ; Was the trap called from super or user mode? beq.s t13_ex ; If from user mode, bail out lea 6(sp),a0 ; Pointer to function code on stack tst $59E ; See what _longframe has to tell us beq.s notlng ; If _longframe is zero, it's a 68000 lea 8(sp),a0 ; Advance past the vector offset word *** This section is based on the assumption that the OS always calls *** BIOS setexec() immediately after obnoxiously grabbing back the trap *** #2 vector with no warning whatsoever. Yes, this is an empirical *** condition, which violates Commandment IX. (But there's no other *** way to prevent that no-good, thieving TOS from ripping off the *** vector while you aren't looking.) notlng: cmp.l #$050101,(a0) ; Setexec call for critical error vector? bne.s t13_ex ; Nope, exit tst prgflg ; On the desktop? Or are vectors already set? beq.s first_time ; No, skip ahead do_crit: move.l #my_trap2,$88 ; Pilfer trap #2 move.l $404,d0 ; Get current crit vector move.l 4(a0),d1 ; Get address we're setting it to bmi.s t13_x1 ; If minus, return old vector in d0 move.l d1,$404 ; Set that vector t13_x1: rte ; We only get here if we're last in the chain first_time: tst.l 4(a0) ; Reading the vector? bmi.s t13_ex ; Yes, let the system take care of it move.l $4F2,a1 ; Get address of OS header (could be in RAM) move.l 8(a1),a1 ; Get pointer to base of OS from header cmp.l 4(a0),a1 ; Is the crit error routine below the OS? bhi.s t13_ex ; Yes, bail out move.l $14(a1),a1 ; Get address of end of OS (GEMDOS parm block) cmp.l 4(a0),a1 ; Is it above the OS? blo.s t13_ex ; Yes, exit stage left *** This is a very important part of the code. In order to maintain the *** correct vector chaining order when running at \AUTO time, it's necessary *** that each program first fall through to the BIOS and RETURN TO ITS OWN *** CODE, grabbing the trap #2 vector on the way back. This way, the order *** that each program intercepts trap #2 is the same as the order in which *** they run from the AUTO folder. move #1,prgflg ; Set the 'first-time'/'desktop' flag move.l 2(sp),retsav ; Save return address move.l #t13_2,2(sp) ; Replace it with my own t13_ex: jmp $DEADBEEF ; Go to the Bios and come back, t13adr = t13_ex+2 ; maintaining the correct chaining order t13_2: bsr prg_start ; Grab the trap #2 vector on the way back move.l retsav(pc),-(sp) ; And return to the caller rts retsav: dc.l 0 *-------------------------------------------------------------- The techniques described here have worked successfully for us, both in our CodeHead Software products and our individual projects. However, we do not wish to appear as the final and absolute authorities on this subject. If you can find any flaws in our scheme, or perhaps enlighten us with a more efficient trick, we can be easily reached. The quickest way to get a reply is to leave a message in the CodeHead Category (#32) on GEnie or leave GEnie mail to C.F.JOHNSON or J.EIDSVOOG1. You may also call CodeHead Software at (213) 386-5735. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><> NOTES ON THE GERMAN "XBRA" PROTOCOL For quite some time we've been hearing rumors about a new "standard" protocol devised in Germany, which supposedly can prevent some of the problems with conflicting vector-grabbers. It's called the "XBRA" protocol -- here's how it works: When a program needs to intercept a trap or interrupt vector, it should put the previous vector address four bytes before the beginning of its routine, preceded by two longwords. The first longword before the address should be a unique identification code for your application. The second longword before the previous vector address should be the magic longword "XBRA" ($58425241). So, in assembly language, the code would look something like: *---------------------------------------------------------------- dc.l 'XBRA' ; Magic longword signifying XBRA protocol dc.l 'BRAT' ; Unique (hopefully) 4-byte ID oldvec: dc.l 0 ; Put the previous vector address here my_vector_routine: ; Your vector-handling code starts here *---------------------------------------------------------------- In order for this protocol to really work, the vector interception code should also use the previous vector address stored in the XBRA structure to fall through to the previous routine. This way, if it's necessary to restructure the fall-through chain, any vector interception code will automatically start falling through to the new address. *---------------------------------------------------------------- move.l oldvec(pc),-(sp) ; One way to fall through to the rts ; address in an XBRA structure *---------------------------------------------------------------- move.l oldvec(pc),jump+2 ; Another way to fall through: jump: jmp $ADEADBEE ; by modifying a JMP instruction. ; This uses more memory, and may ; not work on a 68030 (without ; tweaking), but it doesn't use ; the system stack. *---------------------------------------------------------------- The main use of XBRA seems to be to allow programs to unhook themselves from a vector chain; it provides a method whereby programs can walk through the chain of vectors, unhook themselves (or unhook other programs!) if necessary, and even restructure the whole chain. Again, it would have been nice if the XBRA protocol were proposed three years ago; if even one program in the chain is not following XBRA, the whole scheme is useless. And since there are _many_ programs that don't use XBRA, the scheme is of little use in the real ST world at the present. Still, it doesn't take much effort to implement the XBRA protocol, so it may be a good idea to use it in any future vector-grabbing programs. If all programs used XBRA, _some_ of the problems with conflicting vector thieves could be eased. (Why does XBRA remind us of Esperanto, the United Nations-sponsored "international language" that was going to make it possible for all mankind to live in peace?) (NOTE: In our opinion the XBRA protocol could be improved, by adding a JMP instruction to the XBRA structure immediately before the previous vector address. If the structure looked like this: *---------------------------------------------------------------- dc.l 'XBRA' dc.l 'BRAT' jump: dc.w $4EF9 ; 680x0 absolute JMP instruction oldvec: dc.l 0 ; Put the previous vector address here my_vector_routine: ; Your vector-handling code starts here *---------------------------------------------------------------- then a program could simply branch to the label "jump" to fall through to the previous vector-handling routine. We must _emphasize_, however, that this is merely an observation on our part. Don't use this suggested extension to XBRA in your code, since the XBRA protocol does NOT support it as of this date.) It should be pointed out that XBRA is not a panacea; the "Eleven Commandments" we've outlined here are still valid, even if you do employ the XBRA protocol in your code. In fact, since so many programs already exist that do not use XBRA, it's even more important not to rely on the XBRA protocol to solve your problems for you. <><><><><><><><><><><><><><><><><><><>><><><><><><><><><><> *********************************************************** * * * This document is copyright 1990 CodeHead Software * * and may be freely distributed as long as this ASCII * * text file is complete and unaltered in any way. This * * document MAY NOT be reprinted or used for commercial * * purposes without express written permission from * * CodeHead Software. * * * * If you wish to reprint this document, contact us at * * the phone number given above for permission. * * * *********************************************************** ________________________________________________________ > CRASWELL INTERVIEW CPU/STR Feature¿ Jay Craswell is not, er ah, normal.. ================================== CANNIBALISTIC VIDEO CARD MAKER, JAY CRASWELL, DESCRIBES 300 FOOT INFLATABLE WOMAN AND EXPLAINS DESKTOP SEWING by Charles Medley First of all, I want to state that this is not simply an interview. This is because interviewing Jay Craswell is not, well, a normal process. You cannot expect to ask a question and get normal answers. No, you get far more than that. You get entertainment. So this will be more of a profile of the demented and creative mind of this Atari developer, with a few Q&A's in there to give you an idea of what an interviewer is going up against: Q: What has made you enter the Atari ST market, and become the "force" you are now in the industry? A: I have no idea. Moniterm made me design a card... and then my partner-in-crime, Mark Medin, wanted to do one better. I tried to making something of myself and failed. Q: Okay, why are you in the ST market in particular? A: Sewing. Q: Huh? A: Well, this company called Software Cafe pre-ordered five of our video boards, and they are writing a program that allows you draw logos and things. Then it hooks up to a sewing machine and does the stitching. Desktop Sewing. Q: Er... Right Basically, this was to let you know why I am going to describe, with as few quotes from Jay as possible, the topics of our conversations, and exactly WHO this guy is. Jay works for Image Systems. At least for now (when this article comes out, he may be fired...). He has received a bit of attention over a video card he has made for the Mega ST computer which sports 1024x768 resolution with either 16 colors from 4096 or monochrome. From talking to Jay, I can see that a psychiatrist would have fun with him. It seems that some of the major events in his formative years were: 1) Building model planes without instructions and using a hot butter knife to insure that when you put the wheels on the planes, they could still roll... 2) Going to see "2001: A Space Odyssey" with his brother-in-law as a "young teen" and sitting in the front row of a theatre and getting sick during one of the psychedelic scenes. He attributes this as one of the reasons he works on video cards today. Later in life, Jay went on to hold a radio station hostage to his demands. The station in question was one KXDL whose location I didn't get (but the call letters mean west of the Rockies...). Apparently, Jay used to repair "important stuff" at the radio stations, and as a joke, he told the DJ that he had to play Frank Zappa and John Lennon albums if he was going to fix it. Apparently, the DJ conceded to Jay, and he went about his work. However, Jay erroneously wound up on the air with the DJ, who asked him his full name, to which Jay claimed that he was "fleeing National Drug Enforcement Agents" and that he would not say his name. Apparently, the DJ offered a Leif Garrett album as bounty to the first listener who guessed "Jay the Repairman's" last name. Also, Jay acquired an appreciation for classical music, such as Jimi Hendrix. Being an avid Hendrix fan, he has a ton of basement and bootleg tapes that have inspired him to become a member of a group called "Joe Grow", who is managed by a guy named "Nick Vermin". As you can see, this man is not normal, but who am I, of all people, to judge? He also has an affection for the Rolling Stones, and anyone who has seen their stage has seen the "300 foot inflatable women" that accompany the show. Jay seemed abnormally fascinated with what Mick Jagger did with them, and we both had some good laughs... Well, anyway, after a long tortuous life, Jay wound up acquiring an Atari ST somehow, and got "hired" as an independent contractor to do the video card for the Mega ST Viking Moniterms. He worked on this with Mark Medin, a person who Jay claims "doesn't talk much" . Mark is apparently a very sedate, laid back, person of extraordinary magnitude. So, for a while after that, as mentioned earlier, Mr. Craswell and Mr. Medin decided to do a bit of "improving" on the Moniterm design for the ST since "the Macs, the IBMs and everyone else had these cards except, of course, the Atari". With the noblest of intents, Mark and Jay got to work on what is now called the Image Systems ATR-4CP 1024x768 4 plane video board, which touts a meager suggested list price of $800. Also, for those who enjoy a good "SCOOP", here is one. You read it here first: Image Systems is working on two video cards for the ST and TT030/2. Both are roughly two MEGAPIXEL (two million pixel) displays. One is monochrome with a resolution of "roughly" 2000x1500 and requires a 24" monitor, but it would work on the 19" Viking monitors. The other is color, uses a 21" monitor and has 1600x1280 resolution. No mention was made by Jay as to the full capability of the color display (i.e. bit planes and such), but both of these products are "still on the drawing board" and will be a while before hitting the market. Also, they may or may not have page-flipping capability (so more VRAM