HDTenEightyP/NetNews huggingface dataset:
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 15 Dec 92 01:48:09 GMT
Organization: BBS

> I'm certain that a sizable list of OS-friendly demos, and probably
> all the well-known demos, can be supplied by the people on this
> here net.  I'll start the list with Boing! (the first demo) and
> Juggler.
 
Boing! had to be revised more than once to work on evolving OS
versions.  The first A1000 version had to be fixed in some way for
1.2, I think ... this is understandable when you remember that Boing!
was written when the Amiga was a stack of wire-wrap boards instead of
a set of chips.
 
> Face it, the demo scene will die.  No one will do OS demos.  What's
> the point?  You're far too constrained by the system.
 
90% of what I've seen in demos is inside the constraints of the
system.  I've seen some fairly slick demos that could have been done
all the way through with no hardware banging at all, and many others
where only one little feature might have needed it, such as a copper
plasma.  I suppose all those /<00l vektors would not like the
overhead of Draw(), but who actually wants to sit through vektor
demos anyway??  They're BORING.
 
About the only "contraint" I can think of that you have by going
through the system is that copperlists can't be as fancy.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Base address of custom chips (2nd try)
Date: 10 Dec 92 01:26:57 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

iikoch@techfak.uni-bielefeld.de (Ingolf Koch) writes:
>Hello,
>is there a safe way to determine the base address of the custom chip reg.s
>and the CIAs? Yes, I know: extern struct ...
>
>But will these programs run on other (later) models of the amiga? This method
>is not much better than to explicitly set the value to 0xdff000 (since this
>is the way the compiler handles the `extern struct' call).
>
>Commodore warns not to use any other absolute address than 4. But I cant find
>any structure (like ExecBase, GfxBase, ...) containing pointers to the
>chip reg.s.

	This is an unfortunate but unchangable exception to the "no absolute
addresses other than $4" rule.  In the rush to get 1.0 out, they didn't think
of that.  Maybe it could have been corrected in 1.1 or even 1.2, but after
that it was too late.  The best way to get around it now will be RTG.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.sys.amiga.programmer
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re: make utilities
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Sun, 13 Dec 1992 13:03:57 GMT

In article <1992Dec12.205104.29005@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <1g7h6gINN9ok@crcnis1.unl.edu> tbills@cse.unl.edu (Trent Bills) writes:
>>  cd src; make -D.....
>>Anyway, the point is that this doesn't work with any of the make
>>utilities that I have tried.  Some software packages contain
>>dozens of subdirectories, and running make in each one would be
>>a real pain.
>
>Unfortunately this requires a working Bourne shell clone since
>make simply calles the shell to execute such lines.
>
>The GNU make port from Markus Wild together with his port of the
>PD ksh seem to solve most of these problems.

Mostly correct, though I never ported GNU make ;-) I'm using dmake myself,
and on Makefiles that dmake chokes on, BSD make. 

-Markus
-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
Xref: sparky comp.sys.amiga.programmer:17516 comp.sys.amiga.hardware:21759
From: ahansfor@bigwpi.wpi.edu (Andrew L. Hansford)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 18 Dec 92 07:18:30
Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
	<Bz8FD1.Dxt@ns1.nodak.edu> <6587@pdxgate.UUCP>
NNTP-Posting-Host: bigwpi.wpi.edu
In-reply-to: idr@rigel.cs.pdx.edu's message of 18 Dec 92 00:56:48 GMT

>>>>> On 18 Dec 92 00:56:48 GMT, idr@rigel.cs.pdx.edu (Ian D Romanick) said:

idr> Article-I.D.: pdxgate.6587

idr> In article <Bz8FD1.Dxt@ns1.nodak.edu> dewald@plains.NoDak.edu
idr> (Eric Dewald) writes:
>What are the advantages of CISC and RISC?

idr> Well, since RISC is a more basic instruction set, it is MUCH
idr> easier for a compiler to generate good code for it.

You are joking right?  The compiler and even assemblers are the
elements that got much more complicated.  Dependency avoidance, delay
slot scheduling...easy?

idr> It's to the
idr> point now on RISC machines that a native compiler can usually
idr> BEAT and assembly language progammer (snif) 

No doubt.  Compiler technology has made large advances in dealing with
RISC.  I am not surprised that a compiler with many man hours of
development can outperform an assembly programmer on any section of
code unless the programmer is VERY familiar with pipeline scheduling
algorithms. 


idr> It also makes it so
idr> that the instructions themselves are smaller and can be fetched
idr> and decoded quicker.

The instructions are generally the same format for all instructions
(or the processor supports very few formats) that makes them easier to
decode.  THEY ARE NOT SMALLER.

-- Andrew Hansford
   ahansfor@wpi.wpi.edu



Newsgroups: comp.sys.amiga.programmer
From: amc@wucs1.wustl.edu (Adam Costello)
Subject: Re: Bug in SAS/C V6.1?
Organization: Washington University, St. Louis MO
Distribution: comp
Date: Tue, 15 Dec 1992 10:38:50 GMT

In article <1992Dec15.003553.23198@oracle.us.oracle.com> dnavas@oracle.uucp (David Navas) writes:
>
>Really, ~0 is NOT the same thing as -1.  Not -all- computers in existance
>are two's complement, you know -- and the symbols mean something different
>too.  Had I meant -1, I'd say -1, had I mean ~0, I'll say ~0.  Having to
>cast ~0 back to an unsigned state is, well, icky....
>
>Would you at least be kind enough to make ~0x0 be unsigned?

How about   ~0u   ?  I think that should be the same as
(unsigned int) ~0   to any ANSI C compiler.
AMC
Newsgroups: comp.sys.amiga.programmer
From: umfehr06@ccu.umanitoba.ca (John Fehr)
Subject: wierd sas/c bug
Organization: University of Manitoba, Winnipeg, Canada
Date: Sat, 19 Dec 1992 20:10:09 GMT

I've been trying to compile an lpmud driver with sas/c, and I've
come upon a wierd bug...  In my main program file, I have the following
code:

char master_file = "obj/master";

...
main() {
/* bunch of other variables declared */
	printf("master_file='%s'\n",master_file);
...

When I compile and run this, I get:

master_file='bj/master'

Has anyone run across this bug?  That printf was the first statement
that is executed in the program, so master_file shouldn be obj/master
at that point.  
  Any help would be greatly appreciated.


   John
    umfehr06@ccu.umanitoba.ca

-- 
-----------------------------------------------------
-  John Fehr                        -    DoD#505    -
-  umfehr06@ccu.umanitoba.ca        -    GPz550     -
-  umfehr06@silver.cs.umanitoba.ca  -  A3000 kicks! -
From: pjotr@ludd.luth.se (Peter Sj|str|m)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Emacs and SAS/C
Date: 18 Dec 92 22:51:52 GMT
Organization: Lule} Tekniska H|gskolas Datorf|rening - Ludd

In <1gs1k5INN1av@aurora.unice.fr> beust@aurora.unice.fr (Cedric Beust) writes:

>	I don't understand why you need a personal compile.el package to
>	compile, Peter? The default compile-mode and error-parsing
>	mechanism work like a charm without the least modification. I didn't
>	take a look at your code, did you improve them?

	I got a friend to improve the elisp code as I'm no guru on it myself.
As you can see in the top of the file (one of them) it now relies on one regexp
only, so it's very easy to adapt to new error outputs. The guy who wrote it
wrote it based on his modified compile.el and that's why I sent that too.
It didn't work with the original compile.el. It was just a quick hack.

>	I will possibly upload cpr.el to the usual ftp sites once it gives
>	me satisfaction and if there's interest in it, so let me know.

	Yup!

		/Peter
Xref: sparky comp.sys.amiga.programmer:17573 comp.sys.amiga.hardware:21821
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 16 Dec 92 20:09:07 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

adap@edmund.cs.andrews.edu (Edsel Adap) writes:
>Another Advantage of RISC is the abundance of Register memory.  CISC
>commonly contains few registers (The 68000 has 8 data registers and 8
>address registers) while RISC processors contain anywhere from 32 registers
>to a few hundred registers (It is not uncommon to have RISC processors that
>have 512 registers).

	Actually it is uncommon, the prime purveyor of >32 register RISCs
being SPARC.  Most of the others have 32 (or a few less in some cases),
and one of them is usually hardwired to 0 (usually R0).

>There is also a significant amount of parallellism and pipelining in RISC
>chips.  As soon as an instruction is started another instruction may be
>started even before the completion of the previous instruction.  Output of
>one instructions is passed on to another Unit in the chip for further
>processing while the current unit executing the instruction fetches a new
>instruction to process.  On many RISC chips as many as 4 instructions can be
>completed in one clock cylce as a result of this.

	This has nothing really to do with RISC vs. CISC - CISCs have been
doing for quite a while also.  It's _easier_ to do in a RISC, because of
predictable execution times and less interactions.  Also, 4 completing in the
same cycle is quite rare (maybe the 88110, with it's many functional units
can - even Alpha I don't think does this, it's 2-way superscalar, though they
are planning on 4-way).

>CISC I think is easier to program.  RISC is difficult as you have to worry
>about timing your instructions properly.  If you issued a memory write and
>do a read from the same location immediately after the write instruction,
>the data you may have wanted to read may not be there yet!  So you may have
>to issue the write a few steps earlier than you would normally on a CISC
>chip.

	This is not a problem.  You code as if all instructions complete
immediately, and you let the code reorganizer rearrange it all for fastest
(and safe) execution.  Machines with interlocks will run un-reorganized code,
machines without won't even run it.

	This really is a discussion for comp.arch...

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: bombadil@diku.dk (Kristian Nielsen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 14 Dec 92 14:59:07 GMT
Organization: Department of Computer Science, U of Copenhagen

jesup@cbmvax.commodore.com (Randell Jesup) writes:

>chris@alchemy.tn.cornell.edu writes:
>>However, apparently dol_StartUp does NOT always point to a valid
>>FileSystemStartupMsg (hereafter abbreviated FSSM) even though IsFileSystem()
>>returns true.  I have particularly found this to be the case on devices

>	This is an ugly area.  Unfortunately, early in the Amiga days (or
>perhaps back in tripos), someone though strings would be neat to hold
>parameters for handler startups.  So they implemented BSTRs as an alternative
>to FSSMs.  They also thought that passing small integers would make it slightly
>easier on whoever was writing the port-handler (SER/PAR/PRT).  So they also
>added support to pass an integer.  So, startup can hold 3 things: an integer,
>an BPTR to a BSTR, or a pointer to an FSSM (actually I think it's a BPTR).
>Ugly, eh?

YES! I've found this out the hard way while developing XFH: (a
compressing file system handler).I  pass a string to the handler in the
'Startup' field of the mountlist. Even system programs like C:Info seem
to try to interpret this as a FSSM and cause enforcer hits.

I was under the impression that passing a string to a handler as startup
is a completely legal thing to do, but perhaps this is not so?

	- Kristian (author of XFH).
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 19 Dec 92 10:21:24 PST
Organization: BBS

> I tried TypeOfMem() but I really missed some devices after that,
> because their device name (and I think the environment vector, too)
> was in ROM.
 
I *do* wish C= provided a supported method of asking the system "what
addresses are legitimate ROM addresses".  I've had uses for such a
thing about half a dozen times.  An extra MemHeader in ExecBase would
do the trick
 
Newsgroups: comp.sys.amiga.programmer
From: ry41@rz.uni-karlsruhe.de (Bernhard Moellemann)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: WShell: Hangning forbid!
Date: 12 Dec 1992 17:04:31 GMT
Organization: University of Karlsruhe, Germany
Distribution: world
NNTP-Posting-Host: tp70.rz.uni-karlsruhe.de

In article <1992Dec12.143541.21468@sth.frontec.se>, bjst@sth.frontec.se (Bjorn Stenberg) writes:
>
>A while ago there was some talk about process syncronization when
>multithreading, and Randell Jesup suggested doing:

>   Forbid();
>   Signal(parent,sig);     // tell parent we exited

>Well, I do this in a child of mine, but after the parent exits WShell
>complains with the message:

>***Hanging forbid!

>Is WShell just being paranoid or am I doing something wrong? (I'm not supposed 
>to Permit() or anything in the parent, am I?)

This is only true for a "single-job-process". But your process is running
under the Shell's schedule, so the Forbid() would lock the shell.

-- 
 Bernhard Mllemann   <spare  space>   Chairman of the Nessy-Fan-Club   //
 internet=zza@rz.uni-karlsruhe.de <space> FIDO=2:241/7506.42  IRC=ZZA  //
 nessynet=008  Lifenet=77:7700/11.42  greetings to my Marsupilami  \\ //
 2000/500 Technical Reference Manual:  "A1000, the original Amiga"  \X/
Newsgroups: comp.sys.amiga.programmer
From: aa302@Freenet.carleton.ca (Russell McOrmond)
Subject: Re: Hardware Reference Manual
Reply-To: aa302@Freenet.carleton.ca (Russell McOrmond)
Organization: The National Capital Freenet
Date: Sat, 12 Dec 1992 17:30:29 GMT


In a previous article, idr@rigel.cs.pdx.edu (Ian D Romanick) says:
>This whole issue is kinda like the gun control issue in the US.  If you

  Being a Canadian that giggles at the gun 'lack of control' issue in
the U.S., I agree.  What gun control allows is an easier sence of
the old 'black hat, white hat' issue of 'good guys and bad guys'.  Those
with a Gun are eithor Cops or Criminals.

  In the case of Amiga hardware, you eithor have CBM and other
O.S. companies, and you have poor authors who are criminals in my mind
as they rip people off with their software that doesn't run on upgradable
systems.


  CBM no longer wants to document things that they are not going to guaruntee
exists in every machine.  An Amiga should be defined as a computer
with a motorola 68000 series processor running AmigaDos, not as a
machine with 2M maximum of Chip ram on an ECS clone that cannot
be expanded because no software would work on the expanded
machines.   Why are you hardware hitters not allowing us to do with 
audio and video what we have now accomplished with hard drives, modems, 
etc - complete hardware independance.
-- 
 Russell McOrmond, Ottawa Ontario, Canada    | Standard Disclaimer applies.
 Freenet: aa302@freenet.carleton.ca (Faster) | Current WELMAT 'keeper of
 Home: rwm@Atronx.OCUnix.On.Ca,  1:163/109   | sources.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 14 Dec 92 04:04:25 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

chris@alchemy.tn.cornell.edu writes:
>However, apparently dol_StartUp does NOT always point to a valid
>FileSystemStartupMsg (hereafter abbreviated FSSM) even though IsFileSystem()
>returns true.  I have particularly found this to be the case on devices
>which are not physical disks such as RAM disks or remotely mounted
>network devices.

	This is an ugly area.  Unfortunately, early in the Amiga days (or
perhaps back in tripos), someone though strings would be neat to hold
parameters for handler startups.  So they implemented BSTRs as an alternative
to FSSMs.  They also thought that passing small integers would make it slightly
easier on whoever was writing the port-handler (SER/PAR/PRT).  So they also
added support to pass an integer.  So, startup can hold 3 things: an integer,
an BPTR to a BSTR, or a pointer to an FSSM (actually I think it's a BPTR).
Ugly, eh?

	A heuristic approach: first, filter out values <64 (64*4 = the size of
the 680x0 vector table, no pointer can be here).  Next, see if TypeOfMem
on startup<<2 says it's real memory.  Next, see if the various FSSM pointers
(or BPTRs) point to real memory (TypeOfMem again).  That should catch almost
all cases.  (UGLY!!!!).

	Isn't compatibility grand?

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.amiga.programmer
Date: Tue, 15 Dec 1992 19:26:49 -0500 
From: Michael Witbrock <mjw+@cs.cmu.edu>
Subject: Re: Bug in SAS/C V6.1?
	<1992Dec15.003553.23198@oracle.us.oracle.com>
Distribution: comp

Excerpts from netnews.comp.sys.amiga.programmer: 15-Dec-92 Re: Bug in
SAS/C V6.1? David Navas@oracle.uucp (1594)

> >>SAS/C gives me a warning in a line containg ~0, saying something
> >>like that I can`t init unsigned short to -1. Okey, I understand that
> >>it ~0 means the same as -1 but if I have wanted to use signed numbers
> >>I would have specified it as -1.

> >This is just the compiler trying to keep you out of trouble.  :-)

> I'd like to go on record as saying that this sucks :)

Really, ~0 is NOT the same thing as -1.

That depends on the type of  0.   If 0 is defined as a signed int, and
the machine is an amiga, then it's the same, and it can demand that you
do ~(unsigned short)0 .
However, if this is the case, then it shouldn't let you do  unsigned int
x = 5; either

I'd tend to agree that this optimisation (~0 == -1) is producing the
wrong results, and if it can't stop making the warning, it should
evaluate the ~ at runtime.

michael
Newsgroups: comp.sys.amiga.programmer
Subject: Re: App(Icon|Window) and Style Guide.
From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer)
Date: 18 Dec 92 08:12:02 -0400
Organization: NRL SPACE SYSTEMS DIVISION

In article <BzF2Jo.6Gu@csugrad.cs.vt.edu>, jaker@csugrad.cs.vt.edu (Jake Rose) writes:
> cschneid@amiga.physik.unizh.ch (Christian Schneider) writes:
> 
>>Following AUISG, AppWindows 'should' provide a drop box like IconEdit.
>>AppIcons... hmm... perhaps up to the icon designer to ensure his AppIcon
>>is not mistaken for a normal icon..
> 
> I don't know - actually, I'd *love* it if CBM would modify the Workbench so that
> if you drop a file or set of files onto *any* executable's icon, it gets
> launched with those files as parameters.  This is much more intuitive than the
> current method of WB parameter passing (click on the executable, then select the
> argument files, double-clicking on the last one).>

It would be nice if at least drawers and appicons, appwindows would appear
selected as users drag items over them.
                                                        
--
Doug Dyer   *    STI   *    dyer@nrlvax.nrl.navy.mil    | "(2B) | !(2B) -> ?"
DISCLAIMER:  These are my opinions, and not necessarily |  LOWLY SHOPKEEPER,  
those of STI, NRL,  and most likely you too.            | WHERE IS YOUR PEZZ!
--------------------------------------------------------+---------------------
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Screen lists & locking
Date: 14 Dec 92 22:31:54 GMT
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore-Amiga, Inc.  West Chester, PA.

In article <ByywFv.Mzx@fc.hp.com> koren@fc.hp.com (Steve Koren) writes:
>I'm trying to set a new public screen, and I'm doing something wrong,
>but I don't know what.  My code says:

From the autodoc for LockPubScreenList():
	The nodes on the list are PubScreenNode structures.
	Act quickly while holding this lock.  The restrictions
	on LockIBase() apply here as well.

So, we look at the autodoc for LockIBase():
	NOTE WELL: Do not call any Intuition functions (nor any graphics,
	layers, dos, or other high-level system function) while
	holding this lock.

You're deadlocking because you're violating this, and calling Intuition
functions inside LockPubScreenList().  Try:

	list = LockPubScreenList();

	/* Now find the node */
	strcpy( mybuffer, node->ln_Name );

	UnlockPubScreenList();

	/* This happens outside LockPubScreenList().  Also, there
	 * is no need to LockPubScreen() first.
	 */
	SetDefaultPubScreen(node->ln_Name);

>   - steve

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"Opinions enlarged to show detail"
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: ENFORCER hits from SLINK SAS/C 6.0
Originator: walker@twix.unx.sas.com
Date: Fri, 11 Dec 1992 19:50:49 GMT
Organization: SAS Institute Inc.


In article <BywF1y.ALy@unx.sas.com>, jamie@cdevil.unx.sas.com (James Cooper) writes:
|> That's SAS in all uppercase.  No, they don't own & run it, but they do
|> try to make sure we don't do anything which will relinquish any part of
|> our ownership of the product... as any decent legal staff should.
|> -- 

Actually, the correct attribution is "SAS Institute, Inc.", as the
lawyers would no doubt tell you 8^)

|> Jim Cooper

-- 
  *****
=*|_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.
From: bjst@sth.frontec.se (Bjorn Stenberg)
Newsgroups: comp.sys.amiga.programmer
Subject: WShell: Hangning forbid!
Date: 12 Dec 92 14:35:41 GMT
Organization: IDK/Frontec - System Design Group


A while ago there was some talk about process syncronization when
multithreading, and Randell Jesup suggested doing:

   ...
   Forbid();
   Signal(parent,sig);     // tell parent we exited
}

to make sure the child has exited before any other process gets a time slice.

Well, I do this in a child of mine, but after the parent exits WShell
complains with the message:

***Hanging forbid!

Is WShell just being paranoid or am I doing something wrong? (I'm not supposed 
to Permit() or anything in the parent, am I?)

Any hints are appreciated.

		-- Bjorn

---------------------------------------------------------------------------
Bjorn Stenberg, Stockholm, Sweden                       bjst@sth.frontec.se
---------------------------------------------------------------------------
Xref: sparky comp.sys.amiga.programmer:17480 comp.sys.amiga.hardware:21712