🚀 go-pugleaf

Excerpts from netnews.comp.sys.next.hardware: 6-Nov-92 Re: New RISC
workstations /.. Doug DeJulio@cs.cmu.edu (975)

>I'd buy this argument *IF* NeXT's OS had good realtime support.
>However Mach 2.0 (upon which NeXT mach is based) is just not a
>realtime OS, and you can't do realtime operations with it.  User
>interaction needs to be done by realtime tasks.  That's the main
>reason I was reccomending dedicated chips.  No realtime means no
>reliable synched animation and sound, which sucks on a multimedia
>workstation.

You can do reasonable realtime operations (such as animation) under the
current Mach kernel (Version 2.6 on NeXTs, I believe).  Try looking at
the DPSTimedEntry stuff.  There are examples from NeXT where at each
frame, the animation code checks the actual time delay from the last
frame, and generates the next frame accordingly.  This means that the
frame rate is not constant, but animated objects have constant velocity
and could be sync'ed reliably with sound.  This is generally acceptable
if the CPU(s) can generate a reasonable frame rate considering the other
loads on the system.

But I can't argue that dedicating processing units (like the DSP for
sound generation, or whatever) does not provide advantages for realtime
processing, too.

>If NeXT upgraded to Mach 3, perhaps they could get realtime
>performance by running the display and sound servers at a higher
>priority than the Unix emulation task, but in Mach 2 the unix
>emulation is built into the Mach kernel so that can't be done.
>Correct me if I'm wrong.

"Unix emulation task"?  What are you referring to?  The Mach kernel does
handle system traps (the functions described in "man 2 intro") for
processes, exactly like any other kernel, and I don't see this changing
under Mach 3.x.  Mach provides these functions because a standard unix
kernel provides these functions; programs written for another unix
machine work on the NeXT without modification because the Mach kernel
provides the exactly same functionality.  This compatibility is one of
the most important features of Mach.

Admittedly, Mach implements things internally differently than most
other unix kernels.  For example, all IPC calls are implemented as
special cases of a generic Mach message facility, where in other
kernels, there are generally different internal structures used for
pipes, semaphores, sockets, etc.  Mach frees the programmer from
worrying about which representation is most efficient (IMHO good).  I
have heard that Mach 3.x makes even more internal changes than Mach 2.6,
which means that certain parts of the OS, like the terminal drivers,
should be modified (for efficiency reasons) under Mach 3.x.

But, so what?  You seem to claim that Mach 3.x offers better support for
realtime processing than Mach 2.6.  I don't understand what information
you're using to make this claim; please explain.

-Chuck

+---------------------------------------------+ 
|  Charles William Swiger -- CMU sucks rocks  | "The television screen is the
|   AMS & normal mail: cs4w+@andrew.cmu.edu   | retina of the mind's eye."
|    NeXTmail: <temporarily out of order>     |           
+---------------------------------------------+            --Videodrome