Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: Re: Wishlist for 1.3 Executive.
Message-ID: <8707250710.AA00716@cogsci.berkeley.edu>
Date: Sat, 25-Jul-87 03:10:18 EDT
Article-I.D.: cogsci.8707250710.AA00716
Posted: Sat Jul 25 03:10:18 1987
Date-Received: Sat, 25-Jul-87 18:19:21 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Institute of Cognitive Studies, UC Berkeley
Lines: 127

In article <> scotty@l5comp.UUCP (Scott Turner) writes:
>In article <> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
>>
>>Also I'd define some keys to selectively disable parts of the configuration
>>process.  Press CTRL-F1 and restrict yourself to 256K of CHIP ram.  If
>>CTRL-F3 is held down then $C00000 memory is not sized, etc.  More thought
>>is needed as to the keystrokes, but the idea has merit.
>>
>What is needed is better software. I don't see why the C-A folks should put
>time into this to benefit those who wish to use defective software.  My skyfox
>no longer works with my memory expanded system...

Good comment, but the wrong reason!!  I long ago tossed any software that
I could not get to work with 1.2 and FAST ram.

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.
I want to try it without , and see if it is
still usable.
If I can disable parts of the configuration without a screwdriver, there is a 
better chance that I'll actually test different configurations.
Believe it or not, I *have seen* software that won't work WITHOUT FAST memory,
for no better reason that the author misstyped while using ATOM, and never
noticed.

I recently had to wipe the dust off my V1.1 kickstart so I could run a full ram
test on my $C00000 memory.  If I let V1.2 at it, it would have been full of
system junk before my code go a chance to start. 
If $C00000 memory is bad (mine was) the computer is useless unless the board
is surgically removed, or configuration is not run.

Anyone want a V1.0 kickstart??  I have two for sale, cheap! :-)


>I think C-A's current program of not documenting the COMPLETE set of ACTION
>packets is going to just cause more trouble down stream. People are already
>starting to write more and more handlers.

While I don't think the lack of documentation on all the packets is an
active intent on the part of Commodore, it sure would be reassuring to have
an authoritative "These packets you can support, do it like this"
*and*  "Don't use these, or do that because it might change".  It would
improve the quality and quantity of handlers.
As bad as not knowing about certain internal procedures is knowing TOO MUCH.
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.

If it is needed, I'd like to see ACTION_PREPARE_FOR_DOOM defined.  A shutdown
manager would send one of these off to each handler.  Any handler that knew
about this packet would it would flush it's buffers, park the heads, whatever.
As it stands, ACTION_DIE is not documented, and ACTION_FLUSH does not imply
parking heads or other such drastic action.
Note that this could even be a "paper upgrade" to the OS.  Who says that
the OS has to know about shutdown managers before people can start implementing
this feature in their handler code?  Just distribute a trivial little program
to fire off ACTION_PREPARE_FOR_DOOM along with the documentation.


>> A workbench [shutdown] menu item could verify things with the user...
>
> What I think is needed is a shutdown command. One for the CLI and a menu item
> for the Workbench.

We concur.


> Having it as a Ctrl-Amiga-Amiga-Alt (or whatever key
> sequence you wish to use) could lead people to try the safe reboot in places
> where things are really screwed up. ie if you don't have a working CLI or
> workbench to run a shutdown from then it might be a real good idea to not
> try flushing anything out to disk. :)

Depends on what's going on.  As a programmer I have had times where I knew
what went wrong, and just WHY the input.device was dead, and wanted the safe
reboot.  I'd prefer having BOTH options.
Regardless, the safe shutdown should do all it can to see that things
are not corrupt before acting.  Checking library checksums is a good start
(Though that will blow away anybody using "Blitz" or any other program
that does not use SetFunction() when mangling libraries. ). 


>If those of us that DO know the difference between device drivers and device
>handlers don't keep it straight how can we expect those that DON'T know the
>difference to get it straight?

My first comment stands.  The DOS, certain CLI utilities and the documentation
are inconsistent about terminology. ...I think I'll write a glossary and
post it... 
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?


>As a side note, I think that C-A should have the validator at least print a
>message saying something like "Validating disk XXXX", followed by the
>infamous "This may take a few minutes". :-) I hope this can be slid into
>1.3, the current non-talkative validator does seem to be alarming people.

Yes!  Number 11 on my list of needed improvements would have the validator
pop a requester that says (in proper Victorian English):

"'Yo, 'bro, 'yo disk is fried!  Wanna gamble and let me try ta fix it 'fo ya??"

:-) :-) :-) - And then keep the user informed as to the progress.

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
now almost insures that it will take "several minutes" of heavy grinding
to get anything done...


> [It costs me $9 an hour to get USENET, vs $5 for...]

Have you heard of UUNET communications service?  I don't have details in front
of me, but as I remember for about $2 an hour (?plus?) telenet/tymnet charges
they will give you a feed and a tight link to seismo.   The intent was that
it me much more economical than a long distance call.  Their address is
UUNET.UU.NET , seismo!uunet would probably also work.

-----------------------------
|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."