HDTenEightyP/NetNews huggingface dataset:
From: paul@dragons.DIALix.oz.au (Paul O'Neill)
Subject: GCC wont create executable
Newsgroups: comp.sys.amiga.programmer
X-Newsreader: TIN [version 1.1 PL8]
Date: 26 Dec 92 09:13:06 WST-8
Organization: Private UUCP node

As you can see I'm trying to write a program (well, "hello, world" anyway) using GCC.

I can get it to compile now (thanks John V.) but still nothing to run.

Can anyone help?

Here is an excerpt from my shell window last time I compiled it:

R(0);9:05AM> gcc hello.cc -lg++ -v
Reading specs from gcc:compilers/amiga/2.2.2/specs
gcc version 2.2.2
 gcc:compilers/amiga/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2
-D__cplusplus -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__
-D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga
-D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 hello.cc t:cc599160.i
GNU CPP version 2.2.2 (68k, MIT syntax)
 gcc:compilers/amiga/2.2.2/cc1plus t:cc599160.i -quiet -dumpbase hello.cc -version -o
t:cc599160.s
R(1);9:05AM> _

As you can see it ran 'cpp' and 'cc1plus' but then stopped with return code 1.

What does this mean?

From the second last line I assume -o t:cc599160.s is the output file, but there's
nothing like it in t:.

Any suggestions anyone?

Paul

Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 29 Dec 1992 01:08:53 GMT

In <doiron.0k4a@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
> 32-point line,
> 2 pixels thick:  512 reads 512 writes       64 writes
> (Why are bitplanes better for this?  Seems like an additional 960 memory
>  accesses to me.)

It would be still 256 reads 256 writes unless the line spans over a word
boundary. More, shallow lines will need less reads and writes.

However, your line drawing routine will need cycles itself. So unless
your rendering is done in hardware the difference gets smaller.

> 32x32 blit:      1536 reads 512 writes      1024 reads, up to 1024 writes
>         or up to 2304 reads 768 writes
> (second case if either source or dest. non-aligned)
> (including transparency/masking)

32x32 blit is 512 reads/writes. more for non-aligned objects. chunky
needs 512 reads/writes and a little more for non-aligned objects.
(Both do word accesses).

> Scaling: 32x32 image, blow up to 64x64
>  convert to chunky: 8192 reads              no-op
>  do mathematical xforms                     do mathematical xforms
>  convert to bitplane: 32768 reads           no-op

That's easy. 'blow up' is a table lookup which can be done on each bitplane
independently. No need to convert from and to chunky. If you use a selected
colormap then you get filtering/dithering of the image for free.
BTW, that's the same speed for chunky/bitplanes.

>OK, now tell me which one will be slower?  I'm not even factoring in the
>ridiculous amount of bit-shifting and masking involved in all these
>operations for AGA (excluding the 32x32 blit... blitter was assumed).

Chunky wins slightly in most operations IF you use a 256 color image.
It looses with a depth != 8. BTW, 32x32 blit is tiny, what about 50x50
or 156x200 ? And since we were talking about 'image processing'. Most tools
have some sort of GUI which eats some of the 256 colors. The easiest
way is to go down to 128 colors. Bitplanes will then be faster for 12.5%.

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."
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Access to BIX developer sections or Developer's Mailing lis
Originator: walker@twix.unx.sas.com
Date: Wed, 23 Dec 1992 15:36:18 GMT
Organization: SAS Institute Inc.


In article <1h7ttlINNai8@klee.uni-paderborn.de>, laire@klee.uni-paderborn.de (Ralph Schmidt) writes:
|> The NON-US developer use ADSP, an UUCP network. Almost every land
|> in europe+australia with a CBM-department has a node the local
|> developers can call to get the ADSP groups and the Internet news
|> groups. Furthermore you can also download software.

ADSP-capable developers should also note the new group adsp.sas, 
for SAS/C support.

|> Ralph Schmidt                                            laire@uni-paderborn.de
|> University of Paderborn (Germany)

-- 
  *****
=*|_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: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 24 Dec 92 09:13:47 PST
Organization: BBS

> Four letter ASCII????  Ack!  Randell didn't mention this as a valid
> possibility in his original reply.  Can anyone give me some
> examples of devices which use this?
 
I think one has to assume that ANY bit pattern is possible there.
One just has to test as best one can for a valid FSSM, and ignore if it's
anything else, I guess.
From: Douglas_Stockman@graceUUCP (Douglas Stockman)
Newsgroups: comp.sys.amiga.programmer
Subject: gadtools.library stringgad help
Distribution: world
Date: 30 Dec 92 10:49:13 EST
Organization: Graceful Boot BBS (send replies to User_Name%grace@moscom.com)

Greetings,
     I need some enlightenment regarding the use of gadtools.library string
gadgets.  I have a string gadget that text/numbers are entered into.  This
string gadget is part of a spreadsheet-like data entry window.  I want the
user to be able to strike a keyboard key that signals my program to
activate the string gadget, place the entered character into the string
gadget, and move the active cursor in the string gadget to the position
after the first character entered.  So far I can activate the string gadget
and place the pressed character into the string gadget when the user
presses a desired key.  The trouble is the active string gadget cursor
remains on the first character entered.  If the user continues to enter
text, the new text is inserted before the first character entered placing
the first character entered at the end of the entered text (e.g. elpH,
instead of: Help).  I noticed in RKM:Libraries that NON gadtools.library
string gadgets allow a BufferPos variable to be set which controls where
the cursor appears.  Is there a legal way to do the same thing using a
gadtools.library string gadget????  All help is greatly appreciated.


-- Via DLG Pro v0.992
From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
Newsgroups: comp.sys.amiga.programmer
Subject: Grabbing all 8 sprites under the system?
Distribution: world
Date: 26 Dec 92 22:40:22 CST
Organization: The Amiga GateWay BBS * New Orleans, La.

In my continual quest to make my current project as system-friendly as
possible (hey, the game only eats up around 35-30 raster lines worth of
time, it's not like i need lots of the machine's power), i come to the
following question:
Is it possible to get use of all eight sprites without direct hardware
usage?
You see, right now i'm jamming in my own copper list, and using all 8
sprites in joined mode, so i get 4 16-color objects. What i want to do is
let people use amiga-M to flip my game to the back. I suppose i _could_ do
some trickery with a "fake" screen, like Protracker, but i'd rather do it
in a way the system knows about...
Oh, and i need it to work under 1.3 and up. I still haven't switched.
Neither have many game-oriented Amiga users.

And anyone who plans to flame me for going direct to the hardware: I FOLLOW
ALL THE GUIDELINES LAID DOWN IN THE MANUALS under the sections on "If you
must go to the hardware, do this, don't do this...". And i don't busy-wait
or do anything else nasty like that. My code may be hardware code, but it's
GOOD hardware code. (Why am i getting defensive? Well, i'd written a
message on this same project a while back, and the only response i got was
a "Hardware banging scum!" flame.)

-- Via DLG Pro v0.995

- be zorch, daddi-o --------------- paul (raccoon) trauth ----------------
--------------------------------------------------------------------------
Internet -> paul_trauth@agwbbs.new-orleans.LA.US        \\\///\\\///\\\
Usenet   -> rex!agwbbs!paul_trauth                      \\\///\\\///\\\
--------------------------------------------------------------------------
  "eagles may fly, but a weasel will never get sucked into a jet engine"
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Going to the metal
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 2 Jan 1993 13:02:21 GMT

In <RwqqwB5w165w@lakes.trenton.sc.us> rock@lakes.trenton.sc.us (Rockerboy) writes:
>would be whther or not people were using the 'official' library.  It 
>would be patently obvious why programs crashed if the user were running 
>the 'elite7hardware.library'.  ;)

With a 95% chance a game will require exactly a specific version of that
library.

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)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Should I do the 6.1 patch?
Date: 21 Dec 92 14:52:18 GMT
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <1992Dec20.101229.6301@desire.wright.edu>, fheitkamp@desire.wright.edu writes:
|> 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.

If you have to use the MATH=68881 option, stick with 6.0.  If you
can get along without it for a while, 6.1 does fix some problems
that you probably want fixed.  There is a complete list of what
is fixed in the archive itself.

|> Fred Heitkamp,  ** Not an organization **

-- 
  *****
=*|_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
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 2 Jan 93 10:46:11 PST
 <1992Dec31.011428.2926@mpifr-bonn.mpg.de> <doiron.0kd5@starpt.UUCP> <1993Jan1.141207.20262@mpifr-bonn.mpg.de>
Organization: TAP

Quoted from <1993Jan1.141207.20262@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):

> And as I also pointed out, bitmap scaling (that's what you thought of)
> is about same speed for chunky and bitplanes.

    You seem to have some magnificent algorithms up your sleeve.
    Perhaps we could get this thread onto more .programmer things if
    you outlined some of these algorithms?

> YOU may do it that way. I simply use a table that maps several pixels
> to their scaled counterparts.

    So to expand 4x, you have a 256x4 table mapping source bytes onto
    destination longs? Makes sense!

> Most time consuming graphics operations consist of modifying larger areas,
> drawing diagonal lines or lots of number crunching to generate an image.

    ...

> In the second case you have a major advantage for chunky pixels. But
> the fact that lines cover less memory than filled areas and some
> optimizations possible with non-vertical lines make this advantage less
> important.

    It is not less important. You have to do the drawing portion of
    the line 8 times, which taxes ones ability to hold all the
    required values in registers.

> In the third case the rendering speed isn't important as the calculations
> outweigh any efficiency differences.

    FractInt would be easier to port and run faster if it was using
    chunky pixels.

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Mon, 21 Dec 1992 10:27:51 GMT

In <Jesse_Michael.02qs@matrix.rain.com> Jesse_Michael@matrix.rain.com (Jesse Michael) writes:
>In case you didn't notice, in the Hardware Reference Manuals the C=
>released before  *the examples used absolute addressing*.

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.

>Just about the *only* thing that C= said not to do was to use CLR to the
>custom chips.

Not sure about the 1.3 manual, but read the 2.0 hardware manual page 9ff.

>If they would have released a *proper* reference manual, then we wouldn't
>have as much of a problem.

No. Most problems arise from the fact that people did _learn_ programming
from the hardware manual which is out of scope of the book. It is a
reference manual, nothing else.

>Don't assume that his demos won't work unless you've tried them or heard
>otherwise.

99% of all demos do not run on my machine unless I take some precautions
(like disabling the harddrive, turn off CPU caches, degrader). It is nearly
impossible to even start a demo from a running system not speaking of returning
safely to an OS environment.
Fortunately most demos can't harm my data as they will fail rather soon
when trying to patch the interrupt vectors in lower memory :)

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: charbonn@castor.crd.ge.com (Michael R Charbonneau)
Newsgroups: comp.sys.amiga.programmer
Subject: using gadtoolsbox 1.4 with SAS/C
Date: 27 Dec 92 04:12:21 GMT
Organization: GE Corp. Research & Development, Schenectady, NY


hi,


I am trying to use GTB1.4 with SAS/C 5.1b and I am not having much
luck. I haven't done a lot of programming on the Amiga, but let me describe
the problem.

using GTB I create a simple window with just a single cycle gadget
(something small and easy to start out with).

Then I use SASCsetup to turn the GTB C program's into icons,
and then I hit build (to do the compilation) - and I get a bunch of
linker errors back:

Undefined Symbol
-----------------
GT_RefreshWindow

UnlockPubScreen

etc.

I made sure to set the include assign to lc/include_2.0


any ideas on what the problem is?

does GTB work with SAS 5.1, or am I using the wrong include
files?

Or are these internal GTB functions that I need to fiddle with?

thanks,

michael



PS. GTB1.4 is very impressive , kudo's to the programmer!
pps. (is 1.4 the latest version?)

charbonneau@crd.ge.com

| Michael R. Charbonneau               | It goes on all day long   |
| GE Corporate Research & Development  | Everyone knows everything |
| Artificial Intelligence Laboratory   | No one is ever wrong      |
| Schenectady NY 12345                 | 	until later...     |
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Fri, 1 Jan 1993 14:17:29 GMT

In <jbickers.0mdh@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
>    One thing that is becoming noticeable here is that a couple of the
>    people who are trying to say that chunky pixels are not better
>    than planes for the given operations were _also_ involved in the
>    hardware manual thread, on the side of those who don't care about
>    hitting the hardware directly. In my view, they're blowing their
>    credibility with this stuff about planes.

Maybe not. I'm surely not on the side of those who hit the hardware in
user programs. Hardware access should be limited to the driver software
which _can_ be optimized for bitplanes in the way I have discussed it.

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."
Organization: Stanford Linear Accelerator Center
Date: Friday, 25 Dec 1992 23:48:17 PST
From: LORETI, Maurizio <MLO@SLACVM.SLAC.STANFORD.EDU>
Newsgroups: comp.sys.amiga.programmer
Subject: Listviews

According to RKMs (Libraries, page 396) gadtools listview gadgets
vertical dimension is not bigger than the required one, and
with an height computed to show an integer number of lines.
Is there a way to know how many lines/pixels is actually a
listview gadget high?

          Thank you in advance - and a Merry Christmas to everyone.
                Maurizio
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Access to BIX developer sections or Developer's Mailing lis
Date: Mon, 28 Dec 92 12:44:03 PST
Organization: The Portal System (TM)
  <72132@cup.portal.com> <1992Dec22.033305.45847@kuhub.cc.ukans.edu>
  <1h7ttlINNai8@klee.uni-paderborn.de>
  <1992Dec24.155409.45896@kuhub.cc.ukans.edu>

I would love a developer only mailing list, but what do you do about
proprietary data?  Encrypt it?
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 22 Dec 1992 12:32:03 GMT

In <amipb.05b7@amipb.gna.org> amipb@amipb.gna.org (Philippe Berard) writes:
>    BTW, if RTG was the reason of the 'non-HRM' syndrome, an allowing people
>    to do what they want with the BitMap structure, I think RTG will break
>    on the graphic cards like the VIVID or the RAMBRANDT, and all the ones
>    that have external Video-Ram.

people are not allowed to 'do what they want' with BitMap structures. Only
_standard_ BitMaps are known to be exactly like current BitMaps (i.e.
accessible by blitter, up to 8 planes, etc..). RTG also allows for
non-standard bitmaps with certain attributes (like 'can be displayed'
and 'is planar').

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."
Newsgroups: comp.sys.amiga.programmer
From: shacha1@tau.ac.il (SHEMESH SHACHAR)
Subject: Two mice
Summary: A two mice game (OS legal)
Organization: Tel-Aviv University Computation Center
X-Newsreader: TIN [version 1.1 PL8]
Date: Sun, 3 Jan 1993 12:03:42 GMT

I want to write a game that will be os legal, and multi-task. I want
this game to have two pointers for two mice (one in each port). Since
this is a game it is vitelly important that there will be no
preferation to a mouse in port one over a mouse in port two, otherwise
the game is unfair. I need a way to achive that.
If someone can come up with a way that will enable me to also use
Intuition's gadgeting capabilities with both mice, it will be grand,
but this is of lower priority, as the gadgets in this game are not
very complicated and I can do them on my own.

I stress that this game should be both OS legal (don't think I'll get
anything else from the net anyway) AND multi-tasking (i.e. - leggally
telling intuition to get lost so long as the game is running will not
so the trick.

I thougt of constantly switching back and forth the mouse ports, and
map them with a high priority input-device handler, but I don't think
this will work. anyone can comment on that?

--
"Is it just me or has the world always been like that and I've been to
wraped up in myself to notice?" [Arthur Dent, THHGTTG]
Shachar Shemesh  (TheSun on IRC)
shacha1@ccsg.tau.ac.il
Xref: sparky comp.sys.amiga.programmer:17726 comp.sys.amiga.misc:18987
From: dnavas@oracle.uucp (David Navas)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: Advice to SAS/C 5.10b users
Date: 22 Dec 92 23:31:53 GMT
Organization: Oracle Corporation, Redwood Shores CA
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <BzM5Kw.CuD@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>There are no reported bugs in far code/far data as of now.
>Don't complain about bugs until you have reported them.

Err, uhh, unless 6.2 magically made its appearance without my noticing, there
is at LEAST one reported far data/utillib problem that your should have
scheduled to fix for 6.2....

>I've seen hundreds of cases where 
>using different option sets forced a bug in the user's code 
>to show up.

Hm, the only options that cause me problems are "utillib" and "optimize" ;)

Leaving those off I don't seem to run into problems at all.

Hey, and relax out there -- peace on earth, good will toward (wo)men,
'member something like that from your distant past?  ;}

David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.
Newsgroups: comp.sys.amiga.programmer
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: ASL and GadTools under 1.3 - can this work?
Organization: UNC Office of Information Technology
Date: Mon, 28 Dec 1992 14:41:52 GMT

In article <1992Dec28.032315.6457@bilver.uucp> alex@bilver.uucp (Alex Matulich)  
writes:
>I notice that if I use the pragma include files, the linker (SAS 5.10b)
>will NEVER link amiga.lib.  If I leave out the pragmas, it gets linked in.
>Upon using OML to list the contents of amiga.lib, I notice that it
>contains all Amiga functions, including the gadtools.library functions!
>
>This would imply that amiga.lib contains duplicates of the 2.0 ROM
>functions, [...]

C normally passes arguments on the stack.  The system libraries expect
arguments in registers.  The pragmas enable the compiler to put
arguments in registers for system functions.  The amiga.lib functions
you found simple take arguments off the stack and put them into the
proper registers before calling the real system functions.  They
are not duplicates of the 2.0 ROM functions.
--
 _/_/_/  _/     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