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 another room to discuss things
<[Splat!] DMJ> Youc an do that with a linker, Tim.
<[Chris] C.OATES2> well, you can do in-line assembly with laser C...
<[#include] M.HILL13> then breaking into language groups to accomplish it
<[Sean@TWP] P-DIRECT> All of this is just prelimiary, it isn't set in
stone.
<[Host] MIKE-ALLEN> Ok, how about this. Twice a month, meet in room one
for general discussion and then split for the various languages. OK
folks?
<[Splat!] DMJ> That sounds good.
<[#include] M.HILL13> We have C gurus, Assembly gurus, Logo Gurus :->
<[Chris] C.OATES2> How about the really important things? Like group
name, motto, mascot & t-shirt design??? :)
<[Tim@TWP] P-DIRECT2> I know, but what linker would handle Pascal,
Assembly, C, and Modula 2 object files?
<[Sean@TWP] P-DIRECT> <raising hand>
<[Splat!] DMJ> Logo gurus?
<[Chris] C.CASSADAY> Sounds good to me.
<[Host] MIKE-ALLEN> Ok, thats it.
<[#include] M.HILL13> Sounds good!
<[Zombie] R.ANISKO> some C novices (like me :-)
<[Chris] C.OATES2> a 'C' Grue?
<[Splat!] DMJ> If they're compiled properly, they should all have similar
calling conventions, Tim.
<[Host] MIKE-ALLEN> Any objections to 1st and 3rd thursdays at 10pm
Eastern?
<[Kim] K.SWIFT> But don't we have Babylon with many languages? Aren't we
a small enough group for one language?
<[Splat!] DMJ> Sounds good to me.
<[Sean@TWP] P-DIRECT> No objections from me...
<[Tim@TWP] P-DIRECT2> Pascal calling conventions are different from C in
the standard... Assembly has none.
<[#include] M.HILL13> Sounds good!
<[Splat!] DMJ> No Kim, we DON'T have Babel.
<[Chris] C.CASSADAY> No objections.
<[Bud] B.CONNOLLY1> Go fo it.
<[Host] MIKE-ALLEN> OK - that's it.
<[Kim] K.SWIFT> oops, Tower of Babel <g>
<[Chris] C.CASSADAY> My babel fish is nicely installed in my ear.
<[Splat!] DMJ> Tim, assembly can be written to use C calling conventions
(of course).
<[Host] MIKE-ALLEN> Now to the fun part. Project nominations?
<[Zombie] R.ANISKO> will the pertinent info of this meeting be posted in
the BB?
<[Sean@TWP] P-DIRECT> Now Mike writes it down in stone.. :)
<[Tim@TWP] P-DIRECT2> I know.
<[Splat!] DMJ> Yeah, it should, Rob.
<[Chris] C.OATES2> # include <babelfish.h>
<[#include] M.HILL13> I have an idea!
<[Host] MIKE-ALLEN> Lets go around the horn again. Let's start with Sean
again. ga sean.
<[Tim@TWP] P-DIRECT2> 5 * 9 = 42
<[Sean@TWP] P-DIRECT> GEM window based simple terminal.
<[Chris] C.OATES2> that works on the Falcon??? :)
<[Sean@TWP] P-DIRECT> <big grin>
<[Host] MIKE-ALLEN> Let me do this a little differently. First, it
seemed to me that everyone wante projects. Any objections to that?
<[Splat!] DMJ> No.
<[Bud] B.CONNOLLY1> No
<[Zombie] R.ANISKO> projects are ok with me...
<[#include] M.HILL13> No objections.
<[ACK] C.FOLLETT> no
<[Chris] C.OATES2> nope
<P.HANZE> projects sound great!
<[Duane] D.CHARTER> no objection
<[Sean@TWP] P-DIRECT> Just fine with me, obviously.
<[Chris] C.CASSADAY> NO. objections.
<[Kim] K.SWIFT> good idea
<[John too] J.G.H.> Hmmmmmm...how we going to list the credits on it?
<wink>
<[Host] MIKE-ALLEN> Guess not. Ok, everyone with a project idea, do a
/rai and I will call on you in some sort of order. /rai now.
<[Splat!] DMJ> Why, list all the names, of course.
<[Duane] D.CHARTER> Use remarks for the names.
<[Host] MIKE-ALLEN> Ok Sean - you first.
<[John too] J.G.H.> Me first?
<[Zombie] R.ANISKO> j2 - we'll all create a randomizer, and IT will list
the names in random order :-)
<[Sean@TWP] P-DIRECT> As I said, a GEM window based simple terminal. It
would make all the standard OS calls, and would make use of GEM and
BIOS/XBIOS. Perfect for "testing" out our format. GA
<[John too] J.G.H.> Good looking (forgotten) Sysop's first?
<[Splat!] DMJ> Except for the complete lack of support in the OS for
serial stuff...
<[Host] MIKE-ALLEN> Thanks Sean.
<[Host] MIKE-ALLEN> Mike Hill ga.
<[#include] M.HILL13> I say we start at simple at first. One of the nice
things about Windows is the API calls for creating INI files
(configuration files). I say we make a library other programmers can use
that lets them create ini files that store configuration data for their
programs.
<[Splat!] DMJ> Already exists, Mike, Geneva handles .INI type files.
<oops, speaking out of turn again.>
<[#include] M.HILL13> Not everyone has Geneva though. Storm for instance
does this. INI files are basically text files. GA
<[Tim@TWP] P-DIRECT2> Yeah, but how well does Storm work?
<[Splat!] DMJ> <wince>
<[Host] MIKE-ALLEN> Thanks, Mike. I like starting small myself. dmj you had
an Idea?
<[#include] M.HILL13> Sorm works great as far as I can tell.
<[Host] MIKE-ALLEN> Tim-Storm works very nicely!
<[Splat!] DMJ> Yeah, Sean gave me an idea. How about a GEM-based text
editor? Nothing fancy.
<[Tim@TWP] P-DIRECT2> I'll take your word for it.... I haven't used it.
<[Sean@TWP] P-DIRECT> Storm has a few problems on the Falcon.
<[Splat!] DMJ> What doesn't?
<[Sean@TWP] P-DIRECT> w/ScreenBlaster specifically.
<[Splat!] DMJ> I can think of a few reasons why.
<[Host] MIKE-ALLEN> hey guys, lets hold off the chatter a little.
<[Splat!] DMJ> <oops, sorry>
<[Sean@TWP] P-DIRECT> Okay, Mike. <grin>
<[Host] MIKE-ALLEN> Kim - I think you had an idea? ga,
<[Tim@TWP] P-DIRECT2> I would like a nice ASCII text editor, and I could
write one. I wrote a nice editor for UNIX... it's paragraph oriented and
auto-word wrap and everything... how about I release source?
<[Kim] K.SWIFT> I'd like to see CD-Rom support on the Falcon. Anything
we can do?
<[Splat!] DMJ> You like assembly?
<[Tim@TWP] P-DIRECT2> <sorry out of turn>
<[Kim] K.SWIFT> Also, MIDI.
<[Sean@TWP] P-DIRECT> Start smaller? <big grin>
<[Kim] K.SWIFT> ga
<[Host] MIKE-ALLEN> Kim - I'd like to access a CD ROM without MTOS!
<[Splat!] DMJ> Me too.
<[#include] M.HILL13> Here Here Mike!
<[Chris] C.OATES2> use MiNT? :)
<[Splat!] DMJ> That's as bad as using MTOS.
<[Host] MIKE-ALLEN> Chris Cassaday = your idea? ga
<[John too] J.G.H.> We can also have some of the Advanced programmers
work on a more advanced project so they don't get too bored with us
lesser knowledgable programmers ;>
<[Tim@TWP] P-DIRECT2> I'd like to access CD rom without slowing down my
machine.
<[Chris] C.CASSADAY> Super duper program launcher for MTOS and Geneva.
Would except LZH, ARC, ZOO, ZIP, ARJ, etc and lauch the appropriate
program. Would be user configurable to allow user to add new files...
Support drop and drag protocol to allow window.. to remained open so
user could pass programs to install as new app or data files to execute
them...ga
<[Host] MIKE-ALLEN> Hmmm - what would you call that in 5 words or less,
Chris? ga
<[Chris] C.OATES2> "Super Duper Program Launcher"???
<[Chris] C.CASSADAY> Super Duper Program Launcher?
<[Chris] C.OATES2> :)
<[Chris] C.CASSADAY> <rbg>
<[Chris] C.OATES2> Great names think alike...
<[Chris] C.CASSADAY> <rbg>
<[Host] MIKE-ALLEN> Rob - your idea? ga.
<[Zombie] R.ANISKO> something simple? how bout a GEM-based text
convertor - convert between ST/PC, MAC and Unix files - it would be basic
I/O and GEM windows fgeatures... maybe runnable by both GEM and command
line?
<[Host] MIKE-ALLEN> Ok, rob. Thanks.
<[Host] MIKE-ALLEN> My personal idea would be a library of common
routines that every programmer needs, like walking the rectangle list.
We could all then have a library to start with to use on a larger
project.
<[Host] MIKE-ALLEN> OK, lets vote.
<[#include] M.HILL13> George Bush
<[Zombie] R.ANISKO> Bill the Cat
<[#include] M.HILL13> Oops wrong voting.
<[ACK] C.FOLLETT> right on, Zombie!
<[Host] MIKE-ALLEN> We have in nomination: 1) a terminal prg, 2) a
configuration library, 3) a text editor, 4) a CD rom reader, 5) a word
processing format converter and 6) library of routines.
<[Sean@TWP] P-DIRECT> Something tells me this is going to be edited out.
<[Host] MIKE-ALLEN> Everyone think.
<[Host] MIKE-ALLEN> ok all in favor of #1 (term prg) do a /rai now.
<[Host] MIKE-ALLEN> ok, I got NO /rais for #1
<[Splat!] DMJ> Guess we killed the term program.
<[Sean@TWP] P-DIRECT> Awww...shucks. :)
<[Host] MIKE-ALLEN> hey guys, just a few minutes more and then we can
chatter!
<[Splat!] DMJ> The natives are restless...
<[Host] MIKE-ALLEN> all in favor of #2 (configuration utility) /rai now.
<[Tim@TWP] P-DIRECT2> Reminds me of an elephant joke.
<[Mike] M.HILL13> Can I stuff the ballot
<[Splat!] DMJ> <snicker>
<[Host] MIKE-ALLEN> I got one rai.
<[Mike] M.HILL13> Not the editor!!!!!!!!!!!
<[Host] MIKE-ALLEN> #3 (text editor) /rai now
<[Chris] C.CASSADAY> I presume by configuration utility you mean "Super
Duper Program Launcher"?
<[Mike] M.HILL13> Boooohhhhh
<[Host] MIKE-ALLEN> 4 for #3 - chris - nope, launcher coming up.
<[Zombie] R.ANISKO> (how 'bout an Amiga emulator ;-) oops, quiet :-O
<[Chris] C.OATES2> can we vote for more than one?o
<[Mike] M.HILL13> Can we vote twice? :->
<[Tim@TWP] P-DIRECT2> How about a wordprocessor or a UNIX clone?
<[Host] MIKE-ALLEN> #4 (cd rom reader) I'd appreciate single votes
please. /rai now.
<[Chris] C.OATES2> text editor = simple word processor...
<[Zombie] R.ANISKO> ...sockets library for MiNT?
<[Mike] M.HILL13> I also mentioned to Mike that a university holds an
annual group programming contest. We can get the rules from the
Internet.
<[Host] MIKE-ALLEN> One for the CD rom.
<[Host] MIKE-ALLEN> #5 (the super-dooper program luncher) /rai now.
<[Mike] M.HILL13> The contest starts mid november
<[Host] MIKE-ALLEN> One for the luncher <g>.
<[ACK] C.FOLLETT> I like this one but I already voted :-(
<[Tim@TWP] P-DIRECT2> Nov 18 for the internet programming contest, I
think.
<[Chris] C.CASSADAY> "Luncher" I'm insulted. <g>
<[Host] MIKE-ALLEN> #6 (word proc text converter) /rai now.
<[Chris] C.OATES2> me too, ack.
<[Sean@TWP] P-DIRECT> Isn't 6 the routine set?
<[Splat!] DMJ> That's what I thought it was.
<[Host] MIKE-ALLEN> I screwed up on the list - I forgot the launcher.
<[Host] MIKE-ALLEN> One for the text converter.
<[Sean@TWP] P-DIRECT> We just did the luncher.. :)
<[Mike] M.HILL13> Yeah we voted on the luncher already!
<[Host] MIKE-ALLEN> Sean - I know we did it, I just left it out of my
initial list.
<[Chris] C.CASSADAY> <sigh>
<[Host] MIKE-ALLEN> Finally, the routine library. /rai now.
<[Kim] K.SWIFT> the supper dipper peanut luncher?
<[Host] MIKE-ALLEN> OK - I got 5 for the library.
<[Chris] C.OATES2> peanut launcher?
<[Chris] C.CASSADAY> <double sigh>
<[Chris] C.CASSADAY> <deep heavy sigh>
<[Tim@TWP] P-DIRECT2> <growl>
<[Zombie] R.ANISKO> sigh young?
<[Mike] M.HILL13> Oh well.
<[Host] MIKE-ALLEN> since we had a bunch of ones an 2s, lets revote with
just the text editor and the library in the running.
<[Tim@TWP] P-DIRECT2> What's to be in this library?
<[ACK] C.FOLLETT> maybe one language could get one project, another a
next project etc.?
<[Kim] K.SWIFT> got a good laugh out of me, worth the visit...
<[Host] MIKE-ALLEN> Text editor, /rai now.
<[Splat!] DMJ> Everything useful, Tim.
<[Splat!] DMJ> <g>
<[Host] MIKE-ALLEN> 4 for the editor.
<[Host] MIKE-ALLEN> library, /rai now.
<[Host] MIKE-ALLEN> 7 for the library.
<[Splat!] DMJ> Wow...
<[Tim@TWP] P-DIRECT2> <whine>
<[Splat!] DMJ> Somebody spank that whiner and send him to bed... <rbg>
<[Zombie] R.ANISKO> }do we need a library card? ;-)
<[Kim] K.SWIFT> Please don't tell me you're going to code the library in
a zillion languages.
<[Host] MIKE-ALLEN> Looks like the lib wins. I suggest that until our
next meeting folks post suggestions for the contents of the library in
cat3/top11.
<[Host] MIKE-ALLEN> Kim - nah only about 3. <g>
<[Splat!] DMJ> Kim, anyone who thinks one language can do it all is
crazy...
<[Tim@TWP] P-DIRECT2> I have a couple routines that draw pixels and horizontal
spans very quickly on any resolution or number of bit planes.
<[Splat!] DMJ> But they're hardware-dependent.
<[Splat!] DMJ> Hi Judy.
<[Tim@TWP] P-DIRECT2> I work only in C and Asm.
<[Kim] K.SWIFT> Anybody who thinks you can do a project in many different
languages is crazy.
<[Mike] M.HILL13> I hope we have many languages, to force everyone to
work in one language is crazy.
<[Host] MIKE-ALLEN> Any one have a calender handy?
<[Sean@TWP] P-DIRECT> We need completely portable code.
<[Bud] B.CONNOLLY1> I have one in sight.
<[Judy B.] ANTHILL> Hi DMJ.
<[Splat!] DMJ> The 18th is Thursday, two weeks from now.
<[Tim@TWP] P-DIRECT2> What's wrong with hardware dependant? We're
programming for Atari, right? We're not planning on using these on a PC,
are we?>
<[Host] MIKE-ALLEN> is the 18th the 3rd thursday?
<[Zombie] R.ANISKO> maybe low level stuff (like telecomm) in asm or C;
more screen oriented stuff, etc in a higherlevel language?
<[Mike] M.HILL13> We might have some working in Assembly, some in C,
others in GFA
<[Bud] B.CONNOLLY1> Yes it is Mike.
<[Splat!] DMJ> Hardware-dependent is almost okay.
<[Sean@TWP] P-DIRECT> Things have got to work in all screen rezes and
colors.
<[Splat!] DMJ> But what about graphics cards, and True Color mode?
<[Chris] C.OATES2> yes! graphics cards!
<[Host] MIKE-ALLEN> Thanks Bud and dmj. Ok, next meeting is the 18th of
Nowonder at 10pm eastern.
<[Chris] C.OATES2> suport Crazy Dots! :)
<[Zombie] R.ANISKO> sean - then we need to know what the screen
resolution is and # of colors (and not just ST Low, Med, and Hi)
<[Sean@TWP] P-DIRECT> Nowonder?
<[Kim] K.SWIFT> 18th of Nowonder?
<[Sean@TWP] P-DIRECT> :)
<[Zombie] R.ANISKO> Ah, no wowonmder..
<[Tim@TWP] P-DIRECT2> The code I was referring to works in any rez with
any number of bit planes, as long as you supply it with a proper MFDB.
<[Bud] B.CONNOLLY1> Freud, your slip is showing ;)
<[Mike] M.HILL13> Ive got my Crazy Dots II ready!
<[Duane] D.CHARTER> Good Night everybody, it's been great. See you on
the 18th.
<[Splat!] DMJ> Except that graphics cards do not use the bitplane format
the ST uses.
<[Chris] C.OATES2> Cool. I want to upgrade soon.
<[Zombie] R.ANISKO> we'll need a "dictionary" of terms - like MFDB for us
novices :-)
<[Splat!] DMJ> Memory Form Description Block.
<[Kim] K.SWIFT> Good night. Don't let the PC's bite. :)
<[Sean@TWP] P-DIRECT> I'm sure that helps him... :)
<[Bud] B.CONNOLLY1> Suggestion: The Atari Compendium should be on
everyones desk.
<[Host] MIKE-ALLEN> Thanks to all who participated. I'll post this
transcript (boy is this going to be a bear to edit!) in the libs. Folks,
please hit cat3/top11 with your comments and suggestions. Thanks for
your co-operation also.
Programming Real Time Conference
November 18, 1993
Host - Mike Allen
<[Host] MIKE-ALLEN> Remember, this initial portion of the rtc is being
captured and WILL be posted! Watch your warts. <g>
<[Parrot Head] C.CASSADAY> You have the floor, Mike. er Screen?
<[Host] MIKE-ALLEN> I didn't see a whole lot of activity in Cat3/Top11
during the last 2 weeks So, we will need a little discussion here. BTW,
I do have some good words. Darlah has arranged for a private lib for the
exchange of code while we're working on things. This lib is lib 19. You
need to send me EMail so that I can arrange for access. So, when we have
code segments to look over, we can upload them for our fellow attendees
without exposing our foolishness to the world. Seems like we decided to
work on a "utility ROUTINE (hi, Keith) library" last session. However I
have seen very little in the way of suggestions as to what this library
should contain. Ok, let me swing around the table the way we did last
time - in order of job number. Sean is first - what do you think, Sean?
ga.
<[Sean@TWP] P-DIRECT> I'll have to pass on this, I'm drawing a blank. ga
<[Host] MIKE-ALLEN> Ok - next we'll ask rob in zombie land. ga.
<[Zombie] R.ANISKO> maybe a "system configuratioN" routine - so we'd know
what TOS version, etc the future projects are working on? kind of a "show
me what I'm running on" function? ga
<[Host] MIKE-ALLEN> Ok, rob thanks. I'm kinda with you. I believe I
posted something like that as a suggestion in 3/11. Paul what do you
think? ga
<[paul] P.LANCTOT> i'm the ultimate rookie but maybe something to
makelsimple graphics portable to IBM? ga
<[Host] MIKE-ALLEN> Hmmmm - might make a good later project. thanks.
Bud, your turn. ga
<[Bud] B.CONNOLLY1> I was thinking of putting in routines that handle
general housekeeping chores. i.e. find the size of the screen you are
working with and then pass back scaling information. GA
<[Host] MIKE-ALLEN> Thanks bud. Chris -any ideas? ga
<[Parrot Head] C.CASSADAY> GEM window management stuff. Walking the
rectangle list, etc. ga
<[Host] MIKE-ALLEN> Chris - walking the rectangle list is one of those
things everyone needs. Good suggestion.
<[Keith] K.GERDES> A "what's my system" seems to be a good idea. I know
from a tech support position, there are times when this info is vital to
debugging.
How about a small homework assignment? It could be something that is
coded in any language, with strictly _TOS_ output. GA
<[Host] MIKE-ALLEN> Not a bad idea. CBARRON, your thoughts?
<CBARRON> Easy text writing in windows without really worrying about the
gem messaging stuff 'too much'. Wxlib is to messy, something fairly
portable elsewhere would be nice. ga
<[Host] MIKE-ALLEN> Thanks. Gary - your thoughts? ga?
<[Gary] G.STOLLMAN> Anything to help us learn programming would be
good..... ga
<[Host] MIKE-ALLEN> My thought was a two level "what am I" type of
routine. First some sort of routine to report what the system actually
is and then a routine as to what the current state is. <two different
things!> I must admit that I had hoped for a little more discussion in
3/11 so that we could minimize the "what do we do" talk and get to the
"how do we do it" end of things. I'm just going to open the floor to
general discussion for a few minutes and see if we can hash out our first
"routine" project. Go at it folks, I'll watch. ga
<[Sean@TWP] P-DIRECT> The library of routines idea is good, but is a bit
limited until we know more about what we would need in it. Of course, it
might be a good idea to build it up as we go along... (ga?)
<[Bud] B.CONNOLLY1> Mike, can you define what you mean by 'current
state'?
<[Zombie] R.ANISKO> how much memory free, etc - my guess as to one of the
things Mike means
<[Host] MIKE-ALLEN> Bud - resolution, palatte, Multi-tasking, etc.
Anything that is user configurable (or program configurable).
<[Bud] B.CONNOLLY1> ok, got ya.
<[Keith] K.GERDES> Cookies in the cookie jar.
<[Bud] B.CONNOLLY1> If the jar is there.
<[Sean@TWP] P-DIRECT> People with the Compendium would be at a *slight*
advantage... <g>
<[Host] MIKE-ALLEN> Cookies are part if it - also AES and GEMDOS
versions.
<[Keith] K.GERDES> Variables in the OS header.
<[Bud] B.CONNOLLY1> I got mine! :^)
<[Keith] K.GERDES> Low memory variables.
<[Host] MIKE-ALLEN> Do we count on negative LineA variables?
<[Keith] K.GERDES> Line-A will always be present... no matter what you
know who says.
<[Sean@TWP] P-DIRECT> It would be best to stick with VDI.
<[Bud] B.CONNOLLY1> Didn't Atari say Line-A will no longer be supported?
If so, probably wouldn't want to mess with Line-A.
<[Zombie] R.ANISKO> is it LineA that doesn't work on non-ST modes?
<CBARRON> Anythin that is user configurable? Huh, that is a wide
area... Re Line A I say don't rely on any of that! Positive or neg.
offsets.
<[Keith] K.GERDES> It depends strictly on what you want to and have to
do.
<[Host] MIKE-ALLEN> Which cookies should we check - only the Atari
defined cookies? Could miss the Geneva cookie if we did that.
<[Bud] B.CONNOLLY1> We could start simple and add routines later as we
find the need for them.
<[Keith] K.GERDES> A library routine should take a cookie parameter and
then search for it. Returning a status value.
<[Zombie] R.ANISKO> could build a list of cookies as we learn about them
<[Host] MIKE-ALLEN> Ok - let me make a suggestion. I already have an
assembly language routine for reading the cookie jar. I will post it in
Lib 19. Do we wish to store the cookies internal to the progam? Or just
have the ability to look for a cookie.
<[Sean@TWP] P-DIRECT> Could that cause problems with MultiTOS?
<[Host] MIKE-ALLEN> Sean - How so?
<[Bud] B.CONNOLLY1> Look for what we need and set up the program as
necessary.
<[Sean@TWP] P-DIRECT> Just wondering...I have no idea, myself.
<[Host] MIKE-ALLEN> I have run a program that uses the cookie reader
under MTOS - no problem that I could see.
<[Keith] K.GERDES> Maybe Dan's JARxxx program would be easier to use. It
has hooks to get cookies.
<[Host] MIKE-ALLEN> How about I post two versions. The one that I
presently have and another version that will read and store all the
cookies. Keith - Dan's hooks are nice. I'm going to change my prg to
check for JARxxx first and use it if it is available.
<[Bud] B.CONNOLLY1> Do cookies change while a program is running?
<[Host] MIKE-ALLEN> I assume that we are trying to get a What is my
Machine routine? Bud - It would be possible under MTOS or Geneva, I
think.
<CBARRON> Reading is no problem, writing might be as it becomes a
question who owns the ram reallocatd for cookies if room does not exist.
The latter may cause multitaskers some 'problems'.
<[Host] MIKE-ALLEN> I was just trying to establish the current machine
capabilities, not change them <g>
<[Bud] B.CONNOLLY1> Yes Mike, cookies and system variables should tell us
that.
<[Host] MIKE-ALLEN> I guess we also need to check AES version (Global[0])
and GEMDOS version. what else?
<[Zombie] R.ANISKO> AES, VDI, TOS versions. MiNT version?
<[Host] MIKE-ALLEN> How about GDOS (is it there and if so, what kind?
Cookie for FSM and Speedo how about the old one)
<[Parrot Head] C.CASSADAY> current screen res.
<[Bud] B.CONNOLLY1> Resolution and aspect ratio.
<[Host] MIKE-ALLEN> MiNT is in a cookie.
<[Parrot Head] C.CASSADAY> number of bit planes.
<[Zombie] R.ANISKO> cool - I believe MiNT 1.0 and above were stored a
little differently than pre-1.00 if that matters... dunno if that's via
cookie or not though...
<[Sean@TWP] P-DIRECT> There is a FSMC cookie. It indicates the presence
of either FSM of Speedo.
<[Host] MIKE-ALLEN> Chris, Bud - that is more in the "What is my current
state" category as opposed to "What am I."
<[Parrot Head] C.CASSADAY> ahh.
<[Bud] B.CONNOLLY1> ok
<[Host] MIKE-ALLEN> How do we detect 3rd party video boards?
<[Bud] B.CONNOLLY1> VDI?
<[Host] MIKE-ALLEN> Maybe so. Where does the VDI version live? Sounds
like homework! "Where is the VDI version?"
<[Parrot Head] C.CASSADAY> <grabbing the compendium>
<CBARRON> Do these boards, drivers install cookies, that is what they
were supposed to be for.
<[Sean@TWP] P-DIRECT> Would vq_extnd() tell you if you have a video card
on the system?
<[Host] MIKE-ALLEN> I dunno. Maybe we should ask Gribnif, Lexicor and
CyberCube.
<[Bud] B.CONNOLLY1> According to the Compendium...Page 7.8 you can
determine the category of the device from v_opnwk() work_out(13) and
vq_extnd() work_out(5).
<[Zombie] R.ANISKO> where's Yat? he might be abkle to help us re: Nova
card
<[Host] MIKE-ALLEN> <grabbing his compenduim ...>
<[Parrot Head] C.CASSADAY> Good point. determing whether you are in a
palletted video mode or true color mode would be important.
<[Host] MIKE-ALLEN> Chris - again that is a "what is my state" not "what
can I do." Hokay - how about we devide the various questions up for
"homework." I volunteer for the Cookie Jar in assembly (since I have most
of it done already <g>) anyone for C and/or GFA versions?
[insert massive lack of screen activity here!]
<[Host] MIKE-ALLEN> Hmmm - no volunteers,
<[Parrot Head] C.CASSADAY> <grin>
<CBARRON> the C code is in the atari docs. I'll look and advise which
file its on my other systerm
<[Sean@TWP] P-DIRECT> If I had any time left to volunteer...
<[Bud] B.CONNOLLY1> vq_extnd returns type of screen display in
work_out(0)
<T.MACK1> Hey we should check Check CPU, BlitterCheck
CPU, Blitter etc...
<[Host] MIKE-ALLEN> Ok, seems like AES and GEMDOS is pretty well defined
already - no need for special assembly routines. How about in C or GFA -
I haven't used them on the ST so I don't know. Tom - CPU is a cookie.
Don't know about blitter. Good thought!
<[Sean@TWP] P-DIRECT> The BLiTTER is an XBIOS call. Really high number.
<[Host] MIKE-ALLEN> I assume that Global[0] and the GEMDOS version call
are available in C - howabout GFA?
<T.MACK1> Blitter is xbios 64
<[Host] MIKE-ALLEN> No GFA experts? Where is dmj when you need him <g>
<[Sean@TWP] P-DIRECT> XBIOS 64 is Blitmode() and detects and sets the
BLiTTER mode. I know a bit about GFA.
<[Zombie] R.ANISKO> "C" neophyte here :-)
<[Host] MIKE-ALLEN> So I guess the blitter is an XBIOS call, the CPU is a
Cookie. Still don't know where to find the VDI version. Any volunteers
for that one?
<T.MACK1> How do you detect FPU?
<[Zombie] R.ANISKO> FPU is a cookie I think
<[Host] MIKE-ALLEN> Tom - Cookie, again. Maybe I should post the Atari
defined cookies in 3/11 for those who don't have the compendium?
<[Zombie] R.ANISKO> good idea
<[Host] MIKE-ALLEN> Ok - will do.
<[Sean@TWP] P-DIRECT> There's a printer/plotter return code for
"Ornery Printer" ... sheesh.
<[Host] MIKE-ALLEN> Anyone going to volunteer for any portion of the
"what am I" routines?
<[Zombie] R.ANISKO> I'll volunteer to try some out (but I need to get
some decent documentation first)
<[Sean@TWP] P-DIRECT> I can't find anything to figure out VDI version...
<[Host] MIKE-ALLEN> Lemme see if I can sumarize what we want in the "what
am I" routine so far:
1) read the cookie jar (what do we do with them?)
2) GDOS presence and version
3) AES version (easy)
4) GEMDOS version (easy)
5) TOS version (easy)
6) VDI version
7) BLiTTER present.
8) MultiTasking in effect (easy)
what have I missed other than the individual cookie items?
<T.MACK1> Memory
<[Zombie] R.ANISKO> will there be multiple people doing these, or is it
assigned to one person? each
<[Host] MIKE-ALLEN> Rob - I would like to see everyone
interested to try their hand - the more the merrier - I know that I have
managed to improve some of my routine after exchanges with Tim and
Damien!
<[Host] MIKE-ALLEN> Good - memory size. Memory free would be a "what is
my state"
<[Zombie] R.ANISKO> memory vs memory free
<T.MACK1> RAM
<[Bud] B.CONNOLLY1> ST or TT
<[Sean@TWP] P-DIRECT> What about the fact that TT RAM is available?
<[Bud] B.CONNOLLY1> ST or TT ram and how much of each.
<[Host] MIKE-ALLEN> Yeah - both the size and presence of each RAM type.
<[Sean@TWP] P-DIRECT> Isn't that a Cookie (TT RAM present?)
<[Zombie] R.ANISKO> cool then - I'll attempt some of the AES/TOS version
stuff and see what everyone else comes up with
<[Host] MIKE-ALLEN> BTW, You can have "TT" ram in any TOS from 2.00 up.
<CBARRON> I would guess 3.05 and up, don't you need tos 3+ for an 030???
<[Host] MIKE-ALLEN> Ok, guys - Remember to send me EMail so that I can
give you access to lib 19 to exchange these pearls of programming wisdom!
<T.MACK1> Well that's the only time to look for it then
<[Host] MIKE-ALLEN> CBARRON - actually the support for non-ST ram was
added in 2.00.
<[Bud] B.CONNOLLY1> the _FRB cookie points a 64kb buffer that may be used
by DMA device drivers to transfer memory between 'alternative' RAM and ST
RAM.
<[Host] MIKE-ALLEN> Bud - I haven't figured out how to use that 64k
buffer. <g>
<[Keith] K.GERDES> Look at $5a4 and $5a8 for the alternative RAM.
<[Host] MIKE-ALLEN> Bud - I think "alternative" is a better choice of
word than "TT."
<[Sean@TWP] P-DIRECT> It takes much more effort to type alternative,
though. And as long as we all understand that TT RAM is "alternative"
RAM then there shouldn't be any problem.
<[Keith] K.GERDES> The _FRB cookie is a 64K buffer in ST RAM for DMA
device access. The memory is copied from ST RAM to TT (Alternative) RAM.
<[Host] MIKE-ALLEN> Keith - how does this copy take place? Is it
automatic or does the prorgram have to manage it?
<[Keith] K.GERDES> It's up to the program.
<[Host] MIKE-ALLEN> Aha! Thanks
<[Keith] K.GERDES> The only program that really needs the _FRB is the
hard drive handler.
<T.MACK1> Hey should we also check _drvbits for present drives?
<[Bud] B.CONNOLLY1> another good one.
<CBARRON> Keith - or any other DMA device handler...
<[Host] MIKE-ALLEN> What I suggest is that we press on with the "what am
I" routines and liven up the discussion in 3/11 in anticipation of the
"what is my state" routines.
<T.MACK1> ok
<[Parrot Head] C.CASSADAY> sounds good to me
<[Host] MIKE-ALLEN> Tom - very good point. What drives, are there hard
drive partitions, etc. Is it necessary to check the hd driver sw and
version?
<[Keith] K.GERDES> Correct. Now where's that LAN driver... ;)
<[Host] MIKE-ALLEN> Keith hehe. Go for it.
<[Bud] B.CONNOLLY1> HD driver...I don't think you would need to check it.
<[Keith] K.GERDES> The Atari hard disk handler has docs with details.
I'm not sure about the others.
<[Host] MIKE-ALLEN> I guess we could ask ICD. Keith - think it is
neccessary to check the hd handler version? Probably wouldn't hurt.
<[Keith] K.GERDES> I don't know which category the info fits into.
What am I or What is my state. :)
<[Host] MIKE-ALLEN> Ok, folks - general chatter time. I'll kill the
capture buffer. Keith - I'd say "What am I"
<[Host] MIKE-ALLEN> I'll try and make a summary (lots of luck) to place
in 3/11. I will post a couple of routines in lib 19. Let's get some
chatter going in 3/11. Remember, EMail me for access to lib 19. Think
about the "what is my state" requirements. Maybe we can actually discuss
code next time. Next time, BTW is 2 December. Homework assignment: How
do we determine the "What am I" items mentioned so far in the RTC. I
will post them is 3/11.
Programming Real Time Conference
December 2, 1993
Host - Mike Allen
<[Host] MIKE-ALLEN> Ok folks, the capture buffer is on. good behavior,
everyone. <g>
The response in cat3/top11 and in lib 19 has been underwhelming, There
have been 3 uploads to lib 19 and two of them were mine!
I think Keith may be right in that we need a "homework" assignment for
each meeting. So far the uploads have been cookie jar routine from me
(old and new versions) and blitter routines from T.MACK.
<CBARRON> Gee I forgot which mike to email.<grin> C access to cookie
jar than is ansified, from atari docs. A side note Lexicor's cards
install a cookie. Details [in german ] are coming to me.
<[Host] MIKE-ALLEN> What I would like to suggest for the next meeting (16
December) is everyone try to write a prg that will at least report the
TOS, AES and GEMDOS versions to the screen. More if you want.
<[Host] MIKE-ALLEN> Let me go around the horn and see what people think.
<[Host] MIKE-ALLEN> Bud - your thoughts? ga
<[Bud] B.CONNOLLY1> Sounds good to me.
<[Host] MIKE-ALLEN> Keith? ga
<[Keith] K.GERDES> Me too... You might have a Q&A time each RTC for
people to get answers in realtime. ga
<[Host] MIKE-ALLEN> Good idea, Keith.
<[Host] MIKE-ALLEN> E.MONACO - your thoughts? ga
<E.MONACO> I think giving assignments should improve participation... I
for one really look for the opportunity to pick my fellows programmers
brains :) ga
<[Host] MIKE-ALLEN> Thanks. BTW, since Scott is here, I'd like to
mention that he has given me permission to quote the Compendium on the
official Atari cookies. Thanks Scott. That will be up soon.
<[Scott @ SDS] S.SANDERS2> No problem, Mike...
<[Host] MIKE-ALLEN> CBARRON - your thoughts? ga
<CBARRON> So far I have that solved, but for tos version,in my head. but
something is better than nought. What is a $00aa0066 cookie? there is
one on my TT. ga
<[Host] MIKE-ALLEN> I noticed that the Atari Mouse accelerator puts up a
non ascii Cookie. Could that be it? ga
<CBARRON> Might be maccell is installed ga
<[Host] MIKE-ALLEN> Probably is then. Scott and Charles, we are
discussing a "homework" assignment for the next meeting. I proposed a
simple prg that would display AES, TOS and GEMDOS versions to the screen.
Charles, your thoughts? ga
<C.S.SMETON> Seems simple enough to do...
<[Scott @ SDS] S.SANDERS2> Yeah, I have a similiar program I wrote in
Ataridev...
<[Host] MIKE-ALLEN> I thought we should maybe start simple. Might be
some useful routines to come out of it (like hex to ascii conversions,
etc.) There wasn't a very big response asking folks just to post
routines.
<[Host] MIKE-ALLEN> J2 - I managed to miss you. Your thoughts? ga
<[John too] J.G.H.> Are there any other "Non-programmers" about? ;> You
don't want to scare any 'lurker' types away that might want to learn a
thing or two also ;> ga
<[Host] MIKE-ALLEN> J2 - don't be so bashful! <g> Well, what do you want
to discuss now, all? Pandimonium time!
<[Bud] B.CONNOLLY1> A possible topic for a future RTC,
Debuggers/Monitors, their care and feeding. I have Tempelmon, Sysmon and
the one in the Prospero Workbench, but I really don't know what to do
with them.
<[John too] J.G.H.> The only language I do have is GFA Basic and it has
sat on the shelve for probably a year or so
<E.MONACO> Bud Sysmon can be a very powerful developement tool. I've been
playing with it and find it very useful.
<[Host] MIKE-ALLEN> Bud - I have yet to figure out Templemon. I use
MonST and AMonst from HiSoft.
<[Keith] K.GERDES> I must agree about Sysmon. Anybody know the status of
it. Falcon version?
<[Bud] B.CONNOLLY1> Then, there is room for discussion on that topic?
<[Host] MIKE-ALLEN> Decent english docs for templemon would help.
<[Bud] B.CONNOLLY1> I could use some of your experience <G>
<CBARRON> When I use a debugger it is one of the monST variants.
<[Host] MIKE-ALLEN> Sure, if we can find some templemon/sysmon experts.
<[Keith] K.GERDES> I'm not an "expert" at Sysmon, but I'll help... :)
<E.MONACO> Keith, version 1.05 (I believe) uses a neat technique to find
the various system variables, etc it needs to work... I think its biggest
incompatibility would be with its custom screens/menus.
I'll help with sysmon too.
<[Host] MIKE-ALLEN> How about I shedule up one of our dates in January
for a sysmon/templemon rtc?
Sounds like keith and erin <is that right?> will be our resident experts.
<[Scott @ SDS] S.SANDERS2> I have familiarity with both of those... I
haven't been able to get the new version of Templemon to work with
MultiTOS though...
<[Host] MIKE-ALLEN> Aha, Scott also.
<E.MONACO> It might work on a falcon in hires (ST) mode. Yes, its Erin.
<[Keith] K.GERDES> How recent is 1.05?
<[Bud] B.CONNOLLY1> I knew I could root out some help here.
<[Host] MIKE-ALLEN> You three - which date would be the best? the 1st or
3rd thursday in January? ga
<silence?>
<E.MONACO> Hmmm, winter classes start 6th of january, I don't think I
have any for thursday nights so I'm open
<[Keith] K.GERDES> That's the 6th or 20th. Either one. ga
<[Host] MIKE-ALLEN> Scott? ga
<E.MONACO> Keith, latest version I've seen... pulled it off umich before
KA9Q broke.
<[Host] MIKE-ALLEN> KA9Q broke?
<[Scott @ SDS] S.SANDERS2> What, I have no life... i.e. no real
preference :)
<[Keith] K.GERDES> Ok. I looked around the German FTP sites, but only
found Templemon. I use MonST on all machines, so that's not my forte.
<[Host] MIKE-ALLEN> Let's set it up for the 20th then. Give everyone
time to get their questions lined up and our experts prepared<g>. Sound
ok all?
<[Bud] B.CONNOLLY1> Keith, where can I get monST? Is it commercial, PD or
shareware?
<E.MONACO> Basically I had to install the control.acc in three slots...
and then run Sysmon... (something like that) as it could not find the
vectors etc, it needed for tos 1.62
sounds ok
<[Bud] B.CONNOLLY1> 20th is a go.
<[Host] MIKE-ALLEN> Bud MonST is commercial from HiSoft.
<E.MONACO> isn't there a monST in the PD release of DevPak II?
<[Bud] B.CONNOLLY1> thanx Mike. Are the docs worth the price tag?
<[Keith] K.GERDES> The old "CONTROL.ACC" trick. I did that on the TT
once.
<[Host] MIKE-ALLEN> I didn't think DevPac 2 was PD.
<[Keith] K.GERDES> I'll try it on the Falcon. Thanks.
<E.MONACO> Sounded weird but it worked. :)
Hmm. wasn't it in ST Format or something.
<[Keith] K.GERDES> If we're gonna talk about a program, shouldn't we post
a file # reference for everyone to download?
<[Host] MIKE-ALLEN> Bud - monst is part of their devpac. Don't think it
is sold separately.
Keith, what should be in the file?
<[Bud] B.CONNOLLY1> Oh, I've been looking at Devpac 3 as a replacement
for Assempro.
<E.MONACO> JUNE 1993 Atari ST User disk... Exclusive DevPacST 2
<[Keith] K.GERDES> If we talk about Sysmon and Templemon, people need
them. Right?
<[Scott @ SDS] S.SANDERS2> I noticed in the transcript of the first
Programming RTC you mentioned a module to parse .INI files. I just
completed one for Icon Wizard and I'd be happy to upload the source if it
might be useful.
<E.MONACO> Bud I used Assempro DevPac definitely is better.
<CBARRON> Devpac II did appear on an ST Format Disk, I do not think it is
pd. MonsT is included with DevPac, a variant in Lattice C and some other
language products of HIsoft. opps wrong magazine. It was a cover dsk.
<[Host] MIKE-ALLEN> Aha - yes. Is Sysmon on GEnie? I know templemon is.
<[Keith] K.GERDES> Once you've tried DevPac, there's no turning back.
It's the best- bar none!
<E.MONACO> I have only seen sysmon on the net...
<[Bud] B.CONNOLLY1> Mike, if it isn't, I can LZH my copy and upload it.
<E.MONACO> Unfortunately I don't have the complete archive, so I couldn't
distribute the version I have.
<[Host] MIKE-ALLEN> I haven't installed Devpac3 yet that I bought at
Glendale. Still using ver 2. and now they've got an update to 3.10!
<[Host] MIKE-ALLEN> Bud - are there any docs with it? ga
<[Bud] B.CONNOLLY1> I should have the complete set, I can't say for sure
since I haven't looked at it in a while.
<E.MONACO> Sysmon is shareware with a pricetag of $40 for non-commercial
use. $80 for commercial use.
<[Host] MIKE-ALLEN> If you would upload it, it would be appreciated.
<[John too] J.G.H.> I have found DevPac 1 on a ST Format ;>
<[Host] MIKE-ALLEN> Is it from germany?
<E.MONACO> DevPac II is in the june 1993 ST USER disk.
<[Bud] B.CONNOLLY1> Yes, I do remember that I have a doc file with it,
I'll upload tomorrow.
<[Host] MIKE-ALLEN> thanks a bunch, Bud.
<E.MONACO> I don't remember... probably a good bet though
<[Bud] B.CONNOLLY1> Since I haven't uploaded before, should I put in our
Lib 19 or somewher else?
<[Keith] K.GERDES> Yes, Sysmon is from Germany.
<E.MONACO> I think it should go in lib 2, make a good utility for anyone.
<[Host] MIKE-ALLEN> Bud - just put it in lib 1 and the librarians will
get it to the right place. Right J2?
<[John too] J.G.H.> yes, unless it's for library 19
<[Bud] B.CONNOLLY1> ok, I'll LZH it and put it up tomorrow.
<[Host] MIKE-ALLEN> I don't think this is for lib 19. That is kind of a
private exchange for us.
<[Host] MIKE-ALLEN> I think sysmon would have wider interest. lib 19 is
to keep from exposing ourselves too badly. <g>
<[John too] J.G.H.> I was referring to any uploads ;>
I don't know if the other Librarians would recognize a 19 program
<CBARRON> All you interneter's is there an executable package of
Berkeley(sp?)YACC version 1.9 ported to the atari line. I got the *ix
source, but would appreciate not compiling it. ga
<[Host] MIKE-ALLEN> not Yet Another YACC! <g>
<CBARRON> Wait for aeopj 3+ <grin>
<[Bud] B.CONNOLLY1> When is that due out?
<[Host] MIKE-ALLEN> arrrggggh! Just no more FLEX code <g>
<[John too] J.G.H.> You can put uncompiled programs in Library 19 ;>
<[Host] MIKE-ALLEN> Lib 19 is for us to exchange things privately. If
you haven't got access to it yet, send me EMail and I'll add you to the
list.
<[John too] J.G.H.> Mike while I am thinking of it...You might want to
work up a Text file explaining the purpose of lib 19 and point it out to
people you let in there.
<[Host] MIKE-ALLEN> Ok, John, I will. Put it in 19?
<[John too] J.G.H.> (along with a disclaimer)
<[Host] MIKE-ALLEN> ye gads, a lawyer?
<[John too] J.G.H.> Yes ;>
<CBARRON> Flex is just the beginning. Yacc specs are ussually
recursive... ga
<E.MONACO> I hate rec[rec[recursive]ursive]ursive] code :)
<[Bud] B.CONNOLLY1> Oh, but it can be so interesting!
<[Host] MIKE-ALLEN> Ok - seems I have a couple of action items. 1) get
the cookie stuff from Scott posted (BB or lib 19?), 2) post a message in
the BB noting our sysmon/templemon rtc on the 20th with file references
to both . . .and something in the BB about our "homework" assignment.
BTW anyone who finds info about non-Atari cookies might want to post in
lib 19 also. What else do I need to take care of? <ga all>
<CBARRON> E.MONACO - that ok, but yacc essentially specifies a 'language' to
parse..
<E.MONACO> The surgeon general has determined re_curs_ive code as well as
prolonged exposure to air to be fatal!
<[Bud] B.CONNOLLY1> Find some decent English docs for Tempelmon! <gdr>
<[Host] MIKE-ALLEN> <sorry, bud Meine Deutch ist sehr schlect!>
<E.MONACO> Try running them through Ger2Eng...
<CBARRON> I know that LEXICOR graphics cards install some cookie. I
believe GRIBNIF's '' crazy' cards do also which one I do not know at
this time. ga
<[Bud] B.CONNOLLY1> I'd try running them through GER2EN30, but it leaves
a little bit to be desired in the translation.
<[John too] J.G.H.> Hehe Bud ;>
<E.MONACO> very true.
<[Bud] B.CONNOLLY1> Erin, GER2EN30 is just a straight word for word
translation. Makes some strange looking sentances.
<E.MONACO> Ah, haven't seen any of MY docs have ya! :)
<[Host] MIKE-ALLEN> Ground rules for the homework - Should run on any
ST/STe/TT/Falcon in any Rez. Source included with the executable in a ZIP or
LZH to lib 19. Would be nice to see Assembly, C and GFA Basic version.
<[John too] J.G.H.> I remember the original GER2ENG <hehe>
<[Host] MIKE-ALLEN> Back to the homework - either a .TOS or .PRG. .PRGs
should be GEM!
<E.MONACO> Sounds good.
<[Host] MIKE-ALLEN> Where do you all want the cookie file: The BB or lib 19?
<CBARRON> what no gtp's <grin>
<E.MONACO> lib 19
<[Bud] B.CONNOLLY1> Lib 19 Mike.
<[Host] MIKE-ALLEN> Lib 19 sounds good to me too.
>>>At this point Andreas (AEO.2) drops in to discuss his recent visit
to Atari Headquarters. Much off-topic, but interesting discussion!
[g]<<<
<[Host] MIKE-ALLEN> Looks like this is degenerating. Any more
programming stuff before I turn off the capture buffer? ga
<[Bud] B.CONNOLLY1> kill it Mike.
<[John too] J.G.H.> anyone here planning on programming for the Jag?
<hehe>
<[Andreas@AEO] AEO.2> (I'll stop)
<[John too] J.G.H.> <---always on topic <wink>
<[Host] MIKE-ALLEN> We were about done, Andreas. Ok, capture off. ga
folks jabber at will.
/************************************************************************/
NETWORK SIGN-UP INFORMATION
/************************************************************************/
---------------------------------------------------------------------------
-- --==--==-- GEnie Sign-Up Information --==--==-- --
-- --
-- 1. Set your communications software for half duplex (local echo) --
-- at 300, 1200, or 2400 baud. --
-- --
-- 2. Dial toll free: 1-800-638-8369 (or in Canada, 1-800-387-8330). --
-- Upon connection, enter HHH. --
-- --
-- 3. At the U# prompt, enter XTX99436,GENIE then press <Return>. --
-- --
-- 4. Have a major credit card ready. In the U.S., you may also use --
-- your checking account number. --
-- --
-- For more information in the United States or Canada, call 1-800- --
-- 638-9636 or write: GEnie, c/o GE Information Services, P.O. Box --
-- 6403, Rockville, MD 20850-1785. --
-- --
-- --==--==-- Atari's Official Online Resource! --==--==-- --
---------------------------------------------------------------------------
---------------------------------------------------------------------------
-- --==--==-- CompuServe Sign-Up Information --==--==-- --
-- --
-- --
-- --
-- To sign up for CompuServe service, call (voice call) (800) 848-8199. --
-- Ask for operator #198. You will be sent a $15.00 value CIS membership --
-- kit for free. --
-- --
-- --
-- --
-- --==--==-- CompuServe Sign-Up Information --==--==-- --
---------------------------------------------------------------------------
---------------------------------------------------------------------------
-- --==--==-- Delphi Sign-Up Information --==--==-- --
-- --
-- To enroll as a Delphi subscriber, modem call 1-800-365-4636. Press --
-- [Return] once or twice, and type IP26 [Return] at Password: --
-- --
-- Answer all of the questions, and you'll be cleared for Delphi --
-- access in a few days. If you have questions about Delphi services, --
-- give a voice call to Delphi Member Services at 1-800-544-4005. --
-- --
-- --==--==-- Delphi Sign-Up Information --==--==-- --
---------------------------------------------------------------------------
/***********************************************************************/
USER VIEW
By: Mike Allen
/***********************************************************************/
=-=-=-=-=-=-=-=-=-=-=-=-=-=
//// What USERS would like!
=-=-=-=-=-=-=-=-=-=-=-=-=-=
Now I consider myself a somewhat typical user. My thesis is that most
Atari ST users (and face it, there are a lot more ST users than TT and
Falcon030 users combined), have certain things in common.
What are some of those things? Well, I believe that the majority of
the users are using ST Medium Rez! This tends to be a much neglected
resolution by developers. Also I think the average user would much
rather "point-and-click" than use the keyboard.
Developers are "power" users. Power users like ST Hi rez. They also
like "hot keys" over the mouse. I suspect that a lot of developers
would like to forget that a mouse is connected to the ST!
This brings me to the first few of my user wants:
1) Check what resolution the system is operating in. Don't just
assume that the user has read the manual and/or the read.me file that
states "This program must be run in xxxxxx resolution." The least you
can do is give a polite little alert box that says "This program only
runs in xxxxx resolution." The let the user exit cleanly. Better is
if your application sets the resolution for the user. Best is if the
application is resolution independent.
2) Make ALL operations available from the menu bar and/or icons.
Don't make the user HAVE to use the keyboard except for actual text
entries. I'm not saying eliminate the "hot keys," but make the mouse
your primary input tool. Nothing should be available from a "hot key"
that isn't available somehow using the mouse. The "hot key" might
actually be easier, but lots of people (like me) would rather click a
few times than press a key.
3) Use the file selector! There is no excuse to have a user type in
a path or a file name except to create a new file. Check to see if
the machine supports fsel_exinput(). If it does, use the prompt line
in the file selector. If it doesn't, assume that Charles F. Johnson's
Little Green Selector is available and pass the prompt in that format.
It won't hurt the regular file selector if LGS isn't available and
looks nice if it is.
4) Don't blithely go over-writing files. If a file exists and your
program is going to write to it, warn the user. Give the user the
option to change the file name, backup the old file or abort the
operation.
5) I personally hate install programs! Especially those which
modify existing files like my DESKTOP/NEWDESK.INF file. Mods to the
ASSIGN.SYS and EXTEND.SYS files scare me too. Install programs all
too often write files without checking if files of the same name
exist. (Bravo to Atari. Their SpeedoGDOS install program has the
courtesy to rename existing ASSIGN.SYS and EXTEND.SYS files as
ASSIGN.OLD and EXTEND.OLD.)
6) Don't get "cute" in your program. There is no need to re-invent
the file selector or change the look of the standard GEM window. If
folks want fancier selectors or windows they will probably be using an
alternative file selector or desktop. They might even be using a
Falcon, MultiTOS or Geneva.
7) Don't "cheat" TOS. I know that it is very tempting to "do things
better than Atari," but you'll probably end up with a product that
will break on some present or future version of TOS. Check the AES,
GEMDOS and TOS versions. Look at the Cookie Jar. Make your program
live within the parameters of the system upon which it is operating.
If you don't care to support earlier versions of TOS, plainly state
that in your advertisements and packaging.
Here are some more problems that I find highly irritating. Irritating
to the point that, unless the program is really special, I'll dump it
immediately.
8) Let the user be able to exit your program! I really hate
programs that only let you quit by pressing the reset button. Flat
out, there is no excuse for that.
9) Leave the system the way you found it. If you change ANY user
configurable item, restore it when the program exits. This includes
stuff like resolution, palette, key-click, system bell, repeat rate,
etc. Be courteous to your customer.
Finally we come to protection schemes. (Are you listening Psygnosis
and Silmarils?)
10) If you absolutely MUST use a key disk scheme, don't make the
floppy drive do things it wasn't designed to do. Keep in mind that
machines like the MegaSTe and the TT are MUCH more sensitive to
strange disk actions than the old STs. (I have to boot Lemmings 5 to
10 times before it will finally run. Ishar II fails its test about
1/2 the time. I'm still using a 720k drive and I've changed it and
re-routed cables trying to get more reliability on these two games.)
People also get upset when the heads get banged against the stop so
often and so hard that the drive goes out of alignment.
11) An extension of the above. Do your key disk check ONCE and at
the beginning. Don't go through a bunch of fancy opening screens
before doing your key disk check. Don't check it every time the user
loads a saved position.
12) Better yet, don't use key disk protection. "Find the Nth word on
page so-and-so" works fine if you have a large manual. Code wheels
(Their Finest Hour) or non-Xeroxable key cards (SimCity) work fine.
I'm getting to my final salvo. You won't have to read much further.
13) Make sure your program will take advantage of a second floppy
drive or a hard drive, if available. I know that I haven't bought
(and won't buy) B-17 because it won't run on a hard drive. Also don't
assume everyone uses GEM partitions on a hard drive. Some of us use
BGM and even XGM partitions.
14) DOCUMENTATION! Have someone other than the programmers write the
documentation. Preferably a "typical" user. A good index is
essential to a complex program. Organization and ease of reading is
required. Examples and tutorials are hard to beat. Screen shots are
nice.
15) Error checking. Don't allow your program to bomb just because a
user forgot to select a file name in the file selector. Look at the
return codes of the various system calls to see if the return was
successful. Handle error conditions in an intelligent manner. Don't
just bomb.
16) File handling. Don't keep files open any longer than necessary.
A power failure could do nasty things to your customer's system if it
happens while a file is open. Be smart about what you can do in
memory and then transfer to a file in one quick burst of activity.
17) Quality. Test the pants off your new application. Use beta
testers who are NOT developers. Use intelligent, observant testers.
Supply a "bug" report form that is a "fill in the blank" type - auto
programs, accessories, TOS version, hard drive software, etc. The
more organized your form is, the more complete the data you will
receive are.
18) Customer Service. Don't ignore your customer once you have his
money. Developers like Gribnif and CodeHead benefit from their
excellent customer service. They are available by snail mail, on-line
services, BBSs and even telephone and fax. They are always
responsive, even to abusive customers. Customer service is their
stock in trade. Atari could take some lessons in customer service.
They have suffered badly from a lack thereof!
I guess I have "curmudgeoned" enough for now. Am I off base? What
other "pet peeves" have I missed? I'm sure AEO-PJ would like to hear
from you.
/************************************************************************/
Brain Stem Rotator
By: Albert Dayes
/************************************************************************/
Write a program that will take an integer number as input and generate
Roman Numerals for the output. Attempt to use 20 lines or less of code.
Maximum input value is 32767, while the minimum is 1.
Examples:
input: 5
output: V
input: 9
output: IX
/*************************************************************************/
Glossary of Terms
/*************************************************************************/
ADA = A Programming Language created by the US DOD for use in embedded
systems. The name is in honor of Ada Lovelace who, some claim to
be the world's first programmer.
AES = Application Environment System
AI = Artificial Intelligence
CLASS = An abstract data type which includes information on variables.
In addition one may define precisely what functions have access
to those variables. It can be thought of in C++, as a struct that
allows functions to be part of the struct itself.
DOD = Department of Defense (USA)
DSP = Digital Signal Processor
FORTRAN = Acronym for formula translation. This programming language is
very popular for scientific computation
GEM = Graphics Environment Manager
GRAMMER = One of the principal ways of specifying an infinite formal
language by finite means
LALR = Look ahead left right (a class of grammer) common when
discussing bottom-up parsing
LEX = Lexical Analyzer
PROLOG = A logic programming language which is quite popular in AI
community
VDI = Virtual Device Interface
YACC = Yet Another Compiler Compiler
/*************************************************************************/
ATARI DEVELOPER INFORMATION
/*************************************************************************/
What you can buy from Atari in terms of developer documentation and
support. Contact Atari for the specific details.
Atari Corp
1196 Borregas Ave
Sunnyvale, CA 94089
USA
(408)-745-2000 (voice)
Some of the benefits:
+ Several disks and approximately two thousand pages of programming
documentation.
+ Atari Developer newsletter: ATARI.RSC
+ Atari Developer RoundTable support on GEnie (private)
+ Atari Developer CD-ROM (coming soon)
+ book: Atari Compendium, by SDS Publishing
Call or write for details.
/************************************************************************/
Sources of Information (References)
Books, Magazines and Company Information
/************************************************************************/
book: The C Programming Language (2nd edition, ANSI C)
by Brian Kernighan and Dennis Ritche
ISBN 0-13-110362-8
Prentice Hall
Englewood Cliffs, New Jersey 07632
USA
NCSA (National Computer Security Association)
10 S. Courthouse Ave
Carlisle, PA 17013
USA
(717) 258-1816
(717) 243-8642 (fax)
Computing Professional Organizations:
ACM (The Association for Computing Machinery)
11 West 42nd Street
New York, NY 10016
USA
(800)-342-6626
(212) 869-7440
(212)-626-0500
E-mail: ACMHELP@ACM.org
ACM European Service Center
Avenue Marcel Thiry 204
1200 Brussels, Belgium
Phone: 32-2-744-9602
Fax: 32-2-774-9690
E-mail: ACM_Europe@ACM.org
IEEECS (The Computer Society of the Institute for Electrical and
Electronics Engineers)
Membership Department
445 Hoes Lane, PO Box 1331
Piscataway, NY 08855-9970
USA
(202) 371-0101
/***********************************************************************/
POST INCREMENT
(what is coming up in the next installment)
/***********************************************************************/
We are always looking for new articles, tricks, questions, tips and
suggestions related to programming on the Atari. Also Brain Stem
Rotator style problems are also needed.
* More on Advanced Computing using YACC
* Object Oriented Programming
* C++
* GEM++ Class library
* Developer Perspective
The type of articles we are looking for are anything programming
related. STOS, dBMAN, C, Assembly, BASIC, Pascal, Lex, YACC, etc,
etc. This is of course a very small list.
Letters and comments are always welcome! And if you have a better
technique for solving a problem we want to hear from you. If one has
a suggestion on a particular topic that he/she would like covered
please send EMail to the editor.
Developers [Worldwide] send press releases about your products as
well. We want everyone to know about the newest developer tools
available.
/************************************************************************/
LEGAL NOTES
/************************************************************************/
Articles and letters in Atari Explorer Online Programmers' Journal
(AEO-PJ) represent the views of the authors and do not necessarily
reflect those of the publisher.
Note all code and listings in Atari Explorer Online Programmers'
Journal (AEO-PJ) appear "as is," and AEO-PJ makes no guarantee or
warranty of their quality, performance, accuracy, or suitability for
any particular purpose. AEO-PJ assumes no responsibility or liability
to any person or entity with respect to any damage caused or alleged
to be caused by their use.
Material published in this issue may be reprinted under the following
terms only: articles must remain unedited and include the issue number
and author at the top of each article reprinted. Reprint permission
is granted, unless otherwise noted at the beginning of the article, to
registered Atari user groups and not for profit publications.
/************************************************************************/
-----------------------------------------
Return to message index
