ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (08/26/87)
[ Someone hand me the Pepto Bismol... ]
My dear children,
Do you realize that, since these miserable arguments started,
technical contributions have dropped to near ZERO? Go over about the last
300 articles and you'll see what I mean.
Now, let me see if I can finish off these arguments once and for all
(he said, donning cape, drawing magic wand, and allowing his most warped
thinking processes to surface):
Macintosh MultiFinder
---------------------
There has been very little technical discussion about the new
MultiFinder from Apple, just opinions and flames. As such, without solid
information, it is impossible to properly comment on the issue. So why have
you been bothering?
As it has been presented here, programs under MultiFinder
voluntarily relinquish control of the CPU to allow other programs, should
they exist, to run. This implies that, if a program decides not to
relinquish the CPU, no other program, including the finder, will run.
Assuming this is true, thus pretty much sinks any claims anyone may
try to make about MultiFinder being multitasking. If you start a program
that refuses (or merely neglects) to relinquish the CPU, then you won't be
able to re-activate the finder to start another program. Ergo,
single-tasking.
This scenario seems patently ridiculous to me, so there must be
something we don't know about MultiFinder's operation. Let's adopt a wait-
and-see attitude, shall we? Amiga won't lose its edge *that* quickly...
Amiga Exec
----------
Ever get the feeling no one except you understands what's going on?
Like everyone's jousting with evil dragons, but only you can see that it's
really a windmill?
Exec is *NOT* UNIX. Exec is not **]] ANYTHING ELSE [[** except
Exec. Exec was designed to interfere with running programs *as little as
possible*. As such, it sports a very fast response time. Its philosophy is
as follows:
For all loaded tasks: If a given task is waiting for some event
(signal) to occur, then it takes *NO* CPU time. It sits in the wait queue
until some other task signals it, at which time, Exec will schedule it.
Until this happens, however, Exec *IGNORES* this task.
If a task is ready to run, Exec checks its priority and compares it
with the priorities of all other ready tasks. If this task is *THE ONLY
TASK* with the highest priority, Exec runs it and does not interrupt it
further. Thus, this task will get all of the CPU. This task will be
pre-empted *ONLY* if another higher-priority task becomes ready to run.
If multiple tasks share the same (highest) priority, then Exec
schedules them round-robin. I believe the quantum is 1/30 of a second (one
video frame). This scheduling is pre-emptive.
For all running tasks, a task may choose to wait for some event
(keystroke, mouse movement, disk block, etc.). If a task chooses to do
this, Exec stops the task and drops it in the wait queue. It then applies
the previous rules to all remaining ready tasks, deciding which one to start
running. If there *are* no ready tasks, Exec HALTs the CPU, keeping it off
the bus (letting the custom chips reign freely). Only an interrupt will
start things up again.
From this, it is easy to determine what priorities tasks should be
assigned. Interactive tasks should get the highest priority (since they
will spend most of their "time" waiting for user actions), while CPU-bound
tasks should get lower priorities.
By logical extension, if a program "knows" that it is about to enter
a long CPU-bound operation, it should voluntarily drop its priority a notch
or two to allow other (hopefully interactive) tasks more CPU time so that
they will continue to be responsive. To my knowledge, no Amiga programs
currently do this (though it would be nice if they did). A prime candidate
for such priority shifting activity would be spreadsheets.
ISSUE: WorkBench disk objects (#?.info files) should have a field
specifying the priority the task should be assigned on startup.
Note: I'm not trying to display a holier-than-thou attitude here.
But I like to think that I understand the philosophy and basis on which Exec
was designed. Judging by some of the "priority fudging" algorithms and
programs people have put forth for the Amiga, I begin to seriously wonder if
these people share the same understanding I have.
It is my contention that, if you carefully consider the context in
which your program will be used, you can select a priority for it that will
integrate well with the other programs that may be running. If your
program's needs change depending on what it's doing, consider fudging your
own priority to leave room for everyone else, or to increase your
responsiveness.
My Robotroff program has a facility to allow the user to change
Robotroff's priority at any time. While designing the program, I tried to
consider all possible scenarios where Robotroff might be active. Robotroff
could conceiveably activate while DPaint was running. Since DPaint is a CPU
hog (and Robotroff isn't), it would make sense to allow the user to bump
Robotroff's priority to 1 so its performace wouldn't degrade. But normally,
0 is sufficient. The point is, I put the option in because I knew it might
be an issue with some users.
But PLEASE!! Don't fudge with someone else's priority. I'll close
this topic with three good reasons why you should not do this:
1: You don't know what the other application is, and thus are not
in a position to dictate what its priority should be. Suppose
it's the Facc ][ interface. What's the point of bumping its
priority up? Just because the user activated its window doesn't
mean that it needs more CPU.
2: If this were a memory-protected system, this would be a definite
no-no. You'd be blown out of the water very quickly.
3: It's not nice. The Amiga is a "social" machine. All programs
assume that all other programs will be nice and obey all the
rules. Changing everyone else's priority behind their backs is
very anti-social.
MIDI
----
As I understand it, all you need to do MIDI is a serial port that
will run fast enough, and some level conversion hadrware. This pretty much
inidcates to me that *ANY* computer can do MIDI, from a Timex-Sinclair to a
Cray 2. What really counts is the MIDI control software running on the
computer in question.
From my information, software for the Macintosh wins this
competition hands down. However, the fact that the Atari has the standard
MIDI connector (so you can plug your cable in directly) is a nice win. Note
that that's *ALL* it is: a nice win. The value of this connector is only in
direct proportion to the quality of the software that uses it. Since I'm
not a musician by any stretch of the imagination, I can't comment on Atari
MIDI software.
However, it should be recognized that just because the Atari ST
sports a MIDI connector does not automatically make it the ideal MIDI
controlling system; that is a software issue.
My Computer Is Better Than Your Computer
----------------------------------------
Oh, please. Must we go through this again? I mean, if I *really*
wanted to, I could convince you about how my SOL-20 is better than all this
new stuff.
EnableSmiley ();
The SOL-20 is driven by a 2 MHz 8080 CPU. Instruction for
instruction, this beats the stuffing out of a 6502 (and therefore, the
Apple ][ series). The five slot S-100 backplane allows almost infinite
expansion possibilities.
The text screen is 64 x 16. This is actually quite good, since it's
easier to program (multiplying by 64 is tons easier than multiplying by 80),
and the screen memory is *exactly* 1K, meaning there are no wasted bytes.
The operating system is SOLOS, a monitor ROM, which allows
inspection and entry of raw memory bytes. It also will load and save raw
memory images to and from either of the two cassette ports. SOLOS resides
on a removeable "Personality Module", which means you can change it to
anything you like. Thus, you're not locked into SOLOS if you don't want to
be.
SOLOS will also allow you to transfer control of the computer to an
external terminal keyboard, through either the parallel or serial port.
Thus, you can remotely control your computer via modem (your printer can
also take it over if you want it to). And, SOLOS has a terminal emulator
built-in, so you have no need to purchase a terminal program.
The SOL-20 keyboard is fully-featured. You can assert true RESET
from the keyboard, as well as a true serial BREAK. The keyboard can
generate all 128 ASCII codes, as well as a few special one-character codes
(high bit set). The keyboard also features a numeric keypad, with "+", "-",
"*", "/", and "." keys.
The machine is also very stylish, sporting real solid walnut
end-panels, and an attractive and sturdy blue metal case that is easily
removed.
Clearly, a machine this well thought-out is better than anything
else on the planet.
DisableSmiley ();
The point of the above diatribe is that you can make *any* computer
sound like the best thing since sliced bread. We really ought to have a
group called "talk.comp.compare" or something so we (I) can ignore this
crud.
Pixar
-----
Okay, I know I started this one but it seems to be taking on a life
of its own, which I don't need.
I'm perfectly happy with the situation as it stands now. Think
about it for a moment: If all the controversey were to end tomorrow, I
would still be sitting in a very nice position. By involving themselves,
Pixar has elevated my credibility as a graphics hacker to undreamed-of
levels. I have also accomplished something I've always wanted to have
happen: to have Pixar notice me. Granted, it wasn't under the best of
circumstances, but at least they are now aware of my abilities as a computer
graphic animator and general creative guy, which is something I've wanted
for a while. So there.
Epilogue
--------
Now that we've covered everything, can we please move on to
something more interesting? The signal-to-noise ratio has been dipping
below zero of late.....
I have my asbestos cape on, and my mailbox is prepared...
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\
\_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac
O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor