HDTenEightyP/NetNews huggingface dataset:
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: OS 3.0 Manuals
Date: 28 Dec 92 20:42:20 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

tope@enea.se (Tommy Petersson) writes:
>jesup@cbmvax.commodore.com (Randell Jesup) writes:
>: 	Manuals are always later than the hardware/software, since often
>: details aren't firm until release.  Note that the 2.0 manuals came out shortly
>: after 2.04 (if I remember correctly).  This also gives us time to make sure
>: bugs and workarounds are documented in the manuals.  BTW, even if we were to
>: do a hardware manual it probably wouldn't be available for quite a few months.

>The only way to get good, actual manuals out shortly after program
>release would be to relese them on CD (or floppys) in AmigaGuide format.
>If this format is used during development, small corrections can be made when
>the bugs are found, and the CD's/floppies then made.

	There is a CATS developer CD (I don't think it has the text to the
manuals though).  The biggest problem is not the publishing, however: it's
actually writing them.

-- 
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: dac@prolix.apana.org.au (Andrew Clayton)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Stupid C question
Date: Mon, 28 Dec 1992 06:27:20 GMT
Distribution: world
Organization: More like Dis~, really.
X-Newsreader: Arn V1.00

In article <ad99s461.037k@sycom.mi.org>, Alex Deburie writes:

> Okay, I've had SAS-C 6.0 for about 2 weeks and I'm very pleased. Between GST's 
> and the Workbench interface, I doubt I could ask for a better introduction to 
> C on the Amiga.
> 
> However, I have one very stupid (simple?) question. HOW DOES ONE COVERT A 
> FLOATING POINT VALUE TO AN INTEGER???!!!  I see functions like modf(), but 
> still that returns the integral part of the number as a float. And casting 
> seems to always return a 0!

/* My test */

#include <stdio.h>

void
main(void)
{
    int fred;
    double joe;
    const int square = 4;

    joe = (double)square;
    fred = (int)joe * square;
    printf("Fred %d Joe %f Square %d\n", fred, joe, square);

}

I ran this through the compiler, 

SAS/C Amiga Compiler 6.00                                         
Copyright (c) 1988-1992 SAS Institute Inc.                        
Slink - Version 6.00                                              
Copyright (c) 1992 SAS Institute, Inc.  All Rights Reserved.      
                                                                  
                                                                  
SLINK Complete - Maximum code size = 9032 ($00002348) bytes       
                                                                  
Final output file size = 10888 ($00002a88) bytes


and running this program produced:

Fred 16 Joe 4.000000 Square 4

Note that you must link with the MATH library in order for
floating point operations to work.

Dac
--
dac@prolix.apana.org.au              David Andrew Clayton.           // _| _  _
dac@prolix.sserve.cc.adfa.oz.au      Canberra, Australia           \X/ (_](_](_
                    <Using ARN on an Amiga 4000. Yay!>
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: 25 Dec 92 17:11:04 GMT
Organization: BBS

> So why doesn't the Amiga have an OS friendly method of copy
> protection?
 
I thought that was a contradiction in terms
 
> Give every Amiga a unique serial number implemented in hardware.
> Just like every workstation has a unique hostid.
 
That was tried with the Apple Lisa.  For some reason Apple dropped
the idea.  I wonder why?
 
> That would allow software vendors to provide software that is tied
> to that hostid or multiple hostids.
 
In a cheap game sold off of retail shelves?  How does one implement
this scheme without requiring that each customer get a physically
different disk instead of a single mass-produced shrink-wrapped
product?
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Is utility.library/Stricmp() broken?
Date: 28 Dec 92 20:34:14 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

john@pluto.Jpl.Nasa.Gov writes:
>Is the AmigaDOS 2.04 utility.library/Stricmp() broken?

	Not that I know of...

>I am using Aztec C 5.2a on a 2000HD with DOS 2.04.

>  qsort_comparison( void * s1, void * s2 )
>  {
>    return (int) Stricmp( *(char**)s1, *(char**)s2 );
>  }

	Are you certain that those void *'s are char **'s?  Did you try it
with strcmp in the same place?  Are you including clib/utility_protos.h?
Are you certain that your qsort wants <0, 0, or >0 for a return, and not
-1, 0, and 1?

-- 
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: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Newbie font/screen question
Date: 24 Dec 92 08:52:23 PST
Organization: BBS

> Occasionally you may still want to do an OpenFont first; this
> allows you to use your own judgement about what constitutes an
> acceptable match.  For many purposes, however, this is now
> unnecessary.
 
Yes, I have to do this in most projects, both for 1.x and for
rejecting unusable fonts such as in cases where I need fixed-width
fonts only.
 
Note, everyone: if you don't want a hideous scaled bitmap, be sure to
specify FPF_DESIGNED in the TextAttr's flags field.
From: cmcmanis@pepper.Eng.Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HELP!!!!
Date: 31 Dec 1992 08:27:12 GMT
Organization: Sun
Distribution: global
NNTP-Posting-Host: pepper
Keywords: Lattice C

In article <BzwyMw.2s0@ccu.umanitoba.ca> umbadiu0@ccu.umanitoba.ca (Ted Babiuk) writes:
>HOW DO I PASS THE VIEWPORT ADDRESS TO THE NEWLY CREATED TASK???????

Have your newly created task open a message port, and wait for the parent
to send it the viewport address. Something like this works for my uemacs
hack :
	parent:
		CreatePort("mainport",...);
		CreateChildProcess(...);
		Now as soon as its ready, it will signal us on our
		port...
		Wait(mainport);
		Findport("ChildsPort");
		PutMsg(ChildsPort, "Heres my viewport address");
		...
Simple rendesvous protocol. Note you'll have to fill in the appropriate
message structures etc.

--
--Chuck McManis			    Mr. NIS+			    Sunsoft
uucp: {anywhere}!sun!cmcmanis   BIX: <none>   Internet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
Newsgroups: comp.sys.amiga.programmer
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 30 Dec 92 22:44:37 PST
Organization: BBS

> > Shifting/Masking is a no-time operation in hardware.
 
It approaches no-time for large enough operations, you mean.
 
> If you can make this magical piece of hardware, I'm sure Commodore
> has a job position open for you.
 
Well the regular blitter is not all that far off from being this
magical.  Shifting and masking basically has no speed cost except for
needing to access one more word when your bits stretch over a word
boundary.
 
> > Now render a 64 color image to your 256 color display :)
 
> The best you can hope for is a tie, since with planar you have to
> clear the top two bitplanes anyways.
 
Huh???  Eh?  Duh?
 
All you have to do is tell it to use only six planes now.
 
Sounds like you're getting a little too wrapped up in this.  Time to
take some deep breaths and reoxygenate those crucial tissues.
 
> And some chunky hardware supports color expansion, too, where you
> take a single-bit image and can expand all 0's to one color and 1's
> to another.  Of course, a similar thing could be done for planar,
> but you still have the masking/shifting/bandwidth on unaffected
> pixels problems.
 
You're talking about a case where you are implementing a planar
display in your "chunky" system.  Where's the difference?
Newsgroups: comp.sys.amiga.programmer
From: henning@mari.acc-admin.stolaf.edu (Mark Henning)
Subject: Directly calling AREXX Function Hosts (HELP)
Summary: request for information regarding how to do.
Keywords: AREXX FunctionHost
Organization: St. Olaf College; Northfield, MN
Date: Mon, 28 Dec 1992 22:08:41 GMT

Due to tight timing considerations, I need to be able to call some 
specific function host routines from C.  Since the calls are passed in
"packets similar to commands" I assume this is possible, however, I
have been unable to find documentation explaining how to do this.  

Specifically, I need to control the NewTek Video Toaster switcher,
which is implemented as a function host.  Thus I am currently using
their command host adapter arexx script, but this really has a
potential of messing up my timing (two extra context switches and
AREXX string processing which is pokey at best). 

I really appreciate any help, whether it is a direct answer or a
recommendation of where to look for more information.

thanx,

					-henning
henning@stolaf.edu
From: tim@corcoran.rain.com (tim corcoran)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HiSoft BASIC & WB2.04
Distribution: world
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
Date: 21 Dec 92 22:29:48 PST
Organization: Not an Organization

In article <pete.03kz@bignode.equinox.gen.nz> pete@bignode.equinox.gen.nz (Pete Moore) writes:
> I have quite a lot of stuff which I've written in HiSoft BASIC, and I have
> had some problems since installing WB2.04
> 

I've been using HB/2.04 for many months now and never had any problems.
I've written(and use daily) programs that make pretty extensive calls to the
iff.library (by Christian Weber) as well as to 2.0 libraries. 

Some suggestions:

1. Could it be your version of HB that's at fault? 
2. Are you using 2.0 libraries/.fd files etc. or still 1.2/1.3?
   (I do recall some problems using 1.3 libraries under 2.04)

I would love to get an update to HB however if it's still supported by anyone.
There are some stooopid bugs that p*** me off every time I encounter them, and
the editor sucks wind...


FYI: I'm using HB V1.05

Tim


-- 
[..!{uunet,qiclab,intelhf,bucket}!m2xenix!becca!corcoran!tim]

-----------------------------------------------------------------

           This isn't a job... It's an indenture!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: winikoff@cs.mu.OZ.AU (Michael David WINIKOFF)
Subject: Re: CISC and RISC
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 29 Dec 1992 05:09:01 GMT

jimomura@tndb.UUCP (Jim Omura) writes:

>In article <9235716.13776@mulga.cs.mu.OZ.AU> winikoff@cs.mu.OZ.AU (Michael David WINIKOFF) writes:
>>jimomura@tndb.UUCP (Jim Omura) writes:
>>
>>[Lots of quotes deleted]
>>

>     Well, yes, I know that.  That's why I raised the issue in *this*
>discussion where nobody else has.
Ack.

>>In shared memory machines one relies heavily on caches to reduce the demand
>>on the bus.
>>
>>Another solution to having multiple processors is to build distributes
>>memory machines.

>     Let me repeat "there are going to be times where the various
>busses are going to be the main bottleneck".  This will be true
>in spite of distributed memory and caching.  Actually, I thought
>I implied that fairly well.
>:-)

Yup, if these times don't occur that often though then you're fine.

>>Essentially what (I think) you're saying is "we shouldn't use the fastest
>>CPUs we can on a multiprocessor machines since they'll be tying up more
>>bus bandwidth then slower processors"

>     That's close.  To state it more accurately, we're reaching a
>point where certain classes of applications which push designs
>in various directions have significant representation in the market.
>Considering all the design specification factors (user needs and
>preferences, design costs, material costs and production costs),
>better performance may be achieved where overall system architectures
>are optimized towards certain applications.  And some CPUs will
>be better suited that others in this overall context.  More
>specifically, in some designs, super-scalar RISCs simply may not
>give performance as good as CISC.  Furthermore, there should be

Sure - just leave out the cache :-)

>advantages in designing CPUs with more of an eye on final applications
>and working backwards through the overall system architecture
>than there has been in the past.  This may be happening in the

Huh? Isn't this what the RISC approach is all about?
[Ref. Computer architecture: a quantitative approach. Hennesy & Patterson]

>Apple/IBM/Motorola project -- I don't know.

Whoa! That's a mouthful. You sure you ain't a lawyer/politician/marketroid? :-)

>     I might also add that I doubt that we're close to seeing the
>ultimate designs in any of these classes.

I don't think there ever will be an "ultimate" design since the technology
used to implement designs is continuously developing.

>     Incidentally, the latest word I have is that the physical signals
>in the Apple/IBM/Motorola RISC are essentially 88000 signals, so
>that might be a good reason to design the next generation Amigas
>on 88000's.

>...

>--

>Jim Omura, (416) 652-3880
>'jimomura@lsuc'
-- 

--------------------------------------------------------------------------------
Software Engineering: Quality through Deforestation.
Newsgroups: comp.sys.amiga.programmer
Subject: HiSoft BASIC & WB2.04
From: pete@bignode.equinox.gen.nz (Pete Moore)
Date: 21 Dec 92 21:31:13 +1200
Reply-To: pete@bignode.equinox.gen.nz
Organization: Equinox Networks
X-Newsreader: TIN [version 1.1 PL8]

I have quite a lot of stuff which I've written in HiSoft BASIC, and I have
had some problems since installing WB2.04

Occasionally I get recoverable alerts either on starting or on quitting an
executable created by HSB. Programs started via something else, such as
ToolManager or DiskMaster, seem to be especially prone to this problem, but
I've also had it occur with programs launched from workbench & from CLI.
The `recoverable alerts' are often not recoverable, and are followed by a
lockup when I click the mouse. Once or twice I've had a lockup without an
alert.

Less serious, but quite annoying, is that a running HiSoft program will
often change any existing non-workbench screen to workbench colours. Having
the HSB program call the dos library is almost guaranteed to cause this, but
any HSB program seems to do it occasionally. Moving the affected screen to
the back and then to the front again always restores its correct colours.

Does anyone have any idea what HiSoft is doing wrong, and can it be fixed?

I'm currently almost at the point of abondoning HiSoft in favour of Blitz,
but if possible I'd like a fix for the stuff I've already written.

I'm running an A500+ with 5.5Meg (1.5 chip, 2 32-bit, 2 16-bit) and a
25MHz VXL 68EC030 - I don't think any of this matters, because I've seen
HSB cause similar problems on other WB2.04 machines.

advTHANKSance.
--
 +-------------------  pete@bignode.equinox.gen.nz  -------------------+
 | The effort to understand the universe is one of the very few things |
 | that lifts human life above the level of farce, and gives it some   |  
 | of the grace of tragedy   -  Steven Weinberg                        |
 +---------------------------------------------------------------------+
From: Jesse_Michael@matrix.rain.com (Jesse Michael)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: 27 Dec 92 11:40:34 GMT
Article-I.D.: matrix.Jesse_Michael.02sl
Distribution: world
Organization: The Matrix BBS

In a message dated Sat 26 Dec 92 14:03, Mlelstv@specklec.mpifr-Bonn.mpg.de 
wrote:

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

It appears that our definitions of "absolute addressing" are a bit
different...

What I mean is things like--

"The first example sets up a 320 x 200 playfield with one bitplane, which
is located at $21000.  Also, a Copper list is set up at $20000."

And then hardcoding everything off of that.

This is _not_ a good programming practice.

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

How do you know that his demos aren't in that 1%?

You can't unless you've tested them or heard from someone else that they
weren't.

>Fortunately most demos can't harm my data as they will fail rather soon
>when trying to patch the interrupt vectors in lower memory :)

There were recently several people asking about how to handle a VBR over in
FidoNet.  There should be more demos that'll work more often pretty soon...

-Jesse

-- Via DLG Pro v0.995

--
Haze of Epsilon / Check out Epsilon for the best in NTSC demos!  Ok, so if
you compare us to groups like Anarchy and Silents then we're lame, but what
the hell do you expect from us lazy Americans?!?  :^)
From: ad99s461@sycom.mi.org (Alex Deburie)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Stupid C Question - thanks
Distribution: world
X-BBS-Software: EXCELSIOR! V0.975
Date: 29 Dec 92 01:00:17 EST
Organization: Michigan Information eXchange

 
Thanks for everyone's help with my C problem. Seems that casting is
unary and a misplaced parentheses can make all the difference in the
world. ;^)
 
However, it still seems wierd that there is no internal SAS function to
do float to integer conversion, especially since I've found functions
to do this right in the Amiga math libraries.

Thanks again, and Happee New Year!

     -- Alex Deburie
        ad99s461@sycom.mi.org
Newsgroups: comp.sys.amiga.programmer
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Organization: Jet Propulsion Laboratory
Date: Thu, 31 Dec 1992 03:16:35 GMT

In article <1992Dec30.143415.10947@samba.oit.unc.edu> Todd_Lewis@unc.edu (Todd M. Lewis) writes:
>In article <72553@cup.portal.com> Tony-Preston@cup.portal.com (ANTHONY FRANCIS  
>PRESTON) writes:
>>So give us an "Official" way to walk the device list that is compatible
>>with 1.3 thru 3.0 that will kick out the "strange" things and keep only
>>the valid devices (like DF0:, any DH0:, ect...).  One of the reasons
>>I checked for specific device names(like Pipe:) was because of the 
>>"strange" things....  
>
>Guess I'd better not run your software on my system with a
>hard-disk partition named "Pipe:" or "VD0:" huh?
>--
> _/_/_/  _/     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.

Wouldn't it be sufficient to check the dl_DiskType field of the dos list
structure in order to distinguish between a volume (DLT_VOLUME) and device
(DLT_DEVICE)? 

Jeff


Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 26 Dec 1992 17:05:03 GMT

In <72410@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes:
>I don't know about him, but I'd like chunky pixel mode so I can
>do image processing (part of my job) on my Amiga.  Image processing
>is much easier when you can treat pixels as just big arrays of numbers.

You can do the same with any graphics hardware. AmigaOS already supports
rendering 'big arrays of numbers' with the WritePixelArray8 function.

If you want to poke pixel numbers directly to the screen buffer...well,
that has nothing to do with image processing.

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: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Going to the metal
Date: Sun, 03 Jan 93 01:52:09 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:

> In <RwqqwB5w165w@lakes.trenton.sc.us> rock@lakes.trenton.sc.us (Rockerboy) wr
> >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.

Agreed, but that is not unacceptable.  Many utilities require certain 
libraries, such as reqtools, etc.  Certainly, a software solution would 
be better than hardware, and would be a compromise that would satisfy 
almost everyone.
From: paul@dragons.DIALix.oz.au (Paul O'Neill)
Subject: Re: GCC wont create executable
Newsgroups: comp.sys.amiga.programmer
Distribution: world
X-Newsreader: TIN [version 1.1 PL8]
Date: 28 Dec 92 07:30:39 WST-8
Organization: Private UUCP node

Michael B. Smith (mbs@adastra.cvl.va.us) wrote:
> In article <paul.043m@dragons.DIALix.oz.au> paul@dragons.DIALix.oz.au (Paul O'Neill) writes:
> > 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.
> >
> > Any suggestions anyone?

> How much contiguous memory have you got when you start the g++ compile? Just
> to hazard a guess, you need between 2-3 MB for a "hello world", without any
> include files at all.

2 TO 3 MEGS JUST FOR "HELLO WORLD" - YOU MUST BE !@#@$%@ JOKING.

Why so much (as you can tell I don't have that much - recently loaed my 8MB RAM card
for a 2MB RAM card and a 40MB hard disk >SIGH<) ?

Oh, well. I'll have to see about upgrading my GVP controller to one with SIMM sockets
and plug some more memory in.

Regards (and thanks)
Paul

--

Paul O'Neill                          paul@dragons.DIALix.oz.au     _--_|\
				       (ALT: paul@DIALix.oz.au)    /      \
Secretary				 Phone: (+619) 250 7080    X_.--._/
Amiga Developers Association of Western Australia			 v

Newsgroups: comp.sys.amiga.programmer
From: robart@agora.rain.com (Joe Bob)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: a gora
Distribution: world 
Date: Fri, 25 Dec 1992 17:23:22 GMT

In article <1992Dec21.102751.9671@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>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.

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



Newsgroups: comp.sys.amiga.programmer