jr@frog.UUCP (John Richardson) (08/12/89)
In article <14537@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > In article <[24e0fbce:83.2]un.unix.i386;1@tronsbox.UUCP> tron1@tronsbox.UUCP (K.J.Jamieson) writes: > >>[I sez] > >> If you assign COM1: to > >>anything other than a built-in AT386 serial port (COM1..4), then VP/ix > >>will only let you open COM1 as a vanilla file handle (you may also be > > > >I dont know, I have run Procomm Plus and several "messy" programs on an > >INTELLIGENT I/O board by MAXPEED Inc. This board runs 8 ports at 19200 and > >has no problems with anything I have tried under VPIX. > > > >NOT saying that the above quote is wrong , only that it does not seem to > >apply to procomm. > > OK let me expand a little -- if you assign COM1: to anything whose VP/ix > Direct Device Access (DDA) driver cannot make it *LOOK* like a built-in > AT386 serial port (COM1..4), then VP/ix will bomb you out when you try > to run ProComm. ProComm and its ilk want to see an 8250 at one of the > magic addresses. If someone has a clever enough driver to map something > alien into the proper I/O address space and decode all the bits, then > God bless 'em. I can't imagine doing it for a virtual terminal which > was the original request. I know for a fact that it doesn't work with, > say, the IPC 802. > > If the MAXSPEED board has something 8250-compatible in it, like 16550's, > then the mapping should be a snap. > -- Its not hard. Its such a simple chip that it can be done in an evening if someone has ever programmed one before. You can emulate data ready and tx ready in a virtual interrupt and line status register, and the modem control stuff is also as easy. You can even emulate a "baud rate". There are 8 general registers in which one does nothing, and 2 baud rate registers. So it should not be a large program as well. I am writing a PTY driver for a window product I getting ready to release because stock ISC PTY drivers do not support O_NDELAY. If this is an important feature, I could implement it. JR