HDTenEightyP/NetNews huggingface dataset:
From: Brian_Mury@amusers.UUCP (Brian Mury)
Newsgroups: comp.sys.amiga.programmer
Subject: Case-Sensitive COMMSEQ?
Distribution: world
Date: 14 Dec 92 22:31:25 PST
Organization: AmUsers - The Amiga Users Group of Victoria BC

I'm using menus in an assembly program I'm writing, and have used command
sequences (i.e. Amiga-Q insteading of selecting 'Quit' from the menu) for
some of the menu items. How can I make the command sequence case sensitive
so that, for example, Amiga-Q and Amiga-q would be interpreted as different
menu items?
Also, how can I differentiate between the left and right Amiga keys?
(Intuition only uses the left Amiga key for command sequences). Oh yeah,
I'm using 1.3.

-- Via DLG Pro v0.995

Send email to bmury@Engr.UVic.CA, NOT to Brian_Mury@amusers.UUCP
Newsgroups: comp.sys.amiga.programmer
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: ReadArgs(): One last problem!!
Originator: shulick@navajo
Reply-To: shulick@navajo.ucs.indiana.edu
Organization: Vallen Software
Date: Fri, 18 Dec 1992 01:58:21 GMT


Sorry for the all the posts, but our sysadmin hasn't gotten around to
fixing trn.  (I can't cancel my articles)

Anyway, if I do this:

  rd = ReadArgs("Files/M/A .......

The 'files' are stored in rd->RDA_Buffer.  But how do I parse those out?
Should I juse use some mathematical method like:

Well, screw it.. I was going to try to write a program to separate the
files.  It would've worked, excep this rd->RDA_BufSiz seems to be
limited to 128.  See, what if the user does 'prog fonts:*.font'
(assuming they're using Csh5.19).  I want ReadArgs() to handle up to 300
filenames.  The RDA_BufSiz is limiting this, though.. or so it seems.
Anyway, if anyone could help out, thanks.

-- 
    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
 \/                     / taxi."  --George Bernard Shaw
Xref: sparky comp.sys.amiga.programmer:17578 comp.sys.amiga.hardware:21828
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 22:36:54 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

daveh@cbmvax.commodore.com (Dave Haynie) writes:
>>RISC - Reduced Instruction Set Computer
>>CISC - Complex Instruction Set Computer
>
>Keep in mind that the term "CISC" was coined by proponents of RISC, in order
>to make it sound like there's some sharp dividing line.  There isn't.  The
>differences are more related to the particular designs in vogue at the time any
>particular microprocessor family was created.

	Quite true.  In fact I've said in comp.arch a few times that the line
has and will continue to become blurrier, as the ability to throw transistors
at the problem increases (and as processors outrun their memories).  I.e.
RISCs are getting more and more complex instructions and execution, and
CISCs are getting close to 1 cycle per instruction and are going superscalar,
and you have things like the Hobbit (no registers at all, designed for
efficient execution of C, fast).

	Or you can just consider CISC to mean pre-85 architectures, and RISC
to mean post-85 architectures (yes, I know, vast simplification with 
a number of exceptions, but mostly true).  Or you can think of RISC as merely
a pseudonym for designing your architecture to meet the current technology
at the time, and CISC to mean making old designs fit into new technologies.
Etc, etc.  Don't get too hung up on terminology: all that really matters is
performance (and price).

-- 
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: walker@twix.unx.sas.com (Doug Walker)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS6.1 users: please read
Date: 11 Dec 92 19:10:30 GMT
Article-I.D.: unx.Bz3zxI.2A8
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <Byov0y.nJ@fc.hp.com>, koren@fc.hp.com (Steve Koren) writes:
|> It seems to me that doing an integer operation on an unsigned and a
|> signed integer should always result in a signed integer.  Anybody
|> understand why they picked the opposite?  Kinda like doing an operation
|> on an integer and a double should yield a double.  Ie, I'd think you'd
|> always promote to the most general of the types of the operands,
|> regardless of their order of appearance in the equation.

But what if the unsigned number contained a value that was bigger than
the signed number could represent?  If you converted the unsigned
number instead, you'd have an OVERFLOW instead of an UNDERFLOW and
you'd have some very large negative number involved in the operation.

ANSI chose to consider unsigned types wider than their corresponding
signed types because they can represent larger numbers.  You seem to
be considering signed types wider than unsigned types, from looking at
your example with doubles and ints, but your term is "more general".

If you consider signed wider than unsigned, you could end up with even
more confusing results.  Consider the following:

   unsigned int x = 0x7fffffff;

   if(x+1 > 0x7fffffff)
   {
      printf("Ok\n");
   }

Does the "if" condition come out true or false?  In this case, it
comes out true if the result is "unsigned int" as ANSI states, and
false if the result is "int" as you are suggesting.

-- 
  *****
=*|_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.
Xref: sparky comp.sys.amiga.programmer:17531 comp.sys.amiga.hardware:21770
From: tbills@cse.unl.edu (Trent Bills)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 18 Dec 1992 15:26:57 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
NNTP-Posting-Host: cse.unl.edu

In article <AHANSFOR.92Dec18071830@bigwpi.wpi.edu>, ahansfor@bigwpi.wpi.edu (Andrew L. Hansford) writes:
|> >>>>> 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?
|> 

No.  He is not joking.  Have you ever written a compiler?  Compiler
problems such as register allocation are MUCH more difficult that
avoiding data hazzards and filling delay slots.

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

In many cases, RISC instructions are smaller than CISC instructions.
Consider an add instruction in a CISC chip.  The source operands could
both be some place in memory.  Depending on the addressing mode used,
both source operands could take up 4 bytes or more each.  RISC
instructions are usually a fixed size (32 or 64 bits) which is obviously
smaller than the above CISC example.

 - Trent Bills
Xref: sparky comp.sys.amiga.programmer:17459 comp.sys.amiga.hardware:21679
From: ahansfor@bigwpi.wpi.edu (Andrew L. Hansford)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 17 Dec 92 00:07:06
Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
	<Bz8FD1.Dxt@ns1.nodak.edu> <1992Dec14.155039.7747@ugle.unit.no>
	<BzAxFw.Is6@dcs.ed.ac.uk> <BzBtx4.DLE@gpu.utcs.utoronto.ca>
NNTP-Posting-Host: bigwpi.wpi.edu
In-reply-to: engb@gpu.utcs.utoronto.ca's message of 16 Dec 92 00:41:27 GMT

>>>>> On 16 Dec 92 00:41:27 GMT, engb@gpu.utcs.utoronto.ca (Ben Eng) said:

> It may be easier to make op.sys.-software on a CISC processor.

engb> I consider that to be an incorrect statement.  The operating
engb> system is almost completely written in a language such as C or
engb> C++, just like most other applications.  If the compiler handles
engb> the translation well, where is the difficulty in generating code
engb> for RISC processors?  I don't remember seeing volumes of
engb> articles, or hearing many complaints from RISC OS implementors
engb> about how difficult it is to generate code for RISC as opposed
engb> to CISC.

I a paper titled "The Interaction of Architecture and Operating System
Design" (Anderson,Levy,Bershad,Lazowska, Dept. of Computer Science and
Engineering, University of Washington,) the authors discuss how
current trends in OS and CPU designs are working in opposite
directions.

OS performance has not had the speedup of most applications. (The OS
is not a typical application.)  Some of the issues mentioned: 

1) Code that was formerly in microcode now must be written in software.
   Fine is done correctly, but sub-optimal code will probably exist.

2) Code size of basic system functions.

3) Time to do a context switch (very hairy on a processor with
register windows).

4) Interrupt handling - Many RISC machines do not have specific
exceptions (ie tell you what instruction caused an exception or tell
what the address that caused a page fault ).  And many do not have
vector tables.  This can also effect how user applications trap into
the kernel.

5) saving and restoring state on a page fault - Restarting an
instruction and restoring the pipeline to its previous state (or near
to it) can be very time consuming. (Of course pipelined CISC has the
same problem)

All in all OS still run more quickly on the RISC machines, but some of
the "keep it simple" philosophy has made programming the chip more
difficult in areas that require assembly language.

-- Andrew Hansford
   ahansfor@wpi.wpi.edu
From: fheitkamp@desire.wright.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Should I do the 6.1 patch?
Date: 20 Dec 92 10:12:29 EST
Organization:  Wright State University 

I have SAS/C 6.0 and the file for the 6.1 patch.  I have been "afraid"
to apply it because I heard here on the net the patch introduced some
floating point bugs.  Since I do mostly floating point related stuff, 
I won't apply the patch until I get clarification.

What advantages/disadvantages are their to the SAS/C 6.1?

Please E-Mail or Post.  Thank you!

Fred Heitkamp,  ** Not an organization **

Newsgroups: comp.sys.amiga.programmer
From: fletcher@cs.UAlberta.CA (Cocquyt Fletcher B)
Subject: gadtoolsbox
Keywords: gadtoolsbox library
Organization: University of Alberta, Edmonton, Canada
Date: Mon, 21 Dec 1992 03:55:09 GMT

How do I compile the C source generated by gadtoolsbox with
lattice 5.10b?

I suspect I'm not linking with the correct libraries since I 
get a bunch of undefined symbol errors at link time.

Also I'd like to be able to open other windows with a gadget
event...any source code for this would be appreciated!
Is there a way of doing this right in gadtoolsbox?
 
-Fletch

Newsgroups: comp.sys.amiga.programmer
From: cmh@lysator.liu.se (Magnus Holmgren)
Subject: Re: WShell: Hangning forbid!
Organization: Lysator Academic Computer Society, Linkoping University, Sweden
Date: Sun, 13 Dec 1992 22:36:25 GMT

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

>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?)

In a sense, WShell is paranoid, but I find these kinds of messages useful.
However, if you code assembler, there is a way around this. Instead of
just exit your program with an rts, make a jmp _LVOPermit(a6). This way,
WShell will not complain, and the rts that exits your program is in the
Kickstart, so even if the child would unload some code, there is no
problem.
-- 
 Magnus Holmgren | Email: cmh@lysator.liu.se, cmh@augs.se | FIDO: 2:204/404.6
Comp. Science & Engineering student, Linkoping Institute of Technology, Sweden
From: hjalmar@cbmswe.se.so.commodore.com (Peter Hjalmarsson Sweden)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hardware/Amiga 1200.
Date: 14 Dec 92 09:59:35 GMT
Reply-To: hjalmar@cbmswe.se.so.commodore.com (Peter Hjalmarsson Sweden)
Organization: Commodore Sweden

In article <3335@cbmehq.esco.so.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>	Maybe some group needs to bring the Killer Demo contest back from
>the grave for AGA...  BTW, many of the old killer demo contest winners are
>installed on the machines in our front lobby (that do nothing but run anims/
>demos for people waiting to look at).  We don't install take-over demos
>on them.

Here in Sweden we have just had a demo competition. We received almost
only "euro-style" demos, but with a twist: As a rule we stated that all
demos had to give back all resources, be stoppable by the right menu
button (can you say button B on the CDTV remote), be harddisk installable,
and more.

So although much of the effects in "euro-demos" might be impossible to
do without "taking over", there seems to be no problem to make demos
that at least runs under the OS well enough. All it takes is some
incentive, like the A3000 that was first prize...

A world-wide compo like that, but for AGA instead might be a good idea...


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


-- 
============================================================\\======
Peter Hjalmarsson     \  hjalmar@cbmswe.se.so.commodore.com  \\  _
Amiga Support Engineer >-----------------------------------   \\//
Commodore Sweden      /  ...speaking for myself, not Commodore \/
Newsgroups: comp.sys.amiga.programmer
From: ron@vicorp.com (Ron Peterson)
Subject: What difference 68881 vs Motorola FFP routines?
Organization: V. I. Corporation, Northampton, Massachusetts
Date: Fri, 11 Dec 1992 21:00:30 GMT


Please, does anyone have an idea of how fast math operations can be done with a
68881 as compared to the Motorola fast floating point routines?  I'm
only seeing about a 20% speed increase which hardly makes it worthwhile
to buy a co-processor unless precision is necessary.  Please reply via email.
ron@vicorp.com or uunet!vicorp!ron
Newsgroups: comp.sys.amiga.programmer
From: stigo@ifi.uio.no (Stig Arne Olsen)
Subject: Re: 1200 Compatibility!
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Sat, 12 Dec 1992 13:42:21 GMT
Originator: stigo@yrsa.ifi.uio.no


In article <heinz.05da@edohwg.adsp.sub.org>, heinz@edohwg.adsp.sub.org (Heinz Wrobel) writes:
> In article <BywBA9.9KA@compsci.liverpool.ac.uk> scst72@csc.liv.ac.uk (Mr. P. Lewin) writes:
> >    The only system routine I use is to get the copper list address back at the end of my code. All of my code turns redefines all interupt channels, exceptions etc. So basically you just got the processor, hardware and some memory.
> 
> Which one?
> 
> >    My code is 100% compatible on all machines although I've never tried a 4000 (YET!!!).
> 
> What if the A1300/A5000/bla doesn't have copper?
> 

Then everyone will buy IBM-Clones instead. Simple as that.

Nice to hear it's working P.L, can't wait to try out my own routines.

> --
> Heinz Wrobel, Edotronik GmbH (ECG018)
> FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
> Path: cbmehq!cbmger!edohwg!heinz@cbmvax.commodore.com
> "It's good to have a mouse, it's faster if you can do without one..."
> "He who doesn't develop with an A2024 doesn't know about font independent
>  user interfaces..."

-- 
|    Stig A. Olsen  |  stigo@ifi.uio.no  |  "Ja til EF"       |   
| Never hit a man with glasses.  Hit him with a baseball bat. |

Xref: sparky comp.sys.amiga.programmer:17368 comp.sys.amiga.hardware:21528
From: podesta@qut.edu.au (Department of Computing Science, QUT)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re:  Attn Commodore: You are making a Big Mistake (Hardware
Date: 15 Dec 92 17:08:40 EST
Organization: Queensland University of Technology

In article <heinz.057r@edohwg.adsp.sub.org>, heinz@edohwg.adsp.sub.org (Heinz Wrobel) writes:
> have to make sure that you  don't mess up _your_own_ program? For me, it
> would take longer to write a non-OS SW, because:
> 
>     a) No ENFORCER, MUNGWALL in the background

Correct me if I'm wrong - (a redundant statement, of course) - but the 1200
doesn't have MMU so you can't run either of these. Does this mean you need
an A4000 to develop games for the AGA??

Does anybody know what the lowest end MMU AGA Amiga will be and when??
I imagine there'd have to be at least some sort of lowend GVP accelerator
board out there for the 1200, but it's much nicer to have the right
CPU in the first place.

James
Newsgroups: comp.sys.amiga.programmer
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: Re: wierd sas/c bug
Organization: Vallen Software
Date: Sat, 19 Dec 1992 21:56:48 GMT

In article <BzIw0y.n31@ccu.umanitoba.ca>, umfehr06@ccu.umanitoba.ca (John Fehr) says most sayishly:
>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

It's not a bug.  Do you know C very well?  Tell me how you expect
master_file to hold an entire string, when it's only a single character.
Try this:

char master_file[] = "obj/master";

-- 
    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
 \/                     / taxi."  --George Bernard Shaw
From: jaker@csugrad.cs.vt.edu (Jake Rose)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Sorry, can't learn from includes alone
Date: 16 Dec 92 20:36:22 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

shulick@navajo.ucs.indiana.edu (Sam Hulick) writes:

>To those of you who said it's possible to learn 2.0 programming on the
>includes... sorry.  Look at this:

>struct NewGadget
>    {
>    WORD ng_LeftEdge, ng_TopEdge;   /*  gadget position */
>    WORD ng_Width, ng_Height;    /*  gadget size */
>    UBYTE *ng_GadgetText;     /*  gadget label */
>    struct TextAttr *ng_TextAttr;   /*  desired font for gadget label */
>    UWORD ng_GadgetID;        /*  gadget ID */
>    ULONG ng_Flags;        /*  see below */
>    APTR ng_VisualInfo;       /*  Set to retval of GetVisualInfo() */
>    APTR ng_UserData;         /*  gadget UserData */
>    };

>What's ng_GadgetID supposed to do?  What should I set it to?  What's the
>ng_UserData?  The includes do NOT explain these.  Isn't there some book
>available that does?  For instance, Sybex put out an EXCELLENT book
>called "Amiga Programmer's Handbook" which totally explains the Amiga C
>functions (OS 1.3).. it explains what you should set certain things to,
>etc. etc.  Is there some kind of book like this for OS 2.0?  I want to
>make gadgets, but I have no clue without any good books.

The GadgetID is whatever you want it to be, as is the ng_UserData field.
These are there so you can label your own Gadgets with whatever number you
like and so you can attach other information to the gadget easily.  That's
why they're not explained, I suppose.  You can learn to program the Amiga
from the libraries book, the includes, and other peoples' source code.

>    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
>   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
>\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
> \/                     / taxi."  --George Bernard Shaw
-- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jake Rose               :: Amazing but true: There is so much sand in Northern
jaker@csugrad.cs.vt.edu :: Africa that if spread out it would cover the Sahara. 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: New hardware reference guide?
Date: 11 Dec 92 20:01:13 PST
Organization: BBS

> Do you really think that a software company will sell a game which
> is slower on a 1200 than on a 600 just because of the lack of doc?
 
This assumes that hardware banging is faster than using the OS by
more than four to one.  What a joke.
 
The performance bottleneck in most games and demos is not the time
spent accessing the hardware, it's the bandwidth of the hardware
itself.  With AGA machines doing blits in one quarter or one seventh
the previous time, and doing CPU stuff at least four times as fast
also, NO CONCEIVABLE amount of OS overhead can put you even close to
back where you started.
 
Another thing.  Judging by the demos I've seen, most of the neat
things done in demos DO NOT push the hardware anywhere near its
performance limits.  Only brief sections of any given demo really
make either the blitter or the CPU breathe hard, typically.  And
these are often the most BORING parts!  /<-k0oL filled vektorz eh!
From: cs_e445@ceres (Vlod Kalicun)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: App(Icon|Window) and Style Guide.
Date: 18 Dec 1992 15:08:41 GMT
Organization: Kingston University
NNTP-Posting-Host: ceres.kingston.ac.uk
X-Newsreader: Tin 1.1 PL4

jaker@csugrad.cs.vt.edu (Jake Rose) writes:
: 
: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

Definetely! but methinks you've been using MACs a bit too much, and neglecting
your Ami ;-)

Regards..

Vlod
-Amiga Advocate.
----------------------------------------------
Amiga - Anything else isn't worth considering
----------------------------------------------