HDTenEightyP/NetNews huggingface dataset:
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: RKM description of WaitPort()
Organization: UNC Office of Information Technology
Date: Thu, 7 Jan 1993 20:10:52 GMT

In article <38385@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter  
Cherna) writes:
>[...]Try this to handle messages from two ports:
>
>	struct MsgPort *mp1 = your first message port;
>	struct MsgPort *mp2 = your second message port;
>
>	sigmask1 = 1 << mp1->mp_SigBit;
>	sigmask2 = 1 << mp2->mp_SigBit;
>
>	while ( !done )
>	{
>	    sigmask = Wait( sigmask1 | sigmask2 );
>	    if ( sigmask & sigmask1 )
>	    {
>	        while ( msg1 = GetMsg( mp1 ) )
>	        {
>	            handle messages from port 1 ...
>	        }
>	    }
>	    if ( sigmask & sigmask2 )
>	    {
>	        while ( msg2 = GetMsg( mp2 ) )
>	        {
>	            handle messages from port 2 ...
>	        }
>	    }
>	}

I've used this dozens of times, but the other day I was getting
messages from port 1 faster than I could process them so that
I never got around to processing port 2's message, an act which
would have made port 1's messages stop comming.  A busy dead-lock.
Now I do something like this:

 while ( !done )
 {
     sigmask = Wait( sigmask1 | sigmask2 );
     while ( (msg1 = GetMsg( mp1 )), (msg2 = GetMsg( mp2 )), (msg1 || msg2) )
     {
       if ( msg1 )
              {
                handle a message from port 1 ...
              }
       if ( msg2 )
              {
                handle a message from port 2 ...
              }
     }
 }

This way both ports get roughly equal treatment, whereas in the example
Peter gave port 1's messages must all be handled before port 2 even
gets looked at.

Note that "while ( (msg1 = GetMsg( mp1 )) || (msg2 = GetMsg( mp2 )) )"
wouldn't solve the problem because the second GetMsg() would not
be called if the first GetMsg() actually got a message.

Some people might like this better:
  do {
        if (msg1 = GetMsg( mp1 ))
           {
             handle a message from port 1...
           }
        if (msg2 = GetMsg( mp2 ))
           {
             handle a message from port 2...
           }
     } while ( msg1 || msg2 );
--
 _/_/_/  _/     Todd_Lewis@unc.edu          You can lead a horse to 
  _/    _/     utoddl@guitar.oit.unc.edu   Mohammad, but you can't make
 _/    _/_/_/                             a mountain drink a mole hill.
Newsgroups: comp.sys.amiga.programmer
From: vailm00@DMI.USherb.CA (MARC VAILLANCOURT)
Subject: How to get SAS/C 6.0 educational price
Organization: Universite de Sherbrooke -- Dept. d'Informatique
Date: Thu, 7 Jan 1993 19:07:32 GMT

Hi everybody,

   I'd like to have the information on how to get the special educational
pricing for SAS/C 6.0. I know they sell it for around 200$ US if you
can prove them you're a student, but I'd like to get all the details...
 
   Thanks in advance..

	Marc
From: ccspad@sunlab1.bath.ac.uk (Paul Dale)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AMOS - AGA version
Keywords: AMOS Europress
Date: 8 Jan 93 14:16:34 GMT
Organization: Bath University Computing Services, UK

In the referenced article, ag@hpopd.pwd.hp.com (andy garton) writes:
>When can we expect a version of AMOS which supports AGA?
>
>Andy
>ag@hpopd.pwd.hp.com

Europress were on the phone yesterday doing some canvassing for
views on a front end for all Amos products, some kind application
builder. I took the chance to ask about the AGA machines. They
confirmed Amos will work on an A1200 but were slightly cagey
about when an AGA version would appear. They weren't too sure
how successful the AGA machines were going to be. There is
a very large A500 base, used mainly by game players, which
won't necessarily upgrade. 

First indications were that the 1200 would succeed and that AGA Amos
would follow.

Paul Dale
Systems admin./applications support/programmer.
Bath Information and Data Services,
BUCS, Bath University, Claverton Down, Bath, Avon. UK BA2 7AY
tel: 0225 826215
e-mail: P.A.Dale@bath.ac.uk
fax: 0225 826176
From: chopps@ro-chp.UUCP (Chris Hopps)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Version Strings...
Date: Tue, 12 Jan 1993 09:55:03 GMT
 <C0MEv9.Awr@well.sf.ca.us>
Summary: Reason found
Organization: Not an Organization
X-Newsreader: Arn V1.00 beta rel2

In article <C0MEv9.Awr@well.sf.ca.us>, Greg Comeau writes:

> In article <81pgs*M00@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes:
> >In article <Per_Salmi.0lxs@augs.se>, Per Salmi writes:
> >
> >> accs1@bagheera.mumath wrote:
> >
> >> : >UBYTE Version[] = "\0$VER: ProgName 1.0 (7.1.92)";
> >
> >> : I wonder why that stays in the executable. I would expect a good compiler would
> >> : through that line away unless it is really referenced.
> >
> >> You really got a point there! Why does it?
> >
> >this would 1) probably never work right and 2) someone would find a reason the linker
                                               -----------------------------------------
> >should not be deleting non referenced data objects.
   ---------------------------------------------------

> I've addressed the former in some posts yesterday so will direct you
> to them for that.  Re the latter, it can be made somewhat more likely
> to remain in simply by changing it to:
>
>     UBYTE *VerPtr = "\0$VER: ProgName 1.0 (7.1.92)";
>
> the reason being that it's simple enough to see what's not referenced,
[rest del]

Ironically enough I have found my own reason that the compiler/linker should
not assume something is not referenced.  In a shared memory system, as the amiga
is, there can be no guarantee that another running process will not be referencing
the data.  Also I think someone else (different thread) pointed out that the
command "Version" does indeed reference the data.  Your method is "more" correct
becuase it clearly seperates the data from the symbol.  The data being stored and
the pointer being initialized in reference to the data.

Two things:
1) If a compiler ever went this far, I think many programmers would be pulling
hair out left and right trying to second guess the optimizer.
2) Becuase someone may ignore (1) this method should work:

volatile UBYTE Version[] = "\0$VER: ...";

By the definition of the type qualifier volatile, the compiler would considered
broken if it optimized this out.  This also further illistrates my point that
linker optimizations is "impossible" to do correcty.  The linker does not have
the knowledge about the symbol/data that the compiler does.  I think someone
would have to bend quite a bit of compiler theory to ever come up with a way
around this.

> - Greg

Chris...
------------------------
The Royal Oak Chophouse >> Chris Hopps
Royal Oak, Michigan     >> sycom.mi.org!ro-chp!chopps
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Version Strings...
Date: 11 Jan 93 22:52:30 PST
Organization: BBS

> > Please make sure that the version string is near the beginning of
> > the executable, so that the version command can quickly find it.
> > This can normally be achieved by placing the code above (or
> > similar code) at the top of one of the programs modules, and then
> > making that module the first one in the link command.
 
> That won't work if you use the (equivalent of SAS's blink)
> SMALLDATA option, since that merges all the data segments.
 
What I did with Aztec was make a separate tiny source file containing
the version string and a coupla other revision-sensitive little
items, and tell the compiler, for that one source file, to put all
strings in the code segment instead of the data segment.  This does
mean that if you refer to any of those items elsewhere you have to
use a far reference.
From: s37732v@snakemail.hut.fi (Markus Juhani Aalto)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: IntuitionBase
Date: 12 Jan 93 10:33:40 GMT
Organization: Helsinki University of Technology, Finland
Distribution: inet
NNTP-Posting-Host: lk-hp-22.hut.fi
In-reply-to: ruil@ersys.edmonton.ab.ca's message of Mon, 11 Jan 93 16:34:36 MST

In article <Dok9wB1w165w@ersys.edmonton.ab.ca> ruil@ersys.edmonton.ab.ca (Rui Lopes) writes:

   Well, that's what I thought to, but IntuitionBase is a Library structure 
   (ie. you declare it as: struct Library *IntuitionBase) but what I want is 
   the IntuitionBase structure that holds current system information.  I was 
   hoping that there would be some sort of function that would do this, but 
   I can't find any.....
   Later,

   Rui Lopes              ruil@ersys.edmonton.ab.ca 

Because IntuitionBase structure is documented, you should declare it like
this.

struct IntuitionBase *IntuitionBase = NULL;

Setting it to NULL isn`t necessary but it makes it easier to check if
it was open in a clean up code.

Here is a little clip how to use it
----------------------------------
#include	"intuition/intuition.h"

struct IntuitionBase *IntuitionBase = NULL;

main()
{
  ULONG lock;

  IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library",33);
  if(IntuitionBase == NULL) return;

  /* Now we can use IntuitionBase */
  lock = LockIBase(0);
  
  /* Access IntuitionBase in here. */
  info = IntuitionBase->wantedinfo;

  UnlockIBase(lock);     /* or was it UnLockIBase(lock)? */

  etc...
}
--


**************************************************************************
*         Markus Aalto              | Helsinki University of Technology  *
*                                   |                                    *
*  EMail: s37732v@vipunen.hut.fi    | Faculty of Electric Engineering    *
*  Fax:   358-0-8746991 (Sometimes) |                                    *
*                                   | Undergraduate in Computer Science  *
**************************************************************************
From: Jesse_Michael@matrix.rain.com (Jesse Michael)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: 3 Jan 93 07:21:33 GMT
Article-I.D.: matrix.Jesse_Michael.02ts
Organization: The Matrix BBS

In a message dated Sat  3 Jan 93 14:20, Robart@agora.rain.com (joe Bob)
wrote:

>Well, there's nothing wrong about absolute addressing. Every C compiler
>generates absolute addressing as well. But of course the linker generates
>a relocation table that enables LoadSeg() to load the program to arbitrary
>addresses.

>  True, but that's not what he's talking about here.  Absolute addresses
>like AbsExecBase or custom.bltcon0 certainly don't get relocated.

Actually, what I meant were programs that are *hardcoded* to certain
addresses.

-Jesse

-- Via DLG Pro v0.995

--
Haze of Epsilon / Check out Epsilon for the best in NTSC demos!  Ok, so if
you compare us to groups like Anarchy and Silents then we're lame, but what
the hell do you expect from us lazy Americans?!?  :^)
Newsgroups: comp.sys.amiga.programmer
From: pochanay@cae.wisc.edu (Adisak Pochanayon)
Subject: Copying memory
Organization: College of Engineering, Univ. of Wisconsin--Madison
Date: 8 Jan 93 14:39:32 CST

    I need help with writing a program to copy FAST memory to CHIP memory
as fast as physically possible.  I have heard of several methods in asm
to do this, one in particular involving movem.l instructions.  I also need
a routine to clear areas of memory as fast as possible.  If someone could
e-mail me routines to do these functions I would be very pleased.

pochanay@cae.wisc.edu

Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Version Strings...
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Fri, 8 Jan 1993 18:48:45 GMT

In <1993Jan8.111612.25180@sunbim.be> accs1@bagheera.mumath writes:
>I wonder why that stays in the executable. I would expect a good compiler would 
It is an externally visible symbol. The compiler cannot decide wether some
other module will reference it or not.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: SAS/C 6.1 memlib question
Originator: walker@twix.unx.sas.com
Date: Tue, 12 Jan 1993 14:14:35 GMT
Organization: SAS Institute Inc.


In article <1993Jan12.050704.28814@gn.ecn.purdue.edu>, seifert@gn.ecn.purdue.edu (Michael S. Seifert) writes:
|> 
|> My very dear program has a tendency to lock up after 10 to 15 minutes of
|> use, for no immediately obvious reason.  Therefore Ive broken out my group
|> o' debugging tools, including the memlib option in SAS/C.  Although I dont
|> know if this is the problem, once in a while memlib will open a window
|> and say:
|> 
|> Free memory modified (or something of this sort), line 95 file ""
|> 
|> So my question is-- what is file ""...
|> 
|> The program uses two assembly functions and an input handler, everything else
|> is typical c...
|> 
|> mike

This is definately a problem.  I don't know why you're not getting
the filename, but if free memory is being modified, you have a 
memory trashing bug.

What's happening is this:  You allocate some memory.  You set some
pointers to point into the memory.  You free the memory, but don't
clear the pointers.  Sometime later, you write to the memory
pointed to by the pointers.

Memlib detects this by simply not freeing memory when you ask it to.
Instead, it sets it to a known value and watches it.  If it ever
changes, SOMEBODY has written to memory that doesn't belong to them,
and it's almost 100% sure to be your program using old pointers
into it.

As to the filename thing - it's possible that when the memory gets
trashed, the filename gets trashed as well (although not likely).
Look on line 95 in ALL your files for an allocation call.  If you
don't find any, the line number is probably trashed as well.
It should also have given you the filename and line number that
the memory was freed at.

You do have source code to memlib.  If you can't find the problem
by the above technique, I suggest adding code to print EVERY 
allocation that comes through the memlib stuff.  Then you should
be able to figure out where it's allocated by just the address of
the memory, using the log of when it was allocated.  The bigger
your program, the less practical this becomes, obviously.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: Re: SEEKing to EOF
Organization: Jet Propulsion Laboratory
Date: Tue, 12 Jan 1993 18:11:12 GMT

In article <paulm.02tb@pam-sy.UUCP> paulm@pam-sy.UUCP (Paul C. Mrozowski) writes:
>
>  Hopefully someone here can answer a simple (?) question (or maybe just 
>a dumb question). I'm writing a small program that's supposed to open
>a file, read in some information, and write out this info. to a second
>file (appending it to the second file). Everything seems to work, right
>until I do the FPuts, then the program bombs. Here's some of the code:
>
>  (misc includes, and opening of both files).
>
>
>
>j = Seek(file_handle2, 0, OFFSET_END);     /* Move to the EOF() */
>for( ; ; )
>{
>	
>buffer = FGets(file_handle, line, NUM);
>
>	if(buffer == NULL)
>	{
>		Close(file_handle);    
>                Close(file_handle2);  
>		Exit(0);
>	}
>	
>p = strstr(buffer,string);
>
>	if(p != NULL) break;
>
>}
>
>p=p+sizeof(string);
>strcpy(newstr,"Rename ");
>strcat(newstr, "1439");
>strcat(newstr, p);
>
>printf(newstr);
>i = FPuts(file_handle2, newstr);       /* Program bombs right here */

Are you sure? Aside from the fact that these two lines:

	p=p+sizeof(string);
		and
	strcat(newstr, p);

serve absolutely no purpose - your printf statement is not in the correct
format.

It ought to be something like "printf("%s\n", newstr);"

>
>
>  I have a feeling I'm missing something obvious, but I'm not sure what.
>Any suggestions?
>


> 
>Paul
>
>-- 
>
>paulm%pam-sy%sycom@ilium.troy.msen.com
>---
>   Paul Mrozowski	         |  "You can have anything you want but
>   NetMail: paulm@pam-sy.uucp    |   you'd better not take it from me"-GNR
>
>     IBM Logic: "Keyboard Failure, press <F1> to continue..."

Jeff

Newsgroups: comp.sys.amiga.programmer
From: comeau@csanta.attmail.com (Greg Comeau)
Subject: Re: Wanted: info on available C++ compilers
Originator: comeau@well.sf.ca.us
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Thu, 7 Jan 1993 07:45:23 GMT

In article <7cPfs*kI1@kink.PhaedraV.On.Ca> hugh@kink.PhaedraV.On.Ca (Hugh D. Gamble) writes:
>...You always have the
>option of getting the AT&T Cfront c++ front end from Comeau, which
>will be as good as the c compiler you put underneath it, but g++ is a
>top quality compiler.

Neither of those latter two clauses are entirely accurate.

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
Newsgroups: comp.sys.amiga.programmer
From: walt@bcarh1d7.bnr.ca (Walt Sullivan)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: What is htonl() ?
Date: 4 Jan 93 14:56:58 GMT
Distribution: world
Organization: Bell-Northern Research, Ottawa, Canada
In-reply-to: Counsellor@cup.portal.com's message of 23 Dec 92 07:10:38 GMT

>>>>> "Benjamin" == Benjamin Counsellor Reich <Counsellor@cup.portal.com> writes:

Benjamin> I am writing a program based on another's source code.

Benjamin> I am stumped by one line of code:

Benjamin>      *lmark = htonl(*lmark);

htonl() is a byte-reordering function that converts an unsigned
long quantity (32 bits) from host byte order to network byte order.

If the host and network byte orders are the same for your application,
you could:

#define htonl(l) l

Other byte-reordering functions are:
htons() host-to-network-short
ntohl() network-to-host-long
ntohs() network-to-host-short

--
Walt Sullivan
INTERNET: walt@bnr.ca (work)
UUCP: walt@orbit.ocunix.on.ca (home)
FIDO: 1:163/109.4
From: bytey@werple.apana.org.au (Chris Hames)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Flushing Devices; C= doco (mutter!)
Date: 10 Jan 1993 16:23:40 +1100
Organization: werple public-access unix, Melbourne
NNTP-Posting-Host: werple.apana.org.au

gduncan@philips.oz.au (Gary Duncan) writes:

>   
>A few days ago I posed a question on how to flush unused
>devices out of RAM from a program (as distinct from doing it from the 
>command line using "Avail Flush", for example). Nothing in the
>RKMs seemed to answer this question (but read on).

Note that "Avail FLUSH" has a bit of a bug anyway.  To flush it only
tries to allocate 8 Meg(-1).   Problem is many machines now have 16meg or
more so the allocate succeeds and no flush is done!

>Gary Duncan			gduncan@rosella.pts.philips.oz.au	

-- 
Chris Hames
Internet: bytey@werple.apana.org.au
FidoNet: 3:633/353
Xref: sparky comp.sys.amiga.programmer:18259 comp.sys.amiga.hardware:22539
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: HostileTakeOver of Amiga OS
Keywords: flame bait lives here
Date: Wed, 06 Jan 93 05:34:40 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

mcuddy@fensende.Rational.COM (Mike Cuddy) writes:

> the biggest gotcha when taking over the machine is that on >68000 machines,
> the exception vector table is not always at 0.  The VBR (vector base 
> register) is used to move the exception table into fast ram to avoid 
> contention with the custom chips.

Speaking of this, what is the proper way to find the base of the vectors?
Newsgroups: comp.sys.amiga.programmer
From: labenrsa@ICIL64.CILEA.IT
Subject: Re: SASC 6.1 Wrong Protos
Organization: CILEA - v R. Sanzio 4 - Segrate - ITALY
Date: Tue, 5 Jan 1993 13:23:17 GMT
Reply-To: labenrsa@ICIL64.CILEA.IT

In article <38281@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes:
>>And, by the way, either the proto or a pragma file somewhere should
>>mention that these functions are __stdargs, or somebody should provide
>>a double-standard amiga.lib (like the 6.X standard libraries).
>
>This would be a prototype change.  It couldn't be a pragma, since
>these functions are in a linked library,...

Right, the problem is, as I understand, the clib/xxx_proto.h files
are CBM's and should be compiler-independent, so you can't just
stick a __stdargs or __regargs in there. The pragma files, on the
other hand, already  are compiler-dependencies.

How about an include:compiler.h file (a' la iff) with things like
#define STDARGS __stdargs
that could be provided by the compiler manufacturer, or which could
be replaced to adapt to a new compiler? Then the proto files could
have things like VOID ASM foo (RG(a0) APTR bar);

I know this won't be perfect, but I already had to use this, and I
see many people are doing the same. Perhaps it's better to find a
standard place for such hacks now rather than have people tweek their
includes with every compiler release.

BTW, this is still pretty easy, wait for the day when you'll have
to accomodate for a few *picky* C++ compilers... ;)

>>And oh, it seems that the 6.1 Amiga.lib has no HookEntry(), and
>>maybe none of the shorthands for BOOPSI methods mentioned in
>>AmigaMail and BOOPSI examples that are floating around (DM, DSM).
>
>The original Boopsi examples used functions like DM() and DSM(),
>....

Ok, I agree that the new methods names are much better.
>
>HookEntry() is in amiga.lib.
I *may* be wrong, but slink complained it couldn't find it in
the Amiga.lib that comes with SASC6.1. I was compiling with stdargs,
so I had those underscores in symbols. Too bad doing an OML over
amiga.lib is so slow (unless you have an A4000).

Besides, I know I can do without HookEntry, but I was just trying to write
some *portable* code for a mag, hence I had to do without __asm.

			KUTGW  (keep up that good work!)
			Andy

Newsgroups: comp.sys.amiga.programmer
From: jrauti@cs.joensuu.fi (Juhani Rautiainen)
Subject: Re: GCC 2.3.3 link libraries are hosed?
Keywords: blah
Organization: University of Joensuu
Date: Tue, 5 Jan 1993 09:09:39 GMT

engb@gpu.utcs.utoronto.ca (Ben Eng) writes:

>I just installed the gcc 2.3.3 distribution that I ftped from
>amiga.physik.unizh.ch and I am unable to link anything with the
>supplied link libraries.

>libgcc.a, libc.a, libg++.a, libcurses.a, libauto.a, libtermcap.a,
>and libm.a all appear to be hosed.

>"ar tv libc.a" gives:

>rw-rw-rw-       0/0         85826 Dec 29 20:28 1992 __.SYMDEF
>found string >uf<
>ar: libc.a: Inappropriate file type or format

>Since Markus appears to be away for the next little while,
>does anyone know how to rebuild those libraries?  For example,
>where is the source code to the C, curses, and termcap libs?

>I'm going to give the 2.2.2 libraries a try with the 2.3.3
>compiler next, but it would be nice if the 2.3.3 distribution
>could be "fixed".

I fixed these files by hand and they seem to work now. Files can be
found from amiga.physik.unizh.ch by name gcc233-libs-fix.lha.
 
>Ben
>-- 
>e-mail: engb@gpu.utcs.utoronto.ca or ben@jetpen.gts.org (Ben Eng)
>UofT EngSci 9T2                   ``We are all masochists here.''
>Home: (416)-979-8761, (416)-979-7885

Juhani
--
-- 
*******************************************************************************
Juhani Rautiainen     *   University of   * If you can't beat 'em, blow 'em up!
jrauti@cs.joensuu.fi  *     Joensuu       * 	-Dynamo Duck
*******************************************************************************
Newsgroups: comp.sys.amiga.programmer