mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/11/91)
In article <BURLEY.91Jan10111657@geech.ai.mit.edu> burley@geech.ai.mit.edu (Craig Burley) writes: In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: I'm confused -- is the issue that AmigaDOS' scheduling algorithm allows low-priority tasks to be starved when higher-priority tasks stay eligible? Of course you're confused - you've walked into the middle of a discussion, and have no idea what we're talking about. Loren Rittle was asking if it was possible to change the Amiga's multitasking so that user processes can't be starved, based on commentary in an ongoing discussion of the phrase "true multitasking". He quite correctly moved the discussion to .programmer from .misc. I'll try and fill you in, and point followups to comp.sys.amiga.misc, where this belongs. True multitasking, as I believe it is defined, means preemptive scheduling. Actually, "true multitasking", as it is commonly _used_, means preemptive multitasking. If you've got a reference to a textbook that defines the term (in any way), I'd appreciate hearing about it. As I've just pointed out, there's a perfectly adequate term preemptive multitasking, without the derogatory implication that someone else's multitasking is "fake" or "false" in some way. The first uses I saw were from insecure Amiga owners trying to demonstrate the inferiority of someone else's machine. As such, the terminology is bad, and should be avoided. That is a hard thing to introduce to an operating system with a large installed base including 3rd-party applications. Multifinder is not true multitasking, period. Bullshit. Explain to a user who doesn't have the foggiest idea what a scheduler is why his machine - which, as far as he can tell, behaves exactly like an Amiga under normal operation - has "fake" multitasking. Especially when (from what I hear of the Mac world) the percentage of commercial programs that are multitasking friendly on the Mac is larger than on the Amiga. In summary, I don't think it is at ALL silly to define true multitasking to exclude Multifinder, and I doubt that even Apple Marketing would disagree -- and I do agree it IS silly to claim that true multitasking includes meeting any particular set of requirements for task scheduling, especially since "priority levels" are used to mean so many different things in different situations. Actually, I think it's silly to define "true multitasking" at all. Either something is multitasking, or it isn't. I've already explained how to tell which is which. If you insist on defining "true multitasking", do it in non-technical terms. How about "no non-privileged task can starve any other task"? Please note I don't define single-tasking, cooperative multitasking, or true multitasking as GOOD or BAD. They all have their advantages and disadvantages, and I have done lots of useful work in all three environments (the bulk under true multitasking) and had problems with all three. I take it that the bulk wasn't done on the Amiga - it doesn't have "true multitasking" by the definition I'm going to use until an authoritative source appears. <mike --
skank@iastate.edu (Skank George L) (01/12/91)
In article <27808.278d9319@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: [Childish bickering deleted...] >However, I would not advise on changing the >Amiga scheduleing algorithm, because you might break some internally >multitasking applications that assume a task that it set to higher >priority wont be prempted by a lower priority part. GOOD point! -- George L. Skank | skank@iastate.edu |Fast cars, fast women, fast computers... Senior, Electrical Engineering |(not necessarily in that order)
peter@sugar.hackercorp.com (Peter da Silva) (01/13/91)
In article <MWM.91Jan10120936@raven.relay.pa.dec.com>, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > Actually, "true multitasking", as it is commonly _used_, means > preemptive multitasking. That's because all systems that were designed to multitask from day 1 use pre-emptive scheduling, *except for* a few Forth real-time systems with extremely tight memory budgets. Pre-emptive multitasking is what people for years meant by "multitasking". Polled multitasking was always considered a sort of poor cousin, and systems like Polyforth that depended on it were looked down upon. When people started referring to polled multitasking in terms that indicated they didn't know the difference between the two the terms "real" and "fake" multitasking showed up. > If you've got a reference to a textbook that > defines the term (in any way), I'd appreciate hearing about it. I've got 10 years of experience in the process control industry that defines the term that way. The usual reaction to hearing that Apple is claiming they've got a real O/S finally on the strength of their polled scheduler, among my co-workers, is "you've got to be kidding". > Bullshit. Explain to a user who doesn't have the foggiest idea what a > scheduler is why his machine - which, as far as he can tell, behaves > exactly like an Amiga under normal operation - has "fake" > multitasking. No problem. Just demonstrate that his machine doesn't behave exactly like an Amiga. Cut it down to 512K and watch it crash. Start up more thana couple of applications in a 2 Meg machine. Ask why the mouse is moving funny. Have him try to do anything useful while formatting a disk. Ask him why he can't run multifinder on a Mac Classic. > Actually, I think it's silly to define "true multitasking" at all. I agree. It's silly to even talk about a polled scheduler as "multitasking". > Either something is multitasking, or it isn't. I've already explained > how to tell which is which. If you insist on defining "true > multitasking", do it in non-technical terms. How about "no > non-privileged task can starve any other task"? Funny, people in the process control industry consider UNIX daft because a low priority task can still execute while there are higher priority tasks executing. How about defining "real multitasking" as "real-time multitasking"? At least that has a pretty good definition. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/13/91)
In article <7504@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >No problem. Just demonstrate that his machine doesn't behave exactly like an >Amiga. Cut it down to 512K and watch it crash. Start up more thana couple The average Mac user knows less about the Amiga than the average Amiga user knows about the Mac. Be that as it may, you can run a Mac 512k, and even do task switching on it. >of applications in a 2 Meg machine. Ask why the mouse is moving funny. Have him I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be selective about what I launch). >try to do anything useful while formatting a disk. Ask him why he can't run Yeah, that is a substantial criticism. I mean really, how OFTEN do you need to format a disk? It is nifty to be able to do so and run another task, but it just as easy to format a bunch at once and then go back to work. >multifinder on a Mac Classic. Get a new source for your Mac info. MultiFinder runs just fine on the Classic. When someone spreads misinformation about the competition, you begin to wonder how thoroughly they know their own machine. The Amiga already is an impressive bang/$ hunk of iron WITHOUT tilting the scales with caca spread about "the other guys".
jlh@noether.math.purdue.edu (Jeffrey Hensley) (01/13/91)
In article <42459@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: [Refering to formatting disks while other tasks are still running] > >Yeah, that is a substantial criticism. I mean really, how OFTEN do you need to >format a disk? It is nifty to be able to do so and run another task, but it >just as easy to format a bunch at once and then go back to work. > It is interesting to note what is and is not important to different people!! What is not easy is to discover that you don't have a blank formatted disk handy but that you desparately need to save a couple of hours of work.... This topic often comes up when talking about multitasking and the differences between Amigas and Macs. The point is that an operating system that allows you to do these somewhat small and mundane tasks while still running other tasks is certainly preferable! How many system administrators would tolerate an implementation of Unix which required the system to be halted to add a new user? --Jeff Hensley
peter@sugar.hackercorp.com (Peter da Silva) (01/14/91)
In article <42459@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > In article <7504@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >No problem. Just demonstrate that his machine doesn't behave exactly like an > >Amiga. Cut it down to 512K and watch it crash. Start up more thana couple > The average Mac user knows less about the Amiga than the average Amiga user > knows about the Mac. Be that as it may, you can run a Mac 512k, and even do > task switching on it. Yes, using "switcher". There's as big a difference between Switcher and Multifinder as between Multifinder and AmigaOS. > >of applications in a 2 Meg machine. Ask why the mouse is moving funny. Have him > I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be selective > about what I launch). Whereas I can start up a bunch of applications in my 1.5M Amiga and could care less what they are. That's the main difference... the Amiga just works, and you don't have to play games with partition sizes and stuff. > >try to do anything useful while formatting a disk. Ask him why he can't run > Yeah, that is a substantial criticism. I mean really, how OFTEN do you need > to format a disk? That's bordering on a flame, man. "Formatting a disk" is just an example of a moderately real-time task. There are plenty of others... for example, I can run applications concurrently with real-time music software on the Amiga, without screwing anything up. Again, on the Amiga it just works. On the Mac you have to fiddle with it. > Get a new source for your Mac info. MultiFinder runs just fine on the > Classic. Hmmm, last time I checked Multifinder required a Mac-II. I'll have to go down and watch Multifinder on a stock Classic some time. Given how much of a dog it is on a stock II I'm not expecting much. > When someone spreads misinformation about the competition, you begin to wonder > how thoroughly they know their own machine. Well, I can only work with what I've seen. And I've seen little on the Mac to make me expect Multifinder to be usable on a Classic. It just chews up too much RAM and CPU covering for applications that expect a single-tasking environment. Insinuating that I don't now "my own machine" because I'm not as impressed by multifinder as you would like is a low debating trick. You interested in communicating or "winning" here? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
burley@geech.ai.mit.edu (Craig Burley) (01/15/91)
Regarding Mac's Multifinder, here is how to tell whether it has true multitasking (which does mean preemptive scheduling in any context I've ever heard the term defined): Start up a comms program and get a reasonably long file transfer going, like via kermit or X-modem. Now switch to the Finder or some other app (perhaps even the comm app itself, though mine, Microphone II, is smart enough to keep things going despite the pulled-down menu -- if it is its own). Now pull down a menu and hold it down for about five minutes. Now go back to the comms program window and see how much stuff has been transferred and whether the transfer has crashed. The answer should be "No, the transfer kept plugging along", but on the Mac it currently is, "Yes, when holding a menu in the pulled-down state, no other tasks on the system continued running except perhaps the vertical retrace task". If the comms program is smart enough to put the file transfer into the vertical retrace task, try using a long compilation instead of a comm program task instead, and see if it keeps compiling even while the menu is held down. Note that in any case, it is absolutely certain that on the current Mac, either you don't have true multitasking and it is fairly easy to expose it, or the programmers of the apps you are using have had to jump through hoops to disguise it (as did the Microphone II engineers -- for which I'm very grateful). (To be fair, as I've posted before, just doing true multitasking requires a bit of jumping through hoops for the OS and its applications -- but nothing like simulating it, efficiently, without actually having it.) Anyone care to post whether this kind of scenario works on the Amiga? I.e. when holding a menu down, or doing other purely user-interface things that aren't inherently resource intensive (like just holding a mouse button down without moving the mouse), does true multitasking keep working? My guess would be yes, it does. -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/15/91)
In article <7511@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be > selective about what I launch). Whereas I can start up a bunch of applications in my 1.5M Amiga and could care less what they are. Yeah - GNU Emacs works like a charm, and ADPro can handle some _really_ large images in 1.5M. And AmigaVision runs alongside both of those, just fine. Where did you say that beachfront property was, Peter? <mike --
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/15/91)
In article <3668@mentor.cc.purdue.edu> jlh@noether.math.purdue.edu (Jeffrey Hensley) writes: > It is interesting to note what is and is not important to different >people!! What is not easy is to discover that you don't have a blank >formatted disk handy but that you desparately need to save a couple of >hours of work.... I'll admit that it is a convenient feature. However, I always run with at least a couple of meg free on my hard disk, so I never have the problem. The bottom line in comparing systems is how you normally work with the system and what compromises you have to make to do things the way you want to. > This topic often comes up when talking about multitasking and >the differences between Amigas and Macs. The point is that an operating >system that allows you to do these somewhat small and mundane tasks >while still running other tasks is certainly preferable! How many system >administrators would tolerate an implementation of Unix which required >the system to be halted to add a new user? Yes, but aside from the disk formatting question, I don't know of many small tasks that I can't do with my Mac while doing others. Half the reason I plan on getting an Amiga is just to have the two systems side-by-side to see the differences. I still think one of the best ways to compare two platforms is to have power configs for each side-by-side and compare both the capabilities of the machines and how the user adjusts their work to complement that machine.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/15/91)
In article <7511@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Hmmm, last time I checked Multifinder required a Mac-II. I'll have to go >down and watch Multifinder on a stock Classic some time. Given how much of >a dog it is on a stock II I'm not expecting much. I've run MultiFinder on the Mac Plus and up. I run a network of 30-odd Macs, of which about 10 are running MultiFinder with 2.5 meg of RAM. The only problem people have is RAM shortages. (Part of this is due to running lots of toys like custom desktop patterns and event sounds.) >Well, I can only work with what I've seen. And I've seen little on the Mac to >make me expect Multifinder to be usable on a Classic. It just chews up too much >RAM and CPU covering for applications that expect a single-tasking environment. The major use of MF is task switching. My guess is that for the kinds of things you probably do on an Amiga, it would be a dog. MF is fine for WP while downloading a file. >Insinuating that I don't now "my own machine" because I'm not as impressed by >multifinder as you would like is a low debating trick. You interested in >communicating or "winning" here? It actually wasn't intended as a debating trick. I was angry that you'd posted a piece of blatant misinformation. I apologize. I get really annoyed when seeing comparisons of platforms where one side is unnecessarily handicapped that way.
jimb@pogo.ai.mit.edu (Jim Blandy) (01/15/91)
This discussion makes True Multitasking sound like the True Grail, or True Love. There's an implicit value judgement there, and nobody wants their machine to lack True Multitasking, even if they can't agree on what that actually means. Let's abandon the term, and talk about what actually happens. A Mac running the Multifinder has non-preemptive multitasking; each task voluntarily gives up control. The Amiga does preemptive multitasking; a task may be stopped at any time. It is nice to be able to run other tasks while a task waits for its I/O to complete. The Mac won't do this (will it?); big-machine OS's like VMS and Unix will do this. The Amiga does this. My college OS textbook talks about "strict" and "non-strict" priority systems for scheduling. A strict priority system never runs a lower-priority task when a higher-priority task is runnable. Under a non-strict scheme, lower-priority tasks get less time, but don't starve. Both have their uses, but don't confuse them. The Amiga exec does provide system calls to disable and re-enable multitasking; I imagine this is because Commodore would rather provide a system call than have people non-portably hack it when they need it, but one doesn't need these calls in normal Amiga programming. I think the Amiga support for multi-tasking is a bit cleaner, perhaps because it was in the design early. Separate application heap zones are unnecessary, and processing can go on concurrently with I/O, for example. Backward compatibility is very important to Apple, and this constrains them. -- -Jim Blandy jimb@ai.mit.edu
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/15/91)
In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes:
This discussion makes True Multitasking sound like the True Grail, or
True Love. There's an implicit value judgement there, and nobody
wants their machine to lack True Multitasking, even if they can't
agree on what that actually means. Let's abandon the term, and talk
about what actually happens.
Yes, yes, yes! That's been my point all along. It's judgemental, and
there is a perfectly good term to use for it's normal use here. Also,
nobody has come up with a textbook definition, which means that
misinterpretations due to people using different definitions is
possible.
<mike
--cocoiii@hobbes.ncsu.edu (John Vestal) (01/15/91)
I've been watching this very interesting discussion about
multitasking, and would like to make a few comments. I don't know
about how the kernals in MAC OS, AmigaDOS, OS/2, UNIX, or OS-9 work, but
I've used them all but OS/2. The Mac does a decent job of 'kludging
multitasking'. You can't (or I haven't found a way) of changing tasks
priority's on the Mac though. AmigaDOS does multitasking very
smoothly, but I have seen (mainly games) that will not let anything
else run. Well, at least not get too them, I don't know that they
aren't running, but to me they're not there. If you change a very CPU
intensive task to a higher priority, other tasks can 'stop'. On UNIX
you can run a lot of programs and you can never 'stop' a process,
without killing it, or setting it's priority as low as possible. The
difference between the two, if I have a compile that (for fun) takes
all of the CPU, and a shell running. The compile is one above the
shell. On AmigaDOS, the shell gets no time, until the compile is
done. On UNIX, the shell gets a certain percentage less then the
compile. It still gets some though. This is also how OS-9 works.
Tasks age, and after they are so old, according to the priority, they
get a CPU cycle. They also get any 'leftover' CPU, but AmigaDOS does
this too. Now, for me as a user, I want any process that I am running
to get some time. I should tell it at least how often I want it to
run. It can run more often, but at least this often. OS-9 does this,
and it doen't give up 'real-time response'. As a matter for fact, it
the OS of choice for realtime work. At least from what I've seen and
heard. Anyway that's my 2 cents worth.
cocoiii (John Vestal)
--
******************************************************************************
* cocoiii@catt.ncsu.edu Phone: (919) 831-2890 North Carolina State *
* John Vestal P.O. Box 21537 Raleigh, NC 27607 University *
******************************************************************************yorkw@stable.ecn.purdue.edu (Willis F York) (01/15/91)
pab@po.CWRU.Edu (Pete Babic) writes: >How about if your using a floppy based system, running a term prog. that's >downloading to a ram disk and you find out you need a new floppy to store >the files as they are disolved? And then how about disolving that file to >the floopy while you are downloading another file to ram? And then how about >reading the manual that comes with the first file with a text reader like More >while the second file is being disolved to disk and a third file is being >downloaded to ram? YA frogot to mention that this can be done "automaticially" with a nice Arexx script, so ya can play some nice games while the computer is working........ I get pissed off at my HP calculator because it don't multitask! (same with the my 64....) Once ya Multitask ya never ???????????? (I can't think of a good rhyme) >-- -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
new@ee.udel.edu (Darren New) (01/15/91)
In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: >A Mac running the Multifinder has non-preemptive multitasking; each >task voluntarily gives up control. The Amiga does preemptive >multitasking; a task may be stopped at any time. It's worse than this. Try starting up multifinder, hypercard, and (say) tetris. I just did this last night because I wanted to play tetris but the owner of the machine had the hypercard stack open. Anyway, the music was all messed up and the blocks fell at different speeds, making it difficult to play. I then realised that hypercard must be sucking up CPU time even though it was not active, it was not running anything, and the mouse was not near the window. I confirmed this by closing hypercard and suddenly everything was fine. On the Amiga's exec, if a task is waiting for input, it does not take any CPU time until the input is ready. With cooperative multitasking (at least as implemented on the Mac), each application is asked "are you ready yet?" and each must answer, and this takes noticable CPU time away from the tasks that *are* ready. It also becomes easy to see where tasks can block other tasks, as the music plays fine if you hold open a menu, and totally stops when a floppy is inserted (until the floppy icon comes up). Anyway, by designing in the multitasking on the Amiga, it is possible for a task to totally give up the CPU and get it back later when it needs it. On the Mac, each task must constantly use CPU time to see if it needs more. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/15/91)
In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: > >A Mac running the Multifinder has non-preemptive multitasking; each >task voluntarily gives up control. The Amiga does preemptive >multitasking; a task may be stopped at any time. > Problem is, most tasks DON'T give up control. Mac programs have to be written to purposely give up control and many are still written badly enough to not work, MicroSoft being one of the worst culprits. The Amiga's MAIN advantage is that it is built into the system. You just don't do anything unusual with your program and it'll multitask very nicely. Yes, Apple is constrained by backwards compatibility, but I hate being constrained by backwards operating systems! 8) >The Amiga exec does provide system calls to disable and re-enable >multitasking; I imagine this is because Commodore would rather provide >a system call than have people non-portably hack it when they need it, >but one doesn't need these calls in normal Amiga programming. Actually it can be necessary for normal programming, and Commodore does give examples of programming where it is necessary. If you need to play with any of the system lists, such as task lists, message ports, and you don't use Commodore supplied functions, you'll need forbid/disable. Also, if you are changing some pointers in your internal structures, such as your screen and windows structures, you have to make sure that it never leaves a usable state, otherwise you need to stop multitasking. -- Ethan "Don't forget the importance of the family. It begins with the family. We're not going to redefine the family. Everybody knows the definition of the family. ... A child. ... A mother. ... A father. There are other arrangements of the family, but that is a family and family values." -- Dan Quayle, of course. Our beloved Vice President. It's just too easy!
pswanson@umvlsi.ecs.umass.edu (Paul Swanson) (01/15/91)
In article <42498@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > >Yes, but aside from the disk formatting question, I don't know of many small >tasks that I can't do with my Mac while doing others. > How about this: Try playing tetris while a document is printing in the background. I tried this exactly once and found it to be quite irritating. Oh, and as for importance, if this were possible I bet it would be one of the biggest uses of multi-tasking on the MAC! Paul.
dege@cs.umn.edu (Dege Jeffrey Charles) (01/15/91)
In <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: >This discussion makes True Multitasking sound like the True Grail, or >True Love. There's an implicit value judgement there, and nobody >wants their machine to lack True Multitasking, even if they can't >agree on what that actually means. Let's abandon the term, and talk >about what actually happens. >My college OS textbook talks about "strict" and "non-strict" priority >systems for scheduling. A strict priority system never runs a >lower-priority task when a higher-priority task is runnable. Under a >non-strict scheme, lower-priority tasks get less time, but don't >starve. Both have their uses, but don't confuse them. It's because of this that the Amiga folks get so upset at the idea of Windows, Multi-finder, et al., calling themselves multi-tasking. Unix has a non-strict scheduling scheme, Amiga has a strict scheduling scheme, Windows and Multifinder are neither (the OS doesn't control scheduling, each application does that for itself.) In any case, it's the usefulness to the user that matters. Both Windows and Multifinder provide increased usefulness to their users. Beyond that, not much matters. --------------------------------
andy@cbmvax.commodore.com (Andy Finkel) (01/15/91)
.19816@ncsuvx.ncsu.edu> Sender: Reply-To: andy@cbmvax.commodore.com (Andy Finkel) Followup-To: Distribution: Organization: Commodore, West Chester, PA Keywords: In article <1991Jan14.200405.19816@ncsuvx.ncsu.edu> cocoiii@hobbes.ncsu.edu (John Vestal) writes: >difference between the two, if I have a compile that (for fun) takes >all of the CPU, and a shell running. The compile is one above the >shell. On AmigaDOS, the shell gets no time, until the compile is >done. On UNIX, the shell gets a certain percentage less then the >compile. It still gets some though. This is also how OS-9 works. Even without more complex methods such as task aging, generally the negative priority shell will get some CPU time on the Amiga when the compiler needs to do I/O. This will cause a task switch as the compiler waits for the I/O to complete. So, ever time the compiler Read()s or Write()s, other processes get a shot at the CPU. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
cocoiii@hobbes.ncsu.edu (John Vestal) (01/16/91)
burley@geech.ai.mit.edu (Craig Burley) writes: >"Aging" low-priority processes is a useful feature, especially in >multi-user systems, but it can be critical for a real-time system to >allow specification of priorities such that a low-priority task NEVER >executes as long as any higher-priority tasks do. >I think, therefore, when you say "it doesn't give up 'real-time response'", >you mean "real-time feel", either that or the real-time demands you're >placing on the system are loose enough that an occasional scheduling of >a non-real-time low-priority task doesn't hurt. No, I didn't make my self clear here. You can establish a minumim process priority that is not aged, and a maximum process priority that gets the CPU before other processes. However, only process that NEED this kind of response get it, and I can change whether it gets that time or not. In AmigaDOS, you don't tell the computer... it tells you. I prefer the flexiblity of having the "both of both worlds", ie. realtime if you need it, aging overwise. -- ****************************************************************************** * cocoiii@catt.ncsu.edu Phone: (919) 831-2890 North Carolina State * * John Vestal P.O. Box 21537 Raleigh, NC 27607 University * ******************************************************************************
yorkw@stable.ecn.purdue.edu (Willis F York) (01/16/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >Multitasking continues, however that screen is locked (any task doing output >to that screen is deferred) until you release that task. Programs that don't >output to that screen (either they have their own screen or they're smart and >spawned a task for display update) aren't affected. I've noticed somthing "Silly/odd/ect.." I was crunching some iff's with CRUNCH (By the Powerpacker guy) and the prograqm ticks off a %filedone %gained, in th cli. Works fine... BUT Say i ACCIDENTLY type a char in the cli window. (Without noticing it) the program will "pause" till i hit return or delete the chars... This Seems to be somthing that SHOULDEN't happen.... I seem to remember that programs like Lharc ignore stuff typed in and keep scrolling along.... Why does crunch act diffrently... (could it of been i was using a AREXX script to crunch a BUNCH of Pics) Just wondering..... Seems to "STOP" multiasking to me.... -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
torrie@cs.stanford.edu (Evan J Torrie) (01/16/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >> Get a new source for your Mac info. MultiFinder runs just fine on the >> Classic. >Hmmm, last time I checked Multifinder required a Mac-II. I'll have to go ^^^^^^^^^^^^^^^^^ Peter, Multifinder has NEVER required a Mac II. It runs fine on any Macintosh with 128K ROMs and >= 1MB of memory. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/16/91)
> [Does Amiga multitasking work when menus are held open, windows moved, etc?]
Yep, I just did a cat /etc/termcap on my terminal emulator, flopped
screens, grabbed and held open a menu, flipped screens, and the listing
kept coming through. I slid the terminal screen down, grabbed the screen
behind, and moved some windows and the screen around; you can see the
(blitter?) processor contention in a change of listing speed, but the
listing kept arriving.
I also hit a requestor on my terminal emulator screen by accident
(grabbed the wrong screen's menu), saw the text display pause while I
satisfied the requestor, then catch up in a gulp when the requestor went
away; the text still was arriving through the modem, but the separate
display task was paused to avoid overwriting the requestor (not, in this
case a true requestor, but just a prompt in the same window); despite
Mike Meyer, being able to spawn independent threads within a single
program _is_ an important part of "true" multitasking.
I'm really loving the Mac responses here "yes, you have to load things in
the right order or they don't work; no, that doesn't make the Mac OS load
order dependent"; talk about trying to bail water with a sieve!
Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>rwm@atronx.OCUnix.On.Ca (Russell McOrmond) (01/17/91)
In a message posted on 15 Jan 91 18:26:15 GMT,
yorkw@stable.ecn.purdue.edu (Willis F York) wrote:
WFY>Works fine... BUT Say i ACCIDENTLY type a char in the cli window.
WFY>(Without noticing it) the program will "pause" till i hit return
This is CON: or 1.3's NEWCON:
WFY>This Seems to be somthing that SHOULDEN't happen....
WFY>I seem to remember that programs like Lharc ignore stuff typed in
WFY>and keep scrolling along....
And this uses RAW:
Basicall, the consol hander can be put into a mode where it will accept 'LINES'
(IE: You have full delete/edit/etc ability - This is often called 'cooked' mode)
and a mode where it will accept characters exactly as typed (This is called RAW
mode).
The different modes have different reasons. The default, however, is Cooked when
you are using the normal consol handler.
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@Atronx.OCUnix.On.Ca {tigris,alzabo,...}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/18/91)
In article <BURLEY.91Jan15083631@geech.ai.mit.edu> burley@geech.ai.mit.edu (Craig Burley) writes: >In article <MWM.91Jan14120949@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > In article <7511@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > > I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be > > selective about what I launch). > > Whereas I can start up a bunch of applications in my 1.5M Amiga and could > care less what they are. > > Yeah - GNU Emacs works like a charm, and ADPro can handle some > _really_ large images in 1.5M. And AmigaVision runs alongside both of > those, just fine. Where did you say that beachfront property was, > Peter? > >Um, this seems stupid, pardon my english -- has ANYBODY gotten GNU Emacs to > run under Mac OS? I've got an 8MB SE/30, let me know!! You can find a version of GNU that runs on the Mac on many BBS systems... > >Meanwhile, the debate over image size is fascinating. On the Mac, the >problem is that an application must establish when it is started up how >much memory is to be set aside for it. Aside from temporary allocations >that can't be maintained and still task switch (as used by the Finder >when doing a floppy disk-to-disk copy so each disk need be inserted only >once during the copy), I don't think there's any way for a running app >to reliably say "hey, I need another .5MB after all, to deal with this >new file the user is opening". > >By "reliable" I don't mean "works even if you don't have the RAM [virtual >memory on applicable systems]" -- I mean "works if you have .5MB >contiguous memory available, even if it isn't contiguous with the application's >original image". I think the Mac OS does allow an application to extend >itself, however, if it has unallocated space beyond it, which would indeed >result in order-of-invocation requirements for users who intended to use >one of several simultaneously available applications in a manner that caused >it to have to extend itself (presumably by just opening lots of files or >inputting lots of data). I do recall seeing responses to complaints like >"my Mac says not enough memory, but the About Finder menu shows plenty of >memory, what's the deal?" saying things like "Quit all your applications, >start X up first, then start Y, then start Z, then reopen all your files, >and that will defragment the memory space". > >So my question is, does AmigaOS not require applications to live as >single, contiguous, preallocated chunks in memory? If this is the case, >then indeed the Amiga's memory management seems superior for this >situation. Order of application invocation would not be nearly as important >(or at all important) as it is on the Mac. Of course, sloppily coded >applications that fragment memory, or really bizarre usage of well-coded >applications, could still result in situations where a request for more >memory failed due to more than enough memory being overly fragmented. But >on the Mac, that situation is, I believe, fairly easy for an ordinary user >to encounter while using solid applications. > The AmigaOS supports "scatter" loading of executables which allows an application to NOT bet a single contiguous chunk. This is particulary valuable because of the fragmentation that can occur (parts of programs can load into whatever fragments are available). Memory fragmentation does not really become a problem until you get into low memory situations, which for me (a power user) is practically never. >The Mac OS doesn't make any gains as far as I've been able to analyze in >requiring monolithic application memory images -- it appears to be due to >the original approach of one application at a time (which I call "Unifinder"). >Too many apps, plus the OS interface and mechanisms, made this assumption >for Multifinder to change it. A big win for system 7, virtual memory (on >systems that support it), will allow Mac users to increase the declared >amount of memory each app needs without actually taking up that much RAM, >unless they really need it. I don't think system 7 does away with the >monolithic address space per app, however; I might be wrong. In any case, >this is another example of how the Mac OS' history (and requirements for >backwards compatibility) as a non-multitasking system has crippled its >a dvances somewhat. > virtual memory should be interesting on the Mac. When you click on a window to bring it to the front, you are going to have to SWAP lots of code in and out just to refresh all those applications' windows. On a machine that already has a hard time being fast at refreshing the screen, it is not going to be better, even if you have a 1 Gigahertz 68090 (one of these days!). >Note that Microsoft Excel required special code in Multifinder until a >fairly recent release (I think Apple recently removed this special code >due to this release) that allowed an application to indicate that not >only did it need to reserve <x> MB, but it needed to have live at a >particular place in memory. I don't know whether this meant users had >to invoke Excel first to make sure it got its desired absolute addresses >or Multifinder simply avoided loading any other apps into that area of >memory if Excel was hanging around (which, I think, it could detect due >to the Mac's informative file system). Also, Excel was limited to 1MB >up until this (or a nearby) version. >-- > >James Craig Burley, Software Craftsperson burley@ai.mit.edu
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/18/91)
In article <1991Jan14.200405.19816@ncsuvx.ncsu.edu> cocoiii@hobbes.ncsu.edu (John Vestal) writes: > > I've been watching this very interesting discussion about >multitasking, and would like to make a few comments. I don't know >about how the kernals in MAC OS, AmigaDOS, OS/2, UNIX, or OS-9 work, but >I've used them all but OS/2. The Mac does a decent job of 'kludging >multitasking'. You can't (or I haven't found a way) of changing tasks >priority's on the Mac though. AmigaDOS does multitasking very >smoothly, but I have seen (mainly games) that will not let anything >else run. Well, at least not get too them, I don't know that they >aren't running, but to me they're not there. If you change a very CPU >intensive task to a higher priority, other tasks can 'stop'. On UNIX >you can run a lot of programs and you can never 'stop' a process, >without killing it, or setting it's priority as low as possible. The >difference between the two, if I have a compile that (for fun) takes >all of the CPU, and a shell running. The compile is one above the >shell. On AmigaDOS, the shell gets no time, until the compile is >done. On UNIX, the shell gets a certain percentage less then the >compile. It still gets some though. This is also how OS-9 works. >Tasks age, and after they are so old, according to the priority, they >get a CPU cycle. They also get any 'leftover' CPU, but AmigaDOS does >this too. Now, for me as a user, I want any process that I am running >to get some time. I should tell it at least how often I want it to >run. It can run more often, but at least this often. OS-9 does this, >and it doen't give up 'real-time response'. As a matter for fact, it >the OS of choice for realtime work. At least from what I've seen and >heard. Anyway that's my 2 cents worth. > > cocoiii (John Vestal) >-- >****************************************************************************** >* cocoiii@catt.ncsu.edu Phone: (919) 831-2890 North Carolina State * >* John Vestal P.O. Box 21537 Raleigh, NC 27607 University * >****************************************************************************** Games on the Amiga shouldn't multitask if they need speed (i.e. high speed animation, etc.) because the normal overhead of a multitasking system is enough to steal a lot of your CPU time. Also, games for the Amiga need to run on a 512K Amiga 500 (the most popular Amiga) and there typically is not even room for the OS and a decent sized game (or the game would suffer). Also, games are pirated heavily, and in a multitasking environment it is easy to run a debugger and the game at the same time and patch out copy protection and other forms of protection. Also, many of the images and sounds in a game are copyrighted or licensed material and hackers have no business gaining access to them. As far as the Amiga tasking system and high priority tasks stealing all the CPU time... When you write a program for the machine, you can decide what priority your program and its associated tasks run at. It is considered POOR programming practice to hog the CPU in any way shape or form. However, if you really want to do some CPU intensive processing at a high priority, you do have the power to do it. And there are some cases when it is desireable, like when refreshing your editor's screen. This can make the editor seem much more responsive, even though it can slow down that compilation you have going in the background. But the machine responds immediately to user input, which can be very user friendly. mykes
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/18/91)
In article <1991Jan15.215259.14232@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: >>> Get a new source for your Mac info. MultiFinder runs just fine on the >>> Classic. > >>Hmmm, last time I checked Multifinder required a Mac-II. I'll have to go > ^^^^^^^^^^^^^^^^^ > > Peter, Multifinder has NEVER required a Mac II. It runs fine on any >Macintosh with 128K ROMs and >= 1MB of memory. > > > >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >"I didn't get where I am today without knowing a good deal when I see one, > Reggie." "Yes, C.J." A more realistic fact is that Multifinder requires 2MB to run 2 applications (in the general case) at once.
new@ee.udel.edu (Darren New) (01/19/91)
In article <7536@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >That's how the console device supports typeahead without getting output mixed >up with input: when you type in the screen it blocks output until you enter >a whole line. Other programs are not effected. I thought it was kind of >clever, actually. I prefer the method used in CP-V, namely that the input you type ahead does not echo until it is read. Looking at a hardcopy or a screen, you cant tell whether any given character was typed ahead or not. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
nsw@cbnewsm.att.com (Neil Weinstock) (01/19/91)
In article <7523@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <BURLEY.91Jan14110925@geech.ai.mit.edu> burley@geech.ai.mit.edu (Craig Burley) writes: >> Anyone care to post whether this kind of scenario works on the Amiga? I.e. >> when holding a menu down, or doing other purely user-interface things that >> aren't inherently resource intensive (like just holding a mouse button >> down without moving the mouse), does true multitasking keep working? >> My guess would be yes, it does. > >Multitasking continues, however that screen is locked (any task doing output >to that screen is deferred) until you release that task. Programs that don't >output to that screen (either they have their own screen or they're smart and >spawned a task for display update) aren't affected. Then again, for specialized applications, you can use dual-playfield mode, and the menus can work at the same time as the rest of the screen. My Asteroids program (which I really oughtta get in shape for distribution one of these days) uses the top playfield for Intuition, and does the animation on the bottom. When you pull up a menu, the animation continues without missing a beat, right underneath the menus. The background of the menus is also transparent, so you see the rocks floating around behind the menus. It's a great multitasking example, apart from being flat-out cool. - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
farren@well.sf.ca.us (Mike Farren) (01/21/91)
mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >Games on the Amiga shouldn't multitask if they need speed (i.e. high speed >animation, etc.) because the normal overhead of a multitasking system is >enough to steal a lot of your CPU time. Bullshit. There might be occasions where you don't want full multitasking to run, but there is so seldom a reason to kill multitasking entirely that I tend towards believing it's NEVER absolutely necessary. The "normal overhead" is damned small. >Also, games for the Amiga need to run on a 512K Amiga 500 (the most popular >Amiga) and there typically is not even room for the OS and a decent sized >game (or the game would suffer). More bullshit. There's a LOT of room for a game in a standard A500. A game which needs the full 512K is, IMHO, a badly-designed game. >Also, games are pirated heavily, and in a multitasking environment it is >easy to run a debugger and the game at the same time and patch out copy >protection and other forms of protection. Total bullshit, on at least two different levels. Multitasking has NOTHING to do with running debuggers - they're DESIGNED to run simultaneously with the program they're debugging. And all claims that copy protection is necessary are, as far as I'm concerned, bullshit on the face of it. >Also, many of the images and sounds in a game are copyrighted or licensed >material and hackers have no business gaining access to them. Absolute total bullshit and ignorance of what a copyright IS. The copyright only prevents one from gaining profit from other's work - it does not prevent possession of that work in any way. And all of this from someone who claims to be a hot-shot Amiga game programmer... For further details on these and other flames, see the last few months of comp.sys.amiga.games. -- Mike Farren farren@well.sf.ca.us
dvljhg@cs.umu.se (J|rgen Holmberg) (01/22/91)
In article <22782@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >>Games on the Amiga shouldn't multitask if they need speed (i.e. high speed >>animation, etc.) because the normal overhead of a multitasking system is >>enough to steal a lot of your CPU time. > >Bullshit. There might be occasions where you don't want full multitasking >to run, but there is so seldom a reason to kill multitasking entirely that >I tend towards believing it's NEVER absolutely necessary. The "normal >overhead" is damned small. > Face it! Most european games manufacturers don't give a damn about multitasking. They want their game finished as soon as possible to make the most money! Turning off multitasking makes programming easier for everyone and hence the game will be finished faster. The fact that a fair number of game programmers can't really program anything but hardware. >>Also, games for the Amiga need to run on a 512K Amiga 500 (the most popular >>Amiga) and there typically is not even room for the OS and a decent sized >>game (or the game would suffer). > >More bullshit. There's a LOT of room for a game in a standard A500. A >game which needs the full 512K is, IMHO, a badly-designed game. > It depends on the amount of graphics and music in the game. >>Also, games are pirated heavily, and in a multitasking environment it is >>easy to run a debugger and the game at the same time and patch out copy >>protection and other forms of protection. > >Total bullshit, on at least two different levels. Multitasking has NOTHING >to do with running debuggers - they're DESIGNED to run simultaneously with >the program they're debugging. And all claims that copy protection is >necessary are, as far as I'm concerned, bullshit on the face of it. > I agree that copyprotection should be abolished, that would be the first step towards stopping organized piracy. As for debuggers, have you heard of cartridges? If you really want to you can always crack a game. > >>Also, many of the images and sounds in a game are copyrighted or licensed >>material and hackers have no business gaining access to them. > >Absolute total bullshit and ignorance of what a copyright IS. The >copyright only prevents one from gaining profit from other's work - it >does not prevent possession of that work in any way. > This is posted to sites all over the world, state which copyright laws you mean. If the new european laws are passed we will not be allowed to do anything really At the moment you can use samples freely in any country. Stealing is so common in the music industry that the only thing that is protected is the finished song on whatever media it's recorded. >And all of this from someone who claims to be a hot-shot Amiga game >programmer... For further details on these and other flames, see the >last few months of comp.sys.amiga.games. > >-- >Mike Farren farren@well.sf.ca.us US-Gold and others also employ "hot shot game programmers", personally I wouldn't be caught dead doing software that is that bad! /Jorgen -- ******************************************************************************* email dvljhg@cs.umu.se - other ways to communicate are a waste of time. Everything I say is always true, just apply it to the right reality. "Credo, quia absurdum est." Credo in absurdum est?
farren@well.sf.ca.us (Mike Farren) (01/22/91)
I, my curmudgeonly self, wrote a whole bunch of stuff about games, followed by: >And all of this from someone who claims to be a hot-shot Amiga game >programmer... which was a gratuitous and unnecessary cheap shot at Mike Schwartz, for which I apologize. The rest of my statements I stand behind. -- Mike Farren farren@well.sf.ca.us
DXB132@psuvm.psu.edu (01/24/91)
>More bullshit. There's a LOT of room for a game in a standard A500. A >game which needs the full 512K is, IMHO, a badly-designed game. I disagree strongly with this. A lot of effort is wasted in squeezing games into 512K (and you suggest using even less memory) which does nothing but degrade the quality of the game and it make it much less likely that I will buy it. It doesn't take a genius to figure out that people with no money to spend on a little memory aren't going to buy hundreds of dollars worth of games. People with money buy games. People with money have plenty of memory. At least this is my experience! >the program they're debugging. And all claims that copy protection is >necessary are, as far as I'm concerned, bullshit on the face of it. >And all of this from someone who claims to be a hot-shot Amiga game >programmer... For further details on these and other flames, see the He IS a hot shot programmer, just one with different opinions. -- Dan Babcock
farren@well.sf.ca.us (Mike Farren) (01/24/91)
mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >To program the hardware, you only need to learn 10 pages in the hardware >manual. To program under the operating system, it takes years of experience >and a bunch of banging your head against the wall figuring out why the examples >in the thousands of pages of OS manuals don't work when you type them in. Well, that's a good argument for using examples from the net, or examples from the new RKMs. Yes, many of the old examples did not work. That is not the case any longer. >Then there is the story that Richard Hicks, one of developers of Artic Fox >for Electronic Arts told me. He said that they never could figure out where >all the CPU time was going on the machine. It turns out that if they killed >multitasking, their code would have run at least 2 times faster. These are >words from his mouth. In my experience, those words are the words of inexperience or ignorance. It isn't that hard to make things go fast on this system. >I don't like to cut anything from the design of the game, >especially for the sake of the operating system which does NOTHING for the >game. So who says you have to? You make comparisons with Mac games, which BY THEIR VERY NATURE do not reside in a 512K system. Resource forks, remember? Stuff kept on disk until it's needed, and loaded as required. Seems to work pretty well there - and works pretty well the times I've tried it. If you don't want to use the OS, don't. I don't care, the OS doesn't care. All I'm asking is that you don't trash it for all the other applications unless you absolutely have to - and I STILL haven't seen any convincing example of having to. >However, I do think that many normally honest people will pirate software >if all they have to do is make a diskcopy using standard OS tools. Perhaps. I still haven't seen any hard evidence that this is a significant factor in low sales, though. >Insulting me goes a long way toward making me change my mind! Awesome debating >tactic dude! Yeah, radical, wasn't it :-) -- Mike Farren farren@well.sf.ca.us
jms@vanth.UUCP (Jim Shaffer) (01/27/91)
In article <7536@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <yorkw.663963975@stable.ecn.purdue.edu>, yorkw@stable.ecn.purdue.edu (Willis F York) writes: >> Works fine... BUT Say i ACCIDENTLY type a char in the cli window. >> (Without noticing it) the program will "pause" till i hit return >> or delete the chars... > >That's how the console device supports typeahead without getting output mixed >up with input: when you type in the screen it blocks output until you enter >a whole line. Other programs are not effected. I thought it was kind of >clever, actually. Well, just to get the other viewpoint in here, I thought it was kind of stupid, actually. One configuration of ConMan will give you INVISIBLE, non-blocking typeahead (i.e., it holds typed characters internally until nothing is outputting), and that's what I use for all my shell windows. ConMan in ANY configuration, if I remember rightly, will also give you ^S/^Q to pause and restart the display. (You know, the industry standards?) -- From the disk of: | jms@vanth.uucp | "Glittering prizes and Jim Shaffer, Jr. | amix.commodore.com!vanth!jms | endless compromises 37 Brook Street | 72750.2335@compuserve.com | shatter the illusion of Montgomery, PA 17752 | (CompuServe as a last resort)| integrity!" (Rush)
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
In article <MWM.91Jan14120949@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > Yeah - GNU Emacs works like a charm, and ADPro can handle some > _really_ large images in 1.5M. And AmigaVision runs alongside both of > those, just fine. Where did you say that beachfront property was, > Peter? I stand by what I said. I can run all the apps I want without worrying about which order I load them or what is going to conflict with what. Of course you're gonna get applications that don't even run *once* in 1.5 Meg. There are always people out there writing oversized, overrated, and underdesigned programs. And people willing to buy more and more RAM to run them. I'm quite happy with Digipaint, Sculpt, Manx C, etcetera. And even if AmigaVision ran on my 3000 it's no use to me... there's no separate runtime that'll fit on my 1000, so I can't use it to write stuff for my son. For me Amigavision was worth every penny I spent on it. Lucky it was free... Anyone got any suggestions for a *small* multimedia authoring program? In any case, this thread does not belong in .misc, but rather in .advocacy. How about leaving it there this time? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
In article <1991Jan22.033011.21457@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > I might also point out that AmigaWorld's #1 game of last year was > a European title, Shadow of the Beast, which I would hardly say was a quick > and easy program to do. I find it difficult to play, but not impossible. I don't know... the only guy I know who hasn't given up on it has been using the immortality hack. > I agree 100%. I don't like to cut anything from the design of the game, > especially for the sake of the operating system which does NOTHING for the > game. Sure does. Lets the game run on a 3000, to begin with. In fact I'd love a few decent ports of some of the old 8-bit games. You know, where they couldn't sell the sizzle but instead had to make the game itself attractive. You'll get a lot more playing time out of a good, simple, playable game like Tracers than a fancy, visually exciting, but unplayable game like anything Psygnosis has produced thus far. > I agree, too, and it seems as if a lot of publishers are going to off-disk > protection (look up a word in the manual, please). I have one game that uses "look up a word on the box" protection. I couldn't believe it! How many people keep the game packaging? > Honest people typically don't buy the cartridge devices you are talking > about. I don't know... I'm thinking of it. I've spent enough on $10 a pop replacement disks from Accolade to pay for it. Does anyone know if these replacements show up on the author's royalty statements? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
Please... if you have to post to inappropriate groups at least direct followups somewhere better? In article <1991Jan23.094943.9336@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > Rubbish! The OS steals around 100k, depending > on how many devices are attached, buffers etc. It is VERY tight getting > a game to fit in 512k! You usually have to page stuff off the > disk... Then you've probably written too much code. (god, once upon a time people actually write some fairly impressive programs on the Apple-II with only 48K available, and much of that taken up in the hi-res screen... how quickly we become spoiled) Let me just say that I *will* buy games that are less than balls-to-the-wall so long as they will run nicely. *AND* playability is given priority. > Yep. And you need lots of that nowdays. Yep. Gotta keep people from noticing that some clone of "Galaxians" is almost unplayable for anyone over 15. Oh well, at least this did force me to keep my 1000 when I got my 3000. Got too many badly behaved games to think of getting rid of it, and it *has* come in handy. :-< -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
melling@cs.psu.edu (Michael D Mellinger) (05/04/91)
In article <42459@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >of applications in a 2 Meg machine. Ask why the mouse is moving funny. Have him I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be selective about what I launch). How about Word 4, Excel, and HyperCard? Not an unreasonable request since they are bread and butter apps. System 7 will allow IAC, so one should be able to do useful things with these three programs. Actually, IAC should allow for a lot of "neat" things. I'll need Word 4, PageMaker, and Illustrator open at once. >try to do anything useful while formatting a disk. Ask him why he can't run Yeah, that is a substantial criticism. I mean really, how OFTEN do you need to format a disk? It is nifty to be able to do so and run another task, but it just as easy to format a bunch at once and then go back to work. Ok, how about copying files b/w floppies, or backing up your hard disk to floppies? >multifinder on a Mac Classic. Get a new source for your Mac info. MultiFinder runs just fine on the Classic. How well does System 7 run? -Mike
torrie@cs.stanford.edu (Evan Torrie) (05/14/91)
new@ee.udel.edu (Darren New) writes: >In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: >>A Mac running the Multifinder has non-preemptive multitasking; each >>task voluntarily gives up control. The Amiga does preemptive >>multitasking; a task may be stopped at any time. >It's worse than this. Try starting up multifinder, hypercard, and >(say) tetris. I just did this last night because I wanted to play >tetris but the owner of the machine had the hypercard stack open. >Anyway, the music was all messed up and the blocks fell at different >speeds, making it difficult to play. I then realised that hypercard >must be sucking up CPU time even though it was not active, it was not >running anything, and the mouse was not near the window. ^^^^^^^^^^^^^^^^ Actually, Hypercard is always running something, even when it's sitting in the background. The reason? Hypercard sends "idle" messages to the current chain of control in its object hierarchy when nothing is happening. This allows fields/cards/stacks to perform actions even when nothing is happening. A good example of this is the "Display time continuously" field in the Readymade fields example of HC 2.0. Plunk it in the background, and you'll see that the time continues to update, indicating that the idle message is getting send to the card, which then sends a message to the field, which then updates itself. Since all of this action is via interpreted scripts, HC can quite easily chew up a fair amount of CPU time. >[rest of good expose of cooperative multitasking deleted] -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Where can a nation lie when it hides its organic minds in a cellar dark and grim? They must be ... very dim.