COM1 question

John Richardson jr at frog.UUCP
Sat Aug 12 11:04:00 AEST 1989

In article <14537 at bfmny0.UUCP>, tneff at bfmny0.UUCP (Tom Neff) writes:
> In article <[24e0fbce:83.2]un.unix.i386;1 at tronsbox.UUCP> tron1 at 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. 


More information about the Comp.unix.i386 mailing list