cs@mdbs.UUCP (07/14/87)
The other day I made a change to my sys:s/startup-sequence file using
the editor "ed". Well, I wrote the file out and then immediately rebooted
via Control-Amiga-Amiga to see if it would work. Well, many can guess
that the file was never written out because of the 1 to 2 second delay
it takes to "sync" the disk. What I want to know is, since Control-Amiga-Amiga
is not a system crash but rather a very friendly reboot, why didn't the
system wait for the disks to synchronize?? This is what I would like
the 1.3 executive to do for me, and hurry!
_____________________________________________________________________ _ __
Curtis Smith ...!{decvax,ucbvax,ihnp4}!pur-ee!mdbs!cs / |
Micro Data Base Systems, Inc. PO Box 248 Lafayette IN, 47902 (oo\
\ \
"If I am elected, the concrete barriers around the WHITE HOUSE _/\_|
will be replaced by tasteful foam replicas of ANN MARGARET!" _/bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/18/87)
> The other day I made a change to my sys:s/startup-sequence file using > the editor "ed". Well, I wrote the file out and then immediately rebooted | via Control-Amiga-Amiga to see if it would work. Well, many can guess | that the file was never written out because of the 1 to 2 second delay | it takes to "sync" the disk. What I want to know is,since Control-Amiga-Amiga > is not a system crash but rather a very friendly reboot, why didn't the > system wait for the disks to synchronize?? This is what I would like > the 1.3 executive to do for me, and hurry! Not debating the merits of the idea itself... but this would be a very easy thing to do under the current system. A little program would need to be written that adds a RESET handler to the keyboard.device and on activation sends a FLUSH to each mounted device. Of course the software may be in a somewhat suspect state if the user decides to hit the 'old Vulcan nerve pinch (CTRL-Amiga-Amiga or, for A500 users CTRL-whaddayacallthatkey- whaddayoucalltheotherkey). Care would needed to be taken as to the integerety of the devices you plan to FLUSH. ----------------------------- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."
page@ulowell.cs.ulowell.edu (Bob Page) (07/18/87)
cs@mdbs.UUCP wrote: >since Control-Amiga-Amiga is not a system crash but rather a very >friendly reboot, why didn't the system wait for the disks to synchronize?? >This is what I would like the 1.3 executive to do for me, and hurry! No way. I want to ensure that I can IMMEDIATELY stop writes to the disk (or the serial port, or whatever) on command without powering the system down. That's what Control Uh Uh is for. Sure the file system is fragile, and your disk might get trashed, but that's the price you pay for the ability to STOP the system. For user sanity, there should be a 'reboot' command that will flush I/O buffers, send messages to any processes/daemons, and do whatever other cleanup is necessary. Then it could warm restart the machine, or write "Type Control Uh Uh now" and loop in high priority with interrupts and multitasking disabled so nothing else gets run on the system. Another option would be to have a program that revectors the warm restart location and replaces it with a subroutine that flushes the disk buffers before it calls the REAL warm restart routine. So, what you want is possible, but altering the OS to automatically (by default, built into the kernel) do it for you is the wrong approach. In the meantime, remember that your machine multitasks. The disk driver runs when it can get the CPU slice to. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
scotty@l5comp.UUCP (Scott Turner) (07/20/87)
In article <8707180817.AA05716@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >Not debating the merits of the idea itself... but this would be a very easy >thing to do under the current system. A little program would need to >be written that adds a RESET handler to the keyboard.device and on activation >sends a FLUSH to each mounted device. Of course the software may be in a First, I don't want ANYTHING to intercept my Ctrl-Amiga-Amiga. Because if something can, then something will and if something does then it can fail and leave me reaching for the power switch. Then we'd be right where the PC folks are, cursing and groping. AT&T won't let me intercept signal 9 for that very reason (Signal 9 is the "sure kill" termination signal for a task under un*x.) Second, if someone out there wants to write a 'reboot' command then DO NOT flush devices, flush HANDLERS!!! People love to roll those two together and interchange them in discussions. BUT devices and handlers are NOT one in the same. If you flush trackdisk.device before rebooting you can leave data hanging around in a buffer in a DFx: handler... Or maybe there's a pending request in the handler? Third, how does one command AmigaDOG to make sure that it's ready for a reboot? ie close a file that is being written into so that upon reboot the disk validator doesn't get to come out for a romp? 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 Disclaimer? I own L5 Computing. Isn't that enough?
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/22/87)
In article <299@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >In article <> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >> >>Not debating the merits of the idea itself... but this would be a very easy ^^^^^^^^^^^^^^^^^^^^^^^^ >>thing to do under the current system. A little program would need to >>be written that adds a RESET handler to the keyboard.device and on >>[Ctrl-Amiga-Amiga] sends a FLUSH to each mounted device. Of course the >>software may be in a... > >First, I don't want ANYTHING to intercept my Ctrl-Amiga-Amiga. I agree!!! Anything hanging off that sequence is vulnerable to corruption, anything it does is suspect. I said that I was not debating the merits of the idea itself, but rather poiting out how it could be done. If I was god-of-all-things there would be Ctrl-Amiga-Amiga and Ctrl-Amiga-Amiga-Alt. One would be "safe" and flush all buffers. One would be dirty for use in emergencies. A workbench menu item could verify things with the user, give everything the goodby kiss, and then blank the screen and reset. A lot of people want a "official" shutdown, turning the machine off seems crude and dangerous to them. If they have a harddisk, I agree with them. Also I'd define some keys to selectivly disable parts of the auto-config 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. >Second, if someone out there wants to write a 'reboot' command then DO NOT >flush devices, flush HANDLERS!!! People love to roll those two together and >interchange them in discussions. BUT devices and handlers are NOT one in the >same. Terminology... Terminology. There are a number of things on the Amiga that have multiple names and a number of things that share a common name. YOU ARE more correct in saying that the thing to flush is a HANDLER. DOS was added so late to the Amiga that they fuddled up all the names. Type "assign" and look at what is below the heading "Devices". Some other DOS documentation I've read uses device and handler in the "wrong" manner, so you can see where the problem stems from. >Third, how does one command AmigaDOG to make sure that it's ready for a reboot? >ie close a file that is being written into so that upon reboot the disk >validator doesn't get to come out for a romp? What the validator does is unimportant. Even if the file is left open, and this bitmap is marked as pending... no sweat. What is important is that what has already been written, but is sitting is cache, is flushed. Care needs to be taken that the DEVICE (exec device such as trackdisk.device) has completed writing, turned off the drive, and is generally ready for doomesday. Catching it in the middle of a cache update would be the absolute worst thing that can happen. (See the V1.2 include file devices/trackdisk.i and search for the word "doom" :-) (no, really, it's there! :-|) If there was a better programmers definition of ALL the dos packets, there would be a better chance that you could cause a HANDLER to do the right_stuff before a forced powerdown. ACTION_FLUSH is documented, but whats that ACTION_DIE packet meant for anyway? Even "nothing" would be reassuring to those of use writing handlers. >| If you want to injure my goldfish just make >| sure I don't run up a vet bill. Note to scott on scottdisk.device. You mentioned bad documentation... well what better documentation than source code, and that's in the Rom Kernal Manual. Or perhaphs your troubles related to trackdisk-type devices?? Otherwise the sample source works just fine with a little tweaking and not much adding... ----------------------------- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "America has been discovered before, but it has always been hushed up" -Oscar Wilde
scotty@l5comp.UUCP (Scott Turner) (07/24/87)
In article <8707220001.AA01966@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >I agree!!! Anything hanging off that sequence is vulnerable to corruption, >anything it does is suspect. I said that I was not debating the merits of >the idea itself, but rather poiting out how it could be done. If I was The fact that you were discussing "how to" is what raised my concern. Someone might say "Gee that sounds neat lets do it!" without understanding any flip side issues. >god-of-all-things there would be Ctrl-Amiga-Amiga and Ctrl-Amiga-Amiga-Alt. >One would be "safe" and flush all buffers. One would be dirty for use >in emergencies. A workbench menu item could verify things with the user, give What I think is needed is a shutdown command. One for the CLI and a menu item for the Workbench. 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. :) Remember, no MMU means wild code can wack ANYTHING including data about to get flushed. >people want a "official" shutdown, turning the machine off seems crude >and dangerous to them. If they have a harddisk, I agree with them. Even with just a floppy system it's dangerous to just power off. Hackers are smart enough to know to wait 2-3 seconds for the auto-flush before doing anything drastic but most of John Q Public isn't. And the golden rule "Don't do nothin with the red drive light on" isn't a good rule either. I've seen the light go out and then the auto-flush kick in and it come back on 2-3 seconds after it went out. Hard disks just have it rougher. As an aside, it sure would be neat if the Amiga knew the difference between a floppy and a harddisk. My hard disk gets motor off commands all the time! For a system that's so flexible I don't seem to be able to say "I'll take the periodic flush calls, but please hold the motor offs, they give me gas." ;) But then again the whole motor on/off thing was a MAJOR kludge to begin with. >Also I'd define some keys to selectivly disable parts of the auto-config >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 benifit those who wish to use defective software. My skyfox no longer works with my memory expanded system. I don't blame C-A or expect THEM to fix it, I blame EA. Software that doesn't allocate ram correctly is just plain BROKE, it hits the trash can around here. >Terminology... Terminology. There are a number of things on the Amiga that >have multiple names and a number of things that share a common name. YOU ARE Terminology is important though in this forum. Tons of people read it from different backgrouds and Amiga experience levels. 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? I know the difference and you know the difference which is what concerned me about your statement. The thought "Maybe Bryce forgot about handler caching" ran through my mind. >What the validator does is unimportant. Even if the file is left open, and >this bitmap is marked as pending... no sweat. Obviously you haven't spent alot of time waiting for the validator to run its course. On a 20 meg hard disk it's like watching glaciers form. Sure there's no permanent data loss, but it's still a royal pain plus VERY alarming to those who don't know what the hell is going on. Witness recent messages here. 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. >What is important is that what has already been written, but is sitting is >cache, is flushed. Care needs to be taken that the DEVICE (exec device such >as trackdisk.device) has completed writing, turned off the drive, and is >generally ready for doomesday. Catching it in the middle of a cache update I think this whole topic falls into another one of those nitty gritty details that the C-A crowd has yet to deal with. It took Apple a while to figure out the details on this feature for the Mac family as well. The problem I see is that the hooks were there from day one to shutdown a Mac, but I don't see some of the crucial hooks in the Amiga. Otherwise I'd craft a shutdown program. Having a Mac here on a daily basis has infected me with the desire to have a real shutdown rather than risk my patience at 03:00. It's very comforting to know that if I yank restart or shutdown on the Mac everything will get flushed/shutdown A-OK. >If there was a better programmers definition of ALL the dos packets, there would >be a better chance that you could cause a HANDLER to do the right_stuff before >a forced powerdown. ACTION_FLUSH is documented, but whats that ACTION_DIE >packet meant for anyway? Even "nothing" would be reassuring to those of >use writing handlers. Nothing is what the ram disk does for ACTION_DIE. The best dox I have on dog packets was gleaned from ripping ram-handler apart. But even it doesn't handle some packets that I know the disk handler handles (Like add cache). This has been one of things I've been curious about under the new developer's program. No one replied to my query regarding the new program so I can still only guess. But it seems that they get the same dox that we've always gotten. And sure you can save a few bux on hardware but with Amiga dealers as scarce as they are doesn't it make sense to prop the local ones up? Given the choice of buying my goodies from C-A or my local dealer I'd pick my local dealer. They're nice folks and I'd like to see them stay in the business, even if only so they can sell my commercial products. :) And when it comes to time for service it sure feels good to be able to say "YES!" when they ask if you bought the machine from them. Every dealer I know has a "They bought it here" program in their service departments. If two machines need the last disk drive in stock, the machine bought from that store is going to get it over a developer machine bought from C-A. 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. I'm about to write a HUGE handler, Arthur a whole new file system, and as these handlers start catching on it'll be damn hard for C-A to pop up and say "Well now we're going to document those packets and by the way you've all be using them the wrong way!" >Note to scott on scottdisk.device. You mentioned bad documentation... >well what better documentation than source code, and that's in the Rom Kernal >Manual. Or perhaphs your troubles related to trackdisk-type devices?? >Otherwise the sample source works just fine with a little tweaking and >not much adding... The RKM's driver is missing tons of stuff for those that wish to do a disk driver. It's also missing crucial code concepts for those that wish to do serial or parallel devices. It's great if all you want is yet another ram disk. Also, people like to say source code is great dox. It just isn't so. Working source code just shows you how to make something work as it does. It very often doesn't tell you how to make tweak A or tweak B or don't do this because the machine will vaporize. "DEMO SOURCE" is even worse because it doesn't even work. You always have that nagging doubt in the back of your mind, when your code based on the demo code doesn't work, as to wether it's your code or the code in the demo that's screwed. Source code is to documentation as pictures are to a text book. PERIOD. A picture in a text book is not entirely useless without text to describe it but it's not nearly as useful. Same goes for source code and documentation. 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 Disclaimer? I own L5 Computing. Isn't that enough?
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/25/87)
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 <insert your favorite gizmo here>, 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."
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (07/27/87)
In article <8707250710.AA00716@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > 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... What a great idea! Write a glossary that would explain all the special "terms of art" in the Amiga system so poor folks like me who are trying to understand the RKM could figure out what's going on. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...seismo!akgua!usfvax2!jc3b21!fgd3
scotty@l5comp.UUCP (Scott Turner) (07/28/87)
>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
mjp@spice.cs.cmu.edu (Michael Portuesi) (07/29/87)
Keywords: scotty@l5comp.UUCP (Scott Turner) writes: > 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. > 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. But the problem with these ideas is that it creates an environment that is *not the same* as the one Joe User will be using. Problems could occur in the "developers" configuration that do not show in the "user" configuration, and vice-versa. It's much like cross-developing on a Sun or switching from compiler X, which has very fast compilation to compiler Y, which is slow but highly optimizing, at the completion of program development. Subtle errors can sneak in which get past QA and meet Joe User, whose environment is not the same. Aegis has already run into this problem with Diga!, and list a whole bunch of changes to make the environment of the distributed product match that of the developer's enviroment. The more you distance yourself from the vanilla environment, the more you are asking for trouble. --M -- Mike Portuesi / Carnegie-Mellon University Computer Science Department ARPA: mjp@spice.cs.cmu.edu UUCP: {backbone-site}!spice.cs.cmu.edu!mjp BITNET: rainwalker@drycas (a uVax-1 run by CMU Computer Club...tons o' fun) "Paradise is exactly like where you are right now...only much, much better" --Laurie Anderson, "Lanugage is a Virus"
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/29/87)
In article <308@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: In article <> bryce@cogsci.Berkeley.EDU types: > > ...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. :) Hrmph! If any user holds down control and F3 to disable their ram EACH TIME they boot, then wonders where it all went they paid too much for their computer. I'd recomend switching to something cut out of a magazine. :-) >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... >...This way you can have your cake and eat it too! It's on the A500/A200 workbench. It's called nofastmem, and even comes with a slick icon. It's all you asked for. "poof". >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". That's possible. Just SetFunction AllocMem() and AvailMem(). Do a FindTask(0) to see who called you, and check the table. Remember to make that code re-entrant and place it memory allocated as PUBLIC. >>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 Sorry, you missed the strongly implied COMMODORE-AMIGA COULD at the start of that. It would be pure terror for everyone and his goldfish to take off and start defining packets. >>[UUNET] may much more economical than a long distance call. Their address >>is UUNET.UU.NET , seismo!uunet would probably also work. >Thanks for the hint. Here's a better hint. If you have a system that has a costly feed, send you US snail mail address to usenix!madeline. You will be send a packet describing UUNET communications services. ----------------------------- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."
daveh@cbmvax.UUCP (Dave Haynie) (07/29/87)
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
scotty@l5comp.UUCP (Scott Turner) (08/08/87)
In article <1248@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes: >But the problem with these ideas is that it creates an environment >that is *not the same* as the one Joe User will be using. Problems The idea WAS to create such an environment. The debug tools get to live in FAST ram and the program in CHIP ram. If having an EXACT memavail is needed then you can allocate a hunk of ram to match that used by the OS in a 512k machine. >of program development. Subtle errors can sneak in which get past QA >and meet Joe User, whose environment is not the same. Aegis has >already run into this problem with Diga!, and list a whole bunch of BLOCKER could be used to disable the FAST ram for QA testing. But what kind of ram you have is only half the problem. Aegis screwed up in not using a stock workbench disk to do testing. If their QA department had booted up with a stock workbench disk AND then tested Diga they might have avoided some of the fun they've had with that product. >changes to make the environment of the distributed product match that >of the developer's enviroment. The more you distance yourself from >the vanilla environment, the more you are asking for trouble. But you also forget one of the USES for BLOCKER, to let the a programmer debug a program that would otherwise eat all the ram and leave none for debugging tools. As TDI has shown it's kinda nice to DEBUG things before you ship them. :) 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
scotty@l5comp.UUCP (Scott Turner) (08/08/87)
In article <8707291107.AA05244@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >Hrmph! If any user holds down control and F3 to disable their ram EACH >TIME they boot, then wonders where it all went they paid too much for their >computer. I'd recomend switching to something cut out of a magazine. :-) Yeah, :-), BUT there are people out there that um um "ignorant"? Yeah, that's the term I think. :) Alot of program developers just don't realize that they are designing software that will often NOT be used by terribly sharp people. You have to remember that these computers are already "black magic" for the masses. How should they know that mashing Ctrl-F3 during bootup is rather unusual? The whole computer is rather unusual eh what? :) And if the dealer says "You mash Ctrl-F3 during bootup so you can run software like Skyfox" then there will be those users that take that to mean :mash it all the time". 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