Path: utzoo!attcan!uunet!husc6!think!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: I fixed the loadrgb4() problem myself
Message-ID: <64435@sun.uucp>
Date: 16 Aug 88 19:05:35 GMT
References: <3317@crash.cts.com>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 69

In article <3317@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes:
>        If we need to accomplish something NOW and it can not be done without
>going around the system, and the Amiga Guru's who are changing that system
>won't give specific information about how it is going to work in the future
>(for which I don't blame them, I wan't them to have the freedom to revise 
>earlier decisions as they actually tackle specifics),
>        WHATS A PROGRAMMER TO DO?

Well assuming the programmer is a registered developer, they give Commodore
the low down on what they need to do and why they think they need to go 
around the system and say "Ok, this is what I need to do, and this is 
why it doesn't seem to work currently, and this is what I am considering 
doing about it. How can I do this an be supported in later releases?"

Commodore will (by definition of Technical Support) provide either a solution
or alternative suggestions that will accomplish what you want to do and 
be compatible with the future. That is their job. The stupidest thing a
developer can do is hit a problem, and then blindly charge in and use some
"inside information" like an entrypoint in the ROM or an undocumented data-
structure to solve it and never tell anybody. 

Asking C/A accomplishes three things, one it raises their awareness of a 
weakness in the system that can be addressed in the next release. (Overscan
is a good example of this in 1.4) Two, it lets them figure out how to
support you both now *and* later without compromising the system's design.
Three, any other developer that has the same problem gets a ready made
solution. 

>        I think that 1.4 is far enough away that worring too much about it
> now (as far as games are concerned) is probably a mistake.  Lots of things
> are going to break on 1.4 anyway, so people will be used to needing updates.

Wade, this is a Commodore-64 attitude and you should know it. 2.0 isn't
far enough away that you shouldn't worry about it. If you are a professional
you realize that the better you are at compatibility now the better your
product will be in the future (and the more profitable). Not having to
send updates to your product can be worth hundreds if not thousands of 
sales. That's money, and as a developer for the Amiga you should always
strive to maximize the return on your investment so that you can continue
to eat. 

>        I'm not saying that one should fiddle with the system routines if
>they can avoid it, but if there is no other way...

And I'm saying there is *always* another way. And if there isn't then you
can get Commodore to give you a workaround that they will *always* support.
That's why there is a developer support program in the first place.

>        What I suggest is that anyone implementing such a hack think about
> the fact that it will need updateing in the future.  Arrange things so a
> patch can be made available, or at the very least so that the whole program
> will not need rewriting.

What I suggest is that anyone writing Amiga programs for profit a) Become at
least a registered developer ($50 to CATS, ask ...!cbmvax!lauren for more
info) b) *use* that service to make their code as robust as possible. And
if you are making a living writing code for the Amiga become a commercial
developer. Then when you have these problems solve them *with* Commodore and
everyone wins, your product still works under future revisions and the Amiga
becomes more capable as it is extended to do what you needed it to do.

(In Herbert/Dave's case you will notice that several alternatives were posted
 that solved his problem in a compatible fashion. This is almost *always* the
 outcome when you ask Commodore.)


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.