

     |||||| |||||| ||  || |||||| ||||||
     ||     ||     ||| ||   ||   ||
     || ||| ||||   ||||||   ||   ||||               Your
     ||  || ||     || |||   ||   ||
     |||||| |||||| ||  || |||||| ||||||             GEnieLamp A2Pro

     ||    |||||| ||    || ||||||                   RoundTable
     ||    ||  || |||  ||| ||  ||
     ||    |||||| |||||||| ||||||                   RESOURCE!
     ||    ||  || || || || ||
     ||||| ||  || ||    || ||


             ~ LATEST NEWS FROM THE A2PRO ONLINE DEVELOPERS ~
                   ~ RAMBLINGS OF A WANNABE PROGRAMMER ~
           ~ A2U SPRING SESSION CONTINUES WITH RESOURCE CLASS ~
                  ~ HOT NEWS ~ HOT MESSAGES ~ HOT VIEWS ~

 ////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
  GEnie Lamp A2Pro  ~ A T/TalkNET OnLine Publication  ~  Vol.1, Issue 03
  """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  Publisher.........................................T/TalkNET Publishing
    Editor-In-Chief........................................John Peters
     Editor.................................................Jim Couch

   ~ GEnieLamp IBM ~ GEnieLamp [PR]/TX2 ~ GEnieLamp ST ~ GEnieLamp A2 ~
       ~ GEnieLamp MacPRO ~ GEnieLamp A2Pro ~ GEnieLamp Macintosh ~
             ~ Member Of The Disktop Publishing Association ~
 ////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

          >>> WHAT'S HAPPENING IN THE APPLE A2Pro ROUNDTABLE? <<<
          """""""""""""""""""""""""""""""""""""""""""""""""""""""
                             ~ April 1, 1993 ~

 FROM MY DESKTOP ......... [FRM]        A2PRO ROUNDTABLE STAFF . [DIR]
  Notes From The Editor.                 Directory.

 HEY MISTER POSTMAN ...... [HEY]        DEVELOPER'S CORNER ...... [DEV]
  Is That A Letter For Me?               News from A2Pro Developers.

 RAMBLINGS................ [RAM]        A2U CAMPUS CHAT ......... [A2U]
  Ramblings of a Wannabe Programmer      A2 University:Learning Online.

 ONLINE LIBRARY .......... [LIB]        LOG OFF ................. [LOG]
  April is Tech Note month!              GEnieLamp Information.

[IDX]"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

READING GEnieLamp   GEnieLamp  has  incorporated  a  unique   indexing
"""""""""""""""""   system to help make  reading the  magazine easier.
To  utilize this system, load GEnieLamp into any ASCII  word processor
or text  editor.  In the index  you will find the  following  example:

                   HUMOR ONLINE ............ [HUM]
                    [*]GEnie Fun & Games.

   To read this  article, set your  find or search command to [HUM].  If
you want to scan all of the articles, search for [EOA].  [EOF] will take
you to  the last page,  whereas [IDX]  will bring you back to the index.

MESSAGE INFO   To make it easy for you to respond to messages re-printed
""""""""""""   here in GEnieLamp, you will find all the information you
need immediately following the message.  For example:

                    (SMITH, CAT6, TOP1, MSG:58/M475)
        _____________|   _____|__  _|___    |____ |_____________
       |Name of sender   CATegory  TOPic    Msg.#   Page number|

    In this  example, to  respond to  Smith's  message, log  on to  page
475 enter the bulletin board and set CAT 6. Enter your REPly in TOPic 1.

    A message number that is surrounded by brackets indicates  that this
message  is a "target" message and is  referring  to  a "chain"  of  two
or more  messages that are following the same topic.  For example: {58}.

ABOUT GEnie   GEnie costs only $4.95 a month for  unlimited evening  and
"""""""""""   weekend  access  to  more  than  100  services   including
electronic mail,  online encyclopedia,  shopping,  news,  entertainment,
single-player games,  multi-player chess and bulletin  boards on leisure
and  professional  subjects.   With  many other services,  including the
largest  collection of files  to download and the best online games, for
only  $6  per hour  (non-prime-time/2400  baud).   To sign up for  GEnie
service,  call (with modem) 1-800-638-8369.  Upon  connection  type HHH.
Wait for  the U#= prompt.  Type:  XTX99014,DIGIPUB  and hit RETURN.  The
system will then prompt you for your information. Need more information?
Call GEnie's customer service line (voice) at 1-800-638-9636.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""



[EOA]
[FRM]//////////////////////////////
                 FROM MY DESKTOP /
/////////////////////////////////
Notes From The Editor
"""""""""""""""""""""
By John Peters
   [GENIELAMP]




FROM MY DESKTOP   When I typed in the characters ATDT and the the number of
"""""""""""""""   a local bulletin board for the very first time, I was
completely and utterly awed.  No longer was I alone in my computing
pursuits.  At the touch of a key, I could call out to practically any place
in the world and make friends with people that I would have never had the
chance to do so with otherwise.  The modem had broken my computing
isolation from the rest of the world.

     Ten years later, I'm still awed by it all, but now, even more so.  I
keep in touch with friends via GE Mail, I stay on top of what's happening
in the news with Newbytes and I can get answers to just about any question
I can think of - many times within hours of posting it.  I can share my
knowledge with others and more importantly, I can learn from their
experiences as well.  I can download pictures, sounds and books to read and
I can even play a friendly game of backgammon or chess with someone in
Boston, or Miami, or Japan.  Amazing.

     But it can be frustrating too...  When you think about it, we
"onliners" represent a very small segment of the overall population.
Surprisingly, there are many people who own computers are unaware of what's
available to them online.  They use the computer to type in an occasional
school report or (more likely) play games on it.  That's okay as eventually
many of these people will find their way online by way of a friend, an
article they read or because they are just plain curious (like I was).

     The point is, we've only just begun.  Think about it...we are in the
infancy of telecommunications.  In a way, I'm sorry I won't be around a
hundred years from now to see where all of this is heading.  On the other
hand, I am thrilled to be among the online pioneers of this _new_ and
exciting technology.  Welcome aboard, friend, and I'll see you online!


GEnie Elsewhere   Did you know that the Public Forum RoundTable (M545) is
"""""""""""""""   archiving all of the official White House Electronic
Press Releases issued by the new White House E-Mail Communications Office?
The files are available in the PF Library in the format WHPRxxx.TXT, and
there are currently 177 of these files available.  The files include press
releases, official announcements, transcripts of press conferences & other
official White House communiques.  Interesting stuff here - well worth
checking out!  For more info., contact GRAFFITI, the PF SysOp.


NEW 800 SERVICE   Some GEnie access numbers incur a $2.00 per connect hour
"""""""""""""""   communications surcharge.  This surcharge applies to all
GEnie usage, including GEnie*Basic services.  Surcharged access numbers are
noted with a dollar-sign ($) and the amount of the hourly communications
surcharge (i.e., $2.00/hr).  To retrieve local access numbers, please type
*PHONE or PHONE at any main menu prompt.

     When accessing GEnie via 800-Service (available only in the US), you
will incur a $6.00 per connect hour communications surcharge, for 300, 1200
and 2400 baud access.  This surcharge applies to all usage, including
GEnie*Basic services.

     9600 baud access is also available via 800-Service.  When using 9600
baud via the 800-Service, you will be charged $18.00 per connect hour
during non-prime time and $24.50 per connect hour during prime time.

 LOCATION            BAUD RATE       SURCHARGE    NETWORK    ACCESS NUMBER
---------------    --------------    ---------   ---------   -------------
United States       300/1200/2400      $6.00/hr    GEnie      800-362-1296
United States           9600          $12.00/hr    GEnie      800-847-5260

     When accessing GEnie via SprintNet, you will incur a $2.00 per connect
hour communications surcharge.  This surcharge applies to all GEnie usage,
including GEnie*Basic services.  Surcharged access numbers are noted with a
dollar-sign ($) and the amount of the hourly communications surcharge (i.e.
$2.00/hr).  To retrieve local access numbers, please type *PHONE or PHONE
at any main menu prompt.

PLEASE NOTE   If you are dialing long-distance to access GEnie, we do not
"""""""""""   recommend dialing a surcharged access number, as you will
incur the $2.00 connect hour surcharge in addition to long-distance
charges.  Also note that interstate long-distance calls are usually less
expensive than intrastate long-distance calls.  Please be sure to verify
the long-distance charges with your local telephone company.

                               [*][*][*]


GEnieLamp FUN AND GAMES   This is one big issue so I'm going to keep my
"""""""""""""""""""""""   desktop notes short this time around.  One word
of caution when reading this month's issue: Don't forget, it's April!

     Until next month...
                                                     John Peters
                                                     [GENIELAMP]



[EOA]
[DIR]//////////////////////////////
          A2PRO ROUNDTABLE STAFF /
/////////////////////////////////
By Jim B. Couch
     [J.COUCH2]

                           ____________________________________________

                           A2 PROGRAMMERS & DEVELOPERS ROUNDTABLE STAFF
       _____  ______       ____________________________________________
      /_____|/______\
     /__/|__|  ___|__|     Head Sysop:   Matt Deatherage  (M.DEATHERAGE)
    /__/_|__| /_____/      Assistants:   Steve Gunn        (A2PRO.STEVE)
   /________|/__/       __ __ __         Greg Da Costa      (A2PRO.GREG)
  /__/   |__|__/______ /_//_// /         Todd P. Whitesel (A2PRO.TODDPW)
 /__/    |__|________//  / \/_/


JIM MURPHY LEAVING A2PRO STAFF POSITION   Well, I'm sad to say it, but I'm
"""""""""""""""""""""""""""""""""""""""   announcing my resignation from
the A2Pro staff. I've had a great time helping this place to be as useful
and successful as it has become, but I just don't have the time to spend
here that being a sysop requires. Since I took a position in the Apple II
Continuation Engineering Group in January, about 95% of my waking hours
have been spent hacking on the IIgs System Software, and that has left
precious little time for GEnie (just ask Matt :-).

     I will still be here in A2Pro, just not as a staff member (many of you
are now asking, "Jim? On the A2Pro staff? Since when?" :-). It's been fun.
-Jim Murphy   (A2PRO.JIM [Murph'], CAT1, TOP17, MSG:68/M530)


A2PRO IS LOOKING FOR A NEW STAFF MEMBER     Jim?  On the A2Pro staff?
"""""""""""""""""""""""""""""""""""""""     Since when? <ducking>
He'll still be around, folks, because I live near him and I'll make his
life miserable if he's not.  :)

     However, it does leave us with an opening on the A2Pro staff for
someone who's familiar with GEnie, Apple II technical issues and
third-party developers.

     We need a staff member who can manage A2Pro's extensive list of
third-party companies who support developers right here for Apple II
programmers.  This person will be responsible for assisting companies in
providing support, including answering their GEnie questions and solving
GEnie problems for them.

     The new staff member will also be responsible for managing A2Pro's
beta-test service -- one of our best-kept secrets.  Right now, several
major commercial products are being beta-tested in private, hidden
categories right here in our own bulletin board (and libraries), and this
person will also be responsible for making sure those companies get what
they need. That includes inviting people into private categories and
libraries, helping people set up new beta-test services, and actively going
out to find great new products that we can help make better.

     In return, all connect time in A2Pro is waived, plus this person gets
invited to all the private beta-testing categories (except where legal non-
disclosures are required) and can help shape future Apple II software in a
powerful way.  You also get a few other benefits from Resource-Central,
like a free subscription to A2-Central.

     Interested?  If you have the time and the talent, you can help us make
a difference.  Send me your qualifications in GE Mail (M.DEATHERAGE) if
you've been waiting for this chance.

--Matt (I speak for myself, not for Apple)
                 (M.DEATHERAGE, CAT1, TOP17, MSG:70/M530)



[EOA]
[HEY]//////////////////////////////
              HEY MISTER POSTMAN /
/////////////////////////////////
Is That A Letter For Me?
""""""""""""""""""""""""
By Jim B Couch
    [J.COUCH2]

     o   BULLETIN BOARD HOT SPOTS

          o   A2PRO ODDS & ENDS

               o   WHAT'S NEW?

                    o   THROUGH THE GRAPEVINE

                         o   PROGRAMMER'S CORNER

                              o   HOT TOPICS

                                   o   MESSAGE SPOTLIGHT



                      >>>BULLETIN BOARD HOT SPOTS <<<
                      """""""""""""""""""""""""""""""

   [*]  CAT15,  TOP2,  MSG{41}...........................Memory Manager
   [*]  CAT15,  TOP34, MSG{56}.......................Text Edit Tool Set
   [*]  CAT34,  TOP3,  MSG{58}........................Ultra Programming
   [*]  CAT35,  TOP1,  MSG{8}.............Foundation General Discussion
   [*]  CAT36,  TOP11, MSG{83}...................................ORCA/C


                                 [*][*][*]


                         >>> A2PRO ODDS & ENDS <<<
                         """""""""""""""""""""""""

WELCOME TO THE APRIL ISSUE OF THE A2PRO GENIELAMP   In the spirit of April
"""""""""""""""""""""""""""""""""""""""""""""""""   Fools Day we have taken
our normally solemn Lamp and included just a few brief moments of levity.
keep an eye out for them!  While we have included all the great programming
information and tips we always feature I thought it would be fun to lighten
things up just a tad for this month.


WELCOME NEW WRITERS   I would like to welcome some new writers to the
"""""""""""""""""""   A2Pro GEnieLamp. Appearing in this issue is an
article by Larry Elseman [L.ELSEMAN1] who will be writing feature articles
for us on a regular basis. I would also like to welcome Nate Trost
[N.TROST] who will be starting next month as a staff writer. Nate will be
covering the A2Pro libraries, real time conferences, and A2 University. A
short introduction featuring Nate is a part of this month's lamp. I also
hope to have some other folks writing articles as well. Welcome aboard Nate
and Larry.


INTRODUCING NATE TROST!   Hello!  I'm Nate Trost, newest member of the
"""""""""""""""""""""""   A2Pro GEnieLamp staff.  As my first assignment I
get to introduce myself.

     My experience with computers began back in 1981 when my father bought
an Apple ][+.  Over the next few years I played games, slaved away at Zork,
and started tinkering with BASIC.

     The ][+ was replaced by a IIe in 1983, and then the IIe was traded in
for a Woz IIGS in 1987.  About the time we got the GS, I began to move from
BASIC into the realm of Pascal.  With much encouragement from my father, I
worked through the Instant Pascal tutorial.  Although archaic by today's
standards, most of what I learned about basic programming concepts came
from working with Instant Pascal.

     I began to develop an interest in GS programming and started to fiddle
with TML Pascal.  Then I discovered assembly, and life became a lot more
crash-prone.  :-)  By the time 1990 rolled around I was slowly becoming
familiar with 65816 programming and the use of the IIGS toolbox.  It was
then that I attended KansasFest for the first time and realized how much
there still was to learn!

     I kept plugging away and started messing around with IIGS animation
programming, which would later become my special area of expertise.  During
1991 and 1992 I continued to build on my skills, writing articles for 8/16
Central, developing programs for Softdisk G-S, teaching graphics/sound
programming at KansasFest, and just messing around with the II.

     Currently I am busy finishing high school, working part-time at
Argonne National Laboratory programming UNIX workstations, developing
software for Softdisk Publishing, and writing for GEnieLamp.

                                 [*][*][*]


WE WANT YOUR FEEDBACK!   I would love to hear from you all! I hope that the
""""""""""""""""""""""   A2Pro edition of GEnieLamp is meeting with your
approval. We need your suggestions, comments, ect to make the Lamp even
better. Drop me a line and let me know what you think! E-Mail your comments
to me at [J.COUCH2].

                                 [*][*][*]


WHAT TO DO WITH THOSE PESKY .SYM FILES?   Several people have mentioned
"""""""""""""""""""""""""""""""""""""""   they don't like the .sym file
sitting there with their source files, but I don't know where else to put
it. The problem is that the .sym file is needed right away, before the
first character of the source file is even read, so I can't depend on any
option set within the compiler.  Here are some of the options I looked at
and rejected:

     1.   Make the .sym files invisible.  I thought that would cause more
          problems than it was worth.

     2.   Use resources.  I was afraid that would mess up too
          many editors.  I was starting to reconsider after some
          recent editor resource discussions, but there were some
          pretty negative comments about using the resource fork
          for the .sym information.

     3.   Put them in some other directory.  But where?  This
          runs into all sorts of problems.

     I'm open to suggestions.  One additional though that I've had, and not
yet rejected, is using a shell variable to set the .sym file directory.
The default would be 8:, which is effectively what it is now, and you could
code any other path name you want.  -Mike Westerfield
                  (BYTEWORKS, CAT36, TOP11, MSG:57/M530)


HERE IS A .SYMPLE IDEA TO TRY   A couple of people have mentioned that they
"""""""""""""""""""""""""""""   don't like the .sym file cluttering up the
directory where their source is located.  After playing around with it this
weekend, I found a solution that I personally like.

     Most of us that do multi-file C programming use script files to do the
builds.  In your script file, right after each compile, insert a line more
or less like

   enable i foo.sym

     This makes the file invisible, and the CAT command generally won't
show the file.  There is a CAT command flag that will show invisible files,
or you could use

   disable i =.sym

to see them all again.  Of course, all of the GS/OS based commands still
work; you can copy, delete, or whatever, even when the file is invisible.

     Give it a try and let me know what you think. -Mike Westerfield
                  (BYTEWORKS, CAT36, TOP11, MSG:78/M530)


TELL ME A BIT ABOUT XMODEM   The following is a question a friend of mine
""""""""""""""""""""""""""   asked me to ask here on GEnie (and elsewhere)
regarding the Xmodem protocol.  Here it is (quoted):

 >Specifically, I want to know what they mean by "Block number character
 >in ASCII", and if that block number starts at 0 or 1.  Also, I need to
 >know how it calculates the checksum.

     Can anyone help him out with this question?   - Derek Fong
             (M.POTTER4 [AppleNET], CAT17, TOP2, MSG:10/M530)


XMODEM PACKET FORMAT AND CHECKSUM   In ASCII?  Hmmm  as far as I know it's
"""""""""""""""""""""""""""""""""   just a byte...  Packet format is: "01
xx yy [128 bytes] zz"   where xx is the block number (starting at $00) and
yy is 256 minus the block number (starting at $FF) and zz is the checksum.
The block numbers wrap back to $00 and $FF when you do more than 256
blocks.  The checksum is simply the sum of the [128 bytes] with any carry
discarded.  CRC is a little more complicated, and I don't remember the
formula off-hand, but I could look it up if you wanted it.
  _
 |_)avid
|\/|iller (D.MILLER132 [GTerm] [Dave], CAT17, TOP2, MSG:11/M530)


A SMALL CORRECTION   Packet format is: "01 xx yy [128 bytes] zz"  where
""""""""""""""""""   xx is the block number (starting at $00).  For
XMODEM, the block number starts at $01, goes to $FF, and then wraps around
to $00.  YMODEM transfers start at $00 (file information is passed in the
$00 block :-)   (JWANKERL [Joe], CAT17, TOP2, MSG:16/M530)


WHERE TO GO FOR MORE SPECIFICS   You can find source code to an Example
""""""""""""""""""""""""""""""   CRC-16 algorithm (The same one that XModem
uses) in the NuFX File Type Note. That's $E0/$8002. The new technical notes
aren't up in separate files, but I think that there may be a copy of that
File Type Note in the library separately.

     Plus if I remember correctly, there is a lot of source in the library
that has CRC checking in it.. do a search in the lib on CRC.

     Let me know if you can't find this stuff..  -Steve
                  (A2PRO.STEVE, CAT17, TOP2, MSG:13/M530)


AND A CRC CODE EXAMPLE IN C   The source code I've got is in C...  if you
"""""""""""""""""""""""""""   don't understand C, I can see if I can find
something else...

   /*
    * This function calculates the CRC used by the XMODEM/CRC Protocol
    * The first argument is a pointer to the message block.
    * The second argument is the number of bytes in the message block.
    * The function returns an integer which contains the CRC.
    * The low order 16 bits are the coefficients of the CRC.
    */

   int calcrc(ptr, count)
   char *ptr;
   int count;
   {
       int crc, i;

       crc = 0;
       while(--count >= 0) {
           crc = crc ^ (int)*ptr++ << 8;
           for(i = 0; i < 8; ++i)
               if(crc & 0x8000)
                   crc = crc << 1 ^ 0x1021;
               else
                   crc = crc << 1;
           }
       return (crc & 0xFFFF);
   }

     This was excerpted from a file called YMODEM.DOC, can't remember where
I got it from.
  _
 |_)avid |\/|iller
          (D.MILLER132 [GTerm] [Dave], CAT17, TOP2, MSG:15/M530)


GS/OS OPEN FILE LIMITS   >>> J.KRELL1 [Jay
""""""""""""""""""""""   > The ORCA/C docs say GS/OS is "limited" to 32767
                         > open files. Where is this documented?

     I never saw such a limitation documented; I think someone made it up
and Mike remembered it.

     There are limits in reality, of course -- right now, each open files
takes about 1K of memory, so on an 8 MB system there's a practical limit of
about 8000 open files.

     To date, this hasn't inconvenienced anyone.  :)
-Matt (I speak for myself, not for Apple)
                 (M.DEATHERAGE, CAT36, TOP11, MSG:82/M530)



                            >>> WHAT'S NEW? <<<
                            """""""""""""""""""

EDIT 16 V2.0 DELAYED   Edit-16 v2.0 is delayed a bit.  My fault (although
""""""""""""""""""""   this gives Bill some breathing space in the beta
testing)... The Manual isn't done!  We are now projecting a release toward
the end of this month.

 Marc "feeling harried" Wolfgram
 Lunar Productions
           (M.WOLFGRAM2 [Lunar Host], CAT35, TOP5, MSG:74/M530)


AS IS NAMOBJ   NameOBJ will be shipping soon..
""""""""""""   There have been a few things that are holding up NameOBJ's
release.  We expect it to start shipping later this month.
-Marc Wolfgram
Lunar Productions
           (M.WOLFGRAM2 [Lunar Host], CAT35, TOP6, MSG:18/M530)



                       >>> THROUGH THE GRAPEVINE <<<
                       """""""""""""""""""""""""""""


NEW ULTRA 4 INITS ON THE WAY?   Is there any truth to the rumor I hereby
"""""""""""""""""""""""""""""   start, that there is soon to be an
I.Claudius init? (:-)  -Roger
                    (R.MALTZ, CAT34, TOP3, MSG:50/M530)

>>>>>   Roger, I.DoubtIt  *^P
"""""   -Lorne
            (L.WALTON [Canucklehead], CAT34, TOP3, MSG:51/M530)

>>>>>   Lorne,
"""""   I.EmAshamed
        -Roger
                    (R.MALTZ, CAT34, TOP3, MSG:52/M530)

>>>>>   Lorne and Roger,
"""""   I.Dunno
        -Randy
                (BRANDT [Randy], CAT34, TOP3, MSG:53/M530)


 >>> BRANDT [Randy]

 > I.Dunno

     I.GetIt -- we need a new topic for Init Humor.  I.Laugh when U4 get to
talking like this.   -Will
                   (W.NELKEN1, CAT34, TOP3, MSG:54/M530)



                        >>> PROGRAMMER'S CORNER <<<
                        """""""""""""""""""""""""""

     This month we have a couple more opportunities for those who wish to
make some money programming. We also continue to present programming tips.
This time we present tips on Pascal, Ultra 4, using MaxBlock, and using
colors with text controls!


65816 ASSEMBLY PROGRAMMER WANTED   There's a small company in the Bay Area
""""""""""""""""""""""""""""""""   looking for a SNES programmer.  They're
willing to take a good IIgs programmer and train them. The game you'd be
working on is _VERY_ cool and the starting salary is somewhere around
$35-40K.

     They need someone NOW. If you're interested in this please send me
e-mail or call me at home (evenings/weekends) at 318-424-0263.  -Jay
                   (PUNKWARE, CAT13, TOP8, MSG:33/M530)


PHANTASM (AND TWILIGHT II) BLANKER MODULES WANTED   If you know IIGS
"""""""""""""""""""""""""""""""""""""""""""""""""   graphics programming,
why not contribute a blanker module for the new Phantasm blanker module
disk?  Check the library for details on writing Phantasm modules (which
will also work with Twilight II) -- if they're not there already, they will
be shortly.

     We are interested in buying these modules outright.  They should not
be too difficult to write -- you ought to be able to turn out two or three
in a weekend.  B) (QC [Jerry], CAT13, TOP8, MSG:34/M530)


PASCAL AND THE STACK   Range checking will make sure Pascal doesn't
""""""""""""""""""""   overflow the stack, but it can't check to see what
the tools are doing.  Unfortunately, there is no foolproof way to do so.

     Nesting procedures is fine, although it doesn't effect the stack space
one way or the other.  Using variables from one or two levels up may save
you a word or two of stack space, but it increases your code size by a lot
more than a word, and in some tight loops, it may noticeably effect
execution speed.

     For small stacks, these are the general rules:

     1.   Keep the number of local variables and parameters
          down, especially arrays.

     2.   Pass arrays as var parameters whenever you can, since
          the impact on the stack for a var array is 4 bytes,
          while the impact on the stack for a value array is
          4+sizeof(array).

     3.   Avoid recursion or deeply nested procedure/function calls.

     You should leave about 1K more on the stack than you need.  The tools
can generally live with this amount.

     ORCA/Pascal 2.0 also handles the stack a lot better.  It uses less
stack space to start with (Pascal 1.4.1 wastes about 4K), and procedure and
function calls have less impact on the stack.  Stay tuned...

     As for checking for eof being icky, it's a lot better, more portable,
and generally has less impact on speed and code size than handling through
SystemError.  As for the repeated calls to SystemError, that may just be
the file I/O system trying to read a line at a time or something. I can
look into that further if you like, but I'll need a complete program to
look at. E-mail would be the best way to get it to me.  -Mike Westerfield
                  (BYTEWORKS, CAT36, TOP10, MSG:39/M530)


HOW TO HAVE ALL 16 COLORS AVAILABLE IN TEXT CONTROLS   Recently I was
""""""""""""""""""""""""""""""""""""""""""""""""""""   talking to someone
about something (how's that for vague?) and we got on the subject of stat
text controls.

     He was mad at Apple for only allowing us to use purple and green
colors in stat text controls in 640 mode.  I said, "What?!? Don't you know
about the font flags?"  He said, "Huh?!?"

     To have all 16 colors available to your stat text controls, do this
after you create the window:

   myWindow = NewWindow2(....);
   if (NoErrors)
      {
      SetPort(myWindow);
      SetFontFlags(GetFontFlags() || 0x04);
      etc....
      }

     That'll allow you to use all 16 colors as expected...

     He was happy.  -Bryan
              (SOFTDISK.INC [Zak], CAT15, TOP16, MSG:57/M530)


MAXBLOCK DOES NOT LIE, BUT...   Someone recently noted in private that
"""""""""""""""""""""""""""""   MaxBlock was always returning about 20K
even though RealFreeMem returned about 120K and memory allocations were
always working, and wondered:

 > Does MaxBlock() really report the largest free block in memory, or does
 > the memory manager try to conserve memory by reporting large, but not
 > the largest chunk?

     MaxBlock does not lie, but it's not as useful as lot of people seem to
think.  You can have lots of little free spaces scattered throughout memory
and only one 20K block, and MaxBlock will return 20K even though the Memory
Manager may be able to satisfy a 30K request.  That's why Apple has always
told people to just allocate the block you want and not to preflight by
using MaxBlock or RealFreeMem.  It will work really hard to get you what
you want.

     OOM queue routines firing:  they'll always fire both times before any
$0201 error is returned, even for something that you logically know can't
work. Try allocating a one-byte absolute address handle in the middle of
your program code -- the Memory Manager will purge everything and call
every OOM queue routine in an attempt to get that one-byte handle, and will
finally give up when your fixed program code block doesn't go away.  See
Apple IIgs TN #78 for some more explanation in one specific case.

--Matt (I speak for myself, not for Apple)
                 (M.DEATHERAGE, CAT15, TOP2, MSG:50/M530)


HOW TO UNCACHE ULTRA 4 TASK FILES    >>>B.WEITHOFE
"""""""""""""""""""""""""""""""""    > Is there a way to unload or replace
 > an existing task  file in memory so that the corrected file would be
 > executed?

     Bob, I wrote the following macro that displays a list of Taskfiles in
memory, and allows you to pick ones that you want to "uncache".

    -- David --

 start

 <ba-u>:<all // pick cached macrosets to uncache
 .cls 2 :
 start = 50 : .cachelist start : end = 49 + z :
      //cached macrosets named in strings $(s) thru $(e)
 $40 = .pick 26,8,23,5,start,end,"Uncache Which Sets?" :
 TotalPicks = z //number of picks
 x = len $40: if x = 0 : oa-q rtn stop else :
 for i = 1 to TotalPicks :
      $1 = mid $40,i,1:
      x = asc $1:
      .uncache $(x) :
 next i :
 oa-q rtn>!

                  (D.THOMAS29, CAT34, TOP3, MSG:58/M530)



HOW DO I DETERMINE THE CAUSE OF CRASHES?    I have installed GSbug and the
""""""""""""""""""""""""""""""""""""""""   accompanying Loader Dumper on my
GS. These  tools came from the ORCA/M 2.0 disks.

     Occasionally, my system crashes into GSbug. I would like to determine
what is causing these crashes.

     What kind of information should I record so you can help me determine
what is going on?  Thanks.  -Glenn
              (G.W.HOFFMAN [Glenn], CAT5, TOP3, MSG:31/M530)


YOU CAN USE NIFTY LIST   Glenn, What a question! :)
""""""""""""""""""""""   I do this a lot: note the stack location (address
under the S thing) and the current PC.  Then I pop into Nifty List and do
a "w" on the PC, that'll tell me where I'm crashed. then doing a ";s" on
the stack will do a stack crawl and sometimes you can get an idea of what
was going on before you crashed. -Bryan
               (SOFTDISK.INC [Zak], CAT5, TOP3, MSG:32/M530)


SOME MORE IDEAS   One of the things to look at is the value of the
"""""""""""""""   Accumulator.  If there was a toolbox error, then the
accumulator should hold the error code.  You can also look at the values of
K/PC and use that information with Nifty List to find out who owns the
memory.

     There is a GSBug tutorial around in the library somewhere, which Tim
Swihart wrote and has quite a bit of useful information.  I'm not sure
which file it is, but I'm pretty sure it's in with one of the GSBug or
Nifty List archives.

  _   _
 / _ | \   Greg Da Costa
 \_| |_/  A2Pro Archivist
                   (A2PRO.GREG, CAT5, TOP3, MSG:33/M530)



                            >>> HOT TOPICS <<<
                            """"""""""""""""""

A (NOT SO) QUICK LESSON ON THE IIGS MEMORY MANAGER   There has been some
""""""""""""""""""""""""""""""""""""""""""""""""""   discussion in the
ORCA/C topic about how the Memory Manager should work, or how it should
have been designed.  Such discussion more correctly belongs here, and here
is where I'll respond.

 >>> A2PRO.TODDPW [!@tybalt]

 > I would have preferred that the memory manager require you to
 > dereference and lock all handles in one operation, and enforce the rule
 > that unlocked handles may move at ANY time. If the system doesn't do it
 > from an interrupt, the compiler optimization might.

     If I'd grown up with this kind of memory model, it might not bother
me. But I didn't, and in retrospect, to think of everyone having to lock
any memory block just to reference it seems silly to me.

     As Mike pointed out in the ORCA/C topic, a compiler optimization that
changes the order of evaluation is a bug -- and there is a well-defined and
well-constructed set of rules about when memory can move and when it can't.
It's not a problem, except for:

 >>> PROCYON.INC

 > GNO can context switch out of a  process when it believes that its
 > handles are safe; the process being switched to can allocate memory and
 > cause the 1st process' handles to move or get purged.

     This is a design flaw in GNO.  Plain, simple, incontrovertible.  If it
makes programs crash by changing the Memory Manager's rules, then it is at
fault.

     Jawaid may rightfully say "But there's no way to avoid it!" -- and
he's right.  That's why all the _other_ companies that investigated
projects like GNO did not bring them to market -- because they are
inherently unreliable.

     If people find GNO useful even with these severe restrictions, more
power to them.  Claiming it's the system software's "fault" that GNO breaks
the software architecture is like producing a hardware card that doesn't
work and saying "It's Apple's fault; it would work fine if the IIgs ran at
5.3 MHz."  You should have figured that out before you started.

 > DTS gave me a (not-great- but-it'll-have-to-do) way to tell the memory
 > manager not to ever move blocks.

     This technique, for those interested, is the "We're in an interrupt"
flag documented in Apple IIgs Technical Note #57.  As long as the flag is
set, no memory will _ever_ move.  In effect, the entire point of the
handle-based Memory Manager will be destroyed if this flag is set all the
time, which is what I think GNO is going to do in the future.

     The Technical Note calls setting this flag to avoid memory moving
"mind- numbingly stupid," an assessment with which I heartily agree.

--Matt (I speak for myself, not for Apple)
                 (M.DEATHERAGE, CAT15, TOP2, MSG:41/M530)


MULTITASKING AND MEMORY PROBLEMS?    >>> D.MILLER132 [GTerm] [Dave]
"""""""""""""""""""""""""""""""""    > Specifically with the onset of
 > multitasking (GNO etc.), what if another process does something that
 > moves memory while your process is in between reading part of your block?

     Jawaid would probably say "Yes, you need to worry about this."  In
fact, he already has.

     Apple, however, has said since 1986 that you do not -- memory should
not move behind your back.  If you dereference a handle, the resulting
pointer should stay valid until -you- do something that moves memory.  The
system maintains an interrupt flag to insure that memory allocated at
interrupt time does not cause memory to move.

     Right now, GNO _can_ cause memory to move behind your back, which I'm
fairly sure is at least part of the reason some applications aren't
compatible with it (though Jawaid has not verified any crashes due to
this).  You can either lock everything all the time you reference it or you
can wait for GNO to find a solution.

     Personally, I opt for leaving things unlocked until _I_ move them; I
think it's wasteful to have to lock things all the time when the system
clearly says it's not necessary.

     The System Software's paradigm, for better or worse, is "unlocked
handles are safe unless you do something that moves them."  Programs like
GNO aren't allowed to change rules like that towards being >less<
compatible, but that's what's happened.  Apple certainly isn't going to any
effort to change the places in system software where unlocked handles stay
dereferenced where they should be safe. --Matt (I speak for myself, not for
Apple)           (M.DEATHERAGE, CAT15, TOP2, MSG:52/M530)


GNO AUTHOR SAYS TO LOCK YOUR HANDLES FOR NOW   David, You're right on the
""""""""""""""""""""""""""""""""""""""""""""   mark. I haven't come up with
a solution to the "other process moves a handle" problem yet that won't
eventually cause the machine to run out of memory.  The best thing is for
programmers to lock their handles while they're accessing any information
in them.  Especially since locking a handle can be accomplished in about 20
cycles of machine code (5 lines).

     The problem hasn't caused a verified crash in GNO, but you never know.
-Jawaid              (Message, CAT15, TOP2, MSG:/M530)


HANDLES ALA MACINTOSH   > I haven't come up with a solution to the "other
"""""""""""""""""""""   > process moves a handle problem yet that won't
                        > eventually cause the machine to run out of memory.

     I wonder if it might be possible to patch into the memory manager to
allocate separate "heaps" for applications, such that each program has its
own heap space, can allocate handles within it, and that's it.  That way,
handles that were moved by one application would not affect the handles in
a heap owned by another application.  This is basically how the Mac works
under System 7/MultiFinder.  Each time an application calls NewHandle
(directly or indirectly), you'd have to fake the memory manager into
thinking that all memory outside the application's heap is locked and not
usable.  I'm sure there are a number of unrealized complexities in doing
this, and is probably something you guys have already mulled over.
                 (MORGAN-DAVIS, CAT15, TOP2, MSG:53/M530)


LOCKING ALL HANDLES IS NOT A SOLUTION   Asking those developers who write
"""""""""""""""""""""""""""""""""""""   code specifically for GNO to lock
handles all of the time is, unfortunately, a non-solution. You must realize
that portions of the System Software itself rely on memory not moving when
it's in control. As I've said before many, many (uncountable) times, the
toolbox was never designed for pre-emptive multitasking, and asking
permanently-rooted guidelines to bend is an impossible proposition.

 > The problem hasn't caused a verified crash in GNO, but you never know.

     In all honesty, I could probably create a reproducible sequence that
demonstrates this problem in a matter of minutes. All you need to do is to
allocate memory such that compaction occurs when someone is accessing an
unlocked block. Since pre-emptive context switching can theoretically occur
before any instruction is executed, the best way to show that this is
happening would be through a logic analyzer trace. With intrusive tools
such as GSBug, you just wouldn't be able to show this happening. -Jim
              (A2PRO.JIM [Murph'], CAT15, TOP2, MSG:54/M530)


GNO AUTHOR REPLIES   Morgan, actually, I hadn't thought of that. Hum.  That
""""""""""""""""""   would be a lot of work, but it's closer to my ideal
solution of virtual memory than anything that had crossed my mind. Thanks.

Matt & Jim,

     GNO doesn't context switch while a process is inside the System
Software. So, it's just applications; and you both misread me, or I didn't
make myself clear.  I suggested to lock handles only while accessing them.
GNO's Kernel does this quite a bit; it locks, dereferences, fiddles with
memory, then unlocks. It does not ever assume a handle is in a particular
spot unless it's also known to be locked.

Jim,

     Even Matt gave up the "The System wasn't designed for XXX" argument
some time ago.  Progress, and all that.  -Jawaid
                  (PROCYON.INC, CAT15, TOP2, MSG:55/M530)


YOU DON'T GIVE UP ON THE TRUTH   >>> PROCYON.IN
""""""""""""""""""""""""""""""   > GNO doesn't context switch while a
 > process is inside the System Software.

     How do you keep GNO from switching inside signal handlers?  That'd be
a trick.

 > Even Matt gave up the "The System wasn't designed for XXX" argument some
 > time ago.  Progress, and all that.

     You don't "give up" on the truth.

     The truth is that it's _not_ designed for that, and changing it to be
that way is in no way, shape or form a priority.

     It's just not going to happen, leaving the problem to be addressed in
the software that _makes_ it a problem:  GNO.

--Matt (I speak for myself, not for Apple)
                 (M.DEATHERAGE, CAT15, TOP2, MSG:56/M530)


LOCKING, DEREFING, PIDDLING, AND UNLOCKING NOT NECESSARY   >>> Jawaid
""""""""""""""""""""""""""""""""""""""""""""""""""""""""   > So, it's just
 > applications; and you both misread me, or I didn't make myself clear.
 > I suggested to lock handles only while accessing them.
 > GNO's Kernel does this quite a bit; it locks, dereferences, fiddles
 > with memory, then unlocks. It does not ever assume a handle is in a
 > particular spot unless it's also known to be locked.

     Nope, I read you correctly the first time, it's you who didn't
understand me. Locking, derefing, piddling, and then unlocking is exactly
what I said you don't need to do, as long as you don't make a toolbox call.
I do this, the System Software does this, things that I've added to the
System Software do this, programs written since 1986 do this, etc. By
mentioning that even the System Software does this, I was making the point
that Apple has said this technique is valid and will continue to remain
valid for the existence of the IIgs, or the end of the planet, whichever
comes first.

     If you're not going to cause memory to be compacted, either directly
or indirectly (by making a toolbox call that allocates memory), there is no
need, under the IIgs memory architecture to always lock memory when you
access it, plain and simple.  -Jim Murphy
              (A2PRO.JIM [Murph'], CAT15, TOP2, MSG:57/M530)


A SOLUTION WOULD BE NICE REGARDLESS OF WHOSE PROBLEM IT IS   I agree with
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""   Matt that this
is GNO's problem, not the system software's, yet it would still be way cool
to have a solution that would work reliably without a great deal of
overhead.  The fact that the Memory Manager has at least one problem (not a
bug, really, just a feature that might be done better) suggests another
alternative:

     Jawaid, the Memory Manager is small, rewrite it.  Yours could take
over after the fact as long as it used the same data structures as Apple's,
and as long as it kept those same data structures, you could even embed it
in GNO and return control to the standard Memory Manager when GNO exits.

     In your own Memory Manager, you could impose one additional
restriction: when a program that can be switched asks for memory, don't
purge or move memory unless it belongs to some program you know about.  You
could make up for a lot of the losses this would cause by allowing your
Memory Manager to move blocks around other, fixed blocks, which Apple's
doesn't do.  (Or at least, didn't do the last time I checked.  This is the
problem I alluded to earlier.)

     For the record, all of the ORCA products are designed to lock handles
before they are used.  If any of them are causing you problems, it's a bug.
Let me know and I'll fix it. Mike Westerfield
                   (BYTEWORKS, CAT15, TOP2, MSG:58/M530)


GEE, LOOKS LIKE I DUG UP A CAN OF WORMS!   >>> M.DEATHERAGE
""""""""""""""""""""""""""""""""""""""""   >>> MORGAN-DAVIS
                                           >>> PROCYON.INC
                                           >>> A2PRO.JIM [Murph']

 > The System Software's paradigm, for better or worse, is "unlocked
 > handles are safe unless you do something that moves them."

     Gee, looks like I dug up a can of worms! :-)

     Obviously, locking a handle any time you access it makes the most
sense, but as it's already been stated, the rules already say it isn't
necessary, and it's very hard to change the rules.  Mostly because of
everything that's already been written following the rules.

     Two other solutions I can think of are the one Morgan mentioned, and
the other would be any time GNO pre-empts a process, lock all of its
handles. This would probably be easier to implement than the separate heap
idea, but it would probably be dangerous on programs that use a lot of
memory, especially if memory is becoming scarce.  There may be plenty of
free space, but compacting won't get you anything because all the memory
belongs to one application that happens to be switched out at the moment...
 _
|_)avid |\/|iller
          (D.MILLER132 [GTerm] [Dave], CAT15, TOP2, MSG:59/M530)



                         >>> MESSAGE SPOTLIGHT <<<
                         """""""""""""""""""""""""

Category 36,  Topic 11
Message 83        Wed Mar 03, 1993
BYTEWORKS                    at 14:56 EST

     The problem with sizeof and many of the libraries, especially the
string handling libraries that return lengths, is that the size actually
varies in the various dialects of C, and sometimes even in the same C
compiler. In K&R C, sizeof and strlen return int.  In ANSI C, they return
something of type size_t, which is defined as an integer big enough to hold
the largest pointer, with the implication that for efficiencies sake, it
should be the smallest integer that fits the requirement.  In at least one
implementation of Turbo C, size_t was a 16 bit value for one memory model
and 32 bits for another, and that's with the same compiler!

     You have to couple that with the fact that it is _your_
responsibility, not the compiler's, to make sure that all of the parameters
you pass are used. Many compilers do some stack clean up more or less by
accident, because it's the most efficient way to use the machine, and a lot
of C programmer's have erroneously assumed that this is a requirement of C.
It isn't.  Any C compiler is perfectly within it's rights to crash when it
hits a statement like

    printf("%ld\n", 4);

and with optimizations on, ORCA/C just might do that.  (With optimizations
off, ORCA/C inserts some very time consuming code to "fix" the stack. It
works most of the time, but not all of the time.  Of course, the stack
repair on other compilers doesn't work all of the time, either.  ORCA/C
also has a debug option to help track down these bugs.)

     This leaves you with a problem: you don't know how big the value
returned by sizeof actually is, unless you nail your question down to a
particular memory model of a particular version of a particular compiler,
and then you've defeated the supposed "portability" of C.  The only safe,
portable way to code these statements is with an explicit type cast, like
this:

   printf("%lu\n", (unsigned long) sizeof(int));
   printf("%lu\n", (unsigned long) strlen("Hi"));

     You could, of course, get by with casting the result to int or
unsigned, but on most modern computers, using the largest memory model
available, it's possible for either of these functions to return a value
greater than the maximum allowed integer.  I showed the most general case,
and one that will work on every C compiler that I'm aware of.

Mike Westerfield

                                 [*][*][*]


    While on GEnie,  do  you spend most of your time  downloading files?
If so, you may be missing out some excellent information in the Bulletin
Board  area.   The messages  listed above  only scratch  the surface  of
what's available and waiting for you in the bulletin board area.

    If  you are  serious  about your AII, the GEnieLamp  staff  strongly
urge  you to give the  bulletin board area a try.   There are  literally
thousands  of messages  posted  from people  like you from  all over the
world.



[EOA]
[RAM]///////////////////////////////
                        RAMBLINGS /
//////////////////////////////////
Ramblings from a 'Wannabe' Programmer
"""""""""""""""""""""""""""""""""""""
By Larry E. Elseman
       [L.ELSEMAN1]



                           >>> WHY PROGRAM? <<<
                           """"""""""""""""""""

procedure WhyProgram;
begin
     writleln 'Why do you program?';
     readln (i);
          case i of
               1: ForFame;
               2: ForMoney;
               3: ForSatisfaction;
               4: ForCareer;
               5: ForFun;
               6: ForBabes;
               7: ForHunks;
          otherwise: ForGetIt;
end;

procedure ForFame;
begin
     writeln 'I want to be famous!';
end;

procedure ForMoney;
begin
     writeln 'I want to be rich!';
end;

procedure ForSatisfaction;
begin
     writeln 'I want to be happy!';
end;

procedure ForCareer;
begin
     writeln 'I want a good job!';
end;

procedure ForFun;
begin
     writeln 'I enjoy it!';
end;

procedure ForBabes;
begin
     writeln 'I want to meet women!';
end;

procedure ForHunks;
begin
     writeln 'I want to meet men!';
end;

procedure ForGetIt;
begin
     writeln 'EXCUSES not to program!';
     EXCUSES := true;
end;

procedure WhyNot;
begin
     If not EXCUSES then
          begin
                WhyProgram;
          end
     Else
          begin
               StartArticle;
          end
end;

BEGIN {Main}
     WhyProgram;
     WhyNot;
END.

procedure StartArticle;
begin

                               [*][*][*]


     What the heck am I trying to say here?  Well in my warped twisted way,
what I'm saying is that everyone has their reasons for programming, just as
everyone who doesn't program has a reason or an EXCUSE.

     If I eliminate people who don't use computers, then that leaves us
with people who do use computers... duh.  Okay, so if you use computers and
don't program, I'm asking 'Why don't you program?' And if you do program,
what keeps you from programming more?

     Here are some of my own personal reasons (EXCUSES) for not programming
more:

      I.   I am not a professional programmer.

     II.  I have a full time job, which doesn't involve
          programming.

     III. I have a family.

     IV.  I don't have time.
          A.  I have other activities outside of work.
              1. Share taxi duties with wife, shuttling
                 kids around town.
              2. Little League administrator.
              3. Chores around the house (Honey-do's).
              4. Attending night school.
          B.  I need time for other things.
              1. Spend time with my wife (alone, if
                 possible :))
              2. Love to golf.
              3. Enjoy playing on computer/Sega.

     V.   I don't know how to write the applications I would
          like to program.
          A.  Need to learn powerful languages to
              program the GS.
              1. Orca Pascal.
              2. Orca M.
              3. Micol Advanced Basic.
          B.  Need more time to learn those languages (see
              IV).

     As you can see, time is my biggest stumbling block (EXCUSE) to
becoming a 'real' programmer.

     How about you? For some people they have the time, but programming
logic is their stumbling block. Try this:

          Remove lines from this equation until both sides are equal. But
do it by removing as few lines as possible:

                        XI + I = X

     Come on, that's easy... you can do it in just one move; place the
second 'I' after the right 'X' to give you:

                        XI +   = XI

     Right?.... WRONG! Just look at the equation upside down! Zero lines
moved.

     Logic; sometimes the obvious is too hard. But that's also what makes
programming so doggone much fun. There are many ways to solve a problem,
and probably just as many ways to code a solution to the problem.

     For me programming is a release from the pressure and stress of day to
day living (Of course programming itself can be pressure packed and
stressful too, but that's another topic). And programming is fun. I find it
very exhilarating to get a program up and running, just exactly like I had
planned it. Making that pile of silicon and plastic respond according to my
wishes is a terrific high.

     On GEnie I have found knowledgeable people who are very talented at
programming and offer their expertise to your programming questions. Use
them to your advantage. Learn from their mistakes and achievements. You'll
be on the road to programming success. Don't use the EXCUSE; 'Well, no one
is available to help me', because the folks at A2 Pro, and everyone who
accesses it are here to help!



[EOA]
[DEV]//////////////////////////////
              DEVELOPER'S CORNER /
/////////////////////////////////
News from the A2Pro Online Developers
"""""""""""""""""""""""""""""""""""""
By Jim B.Couch
    [J.COUCH2]



                      >>> ONLINE SUPPORT IN A2PRO <<<
                      """""""""""""""""""""""""""""""

     CAT  COMPANY
     ---  ------------------------
     30   Procyon, Inc.
     31   Softdisk Publishing
     32   Morgan Davis Group (MDG)
     33   GS+ Magazine
     34   JEM Software
     35   Lunar Productions
     36   The Byte Works

     Each month this column feature highlights and news from various
developers who provide support via A2Pro:



                   >>> NEWS FROM SOFTDISK PUBLISHING <<<
                   """""""""""""""""""""""""""""""""""""

SOFTDISK REORGANIZATION BRINGS CHANGES   Recently we had a big re-org here
""""""""""""""""""""""""""""""""""""""   at Softdisk, and one of the
results is that we (Softdisk and Softdisk G-S) are now part of the "Apple
Development Group", or ADG as we like to call it.

     ADG is Softdisk, Softdisk G-S and Diskworld (our Macintosh product).
So, something we are looking for are articles that can apply to all
platforms.

     For example, recently Joe Kohn wrote an article about HP printer
solutions for Softdisk G-S. In about an hour one of our Mac people "ported"
it to Diskworld.

     As another example, Tim Tobin is writing us an article on removable
mass storage options (SyQuest, Floptical, Magneto-Optical, etc) and he's
writing for the GS but keeping in mind the Macintosh.

     So, where does this leave us? Well, we'd like to see some of the
following articles:

  - controlling home electrical stuff with your GS/Mac (X-10??)
  - solutions for the handicapped
  - CD-ROM, the ins and outs
  - ???

     If you're interested in writing an article on any of the above, or
have ideas of your own, please, contact us...we pay anywhere from $75 to
$250 for articles.

     You can reach us at this address (SOFTDISK.INC) or you can call Lee
Golden at 1-318-221-2173. -Bryan
              (SOFTDISK.INC [Zak], CAT31, TOP3, MSG:25/M530)



                      >>> NEWS FROM GS+ MAGAZINE <<<
                      """"""""""""""""""""""""""""""

GS+ PHONES DOWN DURING STORM   For the past week, the phones here at GS+
""""""""""""""""""""""""""""   Magazine have gone unanswered. The reason
for this is that due to the "Storm of the Century" we have been without
power all week.  No power means, among other things, no answering machine
and no fax machine.  We apologize for any concern this may have caused, but
be assured that we are NOT out of business. At approximately 4:30 p.m.
Eastern Time on Thursday, March 18th, the power came back on.  We have
resumed our normal operations as of 9 a.m., Friday, March 19th. Now of
course, we have to make up four lost days and try to get things back on
schedule.  Please spread the word that while we will be working as hard as
we can, the next issue of GS+ Magazine may arrive a little later than
expected.

     Thanks for your patience.

-Everyone at GS+ Magazine
                (JWANKERL [Joe], CAT33, TOP4,, MSG:18/M530)



                      >>> NEWS FROM JEM SOFTWARE <<<
                      """""""""""""""""""""""""""""""

HOW MUCH ARE JEM PRODUCT UPGRADES?   I read in the last AWKS Forum that
""""""""""""""""""""""""""""""""""   updates for JEM products were $5.00. I
sent for and update to TotalControl, but you stated in a recent post in the
A2 area that they are $13.00.  Did I misunderstand the NAUG notice?  I sent
for the update last week.  I need it pretty bad.  Thanks. -John King
               (J.KING26 [JohnK], CAT34, TOP2, MSG:62/M530)


IT DEPENDS   Bug fix disks are always $5 to just cover the cost of the disk
""""""""""   and shipping and handling.

     A feature upgrade is usually $10 plus $3 s/h.
                (BRANDT [Randy], CAT34, TOP2, MSG:64/M530)



                    >>> NEWS FROM LUNAR PRODUCTIONS <<<
                    """""""""""""""""""""""""""""""""""

TELL ME ABOUT FOUNDATION VS GENESYS   Hi, I'm taking the Introduction to
"""""""""""""""""""""""""""""""""""   Resources course and have a question
about Foundation.  (Forwarded here as suggested by Matt D.)  I know that
Mr. Wolfgram worked on Genesys and now Foundation, and that they're
separate products.  I've also heard that Genesys does some things that
Foundation (as yet) cannot.  What and why not?

     Thanks and, editors haven't been discussed in the course yet, so
you're dealin' with a layman here. :)
                (P.CREAGER [Wily], CAT35, TOP1, MSG:8/M530)


MY CHOICE IS FOUNDATION   Well, I'm not Marc, but I can answer your
"""""""""""""""""""""""   question..  First, why Foundation can't do what
Genesys can. Because Foundation has a radically different, uh, foundation!

#     Genesys right now supports "graphical" editing of a lot of different
resource types. (although beware, the editing is System 5.0 based and you
may "damage"  some resource types in some cases, for example Lists that
have the scroll bars drawn inside the bounds rect).

     Foundation doesn't yet have graphical editors for the major resource
types-- why? because they were only three people and there were only 24
hours in a day. :) I'm sure Marc will be along to let you know the time
frame, but my understanding is that full graphical editors are forthcoming.

     In any case, while using Genesys is a Bad Idea, Foundation CAN be used
to edit any resource type. Either ScriptEdit or HexEdit can be used. It's
better than nothing, but not as good as a graphical editor.

     My choice? Foundation, easily.   -Bryan
               (SOFTDISK.INC [Zak], CAT35, TOP1, MSG:9/M530)


FOUNDATION AUTHOR COMPARES BOTH PROGRAMS   Thanks Bryan!  That was well
""""""""""""""""""""""""""""""""""""""""   stated!  Willy, both Genesys
and Foundation have individual strengths that make both of them useful in
different ways.  As Bryan pointed out, Genesys has a somewhat complete set
of "Graphic" resource editors.  It also can generate source for a number of
languages.  It's drawbacks are its total lack of support for System 6
resource structures, and non-existant company support -- there won't be an
update to Genesys as far as I can tell.

     Foundation's strengths are numerous, but as of today, the only
"Graphic" editor available for it is SoundREM from Mike Nuzzi at Triad
Ventures. As Bryan mentioned, additional editors will be forthcoming!  We
are almost done with a combination rIcon/rBundle editor that will be
packaged with the Foundation 1.0.3 update in mid April.

     What Foundation does have right now, is a full HexASCII generic editor
that allows you to edit ANY resource, be it a standard from System 5 or
System 6, or a custom resource that you or someone else created.

     Foundation also comes with a ScriptEditor, which is a template driven
universal editor.  Right now there are some limitations in what it can
edit, but this too will pass (hopefully by mid April as well).

     We concentrated on building a lot of useful features into the
Foundation application, including full recognition of System 6 resource
structures and dependencies, and multiple file support.  This means that
you can select a MenuBar in on file, and copy/paste it into another file
AND all the associated Menus, MenuItems, Pascal Strings and whatever are
copied as well. It also lets you delete resources safely, telling you if
the resource is used by something else, and also allowing a whole resource
dependency tree to be deleted at once.  We have dynamic resource naming,
fork optimization, dependency walking and a bunch of other really nice
features built right into the program.

     Foundation includes a developers kit with sample source code and the
full documentation of the editor interface and 40 odd shell support
functions.

     Yes, I was party to SSSi's Genesys...In fact I use Genesys a lot to
prototype windows and alerts.  However, Foundation lets me manage these a
lot nicer, and it isn't bound by the "System 5 Only" resource limitations
in Genesys.  We're working hard to bring the "Graphic" advantage to our
product, but wanted a solid, er, foundation in place on which to build :)

-Marc Wolfgram
Lunar Productions
           (M.WOLFGRAM2 [Lunar Host], CAT35, TOP1, MSG:10/M530)



                     >>> NEWS FROM THE BYTE WORKS <<<
                     """""""""""""""""""""""""""""""""

TELL ME ABOUT PROGRAMMING THE TOOLBOX   I would like to know more about the
"""""""""""""""""""""""""""""""""""""   programming of the toolbox and what
need to do in order to use it, also some more detail on ORCA/Pascal itself.
-Dave          (D.GANEZER [DAVE], CAT36, TOP22, MSG:1/M530)


CHECK OUT BYTEWORKS TOOLBOX PROGRAMMING COURSE   Toolbox Programming in
""""""""""""""""""""""""""""""""""""""""""""""   Pascal is a self-contained
course.  You need ORCA/Pascal and a computer, but no other books or
reference material. The basic requirements for your computer are:

  1. 1.75M of memory, 2M or more recommended.

  2. A hard drive.  You can get by with 2 or 3 3.5" floppy drives, but
     I'll have to give you some tips if you want to try it.

  3. A color screen is nice, especially for the graphics chapters, but it
     isn't actually required.

  4. A printer that works with Apple's Print Manager is needed for the
     sections that deal with printing, although you can skip those
     sections if you like.

     The course comes with an abridged toolbox reference manual that will
get you through the course and all of the problems.  If you already have
the Toolbox Reference manuals, great -- the course will teach you how to
use them.  If you do not have the Toolbox Reference manuals, yet, I'd
suggest starting without them.  You need to have the Toolbox Reference
manuals before you start writing your own programs, but you don't need them
right away.  About half way through the course, if you like what you are
doing and intend to go on, you'll want to start buying the reference books.
The course itself has a brief description of the various reference books;
that will help you decide which ones to buy, and in what order.

     ORCA/Pascal itself is a complete development system for writing Pascal
programs.  You'll find a short description of it in our online catalog
(topic 1 in this category).  If you'd like more detailed information, you
can ask questions, or send me your mailing address and I'll get some
printed material off to you.   -Mike Westerfield
                   (BYTEWORKS, CAT36, TOP22, MSG:3/M530)



[EOA]
[A2U]//////////////////////////////
                 A2U CAMPUS CHAT /
/////////////////////////////////
A2 University; Learning Online
""""""""""""""""""""""""""""""
By Jim B. Couch
     [J.COUCH2]



                       >>> A2U COURSES CONTINUE <<<
                       """"""""""""""""""""""""""""

 ---+----+--------------------\
  @ |Fila| Redactar  Ventanas <         A2 University is in Session!
 ---+----+---------------+----/
    | Sobre Finder...    |                Introduction to Resources
    | Ayuda...        @? |         with Marc Wolfgram of Lunar Productions
    |--------------------|
    | Panel de Controles |         No, we won't teach you Spanish, but...
    +--------------------+

...we _will_ show you how to customize many System 5 and System 6
applications that use resources to fit your needs -- changing the language
is just an example.

     To learn what resources are and how they can help you customize your
applications, be sure to visit the A2Pro Real Time Conference on Wednesdays
at 9:30pm EST, or visit A2U (Category 22) in the A2Pro bulletin board.  You
don't have to be an official participant in the course to attend, and the
first three lessons are now available!

     This course will be followed by a more technical course aimed at
participants in the first course, and programmers interested in furthering
their skills with resources  Both are taught by Marc Wolfgram, who helped
develop both Genesys and Foundation, two popular resource editors.



             >>> A2U DATA COMPRESSION CONFERENCES CANCELED <<<
             """""""""""""""""""""""""""""""""""""""""""""""""

Current A2U RTC Schedule
------------------------

Wednesdays @ 9:30 EST - Intro to Resources with Marc Wolfgram.


     NOTE: The Data compression conferences, due to lack of attendance,
have been cancelled until the final lesson is released. If you want to see
the conferences, post that why in the discussion topic for Andy's course.
                  (A2PRO.STEVE, CAT22, TOP5, MSG:2/M530)



[EOA]
[LIB]//////////////////////////////
                  ONLINE LIBRARY /
/////////////////////////////////
April is Tech Notes month!
""""""""""""""""""""""""""
By Jim B. Couch
     [J.COUCH2]



                  >>> GET THE LATEST TECH NOTES NOW! <<<
                  """"""""""""""""""""""""""""""""""""""

     Matt Deatherage has been very busy this past month uploading ALL of
the Apple II Tech Notes! There is one mega file that contains ALL of the
Tech Notes AND all of the File Type Notes. For those who do not need the
File Type Notes there is also a mega file that contains ALL the Tech Notes,
but no file Type Notes. There are also numerous files with separate File
Type Notes if you don't need the whole wad!

 ------------
 Number: 3139  Name: ALL.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 828160
 Number of Accesses: 2  Library: 2

     This archive contains all the Technical Notes (but not File Type
 notes) released by Apple Computer as of 6/92, which was the last released
 batch.  Downloading this archive gives you _all_ the current Technical
 Notes.

 Keywords: Apple,TN,Technical,Technote,Notes,DTS

 ------------
 Number: 3140  Name: ALL.NOTES.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 1078912
 Number of Accesses: 23  Library: 2

     This archive contains all the Technical Notes and File Type Notes
 released  by Apple Computer as of 6/92, which was the last released batch.
 Downloading this archive gives you _all_ the current Technical Notes and
 File Type Notes; you'll have every one of them and can throw all your
 older  ones away.

 Keywords: Apple,TN,FTN,Technical,Technote,Filetype,File Type,DTS

 ------------
 Number: 3125  Name: ATALK.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 49536
 Number of Accesses: 2  Library: 2

     This archive contains all the AppleTalk Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the AppleTalk Technical Notes, the Technical Note
 Index  and 'About Technical Notes' so you can find other Notes more
 easily.  The  contents of this archive completely replace any older
 versions of AppleTalk  Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,AppleTalk,ATLK

 ------------
 Number: 3126  Name: IIE.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 103808
 Number of Accesses: 3  Library: 2

     This archive contains all the Apple IIe Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the Apple IIe Technical Notes, the Technical Note
 Index  and 'About Technical Notes' so you can find other Notes more
 easily.  The  contents of this archive completely replace any older
 versions of Apple IIe  Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,Apple IIe,IIe,AIIe

 ------------
 Number: 3128  Name: IIC.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 44672
 Number of Accesses: 1  Library: 2

     This archive contains all the Apple IIc Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the Apple IIc Technical Notes, the Technical Note
 Index  and 'About Technical Notes' so you can find other Notes more
 easily.  The  contents of this archive completely replace any older
 versions of Apple IIc  Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,Apple IIc,IIc,AIIc

 ------------
 Number: 3129  Name: GSOS.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 75776
 Number of Accesses: 4  Library: 2

     This archive contains all the GS/OS Technical Notes released by Apple
 Computer as of 6/92, which was when the last release happened.  This
 archive contains the GS/OS Technical Notes, the Technical Note Index and
 'About Technical Notes' so you can find other Notes more easily.  The
 contents of this archive completely replace any older versions of GS/OS
 Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,GS/OS,GSOS

 ------------
 Number: 3130  Name: HCGS.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 37120
 Number of Accesses: 4  Library: 2

     This archive contains all the HyperCard IIgs Technical Notes released
 by  Apple Computer as of 6/92, which was when the last release happened.
 This  archive contains the HyperCard IIgs Technical Notes, the Technical
 Note  Index and 'About Technical Notes' so you can find other Notes more
 easily.  The contents of this archive completely replace any older
 versions of  HyperCard IIgs Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,HyperCard IIgs,HyperCard,HCGS

 ------------
 Number: 3131  Name: IIGS.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 458368
 Number of Accesses: 6  Library: 2

     This archive contains all the Apple IIgs Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the Apple IIgs Technical Notes, the Technical Note
 Index  and 'About Technical Notes' so you can find other Notes more
 easily.  The  contents of this archive completely replace any older
 versions of Apple  IIgs Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,Apple IIgs,IIgs,GS

 ------------
 Number: 3132  Name: MISC.TNS.BXY
 Address: M.DEATHERAGE                Date: 930213
 Approximate # of bytes: 76544
 Number of Accesses: 1  Library: 2

     This archive contains all the Apple II Miscellaneous Technical Notes
 released by Apple Computer as of 6/92, which was when the last release
 happened.  This archive contains the Apple II Miscellaneous Technical
 Notes, the Technical Note Index and 'About Technical Notes' so you can
 find  other Notes more easily.  The contents of this archive completely
 replace  any older versions of Apple II Miscellaneous Technical Notes you
 may have.

 Keywords: Apple,TN,Technical,Technote,DTS,Miscellaneous,Misc

 ------------
 Number: 3133  Name: MOUSE.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 41728
 Number of Accesses: 2  Library: 2

     This archive contains all the Apple II Mouse Technical Notes released
 by  Apple Computer as of 6/92, which was when the last release happened.
 This  archive contains the Apple II Mouse Technical Notes, the Technical
 Note  Index and 'About Technical Notes' so you can find other Notes more
 easily.  The contents of this archive completely replace any older
 versions of Apple  II Mouse Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,Mouse

 ------------
 Number: 3134  Name: PASCAL.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 73600
 Number of Accesses: 3  Library: 2

     This archive contains all the Apple II Pascal Technical Notes released
 by  Apple Computer as of 6/92, which was when the last release happened.
 This  archive contains the Apple II Pascal Technical Notes, the Technical
 Note  Index and 'About Technical Notes' so you can find other Notes more
 easily.  The contents of this archive completely replace any older
 versions of Apple  II Pascal Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,Pascal,Pasc

 ------------
 Number: 3135  Name: PRODOS8.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 110976
 Number of Accesses: 4  Library: 2

     This archive contains all the ProDOS 8 Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the ProDOS 8 Technical Notes, the Technical Note
 Index and  'About Technical Notes' so you can find other Notes more
 easily.  The  contents of this archive completely replace any older
 versions of ProDOS 8  Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,ProDOS 8,P8,PDOS

 ------------
 Number: 3136  Name: SMTPORT.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 43520
 Number of Accesses: 5  Library: 2

     This archive contains all the SmartPort Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the SmartPort Technical Notes, the Technical Note
 Index  and 'About Technical Notes' so you can find other Notes more
 easily.  The
 contents of this archive completely replace any older versions of
 SmartPort  Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,SmartPort,SmtPort,SmPt

 ------------
 Number: 3137  Name: UNIDISK.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 39424
 Number of Accesses: 3  Library: 2

     This archive contains all the UniDisk 3.5 Technical Notes released by
 Apple  Computer as of 6/92, which was when the last release happened.
 This  archive contains the UniDisk 3.5 Technical Notes, the Technical Note
 Index  and 'About Technical Notes' so you can find other Notes more
 easily.  The  contents of this archive completely replace any older
 versions of UniDisk  3.5 Technical Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,UniDisk 3.5,UniDisk

 ------------
 Number: 3138  Name: IW.MEMX.TNS.BXY
 Address: M.DEATHERAGE                Date: 930214
 Approximate # of bytes: 3456
 Number of Accesses: 2  Library: 2

     This archive contains all the ImageWriter and Memory Expansion
 Technical  Notes released by Apple Computer as of 6/92, which was when the
 last  release happened.  This archive contains the Technical Notes (both
 of  them).  It does _NOT_ contain 'About Technical Notes' or the Technical
 Note  Index to keep the archive size down -- those Notes are in all the
 other  Note archives here in A2Pro.  The contents of this archive
 completely  replace any older versions of ImageWriter or Memory Expansion
 Technical  Notes you may have.

 Keywords: Apple,TN,Technical,Technote,DTS,ImWr,ImageWriter,MemX,Memory,
           Slinky

                                 [*][*][*]



              >>> A2PRO LIBRARY REORGANIZATION COMPLETED! <<<
              """"""""""""""""""""""""""""""""""""""""""""""
     Matt Deatherage is not the only person who has been busy this month.
Todd Whitesel has been engaged with the A2Pro library reorganization. Todd
has arranged the library so that files will be much easier to find. These
alterations reflect the changing nature of programming on the Apple II and
I think you will agree that Todd has done a wonderful job!


YOWZA! YOWZA! A2PRO REORGANIZATION NOW COMPLETE!   Historically, the
""""""""""""""""""""""""""""""""""""""""""""""""   general areas of the
A2PRO library have been divided along the boundaries of programming
languages. This made sense a long time ago, because the Apple programming
world was much smaller and more isolated than it is now. These days, the
environment you're writing your program for is usually more important than
the language (or languaGES) your program will be written in.

     To reflect this, the entire library has been in a state of flux for
nearly four weeks (yeah, I know, sorry bout how long it took) and is now
fully reorganized around a new set of criteria that, while it isn't perfect
yet, should at least make it a lot easier to find things by library number.
A couple of the categories turned out to get rather large, though, so I'll
probably split them up in a little while when I can think of a good, clear
criteria for dividing them. When this happens, it will be far less
traumatic because there is reserved space for them to expand into, and no
other libraries will need to move to accommodate them.

     All the changes were to the general area (libraries 1 through 29).
Here is a listing of the 'final' categories:

  1.   A2Pro Archives and Transcripts
  2.   Apple II Tech Notes
  3.   Apple II File Type Notes
  4.   Apple II Sample Code
  5.   System Software
  6.   Help me! ... Problem source uploads
  7.   Categorize me! & General Uploads.
  8.   8-bit development, AppleSoft, HyperC
  9.   Archive Tools (Shrinkit/Stuffit/BNY)
 10.   A2 University (A2U)
 11.   Theory and General Techniques
 12.   The Reference Shelf: Specs and Info
 13.   HyperCard IIgs and HyperStudio
 14.   Resources: REZ, Tools, and Utilities
 15.   Miscellaneous Programming Utilities
 16.   Interface Files, Macros, & Libraries
 17.   Debugging Tools (GSBUG, Nifty List)
 18.   Other IIgs Languages (BASIC, FORTH)
 19.   Shells and Shell Utilities (EXE's)
 20.   Classic Desk Accessories and Inits
 21.   Desktop Programs and GUI code
 22.   Reserved
 23.   Practice: Putting it all Together
 24.   Reserved
 25-29.Reserved

     In most cases the titles should be self-explanatory. There are now
descriptions available (yeah, that option #1 that never printed anything
before, now it actually says something for most of them).

     Don't worry about getting confused by the new structure. I thought of
the whole flaming thing and even _I_ can't make up my mind about where some
of those files ought to go! That's why there is library #7. If no other
category seems to fit, or you just can't decide between two or three
libraries that look like good places to put the file, just upload it to #7
and let _me_ lose sleep trying to figure out where to put it.

     (Of course, I reserve the option to punt and let it stay in library
#7, which is what I did with a few files from the old organization that
don't seem to fit _anywhere_ in the new scheme -- some of them probably
belong in A2 but I don't have the heart to evict them yet.)

     Any comments or helpful suggestions you can think of are appreciated
-- post them in cat 1 topic 3 or (if you don't want them read in public)
mail them to A2PRO$ so that all the sysops (not just me) will see them.
That way if I don't see the value of your idea but somebody else does, they
can beat me over the head with a cat-o-nine-ball-less-mice until I repent.

Enjoy!  -Todd Whitesel
             (A2PRO.TODDPW [growf?], CAT1, TOP17, MSG:66/M530)



                    >>> HOT FILES YOU CAN DOWNLOAD <<<
                    """"""""""""""""""""""""""""""""""

  File #  Filename                     Description
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 3207    A2U.ULTRA4.BXY        [8bit]  All msgs from the A2U Ultra 4 course
 3206    TMPROGINFO.BXY        [IIgs]  Programmer Info for The Manager
 3205    INDEX.ADB.BXY                 March Index of Topics (ADB Re-Up)
 3203    A2U.RES.3.BXY         [IIgs]  Lesson 3 in the A2U Resource Intro
 3202    ADVSRC.BXY            [IIgs]  APW C source to orig. Adventure
 3201    ADPCM1.1.BXY          [IIgs]  Newer version of 16-bit ADPCM source
 3198    A2NDX0393DB.BXY               A2 Cat/Top Index - Mar '93 (ADB)
 3197    A2NDX0393TX.BXY               A2 Cat/Top Index - Mar '93 (TXT)
 3196    ULT.PROG.01.BXY               Old msgs -- Ultra Programming
 3195    U.QUIRKS.02.BXY               Old msgs -- Ultra Quirks
 3192    INDEX.TXT.BXY                 March 93 A2PRO Topic Index (TXT)
 3186    A2U.RES.2.BXY         [IIgs]  Resource Introduction Lesson 2
 3178    SYS.DISK.P8.BXY       [8bit]  Prodos 8 System Disk 4.0.1
 3173    A2U.RES.1.BXY         [IIgs]  A2U Resource Introduction, lesson 1
 3142    ORCAQUIKREF.BXY       [IIgs]  Orca Editor 2.0 Quick Reference
 3141    ROBCMDS.BXY           [8bit]  external commands for Davex
 3140    ALL.NOTES.BXY                 All TNs and FTNs as of 6/92
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


[EOA]
[EOA]
[LOG]//////////////////////////////
                         LOG OFF /
/////////////////////////////////
GEnieLamp Information
"""""""""""""""""""""

    o   COMMENTS: Contacting GEnieLamp

         o   GEnieLamp STAFF: Who Are We?

              o   GET_THE_LAMP Scripts & Macros

                    o   SEARCH-ME! Answers



GEnieLamp     GEnieLamp is monthly  online magazine  published  in  the
"""""""""     GEnieLamp  RoundTable  on page 515.   You can  also  find
GEnieLamp in the ST (475), the  Macintosh (605), the IBM (615) Apple II
(645),  A2Pro (530), Unix  (160),  Mac Pro (480), Geoworks (1050),  BBS
(610), CE Software  (1005) and  the  Mini/Mainframe (1145) RoundTables.
GEnieLamp can also be found on CrossNet,  Internet,  America Online and
many public and commercial BBS systems worldwide.

     We welcome and respond to all GEmail.To leave messages, suggestions
or just to say hi,  you can contact us in the GEnieLamp RoundTable (515)
or send GE Mail to John Peters at [GENIELAMP] on page 200.


U.S. MAIL
"""""""""
                       GEnieLamp Online Magazine
                           Atten: John Peters
                       5102 Galley Rd. Suite 115/B
                       Colorado Springs, CO  80915


                        >>> GEnieLamp STAFF <<<
                        """""""""""""""""""""""

  GEnieLamp    o John Peters        [GENIELAMP]    Editor-In-Chief
  """""""""

   ATARI ST    o John Gniewkowski   [J.GNIEWKOWSK] Editor
   """"""""    o Mel Motogawa       [M.MOTOGAWA]   ST Staff Writer
               o Terry Quinn        [TQUINN]       ST Staff Writer
               o Sheldon Winick     [S.WINICK]     ST Staff Writer
               o Richard Brown      [R.BROWN30]    ST Staff Writer
               o John Hoffman       [JLHOFFMAN]    ST Staff Writer
               o Al Fasoldt         [A.FASOLDT]    ST Staff Writer

 ATARI ST/TX2  o Cliff Allen        [C.ALLEN17]    Editor/TX2
 """"""""""""
 ATARI [PR]    o Fred Koch          [F.KOCH]       Editor/PD_Q
 """"""""""
        IBM    o Robert M. Connors  [R.CONNORS2]   Editor
        """    o Peter Bogert       [P.BOGERT1]    IBM Staff Writer
               o Brad Biondo        [B.BIONDO]     IBM Staff Writer
               o Tippy Martinez     [TIPPY.ONE]    IBM Staff Writer
               o David Holmes       [D.HOLMES14]   IBM Staff Writer

  MACINTOSH    o James Flanagan     [JFLANAGAN]    Editor
  """""""""    o Richard Vega       [R.VEGA]       Mac Co-Editor
               o Dan "Remo" Barter  [D.BARTER]     Mac Staff Writer
               o Tom Trinko         [T.TRINKO]     Mac Staff Writer
               o Bret Fledderjohn   [FLEDDERJOHN]  Mac Staff Writer
               o Bill Garrett       [BILL.GARRETT] Mac Staff Writer

     MacPRO    o James Flanagan     [JFLANAGAN]    Editor
     """"""    o Erik C. Thauvin    [MACSPECT]     Supervising Editor
               o Chris Innanen      [C.INNANEN]    MacPRO Staff Writer
               o Paul Collins       [P.COLLINS]    MacPRO Staff Writer

   APPLE II    o Darrel Raines      [D.RAINES]     Editor
   """"""""    o Phil Shapiro       [P.SHAPIRO1]   A2 Co-Editor
               o Mel Fowler         [MELSOFT]      A2 Staff Writer

       A2Pro   o Jim B. Couch       [J.COUCH2]     Editor
       """""   o Nate C. Trost      [N.TROST]      A2Pro Staff Writer

    INTERNET   o Jim Lubin          [JIM.LUBIN]    GEnieLamp IBM
    """"""""

       ETC.    o Jim Lubin          [JIM.LUBIN]    Add Aladdin
       """"    o Scott Garrigus     [S.GARRIGUS]   Search-ME!
               o Bruce Faulkner     [R.FAULKNER4]  CrossNET Support
               o Mike White         [M.WHITE25]    Cowlumnist/Asst. SysOp


GEnieLamp CONTRIBUTORS
""""""""""""""""""""""

                   o Steven Weyhrich            [S.WEYHRICH]
                   o Gina Saikin                [G.SAIKIN]
                   o Paul Varn                  [P.VARN]
                   o Larry E. Elseman           [L.ELSEMAN1]
                   o Les Blatt                  [L.BLATT]


\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
   Material  published in this  edition may  be reprinted  under  the
   following  terms  only.   All articles  must remain  unedited  and
   include  the issue  number and author  at the top of  each article
   reprinted.  Reprint permission granted, unless otherwise noted, to
   registered  computer user groups and not  for profit publications.
   Opinions  present herein  are those of the  individual authors and
   does  not necessarily  reflect those of  the publisher or staff of
   GEnieLamp.   We reserve  the right  to edit all  letters and copy.
   Include the following at the end or the beginning of every reprint:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
   (c) Copyright 1993 T/TalkNET Online Publishing and GEnie.  To join
   GEnie,  set  your modem  to 2400  baud  (or less)  and half duplex
   (local echo).  Have the modem dial 1-800-638-8369.  When you get a
   CONNECT message, type HHH. At the U#= prompt, type:
                            XTX99014,DIGIPUB
   and hit the [return] key.  The system  will then  ask you for your
   information.   Call (voice) 1-800-638-9636 for  more  information.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
[EOF]
