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