Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.amiga
Subject: Re: Re: Wishlist for 1.3 Executive.
Message-ID: <308@l5comp.UUCP>
Date: Tue, 28-Jul-87 03:40:47 EDT
Article-I.D.: l5comp.308
Posted: Tue Jul 28 03:40:47 1987
Date-Received: Thu, 30-Jul-87 04:48:55 EDT
References: <8707250710.AA00716@cogsci.berkeley.edu>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 89
Summary: But that's still building in stuff for developers!

>I want to be sure that >>> my <<< software is not defective!  I'd like to
>be sure that it works with only CHIP ram present, I want to check to see if
>it will run with only 256K, or 512K and put that number on the package.
Yeah, well I've always thought that a "developer kickstart" disk would be
real nice to have. It would have more robust error checking and the big
Wack built in! It could also have all your memory toggles as well.

However, I can see what a mess end users could make of things if they were
given these developer strength tools. Sure you and I know to exercise some
control over rebooting the machine, but again the average end user doesn't.
He/she will latch onto the thought "This one is safer than the other one" and
will only do safe reboots. Or "I don't know if I'll be using some EA software
or not so I'll boot with FAST ram disabled" and never stops, then one days
wonders where all the other ram went. :)

What I want is a BLOCKER. This blocker would block any FURTHER allocation
from certain ram types/ranges etc. This is different from the current
schemes where the extra ram is disabled/dismounted by some means. What I
want is something that lets me boot up normally, load the ol' ram disk etc
then say "OK, no further allocating ram from FAST type ram". But anything
already in FAST ram could still be used and deallocated at whim. This way I
could use my extra ram to hold tools and leave me with a "virgin" CHIP ram
to test the program out in. Like say I could load metascope into FAST ram
then set the block and then use the Metascope load command to fire up the
program to be tested which will of course be loaded into CHIP ram. I'm sure
you've worked on programs there were just too big for Metascope (or wack)
to fit into that cramped CHIP space... This way you can have your cake and
eat it too!

Hmm, this blocker could also be tagged by task ID so that a certain task
could be selected for special treatment "Give this task no FAST ram".

Or, I could tag Metascope to the blocker so that it only got FAST ram
except of course when it really wanted CHIP ram... ie force a FAST ram
compaction rather than slide down and give it some CHIP ram etc...

>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! Otherwise it's fair game in my book. If I'm not told to
leave something alone them I'm going to use it if I need it. BUT I don't
mean starting to jump into the ROM, I just mean as with the ACTION packets.
Here we have something OUT IN THE PUBLIC, obviously meant to be used, just
begging me to use it. After all, they could have just NOT defined those
"constants" for those unkown ACTION's if they never wanted us to use them.
You have noticed that the action numbers aren't exactly allocated in a totally
linear fashion right? :) I rest my case.

>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

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

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

>:-) :-) :-) - And then keep the user informed as to the progress.
You mean like "'Yo 'bro, ain't no one savied 'yo to not 'ower down while I be
writ'n to 'yo disk? 'Yo disk is mo' than fried!"

>What really drops AmigaDOS's performance to near zilch is when two tasks try
>reading from different parts of the same disk.  The way the validator works
This is why multiple track buffers are neat stuff. Of course the trick is
knowing how many to have. :) This is one area that gets tuned ALOT on a un*x
box. An Amiga should be easier though since it doesn't have multiple users
all fighting with each other over the track buffers.

>it me much more economical than a long distance call.  Their address is
>UUNET.UU.NET , seismo!uunet would probably also work.
Thanks for the hint.

Scott Turner
-- 
UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make
UUCP-auto: scotty@l5comp.UUCP    | sure I don't run up a vet bill.
GEnie: JST			 | "The bombs drop in 5 minutes" R. Reagan
		"Pirated software? Just say *NO*!" S. Turner