GW>
  > [...] with default COM_DIRECT_ACCESS off LapLink 4.0a
  > reports a 16450 and fails self test, if I set COM_DIRECT_ACCESS on it
  > reports a 16550A and tests OK.
  > [...]
  > I've just swapped to SIO, and indeed LapLink can't determine the UART
  > type and fails self test with it installed.
GW>
  True, and interesting (trust LapLink to muck about like that).
  But, like the other information presented here, it doesn't really help
  this bloke, because he isn't having trouble with it failing the
  self-test.  He actually has LapLink *running* on OS/2.  It just appears
  to be having trouble receiving information from the remote system.
  Refer back to the message that I was replying to.
  As it happens, he has a 16550 UART.  So it looks like I haven't managed
  to diagnose the underlying cause of his problem, either.  (-:
GW>
  > JdeBP> This is easily explained if you happen to have a 16450, or other
  > JdeBP> unbuffered UART, for your serial hardware.  On DOS, LapLink just 
sit
  > JdeBP> in a dedicated loop waiting for characters.  However, OS/2 is
  > JdeBP> multitasking, and it is possible for a second character to be
  > JdeBP> received by the UART before its predecessor has been read from
  > JdeBP> the 1-character UART receive buffer, because OS/2 may be doing
  > JdeBP> something else at the time that the character receive interrupt
  > JdeBP> occurs.  This results in character loss [...]
  >
  > My experience of using LapLink is that it requires the serial interrupt
  > and uses it, so I don't believe this criticism is valid [...]
GW>
  The receive interrupt generated in the VDM is generated by the Virtual
  Machine Manager, in conjunction with the VCOM/VSIO virtual device
  driver.  The *real* receive interrupt vectors into COM/SIO, the
  *physical* device driver.  And this is where the problem I am describing
  lies.
  It's _nothing_ to do with the virtualisation side _at all_.  It's to do
  with interrupt latency in the *physical* device driver due to the nature
  of a multitasking system.  A UART with an 8 character receive buffer
  such as the 16550 won't suffer from receive overrun due to interrupt
  latency.
  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01
---------------