Thanks to all who contributed here, I'm learning a lot.
As to what is 'real time' -- as you can probably tell by watching the video at the URL, the robots were dynamically stable - they had to react within a millisecond (Read sensors; do all control; storage of data for post-run analysis, run all the low-level joint servos (12 of them on the 4-legged machine) -- and because we did not have sensors for everything, some had to be synthesized (e.g. if you have a position sensor, and you take regular samples, you can approximate velocity). This requirement means that you need low 'jitter' from when the pin goes high (it was usually controlled by a clock) to when you can read the raw sensors - obviously, that was done first to minimize this jitter. So to me, 'real time' means response within some specific number of microseconds.
At one point, Greg, I built a Z8002 + Weitek floating point chip to sit between the vax and the 4-legged robot. This indeed helped because now the low-level control (servoing) was done by this Z8002+Weitek, and the 'planning' was done in the vax. It was about 4x faster than the vax could servo; the joint motion was very smooth, because there was also less jitter (it wasn't running unix).
We ended up not using it after all that effort because (1) The ability to have 'everything' on one machine was a Big Win. and (2) Now you had two different software stacks, which increases the overall complexity. The biggest 'win' having it all on one machine was for data collection and analysis: the kernel driver locked down a lot of memory, and wrote dozens of sensors and computed values into a big circular buffer. When the robot failed (which was 90% of the time), we push another button, generating an NMI, which would freeze the circular buffer. Recall, this driver was activated by simply issuing an ioctl() to activate the driver. When the time-sharing part had control again, the data were copied out of kernel space into user space with another ioctl(). And of course the software to drive the graphics display was also on the vax, so literally a few seconds after the robot crapped out, we were looking at data from the run.
I think the lesson is: never discount the communications issues when distributing computation. They add system complexity and often delay.
With the RPi4 NetBSD support coming along nicely, I'd expect to use this. It might be nice to be able to 'dedicate' a core to servicing the interrupt, leaving the other 3 to continue regular operation. Multi-core I would hope would make things that much easer for this problem.
I'll look at gpioirq(4) and gpiopps(4) - sounds promising. I'm happy to hear the Global Interrupt Enable is used for only short times; and yes I bet a high IPL will work.
------------
There is another motive, which is to show how it's possible to run a modern unix with a Real-Time process, specifically for robot control. The other *nix OSs out there don't do Hard Real Time, the best I've seen is a microkernel below a regular kernel (not rump). Again, this makes things complicated.
I'll work on it and maybe it'll all 'just work'.
Thanks everybody,
Mike