/*********************************************************************** Title: AEOPJ1.TXT Last Modified: August 19, 1993 Purpose: First 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] GFA BASIC columnist = Eric Goodman [GE: AEO.6] OBJECT::ATARI columnist = Warwick Allison [In: warwick@cs.uq.oz.au] Contributing: Ed Krimen [AEO.5] J.J. Lehett Ron Robinson [EXPLORER.1] /***********************************************************************/ Table of Contents: * Editorial & Welcome * Meet the Authors -- short biographical notes on the authors * BASIC Column -- Eric Goodman introduces GEM programming with GFA BASIC * C Column -- First steps to learning C programming * Advanced Computing -- Carl Barron takes a look a FLEX * Hard Core -- Interview with Greg Comeau, developer of Comeau C++ * Bad Example -- Do you really want to do that? * Practical DSP -- Ron Robinson discusses Digital Signal Processing * LIB [ new file(s) ] -- A first look at the C Users Group CD-ROM disc * Periodicals -- A magazine just for C programmers * OBJECT::ATARI -- J.J Lehett & Warwick Allison examine OOP ideas * Language Watch -- Current versions of developer tools * On the Networks -- Interactive programming on-line * Network Sign-up Information * User View -- Ed Krimen discusses computing from a user's point of view * 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: "Thank Atari for ST-BASIC" By: Albert Dayes /***********************************************************************/ When the Atari ST was first released many Atari 8-bit BASIC programmers waited to use ST-BASIC on their new machines with bated breath. All were greatly disappointed with its look, feel and lack of features. They then turned their sights on other languages like C and Assembly (and GFA BASIC) and started the tradition of programming the Atari ST. As the Atari market changed in many ways the development tools still continued to get better all the time. Not only did they get better, but a greater variety of development tools continues to increase. Many programmers are finding very useful tools in source code form on other platforms and porting them to the Atari at a tremendous rate. This is a good sign and I hope this trend continues on at a faster pace. Welcome to Atari Explorer Online - Programmers' Journal. This supplement is dedicated to programmers of all types from the hobbyist to commercial and specifically for Atari ST/STe/TT/FALCON030 programmers. There are several goals to AEO-PJ: A) One of them is in the spirit of David Small ... share code. This does not mean trade secrets but just useful code that everyone can benefit from. There are many aspects of GEM that can benefit from this idea. B) Have a large on-line database (maybe even on CD-ROM) of working code to help programmers get GEM applications up and running much more quickly. Have modules that one can link in or merge in source code form to perform some of the necessary parts of GEM without having to rewrite it every time. This is even more of an issue when a developer comes from a different platform. Also this is not limited to GEM and can be easily extended to other programming areas. C) Provide references for other periodicals that provide more in depth information on a particular subject. There are many good programming magazines out there and sometimes they cover a certain programming problem in much more detail. This list includes C Users Journal, Dr. Dobb's Journal, Computer Language, etc. Also there are many good books that can be reviewed or referred to as well. D) Remind us of what users are looking for as features in the software products they purchase. E) Make programming what it always should be ... FUN!!! F) A Trillion lines of new code per day! Special thanks to the Atari Explorer Online and Atari Explorer staff for their input and "debate e-mail" for making this all possible. Also to all who have not been mentioned and should have been. /**********************************************************************/ Meet the Authors /**********************************************************************/ //// Warwick Allison: Warwick has a BSc with first class honours in computer science. He has owned Atari computers since 1982, and has been programming in C++ since the beginning of 1992. He is currently involved in research into language-based editors at the University of Queensland in Australia. //// Carl Barron: I started programming in FORTRAN II back in 1965, while getting a degree in Mathematics, from SUNY at Buffalo. I did write parts of the arithmetic library code for "student" FORTRAN compiler for an IBM 360, various code on an IBM 7044 and CDC 6400, (all obsolete and less powerful than an ST with a 9-track tape unit or two, but required strict climate control). I no longer write code for a living (too many ulcers for me ). I write code for fun these days, and this ATARI platform is a joy to use for that. My main interests are mathematical and scientific. I hate reinventing wheels. Telecomunicating two hours+ a day is the real major use, of this system. I am on GEnie and Compuserve daily in a multiple number of places therein, mostly lurking, but sometimes "vocal." I'm also the editor of a newsletter, disk librarian, an a director of a user's group. Between these duties and programming for fun and making a "few $" for living, writing for AEO-PJ (seems to be a natural thing to do). I have little time for games but have lots of fun programming. It is very gratifying to get a solution to a problem! //// Albert Dayes: Albert has a BSc in Computer/Science and has been enjoying Atari products since 1978. His current areas of interest include filesystems, CD-ROM, PostScript and Scuba Diving. //// Eric Goodman 1981 My first computer was a Commodore Vic 20. I learned the CBM BASIC programming language built into the computer. 1982 Purchased my first Atari Computer, the Atari 400. I continued programming in BASIC for over 4 years developing experience. 1984 Purchased Atari 800XL. Specialized in programs for the 8-bit Ataris in 8-bit BASIC. Started advanced programs with 800XL. Worked with a Macintosh 512KE and IBM computers. 1987 Purchased 520ST. Programmed very little in ST BASIC. 1989 Started programming in GFA BASIC. Attended classes for Multimedia and Computers using NewTek Video Toaster, Macintosh Computer Systems, and Time Code Video Editing Systems. 1991 Started developing professional applications in GFA. Working with Still Video Cameras/Digitizers. 1992-93 Learning C and 68K Assembly along with 56001 DSP Assembly. Still developing heavily in GFA BASIC. Extensive experience with Amiga Video Toaster 2000. Began working with Roland JD800 MIDI Keyboard/Synthesizer. Presently Developing Time Code Editing System for NEC PC VCR Systems. Consulting for Multimedia Systems and Tutoring Programmers and Application Tutoring. System setup and configuration for new IBM Multimedia Hardware. Developing and publishing applications and utilities created in GFA BASIC. Other: Following new developments in Virtual Reality Technology. Staying informed on latest developments of Multimedia Hardware for Home/Small Businesses. Demonstrating Atari Computers to Educational Institutions and Professional Organizations. Follow new developments of Compilable BASICs for ALL platforms. Vice President of Phoenix ST User's Group. Promoting Falcon030 for Multimedia Applications. //// Ed Krimen Ed Krimen has been using Atari ST computers since 1987, but has been tracking them since their debut in 1985. He enjoys his position as a technical support specialist for Macromedia, Inc., a multimedia software company in San Francisco. He spends most of his free-time on GEnie and the Internet, and loves to play basketball. //// J.J. Lehett J.J. Lehett was strongly in favor of starting the Object Atari column but job constraints did not allow him to continue the column. On a good note he pointed us to Warwick Allison who wrote the GEM++ library who gladly agreed to continue with the column. J.J. will be missed. //// Ron Robinson Ron Robinson has been involved in home computering since the mid- 1970's when he built an Altair 8800B with a whopping 1K of memory and toggle switch/LED front panel user interface. He has owned Atari computers starting from the Atari 400 days. His first ST came in a 260ST box and he has managed to collect one of each Atari computer including several Falcon030s. He started writing about the Atari computer through the local users groups in 1986. Since 1988, over 80 of his articles and reviews have been published in Atari magazines, including ST Informer, Atari Advantage and Atari Explorer Magazine. He has served as a GEnie on-line representative for these magazines over much of the same period. To support his computer habit, Ron is a project manager for a major international biotechnology instrumentation company specializing in immunodiagnostics and infectious disease testing. He holds a BSc degree in Engineering and a MSc degree in Computer Science. In his spare time, he teaches courses in engineering and computer technology at a local university, plays tennis and teaches Pattie the Wonder Dog how to fetch the morning paper. /**********************************************************************/ BASIC Programming Column By: Eric Goodman /**********************************************************************/ //// INTRODUCTION Ever since the first computer programmers, man (and woman) have dreamed of developing computer software in a quick, easy, and efficient environment. They wanted speed and compatibility but they also wanted power. They did not want to spend an eternity learning a new machine language. They wanted clean, clear, and easy to read code. They wanted all of this in one simple language. And they got it (well they almost got it). The language was BASIC. Many different BASICs have come and gone. These BASICs were not powerful, they were not fast, and they certainly were not very efficient, they didn't even compile. They required some type of interpreter to execute. For obvious reasons, this was unacceptable, so a new type of BASIC was invented. These new BASIC programs could be compiled into stand-alone applications. Applications that did not require an interpreter to execute. This new BASIC was a COMPILABLE BASIC. GFA BASIC has, recently, evolved into a compilable BASIC. However, there are many things that set GFA BASIC apart from your _typical_ compilable BASIC. For example, your typical BASIC language uses line numbers. GFA BASIC does not. There are many advantages in not using line numbers. One advantage would be the management of subroutines. Subroutines, in GFA BASIC, are called by name, much like a lower level language (such as C). The advantages to this should be clear. Line numbers, simply put, "aren't programming" anymore. Another example that sets GFA apart would be its Editor. GFA BASIC's Editor uses a "forced" structuring system in which the editor automatically indents the code while in a loop or an if/then statement. It also indents while in a PROCEDURE. This allows for clear, straight-forward, source code. And, with the Editor's automatic syntax checking, it will not allow a loop or an if/then statement to remain open. Thus, eliminating a number of potential bugs, almost immediately. Finally GFA BASIC offers power. It offers the power of a low level language yet in a BASIC language environment. With a command such as INLINE, and easy access to GEM, GFA's power and flexibility become apparent. With the INLINE command a programmer can use assembly routines that may not be quick or efficient enough to be written in BASIC. The INLINE command may also be used to store resources, pictures, compressed data, _anything_ a programmer wants embedded into the program. This offers many new possibilities within GFA programs, as opposed to other BASICs. Which brings us to GEM. I didn't say "_easy_ access to GEM" in that last paragraph did I? _EASY_ access? Yes I did, and I meant it. At first GFA's GEM access may look confusing and too much of a pain to worry about. The typical response is, "...no problem, I'll just use GFA's version of the GEM commands." For those of you who don't know what I am referring to, some of these commands are, for example: ON MENU, MENU KILL, MENU OFF, OPENW, CLOSEW, CLEARW, FULLW, INFOW. "...But those commands are easier to use, Besides... they work." Well, little do most GFA'ers know, those commands are highly incompatible, they are buggy, and they, certainly, are not reliable. But most of all... They are not Atari legal! Yes, ladies and gentlemen, boys and girls, you _are_ breaking "The Law." This is why _I_ am here.... To keep all of those outlaws, renegades, and misfits, out there, in line. GEM is the Final Frontier, it is the last unexplored region of the GFA Galaxy. This article will be the first in a series that will guide GFA BASIC Programmers, beginner and advanced alike, through the mysterious workings of this awe inspiring, yet powerful Graphical User Interface. Throughout the series you will be aided by well commented, sample GFA BASIC source code along with tips and techniques for improving your GFA Programming skills. You may leave me GE Mail at AEO.6 regarding any questions, suggestions, and GFA programming mishaps. //// GEM Events The first item on our "GEM Agenda" will be GEM Events. An Event is what GEM uses to communicate with our programs. An Event Message is a detailed description of what event has occurred within the GEM Environment. For example, if you select a menu item GEM will pass a number indicating an event has occurred. In this case a selected menu item passes event number '10'. Different GEM Events are assigned a different number (Refer to your GFA BASIC manual or Atari Developer's Documentation for a complete list of GEM Events and their corresponding numbers). Next, you must find out what menu item was selected. When a GEM Event occurs not only is the event _number_ passed but also the detailed information about the event. This information is stored in an Event Message Buffer which you must define. You will be learning how to define a Message Buffer for GEM Events and read them as fields of data. EVENT_MULTI() will place the event number and any information about the event in the Message Buffer. The _pointer_ to the Message Buffer is one of the parameters passed in EVENT_MULTI(). Other parameters passed in this function will determine what specific GEM Events are returned and _when_ they are returned (Refer to your GFA BASIC manual for the function and parameter definition). If you downloaded the Programmer's Journal Source Code Archive refer to the file 'GFA_GEM1.LST'. This file contains the following source code: ' ** AEO Programmer's Journal Source Code File GFA_GEM1.LST ** ' ========================================================================== ' EVNT_MULTI() - Message Buffer Allocation & GEM Event Test ' ' DESCRIPTION: This GFA BASIC source code will allocate a GEM Event Message ' Buffer and open a GEM Window. If an Event occurs it will check ' the appropriate Message Field for information and adjust the ' window accordingly. The drag and close functions are the only ' working window functions. By using the existing code and what ' you will learn from its comments you must add your own code to ' enable the window to respond to the SIZE event. You may also ' refer to your GFA Manual. ' ' NOTE: The window creation code will not be commented in this example. GEM ' Windows will be explained, in detail, in the another article. ' ========================================================================== ' ' -- Event Message Buffer and Field Definition ----------------------------- ' DIM evnt_msg_buf%(3) ! Allocate 32 bytes for the Buffer msg_buf%=V:evnt_msg_buf%(0) ! Set a pointer to the start of the buffer ' ABSOLUTE evnt1&,msg_buf% ! GEM Event Message Field Definition: ABSOLUTE evnt2&,msg_buf%+2 ! Use the ABSOLUTE command to set the pointer ABSOLUTE evnt3&,msg_buf%+4 ! of a variable. These variable names are ABSOLUTE evnt4&,msg_buf%+6 ! set corresponding to the GEM Message Fields. ABSOLUTE evnt5&,msg_buf%+8 ! The different characteristics of an event ABSOLUTE evnt6&,msg_buf%+10 ! can be found in a given field. Each data ABSOLUTE evnt7&,msg_buf%+12 ! field is of word length (2 bytes). ABSOLUTE evnt8&,msg_buf%+14 ABSOLUTE evnt9&,msg_buf%+16 ! (Refer to the GFA Manual or Atari Dev. Docs ABSOLUTE evnt10&,msg_buf%+18 ! for information on the Event Message Data. ABSOLUTE evnt11&,msg_buf%+20 ! And the GFA Manual for the ABSOLUTE ABSOLUTE evnt12&,msg_buf%+22 ! command definition.) ABSOLUTE evnt13&,msg_buf%+24 ABSOLUTE evnt14&,msg_buf%+26 ABSOLUTE evnt15&,msg_buf%+28 ABSOLUTE evnt16&,msg_buf%+30 ' ' -------------------------------------------------------------------------- ' ' -- Open Window ----------------------------------------------------------- ' --This window is opened only for demonstration purposes. ' --Windows will be explained in another issue. ' window&=WIND_CREATE(&X11111101111,15,25,250,150) wind_name$="AEO-PJ Test" adr_name%=V:wind_name$ ~WIND_SET(window&,2,CARD(SWAP(adr_name%)),CARD(adr_name%),0,0) ~WIND_OPEN(window&,15,25,250,150) ' ' -------------------------------------------------------------------------- ' ' -- Main Event Loop ------------------------------------------------------- ' DO ! Always put EVNT_MULTI() in the MAIN LOOP event|=EVNT_MULTI(&X111111,1,1,1,0,0,0,0,0,0,0,0,0,0,msg_buf%,0) SELECT evnt1& ! The Event number is stored in evnt1& CASE 28 ! Event 28 means a window has been dragged ~WIND_SET(evnt4&,5,evnt5&,evnt6&,evnt7&,evnt8&) ! Change window position ENDSELECT ! Use Msg Buffer Fields for information on LOOP UNTIL evnt1&=22 ! the dragged Window. Notice the Desktop ' ! Updates. (automatic when using GEM) ' You must now determine which Event number indicates a WINDOW SIZE CHANGE. ' Then obtain the correct information for adjusting its size. Use the ' ~WIND_SET() GEM function to set the window's size. GEM windows will be ' covered in another issue of AEO Programmer's Journal. However, there is ' plenty of information above to complete the task. Once you have achieved ' this, try enabling the WINDOW FULL function. ' ------------------------------------------------------------------------ ' ' -- Close Window -------------------------------------------------------- ' ~WIND_CLOSE(window&) ~WIND_DELETE(window&) ' ' ------------------------------------------------------------------------ END In the next issue of AEO Programmers' Journal we will be covering GEM Menu bars using the EVNT_MULTI() function. Using what you have learned in this article, try creating a GEM Menu and reading its Events using the same method as the Window Events. /***********************************************************************/ C Programming Column By: Albert Dayes /***********************************************************************/ Defined in a few words, programming is problem solving. As in real life, it is a love and hate relationship. When learning to program there are a few things one needs to know. The first is knowing what the problem is. If one does not understand the problem one cannot solve something one does not understand. The syntax and semantics is the other part to programming. Syntax is basically rules that govern the language you are programming in. Some syntax errors are spelling errors and just like in normal writing these can cause problems. There is more to syntax errors than that but is just a method to think about them. The next part is semantics which is the meaning of the word, expression or symbols. It also deals with the relationship between words, expressions and symbols. Another important aspect to programming is being consistent. Having a uniform structure throughout the program makes very good sense. Be generous with spacing and make it easy to read is the final important issue. In C we have a compiler which changes the words written in a text editor into tokens and finally into a runable program. On the Atari we have several choices for compilers. There are a few freeware/shareware compilers like Heat & Serve, GCC and SOBOZON and commercial compilers like Pure C and Lattice C. The C compiler used in this column will be the Pure C compiler. There standard used by the commercial C compilers is the ANSI C standard which is the most current standard available for C. This column will stick to this standard as much as possible. If significant differences between K&R (the pre-ANSI format) to ANSI this column will do its best to point them out. The book that defines the ANSI standard is "The C Programming Language" (2nd edition). Make sure that its the second edition since there are older versions of the book still available. Type in the following into your text editor, compile, link and finally run the program. You may have to refer to your compiler documentation for more information on compiling or linking. Also make sure you save the file in ascii format. Make sure you use lower case when typing in the text. Next time we will discuss macros, variables, functions and much more. NOTE: If your compiler supports ANSI C use the first one and if not then your C compiler is a K&R (pre-ANSI) compiler. <=== cut here ANSI code begins ===> #include main(void) { printf("hello atari world\n"); return 0; } <=== end === > <=== cut here K&R or (non ANSI) code begins here === > #include main() { printf("hello atari world\n"); } <=== end ===> /***********************************************************************/ Advanced Computing By: Carl Barron /************************************************************************/ An introduction to FLEX (c)1993 Carl Barron. This article can be reprinted in its entirety for non-commercial purposes. Commercial usage is reserved. This is the first in hopefully a long series of articles describing FREE programming tools available on the ATARI m680x0 platform, for C programmers. If you have any questions, ideas, etc. please send email to the addresses above. I will attempt to answer the questions in future articles if they are general, specifics I may or may not answer in email. I use Lattice C5 at this time and all code I write in these articles will be LATTICE C5 compatible. I will not specifically write old style C but for what little C code there will be, it will be left to the reader to get it to compile on your old C compiler. Flex237 is NOT COMPATIBLE with MWC 3.x and if that is your compiler sorry, but Mark Williams blew it with respect to __STDC__. Flex will produce old style C, ANSI C or C++ compatible C for its output. So just about any C compiler will do. A C compiler is required to use many of the tools to be discussed. I will assume you are familiar with a C compiler and how to execute an external tool in your Compiler's environment. Flex is a descendent of lex a UNIX(tm) tool to generate pattern scanners. Flex is pd and is distributed under the GNU agreement, which essentially states that the source code to flex must be freely available. You can do what ever you want with the result file (lexyy.c), since there is no copyleft. A pattern scanner is a subprogram that reads input data and breaks it into smaller pieces based on what it finds. Flex reads input data and attempts to match it to regular expressions. When it finds at least one that matches it chooses the longest and first rule that matches. That is, it finds the longest match, if there is more than one longest match it chooses the first pattern from its source file, so that order of regular expressions in the flex source file can be very important. A flex program consists of ascii text, any text editor or word processor capable of saving in 100% 7-bit ascii and no word processor control codes is fine. Flex will read files ending in '\n' or '\r\n' just fine. So that UNIX(tm) source can be used directly if desired. The basic format of a flex program is: declarations %% rules %% additional code Declarations are flex macro redefinitions, global variable declarations, function prototype/declarations and other initial C code that needs to appear near the beginning of the file. The declarations can also define pattern names, and start sections (more on as we go along). The C code must be indented or contained in %{,%} blocks. The rules are the form pattern spaces_tabs action The action is C code to execute if the scanner generated recognizes the pattern. If it is all on the same line no {}'s are required, if it extends beyond a line it must be enclosed in {,}'s or %{,%}'s. If it the latter is used no account to the balance of {,}'s will be taken into account. Otherwise it will end the action code where the {,}'s balance. This is to allow conditional compilation, or what have you have code that looks at this stage as if the brackets are unbalanced. The pattern is a regular expression. These are recognized in order of precedence highest to lowest: x match character x. . match any character [xyz] character class match any character in the class. [abj-oZ] matches an a,b,letters j through o and capital Z. [-a] matches a '-' or 'a' [^xyz] negated character class matches any character not in the class. r* zero or more occurrences of regular expression r. r+ one or more occurrences of regular expression r. r? zero or one occurrence of regular expression r. r{2,5} 2 to 5 (inclusive) occurrences of r. r{2,} 2 or more occurrences of r. r{4} exactly 4 occurrences of r. {name} name from the definition section expanded and enclosed in ()'s. "abc" literal string abc, quotes inside a string need to be written as \". "\"hello\"" is "hello". \X where X is in [abfnrtv] the ANSI C '\X' char. \123 octal value 123. \x2a hex value 2a (r) parenthesis used to override precedence. rs regular expression r followed by regular expression s. r|s Either regular expression r or s. r/s r, but only if followed by an s. (r,s are regular expressions). ^r regular expression r at the beginning of a line. r$ regular expression r at the end of a line. r an r, but only if scanner is in start state sc. r an r, but only if scanner is in start state sc1 or start state sc3. (can be any number of comma separated start states if desired). <> an end of file. <> an end of file when in start state sc1 or sc2. Declarations can name common occurring subexpressions. the format is: . Additional code is copied verbatim by flex to the output file lexyy.c. This stuff out of the way, lets get down to basics! What can I do with flex? The general answer is just about anything that searches for patterns in a file, or keyboard input. I will start off with a simple word counter, wc.l which except for the lack of options is very similar to the UNIX(tm) tool. /* start of wc.l */ %{ long wcount,lcount,ccount;/* declare our counters */ %} %% [^ \t\n]+ {++wcount;ccount+=yyleng; /* got a word count it*/ } [ \t]+ {ccount += yyleng; /* spaces or tabs count them */ } [\n]+ {lcount += yyleng;ccount += 2*yyleng; /* newlines count them, take into account ST 'newlines' are two characters. */ } %% int main(int ac,char **av) { int newfile=0; /* flag for file changes */ while(--ac) /* for each argument on cmd line */ { if(!newfile) /* if first file just open the file */ { /* yyin, yylex()'s input FILE * */ newfile=1; yyin =fopen(*++av,"r"); } else { yyin=freopen(*++av,"r",yyin); /* otherwise reopen yyin */ if(yyin!=NULL) yyrestart(yyin); /* reconfigure yylex() for starting again */ } if(yyin==NULL) /* if we don't do this */ { /* yylex will set yyin to */ fprintf(stderr,"Can't open %s\n",*av); /* stdin and we don't want that */ continue; /* no error message written */ } wcount=lcount=ccount=0; /* reset our counters */ yylex(); /* count and display results below */ fprintf(yyout,"%s\t%ld\t%ld\t%ld\n", *av, wcount, lcount ,ccount); } return 0; /* return success */ } /* end of wc.l */ Note that all the 'gibberish' about determining what our input is, is hidden. Note how simple the code is. A word is non spaces or tabs or newlines. If you want to include form feeds, vertical tabs, the extension is fairly easy. You just enlarge the character classes [ \t], and [^ \t\n] to include them. The action code would not be changed unless you wanted to count more things like pages. I'll leave it as an exercise to page count. Don't forget about files with no line feeds! Next I will change all C++ // type comments to /* */ style it will nest any /* */ comments in the // comment however, /* ccpcmnt.l */ /* convert // comments to regular C comments */ /* the following start starts are used for quotes and both comment types so we do not translate //'s in C comments strings, or character constants. */ %x squote dquote ccomment sscomment %% \" ECHO;BEGIN(dquote); /* a double quote */ \' ECHO;BEGIN(squote); /* a single quote */ \\. ECHO; /* escaped char. */ "/*" ECHO;BEGIN(ccomment); /* C comment begin */ "//" fputs("/*",yyout);BEGIN(sscomment); /* C++ comment begin */ .|\n ECHO; /* anything else */ \" ECHO;BEGIN(INITIAL);/* done with quoted string */ .|\n ECHO; /* else continue string */ \' ECHO;BEGIN(INITIAL);/* done with single quotes */ .|\n ECHO; /* else continue scan */ .+ ECHO; /* echo to end of line */ \n {fputs("*/\n",yyout);BEGIN(INITIAL); /* end the comment */} "*/" ECHO;BEGIN(INITIAL); /* end of C comment */ .|\n ECHO; /* else continue*/ %% void main(int ac,char *av[]) { /* I will skip the usual error checking for brevity! */ yyin = fopen(av[1],"r"); yyout = fopen(av[2],"w"); yylex(); } /* end of cppcmnt.l */ INITIAL is the default start state, the one the scanner is in unless another is specified. yyout is the FILE * for ECHO which writes the matched string to yyout. What could be simpler to do this no headaches about setting flags and special conditions all straight forward. The start states are used to handle the subproblems of strings and multiple character constants like '//' if they are in the source code. I will leave with an exercise for the reader write a flex program to convert all assignment operators of the for =+ to +=, delete all C and C++ comments. (you can assume regular C comments are not nested if you desire, its easier), check curly bracket matching, (watch out for strings and char constants)! It should be about four screens or less in size. I have not yet written such, but it is a combination of what we have been doing and combining them is no big problem with flex. I will go into more interesting things like converting a Compuserve library listing to a flash (1 or 2) do file. Its source is a flex file. It will show you how to get just some information from a file and ignore anything that is not correct. It will not change forums or libs if the listings are sorted by library as lib:all does and the file is in the same library and forum as the previous file to download. It is a little more involved than these but still not beyond straight flex code. I think it works, I have not run the do files through flash, but the information gathering works, more next time. As noted at the beginning, if something in these articles is not clear, please ask, via email at addresses above. Flex237 is on GEnie as flex237.zoo. It's docs, a short installation program to change the drive containing \lib\flex.ske, and some notes to get flex.ske to work with lattice 5, will be in a separate file, for GEnie if you have flex237.zoo and the works will be in an lzh file on CIS and GEnie someday soon. /***********************************************************************/ HARD CORE By: Albert Dayes /***********************************************************************/ An interview with Greg Comeau of Comeau Computing about his new C++ compiler for the Atari. AD: What is your new product for the Atari? GC: Comeau C++ 3.0 With Templates. This is not just an "out-of-the blue" product. Point in fact is that Comeau C++ has been the most diversely ported commercial C++ anywhere for over 4 years. Further, Comeau C++ is stable, up-to-date, reasonably priced, and in sync with the implementation and specification that every other vendor shoots for: cfront 3.0 (we literally are cfront 3.0 as we are source code licensees of AT&T USL C++ Language System). AD: What C compiler(s) is/are supported? GC: One must realize that Comeau C++ generates C as its object code (it is NOT a preprocessor though as it does syntax checking, semantic processing, error reporting, etc, in full ... a C compiler is used only to produce native object code and is not expected to perform any activities like error checking and reporting). With that in mind, the initial release of Comeau C++ 3.0 With Templates for the Atari will have "official" support for Lattice C only. A number of upgrades are already being planned, and additional back ends will include as many C compilers as possible. For instance, PureC and gcc. AD: What are the minimum computer requirements to run Comeau C++? (hardware and software) GC: The software requirements are that you have a C compiler as per the conversation above. The hardware requirements are that you have 2M of RAM and disk space available. (NOTE: The product is still in beta but I do not expect this numbers to change). AD: How long has Comeau C++ been in development for the Atari? GC: For over a year. It became an on-again/off-again situation. Similarly a love/hate relationship. It involved a number of different issues ranging from technical to philosophical. Like the post office, we got through it all and now have a solid and stable conforming compiler. Being able to do such "foreign" ports such as this and past ports (MS-DOS, AmigaDOS, Data General AOS, etc) continues to reinforce and strengthen our porting leadership and savvy. AD: Is the code generated portable between other platforms that use Comeau C++? GC: That's a multi-part question whether you know it or not. Let me address each part one at a time: 1) As Comeau C++ is the most diversely ported commercial C++, we guarantee source code compatibility. Hence, users don't need to port their code, they merely need to recompile it ("system" header files and intrinsic OS differences aside of course). 2) Although we provide "official" support for various C backends, many customers use unofficial backends. This is especially true of folks who do embedded systems programming. One has to realize that although the style, customers using unofficial backends may not have access to our run-time library as many C compilers have incompatible object/modules/linkers/etc. AD: What makes your product different from GNU G++? GC: Actually some of your questions above are spelling this out: * based on cfront, the de facto target of every vendor * up-to-date * robust * diversely ported * free tech support * free 2nd day air shipping and handling * excellent reviews and customer feedback * almost always the first to release a new version Whereas the C part of GCC is a top notch compiler, the g++ still has a few bumpy roads to get over. The authors of g++ will not say what version of C++ conforms to, though recently they did state that they are making efforts to be able to shoot at the ARM. Also, our customer base and knowledge of g++ uncontestably indicates that it is not as free as it first appears. AD: What is the estimated cost of Comeau C++ for the Atari? GC: The cost will be $US250. AD: What type of support does one get when they purchase Comeau C++? a) Is the support on-line? b) Telephone? c) BBS? GC: Like our port list, this covers a plethora of areas. For starters, technical support is free. It overwhelmingly takes place involving telephony. That includes: voice, fax, and electronic forums. We prefer electronic forums for a number of reasons and such forums include: Usenet e-mail and newsgroups, BIX, Compuserve, WELL, Prodigy, GEnie, and PANIX. The electronic forums not only allow customers the ability to send us exact examples of what they may be taking about, etc, but on some like BIX, where we have a vendor support conference, customers can also communicate with each other in both private and public areas. We can also have general conversations about the product in its current form and about enhancements they are interested in seeing. Although our official tech support hours are Mon-Fri, 9-5, that is really a voice limitation. It is common for staff to be answering a tech support question at say midnight on Saturday. These forums are effectively monitored 24 hours/7 days a week. This is unheralded IMO. AD: Is there an estimated time frame of when it will be available? GC: We hope to begin taking orders in July 1993, and either ship in July or August 1993. AD: What are three major benefits of using C++ for development in your opinion? GC: 1) The C heritage. Although C is a terse language with a number of confusing issues (like declaration syntax, or pointer use beyond char *), it also has a number of pluses. The vast thought and wisdom and artistry that Stroustrup put upon C++ as a C superset cannot be disputed. 2) The ability to express programs more naturally. 3) Whether a given problem is complicated or not, the solution domain(s) of applications differ because each apps needs differ. C++ is able to span a broader spectrum of solution domains in order to meet these differing needs. I think one has to think about these answers. That is, note that I have NOT said: 1) More productivity 2) Code reuse 3) Object-oriented Although these issues do indeed come into play for the C++ programmer/ designer/application/etc, they are in some ways to me misguided. For instance, I consider it more important to say "C++ is a superset of C supporting multiple paradigms of programming one of which is OO" than the not quite right statement of "C++ is an OOL." AD: In your opinion how long on average does it take to get up to speed on C++ for an experienced C programmer? GC: This is often a misinterpretated question and answer. The question often takes on the form of "what is the "cost" of learning C++" or "how much time is lost" and as in some of my above comments, these are misguided questions. The straight answer is that is takes 6-9 months. Anybody walking away, or letting somebody walk away, with just this information is committing fraud IMO. That's only part of the answer and it does need to be put into perspective. For instance, to the misguided questions, valid answers do include that there is no cost or lost time (even for the person not well versed in C). As mentioned, our research has seen that it takes the average C++ programmer from 6-9 months to be reasonably proficient in C++. The perspective is that we have also seen it take 5ish-8ish months for a programmer in other languages to become reasonably proficient. By reasonably proficient I mean knowing enough nooks and crannies of syntax, idioms, paradigms, etc. So what we end up with is *maybe* 25%+ more time to learn C++, but not in every case. For instance, given those leeways, it might take one person 6 months to learn C++, and somebody else 7 months to learn another language. Of course, when one really thinks about it, what do these number mean? Even if I could show C++ always took less time, I really think we need a fully described context to see what the impact of less time really is. For instance, certainly new issues in design, thought, approach, etc, is part of the "expense" of C++. IOW, the additional time does not so much involve issues like learning new syntax, but is really more of the nature of issues like the impact of truly using and understanding OOT. In the specific case of C -> C++, where many things such as syntax are already familiar, a double edged sword presents itself. The syntax is the same, yet the additions add unfamiliar complexity onto it. Depending upon the individual in the C->C++ case, that 6-9 can be brought down a few months shorter as the syntax is really a bogus obstacle and the other things that are important are where the pain and gain reveals itself. This curve does have many reverse benefits too. For instance, many C++ programmers mention it made them better C programmer as not only do they look at problem in different lights now, but it has helped them to understand the syntax and semantics of C better. One approach to this learning process is to take it one step at a time. 1) Just get some C programs to compile under C++ to get familiar with it. 2) After being comfortable with that, selectively use some of the "better C" features of C++ such as inline function, references, const, function overloading, etc. 3) After being comfortable with that, consider collecting some of your "random" data structures and the apparent functions that use them into a class. You have now created an abstraction and these user defined types should become something whose importance should be clear shortly. 4) After being comfortable with that, consider that you don't want global variables, and that you don't want public access to anything and everything. So you put a level of encapsulation on your data and functions. At this point you should have a good familiarity with constructors and some other special class related issues. 5) After being comfortable with that, using your encapsulated abstractions, you will find the need to make specializations here and there. Well, if appropriate, you may have just realized what inheritance is about and will want to toy around with that for a while. 6) After being comfortable with that, you may see still further commonalities in relationship both "up and down" an inheritance tree or across a set. This is where OO and templates, respectively, come into play. 7) At this point, the programmer should have a good idea of how C++ can help them more naturally express their algorithms. The last piece of the transition involves know what to use where. It also involves not being lazy and re/learning how to think. Note that this is meant as one path to learning C++. The intent of the above is NOT for you to C++'ize all your C programs. It is an approach to bite sized progression though the various facets of the language. During this process, issues like re-evaluation of life cycle phases and re-orchestration and redistribution of modules, data and functions become more a part of the up front issues instead of afterthoughts. The concerns of learning C++ are real and indeed important. Hence, I've elaborated my answer to this question with a flavoring of some of the issues involved. AD: What books do you recommend for programmers who want to have a head start before your product is released? GC: The C++ community has a number of top-notch books these days. A good overview is Al Stevens' "Teach Yourself C++" 3rd edition. The two current "authoritive" texts are Bjarne Stroustrup's "The C++ Programming Language" 2nd edition and Stanley Lippman's "C++ Primer" 2nd edition. As a reference, one should not be without Peggy Ellis and Bjarne Stroustrup's "The Annotated C++ Reference Manual" (a.k.a., ``ARM''). Re OO specific books, the industry seems to agree that the most flexible and practical is Grady Booch's "Object Oriented Design With Applications". There are other books that are also good. Ditto for magazines. We produce a document entitled "The C and C++ Survival Guide" that contains a more complete list. AD: Thank you. [ Editor's NOTE: Greg is VERY accessible via the on-line services and welcomes contact from the readership via one of the electronic (not voice) mechanisms listed below. ] Comeau Computing 91-34 120th Street Richmond Hill, NY, 11418-3214 Producers of Comeau C++ 3.0/3.0.1 With Templates Here:attmail.com!csanta!comeau BIX:comeau or comeau@bix.com CIS:72331,3421 Voice:718-945-0009 Fax:718-441-2310 Prodigy: tshp50a WELL:comeau /************************************************************************/ BAD EXAMPLE By: Albert Dayes and Carl Barron /************************************************************************/ bad example good example ======================================================================== #include #include main() main() { { double a, a2, a3; double total, sales, tax; a2 = 77.00; sales = 77.00; a3 = 0.054; tax = 0.054; /* 5.4 percent */ a = a2 + (a2*a3); total = sales + (sales * tax); printf("%f", a ); printf( "total cost = $%-10.2f\n", total); } } What are some of the major differences between the bad example and the good example? a) Variable names b) Output The variable names in the bad example are a problem. Since one can not just look at them to figure out what they are looking at. The good example shows how much easier the program is to read when MEANINGFUL variable names are used. The output is as follows: 81.1508 <----- for the bad example total cost = $81.15 <----- for the good example The problem with the bad example is that is just prints a number but does not tell you what the number is for. The good example gives the word total so one can tell what it is used for right away. The other issue is how the number is formatted. In the bad example the numeric value is not formatted, but rather just printed raw. For most of use paying an amount of 81.1508 does not make any sense at all (assuming US currency). The good example demonstrates how currency should be formatted with two decimal places. /**********************************************************************/ Practical DSP By: Ron Robinson /**********************************************************************/ Tools for use on the Motorola 56001 DSP. //// Much of the following first appeared in the June/July issue of //// Atari Advantage Magazine and is reproduced here with the //// permission of the author. Permission is NOT granted for //// reproduction in any form other than this issue of AEO-PJ. Telling people what DSP is and can do shares many of the problems Alexander Graham Bell faced when first describing the telephone. "You talk into this end and it does what???" One could suspect many of the best applications for this breakthrough technology haven't even been dreamed of yet. DSP provides capabilities previously not possible in electronic systems. The development of DSP is estimated to have a technological impact similar to the effect the microprocessor had on computing. Sophisticated music systems, automated voice mail, speech synthesis, translating machines and seeing aids for the blind are becoming possible. The AT&T DSP phone answering system and DSP based toys such as the Texas Instruments "Speak and Spell" are common place. Or keyboards such as the Yamaha DX 7 digital keyboard incorporates custom DSP chips for music synthesis. Digital Signal Processing (DSP) has recently become feasible with a new series of specialized microprocessors that are designed to carry out digital signal processing algorithms. From the engineering side, this is characterized by multiply/accumulate computational sequences used to perform digital filtering and spectral analysis of signals. For the rest of us side, DSP is "heavy duty" math -- the process of evaluating signals and then processing that information to generate some kind of useful output. The processor to do this must be good, very good, at high speed math operations on large groupings of data. The Atari Falcon030 uses a Motorola DSP known as the DSP 56001. Motorola DSP 56001 Digital Signal Processor (DSP) Specs The DSP56001 Digital Signal Processor used in the Falcon offers many high performance advanced processor features. A few key points from the Motorola data sheets follow: ù Speed - 32 MHz operation, yields 16 MIPS. ù Precision - 24 bit internal and external data paths, yielding 144 dB dynamic range. 56 bit accumulators can range over 336 dB. ù Parallelism - Programming model is three execution units operating in parallel. ù Instruction Set - 62 instructions. The following operations can be executed in parallel in one instruction cycle: 24 x 24 bit multiply 56bit addition Two data moves Two address pointer updates Instruction prefetch ù Integration - six on-chip memory arrays, three communication channels, and seven buses. 512 x 24 bits of on chip ROM used for Mu-Law, A-Law and four quadrant Sine wave table data. Probably the best way to gain an appreciation for what DSP is all about is to take a look at a wide range of real world examples. //// DSP APPLICATIONS EXAMPLES: Digital Audio and Music Processing Analysis of musical instrument sounds Music synthesizers Digital recording studio and digital home reproduction Voice mail Phone answering machines (AT&T) Educational toys (TI Speak & Spell) Hi-Fi compression; error correction; dynamic noise reduction Reverb and ambience enhancement; pitch transposers Noise cancellation Communications High-speed modems Adaptive equalizers; digital repeaters of analog signals Video phone PCM companding: u/A law conversion Modulation/demodulation: amplitude, frequency, phase Data encryption and scrambling Linear-phase filtering; echo cancellation Spread-spectrum communication Signal Analysis Pulsed-echo acoustic hologram (bat sonar) Radar and sonar processing; electronic countermeasures Speech Processing Speech analysis Speech synthesis; vocoders...; speech compression Speech recognition/speaker authentication Voice store and forward Language translation Speech enhancement, noise cancellation Image Processing Image enhancement, pattern recognition; computer vision Reconstruction: CAT, PET, MRI tomography Radar and sonar image processing Digital TV-video DSP processors Satellite images; earth resource survey Graphic Image Generation Image management: Shapes, sizes, contours, shading, highlights Vector manipulation; graphics "engines" CAD/CAM workstations; 3-D image generators Flight (and other transportation) simulators; arts and film sequences Real-time Measurement Instrumentation Digital filters; fixed and adaptive Spectrum analyzers and estimators Phase-locked loops; coherent detectors; correlators Transient digitizers and analyzers Signal averagers, exponential smoothers Time domain reflectometry and pulse analysis Signal generation Chemical instrumentation: mass spectrometers, chromatograhs, etc. Observational astronomy: multiple-mirror telescope Search for extra-terrestrial intelligence (SETI) Thermography: IR imaging of temperature maps High-Speed Control Servo links; position and rate control; guidance: missiles, etc. Robotics; remote sensing and feedback "Skid-eliminator" adaptive and context-sensitive control Disk-drive head positioners Engine control-iterated with smart sensors Wheel balancing Number-Crunching Array processors for mainframes Floating-point accelerators for microcomputers Vector and matrix processors for supercomputers Sparse matrix algorithm processors Transcendental functions, iterative-solution architectures Artificial intelligence: Lisp machines, parallel processors Seismic earth and sonar sea-floor mapping Weather prediction and atmospheric modelling Real-World Interface Applications Transducer linerization; dynamically linearized loudspeakers "Smart sensors:" Intelligent transducers Solid-state camera with DSP enhancement or preprocess Flat panel display with local pixel-region processing Medical and Biotechnology Ultrasonic Imaging; digital x-ray: enhanced image allows lower dose. Patient monitoring (intensive care, EKG...) Prosthetic IC Implants (Artificial ear...) CAT, PET, MRI tomography (see under image processing) Fourier-transform IR spectrometer Integrative Applications Antibiotic susceptibility Pulse fluorescence analysis Time domain reflectometry DNA sequencing analysis Other Printed-text-to-voice converter for the blind Multilingual translating telephone The intelligent pilot's assistant (DARPA thrust area) Unmanned mobile watchdog or armored weapon ("Think-Tank") ___________________ References: "Digital Signal Processing", R.J.Higgins, Prentice Hall "DSP56001 Reference Manual", Motorola "Digital Signal Processing", McQuilken and LeBlanc, Motorola [ Editor's note: Atari FALCON030 software/hardware examples: MPEG - MPEG de-coder (video) by BrainStorm DIAMOND BACK III - DSP data compression for backups by Oregon Research DAME - Direct to Disk recorder with DSP effects (audio) BLACKMAIL - Voice Mail system WINREC - Direct to Disk recorder (audio) D2D - Direct to Disk recorder (audio) by D2D MUSICOM - Digital Audio, DSP effects (audio) by Compo DIGITAPE - Direct to Disk recorder (audio) by Codehead Technology AUDIO FUN MACHINE (audio) by SDS and many others ... In the next issue we hope to have some sample code for programming the DSP. ] /***********************************************************************/ THE LIBRARY By: Albert Dayes /***********************************************************************/ Library focus: C Users Group Library CD-ROM (October 1992 release) [ Editor's Note: For those who want to know more about CD-ROM technology read AEO volume 2 number 1 and contact ICD for information on their ICD SCSI Pro software. ] For those who enjoy the C Users Journal (CUJ) magazine there are approximately 360 disks in the library filled with C source code. This does not include the source code in each issue of the magazine however. To purchase each disk at $8.00 (US funds) per disk would be very expensive. 360 disks * $8 = $2880 Then if you wanted the source code for each issue for the last five years as well. That is $10 per disk times (5 * 12 = 60) disks. 60 disks * $10 = $600 So your total cost would be approximately $3500. One could buy several new computers at that price. But what if you could get all of it for $50? You would have more than enough money left over to purchase a new multi-session, Photo CD compatible, SCSI CD-ROM drive as well. The Toshiba 3401 CD-ROM drive has been known to sell for $399 bare via mail order for example. Thanks to Walnut Creek you can get all of those disks for $49.95. They are included on one CD-ROM in both archived format and unarchived format. The archive format used is ZIP so Atarians can easily access them using ST-ZIP v2.x. Here is a partial list of some of the files and/or type of C source code available: Zmodem, MNP, MicroEmacs, 68000 C compiler, curve fitting, 6502 cross assembler, Flex, Bison, YACC, Highly Portable Utilities, Little Smalltalk, 68000 floating point library, Othello, Traveling Salesman, 3D medical images, Linear Cellular Automata, Curses, 3-D transformations, make, Group3 image processing, spelling checkers, image processing, TVAL trees, C-windows, PCX graphics library, text editors (STevie and Elvis), GNU C/C++, backgammon, BBSes, games, compilers, text formatters, co-routines, linkers ... and much more. The root directory of the CD-ROM: BBS 10-27-92 4:08p CAPSULE TXT 854484 10-27-92 11:51a CAPSULE ZIP 254612 10-27-92 1:43p CAP_V100 TXT 357846 10-27-92 11:51a CAP_V200 TXT 496638 10-27-92 11:51a CATALOG TXT 6395 10-27-92 11:51a CAT_V100 TXT 2348 10-27-92 11:51a CAT_V200 TXT 2661 10-27-92 11:51a CAT_V300 TXT 1386 10-27-92 11:51a CUG_INFO TXT 5447 10-27-92 11:51a GO BAT 17 10-27-92 11:54a LISTINGS 10-27-92 4:08p README TXT 996 10-27-92 1:09p VOL_100 10-27-92 4:08p VOL_200 10-27-92 4:08p VOL_300 10-27-92 4:08p ZIPPED 10-27-92 4:08p One of the nice features is an index file that lists all of the disks on the CD-ROM. To search the index file (which is in ascii format) effectively a grep-like utility can be used. The second index file includes much longer descriptions and is called capsule.txt on this disc. You can load this into an editor like Clear Thinking's Edhak v3.01 or the editor of choice to see what is available. A short example of a single entry from the file CAPSULE.TXT. CUG274 - ----------- Arrays for C By James P. Cruse. [share] 1 disk. Arrays for C is a shareware package that facilitates the handling of arrays in C. The package includes a wide variety of routines: filling, adding, subtracting, calling functions on each element, scaling by constants, etc. All are implemented as code macros (#defines), and use a uniform naming convention. The routines are very portable and have been tested with several compilers including Microsoft C v5.0, Turbo C v1.5 and Aztec v3.40b. The disk contains source code, documentation, and sample programs. For more details see the narrative description of this package in Section 2. CUG274.01-ARRAY.ART doc Article on Arrays for C. Introduction, overview, usage, and quick summary of "Arrays for C" functions. Also describes example routines and customization options provided. => ARRAY.H. CUG274.02-ARRAY.DOC doc Background, registration information, planned development, breakdown and description of functions in Arrays for C. ARRAY.H. CUG274.03-ARRAY.H header Includes details on compiler dependent options, customization as well as header defines for such. => A_INFO.H, A_BINOP.H, A_FILL.H, A_UNOP.H, A_TESTAL.C, A_TESTF.C, A_TESTI.C. [MS-DOS: MSC5, TC1.5] CUG274.04-ARRAY.SUM doc Summary of Arrays for C. General description of array handling package. => ARRAY.H. CUG274.05-A_BINOP.H header Declares all binary operations. => ARRAY.H. CUG274.06-A_FILL. H header Declares all the various fill operations. ARRAY.H. CUG274.07-A_INFO. H header Declares all information operations: sum, product, minimum, maximum, and minimax. => ARRAY.H. CUG274.08-A_TESTAL.C source Tests all array functions. => ARRAY.H. [MS-DOS: MSC5, TC1.5] CUG274.09-A_TESTF.C source Tests using floating point operations. ARRAY.H. [MS-DOS: MSC5, TC1.5] CUG274.10-A_TESTI.C source Tests using integer operations. => ARRAY.H. [MS-DOS: MSC5, TC1.5] CUG274.11-A_UNOP.H header Declares all unary operations. => ARRAY.H. As one can see it gives a complete description of the overall package and then goes into single line summaries of the individual files. It is simply amazing how much information is available. Here is another entry for a spelling checker ... Spell and Dictionary Part I By Kenji Hino, Bob Denny. [public] 1 disk. Contains a spelling checker and half the dictionary on CUG217. The rest of the dictionary is on CUG218. Kenji Hino rewrote the package from a Software Tools version. The disk contains three executable versions developed under Microsoft C. SPELLC is quite portable and should compile under most compilers. SPELLS is compiled with the small model option, SPELLC with compact model, and SPELLH with hugh model. The nine dictionary data files will require at least 500 Kb when concatenated. Spell copies named files to standard output while looking up each word in a dictionary. Misspelled words are displayed with asterisks beneath. CUG217.01-HEADER.CUG doc File headers. => SPELL.DOC, HY.C. CUG217.02-HY.C source By Bob Denny. Hyphenates words from standard input. => HY.EXE. [MS-DOS: MSC] CUG217.03-HY.EXE executable By Bob Denny. => HY.C. [MS-DOS: MSC] CUG217.04-SPELL.C source By Kenji Hino. Spelling Checker. SPELL.DOC, CUG218. [MS-DOS: MSC] CUG217.05-SPELL.DOC doc By Kenji Hino. User and program documentation. => SPELL.C, SPELLS.EXE, SPELLH.EXE, SPELLC.EXE. CUG217.06-SPELLO.DAT data Dictionary Part O (A - Bright). SPELL*.DAT. CUG217.07-SPELL1.DAT data Dictionary Part 1 (Brighten - Deduce). SPELL*.DAT. CUG217.08-SPELL2.DAT data Dictionary Part 2 (Deduced - Floss). => SPELL*.DAT. CUG217.09-SPELLC.EXE executable By Kenji Hino. Spell with Compact Model. SPELL.C, SPELL.DOC. [MS-DOS: MSC] CUG217.10-SPELLH.EXE executable By Kenji Hino. Spell with Huge Model. SPELL.C, SPELL.DOC. [MS-DOS: MSC] CUG217.11-SPELLS.EXE executable By Kenji Hino. Spell with Small Model. SPELL.C, SPELL.DOC. [MS-DOS: MSC] For those who prefer a single line descriptions of each disk that is available, the catalog index is extremely useful. Here is just a small sample from the file catalog.txt. 320 Convolution Image Process 321 Mouse Trap Library 322 Doctor's Tools 323 Fireworks and Adventure 324 WGCONIO 325 VGA Graphics Library 326 SoftC Database Library 327 Panels for C 328 WTWG 329 Unix Tools for PC 330 CTask 331 SE Editor 332 PC Curses 333 GAWK 334 GNUPLOT 335 Frankenstein Cross Assembler 336 EGAPAL/EDIPAL 337 Designing Screen Interfaces in C 338 68000 C Compiler and Assembler 339 CTRLCLIB 340 C-Window 341 Orbit Propagation 342 I8255 Interface Library 343 C Image Processing System 344 C Grab-Bag #1 345 TLC/TLP 346 ASxxxx Cross Assembler, Part 2 347 TAVL Tree 348 8048 Disassembler/Z80 Asm 349 Simulation Subroutine Set 350 PCX Graphics Library 351 UltraWin 352 String and Vlist 353 Withdrawn from the CUG Library 354 CES Mouse Tools Library 355 Sherlock for MSDOS 356 Withdrawn from the CUG Library 357 CSTAR 358 cbase 359 GNU C/C++ for 386 360 uspell 361 Gadgets and Term 362 RMAXTask 363 68020 Cross Assembler 364 C-Across This small listing of disks above would cost far more ( 44 disks * $8 per disk = $352 versus $50 ) than the a single CD-ROM disc. This is just the library files and not even including the monthly source code disks. For $50 it is an excellent deal. For more information about other source code CD-ROMs, a catalog or information on making your own CD-ROM discs contact: Walnut Creek CDROM 1547 Palos Verdes Mall, Suite 260 Walnut Creek, CA 94596 USA (800) 786-9907 (voice) (510) 947-5996 (voice) source code CD-ROM discs (SCSI CD-ROM drive required) /**********************************************************************/ PERIODICALS By Albert Dayes /**********************************************************************/ Magazine focus: C Users Journal One of the longest running language specific magazines in the C Users Journal magazine. Its been around since for almost a decade and it has approximately 45,000 subscribers. This magazine is dedicated to one only one subject and that subject is C. This magazine is for programmers by programmers and it covers a large variety of subjects. Each issue has a particular theme, such a Graphic User Interfaces, for example. The magazine believes in solving practical problems with real world solutions and not theoretical ones. For those that have access to internet [Editor's note: See back issues of AEO for more information on accessing internet] there is a column that discusses many of the new releases and updates that are available. One can find many interesting programs and many come complete with source code. [Editor's note: many of these files are also available on CD-ROM]. In addition they have columns on the C standard itself and recently added a monthly C++ column. Then there are articles related to the theme of that particular issue itself. The areas that are always very enjoyable are the Questions and Answers section and the letters to the Editor. These provide many useful issues to think about as well as solutions. One can always learn something from these columns. One of the best features of the article is contact information is supplied. This is usually an internet or Compuserve address so its very easy to talk to the author of the article. The source code for each issue is also available on BBSes, Compuserve, internet and also on disk. These monthly archives many times include much more source code than is listed in the magazine which is very useful. There are book reviews are something very familiar as are user reports. User Reports get into the details of a particular software product whether it be a library for PostScript or a database library. Also the ads have some very exciting libraries with C source code available too. The prices are not that bad either. Also a library of source code which exceeds 380 disks currently and are full of C source code. This is separate from the monthly source code disks for each issue, by the way. The disk format used is MS-DOS format; so they work immediately on the Atari platform without any conversion problems. But even with all of this information the bottom line its USEFUL! Most of the time the C code is operating system and platform independent as well. The large variety of subjects gives a C/C++ programmer the exposure and insight to help solve real-world problems today. The C Users Journal 1601 West 23rd Street, Suite 200 Lawrence, KS, 66046-2743 USA (913) 841-1631 (voice) (913) 841-2624 (fax) Available in good bookstores Published 12 times per year. Call or Write for a FREE 16-page catalog of C language related books and publications. Source code (published and some unpublished) is availabe on Compuserve (GO CLMFORUM) in LIB #7; GEnie in the IBMPC RT at page 1335 (keyword IBMPC); and via anaonymous FTP ftp.uu.net for every issue. Also there is a 720K 3.5 inch disk option for a nonimal fee. /***********************************************************************/ OBJECT::ATARI By: J.J. Lehett /***********************************************************************/ Part 1 : Object Oriented != A Ball Sent Eastward Here ... take my hand. Together we'll begin our journey into one of the hotbeds of the programming industry; a whole new dimension in developing software for the Atari: Object Oriented Programming (OOP). Before we begin our explorations in this new and exciting realm, we should become acquainted with some of the terms and ideas behind 'Object-Oriented'-ness in general. This initial column will attempt to give you an overall view of OOP, while focussing on Atari specific implementations when appropriate. Future columns will be largely influenced by reader response. Possible topics include: Installing and Using Gnu C++, Installing and Using Smalltalk, GEM Programming and OOP, and a series on designing Atari class libraries for maximal code reuse. Please feel free to write to me, with you comments, criticisms, and ideas. I look forward to hearing from you! In the first sentence of this column, I asked for your hand. The reasoning was bilateral; in many instances of our explorations of the Object Oriented paradigm, the discoveries we make will be new to both of us. Therefore, I am going to ask for your understanding in the inevitable errors, or subjective or controversial statements that may appear in this column. Any problems along these lines will be corrected, amended, or retracted as soon as possible. //// What does Object Oriented mean? To begin our journey, it seems wise to dispel any pre-conceived ideas or myths that one has about Object Oriented Programming. It is not a database technology, although many databases today use OOP. It is also not a graphical user interface technology, nor does it contain any implicit 'visual' components. Most of these misconceptions stem from the fact that many of these type applications use OOP, and plaster the words 'Object Oriented' over the packaging, however, it (OOP) is simply the method by which the application was written. So, what is Object Oriented Programming? It is a new way to think about programs, a new way to conceptualize their structure, and a new way to proceed to write those programs. Most texts would agree that to be considered a true Object Oriented Programming Language, the language must have the following four components: (1) Encapsulation a.k.a. Data Hiding Encapsulation means that the data associated with a certain 'object' can only be accessed and manipulated by the methods (functions) given to that object. An example in pseudo-code should clarify the meaning of this. class Ball // this is the object's name integer weight // possible 'data' about Ball method change_weight(integer new_weight) { weight = new_weight } (note: the pseudo-code in this column is not C++ or Smalltalk, it is simply an attempt to help present concepts.) What we have now is anywhere in our program that we create a Ball, (we'll call this ball we create OurBall), it automatically has a 'weight' associated with it, and a method by which to change this weight. In OOP terminology you would send a 'message' to the Ball if you wanted to change its weight, ie. OurBall.change_weight(15). Non-OOP programmers may begin to think of this as simply a function or sub-routine call, however since it is directly associated with the OurBall object, it would make no sense to call this method for anything but a Ball-type object. OK, but what advantage does this give us? By hiding this data from other parts of the program, and defining a method to change this data, one increases the ease of program maintenance and debugging. In this small example it may be hard to see, but imagine if you at first assumed that the weight given to change_weight() was in pounds, however, the user of the class deals in kilograms, one way to solve the problem would be to change the following (1) line of code: weight = new_weight ---> weight = new_weight * 2.2 With this one simple change, the program using Ball can now send weight changes in kilograms instead of pounds. Ball, however, now knows to change the weight to pounds before changing it's internal weight data. Thus, any other methods of Ball that worked on pounds still work. (2) Inheritance Inheritance is the ability to define new objects in terms of already defined objects. Another example is in order here. class ColoredBall : derived from Ball int color method change_color(int new_color) { color = new_color } Our new class ColoredBall is said to inherit all the characteristics of the Ball it is derived from, plus any new data and methods added to the new class. Thus, a ColoredBall has both a weight AND a color, as well as methods for changing each of these pieces of data. This is one of the fundamental points of Object Oriented Programming; the ability to start with simple 'objects' and then proceed to define new objects that have all the characteristics of old objects. The programmer does not have to re-invent the wheel so to speak, the code is completely reusable (and even replaceable as we shall soon see). (3) Polymorphism Polymorphism basically means 'multiple forms.' Due to differences in Object Oriented Programming Languages the term can pertain to a couple of different usages. First is the case of multiple instances of method names in classes. In our Ball class, we had a change_weight method (function). Now if we wanted to define a Block class, it is logical we would want another change_weight method. Polymorphism allows different classes to have method names that are the same, but are 'local' to a particular object; there will not be any naming conflicts. Another usage of polymorphism is that derived objects can be used as objects of the parent type. For example, suppose we created a function called MoveBall() that takes as its parameter a Ball object. Polymorphism allows us to use a ColoredBall as a parameter to MoveBall(), since ColoredBall is derived from a Ball. MoveBall() would also work without further refinements on any future derivatives of Ball. Suppose that next week we create a RubberBall class derived from Ball. MoveBall() is capable of working on RubberBall even before we compiled RubberBall! (4) Single Type This last component is also the least accepted component. Essentially it means that any variable can hold anything. Depending on the language you choose, this may or may not be true. C++ does not adhere to this feature, as a char variable cannot hold an int. As a result there is much discussion over the question of 'Is C++ a true Object Oriented Programming Language?'. Smalltalk does have this feature and a variable in Smalltalk has no idea what it is holding until a message is sent to it. //// What Object Oriented programming could mean to you. So what advantages do these features of Object Oriented Programming bring to the Atari programmer? Perhaps the most obvious is code reuse. Imagine having only one SORT function that can operate on all datatypes. To the non-Object Oriented programmer, this would normally require a different sort function for each data type (int, float, char, etc.). The Object Oriented programmer simply writes one SORT function that is capable of working on all data types, including data types (classes) that may be written in the future! A more Atari specific application of code reuse would appear in the area of GEM applications. Most GEM apps revolve around one main loop that watches for GEM events. The OO programmer would never have to write that loop again. By using the code from one's GEM library, and installing only those GEM events which one will be watching for, the amount of code that has to be (re)written is greatly reduced. Another advantage is language extensibility. Because of the polymorphism of the language, most object oriented programming languages grant the programmer the ability to extend the language. Operator overloading is one such way. This allows the programmer to redefine operators of the language (+, -, [], etc) to do various things depending on the data given to them. For example, we all know that if A and B are integers, then in most languages, A + B is a valid expression. However, in OOP, suppose we have two ComplexNumber objects, C and D. Operator overloading allows us to redefine the action of the + operator when used with 2 objects of this type, and C + D would result in a valid operation that adds two ComplexNumber objects. Because of data hiding, code maintenance is eased. Since an object's data is only allowed to be directly manipulated by the methods of the object, the data is isolated from other code, and changes and bugs are localized to one particular area. //// What's available on the Atari platform Probably the most widely used (although calling any OOP language on the Atari platform 'widely used' is probably a misnomer) object oriented language on the Atari platform is the GNU GCC C++ compiler. There are positive and negative aspects to this compiler. First, if you have anything less than about 2.5 megabytes RAM, there is no way to use it. The binaries alone for parts of the compiler are around 1.5 megabytes in length. Secondly, with all the libraries and the above mentioned size, a hard disk is mandatory. If you meet these criteria, the next thing to consider is speed. The compiler is not a speed demon at compiling source code, but the code that it does generate are normally high quality binary files, especially if one turns on the optimization feature of the compiler. Other advantages include: its price, free, as with all GNU software, it is freely distributable; it is updated quite often; and due to its cross platform availability, porting of code between different OS's is often greatly simplified. Also available (or soon to be available) are Smalltalk, Simula, and Comeau C++ for the Atari platform. We look forward to covering each application in future issues. If you know of any further applications having to do with object oriented programming, please drop me a line. //// From C to C++ Since most of my experience in the OOP world revolves around C++, many of this columns future subjects will deal specifically with C++. For those of you lucky enough to know C already, and want to make the transition, you'll have a head start in that C++ is actually a superset of the C language. Therefor, much of the structure and syntax of the language remain the same. You won't have to start from a blank page when it comes to most keywords and such in the language. It may however, be wise to start with a blank page when it comes to designing and programming in C++. Since most C++ compilers will also compile normal C code, it is very tempting for the C programmer to continue using the same logic in one's coding. The true benefits of C++ will only become apparent if you begin thinking with a OO mindset. Many instructors of Object Oriented Programming Languages believe it normally takes at least a month to fully comprehend the change in design paradigms. Be prepared to start small and slow, as with starting any new language, and the rewards will soon follow. //// So what do I do now? We have only scratched the surface of the ideas and concepts behind object oriented programming. Hopefully your appetite has been whetted, and you are eager to start exploring the world of OOP on your Atari computer. What should your next step be? Get a book on OOP in general or specific to a particular language. My recommendation would be to buy a book on generic C++, not one revolving around a specific company's implementation of the language. Start reading whatever you can get your hands on dealing with OO technology. Much of this column has focused on theory and generalities. To attempt much more would simply not be in the scope of anything less than a text book. Next month, we will present a tutorial on setting up GNU C(++) compiler, and begin to get into the nitty gritty details of actual programming examples. Be sure to send in any ideas for things you might like to see in future columns. We look forward to hearing from you. //// References - C++ Report pub. SIGS Publications - The Waite Group's C++ Programming auth. John Thomas Berry pub. Prentice Hall - Concepts in Object-Oriented Programming auth. David N. Smith pub. McGraw-Hill /***********************************************************************/ OBJECT::ATARI By: Warwick Allison /***********************************************************************/ Part 2 : Setting up G++ - the GNU C++ compiler. This article describes the process for setting up the GNU C++ compiler on an Atari ST, STe, TT030 or Falcon030. First, there isn't much point continuing if your system is not up to the task. In order to use the GNU C++ compiler, you will need: 4 Megabytes of RAM 5 Megabytes of free hard disk space Next of course, you need to be able to get hold of the relevant files. This may mean downloading them from a bulletin board, GEnie, Delphi, or other on-line service, or FTPing them from an Internet archive site. I can't help you much with finding a source, but the one I use is the FTP site: atari.archive.umich.edu "cd" to the directory: /atari/Gnustuff/Tos Under there, you will find various subdirectories containing the files you will need. In general, these same filenames will appear on other on-line sources. When getting files, make sure you get the most recent versions. The simplest way to do this is to look at the datestamp on the file. The files you need are: Executables ----------- The current version of the compiler is 2.3.3, but you also need a number of auxiliary programs. You need: ("#" = some digit) Tool | File | Possible archive names | Comment ----------------|------------|---------------------------|------------ compiler driver |gcc.ttp | gcc233b.zoo gcc233b#a.zoo | Also has C compiler compiler |gcc-cc1p.ttp| gcc233b#b.zoo | Avoid:g++233.zoo assembler |gcc-as.ttp | gcc233b.zoo gcc233b#a.zoo | (with the driver) preprocessor |gcc-cpp.ttp | gcc233b.zoo gcc233b#a.zoo | (with the driver) linker |gcc-ld.ttp | utlbin33.zoo utlbin##.zoo | Keep all utils! other useful utils: cnm.ttp, fixstk.ttp, gcc-ar.ttp, gcc-nm.ttp, gcc-size.ttp, printstk.ttp, size68.ttp, sym-ld.ttp, toglclr.ttp, xstrip.ttp look in directories like: Gnustuff/Tos/Gcc Gnustuff/Tos/G++ Gnustuff/Tos/Utils Libraries --------- The compiler will be no use to you without the libraries. GNU C/C++ library files have a ".olb" extension. Library | File | Possible archive names | Comment ----------------|------------|---------------------------|------------ C++ library |g++.olb | gplibo15.zoo gplibo17.zoo | MATCH with headers C, sys library |gnu.olb | libolb87.zoo | You need this too. Runtime library |crt0.o | libolb87.zoo | You need this too. Math library |pml.olb | pmlolb21.zoo | Maybe this too. look in directories like: Gnustuff/Tos/Gnulib Gnustuff/Tos/G++ Gnustuff/Tos/Pmathlib other useful libraries include termcap.olb and curses.olb Headers ------- The libraries are impossible (practically) to use without the *corresponding* header files. Header | Files | Possible archive names | Comment ----------------|------------|---------------------------|------------ C++ headers |*.h | gplibo15.zoo gplibo17.zoo | MATCH with library C, sys headers |*.h | gcc233b#b.zoo | Needed. Shell ----- It is very difficult to use GNU C++ without a CLI (command line interpreter). Fortunately, plenty of shells are available - you probably already have one, otherwise, try: Shell | Files | Possible archive names | Comment ----------------|------------|---------------------------|------------ gulam |gulam.prg | | mupfel |mupfel.prg | gemini.zoo | Now, you've got a whole pile of files ... now you have to put them together in the right way. Directories ----------- Place the files in directories (folders) as follows: /gnu/bin All the .ttp files /gnu/lib All the .olb files, and crt0.o /gnu/include/gcc All the .h files from the C packages /gnu/include/g++ All the .h files from the C++ header package /tmp Nothing - but GNU C++ will use this directory Environment ----------- In order for the GNU C++ compiler to work, you must tell it certain information about your set-up. This is done by using "environment variables". The relevant ones for G++ are: PATH - A comma-separated list of directories were executable programs are found. Your shell will already have one set up. GNULIB - A comma-separated list of directories were libraries are found (olb files). Also, the first directory in the list must also contain the crt0.o file (runtime code). GNUINC - A comma-separated list of directories were include files for GNU C and GNU C++ are found. GXXINC - A comma-separated list of directories were include files for GNU C++ are found. G++ looks on this path first for include files, then looks on GNUINC. TMP - A directory where G++ can store temporary files. It is also a good idea to set TMPDIR and TEMP to this directory too, as some programs use those names. Environment variables like PATH are set by typing: export PATH=.,/gnu/bin,/bin or perhaps: PATH=.,/gnu/bin,/bin export PATH or perhaps: setenv PATH .,/gnu/bin,/bin or perhaps: setenv PATH=.,/gnu/bin,/bin You will just have to see what convention your shell uses. Assuming the first, and assuming you have the directories set-up as above, type: export PATH=.,/gnu/bin,/bin export GNULIB=/gnu/lib,/usr/lib export GNUINC=/gnu/include/gcc export GXXINC=/gnu/include/g++ export TMP=/tmp Of course, you don't want to have to type those in every time you turn your computer on. Therefore, you should put the lines into the automatically read start-up file for your shell. For example: gulam.prg reads gulam.g at start-up mupfel.prg reads mupfel.mup at start-up Finally, it's time to test it. Using a text editor such as elvis (vi clone), emacs, microemacs, tempus, etc. or even a wordprocessor that can output PLAIN ASCII, create a file called "hello.cc", containing: /////////////////////////////////////////////////////// #include main() { cout << "Hello there++" << endl; } /////////////////////////////////////////////////////// (The "//" bits are just comments) Then, at your command line, type: gcc hello.cc -o hello.tos -lg++ This should produce a file called "hello.tos" which when run prints: Hello there++ And you have succeeded in installing the GNU C++ compiler. Trouble Shooting ---------------- Of course, things never work first time. First, make sure everything is located as described above. Your shell should tell you if it cannot find "gcc", in which case, your PATH variable is not set correctly. If gcc is being found, type: gcc -v hello.cc -o hello.tos -lg++ This makes additional information appear. Something like this: gcc version 2.3.3 /gnu/bin/gcc-cpp.ttp -lang-c++ -v -D__cplusplus hello.cc /tmp/1234.i GNU CPP version 2.3.3 (Atari ST) /gnu/bin/gcc-cc1p.ttp /tmp/1234.i -dumpbase hello.cc -o /tmp/1234.s GNU C++ version 2.3.3 (Atari ST) compiled by GNU C version 2.3.3. /gnu/bin/gcc-as.ttp -o /tmp/1234.o /tmp/1234.s /gnu/bin/gcc-ld.ttp -o hello.tos /gnu/lib/crt0.o /tmp/1234.o -lg++ -lgcc (actually, it will print heaps more than that) In the example above, we see that gcc.ttp runs, and it then runs gcc-cpp.ttp (the preprocessor) on hello.cc to produce 1234.i (in the temporary directory). Then, it runs gcc-cc1p.ttp (the compiler itself) on 1234.i to produce 1234.s (assembler code for your program). Next, it runs gcc-as.ttp (the assembler) on 1234.s to produce 1234.o (binary object file). Finally, it runs gcc-ld.ttp (the link editor/loader or "linker") on 1234.o along with crt0.o (the runtime support), gnu.olb (the system library and g++.olb (the C++ library) which links the necessary parts of each of them together, to produce hello.tos, which you can run. The important thing is that each program is run correctly. The "1234" is just some random number. Also, the compiler (actually, the linker) may produce a file called "compiler.err" in the directory you ran gcc from. look at this ASCII file for additional information. One of the most common mistakes is if the filename of your compiler does not match the one gcc.ttp is looking for. For example, if your compiler is named "gcc-cc1+.ttp" instead of "gcc-cc1p.ttp", the compiler will not find it. If the compiler reports that it cannot find a library (or crt0.o), your GNULIB variable is incorrect. If the compiler reports that it cannot find "iostream.h", check that GXXINC indicates a directory containing iostream.h. Notes about the GNU C++ compiler -------------------------------- The program generated by the "hello" code above might seem very large (over 100K), but this is because it must link in many libraries in order for iostreams to work. If you don't like large executables, there are some simple things you can do: 1. strip the debugging data out of them, by typing: xstrip hello.ttp 2. use the C Input/Output libraries rather than the C++ libraries (eg. use printf("hello world\n") rather than the cout << ...) in fact, this also makes things faster too, since the iostream header files are quite large and take time to read in. Of course, you are sliding back into C code then. The GNU C++ compiler (and the other GNU compilers) have DOZENS of optional features, from Optimization (add -O2 on command line when compiling) to support for the 68030 and 68882 special features (-m68020 and -m68881 respectively). You can make it assume "int" is just a 16-bit value (rather than the default 32) with -mshort. That is about as much help as I can give for setting up the GNU C++ compiler. It may seem like a long process, but it is not really very difficult - I have just tried to cover as many possibilities as I could think of. So go get those file, set it up, and you will be ready for the next articles in this column, where you will see actual programming examples! Until my next visit to the Space Bar, Ciao, Warwick. (warwick@cs.uq.oz.au) ========================================================================= /***********************************************************************/ Language Watch -- Current versions of developer tools /***********************************************************************/ DEV| version & date | product ========================================================================== A | 1.1 Nov 24, 1992 | 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.00 | Devpac 3 (assembler) B | 5.52 | Lattice C B | 2.02 | HiSoft BASIC 2 (includes compiler) B | 2.03.02 | HiSoft C (C interpreter) 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 strongly encouraged to send press releases and upgrade announcements to the Editor ] /***********************************************************************/ On The Networks comments and messages from the on-line community /***********************************************************************/ These messages reprinted courtesy of the GEnie ST RoundTable Category 33, Topic 6 HISOFT > ------------ >Category 3, Topic 14 >Message 25 Fri Oct 23, 1992 >FIFTHCRUSADE at 20:59 EDT > > HISOFT, > > Is there some way I can get Lattice C 5.51 to flag an error in the > following situation: > > /* Header file a.h */ > struct a *c_a(void); > void d_a(struct a *); > /* end header */ > --------------------- > #include "a.h"; > struct b *c_b(void); > > void main(void) > { > struct b *ptr = c_b(); > d_a(ptr); /* ERROR */ > } > --------------------- > Right now Lattice compiles the error line without any warnings or > anything. This is causing me problems. I was really hoping it would > see that the struct tags are different and at least warn me about > this. > > I'm writing an encapsulated, object oriented GEM library, and I'm > using pointers to undefined structures as a means of information > hiding. It works fine except there's no type-checking on the > struct pointer parameters. Can I enable a warning for this? If not, > is there a work-around? > > I can't use typedefs because then I'll have order-dependant headers, > or nested headers. The former are a pain, and the latter screw up > make dependencies. > > Ben White > 5th Crusade Software > ------------ For some reason (I know not why) the code in the compiler which would have caused this to give a warning was commented out... I've reinstated it for the upcoming 5.53. Also if you want it to warn you now, run in ANSI mode, but disable message 148 (-ca -j148i) which ANSI mode incorrectly enables. Alex Kiernan, HiSoft. -------------- Category 33, Topic 6 Message 16 D.LIVINGST11 [ErnestBovine] (Forwarded) > explain why a program compiled on my Mega STE is > half the size of the same program on an IBM clone. > It's just a simple program The linker adds lots of things (library routines, program initialization code, etc, and possibly debugging symbols) to your code, to create the executable program. In the case of a very small program, this stuff would usually be much larger than the actual code produced when the compiler compiles your .C source. For example, printf() is a very large function, and even if your source code is nothing but printf("Hi"); the linker must still get the printf function from the library, and put it into the executable. Since printf() calls lots of other functions from the library, these have to be linked in as well. This "extra" is evidently much more stuff on the IBM than on the Atari. If you use Microsoft Windows, there would be a TON of it! Anytime you #include , a LOT of stuff gets added. If you don't need redirection or printf() etc, you can make your programs a lot smaller. ------------- Category 33, Topic 6 Message 98 EXPLORER.1 [ Ron ] The Stephan Kochan book is very good. If you get stuck on pointers and structures try backing off and taking an assembly language course or reading Clayton Walnum's assembler book. Knowing how the computer works helps a lot with the indirection concepts. "Atari ST Applications Programming" by L. Pollack and E. Weber, Bantam Books, ISBN 0-553-34397-1 is a very good ST specific text. Examples from the book are in the libraries, do a search on "Bantam". I doubt the book is still in print but would still be worth looking for on special order or ask if someone has a copy they want to sell. The Compute ST Programming series are worth getting if you can find them, keep an eye open in the for sale topics for used books. Ron @ Atari Explorer ------------ Category 33, Topic 6 Message 99 J.TRAUTSCHOL [jtrautschold] Wayne... You may also want to download the Tim Oren tutorials on GEM programming in C. I believe they exist in one of the library's here on GEnie, although I don't know exactly where. Tim Oren was one of the original programmers of Digitial Research's GEM PC, which was later ported to the ST. His tutorials are quite good and are loaded with some fine (although sometimes confusing) examples. I continue to reference his stuff to this day. The suggestions by others to get as many books on C as you can is also a good one. The C-Manship books are good, but also consider the C-programmers bible, "The C Programming Language" by Kernighan and Ritchie. You should look for edition 2, which covers the ANSI-updated C language. Work through the examples in that book - they'll compile just fine of the ST is TOS mode and will give you a feeling for how the C commands and libraries work. John T. ------------ Category 3, Topic 4 Message 96 J.ZORZIN [Joe] So here's a dumb question from an amateur programmer. In "C" lets say you have a long variable, x=123456789. Now, you want to print that to screen with commas. As I understand there is no standard way to do this. I ended up writing a routine that converts the long to a string then added the commas. I'm very proud of myself that I pulled it off! But does everyone have to write their own routines for commas? Or did I miss the boat? ------------ Category 3, Topic 4 Message 97 STARFALL [Alan] Pretty much, Joe. There are some public domain code floating around for printing formatted numbers, and some C compilers throw it in, but it's not part of the standard C library. ------------ Category 3, Topic 4 Message 98 CBARRON In standard C. The characters are defined in a locale. Dr Plauger in his book the standard C library provides a routine. It is reprinted in a recent edition (late 91-early 92) of C user's journal. MWC came with source code to picture() that sort of emulates a COBOL PICTURE clause. Sadly no locale_printf() family was in the standard, that I can recall. ------------ Category 3, Topic 4 Message 100 S.YELVINGTO2 [Steve] Here's a handy bit of code for putting commas into a numeric string. From: siebeck@infoac.rmi.de (Wolfgang Siebeck ) Newsgroups: comp.lang.c Subject: Re: Putting commas into a numeric string Message-ID: <1992Mar6.124215.1339@infoac.rmi.de> Date: 6 Mar 92 12:42:15 GMT Organization: RMI Net INFO.box Systems * Aachen * Hamburg * Flensburg Marc_North@mindlink.bc.ca (Marc North) writes: >I have written an application that requires I put commas into a string >representing a numeric value. Give this one a try. No error checking is done, so your target should be big enough to hold the string including the commas. For "German" numbers, I call it like commas(numberstring, '.'); you might prefer commas(numberstring, ','); --- cut here --- #include #include #include /* ** If you need strdup(), here it is: */ char *strdup(char *s) { char *t; if (t = malloc(strlen(s)+1)) strcpy(t, s); return t; } void commas(char *dest, char komma) { char *src, *core; /* Place holder for malloc */ unsigned cc; /* The comma counter */ unsigned len; len = strlen(dest); /* Make a copy, so we can muck around */ if( (core = src = strdup(dest)) == NULL) return; cc = (len-1)%3 + 1; /* Tells us when to insert a comma */ while(*src != '\0'){ *dest++ = *src++; if( ((--cc) == 0) && *src ){ *dest++ = komma; cc = 3; } } free(core); *dest = '\0'; } /* ** */ #ifdef TES main() { char in[80]; do { gets(in); if (in[0]) { printf ("%s --> ", in); commas(in,'.'); printf ("%s\n", in); } } while (in[0]); } #endif --- cut here --- Wolfgang -- siebeck@infoac.rmi.de (Wolfgang Siebeck) ------------ Category 33, Topic 6 Message 125 R.WATSON15 [Wayne Watson] Ok, I have a question. WHAT IS A PROTOTYPE? I keep seeing this word and haven't been able to find out what it is. I get this error, 'No prototype at definition of public function'. What does it mean? It might help if I knew what a prototype was. Is there a file or something somewhere that explains the C terminology? Thanks. ------------ Category 33, Topic 6 Message 126 D.CHARTER Wayne, Finally something I can answer (sort of). A prototype is just where you tell the compiler how your functions are called...what parameters you are sending, and what you expect back. An example is the function main(). You can use it like: main() { This will work fine, but you will get the error you received. To solve this problem, tell the compiler if you are sending anything, and if you expect it to give you something back. Like: void main(void) <==void means I am sending/receiving nothing { An example of how to declare a prototype would be: /************ THESE ARE PROTOTYPES *********************/ void main(void); <==I am not sending the function anything..I am expecting nothing to be returned. char get_answer(); <==I am going to receive a character back, but am sending nothing /****************** THIS IS THE PROGRAM *****************/ void main(void) { char answer; answer=get_answer(); <==Here we call the function, sending nothing in the function call..we expect to receive a char. The use of prototyping is helpful for programming, and it allows the compiler to assist by making sure you send and receive what you expect. You are receiving a 'No prototype at definition of public function' because main is a public function. If you do not declare what you expect by using prototypes, the compiler defaults to expecting the return of an INT. Duane ------------ Category 33, Topic 6 Message 127 J.TRAUTSCHOL [jtrautschold] Wayne... A prototype is a way of defining for the compiler, what is to appear in a function. This permits the compiler to easily cross check all of your calls to that function for the proper type of return value, and the proper types of variables being passed to the function. For instance, let's say you write a function that passes 2 character strings, a pointer to an integer, and a long value. The function returns an integer. You would write the prototype like this: int function(char *, char *, int *, long); Now, let's say that, within the body of your program, you call this function twice. The first time you call it as follows: int reply; char string1[] = "ABC", string2[] = "DEF"; int *value; long lvalue; reply = function(string1, string2, value, lvalue); and the next time you call it, you do it as follows: reply = function(string1, string2, *value, lvalue); The first attempt at calling the function would pass just fine. The prototype tells the compiler to expect pointers for the first two character strings as well as for the integer, and just the value of the long lvalue. That's exactly what you are doing the first time. the second call would produce a warning, however, because you are dereferencing the integer value which no longer makes it a point to where that value resides in memory. The compiler will warn you of a prototype mismatch and save you the possibility of hours of debugging later on. John T. ------------- Category 33, Topic 6 Message 124 D.WHITEHEAD3 [Mega ST Man] I'm pretty green when it comes to most of the discussions here. Could someone enlighten me as to what standard C startup is? Also, I've been wondering if the references I've seen to variables that start with a _ are some kind of system variable? If so, where can I find out about them and how to use them. Another question I have concerns sound output. I have C-Manship and it doesn't refer once to sound. The Lattice manuals lists a couple of functions but I have not been able to figure it out. Thanks, Drew Whitehead The Novice Programmer ------------- Category 33, Topic 6 Message 131 HISOFT >... enlighten me as to what standard C startup is? Someone else has probably done this, but just in case... the C startup is the glue between the OS program entry point and the main() function in your program. Its responsible for looking after OS type things and ensuring that standard file handles (stdin, stdout etc.) are set up, and a bunch of other things. Alex Kiernan, HiSoft. ------------- Category 33, Topic 8 Message 5 HISOFT I think Wayne is referring to the old WERCS+ product that we have. This was basically the standard WERCS package together with GDOS and a leaflet describing some of the programming side of the original GDOS. As such its a bit out of date. This isn't included in HiSoft BASIC 2 - you get a version of WERCS just for use with HiSoft BASIC. When SpeedoGDOS comes out we intend add library calls for this to the HiSoft BASIC 2 package. The existing package already has the core routines you need to use the original GDOS (detecting that its there, opening a physical workstation, loading fonts - that sort of thing). Dave Nutkins, HiSoft. /************************************************************************/ 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: Ed Krimen /***********************************************************************/ Apple's popularization of the graphical user interface has demonstrated that the interface is often an application's most important feature. Unfortunately, many programmers, including ST programmers, don't put much thought into the interface. They simply create an interface -- they don't design one. They don't put thought into how the user is going to interact with the application. Programmers know the interface should have some drop-down menus, multiple windows, maybe some buttons, and dialog boxes, but they don't think about how the positioning and implementation of these features will work with the user. After programming the main features of the application, most programmers abhor doing the interface. They know how much thought and design should go into it, but they don't want to muster the effort. Some programmers even leave useful features out because they don't want to bother to fool with the interface. On the ST platform, it's fairly easy to tell which programmers put effort into interfaces, while others seem to put program commands and functions anywhere they see fit, without regard to user tendencies. I'm not singling out freeware/shareware programmers from commercial programmers, either; I've seen strange stuff on both sides of the fence. Some freeware programs have much better interfaces than some commercial stuff. //// LOOK PROFESSIONAL One of my favorite programs is the Interactive Installation demo that CyberCube Research of Canada has recently uploaded to GEnie. There's not much of an interface, and the program has very limited uses, but it's the whole presentation of it that is impressive. It looks like they spent as much time creating the "look" of the program as they did programming it. It has beautifully-designed title screens and helpful diagrams of their graphics card that provide details when you select certain parts of them. The program looks magnificent, especially in TT-medium resolution. A representation of their VME board has each of its parts labeled. When you click on "Monitor Port," for instance, a short description is placed in a dialog box. This is similar to what one would see in Hypercard on that "other" platform. Their "Info" screen displays a professionally-illustrated logo in glorious 16-colors. It doesn't reek of "hurry-up this is the last part that we have to do before we finish the program", but it represents pride and care with a professional look that very few ST programs possess. This entire Interactive Installation program was done just to show you how easy it is to install their VME board. You run it before you do the installation to get a brief, interactive overview. What's so appealing is that the program has an exceptionally professional look to it, unlike many other programs I've seen on the ST. Great care has been made in designing its appearance. //// SIMPLE, EFFECTIVE, AND A LITTLE BIT O' COLOR Other programs, such as Codehead's MultiDesk Deluxe, Warp 9, Bill Aycock's Calendar, and Charles F. Johnson's ARC Shell, use colors and simple, effective, and clean interface designs to maintain the usefulness of their feature-packed programs without overcoming the user. Sure, they're not required to make their programs look good, but they do it anyway because it improves the programs' selling potential. I suppose some programmers don't realize that it's the little things that make a program impressive. For example, when Warp 9 boots from the AUTO folder, you don't see boring old ASCII characters scroll up the screen, but instead you see a nicely-crafted graphic box containing the Warp 9 logo, followed by the program's credits. This is the only program that displays this type of graphic, and it's unfortunate that other programs don't have this professional-looking "feature." MultiDesk Deluxe and Calendar allow you to change the name that will be displayed in the desk accessory slot. Very few desk accessories do this. No, I personally don't have a use for this option, but there are people who want to have more than one copy of MultiDesk and Calendar installed, so the ability to change the desk accessory's name is useful. Another handy function is in ARC Shell's Configuration screen. Here, you can click the mouse pointer on any pathname and an item selector will appear, enabling you to easily select a path; there's no need for manually typing in pathnames. On the ST, there's absolutely no reason why programs shouldn't implement this feature. Look for details on programming these kinds of features in future issues of AEO-PJ. //// WINDOWS ON THE ST TOS 2.0x and 3.0x give us the ability to have up to seven windows open at once, which is an increase from previous TOS versions which only allowed four; MultiTOS allows you to open as many windows as memory will allow. With the four-window restriction lifted, programmers can take advantage of this and use the windows for other things. Papyrus, an excellent, feature-packed graphical word processor from Germany, uses very few dialog boxes. Everything from selecting fonts to selecting patterns and colors are done in windows. If the font window is open, for example, it will display the font type, sizes, and other font details that are currently being used where the cursor is. Everything is done with windows in Papyrus, which means that they can be topped and moved, making things very flexible for the user, especially if he has a large screen monitor. //// "HI THERE." I will never forget viewing the Lotus Improv demo for the NeXT. The one feature that fascinated me was that the program spoke. It used digitized voices to introduce the user to the program and describe its features. But there's no reason why this can't be done on the ST. And finally, it has. No, the application is not some wiz-bang productivity program that costs a couple hundred dollars. It's a freeware program that converts standard sound files into GEM Sound format. It's one of Mike Allen's first attempts at GEM programming and he did it in assembly language. Mike used his own broadcast voice to produce the sounds, which are used in various dialog boxes. For example, in one dialog box with three buttons labeled ".SPL," ".SAM," and "Done," the voice that says, "Dot S-P-L" comes out of the left speaker, the voice that says, "Dot S-A-M" comes out of both speakers (so it's centered), and "Done" comes out of the right speaker. The voices are very well done and sound professional. It's great that someone has finally broken the ice. We need more interfaces done like this one, and with Atari's System Audio Manager debuting soon, I'm sure they will be; apparently, one feature in SAM allows programmers to attach specific sounds to certain program functions. //// SCROLL BAR REMOVAL Those with large-screen monitors don't have worry about this problem, but if you have a standard-size screen, and most of us do, the scroll bars on windows often get in the way. They don't enable us to see a full 80 columns or a full 24 lines. STalker 3.0, a GEM terminal program, first presented us with the option to remove the vertical and horizontal scroll bars, and I think other programs should allow this as well. Even though the scroll bars may be removed, STalker still allows the user to resize the window and scroll through an on-line session. Even when window gadgets and scroll bars are present, the user can move STalker's window by holding down the right and left mouse buttons anywhere in the window. SHIFT-arrow keys will also scroll through the window. When no window gadgets and scroll bars are present, holding down the right and left mouse buttons in the lower right-hand corner of the window will resize it. All scroll and title bar toggle operations are done via drop-down menu selections or hotkeys. Toggling the window's title bar is done with ALT-SHIFT-` (ALT-~). You can toggle the window's vertical scroll bar with ALT-SHIFT-\ (ALT-|). Finally, toggling the horizontal scroll bar is done with ALT-SHIFT-- (ALT-_). //// HELP MESSAGES FOR ICONS Everyone knows what an icon is. It's an image that represents an object, a function, or a command. But how many times have you been overcome with a myriad of icons in an application, only to look at one and wonder, "What does THAT one do?!" Calamus SL is one of those applications that present the user with an enormous number of icons. SL does so many things, that it would be impossible to have each function listed in drop-down menus; you'd need a large-screen monitor just to display them. But then how do you tell the difference between some of the icons in the Page Module's Page Layout Command Group and those icons in the Frame Module's Text Frame Special Functions Group? Many of them look very similar. The brains at DMC have implemented a system that displays a "Help Message" in the upper-right hand corner of the screen. When you pass over the Insert Empty Pages icon, you know that's different from the Piping from Frame to Frame icon because a short Help Message tells you so. As you move from icon to icon, the Help Message changes, displaying the name of the icon. Calamus SL and the new NeoDesk Control Panel are the only programs I've seen that use this feature, and I think other programs would serve their users better by doing so. //// CONFIGURABLE HOTKEYS Many programs provide hotkeys, which are keystrokes that quickly perform menu operations without using the mouse. For example, an ALT-Q or a CTRL-X keypress will usually quit or exit a program, instead of requiring the user to go up to the File menu and select Quit or Exit. However, most programs don't follow the same hotkey conventions. Some programs ask for ALT-Q, for example, while others ask for CTRL-X, and this dissimilarity confuses users. I'd like to see programs allow for custom configurations of hotkeys. The user can use the default settings, or he can create his own. Atari's own NewDesk is an excellent example of enabling the user to configure his own hotkeys. //// MULTIPLE WINDOW MENU SELECTION The best programs allow the user to load more than one file at a time. Whether it's a word processor, desktop publishing program, or paint program, the ability to load multiple files is always convenient. However, what's inconvenient is that some programs don't make it easy for the user to switch between windows. They offer no way to switch, other than selecting the windows themselves. Even if you have only two documents loaded, you may find that selecting the one on the bottom can be a bothersome task, because you must first move the topmost window if it's expanded to the full-screen. Programs should have a drop-down menu whose only function is to list the various windows that are open. Then, when a user wants to top a window, he can just select it from the menu. //// INVISION ELITE ANIMATION SEQUENCE Finally, like the CyberCube Interactive Installation demo, or Warp 9's loader display, or Mike Allen's sound converter, there are some things that aren't necessarily useful to a program, but instead, they give it its "cool" factor. One program with a very high "cool" factor is INVISION Elite. Not only is INVISION Elite an excellent monochrome raster graphics program with an easy-to-use, icon-based interface with Help Messages, but it also has a magnificent introduction and exiting animation sequence. If you haven't seen this thing, you should. It contains a collage of spectacular black-and-white images that dissolve, zoom, and spin, making it an attractive, eye-catching presentation. There's a demo on several of the networks, but if you need a raster graphics program, this one really looks great. //// CLOSE DOCUMENT Users love programs that are easy to use and fun to work with, and programmers need to pay attention to users' preferences if they want to create successful products. While some of the suggestions I mentioned are really extraordinary, others are essential. Just like intuitive and attractive interfaces, it's the little things that make a program impressive. But interfaces don't need to be noticed to be effective. Usually, a good interface is one that isn't noticed and doesn't get in the way. If there's a program that you especially enjoy using, take a look at it a little closer. Try to figure out what you like about it. When you find it, you can strive to include those features in your own programs. /************************************************************************/ Brain Stem Rotator By: Warwick Allison /************************************************************************/ A world class, nightmare problem that may not have a solution. You have one minute to solve! My favourite is the Knight Problem. Starting anywhere you like on a chessboard, move a Knight so as to jump on every square one and only once. A chessboard is 8 x 8 and Knights move in an L shape: ........ ........ k = knight ..o.o... o = legal moves from k .o...o.. ...k.... .o...o.. ..o.o... ........ Try to write a program to do it. Try it for larger (and smaller) chessboards. How many solutions can you find? /*************************************************************************/ Glossary of Terms /*************************************************************************/ AES = Application Environment System BTW = By the way FSF = Free Software Foundation GEM = Graphics Environment Manager IMO = In My Opinion LEX = Lexical Analyzer OO = Object Oriented OOL = Object Oriented Language OOP = Object Oriented Programming USL = Unix System Laboratories 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) Call or write for details. ----------------------------------------------------------------------- From: Mike Fulton, Atari Developer Support To: Atari Developer Community & Atari Programmers everywhere Atari Developer CDROM --------------------- Atari is currently in the production stages of creating a Developer CDROM disc that will be offered to both new and existing developers. The initial release is slated for the developer conference that is going to be held on Friday, September 17, 1993 in Glendale, California, the day before "Atari Computer Faire, Version 7.0" starts (AKA "The Glendale Show"). Once the initial version of the disc has been released, we expect to have updates a couple of times a year with new material and any necessary corrections. Once you've purchased the disc, you'll be able to get the upgrade discs at reduced cost. (Exact pricing information for the disc and/or updates is not available at this time, but it should be pretty reasonable.) Since not all developers will already be using a CDROM drive with their system, we plan to include a floppy disk that will have the necessary CDROM driver software to allow them to access the disc once they have connected a CDROM drive to their computer. =========================================================================== Here's a preliminary outline of what we hope to include on the disc: (This is still preliminary subject to change without notice, of course!) =========================================================================== * All of the current versions of all of the programs and files in the Atari developer's kit, plus additional related items not included in the regular kit. * Atari Falcon030-specific developer's tools such as the DSP Assembler, Linker, and Debugger * Current release of SpeedoGDOS outline font scaler * Current release of MultiTOS multitasking operating system * Atari Works -- integrated word processor, spreadsheet, database * Programs that currently ship with Atari computers such as the Falcon030 (but which work with older machines) that not everybody may have, such as: CalAppt -- Calendar/Appointment Book/Address Book Procalc -- Calculator Accessory (with number-base conversions) Talking Clock -- STE/TT/Falcon030 Talking Clock Program/accessory Accessory Games -- Breakout, Landmine Audio Fun Machine -- Assign sounds to keystrokes & system events on STE/TT/Falcon030 * Online Documentation -- The disc contents will be described in an online hypertext format. Additionally, at least some of the regular developer's documentation will also be available in hypertext format. (With more to come on future updates.) Imagine being able to look at a function reference of all the functions described in the GEMDOS manual. You click on "Fsfirst()" and get a description of that function. While you're looking at that, you start to wonder what the rules for legal filenames are, so you click on "Filename" and see a description of what constitutes a legal filename. * Demo programs -- graphics demos, sound demos, etc. For all machines, especially the new Atari Falcon030. * Sample source code -- for new TOS features, from past developer newsletters, and so on. =========================================================================== Aside from all of the above, there are three additional categories of files that we would like to include. These categories all depend to a large degree on submissions from the Atari Developer community. =========================================================================== * Public-domain & shareware development tools, utilities, & source code. We would like to include as much public domain and shareware stuff as we can. We want development tools, utilties, sample source code, and anything else that is programming-related. For example, we would like to include things like the GNU GCC compiler (C & C++) and other GNU tools, and possibly other PD or shareware compilers as well. We would like to include just about any kind of developer oriented program, but we do have a few basic guidelines about the submissions that we would like to follow: 1) The software should be compatible with both SpeedoGDOS and MultiTOS. By 'compatible' I mean it doesn't crash or mess up the display in some fashion. Taking advantage of either SpeedoGDOS or MultiTOS is not required, although it is certainly welcome. If you have something that you might like to submit, and you aren't sure how it behaves with SpeedoGDOS or MultiTOS, please just go ahead and submit it. We will be testing submissions as much as possible before including them. Include information for any compatibility problems you already know about. If you know for a fact that your submission doesn't work with SpeedoGDOS and/or MultiTOS, but feel that other developers will still find it quite useful, then let us know about it and perhaps we'll make an exception here and there (pun absolutely intended! ;^). In most cases, incompatibility problems with SpeedoGDOS and MultiTOS are easy to fix, because they are usally caused by one of a small handfull of programming errors. If you make your submission, it may be the case that we can point out what's wrong and you will be able to fix it without too much trouble. One problem that some programs have regarding MultiTOS is that they don't do their console & screen I/O in a consistent manner. They mix up BIOS, GEMDOS and GEM calls all together. For example, they might use Bconin() to get keyboard input and then they'll use v_gtext() to output information to the screen. Or they'll use evnt_keybd() or evnt_multi() to get their input, and then use Bconout() or Cconws() or some other such BIOS or GEMDOS call to do their screen I/O. This doesn't work too well with MultiTOS where programs generally don't own the whole system and have to share the keyboard and display screen with other programs. If you're going to do be a GEM program, then you should do all of your screen & console I/O through GEM. If you're not a GEM program, then you should do all of your console & screen I/O through the BIOS and GEMDOS. Pick one or the other and stick with it. 2) The submission should have at least minimal documentation, preferably in English. If complete documentation is only available in another language, then we'll have to judge how difficult the program is to figure out and use without documentation. Submission Guidelines --------------------- * If something is clearly marked as being public domain, you do not have to be the author to submit it. * On files marked "Public Domain", if there is a notice about distibution restrictions of some kind, then the author may have misunderstood what "public domain" means and we'll try to contact them to straighten things out and make sure they don't have a problem with us including their stuff on the CDROM. (Legally speaking, once something has been released into the public domain, the author has given up the rights to put any restrictions on it of any kind. Free Software and Public Domain Software aren't the same thing.) * If something is marked as being shareware, you do not have to be the author to submit it, but you must include all of the appropriate files including the information on how to contact the copyright holder so that we can contact them to obtain permission if necessary. * If something has a copyright notice, but is marked as being freely distributable, you do not have to be the author to submit it, but you must include all of the appropriate files. * If something has a copyright notice, and is not marked as being shareware or as being freely distributable, before submitting it, please send email with whatever information is available for the program, but not the program itself. =========================================================================== * Demo versions of commercially available software We would like to include disabled demo versions of commercially available software. For example, if we weren't including a fully working version of Atari Works, we might instead include a demo version that would let you load and edit files, but not let you save or print (or would print with a special "DEMO VERSION" box on top of the regular text). We would like to concentrate on developer-oriented & power-user software such as programming languages and utilities, program shells, disk utilities, and so forth. However, if space permits, we may be able to include a few more end-user oriented demos. If you would like to make such a submission, let us know and we'll try to get it on the disc if possible. A CDROM holds about 600mb and while that may sound like a lot (and is!) it can still get filled up very quickly. It is strongly recommended that demo versions have their disabled sections completely removed, not simply disabled. If your demo version isn't supposed to be able to print, then take the printing code out completely rather than simply jumping past it. If you don't take such steps, then somebody may figure out how to re-enable the disabled sections of the program. =========================================================================== * Locked (password encrypted) versions of shareware and commercially available software To go along with the demo versions mentioned above, it would be great if we could include actual working versions of some of these products. Let's use Hisoft's Lattice C as an example: Suppose that there was a demo version on the disc that would let you create source code files up to 5K long and compile them. But you couldn't save the files, and you could only have 1 object module, and the resulting program would say "COMPILED WITH DEMO VERSION OF LATTICE C" several times whenever you ran it, and only work right if the Lattice C integrated environment had passed it a special code on the commandline when it ran. Such a demo version would give the user a reasonable chance to see the program and decide if they like it or not, but without making the demo version useful in its own right. So now a user sees the demo version and says "Wow, this looks pretty cool, and I'd like to buy the real thing." So they call up the publisher, which would be Oregon Research here in North America, or HISOFT in the U.K. and Europe, and they say "I have the Atari Developer CDROM and I want to purchase Lattice C". At this point, the publisher would take down the user's credit card number, and say "What's the serial number for your CDROM?" and the user would tell them, and then they would be given a special password that can be used to install a fully working version of the program onto their hard disk from the CDROM. Some documentation would be included online, and the user would get a regular set of manuals in the mail a few days later. This is good for the user: he gets to try out the software before he buys it. This is good for the publisher: you save some money because you don't have to pay for fancy packaging, floppy disks, or even for manuals if you can manage to get it all in online form. You can sell the password at a discount compared with the regular price, and still make more per package than you normally do (since there is no distributor or dealer discount involved). This is good for the user: he gets to save a little money and gets to install the software from CDROM instead of having to do it from floppy disks. This is good for the publisher: You've got direct advertising of the most effective kind aimed at the users who are going to be most interested in this kind of product. How does it work? Will it be secure? Each CDROM will come with a floppy disk that is serialized. Included on this disk will be an installation program shell that will be used to install the locked software after a user has purchased the password. This will be something that Atari will put together that works as follows: The user will run the shell, and their serial number will be displayed on screen. They'll give this number to the publisher, and the publisher will use a special program or spreadsheet or otherwise figure out what the password needs to be, and give the user this password. Now the user can tell the installation shell what they want to install. They'll point at the desired item and then the shell will execute an installation program that the publisher will create. The CDROM serial number will be given to this installation program. Then the publisher's install program will get the password from the user and combine it with the CDROM serial number to generate a decryption code. Then the install program will use this code to decode and install the program. There's more detail here than I'm giving, but I'd rather discuss it only with those developers who are making a submission. I think the basic idea that's important to get across is that it will be at least as secure as your basic floppy disk release. Plus, the resulting installed programs can be marked in such a way that you'd be able to figure out the serial number from the CDROM they were installed from. Time permitting, there will probably be an Atari supplied installation program that is capable of working in this fashion, and it will be made available to those developers who are interested. =========================================================================== For the most part, we would like to avoid the use of file-compression utilities such as ARC, LHARC, ZOO, or ZIP. We would prefer to have files on the CDROM in an uncompressed format that is ready to use. (The encrypted fully working versions of commercial software would be an exception here.) However, if we have so many submissions that we run out of room, some material may be placed onto the disc in an archived format. We plan to include the various file compression utilities on the disc, however, so the user will be able to decompress anything on the disc without needing to get anything like a decompression program from some other source. =========================================================================== Please keep in mind that this is a developer-oriented CDROM, not aimed at the average end-user. There will probably be some sharp edges to watch out for, although we'll try to make everything as easy to figure out and use as possible. If you want to submit an encrypted version of your software, please contact me AS SOON AS POSSIBLE so that we can get things worked out as early as possible. In order to be included on the initial release of the disc, submissions must be received before the deadlines given below. Submissions made after the deadlines will be included if possible, but will most likely be held over for the next update of the disc. The deadline for all submissions except encrypted versions of commercial programs is August 7. The deadline for encrypted versions of working programs is August 21. The CDROM will be going to production approximately the first week of September. If there is some special reason you cannot make either deadline, please contact me as soon as possible so that we can make special arrangements if possible. Your Submissions Are Welcome! Send submissions, questions, comments, etc. to Mike Fulton at: Mailing Address: EMAIL: Atari Corp. GEnie = MIKE-FULTON Attn: Mike Fulton Delphi = ATARITECH 1196 Borregas Ave. Compuserve = 75300,1141 Sunnyvale, CA 94089 Internet = 75300.1141@compuserve.com Atari BBS (408) 745-2196 (Log on with name of "Atari Dev1" and use "DEVONE" for password, send email to "Mike Fulton". You won't be able to read messages or download files with this account, but you can upload and send me email.) /************************************************************************/ Sources of Information (References) Books, Magazines and Company Information /************************************************************************/ book: C-manship Complete by Clayton Walnum Taylor Ridge Books PO BOX 48 Manchester, Connecticut 06040 USA (203)-643-9673 (voice) book: The C Programming Language (2nd edition, ANSI C) by Brian Kernighan and Dennis Ritche ISBN 0-13-110362-8 book: The Standard C Library by P.J. Plauger ISBN 0-13-131509-9 Prentice Hall Englewood Cliffs, New Jersey 07632 USA /***********************************************************************/ 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. We are also looking for problems/solutions for/to the Brain Stem Rotator. * More on Advanced Computing using FLEX * Object Oriented Programming * Brain Stem Rotator * Developer Tool updates 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 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 it 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. /************************************************************************/