🚀 go-pugleaf

In article <3224@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>In article <10811@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes:
>> In article <3206@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>> >Masscomp uses an exotic dual-processor system to achieve real-time.
>
>> Peter's statements are incorrect. Our MC500 has only one CPU, a 68010,
>
>Then Masscomp's published literature is incorrect. I'll have to check this
>out. Either we have different ideas of what "real-time" means, or they
>haven't been telling us everything.

As I understand our masscomp, there is only one CPU running unix (actually
masscomp's Real-Time-Unix); this is a 68020 or variant. The real-time
unix has provisions for upping job priority and page locking. However,
the trick is that an auxiliary bus, with its own 680x0 cpu, called
the DACP (Data Acq Ctrl Proc), handles the things you consider
to be time critical, like polling lab devices, starting/stopping
clocks etc. The DACP is a dedicated data collection CPU and
must be programmed in assembly.

So.. If you want to send out a sine wave, you fill a buffer up in
your locked process's memory and then start up the DACP and then
sleep until the DACP is finished. The DACP grabs the buffer in
pieces via DMA and feeds it to the D/A converter; of course a
similar process is involved for incomming data.

Two things: (1) I've simplified a bit - I've found that programming this
beast is far more complicated than it sounds and (2) You can actually
have multiple Unix CPU's in some configurations which share the Unix
process load - but they have nothing to do with Real-Time issues,
they just increase the through-put of the Unix tasks.

Sorry if this trip into the guts of a masscomp was slightly
off track..
/Jamie
  UUCP: {rutgers,ames}!cit-vax!bek-owl!mazer
  ARPA: mazer@bek-owl.caltech.edu
BITNET: jmazer@caltech.bitnet      "There's no Elvis in Michael J. Fox."