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