Request for Real-time HW/SW Info

[Mike Borza]

[Moderators Note:-  This newsgroup goes around the planet.  I've been
    asked to try and ensure that i/ the content is worth it, and ii/
    that it isn't too long.  With this in mind, in future, would people
    please try and be brief.   Thanks...  - Der]

I tried emailing this response to 
         <gatech!ucsd!nprdc.arpa!trejo at uunet.UU.NET>
(whose name I've now lost), but it bounced, so I'm posting it here.
This is a response to a recent request for information on real-time
physiological data acquisition.

I've worked on a similar project, with the exception that we
had considerably tighter timing requirements (athough still not
particularly tight as real-time data acquisition systems go).  We were
working at extracting audio evoked potentials from single trials on
4 channels at 10 kHz/channel.  (Visuals were a little down the road.)
We were able to do this with an 8 MHz IBM 339 AT (a machine I'd not
recommend).  By carefully interleaving start of conversion and a
computation loop, we could collect on 4 channels at this rate with a
simple artifact rejection algorithm in place.

Anyway, I'd suggest that you change your approach slightly.  I like your
idea about sampling the screen to resolve your stimulus arrival time,
but I'd suggest using an indirect method to determine the start of the
stimulus.  From your posting, it appears that you're going to go with a
PC/AT or 386/AT type machine, either of which should suffice.  I'd suggest
running under MS-DOS (more about this later).  From the description of
your video requirements, you'll be running a VGA or enhanced EGA.  Since
you know (or can determine) the character (or pixel) position on the
screen, you can sit in a tight loop sampling the status bit in the EGA/VGA
registers which indicates the beginning of horizontal re-trace.  You can
compute the start of stimulus as an offset from this time using the
character position and the scan rate, to within the loop time and
the dot clock time.  Naturally, you also have to be careful to write the
character to video memory such that you know that it doesn't appear one cycle
early.  If necessary, your tight loop can also be collecting data during
the pre-stimulus phase.

I'd suggest MS-DOS rather than UNIX (with real-time extensions), and just
take over the machine during your data collection sessions.  This gives you
easier control over the machine and removes some possible unwanted
interruptions.  QNX is another possibility, but I'm not sure of the
interrupt latency.  I did all the code development and maintenance for our
system on a '286 running Microport Unix.  To test the high-level code,
I wrote an emulator to fake the d/a and a/d subsystems.  The low-level
stuff had to be debugged in situ on the MS-DOS machine.  The data
acquisition subsystem was a single-board unit from Scientific Solutions
(a.k.a. Tecmar) for about $CDN 1000-- there are probably better ones around.
We built the outboard antialiasing filters, sample and hold amps, and
digital I/O isolation ourselves from off-the-shelf chips.  Given your
rather coarse timing requirements, you can probably make do with a PC/AT
clone at 10-16 MHz, but given the price differential, I'd just get a cheap
16 or 20 MHz 386 box.  The bonus is that it's a nice cross development
environment for DOS if you get VP/ix or Merge for it, so it's easy to test
your high level stuff, and you can use it for something else when you
finish this line of research (or your funding runs out:).  (You won't be
able to test the low-level stuff that reads EGA reg's or anything like
that.)  I'm using ISC's 386/ix and like it a lot (though I no longer do
any DOS work, and only started VP/ix out of curiosity a couple of
times).  For bang-fer-the-buck, Everex's ENIX seems to be the best value
these days.

I'd also suggest polling the various port states rather than writing
interrupt handlers.  On a slower AT box, the interrupt latency can be
several microseconds, which would have completely fried our single
channel 40 kHz experiments.  You can test for false responses at various
points and have the software restart the collection automatically in
the event of "super-human" response times.

Hope this helps.
mike borza       <antel!mike at maccs.uucp  or  boopsy!mike at maccs.uucp>