gfr@cobra.mitre.org (Glenn Roberts) (02/28/89)
> We have found that both the 386i serial port and ports on a multi- > port card (Comtrol h550) operate fine under Unix, in both directions, > upto 9600 baud... <but under DOS> ...When trying to transmit files > between two machines, 1200 baud is ok, but any higher causes DOS > window to evaporate There's no question that the place you're most likely to get into trouble on the DOS side of a 386i is any software that tries to do "real time" interrupt handling. This includes communication boards, speech boards, A/D converters, etc. Remember that the DOS interrupt handlers aren't really talking to the hardware directly - they're going through Unix! Sun's answer to this is likely to be "use the Unix side" (e.g. run Kermit in a shelltool). I understand that this isn't always the answer though. - Glenn Roberts, The MITRE Corp., McLean VA (703) 883-6820 gfr@cobra.mitre.org
guy@uunet.uu.net (Guy Harris) (03/30/89)
>Remember that the DOS interrupt handlers aren't really talking to the >hardware directly - they're going through Unix! Are they? The 80386 has an "I/O Permission Bit Map" that, I think, lets an OS allow non-privileged programs (including DOS programs running in a DOS emulation) directly manipulate *some* devices, while not allowing them to manipulate *all* devices. I don't know whether the implementation of VP/ix on the '386i uses this. I also don't know whether it allows non-privileged DOS programs manipulate the serial ports. However, this *still* doesn't necessarily mean "real-time" interrupt handling will work well; just because the program can directly bang on the device with I/O instructions doesn't mean it'll instantly see interrupts from the device (for instance, what if the interrupt handling code is paged out, assuming DOS tasks are paged?).