RM> A special ISAbus board is
RM> triggered at 300hz to count photons which are backscattered as a
RM> laser  fires into the sky.  This is typically used to measure
RM> atmospheric  ozone.  The measurement interval is time-sliced and
RM> loaded into a  FIFO. When the FIFO becomes full, IRQ7 is asserted
RM> and a routine  written in assembler reads all the time slices from
RM> the FIFO which is  adressed at D000:0000.

Can you use a bigger FIFO? That will reduce the IRQ rate and amortize
interrupt & I/O processing over a bigger "chunk" of stuff. Port I/O
from the ISA bus is very slow compared to processors that can run OS/2
v2.x (386 and above). You can get FIFOs that go from 2Kx9 to 8Kx9
quite inexpensively; since there are no address pins, these are pin-
compatible with each other. You can also use "half full" signals in-
stead of "full" signals to reduce the need for blazing IRQ response. If
you can set them up thru your ISA interface easily, there are even
FIFOs with programmable signals that you can set to a more reason- able
"almost full" value. Switching from "full" to
"half full" is done
simply enough with an Xacto knife and yellow wire held with hot glue
until the next rev. of your ISA PC board.

If you have a chance at full PC board rework, consider (for both DOS
and OS/2) multiplexing the 16-bit values into a 32-bit FIFO (four
x9s or 2 x18s) addressed at consecutive port addresses. Then, you
can use 32-bit PIO instructions to unload them, since 386 and above
devolve REP INSDs into multiple 16-bit ISA reads faster than two
INSWs. Of course, you use REP INSD or REP INSW with CX set to
the FIFO size you're unloading. So, if you manage to create a half-
full signal from a 2Kx18 FIFO, you'd set CX to 1024 and do a REP
INSW to unload the half, then switch to a simple loop with single
INSWs to unload any remainder that's accumulated between the IRQ
and actual service.

If you get FF from the FIFO, you have to unload as many full record
sizes (400 in your example) as you can when you're able to service it
and then trash any partial record, since you have an incomplete data
set (and set all the appropriate flags).

I've done this in DOS with 20MHz burst data coming in, and believe
me, you want to 1) minimize interrupts by using cheaply available
hardware and heuristics 2) once you get IRQ, use every possible
technique, including arranging the ISA hardware to use consecutive
ports for INSDs, to minimize service time.

I think you could get this done in OS/2, but you'd need to write a
device driver. This is going to have to be at least partially MASM,
and you will end up paying 'way more than $300 for it. Debugging
it won't be fun. If you can get the hardware people to oomph the
FIFO some, it will really help...and isn't your DOS code a bit dicey
depending on FF from the FIFO?? One user wanting to run some
TSR or something that nails IRQs awhile and you lose data. To me,
FF is a fault signal, not "data ready"!

If you plan to control the OS/2 machine and add functionality to
your product, fine. Otherwise, why hurt yourself by having to make
your real-time product adapt to the growing mass of OS/2
applications? There is now, for example, LANTASTIC for OS/2,
and there is LANTASTIC for DOS. Very cheaply, a stand-alone
inexpensive DOS box, perhaps sans monitor, could run your DOS
s/w and, with mods, process the data and send it to an OS/2 or
whatever machine every 10 minutes.  Integrating a call to a
remote filesystem into your processing, and dealing with the
net s/w overhead is possibly far easier than dealing with an 
OS/2 driver and all possible OS/2 apps that could be there
zipping in and out of critical sections, not to mention the OS.

___
 X KWQ/2 1.2g X Rhode Island: the Liberian flag of US licence plates.
--- Maximus/2 2.02