Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Re: Wishlist for 1.3 Executive.
Message-ID: <2166@cbmvax.UUCP>
Date: Wed, 29-Jul-87 15:53:51 EDT
Article-I.D.: cbmvax.2166
Posted: Wed Jul 29 15:53:51 1987
Date-Received: Fri, 31-Jul-87 05:46:16 EDT
References: <308@l5comp.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 79

in article <308@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) says:
> Summary: But that's still building in stuff for developers!
> 
>>I would not want anyone to be depending on certain undocumented parts of
>>AmigaDOS that I hope will one day DISAPPEAR along with the current 
>>implementation of DOS.
> Like it or not what we have here is here. It ain't going to disappear in a
> puff. 1.2 is likely to be around awhile longer now that it's being cranked
> out in ROM form. If something is to be made to disappear then it should
> be documented! 

That's nearly what folks used to say about jumping into the inside of ROM
routines on the C64 ("if I'm not supposed to use it, I shouldn't have normal
read access to it").  We've just moved it up a level or two.  The packets
that are undocumented are logically undocumented for a reason, one would
assume.  Like, maybe they won't always be around.  Now, of course, if you
write your own handler, then you're responsible for the packets that it
accepts.  Hopefully, none of the undocumented packets will go away unless
there's a pressing need for them to do so, but I personally wouldn't risk
it in a commercial product.  It's always up to the handler to accept or
reject an ACTION, so as long as you can cope with a handler that says "I can't
do that", maybe you're OK.  I briefly spoke to Andy about some of this last
week, but I'm not all that sure of C-A's official position on packets, other
than "If we've really told you about it, it's supported and you can expect it
to be around in the future.

>>this feature in their handler code?  Just distribute a trivial little program
>>to fire off ACTION_PREPARE_FOR_DOOM along with the documentation.
> This is exactly my fear. Once this starts then everyone will start defining
> their own ACTION's and all hell will break loose. Byte by Byte will write a
> shutdown manager and their software will know it, then C Ltd will do another
> and of course it won't get a flying leap for Byte by Byte's etc etc etc

That's a good reason to register new packets.  There's a good chance that
if you want to do something new and froody, that the next guy may be
considering the same move.  If you can agree on the name/number of the
packet and the calling convention for the same logical action, then why
not?  It's so easy to do, certainly less detail than creating a spec for a
full IFF form, and it would prevent this type of compatibility.  Kind of a
"C-A isn't doing this thing yet, but if you do it, everyone else is already
doing it this way".
> 
>>There are still disagreements.  I say that $C00000 memory is "automatically"
>>"configured" by the V1.2 operating system, and thus the term "auto-config"
>>could apply.  However, many people object to that term!  Perhaps those
>>people would like to mail the "proper" term to me for inclusion?
> How about "Kludge ram"? :-)

No kludge involved, at least on the machines that have this as an innate
feature (like the A500...).  I'd prefer to call it "motherboard owned RAM",
or something like that.  Add-on memory must certainly show up as real
expansion bus autoconfigured memory, or it's a kludge; I'd be the first to
agree on that.  But an Amiga motherboard has the right to know what native
resources it has, without requiring true autoconfiguration or, for that
matter, taking up valuable autoconfig memory space.  That's basically what
"reserved" means.  $C00000 memory is analogous to CHIP memory; both are
motherboard resources that the OS can automatically size.

Now, $C00000 memory added to an existing system is very likely a kludge,
or very close to it.  There's no completely cool method of installing such
memory on an A1000, though there are a few reasonable schemes which can
work very well if done correctly (Byte-by-Byte uses one of these in it's
PAL Jr., I wrote a "freely-redistributable" article describing one other
method).  Any system that has this as an innate resource would certainly be
able to map it in a completely cool way.
> 
>>"'Yo, 'bro, 'yo disk is fried!  Wanna gamble and let me try ta fix it 'fo ya??"
> Maybe they could put this in a "secret" message, you know you hold down the
> Left Amiga key while booting and if the Validator runs it'll print the above
> message.

Even better, let's have it say "'Yo disk be fried.  Try DiskDoctor if yo' in 
a gamblin' mood, otherwise be tryin' DiskSalv.  An den pay de man!"  :-).

> Scott Turner
-- 
Dave Haynie     Commodore-Amiga    Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh
"The A2000 Guy"                    PLINK : D-DAVE H             BIX   : hazy
     "Catch a wave and you're sittin' on top of the world" -Beach Boys