/********************************************************************** Title: AEOPJ3.TXT Created: October 13, 1993 Last Modified: December 19, 1993 Purpose: Third installment of AEO Programmers' Journal Editor: Albert Dayes Legal Notes: Copyright ½ 1993 Subspace Publishers ***********************************************************************/ 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: Mike Allen [GE: MIKE-ALLEN] Scottt Sanders [GE: S.SANDERS2] [In: S.SANDERS2@genie.geis.com] [CIS: 71461,3645] [ 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 introduces YACC to GEM * Hard Core - Interview with Greg Kopchak developer of Photo Show * Dabbling in PASCAL - Kris Gasteiger discusses clock functions * Library - Error corrections to the book, Atari Compendium by Scott Sanders * Periodicals - Optimization and user interfaces are covered in this issue * OBJECT::ATARI - Warwick Allison examines the GEM++ class library * Parsing the human equation - by Ron Whittam * Language Watch - Current versions of developer tools * Bad Example - Do you really want to do that? * On the Networks - Interactive programming online * Network Sign-up Information * User View - by Mike Allen * Brain Stem rotator - A true programming challenge? * 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: "Software Innovation Halted??" By: Albert Dayes ------------------------------------------------------------------------- A database search system that retrieves multimedia information in a flexible, user friendly system. The search system uses a multimedia database consisting of text, picture, audio and animated data. That database is searched through multiple graphical and textual entry paths. The above is part of the abstract on Compton's NewMedia (a leader in multimedia development and distribution) new software patent number 5,241,671. Software patents have been used by several small companies as essential method to fight large companies. One such company, STAC is fighting Microsoft over the use of data compression technology in MS-DOS v6.x. This technology allegedly infringes on two patents held by STAC. This one is supposed to go to trial by early 1994. But there is also the other problem which recently exploded on the scene with Compton's NewMedia. As defined in the abstract above, which if upheld, anyone that uses a similar technique must pay a licensing fee to Compton's NewMedia. This has brought complaints and threats of a boycott from all over the computing community. In addition Compton sent letters to quite a few developers telling of new licensing and distribution "opportunities." In a nutshell, every database that is not searched using text is subject to Compton's NewMedia's patent. Therefore, a developer must pay licensing fees to Compton's NewMedia. Depending on the way that this patent is interpreted in court, developers may have to pay licensing fees just to avoid infringing on this software patent. Some see this as stopping software innovation while others think this is a necessary defense mechanism against big companies. If this is interpreted the way Compton's NewMedia wants it to be, software development will become a legal nightmare. All companies great and small will flood the US Patent office with software patent requests. The other major issue is the amount of licensing fees a developer will have to pay just to get a product to market. In addition to that if a developer knowingly infringes they can face harsh penalties, in the courts. One organization dedicated to dealing with such issues is the League for Programming Freedom. Their view is generally anti-software patents. League for Programming Freedom 1 Kendall Square #143 PO Box 9171 Cambridge MA 02139 USA [In: lpf@uunet.uu.net] I have not found an organization dedicated to promoting software patents, however. Regardless of the outcome this subject (of software patents) will have a huge impact on all software developers present and future. We will keep you posted on future developments on this explosive topic. -- Albert PS: Anyone who would like to send feedback 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 /**********************************************************************/ Mike Allen ... After graduating from Niles Township High School in Skokie, Illinois, I spent two years at Grinnell College, a small liberal arts college in Iowa, studying Physics and Math. Finding that football, women and beer left me too little time to maintain the grade point average necessary for my scholarship I transferred to the Missouri School of Mines in Rolla, Missouri, where I was graduated with a Bachelor of Science degree in Electrical Engineering in 1962. I went to work for Westinghouse in the Field Engineering and Services Department of what is now the Electronic Systems Group as an Assistant Engineer at the whopping salary of $560/month. Thirty years later I am still with the same department, although I am now a Fellow Engineer and make somewhat more money. My career was interrupted for one year when I returned to my alma mater to earn a Master of Science degree in Engineering Administration in 1967. (How do you administer engineers? With a very large stick!) /**********************************************************************/ What is in this issue of AEO-PJ and new in the Atari market By: Albert Dayes /**********************************************************************/ The Atari Jaguar (64-Bit Interactive Multimedia Entertainment System) has been released in predetermined markets. Everything seems to quite positive for the most part on the Jaguar's introduction. Full US National and European Rollout is schedule for 1994. For more details on Jaguar see the following issues of AEO (Jaguar Special Edition; AEO volume 2, issues #14, #20, #21 and #22; and future issues of AEO). One should notice the great increase in message traffic on the online services, as well. Also GEnie's ST RT has programming RTCs (Real Time Conferences) on the first and third thursday of the month. Each conference is captured and uploaded to the library for later viewing. This is useful in case one cannot make the conference. Two RTCs are currently in the library for downloading. Eric Goodman (former GFA columnist) has left due to job conflicts. If anyone is interested in writing about GFA basic programming, send E-mail to the editor. Also Kris Gasteiger and Ron Whittam have become regular columnists for AEO-PJ. The DSP series has been delayed for a bit, since BrainStorm is working on Jaguar software! /* Oregon Research announces development tool updates */ Modern Atari System Software - The Book. This is a new 256 page HiSoft book covering the newest system software by, and for, Atari. Includes the latest information on TOS 4.x, MultiTOS, SpeedoGDOS, and MINT. This incredibly useful tool also contains information specific to our line of development tools. Also available from Oregon Research are Motorola's 68000 Assembly and 56K DSP Programmers Reference Manuals: We have been very busy working on upgrades for all of our professional development tools. The upgrades add complete Falcon, Mint, MultiTOS, and SpeedoGDOS documentation and library support for all new operating system calls in TOS 4.x. Devpac 3 and HiSoft Basic 2 maintenance upgrades are ready now. The Devpac 3 upgrade includes all new Falcon compatible tools and libraries and a handy reference card. The HiSoft Basic 2 upgrade includes all new Falcon compatible tools and libraries and a 32 page manual addendum. Lattice C 5.6 upgrade adds complete Falcon, Mint, MultiTOS and SpeedGDOS documentation and library support for all of the new operating system calls in TOS 4.x. In addition the upgrade includes: *) Completely rewritten documentation consolidating the previous five manuals into 3 magnificent volumes of the best documentation available for programming your Atari computer. *) Falcon enhanced versions of the compiler and debugger. *) Source level debugging *) Code Profiler. Find out where your code is spending its time so you can optimize it's performance. *) Library Archiver to assist you in building your own libraries. *) DRI to Lattice C object file converter *) True UNIX Make utility for maintaining complex projects *) LCC Compiler driver for use with Make *) Includes Modern Atari System Software book Oregon Research now carries and supports SuperBase Professional v3.02. Special pricing on all products, is available until December 31, 1993. Oregon Research 16200 S.W. Pacific Hwy Suite 162 Tigard, OR 97244 (503) 620-4919 (503) 624-2940 (fax) /* NEW SYSLAW BOOK! MASSIVELY REVISED AND EXPANDED! */ SysLaw, Second Edition: The Legal Guide for Online Service Providers by Lance Rose, Esq., and Jonathan Wallace, Esq. SysLaw provides BBS sysops, network moderators and other online service providers with basic information on their rights and responsibilities, in a form that non-lawyers can easily understand. Subjects covered include the First Amendment, copyrights and trademarks, the user agreement, negligence, privacy, criminal law, searches and seizures, viruses and adult materials. SysLaw not only explains the laws, it gives detailed advice enabling system operators to create the desired balance of user services, freedom, and protection from risk on their systems. SysLaw is available from PC Information Group, 800-321-8285 or 507-452-2824, and located at 1126 East Broadway, Winona, MN, USA 55987. You may order by credit card or by mail. Price is $34.95 plus $3.00 shipping and (if applicable) sales tax. Price is subject to change after January 1, 1993. For additional information, please contact publisher Brian Blackledge at 800-321-8285. /* Software Development: A Legal Guide */ by Attorney Stephen Fishman A reference for people in the software industry, this book (with disk) explores the legal ins and outs of copyright, trade secrets and patent protection, employment agreements, working with independent contractors and employees, development and publishing agreements and multimedia development. Sample agreements and contracts are in included on disk (dual PC/MAC format). Nolo Press 950 Parker Street Berkeley, CA 94710 USA (800)-992-6656 (orders) (510)-549-1976 National 1st Edition * ISBN 0-87337-209-3 /* 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 2: Computers do *exactly* what you tell them to -- In the last issue, I went over why assembly language is important, and I briefly described CPU registers and what instructions look like. This time I'll talk more about addressing modes, tell a little about some instructions, and we'll do a short "Hello world!" program. //// Addressing Modes There aren't all that many instructions for the 68000; there might seem like a lot, until you realize most are just variations of others. I'll cover the most important ones later in this article, but first you need to understand "addressing modes". These are just the different ways that the 68000 gets data to use in instructions. Here's a list, along with examples. //// Data Register Direct This just means a data register is used for the data, either source or destination. You specify this mode simply by naming the data register, for example: move.l d0,d1 ; Copy the contents of d0 to d1. //// Address Register Direct This just means an address register is used for the data, either source or destination; this mode is indicated by naming the address register. For example: movea.l a0,a1 ; Copy the contents of a0 to a1. //// Immediate This indicates a value is stored as part of the instruction. You can only use this as the source of data. You specify immediate addressing by using a # symbol. Here's an example: move.w #3,d0 ; Copy the number 3 into d0. //// Address Register Indirect This addressing mode uses the contents of an address register to indicate a memory address; the contents of that memory address are the actual data used. You show you want to use the register as an address (or pointer) by surrounding it with parentheses, as in this example: move.w (a0),d0 ; Copy memory (address in a0) to d0. //// Address Register Indirect with Postincrement This mouthful is just like address register indirect, with one small difference. After the data is fetched from (or written to) memory, the address register that held the address is incremented. That is, it moves to the next address. If you read or write a byte, the address register is incremented by one. If you read or write a word, the address register is incremented by two. And if you read or write a long word, the address register is incremented by four. You specify this addressing mode by surrounding the address register with parentheses and adding a + symbol to it, like this: move.l (a0)+,d0 ; Copy memory (address in a0) to d0. ; a0 then gets 4 added to it. //// Address Register Indirect with Predecrement Like the previous addressing mode, this one is like address register indirect. This one _subtracts_ the size of the operand _before_ reading or writing memory. This mode is used extensively for stack operations (see below). You specify it with a minus sign (-) followed by the address register in parenthese, as shown: move.w d0,-(a0) ; Copy d0 to memory. Subtract 4 from ; a0 first, then use it as the memory ; address. Note: if you use this mode, or the postincrement mode, with a7 (the stack pointer) and you try to use a byte-size value, the stack pointer will always be incremented or decremented by two instead of one. This keeps the stack pointer at an even address. //// Address Register Indirect with Displacement Yet another variation on the address register indirect, this one uses the address register's contents as the memory address, but also _adds_ another number to it before using it. It does NOT change the address register. You indicate the displacement (which can be any number from -32,768 to 32,767) by listing the number, followed by the address register in parentheses. Here's an example: move.w 2(a0),d0 ; Copy memory from address (address is a0+2) to d0. ; Do NOT change a0. //// Address Register Indirect with Index This is similar to address register indirect with offset. The difference is, not only do you add a fixed number (this time in the range -128 to 127), but you can add the contents of another register - without changing that other register or the address register. What's more, you can use either the entire register, or just the low 16 bits. Specify this mode like this: move.w -2(a0,d1.w),d0 ; Copy memory (address is a0+d1.w-2) ; to d0. Don't change a0 or d1. Remember that you can use .w or .l for the second register. //// Absolute Long Address This is similar to the Immediate addressing mode, except that you provide the _address_ of the data, rather than the data. If you are referring to an address within your own program, you use a label (since you don't know the address); the assembler and TOS each do their part to make sure every time your program is run, these references in your program point to the correct address. You specify absolute long addressing by simply giving the label name (for addresses inside your program) or the actual address (for addresses outside your program). Here's an example: move.l x_pos,d0 ; Copy memory (x_pos is the name of ; the address) into d0. //// Instructions That's most of the addressing modes; there are others, which I will cover when they're needed, but those listed above are the most common addressing modes used. In a moment I'm going to list the instructions used in our "Hello world!" program. There aren't very many. Next month I'll cover more instructions, and show how they're used to piece together programs that actually do something. move.s source,destination This instruction moves data around. More accurately, it copies it from one place to another. You can use any of the addressing modes I listed above for either source or destination. You should replace the ".s" with .b (to copy a byte), .w (to copy a word), or .l (to copy a long). This is the most common instruction of all, which is why it's so flexible. trap #n This instruction calls one of the "traps". With TOS, these traps are used as the method for calling parts of the operating system. This is just the entrance; actually telling TOS to do something always requires a bit more preparation. n is a number from 0 to 15; 1 is for GEMDOS, 2 for VDI and AES, 13 is for BIOS, and 14 is for XBIOS. Don't worry, I'll explain more when it's needed. add.s source,destination This instruction adds the contents of the source to the destination. As with move, this is a common instruction, so there aren't too many restrictions on it. You can use any addressing mode, as long as either source or destination is a register; if your source is immediate data, you can also use any addressing mode for the destination. (There are some variations on this instruction, but your assembler will usually choose the right one for you.) With three instructions, it wouldn't seem possible to do much, but these three instructions give us access to the operating system - so a lot can actually be done. We have enough, now, to say "Hello world!" Here's the program: -=-=-=- CUT -=-=-=- * Hello world! * Some Assembly Required, Article 2 * First, display text on the screen. move.l #text,-(sp) ; Put the value text (an address) ; on the stack. move.w #9,-(sp) ; Put the value 9 (the function ; number for cconws) on the stack. trap #1 ; Call GEMDOS. In this case, cconws ; writes a string of text to the ; screen, stopping when it gets a ; null (0) byte. add.w #6,sp ; We pushed 6 bytes onto the stack; ; normally we'd move them off, but ; since we don't need the information ; we can just move the stack back to ; where it was. * Now wait for a keypress. move.w #8,-(sp) ; Put the value 8 (the function ; number for cnecin) on the stack. trap #1 ; Call GEMDOS. cnecin will get one ; keypress, waiting for a keypress ; if one hasn't already been pressed. add.w #2,sp ; We pushed 2 bytes; move the stack ; back to where it was. * Now exit the program. move.w #0,-(a7) ; Put the value 0 (the function ; number for pterm0) on the stack. trap #1 ; Call GEMDOS. The pterm0 function ; will exit our program, so it won't ; come back. * Data used by our program. text dc.b 'Hello, world!',0 ; The dc.b means "declare constant, ; byte-size". Here we tell the ; assembler to place the text string ; in our program, and refer to its ; start with the label "text". -=-=-=- CUT -=-=-=- That's all! Next month I'll go over this program in greater detail; I'll also explain how to go around in circles. See you then! /***********************************************************************/ C Programming Column By: Albert Dayes /***********************************************************************/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-= //// Where to find new Ideas =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Software development is a very enjoyable process and seeing software from other developers is very enlightening. At the recent Comdex show there was a huge amount of new software announced and demonstrated. After seeing 12+ different word processors one would think they are all the same, but they are not. Taking a closer look, you can see how different parts of the program interact with one another. It's these subtle differences that helps generate ideas for your own software projects. There are many different places to look for new software. Arcades, software stores, online services, etc., are just some of the ways to examine different approaches to problem solving. In addition to looking at software itself, reading provides another great method to discover new techniques. The C Users Journal (October 1993, pages 113-118) had an excellent article on JPEG. In addition to the article there is a disk (#381), in the C Users Group library that can be purchased. One thing I like about C User Journal is, they mention any platform regardless of what platform it is. A short quote from the article illustrates this point. The JPEG software distribution source code is written entirely in C. You can compile it on many platforms including IBM compatibles, Amiga, Macintosh, Atari ST, DEC VAX/VMS, CRAY YMP, and most Unix platforms. Supported Unix platforms include, but are not limited to, Apollo, HP-UX, SGI Indigo, and SUN Sparcstaion. The make system even includes a utility to covert the ANSI-style C code back to the older K&R sytle. Another intersting book that I recently came in contact with is called "Writing Solid Code", by Steve Maguire. Its a book describing the techniques that Microsoft uses for developing bug-free C programs. It will be interesting reading for sure. It's published by Microsoft Press, ISBN 1-55615-551-4, and retails for $24.95. It include a case study of Application Software development at Microsoft, with emphasis on MS Excel (spreadsheet). Recently I purchased a BEST SPS (Standby Power System) for my Atari ST. There is software available that allows one to monitor the SPS system via the serial port, on the computer. Unfortunately it is only available for the IBM PC, Novell Networks and UNIX systems. So I did the next best thing by asking for the source code. Since the worst they can do is say no, I had nothing to lose. Anyway, I ended up with UNIX C source code for free, which will be ported to the Atari, in the near future. =-=-=-=-=-=-= //// The Code =-=-=-=-=-=-= While walking around during Comdex, one cannot help but notice the slot machines. The video ones are of a particular interest. It seems like it would be a trivial program to write. You would never have to write the win portion of the code. It's as simple as, if win goto lose. To create a simple slot machine we need some variables, and several functions. #include #include #define WIN 1 #define LOSE 0 #define AEOPJ_ANSI 0 /* 1 = ANSI C and 0 = K&R style C */ #if AEOPJ_ANSI > 0 int main(void) #else main() #endif { int player; player = slot_machine(); if ( player == WIN ) printf( "You have won a C compiler of your choice!\n" ); else printf( "You lost!\n" ); return(0); } /* main() */ Now that we have a basic framework (main idea) of what we want to do, we need to create a new function. This new function will not have any inputs at all, but only one output. If a function has no inputs in ANSI C the word void is used in place of the arguments. Also function prototypes need to be placed near the top of the file as well. All functions as default return an integer value unless specificed to return a different value. The function can be of type void which returns nothing, to the calling function. #if AEOPJ_ANSI > 0 int slot_machine(void) #else slot_machine() #endif { int score; return( score ); } /* slot_machine() */ Within the slot machine we need to determine whether or not the player's score is a win or a loss. To do that we call the rand() function and then using a predermined value calculate a win or a loss. A modification will allow the number returned to be only a zero or a one. The function rand() produces numbers between 0 and 32768 but we need to reduce that to one and zero respectively. So we will divide RAND_MAX by two. With anything less than one half RAND_MAX being equal to a loss and anything equal to or higher is a win. RAND_MAX is usually equal to 32768 on many C compilers. score = rand(); if ( score >= (RAND_MAX/2) ) score = WIN; else score = LOSE; Also note the rand() is a psuedo-random number generator, so it is possible that values will repeat themselves. There is a way to make the numbers more "truely" random by using the function srand(). #if AEOPJ_ANSI > 0 int slot_machine(void) #else slot_machine() #endif { int score; score = rand(); if ( score >= (RAND_MAX/2) ) score = WIN; else score = LOSE; return( score ); } /* slot_machine() */ And the full program is listed below.... -=-=-=- CUT -=-=-=- #include #include /* <--- might not be necessary for K&R C compilers */ #define WIN 1 #define LOSE 0 #define AEOPJ_ANSI 0 /* 1 = ANSI C and 0 = K&R style C */ /* function prototype for ANSI C */ #if AEOPJ_ANSI > 0 int slot_machine(void); #endif #if AEOPJ_ANSI > 0 int main(void) #else main() #endif { int player; player = slot_machine(); if ( player == WIN ) printf( "You have won a C compiler of your choice!\n" ); else printf( "You lost!\n" ); return(0); } /* main() */ /*-------------------------------------------------*/ /* slot_machine() returns only two values: WIN or LOSE */ #if AEOPJ_ANSI > 0 int slot_machine(void) #else slot_machine() #endif { int score; score = rand(); if ( score >= (RAND_MAX/2) ) score = WIN; else score = LOSE; return( score ); } /* slot_machine() */ -=-=-=- CUT -=-=-=- The next issue will discuss the two different ways to pass arguements into functions. Also think about ways to modify the current program so that the numeric values returned are "truely" random. Also think about possible problems with the current code. /***********************************************************************/ Advanced Computing By: Carl Barron /***********************************************************************/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= //// Introduction to YACC //// (Yet Another Compiler Compiler) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I was going to give a simple Fortran format statement reader in C, but I accidentally destroyed the files. So I will begin an introduction to YACC instead. Yacc is a parser generator, written in C and producing a function yyparse(void) that parses input based on a language description. This language description is best described by first considering an import subset of the possibilities. This subset will be of the form The action part is what to do when the parser finds an instance of this rule. The rule is of the form : or the form | . The is a symbol defined by the rule, the colon a symbol for 'is defined as' and the is a concatenation of symbols for which there is a , called a non©terminal symbol or a symbol of the language we are parsing called a terminal symbol. A synonym for : {action 1} : {action 2} is : {action 1} | {action 2} The terminal symbols can be identifiers as in C or c character constants. The non terminal symbols have can be identifiers as in C. There is a syntax for the file describing this grammar. It is %{ initial C code , usually #includes, #defines and definitions of global variables, function prototypes and the like. It is C code. and ends with a %} This is followed by a bunch of yacc definitions many will be described as we go along. The first one is %token This is a whitespace separated list of terminal symbols that are not character constants. Others will follow as we describe yacc ... this section is terminated by a line containing only %%. The rules and actions follow this and are terminated by another line containing just %% or the end of file. If the rules section is terminated by a %% additional C code may be added to the end of the file. We are going to start with a simple language to define alert boxes in GEM. This is not the usual approach of calculators but should be more interesting. To describe this language is simple. It is a bunch of lines with keywords followed by white space and either numeric indicators, or quoted strings as will be obviously indicated by the keywords 'alert','icon','default','end' (without the quotes). Our first yacc example will do nothing but check the syntax of the input. If we get no output then the input is a valid description of an alert box. Here goes! %token ALERT ICON DEFAULT STRING BUTTON END %token NUMBER %token QSTRING %% alerts : alert | alerts alert ; alert : alert_strt alert_data alert_end ; alert_strt : alert_hdr ID ; alert_end : END ; alert_hdr : ALERT | error ALERT ; alert_item : ICON NUMBER | DEFAULT NUMBER | STRING QSTRING | BUTTON QSTRING ; alert_data : alert_item | alert_data alert_item ; %% #include yyerror(char *s) { fprintf(stderr,"%s\n",s); } main(void) { yyparse(); } The purpose of this little language will be to generate C code to create and display a list of alert boxes. The ID will be used to create part of a C function. The other terminal input will be used to create the rest of the form alert call. yyerror() is called whenever the parser finds a syntax error and error is used to synchronize the parser in the event of an error. The error ALERT line above will "eat" everything until an 'alert' is found. Allowing the checking of complete list of alert boxes without getting lost if we have errors in the code. The lexer for this simple example will be simple as well. The flex looks like this: %{ #include "ytab.h" /* created by yacc */ %} %x STR number [0©9]+ id [a©zA©A_][a©zA©Z0©9]* %% alert return ALERT; icon return ICON; default return DEFAULT; string return STRING; button return BUTTON; end return END; {number} return NUMBER; {id} return ID; \" {BEGIN STR;} [ \t\n]+ /***/ . return (int)(*yytext); [^\"\n]*\" BEGIN INITIAL;return QSTRING; [^\"\n]*\n BEGIN INITIAL;return QSTRING; We will also modify this as we go along. /***********************************************************************/ HARD CORE - Interview with Greg Kopchak developer of Photo Show By: Albert Dayes /***********************************************************************/ AD: What is your product for the Atari ST or Falcon030? GK: In July of this year we released Photo Show for the Falcon030. Photo Show allows you to mix true color graphics and digitized sound into a multimedia presentation on the Falcon030. For those that are not familiar with the Photo CD process, Kodak has made available the technology to have your slides or negatives digitized and stored on a CD-ROM disc. For about $20.00 a roll you can have your negatives or slides converted to the PCD format. The results are better than what you can do yourself with a $10,000 color scanner and are stored in a 24-bit 3048 by 2072 format on your CD-ROM. This means that using today's technology, very few users have the equipment to actually view images at this level. This also means your Photo CD images will not become obsolete in the future. AD: What prompted your interest in CD-ROM and Photo CD? GK: With the current crop of personal computers available, storage technology was not keeping up with data requirements. The more I read about CD-ROM, the more positive I was that it would become the new standard for data storage. At the same time, we were exploring the possiblities of doing a presentation manager for the Atari ST line. After exploring various hardware solutions for getting color images to the ST, we decided we had an idea whose time had not yet come (see file #24473, VBOOKSTE.LZH on GEnie). When Kodak announced the availability of Photo CD technology, we signed on with them as developers for Microsoft Windows. I was thrilled with the quality of imaging that a home user could achieve with the Photo CD process. Within a couple of weeks of releasing our PC product, Atari announced the Falcon 030with true color imaging and CD quality recording of audio. The time was now right for an Atari product. We called Atari and started work on Photo Show. AD: How long did it take to develop Photo Show? GK: The idea for Photo Show started back in January of 1992. By the summer of 1992 we were offering Photo CD to Spectrum conversions for the ST series (see file 24941, FOUNTAIN.ZIP on GEnie). By Christmas 1992, we had our first true-color Photo CD images up on a Falcon screen (see file #27297, DUCK.ZIP on GEnie). In July, 1993, we received a Kodak Photo CD license for the Atari line and released our Photo Show program (see file #30444, XMASDEMO.ZIP on GEnie). AD: What technical difficulties did you encounter and how did you overcome them? GK: Our biggest challenge was getting a reliable way to interface a CD-ROM drive with an Atari computer. As a lot of users are aware, MetaDOS had some problems that proved very difficult to work around. The release of MultiTOS and the XFS extended files system solved all of these problems. Our second challenge was aspect ratio. Depending on the video mode and monitor type, the aspect ratio of an image varied. Photo Show actually changes the aspect ratio of your image to match your video output by using three sets of viewing routines. Our third challenge was image format. At the time the program was written there was XGA format loaded with redundant information, a version of TGA that did not meet cross-platform standards, and not much more. The current 16 bit formats all seemed to use less than 16 bits of color. We chose to use a format called FTC for the program that was 384 pixels wide by 240 pixels high using 16 bits of color in Motorola format. We also let the program create PC standard TIF files in 24 bits, color EPS (Encapsulated PostScript) and a raw 24 bit format for those who like to tinker. If you display an image with a wide range of shades using Photo Show on the Falcon and then display the same image using Studio Photo, you will see a significantly better image with Photo Show and its native FTC format. AD: What programming language did you use? GK: Why not ask what program language didn't we use. The program was written in GFA on the ST, ported to Microsoft C 7.0 on the PC, and ported back to Laser C on the Atari. At this point, we ran into some real problems linking the Atari Photo CD ToolKit into our Laser C program. We ported the Laser C code to Lattice C. Damien Jones (DMJ) rewrote a few routines that were not up to speed in Devpac 3, and we tied the whole thing together with a GFA scripting module. Along the way, the only language we missed was Atari Logo. AD: What future enhancement do you plan for, or are you thinking about for future editions? GK: The future is TODAY. Within the next two weeks, we will be releasing Photo CD Pro. The list of new features is impressive. ù Your choice of 20 different fades and dissolves between images ù All effects are smooth even when running under MultiTOS (another bit of DMJ miracle code) ù 20 ways to fade to black ù 20 ways to fade to white ù The ability to overlay text on an image ù Support for the Corel series of Photo CD images in "Auto" shows ù Support for 24 bit Windows BMP format ù PCD images load twice as fast as our original release (more DMJ magic) ù The ability to view a true-color PCD or FTC image from the desktop by double-clicking on it. The first public showing of Photo Show Pro took place at the meeting of A.C.E. Saint Louis user group on November 20. Photo Show Pro will have a retail of $59.95. Current registered users of Photo Show can upgrade to the Photo Show Pro for $15.00 from Randall Kopchak, 2233 Keeven Lane, Florissant, MO 63031. We're looking forward to Damien Jones' long overdue update to View II. With all the features being added, it will be worth the wait. He just keeps on adding features. We plan a CD-ROM extensions module to View II that will include support for Kodak Photo CD as well as CD audio. One of Canada's finest programmers is working with us on the CD audio. I haven't seen the finished product yet, but it will include features not found on any other CD audio player for the Falcon. Want to create a family history, don't forget "It's All Relative". The Falcon version of Forecaster III now plots radar data with the extended Falcon color palette and outputs its text to a scrolling window. AD: Any problems with using CD-ROMs and Photo CDs on the Atari? GK: Connecting and using a CD-ROM drive on the Falcon is a heck of a lot easier than connecting a CD-ROM drive to a PC. No case to open, no DMA channels to set, no interrupts to set, no conflicts between cards. Installing a CD-ROM drive on the Falcon is as easy as plugging in a SCSI-2 cable, copying a file to your MultiTOS folder and renaming it, and rebooting your machine. It takes about 5 minutes if you don't know what your doing and about 2 minutes if you do. Most problems are created by users connecting the wrong type of cable to an unsupported CD-ROM drive. If you get the correct cable from a reliable dealer and connect it to a CD-ROM drive on our approved list, you will be up and running in no time at all. AD: Any hardware that you recommend or that is compatible with your product? GK: We include a special XFS driver fine-tuned by Michael Bernards, author of the Atari Photo CD ToolKit. The driver works with the Toshiba 3401 drives for standard 9660 format and multi-session Photo CD. It also works very well with the entire NEC MultiSpin series (NEC-38, NEC-55, NEC-74 and NEC-84) for standard 9660 format and single-session Photo CD. We have yet to be confirmed reports of other drives that will work with Photo Show and our included XFS driver. As these reports can be fully confirmed, we will be adding to the approved list. If you have tested a drive not on our list, leave E-mail to GREG on GEnie or Delphi or 70357,2312 on CIS. The driver works with both Photo CD's XA format and standard 9660 format CD rom discs. Unlike the version .3 XFS driver that was then current, it allows a user to switch CD rom formats between XA and 9660 without rebooting the system and solves a few other problems. AD: What are your plans for the Photo CD portfolio format? GK: Kodak has not yet released its Portfolio format to developers. As soon as they do, we will be looking at it as an ideal cross-platform format. If the Portfolio authoring format works as planned, a disc mastered for CD-I or Mac could be played on a Falcon or PC. Standards on all platforms are changing very rapidly. It's really to early to tell if the Portfolio format will be the scripting winner in the standards battle. Look for Kodak to release the Portfolio language after the first of the year. AD: Thank you. /***********************************************************************/ DABBLING IN PASCAL By: Kris Gasteiger /***********************************************************************/ Well, I confess, I screwed up! Last time, I presented a TOS program skeleton, and stated that there were no includes needed. That is not entirely true. The program I presented did not need any includes, but other TOS programs may. Put the following line at the beginning of your code (after the line "Program ******** (Input, Output);") if you need the routines in the AUXSUBS.PAS library. {$I Pathname\Auxsubs.pas} Where Pathname is the complete path to the folder you've stored Auxsubs.pas in. My hard disk committed suicide a while back, and in a puff of smoke, took the controller card, with battery backed up clock with it. My replacement hard disk does not have a battery backed up clock, so all my date stamps were coming up 1986, and all my time stamps were close to midnight. In my distress, I have been unable to find the AUTO program that prompts to set the time and date. I have not gotten into the habit of using the control panel to set them. Hence, the following program. NOTE: This program was written quickly, to solve an immediate problem. I have not included routines to check for valid input values. This means that if you enter bogus values, IT WILL CRASH or at least set your time and date to very odd values! On the other hand, you should find the BIOS input routines useful, they allow a lot of control over the TOS screen. (The text between the dashed lines is a complete Pascal program which I have compiled and run on my system.) ------------------------------------------------------------------------ Program Set_Time( Input, Output ); { This program is to be run from the AUTO folder. It will display the current system time and date, and ask if you want to change them. If you do not respond by striking a key within a few seconds, the program will abort, leaving the time and date unchanged. NOTE: I wrote this program to enable me to set my system clock when my hard drive died and took the battery backed up clock with it. This is a Q&D program, and no input checking is done. If you feed it bogus keystrokes, at best, your clock will be set wrong, and at worst you will crash your boot and have to start over. NOTE: COMPILE FOR TOS THEN CHANGE THE EXTENDER TO PRG! } {$I G:\LIBRARY\AUXSUBS.PAS} { Change the path for the include to reflect your own systems setup. } { ************************************************************************ } { Global declarations. } Type String8=String[ 8 ]; { Convenient size to hold the time or date. } Const Keyboard=2; { Bios Device code for the keyboard. } Var Key: Boolean; HrStr, MnStr, Time: String8; Hours, Minutes, Seconds, Month, Day, Year, Pause: Short_Integer; Time1: Long_Integer; { ************************************************************************ } { Bios Character-Oriented Device Input Status. Becomes true if a } { character is waiting on the specified device. } Function Bcistat( Device: Short_Integer ): Boolean; Bios( 1 ); { ************************************************************************ } { Bios Character-Oriented Device Input. Gets a character from the } { specified device. } Function Bconin( Device: Short_Integer ): Short_Integer; Bios( 2 ); { ************************************************************************ } { Bios Character-Oriented Device Output. Sends a character to the } { specified device. } Procedure Bconout( Device, C: Short_Integer ); Bios( 3 ); { ************************************************************************ } { Get input from the keyboard with which to set the date. } Procedure Get_New_Date( Var Month, Day, Year: Short_Integer ); Var M, Mm, D, Dd, Y, Yy: Short_Integer; MnStr, DyStr, YrStr: String[ 2 ]; Date_Str: String[ 8 ]; Begin Writeln( 'Enter todays date in MM/DD/YY format.' ); InverseVideo; WriteV( MnStr, Month ); { Take the integers passed to the procedure, } WriteV( DyStr, Day ); { and convert them to a string in MM/DD/YY } WriteV( YrStr, Year-1900 ); { format. } If Length( MnStr )=1 then Insert( '0', MnStr, 1 ); If Length( DyStr )=1 then Insert( '0', DyStr, 1 ); Date_Str:=Concat( MnStr, '/', DyStr, '/', YrStr ); Writeln( ' ', Date_Str, ' ' ); { Display the date string. } Curs_Up; { Using the VT52 commands, move the cursor } Curs_Right; { to the first digit of the date string. } M:=Bconin( Keyboard ); { Use the Bios keyboard calls, to control } Bconout( Keyboard, M ); { the screen input/output. This allows for } { formatted entry of the date. } Mm:=Bconin( Keyboard ); Bconout( Keyboard, Mm ); Curs_Right; D:=Bconin( Keyboard ); Bconout( Keyboard, D ); Dd:=Bconin( Keyboard ); Bconout( Keyboard, Dd ); Curs_Right; Y:=Bconin( Keyboard ); Bconout( Keyboard, Y ); Yy:=Bconin( Keyboard ); Bconout( Keyboard, Yy ); Curs_Off; Curs_Down; NormVideo; Gotoxy( 0, 4 ); MnStr:=''; { Clear the destination strings to avoid overflow. } DyStr:=''; YrStr:=''; Insert( Chr( M ), MnStr, 1 ); { Stuff the input characters into their } Insert( Chr( Mm ), MnStr, 2 ); { proper positions in the strings. } ReadV( MnStr, Month ); { then convert the strings to integers } { to be returned. } Insert( Chr( D ), DyStr, 1 ); Insert( Chr( Dd ), DyStr, 2 ); ReadV( DyStr, Day ); Insert( Chr( Y ), YrStr, 1 ); Insert( Chr( Yy ), YrStr, 2 ); ReadV( YrStr, Year ); Year:=Year+1900; End; { ************************************************************************ } { Takes keyboard input using the BIOS routines, modifies and returns the } { time in string form. } Procedure Get_New_Time( Var Time: String8 ); Var Hr, Hhr, Mn, Mmn, Ap: Short_Integer; Begin Curs_On; Writeln( 'Enter the correct time in 12 hour format.' ); InverseVideo; Writeln( ' ', Time, ' ' ); Curs_Up; Curs_Right; Hr:=Bconin( Keyboard ); Bconout( Keyboard, Hr ); Hhr:=Bconin( Keyboard ); Bconout( Keyboard, Hhr ); Curs_Right; Mn:=Bconin( Keyboard ); Bconout( Keyboard, Mn ); Mmn:=Bconin( Keyboard ); Bconout( Keyboard, Mmn ); Curs_Right; Ap:=Bconin( Keyboard ); Bconout( Keyboard, Ap ); NormVideo; Curs_Off; Writeln; Time[ 1 ]:=Chr( Hr ); { Stuff the string TIME with the input values. } Time[ 2 ]:=Chr( Hhr ); { This is a quick and dirty way of doing this. } Time[ 3 ]:=':'; Time[ 4 ]:=Chr( Mn ); Time[ 5 ]:=Chr( Mmn ); Time[ 6 ]:=' '; Time[ 7 ]:=Chr( Ap ); Time[ 8 ]:='m'; Curs_Down; End; { ************************************************************************ } { Takes the hour and minute short_integer values, and converts them to a } { string in HH:MM am/pm 12 hour format. } Procedure Format_Time( Hours, Minutes: Short_Integer; Var Time_Str: String8 ); Var Hour_Str, Minute_Str, Am_Pm: String[ 2 ]; Begin Hour_Str:=''; { Clear string variables. Not really necessary, but } Minute_Str:=''; { then, one never knows... } If Hours<12 then Am_Pm:='am'; { Put the time in 12 hour format. } If Hours>=12 then Am_Pm:='pm'; If Hours=0 then Hours:=12; If Hours>12 then Hours:=Hours-12; WriteV( Hour_Str, Hours ); { Convert it to a string. } WriteV( Minute_Str, Minutes ); If Length( Hour_Str )=1 then Insert( '0', Hour_Str, 1 ); { Format } If Length( Minute_Str )=1 then Insert( '0', Minute_Str, 1 ); { the string} Time_Str:=Concat( Hour_Str,':', Minute_Str,' ', Am_Pm ); End; { ************************************************************************ } { Main Program } Begin Pause:=10; Curs_Off; ClrScrn; Get_Date( Month, Day, Year ); Get_Time( Hours, Minutes, Seconds ); Format_Time( Hours, Minutes, Time ); Writeln( 'Your system date is: ', Month, '/', Day, '/', Year-1900 ); Writeln; Writeln( 'Your system time is: ', Time ); Writeln; Writeln( 'To change them, press any key.' ); Writeln( 'If you don''t wish to change them, wait.' ); Writeln( 'The screen will clear in a few seconds,' ); Writeln( 'and your computer will continue it''s' ); Writeln( 'boot process.' ); Writeln; Time1:=Clock; Repeat { Wait for a keypress, or time to run out. } Until ( Bcistat( Keyboard ) ) or ( Clock=Time1+Pause ); If Bcistat( Keyboard ) Then { If a key was pressed, get the new date } Begin { and time. } ClrScrn; Curs_On; Curs_Home; Get_New_Date( Month, Day, Year ); Get_New_Time( Time ); HrStr:=Copy( Time, 1, 2 ); { Extract info from TIME, } MnStr:=Copy( Time, 4, 2 ); { and convert it to integers } ReadV( HrStr, Hours ); ReadV( MnStr, Minutes ); If Hours=12 then Hours:=0; { convert to 24 hour format. } If ( Time[ 7 ]='p' ) or ( Time[ 7 ]='P' ) Then Hours:=Hours+12; Writeln( 'Setting system date.' ); Set_Date( Month, Day, Year ); Writeln( 'Setting system time.' ); { I'm not concerned about } Set_Time( Hours, Minutes, Seconds ); { total accuracy, so I don't } End; { mess with seconds... } End. ----------------------------------------------------------------------- I hope you find this understandable, and useful. If you need something a little more forgiving of input errors, try writing a procedure to verify valid inputs. Something on the order of... If X in Valid_Digits then... Where Valid_Digits is declared as... Var Valid_Digits_1s:=[ 0..9 ]; { For the ones digit. } Valid_Digits_10s:=[ 0,1 ]; { For the tens digit. } My use of SETs is rusty at best, so take the above with the proverbial grain of salt. Be sure your types match! NEXT TIME: A program skeleton for GEM, and a simple printer utility. FEEDBACK PLEASE! I can be reached on Compuserve [73637,2004] /**********************************************************************/ The Library by Scott Sanders of SDS Publishing /***********************************************************************/ This the first error list for the Atari Compendium which Scott kindly allowed us to run in AEO-PJ. Most of these structures and constants are based on the Lattice C compiler, but can be applied to other languages and compilers, as well. ==================== The Atari Compendium Errata Sheet #1 Nov 1st, 1993 ==================== The enclosed files represent the first errata sheet for The Atari Compendium. The file ERRATA1.TXT is an ASCII format version. The file ERRATA1.STW is an Atari Works format file. These files contain errors, omissions, and clarifications to information contained within the Compendium. My appreciation goes out to those people who graciously spent time sending me reports. If you reported an error and don't find it mentioned in here, one of three things may have happened: 1. The error you reported was typographical and did not affect the content. S.SANDERS2 on GEnie, S.SANDERS2@genie.geis.com over the Internet, or 71461,3645 on Compuserve. Our mailing address is: i I haven't been able to verify if it is an error, or what the proper correction is. 3. I have determined that it wasn't an error. Any further errors or comments you might have may be sent to me in Email a Software Development Systems 996 Redondo Ave. #404 Long Beach, CA 90804 310/430-0364 The Atari¾ Compendium by Scott Sanders Errata Sheet: 11/1/1993 1.3 (The 260/520/1040ST) The original ST computers contained a 320x200x16 mode, a 640x200x4 mode, and a 640x400x2 mode (not 640x400x1 as stated). 1.5 The MegaSTe has three serial ports, not two (one is shared with the LAN). The TT has a 1280x960x2 mode (not 1280x960x1). 1.6 The Falcon030 may have a 2.5" IDE drive installed, not a half-height drive as stated. 2.3 (Overview) GEMDOS derives its heritage from CPM 68k (not CPM 86k). 2.4 (GEMDOS Directories) Each sub-directory contains a directory named '..' which refers to its parent directory. In addition, each sub-directory contains a directory named '.' which refers to itself. The root directory contains neither of these files. 2.5 (Disk Transfer Address) The DTA structure is never defined. It is as follows: typedef struct _dta { BYTE d_reserved[21]; UCHAR d_attrib; UWORD d_time; UWORD d_date; ULONG d_length; BYTE d_fname[14]; } DTA; 2.17 (Signal Table - SIGABRT) The last sentence in this table entry should be "It is unrecommended that you catch this signal." 2.23 (GEMDOS Time & Date Functions) TOS 1.02 is incorrectly referred to as 1.2. Any references to TOS 1.2 should be considered references to TOS 1.02, likewise with TOS 1.04 or TOS 1.06. 2.38 (Dcntl() - FS_INSTALL entry) The structure fs_descr is defined without the portability macros. 'WORD' should be substituted for 'short' and 'LONG' should be substituted for 'long'. 2.51 (Fchmod() - table) The definition 'S_IRUSER' should be 'S_IRUSR'. 2.54-2.58 (Fcntl() - table) Several constant definitions for the cmd parameter of Fcntl() were omitted. The correct constants are (note: TIOCSTOP was documented, but the constant listed was incorrect): Definition Constant F_SETLKW 0x0007 TIOCSTOP 0x5409 TIOCGXKEY 0x540D TIOCSXKEY 0x540E PSETFLAGS 0x5404 PGETFLAGS 0x5405 PTRACEGFLAGS 0x5007 PTRACESFLAGS 0x5006 PTRACEGO 0x5008 PTRACESTEP 0x500A PLOADINFO 0x500C SHMSETBLK 0x4E01 SHMGETBLK 0x4E00 2.77-2.78 (Fsfirst() and Fsnext()) The DTA structure was never defined. See the note for page 2.5 above. 2.87 (Pexec()) Pexec() mode 6 is available as of 0.15. 3.4 (System Startup) The Fuji logo and hard disk spin-up delay occurs on all TOS versions past 2.06, not just 2.06 and 3.06 as is stated. 3.8 (Searching for a Cookie) The example code references the cookie structure members 'cookie' and 'value' as 'c' and 'v' rather than by their full name. 3.11 (_MCH cookie) The ST Book '_MCH' cookie contains a value of 0x00010008. 3.12 (FSMC cookie) The value field of the 'FSMC' cookie contains a pointer to a structure with information about the current version of GDOS as follows: typedef struct _gdos_info { ULONG gdos_type; UWORD gdos_version; WORD gdos_quality; } GDOS_INFO; The structure member gdos_type will be either '_FSM' for FSMGDOS, '_FNT' for FONTGDOS, or '_SPD' for SpeedoGDOS. The structure member gdos_version contains the currently installed version of GDOS with the major version number being in the high byte and the minor version being in the low byte. The structure member gdos_quality is initialized to 0xFFFF to indicate that printouts will be processed at the 'default' quality setting. Applications may change this value to 0x0000 to force GDOS drivers to output in DRAFT mode or 0x0001 to force GDOS drivers to output in FINAL mode. The variable should be restored to 0xFFFF after each print. 3.13 (BIOS Devices) The Mega STe supports devices 6, 7, and 9 as Modem 1, Modem 2, and Serial 2 respectively. Reliable use of BIOS serial devices other than the ST compatible device #1 on a Falcon030 requires the use of the TSR program "FPATCH2.PRG" (available from Atari Developer Support) or a TOS version > 4.04. 3.31 (Setexc() - table) The vector number for TRAP #1 (GEMDOS) is 0x21. 4.16 (The Serial Port) No mention was made of the Mega STe's serial ports. They bear the same functionality as serial ports on the TT except that there is no Serial 1 port on a Mega STe. The Falcon030 contains an MFP chip, however, it is not used to control any of the serial devices. 4.23 (Bconmap()) The Falcon030 requires "FPATCH2.PRG" or an installed TOS version greater than 4.04 for Bconmap() to work as expected. 4.xx (DSP functions) Most of the DSP functions contain an incorrect function opcode in the 'Binding' section of the function reference. The correct opcode for all DSP functions is properly listed in the 'Opcode' section, however. 4.33 (Dosound()) Dosound(-1) returns a pointer to the sound block of the currently playing sound or NULL if no sound is currently being played. This feature is broken in MultiTOS 1.00-1.08. 4.58 (EsetGray()) Mode 0 of EsetGray() causes the low 12 bits of a palette entry to be interpreted as a TT color. Mode 1 causes the low eight bits of a palette entry to be interpreted as a gray value between 0-255. 4.59 (EsetPalette()) The correct binding for EsetPalette() is: pea palette move.w count,-(sp) move.w start,-(sp) move.w #$54,-(sp) trap #14 lea 10(sp),sp 4.61 (Flopfmt()) buf should be a word-aligned pointer to a buffer large enough to hold one complete track (not sector as stated). 4.74 (Kbrate()) The correct binding for Kbrate() is: move.w rate,-(sp) move.w delay,-(sp) move.w #$23,-(sp) trap #14 addq.l #6,sp 4.80 (Offgibit()) Offgibit() bit #7 toggles SCC A between the Serial 2 and LAN ports on a TT. 4.81 (Ongibit()) For each bit of mask that is set, that bit will be toggled. 4.86 (Rsconf()) Rsconf() with a speed parameter of -2 will return the last set baud rate on TOS 1.06 or TOS 1.04 with "TOS14FX2.PRG". 4.92 (Setscreen()) If any parameter of Setscreen() is -1, then the value is left unchanged. 4.94 (Sndstatus()) Sndstatus() is available when bit #2 of the '_SND' cookie is set. 4.96 (Soundcmd() - table) The sample rates generated by using a TT compatible prescale value with SETPRESCALE are incorrectly identified in MHz rather than KHz. 4.97 (Supexec()) The function pointer taken by Supexec() was not properly prototyped. Supexec() takes a pointer to a function accepting no arguments and returning a LONG. 4.99 (VgetRGB()) VgetRGB() is available when the '_VDO' cookie contains a value of 0x00030000 or higher. 4.100 (VsetMask()) The opcode for VsetMask() is 92 (0x5C). 4.101 (VsetMode()) Vsetmode() should be VsetMode(). In addition, a value of -1 for the mode parameter will return the current mode setting. 5.10 (The IKBD Controller - Kbdvbase()) The chain of events that occurs when an IKBD event is generated is incorrectly documented. When an interrupt occurs on either 6850 chip (IKBD or MIDI), the following chain of events happen: 1. The system interrupt handler installed in MFP #4 is called. This routine determines which 6850 caused the interrupt. 2. If the MIDI 6850 caused the interrupt, midisys() is called immediately. midisys() checks the MIDI control register for either an error condition or a data byte. If a data byte is available, it is placed in the low byte of d0 and sent to midivec(). If an error occurred, vmiderr() is called. 3. If the Keyboard 6850 generated the interrupt, ikbdsys() is called immediately. The ikbdsys() handler checks for an error condition or the availability of a data byte. If an error condition exists, vkbderr() is called. Otherwise, the ikbdsys() handler reads data byte(s) as necessary to form a complete 'packet' depending on what generated the interrupt (joystick, mouse, or keyboard). 4. If the ikbdsys() handler receives a keyboard make or break code, it handles the packet internally. Otherwise, the address of the packet is passed to statvec(), mousevec(), clockvec(), or joyvec(). Handler vectors may be altered by modifying the structure whose address is returned by Kbdvbase() or by using Mfpint() as appropriate. 5.22 (Falcon030 Video Modes) The Falcon030 is capable of producing a wide variety of video modes. The table represents those accessible from the Desktop only. 6.5 (Applications) The sample code contains an error. Replace the lines: if(_AESglobal[0] == -1) menu_register( ap_id, menu_title); with: if(_AESglobal[1] == -1) menu_register( ap_id, menu_title); 6.30 (The Desktop Window) Calling wind_get( 0, WF_WORKXYWH, ...) will return the size of the desktop work area minus the menu bar (not WF_PREVXYWH as stated). 6.37 (_aes) The _aes binding should list the arrays _addrin and _addrout as being of type '.ds.l', not '.ds.w'. 6.51 (appl_init()) appl_init() may return a value of -1 which indicates that the AES failed to initialize the application. GEM applications may not make any AES or VDI calls unless appl_init() succeeds. 6.53 (appl_search()) The type parameter will be filled in with the value 10 to indicate the current system shell. 6.53 (appl_tplay()/appl_trecord) These functions require a patch (available from Atari) to work under TOS 1.0. 6.59 (evnt_button()) evnt_button( 0x101, 0x03, 0x00, ... ) may be used to wait for either the left or right mouse button. This method works with evnt_multi() as well. 6.65 (evnt_mesag() - table) The AC_OPEN message contains the menu identifier returned by menu_register() in msg[4]. msg[3] is unused. 6.73 (form_alert()) Each line of an alert may be as many as 30 characters long (not 40 as is stated). 6.99 (menu_attach()) If you remove a menu with menu_bar(), all attachments are cleared and must be reset upon reenabling the menu. The MENU structure is missing a member. It should be defined as follows: typedef struct _menu { OBJECT *mn_tree; WORD mn_menu; WORD mn_item; WORD mn_scroll; WORD mn_keystate; } MENU; mn_keystate is unused with menu_attach() but is used to return the current keyboard state in menu_popup(). 6.124 (rsrc_rcfix()) rsrc_rcfix() is available as of AES version 4.0 and higher. 6.136 (shel_read()) The last sentence of the 'Parameters' section should be: "The first BYTE of the command line indicates the length of the string which actually begins at &tail[1]." 6.138 (shel_write() - table) shel_write() mode 1 should have a wisgr paramater of 0 to launch a TOS application or a wisgr parameter of 1 to launch a GEM application. 6.145 (wind_create() - table) The SMALLER attribute shows the correct mask but an incorrect bit. The correct bit is 14. 6.156 (wind_update()) The first sentence of page 6.156 should read: As of AES version 4.0, you may logically OR a mask of 0x0100 to either BEG_UPDATE or BEG_MCTRL. 7.4 (VDI Device Identification Numbers - table) The "MEMORY.SYS" driver should always be assigned to device #61. 7.35 (v_clswk()) v_clswk() closes a physical workstation. 7.60 (v_opnvwk()) v_opnvwk() opens a virtual workstation. 7.113 (vqt_name()) As of SpeedoGDOS version 4.20, this call will return the a modified font index for GDOS bitmap fonts to avoid conflicting with outline font indexes. The index will be added to 5000 for bitmap fonts. 11.13 (Illustration) The version of Pagestream shown is actually 2.2, not 2.1. 11.15 (The File Menu) If a menu item 'Recall' appears, it should appear between the 'Open' command(s) and 'Save' command(s). 11.23 (Application Software) The '_IDT' cookie does not contain any information that could be used to determine a nation's currency symbol. Use the '_AKP' cookie if present (or the OSHEADER if not) to determine the country for which this version of TOS was compiled (and thus the correct symbol). Applications (like entertainment software) should place any data/configuration files in a sub-directory of the application folder. Only directly reveal those files which the user may have to launch or manipulate. B.6 (Memory Map) The SCC vectors are present on a Mega STe. B.7 (System Variables) The availability of system variables depends on the installed TOS version, not the computer as might be implied by the layout of the table. The columns next to system variables were shaded based upon the release of TOS which is most often associated with that computer as follows: Computer TOS Version ST 1.00 or 1.04 Mega ST 1.02 STe 1.06 Mega STe 2.0x TT030 3.0x Falcon030 4.0x B.15 (_longframe) This system variable is valid on an ST as well (it will simply contain 0). B.15 (kcl_hook) This vector is jumped through with the keycode contained in the low byte of d0. B.16 (0x00E00000) The operating system ROM's moved to this address as of TOS 1.06. B.16 (0x00FC0000) This block of memory extends to 0x00FEFFFF, not FF7FFFF. The memory between 0x00FF0000 and 0xFF7FFF is reserved for the operating system. B.30 (MFP) The MFP is present on a Falcon, however it is not used for serial communications. C.6 (Image Compression) .IMG files do not always contain a vertical replication count at the beginning of every scanline. /**********************************************************************/ PERIODICALS By: Albert Dayes /**********************************************************************/ There are several interesting periodicals that will be discussed this month. The first is a book on optimization, the second is a magazine called Software Development and the last one is a book, on user interfaces. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= //// Large Problems, Small Machines =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= In computing there is always the problem of very large problems. These problems almost always exceed the memory capacity of a particular machine. To solve the problem one has to resort to other method such as: a) solve only part of the problem at a time in memory b) use virtual memory c) optimize the code This book deals with little techniques to generate the best performance for solving any given problem. Unlike other books on optimization, this one does not go into the endless depths of mathematical theory to prove that the given method works. It demonstrates each aspect of optimization with a real world program. Large Problems, Large Machines: Transforming Your Programs with Advanced Algorithms also discusses the algorithm in detail before even touching the code. The code is explained section by section which makes it very easy to follow. In addition the entire C source code listing is included in the book, as well. Some of the key features in the book include the following: *) Shows how various programming optimization techniques are interrelated and cannot be approached in isolation. *) Gives special attention to optimization techniques for programs that make heavy use of input and output. *) Shows how most optimization improvements are the result of incremental changes instead of major ones. This book is written for the IBM PC where the 640K memory limit of MS-DOS is always a problem. Even though it is written for the PC it can be easily applied to the Atari platform, or any computing platform for that matter. This book deals not only of "How," but of "Why" and "When." Also over 98% of the source code is in C with a tiny portion in 80x86 assembly. This does not distract from using the ideas in any programming language, however. When one reads many other books on the subject, the algorithm is discussed in general terms on the first page and then a "nightmare" follows. This nightmare is in the form of a long, detailed, nasty mathematical proof. In most cases this is not a problem if you have a background in math. But many times they skip steps that they assume the reader is already familiar with. And they always end up with that wonderful phrase... "and the rest of this proof is left as an exercise for the reader." This book DOES NOT have any mathematical proofs to wade through. Just straightforward discussions of real world problems and how to optimize for them. It is very interesting how just using some simple steps outlined in the book one can make a large increase in the overall speed of your own programs. Also the discussion of the developer tools in improving optimization is a rare treat. Below is a brief outline of the chapters in the book: Chapter 1: Let's Get Small (and Fast): Introduction to Optimization Chapter 2: Hash, Cache, and Crunch: A Supermarket Price Lookup System Chapter 3: Strips, Bits and Sorts: A Mailing List System Chapter 4: Cn U Rd Ths Qkly? A Data Compression Utility Chapter 5: Free at Last: A Customer Database Program with Variable Length Records Chapter 6: Mozart, No; Would You Believe Gershwin? The last chapter deals which the characteristics of all optimizations listed. These include file access time reduction techniques, data compression techniques and thoughts on the quantum file access method. In addition it gives some thoughts on the future and some suggestions for approaching problems in general. Included is a table of contents, index and a table of figures. The table of figures is very useful if one wants to get directly at the source code for any given algorithm. With regard to the C source code, all of it listed in the book. If one does not want to type all the source code in by hand, there is a diskette available for $29.95. This is one of the best books on the subject of optimization and the author, Steve Heller is very accessible on Compuserve. It was in my wanderings on Compuserve that I found out about his book. Feel free to send him EMail if you want further information on his book. Large Problems, Small Machines: Transforming Your Programs with Advanced Algorithms. [ ISBN 0-23-339090-7 ] Publisher: Academic Press, Inc. 1250 Sixth Avenue San Diego, California, 92101-4311 USA (800)-894-3434 (United Kingdom Edition published by) Academic Press Limited 24-28 Oval Road, London NW1 7DX Author: Steve Heller (president) Chrysalis Software Corporation P.O. Box 0335 Baldwin, NY 11510 USA [CIS: 71101,1702] For ordering the source code disk in the USA call (800)-925-3864. Source code floppy disk: $29.95 + shipping. =-=-=-=-=-=-=-=-=-=-=-=-= //// Software Development =-=-=-=-=-=-=-=-=-=-=-=-= Software Development is a new magazine that came out in early 1993. It was originally Computer Language magazine, but it changed names after Dr. Dobbs Journal and Computer Language were included under the Miller-Freeman Inc. banner. Computer Language has been around for at least seven years prior to the name change. Larry O'Brien is still the editor of the magazine and the magazine's a bit different than the older Computer Language magazine. Its emphasis on the IBM PC and Compatible platform has been diminished to handle many other computing platforms. Also, PJ Plauger's no longer writes his "Programming On Purpose" column for the magazine. Dr. Plauger is editor of CUJ (C Users Journal) and he is currently concentrating all his efforts on the CUJ. Software Development discusses many interesting issues dealing with software development. O'Brien summarizes it very nicely.... To summarize, I'd say Software Development's mission is to provide the highest quality information that will give our readers the knowledge to produce large systems on time and under budget by selecting the appropriate products and practices. Even though the emphasis is on large software projects does not mean that the same ideas cannot be applied to smaller projects. It's very easy to scale down many of the ideas presented, to help produce a quality product. The October 1993 issue covered OOP (Object Oriented Programming) which includes C++, Smalltalk, Eiffel, etc. Even though the discussion of these products are included there are many other interested aspects to this issue. The Industry Watch column discussed the new face of technical support, basically dealing with ending free technical support and charging for each tech support contact. Karen Hooten's Programming by Profession discusses the Group Therapy. Discussion actually deals with professional programming societies like ACM (The Association for Computing Machinery) and the IEEECS (The Computer Society of the Institute for Electrical and Electronic Engineers) is very interesting reading. I am sure that some of you are already members of these organizations. [ Editor's Note: Here is a short list of some of the Special Interest Groups (SIG)s and publications available to ACM members. SIGCAT (Algorithms & Computing Theory) SIGADA (Ada programming language) SIGAPP (Applied Computing) SIGARCH (Computer Architecture) SIGART (Artificial Intelligence) SIGBIO (Biomedical Computing) SIGBIT (Business Information Technology) SIGCAPH (Computers & The Physically Handicapped) SIGCAS (Computers & Society) SIGCHI (Computer-Human Interfaces) SIGCOMM (Data Communications) SIGCPR (Comp. Persl. Research) SIGCSE (Computer Science Education) SIGCUE (Computer Uses In Education) SIGDA (Design Automation) SIGDOC (Documentaion) SIGFORTH (Forth) SIGGRAPH (Computer Graphics) SIGIR (Information Retrieval) SIGLINK (Hypertext/Hypermedia) SIGMETRICS (Measuring and Evalutation) SIGMICRO (Microprogramming) SIGMOD (Management of Data) SIGNUM (Num. Math.) SIGOIS (Office Information Systems) SIGOPS (Operating Systems) SIGPLAN (Programming Languages) SIGSAC (Security, Audit & Control) SIGSAM (Symbolic & Algebraic Manipulation) SIGSIM (Simulation) SIGSMALL/PC (Small and Personal Computing Systems) SIGSOFT (Software Engineering) SIGUCCS (Univeristy & College Computing Services) ACM Technical Publications: Communications of the ACM (monthly) Journal of the ACM (bimonthly) Computing Surveys Computing Reviews (monthly) Collected Algorithms Vol 1-5 (includes one year's supplements) Guide to Computing Literature (book) StandardView Interactions Multimedia Systems (bimonthly) No-Nonsense Guide to Computing Careers (book) Transactions on: Mathematical Software Database Systems Programming Languages and Systems (bimonthly) Graphics Information Systems Computer Systems Software Engineering and Methodology Modeling and Computer Simluation Letters on Programming Languages and Systems Networking (IEEE/ACM-bimonthly) For contact information see sources of information near the bottom of AEO-PJ. ] The November 1993 issue covers many different languages including 12+ Fortran compilers, the ADA 9X specification (which adds OO (Object Oriented) capabilities and other features to this language), and the artificial intelligence language, Prolog. Industry Watch takes a hard look at the benefits and pitfalls of CD-ROM technology, as it relates to programmers. And the most beneficial of all, an article on Software Testing. The testing article covers tools, concepts and techniques to make your testing process more productive. The December 1993 issue deals with Cyberspace development (Virtual Reality) toolkits. There are several freeware ones with C source code on internet which I was very surprised to read about. The Industry Watch deals with the current hot topic (see my editorial) on Software Patents. The Cover feature is called "Zero in on Zero-Width Segments." This deals with graphical applications where filling a zero-width polygon is a tremendous waste of computing time. One that I found very enjoyable is the article on naming conventions, "A Good Name is Hard to Find." This is especially useful when reengineering your old systems and building new ones. And the editorial was the very best article. "Demoware Reviews Hurt the Industry." If anyone has been following the new Symantec C++ compiler reviews one will already know what this editorial is about. It applies to all software and something we (as software developers) should always take into careful consideration. Basically there were several reviews in other magazines that made Symantec C++ the world's hottest development environment. Problem, the reviews were of demos or pre-released software not the final product. When the product was released developers were very disappointed. Some of the tools generated C code only and not C++. Many, many bugs were found that some developers believe meant that they were paying for the "honor" of being beta testers. Symantec is working very hard to correct the problems and hopefully they can recover some lost ground soon. Programming by Profession deals about time management. This is not the normal "Not enough time" type of article, but on the many different ways to continue your education, in computing. January 1994 issue has a great interview with Gene Wang. For those who use Pure C/Turbo C will have a special appreciation for him. He is the main person responsible for the Borland Turbo C/C++ product line. And since Pure C/Pure Debugger are based on this technology, its even more interesting. Mr. Wang jumped ship from Borland to Symantec recently (in 1992) to become vice president of application and development tools. The continuing legal battle between the two companies also makes this a very exiting interview. When Mr. Wang graduated from UC Berkeley in computer science he had nine job offers. Here is a short quote about some of his job offers. Whereas, I could have worked on games and Atari or things like that like that, Wang was offering me the oppertunity to work on operating systems and networking, which I thought was cool hardcore stuff. [ Editor's note: Gene Wang is not related to anyone at Wang Corp. ] Also an interesting discussion of configuration management on DOS machines. Even though its about DOS does not mean it can not be applied to the Atari platform. (Since they dicuss UNIX shells and Revision Control Software.) On the Atari side we have several UNIX shells like Gulam, Beckemeyer's C-Shell and MTC-Shell, etc. For revision control we are a bit more limited but GNU's RCS system is quite a powerful revision control system in its own right. The best part is that it comes with C source code. There is also a discussion of the UNIX make and imake utilities in another section of the magazine. The most important article, in my opinion, is "Software Process Improvement: A Case Study). It discusses the different models involved in software project management and maintence. This article is about nine to ten pages in length and is very good reading. Even though some of the article is explicitly for large scale projects does not mean one cannot glean some good ideas from it, to apply to your own projects. One thing many people forget is that software development involves solving problems. And the more information one has on tackling the problem the better off he or she will be. This is why reading many different type of programming and software development journals is very important. It's not so much as if one grasps all the concepts in the article as learning the little things. These little things become the building blocks that help make a software development project much easier in the long term. Software Development also hosts a forum on Compuserve where one can communicate directly with the editors, and writers. Source code from each issue is also online in addition to several BBSes around the world. This is but a very short preview of everything that Software Development can offer. Please take a closer look by going to your local bookstore and buying a copy of the magazine. There is quite a bit of good information one can glean from this magazine. Software Development 600 Harrison Street San Francisco, CA 94107 USA (415) 905-2200 [CIS: GO CLMFORUM] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= //// User-Interface Screen Design =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This book was originally called "Handbook of Screen Format Design" for the first three editions. The fourth edition changed the name of the book as listed above. This book deals with the designing a user interface. The early versions of the book assumed character based applications, which in most cases was due to the many mainframe and mini hosted applications. The newest edition deals with GUI (Graphical User Interfaces) like MS Windows, IBM's OS/2, UNIX X-Windows, and the Apple Macintosh. Even though Atari's GEM is not listed, many of the ideas can easily be applied to the Atari platform. This is a great supplement for the book, Atari Compendium by SDS publishing. While the Atari Compendium (reviewed in the previous issue of AEO-PJ) is very platform specific, User-Interface Screen Design goes into details about how the user interacts with the system. The first chapter gives an overview of the entire book and allows one to jump to specific chapters, without having to read from chapter one. The second chapter starts out with a very important idea that all computer users can relate to. I will give a short listing of chapter two highlights and expand when necessary. Chapter 2 - The System User Why People Have Trouble with Computer Systems Responses to Poor Design The Nature of the User Nondiscrentionary Versus Discretionary Use Novice Versus Expert Use Designing for Users - The Four Commandments Human Considerations in Design Perception Memory Visual Acuity Learning Skill Individual Differences Many of these ideas have been or probably will be covered in the User View column, but they are still very important ideas. It provides a good foundation to make a system much easier to use. The other chapters deal with important issues like data entry. The layout is usually only thought of as a cosmetic issue, but in reality it can have huge impact on how well the user can use the system. I will use the example on page 97 (Chapter 4 - Considerations in Screen Design) to illustrate this point. All of the following comes from this page. <---------------------------- cut here --------------------------------> Justification of single captions and data fields can be accomplished in several ways. These Include: A. Left-justifying captions; data fields immediately follow caption. Building: __________ FLOOR: ___ ROOM: _____ B. Left-justifying captions; left justified data fields; colon (:) associated with captions. BUILDING: __________ FLOOR: ___ ROOM: _____ C. Left-justifying captions; Left-justifying data fields; colon (:) associated with the data field. BUILDING: __________ FLOOR : ___ ROOM : _____ D. Right-justifying captions; left-justified data fields. BUILDING: __________ FLOOR: ___ ROOM: _____ Alternatives A and C are not recommended. Alternative A, left-justified aligned captions with data fields immediately following, results in poor alignment of data fields and increases the screen's complexity. It is more difficult to find data when searching data fields. Alternative C, while structurally sound associates the colon (:) primarily with the data field. The strongest associate of the colon should be with the caption. The two most desirable alternatives are B and D. Alternative B, left-justified captions and data fields, is the first approach illustrated in the guideline. Alternative D, right-justified captions and left-justified data fields, is the second approach illustrated in the guideline. <---------------------- cut here -------------------------------> All of the examples in this book follow the same pattern. With several items to choose from and then being told in detail which one is the better choice. For example, the alternatives A and D above are discussed in greater detail on the following pages. The same detail holds true in discussion of designing a screen based on paper input. For example, if one was designing a screen to type in tax or insurance forms, versus screens that are not based on paper input. In Chapter 10, the topic of Graphical Screens is discussed. Principles of good design, space relations, and avoiding visual clutter are part of this detailed discussion. This and proceeding chapters talk about fonts, text placement, pop-up boxes, and much more. Chapter 13 deals with a very important topic to all of us: the use of Color in Screen Design. It's very easy to tell when some colors just rake the eyeballs over hot coals. Playing around the colors on the Atari Desktop or a paint program one can discover this quite easily. Also included is a chart on which colors work well together. Much of this information is based on scientific research, and by testing them for yourself it is easy to see why. One page that was quite interesting was the one dealing with patterns. Page 410 has a large group of patterns that create vibrations. It's very interesting the effects that it has on people. Try staring (for a long time) at a large group of small dots and you will see what I mean. In addition the bibliography is almost 20 pages in length, so finding additional information on this subject should be trivial. Many references to the Apple Human Interface Guidelines and other documents should provide more than enough information for further study. This book makes very good reading and it's truely a good learning experience. It is highly recommended for anyone who needs to create a User-Interface for any product. Wiley-QED 170 Linden Street Wellesley, MA 02181 USA (800)-879-4539 (617)-237-5656 call for a free catalog book: User-Interface Screen Design author: Wilbert O. Galitz ISBN: 0-89435-406-X /***********************************************************************/ OBJECT::ATARI By: Warwick Allison /***********************************************************************/ Part 4: In this month's column, I've described some of the basics of my GEM++ library, which is a library of C++ classes that provide a high-level interface to the GEM environment. The GEM++ library is Freeware. Look for a file called "gem++19.zoo" in a Programming area of your favourite software site. Full sources to the library are provided, along the precompiled code, and an example program, with sources. //// Overview of GEM++ Classes GEM++ employs the model that objects in a system are created from, and within, other objects in the system. For example: dialog boxes are created from loaded RSC files; windows and menus are created in "activities" with which the user interacts; buttons, sliders and all kinds of other user interface components are created within dialog boxes; and this *all* happens within the scope of an application. The classes of objects are described in this column in an order suited to this hierarchical model. When programming with such hierarchical objects, it makes sense to have the class in the program mirror that structure. A description of such a class hierarchy is provided in this column, but first we use flat code example to introduce the essential classes of GEM++. //// The Essential Classes Every application program must have a GEMapplication object in existence before making *any* other GEM++ objects. This is simply achieved by declaring a GEMapplication at the beginning of main(): main() { GEMapplication spreadsheet; The next object an application needs is a GEMrsc, which is a loaded RSC file from which to create dialog boxes, window, menus, etc. A GEMrsc can be created by simply declaring one, passing the filename of the RSC file as a parameter to the creation: GEMrsc rsc("SPREAD++.RSC"); Now, if the application is just "dialogware" (Dialogware is an application that runs completely as a dialog box, rather than using windows. MultiTOS and ACC users will hate you.), you might create a dialog from that GEMrsc, by passing the GEMrsc, and the RSC index of the form as found in the ".h" file produced by your RSC editor (in this case, SHEET): GEMform sheetform(rsc,SHEET); This dialog box or form can now be run to interact with the user: sheetform.Do(); Using windows rather than dialog boxes is just as easy. Rather than the GEMform above, we use a GEMformwindow. But first, we must create a GEMactivity which a user-interaction session: GEMactivity activity; Simple. Now, we create the GEMformwindow in that activity in almost the same way as we created the form earlier: GEMformwindow sheetwindow(activity,rsc,SHEET); Now, normally an application's windows would open in response to a menu item being selected, but in this example, we can just do it at the start: sheetwindow.Open(); For anything to actually happen, we must run the activity containing the window. This activity handles all the moving, redrawing, and other window manipulations the user makes. To run the activity, we Do() it: activity.Do(); This call will return when some object in the activity terminates the interaction by returning EndInteraction in response to a user action (for example, selecting "Quit" in a menu). Unfortunately, we don't have any such objects in our activity, so it will loop forever. Oh well lets reboot. So, most applications will want to have a menu. To do this, we declare a GEMmenu in our activity, passing as usual, the RSC index of the menu: GEMmenu my_menu(activity,rsc,MENU_BAR); That's it. Of course, this is not a very interesting menu, since by default, nothing happens when a menu item is selected. So, we still don't have any way to end the activity\ldots reboot. Clearly, the default behaviours of these objects is not very interesting. However, using C++ class inheritance, we can override the default behaviour to something more interesting. For example, to make a new class of GEMmenu, which does interesting things when items are selected, we declare a derived class of GEMmenu: class MyMenu : public GEMmenu { public: // The constructor for MyMenu is just like that for GEMmenu, // except that it knows its own RSC index. // MyMenu(GEMactivity& activity, GEMrsc& rsc) : GEMmenu(activity,rsc,MENU_BAR) { } // We override the DoItem method to control what happens // when menu items are selected. DoItem is actually a method // of GEMform, but since GEMmenu is a derived class of GEMform, // we can override it just the same. // virtual GEMfeedback DoItem(int item, const GEMevent& e) { switch (item) { case QUIT: return EndInteraction; break; case OPENSHEET: sheetwindow.Open(); } return ContinueInteraction; } }; Notice how we open the sheetwindow when one of the menu items is selected, and end the activity by returning EndInteraction when the quite item is selected. "QUIT" and "OPENSHEET" are RSC indices. For this to be correct, the sheetwindow must be in the scope of the MyMenu class. This can be done by having the sheetwindow as a subobject of MyMenu, i.e.: class MyMenu : public GEMmenu { public: MyMenu(GEMactivity& activity, GEMrsc& rsc) : GEMmenu(activity,rsc,MENU_BAR), sheetwindow(activity,rsc,SHEET) { } ... private: GEMformwindow sheetwindow; }; Exactly the same approach as above can be used to make interesting things happened when objects in a GEMform or GEMformwindow are clicked, since they, like GEMmenu, are of type GEMform, and so have the DoItem method. Most forms need more than just the standard GEM buttons and edit objects though, so before we Do() a form, or Open() a GEMformwindow, we will usually want to add some special object in the form. Special objects are those objects objects other than he plain buttons, boxes, text, and icons which a RSC editor can build. For example, a slider in the form can be constructed from a box with another a box inside it, plus some arrow buttons. This is done by passing the form and the RSC indices of the components to the constructor for GEMslider: GEMslider dollars(sheetform,DOLLAR_KNOB,DOLLAR_RACK,DOL_LESS,DOL_MORE); or just the same for our "sheetwindow": GEMslider dollars(sheetwindow,DOLLAR_KNOB,DOLLAR_RACK,DOL_LESS,DOL_MORE); The GEMslider so created (called "dollars") is actually a number of GEMobjects, acting together to make the knob slide in the rack, and "less" and "more" buttons move the knob. The "arrow" buttons can be any GEM object: boxes with arrow characters, icons, buttons with text in them, etc. Similarly, the knob and rack can be any object (usually plain boxes). For a more detailed and thorough example, see the EXAMPLE.CC file in the GEM++ package! -- Warwick /************************************************************************/ Parsing the human equation by Ron Whittam /************************************************************************/ Some time back I attended a seminar where the keynote speaker started his first session with the comment, "I have never had an original thought." This admission seemed to absolve him of plagiarism or at least allowed him to plagiarize without being accused of it. The session that followed was a collection of other people's ideas that were very motivating when put together. I also collect ideas. I enjoy reading other people's ideas and thinking about them. As an eclectic there is always a chance that what one writes was probably written before. King Solomon the Wise once said, "There is nothing new under the Sun." In the computer community, collecting ideas is often a virtue; building on the work of others to improve what has been done. Currently, on GEnie's Atari ST roundtable, there is a topic and lively discussion of the development of another word processor. While there have been many serious contributions to this project, one person poised the question, "Why do we need another word processor?" The response was nearly unanimous, "to improve the way we do things." On the other hand, I can recall reading the documentation to a shareware word processor that stated "This is my last upgrade, this word processor is complete." While that statement seems arrogant, I perceive it to be a response to users who get tired of the countless upgrades a product goes through. I have also heard comments of irritation concerning these upgrades. The sum of the sentiment is that these nay-sayers think that a company should not release a product until it is complete. This is a wrong perception of the computer industry. For in the computer industry the only constant is change. While most are collecting public domain code, programming techniques, and algorithmic solutions; I find an interest in the development of human resources. I would like to share some of these ideas. In my experience, I have found that many computer owners buy the product they believe to be the best. There are some components that make a product the best that go far beyond the user interface and technical advancement of the product. While the programming and technical community often applaud technical feats in programming, this does not always impress the general public of computer owners. The qualities that impress a serious purchaser of computer software are something quite different. //// Sensible Cost-effective Solutions. In 1985, Atari's "Power Without the Price" was a key selling point for many computer buyers. Today, in the cutthroat PC market, keeping the product cost low seems to be a trend of the industry. Many companies seem willing to cut the cost of their expensive products to keep (or take) the market share. One may sell a product based on the time and intricacy of its code development. However, no matter how fancy the product, if the customer cannot see it as an equitable solution they will look elsewhere. The shareware marketing technique seems to provide a low cost solution that will provide the highest return to the developer. The overhead is low. Shareware is not directly marketed to the people who may use it. It is marketed passively and not, by nature, available in stores. On the other hand, retail marketing incurs up-front costs of packaging and distribution. If the product does not sell as expected, the programmer may never recoup the cost. Providing a quality product at a reasonable cost is important. //// Knows the language of their business. Programs that show the developer's knowledge of the business are really a plus. A financial product should correctly evoke terms such as debit, credit, balance, and double entry. Similarly, a word processing product should appropriately use the terms of font, type, layout, etc. Products that improperly use terms, even in ways that seem unimportant, will be dropped by a serious computer owner. Programmers that know the business they write programs for have developed some of the best products in the industry. //// Understands the general principles of their business. Some might contend that this is the number one component. It is very important to understand the general principle of "why" a business operates in a particular fashion. For instance a product that enables a cook to create recipes will require more then basic programming knowledge or skill. It will require the understanding of how a recipe develops and why certain ingredients must be mixed separately. //// Customer support spoken without computer industry jargon. Product documentation and customer support services should avoid using technical computer jargon. Terms like "coprocessor," "subroutine," "instruction set," or "virtual memory" would need to be translated to the average person who plans to purchase a computer or product. When explaining computer jargon, describe what you are talking about without lengthy discourse. This will make your program less threatening and more understandable. While often customer support takes on a technical nature, remember that if your customers had technical prowess, they would not be calling you. Be sure to use easily understood terms. Define or describe the hard to understand terminology. //// Treating customers with respect. There is nothing more irritating then being treated as ignorant. Just because a customer has a technical problem, does not mean they are not intelligent. Recently I heard this story: A client's computer video screen became blank while they were entering data. They called the customer support line for help. After checking the LAN, the support person said, "Everything looks fine, there is nothing wrong." Essentially the support person told the user that although she had a blank screen, she was silly to believe it was blank. While nontechnical people may not use the proper terms, they do know they have a problem. They may just need more information like "press the clear key" or they may need someone to replace the video screen. Do not insult them by saying there is no problem. If they did not have a problem, they would not have called you. Next month I will share some ideas on good phone support. Often times, it is how a person is dealt with on the phone that makes (or breaks) the product. That's it for this month. Got any ideas? Send them my way. I'm on the Internet at: r.whittam@genie.geis.com /***********************************************************************/ 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 | Sept 4, 1992 | Pure Pascal (German) (Turbo pascal 7.x compatible) A | 2.x | Interface, (resource file editor, with 3D icons) B | 3.10 | Devpac 3 (assembler) 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.14, 1989 | Prospero C G | 2.15, 1989 | Prospero Pascal for GEM G | 2.15, 1989 | Prospero Fortran for GEM G | 1.11, 1989 | 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 By Albert "Mr. Skullhead" Dayes /**********************************************************************/ ----------------------------------------------------------------------- bad example ----------------------------------------------------------------------- /* Calculate the area and circumference of a circle. */ main() { double circumference_of_circle, area_of_circle; /* circumference = 2 * pi * radius */ circumference_of_circle = 2.0 * 3.14 * 18.0; printf( "Circumference of a circle = %f\n", circumference_of_circle ); /* area of a circle = 1/2 * pi * (radius * radius) */ area_of_circle = 0.5 * 3.14 * 18.0 * 18.0; printf( "Area of a circle = %f\n", area_of_circle ); } /* main() */ ------------------------------------------------------------------------ good example ------------------------------------------------------------------------ /* Calculate the area and circumference of a circle. */ #define PI 3.14 #define CIRCLE_RADIUS 18.34 main() { double circumference_of_circle, area_of_circle; /* circumference = 2 * pi * radius */ circumference_of_circle = 2.0 * PI * CIRCLE_RADIUS; printf( "Circumference of a circle = %f\n", circumference_of_circle ); /* area of a circle = 1/2 * pi * (radius * radius) */ area_of_circle = 0.5 * PI * CIRCLE_RADIUS * CIRCLE_RADIUS; printf( "Area of a circle = %f\n", area_of_circle ); } /* main() */ These two programs are very close to doing the same, but there is a big difference. When one has a very large program using the same number over and over throughout can be a problem. If one has to go through the entire program and change 999 values slightly one can see that it's quite a workload. Also if one change is missed, the output of the program will be wrong. In addition to being wrong, it might go undetected for long periods of time. By using constants one creates a much better program to maintain. The first benefit is the value used throughout the program is only changed in one place rather than 999. The second being it makes the program more readible. With the program being more readible, finding and fixing errors can be made quickly. /*************************************************************************/ On The Networks /*************************************************************************/ Programming Conferences Courtesy of GEnie <[Host] MIKE-ALLEN> I'm going to put y'awl in listen-only for a few minutes. I have an opening statemeant. Then, we'll go on. Thanks, everyone, for showing up to this, the initial meeting of the Programming RTC. I want to say a few things and state a few opinions before I "un-muzzle" all of you. I would like to have these RTCs run in an informal, but organized manner. What that means is that I would like to have everyone in the talk mode, but with some order. What I suggest, at least for tonight, is that we speak in a rotation based on your Job number. I'll call out who is up, and then that person will have his/her say. When done, he/she lets me know and we pass on to the next person. After one round of this we can see how it is working, if it is too restrictive or if we need to be more formal. I'm sure that we will get to some rather open discussions, but I do ask that everyone respects the right of someone else to speak and doesn't interrupt. I will TRY and moderate a little. Wish me luck with this bunch! 8^} I think there are several issues we need to decide this evening. I'll throw them up along with my opinion. BTW, my opinion counts no more than anyone elses. Question 1: What are we actually trying to do? My thought is that this is more of a "Programming for the Atari" than a "Programming" RTC. I think we should emphasize what is different about programming in the Atari environment. I also believe that this could be a very good means for people to exchange experiences, techniques and problems. I also believe that we should stress "legal" programming. I know that I, at least, would want to believe what I learned here would be applicable across the entire spectrum of Atari 680x0 computers. MTOS and Geneva should be considered. Above all, this should be a learning experience. Question 2: When and how often should we meet? From my initial post I got a pretty mixed response. I think weeknights had a slight edge over weekends (I assume some of you young squirts have better things to do on a Friday or Saturday night than sit in front of a computer) and Thursday seemed to be the most popular. 10 PM Eastern seemed the appropriate time. Frequency is another subject. To be honest, I'm not sure that this type of RTC could survive on a weekly basis. I suggest twice a month: maybe the 1st and 3rd Thursdays. I'm open on this and will cover whatever you decide. Just remember that there are already regularly scheduled RTCs on Monday, Wednesday, Sunday and the 1st Friday of each month. Question 3: What language(s) should we concentrate on? Well, C is an obvious choice. Much of the reference material available is slanted towards C. Lattice C and Pure C are currently supported but a little on the pricy side to me. Lattice is supported on GEnie by HiSoft and Oregon Research. Pure C is supported by Gribnif here also. There are also several free packages available here on GEnie. I don't know how good they are or how easy/hard they are to set up. I'm sure someone will comment on that! Many of us also like assembly. There are advantages to assembly and it really isn't too hard to learn. The Devpacs (2 and 3) from HiSoft are excellent and are supported here on GEnie both by HiSoft and Oregon Research. GFA Basic seems to be popular. I have never used it and I don't know if GFA is or plans to continue to support the Atari platforms. HiSoft also has a basic, but I don't know anything about it. I will admit my own prejudice here: I don't like basic of any ilk. Another possibility is Pascal. ICD is selling (out?) Personal Pascal for $20. It is a dated package and probably won't be supported, but the price is right and I understand that it even runs on a Falcon. High Speed Pascal by HiSoft is available, I believe, from Oregon Research. Again I know very little about it. I hope no one suggests Ada, Modula II or Fortran. I'm sure there are some folks who will want to use C++ or some other Object Oriented Language. Comeau C++ isn't out for the Atari line yet and when it is it will be $250. Then you need a C compiler to go with it. There is a PD version of C++ out, but the same comments I had about the PD C compilers apply here. I, personally, am not ready to get into C++, et alia, yet. I think we should concentrate on C, Assembly and maybe GFA Basic. Question 4: Do we want to work on "projects?" I have some thoughts in that direction. Every programmer I know of has developed a library of routines that can be called upon for various projects. Why re-invent the wheel for each new program? I would like to see us develop a set of common routines in the various languages that we could share with the Atari community. One set I can think of right of the bat would be determining the exact capabilities of the environment in which a program is operating. I'm sure there are many other routines that would be very handy to have in a "canned" state. Maybe as we progress we might want to embark on a group project; a game, a word processor, a CD rom reader that doesn't require MTOS to run, or what ever. Just a thought. If we decide to embark on projects I can probably arrange for a private library where we can exchange code segments. Remember, however, that code developed in this RTC environment should end up public domain. We are here to educate each other, to learn and, hopefully, to be of benefit to the Atari community as a whole. Now, before I turn on the babble mode, let me remind you that I will be releasing a transcript of this RTC (and future ones) to the libraries. This has been requested by several people who either can't or don't want to attend these RTCs, but what to learn also. So remember your rantings will be available to the public. Ok, Sean will be first to comment. Babble mode on. <[Sean@TWP] P-DIRECT> Yikes. Let me read back for a moment... I'll skip #1 for now. How often, twice a month sounds good to me. Language should rotate, or we should have multiple (ouch) projects going on at once, if that isn't too confusing. GFA is popular, and C is the "real" programmers language, and assembly has strong fans so choosing to "ignore" any of them could hurt attendance. I want to work on projects... and back to #1......I think we're all here to learn a little something that we didn't know before and also find out some new tricks. (and meet new people) I guess I'll step down now. <[Host] MIKE-ALLEN> Thanks, Sean. Lou, you're next. ga <[Lou] ST.LOU> I would only comment that I will primarily be reading and learning since I don't program right now. However, I think Thursday is a great night because things are quiet and GEnie will not experience tech problems for an RTC. Mike, I like this format... it should work well to 'set things up'. Can I suggest you have a SIG for novices? GA <[Host] MIKE-ALLEN> Lou - interesting thought. ok. Lou, thanks. Tim, your turn. <[Tim@TWP] P-DIRECT2> Let me see..... In regard to you mention of LEGAL code, in the past, I thought it was easier to avoid the 'system', but I've found that making legal code is pretty nice and easy. I think that once a week would be nice.... I prefer programming in C, and finally, I think projects would be a good idea, but I wouldn't have time for them personally. I think I've babbled enough... GA. <[Host] MIKE-ALLEN> Thanks, Tim.. ACK, Your turn. ga <[ACK] C.FOLLETT> hi, all just a note: Atari topped the Stock EX. active list again today and closed at 11 3/8...3DO lost 3 pts... personally, I was thinking about programming in basic only because I have done it before but would consider learning c I was thinking about maybe just a few litlle programs for my 1.5 year old for starters after that maybe a few bigger projects...ga <[Host] MIKE-ALLEN> Thank for your input. For those who arrived after the opening statement, We are taking comments in a round-robbin based on your job number. I may skip a couple and come back - don't worry, I will get to you. dmj - speak to us. ga <[John too] J.G.H.> If you don't want to say anything just tell Mike to pass you by <[Splat!] DMJ> Biweekly. Assembly / C / GFA (despite my loathing for C). Projects--maybe. Semi-formal like this is good. GA <[Host] MIKE-ALLEN> That was consise, dmj - How unlike you. <[Splat!] DMJ> <[Host] MIKE-ALLEN> J2, your turn. ga <[John too] J.G.H.> We can have one langauge on one week and another one next week say...Basic the 1st Thursday...C the 2nd ... whatever the 3rd also some programs are uploaded in the libraries with source codes and we might tear them apart and see what they do GA <[Host] MIKE-ALLEN> Thanks John. That's an interesting thought. I know GEM sound has source code. Might be fun to find out why it doesn't always co-operate with the OS. Keith, comments? ga <[Keith] K.GERDES> Sure... I sit in front of DevPac most of the time. I've worked in C too. Projects are a must IMO. That's the only way to learn... GA <[Host] MIKE-ALLEN> Thanks, Keith. If you are wondering where we are in the sequence, do an /sta and see what the job numbers are. Chris, ga <[Chris] C.CASSADAY> I concur with most others. Biweekly, switching between C, Assembly (my preference), and GFA. Perhaps we could do some work on GEM Nethack... I like it quite a bit, fun game... I'd like to do some hardware specific stuff as well... but I need some foundation first. GA <[Host] MIKE-ALLEN> Thanks, Chris. Bud, your comments? ga <[Bud] B.CONNOLLY1> #1 - I'm looking for pointers on how to use all of the system calls. I have plenty of books, but they really don't tell me when I should use them. #2 - 1st & 3rd Thursdays. #3 - I program in Fortran at work, ;) but I would like to learn C #4 Projects - YES, I need a goal to get going! GA <[Host] MIKE-ALLEN> Thanks bud. I sympathize - I have to use Fortrash at work too. Sam your turn. ga <[Sam030] SAM-RAPP> I like 'C'. I have done very little programming in the last few years, but I would like to get back into it with 'C'. Perhaps we could get Oregon to make a Programmers RTC discount on Lattice? ... I like the idea of projects. More than twice a month would strain my Master Card. GA. <[Host] MIKE-ALLEN> Ok Sam, thanks - Charles, opinions? ga I use C and 680x0 assembly alot. But I am well versed in other languages I would strongly recommend the Atari Compendium from SDS as it has just about anything you might need in it for the ST/TT/F030 ga <[Host] MIKE-ALLEN> Charles, is STraight FAX C or assembly or both? ga Mainly C, but in a few places assembly for speed. Most of the printer drivers are also assembly. ga <[Host] MIKE-ALLEN> Thanks - Tony, comments? ga <[Tony @ Canoe] A.RIDLEY1> I missed the opening comments. I'm not sure what the purpose of this RTC is? Will there be group programing projects? or Tutorials? or what? Also What is the level expected of programers if any? This seems like a good idea. Who is "in charge" of this TRC? GA oops trc=rtc <[Host] MIKE-ALLEN> Tony - that's exactly what this meeting is about - trying to decide what we are going to do. I guess I'm trying to moderate the RTC, but I don't see how anyone can be "in charge" of this bunch! <[Tony @ Canoe] A.RIDLEY1> Will there be an area for messages ? <[Host] MIKE-ALLEN> Tony - we already have a topic set up (Cat3/Top11) and if there is interest we will set up a private Library area. ga <[Tony @ Canoe] A.RIDLEY1> I'd like to see work specific to the DSp talked about I think most of the other programming topics are overworked..the DSP is new and exciting. GA <[Host] MIKE-ALLEN> I called motorola for the 56k manual the other day. It's out of print! <[Chris] C.CASSADAY> I'll sell you mine for $100! <[Host] MIKE-ALLEN> Mike Hill, your inputs? <[Mike] M.HILL13> Weekly is fine with me. I like the project idea and think regardless of what language you program in people can group off and work on the project in their particular language. Each sub-group can help each other out also. I even have an idea for a project or two. Groups like this can really come out with some nice programs. Look at the free software foundation FSF, Linux, Mint, etc. GA. :-> <[Host] MIKE-ALLEN> Thanks, Mike - some good thought there. Chris Oates? What say? ga. <[Chris] C.OATES2> Well, I don't have much preference for time, and as a student I'm not sure about being able to work on projects intensely, but I'd like to learn more about Assembly and some new Falcon related Stuff. Maybe have occasional meetings to cover "new" technology. DSP, Falcon Specific, MTOS, Speedo compliance? GA <[Host] MIKE-ALLEN> Thanks, Chris - good inputs. Duane, Comments? ga <[Duane] D.CHARTER> -I like the idea of twice a month. Thursdays are fine... I will miss a few due to business travel. -I like C or Assembly, but would still participate in a Basic RTC. -Projects would be great...it is the best way to learn programming, and we have some experts available here to help when we get stuck. Each project should have it's own topic area where we can exchange ideas and code. ga <[Host] MIKE-ALLEN> Duane was ready! Thanks. Kim, your turn. ga <[Kim] K.SWIFT> I'm interested in DSP, MIDI. Strong opinion: object-oriented paradigm is a must! Right now I'm programming in Laser C on the ST but want to move to Falcon040 and C++ or other OO language. I have an interesting MIDI project I'd be willing to consider doing with others. ga <[Host] MIKE-ALLEN> Ok Kim, thanks. OOP seems to have advocates and those who hate it! The big problem I see with OOP on the Atari line . . . is lack of availability and/or cost. I guess G++ is out there, but I don't know too much about it. Ok, Have I missed anyone? If so, yell now! <[Kim] K.SWIFT> project idea: public-domain C++ compiler? <[Splat!] DMJ> That's a big project. <[Sean@TWP] P-DIRECT> <[Kim] K.SWIFT> oops out of turn <[Mike] M.HILL13> By 2095? <[Host] MIKE-ALLEN> Kim - you don't think small, do you? <[Kim] K.SWIFT> <[Tim@TWP] P-DIRECT2> A C++ compiler would be nice, but how we organise the necessdary number of people who are so disconnected into working on this thing? <[Host] MIKE-ALLEN> Ok, let me get some thoughts together from the comments. . . Seems to me that before we decide the frequency of meetings, we need to decide if we are going to program in all languages simutaneously or break up into smaller groups. I personally think that comparing routine across the languages would be of benefit. <[Tim@TWP] P-DIRECT2> How many of you have enought understanding of automata theory? I know I don't. <[Host] MIKE-ALLEN> not me, Tim. <[Bud] B.CONNOLLY1> Tim, can you give a brief rundown of that theory? <[#include] M.HILL13> Mike, I think we need to decide a good project and break into groups. Those groups can meet as often as they want and we can all share info together. The first project should be simple <[Splat!] DMJ> I like the idea of comparing code between languages. It helps to highlight the strengths and weaknesses of the languages. <[Host] MIKE-ALLEN> Lets take a show of hands by using the /rai command. those in favor of separate rtc meetings for the different languages please /rai now. <[Tim@TWP] P-DIRECT2> Are we supposed to talk out of turn? Are there turns now? <[Chris] C.OATES2> what if we're not sure? <[Kim] K.SWIFT> I'm very opposed to separate languages!!! <[Splat!] DMJ> Mike's gonna pop the room into listen-only mode any second... <[Host] MIKE-ALLEN> Ok, I got 4-1/2 raises <[#include] M.HILL13> There should be one meeting a month for all though. <[Splat!] DMJ> Now the NAY vote? <[Tim@TWP] P-DIRECT2> Automata theory, as I understand it, involves parcing things, mostly.... like compilers, natural languages, regular expressions, mathematical expressions, etc. You can do anything with a set of stacks. I could be a little off there. <[Host] MIKE-ALLEN> those in favor of meeting together and splitting up into separate groups privately /rai now. <[Sean@TWP] P-DIRECT> How about different rooms? ie: Room 1 is C, 2 is GFA, etc. <[Splat!] DMJ> What about people who want more than one language? <[ACK] C.FOLLETT> Sean, that sounds good! <[Host] MIKE-ALLEN> Hmmm 4 and 1/2 raises. <[#include] M.HILL13> Separate but not private. <[Tim@TWP] P-DIRECT2> How about we invent a NEW programming language? <[Sean@TWP] P-DIRECT> Monitor <[Lou] ST.LOU> I would like a NOVICE SIG in one room.... <[Splat!] DMJ> I like that idea, Tim. <[Sean@TWP] P-DIRECT> One can monitor multiple channels. <[#include] M.HILL13> Some may want to watch all groups, but your going to have everyone work on the project in their language. <[Splat!] DMJ> Yeah, but it's harder to PARTICIPATE in more than one. <[Host] MIKE-ALLEN> Sean has a very good idea. We could start in a single room and then split up into the various rooms. Like that one folks? <[Kim] K.SWIFT> Divided we stand, separate we fall. I ask: one language! <[#include] M.HILL13> Yes! <[Splat!] DMJ> You can't do that Kim. <[Sean@TWP] P-DIRECT> How about the first in a month being split and the other one combined. <[Splat!] DMJ> Other way around, Sean. Or maybe not. <[Chris] C.OATES2> yes, group meeting first... <[Sean@TWP] P-DIRECT> Whichever :) <[Tim@TWP] P-DIRECT2> It would be nice if you could link code segments from different languages into the same executable. <[Bud] B.CONNOLLY1> Good idea Sean <[ACK] C.FOLLETT> how about we compromise ourselves out of existance? <[Splat!] DMJ> Since we already used the first meeting this month. <[#include] M.HILL13> How about defining a group project first <[John too] J.G.H.> Well if a group is working on a certain project in a langage they can always hop to another room to discuss things <[Splat!] DMJ> Youc an do that with a linker, Tim. <[Chris] C.OATES2> well, you can do in-line assembly with laser C... <[#include] M.HILL13> then breaking into language groups to accomplish it <[Sean@TWP] P-DIRECT> All of this is just prelimiary, it isn't set in stone. <[Host] MIKE-ALLEN> Ok, how about this. Twice a month, meet in room one for general discussion and then split for the various languages. OK folks? <[Splat!] DMJ> That sounds good. <[#include] M.HILL13> We have C gurus, Assembly gurus, Logo Gurus :-> <[Chris] C.OATES2> How about the really important things? Like group name, motto, mascot & t-shirt design??? :) <[Tim@TWP] P-DIRECT2> I know, but what linker would handle Pascal, Assembly, C, and Modula 2 object files? <[Sean@TWP] P-DIRECT> <[Splat!] DMJ> Logo gurus? <[Chris] C.CASSADAY> Sounds good to me. <[Host] MIKE-ALLEN> Ok, thats it. <[#include] M.HILL13> Sounds good! <[Zombie] R.ANISKO> some C novices (like me :-) <[Chris] C.OATES2> a 'C' Grue? <[Splat!] DMJ> If they're compiled properly, they should all have similar calling conventions, Tim. <[Host] MIKE-ALLEN> Any objections to 1st and 3rd thursdays at 10pm Eastern? <[Kim] K.SWIFT> But don't we have Babylon with many languages? Aren't we a small enough group for one language? <[Splat!] DMJ> Sounds good to me. <[Sean@TWP] P-DIRECT> No objections from me... <[Tim@TWP] P-DIRECT2> Pascal calling conventions are different from C in the standard... Assembly has none. <[#include] M.HILL13> Sounds good! <[Splat!] DMJ> No Kim, we DON'T have Babel. <[Chris] C.CASSADAY> No objections. <[Bud] B.CONNOLLY1> Go fo it. <[Host] MIKE-ALLEN> OK - that's it. <[Kim] K.SWIFT> oops, Tower of Babel <[Chris] C.CASSADAY> My babel fish is nicely installed in my ear. <[Splat!] DMJ> Tim, assembly can be written to use C calling conventions (of course). <[Host] MIKE-ALLEN> Now to the fun part. Project nominations? <[Zombie] R.ANISKO> will the pertinent info of this meeting be posted in the BB? <[Sean@TWP] P-DIRECT> Now Mike writes it down in stone.. :) <[Tim@TWP] P-DIRECT2> I know. <[Splat!] DMJ> Yeah, it should, Rob. <[Chris] C.OATES2> # include <[#include] M.HILL13> I have an idea! <[Host] MIKE-ALLEN> Lets go around the horn again. Let's start with Sean again. ga sean. <[Tim@TWP] P-DIRECT2> 5 * 9 = 42 <[Sean@TWP] P-DIRECT> GEM window based simple terminal. <[Chris] C.OATES2> that works on the Falcon??? :) <[Sean@TWP] P-DIRECT> <[Host] MIKE-ALLEN> Let me do this a little differently. First, it seemed to me that everyone wante projects. Any objections to that? <[Splat!] DMJ> No. <[Bud] B.CONNOLLY1> No <[Zombie] R.ANISKO> projects are ok with me... <[#include] M.HILL13> No objections. <[ACK] C.FOLLETT> no <[Chris] C.OATES2> nope projects sound great! <[Duane] D.CHARTER> no objection <[Sean@TWP] P-DIRECT> Just fine with me, obviously. <[Chris] C.CASSADAY> NO. objections. <[Kim] K.SWIFT> good idea <[John too] J.G.H.> Hmmmmmm...how we going to list the credits on it? <[Host] MIKE-ALLEN> Guess not. Ok, everyone with a project idea, do a /rai and I will call on you in some sort of order. /rai now. <[Splat!] DMJ> Why, list all the names, of course. <[Duane] D.CHARTER> Use remarks for the names. <[Host] MIKE-ALLEN> Ok Sean - you first. <[John too] J.G.H.> Me first? <[Zombie] R.ANISKO> j2 - we'll all create a randomizer, and IT will list the names in random order :-) <[Sean@TWP] P-DIRECT> As I said, a GEM window based simple terminal. It would make all the standard OS calls, and would make use of GEM and BIOS/XBIOS. Perfect for "testing" out our format. GA <[John too] J.G.H.> Good looking (forgotten) Sysop's first? <[Splat!] DMJ> Except for the complete lack of support in the OS for serial stuff... <[Host] MIKE-ALLEN> Thanks Sean. <[Host] MIKE-ALLEN> Mike Hill ga. <[#include] M.HILL13> I say we start at simple at first. One of the nice things about Windows is the API calls for creating INI files (configuration files). I say we make a library other programmers can use that lets them create ini files that store configuration data for their programs. <[Splat!] DMJ> Already exists, Mike, Geneva handles .INI type files. <[#include] M.HILL13> Not everyone has Geneva though. Storm for instance does this. INI files are basically text files. GA <[Tim@TWP] P-DIRECT2> Yeah, but how well does Storm work? <[Splat!] DMJ> <[Host] MIKE-ALLEN> Thanks, Mike. I like starting small myself. dmj you had an Idea? <[#include] M.HILL13> Sorm works great as far as I can tell. <[Host] MIKE-ALLEN> Tim-Storm works very nicely! <[Splat!] DMJ> Yeah, Sean gave me an idea. How about a GEM-based text editor? Nothing fancy. <[Tim@TWP] P-DIRECT2> I'll take your word for it.... I haven't used it. <[Sean@TWP] P-DIRECT> Storm has a few problems on the Falcon. <[Splat!] DMJ> What doesn't? <[Sean@TWP] P-DIRECT> w/ScreenBlaster specifically. <[Splat!] DMJ> I can think of a few reasons why. <[Host] MIKE-ALLEN> hey guys, lets hold off the chatter a little. <[Splat!] DMJ> <[Sean@TWP] P-DIRECT> Okay, Mike. <[Host] MIKE-ALLEN> Kim - I think you had an idea? ga, <[Tim@TWP] P-DIRECT2> I would like a nice ASCII text editor, and I could write one. I wrote a nice editor for UNIX... it's paragraph oriented and auto-word wrap and everything... how about I release source? <[Kim] K.SWIFT> I'd like to see CD-Rom support on the Falcon. Anything we can do? <[Splat!] DMJ> You like assembly? <[Tim@TWP] P-DIRECT2> <[Kim] K.SWIFT> Also, MIDI. <[Sean@TWP] P-DIRECT> Start smaller? <[Kim] K.SWIFT> ga <[Host] MIKE-ALLEN> Kim - I'd like to access a CD ROM without MTOS! <[Splat!] DMJ> Me too. <[#include] M.HILL13> Here Here Mike! <[Chris] C.OATES2> use MiNT? :) <[Splat!] DMJ> That's as bad as using MTOS. <[Host] MIKE-ALLEN> Chris Cassaday = your idea? ga <[John too] J.G.H.> We can also have some of the Advanced programmers work on a more advanced project so they don't get too bored with us lesser knowledgable programmers ;> <[Tim@TWP] P-DIRECT2> I'd like to access CD rom without slowing down my machine. <[Chris] C.CASSADAY> Super duper program launcher for MTOS and Geneva. Would except LZH, ARC, ZOO, ZIP, ARJ, etc and lauch the appropriate program. Would be user configurable to allow user to add new files... Support drop and drag protocol to allow window.. to remained open so user could pass programs to install as new app or data files to execute them...ga <[Host] MIKE-ALLEN> Hmmm - what would you call that in 5 words or less, Chris? ga <[Chris] C.OATES2> "Super Duper Program Launcher"??? <[Chris] C.CASSADAY> Super Duper Program Launcher? <[Chris] C.OATES2> :) <[Chris] C.CASSADAY> <[Chris] C.OATES2> Great names think alike... <[Chris] C.CASSADAY> <[Host] MIKE-ALLEN> Rob - your idea? ga. <[Zombie] R.ANISKO> something simple? how bout a GEM-based text convertor - convert between ST/PC, MAC and Unix files - it would be basic I/O and GEM windows fgeatures... maybe runnable by both GEM and command line? <[Host] MIKE-ALLEN> Ok, rob. Thanks. <[Host] MIKE-ALLEN> My personal idea would be a library of common routines that every programmer needs, like walking the rectangle list. We could all then have a library to start with to use on a larger project. <[Host] MIKE-ALLEN> OK, lets vote. <[#include] M.HILL13> George Bush <[Zombie] R.ANISKO> Bill the Cat <[#include] M.HILL13> Oops wrong voting. <[ACK] C.FOLLETT> right on, Zombie! <[Host] MIKE-ALLEN> We have in nomination: 1) a terminal prg, 2) a configuration library, 3) a text editor, 4) a CD rom reader, 5) a word processing format converter and 6) library of routines. <[Sean@TWP] P-DIRECT> Something tells me this is going to be edited out. <[Host] MIKE-ALLEN> Everyone think. <[Host] MIKE-ALLEN> ok all in favor of #1 (term prg) do a /rai now. <[Host] MIKE-ALLEN> ok, I got NO /rais for #1 <[Splat!] DMJ> Guess we killed the term program. <[Sean@TWP] P-DIRECT> Awww...shucks. :) <[Host] MIKE-ALLEN> hey guys, just a few minutes more and then we can chatter! <[Splat!] DMJ> The natives are restless... <[Host] MIKE-ALLEN> all in favor of #2 (configuration utility) /rai now. <[Tim@TWP] P-DIRECT2> Reminds me of an elephant joke. <[Mike] M.HILL13> Can I stuff the ballot <[Splat!] DMJ> <[Host] MIKE-ALLEN> I got one rai. <[Mike] M.HILL13> Not the editor!!!!!!!!!!! <[Host] MIKE-ALLEN> #3 (text editor) /rai now <[Chris] C.CASSADAY> I presume by configuration utility you mean "Super Duper Program Launcher"? <[Mike] M.HILL13> Boooohhhhh <[Host] MIKE-ALLEN> 4 for #3 - chris - nope, launcher coming up. <[Zombie] R.ANISKO> (how 'bout an Amiga emulator ;-) oops, quiet :-O <[Chris] C.OATES2> can we vote for more than one?o <[Mike] M.HILL13> Can we vote twice? :-> <[Tim@TWP] P-DIRECT2> How about a wordprocessor or a UNIX clone? <[Host] MIKE-ALLEN> #4 (cd rom reader) I'd appreciate single votes please. /rai now. <[Chris] C.OATES2> text editor = simple word processor... <[Zombie] R.ANISKO> ...sockets library for MiNT? <[Mike] M.HILL13> I also mentioned to Mike that a university holds an annual group programming contest. We can get the rules from the Internet. <[Host] MIKE-ALLEN> One for the CD rom. <[Host] MIKE-ALLEN> #5 (the super-dooper program luncher) /rai now. <[Mike] M.HILL13> The contest starts mid november <[Host] MIKE-ALLEN> One for the luncher . <[ACK] C.FOLLETT> I like this one but I already voted :-( <[Tim@TWP] P-DIRECT2> Nov 18 for the internet programming contest, I think. <[Chris] C.CASSADAY> "Luncher" I'm insulted. <[Host] MIKE-ALLEN> #6 (word proc text converter) /rai now. <[Chris] C.OATES2> me too, ack. <[Sean@TWP] P-DIRECT> Isn't 6 the routine set? <[Splat!] DMJ> That's what I thought it was. <[Host] MIKE-ALLEN> I screwed up on the list - I forgot the launcher. <[Host] MIKE-ALLEN> One for the text converter. <[Sean@TWP] P-DIRECT> We just did the luncher.. :) <[Mike] M.HILL13> Yeah we voted on the luncher already! <[Host] MIKE-ALLEN> Sean - I know we did it, I just left it out of my initial list. <[Chris] C.CASSADAY> <[Host] MIKE-ALLEN> Finally, the routine library. /rai now. <[Kim] K.SWIFT> the supper dipper peanut luncher? <[Host] MIKE-ALLEN> OK - I got 5 for the library. <[Chris] C.OATES2> peanut launcher? <[Chris] C.CASSADAY> <[Chris] C.CASSADAY> <[Tim@TWP] P-DIRECT2> <[Zombie] R.ANISKO> sigh young? <[Mike] M.HILL13> Oh well. <[Host] MIKE-ALLEN> since we had a bunch of ones an 2s, lets revote with just the text editor and the library in the running. <[Tim@TWP] P-DIRECT2> What's to be in this library? <[ACK] C.FOLLETT> maybe one language could get one project, another a next project etc.? <[Kim] K.SWIFT> got a good laugh out of me, worth the visit... <[Host] MIKE-ALLEN> Text editor, /rai now. <[Splat!] DMJ> Everything useful, Tim. <[Splat!] DMJ> <[Host] MIKE-ALLEN> 4 for the editor. <[Host] MIKE-ALLEN> library, /rai now. <[Host] MIKE-ALLEN> 7 for the library. <[Splat!] DMJ> Wow... <[Tim@TWP] P-DIRECT2> <[Splat!] DMJ> Somebody spank that whiner and send him to bed... <[Zombie] R.ANISKO> }do we need a library card? ;-) <[Kim] K.SWIFT> Please don't tell me you're going to code the library in a zillion languages. <[Host] MIKE-ALLEN> Looks like the lib wins. I suggest that until our next meeting folks post suggestions for the contents of the library in cat3/top11. <[Host] MIKE-ALLEN> Kim - nah only about 3. <[Splat!] DMJ> Kim, anyone who thinks one language can do it all is crazy... <[Tim@TWP] P-DIRECT2> I have a couple routines that draw pixels and horizontal spans very quickly on any resolution or number of bit planes. <[Splat!] DMJ> But they're hardware-dependent. <[Splat!] DMJ> Hi Judy. <[Tim@TWP] P-DIRECT2> I work only in C and Asm. <[Kim] K.SWIFT> Anybody who thinks you can do a project in many different languages is crazy. <[Mike] M.HILL13> I hope we have many languages, to force everyone to work in one language is crazy. <[Host] MIKE-ALLEN> Any one have a calender handy? <[Sean@TWP] P-DIRECT> We need completely portable code. <[Bud] B.CONNOLLY1> I have one in sight. <[Judy B.] ANTHILL> Hi DMJ. <[Splat!] DMJ> The 18th is Thursday, two weeks from now. <[Tim@TWP] P-DIRECT2> What's wrong with hardware dependant? We're programming for Atari, right? We're not planning on using these on a PC, are we?> <[Host] MIKE-ALLEN> is the 18th the 3rd thursday? <[Zombie] R.ANISKO> maybe low level stuff (like telecomm) in asm or C; more screen oriented stuff, etc in a higherlevel language? <[Mike] M.HILL13> We might have some working in Assembly, some in C, others in GFA <[Bud] B.CONNOLLY1> Yes it is Mike. <[Splat!] DMJ> Hardware-dependent is almost okay. <[Sean@TWP] P-DIRECT> Things have got to work in all screen rezes and colors. <[Splat!] DMJ> But what about graphics cards, and True Color mode? <[Chris] C.OATES2> yes! graphics cards! <[Host] MIKE-ALLEN> Thanks Bud and dmj. Ok, next meeting is the 18th of Nowonder at 10pm eastern. <[Chris] C.OATES2> suport Crazy Dots! :) <[Zombie] R.ANISKO> sean - then we need to know what the screen resolution is and # of colors (and not just ST Low, Med, and Hi) <[Sean@TWP] P-DIRECT> Nowonder? <[Kim] K.SWIFT> 18th of Nowonder? <[Sean@TWP] P-DIRECT> :) <[Zombie] R.ANISKO> Ah, no wowonmder.. <[Tim@TWP] P-DIRECT2> The code I was referring to works in any rez with any number of bit planes, as long as you supply it with a proper MFDB. <[Bud] B.CONNOLLY1> Freud, your slip is showing ;) <[Mike] M.HILL13> Ive got my Crazy Dots II ready! <[Duane] D.CHARTER> Good Night everybody, it's been great. See you on the 18th. <[Splat!] DMJ> Except that graphics cards do not use the bitplane format the ST uses. <[Chris] C.OATES2> Cool. I want to upgrade soon. <[Zombie] R.ANISKO> we'll need a "dictionary" of terms - like MFDB for us novices :-) <[Splat!] DMJ> Memory Form Description Block. <[Kim] K.SWIFT> Good night. Don't let the PC's bite. :) <[Sean@TWP] P-DIRECT> I'm sure that helps him... :) <[Bud] B.CONNOLLY1> Suggestion: The Atari Compendium should be on everyones desk. <[Host] MIKE-ALLEN> Thanks to all who participated. I'll post this transcript (boy is this going to be a bear to edit!) in the libs. Folks, please hit cat3/top11 with your comments and suggestions. Thanks for your co-operation also. Programming Real Time Conference November 18, 1993 Host - Mike Allen <[Host] MIKE-ALLEN> Remember, this initial portion of the rtc is being captured and WILL be posted! Watch your warts. <[Parrot Head] C.CASSADAY> You have the floor, Mike. er Screen? <[Host] MIKE-ALLEN> I didn't see a whole lot of activity in Cat3/Top11 during the last 2 weeks So, we will need a little discussion here. BTW, I do have some good words. Darlah has arranged for a private lib for the exchange of code while we're working on things. This lib is lib 19. You need to send me EMail so that I can arrange for access. So, when we have code segments to look over, we can upload them for our fellow attendees without exposing our foolishness to the world. Seems like we decided to work on a "utility ROUTINE (hi, Keith) library" last session. However I have seen very little in the way of suggestions as to what this library should contain. Ok, let me swing around the table the way we did last time - in order of job number. Sean is first - what do you think, Sean? ga. <[Sean@TWP] P-DIRECT> I'll have to pass on this, I'm drawing a blank. ga <[Host] MIKE-ALLEN> Ok - next we'll ask rob in zombie land. ga. <[Zombie] R.ANISKO> maybe a "system configuratioN" routine - so we'd know what TOS version, etc the future projects are working on? kind of a "show me what I'm running on" function? ga <[Host] MIKE-ALLEN> Ok, rob thanks. I'm kinda with you. I believe I posted something like that as a suggestion in 3/11. Paul what do you think? ga <[paul] P.LANCTOT> i'm the ultimate rookie but maybe something to makelsimple graphics portable to IBM? ga <[Host] MIKE-ALLEN> Hmmmm - might make a good later project. thanks. Bud, your turn. ga <[Bud] B.CONNOLLY1> I was thinking of putting in routines that handle general housekeeping chores. i.e. find the size of the screen you are working with and then pass back scaling information. GA <[Host] MIKE-ALLEN> Thanks bud. Chris -any ideas? ga <[Parrot Head] C.CASSADAY> GEM window management stuff. Walking the rectangle list, etc. ga <[Host] MIKE-ALLEN> Chris - walking the rectangle list is one of those things everyone needs. Good suggestion. <[Keith] K.GERDES> A "what's my system" seems to be a good idea. I know from a tech support position, there are times when this info is vital to debugging. How about a small homework assignment? It could be something that is coded in any language, with strictly _TOS_ output. GA <[Host] MIKE-ALLEN> Not a bad idea. CBARRON, your thoughts? Easy text writing in windows without really worrying about the gem messaging stuff 'too much'. Wxlib is to messy, something fairly portable elsewhere would be nice. ga <[Host] MIKE-ALLEN> Thanks. Gary - your thoughts? ga? <[Gary] G.STOLLMAN> Anything to help us learn programming would be good..... ga <[Host] MIKE-ALLEN> My thought was a two level "what am I" type of routine. First some sort of routine to report what the system actually is and then a routine as to what the current state is. I must admit that I had hoped for a little more discussion in 3/11 so that we could minimize the "what do we do" talk and get to the "how do we do it" end of things. I'm just going to open the floor to general discussion for a few minutes and see if we can hash out our first "routine" project. Go at it folks, I'll watch. ga <[Sean@TWP] P-DIRECT> The library of routines idea is good, but is a bit limited until we know more about what we would need in it. Of course, it might be a good idea to build it up as we go along... (ga?) <[Bud] B.CONNOLLY1> Mike, can you define what you mean by 'current state'? <[Zombie] R.ANISKO> how much memory free, etc - my guess as to one of the things Mike means <[Host] MIKE-ALLEN> Bud - resolution, palatte, Multi-tasking, etc. Anything that is user configurable (or program configurable). <[Bud] B.CONNOLLY1> ok, got ya. <[Keith] K.GERDES> Cookies in the cookie jar. <[Bud] B.CONNOLLY1> If the jar is there. <[Sean@TWP] P-DIRECT> People with the Compendium would be at a *slight* advantage... <[Host] MIKE-ALLEN> Cookies are part if it - also AES and GEMDOS versions. <[Keith] K.GERDES> Variables in the OS header. <[Bud] B.CONNOLLY1> I got mine! :^) <[Keith] K.GERDES> Low memory variables. <[Host] MIKE-ALLEN> Do we count on negative LineA variables? <[Keith] K.GERDES> Line-A will always be present... no matter what you know who says. <[Sean@TWP] P-DIRECT> It would be best to stick with VDI. <[Bud] B.CONNOLLY1> Didn't Atari say Line-A will no longer be supported? If so, probably wouldn't want to mess with Line-A. <[Zombie] R.ANISKO> is it LineA that doesn't work on non-ST modes? Anythin that is user configurable? Huh, that is a wide area... Re Line A I say don't rely on any of that! Positive or neg. offsets. <[Keith] K.GERDES> It depends strictly on what you want to and have to do. <[Host] MIKE-ALLEN> Which cookies should we check - only the Atari defined cookies? Could miss the Geneva cookie if we did that. <[Bud] B.CONNOLLY1> We could start simple and add routines later as we find the need for them. <[Keith] K.GERDES> A library routine should take a cookie parameter and then search for it. Returning a status value. <[Zombie] R.ANISKO> could build a list of cookies as we learn about them <[Host] MIKE-ALLEN> Ok - let me make a suggestion. I already have an assembly language routine for reading the cookie jar. I will post it in Lib 19. Do we wish to store the cookies internal to the progam? Or just have the ability to look for a cookie. <[Sean@TWP] P-DIRECT> Could that cause problems with MultiTOS? <[Host] MIKE-ALLEN> Sean - How so? <[Bud] B.CONNOLLY1> Look for what we need and set up the program as necessary. <[Sean@TWP] P-DIRECT> Just wondering...I have no idea, myself. <[Host] MIKE-ALLEN> I have run a program that uses the cookie reader under MTOS - no problem that I could see. <[Keith] K.GERDES> Maybe Dan's JARxxx program would be easier to use. It has hooks to get cookies. <[Host] MIKE-ALLEN> How about I post two versions. The one that I presently have and another version that will read and store all the cookies. Keith - Dan's hooks are nice. I'm going to change my prg to check for JARxxx first and use it if it is available. <[Bud] B.CONNOLLY1> Do cookies change while a program is running? <[Host] MIKE-ALLEN> I assume that we are trying to get a What is my Machine routine? Bud - It would be possible under MTOS or Geneva, I think. Reading is no problem, writing might be as it becomes a question who owns the ram reallocatd for cookies if room does not exist. The latter may cause multitaskers some 'problems'. <[Host] MIKE-ALLEN> I was just trying to establish the current machine capabilities, not change them <[Bud] B.CONNOLLY1> Yes Mike, cookies and system variables should tell us that. <[Host] MIKE-ALLEN> I guess we also need to check AES version (Global[0]) and GEMDOS version. what else? <[Zombie] R.ANISKO> AES, VDI, TOS versions. MiNT version? <[Host] MIKE-ALLEN> How about GDOS (is it there and if so, what kind? Cookie for FSM and Speedo how about the old one) <[Parrot Head] C.CASSADAY> current screen res. <[Bud] B.CONNOLLY1> Resolution and aspect ratio. <[Host] MIKE-ALLEN> MiNT is in a cookie. <[Parrot Head] C.CASSADAY> number of bit planes. <[Zombie] R.ANISKO> cool - I believe MiNT 1.0 and above were stored a little differently than pre-1.00 if that matters... dunno if that's via cookie or not though... <[Sean@TWP] P-DIRECT> There is a FSMC cookie. It indicates the presence of either FSM of Speedo. <[Host] MIKE-ALLEN> Chris, Bud - that is more in the "What is my current state" category as opposed to "What am I." <[Parrot Head] C.CASSADAY> ahh. <[Bud] B.CONNOLLY1> ok <[Host] MIKE-ALLEN> How do we detect 3rd party video boards? <[Bud] B.CONNOLLY1> VDI? <[Host] MIKE-ALLEN> Maybe so. Where does the VDI version live? Sounds like homework! "Where is the VDI version?" <[Parrot Head] C.CASSADAY> Do these boards, drivers install cookies, that is what they were supposed to be for. <[Sean@TWP] P-DIRECT> Would vq_extnd() tell you if you have a video card on the system? <[Host] MIKE-ALLEN> I dunno. Maybe we should ask Gribnif, Lexicor and CyberCube. <[Bud] B.CONNOLLY1> According to the Compendium...Page 7.8 you can determine the category of the device from v_opnwk() work_out(13) and vq_extnd() work_out(5). <[Zombie] R.ANISKO> where's Yat? he might be abkle to help us re: Nova card <[Host] MIKE-ALLEN> <[Parrot Head] C.CASSADAY> Good point. determing whether you are in a palletted video mode or true color mode would be important. <[Host] MIKE-ALLEN> Chris - again that is a "what is my state" not "what can I do." Hokay - how about we devide the various questions up for "homework." I volunteer for the Cookie Jar in assembly (since I have most of it done already ) anyone for C and/or GFA versions? [insert massive lack of screen activity here!] <[Host] MIKE-ALLEN> Hmmm - no volunteers, <[Parrot Head] C.CASSADAY> the C code is in the atari docs. I'll look and advise which file its on my other systerm <[Sean@TWP] P-DIRECT> If I had any time left to volunteer... <[Bud] B.CONNOLLY1> vq_extnd returns type of screen display in work_out(0) Hey we should check Check CPU, BlitterCheck CPU, Blitter etc... <[Host] MIKE-ALLEN> Ok, seems like AES and GEMDOS is pretty well defined already - no need for special assembly routines. How about in C or GFA - I haven't used them on the ST so I don't know. Tom - CPU is a cookie. Don't know about blitter. Good thought! <[Sean@TWP] P-DIRECT> The BLiTTER is an XBIOS call. Really high number. <[Host] MIKE-ALLEN> I assume that Global[0] and the GEMDOS version call are available in C - howabout GFA? Blitter is xbios 64 <[Host] MIKE-ALLEN> No GFA experts? Where is dmj when you need him <[Sean@TWP] P-DIRECT> XBIOS 64 is Blitmode() and detects and sets the BLiTTER mode. I know a bit about GFA. <[Zombie] R.ANISKO> "C" neophyte here :-) <[Host] MIKE-ALLEN> So I guess the blitter is an XBIOS call, the CPU is a Cookie. Still don't know where to find the VDI version. Any volunteers for that one? How do you detect FPU? <[Zombie] R.ANISKO> FPU is a cookie I think <[Host] MIKE-ALLEN> Tom - Cookie, again. Maybe I should post the Atari defined cookies in 3/11 for those who don't have the compendium? <[Zombie] R.ANISKO> good idea <[Host] MIKE-ALLEN> Ok - will do. <[Sean@TWP] P-DIRECT> There's a printer/plotter return code for "Ornery Printer" ... sheesh. <[Host] MIKE-ALLEN> Anyone going to volunteer for any portion of the "what am I" routines? <[Zombie] R.ANISKO> I'll volunteer to try some out (but I need to get some decent documentation first) <[Sean@TWP] P-DIRECT> I can't find anything to figure out VDI version... <[Host] MIKE-ALLEN> Lemme see if I can sumarize what we want in the "what am I" routine so far: 1) read the cookie jar (what do we do with them?) 2) GDOS presence and version 3) AES version (easy) 4) GEMDOS version (easy) 5) TOS version (easy) 6) VDI version 7) BLiTTER present. 8) MultiTasking in effect (easy) what have I missed other than the individual cookie items? Memory <[Zombie] R.ANISKO> will there be multiple people doing these, or is it assigned to one person? each <[Host] MIKE-ALLEN> Rob - I would like to see everyone interested to try their hand - the more the merrier - I know that I have managed to improve some of my routine after exchanges with Tim and Damien! <[Host] MIKE-ALLEN> Good - memory size. Memory free would be a "what is my state" <[Zombie] R.ANISKO> memory vs memory free RAM <[Bud] B.CONNOLLY1> ST or TT <[Sean@TWP] P-DIRECT> What about the fact that TT RAM is available? <[Bud] B.CONNOLLY1> ST or TT ram and how much of each. <[Host] MIKE-ALLEN> Yeah - both the size and presence of each RAM type. <[Sean@TWP] P-DIRECT> Isn't that a Cookie (TT RAM present?) <[Zombie] R.ANISKO> cool then - I'll attempt some of the AES/TOS version stuff and see what everyone else comes up with <[Host] MIKE-ALLEN> BTW, You can have "TT" ram in any TOS from 2.00 up. I would guess 3.05 and up, don't you need tos 3+ for an 030??? <[Host] MIKE-ALLEN> Ok, guys - Remember to send me EMail so that I can give you access to lib 19 to exchange these pearls of programming wisdom! Well that's the only time to look for it then <[Host] MIKE-ALLEN> CBARRON - actually the support for non-ST ram was added in 2.00. <[Bud] B.CONNOLLY1> the _FRB cookie points a 64kb buffer that may be used by DMA device drivers to transfer memory between 'alternative' RAM and ST RAM. <[Host] MIKE-ALLEN> Bud - I haven't figured out how to use that 64k buffer. <[Keith] K.GERDES> Look at $5a4 and $5a8 for the alternative RAM. <[Host] MIKE-ALLEN> Bud - I think "alternative" is a better choice of word than "TT." <[Sean@TWP] P-DIRECT> It takes much more effort to type alternative, though. And as long as we all understand that TT RAM is "alternative" RAM then there shouldn't be any problem. <[Keith] K.GERDES> The _FRB cookie is a 64K buffer in ST RAM for DMA device access. The memory is copied from ST RAM to TT (Alternative) RAM. <[Host] MIKE-ALLEN> Keith - how does this copy take place? Is it automatic or does the prorgram have to manage it? <[Keith] K.GERDES> It's up to the program. <[Host] MIKE-ALLEN> Aha! Thanks <[Keith] K.GERDES> The only program that really needs the _FRB is the hard drive handler. Hey should we also check _drvbits for present drives? <[Bud] B.CONNOLLY1> another good one. Keith - or any other DMA device handler... <[Host] MIKE-ALLEN> What I suggest is that we press on with the "what am I" routines and liven up the discussion in 3/11 in anticipation of the "what is my state" routines. ok <[Parrot Head] C.CASSADAY> sounds good to me <[Host] MIKE-ALLEN> Tom - very good point. What drives, are there hard drive partitions, etc. Is it necessary to check the hd driver sw and version? <[Keith] K.GERDES> Correct. Now where's that LAN driver... ;) <[Host] MIKE-ALLEN> Keith hehe. Go for it. <[Bud] B.CONNOLLY1> HD driver...I don't think you would need to check it. <[Keith] K.GERDES> The Atari hard disk handler has docs with details. I'm not sure about the others. <[Host] MIKE-ALLEN> I guess we could ask ICD. Keith - think it is neccessary to check the hd handler version? Probably wouldn't hurt. <[Keith] K.GERDES> I don't know which category the info fits into. What am I or What is my state. :) <[Host] MIKE-ALLEN> Ok, folks - general chatter time. I'll kill the capture buffer. Keith - I'd say "What am I" <[Host] MIKE-ALLEN> I'll try and make a summary (lots of luck) to place in 3/11. I will post a couple of routines in lib 19. Let's get some chatter going in 3/11. Remember, EMail me for access to lib 19. Think about the "what is my state" requirements. Maybe we can actually discuss code next time. Next time, BTW is 2 December. Homework assignment: How do we determine the "What am I" items mentioned so far in the RTC. I will post them is 3/11. Programming Real Time Conference December 2, 1993 Host - Mike Allen <[Host] MIKE-ALLEN> Ok folks, the capture buffer is on. good behavior, everyone. The response in cat3/top11 and in lib 19 has been underwhelming, There have been 3 uploads to lib 19 and two of them were mine! I think Keith may be right in that we need a "homework" assignment for each meeting. So far the uploads have been cookie jar routine from me (old and new versions) and blitter routines from T.MACK. Gee I forgot which mike to email. C access to cookie jar than is ansified, from atari docs. A side note Lexicor's cards install a cookie. Details [in german ] are coming to me. <[Host] MIKE-ALLEN> What I would like to suggest for the next meeting (16 December) is everyone try to write a prg that will at least report the TOS, AES and GEMDOS versions to the screen. More if you want. <[Host] MIKE-ALLEN> Let me go around the horn and see what people think. <[Host] MIKE-ALLEN> Bud - your thoughts? ga <[Bud] B.CONNOLLY1> Sounds good to me. <[Host] MIKE-ALLEN> Keith? ga <[Keith] K.GERDES> Me too... You might have a Q&A time each RTC for people to get answers in realtime. ga <[Host] MIKE-ALLEN> Good idea, Keith. <[Host] MIKE-ALLEN> E.MONACO - your thoughts? ga I think giving assignments should improve participation... I for one really look for the opportunity to pick my fellows programmers brains :) ga <[Host] MIKE-ALLEN> Thanks. BTW, since Scott is here, I'd like to mention that he has given me permission to quote the Compendium on the official Atari cookies. Thanks Scott. That will be up soon. <[Scott @ SDS] S.SANDERS2> No problem, Mike... <[Host] MIKE-ALLEN> CBARRON - your thoughts? ga So far I have that solved, but for tos version,in my head. but something is better than nought. What is a $00aa0066 cookie? there is one on my TT. ga <[Host] MIKE-ALLEN> I noticed that the Atari Mouse accelerator puts up a non ascii Cookie. Could that be it? ga Might be maccell is installed ga <[Host] MIKE-ALLEN> Probably is then. Scott and Charles, we are discussing a "homework" assignment for the next meeting. I proposed a simple prg that would display AES, TOS and GEMDOS versions to the screen. Charles, your thoughts? ga Seems simple enough to do... <[Scott @ SDS] S.SANDERS2> Yeah, I have a similiar program I wrote in Ataridev... <[Host] MIKE-ALLEN> I thought we should maybe start simple. Might be some useful routines to come out of it (like hex to ascii conversions, etc.) There wasn't a very big response asking folks just to post routines. <[Host] MIKE-ALLEN> J2 - I managed to miss you. Your thoughts? ga <[John too] J.G.H.> Are there any other "Non-programmers" about? ;> You don't want to scare any 'lurker' types away that might want to learn a thing or two also ;> ga <[Host] MIKE-ALLEN> J2 - don't be so bashful! Well, what do you want to discuss now, all? Pandimonium time! <[Bud] B.CONNOLLY1> A possible topic for a future RTC, Debuggers/Monitors, their care and feeding. I have Tempelmon, Sysmon and the one in the Prospero Workbench, but I really don't know what to do with them. <[John too] J.G.H.> The only language I do have is GFA Basic and it has sat on the shelve for probably a year or so Bud Sysmon can be a very powerful developement tool. I've been playing with it and find it very useful. <[Host] MIKE-ALLEN> Bud - I have yet to figure out Templemon. I use MonST and AMonst from HiSoft. <[Keith] K.GERDES> I must agree about Sysmon. Anybody know the status of it. Falcon version? <[Bud] B.CONNOLLY1> Then, there is room for discussion on that topic? <[Host] MIKE-ALLEN> Decent english docs for templemon would help. <[Bud] B.CONNOLLY1> I could use some of your experience When I use a debugger it is one of the monST variants. <[Host] MIKE-ALLEN> Sure, if we can find some templemon/sysmon experts. <[Keith] K.GERDES> I'm not an "expert" at Sysmon, but I'll help... :) Keith, version 1.05 (I believe) uses a neat technique to find the various system variables, etc it needs to work... I think its biggest incompatibility would be with its custom screens/menus. I'll help with sysmon too. <[Host] MIKE-ALLEN> How about I shedule up one of our dates in January for a sysmon/templemon rtc? Sounds like keith and erin will be our resident experts. <[Scott @ SDS] S.SANDERS2> I have familiarity with both of those... I haven't been able to get the new version of Templemon to work with MultiTOS though... <[Host] MIKE-ALLEN> Aha, Scott also. It might work on a falcon in hires (ST) mode. Yes, its Erin. <[Keith] K.GERDES> How recent is 1.05? <[Bud] B.CONNOLLY1> I knew I could root out some help here. <[Host] MIKE-ALLEN> You three - which date would be the best? the 1st or 3rd thursday in January? ga Hmmm, winter classes start 6th of january, I don't think I have any for thursday nights so I'm open <[Keith] K.GERDES> That's the 6th or 20th. Either one. ga <[Host] MIKE-ALLEN> Scott? ga Keith, latest version I've seen... pulled it off umich before KA9Q broke. <[Host] MIKE-ALLEN> KA9Q broke? <[Scott @ SDS] S.SANDERS2> What, I have no life... i.e. no real preference :) <[Keith] K.GERDES> Ok. I looked around the German FTP sites, but only found Templemon. I use MonST on all machines, so that's not my forte. <[Host] MIKE-ALLEN> Let's set it up for the 20th then. Give everyone time to get their questions lined up and our experts prepared. Sound ok all? <[Bud] B.CONNOLLY1> Keith, where can I get monST? Is it commercial, PD or shareware? Basically I had to install the control.acc in three slots... and then run Sysmon... (something like that) as it could not find the vectors etc, it needed for tos 1.62 sounds ok <[Bud] B.CONNOLLY1> 20th is a go. <[Host] MIKE-ALLEN> Bud MonST is commercial from HiSoft. isn't there a monST in the PD release of DevPak II? <[Bud] B.CONNOLLY1> thanx Mike. Are the docs worth the price tag? <[Keith] K.GERDES> The old "CONTROL.ACC" trick. I did that on the TT once. <[Host] MIKE-ALLEN> I didn't think DevPac 2 was PD. <[Keith] K.GERDES> I'll try it on the Falcon. Thanks. Sounded weird but it worked. :) Hmm. wasn't it in ST Format or something. <[Keith] K.GERDES> If we're gonna talk about a program, shouldn't we post a file # reference for everyone to download? <[Host] MIKE-ALLEN> Bud - monst is part of their devpac. Don't think it is sold separately. Keith, what should be in the file? <[Bud] B.CONNOLLY1> Oh, I've been looking at Devpac 3 as a replacement for Assempro. JUNE 1993 Atari ST User disk... Exclusive DevPacST 2 <[Keith] K.GERDES> If we talk about Sysmon and Templemon, people need them. Right? <[Scott @ SDS] S.SANDERS2> I noticed in the transcript of the first Programming RTC you mentioned a module to parse .INI files. I just completed one for Icon Wizard and I'd be happy to upload the source if it might be useful. Bud I used Assempro DevPac definitely is better. Devpac II did appear on an ST Format Disk, I do not think it is pd. MonsT is included with DevPac, a variant in Lattice C and some other language products of HIsoft. opps wrong magazine. It was a cover dsk. <[Host] MIKE-ALLEN> Aha - yes. Is Sysmon on GEnie? I know templemon is. <[Keith] K.GERDES> Once you've tried DevPac, there's no turning back. It's the best- bar none! I have only seen sysmon on the net... <[Bud] B.CONNOLLY1> Mike, if it isn't, I can LZH my copy and upload it. Unfortunately I don't have the complete archive, so I couldn't distribute the version I have. <[Host] MIKE-ALLEN> I haven't installed Devpac3 yet that I bought at Glendale. Still using ver 2. and now they've got an update to 3.10! <[Host] MIKE-ALLEN> Bud - are there any docs with it? ga <[Bud] B.CONNOLLY1> I should have the complete set, I can't say for sure since I haven't looked at it in a while. Sysmon is shareware with a pricetag of $40 for non-commercial use. $80 for commercial use. <[Host] MIKE-ALLEN> If you would upload it, it would be appreciated. <[John too] J.G.H.> I have found DevPac 1 on a ST Format ;> <[Host] MIKE-ALLEN> Is it from germany? DevPac II is in the june 1993 ST USER disk. <[Bud] B.CONNOLLY1> Yes, I do remember that I have a doc file with it, I'll upload tomorrow. <[Host] MIKE-ALLEN> thanks a bunch, Bud. I don't remember... probably a good bet though <[Bud] B.CONNOLLY1> Since I haven't uploaded before, should I put in our Lib 19 or somewher else? <[Keith] K.GERDES> Yes, Sysmon is from Germany. I think it should go in lib 2, make a good utility for anyone. <[Host] MIKE-ALLEN> Bud - just put it in lib 1 and the librarians will get it to the right place. Right J2? <[John too] J.G.H.> yes, unless it's for library 19 <[Bud] B.CONNOLLY1> ok, I'll LZH it and put it up tomorrow. <[Host] MIKE-ALLEN> I don't think this is for lib 19. That is kind of a private exchange for us. <[Host] MIKE-ALLEN> I think sysmon would have wider interest. lib 19 is to keep from exposing ourselves too badly. <[John too] J.G.H.> I was referring to any uploads ;> I don't know if the other Librarians would recognize a 19 program All you interneter's is there an executable package of Berkeley(sp?)YACC version 1.9 ported to the atari line. I got the *ix source, but would appreciate not compiling it. ga <[Host] MIKE-ALLEN> not Yet Another YACC! Wait for aeopj 3+ <[Bud] B.CONNOLLY1> When is that due out? <[Host] MIKE-ALLEN> arrrggggh! Just no more FLEX code <[John too] J.G.H.> You can put uncompiled programs in Library 19 ;> <[Host] MIKE-ALLEN> Lib 19 is for us to exchange things privately. If you haven't got access to it yet, send me EMail and I'll add you to the list. <[John too] J.G.H.> Mike while I am thinking of it...You might want to work up a Text file explaining the purpose of lib 19 and point it out to people you let in there. <[Host] MIKE-ALLEN> Ok, John, I will. Put it in 19? <[John too] J.G.H.> (along with a disclaimer) <[Host] MIKE-ALLEN> ye gads, a lawyer? <[John too] J.G.H.> Yes ;> Flex is just the beginning. Yacc specs are ussually recursive... ga I hate rec[rec[recursive]ursive]ursive] code :) <[Bud] B.CONNOLLY1> Oh, but it can be so interesting! <[Host] MIKE-ALLEN> Ok - seems I have a couple of action items. 1) get the cookie stuff from Scott posted (BB or lib 19?), 2) post a message in the BB noting our sysmon/templemon rtc on the 20th with file references to both . . .and something in the BB about our "homework" assignment. BTW anyone who finds info about non-Atari cookies might want to post in lib 19 also. What else do I need to take care of? E.MONACO - that ok, but yacc essentially specifies a 'language' to parse.. The surgeon general has determined re_curs_ive code as well as prolonged exposure to air to be fatal! <[Bud] B.CONNOLLY1> Find some decent English docs for Tempelmon! <[Host] MIKE-ALLEN> Try running them through Ger2Eng... I know that LEXICOR graphics cards install some cookie. I believe GRIBNIF's '' crazy' cards do also which one I do not know at this time. ga <[Bud] B.CONNOLLY1> I'd try running them through GER2EN30, but it leaves a little bit to be desired in the translation. <[John too] J.G.H.> Hehe Bud ;> very true. <[Bud] B.CONNOLLY1> Erin, GER2EN30 is just a straight word for word translation. Makes some strange looking sentances. Ah, haven't seen any of MY docs have ya! :) <[Host] MIKE-ALLEN> Ground rules for the homework - Should run on any ST/STe/TT/Falcon in any Rez. Source included with the executable in a ZIP or LZH to lib 19. Would be nice to see Assembly, C and GFA Basic version. <[John too] J.G.H.> I remember the original GER2ENG <[Host] MIKE-ALLEN> Back to the homework - either a .TOS or .PRG. .PRGs should be GEM! Sounds good. <[Host] MIKE-ALLEN> Where do you all want the cookie file: The BB or lib 19? what no gtp's lib 19 <[Bud] B.CONNOLLY1> Lib 19 Mike. <[Host] MIKE-ALLEN> Lib 19 sounds good to me too. >>>At this point Andreas (AEO.2) drops in to discuss his recent visit to Atari Headquarters. Much off-topic, but interesting discussion! [g]<<< <[Host] MIKE-ALLEN> Looks like this is degenerating. Any more programming stuff before I turn off the capture buffer? ga <[Bud] B.CONNOLLY1> kill it Mike. <[John too] J.G.H.> anyone here planning on programming for the Jag? <[Andreas@AEO] AEO.2> (I'll stop) <[John too] J.G.H.> <---always on topic <[Host] MIKE-ALLEN> We were about done, Andreas. Ok, capture off. ga folks jabber at will. /************************************************************************/ 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 --==--==-- -- --------------------------------------------------------------------------- /***********************************************************************/ USER VIEW By: Mike Allen /***********************************************************************/ =-=-=-=-=-=-=-=-=-=-=-=-=-= //// What USERS would like! =-=-=-=-=-=-=-=-=-=-=-=-=-= Now I consider myself a somewhat typical user. My thesis is that most Atari ST users (and face it, there are a lot more ST users than TT and Falcon030 users combined), have certain things in common. What are some of those things? Well, I believe that the majority of the users are using ST Medium Rez! This tends to be a much neglected resolution by developers. Also I think the average user would much rather "point-and-click" than use the keyboard. Developers are "power" users. Power users like ST Hi rez. They also like "hot keys" over the mouse. I suspect that a lot of developers would like to forget that a mouse is connected to the ST! This brings me to the first few of my user wants: 1) Check what resolution the system is operating in. Don't just assume that the user has read the manual and/or the read.me file that states "This program must be run in xxxxxx resolution." The least you can do is give a polite little alert box that says "This program only runs in xxxxx resolution." The let the user exit cleanly. Better is if your application sets the resolution for the user. Best is if the application is resolution independent. 2) Make ALL operations available from the menu bar and/or icons. Don't make the user HAVE to use the keyboard except for actual text entries. I'm not saying eliminate the "hot keys," but make the mouse your primary input tool. Nothing should be available from a "hot key" that isn't available somehow using the mouse. The "hot key" might actually be easier, but lots of people (like me) would rather click a few times than press a key. 3) Use the file selector! There is no excuse to have a user type in a path or a file name except to create a new file. Check to see if the machine supports fsel_exinput(). If it does, use the prompt line in the file selector. If it doesn't, assume that Charles F. Johnson's Little Green Selector is available and pass the prompt in that format. It won't hurt the regular file selector if LGS isn't available and looks nice if it is. 4) Don't blithely go over-writing files. If a file exists and your program is going to write to it, warn the user. Give the user the option to change the file name, backup the old file or abort the operation. 5) I personally hate install programs! Especially those which modify existing files like my DESKTOP/NEWDESK.INF file. Mods to the ASSIGN.SYS and EXTEND.SYS files scare me too. Install programs all too often write files without checking if files of the same name exist. (Bravo to Atari. Their SpeedoGDOS install program has the courtesy to rename existing ASSIGN.SYS and EXTEND.SYS files as ASSIGN.OLD and EXTEND.OLD.) 6) Don't get "cute" in your program. There is no need to re-invent the file selector or change the look of the standard GEM window. If folks want fancier selectors or windows they will probably be using an alternative file selector or desktop. They might even be using a Falcon, MultiTOS or Geneva. 7) Don't "cheat" TOS. I know that it is very tempting to "do things better than Atari," but you'll probably end up with a product that will break on some present or future version of TOS. Check the AES, GEMDOS and TOS versions. Look at the Cookie Jar. Make your program live within the parameters of the system upon which it is operating. If you don't care to support earlier versions of TOS, plainly state that in your advertisements and packaging. Here are some more problems that I find highly irritating. Irritating to the point that, unless the program is really special, I'll dump it immediately. 8) Let the user be able to exit your program! I really hate programs that only let you quit by pressing the reset button. Flat out, there is no excuse for that. 9) Leave the system the way you found it. If you change ANY user configurable item, restore it when the program exits. This includes stuff like resolution, palette, key-click, system bell, repeat rate, etc. Be courteous to your customer. Finally we come to protection schemes. (Are you listening Psygnosis and Silmarils?) 10) If you absolutely MUST use a key disk scheme, don't make the floppy drive do things it wasn't designed to do. Keep in mind that machines like the MegaSTe and the TT are MUCH more sensitive to strange disk actions than the old STs. (I have to boot Lemmings 5 to 10 times before it will finally run. Ishar II fails its test about 1/2 the time. I'm still using a 720k drive and I've changed it and re-routed cables trying to get more reliability on these two games.) People also get upset when the heads get banged against the stop so often and so hard that the drive goes out of alignment. 11) An extension of the above. Do your key disk check ONCE and at the beginning. Don't go through a bunch of fancy opening screens before doing your key disk check. Don't check it every time the user loads a saved position. 12) Better yet, don't use key disk protection. "Find the Nth word on page so-and-so" works fine if you have a large manual. Code wheels (Their Finest Hour) or non-Xeroxable key cards (SimCity) work fine. I'm getting to my final salvo. You won't have to read much further. 13) Make sure your program will take advantage of a second floppy drive or a hard drive, if available. I know that I haven't bought (and won't buy) B-17 because it won't run on a hard drive. Also don't assume everyone uses GEM partitions on a hard drive. Some of us use BGM and even XGM partitions. 14) DOCUMENTATION! Have someone other than the programmers write the documentation. Preferably a "typical" user. A good index is essential to a complex program. Organization and ease of reading is required. Examples and tutorials are hard to beat. Screen shots are nice. 15) Error checking. Don't allow your program to bomb just because a user forgot to select a file name in the file selector. Look at the return codes of the various system calls to see if the return was successful. Handle error conditions in an intelligent manner. Don't just bomb. 16) File handling. Don't keep files open any longer than necessary. A power failure could do nasty things to your customer's system if it happens while a file is open. Be smart about what you can do in memory and then transfer to a file in one quick burst of activity. 17) Quality. Test the pants off your new application. Use beta testers who are NOT developers. Use intelligent, observant testers. Supply a "bug" report form that is a "fill in the blank" type - auto programs, accessories, TOS version, hard drive software, etc. The more organized your form is, the more complete the data you will receive are. 18) Customer Service. Don't ignore your customer once you have his money. Developers like Gribnif and CodeHead benefit from their excellent customer service. They are available by snail mail, on-line services, BBSs and even telephone and fax. They are always responsive, even to abusive customers. Customer service is their stock in trade. Atari could take some lessons in customer service. They have suffered badly from a lack thereof! I guess I have "curmudgeoned" enough for now. Am I off base? What other "pet peeves" have I missed? I'm sure AEO-PJ would like to hear from you. /************************************************************************/ Brain Stem Rotator By: Albert Dayes /************************************************************************/ 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 /*************************************************************************/ 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 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 Prentice Hall Englewood Cliffs, New Jersey 07632 USA NCSA (National Computer Security Association) 10 S. Courthouse Ave Carlisle, PA 17013 USA (717) 258-1816 (717) 243-8642 (fax) Computing Professional Organizations: ACM (The Association for Computing Machinery) 11 West 42nd Street New York, NY 10016 USA (800)-342-6626 (212) 869-7440 (212)-626-0500 E-mail: ACMHELP@ACM.org ACM European Service Center Avenue Marcel Thiry 204 1200 Brussels, Belgium Phone: 32-2-744-9602 Fax: 32-2-774-9690 E-mail: ACM_Europe@ACM.org IEEECS (The Computer Society of the Institute for Electrical and Electronics Engineers) Membership Department 445 Hoes Lane, PO Box 1331 Piscataway, NY 08855-9970 USA (202) 371-0101 /***********************************************************************/ 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++ * GEM++ Class library * 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. /************************************************************************/