/********************************************************************** Title: AEOPJ4.TXT Created: December 25, 1993 Last Modified: March 31, 1994 Purpose: Fourth installment of AEO Programmers' Journal Editor: Albert Dayes Legal Notes: Copyright ½ 1993 Subspace Publishers All Rights Reserved ***********************************************************************/ Publisher = Michael Lindsay [GE: EXPLORER] Managing Editor = Travis Guy [GE: AEO.MAG] Editor = Albert Dayes [GE: AEO.1] [CIS: 70007,3615] Technical Editor = Carl Barron [GE: CBARRON] [CIS: 75066,3204] OBJECT::ATARI columnist = Warwick Allison [In: warwick@cs.uq.oz.au] 68K columnist = Damien M. Jones [GE: DMJ] PASCAL columnist = Kris Gasteiger [CIS: 73637,2004] Parsing the human equation = Ron Whittam [In: r.whittam@genie.geis.com] :: Internet subscription service: stzmagazine-request@virginia.edu :: :: (Internet subscription requests ONLY!) :: Contributing: John Perry Barlow [In: barlow@eff.org] Roger Burrows [GE: R.BURROWS1] Gerry J. Elman, J.D. [CIS: 72245,556] Scott R. Garrigus [GE: S.GARRIGUS] Kurt Stammberger [In: kurt@rsa.com] Frederic M. Wilf, J.D. [CIS: 72300,2061] [ Where GE = GEnie In = Internet CIS = Compuserve ] /***********************************************************************/ Table of Contents: * Editorial * Meet the Authors - short biographical notes on the authors * What is in this issue of AEO-PJ. * 68K Column - Some Assembly Required by Damien M. Jones * C Column - First steps to learning C programming * Advanced Computing - Carl Barron YACCs with alert boxes * GFA Basic Column -- Scott R. Garrigus talks about Resources and RCS * Hard Core - Interview with Roger Burrows author of ExtenDOS * Dabbling in PASCAL - Kris Gasteiger discusses keyboard functions * Library - Damien examines a new Atari specific CD-ROM disc called Gemini. * Periodicals - A preprint from Wired magazine on the Clipper Chip + RSA info * OBJECT::ATARI - Warwick Allison on moving from C to shining C++ * Parsing the human equation - by Ron Whittam * Language Watch - Current versions of developer tools * Bad Example - Do you really want to do that? * Legal Forum - A discussion of Intellectual Property issues * Best Software Development tools for 1993 * On the Networks - Interactive programming online * Network Sign-up Information * Shareware survey - for shareware authors only * Brain Stem rotator - A true programming challenge? * Software Development Conference, March 14-18 in San Jose, California * 10 Tips From the Programming Pros * Glossary of Terms * ATARI DEVELOPER INFORMATION - Where to get the official Atari Docs * Sources of Information - References for this issue * Post Increment - What is coming up in the next issue * LEGAL NOTES ------------------------------------------------------------------------- Editorial: "Shareware - Does it really work?" By: Albert Dayes ------------------------------------------------------------------------- Category 3, Topic 11 Message 194 Sun Jan 23, 1994 MIKE-ALLEN [NM~SysOp] at 19:52 EST I just received interesting EMail from Karsten Isakovic, the author of SysMon. Thought folks might be interested. His GEnie Email address is: KARSTEN_ISAKOVIC@B.MAUS.DE@INTERNET# >Hello Mike, > >i read in AEO-PJ3 of December 19 that there was a discussion about my >debugger SysMon in a Genie roundtable. I have some comments to that. >I know its a bit late, but better late than never ;-) > > >The version 1.05 which was in discussion in the RTC is more than 4 >years old. It does not run on TOS 2.06 or TT. The current version >1.08 runs on the TT and TOS 2.06, but not on the falcon. > >But the 1.09 is now in the beta test stage, and runs on the falcon. >SysMon works even with graphic expansions like BlowUp or >Screenblaster. > >It supports all new MTOS (AES 4.2) and MagiX (Beta 2.10) AES Call, >Speedo (Beta 4.2) the MiNT (1.08)/MagiX gemdos calls, all new falcon >XBios calls (like DSP, SND and Video-Calls) and the Metados Xbios >extensions.. > >Some new AES protocolls and extensions are supported, like the new >GEMINI- Messages (1.99), XACC, WinX (2.2), Kobold (2.5), Selectric >(1.10)... > >The XBRA- and cookie list was also updated (up to XBRALIST of Dec 93). > >There is new code to find the internal system variables. Even if none >of them is found, SysMon will run. But you get more information, if >everything is known ;-) > >Since 1.0.8 there is an interface to the templemon debugger, you can >now directly jump into TMON if a System function is used by the >selected programs. (BTW the current TMOS version is 2.2) > >The upcoming 1.09 does not yet work under MiNT/MTOS (but the all >calls are already supported, since the MagiX-Beta offers some of >them...), but a future version will do so.. > > >There is no newer version of SysMon in any FTP site or BBS since i >did not allow this kind of distribution since the version 1.06 >(everybody used SysMon, nearly nobody paid the ShareWare fee...). I >have only 3 US and 2 CA people in the database and as you see in the >RTC, it is fairly common... > >Since then, you can still copy SysMon to a friend, but for a current >version, you have to send a disc with a back envelope and two >international relay coupons (Which i can exchange into stamps at the >postal office). You dont have to register in advance, you can test >SysMon as long as you wish. But if you use it regularly and like it, >pay the fee. > >This simple modification to the distribution mode (and the >announcement about it in the press) raised the percentage of people >who paid the fee. I think it is because they had to get into 'real' >contact with me. The SysMon is no longer an anonymous product, you >know from whom you got it... > >My adress is: > > Karsten Isakovic > Wilmersdorferstrasse 82 > 10629 Berlin > Germany > >You can also reach me via Email at ki@cs.tu-berlin.de and i could send >SysMon as uuencoded Message (_very_ long, about 400 K with english >documentation). I can also split it to several messages. But i still >need your full name and adress. > >The MagiX/Falcon version 1.08 will be ready at the end of february. I >dont know if there will be a new distribution mode, i still have to >think about it... > > >Greetings, Karsten > >PS: If there is also an american list of cookies, Xbra magics or >Message protocolls, send it via email. We have nearly no information >about GENEVA around here, so there is no support yet. > > I have pointed him towards Dan Wilga for Geneva info and given him the Gnva cookie info as well as the CJar cookie info. Any other cookies that he might not have would be appreciated, I'm sure. Only 5 North American registrations (3 USA, 2 Canada) - for shame! Mike Allen ST HelpDesk~Sysop Written: 5:42 PM Mountain Time Sunday, January 23, 1994 Is there anything else that I can add to this message? Probably not, it is very clear. AEO-PJ is moving toward better support for shareware software developers and in our next issue we will have a debut column called Soft Core. Since Hard Core is an interview with a commercial Atari developer Soft Core will be with a shareware Atari developer. Also do not miss the shareware survey, later in this issue. -- Albert PS: Anyone who would like to send feedback to AEO-PJ may send it via any of the electronic addresses listed below. Use the method which is most convenient for you. CIS: 70007,3615 GE: AEO.1 In: 70007.3615@compuserve.com /**********************************************************************/ Meet the Authors /**********************************************************************/ //// John Perry Barlow John Perry Barlow (barlow@eff.org) is co-founder and Vice-Chairman of the Electronic Frontier Foundation, a group which defends liberty, both in Cyberspace and the Physical World. He has three daughters. //// Roger Burrows Roger Burrows has written code in four high-level languages and five assembler languages and usually manages to remember which is which. He lives in Ottawa, Canada with his wife, cat, and computers. He can be reached on GEnie as R.BURROWS1. //// GERRY J. ELMAN Mr. Elman holds an M.S. in Chemistry from Stanford University, in addition to his J.D. from Columbia University. With 26 years of varied experience as a practicing attorney, he is an authority and widely published author on technology and the law. His areas of expertise include biotechnology, computers and intellectual property. For four years, Mr. Elman practiced as an in-house patent attorney for Rohm and Haas, a large multinational chemical company. Then, as a Deputy Attorney General of Pennsylvania, Mr. Elman conducted litigation on behalf of the Commonwealth. Later, as a trial attorney with the U.S. Department of Justice, Antitrust Division, he participated in civil and criminal investigations and complex litigation, including a trial of five pharmaceutical companies accused of fraud on the U.S. Patent Office. Mr. Elman returned to private practice in 1982. Today, Mr. Elman is the founder and editor-in-chief of the lawyers' newsletter Biotechnology Law Report. He has also served on the advisory board on biotechnology monographs for the Bureau of National Affairs (BNA) and the advisory board of the law journal Computer Law Reporter. He frequently lectures on biotechnology and the law. He has arbitrated multi-million dollar disputes for the American Arbitration Association, has served as an expert witness in patent law, and has represented both plaintiffs and defendants in litigation over intellectual property rights. A profile of Mr. Elman appears in Who's Who in America. //// FREDERIC M. WILF Mr. Wilf has been practicing law with Mr. Elman since 1986. He advises clients on copyright, trademark and business law, with an emphasis on computer and high technology issues. He litigates copyright and trademark infringement actions and negotiates software development and license agreements. Mr. Wilf also represents out-of-state corporations as local counsel, and prepares and prosecutes copyright and trademarks applications and related proceedings. A graduate of Rutgers University and Case Western Reserve University Law School, Mr. Wilf writes and speaks extensively on topics involving computers and the law. His articles have appeared in the Computer/Law Journal, the Computer Law Reporter and PC Magazine. He and Mr. Elman wrote the chapter "Trademark Protection of Software" for L.J. Kutten's law treatise. Computer Software: Protection/Liability/Law/Forms. Mr. Wilf contributed a chapter to a book entitled Winning with Computers. Trial Practice in the Twenty-First Century, published by the American Bar Association (ABA) in 1991. Mr. Wilf has also served as the organizer of the corporate law conference (CORPLAW) on the ABA's computer network, ABA/net. A profile of Mr. Wilf appears in Who's Who in the East. //// Scott R. Garrigus Scott's first computer was the venerable Atari 800. He once spent a whole summer vacation indoors because he loved using his computer so much. Nowadays Scott is a college graduate musician and has just recently released his first record album, Pieces Of Imagination. He uses his Atari ST for all aspects of album production, including writing his own MIDI utilities. He also runs his own shareware business, SRG Music & Software and has released his first shareware program called EmailMan, the email address database. A demo of EmailMan can be found on the new GEMini CD ROM. Scott will be taking over our GFA BASIC column and he can be reached at any of the following email addresses: Delphi: GARRIGUS GEnie: S.GARRIGUS Internet: s.garrigus@genie.geis.com PAN: GARRIGUS //// Kurt Stammberger Kurt Stammberger is a Technology Marketing Manager for RSA Data Security, Inc. /**********************************************************************/ What is in this issue of AEO-PJ and new in the Atari market By: Albert Dayes /**********************************************************************/ //// Atari Corp: The Atari Jaguar (64-Bit Interactive Multimedia Entertainment System) continues to make good progress. In addition, the Jaguar won several awards at the Winter CES (Consumer Electronics Show). Discussions continue, on the subject of Atari clones, Falcon and TT accelerators and even new Atari computer magazines. In addition, a new shipment of Atari TT computers to US dealers. //// CD-ROM Technology: In this issue we cover a few programming conferences, and a special one on CD-ROM. The CD-ROM conference discusses how to use a CD-ROM drive on the Atari. In addition an interview with Roger Burrows, author of a new CD-ROM driver (ExtenDOS) is also in the issue. //// Legal Issues: Recently the PTO (Patent & Trademark Office) decided to re-examine the Compton patent and is taking input from software developers on the issue of software patents. In talking with a friend of mine (who has a software patent), I made some interesting findings. Even though his software patent is in his name, the company owns it (which is expected). Xerox, (the company he works for) has patent cross-licesing agreements with Kodak, IBM, etc. That means that Xerox can use any of the patents that Kodak, IBM, etc hold. And conversely, IBM can use all of the patents Xerox has, without paying any licensing fees. For those companies or individuals without a large patent portfolio, paying licensing fees is the only option. Since Intellectual Property is an important subject we have a nice article on the subject. Fred Wilf and Gerry Elman (of the law firm, Elman Wilf & Fried) discuss the different aspects of Intellectual Property, in the article, "How to work with your intellectual property Attorney". Many interesting aspects of the law that developers should know about are included. Also, we have a pre-print from Wired magazine on the Clipper chip and what it means to US citizens. //// Pure Profiler - a new programming tool: A new Profiler from Gribnif Software, called Pure Profiler. Based on the article in Desktop Notes -- Gribnif Software, article by Dan Wilga. The newest programming tool we have to offer is the Pure Profiler, also from Application Systems in Germany. This invaluable program generates statistics about the operation of other programs and helps you make decisions about how to get the best efficency from your code. The Profiler runs much like the Pure Debugger in the Pure C package does. It provides an unlimited number of windows which show you source code modules, 680x0 assembly, and profiler output. The profiler is familiar with Pure C and Pure Pascal symbols, and also the DRI format. This means that it can be used with programs which were generated by almost any compiler. Statistics are broken up into major categories: Code Usage and Profiling. Code Usage provides you with a visual representation of the lines in your program which were actually used as the program ran; they appear in boldface type. This allows you to know if there are segments of "dead" code which are never used. Profiling gives extensive information about how much time each module of your program takes to run and how many times the modules are called. This same information is generated for every single line in the program, as well. By using this information, you can decide where the program spends most of its time during execution, and possibly optimize that area of code. The main level of the Profiling information is broken into two segments: Operating System and Program calls. The Operating System segment lists all of the major types of OS functions (GEMDOS, BIOS, AES, etc). Clicking on a function type then gives you a list of the calls of that type, and provides you with a percentage of time used during each, and the totla number of calls. In the Program calls list, you are given a list of all function in the program, along with the time data. Further clicking on a function reveals the source code for that function, along with the time data for each line. The Pure Profiler also keeps track of all file operations. For each file which is used by your program, it maintains a list of how many times it was read, written, opened, etc., as well as the number of bytes that were operated upon and the underlying GEMDOS call used. Furthermore, useful memeory statistics can be displayed. You can find out how much heap (Malloc) memory the program is using currently, and the highest amount it has used at once. The same data is also displayed for the program stack. Breakpoints can also be set, and the program's instructions can be single-stepped. Profile data can be saved to disk, optionally including the source/assembly code of each line of the program, to make evaluating the code easier. At this time, the Pure Profiler includes a German manual; but the program itself is completely in English, and has a very intuitive user interface. The Pure Profiler is extremely helpful tool that no serious programmer should be without. //// DevPAK DSP HiSoft/ORA is releasing Devpak DSP, which will make Motorola 56K Digital Signal Processor programming much more enjoyable. The price should be close to $100. //// Books There was going to be a review of Writing Solid Code by Microsoft Press in this issue, but the Clipper article took its place. For those who want to read a recent review can read it in the December 1993 issue of the C Users Journal. Software Development: A Legal Guide recently arrived. It includes a 720K floppy disk (works on the Atari) of all of the contracts listed in the book. From a quick scan it covers many details that many people would just skip over in making agreements. It also has icons to indicate when you should get a real Attorney to help you. Some highlights include: * when to use copyright, trademark, trade secret or patent protection * what the strengths and limitations of each type of protection are * how to avoid infringement * what you need to know about software patents * what key provisions to include when drafting an agreement * step-by-step instructions on drafting - employment agreements - agreements with independent contractors and consultants - software publishing agreements - agreements for the development of custom software * when and how to obtain permission to use materials in multimedia projects * what you new to know about the new multimedia patent (Compton's) * when to contact an attorney There will be a review of this book, in the next issue of AEO-PJ. /* DEVELOPERS, PLEASE NOTE! */ The Independent Association of Atari Developers (IAAD) provides peer support to commercial Atari developers. The IAAD can help you find a shrinkwrap machine, weigh the benefits of different kinds of packaging, reach potential customers, tackle programming dilemmas, locate distributors for your products - in short, our members offer each other information on virtually every aspect of commercial software development and marketing. Membership is open to registered Atari developers who have a commercial product currently shipping or about to launch. To apply, please send a note to PERMIT$ on GEnie. /**********************************************************************/ 68K Column - Some Assembly Required By: Damien M. Jones /**********************************************************************/ -- Part 3: Round and round she goes... -- Yes, I'm back. Last month I covered addressing modes and a few (three) instructions. This month I'll cover a few more instructions, including a little looping. This article will be a bit larger than the previous ones, as there's a lot to cover! FLAGS Whenever you do something with a 680x0 program, the CPU "takes notes". That is, it looks at the results of what you did and saves some information about those results in the "condition code register" (ccr). You can play with this register directly, but there are also some special instructions that will look at its contents so you don't have to mess with it too much. There are five flags in the ccr that are important. Each has a letter and is set or cleared based on different properties. Here they are: N This is the "negative" bit. If the result of the operation is less than zero, this bit will be set (1); otherwise (if the result is zero or greater) this bit will be cleared (0). Z This is the "zero" bit. It is set whenever the result of an operation is zero, or cleared whenever the result is NOT zero. V This is the "overflow" bit. If the result of an operation is too big for the size of the operands, an arithmetic overflow occurred, and this bit will be set. Otherwise it is cleared. C This is the "carry" bit. If the result of an addition created a carry out of the highest bit, or if a borrow was needed on the highest bit, this bit is set. Otherwise it is cleared. X This is the "extend" bit. Only certain operations use it, and it mostly is used for large (bigger than 32-bit) operations. When it is used, it will be a copy of the C bit. MORE INSTRUCTIONS Last month's example program used just three instructions, add, move, and trap. There are quite a few more, but this month I'll cover a few variations of those three instructions, plus a few new ones. Keep in mind that most assemblers will choose a more specialized variation of an instruction, if it can, so you can often just write the basic instruction and your assembler will fill in the proper form. The reason I am explaining some of the variations is because they usually have slightly different effects that you need to be aware of when writing programs. move.s source,destination I described this last time, but I did not say what happens to the flags in the ccr after the move (because I hadn't explained the flags yet). So here is what happens to the flags, when you move something: N Set if the value moved is negative. Cleared otherwise. Z Set if the value moved is zero. Cleared otherwise. V Always cleared. C Always cleared. X Not affected. (It won't change.) movea.s source,destination This is just like the move instruction, with a few important differences. First, the destination must be an address register (a0 to a7). As a matter of fact, if the destination is going to be an address register, you _must_ use the movea variation; fortunately most assemblers will slip the "a" in for you if you forget. The other major difference is that this instruction does not change ANY of the ccr flags. This means if you have just done something that sets some of the condition codes, you can still move data into an address register without changing those flags. (This is more useful than it sounds.) Just keep in mind that if you move something into an address register, the condition codes are not affected. moveq #n,destination This is like the move instruction, but it too has some differences. For one thing, the size is always a full 32-bit move. Also, the destination must be a data register (d0 to d7). Finally, the number moved must be between -128 and 127; although this means it's only an 8-bit value, it is sign-extended to 32 bits. Otherwise, this instruction is like the regular move - the condition codes are set the same way. You should use moveq whenever you can, as it is faster and uses less storage space than move.l #n,destination. Your assembler will normally make this distinction for you, but it can only do so if you're moving a long value (.l) and that value is in the range -128 to 127. clr.s destination This is the "clear" instruction. Basically, it moves a zero into the destination. The destination may be any size (byte, word, or long), but it can't be an address register. The condition codes are affected as follows: N Always cleared (since the result is never negative). Z Always set (since the result is always zero). V Always cleared. C Always cleared. X Not affected. add.s source,destination This was mostly explained last time, but as with move I didn't explain what happens to the condition codes: N Set if the result of the addition was negative. Cleared otherwise. Z Set if the result of the addition was zero. Cleared otherwise. V Set if the addition caused an overflow. Cleared otherwise. C Set if the addition caused a carry. Cleared otherwise. X Set the same as the carry bit. Also note that the plain-vanilla add instruction can _only_ be used if either the source or destination is a data register; if this is not the case, you will need to use a different "flavor" of add instruction. (Again, normally your assembler will help you out here, but you should be aware of the differences.) adda.s source,destination This is mostly like the plain-vanilla add, except that the destination must be an address register. In fact, if the destination is an address register, this form MUST be used, even if the source is a data register. There are other differences as well. The size may only be .w or .l; if you use the word size, the word value is sign-extended to a full 32 bits before being added to the address register. And, just like the movea instruction, the condition codes are NOT affected at all by this instruction. addi.s #n,destination This is basically like the plain-vanilla add, with a few minor differences. As you can see from the instruction format, the source must be immediate data. The destination can be anything except an address register (if you need to add immediate data to an address register, you use adda instead). Otherwise this is just like add. The reason this instruction is present is because with the regular add, you can only add an immediate value to a data register--because either the source or destination must be an address register, and the source is already an immediate value. With this instruction, you can add immediate data to anything, not just a data register. Your assembler will normally make this distinction for you. addq.s #n,destination This is like a regular add, with some differences. (That sounds familiar...) The number that you can add is in the range 1 to 8. You can add this number to just about anything; if you add to an address register, the condition codes are not affected (like with adda), but if you add to anything else the condition codes will be set as for a regular add. Also, if you add to an address register, the size is always long (.l). You use addq because it is faster than a regular addition, and it uses less memory. Usually your assembler will replace addi.s #n,destination with addq if it can. sub, suba, subi, subq These are the subtract instructions. They are just like their addition counterparts, add, adda, addi, and addq, except they subtract instead of add. HELLO, WORLD! REVISITED In light of these new instructions, let's look again at last month's example program and see what we can do with it. Here's the program (I've shortened the comments to a single line each; for the fully commented listing, see last month's AEO-PJ): * Hello world! * Some Assembly Required, Article 2 * First, display text on the screen. move.l #text,-(sp) ; Put the address of our text on the stack. move.w #9,-(sp) ; Function code for cconws. trap #1 ; Call GEMDOS. add.w #6,sp ; Remove our 6 bytes from the stack. * Now wait for a keypress. move.w #8,-(sp) ; Function code for cnecin. trap #1 ; Call GEMDOS. add.w #2,sp ; Remove our 2 bytes from the stack. * Now exit the program. move.w #0,-(a7) ; Function code for pterm0. trap #1 ; Call GEMDOS. * Data used by our program. text dc.b 'Hello, world!',0 ; Text to display. All right, to begin with I see in the ninth line the following: add.w #6,sp ; Remove our 6 bytes from the stack. This could use the addq variation; while the assembler will normally fill this in for us, it's a good idea to do it yourself if you see it, so you know what's going on. So we'll replace it with this: addq #6,sp ; Remove our 6 bytes from the stack. Since sp is really a7, and adding to an address register is always a 32-bit operation, I did not include the .l--but you can if you like. In a similar manner, the fifteenth line of our program (add.w #2,sp) can also be changed to addq. As a last change, we can also change the ninteenth line of our program: move.w #0,-(a7) ; Function code for pterm0. The 680x0 has a handy instruction for putting zeroes in places, so we can use that instead: clr.w -(sp) ; Function code for pterm0. Note that I also changed a7 to sp. They really mean the same thing, and I usually use a7 in my own programs, but everywhere else in the program I used sp, so I thought it would be better to be consistent. (Wish I knew how that a7 slipped in there. ;-) WHAT ABOUT LOOPING? Almost every program requires looping of some sort. It's one of the three basic structures of a program (sequential, iteration, and branching). The 680x0 has quite a few instructions to handle looping; I won't cover them all this month, but I will list some of the basics. bra destination This instruction means "branch always" to the destination address. The destination is a label inside your own program. This is sort of like a GOTO in BASIC; those of you who prefer more structured programming may wince at the mention of the dreaded GOTO, but remember that all of the structures you're familiar with can be built from IF and GOTO statements. (Next month I'll even show you how it's done.) One thing to remember is that bra is a "relative" jump; that is, instead of telling the CPU exactly where to go, it tells it how far and what direction (forwards or backwards). This means you can "relocate" or move the code, and as long as you move the destination along with it, the bra instruction will still indicate the proper destination. Most of the time this is not an important distinction; later in this series I'll explain when it does matter. When you write programs using bra, you don't have to figure out how far to jump; you just use the destination's label, and the assembler figures out how far it is. This does mean, however, that you can only bra to destinations within your program. bcc destination This is really an entire class of instructions. The "b" in "bcc" means branch, and the "cc" means condition codes. This is sort of like an IF (condition) THEN GOTO in BASIC. What it does is examine the condition codes (which are normally set by preceding instructions) and, if certain conditions are met, branches to a different place in your program. If the conditions are NOT met, the instruction does nothing. There are several different conditions you can check for; all use a two-letter code (to replace the "cc"). Here they are (note that I'm listing them with the "b" for branch): beq Branch if equal; that is, if the Z flag is set. If the preceding operation resulted in zero, the Z flag will be set, so beq can also be used as a "branch if zero" instruction. (This mnemonic comes from its use with the compare instruction, cmp, which I will discuss next month.) bne Branch if not equal; that is, if the Z flag is clear. If the preceding operation did not result in zero, the Z flag will be cleared, so bne can also be used as a "branch if NOT zero" instruction. (Like beq, this mnemonic relates to the compare instruction.) bgt Branch if greater than; specifically, if the N and V flags match and the Z flag is clear. If the preceding operation resulted in a value greater than zero, the branch occurs. bge Branch if greater than or equal; specifically, if the N and V flags match. If the preceding operation resulted in a value greater than or equal to zero, the branch occurs. ble Branch if less than or equal; specifically, if the N and V flags do not match, or the Z flag is set. If the preceding operation resulted in a value less than or equal to zero, the branch occurs. blt Branch if less than; specifically, if the N and V flags do not match. If the preceding operation resulted in a value less than zero, the branch occurs. bpl Branch if plus (positive); that is, if the N bit is clear. If the preceding operation resulted in a positive value (greater than or equal to zero), the branch occurs. bmi Branch is minus (negative); that is, if the N bit is set. If the preceding operation resulted in a negative value (less than zero), the branch occurs. bhi Branch if higher; specifically, if the C and Z bits are both clear. If the preceding operation resulted in a value greater than zero, the branch occurs. bhs Branch if higher or same; specifically, if the C bit is clear. If the preceding operation resulted in a value greater than or equal to zero, the branch occurs. You can also use "bcc" in place of "bhs"; "bcc" means "branch if carry clear", which is exactly what bhs does. (Sometimes one is more indicative of what you mean than the other is.) bls Branch if lower or same; specifically, if the C or Z bit is set. If the preceding operation resulted in a value less than or equal to zero, the branch occurs. blo Branch if lower; specifically, if the C bit is set. If the preceding operation resulted in a value less than zero, the branch occurs. You can also use "bcs" in place of "blo"; "bcs" means "branch if carry set", which is exactly what blo does. (Sometimes one is more indicative of what you mean than the other is.) bvc Branch if overflow is clear; that is, if the V bit is clear. If the preceding operation did not create an overflow, the branch occurs. bvs Branch if overflow is set; that is, if the V bit is set. If the preceding operation caused an overflow, the branch occurs. Looking at the descriptions for the various branch instructions, it may appear that there are duplicates. The group bgt, bge, ble, and blt may look very similar to the group bhi, bhs, bls, and blo. But if you look closely, you will see that the two groups test very different flags. What's the "real" difference, and how do you tell which group to use? The answer is simple. The first group--bgt, bge, ble, and blt - react to conditions resulting from _signed_ arithmetic. If you are working with signed numbers, use bgt, bge, ble, and blt. The second group--bhi, bhs, bls, and blo--are for _unsigned_ arithmetic. If you are working with unsigned numbers, use these. BUT, WHAT ABOUT LOOPING? All of this branching stuff is wonderful, but it doesn't mean a whole lot by itself. The most common form of looping (although not the simplest) is probably the for loop. So for this month's example program, I'll show a program that inverts the first sixteen colors of the desktop. There's an instruction I'll be using to do the actual inverting, so let's define it now: not.s destination This instruction simply flips all the bits in the destination (i.e. it takes the one's complement). The size can be byte, word, or long, and the destination can be anything except an address register. (Later in this series I will cover the rest of the bit manipulation instructions.) Here's this month's program, outlined in C: main() { short index; /* Our loop counter */ short color; /* One color value */ for (index = 15; index >= 0; index--) /* Process all colors */ { color = setcolor(index, -1); /* Get the old color */ color = ~color; /* Invert the bits */ setcolor(index, color); /* Set the new color */ } pterm0(); /* Exit back to the desktop */ } In C, this could have been done more compactly (there really wasn't a need to use an extra color variable) but I wrote it this way because it more closely follows how the assembly program works. Here's the assembly version: * Desktop color inverter * Some Assembly Required, Article 3 * I use d3 as index. I didn't use d0 because it is "trashed" by TOS. * I use d0 as color, because I don't call TOS before I'm finished * with the value (so it never has a chance to trash it). * Set things up for our loop. moveq #15,d3 ; index starts at 15. While index is really ; just a short (not a long), we're not doing ; anything with the higher 16 bits, so we ; can use moveq and fill in all 32 bits and ; not worry about it. * Do the body of the loop. loop move.w #-1,-(sp) ; Push -1 onto the stack (returns old color). move.w d3,-(sp) ; This is our color number, index. move.w #7,-(sp) ; Function number for setcolor. trap #14 ; Call XBIOS. addq #6,sp ; Remove our parameters from the stack. ; setcolor() returns the old color value in ; d0, so I use it right where it is. not.w d0 ; Flip all the color bits. move.w d0,-(sp) ; This is the new color value (inverted). move.w d3,-(sp) ; This is our color number, index. move.w #7,-(sp) ; Function number for setcolor. trap #14 ; Call XBIOS. addq #6,sp ; Remove our parameters from the stack. * Now update index and see if we're finished with the loop. subq.w #1,d3 ; Decrement "index". bpl loop ; If the result is a positive (>= 0) value, ; this will branch to "loop", processing the ; next color. * We're done, exit back to the desktop. clr.w -(sp) ; Function number for pterm0 (0). trap #1 ; Call GEMDOS. That's all. If you follow the flow of the program, you will notice that the assembly program does not check the for condition (index >= 0) before entering the loop. For this example, it's okay, as we know the first time through the loop (at least), index >= 0 will be TRUE. The C definition of for, however, checks the condition before entering the loop. (We could do this by branching to our test before entering the loop.) This program does assume that it's running in an ST graphics mode; if you have something nicer, you may want to switch to an ST graphics mode to convince yourself this program really does work. (Run the program a second time to restore the colors.) ARE WE DONE? That's all for this month. Next month I'll go over more looping and branching instructions, and show you ways to use them to piece together some high-level structures like IF, FOR, WHILE, and so on. As a closing note, I'd like to point out that all of the Motorola manuals I have give instructions and registers and everything else in all upper case. Generally I'm not fond of all upper case, and since most assemblers don't really care whether you use upper or lower case, I use lower case. You can use whatever makes you happy. (If you have questions regarding any of these articles, don't hesitate to contact me. You can reach me at DMJ on GEnie, or dmj@genie.geis.com from the Internet.) /***********************************************************************/ C Programming Column By: Albert Dayes /***********************************************************************/ //// A new C Book and Configuration files At the Software Development conference I picked up a new book on programming called "C Pointers and Dynamic Memory Management". It's the only book I have seen that deals strictly with pointers in C. It includes a 3.5 inch floppy disk with all of the source code examples used in the book. It covers pointers for beginning to advanced C programmers. A review will follow in the next issue of AEO-PJ. For those who enjoy MicroSoft Windows style configuration files similar to WIN.INI, there is some code just for you. The March 1994 issue of Dr. Dobbs Journal had an article called "MULTIPLATFORM .INI FILES" which provides this capability. If you are not familar with *.INI files an example from Adobe Acrobat Reader follows. [AdobeViewer] IS8514=4 DefaultMag=100 ShowLargeDIBS=1 Chameleons=0 GreekThreshold=6 MaxApp=1 [RecentFiles] File-1=D:\MANUAL.PDF File-2=D:\INTRO.PDF File-3=D:\HELPREAD.PDF Each *.INI file is divided into sections and entries. The sections are enclosed in [] and the entries follow. The entries are in the form of entry_name=entry_value. //// Functions There are several useful functions in the C library, but one of the most useful ones is printf() and its offspring. The printf() allows one to have formatted output, which is useful in itself. Sprintf() is one of the most used functions since the output is directed to a buffer rather than standard output. This allows for creating message strings for GEM form alert that can include different error messages. For example: char alert_buffer[100]; int error_number; error_number = 37; sprintf( alert_buffer, "[1][ Disk error # %d ][ OKAY ]", error_number ); form_alert( 1, alert_buffer ); When it comes to outputting strings as part of the output, it can be somewhat of a problem. The length of each string is dynamic but it can be controlled using special options within the printf() function. To set the minimum width for a string use the following... char string[100], buffer[100]; int width, max_width; strcpy( string, "This is not a long string." ); sprintf( buffer, "%*s", width, string ); To set the maximum width one can use the following... sprintf( buffer, "%*.*s", width, max_width, string ); Being able to set the maximum width of a string has many uses. One such use is in printing reports on a printer. If you have a database with a 100 character description field it must be limited if other data is going to fit. (This is assuming that each printer line is 80 characters in length.) One could limit the max output to 20 characters with the minimum being 5 characters. For example sprintf( buffer, "%*.*s", 5, 20, string ); For left justified text one can use a negative value for the width. For example: sprintf( buffer, "%*.*s", -5, 20, string ); This is different than the normal use of printf() since the values within the format string are dynamic rather than static. The format string is defined as follows. "%*.*s" which equals "%[width].[precision]s" With string data type, the precision becomes the maximum width allowed. By using "*" rather than numbers, one can control the look of the output from within the program. (That is, at run time and not at compile time.) For example one could open a dialog box and ask the user to input the maximum length of a field for sending output to a file. #define AEOPJ_ANSI 1 main() { int field_description_length; field_description_length = get_description_length(); perform_output( field_description_length ); return(0); } /* main() */ #if AEOPJ_ANSI > 0 perform_output( int field_length ) #else perform_output( field_length ) int field_length; #endif { char big_buffer[100]; char descript_string[] = "Database field description"; /* make the minimum field description length at least 1 character */ sprintf( big_buffer, "%*.*s\n", 1, field_length, descript_string ); /* print big_buffer to the file */ return(0); } /* perform_output() */ For more information on how printf() family is implemented a good book on the subject is "The Standard C Library" by P.J. Plauger, ISBN 0-13-131509-9. Next time, more functions will be discussed and some pointers might be thrown in as well. /***********************************************************************/ Advanced Computing By: Carl Barron /***********************************************************************/ //// Introduction to YACC (Yet Another Compiler Compiler) This time I will take our syntax checker of an alert box language and create a compiler to create a C file of functions that will display the alert boxes. We need some more of yacc's directives to do this. We are going to pass character pointers to strings and integers for other parameters. A union is the 'proper' way to do this in C and yacc provides a %union directive to create a stack type that is a union. The syntax is %union { /* C definition of the union fields */ } so after THE %} of alert.y we add %union { char *id; int num; } Yacc also provides a way for it to remember which union element to access for each terminal and non-terminal symbol. Last time I gave a simplified definition of the %token directive. The full blown definition is %token <%union field name or nothing> . To continue modifying our previous yacc file change the %token NUMBER line to :%token NUMBER and the %token QSTRING line to %token ID QSTRING. ID is a new token for an unquoted string. In the actual definition of the language, we now add some C code to aid our compiler. Much of the work is done in the associated file alert.c. This file checks the semantics of the current defintion for illegal conditions like more than five alert strings, etc. The new grammar section is: %% alerts : alert /* this allows multiple alert */ | alerts alert /* boxes per file */ ; alert : alert_strt alert_data alert_end ; alert_strt : alert_hdr ID {add_id($2);/* save ID */} ; alert_end : END {write_alert();clean_alert();} ; alert_hdr : ALERT | error ALERT {clean_alert();} ; alert_item : ICON NUMBER {if(add_icon($2)) YYERROR;} | DEFAULT NUMBER {if(add_default($2)) YYERROR;} | STRING QSTRING {if(add_string($2)) YYERROR;} | BUTTON QSTRING {if(add_button($2)) YYERROR;} ; alert_data : alert_item | alert_data alert_item ; Note that this grammar appears to allow an infinite number of items in an alert box! The add functions check to make sure that the system limits are not exceeded and there is at least one string and button. This is the easiest way to handle the problem of a finite max number of entries in a grammar. It is possible to create a grammar definition that would handle this but it is much more cumbersome and unneeded. The lexer is a bit about the same the only entries changed are for NUMBER, ID and QSTRING. NUMBER and ID just return the lexigraphic value of these tokens in the proper field of the union. Yylval is defined by yacc to hold this infromation. STR was used in the old lex file and string in the new one for some reason. The new one checks for an unterminated string and prints a warning if a newline preceeds the closing quote of a string. The start state eat is used to eat the closing quote or newline, and to exit back to the INITIAL start state of the lexer. The additional C code does all the work of keeping track of what we have so far. and printing out a C function for each alert box defined without error conditions. Error is a special yacc non-terminal symbol used when yacc is in an error correcting state. The usage in this grammar is to skip to the next possibly correct alert box definiton, if there is an error, deleting all infromation about the invalid alert defintion. YYERROR is a yac directive [actually a preprocessor macro] to place yacc in an error correcting state. The file symbol.c contains my special purpose memory allocators for this project. They keep a linked list of all memory that is allocated by malloc(), by this program. This to make memory deletion complete and correct even under an error condition. If the only place the addresses returned by malloc() were stored was the yacc stack, and an error occurred the addresses would be lost before the memory can be freed. This is important to remember. In writing this article I noted some gross errors in the first article. So gross that the code should never have made it thru yacc! Nobody complained or mentioned it. This seems to indicate that prehaps I am talking to no one! (The perils of publishing untested code.) The code in the previous article was untested. The complete tested source and executables of this alert box compiler are enclosed in cmpalert folder or archive. As ussual I am on CIS and GENIE almost every day at least once. GENIE:CBARRON CIS:75066,3204 Perhaps I will do some more yaccing next time, or maybe present an overview of important unix style tools for text file manipulations often done by programmers. /***********************************************************************/ GFA BASIC By: Scott R. Garrigus /***********************************************************************/ //// Introducing... Hi Everybody! My name is Scott R. Garrigus and I'll be your new GFA BASIC liason here at AEO-PJ. (You can call me Mr. Garrigus if you'd like. ) We'll be covering the many facets of our beloved language including using the Resource Construction Set and incorporating its output into our programs, memory management of GFA and the bugs therein :-(, and we'll also be exploring GEM programming taking up where our good friend Eric Goodman left off, as well as anything else that has to do with GFA. //// Strike up the band! Which brings us to a very important person in the GFA world; someone whom I'm sure a lot of you may know... Mr. Han Kempen. Mr. Kempen is the author of 'Your Second GFA-BASIC 3 Manual', which is available free of charge on any of the online services. This manual includes no less than 24 chapters of documentation pertaining to the ins and outs of GFA BASIC. And if that's not enough, it also includes the largest library of GFA BASIC routines on the planet - at least the largest that I know of. If you need to do something specific in GFA, you can usually find an example of it here. The only thing I didn't like was that all the doc files were in 1st Word format and I only have an ASCII viewer, so I've taken the liberty of converting all the docs to ASCII format and you can find them in the Atari ST Library on GEnie as MANUAL_A.ZIP. I'd like everyone to give Mr. Kempen a big round of applause for his valient effort to keep our favorite language alive. Thank you Mr. Kempen! We really appreciate your efforts! And if it hasn't become clear already, if you don't have these files, then go get'em because we'll be using them when needed. //// On with the show... the RCS, that is. Okay, I've introduced myself; I've talked about Mr. Kempen's excellent contributions; let's see... what else is there to do? Ah, yes, maybe we should do a little programming, huh? :-) Well, first I want you to find the files TOSI_10.DFN, TOSI_10.LST, and TOSI_10.RCS (they're included here in this archive). These are the files we'll be working with today and they are the start of a small utility program which we'll be putting together. The program is called TOS Info 1.0 and it will be able to run as either a PRG or an ACC just by renaming it, be resolution independent, and be compatible with all the Atari systems and TOSes out there. Sound complicated? Don't worry, it's not really... and if it sounds too simple, well, then you're ahead of me but you may find a few interesting tidbits you hadn't learned before so stick with us, okay? Now let's zap outa here and get into the RSC program. If you have a multitasking system just run the RSC.PRG, if not then load this magazine into your favorite desk accessory text editor and then run it from within the RSC. Here we go... ...okay I'm here! Coming to you live from within the RCS S S s s s... Did you make it? :-) DON'T open the TOSI_10.RCS file yet. I want to take you through this step by step. You can look at what I've done when we're finished. First we need a box to display inside of our program's window. We're going to make this resolution independent so we should use a Dialog box. The reason for this is because within a Dialog box, all our elements will be snapped into place and they'll appear the same way in any resolution we run the program in. If we were to use a Panel then we could place elements anywhere we wanted but they wouldn't appear the same in different resolutions. So grab a Dialog box and name it MAIN and then open it. Now we need four display elements to show the TOS version, TOS date, System time, and the System date. Grab an EDIT:______ element (w/o the box around it) and place it on the screen. Double-click it to edit it and on the first, second and third lines, enter TOS Version: ~~~~~~~~~~ ~~~~~~~~~~~~~XXXXXXXXXX ~~~~~~~~~~~~~__________ This will give us an editable field with a label so that when we enter a value for it in our program only the underlines will change and the label TOS Version: will stay the way it is. Now to explain this, the first line gives us our label and saves a space for our data. The second line shows what type of data will be allowed... using X means any type of data is allowed be it numerical or alphabetical. The third line gives us a mask to show where the data will appear (represented by the underlines). From here we give the element a name, TOSVERS, and we hit Okay to accept it. Now make three copies of this element and with each one, place it on the display, changing the first line to TOS Date: , System Time: , and System Date: , respectively. (And be sure to give each a name.) Place the elements so they line up with each other and then resize the main box so it's just big enough to hold the elements. Close the dialog box. Next we need a menu bar for our program. Grab the menu icon and place it on the screen. Give it a name such as MENU , and then open it up. You'll see a menu bar and two titles in it. Select the file title and delete it. We won't be needing it in this program. Now click on the Desk title to open it and double-click on the first entry. Type in the name of our program leaving two spaces at the begining and the end to make it look good (ex. TOS Info 1.0 ) and give it a name such as DESKMENU. Click on okay, and we're done. Now wasn't that easy? We could also add a credit dialog like I did but I'm sure you can figure that out from looking at the file I've provided. Be sure and study the TOSI_10.RSC file thoroughly so you can get a good understanding of how it's put together and if you have any questions, just send them my way and I'll cover them in the next installment. //// Coming up... Next time we'll be covering memory management in GFA and how to find the proper amount of memory for our program (thanks to the help of my good friend Damien Jones whom I've been hounding for info. for the past two weeks ). I'll be giving you the first part of the listing for our utility program and I'll also be giving you your first homework assignment... (hee hee hee). Until next time...! /***********************************************************************/ HARD CORE - Interview with Roger Burrows, author of ExtenDOS By: Albert Dayes /***********************************************************************/ AD: What is your product for the Atari ST or Falcon030? RB: The product is ExtenDOS, a CD-ROM driver for the ST, TT030, and now the Falcon030 as well. It allows you to access the most popular CD-ROM formats (ISO-9660 and High Sierra) on any Atari system. It really performs the same function as the CDROM.XFS file system driver for MultiTOS/MiNT, but with two advantages: you don't need MultiTOS or MiNT, and you get better performance. AD: What prompted your interest in CD-ROM? RB: I wanted access to all the data starting to become available on CD-ROM, including source code, electronic text, and graphics, and I wanted access from my TT. I looked around but there didn't seem to be a well-supported, easy-to-use method, so I decided to write my own. AD: How long did it take to develop ExtenDOS? RB: About 6 months, working in the evenings and on weekends. I started work on it in June 1993, began beta-testing at the end of September, and shipped the first version in January this year. AD: What technical difficulties did you encounter and how did you overcome them? RB: The greatest difficulty was debugging the hardware support code during beta test, when I had no hands-on access to the systems being debugged. I relied very much on the problem descriptions by the beta testers. Fortunately the people doing it had had previous beta test experience. I also added trace and debugging code to my drivers, some of which remains in the distributed product, to help out if a user experiences problems. While adding the Falcon support, there were some initial problems because I didn't have all the hardware documentation. However, thanks again to a beta tester, I borrowed a Falcon for a few days and figured out the missing information. AD: What programming language did you use? RB: ExtenDOS is written entirely in 68000 assembler. Since it has to interface to the ACSI/SCSI hardware at a low level, it seemed the best choice, although it would have been possible to write it in a mixture of C and assembler. AD: Compare and contrast the ISO-9660 filesystem vs GEMDOS. RB: The ISO-9660 filesystem is optimised for a relatively slow, read-only, direct-access device such as a CD-ROM. Since the device has relatively long seek times, a hierarchical directory structure like GEMDOS would slow down access because of the constant seeking between directories. Thus ISO-9660 has all the paths to the directories stored in a single path table which is typically read into a buffer when a new CD-ROM is loaded, and remains there. The read-only nature of CD-ROM ensures that files cannot be deleted. Thus there is no need to support the possibility of 'holes' in allocated file space, and the FAT mechanism found in GEMDOS doesn't exist. Each file is stored sequentially on the CD-ROM, which helps performance when reading a file. ISO-9660 is also designed to be architecturally independent, in that any numbers that need more than a byte to store them (such as filesizes or some internal pointers to filesystem structures) are stored in two forms: high-order byte first (Motorola-style) and low-order byte first (Intel-style). In contrast, GEMDOS stores such data in only one form: Intel-style (this is necessary since GEMDOS is designed to be compatible with MSDOS at the filesystem level). Finally, in order to be applicable to the widest range of platforms, ISO-9660 implements a minimal set of file attributes that correspond fairly well to those in GEMDOS: file date/time is provided as well as an attribute that corresponds to GEMDOS's "hidden file" attribute. The "read-only" and "system" attributes are not provided. AD: What future enhancements are you planning for, or thinking about, for future editions of your product? RB: The next enhancement I am planning is support for photoCD (including multi-session). The main effort in this area will be supporting the wide range of implementations that different manufacturers of CD-ROM drives have used. Another area that I am thinking about is integrated support for playing audio CDs. It should also be feasible to read Mac HFS-format CD-ROMs, although that's not a priority since most CD-ROMs are ISO-9660 these days. Longer term, ExtenDOS could be used to add other facilities apart from CD-ROM, and I am looking at that too. AD: Any hardware that you recommend or that is compatible with your product? RB: To connect a SCSI CD-ROM drive to the ACSI port of an ST or TT, you need to use one of ICD's adapters. This is in order to pass the full SCSI command set to the CD-ROM. I use the AdSCSI Plus, but ICD have told me that all the following current and former ICD adapters use the same method to provide full SCSI, so they should all work equally well: Advantage ST Advantage Micro ST Advantage Plus ST, AdSCSI ST AdSCSI Micro ST AdSCSI Plus ST The Link. ICD received a copy of ExtenDOS recently and I'm waiting for them to confirm compatibility. As far as CD-ROM drives are concerned, any SCSI drive should work with ExtenDOS, since it only uses the most basic SCSI commands. There is also code in ExtenDOS to specifically support the Atari CDAR504, the only drive that can connect directly to the ACSI port. The following drives have been verified to work with ExtenDOS: Atari CDAR504 Panasonic (Matsushita) CR-501 NEC 3Xp NEC 74/84 Sony CDU-541 Toshiba 3401 If you are contemplating buying a CD-ROM drive now, I would recommend getting one that supports the SCSI-2 command set. This standardises many of the low-level commands, and will make it more likely that additional features of the drive, such as audio control, will be supported by future versions of ExtenDOS. You may also want to make sure that the drive supports multi-session photoCD, although I haven't found any SCSI-2 compatible drives that don't. I personally use a Toshiba 3401 since it offers full SCSI-2 command set compatibility, as well as photoCD support that is very easy to implement, and very good performance. Other drives that have been well-reviewed include the NEC, Chinon, and Plextor (formerly Texel), although I have had no experience with the latter two. [ Editor's note: ExtenDOS v1.1 is available immediately at only $19.95 (including shipping & handling) from: Anodyne Software 6 Cobbler Court Ottawa Ontario K1V 0B8 CANADA. Please make your payment by cheque or money order, in US$ for shipping to the U.S.A., in Canadian$ for shipping within Canada. Ontario residents please add 8% sales tax. Also contact your local Atari dealer to see if they carry the product. ] /***********************************************************************/ DABBLING IN PASCAL By: Kris Gasteiger /***********************************************************************/ (I was going to include an input verification routine for last month's program, but I lost it along with some other goodies when my hard drive crashed.) I am currently using OSS/ICD Personal Pascal, Ver 2.02. on a 2.5Mb 520ST with TOS 1.4, one double sided floppy drive, a ToadStor130 hard drive, SC1224 color monitor, 2400 baud modem, 24 pin printer, and a few other periferals. All code examples I present will run on MY system, other TOS versions, may give problems, be cautious. A reader asked for some help in getting the Bios call, Bconin, used in the example program last month, to work in Modula II. I don't have Modula II, but from his description of the Modula II version of the call, the problem seems to be that while PP allows you to declare Bconin as Byte, Short_Integer, or Long_Integer, M II declares it as Long_Integer. If Declared as Long_Integer, Bconin returns the Ascii value of the key in the low word ,and the keyboard Scan Code in the high word. (A word is 16 bits, a long word is 32 bits, so there are 4, 8 bit, bytes in a long word.) The problem then is, how do you extract just the ASCII value, the lowest Byte, from a 32 bit long word? The following short program demonstrates... (The text between the dashed lines is a complete Pascal program which I have compiled and run on MY system.) --------------------------------------------------------------------------- { This program is to be compiled for TOS by setting the compiler options } { to TOS in the PP manager. } { It's purpose is to demonstrate how to use the arithmetic shift to } { extract the scan code and ascii value from the Long_Integer returned } { by Bconin. } { Written in OSS/ICD Personal Pascal. 1/22/94 By: Kris J. Gasteiger. } { Parts copywrited by OSS/ICD. } Program Key_read( Input, Output ); Const Keyboard=2; { Bconin looks for a character on the specified device. } { Valid devices are: 1: the serial port, 2: the keyboard, } { and 3: the MIDI port. devices 0 and 4 aren't valid for } { this call as far as I can tell... } Esc=65563; { Raw Long_Integer value returned by Bconin. } Var Ascii_Value, Keypressed, Temp: Long_Integer; { ************************************************************************ } { Bios Character-Oriented Device Input. Gets a character from the } { specified device. } Function Bconin( Device: Short_Integer ): Long_Integer; Bios( 2 ); { Note: A long_Integer is 32 bits, a Short_Integer is 16 bits, and a Byte } { is 8 bits UNSIGNED. These are all valid declarations for Bconin in PP. } { ************************************************************************ } { Main } Begin Writeln( 'Press a key, ends program.' ); Repeat Keypressed:=Bconin( Keyboard ); { Get a key from the keyboard. } Temp:=Shl( Keypressed, 16 ); { Shift left to discard the high word. } Ascii_Value:=Shr( Temp, 16 ); { Shift right to Put the low word back.} { The second parameter to the shifts is the number of bits to shift in } { the direction of the call. Anything shifted beyond the declared size } { of the variable parameter is lost. EG: Shr( byte, 1 ) discards the } { right most bit of the byte. If the byte is all ones, ( 11111111 ), } { after the call, its highest bit will be a zero........( 01111111 ). } { Shifting it back, Shl( byte, 1 ) will give............( 11111110 ). } { However, if the byte contains.........................( 01111110 ), } { then Shr( byte, 1 ) will give.........................( 00111111 ), } { and Shl( byte, 1 ) will give..........................( 01111110 ). } { Display the Ascii value and the character. } Writeln( 'Low word, Ascii value: ', Ascii_Value, '=', Chr(Ascii_Value ) ); { Extract the high word and display it.} Writeln( 'High word, Scan code: ', Shr( Keypressed, 16 ) ); Writeln; Until Keypressed=Esc; { End the program if the Escape key is pressed. } End. --------------------------------------------------------------------------- I hope that is of help to you readers who are translating to other languages or trying to understand the different faces of Bconin. Next time, we'll take that look at parts of GEM, and that simple printer utility, maybe! Until then, have fun dabbling! /**********************************************************************/ The Library: Gemini, a new Atari CD-ROM disc by Damien M. Jones /***********************************************************************/ I should warn you that my "real" job - when I'm not writing Atari software - is to write multimedia CD software on the PC. Perhaps I'm not the best person to review this disc, but I let slip that I had one of these discs, and Albert Dayes insisted I write a review. (Albert's very persuasive... no! No! Please don't hit me Albert, I'll get this review done! Really! ) Ahem. Back to the review. I'll start on the outside, since it's the first thing I saw when I pulled the disc out of the nice, padded envelope it was mailed to me in. The disc comes in a jewel case, which is pretty much standard for CD-ROMs these days. (I won't mention how many discs I've seen in cheap plastic sleeves, because that's another story.) The artwork on the case is tastefully done; from the outside it appears that this is a high-quality disc, which is appreciated. Opening the jewel case, I found the CD; again, the art is tastefully done, but it includes a befuddling line on the disc: "Type GO to start". Hmmm, must be a mistake. Somebody's been spending too much time in DOSland. I took the disk out of the case and slipped it into my PC. (I don't have a CD-ROM drive attached to my Atari, so I'm forced to look at the disk through Messy-DOS.) It didn't take me long to miss the ease of browsing files I get with my Atari, as well as my favorite file viewer (View II). But somehow I found the will to press on. The disk contains two copies of each file, really. In one folder (FILES) is the uncompressed set; this is great for poking through what's there to see what you like and what you don't like. The other folder (ZIP) contains compressed versions of the same files; most of these are compressed with ZIP or LZH. This is ideal if you run a BBS, as there are also pre-made indexes for several BBS packages. Since I'm not running a BBS on this machine, I dived right into the FILES folder and started puttering around. There's another layer of folders here, splitting this huge library into manageable categories. Here's a list (please excuse the DOS format): Volume in drive D is ATARI_1293 Directory of D:\FILES [.] [..] [ACC] [ARCHIVER] [ASTRONMY] [BBS] [CLI] [DATABASE] [DEMO] [DISKUTIL] [DTP] [EDITORS] [EMAG] [EMDEMO11] [EMULATOR] [ETFILES] [FALCON] [FONTS] [GAGS] [GAMES] [GDOS] [GEMINI] [GENIE] [GNU] [GRAPHICS] [JAGUAR] [LANGUAGE] [LYNX] [MATH] [MINT] [MUSIC] [NEODESK] [OTHER] [PORTFOLI] [PROGRAM] [SCRNSAVE] [SP_SHEET] [TELECOMM] [TT] [UTILITY] [VIRUS] [W_PROCS] 42 file(s) 0 bytes 0 bytes free Remember, each of these names is another folder... and many of them are organized even more inside. This may seem like a bit much, but the disc boasts over 2800 programs - if these weren't organized, it'd be almost impossible to find anything. Each program, actually, has its own folder, so you can keep track of which file goes with which program. Almost every folder has a 00_INDEX.TXT file, which is a list of the folders that contain files, and a brief description of what the program does. Here's a sample from the VIRUS folder: Virus utilitys \virus\ atarivir\ Doc describing various atari viruses bootech\ Boot technician, repair, modify, work with boot sector chasseur\ Anti virus co_pilot\ Not really an anti virus, but could be useful fcheck25\ Link virus detector flu\ Simulates a virus, but isn't actually one grab_bag\ Screen dump and anti virus, with C codes hospital\ Help for preventing virus contamination noroach\ TT/MegaSTE boot delay setup and virus guard monomon\ Disk Editor and Utility peneciln\ One fo the 1st virus detectors protect6\ Erik Lars' new one sagrotan\ Great new virus killer. Able to learn new viruses uvk58dem\ Ultimate Virus Killer (Demo version) virend31\ Virus killer virusdie\ Virus killer viruskil\ Virus killer vkiller\ The 'best' of the virus killers, version dated 5/27/91 Most of the listings are MUCH longer than this one. For example, the MUSIC folder has 160 folders inside it, each with something different. It may take me a long time to fully explore what's on this disc, there's so much. Something that can be very useful is the INDEX.TXT in the root directory of the disc. It's a list of every file in the ZIP folder. So how useful is that? Well, the FILES folder and the ZIP folder are organized the same way - so if you know where a file is in the ZIP folder, you know it will be in about the same place in the FILES folder. With a good text viewer, you can search the INDEX.TXT file for something in particular, and it will jump right to that spot. Make a note of where the file is, and go find it. This is generally faster than trying to search the directories - even if you have a program search the directories, it can take a long time, because there are so many. That's pretty much all there is to the disc. Lots and lots of programs, well-organized, with reasonably good indexes. I should point out (as the disc's "authors" do) that many of the programs on the disc have been updated since the program was found; if you like a program, be sure to check local BBSs, GEnie, Delphi, or wherever to see if there is a more current version. Also keep in mind that much of what's on the disc is Shareware. If you use the Shareware, you are still required to pay for it. (Buying the disc only covers the cost of collecting all the programs into one place.) This disc has great value as a collection of useful software for all Atari computers. There are quite a few pictures, fonts, animations - something for everyone. It's not meant to be an end-all collection; software moves too fast for that ever to happen. But it is a fantastic resource. If you have a CD-ROM drive attached to your Atari computer, this disc will give you a chance to do something with it. (Maybe it will even give you an excuse to BUY a CD-ROM drive.) Walnut Creek CD-ROM 1547 Palos Verdes, Suite 260 Walnut Creek, CA 94596 USA (800)-786-9907 (voice) (510)-674-0821 (fax) /**********************************************************************/ PERIODICALS By: John Perry Barlow /**********************************************************************/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-Copyright 1993,4 Wired USA Ltd. All Rights Reserved=-=-=-=-=-= -=-=For complete copyright information, please see the end of this file=-=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= WIRED 2.04 Electrosphere ************* Jackboots on the Infobahn ^^^^^^^^^^^^^^^^^^^^^^^^^ Clipper is a last ditch attempt by the United States, the last great power from the old Industrial Era, to establish imperial control over cyberspace. By John Perry Barlow [Note: The following article will appear in the April 1994 issue of WIRED. We, the editors of WIRED, are net-casting it now in its pre-published form as a public service. Because of the vital and urgent nature of its message, we believe readers on the Net should hear and take action now. You are free to pass this article on electronically; in fact we urge you to replicate it throughout the net with our blessings. If you do, please keep the copyright statements and this note intact. For a complete listing of Clipper-related resources available through WIRED Online, send email to with the following message: "send clipper.index". - The Editors of WIRED] On January 11, I managed to schmooze myself aboard Air Force 2. It was flying out of LA, where its principal passenger had just outlined his vision of the information superhighway to a suited mob of television, show- biz, and cable types who fervently hoped to own it one day - if they could ever figure out what the hell it was. From the standpoint of the Electronic Frontier Foundation the speech had been wildly encouraging. The administration's program, as announced by Vice President Al Gore, incorporated many of the concepts of open competition, universal access, and deregulated common carriage that we'd been pushing for the previous year. But he had said nothing about the future of privacy, except to cite among the bounties of the NII its ability to "help law enforcement agencies thwart criminals and terrorists who might use advanced telecommunications to commit crimes." On the plane I asked Gore what this implied about administration policy on cryptography. He became as noncommittal as a cigar-store Indian. "We'll be making some announcements.... I can't tell you anything more." He hurried to the front of the plane, leaving me to troubled speculation. Despite its fundamental role in assuring privacy, transaction security, and reliable identity within the NII, the Clinton administration has not demonstrated an enlightenment about cryptography up to par with the rest of its digital vision. The Clipper Chip - which threatens to be either the goofiest waste of federal dollars since President Gerald Ford's great Swine Flu program or, if actually deployed, a surveillance technology of profound malignancy - seemed at first an ugly legacy of the Reagan-Bush modus operandi. "This is going to be our Bay of Pigs," one Clinton White House official told me at the time Clipper was introduced, referring to the disastrous plan to invade Cuba that Kennedy inherited from Eisenhower. (Clipper, in case you're just tuning in, is an encryption chip that the National Security Agency and FBI hope will someday be in every phone and computer in America. It scrambles your communications, making them unintelligible to all but their intended recipients. All, that is, but the government, which would hold the "key" to your chip. The key would separated into two pieces, held in escrow, and joined with the appropriate "legal authority.") Of course, trusting the government with your privacy is like having a Peeping Tom install your window blinds. And, since the folks I've met in this White House seem like extremely smart, conscious freedom-lovers - hell, a lot of them are Deadheads - I was sure that after they were fully moved in, they'd face down the National Security Agency and the FBI, let Clipper die a natural death, and lower the export embargo on reliable encryption products. Furthermore, the National Institutes of Standards and Technology and the National Security Council have been studying both Clipper and export embargoes since April. Given that the volumes of expert testimony they had collected overwhelmingly opposed both, I expected the final report would give the administration all the support it needed to do the right thing. I was wrong. Instead, there would be no report. Apparently, they couldn't draft one that supported, on the evidence, what they had decided to do instead. THE OTHER SHOE DROPS On Friday, February 4, the other jackboot dropped. A series of announcements from the administration made it clear that cryptography would become their very own "Bosnia of telecommunications" (as one staffer put it). It wasn't just that the old Serbs in the National Security Agency and the FBI were still making the calls. The alarming new reality was that the invertebrates in the White House were only too happy to abide by them. Anything to avoid appearing soft on drugs or terrorism. So, rather than ditching Clipper, they declared it a Federal Data Processing Standard, backing that up with an immediate government order for 50,000 Clipper devices. They appointed the National Institutes of Standards and Technology and the Department of Treasury as the "trusted" third parties that would hold the Clipper key pairs. (Treasury, by the way, is also home to such trustworthy agencies as the Secret Service and the Bureau of Alcohol, Tobacco, and Firearms.) They reaffirmed the export embargo on robust encryption products, admitting for the first time that its purpose was to stifle competition to Clipper. And they outlined a very porous set of requirements under which the cops might get the keys to your chip. (They would not go into the procedure by which the National Security Agency could get them, though they assured us it was sufficient.) They even signaled the impending return of the dread Digital Telephony, an FBI legislative initiative requiring fundamental reengineering of the information infrastructure; providing wiretapping ability to the FBI would then become the paramount design priority. INVASION OF THE BODY SNATCHERS Actually, by the time the announcements thudded down, I wasn't surprised by them. I had spent several days the previous week in and around the White House. I felt like I was in another remake of The Invasion of the Body Snatchers. My friends in the administration had been transformed. They'd been subsumed by the vast mindfield on the other side of the security clearance membrane, where dwell the monstrous bureaucratic organisms that feed on fear. They'd been infected by the institutionally paranoid National Security Agency's Weltanschauung. They used all the telltale phrases. Mike Nelson, the White House point man on the NII, told me, "If only I could tell you what I know, you'd feel the same way I do." I told him I'd been inoculated against that argument during Vietnam. (And it does seem to me that if you're going to initiate a process that might end freedom in America, you probably need an argument that isn't classified.) Besides, how does he know what he knows? Where does he get his information? Why, the National Security Agency, of course. Which, given its strong interest in the outcome, seems hardly an unimpeachable source. However they reached it, Clinton and Gore have an astonishingly simple bottom line, to which even the future of American liberty and prosperity is secondary: They believe that it is their responsibility to eliminate, by whatever means, the possibility that some terrorist might get a nuke and use it on, say, the World Trade Center. They have been convinced that such plots are more likely to ripen to hideous fruition behind a shield of encryption. The staffers I talked to were unmoved by the argument that anyone smart enough to steal a nuclear device is probably smart enough to use PGP or some other uncompromised crypto standard. And never mind that the last people who popped a hooter in the World Trade Center were able to get it there without using any cryptography and while under FBI surveillance. We are dealing with religion here. Though only ten American lives have been lost to terrorism in the last two years, the primacy of this threat has become as much an article of faith with these guys as the Catholic conviction that human life begins at conception or the Mormon belief that the Lost Tribe of Israel crossed the Atlantic in submarines. In the spirit of openness and compromise, they invited the Electronic Frontier Foundation to submit other solutions to the "problem" of the nuclear-enabled terrorist than key escrow devices, but they would not admit into discussion the argument that such a threat might, in fact, be some kind of phantasm created by the spooks to ensure their lavish budgets into the post-Cold War era. As to the possibility that good old-fashioned investigative techniques might be more valuable in preventing their show-case catastrophe (as it was after the fact in finding the alleged perpetrators of the last attack on the World Trade Center), they just hunkered down and said that when wiretaps were necessary, they were damned well necessary. When I asked about the business that American companies lose because of their inability to export good encryption products, one staffer essentially dismissed the market, saying that total world trade in crypto goods was still less than a billion dollars. (Well, right. Thanks more to the diligent efforts of the National Security Agency than to dim sales potential.) I suggested that a more immediate and costly real-world effect of their policies would be to reduce national security by isolating American commerce, owing to a lack of international confidence in the security of our data lines. I said that Bruce Sterling's fictional data-enclaves in places like the Turks and Caicos Islands were starting to look real-world inevitable. They had a couple of answers to this, one unsatisfying and the other scary. The unsatisfying answer was that the international banking community could just go on using DES, which still seemed robust enough to them. (DES is the old federal Data Encryption Standard, thought by most cryptologists to be nearing the end of its credibility.) More frightening was their willingness to counter the data-enclave future with one in which no data channels anywhere would be secure from examination by one government or another. Pointing to unnamed other countries that were developing their own mandatory standards and restrictions regarding cryptography, they said words to the effect of, "Hey, it's not like you can't outlaw the stuff. Look at France." Of course, they have also said repeatedly - and for now I believe them - that they have absolutely no plans to outlaw non-Clipper crypto in the US. But that doesn't mean that such plans wouldn't develop in the presence of some pending "emergency." Then there is that White House briefing document, issued at the time Clipper was first announced, which asserts that no US citizen "as a matter of right, is entitled to an unbreakable commercial encryption product." Now why, if it's an ability they have no intention of contesting, do they feel compelled to declare that it's not a right? Could it be that they are preparing us for the laws they'll pass after some bearded fanatic has gotten himself a surplus nuke and used something besides Clipper to conceal his plans for it? If they are thinking about such an eventuality, we should be doing so as well. How will we respond? I believe there is a strong, though currently untested, argument that outlawing unregulated crypto would violate the First Amendment, which surely protects the manner of our speech as clearly as it protects the content. But of course the First Amendment is, like the rest of the Constitution, only as good as the government's willingness to uphold it. And they are, as I say, in the mood to protect our safety over our liberty. This is not a mind-frame against which any argument is going to be very effective. And it appeared that they had already heard and rejected every argument I could possibly offer. In fact, when I drew what I thought was an original comparison between their stand against naturally proliferating crypto and the folly of King Canute (who placed his throne on the beach and commanded the tide to leave him dry), my government opposition looked pained and said he had heard that one almost as often as jokes about roadkill on the information superhighway. I hate to go to war with them. War is always nastier among friends. Furthermore, unless they've decided to let the National Security Agency design the rest of the National Information Infrastructure as well, we need to go on working closely with them on the whole range of issues like access, competition, workplace privacy, common carriage, intellectual property, and such. Besides, the proliferation of strong crypto will probably happen eventually no matter what they do. But then again, it might not. In which case we could shortly find ourselves under a government that would have the automated ability to log the time, origin and recipient of every call we made, could track our physical whereabouts continuously, could keep better account of our financial transactions than we do, and all without a warrant. Talk about crime prevention! Worse, under some vaguely defined and surely mutable "legal authority," they also would be able to listen to our calls and read our e-mail without having to do any backyard rewiring. They wouldn't need any permission at all to monitor overseas calls. If there's going to be a fight, I'd rather it be with this government than the one we'd likely face on that hard day. Hey, I've never been a paranoid before. It's always seemed to me that most governments are too incompetent to keep a good plot strung together all the way from coffee break to quitting time. But I am now very nervous about the government of the United States of America. Because Bill 'n' Al, whatever their other new-paradigm virtues, have allowed the very old-paradigm trogs of the Guardian Class to define as their highest duty the defense of America against an enemy that exists primarily in the imagination - and is therefore capable of anything. To assure absolute safety against such an enemy, there is no limit to the liberties we will eventually be asked to sacrifice. And, with a Clipper Chip in every phone, there will certainly be no technical limit on their ability to enforce those sacrifices. WHAT YOU CAN DO GET CONGRESS TO LIFT THE CRYPTO EMBARGO The administration is trying to impose Clipper on us by manipulating market forces. By purchasing massive numbers of Clipper devices, they intend to induce an economy of scale which will make them cheap while the export embargo renders all competition either expensive or nonexistent. We have to use the market to fight back. While it's unlikely that they'll back down on Clipper deployment, the Electronic Frontier Foundation believes that with sufficient public involvement, we can get Congress to eliminate the export embargo. Rep. Maria Cantwell, D-Washington, has a bill (H.R. 3627) before the Economic Policy, Trade, and Environment Subcommittee of the House Committee on Foreign Affairs that would do exactly that. She will need a lot of help from the public. They may not care much about your privacy in DC, but they still care about your vote. Please signal your support of H.R. 3627, either by writing her directly or e-mailing her at cantwell@eff.org. Messages sent to that address will be printed out and delivered to her office. In the subject header of your message, please include the words "support HR 3627." In the body of your message, express your reasons for supporting the bill. You may also express your sentiments to Rep. Lee Hamilton, D-Indiana, the House Committee on Foreign Affairs chair, by e-mailing hamilton@eff.org. Furthermore, since there is nothing quite as powerful as a letter from a constituent, you should check the following list of subcommittee and committee members to see if your congressional representative is among them. If so, please copy them your letter to Rep. Cantwell. > Economic Policy, Trade, and Environment Subcommittee: Democrats: Sam Gejdenson (Chair), D-Connecticut; James Oberstar, D- Minnesota; Cynthia McKinney, D-Georgia; Maria Cantwell, D-Washington; Eric Fingerhut, D-Ohio; Albert R. Wynn, D-Maryland; Harry Johnston, D-Florida; Eliot Engel, D-New York; Charles Schumer, D-New York. Republicans: Toby Roth (ranking), R-Wisconsin; Donald Manzullo, R-Illinois; Doug Bereuter, R-Nebraska; Jan Meyers, R-Kansas; Cass Ballenger, R-North Carolina; Dana Rohrabacher, R-California. > House Committee on Foreign Affairs: Democrats: Lee Hamilton (Chair), D-Indiana; Tom Lantos, D-California; Robert Torricelli, D-New Jersey; Howard Berman, D-California; Gary Ackerman, D-New York; Eni Faleomavaega, D-Somoa; Matthew Martinez, D- California; Robert Borski, D-Pennsylvania; Donal Payne, D-New Jersey; Robert Andrews, D-New Jersey; Robert Menendez, D-New Jersey; Sherrod Brown, D-Ohio; Alcee Hastings, D-Florida; Peter Deutsch, D-Florida; Don Edwards, D-California; Frank McCloskey, D-Indiana; Thomas Sawyer, D-Ohio; Luis Gutierrez, D-Illinois. Republicans: Benjamin Gilman (ranking), R-New York; William Goodling, R-Pennsylvania; Jim Leach, R-Iowa; Olympia Snowe, R-Maine; Henry Hyde, R-Illinois; Christopher Smith, R-New Jersey; Dan Burton, R-Indiana; Elton Gallegly, R-California; Ileana Ros-Lehtinen, R-Florida; David Levy, R-New York; Lincoln Diaz-Balart, R-Florida; Ed Royce, R-California. BOYCOTT CLIPPER DEVICES AND THE COMPANIES WHICH MAKE THEM. Don't buy anything with a Clipper Chip in it. Don't buy any product from a company that manufactures devices with Big Brother inside. It is likely that the government will ask you to use Clipper for communications with the IRS or when doing business with federal agencies. They cannot, as yet, require you to do so. Just say no. LEARN ABOUT ENCRYPTION AND EXPLAIN THE ISSUES TO YOUR UNWIRED FRIENDS The administration is banking on the likelihood that this stuff is too technically obscure to agitate anyone but nerds like us. Prove them wrong by patiently explaining what's going on to all the people you know who have never touched a computer and glaze over at the mention of words like "cryptography." Maybe you glaze over yourself. Don't. It's not that hard. For some hands-on experience, download a copy of PGP - Pretty Good Privacy - a shareware encryption engine which uses the robust RSA encryption algorithm. And learn to use it. GET YOUR COMPANY TO THINK ABOUT EMBEDDING REAL CRYPTOGRAPHY IN ITS PRODUCTS If you work for a company that makes software, computer hardware, or any kind of communications device, work from within to get them to incorporate RSA or some other strong encryption scheme into their products. If they say that they are afraid to violate the export embargo, ask them to consider manufacturing such products overseas and importing them back into the United States. There appears to be no law against that. Yet. You might also lobby your company to join the Digital Privacy and Security Working Group, a coalition of companies and public interest groups - including IBM, Apple, Sun, Microsoft, and, interestingly, Clipper phone manufacturer AT&T - that is working to get the embargo lifted. ENLIST! Self-serving as it sounds coming from me, you can do a lot to help by becoming a member of one of these organizations. In addition to giving you access to the latest information on this subject, every additional member strengthens our credibility with Congress. > Join the Electronic Frontier Foundation by writing membership@eff.org. > Join Computer Professionals for Social Responsibility by e-mailing cpsr.info@cpsr.org. CPSR is also organizing a protest, to which you can lend your support by sending e-mail to clipper.petition@cpsr.org with "I oppose Clipper" in the message body. Ftp/gopher/WAIS to cpsr.org/cpsr/privacy/crypto/clipper for more info. In his LA speech, Gore called the development of the NII "a revolution." And it is a revolutionary war we are engaged in here. Clipper is a last ditch attempt by the United States, the last great power from the old Industrial Era, to establish imperial control over cyberspace. If they win, the most liberating development in the history of humankind could become, instead, the surveillance system which will monitor our grandchildren's morality. We can be better ancestors than that. San Francisco, California Wednesday, February 9, 1994 * * * John Perry Barlow (barlow@eff.org) is co-founder and Vice-Chairman of the Electronic Frontier Foundation, a group which defends liberty, both in Cyberspace and the Physical World. He has three daughters. =-=-=-=-=-=-=-=-=-=-=-=WIRED Online Copyright Notice=-=-=-=-=-=-=-=-=-=-=-= Copyright 1993,4 Wired USA Ltd. All rights reserved. This article may be redistributed provided that the article and this notice remain intact. This article may not under any circumstances be resold or redistributed for compensation of any kind without prior written permission from Wired Ventures, Ltd. If you have any questions about these terms, or would like information about licensing materials from WIRED Online, please contact us via telephone (+1 (415) 904 0660) or email (info@wired.com). WIRED and WIRED Online are trademarks of Wired Ventures, Ltd. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [ Editor's Note: This is some background information on how RSA's technology works. This was provided by Kurt Stammberger, Technology Marketing Manager of RSA Data Security, Inc. RSA Technology - By Kurt Stammberger Privacy protection by conventional means such as DES (the government- sponsered Data Encryption Standard is relatively easy in small networks, requiring the exchange of secret encryption keys with each party. But as a network grows in size, using symmetric encryption techniques like DES by themselves becomes impractical. As the network grows, arranging for the secure exchange of all those secret keys becomes expensive to administer. Moreover, DES requires secret sharing: each person must trust the other to not reveal (or lose) the key they share. |========================================================================| Figure 1:: The Convention System: DES Alice encodes a document with a DES key ... Bob decodes the document with the same key. |---\ |---\ |---\ |---\ | | KEY (des) => | // | ----> | // | KEY (des) => | | |____| |____| |____| |____| Sharing secret keys in conventional systmes requires prior relationship between the parties. The classic "chicken and egg" problem with DES is how to exchange a secret key over an unsecure network with someone you don't necessarily trust. |========================================================================| This means that in partical implementations, secure communcations can only take place between people with some kind of prior relationship, e.g., only between employees of the same company. Finally, shared secret keys prevent either part from proving what the other may have done with that key. Either party could forge a document using the shared key, and a third party would be unable to identify the culprit. The 1976 theoretical work of Drs. Whitfield Diffie and Martin Hellman of Standford University came to fruition in 1977 wwith their development of the Diffie-Hellman Key Agreement technique, and the invention of the RSA Public Key Cryptosystem by Drs. Ronald Rivest, Adi Shamir and Len Aldleman, then professors at the Massachusetts Institute of Technology (MIT). RSA is, quite simple, a method of exchanging authenticated secret messages without exchanging secrets. Rather than using the same key to both encrypt and decrypt the data, the RSA system uses a matched pair of encryption and decryption keys. Each key performs a one-way transformation upon the data -- what one encrypts, only the other can decrypt. |========================================================================| Figure 2:: The RSA Public Key Concept |---\ |---\ |---\ |---\ | | KEY (PUB) => | // | ----> | // | KEY (PRIV) => | | |____| |____| |____| |____| Anything encrypted with someone's RSA public key can only be decrypted with the corresponding RSA private key, and vice-versa. |=========================================================================| Since it is computationaly infeasible to derive one key from the other, one of the keys can be made "Public" while the other key is kept "Private", or secret. To send someone a private message, one simply encrypts the message using the intended recipient's public key, confident in the fact that only the recipient's private key could decrypt it. This forms the basis for the RSA Digital Envelope (see figure #3). The RSA Digital Envelope providess an encrption solution that gives the user the best of both worlds: the speed of secret key algorithms like DES, combined with the security of RSA. Conversely, when a message is encrypted with a private key it provides the basis for a "digital signature" -- a scrambled message that only one person could produce, but everyone could verify with that person's public key. But handwritten signatures do more than just identify the author of a document, they in effect must vouch for the document's integrity. A manager's signature on a letter typed by a secretary says "I have reviewed this page, and the information it contains is the information that I do, in fact wish to send." The RSA algorithm can accomplish even this. |========================================================================| Figure 3:: Privacy : the RSA Digital Envelope |---\ |---\ | | KEY (DES) => | // | |____| |____| 1. Alice encrpts the document with a random DES key. ________ ________ KEY (DES) => [__ PUB__| => [__DES__| |KEY| | | _| | _|//| |___| |___| 2. Alice looks up Bob's RSA public key in her network directory, and uses it to encrypt the DES key. *************** * |---\ * * | // | * * |____| * * * * ________ * ----> * [__DES__| * * | | * * _|//| * * |___| * * * *************** 3. The encrypted document & key together form the RSA Digital Envelope. Only Bob's RSA private key can open this envelope "addressed" to him. |==========================================================================| The RSA Digital Signature employs a cryptographic "hashing" algorithm to create a message digest that is unique to each document, much like a fingerprint. If even a single bit of the document is changed, roughly 50 percent of the bits in the corresponding message digest will change. Furthermore, the hashing alogrithm is a one-way function: the document content cannot be reconstruction from the bits of the message digest. With RSA's MD family of message digest alorithms -- featuring 128-bit message digests -- the probability that different documents will have the same digest by coincidence is less than 1 in a trillion trillion, effectively ensuring that the two message digests will only match if their source documents are bit-for-bit identical. While the RSA Digital Signature is easy to produce and check it is impossible to forge, and therefore positively identifies the author. And unlike a handwritten signature, it also verifies the contents of a document. |========================================================================| Figure 4:: Authentication : the RSA Digital Signature |---\ | | ============ |____| | ******************** | * * | |========> * _______ * | * | \ * ----> ### * | | * ##### ===> * |_______| * ### | * | // | * | ________ | * -------- * | [__PRIV__| | * * V |KEY| | ******************** [.:..:] => _| | => [ // ] |___| Alice passes her document through a hashing algorithm to produce the message digest, then encrypts the digest with her RSA private key (forming an RSA Digital Signature) and transmits the signed document to Bob. # |---\ ### | | === ### ==============> [.:..:] <-------| |____| ### | # COMPARE | [ // ] ===> KEY (pub) ========> [.:..:] <-------- After receiving Alice's transmission, Bob uses the same hashing algorithm to create another message digest, and also decrypts the signature using Alice's RSA public key. The resulting message digests are then compared. |===========================================================================| Security The RSA Public Key Cryptosystem is recognized worldwide as the most secure cryptographic technique commercially available. To understand why RSA is so strong, you need to understand a little bit more about the math behind RSA. The RSA Algorithm is fully disclosed -- that is, there are no secrets about how the system actually works. RSA security is derived solely from its unqiue mathematical characterics. RSA public and private keys are actually each made up of two numbers -- an exponent and a modulus. The modulus is common to both public and the private key, and is the product of two very large prime numbers. Since the public key is, of course, made public the best course for a potential attacker to take is to attempt to factor the modulus back into its component primes, thereby gaining the information required to derive the private key. But factoring is one of the most fundamentally difficult mathematical tasks -- there are precious few "shortcuts." For example, using the best available techniques, factoring a single typical 200-digit RSA modulus would keep a network of one thousand high-powered (70 MIPS) workstations busy for over one thousand years. Even a Cray YMP supercomputer would take tens of thousands of years just to crack one user's key. Even with the availability of ever-increasing computing power, RSA remains secure. Because of the nature of the algorithm, advances in computer speed actually favors security over factorization, since larger keys can be used more efficiently than they can be factored. The above article is Copyright (c) 1994 RSA Data Security Inc. Permission is NOT granted for reproduction in any form other than this issue of AEO-PJ. RSA Data Security Inc. 100 Marine Parkway Redwood City, CA 94065 USA 415-595-8782 (voice) 415-595-1873 (fax) RSA Data Security was founded in 1982 and its technologies have since grown to become defacto standards for data encryption and authentication all over the world. The corporation develops and markets products for the development and end-use of encryption and authentication technologies and provides comprehensive consulting, licensing and research services in the cryptographic sciences field. The RSA Public Key Cryptosystem, in its various forms has been endorsed by the internet, the Pentagon and financial institutions worldwide, and counts nearly every major computer hardware and software corporation as among its many licencees. The RSA Algorithm (U.S. Patent #4,405,829) is widely recognized as the most secure encryption and authentication method commercially available. Licensees and strategic partners include Apple Computer, IBM, Motorola, Sun Microsystems, Digital Equipment Corporation, Word Perfect, Chemical Bank, Novell, Microsoft, General Electric, Lotus Development Corporation, the National Aeronautics and Space Administration, Merrill Lynch and the U.S. Department of Defense. ] /***********************************************************************/ OBJECT::ATARI By: Warwick Allison /***********************************************************************/ Part 5 : C++ Basics for C Programmers. 1. Looking at C++ ----------------- We have looked at what Object Oriented programming is in a general sense, so now is a good time to look specifically at C++ and what makes it different from plain C. C++ can be viewed in a number of ways. One can look at is as a completely new language, with a completely different programming style, or one can see it as an extension of plain C to be slowly eased into and explored. Here, I will take this second view, for the benefit of the great many C programmers in the Atari community. 2. C++ - a Better C. -------------------- C++ can be considered a C with a "class" concept for Object Orientation. In fact, early versions of C++ were called "C with classes". A class is the same as a a "struct" in C with a couple of extensions. They are: 1. Not only can you have data fields (or data "members"), but also have FUNCTIONS as members. 2. You can restrict the access that others can make to the members. 3. Values can be automatically initialized and de-initialized. 4. One can define the standard operators for the class. 5. One can inherit functionality from other classes. 6. One can override functions of inherited classes. Let's ease into that list with an example that looks at the first two. 2.1 Member Functions 1. Not only can you have data fields (or data "members"), but also have FUNCTIONS as members. 2. You can restrict the access that others can make to the members. In C, we might use a struct to store a pair of integers: struct PairOfIntegers { int a; int b; }; Then when declaring a variable of this type, we use: struct PairOfIntegers foo; We can then make assignments to the fields: foo.a = 123; foo.b = 456; And we can use the fields in expressions: return foo.a * foo.b; In C++, we could model this with a class: class PairOfIntegers { public: int First() { return a; } int Second() { return b; } // Put it all on one line to save space. void SetFirst(int new_first) { a=new_first; } void SetSecond(int new_second) { b=new_second; } private: int a; int b; }; The keywords "public:" indicate that the members after it (which, in our example are all member FUNCTIONS), are usable by anyone. The keywords "private:" indicate that the members after it are only accessible to member functions of this class. When declaring a variable of this type, we use: PairOfIntegers foo; // We don't need to say `struct' or `class'. We can then change the values of the pair: foo.SetFirst(123); foo.SetSecond(456); And we can use the values in expressions: return foo.First() * foo.Second(); Now, in C, we might often want to have some function that takes a PairOfIntegers as a parameter, and returns some value. For example: int ProductOfPairOfIntegers(struct PairOfIntegers* pair) { return pair.a * pair.b; } In C++, we would write a function like this as a MEMBER of the class itself: class PairOfIntegers { public: int First() { return a; } int Second() { return b; } int Product() { return a * b; } void SetFirst(int new_first) { a=new_first; } void SetSecond(int new_second) { b=new_second; } private: int a; int b; }; We don't need to give it a long name like "ProductOfPairOfIntegers", because it is a member function that only applies to PairOfIntegers. It is used like this: bar = foo.Product(); THE PLOT THICKENS... Now, what if we only occasionally changed the values of fields a and b, but very frequently wanted to find the product? Well, we could remember the product, and update it whenever we changed the value of a or b. In plain C: struct PairOfIntegers { int a; int b; int a_times_b; }; Now, we must rely on the user of this structure to change a_times_b whenever they change a or b. For example: struct PairOfIntegers foo; foo.a=123; foo.b=20; foo.a_times_b=foo.a*foo.b; This is very error prone, and inefficient. And what about all the programs we wrote while PairOfIntegers just had a and b fields? We will have to go through them all and set a_times_b whenever a or b changes. In practice, people just put up with the inefficiency of repeatedly calculating a*b. But in C++, we don't need to change the usage of the class at all! class PairOfIntegers { public: int First() { return a; } int Second() { return b; } int Product() { return a_times_b; } void SetFirst(int new_first) { a=new_first; a_times_b=a*b; } void SetSecond(int new_second) { b=new_second; a_times_b=a*b; } private: int a; int b; int a_times_b; }; Voila! Instantly we have a class that remembers the product and updates it whenever a or b is changed. And since we only have to change this in one place, we can add further enhancements if we find them helpful: class PairOfIntegers { public: int First() { return a; } int Second() { return b; } int Product() { return a_times_b; } void SetFirst(int new_first) { if (a!=new_first) { a=new_first; a_times_b=a*b; } } void SetSecond(int new_second) { if (b!=new_second) { b=new_second; a_times_b=a*b; } } private: int a; int b; int a_times_b; }; // NB: there is a problem with this implementation, described // in the next section. But it serves an example here. Now this might not look like a very useful class. But what if a and b where X and Y co-ordinates, and you wanted to also provide polar co-ordinates very regularly? A class that allows this would make some calculations MUCH faster. I will not go into the details of that, as anyone who understands operations on polar co-ordinates should be able to see that advantage easily. Polar co-ordinates are equivalent to complex numbers. So, the big advantage revealed here is that with C++, we can hide certain information, and provide functions as members of a class to access and modify that information in an orderly fashion. Because we can make certain guarantees about how the data is accessed, we can add efficiency enhancements that would be too unreliable to consider in plain C. 2.2 Constructors and Destructors There is one problem with the final PairOfIntegers description above: What if the fields a, b, and a_times_b are initialized to some random values? For example, say a starts as 123, b starts as 10, and a_times_b starts as 1948726664. Then suppose we do this: PairOfIntegers foo; foo.SetFirst(123); foo.SetSecond(10); printf("%d\n",foo.Product()); What will be printed? Well, since coincidentally, both values we assigned to a and b equaled what random chance managed to leave in them, a_times_b never got set! The problem is that we are not ensuring that our values start at some known value. Fortunately, and as listed at the beginning of section 2: 3. Values can be automatically initialized and de-initialized. Ah-hah! Just what we need. Here is the corrected class: class PairOfIntegers { public: // We have a `constructor' for the class, which tells // us how to make an object of this class given some // parameters (in this case, no parameters). // PairOfIntegers() { // We don't care what a and b are, // so long as a_times_b is right. a_times_b=a*b; // If we had a_divided_by_b, we would want to also ensure b!=0. } // While we are at it, let's add another constructor that // lets us create a PairOfIntegers from 2 integers: PairOfIntegers(int first, int second) { a=first; b=second; a_times_b=a*b; } int First() { return a; } int Second() { return b; } int Product() { return a_times_b; } void SetFirst(int new_first) { if (a!=new_first) { a=new_first; a_times_b=a*b; } } void SetSecond(int new_second) { if (b!=new_second) { b=new_second; a_times_b=a*b; } } private: int a; int b; int a_times_b; }; Note: There is an alternative form for writing the constructors. In fact, it is the preferred form, called an `initialization list': PairOfIntegers() : a_times_b(a*b) { } PairOfIntegers(int first, int second) : a(first), b(second), a_times_b(a*b) { } Note that the objects are actually assigned in the order they appear in the declaration: ... int a; int b; int a_times_b; }; not in the order they appear in the constructor initialization list. But you should put them both in the same order to avoid confusion (and because GNU C++ gets this wrong in some versions). Now, what about destructors? Well, there isn't really much use for one in the above example. But let's just pretend that it is vitally important to set all fields to 25 before exiting (just say we ant to do that so that some snoop can't go through memory after our program terminates and find our bank accounts by looking for a sequence three of words where the third is the product of the first two). To do this, we simply add another member: class PairOfIntegers { public: ... // This is the destructor. It never have parameters. ~PairOfIntegers() { a = b = a_times_b = 25; } ... }; 2.3 Operators With the first PairOfIntegers example (let's ignore the "Product" enhancement for now, if we want to add the fields of one pair to the fields of another, we would do this is plain C: { struct PairOfIntegers foo; struct PairOfIntegers bar; ... foo.a += bar.a; foo.b += bar.b; } Simple. Now let's look at C++: { PairOfIntegers foo; PairOfIntegers bar; ... foo.SetFirst(foo.First()+bar.First()); foo.SetSecond(foo.Second()+bar.Second()); } YUCK! So verbose, just to add two pairs together. Fortunately: 4. One can define the standard operators for the class. Continuing our example: class PairOfIntegers { public: ... // This member defines the operator "+=" that adds a pair // to this pair. The word "operator" is a keyword. // void operator += (PairOfIntegers other_pair) { a+=other_pair.a; b+=other_pair.b; } ... }; Then, all we need to write whenever we want to add pairs is: { PairOfIntegers foo; PairOfIntegers bar; ... foo += bar; } HAH! Even simpler than the plain C code. You can define all sorts of operators - "+", "-", "==", etc. etc. You can even define the "()" operator, the "()" operator with any parameters! Very powerful. 2.4 Inheritance In all the above sections, we described how we could add features to a class to improve its usefulness. But what if SOMEONE ELSE wrote the class, and we don't want to go around hacking at their code. Or what if we want multiple variations, with different extensions? Well, 5. One can inherit functionality from other classes. Cool. So, just say we have the original very first PairOfIntegers class: class PairOfIntegers { public: int First() { return a; } int Second() { return b; } // Put it all on one line to save space. void SetFirst(int new_first) { a=new_first; } void SetSecond(int new_second) { b=new_second; } private: int a; int b; }; Now, let's add Product to this, without hacking at the code. To do so, we create a new class which INHERITS the PairOfIntegers class: class ProductablePairOfIntegers : public PairOfIntegers { public: int Product() { return First() * Second(); } }; Voila. The words ": public PairOfIntegers" say that this new class inherits all the functionality (and data) of the PairOfIntegers class, and that everyone using the class is allowed to use this fact (hence the "public" keyword after the ":"). 2.5 Overriding Inherited Functions But how do we implement the optimization of having a_times_b set whenever a or b changes? Well, with the PairOfIntegers above, the best we can do is to keep the fact that we inherit PairOfIntegers functionality a private secret, then provide new versions of SetFirst and SetSecond that do the appropriate checks, and possibly call the versions of SetFirst and SetSecond in PairOfIntegers (the "base class" of our new class FastProductablePairOfIntegers): class FastProductablePairOfIntegers : private PairOfIntegers { public: int Product() { return a_times_b; } int First() { // We just call the version of First // from our base class PairOfIntegers. // We use the `scope resolution operator', "::" // to specify that we want THAT version of // First, not the one found in this class, // which would cause infinite recursion! // // This is sometimes called `re-exporting' functions. // return PairOfIntegers::First(); } int Second() { return PairOfIntegers::Second(); } void SetFirst(int new_first) { if (new_first != First()) { PairOfIntegers::SetFirst(new_first); a_times_b=First()*Second(); } } void SetSecond(int new_second) ... and so on. private: int a_times_b; }; This does the job, but didn't we say: 6. One can override functions of inherited classes. ??? Yes, we can. BUT, only if the original class (the "base class") has allowed us to do so in advance. This means the designer of the base class has to think ahead a little bit about what some inheritor of the class ("derived classes") might want to override. Once the designer decides, all they have to do is add "virtual" to the function description. Let's change PairOfIntegers to allow SetFirst and SetSecond to be overridden: class PairOfIntegers { public: int First() { return a; } int Second() { return b; } virtual void SetFirst(int new_first) { a=new_first; } virtual void SetSecond(int new_second) { b=new_second; } private: int a; int b; }; Simple. Now, how do we override? Well, we just DO IT: class FastProductablePairOfIntegers : public PairOfIntegers { public: int Product() { return a_times_b; } virtual void SetFirst(int new_first) { if (new_first != First()) { PairOfIntegers::SetFirst(new_first); a_times_b=First()*Second(); } } virtual void SetSecond(int new_second) ... etc. private: int a_times_b; }; Done. 3. Wrap up. We quickly dived into the differences between a plain C "struct" and a C++ "class". But at least we have seen all those nice features of a class, and we have seen clues as to how we can use the feature to not only make our programs safer and easier to improve, but also how these features can make for faster, more efficient programs. What you do with these features is limited only to your limitless imagination. -- Warwick /************************************************************************/ Parsing the human equation by Ron Whittam /************************************************************************/ Phone support for a product could be your most critical function to maintain continued product sales. This month I would like to jump into this subject. Primarily, how can a one-man shop handle its customer base efficiently? While an often used support-link is the commercial information services like GEnie and Compuserve, not every customer of your product will have access to such services. However, the populariy of the Internet being broadcast in public media is making electronic support a closer reality then ever before. Electronic support can be very advantageous to a one-man shop. Be this media a FAX, voice mail, or computerized information services; it will allow you to handle many problems and product requests in an efficient manner. But, phone support is still a vital need in our world today. It is so important to some companies that they are sub-contracting customer support companies to do this support full-time for them. While the professional support company handles problems, the developer can continue to work on new products without interuptions. Not so easy on a one-man shop operation. OK. Let's say you have implemented the common support media. You have a FAX. You have an address on a commercial information service. You have a message base on a local BBS. You have a phone. Your phone is augmented with an answering machine (voice mail). There is still no substitute for person to person communication when people need help. While some might believe a discussion on good phone support would entail a lengthy dialog on phone etiquette, I choose a different path. While phone etiquette is important to any business dealing, the tools to be efficient are more so. It would do very little good to have a terrific phone personality and only speak gibberish. This discussion will focus on the tools you may use to increase effective customer support while talking on the phone. I believe a the real key to good support is good information that is readily accessable. Easily accessable information will reduce your time on a phone call. You should keep a file drawer near your phone and a notebook near your phone. Both of these will provide you with hard copy information "nearly" at your fingertips. Yet I have found that the best method for supporting computer products is to use the power of the computer. While many database type products exist, I would like to draw your attention to a simple flatfile database method. The flatfile method does not require the purchase of additional software. It uses a simple text editor and a simple utility. The flatfile is a text file you create and update on your computer. CREATE A TEXT FILE Use a word processor or text editor to create a new file. If you are using a word processor (that doesn't have a search feature) be sure you can save the file as ASCII text. For our purposes, we will call the file FLATFILE.DB and use this distiction throughout this discussion. Setup a "template record" such as this: [top of file] ----------------------------------------------------------------- PROBLEM or BUG: SOLUTION or FIX: COMMENTS: ------------------------------------------------------------------ [end of file] Save this file as FLATFILE.DB. This file is now seven (7) lines long. To add data to this file, retreave it and then copy lines 1-6 below line 7. Then fill in the information. Continue to make copies of the first six lines and fill in the appropriate information. Save the file. Or an alternate template might be: [top of file] ------------------------------------------------------------------ CUSTOMER: CONTACT: ADDRESS: CITY: STATE: ZIP: PHONE #1: PHONE #2: FAX NUMBER: PRODUCT: PURCHASE DATE: CONTACT HISTORY: ------------------------------------------------------------------ [end of file] Save this file as FLATFILE.DB. This file is now fourteen (14) lines long. To add data to this file, retreave it and then copy lines 1-13 below line 14. Then fill in the information. Continue to make copies of the first thirteen lines and fill in the appropriate information. Save the file. UPDATE THE TEXT FILE Now you have FLATFILE.DB on your disk with important information. To update this file, retreave it into your text editor and continue to add information. USING "GREP" TO SEARCH FOR INFORMATION A utility common to the UNIX crowd (and now ported to most every computer platform) is a program called GREP. The program will search a file for string of text. When found, it will display the line number and the text of the line in which the match was found. Once the line number is identified you may use your text editor to display that section of the file. USING A WORD PROCESSOR TO DO THE SEARCH Many word processors have a FIND or SEARCH feature. If this is your case then you can forego the ASCII save and the use of GREP. You can exploit these FIND and SEARCH features to do the task just as well or better. ProTEXT has a very powerful FIND option in the TEXT menu. So do other word processors. You can search for a word or a string of words. You may select an option to have the match case sensitive or not. You may search forward or backwards in the file. JUST DO IT Implementing this search and display on the phone is a rather simple procedure. When you get a phone call, GREP the customer file with their company or contact name. Then retrieve the file, find that record. Now you have all the necessary and pertantant information on that person on your screen. You can talk personally and intellegently with your customer. If they report a problem, indicate that on their customer record for cross reference, and save the file. Now you can GREP the problem file. Retreve the file and go to the record that is indicated by the result of the GREP. If you cannot locate a similar problem, create a new entry. While a simple database or a relational database would do this for you, this is definately a quick and dirty method. SuperBase, Tracker ST, dBMAN, and others are fine database programs available for the Atari ST. These products will require some programming and setup to work as efficently as the flatfile. If you have a large shop the database programs would be a must. Most importantly: Have information about your products, your customers, and problems readily available near the phone. You will sound more professional and you will service your customers better. That's it for this month. If you have any suggestions please EMail me a message on the Internet. ----===[O-O-0]===---- Ron Whittam is a Software Support Specialist for a small software firm in Boise, Idaho; and the President of the Atari Boise Users Group. He can be contacted on GEnie or through the Internet at r.whittam@genie.geis.com and on the ROVER BBS (208) 362-2243. /***********************************************************************/ Language Watch - Current versions of developer tools /***********************************************************************/ DEV| version & date | product ========================================================================== A | 1.1 Jan 1993 | Pure C (with ASM/C source level debugger) (German) A | Sep 4, 1992 | Pure Pascal (German) (Turbo pascal 7.x compatible) A | 1.0 Oct 3, 1993 | Pure Profiler (German) A | 2.x | Interface, (resource file editor, with 3D icons) B | 3.10 | Devpac 3 (assembler) B | 1.0 | Devpak DSP (for 56K digital signal processor) B | 5.60 | Lattice C B | 2.10 | HiSoft BASIC 2 (includes compiler) B | 2.03.02 | HiSoft C (C interpreter) B | 3.02 | SuperBase Professional B | 1.6 | HiSpeed Pascal (Turbo pascal compatible) B | 1.21 | FTL Modula-2 B | 1.24 | WERCS (resource file editor) C | 2.05 | Personal Pascal D | Aug 3, 1988 | Assempro (assembler) E | 2.1 1989 | Laser C E | 1.1 1989 | Laser DB (assembly & C source level debugger) F | 3.7 1991 | GFA BASIC (includes compiler) G | 1.115, 1992 | Prospero C G | 2.165, 1992 | Prospero Pascal for GEM G | 2.165, 1992 | Prospero Fortran for GEM G | 1.12, 1992 | Prospero Developer's Toolkit H | 3.6d Oct 1, 1988 | Aztec C H | 3.6e Dec 6, 1988 | Aztec SDB (C source level debugger) I | 3.0.9, 1988 | Mark Williams C I | 1.0, 1988 | CSD (C Source level Debugger) J | *** | GNU tools, compilers and assembler A = Gribnif Software/Applications Systems Heidelberg B = Oregon Research Associates and/or HiSoft C = ICD/OSS D = Abacus Software E = Megamax F = GFA G = Prospero H = Manx I = Mark Williams Company J = Free Software Foundation *** see Warwick's OBJECT::ATARI part 2 for specifics [ Editor's NOTE: Producers of development tools are encouraged to send press releases and upgrade announcements to the Editor. ] /**********************************************************************/ Bad Example--An Assembly Programmer's Nightmare (and pet peeve) By Damien M. Jones /**********************************************************************/ I learned assembly programming mostly by looking at other people's programs, and then writing my own. So I've seen lots of assembly programs, and I've developed a number of pet peeves about source code. The following examples will illustrate both some problems and some solutions. -- BAD EXAMPLE -- * Rectangle intersection. is_rec movem.l 4(a7),a0-a1 move.l (a0),d0 ; xywh -> xyxy add.w d0,6(a0) swap d0 add.w d0,4(a0) move.l (a1),d0 add.w d0,6(a1) swap d0 add.w d0,4(a1) move.w (a0)+,d0 ; compute intersection cmp.w (a1),d0 blt.s .1 move.w d0,(a1) .1 move.w (a0)+,d0 cmp.w 2(a1),d0 blt.s .2 move.w d0,2(a1) .2 move.w (a0)+,d0 cmp.w 4(a1),d0 bgt.s .3 move.w d0,4(a1) .3 move.w (a0),d0 cmp.w 6(a1),d0 bgt.s .4 move.w d0,6(a1) .4 subq.w #6,a0 ; xyxy -> xywh move.l (a0),d0 sub.w d0,6(a0) swap d0 sub.w d0,4(a0) move.l (a1),d0 sub.w d0,6(a1) swap d0 sub.w d0,4(a1) ble.s .5 ; check overlap tst.w 6(a1) ble.s .5 moveq #-1,d0 rts .5 moveq #0,d0 rts In the above example, it's almost impossible to figure out what's going on. Even if you know what the routine does - and the title only hints at it - it can still be very difficult to see what it's doing, and why. Here is the same routine, reformatted and extensively commented. -- GOOD EXAMPLE -- * Compute the intersection of two rectangles. * The rectangles are xywh, as the AES uses. d0.l will contain * TRUE (-1) or FALSE (0), indicating whether the rectangles overlap. * The coordinates of the overlap (or the space between the rectangles, * if no overlap) will be written to the second rectangle. If there * is no overlap, the width and/or height of the "between" rectangle * will be negative or zero. * * Since d0 is the last item set by this routine, you can branch * immediately following the routine--no tst instruction is needed. * On the stack: * 8(a7) Address of second rectangle (will be changed). * 4(a7) Address of first rectangle. * d0-d2 and a0-a2 should be considered trashed by this routine. * The calling routine is responsible for fixing up the stack. * This is standard C calling protocol. intersect_rectangles movem.l 4(a7),a0-a1 ; Get address for rectangles. * Convert xywh to xyxy. move.l (a0),d0 ; Get X and Y of first rectangle. add.w d0,6(a0) ; Add Y to H to get Y2. swap d0 ; Get X. add.w d0,4(a0) ; Add X to W to get X2. move.l (a1),d0 ; Get X and Y of second rectangle. add.w d0,6(a1) ; Add Y to H to get Y2. swap d0 ; Get X. add.w d0,4(a1) ; Add X to W to get X2. * Now compute the coordinates of the intersected rectangle. move.w (a0)+,d0 ; Get A(X1). cmp.w (a1),d0 ; Is A(X1) > B(X1)? blt.s .do_y1 ; No, B(X1) is bigger; use it. move.w d0,(a1) ; Else use A(X1). .do_y1 move.w (a0)+,d0 ; Get A(Y1). cmp.w 2(a1),d0 ; Is A(Y1) > B(Y1)? blt.s .do_x2 ; No, B(Y1) is bigger; use it. move.w d0,2(a1) ; Else use A(Y1). .do_x2 move.w (a0)+,d0 ; Get A(X2). cmp.w 4(a1),d0 ; Is A(X2) < B(X2)? bgt.s .do_y2 ; No, B(X2) is smaller; use it. move.w d0,4(a1) ; Else use A(X2). .do_y2 move.w (a0),d0 ; Get A(Y2). cmp.w 6(a1),d0 ; Is A(Y2) < B(Y2)? bgt.s .convert_xywh ; No, B(Y2) is smaller; use it. move.w d0,6(a1) ; Else use A(Y2). * Now convert the xyxy rectangles back to xywh. .convert_xywh subq.w #6,a0 ; Move this back to start of rectangle. move.l (a0),d0 ; Get X1 and Y1 of first rectangle. sub.w d0,6(a0) ; Subtract Y1 from Y2 to get H. swap d0 ; Get X1. sub.w d0,4(a0) ; Subtract X1 from X2 to get W. move.l (a1),d0 ; Get X1 and Y1 of second rectangle. sub.w d0,6(a1) ; Subtract Y1 from Y2 to get H. swap d0 ; Get X1. sub.w d0,4(a1) ; Subtract X1 from X2 to get W. * Now see if the rectangles overlapped. ble.s .no_overlap ; W is <= 0 (from above), means no overlap. tst.w 6(a1) ; Is H <= 0? ble.s .no_overlap ; Yes, no overlap. moveq #-1,d0 ; Else they do overlap. rts ; We're done. .no_overlap moveq #0,d0 ; Rectangles do not overlap. rts ; We're done. There are a few important differences I'd like to point out here, along with a few style guidelines for assembly language. The first is that the bad example had a grand total of five comments for a 46-line subroutine. Assembly is difficult enough to program, even with comments. There are also only three blank lines separating the routine. In the good example, I expanded the routine header to explain what the function does, and how the parameters are passed to it. I also listed how values are returned from it, and a tip for using return values from the function. Then I list which registers are destroyed. Note that while the routine does not actually destroy all the registers listed, I listed the standard set of destroyed registers for C functions; this lets me change the routine later, perhaps utilizing an extra register or two, without having to rewrite the code that calls it. Then I took each of the small comments and put them on separate lines, expanding them in the process. This helps give an overview of the important sections of the routine. Writing comments as complete sentences also increases the readability of the program, since this is how we normally communicate and expect information to be presented. The next step was to take the long blocks of code and break them up. In general, each small block should contain only one "step". This may be a short concept (doing a simple operation on one set of data) or a bit more complex (an if-then sort of step), but as a general rule it should be no more than six or eight steps (four is ideal). Any time you start doing something different, or do it with a different piece of data, is an excellent time to place a blank line in your code. I then replaced the labels with more explicit, meaningful ones. .5 doesn't tell me much, but .no_overlap does. Good labels, especially for routine names, are important. If you came across a "bsr is_rec" line in a program somewhere, you might wonder if it meant, "find out if the passed data is a rectangle", or who knows what else. If you came across "bsr intersect_rectangles", though, you could be reasonably certain the routine had something to do with intersecting rectangles. Don't be afraid of long names. The final step was to add a comment to each line. This is critical, and often the most left-out step of writing assembly code. If you think I am exaggerating, take a look at the bad example again. Sure, you could figure out exactly what was going on, given time. Now imagine that you have FIFTY pages of assembly code, all just like that bad example. Things start to look a little grim, don't they? Comment every line. You may know what your program does, now, but two weeks from now, when you discover there's a bug in your program, you will appreciate those comments. If you do something differently than you do it elsewhere, and there's a reason for it, spell out the reason; you'll be saving yourself some head-scratching later as you wonder, "Why did I do it that way...?" This may seem very silly. When I was getting started writing programs, I didn't use very many comments. I figured I knew what I was doing (and back then, REM statements in BASIC were all that I had), so why bother adding comments? It seemed so silly. I have learned the hard way, as many must, that comments are not necessarily for the here and now. They are for the tomorrow, the next week, the next year. You can't remember everything. Most languages, including assembly, include the capability to comment every line of your program. Don't waste the opportunity. A comment on the comments is appropriate here. You will notice that in many places in the good example, similar operations are performed on different pieces of data. You will also notice that, in these cases, the comments are also very similar. This is intentional, and invaluable. In general, you will be able to spot meaningful patterns in the comments faster than you will be able to spot patterns in the actual program, because the program statements are all very similar anyway. Use this to your advantage. As a final note, many experienced assembly programmers will note that my style of assembly is slightly non-traditional. As an example, here's the "traditional" style: move.l (a0),d0 ; Get X and Y of first rectangle. add.w d0,6(a0) ; Add Y to H to get Y2. swap d0 ; Get X1. add.w d0,4(a0) ; Add X to W to get X2. Notice the tab between the instruction (add.w) and the operands (d0,6(a0))? I use a space, instead of a tab: move.l (a0),d0 ; Get X and Y of first rectangle. add.w d0,6(a0) ; Add Y to H to get Y2. swap d0 ; Get X1. add.w d0,4(a0) ; Add X to W to get X2. I do this for two reasons. Mostly it's because the more traditional approach splits the instructions into two separate columns, instructions and operands. The effect of this is to bind the operands more tightly to each other, instead of to the instructions. In my approach, the instructions and their operands appear to be much closer related. In truth, your assembly won't care which you use - but you might. /*************************************************************************/ Legal Forum : Intellectual Property by Fred Wilf and Gerry Elman /*************************************************************************/ HOW TO WORK WITH YOUR INTELLECTUAL PROPERTY ATTORNEY: Steps in Obtaining Patents and Registering Trademarks and Copyrights Copyright (c) 1994 Elman Wilf & Fried. All rights reserved. In general, intellectual property is secured by various legal tools including patents, trademarks and copyrights. This summary will provide background information about these forms of intellectual property and the process by which your rights in intellectual property may be secured. It discusses various procedures, which will generally involve assistance by a patent practitioner (who may be a patent attorney or patent agent) or an attorney. This summary is current as of January 1, 1994, but is likely to become outdated as a result of changes in United States and international statutes, regulations, fees and procedures. It provides only general information and should not be considered a substitute for legal advice. If you have specific questions about the law or how the law affects you, then you should retain an attorney for legal consultation. Patents A United States patent gives the owner the right to exclude others from making, using or selling in the United States the invention, which is defined by a series of descriptive "claims." A patent is available for an invention that is found to be (1) novel, (2) useful, and (3) not obvious to someone of ordinary skill in the relevant technology who is fully familiar with the "prior art." The prior art includes, for example, patents and publications worldwide, as well as public uses and products on sale in the United States. Another form of patent protection, called a "design patent," protects ornamental features and the shape of a useful article, such as a keyboard or a piece of laboratory apparatus. A patent application in the United States must contain a disclosure of the invention - in the form of a description and any drawings that may be appropriate - that is complete enough to enable someone having ordinary skill in the field to make and use the invention. In addition, the application must disclose the best mode of carrying out the invention that is known to the inventor at the time the application is filed. Relevant technology may be located by searching in the files of the Patent and Trademark Office or by a computer database or library search. A patent practitioner generally studies the results of such a search and provides you with an opinion on the patentability of your invention in light of the search results. If you are interested in a search to determine whether your proposed product might infringe someone else's patent claims, then the depth of the search, and hence the cost, would be greater, although the focus would be on only unexpired patents. After receiving a discussion of the prior art, you may ask your patent practitioner to prepare a patent application. If so, you might need to provide the practitioner with additional information to complete the disclosure of your invention. You would expect the practitioner to prepare the application and accompanying formal papers and any drawings. There may also be a document to assign ownership of the patent application to your company or another company. Further prosecution of the patent application may be simple or complex. Your patent practitioner will prepare and file an Information Disclosure Statement to present certain information of which you have become aware, such as the results of searching. There is an absolute requirement of full disclosure of all known prior art and prior public uses and offers for sale of the invention, whether by yourself or others. Failure to comply with this requirement would jeopardize the validity of any patent which might issue and might possibly subject you to pay damages in litigation with a potential competitor. Further prosecution over ensuing months will likely include amendment of the claims and argument in response to an Office Action from the Patent Examiner and interviewing the Examiner. In addition, it is possible that such prosecution might include the preparation of affidavits to overcome objections and rejetions by the Examiner, petitions and appeals to higher authorities within the Patent and Trademark Office and to a court, and the preparation of divisional, continuation and continuation-in-part applications. The application (or the issued patent) may also become a party to an interference proceeding to determine which of various claimants can prove priority of invention. "Priority of invention" is a legal principle which does not depend only on the date the invention is conceived. It also requires proof of "diligence," continuous effort to reduce the invention to practice - either actually, by carrying out an actual demonstration of a complete prototype of the claimed invention, or constructively, by filing a patent application. Thus, delays in responding to communications regarding a proposed U.S. patent application should be kept to a minimum. Various government fees may also be payable during prosecution and will be payable upon issuance of the patent, as well as to maintain it in force at various points during its lifetime. If the application is not owned by, or licensed to, a business having 500 or more employees, it will qualify for the 50% discount in government fees available to "small entities." If so, your patent practitioner should prepare and file a verified statement of your status as a "small entity." You will need to make a decision regarding the strategy for filing any foreign counterparts under the Patent Cooperation Treaty or otherwise. These patents would hopefully provide similar rights in various foreign countries you may select. In order to obtain the benefit of the filing date of your United States application in the countries that are members of the Paris Convention on patents, it is required that such foreign counterparts be filed within twelve months from the filing date of the United States application. Beware that although the United States permits inventors up to one year from their own public disclosure or placing the invention on sale before their U.S. patent application is time-barred by their own actions, most foreign countries do not provide such a "grace period." The best strategy to preserve your rights is to file a U.S. patent application BEFORE making a non-confidential disclosure of the invention to anyone. Moreover, certain foreign countries, notably Taiwan and India, have not ratified the Paris Convention. They do not grant priority rights on the basis of a United States patent application. Tell your patent practitioner immediately if you are interested in protecting your rights in these countries or any others that are of particular importance to you. Patent practitioners are also frequently asked to advise whether a proposed product comes within the claims of a particular patent of a competitor or other identified party. In that event they would first determine the scope of the claims by obtaining and reviewing a copy of the prosecution history of the patent. If the proposed product is not clearly outside the scope of the issued claims, they would next seek to determine if any of the claims might be invalid (e.g., because of additional prior art not brought to the Patent Examiner's attention). In the event that they are able to provide an opinion that the proposed product does not infringe any valid claims of the patent, then it would benefit your company because generally a court would decline to award additional damages for "willful infringement," even if the court were to disagree with your patent practitioners and find that the patent is infringed. Copyrights An attorney can help by advising you about United States and international copyright protection, reviewing documents, prosecuting copyright applications, and litigating copyright infringement suits. As soon as a work of authorship is fixed in a tangible medium of expression (e.g., written on paper or saved on a computer disk) it is protected by the U.S. Copyright Act. The protection is automatic and does not require that you take any further action. However, you should consider taking two steps (which are optional for new works) to gain additional protection. These two steps are (1) place your copyright notice on your work, and (2) register your copyright with the U.S. Copyright Office. Your copyright notice should look like this: Copyright * [Year of first publication] [Name of copyright owner]. All rights reserved. where the * stands here in for the encircled-C symbol (which is not part of the ASCII character set). It is advisable to use the "encircled-C" symbol instead of "(c)" or "(C)". If you can't use that symbol, then include the word "Copyright" or the abbreviation "Copr." If your work is not published (i.e., offered for distribution to the general public), then leave out the year of first publication. Although a copyright notice is not absolutely required for any work first published on or after March 1, 1989, it is strongly recommended to use copyright notices on all of your works. The second step is to register your copyrights. You don't need to register your copyright, but the law provides additional benefits to those who do. Moreover, you may not sue an infringer in court unless and until you have received a certificate of copyright registration for your work. The U.S. filing fee is $20.00 per application. The registration process takes approximately four months between the filing of the application and your receipt of the certificate of registration. You may speed up the registration process (e.g., if you immediately need to sue an infringer) by paying an additional $200.00 government filing fee per application. Your applications for copyright registration should be filed as soon as possible after your work is created and before you distribute your work. Your cost of registering your works is lower when you are not in a hurry to sue an infringer. Further, if you file an application for copyright registration before someone infringes your work, or within three months of the date your work is first published (if your work is published), then you receive two additional benefits that you would not otherwise have. The first additional benefit is that the federal court may award you your attorney's fees. The second additional benefit is that you may request the court to award "statutory" damages instead of any actual damages that you have suffered. Statutory damages are preferred when you cannot prove that you actually lost money, or when you have lost a rather small amount of money. The judge may then award statutory damages somewhere between $500.00 and $20,000.00 per work. If you can prove the infringer intentionally infringed your copyright, then the judge may award you up to $100,000.00 of statutory damages per work. It is recommended to file applications for copyright registration before or at least soon after publishing anything that is valuable to you. Once the certificate of copyright registration issues, you do not need to do anything further to secure your copyright rights in the United States. It is important to understand that if the work of authorship is created by an independent contractor, the client does not automatically own the copyright. An attorney should be consulted to assist in making sure that agreements with independent contractors fully protect the client if it wishes to own the copyright outright. Trademarks Attorneys use the term "trademark" to refer to any design, word, or combination of words and designs, used in connection with the products or services of a business. Technically, the term "service mark" is used for designations of services, but a service mark is just one type of trademark. As soon as you start using your trademark, you should use the symbol "TM" to designate a trademark for goods and the symbol "SM" to designate a service mark for services. Thus, you may generally place a tiny "TM" in or adjacent to each trademark for goods and a tiny "SM" next to each service mark. If you desire to protect a trademark, it is common to first do a search to find out if the marks you like are available. One may start by checking on-line databases of federal trademark applications and registrations, plus state trademark registrations. These databases are organized for searching alphabetically for "direct hits," and also by phonetic sound-alikes, and for suffixes and prefixes. Your attorney would use the search results to initially evaluate whether your proposed trademarks are "confusingly similar" to the trademarks of your competitors. If your marks come up reasonably clear from the initial search, one may then check other databases and look for similar marks used by companies that haven't yet registered their marks. These companies may develop "common law" rights in their trademarks by using their trademarks. In addition to searching your proposed trademarks, your attorney can advise you how to use the trademark in connection with your goods (e.g., on labels and on the product) and with your services (e.g., in marketing materials, brochures and advertisements). The U.S. trademark law was amended in 1989 to allow you to file an application based on your bona fide ("good faith") intent to use your trademark. You may file an "intent to use" application even before you place your trademark on your goods. By comparison, you may only file a "use" application after you have used your trademark in interstate commerce, such as by shipping your goods to a customer in another state or by advertising your services in another state. Your attorney can prepare for you a federal "use" or "intent to use" trademark application and file it with the U.S. Patent and Trademark Office. The government charges a filing fee of $245.00 per class of goods or services. If your trademark consists of a logo, design or stylized lettering, then your attorney would need to obtain a black-and-white drawing of the design in the stylized form required for federal trademark applications. Upon filing of your application for trademark registration, an examining attorney in the U.S. Patent and Trademark Office ("PTO") searches registered marks and pending federal applications for any that may be confusingly similar to your trademark. The PTO attorney also examines the application for compliance with various technical and legal standards. The PTO attorney is likely to object to one or more aspects of your application. Your lawyer would generally communicate by phone and in writing to respond to the PTO attorney. When and if the PTO attorney finds no further barriers to granting your application, the PTO will publish your mark in the Official Gazette of the Patent and Trademark Office. Then, for a month or so, others who may have adopted a similar mark will have the opportunity to challenge your right to register your mark. If your mark is challenged, then the PTO conducts a proceeding to determine the matter. If there is no challenge, your application proceeds to the next stage. If your application is an "actual use" application, then the PTO registers the trademark and issues a certificate of registration to you. If your application is an "intent to use" application, then the PTO will not register your trademark until you file a sworn statement that your mark has actually gone into bona fide use in interstate commerce. The filing fee for this statement is $100.00. Once the PTO grants to you a registration and sends you a certificate of registration (but no sooner), you may then use the encircled-R symbol in connection with your mark, or alternatively the term "Reg. U.S. Pat. and T.M. Off." (which is more cumbersome). Until you receive a certificate of trademark registration, you may use the "TM" and "SM" symbols. This completes the registration process. Once the PTO issues a registration, you generally won't be involved with the PTO for another five years. Between the fifth and sixth anniversaries of the registration date, you would need to file an affidavit that you are still using the trademark in connection with the same goods and services. If the "affidavit of use" is not filed during that time, the registration is canceled (although you could seek to re-register your trademark). The PTO filing fee for the affidavit of use is $100.00 per class of goods and services. Further, if your trademark had not been found invalid or was not in litigation at the time that you file the affidavit of use - or at the end of any five-year period - you could file an "affidavit of incontestability." The affidavit of incontestability may be filed by itself or as part of the same document as the affidavit of use. An affidavit of incontestability provides additional rights in case you need to sue a trademark infringer; the infringer would have a higher standard to overcome to battle you in court as the validity of your trademark would be "incontestable." (However, certain things about the trademark may nevertheless be subject to challenge.) The PTO filing fee for the affidavit of incontestability is $100.00 per class of goods and services. A U.S. trademark registration is valid for ten years. A renewal of the registration must be filed anywhere between six months before the anniversary to three months after the anniversary. If you file the renewal application too early or too late, the PTO will ignore it. Unless the renewal application is filed within the window of opportunity, the PTO will cancel your registration (although you could seek to re-register your trademark). Your attorney can also help you register your trademarks in other countries. Other Matters Your attorney can also help you protect your intellectual property in other ways, such as design patents and mask work registrations. Gerry J. Elman, J.D. CompuServe 72245,556 Frederic M. Wilf, J.D. CompuServe 72300,2061 Elman Wilf & Fried 20 West Third Street Media, PA 19063-2824 Phone: 610-892-9580 Fax: 610-892-9577 [ Editor's Note: The above article is Copyright (c) 1994 Elman Wilf & Fried. Permission is NOT granted for reproduction in any form other than this issue of AEO-PJ. Services provided by Elman Wilf & Fried encompass all of the following: Protecting intellectual property, Patents, Copyrights, Trade secrets, Trademarks, Unfair competition, Negotiating and drafting contracts, Licenses and joint research projects, Ownership of inventions by employees and independent contractors, Litigating technology and business disputes, Assisting purchasers and sellers of computer hardware and software, Incorporate and obtaining financing for start-up ventures, Obtaining regulatory approval of technological developments. Gerry Elman is also a Sysop in the Innovator's forum on CompuServe. This Forum is intended to act as a conduit for inventor's, innovator's and those involved in technology transfer world-wide, management people in large or small companies, venture capital firms, investment bankers, new product managers, patent and trademark lawyers or housewives. The purpose of the forum is networking, support and development of new products or improving esisting ones. You will find both experienced inventors and 'wannabees' here. ] /*************************************************************************/ Editor's choice for 1993 - Software Development tools /*************************************************************************/ The questions are: a) Top 10 Development tools b) Best books and periodicals c) Best IDE (Integrated Development Environment) d) Why number one (in your top 10 list) is number one. //// Warwick Allison 1. GNU C++ I can't live without it. 2. GNU Make I'd go crazy without it. 3. GNU BASH Anything less unix-like is a pain. 4. Elvis Anything less vi-like is a pain. 5. MiNT Makes life easier... 6. TOSWIN_W ... especially with this! 7. ORCS I just wish I could find Theodore Otto! 8. grep, etc. It's not complete without this gang. 9. Drawing prg. Any will do. I used to like CrackArt, but STlow is too low. 10. GNU C Just so I don't have to convert all of NetHack to C++. Other: 1. GEM++ I love it. 2. GEM++ But then again, 3. GEM++ I guess I'm biased. Seriously, I think that each programmer also has a favourite C (or C++) library which they just couldn't live without. //// Carl Barron a) 1. my C compiler system (LATTICE) Without a good C compiler I would be lost. 2. Flex 2.3.7 3. Berkeley yacc 4. gawk 5. sed 6. tavlr - threaded avl tree library - free 7. regexp - Free regular expression library 8. Hisoft Basic - good for porting 'foriegn' basic code. 9. Hispeed pascal - ok but needs work, that does not appear to be forth coming. Essentially a turbo pascal compiler. 10. Devpac - good for stand alone assembler progs. I don't write too many.... Wow, I could find 10 b). books purchased in 1993. 1. Writing Solid Code - Good methods of reducing the bugs in a program from day one. 2. Lex & Yacc ,Nutshell book. Good at explaining use of lex and yacc and their clones. 3. Sed & Awk , Nutshell book. Good at explaining use of sed and awk,nawk,gawk. 4. Numerical Recipes in C. A good collection of numerical analysis routines. Looks a lot like fortran conversions. Requires a robust malloc(),free() implementation, if the code is used directly. Periodicals 1. C user's Journal. 2. Dr. Dobb's Journal 3. Software Development c) Only IDE used often is Lattice C. DevPac and others in a) are ok. d) A language compiler is the most important item. Without it all other tools are useless. I use C because there exists so many pd tools and libs to make life easier. [ex. flex yacc tavltr regexp] //// Albert Dayes a) 1. Pure C compiler (includes assembler and C source level debugger) 2. Modem (Can anyone live without one?) 3. grep 4. EdHak - the Super Editor (text and binary) by Clear Thinking 5. Look It - Codehead's text and binary (multiple) file editor 6. MT-C Shell - A UNIX C-shell by Beckemeyer Development 7. SupEdit - Supra's hard disk sector editor 8. C_PSLIB - a PostScript library for C programmers 9. Greenleaf Database library - xBASE data/index/memo file compatible 10. STraight Fax v2.x - fax software by NewStar technologies b) books: 1. The Atari Compendium by SDS Publishing - ISBN 0-9638331-0-3 2. File Structures, 2nd Edition - ISBN 0-201-55713-4 3. Unix Programmer's Reference - ISBN 0-88022-536-X 4. Dictionary of Computing, 3rd Edition - ISBN 0-19-286131-X 5. PostScript Language Reference Manual, 2nd Edition (Red-Book) ISBN 0-201-18127-4 periodicals: 1. C Users Journal 2. Software Development 3. Dr. Dobbs Journal c) Megamax's Laser C Shell. The only GEM development environment with a CLI in a window. The easiest way to access UNIX style tools and still enjoy the benefits of GEM. d) A great ANSI C compiler with an outstanding C source level debugger. Can anyone live with a true source level debugger? //// Scott R. Garrigus a) 1. GFA BASIC 2. GFA BASIC 3. GFA BASIC 4. GFA BASIC 5. GFA BASIC 6. GFA BASIC 7. GFA BASIC 8. GFA BASIC 9. GFA BASIC 10. GFA BASIC //// Kris Gasteiger a) 1: OSS/ICD Personal Pascal ( of course! ). 2: The Abacus Atari ST series of books. ( Out of print, but worth searching for in the used book stores. ). 3: Compuserve. 4: Tackle Box ST, by Rusty Mullins, no longer available, but probably replaceable by the Atari Compendium ( Which I really need to order! ). 5: Someone else's code. 6: A calculator capable of converting one numeric base to another. This can be hardware, or software ( Accessory ). 7: A good text on pascal programing, my current favorite is: Introduction To Pascal, by Rodney Zaks. Sybex Publishing. 8: Graph paper and pencil for mapping out what the program is to do, and how it is to do it. Also useful for bit maps and other graphics layout. 9: Good Colombian Coffee or Peach Schnaps, depending on the time of day, and my current frame of mind. 10: A hard drive with space to hold revision upon revision upon revision, until you realize that revision XXX.X worked best... A hard drive also speeds up compiles by an enormous amount. //// Travis Guy A1) GFA BASIC 3.7 - Great editor. GFA makes it easy to throw an idea into the interpreter and see what happens. A2) My GFA libraries - ... but when it is time to compile something, I like to use my hand-built function libraries. GFA just does some weird things with their built-in GEM & TOS calls. I learned how to interface with GEM and TOS after years of strange bombs and lockups. A3) Devpac - You've got to use assembler to know your machine. Also useful for getting into those hard-to-reach areas that GFA'll never go. A4) Sozobon C - I actually wrote a real program in this once, and had AEO not appeared a month after I did that, I'm sure I would have written more. A5) The original K-Resource. Great interface. I hear it's been updated to work with newer versions of TOS. B1) The Concise 68000 Programmer's Reference Guide - Whatta book. B2) One of the early MichTron GFA programming books - Sorry, but I can't remember its name, but I gave it a glowing review in ST Informer years ago. Only really useful for GFA programmers. B3) Chris Latham - Working with him on the Universal Item Selector (UIS) and his various GEMDOS replacement kernals and networking packages for the Atari was such an experience! I'll never forget when we finally started passing packets back and forth across the LocalTalk ports on our machines, we celebrated with a game of blitz chess and Cokes & cheeseburgers at the King Freeze - charged to the company. B4) The Atari Programming CAT on the GEnie ST RT - Filled with lots of experience, quick answers and great characters. B5) De Re Atari & Your Atari Computer (the purple book) - Yeah, these are 8-bit Atari programming books, but they gave me (a mere afternoon hacker) the urge to explore my 400's OS and get into serious programming. I wore out the spine on the purple book to the point where I had to bind it all together with duct tape. I'm saving my copy of De Re to be cremated with me. //// Damien M. Jones a) 1. Devpac 3. For all the assembly I write, I couldn't survive without it. 2. GFA BASIC 3.5. I wouldn't recommend it to anyone else, but knowing most of its faults, I can work around them, and writing GEM code is easier in GFA. (I dislike C for various reasons.) 3. A custom CLI. I didn't like any of the CLIs that were available; none of them did what I needed in the amount of memory I needed it done. So I wrote my own. 4. ORCS. I use it for dialog construction because it's inexpensive and fairly simple to use. I will probably buy a "real" RCS soon. 5. A custom graphics program. I often need a quick, simple graphics program to do a fast editing job on an icon, using tools not available in ORCS. This custom program is small, and it loads fast. 6. Geneva. It's probably done more for my real productivity on the Atari than any other software package, and I'm still learning to use it more. 7. Desk Manager 3.3. Essential for switching configurations quickly, which I do a lot. 8. Data Diet 2. It helps keep the source files small enough to fit on my even smaller hard drive. 9. NeoDesk 3. I'm a visual person; I like icons. (So why do I use a CLI? They're better at some things.) NeoDesk makes using my computer simpler and less taxing. 10. Warp 9 3.8. By making the whole system run faster and smoother, I can get more work done. b) The Atari Compendium, no question. Graphics Gems I-III. Graphics is one of the things I do, and these books have been invaluable tools here. c) Devpac 3. Editor, assembler, and debugger, all in one convenient package. d) I'm slowly making the move to 100% assembly. Some people believe that assembly is not the best tool for every job; I happen to be one of them. But for almost everything _I_ want to do, it has to be assembly. And if it has to be assembly, it has to be Devpac. I've looked at other assemblers and debuggers--I just like how Devpac works. //// Ron Whittam a) Top 10 1. SOZOBON 2.0 2. Dale Schumacher's dLIBS 1.20.0 3. SZADB Sozobon Debuger 4. STGREP 1.0 (ported by me from Unix to the ST) 5. Gulam CLI 6. Knife ST 7. ZAP 2.0 binary editor 8. MAKE.TOS (Tony Andrew's SOZOBON C make utility) 9. ProEd 1.0f TOS Text Editor - for C script 10. ProTEXT 4.5 Text Editor/WP - For documentation b) Books/Periodicals 1. Atari ST Internals; Bruckmann, English, Gerits; ABACUS 2. "C" A Reference Manual; Harbison-Steel, Tartan Labs; Prentice Hall 3. The Atari Compendium; Sanders; SDS 4. C-manship Complete; Walnum; Taylor Ridge Books 5. COMPUTE'S ST Programmer's Guide; Compute! Books c) Best IDE Gulam CLI with my own menu program to integrate PROED (text editor), Sozobon's MAKE, Compiler, Optimizer, Assembler and Linker programs. Does an OK job for a novice. d) Why #1 is #1 Sozobon C 2.0 is a low cost development system (price of shipping the disks or downloading). It has low overhead and is efficiently fast for my uses. While it is not ANSI compliant, there are many K&R Style code on other platforms that can be easily ported to the ST with Sozobon C. I got it 'cuz it was simple to use and I wanted to have something, other than BASIC, to support my own computer with. e) Non-Fiction books. . . 1 - Hackers, Steven Levy 2 - The Hacker Crackdown, Bruce Sterling /*************************************************************************/ On The Networks /*************************************************************************/ ========================================================================= (C) 1994 by Atari Corporation, GEnie, and the Atari Roundtables. May be reprinted only with this notice intact. The Atari Roundtables on GEnie are *official* information services of Atari Corporation. 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 XTX99437,GENIE and press [RETURN]. The system will prompt you for your information. ========================================================================== Atari ST RoundTable Real Time Conference Monday, Jan. 24, 1994 CD ROM for the Atari Computer! ============================== with CD ROM Developers Greg Kopchak, Roger Burrows, Brian Grier Special Guests David Troy, Damien Jones, S.Fardishgh Host - Lou Rocha <[HoST] ST.LOU> Our guests tonight are Greg Kopchak from It's All Relative, David Troy from Toad Computers and Roger Burrows, from Anodyne Software. Our topic is CD ROM for the Atari and we look forward to hearing about the latest developments for our platform. The crowd is small right now, so if you have a question or comment please /raise your hand. I am going to ask our main guest, Greg Kopchak, to upload his opening comments. GA Greg. I'd like to post a few things about Photo Show Pro supports Kodak Photo CD on the Atari Falcon 030 and allows the user to create scripted slide shows and presentations that make maximum use of the built in hardware capabilities of the Falcon 030. Photo Show Pro has twenty different fades and disolves when creating scripts, allows overlay of text on graphics in your choice of system colors, screen fades to black or white, inverse colors, and image overlays. Photo Show scripts can be created directly from CD using the Kodak Photo CD PCD format or created from disk using the FTC 16 bit true color format. All effects are super smooth, even when running under MultiTOS. Digitized sound files in AVR format can scripted along with graphics allowing the user to add commentary, sound effects, or background music to their presentations. For creating titles, Photo Show Pro displays 24-bit BMP files in the Microsoft Windows bitmap format. Photo Show Pro can be used with VGA, RGB (Atari monitor), and standard broadcast televisions. Slide shows and presentations can be recorded to VCR using either RF output or the higher quality composite output of the Falcon 030. Full 16 bit color with correct aspect ratios are displayed on all monitor types except monochrome. Photo Show Pro will auto show your Kodak Photo CD graphics using 16 different effects directly from your Photo CD discs. A special Corel mode allows the same auto shows using the Corel series of Photo CD images. Corel is planning to release over 100 theme discs of Kodak Photo CD graphics with each disc containing 100 images. Conversions can be made to 16-bit FTC, 24-bit TIF, 24-bit EPS, and 24-bit RAW formats from Kodak Photo CD's PCD format. Image conversions can be done in pixel resolutions of 192 by 128 up to 3072 by 2048. <[HoST] ST.LOU> Thanks Greg. I didn't realize you were an old pro at RTC uploads :-) Our next comment comes from Brian Grier. Go Ahead, Brian. <[Brian] B.GRIER> I really would like to make an announcement. I have created a program to allow Atari users to access Compton's New Media CD-Roms on Atari computers. <[HoST] ST.LOU> Brian, can you tell us a little more about it? <[Brian] B.GRIER> Please excuse my typing as this is my first RTC. <[HoST] ST.LOU> You're doing EXCELLENT. <[Brian] B.GRIER> My program accesses Compton's M.O.S.T discs. It currently works with the "Book of Home Remedies", "The King James Bible", and the "CIA/KGB information book" I would like to say it works with more but I have to buy more CD-Roms to be sure. Everything works pretty much as the windows(tm) version. You are allowed to have as many open sections as you want, and can display pictures, and play audio (STe/TT only right now). <[HoST] ST.LOU> Sounds great! What CD ROM are you using and what is M.O.S.T.? Does your PRG work with MultiTOS, Brian? <[Brian] B.GRIER> That's about it. Except if this goes well I'll be making a verson for Compton's Multi-Media encyclopedia. M.O.S.T. is Multiple Operating System Technology. <[HoST] ST.LOU> What CD are you using, Brian? Does your program run under MulitTOS? <[Brian] B.GRIER> If you mean drive I have a Chinon 431 (from TOAD) and an NEC-84 <[HoST] ST.LOU> Let's move on to Lorne White. <[Lorne] L.WHITE17> Thanks, As a would be developer, I would like to know more about getting into a CD ROM type application development.. <[HoST] ST.LOU> Greg, would you like to answer Lorne's question? Once you get your application running on the very big hard disk you can approach one of the many CD publishers about getting a master done. The big problem has been the minimums required by most publishers and pressers. <[HoST] ST.LOU> Lorne, any followup? <[Lorne] L.WHITE17> Yes please. I've always presumed that the shell program that drives the application could be tricky since it's very much set up for the other platform. True or False. False. A CD looks like a VERY BIG hard disc to the OS <[HoST] ST.LOU> Anything else, Lorne? <[Lorne] L.WHITE17> But doesn't the interface have to be consistent across platforms ?? The CD can be a Mac CD, A PC CD. An Atari CD or cross- platform. You decide what you want it to run on. The media itself is very much cross-platform. <[HoST] ST.LOU> Greg, you mentioned minimums for pressing CD's but I thought PHOTO CD was economically feasible? How does one get PHOTO CD's done? All you do is take a roll of film to Walmart and tell them PCD please. Getting multiple copies pressed is not the same as making a one-of disc. I am about to get a CDROM drive for my TT. Is a Double Speed unit fast "enuf" or should I consider a triple or quad unit? This unit would be SCSI and might be a dual use unit with my PC laptop for tax data research. GA <[HoST] ST.LOU> Maybe David Troy would like to handle that one. <[Dave Troy] TOAD-SERV.> Sure... The double speed drives are pretty quick. Triple speed is even better though [450K/sec vs. 300K/sec & 150 with single speed. Price is not a problem. Are the faster units worth the extra price? <[Dave Troy] TOAD-SERV.> I would say that with the new technology coming out, and if you don't mind spending the extra bucks (approximately $100-$150), it might be a wise choice. Things are always going to need to be faster, wider, lower, longer, etc. :) And we sell double and triple speed NEC units at decent prices. That is cheap for the extra speed. Thanks for the suggestions. <[HoST] ST.LOU> Roger Burrows would like to add to Dave's answer... <[Roger] R.BURROWS1> Yes ... I agree with Dave. If you can afford it, go for the fastest. But I think the speed difference from single to double is enough for most of us poorer folks. <[HoST] ST.LOU> Roger, I know you are working on ExtenDOS. What speed units have you tested ? <[Roger] R.BURROWS1> So far, single and double. Tintin is looking at a triplespeed, so I may get to test on that soon . <[Dave Troy] TOAD-SERV.> I think that that is very fair... Double speed is pretty nice, but triple is maybe a little more future oriented. I am tickled pink with the double speed drive myself. :) I am used to the old 150K/sec 380ms crawlers. 200ms with 300K/sec seems like a speed demon. <[HoST] ST.LOU> I'll take that crawler off your hands :-) <[Dave Troy] TOAD-SERV.> I got plenty of 'em... :) <[HoST] ST.LOU> Next we have Sean Dougherty from Two Worlds Publishing. <[Sean@TWP] P-DIRECT> Right now, the uses of CD-ROM seem fairly limited to the home user. Could one of you go over a few of the more exciting practical things one can do with CD-ROM, just to help convince people they need one? (this isn't prompted, I swear!) GA DTP is a compelling reason. I have a CD with a couple hundred meg of clip art. Corel has several thousand images available now with more planned. The new Gemini CD has fonts ready to go. Animations like FLI are fun to view. Photo CD brings your images home and makes them personal. <[Dave Troy] TOAD-SERV.> The secret to CD-ROM on the Atari is finding applications which are not platform specific, as Greg said. CD-ROM is very much a data storage medium and just as your hard drive holds data files that your favorite programs can use, so can a CD ROM. The only catch is that you don't get to write to the CD ROM yourself, the way you can with a hard drive. So you are challenged to find CD TOAD-SERV. ROM's that already have data that your programme actually use. I think that Photo CD is a very exciting technology for CD-ROM on the Atari, as well as the potential for clip art, fonts, sound files (.WAV on Falcon!!), the new Atari GEMINI CD ROM. There are also lots of CD ROMS available with graphic images in GIF format, soon JPG. format will become prevalent (are the corel's JPG?) and the encyclopedia for the Compton's stuff from Brian. Pretty exciting stuff. [ga] <[HoST] ST.LOU> Mike Fulton is here and I know there was supposed to be a CD DEV pack. Mike, can you comment? Well, as you said, I have been working on an Atari Developer CDROM for several months now. Unfortunately, the collecting of software and other files (shareware and PD stuff) is the least of the whole project. One of the big bottlenecks has been the editing and rewriting of Atari's developer documentation. I've been working on putting it all (or as much as possible) into an online-readable format. And this involves updating old documentation, and a _lot_ of editing. It's taken a lot longer than I originally anticipated. It's not hard, per se, just time consuming. But it's coming along nicely and I do hope to have it done soon. In a lot of ways, it would be a lot easier to write a program to display and otherwise deal with an existing database (like some of the online encyclopedias and so forth). <[HoST] ST.LOU> From what I saw at Las Vegas Comdex, these DEV CD's have arrived in force. Good luck getting finished, Mike. Rob Sattler is next... <[Rob] R.SATTLER> Hello everyone, this is some great stuff! Q- Can you get by without MultiTOS? <[HoST] ST.LOU> Rob, I will let Roger Burrows answer that one. <[Roger] R.BURROWS1> Yes, you can ... that's what ExtenDOS does. It's designed for those people who don't need all the function of MultiTOS and/or have maybe a small hardware config. It's pretty straight forward to use, and works with pretty much any drive. <[HoST] ST.LOU> What about Falcon and PHOTO CD support, Roger? <[Roger] R.BURROWS1> Falcon support is on its way, I hope by the weekend. Photo CD is in the plans ... I only just got a pCD drive to test with. <[HoST] ST.LOU> Mike Allen is next. First let me say that the developments from Roger and Brian are exciting! These apps for the Falcon are all very nice, but how about us non-Falcon types? What I'd like to know is can I use a CD on my MSTe with an older ICD HA (pre AdSCSI). Would I only be able to read files, etc or is there some way I can look at photo-cds too? Not Yet Mike. The Photo Cd process looks best with lots of color. We have samples of Photo CD to SPC up on GEnie. They were done with DMJ-GIF You can convert a PCD to other formats. You see it best in true color. Studio Photo will run on an ST. All you need is for Roger to make a PCD driver for you. <[HoST] ST.LOU> Roger, is there anyway to use ExtenDOS with the ICD HA setup? Dave, do you have any configs for Mike? <[Dave Troy] TOAD-SERV.> You can attach a CD ROM drive to an ICD host but I don't know about the pre-AdSCSI models. ICD's Link & Pro utilities comes with a DMA 0-7 CD ROM driver for Metados. <[Roger] R.BURROWS1> ExtenDOS on the ST needs an ICD AdSCSI or equivalent. <[Rob] R.SATTLER> Is Extendos available now? How much? <[Roger] R.BURROWS1> Yes, available now, currently direct mail from me, hopefully soon at your friendly Atari mail-order dealer. Re price: $19.95 including everything (US$ in US, Cdn$ in Canada) Ontario residents, add sales tax (sorry). <[Dave Troy] TOAD-SERV.> Toad Computers will be talking to Roger about ExtenDOS. :) <[Tintin] C.LABELLE> I noticed TOAD advertises NEC 3xp. Have they been tested with Falcon and XFS? <[Dave Troy] TOAD-SERV.> Yes, but right now MultiSession support won't work with the NEC drives. They DO support single session Photo CD's with the XFS driver. The problem is not, of course, in the drive. They are fully multisession. The XFS driver, however, doesn't understand NEC multisession right now. The only drive that the XFS driver works with in multisession is the Toshiba 3401, which is a double speed drive and can be expensive. I know that Greg @ It's all relative is working on modifying the driver to support multisession on a wider variety of drives, especially the NEC. So all this means is that you would be restricted, right now, to Photo CD's with only one directory (development cycle) right now, but this is changing quickly. And of course all other CD's work fine. <[Tintin] C.LABELLE> OK so this denies earlier reports that the 3xp were not working with Falcon. <[Dave Troy] TOAD-SERV.> I have not had problems, but it does seem to be very driver related. There are many drivers out there, even among XFS varieties (2 or 3 versions). <[HoST] ST.LOU> Next we have Charles Smeton of NewSTar Technology I wanted to ask about ExtendDOS and the Falcon, but this was already answered. So I will ask a bit about how ExtendDOS works, i.e. how is it installed, how does it differ from MetaDOS, etc. <[Roger] R.BURROWS1> OK, well the basic idea is exactly the same as MetaDOS, that is, there's a supervisor (ExtenDOS) that traps the necessary system calls then there are drivers that deal with hardware and file systems. I have another driver written right now, and am working on still others. If they work out, they may be of more limited interest than the CD-ROM. Do you need any Falcon beta testers? ;-) <[Roger] R.BURROWS1> It depends :-) probably not, I have a volunteer in the Ottawa area, and believe me it's tough debugging hardware-level code over the phone! <[HoST] ST.LOU> Thanks Roger and Charles. Our next question comes from Mario Georgiou at DMC Publishing. <[mario] DMCPUBLISH> Hello all, I would like to know what formats are currently supported and whether you plan to support CDI and the new Pro PCD. We will have Portfolio format this summer. I just got a mailing from Kodak last week on the update. The PRO format is tough. Files are 64 meg uncompressed. This is what you call BIG. <[HoST] ST.LOU> Whew! The Portfolio format will have many discs published for it. <[Dave Troy] TOAD-SERV.> That's where you need more memory for the falcon... 14MB gets tight. <[mario] DMCPUBLISH> Big but needed, I look forward to replacing my MetaDOS ... Good luck <[Nima Montase] S.FARSHIDGH> Well, it's been about 30 mins now, but I was just going to add that I was just going to add that you can also use Audio CDs on your system, as another reason to buy a CDROM! <[Dave Troy] TOAD-SERV.> Oh yeah - you can.. Good point. Lots of PD players are available. <[HoST] ST.LOU> I would like to hear more specs, Nima. <[Nima Montase] S.FARSHIDGH> Well, right now you can play AUDIO CDs on all ATARI systems (did the Falcon one) <[HoST] ST.LOU> What is your software? ** <[Nima Montase] S.FARSHIDGH> ** disconnected Nima is the author of CD_AUD20 available as shareware here on GEnie. He is working on a Falcon CD audio player too but work is proceeding slowly as he doesn't have a test system. Watch for something in the next couple of weeks though. And if you are using his CD player, send in the registration. <[HoST] ST.LOU> Nima is back. Do you have more to comment, Nima? As I was saying, (Greg, did the Falcon AUD CD work fine?) NOT yet Anyways, the Audio CD supports all ATARI ST/TTs now, it has play, stop, pause, track with the option of playing random/programmable tracks, fast forward and rewind, eject, and also the capability of taking external data files (which is fully configurable) for any non SCSI II compliant CD ROMs. It should work fine on any CDROM that supports the SCSI II commands, I have also include a almost fully functional data file for NEC drives (older ones, the SCSI II not compliant ones), I am just waiting for some users' feedback! <[Dave Troy] TOAD-SERV.> Does the CD audio spec allow for playing digital data backwards, or do you always have to play forward from a fixed point on the disk? Yes, you can go back and forth either by passing along which track # you want or using the up and down option which moves the song up or down! <[Dr. Bob] W.PARKS3> First, I'd like to thank Charles for so accurately asking _MY_ question. Where can one find out more about ExtenDOS? I don't dislike MultiTos but I'd rather not have to add another level between the OS and a CD? Does it support a variety of CD-ROMS? etc. <[Roger] R.BURROWS1> I posted a notice in one of the conferences recently. Yes, ExtenDOS should support any SCSI CD-ROM drive. It's available mail-order direct from me, or hopefully soon from TOAD. <[Dr. Bob] W.PARKS3> Ok. The price is very nice - that doesn't bother me. What concerns me is when I start scratching my head wondering why the CDROM won't work or what. Does it have some technical documentation? <[Roger] R.BURROWS1> It comes with a manual, and I think it covers everything you need and I'm available by phone or via GEnie if that doesn't do it. <[Dr. Bob] W.PARKS3> Ok, thanks- sounds good! <[HoST] ST.LOU> Thanks Roger and Doc. Rob Sattler has our last question. <[Rob] R.SATTLER> I'm a Falcon user and own a Toshiba 3401b, but I can't seem to get it to handle a driver porperly. I understand Atari has a driver, how can I get it? Also, what would be better to use? AHDI, or ICD-Pro bootware? <[HoST] ST.LOU> Who wants it? <[HoST] ST.LOU> Everyone does :-) OK, one at a time. Mike Fulton... The CDROM driver is independent of the hard disk software. Therefore, it doesn't really matter if you use Atari's hard disk driver or ICD's. Theoretically, a CDROM driver could link in with a hard disk driver, but that's not the way that the MetaDOS or MiNT XFS drivers work. <[HoST] ST.LOU> GREG is next, then Roger then Brian. <[Rob] R.SATTLER> OK, but you do need either extendos or multitos? The version of the XFS driver we ship will all our Photo CD products is the most current XFS for MultiTOS and works quite well with all our suggested drives. <[Roger] R.BURROWS1> Basically, you need ExtenDOS or MultiTOS ... At the moment, ExtenDOS doesn't handle Falcon ... But that should be fixed in a week. <[HoST] ST.LOU> Brian, anything to add? <[Brian] B.GRIER> According to howard at ICD they are having problems with Atari's CD-ROM XFS driver and their software on the Falcon. If you need a CD-Rom driver that works with ALL Atari computers, but does not yet support Photo-CD you'll probably need ExtenDOS or my CD ROM XFS driver that's works on all computers (I wrote it because last year I couldn't find a driver that worked on the SCSI port of my TT :( <[Dave Troy] TOAD-SERV.> We have not had a problem using ICD Pro & the Atari XFS? ICD is shipping an older version <[Dave Troy] TOAD-SERV.> It seems to work fine. <[HoST] ST.LOU> Dave, thank you for coming tonight. Would you like to make any closing comments? <[Dave Troy] TOAD-SERV.> Just to thank everyone for their interest in CD ROM. It's a new and exciting technology, and I hope that everyone gets involved with it so we can build the critical mass necessary to get some apps together. The Gemini CD ROM is selling great! I think that's a good sign. Thanks again. <[HoST] ST.LOU> You're welcome. Greg Kopchak, thank you for organizing the group and getting everyone here tonight. Any closing comments? Thanks goes to Rene Guimont and Rene Tremblay for providing the Gemini CD. As the conference was on tonight I got an Airborne package from our German publisher, totronic. Watch for an announcement shortly. <[HoST] ST.LOU> Sounds exciting. I would also like to post some info on the Gemini CD. Walnut Creek CDROM announces the release of the GEMini CDROM for Atari Computers. The CDROM contains 616 MB, and 2872 public domain programs, shareware programs and commercial demos for the Atari ST, TT, and Falcon Computers plus a section for the Portfolio palmtop computer. It also contains text and graphics for the Lynx and Jaguar video game systems. The GEMini CDROM is set up in a logical tree structure which simpifies seaching for and running the programs. You can find files in areas such as accessories, archives, astronomy, database, fonts, games, GNU, programming, screeen savers, virus , text editors, utilities, etc. It includes 50 megabytes of games and entertainment software. For the desktop publisher, it contains 15 megabytes of fonts. Many programs include source code. All programs may be run directly from the CDROM so there is no need to decompress onto the hard drive in order to use the files. Each directory contains an index and a list of files to make it easier for a user to locate a file. <[HoST] ST.LOU> Greg, thanks again to you and your guests. Mike Fulton, Roger Burrows, Brian Grier, S.Fardishgh, Dave Troy, Damien Jones. We really appreciate the time and are keenly interested in this new era for our Atari Computers. Good night. Programming Real Time Conference January 6, 1994 Host - Mike Allen <[Host] MIKE-ALLEN> Ok guys, capture on! The homework idea sure stirred up some good discussion in cat3/top11. I was glad to see it. There were 4 homework submittals I saw, Keith, Carl, Erin and myself. All seemed to take a different approach to the problem. Carl was quite elegant in C. It was a TOS program. Carl - I couldn't get it to run under MultiTos - Kept getting a "out of stack space" message. Any comments Carl? ga. They were interesting, even some had some 'bugs' in some others. Don't know why it was straight gemdos conws() IO and nothing wierd. Might have been those so called documented settings. ga <[Host] MIKE-ALLEN> It ran fine with Geneva and a normal MSTe. Oh well, someday I will figure out how to use my MTOS, let alone program it. ga <[Host] MIKE-ALLEN> Keith wrote a VERY small assy prog that did everything in a dialog box. It ran fine with normal system, Geneva and MTOS. Comments Keith? ga <[Keith] K.GERDES> Not that I can think of. The dialog box was actually a simple form alert. I didn't want to go overboard on the graphic out... ;) ga <[Host] MIKE-ALLEN> Really small 800 and some odd bytes. <[Keith] K.GERDES> Actually it was 428, but who's counting. GA <[Host] MIKE-ALLEN> Hmmm - I thought it was larger - oh well, I was impressed! Erin Monaco wrote one that ran in a window. He used C. It too ran with a normal system, Geneva and MTOS. I wrote mine in assembly as a TOS program. Not as fancy as the "real" programmers, but it worked - again, normal system, Geneva and MTOS. Lets see if anyone else downloaded the prgs and has any comments. Phil, did you get a chance to look at the prgs? ga <[Phil] P.HANZE> I downloaded yours, but haven't uncompressed it yet. <[JAB] J.BATES15> This should start something. Being new to programming the ST line, I need some reccommendations of languages and such. <[Host] MIKE-ALLEN> Ok - phil, don't laugh too hard. On languages, German is preferred these days, Hardly anyone comments in english any more. <[Host] MIKE-ALLEN> JAB - I think most of us agree on either C or assembly. Carl (CBARRON) will extol the virtues of FLEX, given an chance. Bud - did you get a chance to look at the prgs? ga <[JAB] J.BATES15> Well, John actually <[Host] MIKE-ALLEN> <[Bud] B.CONNOLLY1> No I didn't Mike. I wanted to get started on mine before I looked at the others efforts, but I ended taking a vacation from programming over Christmas. ga <[Host] MIKE-ALLEN> Ok bud, I guess that's allowable. J2 - did you look at them? ga <[John too] J.G.H.> No I didn't get a chance to look at any of them ;( been busy here of late ;> ga <[Host] MIKE-ALLEN> Ok - Hi Erin. Discussing the homework. You have any comments on your prg or any of the others that were uploaded? ga Haven't really had time to update mine or check out the others... been playing with geneva <[Host] MIKE-ALLEN> Understand. I've been playing with 003 too. Carl - any comments on any of the other prgs that were uploaded? ga Erics was nice, almost forces me to upgrade my compiler. All looked ok, after all this was not to be the program of the century, they work, don't look too much like gwbasic spagetti either. ga <[Host] MIKE-ALLEN> hehe - I dunno, mine was spaghettish. Keith - did you have a chance to look at the other uploads? Any thoughts if so? ga <[Keith] K.GERDES> No... Sorry. ga <[JAB] J.BATES15> So C and assembler. What will access the DSP in the Falcon? <[Host] MIKE-ALLEN> Hmmmm - well I guess not too many folks had a chance to review other folks work. If any of you get a chance, you might take a look. John - hang on a couple 'til we get to general discussion please. <[JAB] J.BATES15> No problemo <[Host] MIKE-ALLEN> I noticed a couple of things. Seems like terminolgy bit some of us. Especially when it came to how version numbers were stored. I like to refer to the storage of most of the Atari version numbers as "Packed BCD." Does that need explanation? <[Bud] B.CONNOLLY1> Go for it Mike, so we'll all be on the same page. <[Host] MIKE-ALLEN> e.g. AES version 1.9 is stored a $0190. all I did was report a straight hex conversion. Gemdos version is small endian rest the normal big endian. <[Host] MIKE-ALLEN> Each byte is actually 2 BCD (Binary Coded Decimal) digits. As carl noted, except for GEMDOS, the versions are Major Rev in the first byte and the minor rev in the low byte. make that 2nd byte to avoid confusion! . GEMDOS is backwards, like Intel uses or, as Scott refers to it, "Little endian!" <[Bud] B.CONNOLLY1> Carl or Mike, can you explain the 'ENDIANs'? <[Host] MIKE-ALLEN> Now the first place I ran into confusion was with the GEMDOS version. The fun will come from the cookies, some are 32 bit #'s some are only 16 bit # 's and some are really only one byte #'s. That becomes more fun, I cheated, I reported all as longs.... Big endian means the high bytes before for the low bytes the number twenty would be [as normal] 20 in a high endian, or 02 in low endian. <[Host] MIKE-ALLEN> Bud - Big Endian is like the 68k uses - if you load a word into a register the Most significant byte is in bits 15-8 and the least signigicant byte is in bits 7-0. Little endian does it the other way around. <[Bud] B.CONNOLLY1> thanx guys. <[Host] MIKE-ALLEN> Little endian words are also referred to as byte-reversed. 6502 was little endian too <[Host] MIKE-ALLEN> True. <[Bud] B.CONNOLLY1> So Intel format is Little Endian. I also reported cookie values as longs (hex). <[Host] MIKE-ALLEN> My first confusion was with the GEMDOS version. I understood that it was byte reversed, but I had mixed signals at to whether it was in packed BCD or binary. Most of the European docs (devpac, etc.) reference binary values where as the Compendium says they are Packed BCD. e.g. GEMDOS for TOS 2.05 is 0.19 in the Compendium and 0.25 in the DevPac docs. So which should we use? <[Host] MIKE-ALLEN> I was leaning towards the European convention since the disk based version of TOS reports a $0D00. <[Bud] B.CONNOLLY1> I like the Compendium method. $1900 is 0.19 is a lot easier to keep straight. <[Host] MIKE-ALLEN> However, Scott swears that Atari says they are now using packed BCD. This seems to be verified since the GEMDOS version for TOS 2.06 is $2000 which is one minor rev up from $1900 that was used for TOS 2.05. $0d is not a bcd decimal packed or not. <[Host] MIKE-ALLEN> Carl - you got that right! I would lean towards the consistant bcd myself. <[Host] MIKE-ALLEN> I think we should stick with the Compendium version - Packed BCD, byte reversed. good, I don't have to change it... again :) I THINK atari means they are hex but read as decimal. Seems to be more consistant than the 'normal' definitions. ga <[Host] MIKE-ALLEN> Now where I really got confused was in the cookie Jar. Carl - I think you are right, which is why I like to refer to them as packed BCD. Each 4 bits of a byte defines one decimal number. well I'll be glad to get it all straight <[Host] MIKE-ALLEN> Now, the cookie jar is wild! For instance it appears the MTOS reports a version in packed BCD, whereas the _CPU cookie returns a binary number for the CPU type. Confused the hell out of me! The _CPU cookie returns a $0000001E for a 68030! It is if you wanted to define the meanings of various cookie values... I just report them like carl. <[Host] MIKE-ALLEN> Well, I was kinda of interested in what the cookies meant. Any further discussion before we look for a new assignment? ga I thought about it... it could be done using the compendium, then for all none standard cookies... probably be easier to just report the long value as is. er none=non <[Host] MIKE-ALLEN> I was decoding and reporting the Geneva, MTOS and GDOS cookies in my prg. There is no consistancy on what the parameter is. Plain and simple it is cookie specific. To use a cookie value, you need to know what it is or what it points to. There is a cookie standard, all cookies are standard. Some are ATARI's. ga I have a suggestion for a new assignment, how about a simple gem windowed editor... <[Host] MIKE-ALLEN> I have uploaded the Atari defined cookies as per the compendium to lib 19 for those who don't have the compendium. I would encourage those who have insight into other cookies to upload the info to lib 19. Erin - Gee, I haven't figured out how to open a window yet! yes, when dealing with cookies you HAVE to know what the values mean. good time to learn mike! gee you got some ideas I still am waiting for some cookie info on some graphics cards. w_handle= wind_create(0,20,20,200,100); wind_open(w_handle,20,20,200,200); ga <[Host] MIKE-ALLEN> Ok - suggestions for the next homework assignment. Remember that the next meeting is a Templemon/Sysmon session with some very expert experts. So any assignment would be due the first meeting in Feb. Suggestions? Expand on what we have been doing? Something entirely new (like Erin's suggestion)? Something else? Forget it? ga. good, I got to get to yacc'ing again. >grin< Seriously gem text sounds important, but are we 'up to' it?\ experts?! hardly, although I did get it running and sorta know how to use it. <[Bud] B.CONNOLLY1> Good point Carl, Erin, how 'simple' do you mean? I think we are up to the challenge, especially collectively... and we have the CAT where help is always available. <[Host] MIKE-ALLEN> Carl - that is my thought. Maybe we could work up to it in steps? Like the first step is open a window with certain gadgets and put some GDOS text into it? <[Bud] B.CONNOLLY1> good suggestion Mike. <[Host] MIKE-ALLEN> I know how we could be 'heros!' Figure out why Falcon and FOTI don't work on TOS 2.xx and up and fix them! I was thinking a simple one window editor (24 lines) cursor movements, insert, delete, bs, that sort of thing. <[Host] MIKE-ALLEN> Erin - GDOS? Nah... at least not at this poind. er point. I like the steps idea... lets break it down further. <[Host] MIKE-ALLEN> So, erin, no scroll bars, no fuller gadget, etc? Nope, just a window that'll hold 24 lines 40 or 80 cols with simple editing. <[Bud] B.CONNOLLY1> That might be a little too 'simple' Mike. GDOs who uses GDOS? Only gdos I use is with AW occasionally... First get some user inputted text in the window. A hero's project, is a GEM APPLICATION code generator using gem... I suggest we start with just vdi text, skip using GDOS. <[Host] MIKE-ALLEN> Erin - so later on we could expand it? Do you want it to be able to load a file or just save it? Word wrap? give us a definition of the first step. hmmm, first step no load or save, just 24 lines of programmers choice of text printed into window where the user could then edit it. <[Host] MIKE-ALLEN> It comes up with text? doesn't have to... you could let the user enter and edit it, but keep it to one windows worth <[Host] MIKE-ALLEN> sounds like a good first step. Lemme see if I have it right. Open a GEM window with space for 24 lines of 40 or 80 column text (depending on the rez) and then allow entry and editing using the keyboard, cursor keys, bs and delete. OK? after all the editing is going to be the tricky part... we could always expand the buffer and add load, save, search, replace, etc, etc. sounds perfect. <[Host] MIKE-ALLEN> Gotta run with Geneva and MTOS too! of course! :) <[Host] MIKE-ALLEN> any objections? lets start it with a menu too... with just an about item and quit. <[Host] MIKE-ALLEN> Ok, I have no objection to the menu - makes Geneva's life easier. I think the menu should be in a rsc file, so additions will be easier latter on. Can't guarantee it will run without a stack overflow! Might be a compiler problem, but based on past perfomance... A menu means you are going to do a lot of work, the scrolling is a small part of it, if the data is stored properly. go <[Host] MIKE-ALLEN> Besides, you can brag a little in the "about" box. Yeah I agree with the .rsc, but not as a requirement at this time <[Bud] B.CONNOLLY1> You can do that if everyone has a Resource Editor. <[Host] MIKE-ALLEN> Looks like I get to learn WERCS too. the rsc file is just a suggestion on my part, I've found it much easier to modify rsc files then to modify embedded rsc's. <[Host] MIKE-ALLEN> Lets make the menu optional, but encouraged. If you are going to do gem programming you need one, there is at least one in the libs, if you don't have one. RSC file is a good idea at this point, for menus, dialogs at least... <[Bud] B.CONNOLLY1> How will you exit the program without a Menu? ok, but if we plan to add load and save, etc features it should be HIGHLY recommended. <[Host] MIKE-ALLEN> Bud - why do you always come up with those pesky little details? <[Phil] P.HANZE> what about -q? control-c or have a close box... but then you wouldn't get 24 lines. <[Bud] B.CONNOLLY1> Because, that's what I do at work all day long... <[Host] MIKE-ALLEN> You could exit with the close gadget. Exits without menu things like , q, etc.... I'd stay away from cntrl-C. I like that for kill operation. <[Bud] B.CONNOLLY1> Yep, forgot about that. if you have a close box, you should have a title, and for a multitaskers sake, a move bar. <[Bud] B.CONNOLLY1> Some more pesky little details Mike! <[Host] MIKE-ALLEN> Use the Atari Standard for exiting - ^Q Ah yes, the infamous while(handle_input()!=WM_CLOSED); GA <[Host] MIKE-ALLEN> Ok, I think we have enough to start on - let's keep the discussion going in cat3/top11. I'm sure things will get refined there ok? <[Bud] B.CONNOLLY1> okay sounds good. FINE <[Phil] P.HANZE> sounds fine to me <[Host] MIKE-ALLEN> Thanks for the suggestion, Erin. Considering what I learned with the simple assignement we started with, this one ought to be a real education! no problem, glad to help :) btw, I've learned a few things myself! Thanks erin I might get back into gem yet. <[Host] MIKE-ALLEN> Ok, general discussion. John has been waiting patiently for some suggestions about compilers/assemblers. Give him some ideas. ga all. <[Bud] B.CONNOLLY1> What are you looking for John? <[JAB] J.BATES15> thanks Mike I need a C that will run on a Falcon <[Host] MIKE-ALLEN> Lattice 5.60? Lattice 5.60 is supposed to work fairly well with the falcon As for assemblers, I can only recommend devpac, C compilers , I use Lattice , Pure is OK. Most others are not supported these days. Lattice is supposed to run on a falcon. <[JAB] J.BATES15> downward copatability would be nice I agree if you need languages... check out HiSofts... they have nice, albeit expensive products. <[Bud] B.CONNOLLY1> Prospero has a TT version of their C compiler, that should work on the Falcon. <[Host] MIKE-ALLEN> I believe that DevPac 3.1 is supposed to run on a F030/ Lattice C and DevPac III is a killer programming combo. <[Host] MIKE-ALLEN> I'm using DevPac2. Haven't freed up enought disk space to install 3 yet. 8^{ mike? when is the next assignment due??? I compile old style K&R from the wonderful world of unix with lattice no problems, It even has an old style preprocessor if that is required. Lattice is o.tion city. It is gui driven. Comes with loads of stuff, checkout cat 33 top. <[Host] MIKE-ALLEN> Erin - First thursday in Feb. DevPac III is ... sweet. topic 6 that is. thanks mike... <[JAB] J.BATES15> now about a Resource editor? <[Bud] B.CONNOLLY1> Mike, the meetings are First and Third Thursday now? Lattic comes with wercs. Hey, can I use a Pure C lib with lattice? Wanna update Geneva's Task Manager... without lots of porting hassles. <[Host] MIKE-ALLEN> Bud - I thought they were always the 1st and 3rd. <[Bud] B.CONNOLLY1> I got K-Resource 2 with the Prospero Developers Toolkit. <[Host] MIKE-ALLEN> girn? <[Bud] B.CONNOLLY1> No, Mike, I thought it was every other Thursday. But I could be wrong ,g. I checked out ORCS... seems... relatively complete/complex, any comments on it? <[Host] MIKE-ALLEN> Bud - sorry - I meant it to be 1st and 3rd. Twice a month. I tried it it seems to work, but since I have lattice I use wercs. <[Bud] B.CONNOLLY1> No problem Mike, every other Thursday was just easy for me to remember, PAYDAY! <[JAB] J.BATES15> and the Compendium? <[Host] MIKE-ALLEN> The Compendium is a "gotta have." I know what you mean carl... why fix what aint broke (regarding Wercs) <[Bud] B.CONNOLLY1> Yep, gotta get it! Toad has it for $45. <[JAB] J.BATES15> And you want this program when? <[Bud] B.CONNOLLY1> Feb. 3 <[Host] MIKE-ALLEN> JAB - 1st thursday in Feb. <[JAB] J.BATES15> no problem! Programming Real Time Conference January 20, 1994 Host - Mike Allen Guest Speakers - Erin Monaco Keith Kerdes Scott Sanders <[Host] MIKE-ALLEN> Ok folks, our Guests are all here . . and I guess we should get started. The capture buffer is on, so watch yourselves. <[Scott @ SDS] S.SANDERS2> Ooooh mild aftershock, that was neat. <[Host] MIKE-ALLEN> Tonight Erin, Keith and Scott have agreed to discuss and answer questions about TempleMon and SysMon. Since we aren't loaded with folks I will try to keep it informal. I will ask that you try and keep a little order. What I suggest is that after each question, the guests answer in turn, first Erin, then Keith and then Scott (in order of arrival) I'll try and moderate a little, but I hope I don't need to do too much. You guys have been doing great so far. Each of the guests, please use a GA (go ahead) when you are done so that the next person knows to proceed. Using the /rai command for everyone else will let me get things organized. I already have Charles with a /rai. Can I speak? <[Host] MIKE-ALLEN> Charles - hang on while I ask the guests for opening comments on SysMon and temple mon. Charles yea go for a quickie. ga Does anyone know the latest version of SysMon? I have 1.0.8 (10/11/91) Is there a Falcon compatible version or a way to make it work on a F030? ga <[Host] MIKE-ALLEN> Erin? <[Erin] E.MONACO> 1.0.8 is the latest version that I know of charles. No idea on a Falcon version. GA <[Host] MIKE-ALLEN> Keith? ga <[Keith] K.GERDES> 1.0.8 is the version I have running in the background right now. It's dated 1-26-92. wish there was a Falcon comp. version. GA <[Host] MIKE-ALLEN> Hmmm - scott doesn't use it? <[Scott @ SDS] S.SANDERS2> Yes, I use 1.08. That's the best/most recent as far as I can tell. ga 1.08 has a problem on my Mega STe/TOS 2.06 that wraps the screen (right edge over the left side). That should have said 1.0.8 and it has a date of 10.11.91 when you hit the Help key in SysMon ga <[Host] MIKE-ALLEN> Hmmm - let's let Erin start with opening comments. What is Sysmon/TempleMon and why should I use them? GA <[Erin] E.MONACO> All versions that I have seen seem to shift the screen to the right in like 16 bit increments. I just keep toggling between sysmon and the app till it corrects itself. Hmmm, I don't have a speech prepared, but Sysmon is a VERY powerful developement tool which almost completely monitors every aspect of your machines current state. TempleMon is a resident debugger that can be used hand in hand with Sysmon In combination you have a very powerful debugging/monitor system. GA <[Host] MIKE-ALLEN> Erin - what is the latest version of Templemon? ga <[Erin] E.MONACO> 2.01 or something like that... can't recall exactly. GA <[Host] MIKE-ALLEN> Ok - Keith your comments? ga <[Keith] K.GERDES> I'm not familiar with TempleMon's development... I do know SysMon though! SysMon is an excellent programmer's aid. You can monitor these system functions: AES VDI GEMDOS LINE-A XBIOS & BIOS You can also get the status of different facets of the system, such as memory, vectors, etc. GA <[Host] MIKE-ALLEN> Thanks. <[Erin] E.MONACO> Mike, 2.01 is the latest version available on GEnie. Docs & Prg in German. GA <[Host] MIKE-ALLEN> Keith - it what way does it monitor those functions? Some sort of real time display or what? GA Erin - thanks. <[Keith] K.GERDES> Yes. SysMon works in the background. It hooks into the system and you can control which aspects you want to monitor....in realtime. The info displayed is a detailed readout of each TOS function as it is performed- parameters passed and results returned. You can even send the text output to various devices- serial, parallel, file, etc. GA <[Host] MIKE-ALLEN> Wow - sounds like what is needed to debug the BPS. I'm gonna have to look into it. <[Erin] E.MONACO> I'd like to add to keiths comments. ga <[Host] MIKE-ALLEN> GA, Erin. <[Erin] E.MONACO> Sysmon gives you the option to turn on/off tracing of each OS call. In addition, with the profiler you can do a quick initial run to find out which calls were made and how many times they were made. hmmm, gee I'll shut up for now :) GA <[Host] MIKE-ALLEN> Thanks Erin. Scott, your turn for comments. GA <[Scott @ SDS] S.SANDERS2> I've used both Sysmon and Templemon for debugging, however, I haven't used them actively in some time because neither one likes MultiTOS v1.08 and I have to switch setups to use them. Reportedly, v2.01 of Templemon does work, though, I have been unable to have any success with its setup (it's quite involved). Both tools got me out some sticky situations and helped in writing the Compendium (shameless plug) by disassembling the OS when Atari couldn't answer a question about an obscure function. ga <[Host] MIKE-ALLEN> Thanks Scott. Sounds like you need a boot handler such as MouseBoot, etc. I use Mouseboot to swtich from Geneva to MTOS to vanilla MSTe, etc. <[Scott @ SDS] S.SANDERS2> I use Xboot but it's still a fuss. ga <[Host] MIKE-ALLEN> Well, I guess we are ready for questions. /raises please. GA <[Erin] E.MONACO> I've installed 2.01 it works well with my STE and Geneva. ga <[Host] MIKE-ALLEN> <[Keith] K.GERDES> I can send a sample SysMon output file if you'd like to see it? <[Host] MIKE-ALLEN> Ok, bud - ask away! ga <[Bud] B.CONNOLLY1> So, let's see if I have this right... SysMon will tell me about the OS, what it is doing, and Templemon will tell me what my program is up to? ga <[Host] MIKE-ALLEN> Erin? GA <[Erin] E.MONACO> Basically. SysMon show calls made to the OS and y which process as well as detailed reports on system variables, vectors, I/O buffers, ect. ga <[Host] MIKE-ALLEN> Keith, GA <[Keith] K.GERDES> You would use TempleMon to debug a program at the instruction level- ie. a monitor/debugger. MonST is another example. SysMon is a "system call" monitor. If you want to see what parameters to pass, you could see how another program does it. TempleMon is at a lower level. GA <[Host] MIKE-ALLEN> Keith why don't you dump that sysmon output now. I'd kinda like to see it. ga <[Keith] K.GERDES> Ok... ***************************************************************** * * This file was created by SYS_MON, the ATARI ST System Monitor, * copyright by Karsten Isakovic, Berlin * * It is forbidden to publish this file or extracts of it without * the copyright header ! * ALAD wind_update BEG_UPDATE -> 1 ALAD wind_get H 0 TOP -> 1 ALAD wind_update END_UPDATE -> 1 ALAD evnt_multi KYBD BUT { 2,1,1 } MSG TIMER { 0,0 } Buf $0DE35E -> (124,72 ) B$00 K$00 Key $2300 But $FF Event = MU_TIMER ALAD wind_update BEG_UPDATE -> 1 ALAD wind_get H 0 TOP -> 1 ALAD graf_mouse HIDE_MOUSE $000000 -> ALAD graf_mouse SHOW_MOUSE $000000 -> ALAD graf_mouse HIDE_MOUSE $000000 -> ALAD graf_mouse SHOW_MOUSE $000000 -> ALAD wind_update END_UPDATE -> 1 ALAD wind_update BEG_UPDATE -> 1 ALAD wind_get H 0 TOP -> 1 ALAD wind_update END_UPDATE -> 1 ALAD evnt_multi KYBD BUT { 2,1,1 } MSG TIMER { 0,0 } Buf $0DE35E -> (124,72 ) B$00 K$00 Key $2300 But $FF Event = MU_TIMER <[Keith] K.GERDES> GA <[Host] MIKE-ALLEN> <[Erin] E.MONACO> :) <[Host] MIKE-ALLEN> Scott - anything to add? ga <[Scott @ SDS] S.SANDERS2> Not much. Sysmon and Templemon each have features useful to specific situations. Sysmon cannot disassemble assembly code for instance. ga <[Host] MIKE-ALLEN> Ok, I have MonST, etc., from DevPac3. Is there any advantage to TempleMon over my HiSoft stuff? Ga Erin. <[Erin] E.MONACO> Yes, TempleMon remains resident and can be called up at any time, ever try to debug a desk accessory or worse a TSR? :) GA <[Host] MIKE-ALLEN> I thought I could use AMONST for resident use? ga <[Erin] E.MONACO> er, got me! I'm not sure. GA <[Host] MIKE-ALLEN> Ok. Keith? ga <[Keith] K.GERDES> AMONST is the AUTO TSR version of MonST. Very small and quite handy. GA <[Erin] E.MONACO> Thanks Keith. ga <[Host] MIKE-ALLEN> Keith - any comments on TempleMon vs. MonST? ga <[Keith] K.GERDES> I used TempleMon in an initial release but that was several years ago... GA <[Host] MIKE-ALLEN> Scott - any further comments? GA <[Scott @ SDS] S.SANDERS2> I would say that AMONST would probably be better (slightly) than Templemon but I only have MonST which doesn't have the resident capabilites which are essential to me. MonST can trace C source code (sort) of which is its main advantage. ga <[Host] MIKE-ALLEN> Thanks Scott. What does it take to set up TempleMon. Can I use SysMon without TempleMon? Erin - GA <[Erin] E.MONACO> TempleMon and SysMon are designed to work together Using TempleMon 2.01 with Sysmon 1.0.8 in TT hires they will share the same screen. (can't test this but I bet it'd be nice) Yes, you can use both Sysmon and TempleMon independantly. ga <[Host] MIKE-ALLEN> How do you set up Templemon? Scott indicated some problems. GA Scott. <[Scott @ SDS] S.SANDERS2> I had problems with 2.01. It is advertised to work with MultiTOS but doesn't specify a version so I suspect it was tested on 1.01, not 1.08 which I use. The earlier Templemon is simply one AUTO program. The latest Templmon requires an AUTO program, several overlays, things placed in named directorys, and environment setup. Looks powerful but is a bear to setup (Erin seems to have got it though). ga <[Host] MIKE-ALLEN> Thanks - Keith - comment? GA <[Keith] K.GERDES> Just that I'd take TempleMon over DB anyday... GA <[Host] MIKE-ALLEN> Erin - comment? GA. <[Erin] E.MONACO> 2.01 isn't to difficult when you get past the german translations. It comes with an installation program that'll modify the actually program mainly it consists of preferences, like assigning hotkeys, colors, buffers, edit modes and the like. GA <[Scott @ SDS] S.SANDERS2> I speak pretty good german (must be the new math :). <[Host] MIKE-ALLEN> Ok Erin, thanks. Bud has a question. GA Bud. <[Bud] B.CONNOLLY1> How tough are breakpoints to set up in TempleMon? What do you need to be able to set a breakpoint,(ie assembler listing)? ga <[Host] MIKE-ALLEN> Erin - ga. <[Erin] E.MONACO> I've just played with it, so I can't say. GA <[Host] MIKE-ALLEN> Keith - can you help bud? ga <[Keith] K.GERDES> Breakpoints in a debugger are either set from the commandline input or with a hotkey at an address. GA <[Host] MIKE-ALLEN> Scott - GA. <[Scott @ SDS] S.SANDERS2> For instance, if you want a breakpoint at 0x1FFFFF you type: b1 1FFFFF which sets breakpoint 1 to the given address b+ turns breakpoints on... after this point, anytime the PC==address, Templmon is entered. ga <[Erin] E.MONACO> I can add a little more. ga <[Host] MIKE-ALLEN> GA Erin. <[Erin] E.MONACO> SysMon gives the address at which OS calls were made you could use this to your advantage. Also since TempleMon and SysMon work cooperatively you can actually TELL SysMon to jump to TempleMon when certain OS calls are made. ga <[Host] MIKE-ALLEN> Hmmm. Bud - any more? ga <[Bud] B.CONNOLLY1> thinking... <[Host] MIKE-ALLEN> Erin - could I use sysmon to figure out why the Spectrum-Holobyte games don't work on my MSTe? ga <[Erin] E.MONACO> I'd be willing to bet that you could, especially if its because of a bad OS call. If its just some weird code you'd locate it using a debugger. ga <[Host] MIKE-ALLEN> I think it is a bad mouse or event handler call. Where in the auto folder does SysMon reside? Keith ga <[Keith] K.GERDES> SysMon can be run at any point in the AUTO folder. Since it takes up quite a bit of memory, I just run it from the desktop when needed. GA <[Host] MIKE-ALLEN> Doesn't have to run before or after Warp9 or geneva? ga <[Keith] K.GERDES> Shouldn't require any special run order. It even has a provision for de-installing if you run it from the desktop. GA <[Host] MIKE-ALLEN> That's great. I'm gonna have to try it. I wanna look at the Speedo calls in Atari Works and see why I get the Black Page Syndrome! <[Erin] E.MONACO> SysMon/Geneva/Warp_9 doesn't work... at least for me.. 3 bombs. ga <[Host] MIKE-ALLEN> Anyone else have any questions before we let our guests get some sleep? <[Bud] B.CONNOLLY1> I'm sure we could go all night Mike, but I need some sleep myself. 6:00 am comes pretty early! <[Host] MIKE-ALLEN> <[Host] MIKE-ALLEN> Guess not. Closing comments Erin? ga. <[Erin] E.MONACO> In closing... SysMon is VERY handy, well worth the time to learn and use. ga <[Host] MIKE-ALLEN> Keith? ga <[Keith] K.GERDES> GA <[Host] MIKE-ALLEN> hehe <[Host] MIKE-ALLEN> Scott? GA. <[Scott @ SDS] S.SANDERS2> Both programs are very handy. I can't wait to see something running under MultiTOS such as Spy under Windows. Oh well. ga <[Host] MIKE-ALLEN> Thanks to our guests, Erin, Keith and Scott. I'm gonna have to try Sysmon for sure. <[Bud] B.CONNOLLY1> Thanx Erin, Keith and Scott. You've given me some useful information, now I'll just have to dive in and try 'em out! <[Host] MIKE-ALLEN> Capture buffer off. Rabble time. Wednesday Night Real Time Conference February 3, 1994 Host - Larry Duke <[Temp Host] LARRY.D> I'm gonna be eating pizza while typing. If you see some cheese on my text, you'll understand.... <[John too] J.G.H.> hehe....and drinking Jolt and smoking cigarettes? <[The MadMan] W.JONES43> Keith! Long time no chat! <[Temp Host] LARRY.D> As the room slowly fills..... <[John too] J.G.H.> isn't that the programmer's diet? <[Temp Host] LARRY.D> It is for me. Went to the dentist today, and I'm dying to try out this new cap. I may also type a bit hard to understand, considering the Novacaine.... <[Bill] W.JONES43> Forgot I was being the programmer type tonight! \nam Erin ack! <[John too] J.G.H.> ack...ack <[Temp Host] LARRY.D> We knew who you were anyway, Erin... ok... never mind then! :) <[Bill] W.JONES43> I finally got a Thursday off work - haven't been to this particular RTC before. What type of programming are we discussing? <[Temp Host] LARRY.D> All types, Bill. C, Assembly, GFA BASIC, whatever you want to.... <[John too] J.G.H.> Larry is tonight's "Special" host, Mike is busy tonight gee, thats a wide area <[Bill] W.JONES43> Ah - PureC's my favorite environment. Hisoft BASIC for quick and dirty hacks. <[Temp Host] LARRY.D> You don't want to join us, Rob? (Rob's hiding in the other room) <[John too] J.G.H.> I am currently playing with M.A.G.E. and GFA <[Bill] W.JONES43> John, is M.A.G.E. a toolbox for GFA or library routines? Could it be interfaced to C? The results I've seen look pretty impressive. I can't stay long but Mike wanted us to define our objectives for the next homework assignment a little better. <[John too] J.G.H.> It is a Graphics Engine and I think it currently only works with GFA of course you can use C in GFA so it probably is possible <[Bill] W.JONES43> Did my time with STOS - very nice results if you have LOTS of patience. <[Temp Host] LARRY.D> True enough, Bill. Interesting language, isn't it? <[Bill] W.JONES43> Yeah, but I don't own GFA and can't get a lead on 4.0. The 2.0 version crashes BADLY on my TT. OTOH, PureC's editor is a dream in TT-Med res. <[Temp Host] LARRY.D> I'm using GFA 3.6TT Bill. Works great in all resolutions (including 1280*960) Of course, the guys at GFA will swear up and down there is no 3.6, but that's what mine says.... <[John too] J.G.H.> Also MAGE comes with the latest version of GFA BASIC Interpreter, compiler and assembler on disk <[Bill] W.JONES43> Larry - yeah I heard that from them too. Actually they told me _NO_ version of GFA was TT compatible. It'd be nice if they offered a version of M.A.G.E without GFA for those who already own it. <[Temp Host] LARRY.D> Naw - they are the ones that sold it to me. I think anything after 3.6E is TT compatible... <[Temp Host] LARRY.D> Back from lurking, Rob? <[/dev/null] R.ANISKO> unlurked... how is everyone tonight? <[Bill] W.JONES43> Larry, programs _written_ in 3.5E MAY be TT compatible. All depends on how you set the fastload and TT-RAM bits. I've gotten a few to work well. <[Temp Host] LARRY.D> I see that Carl uploaded homework for this one. What was the actual assignment? <[carl] CBARRON> Re: Homework, good idea, how complicated a editor are we 'eventually' writing? <[Bill] W.JONES43> As long as the author stayed away from the RESERVE command. <[John too] J.G.H.> I know programs using MAGE don't like screen accelerators <[Bill] W.JONES43> John, actually Dark Pearl plays fine here with NVDI on the TT. Too damn fast to get past the first few inches of the board, but it _DOES_ run! <[Temp Host] LARRY.D> Bill - The earlier versions of GFA have a little problem with their MENU S$ command - it always defaulted to an 8 pixel height character. TT resolutions made the menus terribly compressed and overwritten. <[carl] CBARRON> I did? I have an incomplete one on my HD. Perhaps that was the first assignment Mike's looks a little more structured, this time. <[Bill] W.JONES43> Larry - THAT'S what caused that. Always wondered about it. <[John too] J.G.H.> I just turn off my warp 9 <[Temp Host] LARRY.D> Even earlier versions of GFA will still run if you use 24BIT.PRG in the auto folder. They stored additional info in the upper 8 bits of the addresses. <[John too] J.G.H.> MajicSoft also have BUTTONZBASIC a GUI shell for GFA which makes things easier ;> <[Temp Host] LARRY.D> I use GFA for things quick and dirty. For real programming, I use DEV PAC TT. I gotta upgrade to 3.0 soon.... <[Bill] W.JONES43> Larry - actually I use PMMU. Nicer, fixes a couple of mapping problems for games that ask for the ROM version directly and doesn't require a keypress if you have it in the auto folder. Our assignment was to write a simple windowed editor that would edit one windows worth of information. Just do simple stuff like cursor movement, insert, delete. If you wanted you could add a resource contianing a menu with info & Quit. <[John too] J.G.H.> I am trying to get the folks from MajicSoft on GEnie for an RTC <[/dev/null] R.ANISKO> I have a quick "C" question if anyone could answer it? <[Bill] W.JONES43> Shoot, Rob... I don't think anybody got into the editing part of it yet. I didn't. <[carl] CBARRON> where are we going with this editor? I have some gap buffer code, I might use if this is really an editor. I do use Lattice C and misc. unix tools ported to ST/TT. If this is going to go no place a simple arrangement is possible without <[/dev/null] R.ANISKO> real simple (but i haven't figured it out) - how could I simply write a ? <[/dev/null] R.ANISKO> oops. hang on... <[Temp Host] LARRY.D> That sounds like a very adventurous homework assignment.... <[carl] CBARRON> without any real editor code. <[/dev/null] R.ANISKO> how can I ask for a keypress and treat it as a hotkey - that is, take the keypresss and act *without* needing to hit RETURN? in "C" that is <[Bill] W.JONES43> Which C are you using? <[/dev/null] R.ANISKO> GCC How far I am not sure, we had talked about adding maybe load and save, search and replace, things like that in later assignments. <[Bill] W.JONES43> Oh - in your TOS binding you'll find int Bconin(int port). Use port 2 for the keyboard. Inputs 1 character from device. "How far" is something we can address now. <[/dev/null] R.ANISKO> ok - will have to "grep" my header files and see what asscoaiets (associates) to it (typos tonight)... <[Bill] W.JONES43> Rob - or to be more "general", get(stdin) also works. <[Temp Host] LARRY.D> Is anybody having problems with the homework assignment so far? <[/dev/null] R.ANISKO> hmm, Bill, get(stdin) and not stdin( (oops) getch(stdin) or getchar(stdin)? <[Bill] W.JONES43> Rob - getch(stdin) in GCC. PureC has a couple of shortcuts. <[/dev/null] R.ANISKO> which Programming RTC had the latest and greatest description of the homweork? maybe i'll write myself an online spell-checker :-) Was it 6th of Jan? <[carl] CBARRON> Ok if we are going to do something with it sometime, I will play with a gap buffer. Got the generic code for one. <[/dev/null] R.ANISKO> which file transcript though? <[Keith] K.GERDES> I think the description was uploaded to the Topic. <[/dev/null] R.ANISKO> ok - will see if i can capture the info later... <[John too] J.G.H.> I will go look for ya ;> <[Temp Host] LARRY.D> You know, writing an editor is something I've wanted to do for a long time. I am by no means a professional programmer, and my little mind doesn't come up with any creative thoughts on buffering ideas. I believe Keith is right, it should be in the Topic. <[Bill] W.JONES43> Rob - if you're programming TOS style and don't intend to port your code, use TOS for all it's got. Your code will be faster. You need to list out your BIOS.H, GEMDOS.H and other headers and just prowl around. <[/dev/null] R.ANISKO> i wrote a simple editor under microsoft-c some time ago - might have to steal some of my old code (unfortunately it's not Atari code :-( <[Temp Host] LARRY.D> What is the best way to do this? A gap buffer, I realize is what is needd, but how should each line be stored in memory? After an edit, should the entire document be reformatted in memory and the inserted in the proper place? (that should read "the LINE inserted in the proper place.") <[/dev/null] R.ANISKO> ph well, will try to hack around sometimes this week - i need to go now though - maybe see yunz at the brodie rtc... <[John too] J.G.H.> here it is ;> hmmmmm.... <[Bill] W.JONES43> Larry, shouldn't an editor insert 1 character at a time and reformat as quickly as possible? Otherwise you can't see what you're doing until you finish the line! <[John too] J.G.H.> well if anyone else needs the info on the homework here it is Number: 31565 Name: PRGRTC04.ARC Address: MIKE-ALLEN Date: 940108 Approximate # of bytes: 10496 Number of Accesses: 54 Library: 13 Description: Transcript of the 4th Programming RTC held on 6 January, 1994. Comments and reviews of the 1st homework assignment. Second homework assignment defined. <[carl] CBARRON> A gap buffer keeps the free space of the buffer at the insert point. Pointers to the start of lines, with lengths is one approach to lines. I'd planned on doing its something like that. Not worrying about wrapping or stuff like that. <[Bill] W.JONES43> Carl - I like that concept. Easy to implement too. I guess since I wasn't in the original "assignment" RTC I should hush now, though... <[carl] CBARRON> Easy but not that easy, when all the possibilities are considered. Have DDJ's C source on that someplace. <[Temp Host] LARRY.D> So, you basically just have an array of addresses for the start of each line? <[Bill] W.JONES43> Carl, is your line size defined? If so, then you don't need pointers to the start of each line unless your trying to conserve memory. <[Temp Host] LARRY.D> It would be relatively easy if all lines were a given length, but how do you work with variable line lengths, and edits that extend over 1 line? <[Bill] W.JONES43> Any of you ever been on a BBS using FidoDoor? <[carl] CBARRON> That is the only real approach. It also complicates the gap buffer approach some as the start of a line in the buffer is variable. A gap buffer is going to move lots of text variable lines get the most out of a fixed amount of memory and reduce the 'mallocs' involved for long lines. The one thing I hate about some editors is a line max. Some as small as 100 characters. terrible for editing ascii text files.... <[Bill] W.JONES43> Larry, why would an edit extend past one line? You'd have to make changes character by character or the user wouldn't see the results as they typed. <[carl] CBARRON> Search and replace will edit in more than one character at a time... <[Temp Host] LARRY.D> Here's my thought, Bill (it's probably really screwed up, and I'm hoping somebody can set me straight).... <[Bill] W.JONES43> Carl, I see your point. Yes, then you'll have to have pointers to the start of each line and your search routine will have to ignore whatever you're using as an EOL marker. <[Temp Host] LARRY.D> Each character is displayed when it's entered, and the text is stored in a temporary buffer. Once ENTER, an arrow key, or something like that is pressed, the contents of the buffer is dumped into the TEXT buffer and stored. That way, you could have an UNDO function really easily. <[Bill] W.JONES43> But the gap concept isn't totally off. Insert or modify the necessary text, then increment/decrement the line pointers after the modified line by the changed length if any, then redraw. Larry! I'm gonna have to do something like that in MY editor (for real editor, not this project). So obvious it never dawned upon me. I have an undelete line function, but not an undo right now. I'd planned on going pretty much the same route. <[Bill] W.JONES43> Actually, it'd be easier just to have a "twin" of your real text buffer - when they hit your "hot" keys, copy it back to the "real" buffer. Always display the "twin" on screen. <[Temp Host] LARRY.D> If you insert text, the TEXT buffer would then be reformatted with the new text inserted in the right place. It would take LOTS of memory moves to create the text buffer in a sequential order. <[carl] CBARRON> Larry that is one approach useful in reducing memory moves of a gap buffer as well. Bill, all lines after the edit as well will move with a gap buffer. <[Bill] W.JONES43> Carl, yes - I meant to modify ALL the line pointers after the affected line. Inserting text requires 1 memmove() call. Carl, maybe I don't follow you. You have a SECOND area of memory for your gap buffer? Why not just create the gap in your REAL text buffer? <[carl] CBARRON> memmove is ok, but with a project like this and a 680x0 a better approach is to move longs if possible, providing the size of the move is bigger than 16 bytes. <[Bill] W.JONES43> That's the way Bryan Hall and I did it with FidoDoor. Would using the blitter speed it up? <[Temp Host] LARRY.D> My experiences with the Blitter are that it's not quite as fast as straight assembly moves.... <[Bill] W.JONES43> Carl - true. And YES, blitted moves will make it FLY, but only if you're moving 16 bytes or better. But sheesh, how fast are you expecting someone to type? Larry, but this isn't being coded in assembly, is it? Or does the language matter? Using longs you have to insure that your working on even addresses, and on the newer 680X0's using a longword boundry will speed it up even further <[carl] CBARRON> A gap buffer moves the 'free area' to the insertion point any time the text is changed. If you use a simple edit approach in a second buffer then insert it onta return or cursor movement. Moving 64k or 128K at a time to insert one chara cter is slow.... <[Bill] W.JONES43> Carl, okay - but for display purposes you need have a pointer that say which line is currently held in the gap buffer and its location. Also that makes you have a size limit on edits, correct? <[carl] CBARRON> No, you write the text SKIPPING THE AREA OF THE GAP buffer. It is constantly changing in location BTW. <[Bill] W.JONES43> Carl, now I'm confused. Don't you want to display the changes they're making AS THEY MAKE THEM? Otherwise you won't know if you made a typo until you move the cursor. <[carl] CBARRON> Well it is confusing to talk in three lines. A gap buffer is a block of unused memory that is moved to where it will be used. If you set the pointer of the current line to an input buffer, no problem, it will display the input buffer. It is possible in design, details are not infront of me. As we are seeing this is not as simple as first appears.... <[Bill] W.JONES43> Carl, okay. That's what I meant. Display all unchanged lines PLUS the gap buffer they're currently typing. Something I've been meaning to add to FidoDoor, in fact to speed up its redraw speed. <[Temp Host] LARRY.D> I honestly thought this was an ambitious project for this early in the Programmer's RTC life - it may well be over the heads of most people (me included) <[carl] CBARRON> over heads, only if thinking past the 'design specs' of the assignment. I do think, it should be in pieces myself. After years of reading, I am often lost myself.... <[Temp Host] LARRY.D> Can we redefine the assignment? Has anybody got it handy? <[carl] CBARRON> for the assignment an array of say 500 byte lines is more than sufficient, as it stands. 512 makes more sense Carl, for some people even working with GEM is totally new. Why don't we just concentrate on opening a window with a title and close box if thats not enough we could do a displayed cursor that can be moved with the arrow keys. <[Temp Host] LARRY.D> That's not a bad idea. I personally would be intimidated by an assignment to write an editor like this. I could, however, write something that opened windows, reacted to all of the window commands, etc. I could then take THAT knowledge and use it later for a project like this. <[carl] CBARRON> Gem text is something I hardly ever do. Fine we can open a window, clear its contents and redraw it. That is essentially what my shell is doing. <[Temp Host] LARRY.D> Still, I'm a little unclear as to the actual assignment. I realize it's a text editor in a window, but with INSERT, DELETE, and stuff like that? Just writing the cursor control portion would be a relatively long project... <[carl] CBARRON> Supposedly, eventually... Cursor control with mouse or just gadgets and cursor keys??? It shouldn't be that hard. You need routines that will turn the cursor on and off and adjust its onscreen position. I'd like to see mouse control. That'd be a nice feature and not to hard to implement once the regular routines are in place and working correctly. <[carl] CBARRON> a small box drawn in xor mode over the text is the normal way to draw a cursor. removal is the same as drawing... thought lag.... Keith, what do you think? <[Keith] K.GERDES> I sent Mike email a couple weeks ago about starting out small and working the way up through the AES ladder. I believe thats the best way to procede. <[Keith] K.GERDES> The project as it stands is way too ambitious IMO... <[tony] T.SMOLAR> hello everyone <[Temp Host] LARRY.D> I think that's a good idea, Keith. The first assignment was to check the computer status and display it on screen. Now, why not do the same thing in a window? Hiya, Tony. We take what we already know, then build up slowly. Next time, we add resources. The time after that, we add something else, etc... <[tony] T.SMOLAR> I was wondering if anyone could help me, I'm having problems getting GNU C working <[Temp Host] LARRY.D> Pretty soon, we've done every call in standard TOS, and we can then start with the extended calls of MiNT, etc.... Shoot, Tony - I can't answer, but there are people here that probably can. <[carl] CBARRON> Not a bad idea, KISS there are a lot of people with not a lifetime to devote to a project. Structured design helps a lot.... I've got GNU C up, what's the matter. <[tony] T.SMOLAR> I'm trying to get GNU C working with either Gulam, or GNU BASH, preferably BASH But when we try to use the compiler, it seems like it can't find something\ I have to go... so are we just going to worry about getting a window up and handling that? <[Temp Host] LARRY.D> Eric - that's my preference. Of course, I'm just a small player in a big band... Oops - EriN <[carl] CBARRON> Erin, looks like you are right. I don't think mike is ready for a full editor at this time either.... I like the stats in a window idea, but have already done that, I suppose I could add to it though. <[Temp Host] LARRY.D> George, any ideas on how to help Tony? How about a text viewer in a window??? I agree, I've done alot on my project but at the expense of getting other work done, I'd like to see it toned down a bit. :) <[Temp Host] LARRY.D> That's not a bad idea, George. No editing, just viewing, etc... Depends on what it cann't find as to the problem, environment variable probably. <[carl] CBARRON> About GNU C sounds like some environment strings are wrong. I don't use gnu C so the specifics I don't have... <[tony] T.SMOLAR> I have GCC set up (in gulam) as per the "Quick Start" instructions. Okay. Take care everyone. <[Temp Host] LARRY.D> After this, we could add SEARCH capabilities, then menu's to load, etc... 3 variables are needed GCCEXEC "setenv GCCEXEC d://gcc-" GNUINC "setenv GNUINC d:/" GNULIB "setenv GNULIB d:/" <[Temp Host] LARRY.D> Tony - does that sound like it will work? <[tony] T.SMOLAR> Could the problem be that I am using "\" pathname separators instead of the UNIX-like "/" ones? with GCCEXEC the "gcc-" is needed as it prefixs the executable needed "ld", "as", etc with the variable. This assumes the executables are named "gcc-ld", "gcc-as". Tony, it should not "/" & "\" are the same for most GNU and public domain thing. <[tony] T.SMOLAR> Can someone tell me more about "UNIXMODE" under Bash? How do I set Bash up to work with it? Also, instead of "d:/<>" you could try "/dev/d/<>", these programs treat both as the same. Tony, you can send me mail if this doesn't work, include what errors are produced, etc and I'll reply. <[tony] T.SMOLAR> Thanks. <[Splat!] DMJ> Hello... UNIXMODE is to complex to explain here, but I'll send you some docs I have. <[carl] CBARRON> Da fun of 'cheap' software.... Written for unix masters... <[tony] T.SMOLAR> Ok, I'll give that a shot, thanks for the help. and I'll look forward to that doc file. Written to get UNIX things working ok on the Atari. <[Splat!] DMJ> So what's all the discussion about tonight? <[carl] CBARRON> True, you don't happen to have berkeley yacc 1.9 compiled? <[Splat!] DMJ> (And _don't_ ask me if I did my homework...) <[Temp Host] LARRY.D> Damien, did you do your homework? <[carl] CBARRON> What is the discussion? a) splitting the homework, b) how to edit text, c)other. <[Temp Host] LARRY.D> (I had to do that) <[Splat!] DMJ> I said not to ask me that! No, I didn't do my homework. No yacc here, just starting to get GNU stuff, damn they're big. <[Splat!] DMJ> I've _never_ done my homework, if I could get away with it... ever since I started school. Might explain why I nearly flunked out. <[carl] CBARRON> Just downloaded f2c (f77 to c) translator only 594K compressed tar file. <[Splat!] DMJ> Geez, tiny download... Just got CS-TeX, 4meg. Ghostscript 1meg, thank god for fast modems. <[Splat!] DMJ> I could never get into UNIX-type tools. For some reason, they just don't appeal to me. Carl, however, loves them... So it's probably just me. I got really hooked on Unix at school, I REALLY like suns. <[carl] CBARRON> True but it might contain the code I need to write a fortran file reader for my c code..... They do work esp. sed/gawk.... <[Splat!] DMJ> I always knew I was warped. For my entire Atari setup I might be able to buy a CPU. <[Splat!] DMJ> Maybe if I'd had the chance to work on a Sun or other UNIX workstation I might like it more. But then again, my fondness for neat, compact, _usable_ programs might get in the way... Anybody see Keith Gerdes' post about Missouri? "compact" would be really nice. <[Temp Host] LARRY.D> Nope - he just left, though (actually, he was disconnected) <[Splat!] DMJ> Hmmm. Maybe he knew I was coming. I have a feeling we might not be on speaking terms, soon. (Sigh) <[carl] CBARRON> Small useable tools are the backbone of unix style operations. this stuff is source and often underdocumented [for 'dummies'] documentation. <[Splat!] DMJ> That depends what you call a usable tool. <[Temp Host] LARRY.D> "If it was hard to write, it should be hard to use" "Real programmers don't document" or comment their code.... <[Splat!] DMJ> For example, a program to display memory usage in a windowed dialog, updated every five seconds or so... How big, in C? I must not be a real programmer, then. <[Temp Host] LARRY.D> Big - in assembly? Small... <[carl] CBARRON> Larry, that is the problem and they resent profesional writers doing it for them! <[Splat!] DMJ> No, how big would such a program be in C? i.e. how many K is the executable. Did I mention resolution-independent? Works as a program or accessory? Is MTOS & Geneva aware? Includes an option to shut off the five-second update thing? <[Temp Host] LARRY.D> I'd say as a minimum it would be 18K (if you have a good optimizing compiler) GNU C produces about a 15k file to do nothing (stripped). Damn those huge libs. <[Splat!] DMJ> Uses 100% legal GEMDOS and AES calls? Right now, mine is sitting at 5K. And it wasn't something I slaved at for weeks, either. <[carl] CBARRON> Depends on the compiler and slim down startups. maybe 8-12K in LC5. <[Splat!] DMJ> I didn't go to any great pains to make it small. If I had, I wouldn't have embedded a complete .RSC file in the program. I think I'm making an ass of myself here. I should stop. <[Temp Host] LARRY.D> Written in assembly, Damien? <[Splat!] DMJ> Of course. It will probably be ready by Saturday. If I didn't have to work tomorrow, it'd be tomorrow. <[carl] CBARRON> Size of the 'lib stuff' is signifigant only on small student sized projects. a project like ldw power not so.... Anyone know a a good RSC editor (recent) availiable??? <[Splat!] DMJ> That's true, Carl. <[Temp Host] LARRY.D> You know, those are my feelings, too. I write in assembly, never learned C because of the terrible overhead. I started on a 16K computer, and have been very memory conscious ever since. <[Splat!] DMJ> In a 100K program, who cares about a 10K library? <[carl] CBARRON> commericial - I use wercs. Free ORCS works, but is not 3d aware, I do not believe. <[Temp Host] LARRY.D> George - I have INTERFACE from GRIBNIF software. It's really nice. The new one from ATARI is supposed to be really nice, too. Hello. Is this informal? <[Splat!] DMJ> ORCS is not 3D aware, no. It's what I use. Yep, informal. Not many people write 100K programs. <[Splat!] DMJ> Really? Huh. I'll keep that in mind when I try to keep Sound Lab under 200K. Can I ask a non-programming related question? <[Splat!] DMJ> Won't bother _me_. <[Temp Host] LARRY.D> INTERFACE is really nice. GRIBNIF hasn't finished the English docs yet, and I hope to get those in the mail when it then completed. Nice RCS, though. Next time you're in town, I'll be glad to show you, George... <[carl] CBARRON> I got one 141K demo exec, will get bigger since I found the problem. over 400K of source, I did not write... <[Splat!] DMJ> Yeah, those demos are usually huge. A lot of it is because they use straight-line code, tho'. <[carl] CBARRON> esp. when it is msdos code! <[Splat!] DMJ> They get great speed by eliminating the looping overhead. How can one use a WOrd Perfect file on an Atari? <[Splat!] DMJ> Oh, MS-DOS code. That's different. That's always huge, no matter what you do. Use WordPerfect ST? All I have is WORKS. <[carl] CBARRON> unsigned char foo[]={....}; stuff over 400K.... <[Splat!] DMJ> Even a 386 takes twice as many instructions to do the same task as a 68000. It's ridiculous. I don't know AW, Sam... can't help you. Perhaps one of these other enlightened individuals? <[Temp Host] LARRY.D> There is a program to convert Word Perfect to ASCII somewhere in the library... Where? ;-) <[Splat!] DMJ> Which would strip out all the formatting, but would be useful if all you needed was the text. <[Temp Host] LARRY.D> Are we talking WP 4.1 or a later version? I dunno. I FTPed some files off internet, and I THINK they are wordperfect. <[carl] CBARRON> Its about 75% of the msdos side. On WP there is program to translate wp5.2 files to something in the libs I downloaded, but did no use.... internet, tex, or postscript is more likely.... The first two characters are "WP" and one line further down says "NEC SILENTWRITER..." There is a lot of crappy formatting stuff throughout. <[Temp Host] LARRY.D> Yep - that's a WP file, alright. Search the library (item 3) for CONVERT and see if something shows up. <[carl] CBARRON> ok is probably a word perfect file. I'll let some search the libs. It is less than a month old if I recall. I can find it if it's there! Thanks. I'm gonna go look! Thanks! Bye! /************************************************************************/ NETWORK SIGN-UP INFORMATION /************************************************************************/ --------------------------------------------------------------------------- -- --==--==-- GEnie Sign-Up Information --==--==-- -- -- -- -- 1. Set your communications software for half duplex (local echo) -- -- at 300, 1200, or 2400 baud. -- -- -- -- 2. Dial toll free: 1-800-638-8369 (or in Canada, 1-800-387-8330). -- -- Upon connection, enter HHH. -- -- -- -- 3. At the U# prompt, enter XTX99436,GENIE then press . -- -- -- -- 4. Have a major credit card ready. In the U.S., you may also use -- -- your checking account number. -- -- -- -- For more information in the United States or Canada, call 1-800- -- -- 638-9636 or write: GEnie, c/o GE Information Services, P.O. Box -- -- 6403, Rockville, MD 20850-1785. -- -- -- -- --==--==-- Atari's Official Online Resource! --==--==-- -- --------------------------------------------------------------------------- --------------------------------------------------------------------------- -- --==--==-- CompuServe Sign-Up Information --==--==-- -- -- -- -- -- -- -- -- To sign up for CompuServe service, call (voice call) (800) 848-8199. -- -- Ask for operator #198. You will be sent a $15.00 value CIS membership -- -- kit for free. -- -- -- -- -- -- -- -- --==--==-- CompuServe Sign-Up Information --==--==-- -- --------------------------------------------------------------------------- --------------------------------------------------------------------------- -- --==--==-- Delphi Sign-Up Information --==--==-- -- -- -- -- To enroll as a Delphi subscriber, modem call 1-800-365-4636. Press -- -- [Return] once or twice, and type IP26 [Return] at Password: -- -- -- -- Answer all of the questions, and you'll be cleared for Delphi -- -- access in a few days. If you have questions about Delphi services, -- -- give a voice call to Delphi Member Services at 1-800-544-4005. -- -- -- -- --==--==-- Delphi Sign-Up Information --==--==-- -- --------------------------------------------------------------------------- /************************************************************************/ Shareware survey - for shareware authors only By: Albert Dayes /************************************************************************/ The survey will only be used for statistical purposes only. It will not be used for any other purpose. If you have any questions feel free to send me e-mail. Shareware Author's Name: Program Name: Program Type (game,application, utility): Date of first Release: Number of Registrations: Demo (Yes/No): Updated (Yes/No): Current Version: Suggested Donation: Fill out the above form and send it via e-mail to the editor. Please send seperate forms for each individual peice of software. Send your filled out form via e-mail to any of the following addresses. CIS: 70007,3615 GE: AEO.1 In: 70007.3615@Compuserve.com The results will be in the next issue of AEO-PJ. /************************************************************************/ Brain Stem Rotator By: Russell Sasamori /************************************************************************/ Problem: Implement !a&&c&&!d||a&&!b&&c||b&&d in C without using unary or binary operators. a,b,c,d are integers holding boolean values. /*-----------------------------------------------------------------------*/ A possible solution for the last Brain Stem Rotator (AEO-PJ #3) was sent via e-mail. The original problem is listed first followed by the solution. PROBLEM: Write a program that will take an integer number as input and generate Roman Numerals for the output. Attempt to use 20 lines or less of code. Maximum input value is 32767, while the minimum is 1. Examples: input: 5 output: V input: 9 output: IX SOLTUION: Albert: Re: Roman numerals (and back), this does not quite meet your specs, but you might find it interesting. Henry K. van Eyken From "Fleabyte" Course, 1987 Written for Casio pocket computer a. From decimal system to Roman numerals: 10 PRINT CSR3;"ROMAN NVMERALS", CSR5; "under 8999,""" 20 GOSUB 500 40 INPUT "Decimal number:",N 50 IF N>= 8999 THEN 40 60 FOR J=7 TO 1 STEP -2 70 A=10^INT(J/2) 80 B= INT(N/A) 90 N=N-B*A 100 IF J=7 THEN 150 110 IF B=9 THEN PRINT Q$(J);Q$(J+2); : GOTO 190 130 IF B=4 THEN PRINT Q$(J);Q$(J+1); : GOTO 190 140 IF B>=5 THEN PRINT Q$(J+1);:B=B-5 150 IF B=0 THEN 190 160 FOR K=1 TO B 170 PRINT Q$(J); 180 NEXT K 190 NEXT J 200 PRINT "" 210 GOTO 40 500 REM *ENTER SYMBOLS* 510 FOR I=1 TO 7 520 READ Q$(I) 530 NEXT I 540 RETURN 550 DATAI,V,X,L,C,D,M The last subroutine is for computers that have READ and DATA in their vocabulary. For the others, the corresponding sub is: 500 REM *ENTER SYMBOLS* 510 R$="I":S$="V":T$="X":U$="L":V$="C" :W$="D":X$="M" 520 RETURN My sources show evidence that different conventions existed - and, indeed, still do as you may observe by comparing the Roman numeral for four used for page or paragraph numbering with the four on the face of a clock. In writing a program we must make a choice. The program I made will print, for example, 1496 as MCDXCVI, not as MXDVI. The number 49 will produce XLIX, not IL. I gather that, although MCDXCVI is acceptable, XLIX may raise eyebrows. You might want to modify the program by adding or changing these lines: 30 F=0:$="" 110 IF B=9 THEN F=F +2:$=Q$(J)+Q$(J +F): GOTO 190 120 F+0: PRINT $;:$ ="" 130 IF B=4 THEN F=F +1:$=Q$(J)+Q$(J +F): GOTO 190 200 PRINT $,"" 210 GOTO 30 The symbol M for 1000 used to be written in a form resembling (I), 10000 like ((I)), and 100000 like (((I))). I have avoided these symbols by declaring an upper limit of 8998, probably naively so. An old sign for 5000 resembles I)), just as that for 500 looked like I), which has since become D. A subroutine places the Roman symbols in variables R$ - X$. The "J-loop" performs three distinct operations, which might well have been placed in separate subs. The first (lines 70 - 90) is to extract from the given number the thousands first, the hundreds next, then the tens, and the ones. Lines 100 - 150 handle the actual translation and the positioning of the Roman symbols. The "K-loop" (lines 160 - 180) counts out the number of each symbol to be printed. This exhibit may be helpful: Cause: Q$(7) Q$(6) Q$(5) Q$(4) Q$(3) Q$(2) Q$(1) M D C L X V I & Effect: If B = 9(000), line line 170 prints nine times M If B = 9(00), line 110 prints Q$(5) + Q$(7): CM If B = 9(0), line 110 prints Q$(3) + Q$(5): XC If B = 9, line 110 prints Q$(1) + Q$(3): IX If B = 4(00), line 130 prints Q$(5) + Q$(6): CD If B = 5, 6, 7, or 8, line 150 prints Q$(2) and lets B = 0, 1, 2, or 3, and so forth. b. From Roman numerals to the decimal system: The program for converting from Roman to arabic number writing is a lot easier to make and to read: 10 PRINT " BACK FROM ROME","" 20 GOSUB 500 30 P=0:N=0 40 INPUT "Roman nu meral",$ 50 FOR I= LEN($) T O 1 STEP -1 60 FOR J=1 TO 7 70 IF MID$(I,1)=Q$ (J) THEN GOSUB 400 80 NEXT J 90 NEXT I 100 PRINT N 110 GOTO 30 199 END 400 REM **CALC** 410 IF J>= P THEN P=J :N=N+A(J): GOTO 230 420 N=N-A(J) 430 RETURN 500 REM **ARRAYS** 510 FOR I=1 TO 7 520 READ Q$(I),A(I) 530 NEXT I 540 RETURN 550 DATAI,1,V,5,X,1 0,L,50,C,100,D, 500,M,1000 /*************************************************************************/ Software Development Conference and Exhibition By: Albert Dayes /************************************************************************/ Software Development (SD) is for continuing education of programmers and product managers. It offers many different classes including: Aligning Information System Straegies with Business Strategic User Experiences Development Teams More Art than Science? Modeling the Cost of Software Quality 21 Rules of Thumb for Shipping Great Software Model-Driven Rapid Application Prototyping Power, Politics and Developer Productivity Why Settle for Late Software ISO-90001: International Madness or Improving Methods Reengineering Development for Object Oriented Software Managing Design Legal Protection of Software: What Works and What Won't Introduction to C++ Virutal Functions How to Develop GUI Design Standards and Methodology Creating Best-In-Class Software thru Customer Centered Development OLE 2.0 Component Objects Introduction to C++ Exceptions and Pointers Making the Move to C++ Strategies for writing Portable C code C++ Class Design C++ Programming Style Compating Object Database Management Systems Unix System Release (SVR4.2) 4.2 MP Security This is only a very small list of the many classes that were available. A week's worth of classes is close to $1000 which is not too bad. But for 3 days of Exhibits Only is $50 or for free. After attending a few different programmer related shows one will start receiving many offers for free exhibit passes to the different conferences. Many of my friends who attended the conference said it seemed smaller than in past years. But, even still they said the classes are always the best part of the show. Real world questions, and solutions to programming problems. There is approximately 200 classes to choose from and over 250 vendors exhibiting at Software Development this year. California, USA | | V |-------| | | | | \ * <---------- San Jose \ \ \ \ Pacific \ \ Ocean \ \ \ \ ------- The show is also known for new product announcements and good prices on software. For example Computer Associates was giving away CA-Realizer version 2.0 just for sitting through a 15 minute seminar. Other booths had drawings once a day for one free copy of their software as well. Suddenly I heard shotgun blasts and screams coming from the middle of the hall. Rational was showing off ID software's game DOOM to show the power of its DOS extender (breaks the 640K barrier, 32-bit flat model). (You can find an interview with ID software in new magazine, Game Developer.) I can't wait to see it on the Jaguar. Walnut Creek had several CD-ROMs on display including the new Atari GEMini CD-ROM, (see a review of the GEMini disc earlier in this issue). They also had an updated version of C User Journal CD-ROM which includes all disks (thru 384) thru Dec 1993. Speaking of CD-ROMs there will be a CD-ROM disc of all the proceedings of Software Development (SD) conference available on CD-ROM. The cost was supposed to be around $50 or so. The Programmers' Shop, Programmer's Paradise and ProVantage were raffling off new software every hour or so, with T-Shirts were a being a big favorite among show goers. Watching people scrambling for flying T-shirts was really a sight to behold. I also found some good literature on RSA's security products which will you find in this issue. For a complete source code license is only a mere $25,000. Its similar to the price AT&T used to charge for Unix source code too. There are other software development kits available for under $500 that do not include complete source code. Also some freeware kits are available on internet as well. There are always many programming related publications available for no charge as well. The list includes: Software Development, Network Administrator, LAN - the network solutions magazine, Windows/DOS Developer's Journal, Application Development Trends, Microsoft System Journal, Windows Tech Journal, DBMS - Database & Client/Server Solutions, Dr. Dobbs Journal, Unix Review, Embedded Systems and a few others. In addition to magazines there were several book publishers present including MS Press, M&T books and QED/Wiley. Show discounts were ranging from 10 to 30 percent for most books. M&T was giving away a free copy of Al Steven's book C++ Database Developent (this was on the last day of exhbits). Al Steven's writes the C column for Dr. Dobbs Journal in addition to the several books he has published over the years. There was heavy emphasis on MS Windows, which is expected. And the big fight was in C/C++ compiler area with Microsoft, Borland, Watcom and Symantec going all out for the top prize (your money). Borland had a daily drawing to win a brand new CD-ROM drive. You can never have too many of those. In addition cross-platform GUI libraries were being pushed very hard as well. With Zapp, XVT, Zinc and others going through the paces. The best thing about the show is you can see a demo, ask questions and play with the software yourself. Zapp encouraged new users to play with the demos and ask any questions about their GUI library. In addition to these third parties Novell and Borland were pushing AppWare their new cross platform GUI library. Borland's OWL (proprietary GUI library) was demonstrated with the new capability to generate AppWare code as well. Microsoft was pushing Microsoft Foundation Classes (MFCs) for its portable GUI effort. These cross-platform libraries will allow one to use the same source code on DOS, Windows, UNIX (Motif), Windows NT and Macintosh platforms. In addition to programming/management classes and exhibits are the parties. This is another chance to win some more software in addition to talking with more developers until the early morning hours. This usually happened from 8pm to Midnight on most nights. The exhibit hours were from 11 am to 6 pm, Tuesday thru Thursday. "Code or Die" After several days of hype it was finally time to backup those comments with real working code. The C++/Visual Programming Superbowl brought out teams of two people from MicroSoft, Borland and Symantec to code a working Windows application within 45 minutes. Each team was allowed to come in one hour before the event and load their software on the machines (which were 486 DX2-66 machines with 20 megs of ram). Each monitor was projected on a big screen behind the participants so everyone in the Ballroom could see. The crowd was hushed as the moderator told the teams to get ready. The command go instantly got some of the crowd screaming "Go Borland!" The programmers were also allowed to use sample code included with their compilers. The moderator talked about Symantec's incredible progress on their application (since Symantec never showed up). Every 45 seconds a scream "Go Borland!" ripped through the crowd. The people screaming were rewarded with T-Shirts that were flung over the crowd to reward the screaming participants. The moderator had fun with teams members telling them that their code looked funny or took jabs at the companies themselves. The jabs on the legal problems centered on Borland's C++ v4.0 license agreement which was a radical departure from all previous versions. This has since been changed but only after much ranting and raving in their forum on CompuServe. The crowd reacted with glee but then moderator quickly reminded MicroSoft about being compressed recently. In reference to their latest loss to Stac over data compression technology used in MS-DOS 6. It was great to see the true development cycle (edit, compile, link, run) on the big screen. Almost everytime Borland was compiling their code there was the typical "Go Borland" scream. The Moderator made sure he commented on the type of errors the teams were getting. It was with great delight when he commented on compiler or linker errors. When MicroSoft made a small mistake page after page of errors (maybe 100+ compiler errors) were the result. The crowd reacted as would sharks smelling blood with a lone voice yelling "Go Borland!" The pace increased as team members searched directories (some in vain) looking for the special peice of example source code. It was also a great way for other developers to see how effective the IDEs (Integrated Development Environments) that the companies had designed. The screens flipped quickly as team member copies blocks of code from the examples to their application. The "Go Borland" yell was much less frequent as the count down to completion neared. 5-4-3-2-1 ... the last compile and link and it was over. Then the moderator read through the software specification, with each team to demonstrate the feature for the judges. A cheer would rise from respective company employees when a company demonstrated working code. When a feature didn't work on MicroSoft's application according to the specification, the moderator commented "The next release right?" The crowd responded with a loud OOOOOOOOOOOOOOOOOOhhhhhhhhhhhhh which soon melted away into quiet laughter. After the finally tally of points Microsoft won by a narrow margin of five percent. This contest was really great especially after some of those hyped stats coming from both vendors. It was fun watching someone else sweat bullets trying to meet a deadline for a project too. It was definitely the best part of the show in my opinion. If you ever get a chance to go to Software Development it is well worth it. Even if you do not get to the programming classes themselves the exhibits with all the free software and magazines is definately worth your while. /************************************************************************/ 10 Tips From the Programming Pros By: Albert Dayes /************************************************************************/ On Compuserve (in the Atari Gaming forum) there was a discussion about Atari's Laservideo game FireFox. Based on the movie of the same name and the only laser disk game Atari ever made. This was 10 years ago, back in 1984. In the magazine Atari Connection (the magazine before it was renamed Atari Explorer magazine) there was a review of FireFox and an interview with Atari's corporate composer Jeffrey Gusman. To quote from that article "The Sound of Micros" by Michael Goodwin. Or, if you prefer, you can drop a coin into Atari's hot, new arcade game, FireFox, an interactive video-disk adventure for which Gusman wrote an astonishing, modular, 30 part orchestral score that fits together in thousands of different ways to provide a seamless, pulse-stirring soundtrack regardless of which of the 120 path-choices the game takes. That was a great game and they used a real orchestra too. You would have to hear it to believe how good it was. Or even better, play it! In the same magazine there are a few programming articles, but the one on tips was very useful, and still is even though it's 10 years old. So below you will find a reprint of article from the Summer 1984 issue of Atari Connection magazine. 10 Tips From the Programming Pros hex Atari Advanced Games Groups Speaks Your (Computer's) Language. TTTTTT AKE TEN COMPUTER PROFESSIONALS, each with diverse experience and TT at least one successful video game credit. Add the support of a TT major hihg-tech company, ample facilities, state-of-the-art TT hardware and the freedom to explore and create original software. What you'd get would be a consortium like the Atari Advanced Games Group. For the past 14 months they have been writing text adventures, creating skill-and-action games, dreaming up entirely new electronic entertainment forms for the coin arcades, home computers, and video game systems. And without the pressure of the marketplace -- the group's mandate was to please itself, with Atari picking up the tab. Even with the quality and polish of the ensemble, Atari expected only 30 to 60 percent of their projects to make it -- a respectable estimate given the vicissititudes of the market. Currently the group's score is a perfect three for three: its first game Final Legacy has just been released, and slated to follow is an innovative maze game and fully upgraded sequal to Star Raiders. There's a lot of excited conversation around the games-group offices. You hear serious talk about magic rings, black holes, star fighters and their mathematical representations. Also lots of laughter and music. An appropriate tune would be "You Can Be a Star." Sly Stone might have been thinking of the Advanced Games Group. When we asked the group for Ten Tips, we forgot they think in code. What we got was ten hexadecimal tips -- which translates into a few extra. Not a baker's dozen, but a programmer's generous count. 1. Don't be afraid of criticism Once you've developed a part of your program to your satisfaction, ask a friend or someone you trust to take a look at it. Listen to what is said. Criticism is a very touchy subject with most people, but it does work -- to your advantage. Never forget, though, that it's your program. You're the final judge. 2. Be eclectic A video game must put the player inside a world, not just in front of a television screen. A game designer must know more than just computers. The more well-rounded you are, the more you draw from all the aspects of this world, the better your game will be. 3. Learn Assembly Language It's true that Assembly language is fast and memory-efficient, but the real reason to learn it is that you'll never really understand how the computer sees the world until you do. If you're going to program for real, why do it on a "mystery machine?" 4. Keep learning -- ask questions. Programming in general, and game programming in particular, is a constant changing process. There's no such thing as "finally mastering it," the way you might master, say algebra; so never try to conceal you ignorance. Everybody needs help sometime. When that time comes, realize it so that you can get on with the job and your learning by asking. Just make sure you do learn, so you don't have to face that problem a second time. 5. Take chances and big risks Yes, there are lots of people out there making Q-Bert clones, and some of them are doing quite well, unfortunately. But that's not why you got into computing. Why not experiement? Try something nobody's done before. This is still a new field, and big breakthroughs have been made by people just like you. 6. Get something running as soon as possible so you have feedback Use whatever language you're most comfortable with, just to get a feel for the program. Don't worry about graphics or error-checking. The program itself may not be exactly what you want -- if fact it probably won't; but you can't play-test a flow chart. 7. Know your audience Any good programmer will make a memory map or sketch out screens beforehand: so decide who your audience is. Many programmers have set out to write software without considering the user. Before you write for other people, talk to them; afterward, let them test it out. Non-programmers are not going to be satisfied with mediocre products, primarily because they still think computers are magic. 8. Make it simple for the user If the game needs complex commands, make sure the player can get by without knowing all of them at the lower levels. When someone buys a game, he wants to play it, not wade through pages of print.(But read on.) 9. Read the manual again It's very easy for programmers to get set their ways. So many times we're in such a hurry to use that new hard- or software that we only glace at the instructions long enough to set it up--and sometimes not even that long. Once you've got it doing what you initially wanted it to do, take the time to see what else is available. Why reinvent the wheel? Programmers are tool users. When programming you're almost always working with hard- or software developed by someone else. But they become yours if you understand them. A. Clear the decimal flag. Is this facetious? No! When you first learn Assembly language or experiment with your Atari computer, its often convenient to access Assembly routines from BASIC. One problem that invariably occurs is that BASIC sets the Decimal Flag when doing math functions, and doesn't tell you. So your program crashes and you spend hours trying to find out why. So--clear that flag whenever you use USR. B. Throw it out The time always comes when a routine tunrs into a mess. First you try to make it do too much. Then you find a bug and you start rearranging things. Finally you have no idea what's going on anymore. That's the time to pull out a clean piece of paper, get away from the keyboard, and break it all down into smaller routines. C. Choose your tools according to the job No matter whom you ask for advice, you're the one who implements it. You're the one who has to sit over the keyboard for hours or months on end so choose the language, programming style, hardware and so forth that suit the project--and you. D. Take advantage of your computer Today's machine have amazing sound and graphics capabilities. The best software(especially games) use every bit of these they can. If you were a quarterback, you wouldn't run a quarterback sneak every play; you'd use every play you could devise, and all the players on your team. There, we never even got to ten. If you don't understand, see Tip 3. [ Editor's Note: The above article is Copyright (c) 1984 Atari Corp. It originally appeared in Atari Connection magazine, Summer 1984 Vol 4, No.2., pages 40 and 41. Members of the Atari Games Group include Jim Morris, Robert Weatherby, Mike Gurganus, Jack Ritter, Chris Horseman (group leader), Dave Menconi, Steve Englehard, Eric Wilmunder, Dan Oliver and Rita Pless. Back in 1984 the Atari 8-bit line was the only computer line Atari had. So some of the comments are attributed specifically to that platform. Permission is NOT granted for reproduction in any form other than this issue of AEO-PJ. ] /*************************************************************************/ Glossary of Terms /*************************************************************************/ ADA = A Programming Language created by the US DOD for use in embedded systems. The name is in honor of Ada Lovelace who, some claim to be the world's first programmer. AES = Application Environment System AI = Artificial Intelligence CLASS = An abstract data type which includes information on variables. In addition one may define precisely what functions have access to those variables. It can be thought of in C++, as a struct that allows functions to be part of the struct itself. DOD = Department of Defense (USA) DSP = Digital Signal Processor FORTRAN = Acronym for formula translation. This programming language is very popular for scientific computation GEM = Graphics Environment Manager GRAMMER = One of the principal ways of specifying an infinite formal language by finite means LALR = Look ahead left right (a class of grammer) common when discussing bottom-up parsing LEX = Lexical Analyzer PROLOG = A logic programming language which is quite popular in AI community RCS = Resource Construction Set RCS = Revision Control System SDK = Software Development Kit VDI = Virtual Device Interface YACC = Yet Another Compiler Compiler /*************************************************************************/ ATARI DEVELOPER INFORMATION /*************************************************************************/ What you can buy from Atari in terms of developer documentation and support. Contact Atari for the specific details. Atari Corp 1196 Borregas Ave Sunnyvale, CA 94089 USA (408)-745-2000 (voice) Some of the benefits: + Several disks and approximately two thousand pages of programming documentation. + Atari Developer newsletter: ATARI.RSC + Atari Developer RoundTable support on GEnie (private) + Atari Developer CD-ROM (coming soon) + book: Atari Compendium, by SDS Publishing Call or write for details. /************************************************************************/ Sources of Information (References) Books, Magazines and Company Information /************************************************************************/ book: The C Programming Language (2nd edition, ANSI C) By Brian Kernighan and Dennis Ritche ISBN 0-13-110362-8 The Standard C Library By P.J. Plauger ISBN 0-13-131509-9 Prentice Hall Englewood Cliffs, New Jersey 07632 USA [ CIS: GO PHCP ] /***********************************************************************/ POST INCREMENT (what is coming up in the next installment) /***********************************************************************/ We are always looking for new articles, tricks, questions, tips and suggestions related to programming on the Atari. Also Brain Stem Rotator style problems are also needed. * More on Advanced Computing using YACC * Object Oriented Programming * C++ * GFA BASIC * Developer Perspective The type of articles we are looking for are anything programming related. STOS, dBMAN, C, Assembly, BASIC, Pascal, Lex, YACC, etc, etc. This is of course a very small list. Letters and comments are always welcome! And if you have a better technique for solving a problem we want to hear from you. If one has a suggestion on a particular topic that he/she would like covered please send EMail to the editor. Developers [Worldwide] send press releases about your products as well. We want everyone to know about the newest developer tools available. /************************************************************************/ LEGAL NOTES /************************************************************************/ Articles and letters in Atari Explorer Online Programmers' Journal (AEO-PJ) represent the views of the authors and do not necessarily reflect those of the publisher. Note all code and listings in Atari Explorer Online Programmers' Journal (AEO-PJ) appear "as is," and AEO-PJ makes no guarantee or warranty of their quality, performance, accuracy, or suitability for any particular purpose. AEO-PJ assumes no responsibility or liability to any person or entity with respect to any damage caused or alleged to be caused by their use. Material published in this issue may be reprinted under the following terms only: articles must remain unedited and include the issue number and author at the top of each article reprinted. Reprint permission is granted, unless otherwise noted at the beginning of the article, to registered Atari user groups and not for profit publications. /************************************************************************/