Atari Explorer Online: 19-Aug-93 Programmers' Journal #1
From: Bruce D. Nelson (aa789@cleveland.Freenet.Edu)
Date: 08/25/93-05:06:36 PM Z
From: aa789@cleveland.Freenet.Edu (Bruce D. Nelson)
Subject: Atari Explorer Online: 19-Aug-93 Programmers' Journal #1
Date: Wed Aug 25 17:06:36 1993
/***********************************************************************
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 <grin>). 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 <stdio.h>
main(void)
{
printf("hello atari world\n");
return 0;
}
<=== end === >
<=== cut here K&R or (non ANSI) code begins here === >
#include <stdio.h>
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.
<sc>r an r, but only if scanner is in start
state sc.
<sc1,sc2>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).
<<EOF>> an end of file.
<sc1,sc2><<EOF>> an end of file when in start state sc1
or sc2.
Declarations can name common occurring subexpressions. the format is:
<C style name><whitespace><regular expression>.
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 */
<dquote>\" ECHO;BEGIN(INITIAL);/* done with quoted string */
<dquote>.|\n ECHO; /* else continue string */
<squote>\' ECHO;BEGIN(INITIAL);/* done with single quotes */
<squote>.|\n ECHO; /* else continue scan */
<sscomment>.+ ECHO; /* echo to end of line */
<sscomment>\n {fputs("*/\n",yyout);BEGIN(INITIAL); /* end the
comment */}
<ccomment>"*/" ECHO;BEGIN(INITIAL); /* end of C comment */
<ccomment>.|\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 <stdio.h> #include <stdio.h>
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:
y Speed - 32 MHz operation, yields 16 MIPS.
y Precision - 24 bit internal and external data paths, yielding 144
dB dynamic range. 56 bit accumulators can range over 336 dB.
y Parallelism - Programming model is three execution units operating
in parallel.
y 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
y 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 <DIR> 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 <DIR> 10-27-92 4:08p
README TXT 996 10-27-92 1:09p
VOL_100 <DIR> 10-27-92 4:08p
VOL_200 <DIR> 10-27-92 4:08p
VOL_300 <DIR> 10-27-92 4:08p
ZIPPED <DIR> 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 <iostream.h>
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 <stdio.h>, 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 <stdio.h>
#include <string.h>
#include <stdlib.h>
/*
** 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 <Return>. --
-- --
-- 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! <grin>
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.
/************************************************************************/
-----------------------------------------
Return to message index
