HDTenEightyP/NetNews huggingface dataset:
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: CISC and RISC
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 19 Dec 1992 19:45:50 GMT

In <1992Dec16.185521.21232@ichips.intel.com> tjehl@sedona.intel.com (Timothy Jehl) writes:
>   There is one (and only one) reason for RISC processors : clock speed.

There's a second one: chip size. Highspeed RISC chips can be still be
small and thus cheaper to produce than same-performance CISC chips.

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: as894@cleveland.Freenet.Edu (Mark Martin)
Newsgroups: comp.sys.amiga.programmer
Subject: TCP/IP for Amiga
Date: 19 Dec 1992 11:21:07 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: as894@cleveland.Freenet.Edu (Mark Martin)
NNTP-Posting-Host: hela.ins.cwru.edu


This may not be technically programming in nature, but here goes. 8-(*).

I've gotten  a hold of the KA9Q TCP/IP package off of the WU system.  I've
had the hardest time modifying it to compile under DICE (Dmakeing is the main
problem).  I was wondering if perhaps there were other FREEware TCP/IP packages
out there, or perhaps others were doing modifications to KA9Q?  What I
really need is just to get KA9Q to be able to dial my local Merit Dialup and
start a slip "session" (I'm not great with terms).  I've been using the same
package (modified) on an IBM, but it won't work the same for my Amiga (which,
besides being nicer to use, MORE IMPORTANTLY, is AT MY HOUSE).  On the IBM
side of things, you could:
attach asy 03fh 3 2048 128 2048 ATDT XXX-YYYY
the important part is the end, which tells the modem to dial the merit dialup,
and start the motors running.  The Amiga port seemingly lacks this.  But besides
this problem, I think it would be nice to enhance the servers on it, and perhaps
tie it in with a bbs project I've been working on (i.e. possibly a public
access bbs running off an Amiga?!)

email replies, please.  I will post them if anyone needs them.

advTHANKSance,
Mark M.
-- 
Mark Martin    			|		The Safe House BBS
Symbolic Source Group		|		(517) 484-0431
Telecommunications solutions.	|		24 hrs, 7 days
Amiga applications and tools.	|		2400/14.4 (v.22/32b), 8N1
Xref: sparky comp.sys.amiga.programmer:17380 comp.sys.amiga.hardware:21547
From: rcarpent@ringer.cs.utsa.edu (Richard Carpenter)
Subject: Animation Techniques - Q.
Organization: Univ of Texas at San Antonio
Distribution: utsa
Date: Mon, 14 Dec 1992 18:10:14 GMT



I have some graphics questions that I hope someone will be kind
enough to answer.  These questions are in regard to speedy graphics
using the system.  The answers I am looking for need not be extremely
detailed.  What I want are some general ideas on implementing the 
program, such as ideas on how to use the blitter for greater speed, etc.

Set-up : 
--------
I wish to create a set of routines that will handle an unbounded 
Two-d map on which objects can be moved around.  A small portion of the 
map will be displayed on the Amiga's screen at one time.  I would like
to be able to scroll around this map and achieve good performance.
There can be any number of objects on the map at a time.  Also, the map
will probably contain (of course) a starfield, or possibly some other
type of permanent (although changing) backdrop.

QUESTIONS:
---------

1.  How can I place stars on the map and keep them refreshed without
    storing an entire copy of the stars somewhere? Is there a way?

2.  What would be an efficient way to implement double buffering for
    the objects that will be moved around the screen?
    
3.  What would be a good way to implement the scrolling playfield. Note
    that there are sections of the screen that are not part of the
    scrolling area.  For example, a control panel on the left side of 
    the screen.

-------------------------------------------------------------------------
I HAVE thought on this subject a little, but I can't seem to come up
with what looks like a nice solution.  Here is what I have so far.

o  Create two bitmaps for double buffering.  Each bitmap will be 1
   'space' larger than the largest object to be used, so that clipping
   can be done easier. (Of course, if I use an intuition window it will
   handle the clipping).
o  Create horizontal and vertical strips of stars.
   These will be used to blit onto the bitmap for erasing.  Both 
   horizontal and vertical strips will be needed to handle horizontal and
   vertical scrolling.  These can be used to erase old objects with the
   background.  
o  Use a linked list of objects to hold all items on the map.  


Any help will be greatly appreciated.  Thanks in advance.

Richard Carpenter

-- 
-------------------------------------------------------------------
			Richard Carpenter
			ringer.cs.utsa.edu
-------------------------------------------------------------------
Newsgroups: comp.sys.amiga.programmer
From: chris@132.236.236.30 (Christopher A. Wolf)
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Content-Type: text/plain; charset=iso-8859-1
Nntp-Posting-User: tc13@cornell.edu
Reply-To: chris@alchemy.tn.cornell.edu
Content-Transfer-Encoding: 8bit
Organization: none
X-Newssoftware: GRn-beta 1.16g (13.12.92) by Michael B. Smith & Mike Schwartz
Mime-Version: 1.0
Date: Mon, 14 Dec 1992 06:57:34 GMT

In article <37848@cbmvax.commodore.com> 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.

> ...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!!!!).
>

From experimentation I had realized that small ints could be passed and
so was filtering them out as you had suggested.  I hadn't realized that
a BSTR could be passed and that's where my problem was I think.  Thanks
for the info.  Your suggestion of using TypeOfMem sounds like it will work
fine.

> 	Isn't compatibility grand?

Yeah.  I had thought my method was an ugly hack but now I find out there
isn't any better way 8)  oh well.

> Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.

Thanks alot for your help!

--
------------------------------------------------------------------------------
Christopher A. Wolf   mail: chris@alchemy.tn.cornell.edu   IRC: cwolf (#amiga)

The rec.arts.sf.starwars Frequently Asked Question List is available via anon.
FTP from the Star Wars archive site at wpi.wpi.edu. "May the FAQ be with you!"
------------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.programmer
From: dbenn@leven.appcomp.utas.edu.au (David Benn)
Subject: Linking with amiga.lib version 2.0
Organization: University of Tasmania at Launceston
Date: Fri, 18 Dec 92 21:38:13 GMT

ARRG!

Okay, I've tried blink, dlink AND alink when trying to link object modules
produced by ZC and A68K in combination.

Blink just causes a software failure to appear, dlink quits with some error
I don't now recall, and alink quits with an error "00000086" (may be more
0s prefixed).

Can someone PLEASE help me out? The combination works fine with older
versions of amiga.lib. If this is such an important issue, then why hasn't
it been documented??? Or has it? I have the 2.0 NDK stuff. I can't find any
help there and the Bantam books on AmigaDOS give no help in the ALINK
section on errors. 

Yes I know amiga.lib links fine with DICE object modules, but I *like* ZC.

I'd really appreciate some official help on this one. Commodore, are you
listening?

In anticip-p-p-pation.

Regards...

-- 
dbenn@leven.appcomp.utas.edu.au
David Benn - Applied Computing, University of Tasmania at Launceston.
There can be no total understanding and no absolutely
reliable test of understanding. (Joseph Weizenbaum)
From: ry41@rz.uni-karlsruhe.de (Bernhard Moellemann)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 16 Dec 1992 12:20:07 GMT
Organization: University of Karlsruhe, Germany
Distribution: world
NNTP-Posting-Host: tp72.rz.uni-karlsruhe.de

In article <71731@cup.portal.com>, Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) writes:
>What I did was create a little routine that checked the name against a 
>list which includes all the devices I wish to ignore such as:
 
>   PIPE, RAM, RAD, VD0, SER, PAR, ect...
 
Rubbish. I don't know under which name a user mounted a handler/filesystem.
Or C= introduces the brandnew MAGIC:-Handler; is it a "real" disk or not?

Or shall I exclude all devices I don't know? Again I get problems with the 
4.0 MAGIC:-Handler.

   Bernhard

PS: you missed PIP: and VD0: is a real disk: you see, we need another way.

-- 
 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/
From: tctrautm@lifestyle.rhein-main.de (Tim Trautmann)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Strange things with my system
Date: 12 Dec 92 23:34:59 GMT
Organization: Life-Style

Do you know, if I can switch my psu from 220VAC to 110VAC or vice versa?

Tim Trautmann         e-mail 1: tctrautm@lifestyle.rhein-main.de
Roedermark / Germany  e-mail 2: tim.trautmann@P26.F33.N249.Z2.FIDONET.ORG
                      FIDO-NET: Tim.Trautmann@2:249/26.33
From: mjw+@cs.cmu.edu (Michael Witbrock)
Newsgroups: comp.sys.amiga.programmer
Subject: alleged Bug in SAS/C V6.1? IS NOT A BUG, but...
Date: 17 Dec 92 14:28:24 GMT
Article-I.D.: cs.MfAFgcS00hsBMfL35d
	<BzCv72.MBF@unx.sas.com>
Distribution: comp
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.amiga.programmer: 16-Dec-92 Re: Bug in
SAS/C V6.1? Doug Walker@twix.unx.sas (1890)

> |> 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.

> The implementation is free to determine value ~0 has, but the standard
> mandates that the TYPE of the value is definately signed int.  On any 
> two's complement machine, ~0 is going to be -1, and that's what it is 
> on our implementation.  The real problem here is not that the value is
> -1, but rather that you have an overflow:  you are assigning
> 0xffffffff to something that can hold at most 0xffff.  You've lost
> the upper four f's.  The fact that the compiler prints the constant
> as -1 is an artifact of the given machine we're running on, but even
> on a one's complement machine there is precision lost here.

It doesn't like 
unsigned short x = ~(unsigned short)0;
either.
Shouldn't it?  Maybe ~ can only work on ints.....  He goes and looks at
the ANSI version of 
K&R

p. 204 
"A7.4.6 One's Complement Operator
  The operand of the ~ operand must have integral type, and the result
is the one's complement of its operand. The integral promotions are
performed. If the operand is unsigned, the result is computed by
subtracting the value from the largest value of the promoted type [which
seems to be unsigned int, if  I read SS A6.1 correctly]. If the result
is signed, the result is computed by converting the promoted operand to
the corresponding unsigned type, applying ~, and converting back to the
signed type. The type of the result is the type of the promoted operand."

OK, so If I understand this right,  
~0  == ~ [signed] 0 == [signed]  ~ [unsigned int]0 == [signed int] -1   
always. AND the score is SAS/C 1,  detractors, 0.

However.
~(unsigned short int)0 [the new case that I'm annoyingly introducing], 
is  [unsigned int] 1111 1111 1111 1111B   i.e. a large unsigned number!
(but still an int, which won't fit into an unsigned short) and CAN'T be
written as -1
which the compiler does in its warning. 

So the score of now, I think,  SAS/C 1, detractors [well, not really, but...] 1

michael
Newsgroups: comp.sys.amiga.programmer
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: Re: A few Handler/FileSys Q's (Mod.Long.)
Keywords: handler filesystem packets Amiga DOS AmigaDOS lock FileLock
Organization: Jet Propulsion Laboratory
Date: Thu, 17 Dec 1992 22:01:50 GMT

In article <1992Dec17.051905.1@economics.adelaide.edu.au> djung@economics.adelaide.edu.au (David Jung) writes:
>I am in the process (well beginning anyway) of writing a filesystem.  I have a
>few questions.
>
>First here's what I have discovered ... a scenario ...
>
>(to carry this out you need two floppy drives and a disk with a moderately
>long text file)
>
>If I place a disk containing a text file into one drive - say df0, then open
>up a shell and type 'cd more' & 'more file' the file is displayed and the
>more program obtains a lock on the file (and the root dir incidently).
>
>If I then remove the disk - the locks the FFS filesystem issued to More
>appear on the dol_LockList of the disk's volume node in the DosList.
>
>If I then open a second shell and type 'ls diskname:' (where diskname: is the
>disk I just ejected) - I get the usual "please insert volume diskname in any
>drive".  This is because DOS has discovered the volume node's dol_Task is NULL.
>
>OK - so far so good.
>
>Cancel the requester.  Now - with the disk still ejected - press the space bar
>in the more window until more runs out of buffered file and has to read more
>from the disk.  Now I get a "Please insert volume diskname in device df0:".
>(Note this also happens if the disk has been inserted into the other drive!!)
>(i.e. is wants me to remove it from df1 and insert it into df0!)

Locks cannot be used accross file systems as I would imagine applies to other
objects as well (e.g. filehandles). DF0: and DF1: are distinct FS. 

>
>Note that it wants df0 not any drive.  I ASSUME the following has happened.
>
>More has asked DOS to read more of the file, and DOS has used the FileLock's
>fl_Task field to decide which handler to send the packet to. (only place
>it can get it from since the volume node's dol_Task is NULL).

The file handle itself contains the address of the handler message port in 
the field fh_Port or fh_Type. I had read somewhere that the meaning of these
two fields were reversed. I think it was the article by John Tobes which
appeared in the long since defunct Transactor magazine. 

>
>The handler has recieved a packet containing a lock that it is no longer
>managing (no matching key or whatever) - and has put up the requester asking
>for the volume.  My questions are (finally)

MORE would simply issue another ACTION_READ DOS packet. The file handle
contains the address of the handler message port. MORE would have only
obtained a lock on the file to ensure its existance and find out how large
it was. 

Hope this helps.

Jeff


Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re:  SAS6.1 users: please read
Originator: walker@twix.unx.sas.com
Date: Fri, 11 Dec 1992 19:33:47 GMT
Organization: SAS Institute Inc.


In article <wfaust.098k@venus.adsp.sub.org>, wfaust@venus.adsp.sub.org (Wolf Faust) writes:
|> In article <ByMz9y.J0H@fc.hp.com> koren@fc.hp.com (Steve Koren) writes:
|> >LORETI, Maurizio (MLO@SLACVM.SLAC.STANFORD.EDU) wrote:
|> >> Is this a real error? strlen returns a size_t argument
|> >> according with ANSI, and size_t (defined in <stddef.h>) is
|> >
|> >Maybe you're right; maybe its supposed to because size_t is unsigned int
|> >even though num is signed.
|> >
|> >However, at the very least it is something to be aware of, because when
|> >I compile this under 5.10b it does just the opposite thing with the same
|> >code :-)
|> 
|> According to ANSI it's compiler depended. So it may change from
|> compiler to compiler, version to version, revision to revision...

This is Not True.  ANSI does mandate the behavior, and 6.x does it
correctly.  In 5.x, I think the prototype for strlen declared it as
returning "int", so the result was indeed negative;  if you had
tried it with the ANSI library/header file update, it would have
come up with the same result as 6.0.

|> Wolf Faust                 Internet: wfaust@aurea.hotb.sub.org

-- 
  *****
=*|_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: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: THANK YOU!! (ReadArgs()).. but I'm handling something wrong
Date: 21 Dec 92 03:54:37 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

shulick@navajo.ucs.indiana.edu writes:
>Well, the /M/A works and everything.  Umm, something stopped working,
>though.  :)  My template has gotten big, and I have these switches..
>
>".....,B=Blah/S,F=Foobar/S,....."
>
>Well, I used to check them like this:
>
>   blah_mode = arr[1] == -1;   /* assume 'B=Blah/S' was the second in */
>                               /* the template */

	Two things: 1) check for 0/non-0, not exactly -1.  All the autodoc
promises is non-0.  2) It's best to define an enum or a bunch of defines, one
for each parameter in the template.  This means that if you change the
template, all you have to do is change the enum/defines, instead of searching
through your source code.

>Well, it used to work, but now I have lots of things in my template, and
>even though I DON'T specify a switch, it gets set -1 anyway!  So what's
>the REAL way to check if a switch is specified?  Please POST, do NOT
>reply via e-mail.. I get way too many responses to read. :)   Thanks.

	Make sure the array is set to all 0's before calling ReadArgs.  Other
than that, it must be some sort of bug in your program.

-- 
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: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: MPEG on the Amiga
Date: Fri, 11 Dec 92 13:18:21 PST
Organization: The Portal System (TM)
  <1992Dec10.113642.15859@mpifr-bonn.mpg.de>
  <1ga0g2INN6a0@uni-paderborn.de> <Bz3K1K.3K7@hermes.hrz.uni-bielefeld.de>

Is there an MPEG viewer that will run on an ECS machine?
From: shorio@polyslo.csc.calpoly.edu (Shigenori Horio)
Newsgroups: comp.sys.amiga.programmer
Subject: Need help desparately!!!
Date: 16 Dec 92 01:35:14 GMT
Organization: Cal Poly State Univ,CSC Dept,San Luis Obispo,CA 93407

I need Lattice C programming help.  I  have been working on the signal
sampling program on my Amiga 3000 w/ OS 2.04.  I am reading the signal data
from parallel port and putting it to a buffer.  I used CIA routines
( AbleICR, AddICRVector, RemICRVector, ans SetCR) to get data from ciaa.ciaprb
register.  The program works fine when I just read data for a short time of
priod. Say, enough time to fill 1024 bytes data; however, when I put
this routine in the infinite while loop to get sample continuously, the program
stops reading data after 5 to 10 seconds.  I think CIA register gets too busy.
I read all AMIGA ROM Kernal manuals, but it only briefly mentions CIA resources.
If someone know how to fix problem, please let me know!  I will be really 
appreciated. Thanks.

-Fory Horio
 Email at shorio@polyslo.csc.calpoly.edu 
 Phone at 805-595-7639
Xref: sparky comp.sys.amiga.programmer:17574 comp.sys.amiga.hardware:21822
From: tlbechar@thunder.LakeheadU.Ca (Timothy Lee Bechard)
Newsgroups: comp.sys.amiga.programmer
Subject: Cobol
Keywords: cobol, amiga
Date: 15 Dec 1992 19:39:30 GMT
Distribution: comp
Organization: Lakehead University; Thunder Bay, Ont


	I was just wondering if there was a copy of a public domain / commercial
version of COBOL for the Amiga.  If there is a copy, could someone please leave
me mail with information on how to obtain it...

	Thanx.


Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: make utilities
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 12 Dec 1992 20:51:04 GMT

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.

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: tron@davinci.uni-paderborn.de (Matthias Scheler)
Newsgroups: comp.sys.amiga.programmer
Subject: How to detect a 040-MMU
Date: 14 Dec 1992 20:51:35 +0100
Organization: Universitaet Paderborn, Germany
NNTP-Posting-Host: davinci.uni-paderborn.de


	Hi,

a friend of mine wants to know how he can detect a 040 MMU from his program.
He took a look at the sourcecode of SetCPU, but it doesn't work properly
with the 68040 MMU.
-- 
Matthias Scheler                                         tron@uni-paderborn.de
University of Paderborn (Germany)
From: dwdyer@eskimo.com (Wayne Dyer)
Newsgroups: comp.sys.amiga.programmer
Subject: EMITS (SAS)
Date: 15 Dec 92 03:07:11 GMT
Distribution: na
Organization: -> ESKIMO NORTH (206) For-Ever <-

I seem to recall that EMITS is part of SAS's technical support included
with 6.0 -- but, I can't -=find=- anything regarding it in the stuff 
they sent me with 6.0.

Well, that is the stuff I can find and/or still have that they sent me.
I may have just lost it.  Can someone point me to where the info is?


-- 
Wayne Dyer, aka   || "I mistrust all systematizers and I avoid them.
dwdyer@eskimo.com ||  The will to a system is a lack of integrity."  F.W.N.
-- 
Wayne Dyer, aka   || "I mistrust all systematizers and I avoid them.
dwdyer@eskimo.com ||  The will to a system is a lack of integrity."  F.W.N.
From: chr@senga.ka.sub.org (Christian Riede)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: MX_KIND Radio buttons
Date: Tue, 15 Dec 1992 15:49:07 GMT
Organization: Private UUCP site
X-Newsreader: Arn V1.00 pre

In article <1992Dec14.134809.22832@eua.ericsson.se>, Tomas Pihl writes:

> Could someone tell me how to tell (at any time) which one
> of my radio buttons that are currently selected?

You'll have to remember the actual value, something like:

while (IMsg = GT_GetIMsg(Window->UserPort))
{
	/* remember values */
	Class = IMsg->Class;
	Code  = IMsg->Code;	
	IAddr = IMsg->IAddress;

	/* replay message */
	GT_ReplyIMsg(IMsg);

	switch(Class)
	{
		case GADGETDOWN:
			switch(((struct Gadget *)IAddr)->GadgetID)
			{
				case MX_SELECT:
					MX_Select = Code;
			}
	}
}

Gruss, Christian

-- 
Christian Riede, Lange Strasse 88, D-W7500 Karlsruhe 51, Germany 
Tel. (+49) 721 {886091 | 608-4487 | 608-2749}  |   iso-8859-1:   
EMail: chr@senga.ka.sub.org, riede@ira.uka.de  |  ==aeoeuess 
            Fuel is a great substitute for brain