Crawly Crypt Collection 1/crawlyvol1.bin/magazine/aeo/aeopj_04/aepj4.txt

Text File | 1994-03-31 | 297KB | 7,094 lines

/**********************************************************************
    Title:          AEOPJ4.TXT

    Created:        December 25, 1993
    Last Modified:  March  31, 1994

    Purpose:        Fourth installment of AEO Programmers' Journal

    Editor:         Albert Dayes

    Legal Notes:    Copyright © 1993 Subspace Publishers
                    All Rights Reserved

***********************************************************************/

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: [e-mail]]
68K columnist = Damien M. Jones                                [GE: DMJ]
PASCAL columnist = Kris Gasteiger                      [CIS: 73637,2004]
Parsing the human equation = Ron Whittam  [In: [e-mail]]

:: Internet subscription service: [e-mail]    ::
::                 (Internet subscription requests ONLY!)             ::

Contributing:

John Perry Barlow       [In: [e-mail]]

Roger Burrows           [GE: R.BURROWS1]

Gerry J. Elman, J.D.    [CIS: 72245,556]

Scott R. Garrigus       [GE: S.GARRIGUS]

Kurt Stammberger        [In: [e-mail]]

Frederic M. Wilf, J.D.  [CIS: 72300,2061]

[ 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 YACCs with alert boxes
* GFA Basic Column -- Scott R. Garrigus talks about Resources and RCS
* Hard Core - Interview with Roger Burrows author of ExtenDOS
* Dabbling in PASCAL - Kris Gasteiger discusses keyboard functions
* Library - Damien examines a new Atari specific CD-ROM disc called Gemini.
* Periodicals - A preprint from Wired magazine on the Clipper Chip + RSA info
* OBJECT::ATARI - Warwick Allison on moving from C to shining C++
* Parsing the human equation - by Ron Whittam
* Language Watch - Current versions of developer tools
* Bad Example - Do you really want to do that?
* Legal Forum - A discussion of Intellectual Property issues
* Best Software Development tools for 1993
* On the Networks - Interactive programming online
* Network Sign-up Information
* Shareware survey - for shareware authors only
* Brain Stem rotator - A true programming challenge?
* Software Development Conference, March 14-18 in San Jose, California
* 10 Tips From the Programming Pros
* 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:  "Shareware - Does it really work?"
                     By: Albert Dayes
-------------------------------------------------------------------------

Category 3,  Topic 11
Message 194       Sun Jan 23, 1994
MIKE-ALLEN [NM~SysOp]        at 19:52 EST

I just received interesting EMail from Karsten Isakovic, the author of
SysMon.  Thought folks might be interested.  His GEnie Email address is:

 [e-mail]@INTERNET#


 >Hello Mike,
 >
 >i read in AEO-PJ3 of December 19 that there was a discussion about my
 >debugger SysMon in a Genie roundtable. I have some comments to that.
 >I know its a bit late, but better late than never ;-)
 >
 >
 >The version 1.05 which was in discussion in the RTC is more than 4
 >years old.  It does not run on TOS 2.06 or TT. The current version
 >1.08 runs on the TT and TOS 2.06, but not on the falcon.
 >
 >But the 1.09 is now in the beta test stage, and runs on the falcon.
 >SysMon works even with graphic expansions like BlowUp or
 >Screenblaster.
 >
 >It supports all new MTOS (AES 4.2)  and MagiX (Beta 2.10) AES Call,
 >Speedo (Beta 4.2) the MiNT (1.08)/MagiX gemdos calls, all new falcon
 >XBios calls (like DSP, SND and Video-Calls) and the Metados Xbios
 >extensions..
 >
 >Some new AES protocolls and extensions are supported, like the new
 >GEMINI- Messages (1.99), XACC, WinX (2.2), Kobold (2.5), Selectric
 >(1.10)...
 >
 >The XBRA- and cookie list was also updated (up to XBRALIST of Dec 93).
 >
 >There is new code to find the internal system variables. Even if none
 >of them is found, SysMon will run. But you get more information, if
 >everything is known ;-)
 >
 >Since 1.0.8 there is an interface to the templemon debugger, you can
 >now directly jump into TMON if a System function is used by the
 >selected programs.  (BTW the current TMOS version is 2.2)
 >
 >The upcoming 1.09 does not yet work under MiNT/MTOS (but the all
 >calls are already supported, since the MagiX-Beta offers some of
 >them...), but a future version will do so..
 >
 >
 >There is no newer version of SysMon in any FTP site or BBS since i
 >did not allow this kind of distribution since the version 1.06
 >(everybody used SysMon, nearly nobody paid the ShareWare fee...). I
 >have only 3 US and 2 CA people in the database and as you see in the
 >RTC, it is fairly common...
 >
 >Since then, you can still copy SysMon to a friend, but for a current
 >version, you have to send a disc with a back envelope and two
 >international relay coupons (Which i can exchange into stamps at the
 >postal office). You dont have to register in advance, you can test
 >SysMon as long as you wish. But if you use it regularly and like it,
 >pay the fee.
 >
 >This simple modification to the distribution mode (and the
 >announcement about it in the press) raised the percentage of people
 >who paid the fee. I think it is because they had to get into 'real'
 >contact with me. The SysMon is no longer an anonymous product, you
 >know from whom you got it...
 >
 >My adress is:
 >
 >  Karsten Isakovic
 >  Wilmersdorferstrasse 82
 >  10629 Berlin
 >  Germany
 >
 >You can also reach me via Email at [e-mail] and i could send
 >SysMon as uuencoded Message (_very_ long, about 400 K with english
 >documentation). I can also split it to several messages. But i still
 >need your full name and adress.
 >
 >The MagiX/Falcon version 1.08 will be ready at the end of february. I
 >dont know if there will be a new distribution mode, i still have to
 >think about it...
 >
 >
 >Greetings, Karsten
 >
 >PS: If there is also an american list of cookies, Xbra magics or
 >Message protocolls, send it via email. We have nearly no information
 >about GENEVA around here, so there is no support yet.
 >
 >

I have pointed him towards Dan Wilga for Geneva info and given him the
Gnva cookie info as well as the CJar cookie info. Any other cookies
that he might not have would be appreciated, I'm sure.

Only 5 North American registrations (3 USA, 2 Canada) - for shame!


        Mike Allen
        ST HelpDesk~Sysop

        Written: 5:42 PM Mountain Time
                 Sunday, January 23, 1994


Is there anything else that I can add to this message?  Probably not,
it is very clear.  AEO-PJ is moving toward better support for
shareware software developers and in our next issue we will have a
debut column called Soft Core.  Since Hard Core is an interview with a
commercial Atari developer Soft Core will be with a shareware Atari
developer.  Also do not miss the shareware survey, later in this
issue.

-- Albert

PS:  Anyone who would like to send feedback to AEO-PJ 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:  [e-mail]

/**********************************************************************/
                      Meet the Authors
/**********************************************************************/

//// John Perry Barlow

John Perry Barlow ([e-mail]) is co-founder and Vice-Chairman of
the Electronic Frontier Foundation, a group which defends liberty,
both in Cyberspace and the Physical World. He has three daughters.

//// Roger Burrows

Roger Burrows has written code in four high-level languages and five
assembler languages and usually manages to remember which is which.
He lives in Ottawa, Canada with his wife, cat, and computers.  He can
be reached on GEnie as R.BURROWS1.

//// GERRY J. ELMAN

Mr. Elman holds an M.S. in Chemistry from Stanford University, in
addition to his J.D. from Columbia University.  With 26 years of
varied experience as a practicing attorney, he is an authority and
widely published author on technology and the law.  His areas of
expertise include biotechnology, computers and intellectual property.

For four years, Mr. Elman practiced as an in-house patent attorney for
Rohm and Haas, a large multinational chemical company.  Then, as a
Deputy Attorney General of Pennsylvania, Mr. Elman conducted
litigation on behalf of the Commonwealth.  Later, as a trial attorney
with the U.S. Department of Justice, Antitrust Division, he
participated in civil and criminal investigations and complex
litigation, including a trial of five pharmaceutical companies accused
of fraud on the U.S.  Patent Office.  Mr. Elman returned to private
practice in 1982.

Today, Mr. Elman is the founder and editor-in-chief of the lawyers'
newsletter Biotechnology Law Report.  He has also served on the
advisory board on biotechnology monographs for the Bureau of National
Affairs (BNA) and the advisory board of the law journal Computer Law
Reporter.  He frequently lectures on biotechnology and the law.  He
has arbitrated multi-million dollar disputes for the American
Arbitration Association, has served as an expert witness in patent
law, and has represented both plaintiffs and defendants in litigation
over intellectual property rights.  A profile of Mr. Elman appears in
Who's Who in America.

//// FREDERIC M. WILF

Mr. Wilf has been practicing law with Mr. Elman since 1986.  He
advises clients on copyright, trademark and business law, with an
emphasis on computer and high technology issues.  He litigates
copyright and trademark infringement actions and negotiates software
development and license agreements.  Mr. Wilf also represents
out-of-state corporations as local counsel, and prepares and
prosecutes copyright and trademarks applications and related
proceedings.

A graduate of Rutgers University and Case Western Reserve University
Law School, Mr. Wilf writes and speaks extensively on topics involving
computers and the law.  His articles have appeared in the Computer/Law
Journal, the Computer Law Reporter and PC Magazine.  He and Mr. Elman
wrote the chapter "Trademark Protection of Software" for L.J. Kutten's
law treatise.  Computer Software:  Protection/Liability/Law/Forms.
Mr.  Wilf contributed a chapter to a book entitled Winning with
Computers.  Trial Practice in the Twenty-First Century, published by
the American Bar Association (ABA) in 1991.  Mr. Wilf has also served
as the organizer of the corporate law conference (CORPLAW) on the
ABA's computer network, ABA/net.  A profile of Mr. Wilf appears in
Who's Who in the East.

//// Scott R. Garrigus

Scott's first computer was the venerable Atari 800.  He once spent a
whole summer vacation indoors because he loved using his computer so
much.

Nowadays Scott is a college graduate musician and has just recently
released his first record album, Pieces Of Imagination.  He uses his
Atari ST for all aspects of album production, including writing his
own MIDI utilities.

He also runs his own shareware business, SRG Music & Software and has
released his first shareware program called EmailMan, the email
address database.  A demo of EmailMan can be found on the new GEMini
CD ROM.

Scott will be taking over our GFA BASIC column and he can be reached
at any of the following email addresses:

 Delphi: GARRIGUS
 GEnie: S.GARRIGUS
 Internet: [e-mail]
 PAN: GARRIGUS

//// Kurt Stammberger

Kurt Stammberger is a Technology Marketing Manager for RSA Data
Security, Inc.


/**********************************************************************/
      What is in this issue of AEO-PJ and new in the Atari market
                       By: Albert Dayes
/**********************************************************************/

//// Atari Corp:

The Atari Jaguar (64-Bit Interactive Multimedia Entertainment System)
continues to make good progress.  In addition, the Jaguar won several
awards at the Winter CES (Consumer Electronics Show).

Discussions continue, on the subject of Atari clones, Falcon and TT
accelerators and even new Atari computer magazines.  In addition, a
new shipment of Atari TT computers to US dealers.

//// CD-ROM Technology:

In this issue we cover a few programming conferences, and a special
one on CD-ROM.  The CD-ROM conference discusses how to use a CD-ROM
drive on the Atari.  In addition an interview with Roger Burrows,
author of a new CD-ROM driver (ExtenDOS) is also in the issue.

//// Legal Issues:

Recently the PTO (Patent & Trademark Office) decided to re-examine the
Compton patent and is taking input from software developers on the
issue of software patents.

In talking with a friend of mine (who has a software patent), I
made some interesting findings.  Even though his software patent is in
his name, the company owns it (which is expected).  Xerox, (the
company he works for) has patent cross-licesing agreements with Kodak,
IBM, etc.  That means that Xerox can use any of the patents that
Kodak, IBM, etc hold.  And conversely, IBM can use all of the patents
Xerox has, without paying any licensing fees.  For those companies or
individuals without a large patent portfolio, paying licensing fees is
the only option.

Since Intellectual Property is an important subject we have a nice
article on the subject.  Fred Wilf and Gerry Elman (of the law firm,
Elman Wilf & Fried) discuss the different aspects of Intellectual
Property, in the article, "How to work with your intellectual property
Attorney".  Many interesting aspects of the law that developers should
know about are included.

Also, we have a pre-print from Wired magazine on the Clipper chip and
what it means to US citizens.

//// Pure Profiler - a new programming tool:

A new Profiler from Gribnif Software, called Pure Profiler.  Based on
the article in Desktop Notes -- Gribnif Software, article by Dan
Wilga.

The newest programming tool we have to offer is the Pure Profiler,
also from Application Systems in Germany.  This invaluable program
generates statistics about the operation of other programs and helps
you make decisions about how to get the best efficency from your code.

The Profiler runs much like the Pure Debugger in the Pure C package
does.  It provides an unlimited number of windows which show you
source code modules, 680x0 assembly, and profiler output.  The
profiler is familiar with Pure C and Pure Pascal symbols, and also the
DRI format.  This means that it can be used with programs which were
generated by almost any compiler.

Statistics are broken up into major categories: Code Usage and
Profiling.  Code Usage provides you with a visual representation of
the lines in your program which were actually used as the program ran;
they appear in boldface type.  This allows you to know if there are
segments of "dead" code which are never used.

Profiling gives extensive information about how much time each module
of your program takes to run and how many times the modules are
called.  This same information is generated for every single line in
the program, as well.  By using this information, you can decide where
the program spends most of its time during execution, and possibly
optimize that area of code.

The main level of the Profiling information is broken into two
segments:  Operating System and Program calls.  The Operating System
segment lists all of the major types of OS functions (GEMDOS, BIOS,
AES, etc).  Clicking on a function type then gives you a list of the
calls of that type, and provides you with a percentage of time used
during each, and the totla number of calls.

In the Program calls list, you are given a list of all function in the
program, along with the time data.  Further clicking on a function
reveals the source code for that function, along with the time data
for each line.

The Pure Profiler also keeps track of all file operations.  For each
file which is used by your program, it maintains a list of how many
times it was read, written, opened, etc., as well as the number of
bytes that were operated upon and the underlying GEMDOS call used.

Furthermore, useful memeory statistics can be displayed.  You can
find out how much heap (Malloc) memory the program is using currently,
and the highest amount it has used at once.  The same data is also
displayed for the program stack.

Breakpoints can also be set, and the program's instructions can be
single-stepped.  Profile data can be saved to disk, optionally
including the source/assembly code of each line of the program, to
make evaluating the code easier.

At this time, the Pure Profiler includes a German manual; but the
program itself is completely in English, and has a very intuitive user
interface.  The Pure Profiler is extremely helpful tool that no
serious programmer should be without.

//// DevPAK DSP

HiSoft/ORA is releasing Devpak DSP, which will make Motorola 56K
Digital Signal Processor programming much more enjoyable.  The price
should be close to $100.

//// Books

There was going to be a review of Writing Solid Code by Microsoft
Press in this issue, but the Clipper article took its place.  For
those who want to read a recent review can read it in the December
1993 issue of the C Users Journal.

Software Development: A Legal Guide recently arrived.  It includes a
720K floppy disk (works on the Atari) of all of the contracts listed
in the book.  From a quick scan it covers many details that many
people would just skip over in making agreements.  It also has icons
to indicate when you should get a real Attorney to help you.  Some
highlights include:

* when to use copyright, trademark, trade secret or patent protection
* what the strengths and limitations of each type of protection are
* how to avoid infringement
* what you need to know about software patents
* what key provisions to include when drafting an agreement
* step-by-step instructions on drafting
  - employment agreements
  - agreements with independent contractors and consultants
  - software publishing agreements
  - agreements for the development of custom software
* when and how to obtain permission to use materials in multimedia
  projects
* what you new to know about the new multimedia patent (Compton's)
* when to contact an attorney

There will be a review of this book, in the next issue of AEO-PJ.


/*                   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 3: Round and round she goes... --

Yes, I'm back.  Last month I covered addressing modes and a few
(three) instructions.  This month I'll cover a few more instructions,
including a little looping.  This article will be a bit larger than
the previous ones, as there's a lot to cover!

FLAGS

Whenever you do something with a 680x0 program, the CPU "takes notes".
That is, it looks at the results of what you did and saves some
information about those results in the "condition code register"
(ccr).  You can play with this register directly, but there are also
some special instructions that will look at its contents so you don't
have to mess with it too much.

There are five flags in the ccr that are important.  Each has a
letter and is set or cleared based on different properties.  Here they
are:

    N   This is the "negative" bit.  If the result of the operation is
        less than zero, this bit will be set (1); otherwise (if the
        result is zero or greater) this bit will be cleared (0).

    Z   This is the "zero" bit.  It is set whenever the result of an
        operation is zero, or cleared whenever the result is NOT zero.

    V   This is the "overflow" bit.  If the result of an operation is
        too big for the size of the operands, an arithmetic overflow
        occurred, and this bit will be set.  Otherwise it is cleared.

    C   This is the "carry" bit.  If the result of an addition created
        a carry out of the highest bit, or if a borrow was needed on
        the highest bit, this bit is set.  Otherwise it is cleared.

    X   This is the "extend" bit.  Only certain operations use it,
        and it mostly is used for large (bigger than 32-bit)
        operations.  When it is used, it will be a copy of the C bit.

MORE INSTRUCTIONS

Last month's example program used just three instructions, add, move,
and trap.  There are quite a few more, but this month I'll cover a few
variations of those three instructions, plus a few new ones.

Keep in mind that most assemblers will choose a more specialized
variation of an instruction, if it can, so you can often just write
the basic instruction and your assembler will fill in the proper form.
The reason I am explaining some of the variations is because they
usually have slightly different effects that you need to be aware of
when writing programs.

move.s source,destination

I described this last time, but I did not say what happens to the
flags in the ccr after the move (because I hadn't explained the flags
yet).  So here is what happens to the flags, when you move something:

    N    Set if the value moved is negative.  Cleared otherwise.
    Z    Set if the value moved is zero.  Cleared otherwise.
    V    Always cleared.
    C    Always cleared.
    X    Not affected.  (It won't change.)

movea.s source,destination

This is just like the move instruction, with a few important
differences.  First, the destination must be an address register (a0
to a7).  As a matter of fact, if the destination is going to be an
address register, you _must_ use the movea variation; fortunately most
assemblers will slip the "a" in for you if you forget.

The other major difference is that this instruction does not change
ANY of the ccr flags.  This means if you have just done something that
sets some of the condition codes, you can still move data into an
address register without changing those flags.  (This is more useful
than it sounds.)  Just keep in mind that if you move something into an
address register, the condition codes are not affected.

moveq #n,destination

This is like the move instruction, but it too has some differences.
For one thing, the size is always a full 32-bit move.  Also, the
destination must be a data register (d0 to d7).  Finally, the number
moved must be between -128 and 127; although this means it's only an
8-bit value, it is sign-extended to 32 bits.

Otherwise, this instruction is like the regular move - the condition
codes are set the same way.  You should use moveq whenever you can, as
it is faster and uses less storage space than move.l #n,destination.
Your assembler will normally make this distinction for you, but it can
only do so if you're moving a long value (.l) and that value is in the
range -128 to 127.

clr.s destination

This is the "clear" instruction.  Basically, it moves a zero into the
destination.  The destination may be any size (byte, word, or long),
but it can't be an address register.  The condition codes are affected
as follows:

    N    Always cleared (since the result is never negative).
    Z    Always set (since the result is always zero).
    V    Always cleared.
    C    Always cleared.
    X    Not affected.

add.s source,destination

This was mostly explained last time, but as with move I didn't
explain what happens to the condition codes:

    N   Set if the result of the addition was negative.  Cleared
        otherwise.
    Z   Set if the result of the addition was zero.  Cleared
        otherwise.
    V   Set if the addition caused an overflow.  Cleared otherwise.
    C   Set if the addition caused a carry.  Cleared otherwise.
    X   Set the same as the carry bit.

Also note that the plain-vanilla add instruction can _only_ be used if
either the source or destination is a data register; if this is not
the case, you will need to use a different "flavor" of add
instruction.  (Again, normally your assembler will help you out here,
but you should be aware of the differences.)

adda.s source,destination

This is mostly like the plain-vanilla add, except that the
destination must be an address register.  In fact, if the destination
is an address register, this form MUST be used, even if the source is
a data register.  There are other differences as well.  The size may
only be .w or .l; if you use the word size, the word value is
sign-extended to a full 32 bits before being added to the address
register.  And, just like the movea instruction, the condition codes
are NOT affected at all by this instruction.

addi.s #n,destination

This is basically like the plain-vanilla add, with a few minor
differences.  As you can see from the instruction format, the source
must be immediate data.  The destination can be anything except an
address register (if you need to add immediate data to an address
register, you use adda instead).  Otherwise this is just like add.

The reason this instruction is present is because with the regular
add, you can only add an immediate value to a data register--because
either the source or destination must be an address register, and the
source is already an immediate value.  With this instruction, you can
add immediate data to anything, not just a data register.  Your
assembler will normally make this distinction for you.

addq.s #n,destination

This is like a regular add, with some differences.  (That sounds
familiar...)  The number that you can add is in the range 1 to 8.
You can add this number to just about anything; if you add to an
address register, the condition codes are not affected (like with
adda), but if you add to anything else the condition codes will be set
as for a regular add.  Also, if you add to an address register, the
size is always long (.l).

You use addq because it is faster than a regular addition, and it
uses less memory.  Usually your assembler will replace addi.s
#n,destination with addq if it can.

sub, suba, subi, subq

These are the subtract instructions.  They are just like their
addition counterparts, add, adda, addi, and addq, except they subtract
instead of add.

HELLO, WORLD! REVISITED

In light of these new instructions, let's look again at last month's
example program and see what we can do with it.  Here's the program
(I've shortened the comments to a single line each; for the fully
commented listing, see last month's AEO-PJ):

*    Hello world!
*    Some Assembly Required, Article 2

*    First, display text on the screen.

    move.l #text,-(sp)     ; Put the address of our text on the stack.
    move.w #9,-(sp)        ; Function code for cconws.
    trap #1                ; Call GEMDOS.
    add.w #6,sp            ; Remove our 6 bytes from the stack.

*    Now wait for a keypress.

    move.w #8,-(sp)        ; Function code for cnecin.
    trap #1                ; Call GEMDOS.
    add.w #2,sp            ; Remove our 2 bytes from the stack.

*    Now exit the program.

    move.w #0,-(a7)        ; Function code for pterm0.
    trap #1                ; Call GEMDOS.

*    Data used by our program.

text    dc.b 'Hello, world!',0    ; Text to display.

All right, to begin with I see in the ninth line the following:

    add.w #6,sp            ; Remove our 6 bytes from the stack.

This could use the addq variation; while the assembler will normally
fill this in for us, it's a good idea to do it yourself if you see it,
so you know what's going on.  So we'll replace it with this:

    addq #6,sp             ; Remove our 6 bytes from the stack.

Since sp is really a7, and adding to an address register is always a
32-bit operation, I did not include the .l--but you can if you like.
In a similar manner, the fifteenth line of our program (add.w #2,sp)
can also be changed to addq.

As a last change, we can also change the ninteenth line of our
program:

    move.w #0,-(a7)        ; Function code for pterm0.

The 680x0 has a handy instruction for putting zeroes in places, so we
can use that instead:

    clr.w -(sp)        ; Function code for pterm0.

Note that I also changed a7 to sp.  They really mean the same thing,
and I usually use a7 in my own programs, but everywhere else in the
program I used sp, so I thought it would be better to be consistent.
(Wish I knew how that a7 slipped in there. ;-)

WHAT ABOUT LOOPING?

Almost every program requires looping of some sort.  It's one of the
three basic structures of a program (sequential, iteration, and
branching).  The 680x0 has quite a few instructions to handle looping;
I won't cover them all this month, but I will list some of the basics.

bra destination

This instruction means "branch always" to the destination address.
The destination is a label inside your own program.  This is sort of
like a GOTO in BASIC; those of you who prefer more structured
programming may wince at the mention of the dreaded GOTO, but remember
that all of the structures you're familiar with can be built from IF
and GOTO statements.  (Next month I'll even show you how it's done.)

One thing to remember is that bra is a "relative" jump; that is,
instead of telling the CPU exactly where to go, it tells it how far
and what direction (forwards or backwards).  This means you can
"relocate" or move the code, and as long as you move the destination
along with it, the bra instruction will still indicate the proper
destination.  Most of the time this is not an important distinction;
later in this series I'll explain when it does matter.  When you write
programs using bra, you don't have to figure out how far to jump; you
just use the destination's label, and the assembler figures out how
far it is.  This does mean, however, that you can only bra to
destinations within your program.

bcc destination

This is really an entire class of instructions.  The "b" in "bcc"
means branch, and the "cc" means condition codes.  This is sort of
like an IF (condition) THEN GOTO in BASIC.  What it does is examine
the condition codes (which are normally set by preceding instructions)
and, if certain conditions are met, branches to a different place in
your program.  If the conditions are NOT met, the instruction does
nothing.  There are several different conditions you can check for;
all use a two-letter code (to replace the "cc").  Here they are (note
that I'm listing them with the "b" for branch):

beq    Branch if equal; that is, if the Z flag is set.  If the
    preceding operation resulted in zero, the Z flag will be set, so
    beq can also be used as a "branch if zero" instruction.  (This
    mnemonic comes from its use with the compare instruction, cmp,
    which I will discuss next month.)

bne    Branch if not equal; that is, if the Z flag is clear.  If the
    preceding operation did not result in zero, the Z flag will be
    cleared, so bne can also be used as a "branch if NOT zero"
    instruction.  (Like beq, this mnemonic relates to the compare
    instruction.)

bgt    Branch if greater than; specifically, if the N and V flags
    match and the Z flag is clear.  If the preceding operation
    resulted in a value greater than zero, the branch occurs.

bge    Branch if greater than or equal; specifically, if the N and V
    flags match.  If the preceding operation resulted in a value
    greater than or equal to zero, the branch occurs.

ble    Branch if less than or equal; specifically, if the N and V
    flags do not match, or the Z flag is set.  If the preceding
    operation resulted in a value less than or equal to zero, the
    branch occurs.

blt    Branch if less than; specifically, if the N and V flags do not
    match.  If the preceding operation resulted in a value less than
    zero, the branch occurs.

bpl    Branch if plus (positive); that is, if the N bit is clear.  If
    the preceding operation resulted in a positive value (greater than
    or equal to zero), the branch occurs.

bmi    Branch is minus (negative); that is, if the N bit is set.  If
    the preceding operation resulted in a negative value (less than
    zero), the branch occurs.

bhi    Branch if higher; specifically, if the C and Z bits are both
    clear.  If the preceding operation resulted in a value greater
    than zero, the branch occurs.

bhs    Branch if higher or same; specifically, if the C bit is clear.
    If the preceding operation resulted in a value greater than or
    equal to zero, the branch occurs.  You can also use "bcc" in place
    of "bhs"; "bcc" means "branch if carry clear", which is exactly
    what bhs does.  (Sometimes one is more indicative of what you mean
    than the other is.)

bls    Branch if lower or same; specifically, if the C or Z bit is
    set.  If the preceding operation resulted in a value less than or
    equal to zero, the branch occurs.

blo    Branch if lower; specifically, if the C bit is set.  If the
    preceding operation resulted in a value less than zero, the branch
    occurs.  You can also use "bcs" in place of "blo"; "bcs" means
    "branch if carry set", which is exactly what blo does.  (Sometimes
    one is more indicative of what you mean than the other is.)

bvc    Branch if overflow is clear; that is, if the V bit is clear.
    If the preceding operation did not create an overflow, the branch
    occurs.

bvs    Branch if overflow is set; that is, if the V bit is set.  If
    the preceding operation caused an overflow, the branch occurs.

Looking at the descriptions for the various branch instructions, it
may appear that there are duplicates.  The group bgt, bge, ble, and
blt may look very similar to the group bhi, bhs, bls, and blo.  But if
you look closely, you will see that the two groups test very different
flags.  What's the "real" difference, and how do you tell which group
to use?

The answer is simple.  The first group--bgt, bge, ble, and blt - react
to conditions resulting from _signed_ arithmetic.  If you are working
with signed numbers, use bgt, bge, ble, and blt.  The second
group--bhi, bhs, bls, and blo--are for _unsigned_ arithmetic.  If you
are working with unsigned numbers, use these.

BUT, WHAT ABOUT LOOPING?

All of this branching stuff is wonderful, but it doesn't mean a whole
lot by itself.  The most common form of looping (although not the
simplest) is probably the for loop.  So for this month's example
program, I'll show a program that inverts the first sixteen colors of
the desktop.  There's an instruction I'll be using to do the actual
inverting, so let's define it now:

not.s destination

This instruction simply flips all the bits in the destination (i.e.
it takes the one's complement).  The size can be byte, word, or long,
and the destination can be anything except an address register.
(Later in this series I will cover the rest of the bit manipulation
instructions.)

Here's this month's program, outlined in C:

main()
{
    short index;    /* Our loop counter */
    short color;    /* One color value  */

    for (index = 15; index >= 0; index--)    /* Process all colors */
    {
    color = setcolor(index, -1);             /* Get the old color  */
    color = ~color;                          /* Invert the bits    */
    setcolor(index, color);                  /* Set the new color  */
    }

    pterm0();    /* Exit back to the desktop */
}

In C, this could have been done more compactly (there really wasn't a
need to use an extra color variable) but I wrote it this way because
it more closely follows how the assembly program works.  Here's the
assembly version:

*    Desktop color inverter
*    Some Assembly Required, Article 3

*    I use d3 as index.  I didn't use d0 because it is "trashed" by TOS.
*    I use d0 as color, because I don't call TOS before I'm finished
*    with the value (so it never has a chance to trash it).

*    Set things up for our loop.

    moveq #15,d3        ; index starts at 15.  While index is really
                ; just a short (not a long), we're not doing
                ; anything with the higher 16 bits, so we
                ; can use moveq and fill in all 32 bits and
                ; not worry about it.

*    Do the body of the loop.

loop    move.w #-1,-(sp)    ; Push -1 onto the stack (returns old color).
    move.w d3,-(sp)         ; This is our color number, index.
    move.w #7,-(sp)         ; Function number for setcolor.
    trap #14                ; Call XBIOS.
    addq #6,sp              ; Remove our parameters from the stack.

                            ; setcolor() returns the old color value in
                            ; d0, so I use it right where it is.
    not.w d0                ; Flip all the color bits.

    move.w d0,-(sp)         ; This is the new color value (inverted).
    move.w d3,-(sp)         ; This is our color number, index.
    move.w #7,-(sp)         ; Function number for setcolor.
    trap #14                ; Call XBIOS.
    addq #6,sp              ; Remove our parameters from the stack.

*    Now update index and see if we're finished with the loop.

    subq.w #1,d3            ; Decrement "index".
    bpl loop                ; If the result is a positive (>= 0) value,
                            ; this will branch to "loop", processing the
                            ; next color.

*    We're done, exit back to the desktop.

    clr.w -(sp)             ; Function number for pterm0 (0).
    trap #1                 ; Call GEMDOS.

That's all.  If you follow the flow of the program, you will notice
that the assembly program does not check the for condition (index >=
0) before entering the loop.  For this example, it's okay, as we know
the first time through the loop (at least), index >= 0 will be TRUE.
The C definition of for, however, checks the condition before entering
the loop.  (We could do this by branching to our test before entering
the loop.)

This program does assume that it's running in an ST graphics mode; if
you have something nicer, you may want to switch to an ST graphics
mode to convince yourself this program really does work.  (Run the
program a second time to restore the colors.)

ARE WE DONE?

That's all for this month.  Next month I'll go over more looping and
branching instructions, and show you ways to use them to piece
together some high-level structures like IF, FOR, WHILE, and so on.

As a closing note, I'd like to point out that all of the Motorola
manuals I have give instructions and registers and everything else in
all upper case.  Generally I'm not fond of all upper case, and since
most assemblers don't really care whether you use upper or lower case,
I use lower case.  You can use whatever makes you happy.

(If you have questions regarding any of these articles, don't
hesitate to contact me.  You can reach me at DMJ on GEnie, or
[e-mail] from the Internet.)

/***********************************************************************/
                    C Programming Column
                      By: Albert Dayes
/***********************************************************************/

//// A new C Book and Configuration files

At the Software Development conference I picked up a new book on
programming called "C Pointers and Dynamic Memory Management".  It's
the only book I have seen that deals strictly with pointers in C.  It
includes a 3.5 inch floppy disk with all of the source code examples
used in the book.  It covers pointers for beginning to advanced C
programmers.  A review will follow in the next issue of AEO-PJ.

For those who enjoy MicroSoft Windows style configuration files
similar to WIN.INI, there is some code just for you.  The March 1994
issue of Dr. Dobbs Journal had an article called "MULTIPLATFORM .INI
FILES" which provides this capability.  If you are not familar with
*.INI files an example from Adobe Acrobat Reader follows.

[AdobeViewer]
IS8514=4
DefaultMag=100
ShowLargeDIBS=1
Chameleons=0
GreekThreshold=6
MaxApp=1

[RecentFiles]
File-1=D:\MANUAL.PDF
File-2=D:\INTRO.PDF
File-3=D:\HELPREAD.PDF

Each *.INI file is divided into sections and entries.  The sections
are enclosed in [] and the entries follow.  The entries are in the
form of entry_name=entry_value.

//// Functions

There are several useful functions in the C library, but one of the
most useful ones is printf() and its offspring.  The printf() allows
one to have formatted output, which is useful in itself.

Sprintf() is one of the most used functions since the output is
directed to a buffer rather than standard output.  This allows for
creating message strings for GEM form alert that can include different
error messages.  For example:

char alert_buffer[100];
int  error_number;

error_number = 37;

sprintf( alert_buffer, "[1][ Disk error # %d ][ OKAY ]", error_number );

form_alert( 1, alert_buffer );

When it comes to outputting strings as part of the output, it can be
somewhat of a problem.  The length of each string is dynamic but it
can be controlled using special options within the printf() function.

To set the minimum width for a string use the following...

char string[100], buffer[100];
int  width, max_width;

  strcpy( string, "This is not a long string." );

  sprintf( buffer, "%*s", width, string );

To set the maximum width one can use the following...

  sprintf( buffer, "%*.*s", width, max_width, string );

Being able to set the maximum width of a string has many uses.  One
such use is in printing reports on a printer.  If you have a database
with a 100 character description field it must be limited if other
data is going to fit. (This is assuming that each printer line is 80
characters in length.)  One could limit the max output to 20
characters with the minimum being 5 characters.  For example

  sprintf( buffer, "%*.*s", 5, 20, string );

For left justified text one can use a negative value for the width.  For
example:

  sprintf( buffer, "%*.*s", -5, 20, string );

This is different than the normal use of printf() since the values
within the format string are dynamic rather than static.  The format
string is defined as follows.

   "%*.*s"  which equals "%[width].[precision]s"

With string data type, the precision becomes the maximum width
allowed.  By using "*" rather than numbers, one can control the look
of the output from within the program.  (That is, at run time and not
at compile time.)

For example one could open a dialog box and ask the user to input the
maximum length of a field for sending output to a file.

#define AEOPJ_ANSI 1

main()
  {
   int field_description_length;

   field_description_length = get_description_length();

   perform_output( field_description_length );

   return(0);

  } /* main() */

#if AEOPJ_ANSI > 0

perform_output( int field_length )

#else

perform_output( field_length )
  int field_length;

#endif

  {
   char big_buffer[100];
   char descript_string[] = "Database field description";

   /* make the minimum field description length at least 1 character */

   sprintf( big_buffer, "%*.*s\n", 1, field_length, descript_string );

   /* print big_buffer to the file */

   return(0);

  } /* perform_output() */

For more information on how printf() family is implemented a good
book on the subject is "The Standard C Library" by P.J. Plauger, ISBN
0-13-131509-9.

Next time, more functions will be discussed and some pointers might be
thrown in as well.

/***********************************************************************/
                Advanced Computing
                 By: Carl Barron
/***********************************************************************/

//// Introduction to YACC (Yet Another Compiler Compiler)

This time I will take our syntax checker of an alert box language and
create a compiler to create a C file of functions that will display
the alert boxes.

We need some more of yacc's directives to do this. We are going to
pass character pointers to strings and integers for other parameters.
A union is the 'proper' way to do this in C and yacc provides a %union
directive to create a stack type that is a union. The syntax is %union
{ /* C definition of the union fields */ }

so after THE %} of alert.y we add
%union
{
     char *id;
     int  num;
}

Yacc also provides a way for it to remember which union element to
access for each terminal and non-terminal symbol.  Last time I gave a
simplified definition of the %token directive. The full blown
definition is %token <%union field name or nothing> <white space
separated list of token names>.

To continue modifying our previous yacc file change the %token
NUMBER line to :%token <num> NUMBER and the %token QSTRING line to
%token <id> ID QSTRING.  ID is a new token for an unquoted string.

In the actual definition of the language, we now add some C code to
aid our compiler.  Much of the work is done in the associated file
alert.c.  This file checks the semantics of the current defintion for
illegal conditions like more than five alert strings, etc.

The new grammar section is:
%%
alerts    :    alert          /* this allows multiple alert */
          |    alerts alert   /* boxes per file */
          ;

alert     :    alert_strt alert_data alert_end
          ;

alert_strt     :    alert_hdr ID   {add_id($2);/* save ID */}
               ;

alert_end :    END                 {write_alert();clean_alert();}
          ;

alert_hdr :    ALERT
          |    error ALERT         {clean_alert();}
          ;

alert_item :   ICON NUMBER    {if(add_icon($2)) YYERROR;}
          |    DEFAULT NUMBER {if(add_default($2)) YYERROR;}
          |    STRING QSTRING {if(add_string($2)) YYERROR;}
          |    BUTTON QSTRING {if(add_button($2)) YYERROR;}
          ;

alert_data     :    alert_item
               |    alert_data alert_item
               ;


Note that this grammar appears to allow an infinite number of items in
an alert box!  The add functions check to make sure that the system
limits are not exceeded and there is at least one string and button.
This is the easiest way to handle the problem of a finite max number
of entries in a grammar. It is possible to create a grammar definition
that would handle this but it is much more cumbersome and unneeded.

The lexer is a bit about the same the only entries changed are for
NUMBER, ID and QSTRING.

NUMBER and ID just return the lexigraphic value of these tokens in the
proper field of the union. Yylval is defined by yacc to hold this
infromation.  STR was used in the old lex file and string in the new
one for some reason.  The new one checks for an unterminated string
and prints a warning if a newline preceeds the closing quote of a
string.  The start state eat is used to eat the closing quote or
newline, and to exit back to the INITIAL start state of the lexer.

The additional C code does all the work of keeping track of what we
have so far. and printing out a C function for each alert box defined
without error conditions.

Error is a special yacc non-terminal symbol used when yacc is in an
error correcting state. The usage in this grammar is to skip to the
next possibly correct alert box definiton, if there is an error,
deleting all infromation about the invalid alert defintion. YYERROR is
a yac directive [actually a preprocessor macro] to place yacc in an
error correcting state.

The file symbol.c contains my special purpose memory allocators for
this project. They keep a linked list of all memory that is allocated
by malloc(), by this program. This to make memory deletion complete
and correct even under an error condition. If the only place the
addresses returned by malloc() were stored was the yacc stack, and an
error occurred the addresses would be lost before the memory can be
freed.  This is important to remember.

In writing this article I noted some gross errors in the first
article.  So gross that the code should never have made it thru yacc!
Nobody complained or mentioned it.  This seems to indicate that
prehaps I am talking to no one!  (The perils of publishing untested
code.) The code in the previous article was untested.

The complete tested source and executables of this alert box compiler
are enclosed in cmpalert folder or archive. As ussual I am on CIS and
GENIE almost every day at least once.

GENIE:CBARRON
CIS:75066,3204

Perhaps I will do some more yaccing next time, or maybe present an
overview of important unix style tools for text file manipulations
often done by programmers.


/***********************************************************************/
                GFA BASIC
                By: Scott R. Garrigus
/***********************************************************************/


//// Introducing...

Hi Everybody!  My name is Scott R. Garrigus and I'll be your new GFA
BASIC liason here at AEO-PJ.  (You can call me Mr. Garrigus if you'd
like. <grin>) We'll be covering the many facets of our beloved
language including using the Resource Construction Set and
incorporating its output into our programs, memory management of GFA
and the bugs therein :-(, and we'll also be exploring GEM programming
taking up where our good friend Eric Goodman left off, as well as
anything else that has to do with GFA.

//// Strike up the band!

Which brings us to a very important person in the GFA world; someone
whom I'm sure a lot of you may know... Mr. Han Kempen.  Mr. Kempen is
the author of 'Your Second GFA-BASIC 3 Manual', which is available
free of charge on any of the online services.  This manual includes no
less than 24 chapters of documentation pertaining to the ins and outs
of GFA BASIC.  And if that's not enough, it also includes the largest
library of GFA BASIC routines on the planet - at least the largest
that I know of.  If you need to do something specific in GFA, you can
usually find an example of it here.  The only thing I didn't like was
that all the doc files were in 1st Word format and I only have an
ASCII viewer, so I've taken the liberty of converting all the docs to
ASCII format and you can find them in the Atari ST Library on GEnie as
MANUAL_A.ZIP.

I'd like everyone to give Mr. Kempen a big round of applause for his
valient effort to keep our favorite language alive.  Thank you Mr.
Kempen!  We really appreciate your efforts!  And if it hasn't become
clear already, if you don't have these files, then go get'em because
we'll be using them when needed.

//// On with the show... the RCS, that is.

Okay, I've introduced myself; I've talked about Mr. Kempen's excellent
contributions; let's see... what else is there to do?  Ah, yes, maybe
we should do a little programming, huh? :-)  Well, first I want you to
find the files TOSI_10.DFN, TOSI_10.LST, and TOSI_10.RCS  (they're
included here in this archive).  These are the files we'll be working
with today and they are the start of a small utility program which
we'll be putting together.  The program is called TOS Info 1.0 and it
will be able to run as either a PRG or an ACC just by renaming it, be
resolution independent, and be compatible with all the Atari systems
and TOSes out there.  Sound complicated?  Don't worry, it's not
really... and if it sounds too simple, well, then you're ahead of me
but you may find a few interesting tidbits you hadn't learned before
so stick with us, okay?

Now let's zap outa here and get into the RSC program.  If you have a
multitasking system just run the RSC.PRG, if not then load this
magazine into your favorite desk accessory text editor and then run it
from within the RSC.  Here we go... <classic StarTrek transporter
sounds> ...okay I'm here!  Coming to you live from within the RCS S S
s s s... Did you make it? :-)  DON'T open the TOSI_10.RCS file yet.  I
want to take you through this step by step.  You can look at what I've
done when we're finished.

First we need a box to display inside of our program's window.  We're
going to make this resolution independent so we should use a Dialog
box.  The reason for this is because within a Dialog box, all our
elements will be snapped into place and they'll appear the same way in
any resolution we run the program in.  If we were to use a Panel then
we could place elements anywhere we wanted but they wouldn't appear
the same in different resolutions.  So grab a Dialog box and name it
MAIN and then open it.  Now we need four display elements to show the
TOS version, TOS date, System time, and the System date.  Grab an
EDIT:______ element (w/o the box around it) and place it on the
screen.  Double-click it to edit it and on the first, second and third
lines, enter

        TOS Version: ~~~~~~~~~~
        ~~~~~~~~~~~~~XXXXXXXXXX
        ~~~~~~~~~~~~~__________

This will give us an editable field with a label so that when we
enter a value for it in our program only the underlines will change
and the label TOS Version: will stay the way it is.  Now to explain
this, the first line gives us our label and saves a space for our
data.  The second line shows what type of data will be allowed...
using X means any type of data is allowed be it numerical or
alphabetical.  The third line gives us a mask to show where the data
will appear (represented by the underlines).  From here we give the
element a name, TOSVERS, and we hit Okay to accept it.  Now make three
copies of this element and with each one, place it on the display,
changing the first line to TOS Date: , System Time: , and System
Date: , respectively. (And be sure to give each a name.)  Place the
elements so they line up with each other and then resize the main box
so it's just big enough to hold the elements.  Close the dialog box.

Next we need a menu bar for our program.  Grab the menu icon and
place it on the screen.  Give it a name such as MENU <g>, and then
open it up.  You'll see a menu bar and two titles in it.  Select the
file title and delete it.  We won't be needing it in this program.
Now click on the Desk title to open it and double-click on the first
entry.  Type in the name of our program leaving two spaces at the
begining and the end to make it look good (ex.   TOS Info 1.0  ) and
give it a name such as DESKMENU.  Click on okay, and we're done.  Now
wasn't that easy?  We could also add a credit dialog like I did but
I'm sure you can figure that out from looking at the file I've
provided.  Be sure and study the TOSI_10.RSC file thoroughly so you
can get a good understanding of how it's put together and if you have
any questions, just send them my way and I'll cover them in the next
installment.

//// Coming up...

Next time we'll be covering memory management in GFA and how to find
the proper amount of memory for our program (thanks to the help of my
good friend Damien Jones whom I've been hounding for info. for the
past two weeks <grin>).  I'll be giving you the first part of the
listing for our utility program and I'll also be giving you your first
homework assignment...  (hee hee hee).  Until next time...!


/***********************************************************************/
     HARD CORE - Interview with Roger Burrows, author of ExtenDOS
     By: Albert Dayes
/***********************************************************************/

AD: What is your product for the Atari ST or Falcon030?
RB:

   The product is ExtenDOS, a CD-ROM driver for the ST, TT030, and now
   the Falcon030 as well.  It allows you to access the most popular
   CD-ROM formats (ISO-9660 and High Sierra) on any Atari system.  It
   really performs the same function as the CDROM.XFS file system
   driver for MultiTOS/MiNT, but with two advantages: you don't need
   MultiTOS or MiNT, and you get better performance.


AD: What prompted your interest in CD-ROM?
RB:

   I wanted access to all the data starting to become available on
   CD-ROM, including source code, electronic text, and graphics, and I
   wanted access from my TT.  I looked around but there didn't seem to
   be a well-supported, easy-to-use method, so I decided to write my
   own.


AD: How long did it take to develop ExtenDOS?
RB:

   About 6 months, working in the evenings and on weekends.  I started
   work on it in June 1993, began beta-testing at the end of
   September, and shipped the first version in January this year.


AD: What technical difficulties did you encounter and how did you
    overcome them?
RB:

   The greatest difficulty was debugging the hardware support code
   during beta test, when I had no hands-on access to the systems
   being debugged.  I relied very much on the problem descriptions by
   the beta testers.  Fortunately the people doing it had had previous
   beta test experience.  I also added trace and debugging code to my
   drivers, some of which remains in the distributed product, to help
   out if a user experiences problems.

   While adding the Falcon support, there were some initial problems
   because I didn't have all the hardware documentation.  However,
   thanks again to a beta tester, I borrowed a Falcon for a few days
   and figured out the missing information.


AD: What programming language did you use?
RB:

   ExtenDOS is written entirely in 68000 assembler.  Since it has to
   interface to the ACSI/SCSI hardware at a low level, it seemed the
   best choice, although it would have been possible to write it in a
   mixture of C and assembler.


AD: Compare and contrast the ISO-9660 filesystem vs GEMDOS.
RB:

   The ISO-9660 filesystem is optimised for a relatively slow,
   read-only, direct-access device such as a CD-ROM.  Since the device
   has relatively long seek times, a hierarchical directory structure
   like GEMDOS would slow down access because of the constant seeking
   between directories.  Thus ISO-9660 has all the paths to the
   directories stored in a single path table which is typically read
   into a buffer when a new CD-ROM is loaded, and remains there.

   The read-only nature of CD-ROM ensures that files cannot be
   deleted.  Thus there is no need to support the possibility of
   'holes' in allocated file space, and the FAT mechanism found in
   GEMDOS doesn't exist.  Each file is stored sequentially on the
   CD-ROM, which helps performance when reading a file.

   ISO-9660 is also designed to be architecturally independent, in
   that any numbers that need more than a byte to store them (such as
   filesizes or some internal pointers to filesystem structures) are
   stored in two forms: high-order byte first (Motorola-style) and
   low-order byte first (Intel-style).  In contrast, GEMDOS stores
   such data in only one form:  Intel-style (this is necessary since
   GEMDOS is designed to be compatible with MSDOS at the filesystem
   level).

   Finally, in order to be applicable to the widest range of
   platforms, ISO-9660 implements a minimal set of file attributes
   that correspond fairly well to those in GEMDOS:  file date/time is
   provided as well as an attribute that corresponds to GEMDOS's
   "hidden file" attribute.  The "read-only" and "system" attributes
   are not provided.


AD: What future enhancements are you planning for, or thinking
    about, for future editions of your product?
RB:

   The next enhancement I am planning is support for photoCD
   (including multi-session).  The main effort in this area will be
   supporting the wide range of implementations that different
   manufacturers of CD-ROM drives have used.  Another area that I am
   thinking about is integrated support for playing audio CDs.  It
   should also be feasible to read Mac HFS-format CD-ROMs, although
   that's not a priority since most CD-ROMs are ISO-9660 these days.

   Longer term, ExtenDOS could be used to add other facilities apart
   from CD-ROM, and I am looking at that too.


AD: Any hardware that you recommend or that is compatible with your
    product?
RB:

   To connect a SCSI CD-ROM drive to the ACSI port of an ST or TT, you
   need to use one of ICD's adapters.  This is in order to pass the
   full SCSI command set to the CD-ROM.  I use the AdSCSI Plus, but
   ICD have told me that all the following current and former ICD
   adapters use the same method to provide full SCSI, so they should
   all work equally well:

        Advantage ST
        Advantage Micro ST
        Advantage Plus ST,
        AdSCSI ST
        AdSCSI Micro ST
        AdSCSI Plus ST
        The Link.

   ICD received a copy of ExtenDOS recently and I'm waiting for them
   to confirm compatibility.

   As far as CD-ROM drives are concerned, any SCSI drive should work
   with ExtenDOS, since it only uses the most basic SCSI commands.
   There is also code in ExtenDOS to specifically support the Atari
   CDAR504, the only drive that can connect directly to the ACSI port.
   The following drives have been verified to work with ExtenDOS:

        Atari CDAR504
        Panasonic (Matsushita) CR-501
        NEC 3Xp
        NEC 74/84
        Sony CDU-541
        Toshiba 3401

   If you are contemplating buying a CD-ROM drive now, I would
   recommend getting one that supports the SCSI-2 command set.  This
   standardises many of the low-level commands, and will make it more
   likely that additional features of the drive, such as audio
   control, will be supported by future versions of ExtenDOS.  You may
   also want to make sure that the drive supports multi-session
   photoCD, although I haven't found any SCSI-2 compatible drives that
   don't.

   I personally use a Toshiba 3401 since it offers full SCSI-2 command
   set compatibility, as well as photoCD support that is very easy to
   implement, and very good performance.  Other drives that have been
   well-reviewed include the NEC, Chinon, and Plextor (formerly
   Texel), although I have had no experience with the latter two.

[ Editor's note:

ExtenDOS v1.1 is available immediately at only $19.95 (including
shipping & handling) from:

      Anodyne Software
      6 Cobbler Court
      Ottawa
      Ontario K1V 0B8
      CANADA.

Please make your payment by cheque or money order, in US$ for shipping
to the U.S.A., in Canadian$ for shipping within Canada.  Ontario
residents please add 8% sales tax.

Also contact your local Atari dealer to see if they carry the product.

]

/***********************************************************************/
                     DABBLING IN PASCAL
                     By: Kris Gasteiger
/***********************************************************************/

(I was going to include an input verification routine for last month's
program, but I lost it along with some other goodies when my hard
drive crashed.)

I am currently using OSS/ICD Personal Pascal, Ver 2.02. on a 2.5Mb
520ST with TOS 1.4, one double sided floppy drive, a ToadStor130 hard
drive, SC1224 color monitor, 2400 baud modem, 24 pin printer, and a
few other periferals. All code examples I present will run on MY
system, other TOS versions, may give problems, be cautious.

A reader asked for some help in getting the Bios call, Bconin, used in
the example program last month, to work in Modula II. I don't have
Modula II, but from his description of the Modula II version of the
call, the problem seems to be that while PP allows you to declare
Bconin as Byte, Short_Integer, or Long_Integer, M II declares it as
Long_Integer.  If Declared as Long_Integer, Bconin returns the Ascii
value of the key in the low word ,and the keyboard Scan Code in the
high word. (A word is 16 bits, a long word is 32 bits, so there are 4,
8 bit, bytes in a long word.) The problem then is, how do you extract
just the ASCII value, the lowest Byte, from a 32 bit long word?

The following short program demonstrates...

(The text between the dashed lines is a complete Pascal program
 which I have compiled and run on MY system.)
---------------------------------------------------------------------------
{ This program is to be compiled for TOS by setting the compiler options }
{ to TOS in the PP manager.                                              }
{ It's purpose is to demonstrate how to use the arithmetic shift to      }
{ extract the scan code and ascii value from the Long_Integer returned   }
{ by Bconin.                                                             }
{ Written in OSS/ICD Personal Pascal. 1/22/94 By: Kris J. Gasteiger.     }
{ Parts copywrited by OSS/ICD.                                           }

Program Key_read( Input, Output );

Const
  Keyboard=2;  { Bconin looks for a character on the specified device.   }
               { Valid devices are: 1: the serial port, 2: the keyboard, }
               { and 3: the MIDI port. devices 0 and 4 aren't valid for  }
               { this call as far as I can tell...                       }

  Esc=65563;   { Raw Long_Integer value returned by Bconin. }

Var
  Ascii_Value, Keypressed, Temp: Long_Integer;

{ ************************************************************************ }
{ Bios Character-Oriented Device Input. Gets a character from the }
{ specified device.                                               }

Function Bconin( Device: Short_Integer ): Long_Integer;
  Bios( 2 );

{ Note: A long_Integer is 32 bits, a Short_Integer is 16 bits, and a Byte }
{ is 8 bits UNSIGNED. These are all valid declarations for Bconin in PP.  }

{ ************************************************************************ }
{ Main }
Begin
  Writeln( 'Press a key, <Esc> ends program.' );
  Repeat
    Keypressed:=Bconin( Keyboard ); { Get a key from the keyboard. }
    Temp:=Shl( Keypressed, 16 );    { Shift left to discard the high word. }
    Ascii_Value:=Shr( Temp, 16 );   { Shift right to Put the low word back.}

    { The second parameter to the shifts is the number of bits to shift in }
    { the direction of the call. Anything shifted beyond the declared size }
    { of the variable parameter is lost. EG: Shr( byte, 1 ) discards the   }
    { right most bit of the byte. If the byte is all ones,  ( 11111111 ),  }
    { after the call, its highest bit will be a zero........( 01111111 ).  }
    { Shifting it back, Shl( byte, 1 ) will give............( 11111110 ).  }
    { However, if the byte contains.........................( 01111110 ),  }
    { then Shr( byte, 1 ) will give.........................( 00111111 ),  }
    { and Shl( byte, 1 ) will give..........................( 01111110 ).  }

    { Display the Ascii value and the character. }
    Writeln( 'Low word, Ascii value: ', Ascii_Value, '=',
              Chr(Ascii_Value ) );

   { Extract the high word and display it.}
    Writeln( 'High word, Scan code: ', Shr( Keypressed, 16 ) );
    Writeln;
  Until Keypressed=Esc;  { End the program if the Escape key is pressed. }
End.
---------------------------------------------------------------------------

I hope that is of help to you readers who are translating to other
languages or trying to understand the different faces of Bconin.

Next time, we'll take that look at parts of GEM, and that simple
printer utility, maybe! Until then, have fun dabbling!


/**********************************************************************/
              The Library: Gemini, a new Atari CD-ROM disc
                      by Damien M. Jones
/***********************************************************************/

I should warn you that my "real" job - when I'm not writing Atari
software - is to write multimedia CD software on the PC.  Perhaps I'm
not the best person to review this disc, but I let slip that I had one
of these discs, and Albert Dayes insisted I write a review.  (Albert's
very persuasive...  no!  No!  Please don't hit me Albert, I'll get
this review done!  Really! <grin>)

Ahem.  Back to the review.  I'll start on the outside, since it's the
first thing I saw when I pulled the disc out of the nice, padded
envelope it was mailed to me in.  The disc comes in a jewel case,
which is pretty much standard for CD-ROMs these days.  (I won't
mention how many discs I've seen in cheap plastic sleeves, because
that's another story.)  The artwork on the case is tastefully done;
from the outside it appears that this is a high-quality disc, which is
appreciated.

Opening the jewel case, I found the CD; again, the art is tastefully
done, but it includes a befuddling line on the disc: "Type GO to
start".  Hmmm, must be a mistake.  Somebody's been spending too much
time in DOSland.  I took the disk out of the case and slipped it into
my PC.  (I don't have a CD-ROM drive attached to my Atari, so I'm
forced to look at the disk through Messy-DOS.)  It didn't take me long
to miss the ease of browsing files I get with my Atari, as well as my
favorite file viewer (View II).  But somehow I found the will to press
on.

The disk contains two copies of each file, really.  In one folder
(FILES) is the uncompressed set; this is great for poking through
what's there to see what you like and what you don't like.  The other
folder (ZIP) contains compressed versions of the same files; most of
these are compressed with ZIP or LZH.  This is ideal if you run a BBS,
as there are also pre-made indexes for several BBS packages.

Since I'm not running a BBS on this machine, I dived right into the
FILES folder and started puttering around.  There's another layer of
folders here, splitting this huge library into manageable categories.
Here's a list (please excuse the DOS format):

 Volume in drive D is ATARI_1293
 Directory of D:\FILES

[.]             [..]            [ACC]           [ARCHIVER]      [ASTRONMY]
[BBS]           [CLI]           [DATABASE]      [DEMO]          [DISKUTIL]
[DTP]           [EDITORS]       [EMAG]          [EMDEMO11]      [EMULATOR]
[ETFILES]       [FALCON]        [FONTS]         [GAGS]          [GAMES]
[GDOS]          [GEMINI]        [GENIE]         [GNU]           [GRAPHICS]
[JAGUAR]        [LANGUAGE]      [LYNX]          [MATH]          [MINT]
[MUSIC]         [NEODESK]       [OTHER]         [PORTFOLI]      [PROGRAM]
[SCRNSAVE]      [SP_SHEET]      [TELECOMM]      [TT]            [UTILITY]
[VIRUS]         [W_PROCS]
       42 file(s)          0 bytes
                           0 bytes free

Remember, each of these names is another folder... and many of them
are organized even more inside.  This may seem like a bit much, but
the disc boasts over 2800 programs - if these weren't organized, it'd
be almost impossible to find anything.  Each program, actually, has
its own folder, so you can keep track of which file goes with which
program.  Almost every folder has a 00_INDEX.TXT file, which is a list
of the folders that contain files, and a brief description of what the
program does.  Here's a sample from the VIRUS folder:

Virus utilitys

\virus\

atarivir\       Doc describing various atari viruses
bootech\        Boot technician, repair, modify, work with boot sector
chasseur\       Anti virus
co_pilot\       Not really an anti virus, but could be useful
fcheck25\       Link virus detector
flu\            Simulates a virus, but isn't actually one
grab_bag\       Screen dump and anti virus, with C codes
hospital\       Help for preventing virus contamination
noroach\        TT/MegaSTE boot delay setup and virus guard
monomon\        Disk Editor and Utility
peneciln\       One fo the 1st virus detectors
protect6\       Erik Lars' new one
sagrotan\       Great new virus killer.  Able to learn new viruses
uvk58dem\       Ultimate Virus Killer (Demo version)
virend31\       Virus killer
virusdie\       Virus killer
viruskil\       Virus killer
vkiller\        The 'best' of the virus killers, version dated 5/27/91

Most of the listings are MUCH longer than this one.  For example, the
MUSIC folder has 160 folders inside it, each with something different.
It may take me a long time to fully explore what's on this disc,
there's so much.

Something that can be very useful is the INDEX.TXT in the root
directory of the disc.  It's a list of every file in the ZIP folder.
So how useful is that?  Well, the FILES folder and the ZIP folder are
organized the same way - so if you know where a file is in the ZIP
folder, you know it will be in about the same place in the FILES
folder.  With a good text viewer, you can search the INDEX.TXT file
for something in particular, and it will jump right to that spot.
Make a note of where the file is, and go find it.  This is generally
faster than trying to search the directories - even if you have a
program search the directories, it can take a long time, because there
are so many.

That's pretty much all there is to the disc.  Lots and lots of
programs, well-organized, with reasonably good indexes.  I should
point out (as the disc's "authors" do) that many of the programs on
the disc have been updated since the program was found; if you like a
program, be sure to check local BBSs, GEnie, Delphi, or wherever to
see if there is a more current version.

Also keep in mind that much of what's on the disc is Shareware.  If
you use the Shareware, you are still required to pay for it.  (Buying
the disc only covers the cost of collecting all the programs into one
place.)

This disc has great value as a collection of useful software for all
Atari computers.  There are quite a few pictures, fonts, animations -
something for everyone.  It's not meant to be an end-all collection;
software moves too fast for that ever to happen.  But it is a
fantastic resource.  If you have a CD-ROM drive attached to your Atari
computer, this disc will give you a chance to do something with it.
(Maybe it will even give you an excuse to BUY a CD-ROM drive.)

Walnut Creek CD-ROM
1547 Palos Verdes, Suite 260
Walnut Creek, CA 94596
USA
(800)-786-9907 (voice)
(510)-674-0821 (fax)


/**********************************************************************/
                         PERIODICALS
                      By: John Perry Barlow
/**********************************************************************/
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 =-=-=-=-=-=-Copyright 1993,4 Wired USA Ltd.  All Rights Reserved=-=-=-=-=-=
 -=-=For complete copyright information, please see the end of this file=-=-
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 WIRED 2.04
 Electrosphere
 *************

 Jackboots on the Infobahn
 ^^^^^^^^^^^^^^^^^^^^^^^^^

 Clipper is a last ditch attempt by the United States, the last great
 power from the old Industrial Era, to establish imperial control over
 cyberspace.

 By John Perry Barlow

 [Note: The following article will appear in the April 1994 issue of
 WIRED.  We, the editors of WIRED, are net-casting it now in its
 pre-published form as a public service. Because of the vital and
 urgent nature of its message, we believe readers on the Net should
 hear and take action now. You are free to pass this article on
 electronically; in fact we urge you to replicate it throughout the
 net with our blessings. If you do, please keep the copyright
 statements and this note intact. For a complete listing of
 Clipper-related resources available through WIRED Online, send email
 to <[e-mail]> with the following message: "send
 clipper.index". - The Editors of WIRED]

 On January 11, I managed to schmooze myself aboard Air Force 2. It
 was flying out of LA, where its principal passenger had just outlined
 his vision of the information superhighway to a suited mob of
 television, show- biz, and cable types who  fervently hoped to own it
 one day - if they could ever figure out what the hell it was.

 From the standpoint of the Electronic Frontier Foundation the speech
 had been wildly encouraging. The administration's program, as
 announced by Vice President Al Gore, incorporated many of the
 concepts of open competition, universal access, and  deregulated
 common carriage that we'd been pushing for the previous year.

 But he had said nothing about the future of privacy, except to cite
 among the bounties of the NII its ability to "help law enforcement
 agencies thwart criminals and terrorists who might use advanced
 telecommunications to commit crimes."

 On the plane I asked Gore what this implied about administration
 policy on cryptography. He became as noncommittal as a cigar-store
 Indian. "We'll be making some announcements.... I can't tell you
 anything more." He hurried to the front of the  plane, leaving me to
 troubled speculation.

 Despite its fundamental role in assuring privacy, transaction
 security, and reliable identity within the NII, the Clinton
 administration has not demonstrated an enlightenment about
 cryptography up to par with the rest of its digital vision.

 The Clipper Chip - which threatens to be either the goofiest waste of
 federal dollars since President Gerald Ford's great Swine Flu
 program or, if actually deployed, a surveillance technology of
 profound malignancy - seemed at first an ugly legacy of the
 Reagan-Bush modus operandi. "This is going to be our Bay of Pigs,"
 one Clinton White House official told me at the time Clipper was
 introduced, referring to the disastrous plan to invade Cuba that
 Kennedy inherited from Eisenhower.

 (Clipper, in case you're just tuning in, is an encryption chip that
 the National Security Agency and FBI hope will someday be in every
 phone and computer in America. It scrambles your communications,
 making them unintelligible to all but their  intended recipients.
 All, that is, but the government, which would hold the "key" to your
 chip. The key would separated into two pieces, held in escrow, and
 joined with the appropriate "legal authority.")

 Of course, trusting the government with your privacy is like having a
 Peeping Tom install your window blinds. And, since the folks I've
 met in this White House seem like extremely smart, conscious
 freedom-lovers - hell, a lot of them are Deadheads -  I was sure that
 after they were fully moved in, they'd face down the National
 Security Agency and the FBI, let Clipper die a natural death, and
 lower the export embargo on reliable encryption products.

 Furthermore, the National Institutes of Standards and Technology and
 the National Security Council have been studying both Clipper and
 export embargoes since April. Given that the volumes of expert
 testimony they had collected overwhelmingly opposed both, I expected
 the final report would give the administration all the support it
 needed to do the right thing.

 I was wrong. Instead, there would be no report. Apparently, they
 couldn't draft one that supported, on the evidence, what they had
 decided to do instead.


 THE OTHER SHOE DROPS

 On Friday, February 4, the other jackboot dropped. A series of
 announcements from the administration made it clear that cryptography
 would become their very own "Bosnia of telecommunications" (as one
 staffer put it). It wasn't just that the old Serbs in the National
 Security Agency and the FBI were still making the calls. The alarming
 new reality was that the invertebrates in the White House were only
 too happy to abide by them.  Anything to avoid appearing soft on
 drugs or terrorism.

 So, rather than ditching Clipper, they declared it a Federal Data
 Processing Standard, backing that up with an immediate government
 order for 50,000 Clipper devices. They appointed the National
 Institutes of Standards and Technology and the Department of Treasury
 as the "trusted" third parties that would hold the Clipper key pairs.
 (Treasury, by the way, is also home to such trustworthy agencies as
 the Secret Service and the Bureau of Alcohol, Tobacco, and Firearms.)

 They reaffirmed the export embargo on robust encryption products,
 admitting for the first time that its purpose was to stifle
 competition to Clipper.  And they outlined a very porous set of
 requirements under which the cops might get the keys to your chip.
 (They would not go into the procedure by which the National Security
 Agency could get them, though they assured us it was sufficient.)

 They even signaled the impending return of the dread Digital
 Telephony, an FBI legislative initiative requiring fundamental
 reengineering of the information infrastructure; providing
 wiretapping ability to the FBI would then become the paramount design
 priority.


 INVASION OF THE BODY SNATCHERS

 Actually, by the time the announcements thudded down, I wasn't
 surprised by them. I had spent several days the previous week in and
 around the White House.

 I felt like I was in another remake of The Invasion of the Body
 Snatchers.  My friends in the administration had been transformed.
 They'd been subsumed by the vast mindfield on the other side of the
 security clearance membrane, where dwell the  monstrous bureaucratic
 organisms that feed on fear. They'd been infected by the
 institutionally paranoid National Security Agency's Weltanschauung.

 They used all the telltale phrases. Mike Nelson, the White House
 point man on the NII, told me, "If only I could tell you what I know,
 you'd feel the same way I do." I told him I'd been inoculated against
 that argument during Vietnam. (And it does seem to me that if you're
 going to initiate a process that might end freedom in America, you
 probably need an argument that isn't classified.)

 Besides, how does he know what he knows? Where does he get his
 information?  Why, the National Security Agency, of course. Which,
 given its strong interest in the outcome, seems hardly an
 unimpeachable source.

 However they reached it, Clinton and Gore have an astonishingly
 simple bottom line, to which even the future of American liberty and
 prosperity is secondary: They believe that it is their responsibility
 to eliminate, by whatever means, the  possibility that some terrorist
 might get a nuke and use it on, say, the World Trade Center. They
 have been convinced that such plots are more likely to ripen to
 hideous fruition behind a shield of encryption.

 The staffers I talked to were unmoved by the argument that anyone
 smart enough to steal a nuclear device is probably smart enough to
 use PGP or some other uncompromised crypto standard. And never mind
 that the last people who popped a hooter in the World Trade Center
 were able to get it there without using any cryptography and while
 under FBI surveillance.

 We are dealing with religion here. Though only ten American lives
 have been lost to terrorism in the last two years, the primacy of
 this threat has become as much an article of faith with these guys as
 the Catholic conviction that human life begins at conception or the
 Mormon belief that the Lost Tribe of Israel crossed the Atlantic in
 submarines.

 In the spirit of openness and compromise, they invited the Electronic
 Frontier Foundation to submit other solutions to the "problem" of the
 nuclear-enabled terrorist than key escrow devices, but they would
 not admit into discussion the argument that such a threat might, in
 fact, be some kind of phantasm created by the spooks to ensure their
 lavish budgets into the post-Cold War era.

 As to the possibility that good old-fashioned investigative
 techniques might be more valuable in preventing their show-case
 catastrophe (as it was after the fact in finding the alleged
 perpetrators of the last attack on the World Trade Center), they just
 hunkered down and said that when wiretaps were necessary, they were
 damned well necessary.

 When I asked about the business that American companies lose because
 of their inability to export good encryption products, one staffer
 essentially dismissed the market, saying that total world trade in
 crypto goods was still less than a billion dollars. (Well, right.
 Thanks more to the diligent efforts of the National Security Agency
 than to dim sales potential.)

 I suggested that a more immediate and costly real-world effect of
 their policies would be to reduce national security by isolating
 American commerce, owing to a lack of international confidence in the
 security of our data lines. I said that Bruce Sterling's fictional
 data-enclaves in places like the Turks and Caicos Islands were
 starting to look real-world inevitable.

 They had a couple of answers to this, one unsatisfying and the other
 scary.  The unsatisfying answer was that the international banking
 community could just go on using DES, which still seemed robust
 enough to them. (DES is the old federal Data Encryption Standard,
 thought by most cryptologists to be nearing the end of its
 credibility.)

 More frightening was their willingness to counter the data-enclave
 future with one in which no data channels anywhere would be secure
 from examination by one government or another. Pointing to unnamed
 other countries that were developing their own mandatory standards
 and restrictions regarding cryptography, they said words to the
 effect of, "Hey, it's not like you can't outlaw the stuff. Look at
 France."

 Of course, they have also said repeatedly - and for now I believe
 them - that they have absolutely no plans to outlaw non-Clipper
 crypto in the US.  But that doesn't mean that such plans wouldn't
 develop in the presence of some pending "emergency."  Then there is
 that White House briefing document, issued at the time Clipper was
 first announced, which asserts that no US citizen "as a matter of
 right, is entitled to an unbreakable commercial encryption product."

 Now why, if it's an ability they have no intention of contesting, do
 they feel compelled to declare that it's not a right? Could it be
 that they are preparing us for the laws they'll pass after some
 bearded fanatic has gotten himself a surplus nuke and used something
 besides Clipper to conceal his plans for it?

 If they are thinking about such an eventuality, we should be doing
 so as well. How will we respond? I believe there is a strong, though
 currently untested, argument that outlawing unregulated crypto would
 violate the First Amendment, which surely protects the manner of our
 speech as clearly as it protects the content.

 But of course the First Amendment is, like the rest of the
 Constitution, only as good as the government's willingness to uphold
 it. And they are, as I say, in the mood to protect our safety over
 our liberty.

 This is not a mind-frame against which any argument is going to be
 very effective. And it appeared that they had already heard and
 rejected every argument I could possibly offer.

 In fact, when I drew what I thought was an original comparison
 between their stand against naturally proliferating crypto and the
 folly of King Canute (who placed his throne on the beach and
 commanded the tide to leave him dry), my government opposition looked
 pained and said he had heard that one almost as often as jokes about
 roadkill on the information superhighway.

 I hate to go to war with them. War is always nastier among friends.
 Furthermore, unless they've decided to let the National Security
 Agency design the rest of the National Information Infrastructure as
 well, we need to go on working closely with them on the whole range
 of issues like access, competition, workplace privacy, common
 carriage, intellectual property, and such. Besides, the proliferation
 of strong crypto will probably happen eventually no matter what they
 do.

 But then again, it might not. In which case we could shortly find
 ourselves under a government that would have the automated ability to
 log the time, origin and recipient of every call we made, could track
 our physical whereabouts continuously, could keep better account of
 our financial transactions than we do, and all without a warrant.
 Talk about crime prevention!

 Worse, under some vaguely defined and surely mutable "legal
 authority," they also would be able to listen to our calls and read
 our e-mail without having to do any backyard rewiring. They wouldn't
 need any permission at all to monitor overseas calls.

 If there's going to be a fight, I'd rather it be with this
 government than the one we'd likely face on that hard day.

 Hey, I've never been a paranoid before. It's always seemed to me
 that most governments are too incompetent to keep a good plot strung
 together all the way from coffee break to quitting time. But I am now
 very nervous about the government of the United States of America.

 Because Bill 'n' Al, whatever their other new-paradigm virtues, have
 allowed the very old-paradigm trogs of the Guardian Class to define
 as their highest duty the defense of America against an enemy that
 exists primarily in the imagination - and is  therefore capable of
 anything.

 To assure absolute safety against such an enemy, there is no limit to
 the liberties we will eventually be asked to sacrifice. And, with a
 Clipper Chip in every phone, there will certainly be no technical
 limit on their ability to enforce those sacrifices.


 WHAT YOU CAN DO

 GET CONGRESS TO LIFT THE CRYPTO EMBARGO

 The administration is trying to impose Clipper on us by manipulating
 market forces. By purchasing massive numbers of Clipper devices, they
 intend to induce an economy of scale which will make them cheap while
 the export embargo renders all competition either expensive or
 nonexistent.

 We have to use the market to fight back. While it's unlikely that
 they'll back down on Clipper deployment, the Electronic Frontier
 Foundation believes that with sufficient public involvement, we can
 get Congress to eliminate the export embargo.

 Rep. Maria Cantwell, D-Washington, has a bill (H.R. 3627) before the
 Economic Policy, Trade, and Environment Subcommittee of the House
 Committee on Foreign Affairs that would do exactly that. She will
 need a lot of help from the public. They may not  care much about
 your privacy in DC, but they still care about your vote.

 Please signal your support of H.R. 3627, either by writing her
 directly or e-mailing her at [e-mail]. Messages sent to that
 address will be printed out and delivered to her office. In the
 subject header of your message, please include the  words "support HR
 3627." In the body of your message, express your reasons for
 supporting the bill. You may also express your sentiments to Rep. Lee
 Hamilton, D-Indiana, the House Committee on Foreign Affairs chair, by
 e-mailing [e-mail].

 Furthermore, since there is nothing quite as powerful as a letter
 from a constituent, you should check the following list of
 subcommittee and committee members to see if your congressional
 representative is among them. If so, please copy them your  letter to
 Rep. Cantwell.

 > Economic Policy, Trade, and Environment Subcommittee:

 Democrats: Sam Gejdenson (Chair), D-Connecticut; James Oberstar, D-
 Minnesota; Cynthia McKinney, D-Georgia; Maria Cantwell,
 D-Washington; Eric Fingerhut, D-Ohio; Albert R. Wynn, D-Maryland;
 Harry Johnston, D-Florida; Eliot Engel, D-New York; Charles Schumer,
 D-New York.

 Republicans: Toby Roth (ranking), R-Wisconsin; Donald Manzullo,
 R-Illinois; Doug Bereuter, R-Nebraska; Jan Meyers, R-Kansas; Cass
 Ballenger, R-North Carolina; Dana Rohrabacher, R-California.

 > House Committee on Foreign Affairs:

 Democrats: Lee Hamilton (Chair), D-Indiana; Tom Lantos, D-California;
 Robert Torricelli, D-New Jersey; Howard Berman, D-California; Gary
 Ackerman, D-New York; Eni Faleomavaega, D-Somoa; Matthew Martinez, D-
 California; Robert Borski, D-Pennsylvania;  Donal Payne, D-New
 Jersey; Robert Andrews, D-New Jersey; Robert Menendez, D-New Jersey;
 Sherrod Brown, D-Ohio; Alcee Hastings, D-Florida; Peter Deutsch,
 D-Florida; Don Edwards, D-California; Frank McCloskey, D-Indiana;
 Thomas Sawyer, D-Ohio; Luis Gutierrez, D-Illinois.

 Republicans: Benjamin Gilman (ranking), R-New York; William
 Goodling, R-Pennsylvania; Jim Leach, R-Iowa; Olympia Snowe, R-Maine;
 Henry Hyde, R-Illinois; Christopher Smith, R-New Jersey; Dan Burton,
 R-Indiana; Elton Gallegly, R-California; Ileana  Ros-Lehtinen,
 R-Florida; David Levy, R-New York; Lincoln Diaz-Balart, R-Florida; Ed
 Royce, R-California.


 BOYCOTT CLIPPER DEVICES AND THE COMPANIES WHICH MAKE THEM.

 Don't buy anything with a Clipper Chip in it. Don't buy any product
 from a company that manufactures devices with Big Brother inside. It
 is likely that the government will ask you to use Clipper for
 communications with the IRS or when doing business with federal
 agencies. They cannot, as yet, require you to do so. Just say no.


 LEARN ABOUT ENCRYPTION AND EXPLAIN THE ISSUES TO YOUR UNWIRED FRIENDS

 The administration is banking on the likelihood that this stuff is
 too technically obscure to agitate anyone but nerds like us. Prove
 them wrong by patiently explaining what's going on to all the people
 you know who have never touched a computer and  glaze over at the
 mention of words like "cryptography."

 Maybe you glaze over yourself. Don't. It's not that hard. For some
 hands-on experience, download a copy of PGP - Pretty Good Privacy - a
 shareware encryption engine which uses the robust RSA encryption
 algorithm. And learn to use it.


 GET YOUR COMPANY TO THINK ABOUT EMBEDDING REAL CRYPTOGRAPHY IN ITS
 PRODUCTS

 If you work for a company that makes software, computer hardware, or
 any kind of communications device, work from within to get them to
 incorporate RSA or some other strong encryption scheme into their
 products. If they say that they are afraid to violate the export
 embargo, ask them to consider manufacturing such products overseas
 and importing them back into the United States. There appears to be
 no law against that. Yet.

 You might also lobby your company to join the Digital Privacy and
 Security Working Group, a coalition of companies and public interest
 groups - including IBM, Apple, Sun, Microsoft, and, interestingly,
 Clipper phone manufacturer AT&T - that is  working to get the embargo
 lifted.

 ENLIST!

 Self-serving as it sounds coming from me, you can do a lot to help by
 becoming a member of one of these organizations. In addition to
 giving you access to the latest information on this subject, every
 additional member strengthens our credibility  with Congress.

 > Join the Electronic Frontier Foundation by writing [e-mail].

 > Join Computer Professionals for Social Responsibility by e-mailing
 [e-mail]. CPSR is also organizing a protest, to which you can
 lend your support by sending e-mail to [e-mail] with
 "I oppose Clipper" in the message body. Ftp/gopher/WAIS to
 cpsr.org/cpsr/privacy/crypto/clipper for more info.


 In his LA speech, Gore called the development of the NII "a
 revolution." And it is a revolutionary war we are engaged in here.
 Clipper is a last ditch attempt by the United States, the last great
 power from the old Industrial Era, to establish imperial control over
 cyberspace. If they win, the most liberating development in the
 history of humankind could become, instead, the surveillance system
 which will monitor our grandchildren's morality. We can be better
 ancestors than that.

 San Francisco, California

 Wednesday, February 9, 1994

                                    * * *

 John Perry Barlow ([e-mail]) is co-founder and Vice-Chairman
 of the Electronic Frontier Foundation, a group which defends liberty,
 both in Cyberspace and the Physical World. He has three daughters.


 =-=-=-=-=-=-=-=-=-=-=-=WIRED Online Copyright Notice=-=-=-=-=-=-=-=-=-=-=-=

            Copyright 1993,4 Wired USA Ltd.  All rights reserved.

   This article may be redistributed provided that the article and this
   notice remain intact. This article may not under any circumstances
   be resold or redistributed for compensation of any kind without prior
   written permission from Wired Ventures, Ltd.

   If you have any questions about these terms, or would like information
   about licensing materials from WIRED Online, please contact us via
   telephone [phone]) or email ([e-mail]).

        WIRED and WIRED Online are trademarks of Wired Ventures, Ltd.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


[ Editor's Note:

This is some background information on how RSA's technology works.
This was provided by Kurt Stammberger, Technology Marketing Manager of
RSA Data Security, Inc.

RSA Technology - By Kurt Stammberger

Privacy protection by conventional means such as DES (the government-
sponsered Data Encryption Standard is relatively easy in small networks,
requiring the exchange of secret encryption keys with each party. But as
a network grows in size, using symmetric encryption techniques like DES
by themselves becomes impractical.

As the network grows, arranging for the secure exchange of all those
secret keys becomes expensive to administer.  Moreover, DES requires secret
sharing: each person must trust the other to not reveal (or lose) the key
they share.

|========================================================================|
Figure 1:: The Convention System: DES

  Alice encodes a document with a DES key ... Bob decodes the document
  with the same key.

  |---\                 |---\          |---\                |---\
  |    |  KEY (des) =>  | // |  ---->  | // |  KEY (des) => |    |
  |____|                |____|         |____|               |____|

Sharing secret keys in conventional systmes requires prior relationship
between the parties.  The classic "chicken and egg" problem with DES is
how to exchange a secret key over an unsecure network with someone you
don't necessarily trust.
|========================================================================|

This means that in partical implementations, secure communcations can
only take place between people with some kind of prior relationship,
e.g., only between employees of the same company.  Finally, shared
secret keys prevent either part from proving what the other may have
done with that key.  Either party could forge a document using the
shared key, and a third party would be unable to identify the culprit.

The 1976 theoretical work of Drs. Whitfield Diffie and Martin Hellman
of Standford University came to fruition in 1977 wwith their
development of the Diffie-Hellman Key Agreement technique, and the
invention of the RSA Public Key Cryptosystem by Drs. Ronald Rivest,
Adi Shamir and Len Aldleman, then professors at the Massachusetts
Institute of Technology (MIT).

RSA is, quite simple, a method of exchanging authenticated secret
messages without exchanging secrets.  Rather than using the same key
to both encrypt and decrypt the data, the RSA system uses a matched
pair of encryption and decryption keys.  Each key performs a one-way
transformation upon the data -- what one encrypts, only the other can
decrypt.

|========================================================================|
Figure 2:: The RSA Public Key Concept

  |---\                 |---\          |---\                 |---\
  |    |  KEY (PUB) =>  | // |  ---->  | // |  KEY (PRIV) => |    |
  |____|                |____|         |____|                |____|

Anything encrypted with someone's RSA public key can only be decrypted
with the corresponding RSA private key, and vice-versa.
|=========================================================================|

Since it is computationaly infeasible to derive one key from the
other, one of the keys can be made "Public" while the other key is
kept "Private", or secret.  To send someone a private message, one
simply encrypts the message using the intended recipient's public key,
confident in the fact that only the recipient's private key could
decrypt it.  This forms the basis for the RSA Digital Envelope (see
figure #3).  The RSA Digital Envelope providess an encrption solution
that gives the user the best of both worlds: the speed of secret key
algorithms like DES, combined with the security of RSA.  Conversely,
when a message is encrypted with a private key it provides the basis
for a "digital signature" -- a scrambled message that only one person
could produce, but everyone could verify with that person's public
key.  But handwritten signatures do more than just identify the author
of a document, they in effect must vouch for the document's integrity.
A manager's signature on a letter typed by a secretary says "I have
reviewed this page, and the information it contains is the information
that I do, in fact wish to send."  The RSA algorithm can accomplish
even this.

|========================================================================|
Figure 3:: Privacy : the RSA Digital Envelope

  |---\                 |---\
  |    |  KEY (DES) =>  | // |
  |____|                |____|


1. Alice encrpts the document with a random DES key.
               ________       ________
KEY (DES) =>  [__ PUB__|  => [__DES__|
                 |KEY|          |  |
                _|  |          _|//|
                |___|          |___|

2. Alice looks up Bob's RSA public key in her network
   directory, and uses it to encrypt the DES key.

 ***************
 *  |---\      *
 *  | // |     *
 *  |____|     *
 *             *
 *   ________  *   ---->
 *   [__DES__| *
 *     |  |    *
 *    _|//|    *
 *    |___|    *
 *             *
 ***************

 3. The encrypted document & key together form the RSA Digital
    Envelope.  Only Bob's RSA private key can open this envelope
    "addressed" to him.

|==========================================================================|

The RSA Digital Signature employs a cryptographic "hashing" algorithm
to create a message digest that is unique to each document, much like
a fingerprint.  If even a single bit of the document is changed,
roughly 50 percent of the bits in the corresponding message digest
will change.  Furthermore, the hashing alogrithm is a one-way
function:  the document content cannot be reconstruction from the bits
of the message digest.  With RSA's MD family of message digest
alorithms -- featuring 128-bit message digests -- the probability that
different documents will have the same digest by coincidence is less
than 1 in a trillion trillion, effectively ensuring that the two
message digests will only match if their source documents are
bit-for-bit identical.

While the RSA Digital Signature is easy to produce and check it is
impossible to forge, and therefore positively identifies the author.
And unlike a handwritten signature, it also verifies the contents of a
document.

|========================================================================|
Figure 4:: Authentication : the RSA Digital Signature

  |---\
  |    |  ============
  |____|             |            ********************
                     |            *                  *
    |                |========>   *     _______      *
    |                             *     |      \     *  ---->
   ###                            *     |       |    *
  #####                    ===>   *     |_______|    *
   ###                     |      *     |  //   |    *
    |        ________      |      *      --------    *
    |       [__PRIV__|     |      *                  *
    V          |KEY|       |      ********************
   [.:..:] =>  _|  |  => [ // ]
              |___|

 Alice passes her document through a hashing algorithm to produce the
 message digest, then encrypts the digest with her RSA private key
 (forming an RSA Digital Signature) and transmits the signed document
 to Bob.

               #
 |---\        ###
 |    |   === ### ==============>     [.:..:]  <-------|
 |____|       ###                                      |
               #                                    COMPARE
                                                       |
 [ // ]  ===> KEY (pub) ========>     [.:..:]  <--------


After receiving Alice's transmission, Bob uses the same hashing
algorithm to create another message digest, and also decrypts the
signature using Alice's RSA public key.  The resulting message digests
are then compared.
|===========================================================================|

Security

The RSA Public Key Cryptosystem is recognized worldwide as the most
secure cryptographic technique commercially available.  To understand
why RSA is so strong, you need to understand a little bit more about
the math behind RSA.  The RSA Algorithm is fully disclosed -- that is,
there are no secrets about how the system actually works.  RSA
security is derived solely from its unqiue mathematical characterics.

RSA public and private keys are actually each made up of two numbers
-- an exponent and a modulus.  The modulus is common to both public
and the private key, and is the product of two very large prime
numbers.  Since the public key is, of course, made public the best
course for a potential attacker to take is to attempt to factor the
modulus back into its component primes, thereby gaining the
information required to derive the private key.

But factoring is one of the most fundamentally difficult mathematical
tasks -- there are precious few "shortcuts."  For example, using the
best available techniques, factoring a single typical 200-digit RSA
modulus would keep a network of one thousand high-powered (70 MIPS)
workstations busy for over one thousand years.  Even a Cray YMP
supercomputer would take tens of thousands of years just to crack one
user's key.

Even with the availability of ever-increasing computing power, RSA
remains secure.  Because of the nature of the algorithm, advances in
computer speed actually favors security over factorization, since
larger keys can be used more efficiently than they can be factored.

The above article is Copyright (c) 1994 RSA Data Security Inc.
Permission is NOT granted for reproduction in any form other than this
issue of AEO-PJ.

RSA Data Security Inc.
100 Marine Parkway
Redwood City, CA 94065
USA
415-595-8782 (voice)
415-595-1873 (fax)

RSA Data Security was founded in 1982 and its technologies have since
grown to become defacto standards for data encryption and
authentication all over the world.  The corporation develops and
markets products for the development and end-use of encryption and
authentication technologies and provides comprehensive consulting,
licensing and research services in the cryptographic sciences field.

The RSA Public Key Cryptosystem, in its various forms has been
endorsed by the internet, the Pentagon and financial institutions
worldwide, and counts nearly every major computer hardware and
software corporation as among its many licencees.  The RSA Algorithm
(U.S. Patent #4,405,829) is widely recognized as the most secure
encryption and authentication method commercially available.
Licensees and strategic partners include Apple Computer, IBM,
Motorola, Sun Microsystems, Digital Equipment Corporation, Word
Perfect, Chemical Bank, Novell, Microsoft, General Electric, Lotus
Development Corporation, the National Aeronautics and Space
Administration, Merrill Lynch and the U.S. Department of Defense.

]

/***********************************************************************/
                 OBJECT::ATARI
              By: Warwick Allison
/***********************************************************************/

        Part 5 : C++ Basics for C Programmers.

1. Looking at C++
-----------------

We have looked at what Object Oriented programming is in a general
sense, so now is a good time to look specifically at C++ and what
makes it different from plain C.

C++ can be viewed in a number of ways.  One can look at is as a
completely new language, with a completely different programming
style, or one can see it as an extension of plain C to be slowly eased
into and explored.  Here, I will take this second view, for the
benefit of the great many C programmers in the Atari community.


2. C++ - a Better C.
--------------------

C++ can be considered a C with a "class" concept for Object
Orientation.  In fact, early versions of C++ were called "C with
classes".

A class is the same as a a "struct" in C with a couple of extensions.
They are:

    1. Not only can you have data fields (or data "members"),
         but also have FUNCTIONS as members.
    2. You can restrict the access that others can make to the members.
    3. Values can be automatically initialized and de-initialized.
    4. One can define the standard operators for the class.
    5. One can inherit functionality from other classes.
    6. One can override functions of inherited classes.

Let's ease into that list with an example that looks at the first two.


2.1 Member Functions


    1. Not only can you have data fields (or data "members"),
         but also have FUNCTIONS as members.
    2. You can restrict the access that others can make to the
         members.


In C, we might use a struct to store a pair of integers:

struct PairOfIntegers {
    int a;
    int b;
};

Then when declaring a variable of this type, we use:

    struct PairOfIntegers foo;

We can then make assignments to the fields:

    foo.a = 123;
    foo.b = 456;

And we can use the fields in expressions:

    return foo.a * foo.b;

In C++, we could model this with a class:

class PairOfIntegers {
public:
    int First()
    {
        return a;
    }

    int Second() { return b; } // Put it all on one line to save space.

    void SetFirst(int new_first) { a=new_first; }
    void SetSecond(int new_second) { b=new_second; }

private:
    int a;
    int b;
};

The keywords "public:" indicate that the members after it (which, in
our example are all member FUNCTIONS), are usable by anyone.

The keywords "private:" indicate that the members after it are only
accessible to member functions of this class.

When declaring a variable of this type, we use:

        PairOfIntegers foo;  // We don't need to say `struct' or `class'.

We can then change the values of the pair:

        foo.SetFirst(123);
        foo.SetSecond(456);

And we can use the values in expressions:

    return foo.First() * foo.Second();

Now, in C, we might often want to have some function that takes a
PairOfIntegers as a parameter, and returns some value.  For example:

int ProductOfPairOfIntegers(struct PairOfIntegers* pair)
{
    return pair.a * pair.b;
}

In C++, we would write a function like this as a MEMBER of the class
itself:

class PairOfIntegers {
public:
    int First() { return a; }
    int Second() { return b; }
    int Product() { return a * b; }

    void SetFirst(int new_first) { a=new_first; }
    void SetSecond(int new_second) { b=new_second; }

private:
    int a;
    int b;
};


We don't need to give it a long name like "ProductOfPairOfIntegers",
because it is a member function that only applies to PairOfIntegers.
It is used like this:

    bar = foo.Product();


THE PLOT THICKENS...

Now, what if we only occasionally changed the values of fields a and b,
but very frequently wanted to find the product?  Well, we could remember
the product, and update it whenever we changed the value of a or b.
In plain C:

struct PairOfIntegers {
    int a;
    int b;
    int a_times_b;
};

Now, we must rely on the user of this structure to change a_times_b
whenever they change a or b.  For example:

    struct PairOfIntegers foo;

    foo.a=123;
    foo.b=20;
    foo.a_times_b=foo.a*foo.b;

This is very error prone, and inefficient.  And what about all the
programs we wrote while PairOfIntegers just had a and b fields?  We
will have to go through them all and set a_times_b whenever a or b
changes.  In practice, people just put up with the inefficiency of
repeatedly calculating a*b.

But in C++, we don't need to change the usage of the class at all!

class PairOfIntegers {
public:
    int First() { return a; }
    int Second() { return b; }
    int Product() { return a_times_b; }

    void SetFirst(int new_first) { a=new_first; a_times_b=a*b; }
    void SetSecond(int new_second) { b=new_second; a_times_b=a*b; }

private:
    int a;
    int b;
    int a_times_b;
};

Voila!  Instantly we have a class that remembers the product and
updates it whenever a or b is changed.  And since we only have to
change this in one place, we can add further enhancements if we find
them helpful:

class PairOfIntegers {
public:
    int First() { return a; }
    int Second() { return b; }
    int Product() { return a_times_b; }

    void SetFirst(int new_first)
    {
        if (a!=new_first) {
            a=new_first;
            a_times_b=a*b;
        }
    }

    void SetSecond(int new_second)
    {
        if (b!=new_second) {
            b=new_second;
            a_times_b=a*b;
        }
    }

private:
    int a;
    int b;
    int a_times_b;
};
// NB: there is a problem with this implementation, described
// in the next section.  But it serves an example here.


Now this might not look like a very useful class.  But what if a and b
where X and Y co-ordinates, and you wanted to also provide polar
co-ordinates very regularly?  A class that allows this would make some
calculations MUCH faster.  I will not go into the details of that, as
anyone who understands operations on polar co-ordinates should be able
to see that advantage easily.  Polar co-ordinates are equivalent to
complex numbers.

So, the big advantage revealed here is that with C++, we can hide
certain information, and provide functions as members of a class to
access and modify that information in an orderly fashion.  Because we
can make certain guarantees about how the data is accessed, we can add
efficiency enhancements that would be too unreliable to consider in
plain C.


2.2 Constructors and Destructors

There is one problem with the final PairOfIntegers description above:

    What if the fields a, b, and a_times_b are initialized to some
    random values?

For example, say a starts as 123, b starts as 10, and a_times_b starts
as 1948726664.  Then suppose we do this:

    PairOfIntegers foo;

    foo.SetFirst(123);
    foo.SetSecond(10);

    printf("%d\n",foo.Product());

What will be printed?  Well, since coincidentally, both values we
assigned to a and b equaled what random chance managed to leave in
them, a_times_b never got set!

The problem is that we are not ensuring that our values start at some
known value.

Fortunately, and as listed at the beginning of section 2:

    3. Values can be automatically initialized and de-initialized.

Ah-hah!  Just what we need.  Here is the corrected class:

class PairOfIntegers {
public:
    // We have a `constructor' for the class, which tells
    // us how to make an object of this class given some
    // parameters (in this case, no parameters).
    //
    PairOfIntegers()
    {
        // We don't care what a and b are,
        // so long as a_times_b is right.
        a_times_b=a*b;

        // If we had a_divided_by_b, we would want to also ensure b!=0.
    }

    // While we are at it, let's add another constructor that
    // lets us create a PairOfIntegers from 2 integers:
    PairOfIntegers(int first, int second)
    {
        a=first;
        b=second;
        a_times_b=a*b;
    }

    int First() { return a; }
    int Second() { return b; }
    int Product() { return a_times_b; }

    void SetFirst(int new_first)
    {
        if (a!=new_first) {
            a=new_first;
            a_times_b=a*b;
        }
    }

    void SetSecond(int new_second)
    {
        if (b!=new_second) {
            b=new_second;
            a_times_b=a*b;
        }
    }

private:
    int a;
    int b;
    int a_times_b;
};


Note:  There is an alternative form for writing the constructors.
       In fact, it is the preferred form, called an `initialization list':

    PairOfIntegers() :
        a_times_b(a*b)
    {
    }

    PairOfIntegers(int first, int second) :
        a(first),
        b(second),
        a_times_b(a*b)
    {
    }

    Note that the objects are actually assigned in the order they
    appear in the declaration:

        ...
        int a;
        int b;
        int a_times_b;
    };

    not in the order they appear in the constructor initialization
    list.  But you should put them both in the same order to avoid
    confusion (and because GNU C++ gets this wrong in some versions).


Now, what about destructors?  Well, there isn't really much use for
one in the above example.  But let's just pretend that it is vitally
important to set all fields to 25 before exiting (just say we ant to
do that so that some snoop can't go through memory after our program
terminates and find our bank accounts by looking for a sequence three
of words where the third is the product of the first two).  To do
this, we simply add another member:

class PairOfIntegers {
public:
    ...

    // This is the destructor.  It never have parameters.
    ~PairOfIntegers()
    {
        a = b = a_times_b = 25;
    }

    ...
};


2.3 Operators

With the first PairOfIntegers example (let's ignore the "Product"
enhancement for now, if we want to add the fields of one pair to the
fields of another, we would do this is plain C:

{
    struct PairOfIntegers foo;
    struct PairOfIntegers bar;

    ...

    foo.a += bar.a;
    foo.b += bar.b;
}

Simple.  Now let's look at C++:

{
    PairOfIntegers foo;
    PairOfIntegers bar;

    ...

    foo.SetFirst(foo.First()+bar.First());
    foo.SetSecond(foo.Second()+bar.Second());
}

YUCK!  So verbose, just to add two pairs together.

Fortunately:

    4. One can define the standard operators for the class.

Continuing our example:

class PairOfIntegers {
public:
    ...

    // This member defines the operator "+=" that adds a pair
    // to this pair.  The word "operator" is a keyword.
    //
    void operator += (PairOfIntegers other_pair)
    {
        a+=other_pair.a;
        b+=other_pair.b;
    }

    ...
};

Then, all we need to write whenever we want to add pairs is:

{
    PairOfIntegers foo;
    PairOfIntegers bar;

    ...

    foo += bar;
}


HAH!  Even simpler than the plain C code.

You can define all sorts of operators - "+", "-", "==", etc. etc.  You
can even define the "()" operator, the "()" operator with any
parameters!  Very powerful.


2.4 Inheritance

In all the above sections, we described how we could add features to a
class to improve its usefulness.

But what if SOMEONE ELSE wrote the class, and we don't want to go
around hacking at their code.  Or what if we want multiple variations,
with different extensions?

Well,

    5. One can inherit functionality from other classes.

Cool.  So, just say we have the original very first PairOfIntegers
class:

class PairOfIntegers {
public:
    int First()
    {
        return a;
    }

    int Second() { return b; } // Put it all on one line to save space.

    void SetFirst(int new_first) { a=new_first; }
    void SetSecond(int new_second) { b=new_second; }

private:
    int a;
    int b;
};

Now, let's add Product to this, without hacking at the code.

To do so, we create a new class which INHERITS the PairOfIntegers class:


class ProductablePairOfIntegers : public PairOfIntegers {
public:
    int Product() { return First() * Second(); }
};

Voila.  The words ": public PairOfIntegers" say that this new class
inherits all the functionality (and data) of the PairOfIntegers class,
and that everyone using the class is allowed to use this fact (hence
the "public" keyword after the ":").


2.5 Overriding Inherited Functions

But how do we implement the optimization of having a_times_b set
whenever a or b changes?

Well, with the PairOfIntegers above, the best we can do is to keep the
fact that we inherit PairOfIntegers functionality a private secret,
then provide new versions of SetFirst and SetSecond that do the
appropriate checks, and possibly call the versions of SetFirst and
SetSecond in PairOfIntegers (the "base class" of our new class
FastProductablePairOfIntegers):

class FastProductablePairOfIntegers : private PairOfIntegers {
public:
    int Product() { return a_times_b; }

    int First()
    {
        // We just call the version of First
        // from our base class PairOfIntegers.
        // We use the `scope resolution operator', "::"
        // to specify that we want THAT version of
        // First, not the one found in this class,
        // which would cause infinite recursion!
        //
        // This is sometimes called `re-exporting' functions.
        //
        return PairOfIntegers::First();
    }

    int Second() { return PairOfIntegers::Second(); }

    void SetFirst(int new_first)
    {
        if (new_first != First()) {
            PairOfIntegers::SetFirst(new_first);
            a_times_b=First()*Second();
        }
    }

    void SetSecond(int new_second) ... and so on.

private:
    int a_times_b;
};

This does the job, but didn't we say:

    6. One can override functions of inherited classes.

???

Yes, we can.  BUT, only if the original class (the "base class") has
allowed us to do so in advance.  This means the designer of the base
class has to think ahead a little bit about what some inheritor of the
class ("derived classes") might want to override.

Once the designer decides, all they have to do is add "virtual" to the
function description.  Let's change PairOfIntegers to allow SetFirst
and SetSecond to be overridden:


class PairOfIntegers {
public:
    int First() { return a; }
    int Second() { return b; }

    virtual void SetFirst(int new_first) { a=new_first; }
    virtual void SetSecond(int new_second) { b=new_second; }

private:
    int a;
    int b;
};


Simple.  Now, how do we override?  Well, we just DO IT:

class FastProductablePairOfIntegers : public PairOfIntegers {
public:
    int Product() { return a_times_b; }

    virtual void SetFirst(int new_first)
    {
        if (new_first != First()) {
            PairOfIntegers::SetFirst(new_first);
            a_times_b=First()*Second();
        }
    }

    virtual void SetSecond(int new_second) ... etc.

private:
    int a_times_b;
};


Done.


3. Wrap up.

We quickly dived into the differences between a plain C "struct" and
a C++ "class".  But at least we have seen all those nice features of
a class, and we have seen clues as to how we can use the feature to
not only make our programs safer and easier to improve, but also how
these features can make for faster, more efficient programs.

What you do with these features is limited only to your limitless
imagination.


-- Warwick

/************************************************************************/
                 Parsing the human equation
                      by Ron Whittam
/************************************************************************/

Phone support for a product could be your most critical function to
maintain continued product sales.  This month I would like to jump
into this subject.  Primarily, how can a one-man shop handle its
customer base efficiently?

While an often used support-link is the commercial information
services like GEnie and Compuserve, not every customer of your product
will have access to such services.  However, the populariy of the
Internet being broadcast in public media is making electronic support
a closer reality then ever before.  Electronic support can be very
advantageous to a one-man shop.  Be this media a FAX, voice mail, or
computerized information services; it will allow you to handle many
problems and product requests in an efficient manner.

But, phone support is still a vital need in our world today.  It is so
important to some companies that they are sub-contracting customer
support companies to do this support full-time for them.  While the
professional support company handles problems, the developer can
continue to work on new products without interuptions.  Not so easy on
a one-man shop operation.

OK.  Let's say you have implemented the common support media.  You
have a FAX.  You have an address on a commercial information service.
You have a message base on a local BBS.  You have a phone.  Your phone
is augmented with an answering machine (voice mail).  There is still
no substitute for person to person communication when people need
help.

While some might believe a discussion on good phone support would
entail a lengthy dialog on phone etiquette, I choose a different path.
While phone etiquette is important to any business dealing, the tools
to be efficient are more so.  It would do very little good to have a
terrific phone personality and only speak gibberish.  This discussion
will focus on the tools you may use to increase effective customer
support while talking on the phone.

I believe a the real key to good support is good information that is
readily accessable.  Easily accessable information will reduce your
time on a phone call.  You should keep a file drawer near your phone
and a notebook near your phone.  Both of these will provide you with
hard copy information "nearly" at your fingertips.  Yet I have found
that the best method for supporting computer products is to use the
power of the computer.  While many database type products exist, I
would like to draw your attention to a simple flatfile database
method.

The flatfile method does not require the purchase of additional
software.  It uses a simple text editor and a simple utility.  The
flatfile is a text file you create and update on your computer.

 CREATE A TEXT FILE

Use a word processor or text editor to create a new file.  If you are
using a word processor (that doesn't have a search feature) be sure
you can save the file as ASCII text.  For our purposes, we will call
the file FLATFILE.DB and use this distiction throughout this
discussion.  Setup a "template record" such as this:

 [top of file]
 -----------------------------------------------------------------
 PROBLEM or BUG:

 SOLUTION or FIX:

 COMMENTS:
 ------------------------------------------------------------------
 [end of file]

Save this file as FLATFILE.DB.  This file is now seven (7) lines long.
To add data to this file, retreave it and then copy lines 1-6 below
line 7.  Then fill in the information.  Continue to make copies of the
first six lines and fill in the appropriate information.  Save the
file.

Or an alternate template might be:

 [top of file]
 ------------------------------------------------------------------
 CUSTOMER:
 CONTACT:
 ADDRESS:
 CITY:                     STATE:     ZIP:
 PHONE #1:
 PHONE #2:
 FAX NUMBER:

 PRODUCT:                         PURCHASE DATE:

 CONTACT HISTORY:

 ------------------------------------------------------------------
 [end of file]

Save this file as FLATFILE.DB.  This file is now fourteen (14) lines
long.  To add data to this file, retreave it and then copy lines 1-13
below line 14.  Then fill in the information.  Continue to make copies
of the first thirteen lines and fill in the appropriate information.
Save the file.

 UPDATE THE TEXT FILE

Now you have FLATFILE.DB on your disk with important information.  To
update this file, retreave it into your text editor and continue to
add information.

 USING "GREP" TO SEARCH FOR INFORMATION

A utility common to the UNIX crowd (and now ported to most every
computer platform) is a program called GREP.  The program will search
a file for string of text.  When found, it will display the line
number and the text of the line in which the match was found.  Once
the line number is identified you may use your text editor to display
that section of the file.

 USING A WORD PROCESSOR TO DO THE SEARCH

Many word processors have a FIND or SEARCH feature.  If this is your
case then you can forego the ASCII save and the use of GREP.  You can
exploit these FIND and SEARCH features to do the task just as well or
better.  ProTEXT has a very powerful FIND option in the TEXT menu.  So
do other word processors.  You can search for a word or a string of
words.  You may select an option to have the match case sensitive or
not.  You may search forward or backwards in the file.

 JUST DO IT

Implementing this search and display on the phone is a rather simple
procedure.   When you get a phone call, GREP the customer file with
their company or contact name.  Then retrieve the file, find that
record.  Now you have all the necessary and pertantant information on
that person on your screen.  You can talk personally and intellegently
with your customer.  If they report a problem, indicate that on their
customer record for cross reference, and save the file.  Now you can
GREP the problem file.  Retreve the file and go to the record that is
indicated by the result of the GREP.   If you cannot locate a similar
problem, create a new entry.

While a simple database or a relational database would do this for
you, this is definately a quick and dirty method.  SuperBase, Tracker
ST, dBMAN, and others are fine database programs available for the
Atari ST.  These products will require some programming and setup to
work as efficently as the flatfile.  If you have a large shop the
database programs would be a must.

Most importantly: Have information about your products, your
customers, and problems readily available near the phone.  You will
sound more professional and you will service your customers better.
That's it for this month.

If you have any suggestions please EMail me a message on the Internet.


                        ----===[O-O-0]===----

Ron Whittam is a Software Support Specialist for a small software firm
in Boise, Idaho; and the President of the Atari Boise Users Group.  He
can be contacted on GEnie or through the Internet at
[e-mail] and on the ROVER BBS [phone].


/***********************************************************************/
     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  |     Sep 4, 1992  | Pure Pascal (German) (Turbo pascal 7.x compatible)
A  | 1.0 Oct 3, 1993  | Pure Profiler (German)
A  | 2.x              | Interface, (resource file editor, with 3D icons)
B  | 3.10             | Devpac 3 (assembler)
B  | 1.0              | Devpak DSP (for 56K digital signal processor)
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.115, 1992      | Prospero C
G  | 2.165, 1992      | Prospero Pascal for GEM
G  | 2.165, 1992      | Prospero Fortran for GEM
G  | 1.12, 1992       | 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--An Assembly Programmer's Nightmare (and pet peeve)
                      By Damien M. Jones
/**********************************************************************/

I learned assembly programming mostly by looking at other people's
programs, and then writing my own.  So I've seen lots of assembly
programs, and I've developed a number of pet peeves about source
code.  The following examples will illustrate both some problems and
some solutions.

-- BAD EXAMPLE --

*    Rectangle intersection.

is_rec    movem.l 4(a7),a0-a1
    move.l (a0),d0        ; xywh -> xyxy
    add.w d0,6(a0)
    swap d0
    add.w d0,4(a0)
    move.l (a1),d0
    add.w d0,6(a1)
    swap d0
    add.w d0,4(a1)

    move.w (a0)+,d0        ; compute intersection
    cmp.w (a1),d0
    blt.s .1
    move.w d0,(a1)
.1    move.w (a0)+,d0
    cmp.w 2(a1),d0
    blt.s .2
    move.w d0,2(a1)
.2    move.w (a0)+,d0
    cmp.w 4(a1),d0
    bgt.s .3
    move.w d0,4(a1)
.3    move.w (a0),d0
    cmp.w 6(a1),d0
    bgt.s .4
    move.w d0,6(a1)

.4    subq.w #6,a0        ; xyxy -> xywh
    move.l (a0),d0
    sub.w d0,6(a0)
    swap d0
    sub.w d0,4(a0)
    move.l (a1),d0
    sub.w d0,6(a1)
    swap d0
    sub.w d0,4(a1)

    ble.s .5        ; check overlap
    tst.w 6(a1)
    ble.s .5
    moveq #-1,d0
    rts
.5    moveq #0,d0
    rts

In the above example, it's almost impossible to figure out what's
going on.  Even if you know what the routine does - and the title only
hints at it - it can still be very difficult to see what it's doing,
and why.  Here is the same routine, reformatted and extensively
commented.

-- GOOD EXAMPLE --

*    Compute the intersection of two rectangles.
*    The rectangles are xywh, as the AES uses.  d0.l will contain
*    TRUE (-1) or FALSE (0), indicating whether the rectangles overlap.
*    The coordinates of the overlap (or the space between the rectangles,
*    if no overlap) will be written to the second rectangle.  If there
*    is no overlap, the width and/or height of the "between" rectangle
*    will be negative or zero.
*
*    Since d0 is the last item set by this routine, you can branch
*    immediately following the routine--no tst instruction is needed.

*    On the stack:
*    8(a7)    Address of second rectangle (will be changed).
*    4(a7)    Address of first rectangle.

*    d0-d2 and a0-a2 should be considered trashed by this routine.
*    The calling routine is responsible for fixing up the stack.
*    This is standard C calling protocol.

intersect_rectangles
    movem.l 4(a7),a0-a1   ; Get address for rectangles.

*    Convert xywh to xyxy.

    move.l (a0),d0        ; Get X and Y of first rectangle.
    add.w d0,6(a0)        ; Add Y to H to get Y2.
    swap d0               ; Get X.
    add.w d0,4(a0)        ; Add X to W to get X2.

    move.l (a1),d0        ; Get X and Y of second rectangle.
    add.w d0,6(a1)        ; Add Y to H to get Y2.
    swap d0               ; Get X.
    add.w d0,4(a1)        ; Add X to W to get X2.

*    Now compute the coordinates of the intersected rectangle.

    move.w (a0)+,d0       ; Get A(X1).
    cmp.w (a1),d0         ; Is A(X1) > B(X1)?
    blt.s .do_y1          ; No, B(X1) is bigger; use it.
    move.w d0,(a1)        ; Else use A(X1).

.do_y1    move.w (a0)+,d0 ; Get A(Y1).
    cmp.w 2(a1),d0        ; Is A(Y1) > B(Y1)?
    blt.s .do_x2          ; No, B(Y1) is bigger; use it.
    move.w d0,2(a1)       ; Else use A(Y1).

.do_x2    move.w (a0)+,d0 ; Get A(X2).
    cmp.w 4(a1),d0        ; Is A(X2) < B(X2)?
    bgt.s .do_y2          ; No, B(X2) is smaller; use it.
    move.w d0,4(a1)       ; Else use A(X2).

.do_y2    move.w (a0),d0  ; Get A(Y2).
    cmp.w 6(a1),d0        ; Is A(Y2) < B(Y2)?
    bgt.s .convert_xywh   ; No, B(Y2) is smaller; use it.
    move.w d0,6(a1)       ; Else use A(Y2).

*    Now convert the xyxy rectangles back to xywh.

.convert_xywh
    subq.w #6,a0          ; Move this back to start of rectangle.

    move.l (a0),d0        ; Get X1 and Y1 of first rectangle.
    sub.w d0,6(a0)        ; Subtract Y1 from Y2 to get H.
    swap d0               ; Get X1.
    sub.w d0,4(a0)        ; Subtract X1 from X2 to get W.

    move.l (a1),d0        ; Get X1 and Y1 of second rectangle.
    sub.w d0,6(a1)        ; Subtract Y1 from Y2 to get H.
    swap d0               ; Get X1.
    sub.w d0,4(a1)        ; Subtract X1 from X2 to get W.

*    Now see if the rectangles overlapped.

    ble.s .no_overlap     ; W is <= 0 (from above), means no overlap.
    tst.w 6(a1)           ; Is H <= 0?
    ble.s .no_overlap     ; Yes, no overlap.

    moveq #-1,d0          ; Else they do overlap.
    rts                   ; We're done.

.no_overlap
    moveq #0,d0           ; Rectangles do not overlap.
    rts                   ; We're done.

There are a few important differences I'd like to point out here,
along with a few style guidelines for assembly language.  The first is
that the bad example had a grand total of five comments for a 46-line
subroutine.  Assembly is difficult enough to program, even with
comments.  There are also only three blank lines separating the
routine.

In the good example, I expanded the routine header to explain what the
function does, and how the parameters are passed to it.  I also listed
how values are returned from it, and a tip for using return values
from the function.  Then I list which registers are destroyed.  Note
that while the routine does not actually destroy all the registers
listed, I listed the standard set of destroyed registers for C
functions; this lets me change the routine later, perhaps utilizing an
extra register or two, without having to rewrite the code that calls
it.

Then I took each of the small comments and put them on separate lines,
expanding them in the process.  This helps give an overview of the
important sections of the routine.  Writing comments as complete
sentences also increases the readability of the program, since this is
how we normally communicate and expect information to be presented.

The next step was to take the long blocks of code and break them up.
In general, each small block should contain only one "step".  This may
be a short concept (doing a simple operation on one set of data) or a
bit more complex (an if-then sort of step), but as a general rule it
should be no more than six or eight steps (four is ideal).  Any time
you start doing something different, or do it with a different piece
of data, is an excellent time to place a blank line in your code.

I then replaced the labels with more explicit, meaningful ones.  .5
doesn't tell me much, but .no_overlap does.  Good labels, especially
for routine names, are important.  If you came across a "bsr is_rec"
line in a program somewhere, you might wonder if it meant, "find out
if the passed data is a rectangle", or who knows what else.  If you
came across "bsr intersect_rectangles", though, you could be
reasonably certain the routine had something to do with intersecting
rectangles.  Don't be afraid of long names.

The final step was to add a comment to each line.  This is critical,
and often the most left-out step of writing assembly code.  If you
think I am exaggerating, take a look at the bad example again.  Sure,
you could figure out exactly what was going on, given time.  Now
imagine that you have FIFTY pages of assembly code, all just like that
bad example.  Things start to look a little grim, don't they?  Comment
every line.  You may know what your program does, now, but two weeks
from now, when you discover there's a bug in your program, you will
appreciate those comments.  If you do something differently than you
do it elsewhere, and there's a reason for it, spell out the reason;
you'll be saving yourself some head-scratching later as you wonder,
"Why did I do it that way...?"

This may seem very silly.  When I was getting started writing
programs, I didn't use very many comments.  I figured I knew what I
was doing (and back then, REM statements in BASIC were all that I
had), so why bother adding comments?  It seemed so silly.  I have
learned the hard way, as many must, that comments are not necessarily
for the here and now.  They are for the tomorrow, the next week, the
next year.  You can't remember everything.  Most languages, including
assembly, include the capability to comment every line of your
program.  Don't waste the opportunity.

A comment on the comments is appropriate here.  You will notice that
in many places in the good example, similar operations are performed
on different pieces of data.  You will also notice that, in these
cases, the comments are also very similar.  This is intentional, and
invaluable.  In general, you will be able to spot meaningful patterns
in the comments faster than you will be able to spot patterns in the
actual program, because the program statements are all very similar
anyway.  Use this to your advantage.

As a final note, many experienced assembly programmers will note that
my style of assembly is slightly non-traditional.  As an example,
here's the "traditional" style:

    move.l   (a0),d0     ; Get X and Y of first rectangle.
    add.w    d0,6(a0)    ; Add Y to H to get Y2.
    swap     d0          ; Get X1.
    add.w    d0,4(a0)    ; Add X to W to get X2.

Notice the tab between the instruction (add.w) and the operands
(d0,6(a0))?  I use a space, instead of a tab:

    move.l (a0),d0       ; Get X and Y of first rectangle.
    add.w d0,6(a0)       ; Add Y to H to get Y2.
    swap d0              ; Get X1.
    add.w d0,4(a0)       ; Add X to W to get X2.

I do this for two reasons.  Mostly it's because the more traditional
approach splits the instructions into two separate columns,
instructions and operands.  The effect of this is to bind the
operands more tightly to each other, instead of to the instructions.
In my approach, the instructions and their operands appear to be much
closer related.  In truth, your assembly won't care which you
use - but you might.

/*************************************************************************/
                 Legal Forum : Intellectual Property
                   by Fred Wilf and Gerry Elman
/*************************************************************************/

       HOW TO WORK WITH YOUR INTELLECTUAL PROPERTY ATTORNEY:
                 Steps in Obtaining Patents and
              Registering Trademarks and Copyrights

               Copyright (c) 1994 Elman Wilf & Fried.
                      All rights reserved.

In general, intellectual property is secured by various legal tools
including patents, trademarks and copyrights. This summary will
provide background information about these forms of intellectual
property and the process by which your rights in intellectual property
may be secured. It discusses various procedures, which will generally
involve assistance by a patent practitioner (who may be a patent
attorney or patent agent) or an attorney.

This summary is current as of January 1, 1994, but is likely to become
outdated as a result of changes in United States and international
statutes, regulations, fees and procedures.  It provides only general
information and should not be considered a substitute for legal
advice.  If you have specific questions about the law or how the law
affects you, then you should retain an attorney for legal
consultation.

                             Patents

     A United States patent gives the owner the right to exclude
others from making, using or selling in the United States the
invention, which is defined by a series of descriptive "claims." A
patent is available for an invention that is found to be (1) novel,
(2) useful, and (3) not obvious to someone of ordinary skill in the
relevant technology who is fully familiar with the "prior art."  The
prior art includes, for example, patents and publications worldwide,
as well as public uses and products on sale in the United States.
Another form of patent protection, called a "design patent," protects
ornamental features and the shape of a useful article, such as a
keyboard or a piece of laboratory apparatus.

     A patent application in the United States must contain a
disclosure of the invention - in the form of a description and any
drawings that may be appropriate - that is complete enough to enable
someone having ordinary skill in the field to make and use the
invention.  In addition, the application must disclose the best mode
of carrying out the invention that is known to the inventor at the
time the application is filed.

     Relevant technology may be located by searching in the files of
the Patent and Trademark Office or by a computer database or library
search.  A patent practitioner generally studies the results of such a
search and provides you with an opinion on the patentability of your
invention in light of the search results.  If you are interested in a
search to determine whether your proposed product might infringe
someone else's patent claims, then the depth of the search, and hence
the cost, would be greater, although the focus would be on only
unexpired patents.

     After receiving a discussion of the prior art, you may ask your
patent practitioner to prepare a patent application.  If so, you might
need to provide the practitioner with additional information to
complete the disclosure of your invention. You would expect the
practitioner to prepare the application and accompanying formal papers
and any drawings.  There may also be a document to assign ownership of
the patent application to your company or another company.

     Further prosecution of the patent application may be simple or
complex.  Your patent practitioner will prepare and file an
Information Disclosure Statement to present certain information of
which you have become aware, such as the results of searching.  There
is an absolute requirement of full disclosure of all known prior art
and prior public uses and offers for sale of the invention, whether by
yourself or others.  Failure to comply with this requirement would
jeopardize the validity of any patent which might issue and might
possibly subject you to pay damages in litigation with a potential
competitor.

     Further prosecution over ensuing months will likely include
amendment of the claims and argument in response to an Office Action
from the Patent Examiner and interviewing the Examiner.  In addition,
it is possible that such prosecution might include the preparation of
affidavits to overcome objections and rejetions by the Examiner,
petitions and appeals to higher authorities within the Patent and
Trademark Office and to a court, and the preparation of divisional,
continuation and continuation-in-part applications.

     The application (or the issued patent) may also become a party to
an interference proceeding to determine which of various claimants can
prove priority of invention.  "Priority of invention" is a legal
principle which does not depend only on the date the invention is
conceived.  It also requires proof of "diligence," continuous effort
to reduce the invention to practice - either actually, by carrying out
an actual demonstration of a complete prototype of the claimed
invention, or constructively, by filing a patent application.  Thus,
delays in responding to communications regarding a proposed U.S.
patent application should be kept to a minimum.

     Various government fees may also be payable during prosecution
and will be payable upon issuance of the patent, as well as to
maintain it in force at various points during its lifetime.  If the
application is not owned by, or licensed to, a business having 500 or
more employees, it will qualify for the 50% discount in government
fees available to "small entities." If so, your patent practitioner
should prepare and file a verified statement of your status as a
"small entity."

     You will need to make a decision regarding the strategy for
filing any foreign counterparts under the Patent Cooperation Treaty or
otherwise.  These patents would hopefully provide similar rights in
various foreign countries you may select.  In order to obtain the
benefit of the filing date of your United States application in the
countries that are members of the Paris Convention on patents, it is
required that such foreign counterparts be filed within twelve months
from the filing date of the United States application.  Beware that
although the United States permits inventors up to one year from their
own public disclosure or placing the invention on sale before their
U.S. patent application is time-barred by their own actions, most
foreign countries do not provide such a "grace period."  The best
strategy to preserve your rights is to file a U.S. patent application
BEFORE making a non-confidential disclosure of the invention to
anyone.  Moreover, certain foreign countries, notably Taiwan and
India, have not ratified the Paris Convention.

They do not grant priority rights on the basis of a United States
patent application.  Tell your patent practitioner immediately if you
are interested in protecting your rights in these countries or any
others that are of particular importance to you.

     Patent practitioners are also frequently asked to advise whether
a proposed product comes within the claims of a particular patent of a
competitor or other identified party.  In that event they would first
determine the scope of the claims by obtaining and reviewing a copy of
the prosecution history of the patent.  If the proposed product is not
clearly outside the scope of the issued claims, they would next seek
to determine if any of the claims might be invalid (e.g., because of
additional prior art not brought to the Patent Examiner's attention).
In the event that they are able to provide an opinion that the
proposed product does not infringe any valid claims of the patent,
then it would benefit your company because generally a court would
decline to award additional damages for "willful infringement," even
if the court were to disagree with your patent practitioners and find
that the patent is infringed.

                           Copyrights

       An attorney can help by advising you about United States and
international copyright protection, reviewing documents, prosecuting
copyright applications, and litigating copyright infringement suits.

     As soon as a work of authorship is fixed in a tangible medium of
expression (e.g., written on paper or saved on a computer disk) it is
protected by the U.S. Copyright Act.  The protection is automatic and
does not require that you take any further action. However, you should
consider taking two steps (which are optional for new works) to gain
additional protection.  These two steps are (1) place your copyright
notice on your work, and (2) register your copyright with the U.S.
Copyright Office.

     Your copyright notice should look like this:

Copyright * [Year of first publication] [Name of copyright owner].
All rights reserved.

where the * stands here in for the encircled-C symbol  (which is not
part of the ASCII character set).  It is advisable to use the
"encircled-C" symbol instead of "(c)" or "(C)".  If you can't use that
symbol, then include the word "Copyright" or the abbreviation "Copr."
If your work is not published (i.e., offered for distribution to the
general public), then leave out the year of first publication.
Although a copyright notice is not absolutely required for any work
first published on or after March 1, 1989, it is strongly recommended
to use copyright notices on all of your works.

     The second step is to register your copyrights.  You don't need
to register your copyright, but the law provides additional benefits
to those who do.  Moreover, you may not sue an infringer in court
unless and until you have received a certificate of copyright
registration for your work.  The U.S. filing fee is $20.00 per
application.  The registration process takes approximately four months
between the filing of the application and your receipt of the
certificate of registration.  You may speed up the registration
process (e.g., if you immediately need to sue an infringer) by paying
an additional $200.00 government filing fee per application.

     Your applications for copyright registration should be filed as
soon as possible after your work is created and before you distribute
your work.  Your cost of registering your works is lower when you are
not in a hurry to sue an infringer.  Further, if you file an
application for copyright registration before someone infringes your
work, or within three months of the date your work is first published
(if your work is published), then you receive two additional benefits
that you would not otherwise have.

     The first additional benefit is that the federal court may award
you your attorney's fees.  The second additional benefit is that you
may request the court to award "statutory" damages instead of any
actual damages that you have suffered.  Statutory damages are
preferred when you cannot prove that you actually lost money, or when
you have lost a rather small amount of money.  The judge may then
award statutory damages somewhere between $500.00 and $20,000.00 per
work.  If you can prove the infringer intentionally infringed your
copyright, then the judge may award you up to $100,000.00 of statutory
damages per work.

     It is recommended to file applications for copyright registration
before or at least soon after publishing anything that is valuable to
you.  Once the certificate of copyright registration issues, you do
not need to do anything further to secure your copyright rights in the
United States.

     It is important to understand that if the work of authorship is
created by an independent contractor, the client does not
automatically own the copyright.  An attorney should be consulted to
assist in making sure that agreements with independent contractors
fully protect the client if it wishes to own the copyright outright.

                           Trademarks

     Attorneys use the term "trademark" to refer to any design, word,
or combination of words and designs, used in connection with the
products or services of a business.  Technically, the term "service
mark" is used for designations of services, but a service mark is just
one type of trademark.

     As soon as you start using your trademark, you should use the
symbol "TM" to designate a trademark for goods and the symbol "SM" to
designate a service mark for services.  Thus, you may generally place
a tiny "TM" in or adjacent to each trademark for goods and a tiny "SM"
next to each service mark.

     If you desire to protect a trademark, it is common to first do a
search to find out if the marks you like are available.  One may start
by checking on-line databases of federal trademark applications and
registrations, plus state trademark registrations.  These databases
are organized for searching alphabetically for "direct hits," and also
by phonetic sound-alikes, and for suffixes and prefixes.  Your
attorney would use the search results to initially evaluate whether
your proposed trademarks are "confusingly similar" to the trademarks
of your competitors.

     If your marks come up reasonably clear from the initial search,
one may then check other databases and look for similar marks used by
companies that haven't yet registered their marks.  These companies
may develop "common law" rights in their trademarks by using their
trademarks.

     In addition to searching your proposed trademarks, your attorney
can advise you how to use the trademark in connection with your goods
(e.g., on labels and on the product) and with your services (e.g., in
marketing materials, brochures and advertisements).

     The U.S. trademark law was amended in 1989 to allow you to file
an application based on your bona fide ("good faith") intent to use
your trademark.  You may file an "intent to use" application even
before you place your trademark on your goods.  By comparison, you may
only file a "use" application after you have used your trademark in
interstate commerce, such as by shipping your goods to a customer in
another state or by advertising your services in another state.

     Your attorney can prepare for you a federal "use" or "intent to
use" trademark application and file it with the U.S. Patent and
Trademark Office.  The government charges a filing fee of $245.00 per
class of goods or services.  If your trademark consists of a logo,
design or stylized lettering, then your attorney would need to obtain
a black-and-white drawing of the design in the stylized form required
for federal trademark applications.

     Upon filing of your application for trademark registration, an
examining attorney in the U.S. Patent and Trademark Office ("PTO")
searches registered marks and pending federal applications for any
that may be confusingly similar to your trademark.  The PTO attorney
also examines the application for compliance with various technical
and legal standards.  The PTO attorney is likely to object to one or
more aspects of your application.  Your lawyer would generally
communicate by phone and in writing to respond to the PTO attorney.

     When and if the PTO attorney finds no further barriers to
granting your application, the PTO will publish your mark in the
Official Gazette of the Patent and Trademark Office.  Then, for a
month or so, others who may have adopted a similar mark will have the
opportunity to challenge your right to register your mark.  If your
mark is challenged, then the PTO conducts a proceeding to determine
the matter.  If there is no challenge, your application proceeds to
the next stage.

     If your application is an "actual use" application, then the PTO
registers the trademark and issues a certificate of registration to
you.

     If your application is an "intent to use" application, then the
PTO will not register your trademark until you file a sworn statement
that your mark has actually gone into bona fide use in interstate
commerce.  The filing fee for this statement is $100.00.

     Once the PTO grants to you a registration and sends you a
certificate of registration (but no sooner), you may then use the
encircled-R symbol in connection with your mark, or alternatively the
term "Reg. U.S. Pat. and T.M. Off." (which is more cumbersome). Until
you receive a certificate of trademark registration, you may use the
"TM" and "SM" symbols.

     This completes the registration process.  Once the PTO issues a
registration, you generally won't be involved with the PTO for another
five years.  Between the fifth and sixth anniversaries of the
registration date, you would need to file an affidavit that you are
still using the trademark in connection with the same goods and
services.  If the "affidavit of use" is not filed during that time,
the registration is canceled (although you could seek to re-register
your trademark).  The PTO filing fee for the affidavit of use is
$100.00 per class of goods and services.

     Further, if your trademark had not been found invalid or was not
in litigation at the time that you file the affidavit of use - or at
the end of any five-year period -  you could file an "affidavit of
incontestability."  The affidavit of incontestability may be filed by
itself or as part of the same document as the affidavit of use.  An
affidavit of incontestability provides additional rights in case you
need to sue a trademark infringer; the infringer would have a higher
standard to overcome to battle you in court as the validity of your
trademark would be "incontestable." (However, certain things about the
trademark may nevertheless be subject to challenge.) The PTO filing
fee for the affidavit of incontestability is $100.00 per class of
goods and services.

     A U.S. trademark registration is valid for ten years.  A renewal
of the registration must be filed anywhere between six months before
the anniversary to three months after the anniversary.  If you file
the renewal application too early or too late, the PTO will ignore it.
Unless the renewal application is filed within the window of
opportunity, the PTO will cancel your registration (although you could
seek to re-register your trademark).

     Your attorney can also help you register your trademarks in other
countries.

                          Other Matters

     Your attorney can also help you protect your intellectual
property in other ways, such as design patents and mask work
registrations.


Gerry J. Elman, J.D.
  CompuServe 72245,556

Frederic M. Wilf, J.D.
  CompuServe 72300,2061

Elman Wilf & Fried
20 West Third Street
Media, PA  19063-2824

Phone: [phone]
Fax: [phone]

[ Editor's Note:

The above article is Copyright (c) 1994 Elman Wilf & Fried.
Permission is NOT granted for reproduction in any form other than this
issue of AEO-PJ.

Services provided by Elman Wilf & Fried encompass all of the following:

 Protecting intellectual property, Patents, Copyrights, Trade secrets,
 Trademarks, Unfair competition, Negotiating and drafting contracts,
 Licenses and joint research projects, Ownership of inventions by
 employees and independent contractors, Litigating technology and
 business disputes, Assisting purchasers and sellers of computer
 hardware and software, Incorporate and obtaining financing for start-up
 ventures, Obtaining regulatory approval of technological developments.

Gerry Elman is also a Sysop in the Innovator's forum on CompuServe.

This Forum is intended to act as a conduit for inventor's,
innovator's and those involved in technology transfer world-wide,
management people in large or small companies, venture capital firms,
investment bankers, new product managers, patent and trademark lawyers
or housewives. The purpose of the forum is networking, support and
development of new products or improving esisting ones. You will find
both experienced inventors and 'wannabees' here.

]

/*************************************************************************/
    Editor's choice for 1993 - Software Development tools
/*************************************************************************/

The questions are:

a) Top 10 Development tools
b) Best books and periodicals
c) Best IDE (Integrated Development Environment)
d) Why number one (in your top 10 list) is number one.

//// Warwick Allison

 1. GNU C++        I can't live without it.
 2. GNU Make       I'd go crazy without it.
 3. GNU BASH       Anything less unix-like is a pain.
 4. Elvis          Anything less vi-like is a pain.
 5. MiNT           Makes life easier...
 6. TOSWIN_W       ... especially with this!
 7. ORCS           I just wish I could find Theodore Otto!
 8. grep, etc.     It's not complete without this gang.
 9. Drawing prg.   Any will do.  I used to like CrackArt, but STlow is too low.
 10. GNU C         Just so I don't have to convert all of NetHack to C++.

Other:

 1. GEM++          I love it.
 2. GEM++          But then again,
 3. GEM++          I guess I'm biased.

Seriously, I think that each programmer also has a favourite C (or C++)
library which they just couldn't live without.

//// Carl Barron

a) 1. my C compiler system (LATTICE) Without a good C compiler I
      would be lost.
   2. Flex 2.3.7
   3. Berkeley yacc
   4. gawk
   5. sed
   6. tavlr - threaded avl tree library - free
   7. regexp - Free regular expression library
   8. Hisoft Basic - good for porting 'foriegn' basic code.
   9. Hispeed pascal - ok but needs work, that does not appear to be
      forth coming.  Essentially a turbo pascal compiler.
   10. Devpac - good for stand alone assembler progs. I don't write
       too many.... Wow, I could find 10 <grin>

b). books purchased in 1993.

   1. Writing Solid Code  - Good methods of reducing the bugs in a
                            program from day one.
   2. Lex & Yacc ,Nutshell book.  Good at explaining use of lex and
      yacc and their clones.
   3. Sed & Awk , Nutshell book.  Good at explaining use of sed and
      awk,nawk,gawk.
   4. Numerical Recipes in C.  A good collection of numerical
      analysis routines.  Looks a lot like fortran conversions.
      Requires a robust malloc(),free() implementation, if the code
      is used directly.

  Periodicals

    1. C user's Journal.
    2. Dr. Dobb's Journal
    3. Software Development

c) Only IDE used often is Lattice C.  DevPac and others in a) are ok.

d) A language compiler is the most important item. Without it all
other tools are useless.  I use C because there exists so many pd
tools and libs to make life easier. [ex. flex yacc tavltr regexp]

//// Albert Dayes

a)  1. Pure C compiler (includes assembler and C source level debugger)
    2. Modem (Can anyone live without one?)
    3. grep
    4. EdHak   - the Super Editor (text and binary) by Clear Thinking
    5. Look It - Codehead's text and binary (multiple) file editor
    6. MT-C Shell - A UNIX C-shell by Beckemeyer Development
    7. SupEdit - Supra's hard disk sector editor
    8. C_PSLIB - a PostScript library for C programmers
    9. Greenleaf Database library - xBASE data/index/memo file compatible
    10. STraight Fax v2.x - fax software by NewStar technologies

b) books:

    1. The Atari Compendium by SDS Publishing - ISBN 0-9638331-0-3
    2. File Structures, 2nd Edition - ISBN 0-201-55713-4
    3. Unix Programmer's Reference - ISBN 0-88022-536-X
    4. Dictionary of Computing, 3rd Edition - ISBN 0-19-286131-X
    5. PostScript Language Reference Manual, 2nd Edition (Red-Book)
       ISBN 0-201-18127-4

  periodicals:

    1. C Users Journal
    2. Software Development
    3. Dr. Dobbs Journal

c)  Megamax's Laser C Shell.  The only GEM development environment with
    a CLI in a window.  The easiest way to access UNIX style tools and
    still enjoy the benefits of GEM.

d)  A great ANSI C compiler with an outstanding C source level debugger.
    Can anyone live with a true source level debugger?


//// Scott R. Garrigus

a)
  1. GFA BASIC
  2. GFA BASIC
  3. GFA BASIC
  4. GFA BASIC
  5. GFA BASIC
  6. GFA BASIC
  7. GFA BASIC
  8. GFA BASIC
  9. GFA BASIC
 10. GFA BASIC

//// Kris Gasteiger

a)

1: OSS/ICD Personal Pascal ( of course! ).

2: The Abacus Atari ST series of books. ( Out of print, but worth searching
   for in the used book stores. ).

3: Compuserve.

4: Tackle Box ST, by Rusty Mullins, no longer available, but probably
   replaceable by the Atari Compendium ( Which I really need to order! ).

5: Someone else's code.

6: A calculator capable of converting one numeric base to another. This can
   be hardware, or software ( Accessory ).

7: A good text on pascal programing, my current favorite is: Introduction
   To Pascal, by Rodney Zaks. Sybex Publishing.

8: Graph paper and pencil for mapping out what the program is to do, and how
   it is to do it. Also useful for bit maps and other graphics layout.

9: Good Colombian Coffee or Peach Schnaps, depending on the time of day,
   and my current frame of mind.

10: A hard drive with space to hold revision upon revision upon revision,
    until you realize that revision XXX.X worked best... A hard drive also
    speeds up compiles by an enormous amount.


//// Travis Guy

    A1) GFA BASIC 3.7 - Great editor. GFA makes it easy to throw an
        idea into the interpreter and see what happens.

    A2) My GFA libraries - ... but when it is time to compile
        something, I like to use my hand-built function libraries.
        GFA just does some weird things with their built-in GEM & TOS
        calls. I learned how to interface with GEM and TOS after
        years of strange bombs and lockups.

    A3) Devpac - You've got to use assembler to know your machine.
        Also useful for getting into those hard-to-reach areas that
        GFA'll never go.

    A4) Sozobon C - I actually wrote a real program in this once, and
        had AEO not appeared a month after I did that, I'm sure I
        would have written more. <g>

    A5) The original K-Resource. Great interface. I hear it's been
        updated to work with newer versions of TOS.

    B1) The Concise 68000 Programmer's Reference Guide - Whatta book.

    B2) One of the early MichTron GFA programming books - Sorry, but I
        can't remember its name, but I gave it a glowing review in ST
        Informer years ago. Only really useful for GFA programmers.

    B3) Chris Latham - Working with him on the Universal Item
        Selector (UIS) and his various GEMDOS replacement kernals and
        networking packages for the Atari was such an experience!
        I'll never forget when we finally started passing packets
        back and forth across the LocalTalk ports on our machines, we
        celebrated with a game of blitz chess and Cokes &
        cheeseburgers at the King Freeze - charged to the company.

    B4) The Atari Programming CAT on the GEnie ST RT - Filled with
        lots of experience, quick answers and great characters.

    B5) De Re Atari & Your Atari Computer (the purple book) - Yeah,
        these are 8-bit Atari programming books, but they gave me (a
        mere afternoon hacker) the urge to explore my 400's OS and
        get into serious programming. I wore out the spine on the
        purple book to the point where I had to bind it all together
        with duct tape. I'm saving my copy of De Re to be cremated
        with me.

//// Damien M. Jones

a) 1. Devpac 3.  For all the assembly I write, I couldn't survive
      without it.
   2. GFA BASIC 3.5.  I wouldn't recommend it to anyone else, but
      knowing most of its faults, I can work around them, and writing
      GEM code is easier in GFA.  (I dislike C for various reasons.)
   3. A custom CLI.  I didn't like any of the CLIs that were available;
      none of them did what I needed in the amount of memory I needed
      it done.  So I wrote my own.
   4. ORCS.  I use it for dialog construction because it's inexpensive
      and fairly simple to use.  I will probably buy a "real" RCS soon.
   5. A custom graphics program.  I often need a quick, simple graphics
      program to do a fast editing job on an icon, using tools not
      available in ORCS.  This custom program is small, and it loads fast.
   6. Geneva.  It's probably done more for my real productivity on the
      Atari than any other software package, and I'm still learning to
      use it more.
   7. Desk Manager 3.3.  Essential for switching configurations quickly,
      which I do a lot.
   8. Data Diet 2.  It helps keep the source files small enough to fit
      on my even smaller hard drive.
   9. NeoDesk 3.  I'm a visual person; I like icons.  (So why do I use a
      CLI?  They're better at some things.)  NeoDesk makes using my
      computer simpler and less taxing.
  10. Warp 9 3.8.  By making the whole system run faster and smoother, I
      can get more work done.

b) The Atari Compendium, no question.
   Graphics Gems I-III.  Graphics is one of the things I do, and these
   books have been invaluable tools here.

c) Devpac 3.  Editor, assembler, and debugger, all in one convenient
   package.

d) I'm slowly making the move to 100% assembly.  Some people believe
   that assembly is not the best tool for every job; I happen to be
   one of them.  But for almost everything _I_ want to do, it has to be
   assembly.  And if it has to be assembly, it has to be Devpac.  I've
   looked at other assemblers and debuggers--I just like how Devpac works.

//// Ron Whittam

a)  Top 10

  1. SOZOBON 2.0
  2. Dale Schumacher's dLIBS 1.20.0
  3. SZADB Sozobon Debuger
  4. STGREP 1.0 (ported by me from Unix to the ST)
  5. Gulam CLI
  6. Knife ST
  7. ZAP 2.0 binary editor
  8. MAKE.TOS (Tony Andrew's SOZOBON C make utility)
  9. ProEd 1.0f TOS Text Editor - for C script
 10. ProTEXT 4.5 Text Editor/WP - For documentation

b) Books/Periodicals

  1. Atari ST Internals; Bruckmann, English, Gerits; ABACUS
  2. "C" A Reference Manual; Harbison-Steel, Tartan Labs; Prentice Hall
  3. The Atari Compendium; Sanders; SDS
  4. C-manship Complete; Walnum; Taylor Ridge Books
  5. COMPUTE'S ST Programmer's Guide; Compute! Books

c) Best IDE

   Gulam CLI with my own menu program to integrate PROED (text
   editor), Sozobon's MAKE, Compiler, Optimizer, Assembler and Linker
   programs.  Does an OK job for a novice.

d) Why #1 is #1

   Sozobon C 2.0 is a low cost development system (price of shipping
the disks or downloading).  It has low overhead and is efficiently
fast for my uses.  While it is not ANSI compliant, there are many K&R
Style code on other platforms that can be easily ported to the ST with
Sozobon C.  I got it 'cuz it was simple to use and I wanted to have
something, other than BASIC, to support my own computer with.

e) Non-Fiction books. . .

   1 - Hackers, Steven Levy
   2 - The Hacker Crackdown, Bruce Sterling


/*************************************************************************/
                        On The Networks
/*************************************************************************/
=========================================================================
(C) 1994 by Atari Corporation, GEnie, and the Atari Roundtables. May
be reprinted only with this notice intact.  The Atari Roundtables on
GEnie are *official* information services of Atari Corporation. To sign
up for GEnie service, call (with modem) 800-638-8369.  Upon connection
type HHH (RETURN after that). Wait for the U#= prompt.Type XTX99437,GENIE
and press [RETURN]. The system will prompt you for your information.
==========================================================================

                       Atari ST RoundTable
                      Real Time  Conference

                      Monday, Jan. 24, 1994



                  CD ROM for the Atari Computer!
                  ==============================
                               with
                        CD ROM Developers
             Greg Kopchak, Roger Burrows, Brian Grier

                          Special Guests
              David Troy, Damien Jones, S.Fardishgh

                         Host - Lou Rocha

<[HoST] ST.LOU> Our guests tonight are Greg Kopchak from It's All
Relative, David Troy from Toad Computers and Roger Burrows, from
Anodyne Software.

Our topic is CD ROM for the Atari and we look forward to hearing
about the latest developments for our platform. The crowd is small
right now, so if you have a question or comment please /raise your
hand.

I am going to ask our main guest, Greg Kopchak, to upload his
opening comments. GA Greg.

<GREG> I'd like to post a few things about Photo Show Pro supports
Kodak Photo CD on the Atari Falcon 030 and allows the user to
create scripted slide shows and presentations that make maximum
use of the built in hardware capabilities of the Falcon 030. Photo
Show Pro has twenty different fades and disolves when creating
scripts, allows overlay of text on graphics in your choice of
system colors, screen fades to black or white, inverse colors, and
image overlays. Photo Show scripts can be created directly from CD
using the Kodak Photo CD PCD format or created from disk using the
FTC 16 bit true color format. All effects are super smooth, even
when running under MultiTOS.

Digitized sound files in AVR format can scripted along with
graphics allowing the user to add commentary, sound effects, or
background music to their presentations.

For creating titles, Photo Show Pro displays 24-bit BMP files in
the Microsoft Windows bitmap format.

Photo Show Pro can be used with VGA, RGB (Atari monitor), and
standard broadcast televisions. Slide shows and presentations can
be recorded to VCR using either RF output or the higher quality
composite output of the Falcon 030.

Full 16 bit color with correct aspect ratios are displayed on all
monitor types except monochrome.

Photo Show Pro will auto show your Kodak Photo CD graphics using
16 different effects directly from your Photo CD discs. A special
Corel mode allows the same auto shows using the Corel series of
Photo CD images. Corel is planning to release over 100 theme discs
of Kodak Photo CD graphics with each disc containing 100 images.
Conversions can be made to 16-bit FTC, 24-bit TIF, 24-bit EPS, and
24-bit RAW formats from Kodak Photo CD's PCD format. Image
conversions can be done in pixel resolutions of 192 by 128 up to
3072 by 2048.

<[HoST] ST.LOU> Thanks Greg. I didn't realize you were an old pro
at RTC uploads :-) Our next comment comes from Brian Grier. Go
Ahead, Brian.

<[Brian] B.GRIER> I really would like to make an announcement. I
have created a program to allow Atari users to access Compton's
New Media CD-Roms on Atari computers.

<[HoST] ST.LOU> Brian, can you tell us a little more about it?

<[Brian] B.GRIER> Please excuse my typing as this is my first RTC.

<[HoST] ST.LOU> You're doing EXCELLENT.

<[Brian] B.GRIER> My program accesses Compton's M.O.S.T discs. It
currently works with the "Book of Home Remedies", "The King James
Bible", and the "CIA/KGB information book" I would like to say it
works with more but I have to buy more CD-Roms to be sure.

Everything works pretty much as the windows(tm) version. You are
allowed to have as many open sections as you want, and can display
pictures, and play audio (STe/TT only right now).

<[HoST] ST.LOU> Sounds great! What CD ROM are you using and what
is M.O.S.T.? Does your PRG work with MultiTOS, Brian?

<[Brian] B.GRIER> That's about it. Except if this goes well I'll
be making a verson for Compton's Multi-Media encyclopedia.
M.O.S.T. is Multiple Operating System Technology.

<[HoST] ST.LOU> What CD are you using, Brian? Does your program
run under MulitTOS?

<[Brian] B.GRIER> If you mean drive I have a Chinon 431 (from
TOAD) and an NEC-84

<[HoST] ST.LOU> Let's move on to Lorne White.

<[Lorne] L.WHITE17> Thanks, As a would be developer, I would like
to know more about getting into a CD ROM type application
development..

<[HoST] ST.LOU> Greg, would you like to answer Lorne's question?

<GREG> Once you get your application running on the very big hard
disk you can approach one of the many CD publishers about getting
a master done. The big problem has been the minimums required by
most publishers and pressers.

<[HoST] ST.LOU> Lorne, any followup?

<[Lorne] L.WHITE17> Yes please. I've always presumed that the
shell program that drives the application could be tricky since
it's very much set up for the other platform. True or False.

<GREG> False. A CD looks like a VERY BIG hard disc to the OS

<[HoST] ST.LOU> Anything else, Lorne?

<[Lorne] L.WHITE17> But doesn't the interface have to be
consistent across platforms ??

<GREG> The CD can be a Mac CD, A PC CD. An Atari CD or cross-
platform. You decide what you want it to run on. The media itself
is very much cross-platform.

<[HoST] ST.LOU> Greg, you mentioned minimums for pressing CD's but
I thought PHOTO CD was economically feasible? How does one get
PHOTO CD's done?

<GREG> All you do is take a roll of film to Walmart and tell them
PCD please. Getting multiple copies pressed is not the same as
making a one-of disc.

<JOHN.KING.T> I am about to get a CDROM drive for my TT. Is a
Double Speed unit fast "enuf" or should I consider a triple or
quad unit? This unit would be SCSI and might be a dual use unit
with my PC laptop for tax data research. GA

<[HoST] ST.LOU> Maybe David Troy would like to handle that one.

<[Dave Troy] TOAD-SERV.> Sure... The double speed drives are
pretty quick. Triple speed is even better though [450K/sec vs.
300K/sec & 150 with single speed.

<JOHN.KING.T> Price is not a problem. Are the faster units worth
the extra price?

<[Dave Troy] TOAD-SERV.> I would say that with the new technology
coming out, and if you don't mind spending the extra bucks
(approximately $100-$150), it might be a wise choice. Things are
always going to need to be faster, wider, lower, longer, etc. :)
And we sell double and triple speed NEC units at decent prices.

<JOHN.KING.T> That is cheap for the extra speed. Thanks for the
suggestions.

<[HoST] ST.LOU> Roger Burrows would like to add to Dave's
answer...

<[Roger] R.BURROWS1> Yes ... I agree with Dave. If you can afford
it, go for the fastest. But I think the speed difference from
single to double is enough for most of us poorer folks.

<[HoST] ST.LOU> Roger, I know you are working on ExtenDOS. What speed units
have you tested ?

<[Roger] R.BURROWS1> So far, single and double. Tintin is looking at a triplespeed, so I may get to test on
that soon .

<[Dave Troy] TOAD-SERV.> I think that that is very fair... Double
speed is pretty nice, but triple is maybe a little more future
oriented. I am tickled pink with the double speed drive myself. :)

I am used to the old 150K/sec 380ms crawlers. 200ms with 300K/sec
seems like a speed demon. <ga>

<[HoST] ST.LOU> I'll take that crawler off your hands :-)

<[Dave Troy] TOAD-SERV.> I got plenty of 'em... :)

<[HoST] ST.LOU> Next we have Sean Dougherty from Two Worlds
Publishing.

<[Sean@TWP] P-DIRECT> Right now, the uses of CD-ROM seem fairly
limited to the home user. Could one of you go over a few of the
more exciting practical things one can do with CD-ROM, just to
help convince people they need one? (this isn't prompted, I
swear!) GA

<GREG> DTP is a compelling reason. I have a CD with a couple
hundred meg of clip art. Corel has several thousand images
available now with more planned. The new Gemini CD has fonts ready
to go. Animations like FLI are fun to view. Photo CD brings your
images home and makes them personal.

<[Dave Troy] TOAD-SERV.> The secret to CD-ROM on the Atari is
finding applications which are not platform specific, as Greg
said. CD-ROM is very much a data storage medium and just as your
hard drive holds data files that your favorite programs can use,
so can a CD ROM. The only catch is that you don't get to write to
the CD ROM yourself, the way you can with a hard drive. So you are
challenged to find CD TOAD-SERV. ROM's that already have data that
your programme actually use. I think that Photo CD is a very
exciting technology for CD-ROM on the Atari, as well as the
potential for clip art, fonts, sound files (.WAV on Falcon!!), the
new Atari GEMINI CD ROM.

There are also lots of CD ROMS available with graphic images in
GIF format, soon JPG. format will become prevalent (are the
corel's JPG?) and the encyclopedia for the Compton's stuff from
Brian. Pretty exciting stuff. [ga]

<[HoST] ST.LOU> Mike Fulton is here and I know there was supposed
to be a CD DEV pack. Mike, can you comment?

<MIKE-FULTON> Well, as you said, I have been working on an Atari
Developer CDROM for several months now. Unfortunately, the
collecting of software and other files (shareware and PD stuff) is
the least of the whole project. One of the big bottlenecks has
been the editing and rewriting of Atari's developer documentation.
I've been working on putting it all (or as much as possible) into
an online-readable format. And this involves updating old
documentation, and a _lot_ of editing. It's taken a lot longer
than I originally anticipated. It's not hard, per se, just time
consuming. But it's coming along nicely and I do hope to have it
done soon. In a lot of ways, it would be a lot easier to write a
program to display and otherwise deal with an existing database
(like some of the online encyclopedias and so forth).

<[HoST] ST.LOU> From what I saw at Las Vegas Comdex, these DEV
CD's have arrived in force. Good luck getting finished, Mike. Rob
Sattler is next...

<[Rob] R.SATTLER> Hello everyone, this is some great stuff! Q- Can
you get by without MultiTOS?

<[HoST] ST.LOU> Rob, I will let Roger Burrows answer that one.

<[Roger] R.BURROWS1> Yes, you can ... that's what ExtenDOS does.
It's designed for those people who don't need all the function of
MultiTOS and/or have maybe a small hardware config. It's pretty
straight forward to use, and works with pretty much any drive.

<[HoST] ST.LOU> What about Falcon and PHOTO CD support, Roger?

<[Roger] R.BURROWS1> Falcon support is on its way, I hope by the
weekend. Photo CD is in the plans ... I only just got a pCD drive
to test with.

<[HoST] ST.LOU> Mike Allen is next.

<MIKE-ALLEN> First let me say that the developments from Roger and
Brian are exciting! These apps for the Falcon are all very nice,
but how about us non-Falcon types? What I'd like to know is can I
use a CD on my MSTe with an older ICD HA (pre AdSCSI). Would I
only be able to read files, etc or is there some way I can look at
photo-cds too?

<GREG> Not Yet Mike. The Photo Cd process looks best with lots of
color. We have samples of Photo CD to SPC up on GEnie. They were
done with DMJ-GIF You can convert a PCD to other formats. You see
it best in true color. Studio Photo will run on an ST. All you
need is for Roger to make a PCD driver for you.

<[HoST] ST.LOU> Roger, is there anyway to use ExtenDOS with the
ICD HA setup? Dave, do you have any configs for Mike?

<[Dave Troy] TOAD-SERV.> You can attach a CD ROM drive to an ICD
host but I don't know about the pre-AdSCSI models. ICD's Link &
Pro utilities comes with a DMA 0-7 CD ROM driver for Metados.

<[Roger] R.BURROWS1> ExtenDOS on the ST needs an ICD AdSCSI or
equivalent.

<[Rob] R.SATTLER> Is Extendos available now? How much?

<[Roger] R.BURROWS1> Yes, available now, currently direct mail
from me, hopefully soon at your friendly Atari mail-order dealer.
Re price: $19.95 including everything (US$ in US, Cdn$ in Canada)
Ontario residents, add sales tax (sorry).

<[Dave Troy] TOAD-SERV.> Toad Computers will be talking to Roger
about ExtenDOS. :)

<[Tintin] C.LABELLE> I noticed TOAD advertises NEC 3xp. Have they
been tested with Falcon and XFS?

<[Dave Troy] TOAD-SERV.> Yes, but right now MultiSession support
won't work with the NEC drives. They DO support single session
Photo CD's with the XFS driver. The problem is not, of course, in
the drive. They are fully multisession. The XFS driver, however,
doesn't understand NEC multisession right now. The only drive that
the XFS driver works with in multisession is the Toshiba 3401,
which is a double speed drive and can be expensive. I know that
Greg @ It's all relative is working on modifying the driver to
support multisession on a wider variety of drives, especially the
NEC. So all this means is that you would be restricted, right now,
to Photo CD's with only one directory (development cycle) right
now, but this is changing quickly. And of course all other CD's
work fine.

<[Tintin] C.LABELLE> OK so this denies earlier reports that the
3xp were not working with Falcon.

<[Dave Troy] TOAD-SERV.> I have not had problems, but it does seem
to be very driver related. There are many drivers out there, even
among XFS varieties (2 or 3 versions).

<[HoST] ST.LOU> Next we have Charles Smeton of NewSTar Technology

<C.S.SMETON> I wanted to ask about ExtendDOS and the Falcon, but
this was already answered. So I will ask a bit about how ExtendDOS
works, i.e. how is it installed, how does it differ from MetaDOS,
etc.

<[Roger] R.BURROWS1> OK, well the basic idea is exactly the same
as MetaDOS, that is, there's a supervisor (ExtenDOS) that traps
the necessary system calls then there are drivers that deal with
hardware and file systems. I have another driver written right
now, and am working on still others. If they work out, they may be
of more limited interest than the CD-ROM.

<C.S.SMETON> Do you need any Falcon beta testers? ;-)

<[Roger] R.BURROWS1> It depends :-) probably not, I have a
volunteer in the Ottawa area, and believe me it's tough debugging
hardware-level code over the phone!

<[HoST] ST.LOU> Thanks Roger and Charles. Our next question comes
from Mario Georgiou at DMC Publishing.

<[mario] DMCPUBLISH> Hello all, I would like to know what formats
are currently supported and whether you plan to support CDI and
the new Pro PCD.

<GREG> We will have Portfolio format this summer. I just got a
mailing from Kodak last week on the update. The PRO format is
tough. Files are 64 meg uncompressed. This is what you call BIG.

<[HoST] ST.LOU> Whew!

<GREG> The Portfolio format will have many discs published for it.

<[Dave Troy] TOAD-SERV.> That's where you need more memory for the
falcon... 14MB gets tight.

<[mario] DMCPUBLISH> Big but needed, I look forward to replacing
my MetaDOS ... Good luck

<[Nima Montase] S.FARSHIDGH> Well, it's been about 30 mins now,
but I was just going to add that I was just going to add that you
can also use Audio CDs on your system, as another reason to buy a
CDROM!

<[Dave Troy] TOAD-SERV.> Oh yeah - you can.. Good point. Lots of
PD players are available.

<[HoST] ST.LOU> I would like to hear more specs, Nima.

<[Nima Montase] S.FARSHIDGH> Well, right now you can play AUDIO
CDs on all ATARI systems (did the Falcon one)

<[HoST] ST.LOU> What is your software?

** <[Nima Montase] S.FARSHIDGH> ** disconnected

<GREG> Nima is the author of CD_AUD20 available as shareware here
on GEnie. He is working on a Falcon CD audio player too but work
is proceeding slowly as he doesn't have a test system. Watch for
something in the next couple of weeks though. And if you are using
his CD player, send in the registration.

<[HoST] ST.LOU> Nima is back. Do you have more to comment, Nima?

<S.FARSHIDGH> As I was saying, (Greg, did the Falcon AUD CD work
fine?)

<GREG> NOT yet

<S.FARSHIDGH> Anyways, the Audio CD supports all ATARI ST/TTs now,
it has play, stop, pause, track with the option of playing
random/programmable tracks, fast forward and rewind, eject, and
also the capability of taking external data files (which is fully
configurable) for any non SCSI II compliant CD ROMs. It should
work fine on any CDROM that supports the SCSI II commands, I have
also include a almost fully functional data file for NEC drives
(older ones, the SCSI II not compliant ones), I am just waiting
for some users' feedback!

<[Dave Troy] TOAD-SERV.> Does the CD audio spec allow for playing
digital data backwards, or do you always have to play forward from
a fixed point on the disk?

<S.FARSHIDGH> Yes, you can go back and forth either by passing
along which track # you want or using the up and down option which
moves the song up or down!

<[Dr. Bob] W.PARKS3> First, I'd like to thank Charles for so
accurately asking _MY_ question. <grin> Where can one find out
more about ExtenDOS? I don't dislike MultiTos but I'd rather not
have to add another level between the OS and a CD? Does it support
a variety of CD-ROMS? etc.

<[Roger] R.BURROWS1> I posted a notice in one of the conferences
recently. Yes, ExtenDOS should support any SCSI CD-ROM drive. It's
available mail-order direct from me, or hopefully soon from TOAD.

<[Dr. Bob] W.PARKS3> Ok. The price is very nice - that doesn't
bother me. What concerns me is when I start scratching my head
wondering why the CDROM won't work or what. Does it have some
technical documentation?

<[Roger] R.BURROWS1> It comes with a manual, and I think it covers
everything you need and I'm available by phone or via GEnie if
that doesn't do it.

<[Dr. Bob] W.PARKS3> Ok, thanks- sounds good! <we now return you
to...>

<[HoST] ST.LOU> Thanks Roger and Doc. Rob Sattler has our last
question.

<[Rob] R.SATTLER> I'm a Falcon user and own a Toshiba 3401b, but I
can't seem to get it to handle a driver porperly. I understand
Atari has a driver, how can I get it? Also, what would be better
to use? AHDI, or ICD-Pro bootware?

<[HoST] ST.LOU> Who wants it?

<[HoST] ST.LOU> Everyone does :-)  OK, one at a time. Mike
Fulton...

<MIKE-FULTON> The CDROM driver is independent of the hard disk
software. Therefore, it doesn't really matter if you use Atari's
hard disk driver or ICD's. Theoretically, a CDROM driver could
link in with a hard disk driver, but that's not the way that the
MetaDOS or MiNT XFS drivers work.

<[HoST] ST.LOU> GREG is next, then Roger then Brian.

<[Rob] R.SATTLER> OK, but you do need either extendos or multitos?

<GREG> The version of the XFS driver we ship will all our Photo CD
products is the most current XFS for MultiTOS and works quite well
with all our suggested drives.

<[Roger] R.BURROWS1> Basically, you need ExtenDOS or MultiTOS ...
At the moment, ExtenDOS doesn't handle Falcon ... But that should
be fixed in a week.

<[HoST] ST.LOU> Brian, anything to add?

<[Brian] B.GRIER> According to howard at ICD they are having problems with
Atari's CD-ROM XFS driver and their software on the Falcon.

If you need a CD-Rom driver that works with ALL Atari computers,
but does not yet support Photo-CD you'll probably need ExtenDOS or
my CD ROM XFS driver that's works on all computers (I wrote it
because last year I couldn't find a driver that worked on the SCSI
port of my TT :( <ga>

<[Dave Troy] TOAD-SERV.> We have not had a problem using ICD Pro &
the Atari XFS?

<GREG> ICD is shipping an older version

<[Dave Troy] TOAD-SERV.> It seems to work fine.

<[HoST] ST.LOU> Dave, thank you for coming tonight. Would you like
to make any closing comments?

<[Dave Troy] TOAD-SERV.> Just to thank everyone for their interest
in CD ROM. It's a new and exciting technology, and I hope that
everyone gets involved with it so we can build the critical mass
necessary to get some apps together. The Gemini CD ROM is selling
great! I think that's a good sign. Thanks again. <ga>

<[HoST] ST.LOU> You're welcome. Greg Kopchak, thank you for
organizing the group and getting everyone here tonight. Any
closing comments?

<GREG> Thanks goes to Rene Guimont and Rene Tremblay for providing
the Gemini CD. As the conference was on tonight I got an Airborne
package from our German publisher, totronic. Watch for an
announcement shortly.

<[HoST] ST.LOU> Sounds exciting.

<GREG> I would also like to post some info on the Gemini CD.

Walnut Creek CDROM announces the release of the GEMini CDROM for
Atari Computers. The CDROM contains 616 MB, and 2872 public domain
programs, shareware programs and commercial demos for the Atari
ST, TT, and Falcon Computers plus a section for the Portfolio
palmtop computer. It also contains text and graphics for the Lynx
and Jaguar video game systems.

The GEMini CDROM is set up in a logical tree structure which
simpifies seaching for and running the programs. You can find
files in areas such as accessories, archives, astronomy, database,
fonts, games, GNU, programming, screeen savers, virus , text
editors, utilities, etc.

It includes 50 megabytes of games and entertainment software. For
the desktop publisher, it contains 15 megabytes of fonts. Many
programs include source code. All programs may be run directly
from the CDROM so there is no need to decompress onto the hard
drive in order to use the files. Each directory contains an index
and a list of files to make it easier for a user to locate a file.

<[HoST] ST.LOU> Greg, thanks again to you and your guests. Mike
Fulton, Roger Burrows, Brian Grier, S.Fardishgh, Dave Troy, Damien
Jones. We really appreciate the time and are keenly interested in
this new era for our Atari Computers. Good night.

                  Programming Real Time Conference

                           January 6, 1994

                          Host - Mike Allen


<[Host] MIKE-ALLEN> Ok guys, capture on! The homework idea sure stirred
up some good discussion in cat3/top11.  I was glad to see it.  There were
4 homework submittals I saw, Keith, Carl, Erin and myself.  All seemed to
take a different approach to the problem.  Carl was quite elegant in C.
It was a TOS program.  Carl - I couldn't get it to run under MultiTos -
Kept getting a "out of stack space" message.  Any comments Carl? ga.

<CBARRON>  They were interesting, even some had some 'bugs' in some
others.  Don't know why it was straight gemdos conws() IO and nothing
wierd. Might have been those so called documented settings.  ga

<[Host] MIKE-ALLEN> It ran fine with Geneva and a normal MSTe.

<CBARRON> Oh well, someday I will figure out how to use my MTOS, let
alone program it. ga

<[Host] MIKE-ALLEN> Keith wrote a VERY small assy prog that did
everything in a dialog box.  It ran fine with normal system, Geneva and
MTOS.  Comments Keith? ga

<[Keith] K.GERDES> Not that I can think of.  The dialog box was actually
a simple form alert.  I didn't want to go overboard on the graphic out...
 ;) ga

<[Host] MIKE-ALLEN> Really small 800 and some odd bytes.

<[Keith] K.GERDES> Actually it was 428, but who's counting.  GA

<[Host] MIKE-ALLEN> Hmmm - I thought it was larger - oh well, I was
impressed! Erin Monaco wrote one that ran in a window.  He used C.  It
too ran with a normal system, Geneva and MTOS.  I wrote mine in assembly
as a TOS program.  Not as fancy as the "real" programmers, but it worked
- again, normal system, Geneva and MTOS.  Lets see if anyone else
downloaded the prgs and has any comments.  Phil, did you get a chance to
look at the prgs? ga

<[Phil] P.HANZE> I downloaded yours, but haven't uncompressed it yet.

<[JAB] J.BATES15> This should start something.  Being new to programming
the ST line, I need some reccommendations of languages and such.

<[Host] MIKE-ALLEN> Ok - phil, don't laugh too hard.

<CBARRON>  On languages, German is preferred these days, Hardly anyone
comments in english any more. <g>

<[Host] MIKE-ALLEN> JAB - <Jeff isn't it>  I think most of us agree on
either C or assembly.  Carl (CBARRON) will extol the virtues of FLEX,
given an chance.  Bud - did you get a chance to look at the prgs? ga

<[JAB] J.BATES15> Well, John actually

<[Host] MIKE-ALLEN> <sorry - there was another J.BATES in the other night
- I guess the number was different.>

<[Bud] B.CONNOLLY1> No I didn't Mike. I wanted to get started on mine
before I looked at the others efforts, but I ended taking a vacation from
programming over Christmas.  ga

<[Host] MIKE-ALLEN> Ok bud, I guess that's allowable. <g>  J2 - did you
look at them? ga

<[John too] J.G.H.> No I didn't get a chance to look at any of them ;(
been busy here of late ;> ga

<[Host] MIKE-ALLEN> Ok - Hi Erin. Discussing the homework.  You have any
comments on your prg or any of the others that were uploaded? ga

<E.MONACO> Haven't really had time to update mine or check out the
others...  been playing with geneva <sheepish grin>

<[Host] MIKE-ALLEN> Understand.  I've been playing with 003 too.  Carl -
any comments on any of the other prgs that were uploaded?  ga

<CBARRON>   Erics was nice, almost forces me to upgrade my compiler.  All
looked ok, after all this was not to be the program of the century, they
work, don't look too much like gwbasic spagetti either.  ga

<[Host] MIKE-ALLEN> hehe - I dunno, mine was spaghettish.  Keith - did
you have a chance to look at the other uploads?  Any thoughts if so? ga
<Keith's been pretty busy in the ST Aladdin RT!>

<[Keith] K.GERDES> No...  Sorry.  ga

<[JAB] J.BATES15> So C and assembler.  What will access the DSP in the
Falcon?

<[Host] MIKE-ALLEN> Hmmmm - well I guess not too many folks had a chance
to review other folks work.  If any of you get a chance, you might take a
look.  John - hang on a couple 'til we get to general discussion please.

<[JAB] J.BATES15> No problemo

<[Host] MIKE-ALLEN> I noticed a couple of things.  Seems like terminolgy
bit some of us.  Especially when it came to how version numbers were
stored.  I like to refer to the storage of most of the Atari version
numbers as "Packed BCD."  Does that need explanation?

<[Bud] B.CONNOLLY1> Go for it Mike, so we'll all be on the same page.

<[Host] MIKE-ALLEN> e.g. AES version 1.9 is stored a $0190.

<CBARRON>  all I did was report a straight hex conversion.  Gemdos
version is small endian rest the normal big endian.

<[Host] MIKE-ALLEN> Each byte is actually 2 BCD (Binary Coded Decimal)
digits.  As carl noted, except for GEMDOS, the versions are Major Rev in
the first byte and the minor rev in the low byte.  make that 2nd byte to
avoid confusion! <hehe>.  GEMDOS is backwards, like Intel uses or, as
Scott refers to it, "Little endian!"

<[Bud] B.CONNOLLY1> Carl or Mike, can you explain the 'ENDIANs'?

<[Host] MIKE-ALLEN> Now the first place I ran into confusion was with the
GEMDOS version.

<CBARRON>  The fun will come from the cookies, some are 32 bit #'s some
are only 16 bit # 's and some are really only one byte #'s.  That becomes
more fun, I cheated, I reported all as longs....  Big endian means the
high bytes before for the low bytes  the number twenty would be [as
normal] 20 in a high endian, or 02 in low endian.

<[Host] MIKE-ALLEN> Bud - Big Endian is like the 68k uses - if you load a
word into a register the Most significant byte is in bits 15-8 and the
least signigicant byte is in bits 7-0.  Little endian does it the other
way around.

<[Bud] B.CONNOLLY1> thanx guys.

<[Host] MIKE-ALLEN> Little endian words are also referred to as
byte-reversed.

<CBARRON> 6502 was little endian too

<[Host] MIKE-ALLEN> True.

<[Bud] B.CONNOLLY1> So Intel format is Little Endian.

<E.MONACO> I also reported cookie values as longs (hex).

<[Host] MIKE-ALLEN> My first confusion was with the GEMDOS version.
<correct, Bud> I understood that it was byte reversed, but I had mixed
signals at to whether it was in packed BCD or binary.  Most of the
European docs (devpac, etc.) reference binary values where as the
Compendium says they are Packed BCD.  e.g. GEMDOS for TOS 2.05 is 0.19 in
the Compendium and 0.25 in the DevPac docs.

<E.MONACO> So which should we use?

<[Host] MIKE-ALLEN> I was leaning towards the European convention since
the disk based version of TOS reports a $0D00.

<[Bud] B.CONNOLLY1> I like the Compendium method. $1900 is 0.19 is a lot
easier to keep straight.

<[Host] MIKE-ALLEN> However, Scott swears that Atari says they are now
using packed BCD.  This seems to be verified since the GEMDOS version for
TOS 2.06 is $2000 which is one minor rev up from $1900 that was used for
TOS 2.05.

<CBARRON> $0d is not a bcd decimal <grin> packed or not.

<[Host] MIKE-ALLEN> Carl - you got that right!

<E.MONACO> I would lean towards the consistant bcd myself.

<[Host] MIKE-ALLEN> I think we should stick with the Compendium version -
Packed BCD, byte reversed.

<E.MONACO> good, I don't have to change it... again :)

<CBARRON> I THINK atari means they are hex but read as decimal. Seems to
be more consistant than the 'normal' definitions.  ga

<[Host] MIKE-ALLEN> Now where I really got confused was in the cookie
Jar.  <Erin - I changed mine to Compendium the same time you changed
yours to binary.  hehe> Carl - I think you are right, which is why I like
to refer to them as packed BCD.  Each 4 bits of a byte defines one
decimal number.

<E.MONACO> well I'll be glad to get it all straight

<[Host] MIKE-ALLEN> Now, the cookie jar is wild! For instance it appears
the MTOS reports a version in packed BCD, whereas the _CPU cookie returns
a binary number for the CPU type.  Confused the hell out of me! The _CPU
cookie returns a $0000001E for a 68030!

<E.MONACO> It is if you wanted to define the meanings of various cookie
values... I just report them like carl.

<[Host] MIKE-ALLEN> Well, I was kinda of interested in what the cookies
meant.  <g> Any further discussion before we look for a new assignment?
ga <he says, ducking>

<E.MONACO> I thought about it... it could be done using the compendium,
then for all none standard cookies... probably be easier to just report
the long value as is.  er none=non

<[Host] MIKE-ALLEN> I was decoding and reporting the Geneva, MTOS and
GDOS cookies in my prg.

<CBARRON>  There is no consistancy on what the parameter is. Plain and
simple it is cookie specific.  To use a cookie value, you need to know
what it is or what it points to.  There is a cookie standard, all cookies
are standard. Some are ATARI's.  ga

<E.MONACO> I have a suggestion for a new assignment, how about a simple
gem windowed editor...

<[Host] MIKE-ALLEN> I have uploaded the Atari defined cookies as per the
compendium to lib 19 for those who don't have the compendium.  I would
encourage those who have insight into other cookies to upload the info to
lib 19.  Erin - Gee, I haven't figured out how to open a window yet! <g>

<E.MONACO> yes, when dealing with cookies you HAVE to know what the
values mean.  good time to learn mike! <g>

<CBARRON>   gee you got some ideas<grin>   I still am waiting for some
cookie info on some graphics cards.   w_handle=
wind_create(0,20,20,200,100); wind_open(w_handle,20,20,200,200);<g> ga

<[Host] MIKE-ALLEN> Ok - suggestions for the next homework assignment.
Remember that the next meeting is a Templemon/Sysmon session with some
very expert experts.  So any assignment would be due the first meeting in
Feb.  Suggestions?  Expand on what we have been doing?  Something
entirely new (like Erin's suggestion)?  Something else?  Forget it?  ga.

<CBARRON>  good, I got to get to yacc'ing again. >grin< Seriously gem
text sounds important, but are we 'up to' it?\

<E.MONACO> experts?! hardly, although I did get it running and sorta know
how to use it.

<[Bud] B.CONNOLLY1> Good point Carl, Erin, how 'simple' do you mean?

<E.MONACO> I think we are up to the challenge, especially collectively...
and we have the CAT where help is always available.

<[Host] MIKE-ALLEN> Carl - that is my thought.  Maybe we could work up to
it in steps?  Like the first step is open a window with certain gadgets
and put some GDOS text into it?

<[Bud] B.CONNOLLY1> good suggestion Mike.

<[Host] MIKE-ALLEN> I know how we could be 'heros!'  Figure out why
Falcon and FOTI don't work on TOS 2.xx and up and fix them!  <g>

<E.MONACO> I was thinking a simple one window editor (24 lines) cursor
movements, insert, delete, bs, that sort of thing.

<[Host] MIKE-ALLEN> Erin - GDOS?

<E.MONACO> Nah... at least not at this poind.  er point.  I like the
steps idea... lets break it down further.

<[Host] MIKE-ALLEN> So, erin, no scroll bars, no fuller gadget, etc?

<E.MONACO> Nope, just a window that'll hold 24 lines 40 or 80 cols with
simple editing.

<[Bud] B.CONNOLLY1> That might be a little too 'simple' Mike. <g>

<CBARRON>  GDOs who uses GDOS? Only gdos I use is with AW occasionally...
First get some user inputted text in the window.  A hero's project, is a
GEM APPLICATION code generator using gem... <grin>

<E.MONACO> I suggest we start with just vdi text, skip using GDOS.

<[Host] MIKE-ALLEN> Erin - so later on we could expand it?  Do you want
it to be able to load a file or just save it?  Word wrap?  give us a
definition of the first step.  <Carl - my #1 son wants to play Falcon and
FOTI on my MSTe! You'd be a hero to him if you could fix them!>

<E.MONACO> hmmm, first step no load or save, just 24 lines of programmers
choice of text printed into window where the user could then edit it.

<[Host] MIKE-ALLEN> It comes up with text?

<E.MONACO> doesn't have to...  you could let the user enter and edit it,
but keep it to one windows worth

<[Host] MIKE-ALLEN> sounds like a good first step.  Lemme see if I have
it right.  Open a GEM window with space for 24 lines of 40 or 80 column
text (depending on the rez) and then allow entry and editing using the
keyboard, cursor keys, bs and delete.  OK?

<E.MONACO> after all the editing is going to be the tricky part... we
could always expand the buffer and add load, save, search, replace, etc,
etc. sounds perfect.

<[Host] MIKE-ALLEN> Gotta run with Geneva and MTOS too!

<E.MONACO> of course! :)

<[Host] MIKE-ALLEN> any objections? <boy am I about to learn things!>

<E.MONACO> lets start it with a menu too... with just an about item and
quit.

<[Host] MIKE-ALLEN> Ok, I have no objection to the menu - makes Geneva's
life easier.

<E.MONACO> I think the menu should be in a rsc file, so additions will be
easier latter on.

<CBARRON>  Can't guarantee it will run without a stack overflow! Might be
a compiler problem, but based on past perfomance...  A menu means you are
going to do a lot of work, the scrolling is a small part of it, if the
data is stored properly.  go

<[Host] MIKE-ALLEN> Besides, you can brag a little in the "about" box.
Yeah I agree with the .rsc, but not as a requirement at this time

<[Bud] B.CONNOLLY1> You can do that if everyone has a Resource Editor.

<[Host] MIKE-ALLEN> Looks like I get to learn WERCS too.

<E.MONACO> the rsc file is just a suggestion on my part, I've found it
much easier to modify rsc files then to modify embedded rsc's.

<[Host] MIKE-ALLEN> Lets make the menu optional, but encouraged.  <grin>

<CBARRON>  If you are going to do gem programming you need one, there is
at least one in the libs, if you don't have one.  RSC file is a good idea
at this point, for menus, dialogs at least...

<[Bud] B.CONNOLLY1> How will you exit the program without a Menu?

<E.MONACO> ok, but if we plan to add load and save, etc features it
should be HIGHLY recommended.

<[Host] MIKE-ALLEN> Bud - why do you always come up with those pesky
little details?  <g>

<[Phil] P.HANZE> what about <cntrl>-q?

<E.MONACO> control-c or have a close box... but then you wouldn't get 24
lines.

<[Bud] B.CONNOLLY1> Because, that's what I do at work all day long... <G>


<[Host] MIKE-ALLEN> You could exit with the close gadget.

<CBARRON>   Exits without menu things like <alt-q>, <esc>q, etc.... I'd
stay away from cntrl-C. I like that for kill operation.

<[Bud] B.CONNOLLY1> Yep, forgot about that.

<E.MONACO> if you have a close box, you should have a title, and for a
multitaskers sake, a move bar.

<[Bud] B.CONNOLLY1> Some more pesky little details Mike!

<[Host] MIKE-ALLEN> Use the Atari Standard for exiting - ^Q

<CBARRON>  Ah yes, the infamous     while(handle_input()!=WM_CLOSED); GA

<[Host] MIKE-ALLEN> Ok, I think we have enough to start on - let's keep
the discussion going in cat3/top11.  I'm sure things will get refined
there ok?

<[Bud] B.CONNOLLY1> okay

<E.MONACO> sounds good.

<CBARRON> FINE

<[Phil] P.HANZE> sounds fine to me

<[Host] MIKE-ALLEN> Thanks for the suggestion, Erin.  Considering what I
learned with the simple assignement we started with, this one ought to be
a real education!

<E.MONACO> no problem, glad to help :) btw, I've learned a few things
myself!

<CBARRON> Thanks erin <grin> I might get back into gem yet. <grin>

<[Host] MIKE-ALLEN> Ok, general discussion.  John has been waiting
patiently for some suggestions about compilers/assemblers.  Give him some
ideas. ga all.

<[Bud] B.CONNOLLY1> What are you looking for John?

<[JAB] J.BATES15> thanks Mike I need a C that will run on a Falcon

<[Host] MIKE-ALLEN> Lattice 5.60?

<E.MONACO> Lattice 5.60 is supposed to work fairly well with the falcon

<CBARRON>   As for assemblers, I can only recommend devpac,   C compilers
, I use Lattice , Pure is OK.  Most others are not supported these days.
Lattice is supposed to run on a falcon.

<[JAB] J.BATES15> downward copatability would be nice

<E.MONACO> I agree if you need languages... check out HiSofts... they
have nice, albeit expensive products.

<[Bud] B.CONNOLLY1> Prospero has a TT version of their C compiler, that
should work on the Falcon.

<[Host] MIKE-ALLEN> I believe that DevPac 3.1 is supposed to run on a
F030/

<E.MONACO> Lattice C and DevPac III is a killer programming combo.

<[Host] MIKE-ALLEN> I'm using DevPac2.  Haven't freed up enought disk
space to install 3 yet.  8^{

<E.MONACO> mike? when is the next assignment due???

<CBARRON>   I compile old style K&R from the wonderful world of unix with
lattice no problems, It even has an old style preprocessor if that is
required.  Lattice is o.tion city. It is gui driven.  Comes with loads of
stuff, checkout cat 33 top.

<[Host] MIKE-ALLEN> Erin - First thursday in Feb.

<E.MONACO> DevPac III is ... sweet.

<CBARRON> topic 6 that is.

<E.MONACO> thanks mike...

<[JAB] J.BATES15> now about a Resource editor?

<[Bud] B.CONNOLLY1> Mike, the meetings are First and Third Thursday now?

<CBARRON> Lattic comes with wercs.

<E.MONACO> Hey, can I use a Pure C lib with lattice? Wanna update
Geneva's Task Manager... without lots of porting hassles.

<[Host] MIKE-ALLEN> Bud - I thought they were always the 1st and 3rd.
<girn>

<[Bud] B.CONNOLLY1> I got K-Resource 2 with the Prospero Developers
Toolkit.

<[Host] MIKE-ALLEN> girn?

<[Bud] B.CONNOLLY1> No, Mike, I thought it was every other Thursday.  But
I could be wrong ,g.  <g>

<E.MONACO> I checked out ORCS... seems... relatively complete/complex,
any comments on it?

<[Host] MIKE-ALLEN> Bud - sorry - I meant it to be 1st and 3rd.  Twice a
month.

<CBARRON>  I tried it it seems to work, but since I have lattice I use
wercs.

<[Bud] B.CONNOLLY1> No problem Mike, every other Thursday was just easy
for me to remember, PAYDAY!

<[JAB] J.BATES15> and the Compendium?

<[Host] MIKE-ALLEN> The Compendium is a "gotta have."

<E.MONACO> I know what you mean carl... why fix what aint broke
(regarding Wercs)

<[Bud] B.CONNOLLY1> Yep, gotta get it! Toad has it for $45.

<[JAB] J.BATES15> And you want this program when?

<[Bud] B.CONNOLLY1> Feb. 3

<[Host] MIKE-ALLEN> JAB - 1st thursday in Feb.

<[JAB] J.BATES15> no problem!

                   Programming Real Time Conference

                          January 20, 1994

                          Host - Mike Allen

                      Guest Speakers - Erin Monaco
                                       Keith Kerdes
                                       Scott Sanders




<[Host] MIKE-ALLEN> Ok folks, our Guests are all here . .  and I guess we
should get started.  The capture buffer is on, so watch yourselves.

<[Scott @ SDS] S.SANDERS2> Ooooh mild aftershock, that was neat.

<[Host] MIKE-ALLEN> Tonight Erin, Keith and Scott have agreed to discuss
and answer questions about TempleMon and SysMon.  Since we aren't loaded
with folks I will try to keep it informal.  I will ask that you try and
keep a little order.  What I suggest is that after each question, the
guests answer in turn, first Erin, then Keith and then Scott (in order of
arrival) I'll try and moderate a little, but I hope I don't need to do
too much.  You guys have been doing great so far.  Each of the guests,
please use a GA (go ahead) when you are done so that the next person
knows to proceed.  Using the /rai command for everyone else will let me
get things organized.  I already have Charles with a /rai.

<C.S.SMETON> Can I speak?

<[Host] MIKE-ALLEN> Charles - hang on while I ask the guests for opening
comments on SysMon and temple mon.  Charles yea go for a quickie.  ga
<changed my mind in mid-type!  GA Charles>

<C.S.SMETON> Does anyone know the latest version of SysMon? I have 1.0.8
(10/11/91) Is there a Falcon compatible version or a way to make it work
on a F030? ga

<[Host] MIKE-ALLEN> Erin?

<[Erin] E.MONACO> 1.0.8 is the latest version that I know of charles. No
idea on a Falcon version. GA

<[Host] MIKE-ALLEN> Keith? ga

<[Keith] K.GERDES> 1.0.8 is the version I have running in the background
right now.  It's dated 1-26-92.  wish there was a Falcon comp. version.
GA

<[Host] MIKE-ALLEN> Hmmm - scott doesn't use it? <Boy is GEnie slow
tonight!>

<[Scott @ SDS] S.SANDERS2> Yes, I use 1.08.  That's the best/most recent
as far as I can tell. ga

<C.S.SMETON> 1.08 has a problem on my Mega STe/TOS 2.06 that wraps the
screen (right edge over the left side).  That should have said 1.0.8 and
it has a date of 10.11.91 when you hit the Help key in SysMon ga

<[Host] MIKE-ALLEN> Hmmm - let's let Erin start with opening comments.
What is Sysmon/TempleMon and why should I use them?  <generic I> GA

<[Erin] E.MONACO> All versions that I have seen seem to shift the screen
to the right in like 16 bit increments. I just keep toggling between
sysmon and the app till it corrects itself.

Hmmm, I don't have a speech prepared, but Sysmon is a VERY powerful
developement tool which almost completely monitors every aspect of your
machines current state. TempleMon is a resident debugger that can be used
hand in hand with Sysmon In combination you have a very powerful
debugging/monitor system. GA

<[Host] MIKE-ALLEN> <BTW, with the Slowdown with GEnie tonight, I suggest
everyone keep their lines short so we know that you haven't died> Erin -
what is the latest version of Templemon? ga

<[Erin] E.MONACO> 2.01 or something like that... can't recall exactly. GA

<[Host] MIKE-ALLEN> Ok - Keith your comments?  <do you know the latest
version of Templemon?> ga

<[Keith] K.GERDES> I'm not familiar with TempleMon's development...  I do
know SysMon though! SysMon is an excellent programmer's aid.  You can
monitor these system functions: AES VDI GEMDOS LINE-A XBIOS & BIOS You
can also get the status of different facets of the system, such as
memory, vectors, etc.  GA

<[Host] MIKE-ALLEN> Thanks.

<[Erin] E.MONACO> Mike, 2.01 is the latest version available on GEnie.
Docs & Prg in German.  GA

<[Host] MIKE-ALLEN> Keith - it what way does it monitor those functions?
Some sort of real time display or what?  GA Erin - thanks.

<[Keith] K.GERDES> Yes.  SysMon works in the background.  It hooks into
the system and you can control which aspects you want to monitor....in
realtime.  The info displayed is a detailed readout of each TOS function
as it is performed- parameters passed and results returned.  You can even
send the text output to various devices- serial, parallel, file, etc.  GA

<[Host] MIKE-ALLEN> Wow - sounds like what is needed to debug the BPS.
<g> I'm gonna have to look into it.

<[Erin] E.MONACO> I'd like to add to keiths comments.  ga

<[Host] MIKE-ALLEN> GA, Erin.

<[Erin] E.MONACO> Sysmon gives you the option to turn on/off tracing of
each OS call.  In addition, with the profiler you can do a quick initial
run to find out which calls were made and how many times they were made.
hmmm, gee I'll shut up for now :) GA

<[Host] MIKE-ALLEN> Thanks Erin.  Scott, your turn for comments.  GA

<[Scott @ SDS] S.SANDERS2> I've used both Sysmon and Templemon for
debugging, however, I haven't used them actively in some time because
neither one likes MultiTOS v1.08 and I have to switch setups to use them.
Reportedly, v2.01 of Templemon does work, though, I have been unable to
have any success with its setup (it's quite involved).  Both tools got me
out some sticky situations and helped in writing the Compendium
(shameless plug) by disassembling the OS when Atari couldn't answer a
question about an obscure function. ga

<[Host] MIKE-ALLEN> Thanks Scott.  Sounds like you need a boot handler
such as MouseBoot, etc.  I use Mouseboot to swtich from Geneva to MTOS to
vanilla MSTe, etc.

<[Scott @ SDS] S.SANDERS2> I use Xboot but it's still a fuss.  ga

<[Host] MIKE-ALLEN> Well, I guess we are ready for questions.  /raises
please.  GA

<[Erin] E.MONACO> I've installed 2.01 it works well with my STE and
Geneva.  ga

<[Host] MIKE-ALLEN> <no questions? c'mon, folks!>

<[Keith] K.GERDES> I can send a sample SysMon output file if you'd like
to see it?

<[Host] MIKE-ALLEN> Ok, bud - ask away! ga

<[Bud] B.CONNOLLY1> So, let's see if I have this right...  SysMon will
tell me about the OS, what it is doing, and Templemon will tell me what
my program is up to? ga

<[Host] MIKE-ALLEN> Erin? GA

<[Erin] E.MONACO> Basically.  SysMon show calls made to the OS and y
which process as well as detailed reports on system variables, vectors,
I/O buffers, ect.  ga

<[Host] MIKE-ALLEN> Keith, GA

<[Keith] K.GERDES> You would use TempleMon to debug a program at the
instruction level- ie. a monitor/debugger.  MonST is another example.
SysMon is a "system call" monitor.  If you want to see what parameters to
pass, you could see how another program does it.  TempleMon is at a lower
level. GA

<[Host] MIKE-ALLEN> Keith why don't you dump that sysmon output now.  I'd
kinda like to see it.  ga

<[Keith] K.GERDES> Ok...

*****************************************************************
*
* This file was created by SYS_MON, the ATARI ST System Monitor,
* copyright by Karsten Isakovic, Berlin
*
* It is forbidden to publish this file or extracts of it without
* the copyright header !
*
 ALAD     wind_update    BEG_UPDATE -> 1
 ALAD     wind_get       H 0 TOP   -> 1
 ALAD     wind_update    END_UPDATE -> 1
 ALAD     evnt_multi     KYBD BUT { 2,1,1 } MSG TIMER  { 0,0 } Buf $0DE35E ->
                         (124,72 ) B$00 K$00 Key $2300 But $FF Event =
                         MU_TIMER
 ALAD     wind_update    BEG_UPDATE -> 1
 ALAD     wind_get       H 0 TOP   -> 1
 ALAD     graf_mouse     HIDE_MOUSE $000000 ->
 ALAD     graf_mouse     SHOW_MOUSE $000000 ->
 ALAD     graf_mouse     HIDE_MOUSE $000000 ->
 ALAD     graf_mouse     SHOW_MOUSE $000000 ->
 ALAD     wind_update    END_UPDATE -> 1
 ALAD     wind_update    BEG_UPDATE -> 1
 ALAD     wind_get       H 0 TOP   -> 1
 ALAD     wind_update    END_UPDATE -> 1
 ALAD     evnt_multi     KYBD BUT { 2,1,1 } MSG TIMER  { 0,0 } Buf $0DE35E ->
                         (124,72 ) B$00 K$00 Key $2300 But $FF Event =
                         MU_TIMER


<[Keith] K.GERDES> GA

<[Host] MIKE-ALLEN> <bet I know why he had that! grin>

<[Erin] E.MONACO> :)

<[Host] MIKE-ALLEN> Scott - anything to add? ga

<[Scott @ SDS] S.SANDERS2> Not much. Sysmon and Templemon each have
features useful to specific situations.  Sysmon cannot disassemble
assembly code for instance.  ga

<[Host] MIKE-ALLEN> Ok, I have MonST, etc., from DevPac3.  Is there any
advantage to TempleMon over my HiSoft stuff?  Ga Erin.

<[Erin] E.MONACO> Yes, TempleMon remains resident and can be called up at
any time, ever try to debug a desk accessory or worse a TSR? :) GA

<[Host] MIKE-ALLEN> I thought I could use AMONST for resident use? ga

<[Erin] E.MONACO> er, got me! I'm not sure. GA

<[Host] MIKE-ALLEN> Ok.  Keith? ga

<[Keith] K.GERDES> AMONST is the AUTO TSR version of MonST.  Very small
and quite handy.  GA

<[Erin] E.MONACO> Thanks Keith. ga

<[Host] MIKE-ALLEN> Keith - any comments on TempleMon vs. MonST? ga

<[Keith] K.GERDES> I used TempleMon in an initial release but that was
several years ago...  GA

<[Host] MIKE-ALLEN> Scott - any further comments?  GA

<[Scott @ SDS] S.SANDERS2> I would say that AMONST would probably be
better (slightly) than Templemon but I only have MonST which doesn't have
the resident capabilites which are essential to me.  MonST can trace C
source code (sort) of which is its main advantage.  ga

<[Host] MIKE-ALLEN> Thanks Scott.  What does it take to set up TempleMon.
Can I use SysMon without TempleMon?  Erin - GA

<[Erin] E.MONACO> TempleMon and SysMon are designed to work together
Using TempleMon 2.01 with Sysmon 1.0.8 in TT hires they will share the
same screen. (can't test this but I bet it'd be nice) Yes, you can use
both Sysmon and TempleMon independantly. ga

<[Host] MIKE-ALLEN> How do you set up Templemon?  Scott indicated some
problems.  GA Scott.

<[Scott @ SDS] S.SANDERS2> I had problems with 2.01. It is advertised to
work with MultiTOS but doesn't specify a version so I suspect it was
tested on 1.01, not 1.08 which I use.  The earlier Templemon is simply
one AUTO program.  The latest Templmon requires an AUTO program, several
overlays, things placed in named directorys, and environment setup. Looks
powerful but is a bear to setup (Erin seems to have got it though).  ga

<[Host] MIKE-ALLEN> Thanks - Keith - comment? GA

<[Keith] K.GERDES> Just that I'd take TempleMon over DB anyday...  <g> GA

<[Host] MIKE-ALLEN> <someone else MUST have some questions!> Erin -
comment?  GA.

<[Erin] E.MONACO> 2.01 isn't to difficult when you get past the german
translations.  It comes with an installation program that'll modify the
actually program mainly it consists of preferences, like assigning
hotkeys, colors, buffers, edit modes and the like. GA

<[Scott @ SDS] S.SANDERS2> I speak pretty good german (must be the new
math :).

<[Host] MIKE-ALLEN> Ok Erin, thanks.  Bud has a question.  GA Bud.

<[Bud] B.CONNOLLY1> How tough are breakpoints to set up in TempleMon?
What do you need to be able to set a breakpoint,(ie assembler listing)?
ga

<[Host] MIKE-ALLEN> Erin - ga.

<[Erin] E.MONACO> I've just played with it, so I can't say. GA

<[Host] MIKE-ALLEN> Keith - can you help bud? ga

<[Keith] K.GERDES> Breakpoints in a debugger are either set from the
commandline input or with a hotkey at an address.  GA

<[Host] MIKE-ALLEN> Scott - GA.

<[Scott @ SDS] S.SANDERS2> For instance, if you want a breakpoint at
0x1FFFFF you type:

 b1 1FFFFF

which sets breakpoint 1 to the given address

 b+

turns breakpoints on... after this point, anytime the PC==address,
Templmon is entered. ga

<[Erin] E.MONACO> I can add a little more. ga

<[Host] MIKE-ALLEN> GA Erin.

<[Erin] E.MONACO> SysMon gives the address at which OS calls were made
you could use this to your advantage. Also since TempleMon and SysMon
work cooperatively you can actually TELL SysMon to jump to TempleMon when
certain OS calls are made. ga

<[Host] MIKE-ALLEN> Hmmm.  Bud - any more? ga

<[Bud] B.CONNOLLY1> thinking...

<[Host] MIKE-ALLEN> Erin - could I use sysmon to figure out why the
Spectrum-Holobyte games don't work on my MSTe? ga

<[Erin] E.MONACO> I'd be willing to bet that you could, especially if its
because of a bad OS call. If its just some weird code you'd locate it
using a debugger. ga

<[Host] MIKE-ALLEN> I think it is a bad mouse or event handler call.
Where in the auto folder does SysMon reside? Keith ga

<[Keith] K.GERDES> SysMon can be run at any point in the AUTO folder.
Since it takes up quite a bit of memory, I just run it from the desktop
when needed.  GA

<[Host] MIKE-ALLEN> Doesn't have to run before or after Warp9 or geneva?
ga

<[Keith] K.GERDES> Shouldn't require any special run order.

It even has a provision for de-installing if you run it from the desktop.
GA

<[Host] MIKE-ALLEN> That's great.  I'm gonna have to try it.  I wanna
look at the Speedo calls in Atari Works and see why I get the Black Page
Syndrome!

<[Erin] E.MONACO> SysMon/Geneva/Warp_9 doesn't work... at least for me..
3 bombs. ga

<[Host] MIKE-ALLEN> Anyone else have any questions before we let our guests get
some sleep?

<[Bud] B.CONNOLLY1> I'm sure we could go all night Mike, but I need some
sleep myself. 6:00 am comes pretty early! <G>

<[Host] MIKE-ALLEN> <me too, Bud>

<[Host] MIKE-ALLEN> Guess not.  Closing comments Erin? ga.

<[Erin] E.MONACO> In closing... SysMon is VERY handy, well worth the time
to learn and use. ga

<[Host] MIKE-ALLEN> Keith? ga

<[Keith] K.GERDES> GA

<[Host] MIKE-ALLEN> hehe

<[Host] MIKE-ALLEN> Scott?  GA.

<[Scott @ SDS] S.SANDERS2> Both programs are very handy. I can't wait to
see something running under MultiTOS such as Spy under Windows. Oh well.
ga

<[Host] MIKE-ALLEN> Thanks to our guests, Erin, Keith and Scott.  I'm
gonna have to try Sysmon for sure.

<[Bud] B.CONNOLLY1> Thanx Erin, Keith and Scott. You've given me some
useful information, now I'll just have to dive in and try 'em out!

<[Host] MIKE-ALLEN> Capture buffer off.  Rabble time.

                      Wednesday Night Real Time Conference

                              February 3, 1994

                          Host - Larry Duke



<[Temp Host] LARRY.D> I'm gonna be eating pizza while typing.  If you see
some cheese on my text, you'll understand....

<[John too] J.G.H.> hehe....and drinking Jolt and smoking cigarettes?

<[The MadMan] W.JONES43> Keith!  Long time no chat!

<[Temp Host] LARRY.D> As the room slowly fills.....

<[John too] J.G.H.> isn't that the programmer's diet?

<[Temp Host] LARRY.D> It is for me.  Went to the dentist today, and I'm
dying to try out this new cap.  I may also type a bit hard to understand,
considering the Novacaine....

<[Bill] W.JONES43> Forgot I was being the programmer type tonight! <grin>

<E.MONACO> \nam Erin

<E.MONACO> ack!

<[John too] J.G.H.> ack...ack

<[Temp Host] LARRY.D> We knew who you were anyway, Erin...

<E.MONACO> ok... never mind then! :)

<[Bill] W.JONES43> I finally got a Thursday off work - haven't been to
this particular RTC before.  What type of programming are we discussing?

<[Temp Host] LARRY.D> All types, Bill.  C, Assembly, GFA BASIC, whatever
you want to....

<[John too] J.G.H.> Larry is tonight's "Special" host, Mike is busy
tonight

<CBARRON> gee, thats a wide area<grin>

<[Bill] W.JONES43> Ah - PureC's my favorite environment.  Hisoft BASIC
for quick and dirty hacks.

<[Temp Host] LARRY.D> You don't want to join us, Rob? (Rob's hiding in
the other room)

<[John too] J.G.H.> I am currently playing with M.A.G.E. and GFA

<[Bill] W.JONES43> John, is M.A.G.E. a toolbox for GFA or library
routines?  Could it be interfaced to C?  The results I've seen look
pretty impressive.

<E.MONACO> I can't stay long but Mike wanted us to define our objectives
for the next homework assignment a little better.

<[John too] J.G.H.> It is a Graphics Engine and I think it currently only
works with GFA of course you can use C in GFA so it probably is possible

<[Bill] W.JONES43> Did my time with STOS - very nice results if you have
LOTS of patience.

<[Temp Host] LARRY.D> True enough, Bill.  Interesting language, isn't it?

<[Bill] W.JONES43> Yeah, but I don't own GFA and can't get a lead on 4.0.
The 2.0 version crashes BADLY on my TT.  OTOH, PureC's editor is a dream
in TT-Med res.

<[Temp Host] LARRY.D> I'm using GFA 3.6TT Bill.  Works great in all
resolutions (including 1280*960)  Of course, the guys at GFA will swear
up and down there is no 3.6, but that's what mine says....

<[John too] J.G.H.> Also MAGE comes with the latest version of GFA BASIC
Interpreter, compiler and assembler on disk

<[Bill] W.JONES43> Larry - yeah I heard that from them too.  Actually
they told me _NO_ version of GFA was TT compatible.

<E.MONACO> It'd be nice if they offered a version of M.A.G.E without GFA
for those who already own it.

<[Temp Host] LARRY.D> Naw - they are the ones that sold it to me.  I
think anything after 3.6E is TT compatible...

<[Temp Host] LARRY.D> Back from lurking, Rob?

<[/dev/null] R.ANISKO> unlurked... how is everyone tonight?

<[Bill] W.JONES43> Larry, programs _written_ in 3.5E MAY be TT
compatible.  All depends on how you set the fastload and TT-RAM bits.
I've gotten a few to work well.

<[Temp Host] LARRY.D> I see that Carl uploaded homework for this one.
What was the actual assignment?

<[carl] CBARRON>  Re: Homework, good idea, how complicated a editor are
we 'eventually' writing?

<[Bill] W.JONES43> As long as the author stayed away from the RESERVE
command.

<[John too] J.G.H.> I know programs using MAGE don't like screen
accelerators

<[Bill] W.JONES43> John, actually Dark Pearl plays fine here with NVDI on
the TT.  Too damn fast to get past the first few inches of the board, but
it _DOES_ run!

<[Temp Host] LARRY.D> Bill - The earlier versions of GFA have a little
problem with their MENU S$ command - it always defaulted to an 8 pixel
height character.  TT resolutions made the menus terribly compressed and
overwritten.

<[carl] CBARRON> I did?  I have an incomplete one on my HD. Perhaps that
was the first assignment Mike's looks a little more structured, this
time.<grin>

<[Bill] W.JONES43> Larry - THAT'S what caused that.  Always wondered
about it.

<[John too] J.G.H.> I just turn off my warp 9

<[Temp Host] LARRY.D> Even earlier versions of GFA will still run if you
use 24BIT.PRG in the auto folder.  They stored additional info in the
upper 8 bits of the addresses.

<[John too] J.G.H.> MajicSoft also have BUTTONZBASIC a GUI shell for GFA
which makes things easier ;>

<[Temp Host] LARRY.D> I use GFA for things quick and dirty.  For real
programming, I use DEV PAC TT.  I gotta upgrade to 3.0 soon....

<[Bill] W.JONES43> Larry - actually I use PMMU.  Nicer, fixes a couple of
mapping problems for games that ask for the ROM version directly and
doesn't require a keypress if you have it in the auto folder.

<E.MONACO> Our assignment was to write a simple windowed editor that
would edit one windows worth of information.  Just do simple stuff like
cursor movement, insert, delete.  If you wanted you could add a resource
contianing a menu with info & Quit.

<[John too] J.G.H.> I am trying to get the folks from MajicSoft on GEnie
for an RTC

<[/dev/null] R.ANISKO> I have a quick "C" question if anyone could answer
it?

<[Bill] W.JONES43> Shoot, Rob...

<E.MONACO> I don't think anybody got into the editing part of it yet. I
didn't.

<[carl] CBARRON> where are we going with this editor?  I have some gap
buffer code, I might use if this is really an editor.  I do use Lattice C
and misc. unix tools ported to ST/TT.  If this is going to go no place a
simple arrangement is possible without

<[/dev/null] R.ANISKO> real simple (but i haven't figured it out) - how
could I simply write a  ?

<[/dev/null] R.ANISKO> oops. hang on...

<[Temp Host] LARRY.D> That sounds like a very adventurous homework
assignment....

<[carl] CBARRON> without any real editor code.

<[/dev/null] R.ANISKO> how can I ask for a keypress and treat it as a
hotkey - that is, take the keypresss and act *without* needing to hit
RETURN? in "C" that is

<[Bill] W.JONES43> Which C are you using?

<[/dev/null] R.ANISKO> GCC

<E.MONACO> How far I am not sure, we had talked about adding maybe load
and save, search and replace, things like that in later assignments.

<[Bill] W.JONES43> Oh - in your TOS binding you'll find int Bconin(int
port).  Use port 2 for the keyboard.  Inputs 1 character from device.

<E.MONACO> "How far" is something we can address now.

<[/dev/null] R.ANISKO> ok - will have to "grep" my header files and see
what asscoaiets (associates) to it (typos tonight)...

<[Bill] W.JONES43> Rob - or to be more "general", get(stdin) also works.

<[Temp Host] LARRY.D> Is anybody having problems with the homework
assignment so far?

<[/dev/null] R.ANISKO> hmm, Bill, get(stdin) and not stdin(  (oops)
getch(stdin) or getchar(stdin)?

<[Bill] W.JONES43> Rob - getch(stdin) in GCC.  PureC has a couple of
shortcuts.

<[/dev/null] R.ANISKO> which Programming RTC had the latest and greatest
description of the homweork? maybe i'll write myself an online
spell-checker :-)

<E.MONACO> Was it 6th of Jan?

<[carl] CBARRON> Ok if we are going to do something with it sometime, I
will play with a gap buffer.  Got the generic code for one.

<[/dev/null] R.ANISKO> which file transcript though?

<[Keith] K.GERDES> I think the description was uploaded to the Topic.

<[/dev/null] R.ANISKO> ok - will see if i can capture the info later...

<[John too] J.G.H.> I will go look for ya ;>

<[Temp Host] LARRY.D> You know, writing an editor is something I've
wanted to do for a long time.  I am by no means a professional
programmer, and my little mind doesn't come up with any creative thoughts
on buffering ideas.

<E.MONACO> I believe Keith is right, it should be in the Topic.

<[Bill] W.JONES43> Rob - if you're programming TOS style and don't intend
to port your code, use TOS for all it's got.  Your code will be faster.
You need to list out your BIOS.H, GEMDOS.H and other headers and just
prowl around.

<[/dev/null] R.ANISKO> i wrote a simple editor under microsoft-c some
time ago - might have to steal some of my old code (unfortunately it's
not Atari code :-(

<[Temp Host] LARRY.D> What is the best way to do this?  A gap buffer, I
realize is what is needd, but how should each line be stored in memory?
After an edit, should the entire document be reformatted in memory and
the inserted in the proper place? (that should read "the LINE inserted in
the proper place.")

<[/dev/null] R.ANISKO> ph well, will try to hack around sometimes this
week - i need to go now though - maybe see yunz at the brodie rtc...

<[John too] J.G.H.> here it is ;>
hmmmmm....

<[Bill] W.JONES43> Larry, shouldn't an editor insert 1 character at a
time and reformat as quickly as possible?  Otherwise you can't see what
you're doing until you finish the line!

<[John too] J.G.H.> well if anyone else needs the info on the homework
here it is

Number: 31565  Name: PRGRTC04.ARC
Address: MIKE-ALLEN                Date: 940108
Approximate # of bytes: 10496
Number of Accesses: 54  Library: 13

Description: Transcript of the 4th Programming RTC held on 6 January,
1994.  Comments and reviews of the 1st homework assignment.  Second
homework assignment defined.

<[carl] CBARRON>  A gap buffer keeps the free space of the buffer at the
insert point. Pointers to the start of lines, with lengths is one
approach to lines.

<E.MONACO> I'd planned on doing its something like that.  Not worrying
about wrapping or stuff like that.

<[Bill] W.JONES43> Carl - I like that concept.  Easy to implement too.  I
guess since I wasn't in the original "assignment" RTC I should hush now,
though... <smile>

<[carl] CBARRON>  Easy but not that easy, when all the possibilities are
considered. Have DDJ's C source on that someplace.

<[Temp Host] LARRY.D> So, you basically just have an array of addresses
for the start of each line?

<[Bill] W.JONES43> Carl, is your line size defined?  If so, then you
don't need pointers to the start of each line unless your trying to
conserve memory.

<[Temp Host] LARRY.D> It would be relatively easy if all lines were a
given length, but how do you work with variable line lengths, and edits
that extend over 1 line?

<[Bill] W.JONES43> Any of you ever been on a BBS using FidoDoor?

<[carl] CBARRON> That is the only real approach. It also complicates the
gap buffer approach some as the start of a line in the buffer is
variable.  A gap buffer is going to move lots of text variable lines get
the most out of a fixed amount of memory and reduce the 'mallocs'
involved for long lines.  The one thing I hate about some editors is a
line max. Some as small as 100 characters.  terrible for editing ascii
text files....

<[Bill] W.JONES43> Larry, why would an edit extend past one line?  You'd
have to make changes character by character or the user wouldn't see the
results as they typed.

<[carl] CBARRON>  Search and replace will edit in more than one character
at a time...

<[Temp Host] LARRY.D> Here's my thought, Bill (it's probably really
screwed up, and I'm hoping somebody can set me straight)....

<[Bill] W.JONES43> Carl, I see your point.  Yes, then you'll have to have
pointers to the start of each line and your search routine will have to
ignore whatever you're using as an EOL marker.

<[Temp Host] LARRY.D> Each character is displayed when it's entered, and
the text is stored in a temporary buffer.  Once ENTER, an arrow key, or
something like that is pressed, the contents of the buffer is dumped into
the TEXT buffer and stored.  That way, you could have an UNDO function
really easily.

<[Bill] W.JONES43> But the gap concept isn't totally off.  Insert or
modify the necessary text, then increment/decrement the line pointers
after the modified line by the changed length if any, then redraw.
Larry!  I'm gonna have to do something like that in MY editor (for real
editor, not this project).  So obvious it never dawned upon me.  I have
an undelete line function, but not an undo right now.

<E.MONACO> I'd planned on going pretty much the same route.

<[Bill] W.JONES43> Actually, it'd be easier just to have a "twin" of your
real text buffer - when they hit your "hot" keys, copy it back to the
"real" buffer.  Always display the "twin" on screen.

<[Temp Host] LARRY.D> If you insert text, the TEXT buffer would then be
reformatted with the new text inserted in the right place.  It would take
LOTS of memory moves to create the text buffer in a sequential order.

<[carl] CBARRON>  Larry that is one approach useful in reducing memory
moves of a gap buffer as well.  Bill, all lines after the edit as well
will move with a gap buffer.

<[Bill] W.JONES43> Carl, yes - I meant to modify ALL the line pointers
after the affected line.  Inserting text requires 1 memmove() call.
Carl, maybe I don't follow you.  You have a SECOND area of memory for
your gap buffer?  Why not just create the gap in your REAL text buffer?

<[carl] CBARRON> memmove is ok, but with a project like this and a 680x0
a better approach is to move longs if possible, providing the size of the
move is bigger than 16 bytes.

<[Bill] W.JONES43> That's the way Bryan Hall and I did it with FidoDoor.

<E.MONACO> Would using the blitter speed it up?

<[Temp Host] LARRY.D> My experiences with the Blitter are that it's not
quite as fast as straight assembly moves....

<[Bill] W.JONES43> Carl - true.  And YES, blitted moves will make it FLY,
but only if you're moving 16 bytes or better.  But sheesh, how fast are
you expecting someone to type? Larry, but this isn't being coded in
assembly, is it? Or does the language matter?

<E.MONACO> Using longs you have to insure that your working on even
addresses, and on the newer 680X0's using a longword boundry will speed
it up even further

<[carl] CBARRON>  A gap buffer moves the 'free area' to  the insertion
point any time the text is changed.  If you use a simple edit approach in
a second buffer then insert it onta return or cursor movement.  Moving
64k or 128K at a time to insert one chara cter is slow....

<[Bill] W.JONES43> Carl, okay - but for display purposes you need have a
pointer that say which line is currently held in the gap buffer and its
location.  Also that makes you have a size limit on edits, correct?

<[carl] CBARRON> No, you write the text SKIPPING THE AREA OF THE GAP
buffer. It is constantly changing in location BTW.

<[Bill] W.JONES43> Carl, now I'm confused.  Don't you want to display the
changes they're making AS THEY MAKE THEM?  Otherwise you won't know if
you made a typo until you move the cursor.

<[carl] CBARRON> Well it is confusing to talk in three lines. A gap
buffer is a block of unused memory that is moved to where it will be
used. If you set the pointer of the current line to an input buffer, no
problem, it will display the input buffer.  It is possible in design,
details are not infront of me. As we are seeing this is not as simple as
first appears....

<[Bill] W.JONES43> Carl, okay.  That's what I meant.  Display all
unchanged lines PLUS the gap buffer they're currently typing.  Something
I've been meaning to add to FidoDoor, in fact to speed up its redraw
speed.

<[Temp Host] LARRY.D> I honestly thought this was an ambitious project
for this early in the Programmer's RTC life - it may well be over the
heads of most people (me included)

<[carl] CBARRON>  over heads, only if thinking past the 'design specs' of
the assignment. I do think, it should be in pieces myself.  After years
of reading, I am often lost myself....

<[Temp Host] LARRY.D> Can we redefine the assignment?  Has anybody got it
handy?

<[carl] CBARRON>  for the assignment an array of say 500 byte lines is
more than sufficient, as it stands.  512 makes more sense <grin>

<E.MONACO> Carl, for some people even working with GEM is totally new.
Why don't we just concentrate on opening a window with a title and close
box if thats not enough we could do a displayed cursor that can be moved
with the arrow keys.

<[Temp Host] LARRY.D> That's not a bad idea.  I personally would be
intimidated by an assignment to write an editor like this.  I could,
however, write something that opened windows, reacted to all of the
window commands, etc.  I could then take THAT knowledge and use it later
for a project like this.

<[carl] CBARRON>  Gem text is something I hardly ever do. Fine we can
open a window, clear its contents and redraw it. That is essentially what
my shell is doing.

<[Temp Host] LARRY.D> Still, I'm a little unclear as to the actual
assignment.  I realize it's a text editor in a window, but with INSERT,
DELETE, and stuff like that? Just writing the cursor control portion
would be a relatively long project...

<[carl] CBARRON>   Supposedly, eventually...  Cursor control with mouse
or just gadgets and cursor keys???

<E.MONACO> It shouldn't be that hard.  You need routines that will turn
the cursor on and off and adjust its onscreen position.  I'd like to see
mouse control.  That'd be a nice feature and not to hard to implement
once the regular routines are in place and working correctly.

<[carl] CBARRON>  a small box drawn in xor mode over the text is the
normal way to draw a cursor. removal is the same as drawing...  thought
lag....

<E.MONACO> Keith, what do you think?

<[Keith] K.GERDES> I sent Mike email a couple weeks ago about starting
out small and working the way up through the AES ladder.

<E.MONACO> I believe thats the best way to procede.

<[Keith] K.GERDES> The project as it stands is way too ambitious IMO...

<[tony] T.SMOLAR> hello everyone

<[Temp Host] LARRY.D> I think that's a good idea, Keith.  The first
assignment was to check the computer status and display it on screen.
Now, why not do the same thing in a window? Hiya, Tony.  We take what we
already know, then build up slowly.  Next time, we add resources.  The
time after that, we add something else, etc...

<[tony] T.SMOLAR> I was wondering if anyone could help me, I'm having
problems getting GNU C working

<[Temp Host] LARRY.D> Pretty soon, we've done every call in standard TOS,
and we can then start with the extended calls of MiNT, etc....  Shoot,
Tony - I can't answer, but there are people here that probably can.

<[carl] CBARRON>   Not a bad idea, KISS there are a lot of people with
not a lifetime to devote to a project.<grin>  Structured design helps a
lot....

<G.SIMUNOVICH> I've got GNU C up, what's the matter.

<[tony] T.SMOLAR> I'm trying to get GNU C working with either Gulam, or
GNU BASH, preferably BASH But when we try to use the compiler, it seems
like it can't find something\

<E.MONACO> I have to go... so are we just going to worry about getting a
window up and handling that?

<[Temp Host] LARRY.D> Eric - that's my preference.  Of course, I'm just a
small player in a big band...  Oops - EriN

<[carl] CBARRON>   Erin, looks like you are right.  I don't think mike is
ready for a full editor at this time either....

<E.MONACO> I like the stats in a window idea, but have already done that,
I suppose I could add to it though.

<[Temp Host] LARRY.D> George, any ideas on how to help Tony?

<G.SIMUNOVICH> How about a text viewer in a window???

<E.MONACO> I agree, I've done alot on my project but at the expense of
getting other work done, I'd like to see it toned down a bit. :)

<[Temp Host] LARRY.D> That's not a bad idea, George.  No editing, just
viewing, etc...

<G.SIMUNOVICH> Depends on what it cann't find as to the problem,
environment variable probably.

<[carl] CBARRON>   About GNU C sounds like some environment strings are
wrong. I don't use gnu C  so the specifics I don't have...

<[tony] T.SMOLAR> I have GCC set up (in gulam) as per the "Quick Start"
instructions.

<E.MONACO> Okay.  Take care everyone.

<[Temp Host] LARRY.D> After this, we could add SEARCH capabilities, then
menu's to load, etc...

<G.SIMUNOVICH> 3 variables are needed GCCEXEC "setenv GCCEXEC
d:/<path>/gcc-" GNUINC "setenv GNUINC d:/<path to includes>" GNULIB
"setenv GNULIB d:/<path to libs>"

<[Temp Host] LARRY.D> Tony - does that sound like it will work?

<[tony] T.SMOLAR> Could the problem be that I am using "\" pathname
separators instead of the UNIX-like "/" ones?

<G.SIMUNOVICH> with GCCEXEC the "gcc-" is needed as it prefixs the
executable needed "ld", "as", etc with the variable.  This assumes the
executables are named "gcc-ld", "gcc-as".  Tony, it should not "/" & "\"
are the same for most GNU and public domain thing.

<[tony] T.SMOLAR> Can someone tell me more about "UNIXMODE" under Bash?
How do I set Bash up to work with it?

<G.SIMUNOVICH> Also, instead of "d:/<>" you could try "/dev/d/<>", these
programs treat both as the same.  Tony, you can send me mail if this
doesn't work, include what errors are produced, etc and I'll reply.

<[tony] T.SMOLAR> Thanks.

<[Splat!] DMJ> Hello...

<G.SIMUNOVICH> UNIXMODE is to complex to explain here, but I'll send you
some docs I have.

<[carl] CBARRON> Da fun of 'cheap' software.... <grin>  Written for unix
masters... <grin>

<[tony] T.SMOLAR> Ok, I'll give that a shot, thanks for the help.  and
I'll look forward to that doc file.

<G.SIMUNOVICH> Written to get UNIX things working ok on the Atari.

<[Splat!] DMJ> So what's all the discussion about tonight?

<[carl] CBARRON> True, you don't happen to have berkeley yacc 1.9
compiled?

<[Splat!] DMJ> (And _don't_ ask me if I did my homework...)

<[Temp Host] LARRY.D> Damien, did you do your homework?

<[carl] CBARRON> What is the discussion? a) splitting the homework, b)
how to edit text, c)other.

<[Temp Host] LARRY.D> (I had to do that)

<[Splat!] DMJ> I said not to ask me that! No, I didn't do my homework.

<G.SIMUNOVICH> No yacc here, just starting to get GNU stuff, damn they're
big.

<[Splat!] DMJ> I've _never_ done my homework, if I could get away with
it... ever since I started school.  Might explain why I nearly flunked
out.

<[carl] CBARRON> Just downloaded f2c (f77 to c) translator only 594K
compressed tar file.<grin>

<[Splat!] DMJ> Geez, tiny download...

<G.SIMUNOVICH> Just got CS-TeX, 4meg.  Ghostscript 1meg, thank god for
fast modems.

<[Splat!] DMJ> I could never get into UNIX-type tools.  For some reason,
they just don't appeal to me.  Carl, however, loves them...  So it's
probably just me.

<G.SIMUNOVICH> I got really hooked on Unix at school, I REALLY like suns.

<[carl] CBARRON> True but it might contain the code I need to write a
fortran file reader for my  c code..... They do work esp. sed/gawk....

<[Splat!] DMJ> I always knew I was warped.

<G.SIMUNOVICH> For my entire Atari setup I might be able to buy a CPU.<g>

<[Splat!] DMJ> Maybe if I'd had the chance to work on a Sun or other UNIX
workstation I might like it more.  But then again, my fondness for neat,
compact, _usable_ programs might get in the way... <g> Anybody see Keith
Gerdes' post about Missouri?

<G.SIMUNOVICH> "compact" would be really nice.

<[Temp Host] LARRY.D> Nope - he just left, though (actually, he was
disconnected)

<[Splat!] DMJ> Hmmm.  Maybe he knew I was coming.  I have a feeling we
might not be on speaking terms, soon.  (Sigh)

<[carl] CBARRON>   Small useable tools are the backbone of unix style
operations. this stuff is source and often underdocumented [for
'dummies'] documentation.

<[Splat!] DMJ> That depends what you call a usable tool.

<[Temp Host] LARRY.D> "If it was hard to write, it should be hard to use"
"Real programmers don't document" or comment their code....

<[Splat!] DMJ> For example, a program to display memory usage in a
windowed dialog, updated every five seconds or so...  How big, in C? I
must not be a real programmer, then.

<[Temp Host] LARRY.D> Big - in assembly?  Small...

<[carl] CBARRON>  Larry, that is the problem and they resent profesional
writers doing it for them!

<[Splat!] DMJ> No, how big would such a program be in C? i.e. how many K
is the executable.  Did I mention resolution-independent? Works as a
program or accessory? Is MTOS & Geneva aware? Includes an option to shut
off the five-second update thing?

<[Temp Host] LARRY.D> I'd say as a minimum it would be 18K (if you have a
good optimizing compiler)

<G.SIMUNOVICH> GNU C produces about a 15k file to do nothing (stripped).
Damn those huge libs.

<[Splat!] DMJ> Uses 100% legal GEMDOS and AES calls? Right now, mine is
sitting at 5K.  And it wasn't something I slaved at for weeks, either.

<[carl] CBARRON> Depends on the compiler and slim down startups. maybe
8-12K in LC5.

<[Splat!] DMJ> I didn't go to any great pains to make it small.  If I
had, I wouldn't have embedded a complete .RSC file in the program.  I
think I'm making an ass of myself here.  I should stop.

<[Temp Host] LARRY.D> Written in assembly, Damien?

<[Splat!] DMJ> Of course.  It will probably be ready by Saturday.  If I
didn't have to work tomorrow, it'd be tomorrow.

<[carl] CBARRON>   Size of the 'lib stuff' is signifigant only on small
student sized projects. a project like ldw power not so....

<G.SIMUNOVICH> Anyone know a a good RSC editor (recent) availiable???

<[Splat!] DMJ> That's true, Carl.

<[Temp Host] LARRY.D> You know, those are my feelings, too.  I write in
assembly, never learned C because of the terrible overhead.  I started on
a 16K computer, and have been very memory conscious ever since.

<[Splat!] DMJ> In a 100K program, who cares about a 10K library?

<[carl] CBARRON>  commericial - I use wercs.  Free ORCS works, but is not
3d aware, I do not believe.

<[Temp Host] LARRY.D> George - I have INTERFACE from GRIBNIF software.
It's really nice.  The new one from ATARI is supposed to be really nice,
too.

<SAM-RAPP> Hello.  Is this informal?

<[Splat!] DMJ> ORCS is not 3D aware, no.  It's what I use.  Yep,
informal.

<G.SIMUNOVICH> Not many people write 100K programs.

<[Splat!] DMJ> Really? Huh.  I'll keep that in mind when I try to keep
Sound Lab under 200K.

<SAM-RAPP> Can I ask a non-programming related question?

<[Splat!] DMJ> Won't bother _me_. <g>

<[Temp Host] LARRY.D> INTERFACE is really nice.  GRIBNIF hasn't finished
the English docs yet, and I hope to get those in the mail when it then
completed.  Nice RCS, though.  Next time you're in town, I'll be glad to
show you, George...

<[carl] CBARRON>  I got one 141K demo exec, will get bigger since I found
the problem. over 400K of source, I did not write...

<[Splat!] DMJ> Yeah, those demos are usually huge.  A lot of it is
because they use straight-line code, tho'.

<[carl] CBARRON> esp. when it is msdos code!

<[Splat!] DMJ> They get great speed by eliminating the looping overhead.

<SAM-RAPP> How can one use a WOrd Perfect file on an Atari?

<[Splat!] DMJ> Oh, MS-DOS code.  That's different.  That's always huge,
no matter what you do.  Use WordPerfect ST?

<SAM-RAPP> All I have is WORKS.

<[carl] CBARRON>  unsigned char foo[]={....}; stuff over 400K....

<[Splat!] DMJ> Even a 386 takes twice as many instructions to do the same
task as a 68000.  It's ridiculous.  I don't know AW, Sam... can't help
you.  Perhaps one of these other enlightened individuals?

<[Temp Host] LARRY.D> There is a program to convert Word Perfect to ASCII
somewhere in the library...

<SAM-RAPP> Where?  ;-)

<[Splat!] DMJ> Which would strip out all the formatting, but would be
useful if all you needed was the text.

<[Temp Host] LARRY.D> Are we talking WP 4.1 or a later version?

<SAM-RAPP> I dunno.  I FTPed some files off internet, and I THINK they
are wordperfect.

<[carl] CBARRON>   Its about 75% of the msdos side. On WP there is
program to translate wp5.2 files to something in the libs I downloaded,
but did no use....  internet, tex, or postscript is more likely....

<SAM-RAPP> The first two characters are "WP" and one line further down
says "NEC SILENTWRITER..." There is a lot of crappy formatting stuff
throughout.

<[Temp Host] LARRY.D> Yep - that's a WP file, alright.  Search the
library (item 3) for CONVERT and see if something shows up.

<[carl] CBARRON>  ok is probably a word perfect file. I'll let some
search the libs. It is less than a month old if I recall.  I can find it
if it's there!  Thanks.  I'm gonna go look!  Thanks! Bye!


/************************************************************************/
                        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) [phone].  --
-- 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      --==--==--      --
---------------------------------------------------------------------------



/************************************************************************/
             Shareware survey - for shareware authors only
             By: Albert Dayes
/************************************************************************/

 The survey will only be used for statistical purposes only.  It will not
 be used for any other purpose.  If you have any questions feel free to
 send me e-mail.

 Shareware Author's Name:
 Program Name:
 Program Type (game,application, utility):
 Date of first Release:
 Number of Registrations:
 Demo (Yes/No):
 Updated (Yes/No):
 Current Version:
 Suggested Donation:

 Fill out the above form and send it via e-mail to the editor.  Please
 send seperate forms for each individual peice of software.

 Send your filled out form via e-mail to any of the following addresses.

 CIS: 70007,3615
 GE:  AEO.1
 In:  [e-mail]

 The results will be in the next issue of AEO-PJ.

/************************************************************************/
                 Brain Stem Rotator
                 By: Russell Sasamori
/************************************************************************/

Problem: Implement !a&&c&&!d||a&&!b&&c||b&&d in C without using unary or
         binary operators.  a,b,c,d are integers holding boolean values.


/*-----------------------------------------------------------------------*/

A possible solution for the last Brain Stem Rotator (AEO-PJ #3) was sent
via e-mail.  The original problem is listed first followed by the
solution.

PROBLEM:

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


SOLTUION:

Albert:

Re: Roman numerals (and back), this does not quite meet your specs,
    but you might find it interesting.

Henry K. van Eyken


From "Fleabyte" Course, 1987
Written for Casio pocket computer


a.  From decimal system to Roman numerals:

           10 PRINT CSR3;"ROMAN NVMERALS", CSR5;
              "under 8999,"""
           20 GOSUB 500
           40 INPUT "Decimal number:",N
           50 IF N>= 8999 THEN 40
           60 FOR J=7 TO 1 STEP -2
           70 A=10^INT(J/2)
           80 B= INT(N/A)
           90 N=N-B*A
          100 IF J=7 THEN 150
          110 IF B=9 THEN PRINT Q$(J);Q$(J+2);
              : GOTO 190
          130 IF B=4 THEN PRINT Q$(J);Q$(J+1);
              : GOTO 190
          140 IF B>=5 THEN PRINT Q$(J+1);:B=B-5
          150 IF B=0 THEN 190
          160 FOR K=1 TO B
          170 PRINT Q$(J);
          180 NEXT K
          190 NEXT J
          200 PRINT ""
          210 GOTO 40
          500 REM *ENTER SYMBOLS*
          510 FOR I=1 TO 7
          520 READ Q$(I)
          530 NEXT I
          540 RETURN
          550 DATAI,V,X,L,C,D,M

    The last subroutine is for computers that have READ and DATA
    in their vocabulary.  For the others, the corresponding sub
    is:

               500 REM *ENTER SYMBOLS*
               510 R$="I":S$="V":T$="X":U$="L":V$="C"
                   :W$="D":X$="M"
               520 RETURN


My sources show evidence that different conventions existed - and,
indeed, still do as you may observe by comparing the Roman numeral
for four used for page or paragraph numbering with the four on the
face of a clock.  In writing a program we must make a choice.  The
program I made will print,  for example, 1496 as MCDXCVI, not as
MXDVI.  The number 49 will produce XLIX, not IL.  I gather that,
although MCDXCVI is acceptable, XLIX may raise eyebrows. You might
want to modify the program by adding or changing these lines:

                         30 F=0:$=""
                        110 IF B=9 THEN F=F
                            +2:$=Q$(J)+Q$(J
                            +F): GOTO 190
                        120 F+0: PRINT $;:$
                            =""
                        130 IF B=4 THEN F=F
                            +1:$=Q$(J)+Q$(J
                            +F): GOTO 190
                        200 PRINT $,""
                        210 GOTO 30

The symbol M for 1000 used to be written in a form resembling (I),
10000 like ((I)),  and 100000 like (((I))).  I have avoided these
symbols by declaring an upper limit of 8998,  probably naively so.
An  old sign for 5000 resembles I)), just as that for 500 looked
like I), which  has since become D.

A  subroutine places the Roman symbols in variables R$ - X$.  The
"J-loop" performs three distinct operations, which might well have
been placed in separate subs.  The first (lines 70 - 90) is to
extract from the given number the thousands first, the hundreds
next, then the tens, and the ones.  Lines 100 - 150 handle the
actual translation and the positioning of the Roman symbols.  The
"K-loop" (lines 160 - 180) counts out the number of each symbol to
be printed.  This exhibit may be helpful:

         Cause:

           Q$(7)  Q$(6)  Q$(5)  Q$(4)  Q$(3)  Q$(2)  Q$(1)
           M      D      C      L      X      V      I

       & Effect:

         If B = 9(000), line line 170 prints nine times M
         If B = 9(00),  line 110 prints Q$(5) + Q$(7): CM
         If B = 9(0),   line 110 prints Q$(3) + Q$(5): XC
         If B = 9,      line 110 prints Q$(1) + Q$(3): IX
         If B = 4(00),  line 130 prints Q$(5) + Q$(6): CD
         If B = 5, 6, 7, or 8, line 150 prints Q$(2) and
                  lets B = 0, 1, 2, or 3, and so forth.


b.  From Roman numerals to the decimal system:

The program for converting from Roman to arabic number writing is
a lot easier to make and to read:

                        10 PRINT "   BACK
                           FROM ROME",""
                        20 GOSUB 500
                        30 P=0:N=0
                        40 INPUT "Roman nu
                           meral",$
                        50 FOR I= LEN($) T
                           O 1 STEP -1
                        60 FOR J=1 TO 7
                        70 IF MID$(I,1)=Q$
                           (J) THEN GOSUB
                           400
                        80 NEXT J
                        90 NEXT I
                       100 PRINT N
                       110 GOTO 30
                       199 END
                       400 REM **CALC**
                       410 IF J>= P THEN P=J
                           :N=N+A(J): GOTO
                            230
                       420 N=N-A(J)
                       430 RETURN
                       500 REM **ARRAYS**
                       510 FOR I=1 TO 7
                       520 READ Q$(I),A(I)
                       530 NEXT I
                       540 RETURN
                       550 DATAI,1,V,5,X,1
                           0,L,50,C,100,D,
                           500,M,1000


/*************************************************************************/
            Software Development Conference and Exhibition
                      By: Albert Dayes
/************************************************************************/

Software Development (SD) is for continuing education of programmers and
product managers.  It offers many different classes including:

Aligning Information System Straegies with Business
Strategic User Experiences
Development Teams More Art than Science?
Modeling the Cost of Software Quality
21 Rules of Thumb for Shipping Great Software
Model-Driven Rapid Application Prototyping
Power, Politics and Developer Productivity
Why Settle for Late Software
ISO-90001: International Madness or Improving Methods
Reengineering Development for Object Oriented Software
Managing Design
Legal Protection of Software: What Works and What Won't
Introduction to C++ Virutal Functions
How to Develop GUI Design Standards and Methodology
Creating Best-In-Class Software thru Customer Centered Development
OLE 2.0 Component Objects
Introduction to C++ Exceptions and Pointers
Making the Move to C++
Strategies for writing Portable C code
C++ Class Design
C++ Programming Style
Compating Object Database Management Systems
Unix System Release (SVR4.2) 4.2 MP Security

This is only a very small list of the many classes that were available.  A
week's worth of classes is close to $1000 which is not too bad.  But for
3 days of Exhibits Only is $50 or for free.  After attending a few different
programmer related shows one will start receiving many offers for free
exhibit passes to the different conferences.

Many of my friends who attended the conference said it seemed smaller than
in past years.  But, even still they said the classes are always the best
part of the show.  Real world questions, and solutions to programming
problems.  There is approximately 200 classes to choose from and over
250 vendors exhibiting at Software Development this year.


      California, USA
          |
          |
          V

       |-------|
       |       |
       |       |
       \    * <---------- San Jose
        \        \
         \        \
Pacific   \        \
Ocean      \        \
             \        \
               -------

The show is also known for new product announcements and good prices on
software.  For example Computer Associates was giving away CA-Realizer
version 2.0 just for sitting through a 15 minute seminar.  Other booths
had drawings once a day for one free copy of their software as well.

Suddenly I heard shotgun blasts and screams coming from the middle of
the hall.  Rational was showing off ID software's game DOOM to show the
power of its DOS extender (breaks the 640K barrier, 32-bit flat model).
(You can find an interview with ID software in new magazine, Game
Developer.)  I can't wait to see it on the Jaguar.

Walnut Creek had several CD-ROMs on display including the new Atari
GEMini CD-ROM, (see a review of the GEMini disc earlier in this issue).
They also had an updated version of C User Journal CD-ROM which includes
all disks (thru 384) thru Dec 1993.

Speaking of CD-ROMs there will be a CD-ROM disc of all the proceedings of
Software Development (SD) conference available on CD-ROM.  The cost was
supposed to be around $50 or so.

The Programmers' Shop, Programmer's Paradise and ProVantage were raffling
off new software every hour or so, with T-Shirts were a being a big
favorite among show goers.  Watching people scrambling for flying T-shirts
was really a sight to behold.

I also found some good literature on RSA's security products which will
you find in this issue.  For a complete source code license is only a mere
$25,000.  Its similar to the price AT&T used to charge for Unix source code
too.  There are other software development kits available for under $500
that do not include complete source code.  Also some freeware kits are
available on internet as well.

There are always many programming related publications available for
no charge as well.  The list includes:

Software Development, Network Administrator, LAN - the network solutions
magazine, Windows/DOS Developer's Journal, Application Development Trends,
Microsoft System Journal, Windows Tech Journal, DBMS - Database &
Client/Server Solutions, Dr. Dobbs Journal, Unix Review, Embedded Systems
and a few others.

In addition to magazines there were several book publishers present
including MS Press, M&T books and QED/Wiley.  Show discounts were ranging
from 10 to 30 percent for most books.  M&T was giving away a free copy
of Al Steven's book C++ Database Developent (this was on the last day of
exhbits). Al Steven's writes the C column for Dr. Dobbs Journal in addition
to the several books he has published over the years.

There was heavy emphasis on MS Windows, which is expected.  And the big
fight was in C/C++ compiler area with Microsoft, Borland, Watcom and
Symantec going all out for the top prize (your money).  Borland had a daily
drawing to win a brand new CD-ROM drive.  You can never have too many of
those.

In addition cross-platform GUI libraries were being pushed very hard
as well.  With Zapp, XVT, Zinc and others going through the paces.  The
best thing about the show is you can see a demo, ask questions and play
with the software yourself.  Zapp encouraged new users to play with the
demos and ask any questions about their GUI library.  In addition to these
third parties Novell and Borland were pushing AppWare their new cross
platform GUI library.  Borland's OWL (proprietary GUI library) was
demonstrated with the new capability to generate AppWare code as well.
Microsoft was pushing Microsoft Foundation Classes (MFCs) for its portable
GUI effort.  These cross-platform libraries will allow one to use the same
source code on DOS, Windows, UNIX (Motif), Windows NT and Macintosh
platforms.

In addition to programming/management classes and exhibits are the parties.
This is another chance to win some more software in addition to talking
with more developers until the early morning hours.  This usually happened
from 8pm to Midnight on most nights.  The exhibit hours were from 11 am to
6 pm, Tuesday thru Thursday.

                          "Code or Die"

After several days of hype it was finally time to backup those comments
with real working code.  The C++/Visual Programming Superbowl brought
out teams of two people from MicroSoft, Borland and Symantec to code a
working Windows application within 45 minutes.

Each team was allowed to come in one hour before the event and load their
software on the machines (which were 486 DX2-66 machines with 20 megs
of ram).  Each monitor was projected on a big screen behind the participants
so everyone in the Ballroom could see.  The crowd was hushed as the
moderator told the teams to get ready.  The command go instantly got some
of the crowd screaming "Go Borland!"

The programmers were also allowed to use sample code included with their
compilers.  The moderator talked about Symantec's incredible progress on
their application (since Symantec never showed up).  Every 45 seconds a
scream "Go Borland!" ripped through the crowd.  The people screaming were
rewarded with T-Shirts that were flung over the crowd to reward the
screaming participants.

The moderator had fun with teams members telling them that their code
looked funny or took jabs at the companies themselves.  The jabs on the
legal problems centered on Borland's C++ v4.0 license agreement which was
a radical departure from all previous versions.  This has since been
changed but only after much ranting and raving in their forum on CompuServe.
The crowd reacted with glee but then moderator quickly reminded MicroSoft
about being compressed recently.  In reference to their latest loss to Stac
over data compression technology used in MS-DOS 6.

It was great to see the true development cycle (edit, compile, link, run) on
the big screen.  Almost everytime Borland was compiling their code there was
the typical "Go Borland" scream.  The Moderator made sure he commented on
the type of errors the teams were getting.  It was with great delight when
he commented on compiler or linker errors.  When MicroSoft made a small
mistake page after page of errors (maybe 100+ compiler errors) were the
result.  The crowd reacted as would sharks smelling blood with a lone
voice yelling "Go Borland!"

The pace increased as team members searched directories (some in vain)
looking for the special peice of example source code.  It was also a great
way for other developers to see how effective the IDEs (Integrated
Development Environments) that the companies had designed.  The screens
flipped quickly as team member copies blocks of code from the examples
to their application.  The "Go Borland" yell was much less frequent as
the count down to completion neared.

5-4-3-2-1 ... the last compile and link and it was over.  Then the
moderator read through the software specification, with each team to
demonstrate the feature for the judges.  A cheer would rise from respective
company employees when a company demonstrated working code.  When a
feature didn't work on MicroSoft's application according to the
specification, the moderator commented "The next release right?"  The
crowd responded with a loud OOOOOOOOOOOOOOOOOOhhhhhhhhhhhhh which soon
melted away into quiet laughter.  After the finally tally of points
Microsoft won by a narrow margin of five percent.

This contest was really great especially after some of those hyped stats
coming from both vendors.  It was fun watching someone else sweat bullets
trying to meet a deadline for a project too.  It was definitely the best
part of the show in my opinion.

If you ever get a chance to go to Software Development it is well worth it.
Even if you do not get to the programming classes themselves the exhibits
with all the free software and magazines is definately worth your while.

/************************************************************************/
             10 Tips From the Programming Pros
                    By: Albert Dayes
/************************************************************************/

On Compuserve (in the Atari Gaming forum) there was a discussion about
Atari's Laservideo game FireFox.  Based on the movie of the same name and
the only laser disk game Atari ever made.  This was 10 years ago, back
in 1984.

In the magazine Atari Connection (the magazine before it was renamed
Atari Explorer magazine) there was a review of FireFox and an interview
with Atari's corporate composer Jeffrey Gusman.  To quote from that
article "The Sound of Micros" by Michael Goodwin.

     Or, if you prefer, you can drop a coin into Atari's hot,
     new arcade game, FireFox, an interactive video-disk
     adventure for which Gusman wrote an astonishing, modular,
     30 part orchestral score that fits together in thousands
     of different ways to provide a seamless, pulse-stirring
     soundtrack regardless of which of the 120 path-choices the
     game takes.

That was a great game and they used a real orchestra too.  You would
have to hear it to believe how good it was.  Or even better, play it!

In the same magazine there are a few programming articles, but the one
on tips was very useful, and still is even though it's 10 years old.  So
below you will find a reprint of article from the Summer 1984 issue of
Atari Connection magazine.

             10    Tips From the Programming Pros
               hex

   Atari Advanced Games Groups Speaks Your (Computer's) Language.

TTTTTT AKE TEN COMPUTER PROFESSIONALS, each with diverse experience and
  TT   at least one successful video game credit.  Add the support of a
  TT   major hihg-tech company, ample facilities, state-of-the-art
  TT   hardware and the freedom to explore and create original software.

What you'd get would be a consortium like the Atari Advanced Games Group.

For the past 14 months they have been writing text adventures, creating
skill-and-action games, dreaming up entirely new electronic entertainment
forms for the coin arcades, home computers, and video game systems.  And
without the pressure of the marketplace -- the group's mandate was to
please itself, with Atari picking up the tab.  Even with the quality and
polish of the ensemble, Atari expected only 30 to 60 percent of their
projects to make it -- a respectable estimate given the vicissititudes
of the market.  Currently the group's score is a perfect three for three:
its first game Final Legacy has just been released, and slated to
follow is an innovative maze game and fully upgraded sequal to Star Raiders.

There's a lot of excited conversation around the games-group offices.  You
hear serious talk about magic rings, black holes, star fighters and their
mathematical representations.  Also lots of laughter and music.  An
appropriate tune would be "You Can Be a Star."  Sly Stone might have been
thinking of the Advanced Games Group.

When we asked the group for Ten Tips, we forgot they think in code.  What
we got was ten hexadecimal tips -- which translates into a few extra.
Not a baker's dozen, but a programmer's generous count.

1. Don't be afraid of criticism

Once you've developed a part of your program to your satisfaction, ask a
friend or someone you trust to take a look at it.  Listen to what is said.
Criticism is a very touchy subject with most people, but it does work -- to
your advantage.  Never forget, though, that it's your program.  You're
the final judge.

2. Be eclectic

A video game must put the player inside a world, not just in front of a
television screen.  A game designer must know more than just computers.
The more well-rounded you are, the more you draw from all the aspects of
this world, the better your game will be.

3. Learn Assembly Language

It's true that Assembly language is fast and memory-efficient, but the
real reason to learn it is that you'll never really understand how the
computer sees the world until you do.  If you're going to program for
real, why do it on a "mystery machine?"

4. Keep learning -- ask questions.

Programming in general, and game programming in particular, is a constant
changing process.  There's no such thing as "finally mastering it," the
way you might master, say algebra; so never try to conceal you ignorance.
Everybody needs help sometime.  When that time comes, realize it so that
you can get on with the job and your learning by asking.  Just make sure
you do learn, so you don't have to face that problem a second time.

5. Take chances and big risks

Yes, there are lots of people out there making Q-Bert clones, and some
of them are doing quite well, unfortunately.  But that's not why you got
into computing.  Why not experiement?  Try something nobody's done before.
This is still a new field, and big breakthroughs have been made by people
just like you.

6.  Get something running as soon as possible so you have feedback

Use whatever language you're most comfortable with, just to get a feel
for the program.  Don't worry about graphics or error-checking.  The
program itself may not be exactly what you want -- if fact it probably
won't; but you can't play-test a flow chart.

7. Know your audience

Any good programmer will make a memory map or sketch out screens
beforehand: so decide who your audience is.  Many programmers have set out
to write software without considering the user.  Before you write for other
people, talk to them; afterward, let them test it out.  Non-programmers
are not going to be satisfied with mediocre products, primarily because
they still think computers are magic.

8. Make it simple for the user

If the game needs complex commands, make sure the player can get by
without knowing all of them at the lower levels.  When someone buys a game,
he wants to play it, not wade through pages of print.(But read on.)

9. Read the manual again

It's very easy for programmers to get set their ways.  So many times we're
in such a hurry to use that new hard- or software that we only glace at the
instructions long enough to set it up--and sometimes not even that long.
Once you've got it doing what you initially wanted it to do, take the time
to see what else is available.  Why reinvent the wheel?  Programmers are
tool users.  When programming you're almost always working with hard- or
software developed by someone else.  But they become yours if you
understand them.

A. Clear the decimal flag.

Is this facetious? No! When you first learn Assembly language or experiment
with your Atari computer, its often convenient to access Assembly routines
from BASIC.  One problem that invariably occurs is that BASIC sets the
Decimal Flag when doing math functions, and doesn't tell you.  So your
program crashes and you spend hours trying to find out why.  So--clear
that flag whenever you use USR.

B. Throw it out

The time always comes when a routine tunrs into a mess.  First you try to
make it do too much.  Then you find a bug and you start rearranging things.
Finally you have no idea what's going on anymore.  That's the time to pull
out a clean piece of paper, get away from the keyboard, and break it all
down into smaller routines.

C. Choose your tools according to the job

No matter whom you ask for advice, you're the one who implements it. You're
the one who has to sit over the keyboard for hours or months on end so
choose the language, programming style, hardware and so forth that suit
the project--and you.

D. Take advantage of your computer

Today's machine have amazing sound and graphics capabilities.  The best
software(especially games) use every bit of these they can.  If you were
a quarterback, you wouldn't run a quarterback sneak every play; you'd
use every play you could devise, and all the players on your team.

There, we never even got to ten.  If you don't understand, see Tip 3.

[ Editor's Note:

The above article is Copyright (c) 1984 Atari Corp.  It originally
appeared in Atari Connection magazine, Summer 1984 Vol 4, No.2., pages
40 and 41.

Members of the Atari Games Group include Jim Morris, Robert Weatherby,
Mike Gurganus, Jack Ritter, Chris Horseman (group leader), Dave Menconi,
Steve Englehard, Eric Wilmunder, Dan Oliver and Rita Pless.

Back in 1984 the Atari 8-bit line was the only computer line Atari had.
So some of the comments are attributed specifically to that platform.

Permission is NOT granted for reproduction in any form other than this
issue of AEO-PJ.

]


/*************************************************************************/
                            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
RCS     = Resource Construction Set
RCS     = Revision Control System
SDK     = Software Development Kit
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

      The Standard C Library
      By P.J. Plauger
      ISBN 0-13-131509-9

Prentice Hall
Englewood Cliffs, New Jersey 07632
USA
[ CIS: GO PHCP ]



/***********************************************************************/
                             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++
* GFA BASIC
* 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.

/************************************************************************/