Ross has us entralled!  I for one must ask:  "What on earth are you
going to do with a 4 to 20mA current-encoded panic analog?"

  Goes rather against the grain of we "digital types"!  I«m not
complaining, you understand, just curious!  Have you considered a digital 
implementation of the output device?

> I am a newbie to the world of PIC devices having a distant history with
> the 6809 family.

  Hey, that«s aristocracy!  By no means a novice!

> I have not yet chosen a device or indeed a programming/development
> environment so any input, without causing a "mine is better than yours"
> type war, would also be appreciated.

  It gets down to three features: Price, Availability and Capability, as
a matter of fact, in that order!  It appears at present, that the PIC
devices win out.  68HC11s (developed from the the 6809 you mentioned, and
therefore my preference) just haven«t "arrived" on these criteria,
particularly the first two.  PICs have, and we are seeing, particularly
in the 16C84, an explosion in popularity where popular use spawns cheap
programming adaptors, making them even more popular etc.  Motorola has
devices in the 65HC05/ 68HC11 line every bit as easy to use and support,
but CAN YOU BUY THEM?

> There is no synchronisation of serial comms between any of the 4
> instruments.

  If you intend to interleave the input and output processing, you must
needs use a(n interrupt-driven) state machine UART sampling at three or
four times the bitrate.  Such an implementation was as I recall, used
in the TRS-80 Micro Color Computer (based on the 6803 which is of course
essentially the 6811).  While this device is rather antique now, it would
be folly to assume that algorithms have somehow become more "modern" in
the interim!

  As it is however said that the PIC architecture is more efficient, it
is reasonable to expect to implement this state machine common to four
channels with say, a 4MHz (crystal) clock, with a common sampling "tick"
at 3600 or 4800 interrupts per second reading simultaneously the four
inputs and processing them in turn, thus avoiding any slew introduced by
different processing times for different state values.

  The usual approach would be to perform the UART functions under
interrupt drive to the point of presenting received characters to a
buffer (albeit a small one - two characters each perhaps?), which the
mainline code proceeds to search for significant events.

> These outputs would then be fed to a small combination of say 4585 4-
> bit magnitude comparators ...

  NOT the way to go!  If you«re using one or more PICs, use their logic
to get the maximum.  At worst, use four simple DACs and four DIODES to
get the largest.  More clever: daisy-chain the PWM pulses from one PIC to
another and let them synchronise so that the final output is the longest
pulse within the fixed cycle time.  Cycle time could probably be derived
>from the serial sampling rate as above.  Best: Use 1 PIC.  Maybe two if
one just wasn«t QUITE fast enough.  The really exciting idea in PICs is
distributed processing; using two (or more) together when one hasn«t
enough inputs or processing capacity.  You balance the overheads of
making one switch between many tasks against inter-chip communication or
synchronisation.

> 2. Would a newbie be able to produce this level of processing without
> going bald

  But you AREN«T a newbie as per above!

> or should a Basic Stamp version be used?

  Mmmmmm.  They have their uses, but performance isn«t one!

> 3. Should the comparator/DAC combination be replaced by a PIC with a
> PWM output feeding a filtered OpAmp stage?

  For sure!  But use one of the PICs ALREADY there.

> 4. Which development machine could be used economically for a
> production of say 10 units?

  The cheapest!  See Dontronics.   http://www.dontronics.com
... he«s just round the corner (as it were)!


  Cheers!
    Paul B.