Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!mindseye!izumi
From: izumi@mindseye.berkeley.edu (Izumi Ohzawa)
Newsgroups: comp.sys.next
Subject: Re: real-time applications on 040 cube
Message-ID: <1991Mar29.190903.23196@agate.berkeley.edu>
Date: 29 Mar 91 19:09:03 GMT
References: <1991Mar27.082322.27952@news.cs.indiana.edu> <91086.222234DWN2@psuvm.psu.edu> <2122@kgw2.Xetron.COM>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: /etc/organization
Lines: 31

In article <2122@kgw2.Xetron.COM> dennisg@Xetron.COM writes:
>
>with the limitation of +/- 1ms i would say:  no.
>
>what i did was develop a devide that performed the time critical stuff
>then interacted with the NeXT through a serial interface.  in this fashion
>my real-time constraints were met and the NeXT could do the heavy processing.

I would say no too.
NeXTdimension, with right hooks, should be able to do
animation with guaranteed timing accuracy down to frame period.
I don't know if there will be such hooks in the Appkit timed
entry functions.  On ohter systems which use 040 for display
handling, there's no way you can guarantee that sort of timing.

Have your PC or Mac generate visual stimuli at timing resolutions
upto the frame rate.  Let them also generate trigger pulses
on a digital I/O line, feed that to the DSP port along
with other events such as button presses through
a multiplexer.  DSP chip can run a clock which time stamps
these incoming events.  Your NeXTstep app can then receive
these buffered events whenever it can.

Parameters for the visual display can be sent down the serial
line to the PC or Mac as Dennis suggest.


Izumi Ohzawa             [ $@Bg_78^=;(J ]
USMail: University of California, 360 Minor Hall, Berkeley, CA 94720
Telephone: (415) 642-6440             Fax:  (415) 642-3323
Internet: izumi@violet.berkeley.edu   NeXTmail: izumi@pinoko.berkeley.edu